[00:02] <asac> kees: i guess when getting somethign like this http://paste.ubuntu.com/337657/ adding -fPIC is to easy to be the right answer?
[00:02] <asac> thats on armel
[00:02] <kees> james_w: cool, thanks
[00:03] <asac> too easy
[00:03] <asac> a bit more context: http://paste.ubuntu.com/337658/
[00:03] <kees> asac: yeah, all libs should be -fPIC
[00:04] <asac> kees: hmm. so atm this seems to not use -fPIC on i386/amd64
[00:04] <asac> but still works
[00:04] <asac> at least builds
[00:04] <asac> so using fPIC everywhere is better?
[00:06] <mjr> I didn't think non-pic .sos worked on amd64 either
[00:06] <asac> let me check the build log for amd64
[00:07] <asac> right. its used there
[00:08] <mjr> (one would think it would be prudent on i386 as well, but what do I know)
[00:09] <kees> asac: hrm, so, the problem is that it lacks -fPIC when doing the .so build, for sure
[00:09] <kees> I can't say that's is best to _always_ build -fPIC, but usually you'll want it.
[00:10] <asac> thx. thats good enough
[00:10] <asac> its probably a build system issue
[00:10] <kees> the line that starts:  gcc -shared -Wl,-soname,libavutil.so.50
[00:10] <kees> is using .o's that weren't -fPIC compiled.
[00:10] <asac> yes
[00:10] <asac> thats the point. it doesnt ad fPIC at all on armel and i386
[00:10] <asac> add -fPIC
[00:10] <kees> it's just that due to the stack-protector symbol, it's showing up quickly.
[00:11] <kees> that's ... odd
[00:11] <asac> right. just wanted to check back if thats something broken because of armel
[00:11] <asac> kees: its a non autotools build system (e.g. manual configure + Makefile) ... so its not really shocking ;)
[00:11] <kees> heh, ok
[00:18] <kees> james_w: hrm, smarty melted down on the merge.  got confused by a remove/add it looks like and claimed conflicts that aren't really conflicts.
[00:19] <slangasek> james_w: ^^ the merge-package "upstream branches have diverged" OMG failure
[00:20] <james_w> what? it's just a full and clear exception message! :-)
[00:20] <slangasek> yes, I was just clarifying "melted down" :)
[00:21] <slangasek> james_w: the /problem/ is that the branches seem to think that the misc/ and unit_test/ subdirs are complete removals & re-additions, which is a bit of a suboptimal merge :)
[00:25] <nhandler> mdz: Are you planning on sending out an email about http://mdzlog.alcor.net/2009/12/08/call-for-nominations-ubuntu-developer-membership-board/ ? The post is also missing some information (such as a timeline for the election, what team will be able to vote, is it really 100% open to anyone to run?, etc)
[00:32] <mdz> nhandler, I sent email to ubuntu-devel-announce, though maybe it hasn't been moderated yet
[00:33] <mdz> nhandler, the timeline I'll pattern after the TB election, and yes, it's open (I thought that was clear from the text)
[00:34] <nhandler> mdz: It said it was open, but iirc, most of the other council elections had some type of basic requirement (i.e. must be an Ubuntu member or Ubuntu developer), so I wanted to make sure
[00:35] <mdz> nhandler, it seems unlikely that someone with no experience as an ubuntu developer would qualify, but I saw no reason to exclude anyone out of hand
[00:40] <james_w> kees/slangasek: I've no idea why that conflicts, I'm asking in #bzr
[00:40] <slangasek> ok :)
[03:02] <jennie> Hello
[03:02] <jennie> I need assistance
[03:05] <micahg> jennie: #ubuntu is for support, this channel is for development discussion
[03:06] <jennie> micahg , i need a simple help , please help me its related to printer installation
[03:07] <syn-ack> erg
[03:07] <syn-ack> jennie, then you need to go to #ubuntu, please
[03:50] <LucidFox> Hmm, Thunderbird 3 is out.
[03:51] <micahg> LucidFox: indeed
[03:51] <LucidFox> micahg, perhaps it would make sense to replace rc3 in your PPA? :)
[03:51] <micahg> LucidFox: rc3 is the release version
[03:52] <micahg> LucidFox: when there's an official .orig.tar.gz, I'll think about fixing it
[03:53]  * LucidFox nods
[03:53] <micahg> but that is the actual release code though, just not branded or versioned properly
[03:54] <LucidFox> I actually believe Mozilla versions RCs without any mention of them being RCs in the about dialog. RC3 for Firefox 2.0 and 3.0 was byte-for-byte identical to the final release.
[03:55] <LucidFox> Ah, your version is still branded Shredder. :(
[03:55] <micahg> LucidFox: right :)
[03:56] <syn-ack> Hey anyone know if we're gonna have a 64 bit compatible version of Enigmail anytime soon?
[03:56] <syn-ack> If not, I suppose I could look into it
[03:56] <micahg> syn-ack: well, that depends on how much free time I have :)
[03:57] <syn-ack> hah
[03:57] <syn-ack> no way
[03:57]  * micahg needs it as well and is part of the mozilla team :)
[03:57] <syn-ack> heh
[03:57] <syn-ack> How about that. :P
[04:58] <ScottK> StevenK: On the off chance you're awake and willing to help me out, plasma-desktop should have been accepted into Main, not Universe (it's split out of two Main packages).  I've fixed the seeds, would you please promote it.
[05:07] <StevenK> ScottK: Looking.
[05:08] <ScottK> StevenK: Thanks.
[05:09] <StevenK> ScottK: Which source package builds it?
[05:09] <ScottK> StevenK: kdebase-workspace
[05:11] <StevenK> ScottK: Done.
[05:11] <ScottK> StevenK: Thanks.
[05:35] <pitti> Good morning
[05:36] <pitti> Keybuk: resume straight away> oh, nice! haven't noticed that yet
[06:05] <lwb> anyone please?
[06:08] <ScottK> lwb: Help is in #ubuntu.
[06:34] <syn-ack> Anyone care to test an apparmor script I just got working for skype?
[06:41] <LLStarks> hey keybuk, what's that new kernel in boot staging do?
[06:41] <LLStarks> *what does that
[06:47] <LucidFox> Riddell> So the Kubuntu Karmic final release uses Konqueror rather than Arora by default after all. When was the decision to revert made?
[06:47] <LucidFox> (I'm not disputing it, just curious)
[06:51] <CptHowdy> can someone help me build ati drivers from src?
[06:52] <CptHowdy> #ubuntu = no luck . . . #debian = got threatened
[07:11] <LucidFox> CptHowdy> Threatened
[07:11] <LucidFox> ?
[07:13] <RAOF> I'd guess "strongly suggested to ask elsewhere".
[07:15] <Darko> ... and "ubuntu has been a bloated peice of trash since ... "
[07:16] <Darko> actual quote btw
[07:16] <Tm_T> yay for alpha 1
[07:19] <LucidFox> Darko> From Debian developers?
[07:19] <Darko> not sure, probably not though
[07:20] <Tm_T> I'm not sure if you should discuss about that here anyway (:
[08:02] <dholbach> good morning
[08:02] <mvo> hey dholbach!
[08:03] <dholbach> hey mvo
[08:26] <pitti> ScottK, Riddell: any idea about http://launchpadlibrarian.net/36614923/buildlog_ubuntu-lucid-i386.compiz_1%3A0.8.4-0ubuntu7_FAILEDTOBUILD.txt.gz ? Did KWD::Window change recently?
[08:27] <pitti> (I need to rebuild compiz to make it installable for alpha-1)
[08:51] <geser> pitti: Hi, any idea why pkgbinarymangler couldn't find DEBIAN/control? http://launchpadlibrarian.net/36598521/buildlog_ubuntu-lucid-i386.stx-btree_0.8.3-1_FAILEDTOBUILD.txt.gz
[08:51] <geser> I tried it in my lucid pbuilder where it succeeds but on the buildd it failed again
[08:57] <lool> geser: Looks like the build is happening in parallel though
[08:57] <lool> geser: You have two dh_prep calls which might be called one after the other
[08:58] <lool> geser: e.g. dh_prep (install-indep), make install (install-indep), dh_prep (cleans up), dh_install (binary-indep) => boom
[09:00] <lool> geser: One way around it is to change MAKE instead of MAKEFLAGS until your rules are -j safe
[09:06] <dholbach> james_w: I reviewed a bunch of merge proposals! it was fun! :)
[09:07] <dholbach> james_w: now I just need a programmatic way to get them from LP onto the sponsoring overview :)
[09:19]  * pitti eyes component-mismatches
[09:19] <pitti>  o pmount: pmount
[09:19] <pitti>    [Reverse-Recommends: kdebase-runtime]
[09:19] <pitti> o_O
[09:20] <pitti> Riddell: going back to the old times? :-)
[09:23] <directhex> pitti, just wait for him to upload MAKEDEV!
[10:15] <free> mvo: hi again! :)
[10:16] <free> mvo: I've noticed a little difference between the hardy section of the meta-release and meta-release-lts files published under changelogs.ubuntu.com
[10:17] <free> mvo: the upgrade tool for hardy in meta-release points to version 0.87.30, while meta-release-lts points to 0.87.31
[10:17] <free> mvo: is there some specific reason for that?
[10:20] <mdz> pitti, I had an X server crash last night, and apport failed to capture it due to: ValueError: Invalid process ID: [Errno 2] No such file or directory: '/proc/1167'
[10:21] <free> mvo: incidentaly that appears the reason for the APT fetch errors I reported you last week, version 0.87.30 fails, while 0.87.31 is fine
[10:21] <mvo> free: the explicit version numbers are workaround for a soyuz bug, it does not deal with copying the stuff from -proposed to -updates (there is a bug about that)
[10:22] <mvo> free: oh? let me check
[10:22] <pitti> mdz: current x server has the apport patch disabled, I think; It still needs to be ported to the current version
[10:22] <pitti>   * 135_rethrow_signals.patch, 168_glibc_trace_to_stderr.patch:
[10:22] <free> mvo: yeah, the point is that the two versions published are different, I'm wondering if it's on purpose
[10:22] <pitti>     Disabled until fixed to work with the current version.
[10:23] <free> mvo: in my tests the Landsacpe server is passing the landscape client the .30, hence the failures
[10:24] <mdz> pitti, oh, hmm. I thought without the patch, apport would never see it at all because the signal was caught
[10:24] <pitti> that's what I had expected
[10:24] <pitti> it seems that the process went away while it was still dumping core, which seems odd
[10:25] <mdz> bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/xorg-server": xorg-server in ubuntu has no default branch.
[10:25] <mdz> :-(
[10:25] <mdz> james_w, ^
[10:26] <mvo> free: so for lts-upgrades you should always use the meta-release-lts file, as for the bug, I'm not sure, 0.87.31 is a no-change upload according to the changelog
[10:26] <mvo> free: I need to diff the actual files
[10:29] <free> mvo: so, okay, between two lts releases I should use meta-release-lts
[10:30] <mdz> pitti, shouldn't we open bugs when we disable patches like this, so that they aren't forgotten entirely?
[10:30] <free> mvo: what about between a non-lts and an lts? like from karmic to lucid
[10:30] <free> mvo: supposing lucid is out already
[10:30] <ogra_> hmm, i see gnome-python-desktop_2.28.0-0ubuntu2 built on all arches ... i dont get why the source isnt published at all yet
[10:30] <free> mvo: should you use the upgrade tool url in meta-release or meta-release-lts in that case?
[10:31] <tjaalton> mdz: they aren't forgotten
[10:31] <pitti> tjaalton: ^ is re-enabling 135_rethrow_signals.patch in xorg-server on some radar? (like mdz's bug opening suggestion)
[10:31] <mvo> free: it depends on what the user wants. by default on a lts we make it look at lts versions, that is configured in /etc/update-manager/release-upgrades
[10:31] <tjaalton> pitti: bryce said he'd look at it after his vacation
[10:31] <free> mvo: yes, I know about it
[10:31] <mvo> free: maybe it would be best to just use the code from u-m (metarelease.py) in landscape too?
[10:32] <free> mvo: so it's really a user conf
[10:32] <tjaalton> pitti: I understood that apport was still disabled anyway
[10:32] <mvo> free: than we can be sure its behaving the same
[10:32] <pitti> tjaalton: it is
[10:32] <mvo> free: yeah, user/admin choice, on lts we default to lts->lts, but if the user wants he is free to go from lts->non-lts of curse
[10:32] <free> mvo: the thing is that we would like to be able to specify the target release from the web ui
[10:33] <mdz> tjaalton, it's disabled by default, but those of us who have crashes will turn it on to capture a report
[10:33] <free> mvo: without having to modify /etc/update-manager/release-upgrades
[10:34] <mvo> free: I see. you could subclass MetaReleaseCore and override CONF I guess, sorry that there is no nicer mechanism at this point
[10:35] <tjaalton> mdz: git clone, btw ;)
[10:38] <mvo> free: I found the bug btw, but it can really only be triggered by someone doing a dapper->hardy upgrade with the version in meta-release (and not -lts)
[10:38] <free> mvo: yeah, in all other cases it works indeed
[10:38]  * mvo scratches his head
[10:38] <free> mvo: it's the only case I'm having problems with, but know it's clear why :)
[10:39] <mvo> free: :) I can make changes the the MetaReleaseCore api so that it is easier for you to point it to a different conf or force a specific behavior (if that helps you)
[10:39] <pitti> geser: hm, seems the package is building in parallel on the buildds
[10:40] <free> mvo: thanks, in the long run it would be probably nice to have do-release-upgrade flexible enough to be driven from the outside
[10:41] <mvo> free: right, if all you need is override of the "release-upgrades" conf via a commandline, that can be done easily
[10:43] <free> mvo: yeah, that would do it, I guess
[10:44] <free> mvo: it's not at all urgent though, maybe we can switch to that in the long run, to avoid SRU's for this
[10:48] <mvo> ok
[10:49] <free> mvo: just one more thing about this specifc issue
[10:50] <free> mvo: in general is it common that the urls of the upgrade tool for lts and non-lts are different? in the meta-release-lts and meta-release files
[10:51] <free> mvo: or is it only in this specific case due to a bug in soyuz?
[10:51] <mvo> free: no, it should not happen, they basicly should point to lucid-updates/main/dist-upgrade-all/current, its there because of the soyuz issue
[10:52] <free> mvo: okay, thank you
[10:52] <mvo> thanks
[10:52] <mvo> free: what what might happen is that that -lts file is updated a bit later to give us extra time for testing the lts->lts upgrade path
[10:54] <dholbach> can anybody give me some feedback on http://people.canonical.com/~dholbach/cheatsheet.jpg and say if I forgot anything? (still in the brainstorming phase :))
[10:55] <free> mvo: okay
[11:23] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/dpkg-cross/crossbuild>$ bzr import-dsc ../dpkg-cross_2.5.2ubuntu2~cross*.dsc
[11:23] <cjwatson> bzr: ERROR: Unable to find the tag for the previous upstream version, 2.5.2ubuntu1, in the branch: upstream-2.5.2ubuntu1
[11:24] <cjwatson> james_w: ^- how do I tell import-dsc that this is a native package and it shouldn't go looking for upstream- tags?
[11:25] <james_w> cjwatson: that may well be a bug
[11:25] <james_w> Steve reported something similar
[11:25] <james_w> I thought it was handled, but obviously not
[11:25] <cjwatson> I'll go report it then
[11:26] <james_w> thanks
[11:27] <james_w> the -Derror trace would be useful
[11:27] <james_w> (debug flag to always print tracebacks for exceptions)
[11:30] <cjwatson> james_w: cool; added
[11:30] <james_w> thanks
[11:30] <cjwatson> maybe just needs 'if config.native:'
[11:30] <cjwatson> ?
[11:31] <cjwatson> well, 'if not'
[11:32] <cjwatson> hmm, now I have Unicode trouble with lool's name
[11:33] <ScottK> pitti: I have not looked at the code (re compiz/kde), but we just switched from KDE 4.3 to the 4.4 beta, so I wouldn't be suprised if it had changed.
[11:33] <pitti> ScottK: I hit it over the head now, it builds now
[11:34] <ScottK> OK.  Good.
[12:17] <dnivra_> I downloaded the source of gedit 2.29 from launchpad. However the source and diff files were downloaded separately. How do I apply the diff to the original?
[12:17] <pitti> dnivra_: you need the .dsc, and then use dpkg-source -x foo.dsc
[12:17] <pitti> dnivra_: but that's not the usual way, you usually just do "apt-get source packagename"
[12:21] <ev> we don't have any way of doing translucent overlays in lucid, do we?  That is, I want to be able to mount A over B, and I want the files in B that aren't present in A to show through.
[12:21] <ogra> ev, aufs ?
[12:22] <pitti> that would stretch the "everything is a file" principle veeery far :)
[12:22] <ogra> (wouldnt be an pverlay but a union mount indeed)
[12:22] <ogra> *over
[12:22] <pitti> oh, ignore me; I misread
[12:23] <pitti> sounds pretty much what aufs does on the live system indeed?
[12:23] <pitti> ev: but I wouldn't recommend that for production use
[12:23] <ev> indeed, that slipped my mind
[12:23] <pitti> I think there's a way to do it with LVM, though
[12:23] <pitti> Fedora live systems work like that
[12:23] <ev> pitti: this is simply to save me the work of tons of NFS mounts
[12:24] <ev> in development on the live CD
[12:24] <dnivra_> pitti: but the current repository is karmic's and i want the lucid development package. thanks
[12:24] <pitti> dnivra_: (you can add deb-src for lucid)
[12:24] <dnivra_> pitti: true
[12:24]  * dnivra_ didn't think of that
[12:33] <doko__> does dpkg already support xz?
[12:34] <Tm_T> xz?
[12:34] <ScottK> I think it doesn't.
[12:35] <cjwatson> not yet in lucid, although I think it probably will in the lucid cycle; the work's done upstream
[12:35] <mjr> Tm_T, lzma-utils's slightly more generic continuation
[12:35] <ogra> me is scared
[12:35] <Tm_T> mjr: ah, thanks
[12:35] <mjr> provides for unpacking the old lzma format
[12:35] <cjwatson> although that would require another rev of the dpkg code used by LP, so maybe not. don't bank on it
[12:36] <mjr> (possibly also compression for now, not sure)
[12:38] <ScottK> mjr: It does.  KDE uses xz for all it's lzma support.
[13:01] <lool> I uploaded a fixed maximus since it was missing a Provide causing compiz to appear in the ubuntu-netbook-remix task
[13:20] <tkamppeter> pitti, seb128, there is a problem with Lucid's Poppler.
[13:20] <pitti> tkamppeter: ?
[13:21] <pitti> tkamppeter: if you ask because of cups trunk FTBFSing, that's know
[13:21] <pitti> n
[13:21] <pitti> Debian reverted an upstream API/ABI change
[13:21] <pitti> so we can't build current cups trunk in lucid
[13:21] <pitti> that needs some h4ck3ry again
[13:22] <tkamppeter> pitti, seb128, according to debian/changelog our Poppler is 0.12.2-2.1ubuntu1, but it doews not contain the patches of Debian's 0.12.2-2.
[13:22] <pitti> tkamppeter: right, the version number is screwed up
[13:22] <tkamppeter> I cannot find the files 01_revert_abi_change.patch and 02_autohinting_abi_compatibility.patch in our Poppler.
[13:22] <pitti> it should have been 0.12.2-0ubuntu1
[13:22] <pitti> tkamppeter: we dno't want 01_revert_abi_change.patch
[13:23] <tkamppeter> And Debian's ChangeLog entries of 0.12.2-1 and 0.12.2-2 are also missing.
[13:23] <tkamppeter> pitti, what is wrong with 01_revert_abi_change.patch?
[13:24] <seb128> it reverts upstream abi
[13:24] <seb128> there is no reason to be api incompatible with upstream
[13:25] <pitti> tkamppeter: there's a patch in bzr history which was reverted again which makes it build with our poppler
[13:26] <tkamppeter> pitti, CUPS I have now synced to the upstream version of the PDF filters, this works with both ABI versions of Poppler, but it requires that CUPS is run with the ABI version of Poppler with which it got compiled.
[13:26] <pitti> nice
[13:26] <pitti> tkamppeter: sure, we can take that for granted
[13:27] <tkamppeter> Koji Otani, upstream developer of pdftopdf has made this final patch.
[13:28] <tkamppeter> pitti, seb128, I have built our current version of Poppler locally, installed it, and then built CUPS. According to config.h our Poppler has the new, accidentally introduced ABI.
[13:28] <pitti> mr_pouit, cody-somerville: can you please unseed gnome-games and seed the selection that we have in ubuntu-desktop? that should make xubuntu installable again
[13:28] <pitti> are you interested in xubuntu alpha-1 at all?
[13:29] <tkamppeter> We should have a Poppler which has the ABI which is official by Poppler upstream.
[13:29] <pitti> i. e. should we put some effort into getting buildable CDs?
[13:29] <pitti> tkamppeter: so the situation is that the poppler API/ABI was officially broken (without bumping soname)
[13:29] <pitti> tkamppeter: so the current lucid abi is the upstream abi
[13:30] <pitti> it was just reverted in Debian to not delay the huge testing transition even more
[13:30] <tkamppeter> pitti, seb128, so Ubuntu is intended to use the new ABI then?
[13:30] <pitti> right
[13:31] <tkamppeter> pitti, then CUPS is perfectly prepared now, under Debian it compiles with the old ABI then and under Ubuntu with the new ABI.
[13:31] <pitti> joss said he'd do a libpoppler5a once the dust settles in Debian, to properly handle the abi break
[13:31] <pitti> yay
[13:32] <pitti> thanks
[13:32] <tkamppeter> pitti, so you should upload the current CUPS to both distros now.
[13:32] <pitti> will do after alpha-1
[13:33] <tkamppeter> pitti, I will update the debian/changelog of cups.
[13:35] <pitti> tkamppeter: ugh, what did you do with bzr? you removed 3 revisions of mine and seem to have merged them back in a huge commit
[13:35] <pitti> oh, it's a merge
[13:38] <pitti> tkamppeter: I fixed the changelog (unstable -> UNRELEASED), please ull
[13:38] <pitti> and pull, too
[13:39] <tkamppeter> pitti, it accepted a "bzr push" by me though you had done three commits which I did not have downloaded. I discovered it on a later "bzr pull". So I did "bzr merge" to get your changes, solved the conflicts, synced the filters with upstream, wrote a debian/changelog entry and committed.
[13:40] <tkamppeter> Now I have done another commit to update the text of my last debian/changelog entry.
[13:40] <pitti> right
[13:41] <pitti> cjwatson, ev: "Update this installer" -> brilliant!
[13:42] <ev> all cjwatson on that one
[13:42] <tkamppeter> pitti, now all is in sync again with CUPS.
[13:43] <tkamppeter> pitti, will alpha-1 have CUPS working? Otherwise we perhaps need to upload this CUPS as a freeze exception. Please test.
[13:43] <pitti> tkamppeter: doesn't it right now?
[13:44] <tkamppeter> pitti, I do not know what is in alpha-1, I have manually installed the newest Poppler and the newest CUPS of Lucid, Poppler downloaded from LP and CUPS from BZR.
[13:44] <pitti> 1.4.2-1git1 should work just fine
[13:45] <pitti> except that the version number should have been "1bzr1" :0
[13:45] <mr_pouit> pitti: done, I'll also refresh xubuntu-desktop
[13:45]  * pitti works too much with git these days
[13:46] <tkamppeter> pitti, only if the Poppler in alpha-1 is old enough (not yet containing the ABI change).
[13:46] <pitti> mr_pouit: nice, thanks; should I attempt another xubuntu live build after that published?
[13:47] <pitti> tkamppeter: the current cups is built against the current poppler; should be all good
[13:48] <mr_pouit> pitti: yeah, probably, if xfce4-power-manager doesn't lag behing for amd64 anymore. It seems to be built now.
[13:48] <cjwatson> pitti: it's a right pain to test because you have to manually backrev the ubiquity package :)
[13:52] <tkamppeter> pitti, assuming that the CDs will contain the last version of each package which did not FTBFS CUPS comes as 1.4.2-1git1, which is built against 0.12.0-0ubuntu2 (old ABI) according to the i386 build log on LP, and Poppler in alpha-1 is 0.12.2-2.1ubuntu1 which is the new ABI. So for me it looks that CUPS will not work in alpha-1.
[13:52] <seb128> mr_pouit, hey, do you know if somebody in the xubuntu could do a mir for psiconv which is needed by abiword?
[13:53] <cjwatson> ttx: bit of a problem with the cloud preseeding stuff - I only seem to be able to talk to it by https, and busybox wget only supports http
[13:54] <ttx> cjwatson: I was fearing that would be the case
[13:54] <JontheEchidna> pitti: ping
[13:54] <cjwatson> ttx: any idea if there's any plain HTTP interface I can use?
[13:55] <ttx> cjwatson: not that I know of on the CLC itself, the other one seems hardwired to the webservices stuff. You should ask the eucalyptoids for advice.
[13:56] <cjwatson> I suppose this is only for eucalyptus, I could use wget-udeb
[13:56] <cjwatson> that might be easier
[13:56] <mr_pouit> seb128: abiword seems to be seeded by only xubuntu-desktop & lubuntu-desktop, so is there a reason to keep it in main?
[13:56] <cjwatson> yeah, I'll do that
[13:57] <seb128> pitti, ^ do you know?
[13:57] <ttx> cjwatson: yes. Adding a static file service webthing to the HTTP-based service on the CLC would probably require some change in upstream code itself
[13:57] <pitti> JontheEchidna: pong
[13:58] <ttx> cjwatson: and dropping that servlet xml in /etc is so much more elegant :)
[13:58] <JontheEchidna> pitti: Hi, I have a few revisions to jockey I would like to get merged: https://code.launchpad.net/~echidnaman/jockey/work
[13:59] <JontheEchidna> Also, I was wondering if the ~kubuntu-dev group could get added to ~jockey-hackers
[13:59] <tkamppeter> pitti, have you seen my longer message about a possibly broken CUPS in alpha-1 some lines above?
[13:59] <pitti> tkamppeter: yes, I did; haven't tested it (no printer right now, and busy with release stuff)
[14:00] <pitti> seb128: hm, I wonder what keeps it in main; checkrdepends doesn't have anything, but it's not on component-mismatches
[14:01] <pitti> ./ubuntu.lucid/dvd: * abiword-gnome
[14:01] <pitti> there we go
[14:01] <tkamppeter> pitti, this can get tested without printer, simply running '/usr/lib/cups/filter/pdftopdf 1 1 1 1 "" in.pdf > out.pdf'.
[14:01] <pitti> seb128: and edubuntu has it as well
[14:01] <seb128> pitti, does edubuntu requires main?
[14:01] <seb128> pitti, or can it use universe packages?
[14:01] <pitti> tkamppeter: seems we have it then
[14:02] <ScottK> seb128: Requires Main, I believe.
[14:02] <pitti> tkamppeter: i.  e. the problem; ok, I'll do an upload
[14:02] <seb128> who cares about edubuntu nowadays?
[14:02] <pitti> seb128: abiword-gnome doesn't exist at all any more, so the seeds need to be updated either way
[14:02] <ogra> seb128, highvoltage stgraber and sbalneav
[14:03] <pitti> stgraber: would you mind updating the edubuntu seeds for abiword? abiword-gnome doesn't exist any more; (or just drop it entirely, then it can go to universe and doesn't require a MIR)
[14:03] <seb128> ^ who is wanting to do the psiconv mir for abiword then?
[14:03] <seb128> or move it to universe
[14:04] <seb128> ogra, pitti: thanks
[14:06] <seb128> ups, focus with multi screen is confusing
[14:12] <pitti> stgraber: nevermind, did it for you; I can commit to the edubuntu seeds (fixed package names now)
[14:19] <tkamppeter> pitti, thanks, your new CUPS upload should clode bug 489791.
[14:25] <maxb> mvo, others: Any time a package being updated under update-manager fires off a debconf interaction, I get an error popup about "Cannot contact the configuration server". I see this on multiple machines, but there's no bug filed. Is there anything I could do to debug a bit more before I file one?
[14:29] <pitti> tkamppeter: uploaded to Debian now; test-building on lucid
[14:34] <pitti> tkamppeter: fails for me
[14:34] <mvo> maxb: lucid or karmic? is this the ubuntu update-manager? or do you use something like kubuntu?
[14:34] <pitti> tkamppeter: http://paste.ubuntu.com/338028/
[14:35] <maxb> mvo: Plain Ubuntu update-manager. I have observed this in jaunty, karmic, lucid.
[14:35] <pitti> tkamppeter: was this added recently? perhaps you forgot to bzr add it or so?
[14:36] <tkamppeter> No, CUPS shipped all the time with pdftops.c.
[14:36] <mvo> maxb: interessting, did you do any modifications to /etc/debconf.conf ? like putting a ldap there or something?
[14:36] <maxb> No
[14:37] <maxb> I am guessing that the "configuration server" is gconf
[14:37] <maxb> ORBit is mentioned in the error message
[14:37] <tkamppeter> pitti, there is no pdftops.c in the debian/ directory tree. pdftops.c is part of upstream CUPS.
[14:38] <pitti> tkamppeter: does "bzr st" show any modifications for you? does "bzr bd -- -b" build for you?
[14:38] <maxb> It's perhaps worth noting that the debconf prompts do appear (in GTK dialogs) underneath the error popup
[14:39] <maxb> dpkg-reconfigure says my debconf frontend is 'dialog'
[14:40] <tkamppeter> bzr st does not show any output, the other command I am running now.
[14:40] <tkamppeter> pitti ^^
[14:40] <tkamppeter> pitti: The PDF filters are compiled now ...
[14:41] <mvo> maxb: ohh, right. that is quite possible a side-effect of the perl-gtk2 bindings
[14:41] <maxb> perl!?
[14:41] <maxb> What do I install/uninstall/tweak to verify this?
[14:42] <tkamppeter> pitti, ... now it started testing, so everything seems to be compiled ...
[14:42] <pitti> tkamppeter: weird
[14:42] <tkamppeter> pitti, I have the current Lucid package and its -dev of Poppler installed.
[14:42] <tkamppeter> pitti, now it runs the debhelpers to complete the packaging.
[14:43] <pitti> tkamppeter: let me try again; I think I did a source build in parallel
[14:43]  * pitti does too much stuff in parallel today
[14:43] <tkamppeter> pitti, "rm -rf ../build-area/
[14:44] <tkamppeter> "
[14:44] <JontheEchidna> pitti: heh, mind if I ping you about jockey later then? You seem quite busy.
[14:44] <pitti> JontheEchidna: I have a tab open with the branch, so I'll merge it ASAP
[14:44] <JontheEchidna> thanks
[14:45] <tkamppeter> pitti, now the build ended successfully.
[14:46] <tkamppeter> pitti, I am trying with pbuilder now.
[14:46] <pitti> tkamppeter: let me finish my second build first; seems it's working now
[14:53] <pitti> JontheEchidna: merged, pushed
[14:53] <pitti> thanks!
[14:55] <JontheEchidna> pitti: thank amichair too if you see him around
[14:56] <pitti> JontheEchidna: I added you to ~jockey-hackers, so feel free to commit such fixes directly
[14:56] <tkamppeter> pitti, a Lucid pbuilder with the newest Poppler 0.12.2-2.1ubuntu1 builds CUPS 1.4.2-5 correctly for me.
[14:56] <JontheEchidna> pitti: ok, thanks
[14:56] <pitti> tkamppeter: uploaded -5 to lucid
[14:57] <tkamppeter> pitti, OK, Thanks.
[15:01] <syn-ack> 'mornin' pitti
[15:01]  * syn-ack hugs pitti 
[15:11] <tkamppeter> pitti, I got a "rejected" message of your upload: Unable to find distroseries: unstable
[15:12] <tkamppeter> pitti, seems that the config of LP in terms of accepting uploads of synced packages has changed or your need to conmfirm the upload somehow.
[15:13] <cjwatson> nothing to do with that, pitti just got the .changes file wrong it seems
[15:13] <cjwatson> synced .changes files always have the Distribution: field specially munged
[15:19] <iuso> hi, is there a standard way to manipulate /etc/network/interfaces in deb packages?
[15:19] <iuso> or is it just scripting in (pre|post)(inst|rm)?
[15:20] <cjwatson> I think packages are forbidden from manipulating /etc/network/interfaces, generally; it's a configuration file belonging to another package that doesn't provide an interface to manipulate it
[15:21] <cjwatson> if you do it, you'd have to (a) just use standard text editing tools (b) not upload it to the Ubuntu archive
[15:22] <iuso> cjwatson: thanks, that seems to answer the formal side. i'm writing a config package for my employer's internal systems which are running on ubuntu. i have free hands to do $whatever within the deb but i prefer to go by the book whenever possible
[15:22] <iuso> cjwatson: i guess it's careful use of grep and sed mainly from now on :)
[15:22] <cjwatson> sounds like it, yes
[15:22] <iuso> thanks again and bye
[15:23] <cjwatson> fortunately it's not *that* complex a file format
[15:46] <lamont> wtf does cups(presumably..) think it should be using snmp to talk to the host a printer spools to?
[15:56] <tkamppeter> Someone of the Alpha 1 release gurus around? pitti? slangasek? There is a problem with bug 489791, pitti has uploaded the fix but the upload gets rejected due to some LP problem. Can someone fix this or should I simply work around by uploading the same package with a 1.4.2-5ubuntu1 debian/changelog entry added?
[16:03] <cjwatson> tkamppeter: it's really easiest for pitti to fix this when he returns
[16:03] <cjwatson> tkamppeter: I didn't think he was going to be that long
[16:05] <pitti> tkamppeter: don't panic
[16:05] <pitti> I uploaded it again
[16:06] <pitti> cjwatson: ^
[16:06] <pitti> (also, it won't be on the alpha-1 images anyway)
[16:06] <pitti> people can just upgrade
[16:26] <ion> keybuk: Each graph at http://people.canonical.com/~scott/daily-bootcharts/ could have the (SSD) budget for that part as a constant line. :-)
[16:27] <Keybuk> I did put that on
[16:27] <Keybuk> but found it distracting
[16:27] <ion> Ok
[16:27] <Keybuk> started to become too much noise
[16:37] <dholbach> pitti: I'm sorry, but do you think you can restart the community team chart? we have a spike in there again :)
[16:37] <dholbach> (due to straggling)
[16:40] <pitti> dholbach: done
[16:41] <dholbach> thanks a lot pitti
[17:07] <robbiew> cjwatson: guess we forgot to choose a chair for next week :/
[17:07] <Keybuk> I don't mind doing it
[17:08] <robbiew> done!
[17:11]  * ScottK predicts a short meeting.
[17:14] <ion> keybuk: Do you happen to have time for reviewing <https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/parallel-checks>? :-)
[17:14] <Keybuk> no
[17:14] <ion> Aye
[17:14] <Keybuk> I'm not even sure it's the right idea ;)
[17:15] <Keybuk> do you have graphs to show it works?
[17:16]  * ion installs bootchart to the VM, let’s see.
[17:16] <Keybuk> blktrace would probably be good too
[17:37] <ueu001> I have a question about the default inclusion of software in karmic
[17:37] <ueu001> Why doesn't karmic come with python3 by default ?
[17:41] <ScottK> Because very few applications and almost no third party modules support it yet.
[17:42] <ueu001> is python 3 a major change of python 2 then  ?
[17:43] <ScottK> Yes.
[17:43] <ueu001> Thank you :  )
[17:43] <ScottK> It's useful for developers so we provide it, but it will be a long time before enough has transitioned to it to be a suitable default
[17:44] <ueu001> So for example if someone  is just now beginning python, which of the two would be the better choice ?
[17:46] <ScottK> It depends.  If you are learning it in school now to use later, probably Python 3.  If you need to deliver production code next month, Python 2.
[17:54]  * pitti can't believe that people seriously discuss a hurd port
[17:56] <cyberix> pitti: Ubuntu GNU/HURD then?
[17:57] <ogra> pitti, i think Keybuk trashed their hopes already :)
[18:00] <ScottK> ogra: They didn't give up.
[18:00] <ScottK> If not Hurd, how about Minix?
[18:00] <ogra> they will eventually ...
[18:00] <ogra> or BSD :P
[18:02] <ScottK> We already have an opensolaris downstream, so why not?
[18:11] <slangasek> james_w: pristine-tar reconstitution seems to fail for quilt
[18:11] <slangasek> (lp:ubuntu/quilt, after merge-package)
[18:13] <james_w> ok, thanks
[18:14] <james_w> that's a problem at creation time, rather than when you get the error
[18:16] <cyberix> I don't think a HURD edition of Ubuntu would be a bad idea once we first have an official Debian release with HURD
[18:17] <cyberix> But I don't think it should be marketed trought Ubuntu.com
[18:17] <cyberix> we should just have the packages available so someone can derive a Hurdubuntu from Ubuntu package repository
[18:18] <cyberix> but I guess HURD is still far from being officially supported by Debian
[18:18] <cyberix> atleast that comes closer as Debian starts to ship BSD
[18:18] <cyberix> and we have multi-arch in place
[18:19] <cyberix> talking of which, are we going to have multi-arch in Lunatic Lynx?
[18:19] <cyberix> Lucid
[18:19] <cyberix> -Lunatic
[18:22] <cyberix> This is still outdated https://wiki.ubuntu.com/MultiarchSpec
[18:22] <cyberix> it says "Ubuntu 9.10 introduces support for installing packages from multiple architectures on a single system"
[18:22] <cyberix> and obviously it didn't
[18:28] <kirkland> james_w: hi, i'm having trouble finding an imported package branch ... how do you search these?
[18:28] <kirkland> james_w: or is the url well-defined enough for me to just guess it?
[18:29] <kirkland> james_w: specifically, i'm looking for "screen"
[18:29] <tdomhan> why can't I currently create bugs in launchpad? https://bugs.launchpad.net/ubuntu/+filebug will redirect me to the wiki. is this intended?
[18:29] <beuno> tdomhan, yes, read the wiki
[18:30] <james_w> kirkland: code.launchpad.net/ubuntu/+source/screen
[18:31] <james_w> kirkland: or go to the package page and click the "Branches" tab
[18:31] <james_w> to just branch it with bzr "bzr branch lp:ubuntu/screen" for lucid
[18:31] <james_w> lp:ubuntu/<series>/screen for an arbitrary series
[18:33] <kirkland> james_w: perfect, thanks
[19:12] <LaserJock> is dholbach on vacation?
[19:14] <geser> LaserJock: at least he wasn't today
[19:14] <LaserJock> hmm, I never seem to find him
[19:15] <jcastro> LaserJock: he usually signs off about -2 hours ago every day
[19:18] <geser> LaserJock: try around between 8 UTC and 17 UTC
[19:37] <ion> keybuk: http://heh.fi/tmp/mountall/ Bootcharts from current mountall behavior and two methods to inhibit low-priority instances: ioprio_set+setpriority and SIGSTOP.
[19:38] <ion> keybuk: I have trouble distinguishing the two fsck instances from blktrace’s output.
[19:38] <Keybuk> ioprio one looks quite reasonable
[19:39] <Keybuk> it's simpler in the code too, right?
[19:39] <ion> As opposed to mountall’s current behavior?
[19:39] <Keybuk> yeah
[19:44] <ion> keybuk: Hmm. The number of lines of code didn’t change much, because it still needs determine which instances to inhibit based on which physical devices they’re operating on. It no longer needs to maintain a global fsck queue and device locks. Instead it maintains a list of running checks sorted by their priorities. When checks start or finish, it updates the list and then updates the process priorities.
[19:45] <Keybuk> right
[19:45] <learner001> Hi
[19:45] <Keybuk> which seems simpiler
[19:45] <Keybuk> less prone to forgetting to run fsck
[19:46] <learner001> i need help please
[19:46] <Keybuk> learner001: #ubuntu for help
[19:46] <ion> Yeah, i’d say it’s conceptually simpler.
[19:46] <learner001> i did upgrade from 9.10 to 10.4
[19:46] <learner001> then i can not run xserver
[19:47] <learner001> how can i do undo upgrade
[19:49] <ion> Basically, reinstall. You upgraded to a development version. When running one, you should *expect* it to break periodically. Now, please, #ubuntu for help.
[19:49] <learner001> ok thank u
[19:51] <ajmitch> actually #ubuntu+1 for lucid help, I think
[20:13] <Keybuk> ajmitch: #ubuntu-wddtt ?
[20:13] <ajmitch> Keybuk: I won't even try & figure out what that one means :)
[20:13] <Keybuk> Well Don't Do That Then
[21:27] <barry> hi all.  i have a complete n00b question.  i'm learning how to be an ubuntu developer (working w/cjwatson) and am trying to fix a particular bug.  the bug had a patch, which i applied, and built a new package.  what is the best way to test the fix?  by that i mean, is it better to install the new deb and try it then?  what about when i'm done and want to restore the original package?  note that i'm working in a vm so not too concerned
[21:27] <barry> about hosing the system.  i'm just trying to understand best practices
[21:29] <lamont> barry: generally I wind up installing the package and going from there.
[21:30] <lamont> though downgrading, while covered in the developer spec, is "not exactly the most robustly tested piece" to gloss over the ugliness that it can be - exactly how well, or even if, it works to go back to the old package with just a downgrade, depends on the packagea
[21:30] <slangasek> james_w: "when you merge-package outside a shared repo" - what does "shared repo" mean, here?  Is there something I should have done differently on my side?
[21:31] <barry> lamont: ah.  so does that mean over time, you end up with an environment that can have many in-development packages?  i guess as your changes get reviewed and accepted, they get uploaded and everything evens out
[21:31] <slangasek> barry: pretty much, yeah
[21:31] <barry> lamont: although it does make a good case for something even more lightweight than virtual machines (i.e. chroots)
[21:32] <slangasek> once I've tested a package, the next step is to throw it at the archive :)
[21:32] <james_w> slangasek: what you get with "bzr init-repo". It's not required, but it's an optimisation that can give big wins
[21:32] <james_w> and also in this case means you sidestep the bug
[21:32] <barry> slangasek: that makes sense!  one other question: what if my initial patch is not good enough and i need to revise it?  is it just: re-patch, rebuild, dpkg -i new.deb, rinse, repeat?
[21:33] <slangasek> james_w: oh, hmm; does it have other benefits for one-off package merges?
[21:33] <slangasek> barry: yes
[21:34] <slangasek> james_w: rephrase: does it actually optimize anything for one-off package merges?
[21:34] <james_w> slangasek: if you never move outside the one branch on your filesystem then it's an overhead of one command
[21:34] <barry> slangasek: alright!  thanks!
[21:34] <slangasek> barry: enjoy :)
[21:34] <james_w> if you put multiple branches to your filesystem, then it's a win
[21:34] <barry> :)
[21:35] <slangasek> james_w: right; so for this kind of thing where my workflow is "bzr co lp:ubuntu/$pkg; cd $pkg; bzr merge-package lp:debian/$pkg; bzr resolve; bzr commit; bzr bd --source; cd ..; dput; rm -r $pkg", not actually an optimization :)
[21:35] <james_w> correct
[21:35] <slangasek> ok
[21:36] <james_w> well, saying that, it avoids the bug
[21:36] <slangasek> yeah
[21:36] <james_w> and that's because it will be an optimisation to "merge-package"
[21:36] <slangasek> in the present instance, I'm avoiding the bug by having done a MoM merge in the meantime :/
[21:36] <james_w> I'll look in to making it not be needed for that optimisation
[21:37] <james_w> I'll have to ask a bzr person the best way to that though
[21:39] <lamont> slangasek: I've been quoted as to my sometimes-practice of fixing bugs
[21:39] <slangasek> lamont: ?
[21:39] <lamont> barry: if it's one of my packages, I tend to leave on my machines.  if it's not,  I downgrade the package after testing
[21:40] <lamont> slangasek: something to the effect of "I frequently don't care about packages I uploaded 5 minutes ago" or some such
[21:40] <slangasek> heh
[21:40] <lamont> and well, sometimes my testing is a bit, um, sparse.
[21:40] <barry> lamont: gotcha
[22:36] <ccheney> http://www.phoronix.com/scan.php?page=article&item=ubuntu_1004_alpha1&num=1 <- ouch
[22:44] <slangasek> ccheney: hmm, interesting postgresql benchmark results, does that imply that postgresql is calling fsync() too much?
[22:55] <ccheney> slangasek: maybe, i'm not sure if phoronix has investigated it
[22:56] <ccheney> slangasek: he did track down it was caused by the barriers code but not whether it was postgresql or something else running at the same time
[22:56] <slangasek> well, presumably for a proper benchmark he wasn't running other stuff at the same time :)
[22:57] <ccheney> but iirc tytso was wanting everyone to call fsync on every write a few months back
[22:57] <slangasek> eh
[22:57] <ccheney> yea hopefully not ;)
[22:57] <ccheney> the don't fear the fsync blog entry
[22:57] <ccheney> this seems to be a obvious case of yes fear the fsync
[22:58] <slangasek> yes, didn't everyone reply to that blog entry and tell him he was on crack?
[22:58] <directhex> what's the status of source format 3.0?
[22:58] <ccheney> if it works the way the article says every fsync call flushes the full physical disk buffer
[22:59] <directhex> ccheney, phoronix's benchmarking methodology is inherently flawed IME, and shows a deep understanding of how to make valid benchmarks
[22:59] <directhex> i.e. heart in right place, execution not so hot
[22:59] <slangasek> directhex: LP is supposed to get support for it next week; MoM shrieks whenever it sees it but we don't know why
[22:59] <slangasek> (yet)
[23:00] <ccheney> what i hope is that these changes fixed the problem where heavy disk io causes ubuntu to completely stop responding until it is done
[23:00] <directhex> slangasek, so i should be reasonably comfortable uploading 3.0(quilt) to debian for somethign i want in lucid?
[23:00] <ccheney> i don't care about a little lost performance if i can do disk io and something else at the same time, heh
[23:01] <slangasek> directhex: it's imperative that we have support for 3.0 in lucid; whether that means you want to bet on the support landing when it's /supposed/ to is up to you
[23:46] <slangasek> ajmitch: hi, what was the status of fixing boost1.40?