[06:37] <brucee> hi all. I have a query about natty. Is this the right place
[06:39] <RAOF> That depends on the type of question.  This is a channel for the development of Natty, so if your question has to do with that, yes :)
[06:40] <brucee> well, I installed it (alpha3) on an older lenovo z61m laptop and I
[06:40] <brucee> I'm having some difficulty with the network. does that qualify :) ?
[06:41] <RAOF> MAybe; it perhaps sounds more like a bug report, though. :)
[06:42] <brucee> probably. Or just me being braindead. So you recommend launchpad?
[06:42] <RAOF> Or #ubuntu+1 for support.
[06:42] <brucee> great idea - I'll head there !
[06:47] <slangasek> ogasawara: gcc-4.5 4.5.2-6ubuntu5 uploaded; TTBOMK this is the last upload needed before beta
[07:07] <pitti> cjwatson, slangasek: I uploaded a new scour with dropping rsvg, and reverted cdbs; that should do
[07:08] <pitti> Good morning
[07:08] <slangasek> pitti: morning!  Yes, saw your mail over the weekend, thanks for taking care of this
[07:08] <pitti> sorry for the mess
[07:08] <slangasek> n/p, I'm glad you found a better solution than my "kick it out of cdbs" one :)
[07:08] <cdbs> out of me?
[07:09] <nigelb> This is precisely why you need a new nick :P
[07:09] <slangasek> cdbs: are you the personification of a package helper? :)
[07:09] <cdbs> slangasek: yes, but I prefer debhelper over myself
[07:09] <slangasek> heh
[07:09] <nigelb> lol
[07:09] <nigelb> the irony.
[07:10] <TheMuso> lol
[07:10] <cdbs> no, the advantage of this nick is that whenever someone mentions 'cdbs' I get pinged
[07:10] <nigelb> deserves a bash.org
[07:10] <cdbs> giving me the chance to kick into the conversation and recommend others to use dh
[07:11] <cdbs> okay, enough offtopic conversation, and slangasek just /ctcp versioned me :{
[07:11] <slangasek> cdbs: /hilight cdbs would do for that ;)
[07:14] <Chipzz> cdbs: that's a... weird attitude :)
[07:14] <Chipzz> cdbs: that or a very strong dislike of cdbs ;P
[07:27] <\sh> moins
[07:51] <didrocks> good morning
[08:16] <dholbach> good morning
[08:16]  * slangasek waves
[08:24] <jamespage> slangasek: good morning
[08:24] <jamespage> slangasek: re bug 737603 - I can either provide you with details on how to reproduce in Jenkins (its fairly easy)
[08:25] <jamespage> or happy to test a deb now if you want me to.
[08:25] <slangasek> jamespage: I don't have any .debs built in a useful place, but I guess you can rebuild openjdk-6 from source more quickly than I could get you one (given that it's 1:30am here)
[08:26] <jamespage> slangasek: OK - I'll do a local rebuild and try out the patch; I'll also append test case details into the bug.
[08:26] <slangasek> jamespage: sounds good :)
[08:26] <jamespage> thanks for looking at this
[08:27] <slangasek> no prob
[08:27] <jamespage> :-)
[08:30] <slangasek> pitti: so, are you happy for me to upload eglibc with this change?
[08:31] <pitti> slangasek: yes, except I'd like to understand why it's only a transitional pacakge
[08:31] <slangasek> pitti: ah, replied in the merge log, darn slow email :)
[08:32] <slangasek> pitti: "transitional" in the sense that it exists only to enforce fully upgrading libc6 before upgrading anything else; once everything's upgraded (after next LTS), we can drop it
[08:32] <pitti> slangasek: ah, thanks
[08:32] <pitti> slangasek: updated MP again
[08:33] <slangasek> w00t
[08:34] <slangasek> just noticed a (non-linux-specific) bug there, which I'll fix up before uploading
[08:45] <slangasek> pitti: yay, eglibc uploaded, thanks for the review
[08:46] <slangasek> that just leaves glib2.0 for me to break
[08:46] <slangasek> er, I mean, convert ;)
[09:10] <dholbach> can anyone review my lp:ubuntu-packaging-guide branches please?
[09:36] <seb128> hey, does anybody know if soyuz support.tar.xz tarballs?
[09:38] <mr_pouit> seb128: Bug #619152 (there's a branch but it doesn't seem merged yet)
[09:38] <mr_pouit> oops, no
[09:38] <mr_pouit> I misread, sorry
[10:04] <cjwatson> pitti: did you notice the livefs build errors which seem to be caused by language-pack-kde-es and language-pack-kde-oc having file overlaps with the non-KDE versions?
[10:05] <pitti> cjwatson: uh, no, I didn't
[10:05] <pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/kubuntu/latest/livecd-20110321-i386.out seems fine?
[10:09] <cjwatson> try kubuntu-mobile
[10:10] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/kubuntu-mobile/latest/livecd-20110321-i386.out
[10:10] <pitti> cjwatson: ah, thanks; will check that
[10:11] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/latest/livecd-20110321-i386.out
[10:11] <cjwatson> (more inclusive)
[10:11] <cjwatson> seb128,mr_pouit: I guess I should work on the infrastructure needed for that
[10:12] <seb128> cjwatson, so soyuz doesn't handle it yet?
[10:12] <seb128> cjwatson, GNOME is thinking to switch to .tar.xz tarballs
[10:12] <seb128> cjwatson, that's why I was asking
[10:13] <cjwatson> it doesn't - https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152/+merge/32868 explains the situation
[10:13] <cjwatson> oh shut up ubottu
[10:14] <cjwatson> huh, I apparently have most of the work done locally - I must have got sidetracked
[10:14] <seb128> cjwatson, thanks
[10:15] <seb128> cjwatson, does that cover all orig.tar.xz use?
[10:16] <cjwatson> oh, wait, you said orig, my branch was just for data
[10:16] <cjwatson> let me check status of that
[10:17]  * cjwatson misread in the same way as mr_pouit
[10:18] <seb128> cjwatson, sorry for not being clear ;-)
[10:19] <cjwatson> dpkg-dev/lucid supported orig.tar.xz, at least
[10:19] <cjwatson> I think it's just a matter of extending a few regexes and enumerations and the like in LP
[10:21] <seb128> cjwatson, is there any way we can make sure it's on the launchpad team list to get working for next cycle?
[10:21] <cjwatson> I can probably just submit a branch for it
[10:22] <seb128> cjwatson, no hurry, I'm just trying to make sure we don't get blocked at some point because the switch happen for GNOME and in Debian and our bits are not in place for it
[10:22] <seb128> but that's not before some months, they are still discussing it
[10:23] <cjwatson> it falls in the category of rather-do-it-now-than-in-a-hurry-later for me
[10:23] <seb128> right
[10:50] <cjwatson> seb128: note that Debian doesn't support it yet either
[10:51] <cjwatson> fwiw
[10:52] <seb128> cjwatson, seems pochu is on it,he said he talked to the debian ftp-masters and the topic is on the agenda for their next meeting
[10:53] <cjwatson> that's useful to know, thanks.  there's no bug report.
[10:56] <seb128> cjwatson, in fact pochu mentioned it on debian-project@l.d.o in reply to the reminder email sent there
[10:57] <seb128> oh, buxy mentioned it first it seems
[10:57] <seb128> well anyway it's being discussed there
[11:27] <emgent> mdz ping
[11:39] <dholbach> bdrung, pushed harvest tool to ubuntu-dev-tools again
[11:39] <dholbach> bdrung, let me know if it'S alright this time
[11:40] <dholbach> seb128, ^
[11:40] <seb128> dholbach, thanks
[11:43] <bdrung> dholbach: grep hugdaylist harvest
[11:45] <dholbach> fixed
[11:45]  * dholbach now takes the dog for a walk - see you in a bit
[11:45] <bdrung> dholbach: pylint found some unused variables
[11:46] <hallyn> jdstrand: kees: hey, debian has security updates for libcgroup and libvirt-bin.  Has someone already started on merging those?  (I don't care toduplicate work)
[11:53] <Riddell> TheMuso: how do I get orca to read me something?
[12:15] <JackyAlcine> o/
[12:36] <jdstrand> hallyn: I am preparing libvirt-bin. I don't think anyone is working on libcgroup atm, though you might ask in #ubuntu-hardened
[12:36] <jdstrand> kees: ^
[12:39] <hallyn> jdstrand: thanks
[13:14] <cnd> @pilot in
[13:23] <cjwatson> ogra_: hi, could you apply http://paste.ubuntu.com/583309/ to jasper-initramfs, please?  using ubuntu-devel as Maintainer means that upload acknowledgements go to the reviews list; ubuntu-devel-discuss is more conventional
[13:24] <ogra_> cjwatson, oops, doing so
[13:25] <cjwatson> thanks
[13:34] <pitti> cjwatson: btw, if the kernel team asks you to copy kernels around, this should help quite a bit: http://people.canonical.com/~ubuntu-archive/pending-sru.html#kernelppa
[13:34] <Riddell> pitti: is b43-fwcutter still needed on the CDs?
[13:35] <cjwatson> pitti: neat!  thanks
[13:35] <pitti> Riddell: not urgently, I think; we don't even offer b43 any more in jockey, wl is the standard driver now
[13:35] <Riddell> pitti: so broadcom is all free now?
[13:35] <pitti> cjwatson: to avoid confusion: the sru-accept.py thing does not include the automatically generated CVE bugs, as they don't get verified by QA
[13:35] <pitti> Riddell: no, wl is proprietary
[13:36] <pitti> Riddell: there is an experimental broadcom driver in staging, but still too unstable; we don't offer it in jockey yet
[13:36] <Riddell> hmm, confusing
[13:41] <hallyn> the free broadcom driver doesn't do ad-hoc though still, right?
[13:41] <hallyn> which seems to really imply we should have b43 in jockey...  it's actually half the reason why i'm back on lucid on my netbook
[13:42] <pitti> I took it out since it deterioates quickly; I got tons of kernel oopses/crashes with b43, and people kept picking the wrong one
[13:42] <hallyn> yeah having two is confusing, for sure
[13:43] <hallyn> i just need someone with spare time to implement ad-hoc in the free one :)
[13:43] <hallyn> s/implement/fix/ (as the source suggests it thinks it implements it)
[13:47] <cnd> SpamapS, I'm reviewing bug 533985
[13:48] <cnd> oh wait, I thought there was an issue
[13:48] <cnd> but I realized I was working on the wrong computer
[14:24] <mterry> What's the most useful way to report a kernel panic?  I don't see anything in /var/crash, and I don't get an apport prompt
[14:28] <cjwatson> seb128,mr_pouit: https://code.launchpad.net/~cjwatson/launchpad/tar-xz/+merge/54215, FYI
[14:29] <seb128> cjwatson, thanks
[14:30] <cjwatson> and the data.tar.xz bit is now waiting on sysadmin
[14:31] <seb128> ok
[14:31] <seb128> mterry, try asking on #ubuntu-kernel I guess
[14:31] <cjwatson> (orig.tar.xz doesn't need any sysadmin action)
[14:31] <seb128> mterry, you want kerneloops-daemon for oops issues, not sure about panic ones
[14:45] <ari-tczew> pitti: are you apport developer?
[14:45] <pitti> ari-tczew: yes
[14:45] <ari-tczew> pitti: look http://paste.ubuntu.com/583335/
[14:50] <pitti> ari-tczew: I see the problem, hang on
[14:52] <pitti> ari-tczew: fixed in trunk, thanks
[14:52] <ari-tczew> pitti: 7 minutes needed, wow! :)
[15:28] <pitti> dpm: oh, thanks for pointing to the https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam stuff, that's useful!
[15:30] <dpm> pitti, no worries :) - btw, after we have a locale for a new language in langpack-locales or upstream, are there any other technical steps to enable it and ship a langpack for it? I've meant to ask you for ages, I've just remembered now
[15:30] <pitti> dpm: yes, one: we need to add it as a supported locale to langpack-o-matic
[15:31] <pitti> dpm: ah, that could actually do with a bit of automation, hang on
[15:31] <dpm> ok :)
[15:34] <pitti> dpm: done; ./update-maps in langpack-o-matic now updates maps/supported-locales as well
[15:35] <pitti> dpm: we need to do that as we usually run this under lucid, and the local /usr/share/i18n/SUPPORTED is older than the releases we are building for
[15:35] <dpm> pitti, thanks, automation ftw!
[15:35] <pitti> dpm: so once we have a locale, we run that, and once the LP exports have files for the locale, they'll get shipped
[15:36] <pitti> dpm: lucid's gdm would need an update as well, but since maverick it doesn't any more either
[15:36] <pitti> so I'm not aware of anything else that needs to happen for this
[15:37] <dpm> pitti, ok, but what's the gdm stuff? I'm not sure I can follow that. Why does it need to be updated in Lucid and why does it not need to on Maverick?
[15:37] <pitti> dpm: in lucid, gdm had its own language/locale list
[15:38] <dpm> oh, I see
[15:45] <pitti> doko: FYI, I talked to the debian gnome folks again, and they are ok with doing the pysupport -> dh_py2 transition for pygobject and friends; we'll ship a compatibility symlink until the reverse dependencies were converted, does that sound okay to you?
[15:55] <doko> \o/ still starting in natty?
[15:55] <micahg> pitti: was the 0317 langpack supposed to fix the file overwrite issue?
[15:57] <pitti> micahg: the 0317.1 ones for kde-{oc,es}, yes
[15:57] <micahg> ok, so I'll wait for the point update
[16:03] <seb128> zul, hi, do you have a vcs for samba? Could you review and check the fix bug #668368 in if you have one?
[16:04] <seb128> it's a one char change, I don't want to an upload for that ;-)
[16:07] <doko> pitti: ^^^
[16:08] <pitti> doko: I hope so, I'm working on it right now (it's more complicated than a symlink, though)
[16:09] <zul> seb128 sure on a call right now
[16:09] <seb128> zul, no hurry, thanks
[16:09] <AnAnt> Hello, I get a UnicodeEncodeError message when I try to login on wiki.ubuntu.com, where should I report that ?
[16:11] <davmor2> AnAnt: goto #canonical-isd as a first port of call
[16:11] <debfx> kirkland: shouldn't console-setup register /etc/console-setup/vtrgb.vga as an alternative? kubuntu-default-settings could then switch to it if it's in auto mode
[16:12] <AnAnt> davmor2: thanks
[16:12] <kirkland> debfx: no, it can't;  otherwise, every time console-setup upgrades it would overwrite the alternative priority that kubuntu-settings sets
[16:12] <kirkland> debfx: ie, it could register it at a lower priority, say 20
[16:13] <kirkland> debfx: but every time it upgrades it would re-register it at 20 again
[16:14] <debfx> kirkland: yes, console-setup would register it with a lower priority and k-d-s runs updater-alternatives --set ... in postinst
[16:16] <kirkland> debfx: right, but what happens when console-setup upgrades later?
[16:17] <kirkland> debfx: at least the way i'm calling update-alternatives in console-setup.postinst, it's going to overwrite it
[16:17] <kirkland> debfx: unless i'm misunderstanding you...
[16:19] <debfx> kirkland: it's not supposed to overwrite it if it's in manual mode
[16:20] <debfx> update-alternatives --install is a no-op if the alternative is already installed (with the same priority)
[16:20] <kirkland> debfx: interesting...
[16:20] <kirkland> debfx: can you propose a debdiff to console-setup.postinst, test it, and show me how you recommend we do it?
[16:20] <kirkland> debfx: and newt's postinst too
[16:21] <kirkland> debfx: note that newt takes about 20 seconds to build, and console-setup takes about 20 minutes
[16:23] <debfx> kirkland: will do, thanks for the hint :)
[16:24] <debfx> the tricky part is in k-d-s as update-alternatives doesn't have a --only-if-in-auto-mode option
[16:27] <kirkland> debfx: sure thing
[16:27] <kirkland> debfx: i do like the idea of having the originals registered as lower-priority alternatives, such that they're more discoverable
[16:28] <kirkland> debfx: i just want to make sure it's done in a way that other optional packages (like the kubuntu themes one) can override and make their alternatives stick and maintain across upgrades
[16:29] <debfx> kirkland: aha, just revert the changes from the last newt upload :)
[16:30] <kirkland> debfx: okay, if so, then what's the proper syntax for update-alternatives in the kubuntu settings postinst?
[16:31] <debfx> kirkland: the easiest way would be: update-alternatives --set newt-palette /etc/newt/palette.original
[16:31] <kirkland> debfx: ah, okay, cool
[16:32] <jcastro> wendar: there appears to be nothing on Wednesday UDS, if you want to try "fun" lightning talks or something clever, that would be the night to do it
[16:32] <debfx> but that overwrite all user choices so guarding that with a check if the alternative is in auto mode would be good
[16:32] <wendar> jcastro: could be fun
[16:34] <debfx> kirkland: newt doesn't remove the alternatives in postrm
[16:34] <kirkland> debfx: good catch
[16:59] <slangasek> kirkland: hi, do you feel like NEWing eglibc today? :)
[16:59] <kirkland> slangasek: i can have a look ....
[17:02] <debfx> kirkland: we could use something like this in kubuntu-default-settings: http://paste.ubuntu.com/583394/
[17:09] <kirkland> slangasek: https://launchpad.net/ubuntu/natty/+queue keeps timing out on me
[17:09] <slangasek> curses
[17:10] <kirkland> slangasek: okay, it landed
[17:10] <kirkland> slangasek: oh, a binary deNEW, that's easier :-)
[17:10] <kirkland> slangasek: looking now ...
[17:10] <slangasek> yep, trivial, just a new package added to the base system ;)
[17:11] <kirkland> slangasek: multiarch support :-)  trivial :-)
[17:12] <kirkland> slangasek: hmm, http://pastebin.ubuntu.com/583405/
[17:12] <kirkland> slangasek: there isn't actually anything in that package?
[17:12] <slangasek> correct
[17:12] <slangasek> kirkland: let me grab you a link to the explanation
[17:13] <slangasek> kirkland: https://code.launchpad.net/~vorlon/ubuntu/natty/eglibc/multiarch-support/+merge/54135
[17:13] <kirkland> slangasek: cool, works for me
[17:14] <kirkland> slangasek: needs to go to main, i presume?
[17:14] <slangasek> kirkland: yeppers
[17:14] <slangasek> as Priority: standard, in fact
[17:14] <slangasek> er, Priority: required even
[17:14] <slangasek> (but I can poke that once it's in the archive, if there are any issues)
[17:15] <kirkland> slangasek: OK: eglibc, eglibc_2.13-0ubuntu8_armel_translations.tar.gz(main/(unchanged)/(unchanged))
[17:15] <kirkland> slangasek: so i missed your priority note
[17:15] <slangasek> no problem
[17:15] <kirkland> slangasek: so yeah, poke that once it's in
[17:21] <slangasek> Laney: how are things with ghc6?  Everything good, now that libffi is fixed?
[17:21] <Laney> slangasek: Mostly. I see a perplexing failure that I think is due to a newer binutils; mailed d-haskell@ to ask for insight earlier.
[17:21] <Laney> At least the libffi fix is good.
[17:22] <Laney> http://launchpadlibrarian.net/66834248/buildlog_ubuntu-natty-amd64.haskell-happstack-util_0.5.0.2-2build2_FAILEDTOBUILD.txt.gz
[17:22]  * slangasek checks the mail to make sure it's really a binutils bug and not a multiarch bug ;)
[17:22] <Laney> it's in a library, not ghc6 itself (thankfully)
[17:25] <kirkland> slangasek: okay, it's taking a few button pushes to get past all the launchpad timeouts for the other arches
[17:26] <kirkland> slangasek: okay, done
[17:26] <slangasek> kirkland: your pain is appreciated, as this puts us one package upload away from 'sudo apt-get install flashplugin-installer:i386' working in a chroot :)
[17:26] <kirkland> slangasek: heh :-)
[17:27] <slangasek> now to upload glib2.0
[17:34] <cjwatson> slangasek: 'sudo apt-get install libc6:amd64' doesn't seem to work for me, with a 'deb [arch=i386,amd64] ...' line in sources.list; what am I missing?
[17:34] <cjwatson> it just says "E: Unable to locate package libc6:amd64"
[17:35] <slangasek> cjwatson: APT::Architectures { "i386"; "amd64"; }; also, dpkg --foreign-architecture amd64 (can set in /etc/dpkg of course); finally, I think but have not yet confirmed that there's a change in the apt cache format before and after multiarch, requiring rm /var/cache/apt/*cache* && apt-get update to get everything where it's supposed to be
[17:36] <cjwatson> aha
[17:36] <cjwatson> (is there user documentation for multiarch yet?)
[17:36] <slangasek> cjwatson: the UI is still a little rough, probably will remain so for natty as I don't see us turning this on by default - I'll work on user documentation next week
[17:37] <slangasek> given that today is the first day that it's possible to run that apt-get command against the archive and have it succeed (and only once the NEWed eglibc is published), I didn't want to encourage foot-shooting too early :)
[17:37] <cjwatson> heh, yeah
[17:45] <hyperair> ari-tczew: weird, your coredump seems truncated. or so gdb says =\
[17:50] <cjwatson> slangasek: without flushing the apt cache, 'sudo apt-get install libc6:amd64' now seems to list a reasonably plausible set of things to do
[17:50] <cjwatson> (this is before your latest eglibc change ...)
[17:51] <slangasek> cjwatson: right, the cache bit pertains to how Multi-Arch: foreign, Architecture: all packages are handled (which are only an issue once you get a little farther up the stack)
[17:51] <slangasek> cjwatson: and apt will happily start downloading the packages and only fail when it tries to configure the dependency loop :)
[17:54] <cjwatson> ok ...
[17:54] <ari-tczew> hyperair: so what's the conclusion?
[17:55] <hyperair> ari-tczew: the conclusion is that the coredump is completely useless ^_^
[17:55] <hyperair> sorry to say
[18:01] <mterry> slangasek, do you know what the deal with bug 739575 is?
[18:01] <mterry> (seb128 promised you would  ;))
[18:02] <seb128> ;-)
[18:02] <seb128> that's going to be a fun transition if we need to start rebuild .la in order
[18:03] <slangasek> mterry: .la files should not reference other .la files in their dependency_libs field (Debian Policy 10.2); see clean-la.mk in gnome-pkg-tools for an example fix
[18:03] <slangasek> seb128: well, I assumed most packages were already DTRT on this point, since it's in policy... I see I was too optimistic :)
[18:03] <slangasek> mterry: a quick-n-dirty fix is to just reupload the package that has the broken reference, but that's a bandaid
[18:04] <Riddell> ev: I got usb-creator built on suse https://build.opensuse.org/project/show?project=home%3Ariddell%3Ausb-creator
[18:04] <ev> Riddell: that's awesome!
[18:05] <seb128> slangasek,
[18:05] <seb128> $ grep [.]la *.la | grep dependency_libs | sed 's#:.*##' | sort | uniq | wc -l
[18:05] <seb128> 29
[18:05] <seb128> in /usr/lib on my natty system
[18:05] <lamont> (etherape:25852): GLib-CRITICAL **: g_ascii_strcasecmp: assertion `s2 != NULL' failed
[18:05] <lamont> Segmentation fault
[18:05] <lamont> I'm pretty sure it's not supposed to do that
[18:05] <mterry> slangasek, well that's the interesting thing, when I rebuilt the package, it stopped referencing the other .la file in its own .la.   It started using -l syntax
[18:06] <mterry> Not sure how the original path got in there
[18:06] <slangasek> mterry: <cough> that's because libtool doesn't know to look in the multiarch directories at all for its .la files
[18:06] <ari-tczew> hyperair: so how can I do with that bug?
[18:06] <mterry> ah...  so that's a fix by way of a different bug?  :)
[18:06]  * hyperair shrugs
[18:06] <lamont> slangasek: I thought that was because libtool is just plain not  your friend
[18:07] <lamont> kinda like .la files, iirc
[18:07] <mterry> slangasek, could you rebuild apr-utils for me?  I'm not core-dev atm
[18:07]  * doko doesn't ask when to start the rebuild test ...
[18:07] <slangasek> mterry: the .la is the expected behavior with libtool, when the dependent library has a .la of its own; but we really want it to be *empty*, not just switched to use -l
[18:07] <slangasek> lamont: libtool *isn't* my friend, and I really wish it would stop sending me these messages on LinkedIn
[18:08] <slangasek> mterry: sure thing
[18:08] <mterry> :)
[18:08] <lamont> slangasek: heh
[18:08] <slangasek> seb128: 29 doesn't seem so bad... :)
[18:09] <seb128> slangasek, I'm happy that you are not scared about those ;-)
[18:10] <slangasek> seb128: care to paste me the list of actual lib names?  That way I can bump them proactively :)
[18:10] <slangasek> seb128: and no, 29 libs uploaded for a trivial .la change, compared to what I've /been/ doing, is not scary at all ;)
[18:12] <seb128> slangasek, http://paste.ubuntu.com/583439/
[18:12] <slangasek> seb128: sweet, thanks
[18:13] <seb128> slangasek, http://paste.ubuntu.com/583442/
[18:13] <seb128> slangasek, that's the corresponding sources
[18:13] <seb128> if you prefer that list
[18:13] <seb128> ups, binaries rather
[18:13] <seb128> I can do the sources version if you want ;-)
[18:18] <slangasek> seb128: binaries are fine, no problem
[18:42] <Keybuk> SpamapS: you realise that there is no benefit to constructive discussion with Lennart, right? ;-)
[18:42] <Keybuk> his entire reason for even being on the upstart list and IRC channel is simply to be disruptive
[18:44] <ogra> Keybuk, not to pick up clever ideas ?
[18:46] <Keybuk> ogra: well, given he generally describes Upstart as "wrong", I doubt that
[18:49] <SpamapS> Keybuk: I guess I'm like the guy who makes funny faces at the gorillas just to see if they'll fling excrement, event hough everybody has told me thats whats going to happen. ;)
[18:50] <Keybuk> lol
[18:51] <Keybuk> actually it's always fun to have more people make funny faces at him
[18:51] <Keybuk> because then he'll reply that he's tried, and I'm not interested in working together
[18:51] <Keybuk> and I'll point out that I've repeatedly said that I am, but that I don't consider "working together" to be "do what Lennart says"
[18:51] <Keybuk> and then I attempt to get him to agree to something
[18:51] <Keybuk> and he goes silent
[18:51] <Keybuk> and then turns up with "NAK, I'm doing this differently in systemd" or something
[18:54] <walters> Keybuk: 1) your movie twitter post was hilarious  2) i think he's doing the right thing; give him a little bit to come up with another approach
[18:54] <Keybuk> cf. https://bugs.freedesktop.org/show_bug.cgi?id=34526#c1
[18:54] <SpamapS> Keybuk: I suppose all we can do to counter that is to be open and ask for comments on major changes... since... you know.. there are somewhere around a million more upstart users than systemd.. we should probably ask upstart users before Lennart. ;)
[18:55] <Keybuk> SpamapS: at Google alone, there is probably 1,000 *times more* upstart installs than there are Fedora installs in the entire world ;-)
[18:55] <Keybuk> walters: I'm not interesting in Lennart coming up with another approach - I'm interested in Lennart actually discussing with me, and others, what the other approach should be
[18:55] <walters> sure, so give him a bit of time to post that
[18:56] <Keybuk> walters: I've given him a year so far; how much more time should I give?
[18:56] <Keybuk> (the LISTEN_FDS discussion started April last year)
[18:57] <Keybuk> sadly this approach of "the only valid decision is the one made by the Fedora+SuSE cabal" is starting to infect other projects
[18:57] <Keybuk> see the recent udev announcement that all systems must support /dev/.run as a tmpfs throughout boot that's later bind-mounted to /var/run
[18:57] <Keybuk> and then the creation of /run after that
[18:58] <Keybuk> without, at any point, asking any other distribution - many of which have *already solved this* - what they think the approach should be
[18:58] <Keybuk> or going via the FHS or some other neutral body
[18:58] <highvoltage> /run!?
[18:59] <walters> Keybuk: i'm not involved in that really so i can't comment on it usefully
[18:59] <Keybuk> lunch, bbl
[19:36] <Keybuk> omnomnom
[20:23] <\sh> hmmm..could it be that we are right now in the "Everything what Ubuntu does and did is wrong, nasty, evil and totally useless?" unity vs. gnome-shell, upstart vs. systemd , multi-arch ubuntu vs. multi-arch debian? (WRT http://jackyf.livejournal.com/115703.html)
[20:24] <broder> \sh: our multiarch spec is the same as debian's
[20:25] <broder> which is to say, we're using a spec developed at debconf, and for all intents and purposes is a "debian spec", not an "ubuntu spec", but just implementing it sooner
[20:25] <highvoltage> \sh: nah, Ubuntu does quite a few things really good
[20:25] <\sh> broder: I thought so, but it sounds different from the post I just read on p.d.o.
[20:26] <cjwatson> jackyf is several years too late to the party
[20:26] <broder> \sh: that post is complaining about not understanding the spec that's being implemented
[20:26] <broder> and suggesting an alternative that they're asserting makes more sense
[20:28] <ScottK> cjwatson: If their blogging on livejournal, that's a given.
[20:29] <\sh> broder: I'm just concerned about "bad PR" with regards of the latest happenings
[20:29] <ScottK> \sh: Bad PR can happen whether you deserve it or not.  I think we should just minimize the deserving it and not worry about the rest.
[20:30] <ScottK> \sh: It would be interesting to hear about the distros that started transitioning to System D in 2006 when we started our Upstart transition.
[20:31] <ScottK> Some people don't understand the notion that time move in one direction for most mortals.
[20:32] <nigelb> kirkland: hey, add a warning to your blog.  The presentation linked on the scale website is wrong :P
[20:33] <kirkland> nigelb: thanks
[20:33] <\sh> ScottK: actually I don'
[20:33] <kirkland> nigelb: i wonder what's up with that
[20:34] <ScottK> \sh: You don'?
[20:34] <nigelb> kirkland: I poked Gareth, I figure he'll get it fixed :)
[20:34] <\sh> 't care about what system we will or others will use...I just want to use the best technique and this technique needs to be supported for a long time
[20:34] <\sh> moment...phone call
[20:34] <kirkland> nigelb: cool, thanks
[20:34] <kirkland> nigelb: any chance you can ask them where my video is?  :-)
[20:36] <nigelb> kirkland: yup, will do.  I wanna see it too :)
[20:39] <\sh> back...
[20:41] <ScottK> \sh: Also keep in mind the author of that blog post decided apt was hopeless and is re-implementing it, so some level if disagreement from that source is not particularly suprising.
[20:44] <slangasek> yes, reimplementing it in perl
[20:44] <nigelb> ScottK: heh, lol about livejournal comment :)
[21:06] <cnd> I'm trying to help someone get their game into Ubuntu, but there are possible issues with media licensing (fonts and audio)
[21:06] <cnd> the audio files clearly aren't gpl compatible, but I don't know if they really need to be
[21:07] <cnd> is there some place where these issues can be reviewed?
[21:16] <ScottK> cnd: We don't require GPL compatiblity.  To get into Universe it needs to be ~DFSG free (was also allow GFDL with invariant sections that Debian doesn't).  To get into Multiverse it just has to be legal to distribute.
[21:16] <ScottK> cnd: Any archive admin can answer questions, so just ask.
[21:17] <slangasek> jamespage: any luck with jenkins?
[21:17] <slangasek> or with openjdk, I should say
[21:19] <cnd> ScottK, I should have mentioned that the source code is GPL, but here's a merge request with the important information: https://code.launchpad.net/~libavg-team/geneatd/packaging.cleanup/+merge/53538
[21:19] <cnd> there's audio files that are CC-sampling 1.0
[21:19] <cnd> and the game source code is GPLv3+
[21:20] <ScottK> I'd have to look up that CC license, but IIRC it's problematic to combine those into one work.
[21:21] <slangasek> however, it's questionable whether a game engine + accompanying audio files are considered "one work"; it depends a lot on the specific license wording
[21:30] <ScottK> I guess.
[21:50] <cnd> ScottK, so where do I go from here to get a more definitive answer?
[22:16] <GatoLoko> hi
[23:41] <ScottK> cnd: Get the package uploaded to REVU and then one of us archive admins might review it if we have time.  We don't have even a rough equivalent of debian-legal.