[02:56] <slangasek> @pilot in
[03:02] <psusi> slangasek, say, why does loading vesafb preclude switching to the proper drm/dri driver later?
[03:02] <slangasek> psusi: because there's no race-free way to switch between them in the kernel
[03:03] <psusi> slangasek, howso?  iirc there was support for unloading a console driver, then loading a new one...
[03:03] <slangasek> that's about as precise an answer as I can give you, I haven't looked deeply at the problem
[03:05] <psusi> hrm... guess I'll take a look at it... it seems like you should be able to load the plain old fashioned vga16 driver then switch later.. last time I was poking around the generic console code it looked like it was designed to handle switching drivers like that
[03:27] <larsduesing> good morning slangasek :)
[03:45] <slangasek> larsduesing: good evening. :)
[03:46] <slangasek> psusi: so yes, the console code is designed to support switching, but a) IME this hasn't actually worked for a while, b) the framebuffer code is another matter entirely, and fbcon has its hooks into the framebuffer device
[03:47] <larsduesing> slangasek: could you have a look at https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 please?
[03:48] <slangasek> sure, let's see
[03:48] <larsduesing> cool, thanks :)
[03:48] <psusi> slangasek, iirc, you would have to shut down fbcon, then vga16/vesafb, which it depends on, leaving you with the default null console, then load the new proper dri driver and then reload fbcon bound to that
[03:49] <slangasek> psusi: if you manage to do this I would be interested to see it; I'm still not sure it would be sane to do it in Ubuntu by default, but I have a myth box I'd like to be able to use it on
[03:50] <slangasek> psusi: don't forget that X and plymouth will both also try to use the framebuffer
[03:50] <psusi> slangasek, yea... not something you can do after they load...
[03:51] <psusi> would need to make the switch first
[03:51] <slangasek> well, so then you're waiting until you've made a determination (via udev) that there's no better driver before you do anything useful with the console, so what's the point :)
[03:52] <slangasek> not the console technically, but the fb
[03:52] <psusi> well, you wouldn't load vesafb unless you need to drop to the initramfs prompt, then you can unload it if/when you continue
[03:52] <slangasek> ah
[03:52] <psusi> yea, this is just for the initramfs emergency shell, no need to bother unless the shit hits the fan
[03:52] <psusi> err... fecal matter hits the rotary air impeller
[03:53] <infinity> I'm highly insulted.
[03:53] <psusi> ;)
[03:53] <Jagst3r15> in 12.10 what will the gnome option be called
[03:54] <Jagst3r15> like on the login screen will it say GNOME 3.5.X?
[03:55] <slangasek> larsduesing: so you note in this bug that the impact is "medium to low", which would normally exclude it from an SRU according to https://wiki.ubuntu.com/StableReleaseUpdates.  Do you want to revise your impact statement, or should the SRU be withdrawn?
[03:58] <larsduesing> oh
[03:58] <larsduesing> second...
[03:59] <larsduesing> so this won't be a SRU? James Page told me to do a SRU...
[04:00] <psusi> slangasek, ohh, did you think I was getting at being able to have plymouth display the splash screen during the initramfs without including the proper dri driver?  I was just thinking about the emergency shell not showing up
[04:04] <larsduesing> "crashing on startup" if someone deletes something in the config... First part is high impact - but second one... ahem... tough luck *g*
[04:05] <larsduesing> so, no SRU in your opinion?
[04:13] <slangasek> larsduesing: well, my personal opinion is that it probably shouldn't be an SRU; but if you think it's high enough impact that it should be, I'll sponsor it, I just want you to stand behind it :)
[04:14] <slangasek> and if jamespage said it should be SRUed, that's certainly a point in favor
[04:15] <larsduesing> Ok, lets wait a little bit...
[04:15] <slangasek> what are we waiting for?
[04:17] <larsduesing> I'm reading wiki about SRU
[04:17] <slangasek> ok
[04:17] <larsduesing> again
[04:17] <larsduesing> and think about it all..
[04:18] <slangasek> ok then :)
[04:18] <Jagst3r15> hmm, you guys know where i'd inquire about including the latest build of chromium into 12.10?
[04:18] <Jagst3r15> the package for 12.10 is only 18.xxxxx
[04:19] <larsduesing> pro: it doesn't accept legal config-files. con: rarely anyone should run into it...
[04:20] <larsduesing> PRO: Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
[04:21] <larsduesing> slangasek: it files under that. aiccu is not critical infrastucture :) (ok, for us it may be... but for the normal user...)
[04:22] <RAOF> larsduesing: Is acciu in Universe? We're less conservative there.
[04:22] <slangasek> I'm not ;)
[04:23] <RAOF> By policy, we're less conservative there :P
[04:23] <larsduesing> ir is
[04:24] <RAOF> Or perhaps I'm
[04:24] <larsduesing> ik
[04:24] <RAOF> ...misremembering policy?
[04:24] <larsduesing> argh
[04:24] <larsduesing> cat
[04:24] <larsduesing> it is
[04:25] <larsduesing> and patch is obviously safe: rather to stop starting it does set a default
[04:28] <slangasek> larsduesing: have you reached a verdict? :)
[04:29] <larsduesing> yes
[04:30] <larsduesing> it matches clearly the above part
[04:30] <larsduesing> in my opinion
[04:31] <micahg> Jagst3r15: not available ATM AFAIK
[04:41] <slangasek> larsduesing: ok, will sponsor it - thanks for thinking it through
[05:14] <larsduesing> "This line-cut was proudly sponsored by Deutsche Telekom AG" *grr*
[05:14] <larsduesing> thanks slangasek
[05:15] <larsduesing> should I add the category it will fit in my SRU-Comment?
[05:58] <vibhav> j #ubuntu
[06:02] <vibhav> Is there any page for listing packages which have to be transitioned to dh_python2 ?
[06:04] <slangasek> larsduesing: don't worry about it
[06:06] <slangasek> vibhav: any package that still depends on python-support or python-central should be transitioned; however, aside from packages in main, we generally don't diverge from Debian on this because it increases the maintenance burden and not all Debian package maintainers have agreed to migrate to dh_python2
[06:06] <slangasek> vibhav: and for main, the transition is already done
[06:07] <StevenK> slangasek: The maintainers haven't agreed because they like pain?
[06:52] <dholbach> good morning
[07:23] <pitti> Good morning
[07:26] <Sweetshark> moin!
[07:27] <Sweetshark> slangasek: i dont think I can pass around a binary easily, the test cases have to run from a build (and are not packaged)
[07:28] <Sweetshark> slangasek: I guess it is easiest still you get https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+sourcepub/2537780/+listing-archive-extra and build it (overnight for example)
[07:28] <slangasek> Sweetshark: extract the test case from your build tree and post it somewhere? :)
[07:28] <slangasek> yeah :/
[07:29] <slangasek> @pilot out
[07:29] <Sweetshark> slangasek: no easy extracting this: it is a junit test remotecontrolling LibreOffice via UNO-API ....
[07:29] <dupondje> slangasek: you take a look at the cryptsetup sync when you are bored ? ;)
[07:30]  * dholbach hugs slangasek
[07:30] <slangasek> dupondje: hmm, did you see my response on IRC to your last question?
[07:30]  * slangasek hugs dholbach and slinks off toward bed :)
[07:30] <Sweetshark> slangasek: and the test is started from inside the buildsystem (expecting the build, not only an install  to be there)
[07:31] <slangasek> dupondje: we shouldn't sync it unless you're going to add full conffile upgrade handling to the package in Debian... and I don't see why you've changed the names of the upstart jobs in Debian anyway, wouldn't it be better to just make the Debian package use the names that are already in use in Ubuntu?
[07:31] <Sweetshark> slangasek: :) good night then
[07:32] <slangasek> Sweetshark: so I posted a reply on the list with some suggestions on how to go about debugging this... maybe that'll help you
[07:33] <dupondje> slangasek: must have missed it :)
[07:33] <Sweetshark> slangasek: cant see it yet on the list archive.
[07:34] <dupondje> and dh_installinit can only handle <packagename>.upstart/.init
[07:35] <dupondje> so if we want to install .upstart OR .init, we need to it give it the same name OR handle it in debian/rules, which isn't that clean
[07:35] <dupondje> anyway :) enjoy your night
[08:14] <xnox> @pilot in
[09:12] <xnox> dholbach: I am not a member of the ~ubuntu-sponsors. Would you please, please, add me? or maybe add ~ubuntu-core-dev to that one?
[09:13] <dholbach> added you :)
[09:13] <xnox> dholbach: \0/ yeah
[09:13] <xnox> thanks ;-)
[09:14] <larsduesing> ah, dholbach: short question, is it somehow possible to add the irc-nicks of the pilots to the calendar?
[09:15] <dholbach> larsduesing, generally that'd be possible, but I'd need to change my pilot schedule script a bit for that
[09:16] <dholbach> I'd need to write down in the code which mail address is tied to which irc nick
[09:16] <larsduesing> dholbach: it's just a suggestion, as I stumbled over the names from time to time
[09:17] <dholbach> I'll note it down in my TODO
[09:17] <larsduesing> thanks :-)
[10:19] <dholbach> didrocks, do you think you can join #ubuntu-arb again? :
[10:19] <dholbach> :)
[10:20] <didrocks> oooopsss
[10:20] <didrocks> sorry, got stuck on the unity release
[10:20] <didrocks> coming
[10:40] <xnox> pitti: is it possible to set ProblemType when running $ apport-cli --save -p binarypackagename
[10:40] <xnox> pitti: in particular due "if report['ProblemType'] == 'Package':" part of the source package hook is not run
[10:41] <pitti> xnox: you can't change ProblemType in the CLI, but you can hack the .crash file, of coursr
[10:42] <pitti> xnox: what prevents running the source package hook?
[10:46] <xnox> pitti: I wrote the hook locally, I built the package, I installed the package, I want to run $ apport-cli --save -p mybinarypackage as it would by apport and I noticed that by default apport-cli didn't set ProblemType
[10:46] <xnox> pitti: not really me, I am sponsoring an update / change to the source hook
[10:46] <xnox> pitti: not really me, I am sponsoring an update / change to a source hook
[10:46] <pitti> xnox: it sets it to "Bug"
[10:46] <pitti> or, it ought to
[10:47] <xnox> pitti: ok, when is 'Package' ProblemType set?
[10:47] <pitti> xnox: that's done by apt (or dpkg, not sure), when a package fails to install or upgrade
[10:47] <pitti> xnox: as I said you can vi the saved .apport file to change it
[10:48] <xnox> ok...
[11:03] <hrw> can someone hint me why my quantal reports as Debian for 'lsb_release -a'?
[11:03] <pitti> it doesn't here, and is not supposed to
[11:03] <pitti> hrw: dpg -s base-files ?
[11:03] <pitti> dpkg even
[11:04] <hrw> pitti: just resintalled base-files to 6.5ubuntu7
[11:05] <pitti> conffiles are magic, though; if your /etc/lsb-release is modified locally, reinstalling won't restore it
[11:05] <infinity> Or if it's been deleted.
[11:05] <infinity> If it's done, lsb_release does, indeed, default to Debian.
[11:05] <infinity> s/done/gone/
[11:06] <infinity> hrw: dpkg -i --force-confmiss base-files.deb
[11:06] <hrw> thanks
[11:06] <hrw> restored it by hand
[11:07] <infinity> We might want to mangle our copy of lsb-release to at least lie more creatively when the conffile is gone.
[11:07] <hrw> ok, back to rebuilding cross toolchain
[11:47] <saurabh> Hello, I have created a project and setup a ppa on launchpad. I am using quickly to create my application. But when I try to push the code to launchpad, it created 12.07 version instead of 0.1 version
[11:47] <saurabh> can somebody help me to resolve this issue?
[11:48] <pitti> sounds like "July 2012"
[11:48] <pitti> didrocks: ^ do you know if that's intended?
[11:49] <didrocks> yeah, it's the way Quickly is versionning apps
[11:49] <didrocks> saurabh: ^
[11:49] <saurabh> ok
[11:50] <saurabh> how can change it to 0.1?
[11:52] <didrocks> saurabh: when you quickly release, you can quickly release <version>
[11:53] <saurabh> ok didrocks. thanks
[11:53] <didrocks> yw :)
[11:53] <saurabh> one more thing
[11:53] <didrocks> saurabh: this discussion should rather be on #quickly btw :)
[11:53] <saurabh> I have already tried there
[11:53] <saurabh> in quickly, launchpad and also in ubuntu
[11:53] <saurabh> but din't get the answer there
[11:55] <saurabh> didrocks, I'm getting a warning while packaging my app
[11:55] <saurabh> Hello, I have created a project and setup a ppa on launchpad. I am using quickly to create my application. But when I try to push the code to launchpad, it created 12.07 version instead of 0.1 version
[11:55] <didrocks> saurabh: well, it was 2 minutes before you asked here, you can't expect people answering immediately on all channels
[11:55] <saurabh> sorry, worngly pasted
[11:55] <saurabh> ** (setup.py:5585): WARNING **: Error sending credentials: Error sending message: Operation not permitted
[11:55] <didrocks> saurabh: let's continue on #quickly, this channel is not for application development
[11:55] <saurabh> ok didrocks
[12:43] <xnox> @pilot out
[12:44]  * xnox should have done that before going to lunch, not after
[13:03] <edlerk> I have just produced my first ubuntu package (.deb file) and am a little confused on how to submit it for possible inclusion in ubuntu. Is there a document which will walk me through this process?
[13:06] <edlerk> I used "https://wiki.ubuntu.com/PackagingGuide/Complete#Introduction" to learn to make the package.
[13:07] <xnox> edlerk: if it is a bugfix or an update to an existing package you can either submit a merge proposal against lp:ubuntu/$package or you can file a bug on launchpad against the package and attach a debdiff
[13:07] <cjwatson> https://wiki.ubuntu.com/SponsorshipProcess
[13:07] <xnox> edlerk: if it's a new package, you will need to upload .dsc & the tarballs to any http/ftp location or simply attach to a bug
[13:07] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[13:08] <xnox> cjwatson: do we have ubottu command to print all of the above? =)
[13:08] <edlerk> xnox: it is just a simple program packaged from scratch. Okay. I will read the docs.
[13:08] <xnox> cjwatson: or is it a short irc marco that you run? =)
[13:08] <cjwatson> er I typed the first into my browser to check it and then copied and pasted
[13:08] <cjwatson> the second is linked from the first
[13:10] <xnox> !packaging
[13:10] <jbicha> edlerk: what software did you package?
[13:11] <edlerk> jbicha: I packaged something called "ft232r_prog" (http://rtr.ca/ft232r/).
[13:12] <edlerk> jbicha: It is for setting the eeprom contents of USB devices. Very useful if you are manufacturing your own hardware...
[13:17] <jamespage> sbeattie, whats happening with the update of openjdk-6 in Lucid?
[13:18] <edlerk> jbicha: Should I send Aurelien Jarno an email?
[13:22] <edlerk> jbicha: I just sent him an email. Thanks.
[13:22] <ev> mpt: so to be clear, you're happy for the apport window to disappear if the application becomes responsive again?
[13:23] <edlerk> jbicha: I also sent him a copy of the package and its friends.
[13:25] <edlerk> jbicha: Okay bye. I need to do more soldering...
[14:02] <seb128> infinity, hey, do you plan to do your SRU review day you missed yesterday today? ;-à
[14:02] <seb128> ;-)
[14:08] <stgraber> micahg: I know you'll notice, so sorry for the resolvconf merge without -v... my ctrl+c skills weren't good enough to kill the upload when I noticed I didn't pass it
[14:09] <stgraber> should someone be actually interested, the full changelog is: http://paste.ubuntu.com/1073112/
[14:15] <mvo> ev: is there something like http://errors.ubuntu.com/by-package/software-center ? instead of having to type it manually in the input field?
[14:18] <ev> mvo: not yet. I've just created https://bugs.launchpad.net/errors/+bug/1020580 for it
[14:20] <mvo> ev: awsome, thanks
[14:20] <mvo> ev: its really minor, just a nice to have to include e.g. in a team report mail
[14:21] <ev> mvo: shouldn't be too hard, and I'd love to have it as well :)
[14:22] <mvo> :)
[15:02] <highvoltage> stgraber: should I file a UI freeze exception for ldm-themes so long or should I assume that the design team is going to get the artwork in on time this time?
[15:04] <highvoltage> stgraber: speaking of which, I screwed up and made the debian version a lot higher, so now we have the debian themes in Ubuntu... I'll at least get that fixed so long
[15:05] <ScottK> highvoltage: Don't file for a UI freeze exception now.  Wait until something doesn't make the deadline.
[15:05] <ScottK> If someone already knows they won't make it, they're doing it wrong.
[15:05] <highvoltage> ScottK: ok, that sounds completely rational.
[15:05]  * Laney wonders why he got an email to openstack-packaging
[15:11] <robbiew> cjwatson: just updated quantal...interesting grub2 background
[15:11] <robbiew> :)
[15:12] <cjwatson> hm?  I didn't knowingly change anything
[15:12] <cjwatson> Perhaps you have desktop-base installed
[15:14] <cjwatson> mterry: Did you see bug 1020462 and bug 1020526
[15:14] <cjwatson> ?
[15:14] <highvoltage> ah yes that would give him the debian "joy" theme :)
[15:14] <cjwatson> mterry: I was thinking of http://paste.ubuntu.com/1073223/ for the second one, but I haven't been able to reproduce the bug as reported yet
[15:15] <highvoltage> like you'd get on ltsp with the current 'ldm' themes. that could really confuse someone :)
[15:15] <cjwatson> Well, I could reproduce the missing do-partial-upgrade part of it, but not the crash
[15:15] <seb128> bdmurray: hey, since you are off thursday, is there any chance you would do a SRU review round today?
[15:15]  * seb128 has the feeling it will be hard to get SRU reviews this week ;-)
[15:16] <mterry> cjwatson, I saw you assign the upgrader one, thanks.  The metarelease.py one I hadn't seen
[15:24] <bdmurray> seb128: is there something specific you would like me to look at?
[15:26] <seb128> bdmurray: hey, from an errors.ubuntu.com "target top issues" perspective ubuntu-sso-client and software-center, otherwise the recent unity-lens-video is a trivial 1 liner over the SRU from yesterday to fix a case which was not covered in the previous fix
[15:27] <seb128> bdmurray: ubuntuone-client seems like a good one as well then if you still have time for SRU
[15:27] <seb128> bdmurray: thanks ;-)
[15:28] <seb128> gwibber could be good as well ... and I will stop there :-)
[15:53] <robbiew> cjwatson: hmm, so I didn't purposely install desktop-base...but I can check...this machine went through a pretty crazy upgrade path lastweek (natty->oneiric->precise->quantal), so who knows :)
[15:53] <cjwatson> It does occasionally get accidentally installed, despite being in universe
[15:54] <robbiew> ah, cool
[15:55] <robbiew> cjwatson: yep...that was it, thnx!
[15:56] <cjwatson> np
[15:58] <dupondje> heh, somebody forgot to remove [ Merge-O-Matic ] from his changelog
[16:12] <nigelb> ev: "It's really fantastic. Very impressed." -- from a friend re: 12.04 installer :)
[16:12] <ev> nigelb: thanks. Credit goes to everyone in #ubuntu-installer though. I barely touched it in 12.04
[16:13] <ev> nigelb: my focus was then and continues to be http://errors.ubuntu.com :)
[16:13] <nigelb> ah! Nice :)
[16:32] <mterry> cjwatson, I can reproduce that update-manager crash by running "nosetests3" in update-manager trunk.  This is a new exception for some reason.  But your patch does fix it
[16:46] <bdmurray> mvo: I'm looking at software-center in precise-proposed and a couple of bugs don't seem to be fixed in quantal
[16:47] <bdmurray> bug 970627 and bug 971776
[16:50] <mhall119> highvoltage: you ready for the hangout workshop in about 10 minutes?
[16:52] <highvoltage> mhall119: will be in around a min
[17:01] <vibhav> What is the concept of having a seperate debian/control.in?
[17:02] <mterry> vibhav, some fields in it are generated (like @GNOME_TEAM@) and put in the real debian/control
[17:03] <vibhav> ah
[17:12] <jcastro> xnox: hey are you still going to try some archive rebuild madness on hp cloud? (please say yes!)
[17:12] <xnox> jcastro: i'm listening
[17:12]  * xnox is setting things up to launch one
[17:12] <jcastro> yeah just take good notes, I am interested in how well it'll perform, etc.
[17:13] <xnox> jcastro: ok.
[17:13] <jcastro> if you could like time it or something measurable
[17:13] <jcastro> I am interested if it's possible to see how much faster it'll be on these new servers than our typical resources
[17:14] <xnox> jcastro: given the size of their instances I wonder if it can be done in less than one hour excluding libreoffice
[17:14] <jcastro> heh, yeah.
[17:15] <xnox> jcastro: the golden rule of archive rebuilds - always exclude libreoffice ;-)
[17:15] <smoser> anyone else believe that firefox generally leaks memory? i've disabled just about all my plugins (other than pentadactyl that i can't live without) and it seems to grow in footprint over time.
[17:15] <jcastro> xnox: is it possible to parallelize it? like split it into 3 parts on 3 different instances?
[17:15] <micahg> smoser: each release it gets better
[17:15] <xnox> jcastro: split what? the libreoffice build?
[17:16] <smoser> micahg, personally, this one seems worse (precise)
[17:16] <jcastro> xnox: the entire rebuild I mean
[17:16] <micahg> xnox: you can't rebuild everything in one hour, on the grid 5000, a total rebuild took 8 hrs
[17:16] <smoser> micahg, but you're suggesting it is at least accepted that it leaks. which saves me from proving it.
[17:16] <xnox> micahg: grid 5000 only gave lucas ~100 instances
[17:16] <micahg> smoser: yes, along with most other applications
[17:17] <xnox> micahg: on HPCloud they have 8-core & 32RAM instances
[17:17] <xnox> micahg: on HPCloud they have 8-core & 32 GB RAM instances
[17:17] <micahg> xnox: you're still blocked on build time :)
[17:17] <jcastro> xnox: ok so there's your baseline .... 8 hours. See if you can beat it. :)
[17:17] <xnox> micahg: yeah, hence excluding libreoffice
[17:17] <micahg> xnox: libreoffice isn't the worse thing time wise IIRC
[17:17] <infinity> xnox: 8 cores isn't interesting.  How many of those instances are you using?
[17:17] <smoser> well... most applications probably leak, but no other app both a.) do i run all day and use heavily and b.) leak memory in the dozens of megabytes per hour range.
[17:18] <xnox> infinity: i'm fighting with juju, I will let you know as soon as I get plenty instances
[17:18] <xnox> smoser: chromium is slightly better
[17:18] <infinity> xnox: Not in my experience. :P
[17:18] <micahg> smoser: https://wiki.mozilla.org/Performance/MemShrink#Bug_Tracking, feel free to file bugs if they aren't filed already if you have reproducers
[17:19] <infinity> xnox: chromium just fools you into thinking it's better because no one can do basic arithmetic to add up all the processes.
[17:19] <micahg> hehe
[17:19] <xnox> infinity: LOL
[17:19] <xnox> chromium generally uses MORE memory, but in my experience it LEAKS LESS
[17:19] <xnox> in my usage anyway
[17:19] <smoser> micahg, thanks. xnox, maybe, but chromium has no pentadactyl. so its not an option
[17:19] <jcastro> xnox: the openstack provider hasn't landed yet for juju, if you plop over on #juju we can give you a hand.
[17:19] <xnox> so it is rather under control.
[17:19] <slangasek> infinity: to be fair, it does tend to overflow the register
[17:19] <slangasek> so it's not entirely basic arithmetic
[17:20] <xnox> jcastro: ok. But it does kinda work with canonistack for example
[17:20] <smoser> but, thanks for the verification, micahg and xnox
[17:20] <jcastro> xnox: yeah we turn on things they don't, which is why you need the native provider
[17:21] <xnox> =(
[18:35] <alazare619> hey anyone here have any ideas how to create an entire chroot enviorment say with like debootstrap but have a certain user who connects via ssh go into that chroot (for development purposes as they require a sudo password to run some commands)
[18:44] <mterry> pitti, btw, test suites of trunks of update-manager and ubuntu-release-upgrader seem to work fine in a chroot now, so presumably will work on jenkins
[18:44] <jtaylor> alazare619: thats not very safe, you can escape chroots quite easily
[18:46] <alazare619> i did a vm server and port forwarded it to a vbox jtaylor but it kept on disconnecting the vbox session
[18:47] <alazare619> what other options do i have?
[18:47] <jtaylor> maybe a lxc container, but I don't know much about these
[19:22] <roaksoax> jdstrand: howdy! I'm looking for your input as part of the MIR team. For MAAS, one of the targets is to remove yui3 from maas source. I've been working with the debian maintainer for it, and we now have it in Ubuntu. He has patched the source package to include the source files to build a couple *.swf files shipped in yui3. However, this has added a build-dep on swftools, which is in universe.
[19:23] <roaksoax> jdstrand: swftoosl build-deps on libmp3lame-dev (from the lame source pacakage). So this means that in order to MIR this, we would need swftools and lame MIR's. Do you thin this is feaseable? Or, do you think I should remove the *.swf files from yui3 source and make it a dfsg package?
[19:24] <micahg> it's already dfsg if you're building the .swf files from source :)
[19:25] <roaksoax> micahg: right, but I mean repack the source and make it +dfsg
[19:26] <micahg> there's no need for that if the source is provided AIUI
[19:26] <jdstrand> roaksoax: hey. otoh I would suggest just removing the swf files. I'm guessing you don't use them, so I'm not super keen on pulling in these things just for a build-dep
[19:26] <roaksoax> micahg: if drop DM's patch and remove the *.swf it because a repacked source including +dsfg
[19:27] <roaksoax> s/because/becomes
[19:27] <roaksoax> jdstrand: ok, will do so. Thanks for the input
[19:28] <micahg> roaksoax: you can keep the patch and just not build the .swf files :)
[19:29] <micahg> that should keep the diff lower
[19:29] <roaksoax> micahg: good point!
[19:29]  * micahg sees the patch adds the source, not the logic to build
[19:30] <roaksoax> micahg: yes, the logic to build is in the rules files obviously
[19:31] <micahg> roaksoax: just make sure you don't end up installing the upstream .swf files either :)
[19:53] <OdyX> doko: are you coming to DebConf ? I'd like to handle the lsb sync from Debian (I'm planning to finish the testsuite and python3 port during DebCamp).
[19:53] <OdyX> doko: … to handle the lsb sync (…) in collaboration with you, preferably f2f.
[19:54] <infinity> OdyX: He is.
[19:54] <OdyX> infinity: cool, thanks.
[20:16] <dobey> hrmm
[20:16] <dobey> is there a way to force dh to use a specific build system, if multiple are in use?
[20:17] <jtaylor> --buildsystem
[20:26] <dobey> jtaylor: thanks. is there some easy way to see what it's doing exactly for cmake? is *all* the logic in the dh_auto_configure script?
[20:26] <jtaylor> export DH_VERBOSE=1
[20:29] <dobey> ah right
[20:30] <dobey> hrmm, it isn't printing the exact cmake command though :-/
[21:03] <micahg> roaksoax: I think we've been using yuicompressor rather than uglify to accomplish the same task
[21:04] <micahg> technically since it's MIT, you can get away with what you did
[21:11] <roaksoax> micahg: right, upstream ships a -min.js library which for some reason was not being included in the source when the debian maintainer packaged it
[21:11] <roaksoax> micahg: so it made no sense to build one in packaging
[21:12] <micahg> roaksoax: right, because, that's not the preferred form of modification
[21:12] <ScottK> roaksoax: minified javascript is not considered source.
[21:12] <micahg> ScottK: I thought that was license dependent
[21:13] <roaksoax> ScottK: some libraries do ship minified javascript
[21:13] <ScottK> Those are buggy from a Debian policy POV.
[21:13] <micahg> roaksoax: that's not what he means :)
[21:13] <ScottK> Just because the license allows it, doesn't make not providing source DFSG free.
[21:14] <roaksoax> ScottK: right, but the minified version is distributed with the source
[21:14] <ScottK> Effectively, you need to provide preferred form to meet DFSG even if the license doesn't require it.
[21:14] <roaksoax> ScottK: i'm just adapting to what the maintiner did.
[21:14] <ScottK> roaksoax: We strip pre-compiled binaries out of upstream source all the time.  This is the same thing.
[21:15] <micahg> roaksoax: no adapting would be using yuicompressor instead of uglify, you basically reverted the removal of the non-source
[21:15] <ScottK> Figure out what it's a minified version of and then depend on the appropriate javscript library.  It's probably in the archive.
[21:16]  * micahg apologizes for the misinfomation earlier
[21:16] <ScottK> dh_sphinx is super cool about handling this for sphinx based docs.
[21:16] <roaksoax> ScottK: so these means an archive cleanup in debian would need to be done as other packages do ship minified versions
[21:16] <roaksoax> such as YUI3
[21:16] <ScottK> roaksoax: It is in progress.
[21:16] <ScottK> There are lintian warnings about it now and eventually it'll be bugs.
[21:17] <roaksoax> ack
[21:17] <ScottK> It's a large mess that won't get fixed overnight, but in the meantime, don't make it worse.
[21:17] <micahg> well, yui3 has both the minified versions and the full source shipped
[21:17] <micahg> *in binary form as well
[21:18] <ScottK> That's OK, although what's shipped in the binary package should be rebuilt.
[21:19] <Daviey> slangasek: I seem to remember you were involved with DFSG discussion around packages which were Public Domain?  Was that right?
[21:19] <slangasek> uh... possibly
[21:19] <Daviey> slangasek: I failed to remember the outcome.. is it fit for universe/main ?
[21:20] <slangasek> true public domain works are always free
[21:20] <infinity> Daviey: Public domain is perfectly free.  The problem comes in with some countries that stubbornly insist that you "can't" put a work in the public domain.
[21:20] <ScottK> Emphasis on the true.
[21:20] <Daviey> i thought in some countries it meant it was actually non-free?
[21:20] <infinity> Daviey: As long as we have a strong statement from the original copyright-abandoner, I do believe we tend to just ignore those countries and their silliness.
[21:21] <slangasek> however, some licensors fail to use the term "public domain" correctly and make conflicting statements in their own license grant, in which case the "public domain" statement should be ignored
[21:21] <slangasek> Daviey: the issue is that, in *most* countries, there's either no such legal doctrine as "public domain", or there's no process for a copyright holder to make a public domain grant of a work
[21:21] <infinity> (There's actually a creative commons "as close to PD as you can get while still technically retaining copyright" license that tries to work around the weird places where you "can't" give up copyright)
[21:22] <slangasek> where the intent is clear, it should be sufficient to let it in as-is provided we also follow up and ask them for a clarifying license grant
[21:22] <Daviey> http://pb.daviey.com/PrwT/
[21:22] <slangasek> ("clarifying" in the sense that it will stand up in court, even though we and they both already know what they mean)
[21:22] <Daviey> PKG-INFO from upstream seems pretty clear
[21:22] <Daviey> (yes, i know it's not a versioned dep-5 spec)
[21:23] <slangasek> Daviey: wrong license on the debian/* files, should be GPL-3 ;)
[21:23] <ScottK> Also this can't be right:
[21:23] <ScottK> Copyright: 2012 Yannick Gingras
[21:23] <ScottK> License: Public domain
[21:23] <ScottK> It's have to be Copyright: None, wouldn't it?
[21:24] <Daviey> ScottK: Well can you work out how to do it via dep-5?
[21:24] <Daviey> hmm
[21:24] <ScottK> Daviey: I manage it fine by ignoring DEP-5.
[21:24] <tumbleweed> Daviey: start with the basics. Work out what the author meant
[21:24] <infinity> Daviey: Copyright "None" or "Public domain" would be correct.  PD, by definition, means no copyright.
[21:24] <Daviey> yeah
[21:24]  * Daviey rejects.
[21:25] <infinity> (Which is why it breaks in some countries, where original artists *always* retain copyright, legally)
[21:25] <slangasek> Daviey: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ (DEP-5 was the draft), and yes, you can: there's verbiage in the spec about what to put in "Copyright" for PD works
[21:27] <Daviey> slangasek: I think it'll forever be called DEP-5 :)
[21:27] <Daviey> i see it should also be, Licence: public-domain
[21:28] <slangasek> if it's meaning to be compliant with the spec, yes
[21:28] <Laney> License ;-)
[21:28] <Daviey> slangasek: What is the point in specs if it's not adhered to? :)
[21:28] <slangasek> Daviey: getting DEP-5 syntax wrong is not grounds for rejecting a package from the archive
[21:28] <Daviey> Laney: well spotted
[21:29] <slangasek> claiming that something is both copyrighted and public domain is
[21:29] <Laney> that always stands out to me
[21:29] <Daviey> slangasek: No, but the Copyright: None is, right?
[21:29] <galfly> hi everyone. How can I make changes to a package and test it locally? I downloaded the source but when I try to configure and make, I get a long list of errors
[21:29] <Daviey> slangasek: Right, so i've made suggestions that the other parts are changed, but the Copyright: None is essential.
[21:30] <slangasek> sounds good
[21:30] <slangasek> galfly: package builds are controlled through the makefile called debian/rules; you can call it as a script, as in 'debian/rules build' or 'fakeroot debian/rules binary'
[21:30] <roaksoax> micahg: does this satisfy your concerns? http://paste.ubuntu.com/1073845/
[21:31] <micahg> roaksoax: looks great (and mirrors the other JS stuff in main)
[21:32] <galfly> slangasek: I will try that. Thank you so much.
[21:40] <jdstrand> tumbleweed: fyi, --install-layout=deb did the trick. thanks!
[21:41] <seb128> barry, hey
[21:41] <barry> hi seb128
[21:41] <seb128> barry, I see that you have a work item "port xdg" on foundations-q-python-versions
[21:41] <seb128> barry, is that pyxdg?
[21:42] <seb128> barry, they released a new version compatible with python3 recently, http://freedesktop.org/wiki/Software/pyxdg
[21:42] <barry> seb128: yeah, but i think that's a big task, if not improbable ;)
[21:42] <barry> oh!
[21:42] <seb128> barry, not sure if you saw, but I figured you might be interested to do the package update
[21:42] <seb128> "Compatible with Python 3; requires Python 2.6 or later "
[21:42] <barry> seb128: indeed i am, thanks for the pointer!
[21:42] <seb128> barry, yw ;-)
[21:43] <slangasek> barryyyy
[21:43] <slangasek> how's post-apocalyptic DC?
[21:43] <barry> slangasek: getting back to normal.  how precarious is our society! :)
[21:45] <slangasek> :)
[21:45] <seb128> barry, I've assigned you https://bugs.launchpad.net/ubuntu/+source/pyxdg/+bug/823150 so we don't dup work if anyone else wants to look at that update
[21:46] <barry> seb128: perfect thanks.  i'm going to start working on that now
[21:46]  * slangasek replaces the WI in the blueprint with a linked bug
[21:46]  * barry updates the spreadsheet
[21:47] <seb128> barry, thanks
[21:47] <barry> actually, spreadsheet is already updated
[21:49] <seb128> slangasek, is the $XDG_RUNTIME_DIR support for our stack still likely for this cycle? :-)
[21:50] <slangasek> seb128: yes, I think so
[21:50] <seb128> slangasek, the most popular nautilus segfault on errors.ubuntu.com is due to the lack of $XDG_RUNTIME_DIR in Ubuntu :-(
[21:50] <slangasek> oh really?
[21:50] <seb128> yes
[21:50] <slangasek> that seems like an unfriendly thing for nautilus to do
[21:51] <seb128> dconf uses mmap and those don't work reliable on ecryptfs or nfs
[21:51] <seb128> reliably
[21:51] <slangasek> seb128: btw, can someone please revert the /run/media nonsense?  /media is defined in the FHS
[21:52] <seb128> slangasek, I will have a look at what's the rational for using /run ... how much do we care about being compliant with the FHS on that? :-)
[21:52] <slangasek> a lot?
[21:52] <slangasek> moving mount points around under users for no reason is unfriendly
[21:53] <Daviey> Perhaps i am a bad man, but I actually have things hardcoded to use /media/FOO
[21:54] <maxb> If the FHS says you can.... :-)
[21:54] <seb128> slangasek, I need to check but I think it makes sense for parts of the mounts to be under /run
[21:54] <slangasek> seb128: there's no reason for this move, it's entirely gratuitous
[21:54] <seb128> slangasek, i.e the ones which were in .gvfs before
[21:54] <slangasek> oh
[21:54] <seb128> the fuse user mounts
[21:54] <slangasek> ok, I haven't seen that happening yet - so possibly
[21:54] <slangasek> but e.g., my usb stick shouldn't suddenly move from /media/$SERIAL to /run/media/vorlon/$SERIAL on upgrade
[21:55] <Daviey> unless at least a compat symlink is put in place?
[21:55] <slangasek> gvfs-fuse-daemon on /home/vorlon/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=vorlon)
[21:55] <slangasek> so no, this doesn't even touch gvfs ;)
[21:57] <seb128> slangasek, http://git.gnome.org/browse/gvfs/commit/?id=6307d017a12642e71ba2f04e82fc3781425a3eb6
[21:57] <seb128> that indicates it's coming from udisks2
[21:57] <seb128> I will check with pitti what he thinks ;-)
[21:57] <slangasek> okie
[21:58] <seb128> slangasek, http://cgit.freedesktop.org/udisks/commit/?id=502fb5b7810afb50e48354e6b4d1781d07f79e10
[21:58] <seb128> no bug reference or rational :-(
[21:59] <seb128> slangasek, can you open a bug about that?
[21:59] <seb128> so we make sure to track it
[21:59] <slangasek> seb128: ok
[21:59] <seb128> thanks
[21:59] <slangasek> thank you!
[22:50] <slangasek> seb128: bug #1020759
[22:50] <seb128> slangasek, thanks