[00:02] 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] thats on armel [00:02] james_w: cool, thanks [00:03] too easy [00:03] a bit more context: http://paste.ubuntu.com/337658/ [00:03] asac: yeah, all libs should be -fPIC [00:04] kees: hmm. so atm this seems to not use -fPIC on i386/amd64 [00:04] but still works [00:04] at least builds [00:04] so using fPIC everywhere is better? [00:06] I didn't think non-pic .sos worked on amd64 either [00:06] let me check the build log for amd64 [00:07] right. its used there [00:08] (one would think it would be prudent on i386 as well, but what do I know) === nhandler_ is now known as nhandler [00:09] asac: hrm, so, the problem is that it lacks -fPIC when doing the .so build, for sure [00:09] I can't say that's is best to _always_ build -fPIC, but usually you'll want it. [00:10] thx. thats good enough [00:10] its probably a build system issue [00:10] the line that starts: gcc -shared -Wl,-soname,libavutil.so.50 [00:10] is using .o's that weren't -fPIC compiled. [00:10] yes [00:10] thats the point. it doesnt ad fPIC at all on armel and i386 [00:10] add -fPIC [00:10] it's just that due to the stack-protector symbol, it's showing up quickly. [00:11] that's ... odd [00:11] right. just wanted to check back if thats something broken because of armel [00:11] kees: its a non autotools build system (e.g. manual configure + Makefile) ... so its not really shocking ;) [00:11] heh, ok [00:18] 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] james_w: ^^ the merge-package "upstream branches have diverged" OMG failure [00:20] what? it's just a full and clear exception message! :-) [00:20] yes, I was just clarifying "melted down" :) [00:21] 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] 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] nhandler, I sent email to ubuntu-devel-announce, though maybe it hasn't been moderated yet [00:33] 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] 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] 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 === asac_ is now known as asac [00:40] kees/slangasek: I've no idea why that conflicts, I'm asking in #bzr [00:40] ok :) [03:02] Hello [03:02] I need assistance [03:05] jennie: #ubuntu is for support, this channel is for development discussion [03:06] micahg , i need a simple help , please help me its related to printer installation [03:07] erg [03:07] jennie, then you need to go to #ubuntu, please === dous_ is now known as dous === Epigene is now known as Epistaxis [03:50] Hmm, Thunderbird 3 is out. [03:51] LucidFox: indeed [03:51] micahg, perhaps it would make sense to replace rc3 in your PPA? :) [03:51] LucidFox: rc3 is the release version [03:52] LucidFox: when there's an official .orig.tar.gz, I'll think about fixing it [03:53] * LucidFox nods [03:53] but that is the actual release code though, just not branded or versioned properly [03:54] 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] Ah, your version is still branded Shredder. :( [03:55] LucidFox: right :) [03:56] Hey anyone know if we're gonna have a 64 bit compatible version of Enigmail anytime soon? [03:56] If not, I suppose I could look into it [03:56] syn-ack: well, that depends on how much free time I have :) [03:57] hah [03:57] no way [03:57] * micahg needs it as well and is part of the mozilla team :) [03:57] heh [03:57] How about that. :P === robert_ancell_ is now known as robert_ancell === bob is now known as Guest26677 === bob__ is now known as Guest34652 [04:58] 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] ScottK: Looking. [05:08] StevenK: Thanks. [05:09] ScottK: Which source package builds it? [05:09] StevenK: kdebase-workspace [05:11] ScottK: Done. [05:11] StevenK: Thanks. [05:35] Good morning [05:36] Keybuk: resume straight away> oh, nice! haven't noticed that yet === ArneGoet1e is now known as ArneGoetje [06:05] anyone please? [06:08] lwb: Help is in #ubuntu. [06:34] Anyone care to test an apparmor script I just got working for skype? [06:41] hey keybuk, what's that new kernel in boot staging do? [06:41] *what does that [06:47] 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] (I'm not disputing it, just curious) [06:51] can someone help me build ati drivers from src? [06:52] #ubuntu = no luck . . . #debian = got threatened [07:11] CptHowdy> Threatened [07:11] ? [07:13] I'd guess "strongly suggested to ask elsewhere". [07:15] ... and "ubuntu has been a bloated peice of trash since ... " [07:16] actual quote btw [07:16] yay for alpha 1 [07:19] Darko> From Debian developers? [07:19] not sure, probably not though [07:20] I'm not sure if you should discuss about that here anyway (: [08:02] good morning [08:02] hey dholbach! [08:03] hey mvo [08:26] 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] (I need to rebuild compiz to make it installable for alpha-1) [08:51] 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] I tried it in my lucid pbuilder where it succeeds but on the buildd it failed again [08:57] geser: Looks like the build is happening in parallel though [08:57] geser: You have two dh_prep calls which might be called one after the other [08:58] geser: e.g. dh_prep (install-indep), make install (install-indep), dh_prep (cleans up), dh_install (binary-indep) => boom [09:00] geser: One way around it is to change MAKE instead of MAKEFLAGS until your rules are -j safe [09:06] james_w: I reviewed a bunch of merge proposals! it was fun! :) [09:07] james_w: now I just need a programmatic way to get them from LP onto the sponsoring overview :) === tkamppeter_ is now known as tkamppeter [09:19] * pitti eyes component-mismatches [09:19] o pmount: pmount [09:19] [Reverse-Recommends: kdebase-runtime] [09:19] o_O [09:20] Riddell: going back to the old times? :-) [09:23] pitti, just wait for him to upload MAKEDEV! === Tonio__ is now known as Tonio_ [10:15] mvo: hi again! :) [10:16] 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] 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] mvo: is there some specific reason for that? [10:20] 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] 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] 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] free: oh? let me check [10:22] mdz: current x server has the apport patch disabled, I think; It still needs to be ported to the current version [10:22] * 135_rethrow_signals.patch, 168_glibc_trace_to_stderr.patch: [10:22] mvo: yeah, the point is that the two versions published are different, I'm wondering if it's on purpose [10:22] Disabled until fixed to work with the current version. [10:23] mvo: in my tests the Landsacpe server is passing the landscape client the .30, hence the failures === jelmer_ is now known as jelmer [10:24] pitti, oh, hmm. I thought without the patch, apport would never see it at all because the signal was caught [10:24] that's what I had expected [10:24] it seems that the process went away while it was still dumping core, which seems odd [10:25] bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/xorg-server": xorg-server in ubuntu has no default branch. [10:25] :-( [10:25] james_w, ^ [10:26] 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] free: I need to diff the actual files [10:29] mvo: so, okay, between two lts releases I should use meta-release-lts [10:30] pitti, shouldn't we open bugs when we disable patches like this, so that they aren't forgotten entirely? [10:30] mvo: what about between a non-lts and an lts? like from karmic to lucid [10:30] mvo: supposing lucid is out already [10:30] 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] mvo: should you use the upgrade tool url in meta-release or meta-release-lts in that case? === ogra_ is now known as ogra [10:31] mdz: they aren't forgotten [10:31] tjaalton: ^ is re-enabling 135_rethrow_signals.patch in xorg-server on some radar? (like mdz's bug opening suggestion) [10:31] 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] pitti: bryce said he'd look at it after his vacation [10:31] mvo: yes, I know about it [10:31] free: maybe it would be best to just use the code from u-m (metarelease.py) in landscape too? [10:32] mvo: so it's really a user conf [10:32] pitti: I understood that apport was still disabled anyway [10:32] free: than we can be sure its behaving the same [10:32] tjaalton: it is [10:32] 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] mvo: the thing is that we would like to be able to specify the target release from the web ui [10:33] tjaalton, it's disabled by default, but those of us who have crashes will turn it on to capture a report [10:33] mvo: without having to modify /etc/update-manager/release-upgrades [10:34] free: I see. you could subclass MetaReleaseCore and override CONF I guess, sorry that there is no nicer mechanism at this point [10:35] mdz: git clone, btw ;) [10:38] 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] mvo: yeah, in all other cases it works indeed [10:38] * mvo scratches his head [10:38] mvo: it's the only case I'm having problems with, but know it's clear why :) [10:39] 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] geser: hm, seems the package is building in parallel on the buildds [10:40] 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] free: right, if all you need is override of the "release-upgrades" conf via a commandline, that can be done easily [10:43] mvo: yeah, that would do it, I guess [10:44] 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] ok === saispo_ is now known as saispo [10:49] mvo: just one more thing about this specifc issue [10:50] 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] mvo: or is it only in this specific case due to a bug in soyuz? [10:51] 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] mvo: okay, thank you [10:52] thanks [10:52] 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] 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] mvo: okay === pedro__ is now known as pedro_ === seb128_ is now known as seb128 [11:23] $ bzr import-dsc ../dpkg-cross_2.5.2ubuntu2~cross*.dsc [11:23] bzr: ERROR: Unable to find the tag for the previous upstream version, 2.5.2ubuntu1, in the branch: upstream-2.5.2ubuntu1 [11:24] 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] cjwatson: that may well be a bug [11:25] Steve reported something similar [11:25] I thought it was handled, but obviously not [11:25] I'll go report it then [11:26] thanks [11:27] the -Derror trace would be useful [11:27] (debug flag to always print tracebacks for exceptions) [11:30] james_w: cool; added [11:30] thanks [11:30] maybe just needs 'if config.native:' [11:30] ? [11:31] well, 'if not' [11:32] hmm, now I have Unicode trouble with lool's name [11:33] 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] ScottK: I hit it over the head now, it builds now [11:34] OK. Good. [12:17] 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] dnivra_: you need the .dsc, and then use dpkg-source -x foo.dsc [12:17] dnivra_: but that's not the usual way, you usually just do "apt-get source packagename" [12:21] 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] ev, aufs ? [12:22] that would stretch the "everything is a file" principle veeery far :) [12:22] (wouldnt be an pverlay but a union mount indeed) [12:22] *over [12:22] oh, ignore me; I misread [12:23] sounds pretty much what aufs does on the live system indeed? [12:23] ev: but I wouldn't recommend that for production use [12:23] indeed, that slipped my mind [12:23] I think there's a way to do it with LVM, though [12:23] Fedora live systems work like that [12:23] pitti: this is simply to save me the work of tons of NFS mounts [12:24] in development on the live CD [12:24] pitti: but the current repository is karmic's and i want the lucid development package. thanks [12:24] dnivra_: (you can add deb-src for lucid) [12:24] pitti: true [12:24] * dnivra_ didn't think of that [12:33] does dpkg already support xz? [12:34] xz? [12:34] I think it doesn't. [12:35] not yet in lucid, although I think it probably will in the lucid cycle; the work's done upstream [12:35] Tm_T, lzma-utils's slightly more generic continuation [12:35] me is scared [12:35] mjr: ah, thanks [12:35] provides for unpacking the old lzma format [12:35] although that would require another rev of the dpkg code used by LP, so maybe not. don't bank on it [12:36] (possibly also compression for now, not sure) [12:38] mjr: It does. KDE uses xz for all it's lzma support. === MacSlow is now known as MacSlow|lunch [13:01] I uploaded a fixed maximus since it was missing a Provide causing compiz to appear in the ubuntu-netbook-remix task === MacSlow|lunch is now known as MacSlow [13:20] pitti, seb128, there is a problem with Lucid's Poppler. [13:20] tkamppeter: ? [13:21] tkamppeter: if you ask because of cups trunk FTBFSing, that's know [13:21] n [13:21] Debian reverted an upstream API/ABI change [13:21] so we can't build current cups trunk in lucid [13:21] that needs some h4ck3ry again [13:22] 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] tkamppeter: right, the version number is screwed up [13:22] I cannot find the files 01_revert_abi_change.patch and 02_autohinting_abi_compatibility.patch in our Poppler. [13:22] it should have been 0.12.2-0ubuntu1 [13:22] tkamppeter: we dno't want 01_revert_abi_change.patch [13:23] And Debian's ChangeLog entries of 0.12.2-1 and 0.12.2-2 are also missing. [13:23] pitti, what is wrong with 01_revert_abi_change.patch? [13:24] it reverts upstream abi [13:24] there is no reason to be api incompatible with upstream [13:25] tkamppeter: there's a patch in bzr history which was reverted again which makes it build with our poppler [13:26] 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] nice [13:26] tkamppeter: sure, we can take that for granted [13:27] Koji Otani, upstream developer of pdftopdf has made this final patch. [13:28] 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] 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] are you interested in xubuntu alpha-1 at all? [13:29] We should have a Poppler which has the ABI which is official by Poppler upstream. [13:29] i. e. should we put some effort into getting buildable CDs? [13:29] tkamppeter: so the situation is that the poppler API/ABI was officially broken (without bumping soname) [13:29] tkamppeter: so the current lucid abi is the upstream abi [13:30] it was just reverted in Debian to not delay the huge testing transition even more [13:30] pitti, seb128, so Ubuntu is intended to use the new ABI then? [13:30] right [13:31] 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] joss said he'd do a libpoppler5a once the dust settles in Debian, to properly handle the abi break [13:31] yay [13:32] thanks [13:32] pitti, so you should upload the current CUPS to both distros now. [13:32] will do after alpha-1 [13:33] pitti, I will update the debian/changelog of cups. [13:35] 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] oh, it's a merge [13:38] tkamppeter: I fixed the changelog (unstable -> UNRELEASED), please ull [13:38] and pull, too [13:39] 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] Now I have done another commit to update the text of my last debian/changelog entry. [13:40] right [13:41] cjwatson, ev: "Update this installer" -> brilliant! [13:42] all cjwatson on that one [13:42] pitti, now all is in sync again with CUPS. [13:43] pitti, will alpha-1 have CUPS working? Otherwise we perhaps need to upload this CUPS as a freeze exception. Please test. [13:43] tkamppeter: doesn't it right now? [13:44] 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] 1.4.2-1git1 should work just fine [13:45] except that the version number should have been "1bzr1" :0 [13:45] pitti: done, I'll also refresh xubuntu-desktop [13:45] * pitti works too much with git these days [13:46] pitti, only if the Poppler in alpha-1 is old enough (not yet containing the ABI change). [13:46] mr_pouit: nice, thanks; should I attempt another xubuntu live build after that published? [13:47] tkamppeter: the current cups is built against the current poppler; should be all good [13:48] pitti: yeah, probably, if xfce4-power-manager doesn't lag behing for amd64 anymore. It seems to be built now. [13:48] pitti: it's a right pain to test because you have to manually backrev the ubiquity package :) [13:52] 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] mr_pouit, hey, do you know if somebody in the xubuntu could do a mir for psiconv which is needed by abiword? [13:53] 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] cjwatson: I was fearing that would be the case [13:54] pitti: ping [13:54] ttx: any idea if there's any plain HTTP interface I can use? [13:55] 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] I suppose this is only for eucalyptus, I could use wget-udeb [13:56] that might be easier [13:56] seb128: abiword seems to be seeded by only xubuntu-desktop & lubuntu-desktop, so is there a reason to keep it in main? [13:56] yeah, I'll do that [13:57] pitti, ^ do you know? [13:57] 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] JontheEchidna: pong [13:58] cjwatson: and dropping that servlet xml in /etc is so much more elegant :) [13:58] pitti: Hi, I have a few revisions to jockey I would like to get merged: https://code.launchpad.net/~echidnaman/jockey/work [13:59] Also, I was wondering if the ~kubuntu-dev group could get added to ~jockey-hackers [13:59] pitti, have you seen my longer message about a possibly broken CUPS in alpha-1 some lines above? [13:59] tkamppeter: yes, I did; haven't tested it (no printer right now, and busy with release stuff) [14:00] seb128: hm, I wonder what keeps it in main; checkrdepends doesn't have anything, but it's not on component-mismatches [14:01] ./ubuntu.lucid/dvd: * abiword-gnome [14:01] there we go [14:01] pitti, this can get tested without printer, simply running '/usr/lib/cups/filter/pdftopdf 1 1 1 1 "" in.pdf > out.pdf'. [14:01] seb128: and edubuntu has it as well [14:01] pitti, does edubuntu requires main? [14:01] pitti, or can it use universe packages? [14:01] tkamppeter: seems we have it then [14:02] seb128: Requires Main, I believe. [14:02] tkamppeter: i. e. the problem; ok, I'll do an upload [14:02] who cares about edubuntu nowadays? [14:02] seb128: abiword-gnome doesn't exist at all any more, so the seeds need to be updated either way [14:02] seb128, highvoltage stgraber and sbalneav [14:03] 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] ^ who is wanting to do the psiconv mir for abiword then? [14:03] or move it to universe [14:04] ogra, pitti: thanks [14:06] ups, focus with multi screen is confusing [14:12] stgraber: nevermind, did it for you; I can commit to the edubuntu seeds (fixed package names now) [14:19] pitti, thanks, your new CUPS upload should clode bug 489791. [14:19] Launchpad bug 489791 in cups "Compilation fails because of changed interface in libpoppler" [Critical,Fix committed] https://launchpad.net/bugs/489791 [14:25] 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] tkamppeter: uploaded to Debian now; test-building on lucid [14:34] tkamppeter: fails for me [14:34] maxb: lucid or karmic? is this the ubuntu update-manager? or do you use something like kubuntu? === thunderstruck is now known as gnomefreak [14:34] tkamppeter: http://paste.ubuntu.com/338028/ [14:35] mvo: Plain Ubuntu update-manager. I have observed this in jaunty, karmic, lucid. [14:35] tkamppeter: was this added recently? perhaps you forgot to bzr add it or so? [14:36] No, CUPS shipped all the time with pdftops.c. [14:36] maxb: interessting, did you do any modifications to /etc/debconf.conf ? like putting a ldap there or something? [14:36] No [14:37] I am guessing that the "configuration server" is gconf [14:37] ORBit is mentioned in the error message [14:37] pitti, there is no pdftops.c in the debian/ directory tree. pdftops.c is part of upstream CUPS. [14:38] tkamppeter: does "bzr st" show any modifications for you? does "bzr bd -- -b" build for you? [14:38] It's perhaps worth noting that the debconf prompts do appear (in GTK dialogs) underneath the error popup [14:39] dpkg-reconfigure says my debconf frontend is 'dialog' [14:40] bzr st does not show any output, the other command I am running now. [14:40] pitti ^^ [14:40] pitti: The PDF filters are compiled now ... [14:41] maxb: ohh, right. that is quite possible a side-effect of the perl-gtk2 bindings [14:41] perl!? === barry` is now known as barry_ [14:41] What do I install/uninstall/tweak to verify this? [14:42] pitti, ... now it started testing, so everything seems to be compiled ... [14:42] tkamppeter: weird [14:42] pitti, I have the current Lucid package and its -dev of Poppler installed. [14:42] pitti, now it runs the debhelpers to complete the packaging. [14:43] 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] pitti, "rm -rf ../build-area/ [14:44] " [14:44] pitti: heh, mind if I ping you about jockey later then? You seem quite busy. [14:44] JontheEchidna: I have a tab open with the branch, so I'll merge it ASAP [14:44] thanks [14:45] pitti, now the build ended successfully. [14:46] pitti, I am trying with pbuilder now. [14:46] tkamppeter: let me finish my second build first; seems it's working now [14:53] JontheEchidna: merged, pushed [14:53] thanks! [14:55] pitti: thank amichair too if you see him around [14:56] JontheEchidna: I added you to ~jockey-hackers, so feel free to commit such fixes directly [14:56] pitti, a Lucid pbuilder with the newest Poppler 0.12.2-2.1ubuntu1 builds CUPS 1.4.2-5 correctly for me. [14:56] pitti: ok, thanks [14:56] tkamppeter: uploaded -5 to lucid [14:57] pitti, OK, Thanks. [15:01] 'mornin' pitti [15:01] * syn-ack hugs pitti [15:11] pitti, I got a "rejected" message of your upload: Unable to find distroseries: unstable === paran_ is now known as paran [15:12] 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] nothing to do with that, pitti just got the .changes file wrong it seems [15:13] synced .changes files always have the Distribution: field specially munged [15:19] hi, is there a standard way to manipulate /etc/network/interfaces in deb packages? [15:19] or is it just scripting in (pre|post)(inst|rm)? [15:20] 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] 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] 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] cjwatson: i guess it's careful use of grep and sed mainly from now on :) [15:22] sounds like it, yes [15:22] thanks again and bye [15:23] fortunately it's not *that* complex a file format === mac_v_ is now known as mac_v === beuno is now known as beuno-lunch [15:46] wtf does cups(presumably..) think it should be using snmp to talk to the host a printer spools to? === barry_ is now known as barry [15:56] 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? [15:56] Launchpad bug 489791 in cups "Compilation fails because of changed interface in libpoppler" [Critical,Fix committed] https://launchpad.net/bugs/489791 === robbiew_ is now known as robbiew [16:03] tkamppeter: it's really easiest for pitti to fix this when he returns [16:03] tkamppeter: I didn't think he was going to be that long [16:05] tkamppeter: don't panic [16:05] I uploaded it again [16:06] cjwatson: ^ [16:06] (also, it won't be on the alpha-1 images anyway) [16:06] people can just upgrade [16:26] 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] I did put that on [16:27] but found it distracting [16:27] Ok [16:27] started to become too much noise [16:37] pitti: I'm sorry, but do you think you can restart the community team chart? we have a spike in there again :) [16:37] (due to straggling) === beuno-lunch is now known as beuno [16:40] dholbach: done [16:41] thanks a lot pitti === dendro-afk is now known as dendrobates [17:07] cjwatson: guess we forgot to choose a chair for next week :/ [17:07] I don't mind doing it [17:08] done! [17:11] * ScottK predicts a short meeting. [17:14] keybuk: Do you happen to have time for reviewing ? :-) [17:14]