=== asac_ is now known as asac === asac_ is now known as asac === santiago-pgsql is now known as santiago-ve [02:38] anyone seen LaserJock recently? [02:39] he's taking a leave of absence of sorts. [02:40] (so, not in the few days, no) [02:40] One of his usual 'i gotta get out' ones, or something else? [02:40] (;)) [02:41] Heya gang [02:41] hey! [02:41] Hello tbielawa [02:42] bddebian! [02:42] how goes? [02:42] Heya crimsun [02:42] tbielawa: OK thanks, yourself? [02:42] bddebian: super excited. I think i tamed the beast that was packaging 'bibus' [02:42] Nice, congratulations :) [02:43] silly upstream folks and their debianizations... [02:43] I took ScottKs advice and ended up recreating the orig.tar.gz without debian/ [02:44] That's usually the wisest [02:59] Hi! May I ask how long does it normally take a REVU upload to appear on the website? (I've just uploaded two sourcepackages, one of them has appeared, and the other did not) [03:00] artfwo: It usually takes about 10 minutes, but it may be that it didn't get accepted, and REVU is silent on rejections. [03:01] ah, and if it got rejected, how do I know about that? ;) [03:02] artfwo: You don't :) More specifically, you can ask a REVU admin, and if you get one who is better about having ssh keys handy than I, they can look. [03:02] More specifically, which package is missing? [03:04] artfwo: Also, for supercollider, you'll likely get a better response by posting a bug against the package, rather than putting something in REVU. [03:06] * ajmitch sees that it's a package that was removed from debian [03:09] ajmitch: Ought that matter? I acknowledge that supercollider is broken in a significant number of ways, but wouldn't expect REVU to drop it just because it used to be in Debian. Does the package cache need a refresh, maybe? [03:09] not saying that it should be dropped, just that it'd be something to look at closely due to how broken it was in debian before removal [03:10] I just saw the 'repackaged from scratch' in the changelog [03:11] it was logical to repackage from scratch [03:11] the new package is a lot cleaner (cdbs, simple-patch-sys, etc.) [03:11] it builds and runs [03:12] artfwo: In general, it's better to preserve changelog history for upgraders. The rest can be dropped. Also note that you'll need to get an entry into P-a-s before it goes in, unless someone did sufficient engine redesign to make it work for 64-bit architectures. [03:12] I've got a couple of good testimonials: http://artfwo.blogspot.com/2008/04/supercollider-for-hardy.html [03:12] * ajmitch is running revu-key update now, btw [03:12] I've got the changelog history in place [03:12] please sync my key from lp too [03:12] launchpad.net/~tbielawa [03:13] persia_: and what is P-a-s? [03:13] artfwo: In that case, you're likely good. Also woth reviewing the old BTS bugs just to make sure they all got closed. [03:14] persia_: yes, I remember you pointed me to those bugs earlier. As the new upstream has greatly simplified and enchaned SConstruct, the source compiles just about anywhere! [03:14] P-a-s is Packages-architecture-specific, which is a file that is shared between Debian and Ubuntu to control where packages are built and distributed. While much of this can be handled by appropriate use of Architecture: in debian/control, it is very useful in cases where you have a mix of Arch: all and Arch: any binaries that need support, as it's not worth making the arch: all binaries arch-specific just because they are completel [03:15] artfwo: Compiles, sure. Is it 64-bit clean yet? [03:15] persia_: no, but I simply disable sclang with a scons option for amd64 [03:16] artfwo: What about ia64? [03:17] this architecture wasn't among supported arches even for the server in the original package, so I didn't specify it as well [03:17] Hmm.. OK. Ubuntu used to ship supercollider for ia64 (back in the 04xxxx versions), so this is a surprise to me. [03:18] up upstream tar.gz is filled with CVS folders, is it bad practice to remove those? (I'm removing the debian/ folder already) [03:18] tbielawa: Best to do as little as possible. Can you not get away with the --ignore option to debhelper to handle the variation? [03:19] persia_: I'll look at that! thanks for the tip [03:19] persia_: I've got "i386 powerpc lpia" for the sclang and "any" for the server [03:19] tbielawa: For the majority of cases, it allows you to get by even when upstream decides to include a debian/ directory (although it's still good practice to ask them to remove it) [03:20] artfwo: I know a fair number of powerpc people who like to do audio stuff. I'm not sure it isn't also interesting for other architectures. I also heard rumblings about ARM at UDS. [03:20] persia_: while i'm asking questions, is it acceptable for debian/ files to be executable, dpkg-source is warning about it [03:21] debian/rules should be the only one [03:21] StevenK: thanks [03:21] tbielawa: It is acceptable for them to be executable. On the other hand, it is not safe to rely on anything other than debian/rules being executable for use of the package. [03:21] dpatch likes having debian/patches/* executable, but will deal if they aren't. [03:21] StevenK: And dpatches in patches/ right? [03:21] RAOF: Automated. [03:22] StevenK: Is it worth patching out the executable bit of an upstream debian/ if they leave it there? [03:22] watch doesn't need +x either? [03:23] tbielawa: No. Only debian/rules needs it, and dpkg-source typically sets that anyway. [03:23] persia_: do you think it's okay to include arm in debian/control? I didn't quite get the point. [03:23] persia_: I thought diff didn't preserve permissions? [03:23] StevenK: I think it can for new files, but I may be mistaken. [03:23] StevenK: dpkg-source: warning: executable mode 0755 of 'debian/bibus.menu' will not be represented in diff [03:23] exactly [03:23] tbielawa: Just ignore that warning. [03:24] artfwo: For now, I'd include every architecture not known to be 64-bit. As there isn't infrastructure in place for arm, it's only worth including that if you're planning to put supercollider back in Debian. [03:25] Pity any [!amd64] doesn't work [03:25] persia_: okay, but where can I get the list of available architectures? [03:26] StevenK: Yes, but what about ia64? [03:26] artfwo: https://launchpad.net/+builds [03:26] persia_: I didn't want to complicate matters. :-) [03:26] thanks! [03:27] StevenK: :) Aren't you one of the only people with an ia64 workstation around anyway? [03:27] I have an amd64, not an Itantic [03:27] StevenK: Ah. I thought you had at least one of each arch. [03:27] Itanic, sigh [03:28] persia_: I'm ignoring ia64 in the hope it goes away [03:28] heh [03:28] hppa and sparc have both 32-bit and 64-bit designs, right? [03:28] Yes [03:29] I think we only do 32-bit versions of those, kernels aside. [03:29] sparc32, also known as "Ohmigod, those come in only 32 bit?" [03:29] * persia_ waves around a selection of hypersparcs [03:29] so, is it okay to assume those are not 64-bit? [03:30] I have a SparcStation [25] around somewhere. [03:30] zomg, lintian had no output! success! [03:30] The 2 is a sun4c, from memory. [03:30] tbielawa: Did you turn on all of the flags? [03:30] oh.. no... [03:30] recommended flags? [03:30] tbielawa: lintian -iIv [03:30] Also remember to use it on both the source and binary builds. [03:30] persia_: thanks [03:32] persia_: it's not as quiet as it was before.... I guess I have more work to do [03:32] i'm sorry for repeating the question, but anyway is it okay to assume hppa and sparc are not 64-bit? [03:33] Nope. [03:33] All modern hppa and sparc hardware is 64-bit [03:34] StevenK: Don't we compile 32-bit userspace anyway? Did we change that? [03:34] For sparc, I don't think so. hppa, I *think* so [03:34] My PA-RISC is lucky to be 32 bit, so I can't check [03:35] artfwo: You likely want to ask the sparc and hppa teams. Unfortunately, I don't know the best points of contact. [03:35] by reading the supercollider changelog, I see that it failed to run on anything but i386 and powerpc [03:37] artfwo: It ought work fine on lpia as well. [03:38] yes, lpia is okay [03:38] i'm looking through debian bugs, e.g. debian bug 290339 [03:38] Debian bug 290339 in supercollider "supercollider: [m68k] FTBFS" [Serious,Closed] http://bugs.debian.org/290339 [03:39] artfwo: That's just bad coding of the 64-bit test. I would be extra surprised to find a 64-bit m68k [03:40] but there's also debian bug 276212 [03:40] Debian bug 276212 in ftp.debian.org "RM: supercollider [alpha sparc amd64]" [Grave,Closed] http://bugs.debian.org/276212 [03:41] it also mentions debian using 64-bit sparc kernel [03:41] artfwo: That's the design issue. There's an 8-byte variable, for which the lower 32-bits is used for the value, and the upper 32-bits is used for a pointer to something else. This fails for word sizes != 32-bits. [03:42] persia_: yes, I'm aware of that [03:42] artfwo: Right. I'm saying 290339 is fixable, but 276212 is very difficult. [03:42] the upstream is working on fixing this, but there's no release yet [03:44] anyway, could the REVU upload got rejected because of original source being included twice? [03:44] That's excellent news. Last I read from upstream was that it didn't matter, and everyone should use 32-bit, but that was years ago. [03:45] artfwo: Included twice? That's bad. Which package was rejected? [03:45] supercollider [03:45] http://revu.ubuntuwire.com/details.py?package=supercollider [03:45] That's there. Look way down at the bottom of the page. [03:45] my today's upload had the same .orig inside [03:46] the last upload in REVU is dated may 21 [03:46] Ah. Hmm. And the most recent upload was source-only? Odd. [03:46] * persia_ goes away for a while, lamenting the existence of clocks [03:49] c ya later persia_ [04:12] It looks like REVU finally accepted the package after excluding .orig from upload [04:12] weird [04:12] I thought i saw it saying something about .orig's causing rejection some where [04:13] well, it seems to be a problem for reviewers - the source did not get unpackaged for this upload [04:14] bibus source: build-depends-without-arch-dep python [04:14] I have no idea how to begin dealing with that lintial error [04:15] afaik, build-depends should not include python [04:16] oh! good to know [04:16] If it needs python to build, it should be in a build-dep :) [04:16] python-distutils or something like that should go to build-depends, I though [04:16] On the other hand, you're probably running into build depends vs build depends indep issues. [04:17] RAOF: I do not understand the different yet [04:17] If you're producing an arch independent (arch all) package (ie: a pure python module/program), lintian will complain if you have unnecesary stuff in build-depends. [04:17] that is what this is [04:17] arch indipendent [04:18] tbielawa: Basically, build-depends-indep should contain everything needed to build the arch-independent part (ie: everything). [04:18] i had python and python-central [04:18] With the important proviso that anything necessary to run the clean: rule _must_ be in build-depends. [04:18] python-support (>= 0.3) should be enough for most packages [04:18] RAOF: that message from lintian makes more sense now, thanks a lot [04:19] artfwo: in build-dep or build-dep-indep? [04:19] I've used it for Build-Dep [04:19] does PPA build for intrepid yet? [04:19] tbielawa: that depends. Does the clean: target fail if you don't have python? :) (Chances are that it does, but I'd need to know what your clean: target runs first.) [04:20] good question [04:21] <3 pbuilder [04:22] That should be easy enough to see without pbuilder, but I suppose it's a fallback. [04:24] Okay, may I ask kind reviewers to look at http://revu.ubuntuwire.com/details.py?package=supercollider and http://revu.ubuntuwire.com/details.py?package=supercollider-gedit ? Thanks. [04:24] Hmm. Doesn't Bind 9 ship with the zone parser? [04:25] Ah yes. named-checkzone [04:25] can anyone with REVU access sync my new keys from launchpad please (lp.net/~tbielawa) [04:25] tbielawa: how long ago did you update your keys? [04:26] considering that I resynced the keyring an hour or so ago [04:26] days ago [04:27] I guess then that trying to ssh to the revu server is supposed to fail outright? [04:27] yes [04:27] tbielawa: You're not meant to be able to ssh to the revu server unless you're a revu admin (or possibly a motu, I'm not sure). [04:28] silly me [04:28] since it's only your gpg key that it's grabbing [04:29] and the gpg key is just used for verifying uploads, and for the password for the revu interface [04:29] RAOF: I believe it's REVU Admins + REVU Hackers + UWSA, but I may be mistaken. [04:29] I believe its working.... [04:29] Uploading to revu (via ftp to revu.tauware.de): [04:29] * ajmitch thinks there's a fair bit of overlap between those teams [04:30] time to call it quits for tonight. thanks for your help everyone [04:41] downside to meeting people in person [04:41] persia is assigning me directly to compiz bugs now :P [04:41] haha [04:42] I'd do that anyway, if you set it in-progress and didn't assign it, and someone told me. You can always reassign, or better explain how to came to be "In Progress"... [04:43] I was using In Progress as "is fixed upstream, will be fixed when we update" [04:43] Although that bug actually ended up not being fixed [04:43] * persia_ wants "Fix Available" back [04:44] I think it might be a bug in gnome-screensaver, honestly [04:44] I should try xscreensaver and kscreensaver [04:44] persia_: Oh, bye the way, any particular reason you worked on libjsw in Ubuntu but didn't do anything in Debian? Though now that I ask that, libjsw isn't a games team package is it? [04:44] Could be. I just noticed the assigned package, and the identity of the person setting "In Progress", and thought I'd assign it. [04:44] oh well, now it's on my todo list :P [04:45] need to get it fixed somehow anyway [04:45] bddebian: It's not games team. There was some discussion about it on the mailing list several months ago (maybe even a year), but the general agreement was that it was better not to use libjsw. [04:45] or off the list of compiz bugs :) [04:46] Amaranth: If you're feeling extra LP-cool, link to the upstream bug, set the upstream bug as committed (or whatever), and set the Ubuntu bug as Confirmed. This will push it into the fixed upstream list, and then into really-fix-it (I think). [04:46] heh, it's not actually fixed upstream [04:47] just sort of maybe fixed upstream? [04:47] we thought it would be, needed those people to test and i doubt any of them can manage to build compiz [04:48] bddebian: http://lists.debian.org/debian-devel-games/2008/01/msg00247.html [04:48] I believe that had all the Ubuntu changes merged, at the time of review. [04:49] bddebian: Reviewing that, it appears you are the person who convinced me not to pull libjsw into the games team :p [04:53] Oh yeah, I even replied to that one.. heh [04:54] I was complaining about search and rescue being an unmaintained POS [04:55] bddebian: Right, and as that's the only intentional user of libjsw (oxine can do better: it has an upstream), someone ought either fix or remove searchandrescue, and then we can drop libjsw. [04:55] * persia_ likes the S&R engine, but has never been able to complete a mission [04:56] * ajmitch has never used that 'application' [04:57] more things to waste my time cannot be good [04:57] Weird, I don't see libjsw as a build-dep or dep of oxine [04:57] ajmitch: Consider it an opportunity to improve hand/eye coordination. [04:58] bddebian: Right. That got fixed. it's only S&R that needs to be ripped to shreds. There's only three or four calls, so porting to SDL ought be fairly easy. [04:59] bddebian: I haven't looked recently, but I suspect http://lists.debian.org/debian-devel-games/2008/01/msg00254.html is still accurate, given how much attention is given to S&R maintenance. [04:59] Hmm, I'm not sure I would know where to start with that one [05:00] I'd start with the menu. Once that works, you can fiddle with gctl.c [05:01] Not that anyone looks at the work I do already.. ;-P [05:02] bddebian: Right. Make me a list of 10 things to look at over the weekend, and I'll look at them, just to disprove your point. [05:03] hah [05:03] You don't help me much when you can't upload to Debian. ;-P [05:03] bddebian: Well then. Don't complain :p [05:03] I was talking about Games Team folks atm :) [05:04] Have you ever tried AstroMenace? [05:04] * persia_ refrains from learning about the existence of more games, in hopes of doing something. [05:04] heh [05:39] Hmm. [05:39] It looks like GTK applications written in interpreted languages, like Perl, Python and Java, are the ones most likely to completely disregard the HIG. [05:45] LucidFox: Is there perhaps also a relation to things in GNOME upstream? [06:11] good morning [06:12] greetings, dholbach [06:13] hi ajmitch [06:15] oi oi [06:15] mornin' dholbach [06:16] hiya nixternal :) [06:17] so, did you enjoy uds? [06:17] absolutely :-) [06:17] I promise to be at the next one! [06:17] 6 more months!!! :) [06:17] once I triaged my inbox I'll probably write a lenghty blog post :) [06:18] heh, my inbox is nuts...I have about 100 doc patches for KDE 4.trunk [06:18] I was sick all weekend, so I didn't get a chance to upload them to svn yet [06:18] WOW [06:19] and to top it off, my trunk build box has something funky with my radeon 9500 [06:19] hope you're going to be better soon again [06:19] constantly locking up [06:19] ya, I am better right now, tomorrow I should be golden [06:19] ROCK [06:19] I have been pretty sick since like thursday [06:20] the last night was awesome - we rented a club and had the first ever "Ubuntu Allstars" where an Ubuntu band played and james_w and I played some drum'n'bass afterwards [06:20] I immensely enjoyed that [06:20] rock on...I watched the one video of the allstars [06:20] tried to get jono and jorge rock out last month in detroit, but that didn't prove successful [06:20] heh, see, open source programming is just like being a rock star [06:21] it was big fun - TheMuso_ was brilliant on the keyboard and the drums [06:22] hey all === ^Gonzo^ is now known as [PUPPETS]Gonzo [06:22] Hobbsee! [06:22] he played "Light my Fire" together with sabdfl :) [06:22] hi Hobbsee [06:43] Good morning [08:25] * persia_ seeks volunteers with some familiarity with packaging who are looking for something to do. [08:26] i'm currently available [08:27] artfwo: We've a number of packages that are Ubuntu-local, in that they don't have an assigned Debian maintainer. [08:27] 80 of these are known to be out of sync with upstream, and need an update for intrepid. [08:28] The list of these packages can be found from http://qa.ubuntuwire.com/uehs/no_updated.html [08:28] For each package, it needs a quick update to the new upstream, a review of outstanding LP bugs to close what can be closed, often a policy update to make it lintian clean, and some testing. [08:29] In many cases, the new upstream (with fixes) will be better than what we have now, and it ought be in intrepid. [08:29] how do I propose an update for such a package? LP bug with debdiff? [08:30] artfwo: Create an Update bug, and attach the diff.gz for the new package. If you can't get the right upstream directly from the watch file, make sure debian/rules get-orig-source will do the right thing. [08:30] what if there's no get-orig-source? [08:31] Patches welcome? :) [08:31] artfwo: It can be added :) [08:31] persia_: How many of them _should_ be Ubuntu local? I'm on a bit of a push to Debian phase. Is there anything interesting there? [08:31] Note that some of these are false positives. For example, libfile-flock-perl appears to be a bug in the watch file, rather than there actually being a new upstream. [08:32] hi persia_ [08:32] RAOF: ffmpegthumbnailer? [08:32] it's a surprise for me, that get-orig-source is actually used [08:32] RAOF: I'm not actually sure. I'm guessing about half are QA-maintained in Debian: might be worth chasing those if you're on a DCT-push. [08:33] artfwo: It's easy enough to implement a crappy get-orig-source using the watch file, if available. It's also possible to implement a good g-o-s with the watch file, but I've forgotten how ;) [08:33] To make a good one, you have to mess with options. I'll see if I can find a reference... [08:34] RAOF: but is it okay to use uscan from debian/rules? [08:34] Why not? [08:34] artfwo: Yes. [08:35] the options are in man uscan afaik, btw [08:35] Yeah, but you need to do special things to ensure that you can call get-orig-source from an arbitrary directory. [08:36] but what is better for debian/rules? uscan or wget/svn export, etc.? [08:37] Depends. uscan isn't going to work anytime you need svn export. And wget is probably duplication work performed by the watchfile, anyway. [08:38] artfwo: http://lists.debian.org/debian-devel-games/2008/02/msg00135.html is likely the best example I've written (although for a more complex case). It might need a bit of editing. [08:39] artfwo: Use uscan when you can, wget when you can't, and $(VCS) export only when you must. [08:39] Note that for "can't", it needs to be an upstream that does not support a watch file, not just a missing watch file. uscan will work in all cases from that URL. [08:40] persia_: Awesome. I've been looking for that on and off for a while. [08:40] RAOF: Which: the rules for uscan/wget/$(VCS) export, or how to hack mediatomb? [08:40] Anyway, it's worth reviewing the entire thread, as I believe someone found a bug in my initial hack. [08:41] persia_: what about the changelog entries for your list? [08:43] artfwo: You'll likely want " * New Upstream Version (LP: #nnnnnn)" at the top. If upstream closed some bugs or had interesting changes, list these underneath with (" + Allow user to frab quux (LP: #nnnnnn)". Also mention any other bugs you close, or packaging changes. [08:43] okay, thanks! [08:44] persia_: How to get the right directory from Make, basically. $(dir $(_)) seems to do it. [08:45] RAOF: Yeah. $(dir $(_)) is raw sneakiness. Took me days to find it. [08:45] We should put that on a wiki somewhere. [08:46] persia_: lv2core from the list is already in revu: http://revu.tauware.de/details.py?package=lv2core [08:47] Some of those _must_ be in Debian. swfdec certainly is. [08:47] artfwo: It doesn't belong in REVU, where it will be ignored. Anyway, maybe look at the next one. [08:47] RAOF: If they are in Debian, they are orphaned. [08:48] Hm. So, my Sid system doesn't have swfdec0.5; it does however have an apparently non-orphaned swfdec-mozilla and a libswfdec-0.6-90 [08:48] persia_: why it will be ignored in REVU? isn't REVU a place for actually reviewing and accepting packages? [08:48] RAOF: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball might be a good candidate. [08:48] artfwo: NEW packages, yes. Updates, no. [08:49] I suspect that swfdec0.5 is an obsolete package that should be replaced by/merged with the debian one. [08:49] RAOF: Likely. Given autosync, it might just need a removal request. [08:50] Heh; yup. Hardy has the 0.60 swfdec packages. swfdec0.5 can probably die, then. [08:51] persia_: but then the only acceptable way for a contributor to update a package is a debdiff in LP? [08:51] artfwo: either a debdiff or a diff.gz, yes. [08:52] artfwo: The benefit is that you only need one approval for something in LP, as opposed to three (two MOTU + Archive Admin) from REVU, so this is really easier, although sometimes confusing. [08:52] aha, I see [08:53] (well, sometimes you need dev+archive admin, if you have new binary packages, but it's still easier) [08:54] zope2.9 may also be a candidate for removal [08:55] RAOF: If you're considering removals, you may find the other UEHS lists just as interesting. While they aren't as easy for someone to just update, they still have lists of Ubuntu-local stuff. [08:56] Or maybe not. We seem to have a whole lot more zope packages that Debian, and many of them depend on 2.9 [08:56] Maybe we need to organise a transition? I seem to remember something about there being a combined Debian/Ubuntu Zope team. [08:58] Mayhap. [08:59] I'm not particularly interested in zope, I just know that others are and was hence surprised that it's on the list.- [08:59] Any Zope people around? Maybe from the antipodes? [09:00] * persia_ expects it's too late that far east anyway [09:00] * RAOF is just about to head home and make delicious con carne. [09:01] RAOF: I was thinking even further east than you, but interest may have waned over time [09:03] * RAOF wasn't aware there _was_ further east than me :P [09:03] RAOF: Aren't you only in UTC+10? [09:03] Well, yeah. [09:04] RAOF: Well, the world goes UTC+13 through UTC-14, so there's heaps east of you (although not as much as is west of you). [09:04] I think there are at least 5 significant polities east, but would have to check a map to be sure. [09:04] But only the southern hemisphere counts, so that leaves just NZ and some tiny islands :P [09:05] True. Northern Hemisphere doesn't really have anything between UTC+10 and UTC-11. Not even islands. [09:05] (I think in one place, UTC+10 and UTC-11 are about 20km apart) [09:06] There's the far eastern edge of Russia, I think, and ...? [09:06] far western edge of Alaska [09:06] Oh, at -11, yeah. [09:09] Anyway, I'm off to make good on my threat of con carne. [09:16] Strange, I have tried to produce a debdiff between hardy lv2 and LV2 from REVU, but it also shows differences between the orig tarballs. [09:23] artfwo: debdiff isn't really the best tool to do that. You'll want to attach your diff.gz for review. [09:24] artfwo: If you want to see your changes, use interdiff on the diff.gz files. I think it's something like interdiff -z -p1 foo_x.y-0ubuntu1.diff.gz foo_x.z-0ubuntu1.diff.gz, but man interdiff to be sure. [09:24] * persia_ really ought update that documentation soon [09:26] artfwo: Also, if you're interested in LV2 beyond just updating it, there's tons of modules that still need packaging. [09:28] persia_: yes, I'm going to try packaging the plugins in my spare time, cause I wanna switch to LV2 soon :) [09:29] artfwo: Excellent. I'm looking forward to that, as there's a few neat things that LV2 does so much better. Getting a nice suite of tools available for intrepid is one of my private goals. [09:30] they say interdiff is deprecated here: http://irclogs.ubuntu.com/2008/03/07/%23ubuntu-motu.txt [09:30] artfwo: interdiff is deprecated for attachment to a bug. It's still a useful tool. [09:32] how do I name the interdiff output file? [09:32] lv2core_2.0-0ubuntu1.diff.gz is already taken by the .diff.gz [09:32] artfwo: I use .interdiff, but I recommend just piping into less for your personal review, rather than making a file. [09:33] i am browsing it with less right now :) [09:33] just want to name the bug attachment in a standard way [09:33] artfwo: Found it. https://wiki.ubuntu.com/MOTU/Meetings/2008-02-01 talks about the switch from interdiff as a bug attachment to diff.gz as a bug attachment. [09:33] artfwo: Attach the new diff.gz to the bug, not the interdiff. [09:34] persia_: Back from UDS? [09:34] Interdiff can help you understand what you changed, and help the reviewer understand what you changed, but is a waste of storage, and confusing when attached directly. [09:34] slytherin: UDS is over. [09:34] persia_: I know. I was wondering if you are back home or still in Prague [09:35] slytherin: I'm back. [09:35] :_) [09:35] :-) [09:42] persia_: latest version for gnochm from UEHS is also already available in debian [09:43] artfwo: In that case, a sync/merge would be ideal. That tool only checks watch files: it doesn't tell you how to get the new version. [09:44] but how is sync performed? I though it requires to be a motu to do these things... [09:45] artfwo: you verify if a sync is sufficient and then file a bug. Once it is ack'ed by a MOTU an archive admin will do that. [09:45] artfwo: It requires MOTU approval, but anyone can request a sync. If you aren't MOTU, just subscribe the sponsorsr. [09:45] artfwo: It will be great if you can verify that the package actually builds in intrepid chroot. [09:45] could you give some sync request examples in LP? [09:46] artfwo: https://bugs.launchpad.net/~ubuntu-archive/ has a few [09:51] the gnochm package from debian builds alright, to whom would I subsribe a sync request - the motu or ubuntu-archive? [09:52] artfwo: neither. You want to subscribe one of ubuntu-main-sponsors or ubuntu-universe-sponsors (depending on whether gnochm is in main). [09:53] but why the requests show in /~ubuntu-archive? [09:53] ah, the sponsor subscribes after verification [09:55] artfwo: Exactly. I pointed at the archive list because there are typically between 10 and 200 pending requests there. [09:58] persia_: Now that you are back may I again bug you about review? geser did a review and I have fixed the problems he specified. http://revu.ubuntuwire.com/details.py?package=xml-commons-external [09:59] slytherin: Not now, but I'll take a look in a few hours (assuming I can catch up with my backlist of outstanding promises) [09:59] persia_: Ok. I understand you must be having huge backlog. :-) [10:05] hi * [10:05] heya pochu :) [10:06] hey emgent :) [10:26] hi ppl [10:27] if there's an open bug in LP for a given package, and upstream fixes it. Should the the bug status change to "fix committed"? [10:28] foolano: No. The upstream task should be Fix Released or Fix Committed, depending on how fixed it is upstream. [10:28] Some people do abuse the Ubuntu task to show that state, however. [10:32] * pochu throws https://bugs.edge.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs?field.searchtext=merge to the channel [10:35] wgrant: so the bug status will never change to fix committed or fix released until a new package is uploaded, whether upstream has released a fix or not? [10:39] foolano: Why would the Ubuntu status change unless the status in Ubuntu had changed? [10:41] wgrant: i was wondering if there was any relationship between upstream changes on the bug and the actual bug in ubuntu [10:42] foolano: No. The Ubuntu task reflects the status in Ubuntu, and that's all. [10:42] ok, got it [10:43] When merging a package from Debian, is it necessary to preserve old Ubuntu changelog entries if old Ubuntu changes have been merged but new ones are needed? [10:45] LucidFox: In general, yes. [10:45] huhu mok0 :) [10:45] ok [10:46] sebner!!!!! [10:46] mok0: ??????????? [10:46] sebner: that was an outcry of enthusiasm! [10:47] mok0: ah. ok ^^ [11:02] foolano: you can add a watch for upstream bug, if there is any. Check 'Also Affects ..." [11:04] slytherin: alright, thanks :) [11:08] dholbach: ping [11:25] Hi all. I have a package in my ppa whose version has a "+ppaname1" appended to avoid being superceded by ubuntu updates [11:25] now I want to revert to ubuntu defaults for users of my ppa [11:25] so I would like every user to get back to the ubuntu version (possibly upgrading the package with a dummy package?) [11:26] I don't know how to do that :) [11:26] Le-Chuck_ITA: via synaptic you may force version of a package [11:27] easiest way is to get the ubuntu version (remove the deb-src for your ppa and apt-get source ", then increment the version to be higher than yours [11:27] other than that, the only way is to get the users to manually do it [11:28] stdin but if I do that, how can I be sure that they'll get next ubuntu update? [11:28] I did this right now but I had to append +ppaname2 to supercede mine [11:29] so when -ubuntu2 will be out, it will not be higher than mine [11:29] what's the version you have for your package? [11:29] ubuntu1+ppaname2 [11:29] ubuntu1+ppaname1 ? [11:29] oh [11:30] well, ubuntu1+ppaname2 is less than ubuntu2 [11:30] Grr. This package builds in pbuilder but not using debuild -B [11:31] hmmm. And suppose I wish to overwrite *every* ubuntu update in the future [11:31] how would I name my package then? [11:32] and how would I cancel should I decide to abandon the package? [11:32] maybe it's still not possible? [11:32] The idea is to be able to maintain a bugfix to a package until ubuntu adds it, then remove it from the ppa [11:33] so I can't allow ubuntu updates until ubuntu fixes the bug, and, since then, my version should no longer be used [11:33] just keep a higher version in your repo, I usually increment the ubuntu release and append ~ppaname1 to my package [11:34] the safest way for the users is to update your version whenever ubuntu updates theirs [11:34] stdin: but in the lag when I still didn't notice there's a new ubuntu version out, users will get a version without the fix or am I missing the point? [11:35]