[00:04] <ari-tczew> kees: around?
[00:06] <kees> ari-tczew: hi!
[00:06] <ari-tczew> kees: hello. have you got time for sponsor emacs23? IIRC you have expierence with this package,
[00:07] <kees> ari-tczew: perhaps tomorrow. I'm deep in kernel code at the moment. :)
[00:07] <ari-tczew> kees: cool. you want to be subscribed to bug?
[00:07] <kees> ari-tczew: sure
[00:08] <ari-tczew> kees: done
[02:49] <JackyAlcine-AFK> Hello, where would I go to attempt to recruit individuals for a new project?
[02:50] <JackyAlcine-AFK> The project's Ubuntu-orientated, designed to integrate with the OS.
[02:58] <persia> JackyAlcine, "the internet".  More seriously, you'd do better to create a nice home page, blog about it, announce releases to some news sites, etc.
[03:01] <JackyAlcine> Alright, thanks persia.
[06:03] <pitti> Good morning
[06:03] <pitti> micahg: yes, uploading with -v to include both versions
[06:10] <micahg> pitti: is bug 707104 owrth reuploading for?
[06:10] <micahg> pitti: and good morning :)
[06:12] <pitti> micahg: if you are uploading anyway, feel free to fix this as well
[06:13] <micahg> pitti: no, this was the bug, there's no regression, it's a new bug introduced by the updated docs
[06:38] <pitti> Riddell, ScottK: do you know what happened yesterday that suddenly made all KDE being uninstallable?
[06:53] <pitti> Riddell, ScottK: ah, got it; followed up to bug 682404
[07:03] <pitti> ogra: do you want to keep bug 615773 on the alpha-2 blocker list? who will work on it? or move to beta?
[07:38] <bryceh> pitti, you announced that alpha-2 is coming out in 2 days, but according to https://wiki.ubuntu.com/NattyReleaseSchedule it's not until feb 3?
[07:39]  * micahg was just going to ask about that
[07:39] <pitti> bryceh: oh, d'oh
[07:39] <pitti> darn, I was sure we talked about it in Dallas, I must have mixed it up
[07:39]  * pitti unannounces then, thanks for pointing out1
[07:48] <bryceh> pitti, ah whew, thanks.
[07:51] <bryceh> pitti, btw rough plan of attack for X updates for alpha-2:  https://wiki.ubuntu.com/X/Roadmap/Natty
[07:52] <pitti>  bryceh: ah, thanks; a lot of that is already in edgers PPA, right?
[07:53] <pitti> bryceh: did you get a lot of feedback on that?
[07:54] <superm1> bryceh, thanks for uploading that intel package.  it would be easier to test on a new live disk.  i'm unfortunately going to be OOO for the week so i won't have access to that hardware most likely.  some of the canonical QA guys were noticing similar crashes though, so you might check with them for a new crash report (or if you want to be optimistic; success report)
[07:55] <bryceh> pitti, yep most all of it is in edgers
[07:56] <superm1> bryceh, bug 706117 was the bug that's most likely the duplicate that i was seeing them with some reports on
[07:56] <bryceh> we got a little testing.  More would be nice but enough for sanity checking
[07:58] <bryceh> superm1, ok yeah if others have the same problem maybe we can get a fixed verification from them.  I think once we get the new X stack in for alpha-2 it'll be harder to verify this fix.
[08:11] <didrocks> good morning
[08:14] <dholbach> good morning
[09:27] <doko_> seb128: are the current gtk+2.0 binaries in natty usable? asking because the last upload ftbfs
[09:28] <seb128> doko_, yes, I think someone would have noticed if gtk was not usable
[09:28] <doko_> ok, thanks
[09:28] <seb128> kenvandine was working on the build issue
[09:29] <seb128> so should be fixed this week
[09:29] <tkamppeter> directhex, did you have any success with Kyocera?
[09:35] <pitti> superm1: can you please make bug 692911 public? otherwise it's impossible to check the state of this SRU and move it to -updates; there's another dell-recovery upload in the queue which is blocked by that
[09:36] <pitti> superm1: actually there are two
[09:37] <pitti> superm1: I'll reject them both, can you please upload with either a merged changelog or with using -v to include all versions which are currently in -proposed?
[09:37] <\sh> hmmm...
[09:37] <\sh> Setting up tomcat6 (6.0.28-2ubuntu1.1) ...
[09:37] <\sh> sed: -e expression #1, char 118: unknown option to `s'
[09:38] <pitti> using s/// on a file path containing '/'?
[09:41] <\sh> hmm..reading tomcat6.postinst the only seds in there are
[09:41] <\sh> http://paste.ubuntu.com/558026/
[09:43] <\sh> pitti: I don't mind that error...but the problem is lucid/maverick -> security update ;)
[09:43] <\sh> + sed s/^JAVA_OPTS=.*$/JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Dnetviewer.monitoringConfig=/etc/netviewer/monitoring.properties"/ there is the bugger
[10:21] <jfer> hi i was wondering if Acire is available for ubuntu 10.10
[10:21] <doko_> ScottK: please could you add the preprocessed source for the bug reports with the symbols issues? just for the files with relevant symbol(s), including the gcc command line
[10:28] <ogra> pitti, set to beta
[10:28] <ogra> pitti, thanks for the reminder
[10:28] <pitti> ogra: thanks
[10:34] <\sh> mdeslaur: I think we have to reword the last sed line in tomcat6.postinst
[10:34] <\sh> mdeslaur: it fails when you have some strange JAVA_OPTS line with slashes
[11:10] <\sh> mdeslaur: bug #707348
[11:11]  * ogra sees cjwatson's bug karma go through the roof today
[11:38] <AnAnt> Hello, is there some page (preferably on Debian) regarding listing -lfoo before the object files using it when linking ?
[11:39] <RAOF> AnAnt: I think it's DSOLinking; let me google it.
[11:39] <AnAnt> ok
[11:39] <AnAnt> erm, I don't think so
[11:40] <AnAnt> http://wiki.debian.org/ToolChain/DSOLinking
[11:40] <RAOF> Yup, that's it.
[11:40] <AnAnt> but I don't see the mention of what I asked about there
[11:41] <AnAnt> it talks about using --as-needed
[11:41] <RAOF> Hm, you're right.
[11:43] <RAOF> But what you're talking about is the fact that objects that contain definitions need to appear to the right of the objects that reference those definitions on the linker line, right?
[11:45] <AnAnt> and yup
[11:45] <AnAnt> yup
[11:47] <RAOF> So, I think that's an interaction with --as-needed.  The linker *always* has that positional behaviour, but with --as-needed if the library hasn't been used to resolve some unresolved symbols already, it's dropped.
[11:48] <AnAnt> RAOF: so you mean, that this is required only when --as-needed is used (which is the case in natty), right ?
[11:49] <RAOF> The linker *always* has that positional behaviour; you should be listing objects with unresolved symbols before the libraries which resolve those symbols regardless.
[11:49] <RAOF> I *think* that --as-needed makes things fail more often if you don't do the right thing.
[11:52] <RAOF> AnAnt: You'll notice that the Debian page says “Object files, including .la files from a package build must appear before any library on the command line”, although it doesn't justify that.
[11:53] <AnAnt> RAOF: but what I am talking about is that the -lfoo should appear before the object files, not vice versa
[11:53] <RAOF> Under what circumstances is that necessary?
[11:54] <AnAnt> RAOF: "gcc -lncursesw test.c" failed, yet "gcc test.c -lncursesw" worked !
[11:55] <AnAnt> RAOF: that's on natty , on maverick it didn't matter
[11:55] <RAOF> To me, that looks like the -lncursesw is after the object files, as expected.
[11:55] <RAOF> (When it works)
[11:56] <AnAnt> oh, sorry, you're right
[11:57] <cjwatson> yes.  folks who've worked on other Unix systems will have seen similar things there
[11:57] <cjwatson> (aside from AIX, which is totally backwards)
[11:58] <cjwatson> this is one of those cases where gcc let people get away with stuff so they didn't notice, but if you were trying to be portable you'd work left-to-right anyway
[12:24] <nigelb> cjwatson, pitti: Could either of you show the door to the troll in -release?
[12:25] <nigelb> wait, never mind.
[12:26] <persia> nigelb, You had the right channel at :49, although response took a bit :)
[12:26] <nigelb> persia: Well, true. But not many there had access.
[12:26] <nigelb> persia: Except for the council.
[12:27] <persia> True, but that's typically enough, if it's needed.
[12:27] <nigelb> So, I poked folks who actually did have access and would probably be around.
[12:27] <nigelb> persia: Noted for future :)
[12:28] <nigelb> persia: Also, are you backlogged on PM?
[12:29] <persia> Very, although some is likely to slip, truthfully
[12:43] <Daviey> cjwatson, Hi!  Do you have any thoughts on bug #699665?
[12:57] <cjwatson> Daviey: I've looked, but I don't see any way to recover enough information from just the address dump supplied
[12:57] <cjwatson> Clint's right, we need a core file really
[12:58] <mdeslaur> \sh: could you nominate the affected releases in bug #654549 and subscribe ubuntu-sponsors, please?
[13:01] <Daviey> cjwatson, my thoughts aswell.
[13:01] <Daviey> thanks for looking
[13:01] <\sh> mdeslaur: well, 6.0.28 is in maverick but for lucid (6.0.24) it needs to be fixed with another upload..right?
[13:06] <mdeslaur> \sh: lucid doesn't seem to have the seds in its postinst, but maverick does
[13:07] <mdeslaur> \sh: so, only maverick is affected I think
[13:07] <\sh> mdeslaur: ok...nominated bug #654549 for maverick
[13:07] <\sh> mdeslaur: to be sure, I'll check lucid on a newly installed tomcat appserver :)
[13:13] <ari-tczew> hello folks, I need your help
[13:14] <ari-tczew> slangasek: is it very necessary ship separate binary package smartdimmer? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nvclock/natty/changes?filter_file_id=smartdimmer.install-20090626033400-d3ab2kzykpm31he0-184
[13:16] <ari-tczew> I'm trying forward that change to Debian, but maintainer asking me:  Is it useful to have smartdimmer as a separate package? Can it be used on non-nvidia hardware, too?
[13:16] <ari-tczew> tseliot: maybe you could give a feedback? ^^
[13:30] <tseliot> ari-tczew: I don't think smartdimmer is used with any driver other than nvidia
[13:31] <ari-tczew> tseliot: so does it make sense to separate smartdimmer from nvclock?
[13:33] <tseliot> ari-tczew: if what I said is correct, then I don't see the need to make it a separate package
[13:34] <ari-tczew> slangasek: could you give a feedback to above? ^^
[13:37] <zyga> mvo, hi
[13:38] <zyga> mvo, just a quick question, please point me to a more appropriate person if you can, why can pip install stuff into /usr/local while gem puts stuff into /var/lib/gems/
[13:39] <zyga> mvo, this is in regard to bug 706603
[13:41] <tseliot> ari-tczew: mjg59 (in #ubuntu-kernel) should know if smartdimmer can be used with other drivers
[13:43] <ari-tczew> tseliot: thanks, I'm there
[13:54] <cdbs> The new release of ubuntu-dev-tools has broken many things for me
[13:55] <cdbs> I get an error, that /usr/local/bin/debian.csv and ubuntu.csv cannot be found
[13:55] <tumbleweed> /usr/local/bin?
[13:55] <cdbs> when I sudo touched them, the error got supressed, but pbuilder-dist began to fail to find out the proper mirrors
[13:55] <cdbs> tumbleweed: I am sudo python setup.py installing the version in bzr
[13:56] <tumbleweed> cdbs: eek, I really don't recommend that
[13:56] <cdbs> tumbleweed: earlier when I installed from the package, the error came that ubuntutools.distro_tools didn't exist
[13:56] <tumbleweed> cdbs: there are daily buids in deb form: https://launchpad.net/~udt-developers/+archive/daily
[13:56] <cdbs> so I uninstalled the package and installed from bzr
[13:57] <tumbleweed> cdbs: I suggest removing everything ubuntu-dev-tools (and ubuntutools) related from /usr/local
[13:57] <cdbs> okay
[14:00] <doko_> janimo_: is there anything which should prevent starting an armel/universe test rebuild?
[14:02] <lool> cjwatson: hey, sorry for the delay; tried your binfmt-support branch, but didn't work for me
[14:02] <lool> cjwatson: file /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true
[14:02] <lool> /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
[14:02] <lool> src/update-binfmts --find /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true
[14:02] <lool> (no output)
[14:04] <lool> cjwatson: strace shows it going over open("/var/lib/binfmts/qemu-microblaze", O_RDONLY) = 4
[14:04] <lool> and others
[14:06] <cjwatson> lool: can you put the /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true binary somewhere for me?
[14:07] <lool> cjwatson: http://people.canonical.com/~lool/true
[14:07] <janimo_> doko_, nothing I know of
[14:07] <janimo_> doko_, it takes a few builders for itself and that's all right?
[14:08] <doko_> janimo_: hmm, just see that mesa is not installable. will wait until bryceh fixes it
[14:11] <doko_> bryceh: I only see that x11proto-xext did fail to build
[14:16] <cjwatson> lool: working on it, thanks
[14:16] <lool> cjwatson: The loop on breakpoints seem to not go over the ones with magic
[14:16] <lool> while (gl_list_iterator_next (&format_iter, (const void **) &binfmt,
[14:16] <lool> This only goes over python2.6, wine, jexec and cli
[14:16] <cjwatson> lool: it's because \x7fELF is misparsed as \x7fE L F
[14:16] <cjwatson> I'm fixing it now
[14:18] <lool> Hmm I was looking at the wrong loop anyway
[14:19] <lool> cjwatson: So what do binfmt-support/kernel do if multiple interpreters match?
[14:21] <cdbs> tumbleweed: thanks. works well now
[14:21] <superm1> pitti, i won't be able to make that public, i shouldn't have included it in the changelog.  if you can reject them i'll upload again with a merged changelog instead that excludes that bug
[14:22] <cjwatson> lool: tries them in sequence
[14:22] <cjwatson> lool: see the comment in update-binfmts(8)
[14:25] <pitti> superm1: ok, please do that then
[14:27] <cjwatson> lool: please update and retry?
[14:30] <lool> cjwatson: Works now!  I get a single line of output: /usr/bin/qemu-arm-static
[14:30] <cjwatson> good
[14:31] <cjwatson> I'll upload that then
[14:31] <ogra> uuuh, magic !
[14:31] <ogra> :)
[14:31] <ogra> awesome
[14:37] <lool> cjwatson: I'll relay that to Roger; thanks a lot!  do you have plans to upload this at a specific time in Debian?
[14:37] <lool> cjwatson: Also, do you know if binfmt-support is used in non-Debian/Ubuntu distros?
[14:38] <lool> cjwatson: I'm curious whether this is Debian-specific technology and whether it needs to be ./configure-able in schroot
[14:47] <cjwatson> lool: I already uploaded it to experimental and synced to natty
[14:48] <cjwatson> lool: I don't know of any non-Debianish distributions using binfmt-support right now; I would be happy to help make it work for them.  Is it not ./configure-able in schroot right now?  It should be
[14:50] <tumbleweed> cdbs: great :)
[14:51] <pitti> cjwatson, mdz, kees: 10-minute reminder for TB meeting
[14:51] <lool> cjwatson: It's not yet in schroot; right now, we were discussing something like an "use_qemu" flag which meant "run file $chroot/bin/true to detect arch, and copy /usr/bin/qemu-$arch-static into the chroot"
[14:52] <lool> cjwatson: But I proposed checking with you whether we could get the information straight from binfmt-support, which is much nicer
[14:52] <cjwatson> oh I see what you mean, I misunderstood
[14:52] <lool> cjwatson: Thanks a lot for uploading
[14:53] <cjwatson> I thought you meant "should it be possible to unpack the binfmt-support source package in schroot and run ./configure"?
[15:07] <Riddell> hmm, libdrm broke natty
[15:10] <zyga> doko_, around?
[15:10] <chrisccoulson> Riddell, and i was just about to upgrade ;)
[15:11] <zyga> marjo, ping
[15:11]  * zyga needs someone to talk to ;P
[15:20] <tseliot> Riddell: yes, we're discussing the problem with Sarvatt in #ubuntu-x
[15:28] <chrisccoulson> oh, i see what you mean about drm breaking natty now
[15:28] <chrisccoulson> i can't build firefox anymore ;)
[15:38] <pitti> bdmurray: did you file a bug about "bug supervisor not being able to set bug reporting guidelines for Ubuntu as a whole (not just packages)"?
[15:38] <Sarvatt> the experimental libdrm-nouveau1 (who's ABI and API breaks monthly) is basically Priority: required right now thanks to mountall/plymouth and the package was renamed to libdrm-nouveau1a in debian this last abi break
[15:47] <chrisccoulson> Sarvatt, what's the plan then? i'm basically blocked on the libdrm issue now ;)
[15:47] <chrisccoulson> (no pressure) :-)
[15:47] <cjwatson> Sarvatt: is it just a matter of rebuilding plymouth?
[15:47] <cjwatson> Priority: required (unlike Essential: yes) isn't that desperately sticky - we can make it fall out of that once plymouth no longer needs it
[15:48] <Sarvatt> cjwatson: can't rebuild plymouth because it requires libdrm-dev, setting up a chroot to build plymouth would bring in plymouth with the libdrm-nouveau1 requirement..
[15:48] <OdyX> Hrm. /me is having a weird libdrm issue too. Shouldn't mesa get rebuilt against latest mesa-dev to get an updated depends on libdrm-nouveau1a ?
[15:48] <Sarvatt> OdyX: we have a new mesa waiting to be uploaded but this needs to be fixed
[15:48] <cjwatson> Sarvatt: isn't libdrm-nouveau1 still in the archive though?
[15:49] <Sarvatt> yeah, libdrm-nouveau1a conflicts with it
[15:49] <doko_> zyga: ?
[15:49] <cjwatson> why dear god why?
[15:49] <cjwatson> oh yeesh, same files
[15:49] <cjwatson> what was the point of renaming if it's just going to ship the same files?
[15:50] <OdyX> Sarvatt: Okay. (This makes my natty PPAs with packages Build-Depending on libgl1-mesa-dri and libqtwebkit-dev fail…)
[15:50] <OdyX> cjwatson: ABI bump ?
[15:50] <Sarvatt> i've already got a revert of the rename prepared but the debian guys aren't happy about that
[15:50] <cjwatson> I suppose they're probably right
[15:50] <cjwatson> can I see a build log that goes wrong?
[15:51] <chrisccoulson> http://launchpadlibrarian.net/62773726/buildlog_ubuntu-natty-amd64.xulrunner-2.0_2.0~b10%2Bbuild1%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:51] <Sarvatt> upstream doesn't bump the sonames but the abi/api's are incompatible, up until now we've just been rebuilding everything when we update but they have to worry about unstable/experimental issues
[15:51] <cjwatson> let me think about this for a bit
[15:51] <chrisccoulson> (i assume that's the same issue in my build log)
[15:52] <cjwatson> ok, using Conflicts for this is against current policy, which may be part of why it broke
[15:52] <cjwatson> the correct package relationships would have been:
[15:52] <cjwatson> Breaks: libdrm-nouveau1
[15:53] <cjwatson> Replaces: libdrm-nouveau1
[15:53] <cjwatson> I suspect that if you do that then it will be happier
[15:53] <cjwatson> (reference: policy 7.4)
[15:53] <cjwatson> `Breaks' should be used
[15:53] <cjwatson>         * when moving a file from one package to another (see Section 7.6,
[15:53] <cjwatson>           `Overwriting files and replacing packages - `Replaces''),
[15:53] <Amaranth> yay breaks
[15:53] <cjwatson> so try that first; if even that doesn't work, then we could temporarily remove the Breaks to bootstrap our way out of this
[15:55] <Laney> doko_: re your email — do you have a problem with the haskell rebuilds? I'm ready to upload the next round but just want to check your concerns...
[15:56] <cjwatson> thinking about it Breaks will probably (ahem) break it too.  I suggest Replaces alone until we've unstuck the builds, and then we can add the Breaks back in afterwards
[15:57] <cjwatson> it should definitely not be Conflicts though.  That would make maverick->natty upgrades a total nightmare.
[15:59] <OdyX> cjwatson: hrm. Conflicts are an obligation IMHO; otherwise you allow both versions to be unpacked at the same time, while sharing the same files
[16:00] <cjwatson> OdyX: this was all gone through on the policy list
[16:00] <mr_pouit> pitti: hey, do you have by chance any idea why gdm is taking its time to kill its gnome-settings-daemon? Here, it is stopped much too late (maybe 10s after the user session is started), therefore it prevents the "real" xsettings daemon for the user session (xfsettingsd) from starting...
[16:00] <OdyX> cjwatson: okay. Sorry.
[16:00] <cjwatson> and Conflicts will cause a vastly difficult upgrade computation
[16:01] <pitti> mr_pouit: not off the back of my hand; I didn't notice that here
[16:01] <seb128> gdm doesn't stop it it seems
[16:02] <seb128> rodrigo was investigating that the other day since users get that on GNOME as well with modern configs
[16:02] <seb128> well it doesn't take 10 seconds to exit rather one but it's enough to make g-s-d fails in the user session
[16:02] <cjwatson> OdyX: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578854 - particularly message #55 onwards
[16:03] <mr_pouit> seb128: ah okay. I was able to preoduce that in a slow vm (hence the 10s ;), but I didn't try on a real hw
[16:03] <mr_pouit> *reproduce
[16:05] <ogra> jhunt, is there any chance the serial support will land in upstart before A2 ? (i have a workitem for it open and need to know if i need to postpone or can set it to DONE before A2)
[16:09] <OdyX> cjwatson: Thanks for the clarification; my bad.
[16:09] <doko_> Laney: do you upload a package more than once?
[16:10] <Laney> if it becomes uninstallable again
[16:10] <doko_> Laney: how would it?
[16:10] <Laney> due to one of its rdepends changing abi
[16:11] <doko_> and that cannot be done by uploading the packages in the correct order?
[16:11] <Laney> that is what is done
[16:11] <Laney> but if one package breaks abi then all packages from that point downwards in the graph must be rebuilt
[16:11] <jhunt> ogra: there is always a chance :) Seriously, there is discussion on the upstart-devel mailing list about this. Scott has questions regarding the strategy. I'll take a look tomorrow and give you and update then if that's ok?
[16:12] <doko_> hmm, ok. just thought I did see some packages uploaded more than once
[16:12] <ogra> jhunt, fine with me
[16:12] <Laney> not intentionally, it's possible that there could be a collision
[16:13] <Sarvatt> any core-dev's around that'd be willing to sponsor http://sarvatt.com/downloads/merges/libdrm-natty-2/ so we can get this libdrm-dev mess out of the way? :)
[16:14] <bdmurray> pitti: yes and I emailed the tech board about it but it was held in moderation
[16:14] <pitti> Sarvatt: sure, doing
[16:15] <Sarvatt> pitti: appreciate it!
[16:18] <Sarvatt> plymouth will need a rebuild and the hardcoded depends changed to libdrm-nouveau1a
[16:19] <cjwatson> I can do that
[16:20] <cjwatson> Sarvatt: re "Temporarily lower", when the temporary period ends, please don't put the Conflicts back, of course, but add Breaks in addition to the Replaces
[16:20] <Sarvatt> thank ya guys so much for the help, was beating my head on the wall on how to get out of that mess without renaming things back to libdrm-nouveau1 :)
[16:20]  * Sarvatt nods at cjwatson
[16:21] <cjwatson> don't thank us until libdrm builds successfully. :)
[16:24] <tseliot> :)
[16:24] <Riddell> TheMuso: who's our current pulse master?  module-device-manager is failing to load for me
[16:25] <ogra> Riddell, beyond TheMuso thats diwic
[16:36] <cjwatson> hallyn: the keyboard configuration junk is known, I'm having a hard time picking it apart but it's on my list
[16:36] <cjwatson> (from #ubuntu-meeting)
[16:36] <cjwatson> it has nothing to do with plymouth, for the record
[16:37] <cjwatson> oh, wait, I misread the meeting log for that last bit :)
[16:39] <ospiracy> string exec ( string $command [, array &$output [, int &$return_var ]] )
[16:39] <ospiracy> spider ill
[16:39] <ospiracy> ukposg|*
[16:39]  * ospiracy osg
[16:40]  * ospiracy $CGI::Pretty::INDENT = $CGI::Pretty::LINEBREAK = "";
[16:41] <cjwatson> ospiracy: whatever this is, it has nothing obvious to do with Ubuntu development - please take it elsewhere
[16:41] <ospiracy>       NAME1=VALUE1
[16:41]  * ospiracy perl Makefile.PL make make test make install
[16:41] <pitti> . o O { is it just me, or do we have a spammer's day today? }
[16:41] <nigelb> pitti: not just you for sure.
[16:46] <hallyn> cjwatson: yeah, i wasn't saying it was plymouth, just that i figured you were busy with plymouth this week :)
[16:46] <hallyn> cjwatson: thanks, long as it's known, i'm good
[16:47] <cjwatson> hallyn: actually it was just that I misunderstood an interleaved comment from SpamapS
[17:16] <charlie-tca> pitti: I verified the plymouth package in -proposed for lucid works
[17:17] <charlie-tca> bug 563916
[17:17] <pitti> charlie-tca: many thanks! would you mind sending that to the bug?
[17:17] <charlie-tca> did
[17:17] <pitti> ah, right
[17:29] <amorphous1> tkamppeter, ping
[17:42] <janimo_> doko_, if a libo build fails midway should it be cleanly restartable using fakeroot debian/rules build or similar? I know that build system is a bit more fragile then usual
[17:44] <pitti> o_O
[17:45] <pitti> python -c '"%s ä" % u"a"' gives me an UnicodeDecodeError, as documented
[17:45] <pitti> but what kind of black magic does pygtk do? python -c 'import gtk; print "%s ä" % u"a"'  -> that works
[17:45] <pitti> (I don't think it's related to stdout -- I'm trying to set a GtkLabel)
[17:47] <broder> that's amazing
[17:48] <pitti> I checked the pygtk source for "textdomain", "locale", "UTF-8", "UTF8", nothing plausible there
[17:48] <Sarvatt> cjwatson: Replaces: wasn't enough it looks like..  http://paste.ubuntu.com/558189/
[17:48] <broder> pitti: i would look for something evil wherever it is that pygtk sets up the separate main loop thread and stuff
[17:48] <pitti> oh, pangomodule.c does
[17:48] <pitti>     /* set the default python encoding to utf-8 */
[17:48] <apw> pitti, could it have changed the default binding for stdout, pushed a unicode thingy onto it?
[17:48] <pitti>     PyUnicode_SetDefaultEncoding("utf-8");
[17:49] <pitti> apw: that was my first guess, but my original program crashes on GtkLabel.set_label(), which doesn't touch stdout
[17:49] <apw> woh that looks scarey
[17:49] <pitti> barry: do you know whether I can do the equivalent of PyUnicode_SetDefaultEncoding("utf-8") in Python?
[17:51] <cjwatson> Sarvatt: can you add '-o Debug::pkgProblemResolver=true' to that?
[17:51] <broder> pitti: i see a sys.setdefaultencoding in the source, but it appears to be ifdef'd out
[17:51] <Sarvatt> cjwatson: http://paste.ubuntu.com/558191/
[17:52] <broder> hmm, no. something more complicated is going on, because sys.getdefaultencoding is #ifdef'd the same way and that works
[17:52] <pitti> broder: hm, not in my copy of pygtk-2.22.0
[17:52] <broder> pitt: sorry, i'm looking in python6
[17:52] <broder> err, 2.6
[17:52] <pitti> broder: anyway, above call looks very much like the reason
[17:52] <pitti> broder: ooh, indeed! that might be the magic
[17:53] <pitti> broder: right, can't call that, not available
[17:53] <pitti> ok, I'm going to actually fix the source then
[17:53] <broder> pitti: which is weird, because it appears to be ifdef'd the same way as sys_getdefaultencoding, which works
[17:53] <tkamppeter> amorphous1, hi
[17:54] <kklimonda> setdefaultencoding is available only during site.py evaluating
[17:54] <pitti> so pygtk hacked around that by using the C API -- cheating!
[17:54] <kklimonda> indeed
[17:54] <broder> kklimonda: well, more that site.py expunges it in its main() function. that's kind of gross
[17:55] <cjwatson> Sarvatt: odd, it looks like it's trying to install the old version of libdrm-dev
[17:55] <cjwatson> waiting for my mirror to update so that I can chck
[17:55] <cjwatson> *check
[17:56] <tkamppeter> amorphous1, you want to talk with me about bug 693922?
[17:56] <Sarvatt> cjwatson: PHEW you were right
[17:56] <kklimonda> broder: right, but the effect is the same.
[17:56] <amorphous1> tkamppeter, yes
[17:56] <Sarvatt> cjwatson: I just caught it in the middle of updating the mirror or something, now it works
[17:56] <amorphous1> tkamppeter,  I wrote you details on the private channel and sent an email
[18:03] <cjwatson> Sarvatt: OK, great
[18:24] <Sarvatt> bryceh: ok RAOF's mesa builds fine with the current packages, can ya sponsor it for him? http://cooperteam.net/Packages/
[18:24] <smb> cjwatson, Colin, is there such a thing as daily (or at least point release) netboot images for Lucid.  I only seem to find the release versions
[18:25] <smb> Oh, nm. I guess its only the pxelinux.0 that needs to be refreshed
[18:27] <Sarvatt> sorry, got booted there
 bryceh: ok RAOF's mesa builds fine with the current packages, can ya sponsor it for him? http://cooperteam.net/Packages/
[18:27] <micahg> pitti: sorry to ask again, but I don't recall receiving an answer is bug 707104 worth reuploading for?
[18:27] <Sarvatt> here's a build log http://sarvatt.com/downloads/mesa_7.10-1ubuntu1_i386.build
[18:32] <bryceh> Sarvatt, sure on it now
[18:49] <cjwatson> smb: look in lucid-proposed rather than lucid
[18:50] <smb> cjwatson, Ah. Thanks for the pinter
[18:50] <smb> pointer even
[18:51] <smb> Seems to be beer-o-clock in my mind...
[18:52] <bryceh> Sarvatt, (still reviewing changes)
[18:54] <bryceh> Sarvatt, ok I'm ready to sponsor RAOF's mesa upload.  Any reason I should hold off?
[18:54] <Sarvatt> bryceh: nope, everything looks good to me
[18:55]  * bryceh holds his ears and pushes the mesa plunger.  'Fire in the hole'
[18:55]  * SpamapS dives for cover
[18:55] <bryceh> uploaded
[18:56] <bryceh> I should send out an announcement too, before we get too much further into these X updates
[19:01] <RoAkSoAx> kirkwin 3
[19:01] <RoAkSoAx> jeeeeeeeeez
[19:54] <jhunt> quit
[20:14] <ari-tczew> bryceh: could you be more verbose on bug 675622 ?
[20:49] <lostinlinux> Hey everyone.. good afternoon
[21:23] <bryceh> ari-tczew, tormod seems to have covered it already
[21:34] <ari-tczew> bryceh: you wrote only "+1 to a sync for this." but would be nice to write why delta should be dropped even if you're developer.
[21:36] <bryceh> ari-tczew, *shrug* I think tormod already covered it, no need for me to add noise
[21:37] <ari-tczew> bryceh: what is "tormod" ?
[21:37] <tormod> ari-tczew, hehe that is me :)
[21:37] <ari-tczew> aaaaaaaaa
[21:40] <ari-tczew> tormod: are you able to see changes in http://pastebin.ca/1447378 ?
[21:40] <ari-tczew> this page couldn't be loaded for me :?
[21:41] <tormod> ari-tczew, no that pastebin is lost. pastebin != documentation
[21:41] <ari-tczew> tormod: Agreed.
[21:43] <ari-tczew> tormod: unfortunately, merge ATM
[21:43] <ari-tczew> tormod, bryceh: debian/watch from Ubuntu works, in Debian not
[21:44] <ari-tczew> I'm looking next
[21:44] <tormod> ari-tczew, what do you mean? what do you need that watch for, if we have it synced?
[21:44] <ari-tczew> if someone wants to run uscan
[21:44] <tormod> that's not a reason for keeping a Ubuntu delta
[21:45] <tormod> get it fixed in Debian if it is important
[21:45] <ari-tczew> tormod: I don't agree.
[21:46] <tormod> if it is broken in Debian, we should have it fixed in Debian, and sync the next version
[21:47] <tormod> and not waste time on keeping a separate Ubuntu package
[21:47] <tormod> which will cause more work in the next merge cycle
[21:49] <ari-tczew> tormod: please don't get me wrong. I'd like to sync package. Just making sure about delta drop.
[21:50] <tormod> ari-tczew, good
[22:01] <BlackZ> tormod: hello, can you review https://code.launchpad.net/~eugenesan/ppa-purge/trunk/+merge/46673 again and say if it looks good for you? thanks!
[22:04] <ari-tczew> tormod: did you test glew from experimental on natty?
[22:05] <tormod> BlackZ, hi, I am still not happy about the "empty repo" handling. I think it should bail out or complain massively, not just quietly finish
[22:05] <BlackZ> tormod: thanks for your time! :) from your last comment I didn't understand well
[22:06] <tormod> BlackZ, what is unclear?
[22:06] <BlackZ> tormod: if it was ready to be merged or not
[22:08] <tormod> BlackZ, aha. I hoped Eugene would fix it up, but he got quiet. I hope he's working on a way to find which packages come from a ppa :)
[22:08] <BlackZ> tormod: heh. The versioning for such packages is very different so I don't think there's a "simple way" to do that
[22:09] <ari-tczew> tormod: what about that change: debian/rules: Amend for pkg-config addition http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/glew/natty/revision/15#debian/rules
[22:11] <tormod> ari-tczew, I tried 1.5.7-1 on Lucid and Maverick
[22:12] <tormod> ari-tczew, did you read through the Debian changelog?
[22:14] <ari-tczew> tormod: yes I did, but I'm going to read again
[22:14] <tormod> ari-tczew, btw I don't understand why Daniel added that to the Ubuntu package instead of getting it into Debian
[22:14] <ari-tczew> tormod: I also want to get to know.
[22:15] <tormod> the same was done in Debian 6 months later. just duplicated effort
[22:15] <ari-tczew> He did it wrong. Should add patch instead patching files directly.
[22:16] <tormod> ari-tczew, yes, the Makefile change should have been in a patch
[22:16] <luca__> ciao
[22:16] <luca__> italiani
[22:16] <luca__> ci sono
[22:17] <ari-tczew> tormod: OK, I forward d/watch to debian bug 611137 and I'm giving +1 for sync.
[22:17] <tormod> ari-tczew, he probably just wanted to upload a quick'n'dirty fix without going the proper route, and know it causes us these discussions and questions :(
[22:18] <tormod> ari-tczew, great, thanks for the filing that bug
[22:18] <ari-tczew> tormod: yea, current glew on Ubuntu looks very shameful
[22:26] <tormod> BlackZ, I am happy with the merge except the "empty ppa" hunk. I don't know bazaar well enough to do a selective merge. If this was 3-4 different git patches it would have been easier for me...
[22:27] <BlackZ> tormod: I can pick up the other changes, if you want :)
[22:27] <BlackZ> tormod: except the one you mentioned
[22:28] <tormod> BlackZ, great! thanks. and let's encourage Eugene to handle the empty repo thing...
[23:10] <ari-tczew> torkel: what do you think about request fresh sync ?
[23:11] <ari-tczew> sorry, should be tormod ^^
[23:42] <ari-tczew> Riddell: regarding to last cjwatson 's words, there is no need to get an ACK from sponsors. archive admins are better knowledged to review removal requests. bug 687405
[23:43] <persia> Please, could we continue to request sponsorship for removal requests from non-members of ubuntu-dev?
[23:44] <persia> I've seen any number of such requests that were immediately unactionable for a variety of reasons, and it would be good to catch those before they reach the archive admins.
[23:44] <micahg> ari-tczew: archive admins shouldn't be tasked with doing the initial verification as they already have plenty of work to do, they are of course a sanity check on the final removal
[23:47] <persia> Note that any archive-admin is perfectly capable of performing the removal sponsorship if they happen to feel so motivated: the point is to encourage more folk to do initial review for non-developers, not to block action in any way.
[23:51] <ari-tczew> micahg, persia: please don't gotcha me as bum rap. Just yesterday IIRC cjwatson wrote that there is no need to sponsors ACK. ubuntu-archive will take a look.
[23:52] <persia> ari-tczew, My comments were intended generally, and not intended as a critique of your statement directly, but rather a critique of discouraging non-developers from requesting sponsorship of removal requests.
[23:53] <ari-tczew> aha
[23:59] <micahg> ari-tczew: I was simply saying that it should be up to the Archive Admins if they want to look at it, not be required for them to do it
[23:59] <ari-tczew> micahg: aha