[00:02] <bryceh> slangasek, does the multiarch patch for libxaw on bug 834438 look sane to you?
[00:03] <Daviey> infinity: sounds good to me!
[00:06] <kees> smoser: it looks like it's more than just adding it back in, since they appear to have added vulnerable code now, too.
[00:07] <kees> smoser: so you'll need to fix at least the one flaw that the compiler flags found
[00:07] <smoser> suck.
[00:08] <smoser> kees, that can wait til post beta?
[00:08] <smoser> (i opened bug 837085)
[00:08] <kees> smoser: totally
[00:08] <kees> smoser: no rush at all. I just happened to notice it today while running the packages-built-with-PIE regression tests
[00:09] <Daviey> kees: I've noticed over the cycles that you re-introduce PIE on a number of packages. :/
[00:10] <kees> Daviey: well, people don't always merge correctly. so I wrote regression tests. :)
[00:10] <micahg> Debian is starting to get into PIE more as well
[00:10] <kees> micahg: yup, totally. for every PIE change I make, I usually open a Debian bug for it.
[00:10] <kees> micahg: most have been accepted.
[00:17] <smoser> kees, it was completely a wrap-and-sort failure :-(
[00:17] <smoser> eyeballs bad after 80 columns
[00:19] <Daviey> 14:37 <zul> ok MIRs updates:
[00:19] <Daviey> oops
[00:19] <infinity> Away for a few hours, nick hilight me if you need me, I'll be back in the evening.
[00:23] <kees> smoser: heh, no worries.
[00:24] <slangasek> bryceh: yes, the patch looks correct to me provided that the package builds with it applied; bear in mind that this gets entangled with the freeze however
[00:24] <slangasek> (feature freeze)
[00:27] <bryceh> slangasek, should it wait for post-beta, or delay until p opens?
[00:28] <slangasek> bryceh: there's risk of regression for reverse-build-deps, so I think it's "delay until p" (preferably pushing to Debian in the meantime)
[00:28] <bryceh> ok thanks
[00:31] <bryceh> robert_ancell, how come on some of my test boxes I see a greeter with a pretty password entry field on the left, and on other test boxes I see a centered dialog with more of a gnome-ish looking icon on it.  Am I missing some theme package?
[00:32] <bryceh> hmm unity-greeter mayhaps
[00:34] <robert_ancell> bryceh, it sounds like you're running unity-greeter on some boxes and lightdm-gtk-greeter on others
[00:34] <bryceh> yep, installing unity-greeter did it
[01:17] <TheMuso> /c
[01:47] <RAOF> @pilot in
[01:56] <ArneGoetje> pitti: where can I download the Chinese edition for testing?
[03:16] <broder> cjwatson, stgraber: quick ping re plymouth-upstart-bridge. why not have it connect to the dbus daemon upstart itself runs on @/com/ubuntu/upstart? it seems like that would actually allow us to catch almost all of the events that happen at boot, instead of now when we only see things in the narrow window between when dbus starts and when gdm/lightdm do
[04:10] <pitti> Good morning
[04:11] <pitti> freeflying: ah, thanks
[04:14] <pitti> ArneGoetje: it's not on any public place yet; you can build it with ubuntu-defaults-image, but it's by and large the standard CD plus the full Chinese support (as per language-selector), minus all other langpacks (we keep -en), plus the extra stuff from the ubuntu-defaults-zh-cn package
[04:15] <ajmitch> morning pitti
[04:16] <nigelb> Good morning pitti, afternoon ajmitch )
[04:16] <nigelb> :)
[04:16]  * nigelb tried to autocomplete afternoon.
[04:16] <ajmitch> hi nigelb
[04:16] <ajmitch> heh
[04:16] <RAOF> :)
[04:23] <ArneGoetje> pitti: I'm rebuilding the ttf-arphic-uming and ttf-arphic-ukai packages, which will add lzma compression to ukai and remove the dependencies on defoma and x-ttcidfont-conf for both packages.
[04:26] <ArneGoetje> pitti: I will take a look at the dependencies for the language-support stuff and get back to you later... maybe we can throw something out which is not terribly important.
[04:29] <pitti> ArneGoetje: I removed the two fonts as freeflying suggested (in bzr, not uploaded)
[04:30] <ArneGoetje> pitti: ah...
[04:30] <ArneGoetje> pitti: and still not enough?
[04:31] <pitti> we can also put them back there, and only install a subset of the Chinese support on the CD, but that's harder to maintain and would still bother people with downloading 20 MB of stuff after installing
[04:31] <pitti> ArneGoetje: still need to reduce by a bit, but shouldn't be so bad any more; I'll rebuild a CD with that and see what's left
[04:32] <ArneGoetje> pitti: people will have to download additional packages anyways, since there is no way to fit all of them on the CD... we only need to choose which packages they have to download. ;)
[04:33] <pitti> ArneGoetje: well, it's not actually that many -- with the two fonts gone, it'll almost fit, and the CD even has some extra stuff like sina/soho gwibber plugins, stardict, nanny, gufw
[04:38] <ArneGoetje> pitti: but the OEM fonts are not included?
[04:38] <pitti> OEM fonts?
[04:39] <ArneGoetje> pitti: ok, they are not. In that case, users will want to download the uming and ukai fonts, otherwise they don't have Song/Kai style fonts for printing.
[04:40] <ArneGoetje> pitti: but that's OK. For the live CD, the WQY-MicroHei font is sufficient.
[04:40] <pitti> ArneGoetje: we also have ttf-wqy-zenhei
[04:40] <pitti> i. e. with the full support we ship microhei, zenhei, and currently ttf-arphic-{uming,ukai}
[04:40] <pitti> that seems a little excessive?
[04:41] <pitti> ArneGoetje: ok, reverted the l-s commit
[04:41] <pitti> I'll update ubuntu-defaults-zh-cn instead
[04:41] <pitti> to only explicitly depend on a subset and not install the full chinese support
[04:42] <pitti> that pretty much breaks the idea of check-language-support, but *shrug*
[04:42] <ArneGoetje> pitti: not necessary, IMHO. ZenHei is the same style as MicroHei, but covers more characters IIRC. However, for daily use, MicroHei is sufficient.
[04:43] <ArneGoetje> pitti: uming and ukai are different font styles, which are mostly used for printing.
[04:43] <ArneGoetje> pitti: why would updating ubuntu-defaults-zh-cn break check-language-support?
[04:44] <pitti> I mean, we can't use it, but would use an explicit dependency list
[04:44] <pitti> it's not a big deal, we just need to update it whenever pkg_depends changes
[04:44] <ArneGoetje> pitti: sure
[04:45] <pitti> and it would still mean that Chinese users had to download stuff during installtion
[04:46] <ArneGoetje> pitti: of course and I guess that's inevitable
[04:49] <ArneGoetje> pitti: I just wonder why all of a sudden you care about a Chinese edition, when all the years we said we don't want specific language editions...
[04:50] <pitti> ArneGoetje: we have had a Chinese Edition since Maverick
[04:50] <pitti> but it's rather poor, it's exactly like the standard CD just with the language default being zh_CN
[04:50] <pitti> now we want to do a proper Chinese one with more localization/special programs/web launchers etc.
[04:51] <ArneGoetje> pitti: ah really? Will this also happen for other languages?
[04:52] <pitti> ArneGoetje: not on cdimage.u.c. (at least just yet), but with ubuntu-defaults-builder we now offer tools for Locos etc. to build their own
[04:52] <ArneGoetje> pitti: good.
[04:52] <pitti> ArneGoetje: e. g. the French loco has been building French CDs for a long time, and now they get better tools
[04:54] <ArneGoetje> pitti: does this also work with DVD images?
[04:55] <pitti> not yet
[04:55] <pitti> well, of course the defaults packages can pull in arbitrarily many dependencies
[04:55] <pitti> but ubuntu-defaults-image currently bases off the standard Ubuntu CD set, not the USB/DVD one
[04:55] <pitti> but that should be rather easy to add
[04:59] <ArneGoetje> pitti: I can imagine that for some Locos DVD images should be more interesting... in TW for example a very popular Ubuntu spin-off is Ezgo, which puts everything education related, plus full localization on a DVD.
[05:04] <ArneGoetje> pitti: anyways, I would suggest to remove the zenhei, uming and ukai fonts from the live CD, but let the users download them during insstallation.
[05:04] <pitti> okay
[05:32] <RAOF> @pilot out
[05:39] <didrocks> good morning
[06:50] <pitti> doko_: nice, did you see sqlite on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
[06:51] <pitti> doko_: do you want to have the honor of demoting it, or want me to? :-)
[07:00] <dholbach> good morning
[07:35] <jamespage> @pilot in
[07:35] <jamespage> morning all
[07:42]  * dholbach hugs jamespage
[08:45] <tkamppeter> pitti, hi
[08:46] <pitti> hello tkamppeter
[08:47] <tkamppeter> pitti, can you approve c2esp? It is a fix of a security problem. The printer maintenance filter of the driver generates temporary files with a fixed name.
[08:48] <cjwatson> broder: I would except that's formally private to upstart and other packages are not permitted to depend on its interface.  if I'd elected to make plymouth-upstart-bridge part of upstart, that might be different
[08:48] <pitti> tkamppeter: ok, looks harmless enough
[08:49] <tkamppeter> pitti, thanks.
[09:05] <OdyX> tkamppeter: ah, I'm currently patching pxljr because it embeds both ijs and libjpeg (dunno how it could end in Ubuntu…)
[09:13] <tkamppeter> OdyX, IJS it embedded all the time, libjpeg I have embedded recently, because of bug 777670. Now, where libjpeg6b is fixed, the embedding is not needed any more.
[09:14] <OdyX> tkamppeter: I'd be happy to see an updated upstream release with libjpeg and ijs thrown out of the source (I'll upload 1.3+repack0 with a patch that enables build with system ijs and libjpeg).
[09:15] <tkamppeter> OdyX, my Ubuntu package uses the pxljr upstream version with embedded libjpeg, one should somehow switch to the one without, but in a way that Ubuntu can merge it.
[09:16] <OdyX> tkamppeter: oh, there is one upstream version without libjpeg ?
[09:16] <tkamppeter> OdyX, you should contain upstream maintainer Hin-Tak Leung and send him a patch.
[09:17] <OdyX> tkamppeter: will do once pxljr is accepted in Debian
[10:05] <cjwatson> argh, so many broken cmake libraries in the archive
[10:05] <cjwatson> it's like dependency_libs only worse
[10:11] <doko_> pitti, heh, go ahead =) Daviey did give it back one more time, and it did succeed to build ...
[10:14] <pitti> doko_: heh, sometimes being insistive seems to help :) demoted
[10:56] <doko> Sweetshark, ping
[11:13] <jtaylor> did the Release signing break again? got another bad signature from main archive made Tue 30 Aug 2011 11:16:37 AM CEST
[11:15] <tkamppeter> pitti, can you approve system-config-printer? I had to apply a small patch as one of my patches from last week broke the printer maintenance buttons (head cleaning, ...).
[11:15] <pitti> tkamppeter: sounds like that would have time until after b1, though?
[11:22] <tkamppeter> pitti, OK. Will it get approved then? I am on vacation from this Thursday until the Friday of the next week.
[11:23] <pitti> tkamppeter: yes, the queue will be flushed after b1
[11:24] <jamespage> @pilot out
[11:26] <tkamppeter> pitti, OK, so I simply upload further fixes which I will find and the not urgent ones get into Oneiric after b1. OK.
[11:37] <Sweetshark> doko: pong
[12:04] <hrw> is simple-ccsm used at all today?
[12:25] <janimo> @pilot in
[12:25] <janimo> dholbach, hello. Can I unsubscribe sponsors from a bug? I see no such link in LP
[12:28] <janimo> dholbach, AIUI needs-packaging bugs do not needs sponsors (yet) as packaging can be done without upload privileges
[12:42] <dholbach> janimo, I added you to ubuntu-sponsors
[12:42] <dholbach> does it work now?
[12:42] <dholbach> janimo, is the new package in the bug ready to be sponsored maybe?
[13:14] <dholbach> slangasek, hiya - how do you feel about bug 837383?
[13:14] <janimo> dholbach, there was no package attached, just a need-packaging tag, Thanks for adding me to sponsors
[13:15] <janimo> hmm. there's a REVU link though. I stand corrected
[13:17] <dholbach> stgraber, https://launchpad.net/arkose says there talks about an arkose-wrapper package - is that available somewhere?
[13:18] <dholbach> janimo, no worries :)
[13:19] <stgraber> dholbach: arkose-wrapper-gui /usr/share/arkose/wrapper-profiles/skype.conf
[13:19] <stgraber> dholbach: on Oneiric
[13:20] <dholbach> arkose-gui you mean?
[13:20] <dholbach> yeah, I see it - thanks :)
[13:21] <soren> dholbach: You can install all of those using multiarch these days.
[13:22] <soren> dholbach: I got skype to work that way.
[13:22] <dholbach> soren, yes,  I guess I should have just installed skype_something_i386.deb
[13:23] <dholbach> soren, but people who upgrade might be in for a nice surprise
[14:16] <OdyX> tkamppeter: do you have a possibility to test pxljr ? FYI, I pushed my work on http://anonscm.debian.org/gitweb/?p=collab-maint/pxljr.git;a=summary and I'd appreciate "review" (aka does it work).
[14:43] <janimo> can someone allow gnome-utils in, so further patch pilots do not try to do the same work again?
[15:01] <pitti> janimo: can't you just unsubscribe sponsors from the bug?
[15:02] <slangasek> dholbach: 837383 is a wontfix - you need to install skype:i386 instead :)
[15:02] <slangasek> dholbach: as soon as there's an updated skype package for oneiric in partner, ia32-libs in oneiric will declare a Breaks: on the old versions
[15:08] <janimo> pitti, it is that what I could not do, before dholbach added me to the sponsors team. I though every uploader is a sponsor implicitly
[15:08] <janimo> but turned out sponsors may need to remaIn subscribed as there is a REVU link on the bug I looked at
[15:08] <tkamppeter> OdyX, will do.
[15:08] <janimo> pitti, ah, you mean as an alternative to the moderation
[15:09] <OdyX> tkamppeter: great, thanks.
[15:09] <janimo> good idea, will do that, thanks!
[15:10] <dholbach> slangasek, so we won't have a way to upgrade skype? (if I understand correctly, folks will have to upgrade, then notice that skype is gone, then install skype through software-center?)
[15:21] <pitti> janimo: i. e. if you upload a package, and it won't hit the archive right away (freeze or SRU), I think ubuntu-sponsors should generally be unsubscribed to get it off the queue, yes
[15:25] <tkamppeter> OdyX, I have downloaded your GIT, the debian/changelog seems not to be up-to-date yet.
[15:25] <OdyX> tkamppeter: it's never. I prepare it just before uploading using git-dch + hand-editing.
[15:26] <tkamppeter> OdyX, and where do I get the .orig.tar.gz to be able to build the package?
[15:26] <OdyX> tkamppeter: try to build with 1.3+repack0-0ubuntu1 e.g
[15:26] <OdyX> tkamppeter: git-buildpackage -S (will use pristine-tar
[15:27] <OdyX> tkamppeter: or pristine-tar checkout pxljr_1.3+repack0.orig.tar.bz2; mv pxljr_1.3+* ../
[15:27] <slangasek> dholbach: I believe they will be able to automatically upgrade to the i386 skype package
[15:27] <dholbach> slangasek, that'd be nice
[15:28] <slangasek> can't test this for certain until there's an i386-only skype package in the partner archive though
[15:30] <dholbach> ok
[15:31] <OdyX> tkamppeter: here it does compile against libjpeg8 and libijs-0.35, no idea if it works sanely though (and that's what I'd like to know)
[15:32] <OdyX> tkamppeter: the thing is I cannot upload a source that uses embedded libraries to Debian.
[15:32] <tkamppeter> OdyX, problem is that you do not provide the newest debian/changelog entry, as this one defines the version number.
[15:33] <tkamppeter> OdyX, it would be much more convenient to have this entry in the GIT, so that one can simply build the package from the GIT.
[15:33] <OdyX> tkamppeter: dch -b -v 1.3+repack0-0ubuntu1~local0 "TEST-BUILD"
[15:34] <OdyX> tkamppeter: well, that's my imperfect git-dch workflow. I know it has flaws, but it works-for-me™
[15:35] <mr_pouit> superm1: xubuntu doesn't ship a default lightdm.conf file. If lightdm-set-default creates it with wrong values, then it should be fixed I guess (adding workarounds for that in the postinst looks like a bad idea?)
[15:36] <superm1> mr_pouit, that's why i was proposing the user-setup solution to follow the casper solution rather than sed values that aren't put by lightdm-set-defaults
[15:37] <tkamppeter> OdyX, why keeping changelog messages as private secrets, they can also be handled by version control.
[15:38] <OdyX> tkamppeter: git-dch uses the commit messages to generate the debian/changelog, they are not secret. (This way I avoid writing them twice)
[15:39] <OdyX> (and forces me to write nice commit messages. You can also use meta-tags: Signed-off-by, Reported-by, Closes, … and assign stuff to people correctly with --author="…")
[15:39] <tkamppeter> OdyX, it does not link for me, http://paste.ubuntu.com/678064/
[15:40] <mr_pouit> superm1: sorry, I don't really follow the discussion, so I've probably no idea what you're talking about (I just reacted to some comments charlie-tca forwarded to me). I'm just saying that we don't ship any default config (and we don't intend to), we only rely on lightdm-set-default.
[15:40] <OdyX> tkamppeter: do you have libijs-dev installed !?
[15:40] <OdyX> (and libjpeg8-dev)
[15:41] <charlie-tca> heh, I haven't been able to follow the discussion either. I just got asked and told we needed to do something
[15:41] <superm1> mr_pouit, OK, it was discussion in #ubuntu-installer with ev and stgraber about user-setup's solution for lightdm autologin
[15:41] <OdyX> tkamppeter: Agreed, my auto*foo is bad and I don't check those in the build process, but they are listed as build-depends)
[15:43] <tkamppeter> OdyX and your package does not build-depend on these libraries.
[15:43] <infinity> @pilot in
[15:43] <infinity> Fair warning, my cable is out and I'm stuck tethering on 3G right now, but still happy to pilot urgent things, if people have any.
[15:44] <OdyX> tkamppeter: huh ? It does.
[15:44] <tkamppeter> OdyX, it build-depends on libjpeg-dev which conflicts with libjpeg8-dev (at least in Oneiric).
[15:44] <OdyX> tkamppeter: huh ? In Debian, it's a "Provides"
[15:46] <OdyX> tkamppeter: in any case, I have to go, sorry. I'd love some feedback per mail or as a separate branch on the git repo.
[15:46] <tkamppeter> OdyX, in Ubuntu, libjpeg-dev is still provided by libjpeg62-dev and several library's -dev packages depend on libjpeg62-dev (libjpeg-dev).
[15:46] <OdyX> tkamppeter: it should build with B-D: libjpeg-dev | libjpeg8-dev
[15:46] <OdyX> anyway, I'm really late, have to go ! Cheers
[15:47] <tkamppeter> OdyX, see you tomorrow.
[16:05] <janimo> @pilot out
[16:10] <Daviey> jdstrand: Did you get the mail from Thomas regarding the mythbuntu-bare reject?
[16:14] <jdstrand> Daviey: I have it but didn't see it. I'll respond
[16:15] <SpamapS> ARGH! mongodb now embeds spidermonkey in its source tree
[16:16] <micahg> SpamapS: not a problem, Debian switched to v8 and we'll follow for P
[16:16] <SpamapS> micahg: upstream is only going to support their in tree spidermonkey. :(
[16:17] <SpamapS> They're also switching to static linking by default
[16:17] <SpamapS> Basically "screw our users' security, we know better"
[16:17] <Daviey> jdstrand: thanks
[16:18] <micahg> SpamapS: hmm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631054#19
[16:19] <SpamapS> micahg: yeah, thats a sensible solution. I'm more concerne that upstream will now really dislike the Debian and Ubuntu packages.
[16:19] <SpamapS> they already derride them because they're so far behind Mongo's usual release schedule
[16:21] <pitti> lamont, infinity: could you please kill the linux build on crested?
[16:22] <pitti> I set it to manual now as we are going to need some urgent uploads for beta-1
[16:22] <pitti> and we can't afford having three linuxes build at the same time (each taking 6 hours)
[16:22] <pitti> they just started, so not much will be lost
[16:27] <pitti> lamont, infinity: linux build on yellow, too, please
[16:27] <pitti> elmo: or can you do it? infinity can't any more
[16:33] <infinity> pitti: IS contacted, deej is on it.
[16:33] <pitti> infinity: cheers
[16:37] <pitti> infinity: nice, done now; thanks!
[16:39] <pitti> argh, darn
[16:39] <pitti> infinity: someone switched it to auto (or the restarting did)
[16:39] <pitti> infinity: we need crested build killed again :/
[16:40] <pitti> ithanks
[16:41] <infinity> pitti: Should be good to go.
[16:42] <pitti> right
[16:43] <pitti> sconklin: please ignore the linux build failures that you just got
[16:43] <pitti> sconklin: we had to kill some amd64 builds, as they got in the way of beta-1 release, sorry
[16:43] <pitti> sconklin: I'm retrying the builds and lowering their score
[16:44] <infinity> sconklin: (And on a side note, please don't upload a ton of kernels to non-virtual PPAs during a beta/release freeze)
[16:44] <sconklin> pitti, thanks for the warning
[16:44] <infinity> sconklin: If you do it serially, that would be alright, but clogging up all the buildds in parallel can be problematic.
[16:46] <sconklin> pitti, we don't really have any sort of interlock with stable cycle and freezes, nor do we want to.
[16:46] <sconklin> and our whole cycle is that we tend to do them all at the same time. So I think this needs more discussion.
[16:46] <pitti> sconklin: yeah, in most cases it's not a problem, just right now; so I had to kill the lucid/maverick ones, but they should build in a couple of hours
[16:47] <infinity> sconklin: In an ideal world, we'd have slightly better control over how we can allocate these resources.  We'll revisit it. :P
[17:02] <infinity> pitti: I'm going to steal one of your amd64 buildds for a 2-minute build and give it right back. :)
[17:02] <pitti> infinity: sounds fine, please go ahead
[17:02] <pitti> infinity: in fact, the other buildd would be fine to grab small packages, just not the linuxes
[17:03] <infinity> Or... Nevermind, it just built on allspice.
[17:17] <cjwatson> Picking 'sushi' as source package instead of 'maki'
[17:17] <cjwatson> ... ah, one of *those* naming schemes
[17:27] <pitti> frankly I'd rather pick a pizza now
[17:37] <infinity> pitti: Send me one too, please.
[17:39] <SpamapS> slangasek: with the upload of libpam-heimdal to maverick-proposed .. was the plan to also copy the binaries to natty-proposed ?
[17:40] <SpamapS> slangasek: otherwise seems like the version needs to be 3.15-2ubuntu2.10.10
[17:40] <slangasek> SpamapS: yes, was intending to copy the one binary to both
[17:40] <SpamapS> slangasek: ok sounds good
[17:58] <Sweetshark> sooo, whats the best way to binary patch something in a package? apart from "dont"?
[18:09] <pitti> infinity: what was the package for the pizza IRC plugin again?
[18:09] <ion> sweetshark: I’m doing that hack with diversions. It’s nasty, but it works. https://github.com/ion1/gsd-lcdfilter https://launchpad.net/~ion/+archive/gsd-lcdfilter/+packages
[18:11] <kirkland> fresh install of ubuntu oneiric server today, and / is getting mounted read-only ... known bug or perhaps something new?
[18:12] <kirkland> cjwatson: ^
[18:12] <kirkland> cjwatson: i'm trying a second time now, to see if i can reproduce it
[18:15] <infinity> pitti: You can just jam a pizza in your CD drive and udev will link it to /dev/pizza, which you can then DCC to me.  Thanks in advance.
[18:16] <janimo> Sweetshark, what kind of binary patch?
[18:16] <pitti> infinity: it failed at 97%, but that might be enough for dinner; add the missing slice of salami yourself
[18:17] <infinity> pitti: If your pizza's being truncated, it's probably too high density, might need a Blu-ray player.
[18:17] <broder> that would be one tasty pizza
[18:19] <Sweetshark> janimo: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/756895 <- change to icons (pngs) done on the master branch, but after branch off of the release branch.
[18:19] <doko> Laney, did you look at haskell on arm and powerpc and find out what is the blocking thing?
[18:21] <Sweetshark> janimo: git can create binary patches, but I know if they can be applied to raw files without a repo below it -- also I would need git as a build dep (not that it would matter much for LO)
[18:21] <janimo> Sweetshark, is doing that as a backport an option? I see that seems to be implied by your last comment on the bug. It may be cleaner that way
[18:23] <broder> Sweetshark: libreoffice is a v3 source package, so just drop the icons in the debian/ directory and copy them over the original versions during build
[18:24] <infinity> doko: Did you want me to do those ocaml syncs, or are you on it?
[18:24] <infinity> doko: Oh, nevermind, I see them.
[18:25] <doko> infinity, you could accept a few universe packages from unapproved instead ;)
[18:26] <Sweetshark> broder: could do. but those images are quite a few ...
[18:29] <Sweetshark> janimo: doing it as a backport is certainly an option.
[18:30] <broder> Sweetshark: put the images in the same directory structure they'll be in when they're installed (i.e. if they're all going in /usr/share/icons/stuff, create a "debian/stuff" directory), then you can just specify "debian/stuff usr/share/icons/stuff" in a .install file
[18:33] <Sweetshark> broder: its not that easy as LO is currently still a rather perverted package: Its *.orig tarball contains again tarballs with the real source which are then unpacked during the build. which makes all patching a PITA.
[18:33] <broder> Sweetshark: yeah, i was looking - it's impressively messy :)
[18:33] <broder> but i think you could patch this in in the install target of the rules file just before you call dh_install
[18:33] <Sweetshark> broder: right.
[18:34] <broder> so:
[18:34] <broder> - put the images in the debian/ directory, so they get included in the debian.tar.gz
[18:34] <broder> - patch debian/rules install target to include that debian/ subdirectory in the libreoffice-common.install file, or wherever it is that it's going
[18:36] <Sweetshark> janimo: as for backports: I could also propose the commits to be cherrypicked to 3.4 for the 3.4.4 release, so they would be included in that release (which we would likely SRU anyway) http://wiki.documentfoundation.org/ReleasePlan/3.4#3.4.4_release
[18:38] <janimo> Sweetshark, yeah, that would be best, it should be a safe change
[18:39] <janimo> the less package changes the better :)
[18:40] <Sweetshark> broder: naa, I have to copy the files into the source after the tarballs have been unpacked and before the "real" build is started. the images get packed again in some zip-file with some additional magic. And the zip-file is the stuff that goes in the final package later ;)
[18:40] <Sweetshark> janimo: ohh, in LibreOffice we only have ~50 patches to upstream.
[18:40] <broder> Sweetshark: you don't need the files to be in the original source. instead of replacing them at build time, you can replace them during the package's install target in place on the DESTDIR
[18:41] <Sweetshark> broder: I am not installing the pngs, I am installing a special zip-file where the pngs have been packing into after some namemangling magic.
[18:42] <infinity> Sweetshark: So, you need a bit of magic to copy from debian/ to the source tree before the build.  And if you want debian/rules clean to actually work, you need to back up the originals, and have clean put them back in place.
[18:45] <infinity> Well, unless the build system is smart enough to pick up your copies if you put them in build/path/to/where/they/live/in/src/file.png
[18:45] <infinity> Then no real magic required, you just need to put them there at the beginning of your build.
[18:45] <Sweetshark> infinity: I dont have to care about the clean target, as clean deletes the unpacked tarballs completely regardless of if they are patched or unpatched.
[18:45] <Sweetshark> infinity: right.
[18:46] <infinity> Sweetshark: Shiny.  Then yeah, not terribly difficult sounding.
[18:46] <Sweetshark> infinity: I was just hestitating to dump all the binaries in debian/ ..
[18:48] <infinity> Sweetshark: Well, you could also do it as an extra orig tarball.
[18:48] <infinity> Sweetshark: libreoffice.orig-icons.tar.gz
[18:49] <infinity> (making sure that "icons" is a unique directory name not in the source)
[18:49] <infinity> dpkg v3 format will unpack orig-$foo to $foo/ in the source.
[18:50] <Sweetshark> infinity: yeah, thats what I had before (although that was the complete theme, not only the updates) ...
[18:52] <Sweetshark> that would be 256 icons a approx. 4K each
[18:55] <ahasenack> hi guys, for a new python package for lucid, or any other distro where dh_python2 isn't available, what is recommended: python-central or python-support?
[18:56] <infinity> support, I believe, was the old new hotness before the new new hotness of dh_python2.
[18:56] <infinity> But I lose track of these things.
[18:56] <ahasenack> yeah
[18:56] <ahasenack> I used -support in two packages but hit an issue with a twisted plugin, seems I need to create a .noinit file
[18:56] <ahasenack> python-central works without this hack
[18:57] <ahasenack> funny, the README of python-support even mentions twisted as a special case, calls it broken, etc ;)
[18:57] <infinity> I won't disagree with that.
[18:57] <infinity> Twisted and I aren't really on speaking terms.
[18:57] <Sweetshark> heh, ok. the icons are ~1MB and the packaging repo for LO is >300MB -- no, I wont use a ext-tarball.
[18:58] <doko> mrpt throws in every optimization level and sees what wins ... -g -O2 ... -Os ... -g -O2 -Os ... -O3 ...
[18:58] <infinity> Sweetshark: Hrm?  Another tarball would have the same size effect as putting them in debian/, just lands them elsewhere in the source.
[18:58] <infinity> doko: Niiice.
[18:59] <doko> and then fails with
[18:59] <doko> virtual memory exhausted: Cannot allocate memory
[18:59] <doko> make[3]: *** [tests/CMakeFiles/test_mrpt_base.dir/__/libs/base/src/math/matrix_ops_unittest.cpp.o] Error 1
[18:59] <doko> we optimize our tests!
[18:59] <infinity> doko: Oh, was that the one that failed on arm after two days of grinding?
[19:00] <doko> infinity, yes. you want to fix this before giving back stuff ... imo -O2 should be fine
[19:01] <infinity> doko: It's vaguely on my post-beta radar.  Wasn't going to worry about it just now.  If you have a fix, go nuts. :P
[19:01] <infinity> I didn't even notice that was the testsuite exhausting the VM, not the actual application.  That's pretty special.
[19:01] <infinity> (well, it's g++, but I assumed it was g++ grinding on a massive cpp file that mattered, not a stupidly-written testsuite)
[19:03] <infinity> ...
[19:03] <infinity> CFLAGS="-g -O2 -Os" on the configure line?  Reall?
[19:03] <infinity> y
[19:04] <infinity> I had assumed broken build system, not broken maintainer. :P
[19:05] <infinity> And then the build system adds O3 later.  Hahaha.
[19:05] <infinity> doko: Yeah, this is special.  Thanks for the laugh.  I needed it. :)
[19:05] <debfx> ScottK: is there some documentation available on how to upgrade packages to the version from backports?
[19:06] <Sweetshark> doko, infinity: http://funroll-loops.info/
[19:08] <debfx> ScottK: and is there a bug report about packages not being able to build-dep on other packages from backports?
[19:11] <ScottK> debfx: I think so.
[19:12] <ScottK> debfx: I don't think we've done documentation on this, but it's the same as installing from a pinned repository (which we do eocument)
[19:14] <ScottK> debfx: Bug #828017 is the bug on build-deps.
[19:18] <madnick> Anyone happen to know what invokes plymouth with a prompt to remove installation media?
[19:18] <madnick> after desktop install :)
[19:19] <debfx> ScottK: thanks
[20:33] <broder> madnick: it's /etc/init.d/casper
[21:05] <madnick> broder: thanks
[22:05] <doko> I like this chromium start page ..
[22:05] <doko> Most visited:
[22:06] <doko>   lp: Oops ...
[22:30] <astraljava> Okay, I'm a bit of a newbie (although having been involved with Studio since '06) when it comes to working with bzr branches and those becoming to packages. I have mainly been working with desktop in ubuntustudio seeds. Was recently informed though that that's not what I should ask for when wanting things uploaded.
[22:30] <astraljava> ubuntustudio-meta is what needs to be uploaded.
[22:31] <astraljava> So my question really is, how does it work, so that if I upload a new commit to ubuntustudio.oneiric branch, how soon can I ask for ubuntustudio-meta to be uploaded?
[22:34] <cjwatson> astraljava: five minutes at most
[22:35] <astraljava> cjwatson: Alright, thanks (again!) :)
[22:35] <cjwatson> there's an every-five-minutes cron job that pulls to http://people.canonical.com/~ubuntu-archive/seeds/, which is where germinate-update-metapackage pulls from, which is what the ./update script in ubuntustudio-meta calls
[22:35] <cjwatson> all a developer needs to do is run ./update, review the changes, and upload
[22:36] <astraljava> Right, that's good info.
[22:36] <Daviey> cjwatson: if --bzr is used, surely it can be done straight away?
[22:38] <cjwatson> oh, yeah, that's probably true
[22:38] <cjwatson> I figure five minutes isn't worth worrying about either way :)
[22:39] <Daviey> good point.
[22:40] <infinity> astraljava: Did you need someone to do said upload for you, or is this a hypothetical situation right now? :)
[22:41] <astraljava> infinity: Colin took care of it this time. But I was advised to ask here in the future. Thanks, anyhoo! :)
[22:41] <infinity> astraljava: I saw, yes.
[22:45] <astraljava> Okay, one more question, ubuntustudio-menu has it's own branch in LP. How can we get a new .deb rolled from it? Does the feature freeze affect that now?
[22:55] <infinity> astraljava: Feature Freeze affects pretty much everything, yes, but if there's sufficient justification, exceptions can be made.
[22:56] <slangasek> in particular, the ubuntustudio team gets to tell us what is or isn't critical for ubuntustudio packages
[22:56] <slangasek> (within reason)
[22:57] <infinity> ^
[23:46] <infinity> @pilot out