[00:00] jjlee, let me know if there is, i carry that baggage around in debian/rules all the time [00:00] bleh [00:01] I guess git-buildpackage gets it from somewhere... [00:02] or I guess it's actually dpkg-buildpackage or something below that [00:04] I'm not sure where to get the source package name from, either [00:04] is there a command to parse that out of debian/control? [01:30] if i wanted to get involved developing a better gnome menu bar... where would i start? [01:30] freedesktop.org? [01:31] The Gnome project? [01:32] i meant... as far as finding source, to hack at, and then propose [01:33] bddebian: do you know where the menu bar module can be found? i've only been able to find bits and pieces, but not the parent [01:33] No idea, sorry [01:35] mahngiel, how do you mean the menu bar? [01:35] ya, didn't think so. i've found children in ~/.config/menus and /etc/xdg/menus. but nothing about the actual parent. it HAS to have a parent, it's referenced in languages and themes [01:35] bjsnider: i mean the "Applications, Places, System" menu bar [01:35] mahngiel, forget it [01:35] bjsnider, hm? [01:35] it's dead code. it's not being worked on anymore [01:36] gnome-shell is replacing it and that's the code that's being worked on now [01:36] bjsnider: ok, well if i wanted to break into it, and make it work-able for distros prior to lucid? [01:36] it's a gnome-panel app [01:37] hackable? [01:37] i don't know why anyone would accept patches though [01:37] no, but people still use hardy :/ [01:38] take a look at the source for gnome-panel and look at the applets [01:38] if i wanted to break into the code, and adjust it for current use in karmic... could you point me in the right direction to find it's parent? [01:38] i forget which one it is [01:38] alright, thanks [01:38] you can right-click on the panel and go throught he list until you find it [01:39] i know it's called 'menu bar'. just trying to find the main parent. the user/system files i've found are just children [01:39] so you'd have to change it and make it work and then release a ppa version of gnome-panel i suppose [01:39] that's not an issue, finding the s.o.b. HAS been [01:40] but looking through gnome panel is a new start. [01:40] what is so terribly broken about it? and you know there are alternatives [01:40] there's a project called "ubuntu system panel" out there for one [01:41] i'm not aware of any alternatives, and it's not that it's 'broken'... it's just that it's not customizable to my regards [01:41] there's an alternative already in there [01:41] i forget what it's called [01:42] end effect, i would like to expand it's .menu holders from 3 to more/less depending on the user, and the names [01:43] the files accessible through local files only replicate what can be accomplished through the 'menu edit' mod [01:43] in a year's time i don't know how many users will still be using gnome-panel [01:44] well, that's refreshing to hear. but in that same regard, people (including myself) still use XP :) [01:44] it's just a matter of being able to get something unique and enjoyable to the end user. and being an end user and hobbying hacker, i'm trying to figure how to customize the damned menu bar [01:46] i'm not sure the plan for implementing task/tool bars in lucid, but i'm sure there'll be a reciprocative effect of what is the current menu bar, unless the plan is to be more like win/mac to attract users [01:46] great idea but several years too late [01:48] however it goes, my friend, people enjoy *nix systems due to customability. everything should be customizable, and being GPL and open source, finding homes to things they'd like to hack ought to be attainable [01:50] actually if you want to talk to the gnome devs about this, you can go to irc.gnome.org #gnome-shell [01:50] i suspect the features you're talking about were left out intentionally, because if you give the user the power to screw up the menu bar, they'll screw up the menu bar [01:51] hahaha. truth preached my friend. unless the capable hacker comes along and provides a howto. such as we seen grub2 f*ck ups before public documentation. hahaha [01:52] anyways, thanks for the chat. [01:53] you sure that was #gnome-shell? room was empty [01:53] irc.gnome.org [01:53] not freenode [01:53] that's what i get for drinking. :) carry on. [04:10] kimi: aparently I was able to register for two classes that happen at the same time.... [04:11] ^ wrong chan; sorry [04:55] zooko: Sorry for the delay: I have fairly large latencies in my connection now (10-100 Ksec). I'm not particular about how I'm quoted, although using my name in email may make it easier for someone to find me for a direct quote, and using my nick may be easier if you want to paste IRC log and reference http://irclogs.ubuntu.com/2009/12/29/%23ubuntu-motu.html [06:02] bjsnider, why is your 190.53 driver package depending on "libvdpau"? there's no need for such a dependency [06:02] if something else is using vdpau, shlibs will cause the package to depend on libvdpau1 (which is appropriate) [06:03] the nvidia driver package itself doesn't need libvdpau to operate (and if it did, it would be libvdpau1 not libvdpau) [06:14] persia: FYI here is the plan for Tahoe-LAFS v1.6 (such as it is): http://allmydata.org/pipermail/tahoe-dev/2009-December/003436.html === asac_ is now known as asac [07:15] Hello [08:47] Hello, is there a team on Ubuntu for scientific/electronic packages ? [09:08] hello, any ubuntu motu who conduct ppa here? [09:08] I have the questions about ubuntu ppa [09:09] rawang: just ask [09:10] slytherin, alright, I just successfully built a package, and build another package which depends on it. when ppa install that package, it runs into error, and I can't figure out what's the problem. [09:11] http://launchpadlibrarian.net/37265946/buildlog_ubuntu-karmic-i386.mono-uia-atkbridge_1.0-2~pre1_FAILEDTOBUILD.txt.gz [09:12] slytherin, it said when it wants to install some assemblies, it failed, but i manage to install it locally [09:14] checking [09:14] rawang: are you sure you have specified correct dependencies? [09:15] rawang: and in regards with mono directhex is the best person to ask for help. [09:19] slytherin, he saw, and I've tried his suggestion with no luck [09:19] E: installing Assembly /usr/lib/mono/accessibility/UIAutomationProvider.dll failed [09:19] ppa just say it failed, but without any details about why it failed [09:20] slytherin, would PPA be more verbose when building a package? [09:20] s/would/Could/ [09:20] I have a question, in Ubuntu there are geda-* (version 1.4.x) source packages , currently geda upstream unified all source tarballs into one (using a unified build system), and that is in Debian unstable now (and the geda-* source packages got RM'ed), will Ubuntu be able to sync that situation for lucid ? [09:21] rawang: won't make a difference. The failure here is to install one of the build dependencies. Not some problem with package you are trying to build. [09:22] AnAnt: Provided it enters in Debian testing. [09:22] slytherin: ok [09:22] slytherin: and the old geda-* packages would be removed from lucid too ? [09:23] slytherin, yes, that makes sense, but why it failed at installing one of the build dependencies while preparing build environment? do you have any idea? :) [09:23] AnAnt: Ubuntu archive admins keep watch on removals in Debian and carry out same removals in Ubuntu too. [09:24] rawang: Nope. I don't do mono development/packaging. [09:24] good, thanks [09:24] slytherin, k, but thanks all same :) [09:27] slytherin, btw, would you have a chance to sponsor my package? i have been waiting for almost 7 month..... https://bugs.launchpad.net/ubuntu/+bug/380496 [09:27] Ubuntu bug 380496 in ubuntu "[needs-packaging] strongwind" [Wishlist,New] [09:30] rawang: I work mainly on java packages. And I usually stay away from python. So can't help here. :-) [09:30] slytherin, alright, so who is the right person that i'd better to ask? :) [09:31] Can't say. [09:32] slytherin, np, thanks a bunch :) [10:56] porthose: I've added a comment to your merge proposal for bpython [10:56] * porthose looks [11:04] geser, I will look into it when I wake up, the sun is coming up and I should really get some sleep first before I mess with it :) [11:04] ok, no hurry and sleep well === menesis1 is now known as menesis === ogra_ is now known as ogra [12:42] can anybody suggest a simple python setuptools-based package to crib from? What do people do to exclude debian/ from the setup.py sdist generated orig.tar.gz? [12:46] jjlee: you're probably better off asking #debian-python @ oftc [12:46] thanks [13:29] are SRU's also sponsored? or need to be [13:31] yes [13:34] aha.. can someone sponsor https://bugs.launchpad.net/bugs/350562 [13:34] Ubuntu bug 350562 in gdesklets "gdesklets requires python2.5 without package dependency" [Undecided,Fix released] [13:34] ? [13:34] needs sru ack first [13:35] so sru acks, then it goes into sponsering then magic happens and everyone is happy [13:36] that's the idea [13:36] k [13:36] (if you subscribe the sponsor team) [13:36] sru doesn't do that? [13:36] i'll keep an eye on my mailbox then [13:36] i wouldn't count on it [13:38] thnx [15:10] superm1, i have you now... [15:11] the answer to the question why is libvdpau in the depends field in my 190 driver is that i based it on *your* 190 driver, and it is in the control file there [15:11] observe: [15:11] http://launchpadlibrarian.net/35457837/nvidia-graphics-drivers-190_190.42-0ubuntu1%2Bppa2.diff.gz [15:12] Depends: nvidia-190-kernel-source (>= 190.42), libvdpau, x11-common (>= 1:7.0.0), ${shlibs:Depends} [15:17] hello, I am trying to get into ubuntu development and packaging. I am looking at the motu TODO for ideas. I figured I can work on stuff in harvest (more spefically patches) does that make sense? [15:21] yes you can review patches, convert them to debdiffs and ask for them to be uploaded [15:22] joe____, you can also have a look at build failure, and you should also have a look at the sponsorship process, to know how to 'submit' your work for sponsorship [15:22] (see topic for 'hot' topics ;-) ) [15:22] Hey randomaction ! [15:22] :-) [15:23] I still hate baazar for sponsoring :-) [15:24] hello fabrice_sp [15:24] I get slowly used to it (if I don't stumble across bugs or out-of-date branches) [15:25] build-from-branch should change the game [15:25] is there a roadmap for it? [15:25] I still think it's slower than sposoring a debdiff, and people don't review the previous changes as they should [15:26] i look for build failure at debcheck on qa.ubuntuwire.com right? [15:27] joe____, http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi is more up-to-date, IIRC [15:27] fabrice_sp: that are the results from lucas' last archive rebuild [15:28] the current archive FTBFS list is at http://qa.ubuntuwire.com/ftbfs/ [15:28] geser, I remember reading that the lucas's list was more accurate [15:29] Anyway, I may be wrong or misunderstood [15:29] the official one lists only half as many packages [15:30] you probably need a combination of both lists: lucas to see what would fail in a archive rebuild and the other to see what is also currently failing to build [15:30] I think it's because packages which were not modified in this cycle weren't rebuilt [15:30] yes [15:30] the archive will be rebuilt as soon as auto sync stop, right? [15:31] I remember some comments saying that in this cycle, we won't deliver binaries that won't have been rebuilt at least once [15:31] don't know when lucas planned the next archive rebuild, but short after DIF would be nice [15:32] fabrice_sp: we won't ship binaries that fail a rebuild test [15:32] there was a proposal by ScottK to rebuild everything and remove binary packages [15:32] if the package was last modified in e.g. hardy but still builds it's ok [15:33] very good idea, IMHO [15:33] well in the one that fabrice sent me for example there is a failed build in f-spot but in the ubuntuwire one that doesn't exist and on LP it says it built [15:33] randomaction: yes, but we won't do (source-)uploads to test for it [15:34] sure [15:34] joe____: that only means that it build once in the past but not anymore [15:34] joe____, it means that f-spot now FTBS, but not when it has been uploaded [15:34] too slow :-) [15:35] gotcha, thanks [15:37] by the way, that proposal was to rebuild+remove at the very beginning of the cycle, and it didn't happen, did it? [15:38] AFAIK, no [15:39] no, it didn't happen yet [15:39] next logical point to do it is DIF [16:03] randomaction: The rebuild happened, but the analysis results aren't complete. [16:04] you also need to check if you don't break other packages with removing a binary (and what to do about it) [16:11] is it just me, or some Debian package branches are not up-to-date? [16:11] it's not only you [16:15] see http://package-import.ubuntu.com/failures/.bzr/failures/ for a list of packages where importing failed [16:15] fabrice_sp, i see you reassigned yourself bug 495998. It is because I completely did it wrong or because you're looking at my merge request? :) [16:15] Launchpad bug 495998 in resolvconf "Please merge resolvconf 1.45 (universe) from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/495998 [16:18] geser: when is DIF? [16:19] lucas: mid-february [16:19] ok, I can do another rebuild before that too [16:19] lucas: around Feb 11th 2010 (https://wiki.ubuntu.com/LucidReleaseSchedule) [16:21] lucas: ah you are mighty Lucas Nussbaum :D huhu there [16:21] geser: ~aloha~ [16:22] sebner: Hi [16:51] whats the single best resource for doing merges with bzr? [16:51] how about adding reference to that to the merges.html page on ubuntuwire.com? [16:53] asac: probably this: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging [16:54] lucas: ^^ [16:58] ok let me check [17:01] so we are going to native package everywhere? [17:01] ugly imo ... but well [17:02] asac: before you start check that the debian branch is up-to-date [17:02] sure [17:07] asac: what makes you think so? [17:08] the fact that i only looked at resolvconf [17:08] ;) [17:08] asac: btw, are the Xb-Npp- flags in the mozilla-plugin-vlc package still of any use in lucid? [17:08] so how dose bzr bd spot the pristine-tar thing? [17:09] siretart: why wouldnt they? [17:09] we still have a plugin DB ... and we will in future [17:09] cyphermox, working on the merge :-) [17:09] you can put that into debian directly imo [17:09] it doesnt hurt and debian is slowly accepting innovation ;) [17:10] fabrice_sp: for me it looks good [17:10] (the merge) [17:10] I just got this error even though I just deleted the package from my PPA: [17:10] File python-figleaf_0.6.1.dev-20091230.orig.tar.gz already exists in PPA for python-figleaf, but uploaded version has different contents. [17:10] asac: I've just uploaded 1.0.4-1 to debian and could have just added them, but I have no idea what package/program uses that information [17:10] jjlee: deleting doesnt remove origs [17:10] asac, I'm fixing the postrm script [17:10] asac: why not? [17:10] siretart: its used to populate the online db for plugins [17:10] otherwise, looks good, yes :-) [17:10] asac: could you perhaps file a wishlist bug in debian with that information? I'll add that then to our git branch so that it can get included in vlc_1.0.4-2 [17:11] asac: in this case, it's an orig I built myself [17:11] so based on that the firefox plugin finder can show proper debian packages for mime-types [17:11] what's 'the online db'? [17:11] siretart: since you apparently do the merges in debian, i am sure you will remember on next merge ;) [17:11] siretart: its an online webservice that gives info what plugins exist for a given mimetype [17:12] so you get choice for flash: gnash, swfdec flashplugin [17:12] nonfree [17:12] etc. [17:12] and for all the other mime types we have [17:12] mozilla has its own online webservice, but since they have exactly one plugin in there, we run our own in ubuntu [17:13] like http://people.canonical.com/~asac/pfs/screens/pfs1.png (old screenshot from gutsy iirc) [17:14] jjlee: well. that means you first uploaded an orig that was different to the one you now try to upload :) [17:14] if you create the same orig two times thats usually the outcome [17:14] so you need to get the orig from the ppa somehow [17:14] (check the pool) [17:14] or you need to artificually bump the upstream version [17:15] asac: think I'll bump upstream, or it will get annoying [17:15] why? [17:15] just download the orig from pool ;) [17:15] and use that [17:15] but your decision ;) [17:15] as long as its not a package in real archive it doesnt really matter what version it is [17:16] asac: no, please still file a wishlist bug with references to this online db, I'd like to read more about it and add some lines for that in the package [17:16] ;] [17:16] siretart: there isnt much info about that online db, except the initial spec. [17:17] its really old mozilla stuff that we just host on our own now [17:17] and we could host for debian [17:17] too [17:17] asac: now you confuse me again. are these flags useful for a package in the debian archive at all or not? [17:18] they dont hurt. and if debian wants to adopt it we can use those flags [17:18] if it means that you can sync [17:18] its good to just add them to debian without thinking [17:18] if you have to merge anyway, then its not important until we decide to bring this service to debian [17:19] I cannot sync anyway, because debian does not have libx284 (anymore) [17:19] so no. atm, it doesnt give any benefit for debian except that you can sync if you add the flags there [17:20] then dont bother. we would file bugs if we start a service like that in debian anyway [17:20] ok, so in short: we have some magic webservice running on some ubuntu server that the firefox package uses to detect that mozilla-vlc-plugin could be useful for some mimetypes in the firefox package, right? [17:21] yes [17:21] we have that for all plugin packages [17:22] its potentially useful for all browser that can make use of nppapi plugins [17:22] why not package that database? I cannot imagine that there are frequent updates to that [17:23] there are [17:23] also the whole online lookup stuff is already in firefox [17:23] so we just extended the same mechanism [17:24] aha [17:25] also it merges results from the mozilla webservice [17:25] so you get mozilla results + our results [17:27] the url to the service is in the firefox pref called: pfs.datasource.url [17:27] the webservice and database population code is currently in the ubufox source [17:30] asac: does PPA system keep source packages forever? [17:30] it keeps the memory of them forever, yes [17:30] oh, just the hash? [17:44] bjsnider, ah well that's totally a mistake then :) where did i have that published? === yofel_ is now known as yofel [17:46] superm1, in your ppa [17:47] jjlee: usually you remember to be more careful about origs in future after oyu bumped into this ;) [17:47] bjsnider, ah i just used that for staging a while back, i'll delete it from there [17:47] i'm planning on switching things over when alberto gets finished with the new scripts [17:47] jjlee: just like in real "archive" life ;) [17:47] asac: or you just say heck, Irebuild the thing [17:47] *I'll rebuild the thing every time [17:48] siretart, should mplayer in karmic be able to play wmapro audio files? [17:48] jjlee: rebuild? [17:48] bjsnider, in the interim can you just drop that dependency? [17:48] it will keep people sane and prevent upgrade problems when they're using the mythbuntu PPAs [17:48] asac: a new .orig.tar.gz every time [17:48] why? [17:48] thats exactly what is causing the problem here ;) [17:48] dont rebuild origs ... reuse them [17:48] superm1, sigh [17:49] bjsnider: not sure, I don't think i have samples on my lapotop to test [17:49] won't cause a problem if it has a different upstream version (which it does, in build I just submitted) [17:49] sebner: yes? [17:49] well, at least i wouldn't have to upload a new source tarball [17:49] bjsnider, we unfortunately get people trying all sorts of wacky combinations like that and reporting bugs :) [17:49] siretart, i have one i can send you a link [17:50] bjsnider: how about you try yourself? ;-) [17:50] asac: it's a useful feature for a package that has any visibility of course, but for this little PPA I've not told anybody about, it was just irritating :-) [17:50] siretart, i did. it failed [17:50] but rvm's ppa has an older mplayer that supposedly works [17:51] i think he's using internal libavcodec [17:52] siretart: hmm, might work here as well. I was told that you might be able to help me as you are related to sound stuff. The problem is burning stuff, to find out if a) the burner dies b) ubuntus fault or c) of the CDs [17:52] superm1, is the vdpau nvidia driver pre-built? we don't build it against the libvdpau.h file? [17:53] sebner: puh, I'm not sure what makes you think I was qualified for these questions.. ;-) [17:53] bjsnider, the closed source libvdpau_nvidia, yes it's prebuilt [17:53] bjsnider, the libvdpau drivers for all other applications using libvdpau will need to build against libvdpau.h [17:53] so how do we know which version of vdpau they built it against? [17:53] bjsnider: perhaps the auto detection of mplayer is a bit wacky. try forcing the available codecs to see if one of them works [17:54] siretart, interesting you say that because it does say it has codecs for those files [17:54] bjsnider, at this point it's "whatever was latest", but its irrelevant since their API for using it hasn't changed [17:55] Hi All, Someone could upload a patch (I can provide it) for updating linux-rt package? Thanks in advance! [17:55] ^ I meant for Lucid. [17:55] bjsnider, so 190.53 will work with the latest libvdpau, 0.3-2 [17:56] abogani: Are you an Ubuntu Studio developer? [17:56] by the way, what's the policy about upstream maintainers maintaining (non-native) debian packages? [17:56] ScottK: Yes. [17:56] jjlee: what do you mean=? [17:56] jjlee: There isn't one, but we generally encourage it. [17:57] jjlee: in general we encourage upstream folks to maintain their stuff in ubuntu directly [17:57] ok [17:57] superm1, is alberto ever in any of these channels? there's some info in the new control files that needs to be changed [17:57] abogani: I'd ask TheMuso to upload it since a: He can and b: he's involved in Ubuntu Studio. [17:57] its just that usually we do that as a service for them [17:57] by "in ubuntu", you mean that the package is uploaded to universe / multiverse, I guess? [17:57] yes [17:57] also main [17:57] cool [17:58] jjlee: Even better to maintain it in Debian so more people benifit from your work. [17:58] right ;) [17:58] but step by step [17:58] ;) [17:58] ScottK: sure [17:58] asac: quite! [18:15] bjsnider, he's in #ubuntu-x when he is [18:16] tseliot is his nick === jMyles_ is now known as jMyles [18:23] geser: Are you around? [18:28] dabaR: yes [18:28] Cool. I have a follow-up question on our conversation from yesterday. Once you decide on how to fix some package, like atheist from yesterday, what is the process to get it applied? [18:29] For the fix to make it into Ubuntu [18:29] dabaR: Attach the fix to a bug and subscribe ubuntu-universe-sponsors to the bug. [18:29] (assuming the package is in Universe/Multiverse) [18:30] ScottK: so there is a bug for each of the FTBFSs? [18:30] dabaR: https://wiki.ubuntu.com/SponsorshipProcess [18:30] dabaR: As a rule, no. You need to file one. [18:30] dabaR: no (unless you file it) [18:32] ScottK: So maybe, to start working on a FTBFS, you search whether there is a bug for it, and then you file a bug if there is not, then you make the changes, and attach a fix to the bug, and then subscribe the appropriate sponsors team? [18:32] dabaR: Yes, although there's really no point in filing the bug until you have a fix. [18:33] ScottK: how do you avoid working on the same bug as someone else? Does it just generally not happen? [18:33] dabaR: It happens every now and then, but there's 20,000 packages in Universe. [18:33] Not so many FTBFSs in Lucid ATM, though, right? [18:33] True [18:34] Still it's uncommon that two people work on the same thing. [18:34] But it is not a problem you have identified, right? I understand you are very involved in MOTU [18:34] but still more than person working on them [18:34] I meanm, you work on it quite a bit [18:34] dabaR: It happens, but rarely. Yes [18:34] IMO it's more work to document what everyone is working on than is saved by it. [18:35] ScottK: And ubuntuwire FTBFS page, how often are new builds done? [18:35] the page itself is updated every 4 or 6 hours (don't know exactly) [18:35] qa.ubuntuwire.com/ftbfs is based on the current state of the archive. [18:36] So it only changes when a new package is uploaded or a build attempted. [18:36] So it polls for changes in the archive? [18:37] yes, it asks LP for all current builds that FBTFS and displays it in a nice overview [18:37] So Launchpad tracks similar information, do you know the URL for that? [18:38] it tracks it on per-package basis so there is no overview [18:39] Oh, OK, probably to do with how the packages can be tagged with releases... [18:39] dabaR: see e.g. https://edge.launchpad.net/ubuntu/+source/atheist/0.20091130-1 (look at Builds) [18:40] geser: how would you reproduce that bug on your system? [18:40] I mean, how would you try TBFS and fail? [18:41] I use pbuilder (others prefer sbuild) [18:41] geser: what about starting from open terminal [18:42] Do I apt-get source atheist? [18:42] And go from there [18:42] yes [18:43] but I prefer using pbuilder for test-building to not pollute my system with -dev packages that I won't need a few minutes later anymore [18:44] so what command do you run? [18:44] pbuilder atheist? [18:44] !pbuilder [18:44] pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto [18:45] Thanks [18:45] "apt-get source -d atheist" (don't unpack) and later "pbuilder build atheist.*dsc" [19:24] Where does dh_clean get defined? [19:25] /usr/bin/ ? [19:25] dh_ which one [19:26] I mean, there is no dh_clean in /usr/bin on my computer./ [19:26] dabaR: debhelper package [19:29] What creates a .dsc file? [19:29] is it dpkg-source? [19:32] I mIt is [19:41] So when I build a package with pbuilder, I specify the .dsc file, but the output seems to "dpkg-source: info: extracting atheist in atheist-0.20091130 [19:42] Unpacks the orig tarball, and applies the diff. [19:42] Where do I apply the changes I make to the source package I downloaded? [19:42] In the unpacked directory that is in the same place where the orig and diff files are? [19:43] Or does that get overridden as shown in the pbuilder output? [19:44] OK, I think I got it. I make the changes in the unpacked dir, then I pdebuild, right? [19:46] So pbuilder creates a build environment for itself, right? [19:46] yes, or you can debuild -S, which will create .diff.gz and .dsc which you feed to pbuilder [19:47] pdebuild gives me errors about unmet dependencies. Should I somehow edit .pbuilderrc? [19:47] To point it to my base.tgz, or something? [19:48] did you enable universe in pbuilder? [19:48] Dunno [19:49] I will now [19:49] PbuilderHowto has a section for it [19:49] I see it in the howto [19:49] it's off by default, so you need to do it if some of build-deps are in universe [19:51] I've got a .build file now. [19:54] randomaction: do you use pbuilder? [19:54] yes [19:56] So I have modified my .pbuilderrc and still there is an error about unmet dependencies. [19:56] Is the command just pdebuild? [19:58] pdebuild I don't use :) [19:58] Should I just install its build dependencies? SHould I use the satisfy dependencies flag? [19:58] Oh, I see. [19:58] so, you enabled universe? [19:58] AFAICT [19:59] try to create a source package (debuild -S from the package directory) [20:03] So I have to have a valid GPG key to build the package? [20:04] In fact, why is it trying to sign with someone else's signature [20:04] no, if you don't you'll just be making unsigned packages [20:05]