[01:28] <kieppie> hi guys. I'm trying to substantiate a statement that Canonical/Ubuntu *does* contribute back to the GNU/GNOME desktop platform. is this true & are there online references I can refer to?
[01:33] <kieppie> hi guys. I'm trying to substantiate a statement that Canonical/Ubuntu *does* contribute back to the GNU/GNOME desktop platform. is this true & are there online references I can refer to?
[01:34] <spm> kieppie: http://www.markshuttleworth.com/archives/439 and links referenced within
[01:34] <kieppie> thansk
[01:37] <kieppie> spm: they. the "tribalism" article. read it & wholehartedly agree, but some feel it's not addressing the issue. one point was that canonical uses other project (GNOME desktop being the big one), but does not contribute upstream, or have people dedicated to those projects
[01:38] <kieppie> i do not agree withthat assesment, but I'd like to substantiate my viewpoint
[01:38] <spm> kieppie: this is emphatically not the channel for discussing those issues.
[01:39] <kieppie> as far as I can see, it's a developer-releated issue, so I thought I'd ask the deveopers directly, as you guys, more than anyone else, may be able to point me in the right direction
[01:41] <lifeless> ubuntu-devel-discuss@lists.ubuntu.com might be a better place
[01:42] <lifeless> this channel is very technical-content-focused, and while this is relevant to developers, its not particularly technical in nature
[01:43] <kieppie> lifeless: thanks. will pose question there
[01:43] <kieppie> bb
[03:12] <kish> sigh
[03:13] <kish> are ubuntu 10.04 iso's hybrids?
[03:13] <kish> will dd stick it to usb drives?
[03:13] <bilalakhtar> tumbleweed: You there?
[03:13] <RAOF> kish: WFM™
[03:14] <kish> What?
[03:14] <RAOF> Works For Me.
[03:14] <kish> and topc?
[03:14] <bilalakhtar> !support | kish
[03:15] <kish> #ubuntu really cant help with something this complicated
[03:15]  * RAOF waits impatiently for his btrfs-tools segfaults to move from “In Progress” so he can blow away the stupid slow filesystem.
[03:15] <bilalakhtar> kish: try it
[03:15] <bilalakhtar> !ot | RAOF
[03:16] <kish> bilalakhtar, of course, i did ;)
[03:16] <kish> anyway, i'll find a way
[03:16] <lifeless> bilalakhtar: how was RAOF's comment off topic ?
[03:16] <bilalakhtar> lifeless: it was. It said 'stupid slow'
[03:17] <bilalakhtar> lifeless: it suggests something offtopic
[03:17] <RAOF> How's this for off-topic: Yay!  dpkg finished installing the 10 new packages after only 5 minutes!
[03:17] <kish> very!
[03:17] <bilalakhtar> lifeless: this is a highly-monitored channel.
[03:17] <bilalakhtar> I suppose
[03:20] <RAOF> I think a little gentle bitching about a development filesystem in #ubuntu-devel can be useful.  When people ask “hey, should I try this shiny new btrfs option in the installer”, you can say “well, RAOF did nothing but moan about segfaulting fsck tools and abysmal performance” :)
[03:20] <StevenK> I thought that last statement was a tautology
[03:20] <StevenK> "well, RAOF did nothing but moan about segfaulting"
[03:21] <RAOF> :P
[03:21] <bilalakhtar> !language | RAOF
[03:22] <bilalakhtar> RAOF: You said 'I think a little gentle ******** about .......'
[03:23] <RAOF> I think you may have your language threshold set a little to low.
[03:24] <RAOF> s/to/too/g.  Grammar is for the weak.
[03:25] <un214> running apt-get dist-upgrade in a chroot system is a good way to brick the host
[03:26] <un214> grub-install was too dumb to figure out that / wasn't the root of a drive
[03:28] <RAOF> Anyway, bug #601874 and bug #601877 are me doing a little bit more than moaning :)
[03:29] <lifeless> RAOF: is this M onky ?
[03:29] <lifeless> s/k/l/
[03:29] <johanbr> un214, could be https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/496435
[03:30] <un214> actually not
[03:30] <un214> in this case, the correct answer was "none"
[03:30] <RAOF> lifeless: I'm not sure what you mean.  There's a bunch of stuff that's M-only that's a prerequisite for good btrfs support.
[03:30] <lifeless> RAOF: well, I have a btrfs backup drive on my lucid home serverish box
[03:31] <lifeless> RAOF: which is running quite ok :)
[03:31] <un214> FYI, I managed to write a serial startup script that puts upstart to shame
[03:31] <RAOF> lifeless: It's possible that something I've done has hit a poorly-tested path.  This laptop does a lot of power-off shutdowns.
[03:32] <lifeless> ah
[03:32] <RAOF> And since btrfsck segfaults, there's no way to repair.
[03:32] <un214> how about mounting ro and using cpio to get your files out and reformat?
[03:33] <RAOF> It's quite possible that my abysmal performance is due to a broken on-disc format.
[03:33] <RAOF> un214: I'll do that just as soon as nothing needs testing - I can't btrfs-image this filesystem either.
[03:33] <un214> dd will image it
[03:34] <RAOF> dd will image it onto your choice of 240GB discs, true.
[03:34] <lifeless> though it will keep it precisely as broken.
[03:35] <RAOF> Yeah, that's the point.
[03:35] <lifeless> hmm
[03:35] <lifeless> what does securedelete do on btrfs ?
[03:36] <un214> probably something else
[03:36] <un214> securedelete is dead on journaled filesystems
[04:03] <un214> there filed bug: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/612409
[04:09] <un214> I have this propensity for finding really obscure bugs
[04:23] <un214> I was told back in march that removing plymouth was simply a longer way to pain when I got bit by some early bugs that made it not work right (no failover for no fbcon)
[04:24] <un214> well I had to remove it in the end anyway and now anybody else who needed it has left
[04:24] <un214> so I can't get real support for removing the abomination anyway
[05:26] <TheMuso> cjwatson: I was looking at freej earlier, and tried building the synced version of freej to see if it could be synced. As you see, it FTBFs, due to the joys of xulrunner.
[05:27] <TheMuso> cjwatson: Tried to untagle whats required to work with out xulrunner to no avail so far.
[06:59] <pitti> Good morning
[06:59] <pitti> micahg: indeed, empathy FTBFSes on that, too
[07:00] <pitti> micahg: I didn't actually remove them, but I'll have a look why they disappeared
[07:00] <pitti> we should just clean the dependencies in the .la
[07:04] <pitti> apw: ah, seems we got a -14 by now
[07:04] <pitti> . o O { with a new kernel ABI each day we'll never get a working CD build }
[07:05] <ion> :-)
[07:21] <pitti> micahg: erm, do you really mean gtk+2.0? It  still ships .la files
[07:21] <pitti> micahg: you might mean libgdk-pixbuf?
[07:25]  * pitti fixes gdk-pixbuf
[07:51] <pitti> bah, it seems the lagging dpkg build causes quite some FTBFS
[08:06] <pitti> cjwatson: would you mind if I remove the upstream changelog from grub-{common,pc}? it's .5 MB for the two of them
[08:13] <pitti> ogra, lool: do you already happen to know the root cause of all the armel uninstallability? (http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html)
[08:13] <pitti> for i386/amd64 I now fixed everything but linux-backports-moudles
[08:15] <slangasek> pitti: looks like most of it is still a continuation of the kde problem we've had for a while, plus some sort of java issue?
[08:15] <slangasek> openjdk needed re-bootstrapping on armel in maverick ; I don't know whether that's done yet
[08:16] <dholbach> good morning
[08:19] <pitti> hello slangasek
[08:19] <pitti> hey dholbach
[08:20] <pitti> slangasek: ah, thanks; I just wondered about weird things like cpp-4.5-doc, which don't look very java-ish
[08:21] <bilalakhtar> dholbach: good morning
[08:21] <dholbach> hey pitti, hey bilalakhtar
[08:22] <slangasek> pitti: arch: all w/ unsatisfiable arch: any dep on gcc-4.5-base
[08:23]  * slangasek sleeps
[08:23] <pitti> ah, thanks
[08:23] <pitti> slangasek: good night!
[08:31] <bilalakhtar> ev: You there?
[09:02] <ogra> pitti, ubuntu-netbook-efl-default-settings seems to be stuck in NEW
[09:04] <ogra> pitti, kde is still not completely rebuilt openjdk wasnt bootstrapped newly on purpose yet (which holds back openoffice)
[09:04] <pitti> ogra: good morning
[09:04] <ogra> heh, and good morning indeed :)
[09:04] <pitti> ogra: ah, slangasek already followed up with why those -doc packages are uninstallable as well
[09:04] <pitti> seems like a missing gcc-4.5 bootstrap or so?
[09:05] <ogra> might be, thats linaro land
[09:06] <ogra> they do toolchain and openjdk currently, so i'll defer to lool for that, what i know for sure is that we dont want the current openjdk source to be built on armel
[09:07] <ogra> since it has a bug that makes java 5x slower, so we need to stick with the existing binary unless we want week long builds
[09:09] <pitti> cjwatson: argh, new dpkg:
[09:09] <pitti> *** buffer overflow detected ***: /usr/bin/dpkg-deb terminated
[09:09] <pitti> that's not good :-/
[09:12] <ion> If dpkg made reflinks (if supported by fs) out of duplicate files it installs (e.g. based on md5sum→filename mapping with a byte-by-byte comparison check to verify the match), it seems my server would save about 319 MB of disk space and my laptop about 703 MB.
[09:37] <pitti> ok, so this isn't ddeb specific
[09:37] <pitti> normal builds fail as well
[09:37] <pitti> so of course the fixed dpkg package will FTBFS, too
[09:38] <ion> :-)
[09:38]  * pitti stops buildds
[09:39] <pitti> all on MANUAL now
[09:41] <ion> I wish apt and dpkg used a real, indexable database. The duplicate handling (re: what i said above) would be cheap if one could just add an index for the md5sum→file mapping.
[09:43] <ion> Things like dpkg -S foo would also be faster, taking advantage of an indexed filename→package mapping. :-)
[09:56] <DktrKranz> james_w: http://blog.ganneff.de/blog/2010/08/02/removalstxt---removals822.html
[09:56] <pitti> ok, got the dpkg bug fixed
[09:56] <pitti> now I need to whack debian/rules to use the local version to actually build..
[10:14] <apw> bug #612457
[10:14] <pitti> apw: right, see /topic
[10:15] <pitti> just uploaded a fixed one, I'll handhold it through the buildds
[10:15] <apw> pitti, sorry ... was using ubbotu to get a link to the bug ... doh for doing it in here
[10:17] <ion> I have a convenient quicksearch bookmark: “lp” for https://bugs.launchpad.net/bugs/+bugs?field.searchtext=%s (so e.g. “lp 12345” works in the location bar).
[10:18] <apw> pitti, you are a stat btw :)
[10:18] <apw> star
[10:18] <pitti> stat?
[10:18] <pitti> ah :)
[10:18] <pitti> ion: "ubug" for me; those are quite handy indeed :)
[10:18] <ion> File.stat('pitti').mtime
[10:20] <apw> pitti, do you know if the PPA amd64 builders are switchable to i386?  and if so, who owns that sort of thing ... we have a major imbalance between the two in terms of queue right now, days for i386
[10:20] <pitti> apw: I suppose they are, but I can't do tha
[10:21] <pitti> apw: #soyuz perhaps?
[10:22] <ion> Theoretically, they could do both on demand.
[10:22] <pitti> ok, building everywhere, and all buildds back on manual
[10:22] <asac> mvo: apt-transport-https/0.7.26~exp12ubuntu1 -> libapt-pkg4.10   ...  but libapt-pkg4.10 doesnt exist
[10:23] <asac> e.g. our images ftb
[10:23] <asac> https://edge.launchpad.net/ubuntu/maverick/armel/apt-transport-https/0.7.26~exp12ubuntu1
[10:23] <apw> ion, yeah my thought exactly ... /me investigates
[10:24] <pitti> wahwahwah, dpkg FTBFS
[10:24] <asac> mvo: let me know how we can fix this ;)
[10:24] <asac> oh
[10:24] <mvo> asac: libapt-pkg4.10 is provided by ap
[10:24] <mvo> asac: apt
[10:24] <pitti> seems I didn't take the binary mangler into account
[10:24] <asac> mvo: well. all i see is that the images fail to build for three days ;)
[10:24] <mvo> asac: its very odd that you get 0.7.26~exp12ubuntu1 for a-t-https but not for apt
[10:24] <asac> http://snapshots.linaro.org/10.11-daily/linaro-headless/20100801/0/build-log.txt
[10:25] <asac> mvo: ^^
[10:25] <wgrant> ion, apw: The main thing holding me back from doing that is job dispatch time estimation, unfortunately.
[10:25] <asac> mvo: ah
[10:25] <wgrant> ion, apw: Everything else is done or easy.
[10:25] <mvo> asac: Setting up apt (0.7.26~exp12ubuntu1) ...
[10:25] <mvo> ERROR: Can't find the archive-keyring
[10:25] <mvo> Is the ubuntu-keyring package installed?
[10:25] <mvo> dpkg: error processing apt (--configure):
[10:25] <mvo>  subprocess installed post-installation script returned error exit status 1
[10:25] <asac> ERROR: Can't find the archive-keyring
[10:25] <mvo> asac: my mistake, I fix that
[10:25] <asac> mvo: thats interesting. we didnt change anything
[10:25] <asac> ah ok
[10:25] <mvo> asac: it should not fail because of this
[10:26] <apw> wgrant, could we perhaps give the build-admins a knob to bounce machines one way or the other ?
[10:26] <asac> cool
[10:26] <wgrant> apw: I just proposed that I merge the half of the work that lets them do exactly that.
[10:26] <apw> wgrant, as obviously to a human it is something thats calculable
[10:26] <apw> :)
[10:27] <asac> mvo: once uploaded, can you poke someone to get the upload buildscore bumped so we can rerun the image build today?
[10:27] <asac> nevermind
[10:27] <asac> builders seem to be more or less empty
[10:32] <pitti> dpkg upload, take II
[10:41] <micahg> pitti: yeah, libgdk-pixbuf since it replaced that part of gtk+2.0
[10:41] <pitti> micahg: ok, thanks for confirming; should be fixed now
[10:41] <pitti> that is, once we actually get package builds back :)
[10:42] <micahg> pitti: thanks
[10:45] <pitti> https://edge.launchpad.net/ubuntu/+source/dpkg/1.15.8.2ubuntu3
[10:46] <pitti> HAR HAR! pitti - dpkg 2:1
[10:51] <tseliot> cjwatson: I can't unsubscribe from https://lists.ubuntu.com/mailman/listinfo/lucid-changes (basically the "unsubscribe" email never arrives). Can you help me, please?
[11:10] <geser> mvo: you can close bug 611994 when you fix the keyring issue
[11:12] <mvo> geser: will do, thanks
[11:53] <pitti> ogra: is bug 600487 really in gnome-session (also?) or just in the new default-settings package, and seeds?
[11:53] <ogra> pitti, only in ubuntu-netbook
[11:54] <pitti> ogra: so the gnome-session task should be a netbook-meta task?
[11:54] <ogra> it launches, but nautilus sits on top
[11:54] <ogra> yeah
[11:54]  * ogra changes
[11:54] <ogra> heh, youre to fast
[11:55] <pitti> ogra: thanks
[11:55] <pitti> ogra: ah, now you added a task; but do we actually need to fix something in gnome-session?
[11:55] <ogra> not at all
[11:56] <ogra> should be wontfix
[11:56] <ogra> or invalid
[11:56] <pitti> ok, done
[11:56] <pitti> ogra: you could just have changed it :)
[11:56] <pitti> anyway, done now
[11:56]  * pitti looks at NEW
[11:56] <ogra> thanks
[11:59]  * pitti wonders about the slightly weird debian/rules there
[11:59] <pitti> a mere %: dh "$@" doesn't do? it just looks like boilerplate
[12:00] <ogra> i must admit i didnt touch it at all :)
[12:00] <pitti> ogra: also, can you please fix une-efl.desktop to say that it's the 2D launcher?
[12:01] <pitti> right now it looks identical to the "real" 3d netbook one
[12:01] <ogra> oh, k
[12:02] <pitti> ogra: I'll source-NEW the package now (to main), but I won't binNEW for now; this should be fixed first
[12:02] <pitti> but now you can upload a fixed version without the new queue
[12:02] <ogra> great, thanks
[12:03] <pitti> \o/ new dpkg is published
[12:03] <ogra> yay
[12:04]  * pitti tries amd64 gdk-pixbuf build
[12:13] <pitti> yay, stuff works again
[12:13]  * pitti unleashes buildds
[12:54] <SpamapS> any moderators of ubuntu-devel around? Sent a message last Thursday, still have not seen it, and it relates to things that need to be completed by FeatureFreeze this week.
[12:55] <SpamapS> sorry, Sent a message to ubuntu-devel@lists.ubuntu.com ..
[13:46] <pitti> ogra: u-n-e-d-s binNEWed to main; so you can rebuild n-meta in 1:20 ohurs
[13:46] <pitti> hours, too
[13:47] <tkamppeter> pitti, hi
[13:47] <pitti> apw: bin-NEWed -14, if you want to upload lbm and -meta soon? (armel -14 is still building, though)
[13:47] <pitti> hello tkamppeter, how are you?
[13:48] <tkamppeter> pitti, will you do the Jockey stuff for the driver download before FF/before release?
[13:48] <pitti> tkamppeter: not sure yet; as I said, I'm in the OEM team this cycle, so I dno't have a lot of platform cycles left
[13:49] <pitti> and if I do, it seems I get booked fulltime as acting RM or for SRUs..
[14:03] <tkamppeter> pitti, so Jockey is unmaintained upstream for Maverick and I should skip this over to Maverick + 1?
[14:04] <pitti> tkamppeter: we might need to defer it to N, yes
[14:04] <pitti> I do some bug fixes, but this is a major new featuer
[14:06] <tkamppeter> pitti, the problem is that Epson has made the first downloadable drivers and now they do not get used as there are no cycles to finish the development of a client.
[14:08] <tkamppeter> pitti, is it so much to fix Jockey? Jockey probably has already the capabilities to check signatures for NVidia packages and it it is probably no big deal for Jockey to look for printer drivers without checking the whole system's hardware. And I reported everything early enough in the cycle.
[14:10] <pitti> tkamppeter: no, jockey does not check any packages, apt does that
[14:10] <pitti> but apt does not have a dynamic and magic way to import gpg keys, grab them from keyrings, compare to https:// web sites, etc.
[14:10] <pitti> implementing all that is quite some work
[14:11] <pitti> well, apt can import new gpg keys, of course
[14:11] <pitti> but we shouldn't do that permanently
[14:11] <ogra> pitti, merci
[14:13] <tkamppeter> pitti, what would need to be done for implementing this? Or should we simply add Epson's key to our key collection for Maverick and then do a formal Blueprint with UDS session for automated key loading for Maverick + 1?
[14:14] <pitti> tkamppeter: we could probably ship the epson key in jockey and only accept those drivers, that's a lot less work, yes
[14:15] <tkamppeter> pitti, are these keys (like NVidia) in Jockey?
[14:16] <tkamppeter> pitti, then we must set Jockey's config to accept binary packages if the key is present and non-binaries (like Ricoh's PPDs) without key as before.
[14:16] <pitti> tkamppeter: no, nvidia is a regular ubuntu pacakge and is taken care of by apt
[14:18] <tkamppeter> pitti, OK. So let us ship the Epson key for just this one cycle and assure that Jockey finds non-binary drivers and binary drivers and accepts the latter with an existing key. Then the Epson drivers will be accepted as we ship[ their key. Automatized key loading infrastructure will then be a feauture for N.
[14:26] <apw> pitti, thanks ...
[14:30] <tkamppeter> pitti, still there?
[14:30] <pitti> yes
[14:31] <tkamppeter> pitti, what about my last suggestion?
[14:31] <pitti> tkamppeter: as I said, it's a lot less work; still nontrivial, but might be doable for M
[14:31] <tkamppeter> pitti, OK
[14:32] <tkamppeter> pitti, and is there a chance to fix the problem of Jockey checking the whole system when it get only asked for searching a printer driver?
[14:33] <pitti> tkamppeter: well, sure there is a chance -- it's a SMOP :)
[14:33] <pitti> so if anyone wants to tackle this, that's great
[14:36] <tkamppeter> pitti, SMOP?
[14:37] <pitti> simple matter of programming
[14:38] <tkamppeter> pitti, have found it, seems to be a major rewrite of Jockey, seems to be better I provide an OpenPrinter driver package search and install client as a part of OpenPrinting ...
[14:38] <tkamppeter> pitti, am I right?
[14:41] <pitti> ..
[14:42] <tkamppeter> pitti, what does this mean?
[14:42] <pitti> tkamppeter: I meant of course it is possible to fix that bug; it just needs some time to fix it
[14:44] <tkamppeter> pitti, OK. It would be great if you could solve these little problems, so that I can present results to the LF managers and the printer manufacturers, especially to get more manufacturers to package up drivers in LSB format.
[14:55] <bdrung> mvo: edit-patch lacks an non-interactive mode
[14:56] <mvo> bdrung: that is quite possible, could you please file a bug? its a pretty straightforward script, I'm happy to help with the implementation as well if you want to give it a try
[14:56] <bdrung> mvo: i want to use it in sponsor-patch (current state: http://paste.debian.net/82041/ )
[14:57] <mvo> bdrung: nice idea!
[15:01] <bdrung> mvo: filed bug #612566
[15:08] <bdrung> mvo: could edit-patch be rewritten in python? then it could be used directly by sponsor-patch
[15:08] <mvo> bdrung: I would not mind if it would be rewritten, but I don't have the time currently to do it myself
[15:09] <dholbach> I think the idea was to get it into devscripts at some stage
[15:09] <dholbach> (iirc)
[15:10] <bdrung> k, then python would be not the right way
[15:19] <cjwatson> TheMuso: yeah, I'm going to look at that some more
[15:21] <cjwatson> tseliot: what e-mail address?
[15:21] <cjwatson> SpamapS: I moderated your mail
[15:21] <tseliot> cjwatson: alberto.milone at canonical.com
[15:22] <cjwatson> tseliot: you're not subscribed to lucid-changes with that address
[15:22] <cjwatson> tseliot: albertomilone at gmail.com is subscribed
[15:22] <tseliot> cjwatson: yes, that's the one
[15:22] <tseliot> sorry
[15:23] <cjwatson> tseliot: unsubscribed
[15:23] <tseliot> cjwatson: thanks a lot
[15:31] <ttx> I'd need some AA love on this sync request, it blocks one of my specs for alpha-3 completion: bug 612124
[15:51] <cjwatson> ttx: done
[15:59] <sense> Is there a good guide for editing a debian directory that is in an Ubuntu Bazaar branch with help from the apt-get source sources?
[16:00] <pitti> sense: https://wiki.ubuntu.com/DesktopTeam/Bzr is the guide for the desktop team, but it's not really desktop specific
[16:00] <sense> pitti: Thanks a lot!
[16:00] <pitti> sense: but apt-get source is neither useful nor helpful there
[16:01] <pitti> sense: we use bzr-buildpackage, which provides quite a nice and easy workflow
[16:01] <ttx> cjwatson: great, thx !
[16:01] <pitti> bzr-builddeb even
[16:02] <sense> pitti: OK, thanks
[16:02] <cjwatson> sense: try https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[16:03] <sense> cjwatson: Ah, of course, that documentation! I had completely forgot about it.
[16:04] <pitti> sense: the difference between those is whether you have a package with an implicit auto-import branch (lp:ubuntu/pkgname) or an explicitly maintained debian/ only branch (Vcs-Bzr:)
[16:05] <sense> pitti: gtk+2.0, more than just the debian direcotry
[16:05] <pitti> Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntu
[16:05] <pitti> sense: you want the first link then
[16:05] <sense> pitti: Isn't that equal to lp:ubuntu/gtk+2.0?
[16:05] <pitti> sense: no, it's not
[16:05] <sense> ah
[16:05] <sense> ok, thanks!
[16:05] <pitti> if a source package has a Vcs-Bzr: tag, then that is the definitive branch
[16:06] <pitti> the auto-import is not used
[16:06] <sense> I see.
[16:06] <pitti> sense: admittedly this is rather confusing
[16:06] <sense> A bit indeed. :)
[16:06] <pitti> unfortunately there is no real way to mark those auto-imports as "please don't use"
[16:06] <pitti> (or I'm not aware of it)
[16:06] <sense> Branch status?
[16:07] <pitti> sense: these are owned by the importer, and bzr get doesn't tell you the status anyway
[16:07] <sense> That's true.
[16:07] <pitti> it would be great if lp:ubuntu/gtk+2.0 could somehow point to the actually used branch
[16:07] <pitti> but well, not quite there yet :)
[16:08] <sense> Rome wasn't built in one day, shall we say? ;)
[16:08] <pitti> apw: do you plan to have the -14 kernel in alpha-3?
[16:08] <pitti> sense: and neither cathedrals and bazaars
[16:09] <sense> nope
[16:11] <Laney> pitti: I thought you could have that happen (redirecting the ubuntu/* branches)
[16:16] <pitti> Laney: somehow it's possible, but (1) it's nontrivial even for full-source branches (e. g. apport), and (2) I was told we shouldn't have debian/ only branches in those lp:ubuntu/ ones
[16:16] <Laney> hm, alright
[16:16] <Laney> maybe it would be good to be able to make them read-only or have a warning when they are branched
[16:17] <asac> mvo: apt uploaded already?
[16:17] <asac> ah seems something went up. thx
[16:24] <bdrung> pitti: what do you think about having a dh_apporthook command for installing apport hooks?
[16:40] <mvo> asac: uploaded a couple of hours ago
[16:40] <asac> mvo: yep. saw that. i am waiting for results from image build atm
[16:40] <asac> let me see
[16:41] <asac> seems fine. thanks mvo!
[17:11] <SpamapS> cjwatson: thank you. :)
[17:47] <SpamapS> hrm.. when building a package, doesn't dpkg-source ignore the top level directory from the orig tarball?
[17:53] <cjwatson> mvo: does http://paste.ubuntu.com/472273/ look right to you?  apt-cdrom always fails right now
[17:54] <cjwatson> (because it drops one too many characters from the end of the binary-* directory name)
[18:07] <SpamapS> http://paste.ubuntu.com/472278/
[18:08] <SpamapS> Very confusing..
[18:08] <SpamapS> does the .orig tar ball have to match the name of the source package?
[18:08]  * SpamapS wonders if he's just always accidentally gotten this right
[18:09] <cjwatson> wow, running apt-cdrom replaces /dev/null with a regular file
[18:11] <cjwatson> SpamapS: the filename of the tarball must match; the contents only have to be all under one directory, but the name of that directory doesn't matter
[18:14] <SpamapS> cjwatson: I'm a bit confused by the output of dpkg-source (see paste link above) then.
[18:14] <SpamapS> cjwatson: if I recreate the .orig.tar.gz to have its first level dir be php-gearman-0.7.0 .. the package is built as I would expect.
[18:15] <cjwatson> can I download your original .orig.tar.gz somewhere?
[18:15] <cjwatson> I mean, it looks from that paste as if it has some stuff at the top level
[18:16] <cjwatson> so repacking it is probably reasonable anyway
[18:16] <SpamapS> cjwatson: the upstream tarball is http://pecl.php.net/get/gearman-0.7.0.tgz
[18:16] <cjwatson> it's probably just getting confused by the file at the top level
[18:16] <cjwatson> repack and move on :)
[18:16] <cjwatson> (package.xml)
[18:17] <SpamapS> oooohhhhhh
[18:17] <SpamapS> thank you for lending me your eyes for a bit.. ;)
[18:17] <cjwatson> oh, wow, apt-cdrom has had this bug forever
[18:18] <SpamapS> cjwatson: its a feature... turns the bit bucket into a recycle bin. ;)
[18:33] <mvo> cjwatson: hi, thanks for the apt-cdrom fix, I assume its a very recent regression (by the latest apt upload)?
[19:01] <cjwatson> mvo: can't tell quite how recent, though bzr blame suggests it's part of the multiarch changes
[19:31] <JamesWstubbs91> Hello, I asked this question in #Ubuntu and wasn't able to get a response, I guess it's kind of relevant for development, I'm doing an iPhone port of Karmic, I have X11 fully up and running with wifi and a ssh connection, I can use the touchscreen using the "evdev" driver which works perfectly in a landscape orientation, I'm working on making it landscape for screen space, I've swapped the axes and invert the y axis so
[19:31] <JamesWstubbs91> But now the top part of the screen is unaccesable by the mouse
[19:31] <JamesWstubbs91> Is there a tool to calibrate the evdev driver for touchscreens?
[19:31] <JamesWstubbs91> Any help's appreciated
[19:31] <rsavoye> I had the same problem this week :-(
[19:32] <JamesWstubbs91> I meant evdev works perfectly in a portrait orientation.
[19:32] <JamesWstubbs91> Hm, I tried switching my MaxX and Maxy round, didn't make a difference
[19:32] <rsavoye> I added full touchscreen support,m only to find I can't calibrate under GNOME
[19:32] <JamesWstubbs91> Option "Calibrate" in xorg.conf doesn't do much
[19:32] <micahg> JamesWstubbs91: if no one answers, you can try #ubuntu-x
[19:33] <JamesWstubbs91> I'll join the channel now
[19:35] <lool> pitti, ogra: Hey; I'm in NY for debconf, were the installability issue solved?
[19:37] <lool> pitti: Did you find the patch for dpkg I worked on with Reinhard yesterday?
[19:37] <lool> I see you did
[19:45] <mvo> cjwatson: shall I do the apt upload with the apt-cdrom change? or do you want to do it (I'm fine uploading, unless you have everything prepared already etc :)
[19:45] <lool> pitti: BTW, I made a point here that we would have catched that with -fstack-protector in Debian   ;-)  dpkg would just produce corrupted .debs instead on some arches!!
[19:47] <pitti> bdrung: cjwatson added a dh-apport package the other day with exactly that :)
[19:47] <pitti> lool: dpkg patch> yes, I found it
[19:48] <pitti> lool: in fact, I had my own patch after 1 min of debugging :)
[19:48] <pitti> but I took upstream's, since htat was a tad nicer
[19:48] <pitti> lool: enjoy debconf!
[19:48] <lool> pitti: I was really happy that we have -fstack-protector
[19:48] <pitti> yes, it's great
[19:49] <pitti> a solid crash was very obvious :)
[19:49] <lool> pitti: You should offer the PATH change upstream though, I don't think we do that in Debian
[19:49] <pitti> lool: it was only meant for this one upload
[19:49] <pitti> since otherwise it would have FTBFSed
[19:49] <lool> pitti: Hmm ok, I found it not a bad idea
[19:49] <pitti> we were going to ditch it again on the next one
[19:49] <pitti> lool: yeah, maybe; more dogfooding
[19:49] <pitti> the previous (broken) dpkg would have FTBFSed right away
[19:56] <cjwatson> mvo: if you could, that would be great
[19:58] <mvo> cjwatson: sure thing, thanks for the fix!
[20:49]  * Keybuk shakes his fist at pitti
[20:52] <Keybuk> pm-utils now mucks around with readahead settings
[21:36] <ResQue> Hello people
[21:36] <ResQue> hello freddy
[21:37] <ResQue> is there a channel for developer who like to develop apps for ubuntu, rather than the development of ubuntu
[21:37] <micahg> ResQue: #ubuntu-app-devel ?
[21:37] <ResQue> micahg:  thanks
[21:38] <ResQue> freddy_: you want the room micahg just mentioned
[21:51] <SpamapS> mathiaz: ping!
[21:51] <mathiaz> SpamapS: o/
[21:51] <SpamapS> mathiaz: I don't think CEPH is going to make it into Debian by FF
[21:51] <mathiaz> SpamapS: agreed
[21:51] <mathiaz> SpamapS: I've seen the comment from the merge proposal
[21:52] <mathiaz> SpamapS: it seems that upstream is responsive
[21:52] <SpamapS> mathiaz: very
[21:52] <mathiaz> SpamapS: for now the plan I'd suggest that we don't wait for Debian
[21:52] <SpamapS> mathiaz: Sage is quite excited to see ceph get out there and is hoping this will provide the testing that it needs to stabilize
[21:52] <mathiaz> SpamapS: and instead upload ceph to Ubuntu in time for Feature Freeze
[21:53] <mathiaz> SpamapS: is the bzr branch up-to-date wrt to the new usptream changes?
[21:53] <mathiaz> SpamapS: IIUC Sage made some changes in the packaging branch as well
[21:53] <SpamapS> mathiaz: no, I was going to ask you if you wanted me to merge his last few changes
[21:53] <mathiaz> SpamapS: seems like a good plan
[21:54] <mathiaz> SpamapS: given that he pushed fixes based on the feedback
[21:55] <SpamapS> indeed
[22:02] <SpamapS> mathiaz: /win 3
[22:02] <SpamapS> bllaha
[22:03]  * SpamapS must really write a script to stop that
[22:03] <mathiaz> SpamapS: at least you're not doing /win 124
[22:03] <SpamapS> mathiaz: anyway, I'm pulling down his git repository now, will merge and push as necessary
[22:03] <mathiaz> SpamapS: great - thanks!
[22:03] <SpamapS> mathiaz: of course not, the people in window 124 are boooring
[22:04] <mathiaz> SpamapS: well - I'm not sure I'd see the value of having *124* windows opened
[22:06] <SpamapS> $ bzr branch git://ceph.newdream.net/git/ceph.git
[22:06] <SpamapS> | fetching revisions 6594/10811
[22:06] <SpamapS> oi.. this has my laptop's fan spinning pretty hard. ;)
[22:15] <bdrung> pitti: great, but it will lead to to a debian -> ubuntu diff.
[22:17] <jelmer> bdrung: Hi, thanks for looking at those sync requests.
[22:18] <bdrung> jelmer: np
[22:19] <bdrung> jelmer: sync requests are the first priority in the sponsors queue
[22:23] <SpamapS> mathiaz: absent any more issues, can you upload the package that is in that branch?
[22:24] <mathiaz> SpamapS: I plan to have a second round of review
[22:24] <mathiaz> SpamapS: I usually stop my review after outlining a few things
[22:24] <mathiaz> SpamapS: in order to not come up with a long landry list of things to fix
[22:24] <mathiaz> SpamapS: and I get tired of reviewing the package after some time as well
[22:25] <mathiaz> SpamapS: it may well be that the package would be ready for upload this time around
[22:25] <SpamapS> mathiaz: I will cross my fingers then. :)
[22:25] <SpamapS> mathiaz: did you see my message from Hung?
[22:25] <mathiaz> SpamapS: yes
[22:28] <SpamapS> mathiaz: can you also give some attention to this one when you have some time? https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/rrdtool/merge-1.4.3-1/+merge/30675
[22:28] <mathiaz> SpamapS: sure - review claimed
[22:30] <SpamapS> mathiaz: ty.
[23:14] <pitti> bdrung: hm?
[23:15] <bdrung> pitti: on debian dh-apport does not exits. so how can i keep the debian and ubuntu package in sync if it contains an apport hook?
[23:16] <pitti> bdrung: conditionally install it in debian/rules, that's what I do for my packages (udisks, etc.)
[23:16] <Laney> yes, guard your call to dh-apport by dpkg-vendor
[23:16] <pitti> bdrung: http://git.debian.org/?p=pkg-utopia/udisks.git;a=commitdiff;h=a9ddc5bb660a4f53c2533c8e154159dfcdd94519
[23:17] <pitti> but dpkg-vendor is a bit more modern indeed
[23:17] <bdrung> but then there is still the build dependency
[23:17] <pitti> bdrung: you don't need a build dependency to install file?
[23:17] <bdrung> then i can't use dh_apport
[23:18] <pitti> right, what I said; use debian/rules
[23:18] <bdrung> ok
[23:18] <bdrung> and dpkg-vendor!
[23:18] <pitti> :)
[23:18] <Laney> bdrung: you can use dpkg-gencontrol to replace ubuntu specific substvars if you want
[23:18] <Laney> in combination with dpkg-vencor
[23:18] <Laney> dpkg-vendor
[23:18] <pitti> doesn't work for build depends, though
[23:19] <Laney> oh, yeah
[23:27] <Laney> couldn't dh_apport just be added to the default debhelper sequence on Ubuntu?
[23:27] <Laney> or does it bring in a long chain of depends?
[23:29] <Laney> no, in fact it does not
[23:33] <ajmitch> it'd be good to just have apport in debian, though I don't know if having it optionally file bugs to the BTS would be useful there
[23:34] <Laney> cjwatson: what do you think to ^^^? (I see you wrote dh_apport)
[23:34] <ajmitch> there's an ITP open for apport, but no action on it for the last year or so
[23:35] <Laney> I imagine it would require quite some engineering
[23:35] <ajmitch> the retracing part would, since there aren't currently debug packages, unless that gsoc work has been put in place
[23:38] <cjwatson> Laney: I don't want to change debhelper defaults - joeyh tends to get unhappy when we do that.  I'd rather leave it as a sequence extension
[23:40] <Laney> OK, just thinking how to reduce deltas, but it's no big deal