[00:00] this package you are working on uses quilt. So if you touch the upstream source (i.e. outside /debian) you need to do so with a quilt patch [00:00] Oh hang on...I just noticed /deb/patches/deb-changes-version [00:00] this is why it generated a quilt patch for you [00:00] tumbleweed: Right I understand, but what I don't get is _how_ do I do that? [00:01] first it helps if you are aware that this is going to happen, so that you can create the patch with quilt rather than have it create it for you [00:01] tumbleweed: I think I've got it on my own, cn I pastebin you the diff? [00:01] have a look at that wiki page again now [00:01] sure [00:02] I redone it again from scratch and used quilt to make a new one and refresh, rebuild, redebdiff [00:02] http://paste.ubuntu.com/517741/ [00:03] It looks like a "normal" one now [00:04] that's better. Bonus points now is a DEP3 header on the patch. http://dep.debian.net/deps/dep3/ [00:04] Bloody hell, I've had a couple of drinks I shouldn't be doing this :P [00:04] I'll take a look :) [00:04] Also, instead of "debian/patches:" in your changelog entry just put teh patch name, "libs.patch" [00:04] err libs.diff [00:04] Ok :) [00:04] yeah I've been out tonight too :P [00:05] hehe [00:05] Nah, I'm still drinking at home, so much cheaper [00:08] tumbleweed: That page is REALLY confusing, I can't make anything of it [00:09] it helps if you've seen an example [00:10] I've seen the examples at the bottom but they're not much use [00:10] Look in your previous debdiff http://launchpadlibrarian.net/57986452/debdiff [00:10] you can see it has a description, an author, and it links to the bug [00:10] the only issue is that the description is long and not very useful [00:12] So copy and paste desc, author, bug-ubuntu to the top of libs.diff? [00:12] And amend those as needed? [00:12] well, not necessarily copy-paste, but that's an example of what you want [00:12] But where does it go? [00:13] in the top of the patch, before the first hunk [00:13] So after Index: ... but before ============= ? [00:14] http://paste.ubuntu.com/517749/ libs.diff [00:14] actually both index and ====== are unnecessary, they are the current header [00:15] So it goes right at the top? [00:16] yup [00:16] no # for comments or anything, just plain insert? [00:16] well amending things that need it obviously [00:16] correct [00:16] another hard way of doing something relatively simple ;) [00:16] "quilt header -e" is an easy way to edit this [00:19] tumbleweed: http://paste.ubuntu.com/517751/ what do we think? :) [00:19] looks great [00:19] time to rebuild and redebdiff :) [00:23] ok, bug 664662 updated :) [00:23] Launchpad bug 664662 in tea (Ubuntu) "tea FTBFS on natty" [High,Triaged] https://launchpad.net/bugs/664662 [00:23] and _should_ be done correctly [00:24] tumbleweed: As usual, thank you for the great help :D [00:24] It's not that difficult really when you get into it, probably helps I learn quite quick [00:27] xteejx: no problem. BTW don't report debian bugs as FTBFSs (with RC severities) unless they ftbfs on debian [00:29] oh :S [00:29] As an ubuntu dev contributing upstream, you want to be helpful, not an irritation :) [00:29] Just report ftbfs and leave the severity? [00:29] well, in this case it's only going to be an issue when debian has binutils-gold [00:29] Well, only report a Debian bug if there's a bug in Debian :-) [00:30] maxb: debian *is* collecting binutils-gold bugs [00:30] So how should we forward patches? I mean the ideal subject line? [00:30] but they aren't RC because tehy aren't failures yet [00:31] PKG fails to build from source in Ubuntu << ?? [00:31] xteejx: see these ones: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=no-add-needed;users=peter.fritzsche@gmx.de [00:32] when it loads..... :P [00:32] no, the debian maintainer quite likely isn't interested in hearing that ubuntu has a problem. [00:34] tumbleweed: So "at the moment" [00:34] oops [00:34] So at the moment, FTBFS withbinutils-gold is a good subject line if it's a linker prob? [00:34] if I type it right of course ;) [00:35] sounds good, and even better, usertag the bug like the other ones [00:35] as in? [00:36] http://wiki.debian.org/bugs.debian.org/usertags [00:36] you can see it in the psuedo-headers of those bugs [00:36] ohh Tags: patch [00:37] no, Usertag [00:37] no-add-needed? [00:37] yeah, but it also needs the corrosponding user [00:38] Huh? [00:38] debian's BTS has predefined global tags (like patch) and user tags. You can make up any tag you want, and associate it with your e-mail address. In this case, binutils-gold bugs are being tagged no-add-needed, against the address peter.fritzsche@gmx.de [00:39] So I shouldn't use no-add-needed because he'll be pi**ed off at being emailed?? [00:39] I don't get you [00:40] no, it doesn't have anything to do with e-mailing him [00:40] it's just a way to let everyone make up their own tags. [00:40] Do I *have* to use the usertags? [00:40] it is helpful to tag related bugs like that, that's how I was able to show you that list [00:41] anyway, off to bed. night. [00:41] lol goodnight mate, thanks again :) === emma is now known as emmaldp === emmaldp is now known as emma === ubott2 is now known as ubottu === MTecknology is now known as AFWEG43y6t23yt2t === AFWEG43y6t23yt2t is now known as MTecknology [06:33] are we pulling from unstable or testing for natty? [06:34] paultag: unstable [06:34] micahg, awesome, thanks. [06:35] paultag: you can even request from experimental if need be [06:38] micahg, nah, it's OK. I just got a packaged uploaded to deb, so I was trying to think ahead for the sync [07:47] Good morning! === hrw|gone is now known as hrw === gaspa1 is now known as gaspa [12:21] cjwatson: do you planning merge package db in universe? [12:21] It waiting so long for merge [12:24] ari-tczew: yes, I do [12:24] cool [12:25] and to forestall future questions, I plan to do all my merges :) [12:25] cjwatson: during natty? [12:25] yes. [12:25] cjwatson: I suggest to comment on MoM, that you will do this merge, where are you as a last uploader [12:26] no need; that is implicit. [12:27] cjwatson: I just want to avoid questions like mine some minutes ago :) [12:27] I'm not going to waste time adding comments to every one of my merges; sorry. I'd rather spend time doing merges, which I am actively doing right now [12:29] besides, I don't get that many questions about it [12:30] cjwatson: ok, I didn't want being you an upset [12:31] you didn't [12:39] ari-tczew: The way to avoid such questions is not to ask them. Up until DIF, if someone is active in the project, you should assume they will do their merges. It would, however, be valuable to seek out merges of people who have are not active in the project anymore and have sat there for a while. Pinging those people would be useful. [12:42] ScottK: and I practice this one. when I see that latest merge is done by John Don (it's an example), then I'm owning this merge [12:43] hmmm, python3.2 is blocking builder [12:45] ari-tczew: John Dong? [12:46] ScottK: John Doe. my typo [12:53] Who will I have to talk to about packages.ubuntu.com updates? It seems like djpig is still not responding/reachable at all unfortunately, and I'd be interested to get the service updated nevertheless. People started to address me with respect to screenshots addition, e.g. [13:05] Rhonda: do you want to be a maintainer of packages.ubuntu.com? would be nice! [13:05] it has to be updated for natty [13:06] ari-tczew: The commits are already done. [13:08] Rhonda: and what's the next step? approve by admin? [13:09] That's my question about. Frank, who seems to be the only person having access (appart from canonical sysadmin team of course) didn't respond since over a year. [13:10] Alright, probably less than a year, but not much [13:10] Rhonda: so... let's ask canonical sysadmins :) [13:11] or maybe dholbach knows? ^^ [13:18] fabrice_sp: you don't use syncpackage? [13:51] BlackZ: err I've just uploaded qtiplot (which you've just marked in progress) [13:55] tumbleweed: heh, no problem ;) [13:55] ari-tczew: If you want to steal xine-lib, feel free. [13:55] ScottK: I tried this one some time ago and it's not for me. :) [13:56] ScottK: I can take a look on FTBFS as we had discussion some time ago, do you remember? [13:56] OK. [13:56] I vaguely remember. [13:57] ScottK: adding libs to LDFLAGS. if you have more, ping me [14:03] OK. [14:09] ScottK: do you have a min to hop into kubuntu-offtopic someone has a serious show stopper kernel issue with maverick [14:10] nm hes here :) [14:10] welcome BluesKaj :) [14:10] howdy folks , dpkg locks my system trying to install a kernel module/linix image that seems non-existent ...any ideas? [14:11] hi eagles0513875 [14:12] does linux-image 2.6.32.24 generic actually exist ? [14:13] if i am not mistaken it exists on lucid [14:13] let me hop on my server [14:13] BluesKaj: its a lucid kernel [14:14] BluesKaj: and you basically upgraded from lucid to mav [14:14] * eagles0513875 always runs into issues with the upgrades [14:14] eagles0513875: It's really a support question and not an area I'm an expert in. [14:15] ScottK: i know Riddell is probably swamped with work but is he around to help him possibly [14:15] BluesKaj: i forgot entierly there is an ubuntu-kernel channel [14:16] this was on maverick, I did the alterhnate install to / , due to the fact my new graphics card required it, there weren't any proper drivers available [14:19] cjwatson: could you check why package earcandy is not getting by MoM? [14:23] ari-tczew: it is, on https://merges.ubuntu.com/universe-manual.html [14:26] geser: It would be useful to have a link to that page off m.u.c. I didn't even know that existed. [14:28] ScottK: I guess the index listing on m.u.c doesn't count (the other components have a "manual" page too) [14:29] What determines whether a merge lands on that page? [14:31] what is m.u.c? [14:31] merges.ubuntu.com [14:31] so MoM [14:31] Laney: based on the versions on that page, my guess is those are packages which were packaged in Ubuntu first [14:31] yes [14:32] geser: yeah, looks that way doesn't it? [14:32] Would have thought there'd be more though [14:32] manual merges are ones where the automerger just broke. [14:32] Usually orig conflicts, or weird version changes, etc. [14:33] (there's a correlation with things in Ubuntu first, but not a direct causation) [14:35] that's not quite right [14:35] manual merges are ones where there's no base version [14:35] i.e. the Debian and Ubuntu packages share no common history [14:37] thus is my understanding anyway [14:37] which would happen with packages that were in Ubuntu first and Ubuntu hasn't merged / synced from debian yet [14:39] Also happens for stuff that has been merged once sometimes, if the changelogs are sufficiently confusing. [14:39] ah, it resolves using the changelog [14:40] ari-tczew, no, I don't know [14:40] I believe so. I may be mistaken. [14:44] ScottK: I've added links. [14:55] cjwatson: Thanks. [15:23] DktrKranz: how it's going about gnustep-base? I see that you've already sync'd it. what about rebuilds? [15:24] ari-tczew: it needs to clear binary NEW on all architectures first, then -gui and -back have to be built (and clear bin-NEW again), after that rebuilds can start [15:25] yeah, it's a bit complicated :) [15:25] Riddell: I just stumble across bug #607094 [15:25] Launchpad bug 607094 in spacenavd (Ubuntu) "Please sync spacenavd 0.4-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/607094 [15:26] if it's ok with you, I can sync it [15:27] debfx, Better to let archive-admins do syncs. [15:27] (Yes, this would be nice to fix, but LP doesn't support it yet, and the hack requires cleanup afterwards) [15:27] persia: why? [15:28] Something to do with how the archive is constructed on the archive master. [15:28] I'm not an archive admin, and don't understand the details, but I've been told this continuously since I first thought it would be nifty to hack Origin back in feisty. [15:28] I know there's ongoing work to make it so we can just press a button and LP does all the right stuff, but it's not ready yet. [15:29] So for now, best practice is just to file confirmed bugs and subscribe the archive-admins. [15:29] what's the disadvantage of syncpackage? [15:29] debfx: there's a concern that it's an unecessary round-trip trhough a developer's personal machine [15:29] It messes up some indices somewhere and requires someone to sort them out. [15:30] Sorting it out isn't hard, but still. [15:31] well either it's acceptable to use syncpackage or it should be removed from ubuntu-dev-tools [15:31] If you want all the grubby details, the folk in #launchpad might know, and a fair number of them were raised in the discussion about syncpackage by some of the archive admins who responded. [15:31] persia: that suprises me (never heard anything about this before) - but I also don't know the archive internals. archive-admins also tend to be quiet whenever anyone brings syncpackage up [15:32] Nobody wants to have the argument. Technically, it's not that much harder for an archive admin to clean up later than to perform the syncs in the first place. [15:32] debfx: this is an on-going debate, there's no paticular problem with syncpackage but some people feel it might increase the chance of a problem occuring [15:32] tumbleweed, Yeah, archive admins tend to be busy and not want to get into the argument as to why it's a bad idea. [15:33] persia: fair enough. But it does seem odd that we have a tool that we 'shouldn't" use [15:33] debfx: I'm happy for it to be synced [15:33] We've had the tool since edgy or so. We kept it out of ubuntu-dev-tools for the longest time, but someone stuck it in after discussion during which nobody listened to the archive-admins. [15:34] well, it is of course useful for fake syncs [15:37] I really think we should add a warning section to the manpage, listing the concerns, not FUD, then we don't have to have this discussion every other month [15:44] For fake syncs, we shouldn't be using it anyway. Fake syncs should be Origin: Ubuntu. [15:44] Anything else falsely implies we got the package from Debian. [15:47] if it adds origin: debian when fakesyncing that would be a bug (I don't know that offhand) [15:48] syncpackage wasn't designed for fakesyncs [15:51] of course. Personally I used it because I wasn't compelled by the arguments against using it, ack-sync made it mostly-safe and convenient, it would save archive-admin time, and it would get the sync done now (which is an issue around freezes) [15:52] however archive-admins don't complain about not having time, and ack-sync now can ack without syncpackage-ing [15:53] And archive-admins often pay special attention to seeded syncs during freezes (unseeded syncs get delayed, but they are rarely as time-critical) [15:59] cjwatson: could you remove nvidia-settings from MoM/main ? [16:01] tumbleweed: what's ack-sync? [16:01] debfx: it's in ubuntu-dev-tools source package, a tool that pulls source, test-builds, and asks you if you want to ACK [16:02] tumbleweed: quiet? hmm. I complained about it nearly every time it was brought up for quite a while. I gave up because who wants to be the guy who just sits there complaining all the time? [16:02] cjwatson: :) Well I only arrived on the scene after it already existed and was well known [16:03] ari-tczew: done [16:03] thanks [16:06] persia: why does syncpackage messes up some indices? [16:07] bdrung, I don't know the details. [16:07] I'd encourage you to read through cjwatson's complaints before he gave up complaining, as those are surely more accurate than any information I can provide. [16:10] who has upload access to multiverse? core-dev? [16:10] * micahg thought MOTU did [16:10] ari-tczew, Different groups of folk. You probably have upload rights to most of it. [16:11] micahg, Not exclusively: some of Mythbuntu is in multiverse. [16:11] persia: right, but has that restriction of partial pocket access been implemented? [16:11] persia: ah, my bad. I saw that fabrice_sp has uploaded package @multiverse, but sponsored by dholbach. I've looked on the date and now I know, that in those days fabrice_sp wasn't yet in MOTU. [16:11] micahg, No, hence "not exclusively". [16:11] * micahg thinks pocket is the wrong tem [16:12] *term [16:12] "component" [16:12] ari-tczew: multiverse access control is equivalent to universe, unless other package sets are involved [16:12] thanks [16:13] my complaint about syncpackage was essentially that a sync constitutes a promise that this is a verbatim copy of the package from Debian. Given that there is no monitoring of whether that's actually the case, I think it's less risky to have the copy be done centrally rather than going through client machines. I would love developers to be able to press the button rather than it having to go through archive admins, but I ... [16:13] ... want it to be a button that creates a new publication record, rather than involving downloading/uploading the package. [16:15] cjwatson: obvious response: given that syncpackage doesn't alter the checksums in the dsc file, the upload would be rejected if the package was modified. [16:15] It's on the LP roadmap. Mostly needs a couple jobs to run to clean up some other bugs, and then can be enabled. [16:15] tumbleweed, But we can't prove that. [16:16] cjwatson: agreed. once we have the LP button, syncpackage will be changed to trigger the sync through launchpadlib. [16:16] I'm not arguing that we don't want to be able to do it centrally, as soon as LP can support it. [16:17] cjwatson, bdrung: http://paste.ubuntu.com/518106/ ? [16:17] I'd find that an improvement, yes [16:17] tumbleweed: yes [16:18] persia: if users have the ability to upload to ubuntu, they can break things. Actually managing to break things with syncpackage (esp ack-sync + syncpackage) would require concerted effort [16:18] tumbleweed: maybe document the future plans, too [16:18] bdrung: Now we just need someone to write the soyuz patch. [16:18] err yes [16:18] ScottK, We have most of that. The main blocker is some DB/librarian cleanup, which needs a job to run. [16:42] bdrung: what is the command for fakesync? [16:46] Riddell: you want to get synced knmap, but it's FTBFS [16:47] http://paste.ubuntu.com/518120/ [16:58] cjwatson: could you also take a look on bug 636636 ? I see that you're working on archive. [16:58] Launchpad bug 636636 in gupnp-vala (Ubuntu) "Sync gupnp-vala 0.6.12-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/636636 [17:01] ari-tczew: done [17:02] thanks [17:16] ari-tczew: use syncpackage [17:18] bdrung, We just had a long discussion about that. [17:19] We very actively *don't* want to use syncpackage for fakesyncs. We need Origin: Ubuntu on those. [17:19] persia: syncpackage uses debuild for building fakesync packages. so origin should be ubuntu. [17:20] OK. I just worry about syncpackage, but if it does the right thing, it does. [17:21] persia: use "syncpackage -v" and it will tell you which command are used. [17:22] I get a KeyError for an environment variable I've never set (DEBEMAIL respects the "name name " syntax) [17:22] persia: log? [17:23] http://pastebin.com/5aPhzSMu [17:23] persia: file a bug [17:24] Do you especially want to fix it (am I putting something on your TODO list, or just filing a bug)? [17:25] persia: i will fix it unless someone else wants to do it [17:25] OK. I'll file it when I'm done with the current bug then. [17:30] ari-tczew, I do, but only when needed. why are you asking that? [17:31] fabrice_sp: curiosity [17:35] hello, where can I find the script which imports the gpg keys from LP users in a specific group ? [17:37] I think there are a couple of those. There's one in REVU, at least. [17:38] Or there used to be: it might have gone away with the new authentication model. [17:38] it seems there were some rdf changes and the script I use does not work any longer. [17:38] hm [17:39] REVU will at least have the script to get a GPG key for a single user. [17:39] You probably want to use the API to get the group membership as a safer means (ask for details in #launchpad) [17:41] it is for checking if a user was allowed to upload a package in the build system. we need his gpg key for checking this. [17:46] c_korn, Right. REVU probably has the per-user bit you need (else REVU is also broken). [17:46] For per-group, I recommend using the API to get the members of the group (but ask in #launchpad for instructions) [17:47] ScottK: do you know how fix this FTBFS? http://launchpadlibrarian.net/58037661/buildlog_ubuntu-natty-i386.zvbi_0.2.33-2_FAILEDTOBUILD.txt.gz [17:48] ari-tczew: I get the feeling there's a missing stat.h include [17:48] tumbleweed: heh, but in which file? :) [17:49] the one that uses S_ISCHR [17:49] (I'm a n00b in FTBFS fixin') [17:53] how can I run pbuilder for sid on my maverick? I got the problem: http://paste.ubuntu.com/518144/ [17:55] I import the key into my gpg keyring and do pbuilder create --debootstrap-opts --keyring=~/.gnupg/pubring.gpg [17:57] tumbleweed: thanks, I'll try it later [17:57] wth... yesterday was 180 FTBFS in universe. now it's 61 [18:00] ari-tczew: I think someone did a retry. Look how many pending builds there are. [18:00] ScottK: that's right, builders are busy today [18:00] ari-tczew: I'm not sure on Sid pbuilder. It works here, but IIRC I have debian-keyring installed. Maybe that's the difference. [18:01] ScottK: is it make sense, whether I'll upload some fixes for FTBFS? [18:01] it's about to add missing things to LDFLAGS [18:01] ari-tczew: If they are broken in Ubuntu it does. [18:06] i picked off a few FTBFS yesterday. i wrote patches to fix them, but in one case, sent the patch upstream and in the other, submitted the patch to debian BTS. in both cases, i expect debian to take the patches rather quickly, and then ubuntu can sync from debian [18:06] was my expectation correct? or should i prepare ubuntu debdiffs too, and attach them to the LP bugs i opened? [18:09] achiang: depends on the Debian maintainer. And the current Debian freeze may slow it down too. [18:10] geser: for #664760, i've already been in contact with the debian maintainer, and he agreed to take the patch once it is accepted upstream. although checking qawire, i see that the package has disappeared from the list [18:10] I have found a package for which uscan does not get the latest version, because the debian mirror of sourceforge is not updated since september the 16th. Is the update blocked because of squeeze being frozen? [18:10] it wouldn't hurt to have debdiffs ready in case it takes some time till the fix gets into Debian [18:10] it's muse [18:11] geser: good point, i can attach some debdiffs. i guess i was trying to avoid doing extra work in ubuntu of carrying patches for a little while, and then having to figure out that the patch should be dropped once the fix hits debian [18:12] achiang: there was apprarently some give back today (fossology waits on a new build attempt) so it doesn't get listed currently on the FTBFS page [18:13] achiang: If the package is currently FTBFS in Debian too, then the odds of it getting accepted quickly are good. If it's due to toolchain changes that Debian doesn't have yet, you probably won't see it in Debian until after Squeeze releases (except maybe in Experimental) [18:13] geser: ah, ok. "give back" means re-try build? [18:13] achiang: at the very least it helps to file a bug in launchpad so that other people know what you've done - i.e. that this is in progress upstream (you link the upstream / debian bugs to it) [18:13] achiang: Yes. [18:14] tumbleweed: i did file bugs, one is listed above, the other is #664941 [18:14] achiang: aah missed that, cool. [18:14] fabrice_sp: that would be suprising, file a bug against qa.debian.org? [18:15] ScottK: thank you. the two packages i picked are not FTBFS in debian. based on what you said, I'll prepare ubuntu debdiffs, attach them to my bugs, and subscribe ubuntu-sponsors [18:15] Great. [18:16] tumbleweed, it's http://qa.debian.org/watch/sf.php/lmuse and it indicates "last database update: Sun, 19 Sep 10 06:17:35. How can I check if bug already exists? [18:17] fabrice_sp: http://bugs.debian.org/qa.debian.org (which lists debbug 599064) [18:20] tumbleweed, got it. thanks for the link! This mean that UEHS is not up-to-date either is the project is on sourceforge [18:20] yup :/ [18:28] which debian repo do syncs typically come from? is it possible to request a sync of a package from unstable at some point? [18:28] we sync for unstable by default [18:29] ah, great. and unstable is not frozen, so if i can get a patch to land there, then there really isn't a need to carry an ubuntu patch. [18:30] yes [18:30] we can also sync a package from experimental if needed [18:31] nod. i don't think that will be necessary in my case though [18:31] achiang: Yes, but in Debian it's generally preferred to keep Unstable clear of changes not intended for the next Debian release during the freeze as that's the preferred route for updates to Testing. [18:31] ScottK: but are you sure for fixing FBTFS by flags? maybe next toolchain change and rebuild will fix these FTBFS [18:32] ari-tczew: No. The linking change is by design and permanent. It will also be in Debian for Wheezy after Squeeze is released. [18:32] ScottK: I see, thanks. Learning various project processes is much harder than learning programming. ;) [18:32] achiang: Yep. [18:33] How come a hundred or so FTBFS have disappeared on http://qa.ubuntuwire.org/ftbfs/natty.html [18:33] Were they all done or is the site wrong? [18:35] massive give-back [18:35] geser: What does that mean? [18:35] geser: give-back? [18:35] given back to the buildds - i.e. retried [18:36] Oh, sent back to the autobuilders? [18:36] yip. A bunch will presumably fail again. [18:36] I was just thinking that, wouldn't they just re-fail [18:37] So will, some won't. Depends on why they failed. [18:37] Oh well, even if a few sort themselves out, its better I suppose :) [18:37] brb all [18:38] there's a bug with launchpad not detecting DEPWAIT reliably, so quite a few might succeed [19:01] ScottK: could you take a look on bug 664612 ? [19:01] Launchpad bug 664612 in nvidia-kernel-common (Ubuntu) "Remove nvidia-kernel-common from repositories" [Undecided,New] https://launchpad.net/bugs/664612 [19:02] ari-tczew: I don't have an opinion on it. === bilalakhtar_ is now known as bilalakhtar [19:43] achiang: bug #664941: if you need sponsorship for the upload of that fix, the bug should not be assigned to anyone (please read https://wiki.ubuntu.com/SponsorshipProcess) [19:43] Launchpad bug 664941 in reprepro (Ubuntu) "FTBFS: undefined reference to S_ISDIR, S_ISREG" [Undecided,New] https://launchpad.net/bugs/664941 [19:43] BlackZ: reading now [19:44] BlackZ: ok, i'll go unsub myself, thanks for pointing this out to me [19:45] BlackZ: i'm unsubscribed [19:45] uh, un-assigned, that is [19:46] bug 665276, can someone check the debdiff please? I've remembered and done what people [19:46] Launchpad bug 665276 in webfs (Ubuntu) "webfs FTBFS" [High,Triaged] https://launchpad.net/bugs/665276 [19:46] have advised, and this one is totally on my own [19:48] achiang: also, the package has to go for "natty" and not "lucid". Can you please fix that? [19:49] btw Good evening all :) [19:51] achiang: .. and you have to set "Ubuntu Developers" as the maintainer of the package (you can run the "update-maintainer" script to do that automatically). However commenting on the bug [19:52] BlackZ: hm, i just uploaded v2 of the debdiff which fixes the distro field in the changelog [19:55] BlackZ: ok, i guess i should upload a v3 then? is there anything else i should do? [19:55] achiang: commented on the bug [19:57] 1969-12-31 17:00:00.000000000 -0700 lol :D [19:59] achiang, BlackZ: also in d/changelog should be changed: * debian/patches/filecntl-include-stat.patch: [19:59] ari-tczew: yes, usually I do that commenting on the bug with something like: "Uploaded with a minor correction to the package's changelog file." [20:00] ugh, i kinda botched this one up, didn't i? sorry about this, i'll be more careful next time [20:03] achiang: uploaded [20:03] BlackZ: ta! === yofel_ is now known as yofel [20:05] achiang: however in the future you can consider to use DEP-5 headers for the patches [20:06] DEP3 IIRC BlackZ [20:06] BlackZ: DEP-3 is for patches, DEP-5 is for copyright [20:06] BlackZ: sorry, i don't think i understand. DEP-5 covers copyright? [20:06] oh sorry, I meant DEP-3 [20:06] :) [20:07] * micahg hopes to proposal to give those sensible names is considered again [20:07] achiang: you're right, DEP-5 is for copyright files; I meant DEP-3 [20:07] is there an easy way to generate those headers? what i uploaded was just a raw debdiff [20:08] achiang: please read http://dep.debian.net/deps/dep3/ [20:08] that should really be built into Quilt after the DEP is approved [20:08] xteejx: I suggest to remove Last-Update: and replace by Forwarded: [20:09] BlackZ: yeah, i just read that. looks like the way to generate those headers is by hand. i was asking if there's some handy tool to do that for you, but it seems like not [20:10] achiang: DebSrc format 3 does it for you [20:10] achiang: then you just have to clean it up [20:11] micahg: but what if the package is in 1.0 format? [20:11] achiang: then you have to do it manually :) [20:12] micahg: heh, ok. thanks. :) [20:12] achiang: it one of the reasons to move to source format 3, but that should be done in Debian for shared packages [20:13] nod. [20:13] and according to recent statistics, we're 1/3 of the way there [20:13] achiang: it's not a big deal but I'd recommend you to use the DEP-3 tags for your future patches [20:13] BlackZ: ok, got it [20:25] paultag, quilt header does a fair bit of it. [20:26] persia, ahha. Just found that on the man page [20:28] persia, on another note, I got my first new package into debian :) [20:31] Congratulations! [20:31] ScottK: could you take a look whether I did correctly this one? https://launchpad.net/ubuntu/+source/yaz/4.0.11-1ubuntu1 [20:31] persia, :) === hanska is now known as dapal [21:28] maybe someone else could check whether I added LDFLAGS correctly? ^^ [21:29] ari-tczew: it's usually better to ask before uploading [21:29] It's *always* better to ask before uploading. [21:29] One uploads only if one doesn't need to ask. [21:29] persia: right, heh, sorry :) [21:29] (often because one already has) [21:30] I thought about this case some minutes after uploading. [21:30] * micahg has tried to get out of the habit of using always, but there are cases where it is valid :) [21:30] and please stop attack me, I usually ask [21:30] ari-tczew: not attacking you [21:30] ari-tczew: just reminding [21:31] micahg: calm down, packages are waiting to build [21:31] I can overwrite it right now, so I'm asking [21:32] ari-tczew: no, you can't once it's uploaded and accepted , it's in [21:32] I can't stand warnings if I know about these. [21:32] ari-tczew, Did your test builds work? [21:33] persia: yes! [21:33]