| === asac_ is now known as asac | ||
| === asac_ is now known as asac | ||
| === santiago-pgsql is now known as santiago-ve | ||
| tbielawa | anyone seen LaserJock recently? | 02:38 |
|---|---|---|
| crimsun | he's taking a leave of absence of sorts. | 02:39 |
| crimsun | (so, not in the few days, no) | 02:40 |
| tbielawa | One of his usual 'i gotta get out' ones, or something else? | 02:40 |
| tbielawa | (;)) | 02:40 |
| bddebian | Heya gang | 02:41 |
| tbielawa | hey! | 02:41 |
| bddebian | Hello tbielawa | 02:41 |
| crimsun | bddebian! | 02:42 |
| tbielawa | how goes? | 02:42 |
| bddebian | Heya crimsun | 02:42 |
| bddebian | tbielawa: OK thanks, yourself? | 02:42 |
| tbielawa | bddebian: super excited. I think i tamed the beast that was packaging 'bibus' | 02:42 |
| bddebian | Nice, congratulations :) | 02:42 |
| tbielawa | silly upstream folks and their debianizations... | 02:43 |
| tbielawa | I took ScottKs advice and ended up recreating the orig.tar.gz without debian/ | 02:43 |
| bddebian | That's usually the wisest | 02:44 |
| artfwo | 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) | 02:59 |
| persia_ | artfwo: It usually takes about 10 minutes, but it may be that it didn't get accepted, and REVU is silent on rejections. | 03:00 |
| artfwo | ah, and if it got rejected, how do I know about that? ;) | 03:01 |
| persia_ | 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 |
| persia_ | More specifically, which package is missing? | 03:02 |
| persia_ | 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:04 |
| * ajmitch sees that it's a package that was removed from debian | 03:06 | |
| persia_ | 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 |
| ajmitch | 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:09 |
| ajmitch | I just saw the 'repackaged from scratch' in the changelog | 03:10 |
| artfwo | it was logical to repackage from scratch | 03:11 |
| artfwo | the new package is a lot cleaner (cdbs, simple-patch-sys, etc.) | 03:11 |
| artfwo | it builds and runs | 03:11 |
| persia_ | 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 |
| artfwo | 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 | |
| artfwo | I've got the changelog history in place | 03:12 |
| tbielawa | please sync my key from lp too | 03:12 |
| tbielawa | launchpad.net/~tbielawa | 03:12 |
| artfwo | persia_: and what is P-a-s? | 03:13 |
| persia_ | artfwo: In that case, you're likely good. Also woth reviewing the old BTS bugs just to make sure they all got closed. | 03:13 |
| artfwo | 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 |
| persia_ | 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:14 |
| persia_ | artfwo: Compiles, sure. Is it 64-bit clean yet? | 03:15 |
| artfwo | persia_: no, but I simply disable sclang with a scons option for amd64 | 03:15 |
| persia_ | artfwo: What about ia64? | 03:16 |
| artfwo | 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 |
| persia_ | Hmm.. OK. Ubuntu used to ship supercollider for ia64 (back in the 04xxxx versions), so this is a surprise to me. | 03:17 |
| tbielawa | 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 |
| persia_ | tbielawa: Best to do as little as possible. Can you not get away with the --ignore option to debhelper to handle the variation? | 03:18 |
| tbielawa | persia_: I'll look at that! thanks for the tip | 03:19 |
| artfwo | persia_: I've got "i386 powerpc lpia" for the sclang and "any" for the server | 03:19 |
| persia_ | 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:19 |
| persia_ | 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 |
| tbielawa | persia_: while i'm asking questions, is it acceptable for debian/ files to be executable, dpkg-source is warning about it | 03:20 |
| StevenK | debian/rules should be the only one | 03:21 |
| tbielawa | StevenK: thanks | 03:21 |
| persia_ | 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 |
| StevenK | dpatch likes having debian/patches/* executable, but will deal if they aren't. | 03:21 |
| RAOF | StevenK: And dpatches in patches/ right? | 03:21 |
| persia_ | RAOF: Automated. | 03:21 |
| persia_ | StevenK: Is it worth patching out the executable bit of an upstream debian/ if they leave it there? | 03:22 |
| tbielawa | watch doesn't need +x either? | 03:22 |
| persia_ | tbielawa: No. Only debian/rules needs it, and dpkg-source typically sets that anyway. | 03:23 |
| artfwo | persia_: do you think it's okay to include arm in debian/control? I didn't quite get the point. | 03:23 |
| StevenK | persia_: I thought diff didn't preserve permissions? | 03:23 |
| persia_ | StevenK: I think it can for new files, but I may be mistaken. | 03:23 |
| tbielawa | StevenK: dpkg-source: warning: executable mode 0755 of 'debian/bibus.menu' will not be represented in diff | 03:23 |
| tbielawa | exactly | 03:23 |
| persia_ | tbielawa: Just ignore that warning. | 03:23 |
| persia_ | 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:24 |
| StevenK | Pity any [!amd64] doesn't work | 03:25 |
| artfwo | persia_: okay, but where can I get the list of available architectures? | 03:25 |
| persia_ | StevenK: Yes, but what about ia64? | 03:26 |
| persia_ | artfwo: https://launchpad.net/+builds | 03:26 |
| StevenK | persia_: I didn't want to complicate matters. :-) | 03:26 |
| artfwo | thanks! | 03:26 |
| persia_ | StevenK: :) Aren't you one of the only people with an ia64 workstation around anyway? | 03:27 |
| StevenK | I have an amd64, not an Itantic | 03:27 |
| persia_ | StevenK: Ah. I thought you had at least one of each arch. | 03:27 |
| StevenK | Itanic, sigh | 03:27 |
| StevenK | persia_: I'm ignoring ia64 in the hope it goes away | 03:28 |
| persia_ | heh | 03:28 |
| artfwo | hppa and sparc have both 32-bit and 64-bit designs, right? | 03:28 |
| StevenK | Yes | 03:28 |
| persia_ | I think we only do 32-bit versions of those, kernels aside. | 03:29 |
| StevenK | sparc32, also known as "Ohmigod, those come in only 32 bit?" | 03:29 |
| * persia_ waves around a selection of hypersparcs | 03:29 | |
| artfwo | so, is it okay to assume those are not 64-bit? | 03:29 |
| StevenK | I have a SparcStation [25] around somewhere. | 03:30 |
| tbielawa | zomg, lintian had no output! success! | 03:30 |
| StevenK | The 2 is a sun4c, from memory. | 03:30 |
| persia_ | tbielawa: Did you turn on all of the flags? | 03:30 |
| tbielawa | oh.. no... | 03:30 |
| tbielawa | recommended flags? | 03:30 |
| persia_ | tbielawa: lintian -iIv | 03:30 |
| persia_ | Also remember to use it on both the source and binary builds. | 03:30 |
| tbielawa | persia_: thanks | 03:30 |
| tbielawa | persia_: it's not as quiet as it was before.... I guess I have more work to do | 03:32 |
| artfwo | i'm sorry for repeating the question, but anyway is it okay to assume hppa and sparc are not 64-bit? | 03:32 |
| StevenK | Nope. | 03:33 |
| StevenK | All modern hppa and sparc hardware is 64-bit | 03:33 |
| persia_ | StevenK: Don't we compile 32-bit userspace anyway? Did we change that? | 03:34 |
| StevenK | For sparc, I don't think so. hppa, I *think* so | 03:34 |
| StevenK | My PA-RISC is lucky to be 32 bit, so I can't check | 03:34 |
| persia_ | artfwo: You likely want to ask the sparc and hppa teams. Unfortunately, I don't know the best points of contact. | 03:35 |
| artfwo | by reading the supercollider changelog, I see that it failed to run on anything but i386 and powerpc | 03:35 |
| persia_ | artfwo: It ought work fine on lpia as well. | 03:37 |
| artfwo | yes, lpia is okay | 03:38 |
| artfwo | i'm looking through debian bugs, e.g. debian bug 290339 | 03:38 |
| ubottu | Debian bug 290339 in supercollider "supercollider: [m68k] FTBFS" [Serious,Closed] http://bugs.debian.org/290339 | 03:38 |
| persia_ | artfwo: That's just bad coding of the 64-bit test. I would be extra surprised to find a 64-bit m68k | 03:39 |
| artfwo | but there's also debian bug 276212 | 03:40 |
| ubottu | Debian bug 276212 in ftp.debian.org "RM: supercollider [alpha sparc amd64]" [Grave,Closed] http://bugs.debian.org/276212 | 03:40 |
| artfwo | it also mentions debian using 64-bit sparc kernel | 03:41 |
| persia_ | 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:41 |
| artfwo | persia_: yes, I'm aware of that | 03:42 |
| persia_ | artfwo: Right. I'm saying 290339 is fixable, but 276212 is very difficult. | 03:42 |
| artfwo | the upstream is working on fixing this, but there's no release yet | 03:42 |
| artfwo | anyway, could the REVU upload got rejected because of original source being included twice? | 03:44 |
| persia_ | 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:44 |
| persia_ | artfwo: Included twice? That's bad. Which package was rejected? | 03:45 |
| artfwo | supercollider | 03:45 |
| artfwo | http://revu.ubuntuwire.com/details.py?package=supercollider | 03:45 |
| persia_ | That's there. Look way down at the bottom of the page. | 03:45 |
| artfwo | my today's upload had the same .orig inside | 03:45 |
| artfwo | the last upload in REVU is dated may 21 | 03:46 |
| persia_ | 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:46 | |
| tbielawa | c ya later persia_ | 03:49 |
| artfwo | It looks like REVU finally accepted the package after excluding .orig from upload | 04:12 |
| tbielawa | weird | 04:12 |
| tbielawa | I thought i saw it saying something about .orig's causing rejection some where | 04:12 |
| artfwo | well, it seems to be a problem for reviewers - the source did not get unpackaged for this upload | 04:13 |
| tbielawa | bibus source: build-depends-without-arch-dep python | 04:14 |
| tbielawa | I have no idea how to begin dealing with that lintial error | 04:14 |
| artfwo | afaik, build-depends should not include python | 04:15 |
| tbielawa | oh! good to know | 04:16 |
| RAOF | If it needs python to build, it should be in a build-dep :) | 04:16 |
| artfwo | python-distutils or something like that should go to build-depends, I though | 04:16 |
| RAOF | On the other hand, you're probably running into build depends vs build depends indep issues. | 04:16 |
| tbielawa | RAOF: I do not understand the different yet | 04:17 |
| RAOF | 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 |
| tbielawa | that is what this is | 04:17 |
| tbielawa | arch indipendent | 04:17 |
| RAOF | tbielawa: Basically, build-depends-indep should contain everything needed to build the arch-independent part (ie: everything). | 04:18 |
| tbielawa | i had python and python-central | 04:18 |
| RAOF | With the important proviso that anything necessary to run the clean: rule _must_ be in build-depends. | 04:18 |
| artfwo | python-support (>= 0.3) should be enough for most packages | 04:18 |
| tbielawa | RAOF: that message from lintian makes more sense now, thanks a lot | 04:18 |
| tbielawa | artfwo: in build-dep or build-dep-indep? | 04:19 |
| artfwo | I've used it for Build-Dep | 04:19 |
| artfwo | does PPA build for intrepid yet? | 04:19 |
| RAOF | 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:19 |
| tbielawa | good question | 04:20 |
| tbielawa | <3 pbuilder | 04:21 |
| RAOF | That should be easy enough to see without pbuilder, but I suppose it's a fallback. | 04:22 |
| artfwo | 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 |
| StevenK | Hmm. Doesn't Bind 9 ship with the zone parser? | 04:24 |
| StevenK | Ah yes. named-checkzone | 04:25 |
| tbielawa | can anyone with REVU access sync my new keys from launchpad please (lp.net/~tbielawa) | 04:25 |
| ajmitch | tbielawa: how long ago did you update your keys? | 04:25 |
| ajmitch | considering that I resynced the keyring an hour or so ago | 04:26 |
| tbielawa | days ago | 04:26 |
| tbielawa | I guess then that trying to ssh to the revu server is supposed to fail outright? | 04:27 |
| ajmitch | yes | 04:27 |
| RAOF | 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:27 |
| tbielawa | silly me | 04:28 |
| ajmitch | since it's only your gpg key that it's grabbing | 04:28 |
| ajmitch | and the gpg key is just used for verifying uploads, and for the password for the revu interface | 04:29 |
| persia_ | RAOF: I believe it's REVU Admins + REVU Hackers + UWSA, but I may be mistaken. | 04:29 |
| tbielawa | I believe its working.... | 04:29 |
| tbielawa | Uploading to revu (via ftp to revu.tauware.de): | 04:29 |
| * ajmitch thinks there's a fair bit of overlap between those teams | 04:29 | |
| tbielawa | time to call it quits for tonight. thanks for your help everyone | 04:30 |
| Amaranth | downside to meeting people in person | 04:41 |
| Amaranth | persia is assigning me directly to compiz bugs now :P | 04:41 |
| bddebian | haha | 04:41 |
| persia_ | 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:42 |
| Amaranth | I was using In Progress as "is fixed upstream, will be fixed when we update" | 04:43 |
| Amaranth | Although that bug actually ended up not being fixed | 04:43 |
| * persia_ wants "Fix Available" back | 04:43 | |
| Amaranth | I think it might be a bug in gnome-screensaver, honestly | 04:44 |
| Amaranth | I should try xscreensaver and kscreensaver | 04:44 |
| bddebian | 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 |
| persia_ | 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 |
| Amaranth | oh well, now it's on my todo list :P | 04:44 |
| Amaranth | need to get it fixed somehow anyway | 04:45 |
| persia_ | 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 |
| Amaranth | or off the list of compiz bugs :) | 04:45 |
| persia_ | 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 |
| Amaranth | heh, it's not actually fixed upstream | 04:46 |
| ajmitch | just sort of maybe fixed upstream? | 04:47 |
| Amaranth | we thought it would be, needed those people to test and i doubt any of them can manage to build compiz | 04:47 |
| persia_ | bddebian: http://lists.debian.org/debian-devel-games/2008/01/msg00247.html | 04:48 |
| persia_ | I believe that had all the Ubuntu changes merged, at the time of review. | 04:48 |
| persia_ | bddebian: Reviewing that, it appears you are the person who convinced me not to pull libjsw into the games team :p | 04:49 |
| bddebian | Oh yeah, I even replied to that one.. heh | 04:53 |
| bddebian | I was complaining about search and rescue being an unmaintained POS | 04:54 |
| persia_ | 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:55 | |
| * ajmitch has never used that 'application' | 04:56 | |
| ajmitch | more things to waste my time cannot be good | 04:57 |
| bddebian | Weird, I don't see libjsw as a build-dep or dep of oxine | 04:57 |
| persia_ | ajmitch: Consider it an opportunity to improve hand/eye coordination. | 04:57 |
| persia_ | 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:58 |
| persia_ | 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 |
| bddebian | Hmm, I'm not sure I would know where to start with that one | 04:59 |
| persia_ | I'd start with the menu. Once that works, you can fiddle with gctl.c | 05:00 |
| bddebian | Not that anyone looks at the work I do already.. ;-P | 05:01 |
| persia_ | 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:02 |
| bddebian | hah | 05:03 |
| bddebian | You don't help me much when you can't upload to Debian. ;-P | 05:03 |
| persia_ | bddebian: Well then. Don't complain :p | 05:03 |
| bddebian | I was talking about Games Team folks atm :) | 05:03 |
| bddebian | Have you ever tried AstroMenace? | 05:04 |
| * persia_ refrains from learning about the existence of more games, in hopes of doing something. | 05:04 | |
| bddebian | heh | 05:04 |
| LucidFox | Hmm. | 05:39 |
| LucidFox | 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:39 |
| persia_ | LucidFox: Is there perhaps also a relation to things in GNOME upstream? | 05:45 |
| dholbach | good morning | 06:11 |
| ajmitch | greetings, dholbach | 06:12 |
| dholbach | hi ajmitch | 06:13 |
| nixternal | oi oi | 06:15 |
| nixternal | mornin' dholbach | 06:15 |
| dholbach | hiya nixternal :) | 06:16 |
| nixternal | so, did you enjoy uds? | 06:17 |
| dholbach | absolutely :-) | 06:17 |
| nixternal | I promise to be at the next one! | 06:17 |
| nixternal | 6 more months!!! :) | 06:17 |
| dholbach | once I triaged my inbox I'll probably write a lenghty blog post :) | 06:17 |
| nixternal | heh, my inbox is nuts...I have about 100 doc patches for KDE 4.trunk | 06:18 |
| nixternal | I was sick all weekend, so I didn't get a chance to upload them to svn yet | 06:18 |
| dholbach | WOW | 06:18 |
| nixternal | and to top it off, my trunk build box has something funky with my radeon 9500 | 06:19 |
| dholbach | hope you're going to be better soon again | 06:19 |
| nixternal | constantly locking up | 06:19 |
| nixternal | ya, I am better right now, tomorrow I should be golden | 06:19 |
| dholbach | ROCK | 06:19 |
| nixternal | I have been pretty sick since like thursday | 06:19 |
| dholbach | 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 |
| dholbach | I immensely enjoyed that | 06:20 |
| nixternal | rock on...I watched the one video of the allstars | 06:20 |
| nixternal | tried to get jono and jorge rock out last month in detroit, but that didn't prove successful | 06:20 |
| pwnguin | heh, see, open source programming is just like being a rock star | 06:20 |
| dholbach | it was big fun - TheMuso_ was brilliant on the keyboard and the drums | 06:21 |
| Hobbsee | hey all | 06:22 |
| === ^Gonzo^ is now known as [PUPPETS]Gonzo | ||
| ajmitch | Hobbsee! | 06:22 |
| dholbach | he played "Light my Fire" together with sabdfl :) | 06:22 |
| dholbach | hi Hobbsee | 06:22 |
| warp10 | Good morning | 06:43 |
| * persia_ seeks volunteers with some familiarity with packaging who are looking for something to do. | 08:25 | |
| artfwo | i'm currently available | 08:26 |
| persia_ | artfwo: We've a number of packages that are Ubuntu-local, in that they don't have an assigned Debian maintainer. | 08:27 |
| persia_ | 80 of these are known to be out of sync with upstream, and need an update for intrepid. | 08:27 |
| persia_ | The list of these packages can be found from http://qa.ubuntuwire.com/uehs/no_updated.html | 08:28 |
| persia_ | 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:28 |
| persia_ | In many cases, the new upstream (with fixes) will be better than what we have now, and it ought be in intrepid. | 08:29 |
| artfwo | how do I propose an update for such a package? LP bug with debdiff? | 08:29 |
| persia_ | 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 |
| artfwo | what if there's no get-orig-source? | 08:30 |
| RAOF | Patches welcome? :) | 08:31 |
| persia_ | artfwo: It can be added :) | 08:31 |
| RAOF | 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 |
| persia_ | 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:31 |
| dholbach | hi persia_ | 08:32 |
| pwnguin | RAOF: ffmpegthumbnailer? | 08:32 |
| artfwo | it's a surprise for me, that get-orig-source is actually used | 08:32 |
| persia_ | 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:32 |
| RAOF | 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 |
| persia_ | To make a good one, you have to mess with options. I'll see if I can find a reference... | 08:33 |
| artfwo | RAOF: but is it okay to use uscan from debian/rules? | 08:34 |
| RAOF | Why not? | 08:34 |
| persia_ | artfwo: Yes. | 08:34 |
| artfwo | the options are in man uscan afaik, btw | 08:35 |
| RAOF | Yeah, but you need to do special things to ensure that you can call get-orig-source from an arbitrary directory. | 08:35 |
| artfwo | but what is better for debian/rules? uscan or wget/svn export, etc.? | 08:36 |
| RAOF | Depends. uscan isn't going to work anytime you need svn export. And wget is probably duplication work performed by the watchfile, anyway. | 08:37 |
| persia_ | 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:38 |
| persia_ | artfwo: Use uscan when you can, wget when you can't, and $(VCS) export only when you must. | 08:39 |
| persia_ | 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:39 |
| RAOF | persia_: Awesome. I've been looking for that on and off for a while. | 08:40 |
| persia_ | RAOF: Which: the rules for uscan/wget/$(VCS) export, or how to hack mediatomb? | 08:40 |
| persia_ | Anyway, it's worth reviewing the entire thread, as I believe someone found a bug in my initial hack. | 08:40 |
| artfwo | persia_: what about the changelog entries for your list? | 08:41 |
| persia_ | 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 |
| artfwo | okay, thanks! | 08:43 |
| RAOF | persia_: How to get the right directory from Make, basically. $(dir $(_)) seems to do it. | 08:44 |
| persia_ | RAOF: Yeah. $(dir $(_)) is raw sneakiness. Took me days to find it. | 08:45 |
| RAOF | We should put that on a wiki somewhere. | 08:45 |
| artfwo | persia_: lv2core from the list is already in revu: http://revu.tauware.de/details.py?package=lv2core | 08:46 |
| RAOF | Some of those _must_ be in Debian. swfdec certainly is. | 08:47 |
| persia_ | artfwo: It doesn't belong in REVU, where it will be ignored. Anyway, maybe look at the next one. | 08:47 |
| persia_ | RAOF: If they are in Debian, they are orphaned. | 08:47 |
| RAOF | 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 |
| artfwo | persia_: why it will be ignored in REVU? isn't REVU a place for actually reviewing and accepting packages? | 08:48 |
| persia_ | RAOF: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball might be a good candidate. | 08:48 |
| persia_ | artfwo: NEW packages, yes. Updates, no. | 08:48 |
| RAOF | I suspect that swfdec0.5 is an obsolete package that should be replaced by/merged with the debian one. | 08:49 |
| persia_ | RAOF: Likely. Given autosync, it might just need a removal request. | 08:49 |
| RAOF | Heh; yup. Hardy has the 0.60 swfdec packages. swfdec0.5 can probably die, then. | 08:50 |
| artfwo | persia_: but then the only acceptable way for a contributor to update a package is a debdiff in LP? | 08:51 |
| persia_ | artfwo: either a debdiff or a diff.gz, yes. | 08:51 |
| persia_ | 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 |
| artfwo | aha, I see | 08:52 |
| persia_ | (well, sometimes you need dev+archive admin, if you have new binary packages, but it's still easier) | 08:53 |
| RAOF | zope2.9 may also be a candidate for removal | 08:54 |
| persia_ | 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:55 |
| RAOF | 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 |
| persia_ | Maybe we need to organise a transition? I seem to remember something about there being a combined Debian/Ubuntu Zope team. | 08:56 |
| RAOF | Mayhap. | 08:58 |
| RAOF | 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 |
| persia_ | Any Zope people around? Maybe from the antipodes? | 08:59 |
| * 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:00 | |
| persia_ | RAOF: I was thinking even further east than you, but interest may have waned over time | 09:01 |
| * RAOF wasn't aware there _was_ further east than me :P | 09:03 | |
| persia_ | RAOF: Aren't you only in UTC+10? | 09:03 |
| RAOF | Well, yeah. | 09:03 |
| persia_ | 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 |
| persia_ | I think there are at least 5 significant polities east, but would have to check a map to be sure. | 09:04 |
| RAOF | But only the southern hemisphere counts, so that leaves just NZ and some tiny islands :P | 09:04 |
| persia_ | True. Northern Hemisphere doesn't really have anything between UTC+10 and UTC-11. Not even islands. | 09:05 |
| persia_ | (I think in one place, UTC+10 and UTC-11 are about 20km apart) | 09:05 |
| RAOF | There's the far eastern edge of Russia, I think, and ...? | 09:06 |
| persia_ | far western edge of Alaska | 09:06 |
| RAOF | Oh, at -11, yeah. | 09:06 |
| RAOF | Anyway, I'm off to make good on my threat of con carne. | 09:09 |
| artfwo | 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:16 |
| persia_ | artfwo: debdiff isn't really the best tool to do that. You'll want to attach your diff.gz for review. | 09:23 |
| persia_ | 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:24 | |
| persia_ | artfwo: Also, if you're interested in LV2 beyond just updating it, there's tons of modules that still need packaging. | 09:26 |
| artfwo | persia_: yes, I'm going to try packaging the plugins in my spare time, cause I wanna switch to LV2 soon :) | 09:28 |
| persia_ | 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:29 |
| artfwo | they say interdiff is deprecated here: http://irclogs.ubuntu.com/2008/03/07/%23ubuntu-motu.txt | 09:30 |
| persia_ | artfwo: interdiff is deprecated for attachment to a bug. It's still a useful tool. | 09:30 |
| artfwo | how do I name the interdiff output file? | 09:32 |
| artfwo | lv2core_2.0-0ubuntu1.diff.gz is already taken by the .diff.gz | 09:32 |
| persia_ | artfwo: I use .interdiff, but I recommend just piping into less for your personal review, rather than making a file. | 09:32 |
| artfwo | i am browsing it with less right now :) | 09:33 |
| artfwo | just want to name the bug attachment in a standard way | 09:33 |
| persia_ | 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 |
| persia_ | artfwo: Attach the new diff.gz to the bug, not the interdiff. | 09:33 |
| slytherin | persia_: Back from UDS? | 09:34 |
| persia_ | 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 |
| persia_ | slytherin: UDS is over. | 09:34 |
| slytherin | persia_: I know. I was wondering if you are back home or still in Prague | 09:34 |
| persia_ | slytherin: I'm back. | 09:35 |
| slytherin | :_) | 09:35 |
| slytherin | :-) | 09:35 |
| artfwo | persia_: latest version for gnochm from UEHS is also already available in debian | 09:42 |
| persia_ | 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:43 |
| artfwo | but how is sync performed? I though it requires to be a motu to do these things... | 09:44 |
| slytherin | 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 |
| persia_ | artfwo: It requires MOTU approval, but anyone can request a sync. If you aren't MOTU, just subscribe the sponsorsr. | 09:45 |
| slytherin | artfwo: It will be great if you can verify that the package actually builds in intrepid chroot. | 09:45 |
| artfwo | could you give some sync request examples in LP? | 09:45 |
| persia_ | artfwo: https://bugs.launchpad.net/~ubuntu-archive/ has a few | 09:46 |
| artfwo | the gnochm package from debian builds alright, to whom would I subsribe a sync request - the motu or ubuntu-archive? | 09:51 |
| persia_ | artfwo: neither. You want to subscribe one of ubuntu-main-sponsors or ubuntu-universe-sponsors (depending on whether gnochm is in main). | 09:52 |
| artfwo | but why the requests show in /~ubuntu-archive? | 09:53 |
| artfwo | ah, the sponsor subscribes after verification | 09:53 |
| persia_ | artfwo: Exactly. I pointed at the archive list because there are typically between 10 and 200 pending requests there. | 09:55 |
| slytherin | 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:58 |
| persia_ | 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 |
| slytherin | persia_: Ok. I understand you must be having huge backlog. :-) | 09:59 |
| pochu | hi * | 10:05 |
| emgent | heya pochu :) | 10:05 |
| pochu | hey emgent :) | 10:06 |
| foolano | hi ppl | 10:26 |
| foolano | 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:27 |
| wgrant | foolano: No. The upstream task should be Fix Released or Fix Committed, depending on how fixed it is upstream. | 10:28 |
| wgrant | Some people do abuse the Ubuntu task to show that state, however. | 10:28 |
| * pochu throws https://bugs.edge.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs?field.searchtext=merge to the channel | 10:32 | |
| foolano | 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:35 |
| wgrant | foolano: Why would the Ubuntu status change unless the status in Ubuntu had changed? | 10:39 |
| foolano | wgrant: i was wondering if there was any relationship between upstream changes on the bug and the actual bug in ubuntu | 10:41 |
| wgrant | foolano: No. The Ubuntu task reflects the status in Ubuntu, and that's all. | 10:42 |
| foolano | ok, got it | 10:42 |
| LucidFox | 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:43 |
| wgrant | LucidFox: In general, yes. | 10:45 |
| sebner | huhu mok0 :) | 10:45 |
| LucidFox | ok | 10:45 |
| mok0 | sebner!!!!! | 10:46 |
| sebner | mok0: ??????????? | 10:46 |
| mok0 | sebner: that was an outcry of enthusiasm! | 10:46 |
| sebner | mok0: ah. ok ^^ | 10:47 |
| slytherin | foolano: you can add a watch for upstream bug, if there is any. Check 'Also Affects ..." | 11:02 |
| foolano | slytherin: alright, thanks :) | 11:04 |
| Laney | dholbach: ping | 11:08 |
| Le-Chuck_ITA | Hi all. I have a package in my ppa whose version has a "+ppaname1" appended to avoid being superceded by ubuntu updates | 11:25 |
| Le-Chuck_ITA | now I want to revert to ubuntu defaults for users of my ppa | 11:25 |
| Le-Chuck_ITA | so I would like every user to get back to the ubuntu version (possibly upgrading the package with a dummy package?) | 11:25 |
| Le-Chuck_ITA | I don't know how to do that :) | 11:26 |
| BugMaN | Le-Chuck_ITA: via synaptic you may force version of a package | 11:26 |
| stdin | easiest way is to get the ubuntu version (remove the deb-src for your ppa and apt-get source <package>", then increment the version to be higher than yours | 11:27 |
| stdin | other than that, the only way is to get the users to manually do it | 11:27 |
| Le-Chuck_ITA | stdin but if I do that, how can I be sure that they'll get next ubuntu update? | 11:28 |
| Le-Chuck_ITA | I did this right now but I had to append +ppaname2 to supercede mine | 11:28 |
| Le-Chuck_ITA | so when -ubuntu2 will be out, it will not be higher than mine | 11:29 |
| stdin | what's the version you have for your package? | 11:29 |
| Le-Chuck_ITA | ubuntu1+ppaname2 | 11:29 |
| stdin | ubuntu1+ppaname1 ? | 11:29 |
| stdin | oh | 11:29 |
| stdin | well, ubuntu1+ppaname2 is less than ubuntu2 | 11:30 |
| Laney | Grr. This package builds in pbuilder but not using debuild -B | 11:30 |
| Le-Chuck_ITA | hmmm. And suppose I wish to overwrite *every* ubuntu update in the future | 11:31 |
| Le-Chuck_ITA | how would I name my package then? | 11:31 |
| Le-Chuck_ITA | and how would I cancel should I decide to abandon the package? | 11:32 |
| Le-Chuck_ITA | maybe it's still not possible? | 11:32 |
| Le-Chuck_ITA | The idea is to be able to maintain a bugfix to a package until ubuntu adds it, then remove it from the ppa | 11:32 |
| Le-Chuck_ITA | so I can't allow ubuntu updates until ubuntu fixes the bug, and, since then, my version should no longer be used | 11:33 |
| stdin | just keep a higher version in your repo, I usually increment the ubuntu release and append ~ppaname1 to my package | 11:33 |
| stdin | the safest way for the users is to update your version whenever ubuntu updates theirs | 11:34 |
| Le-Chuck_ITA | 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:34 |
| man-di | Le-Chuck_ITA: maybe you can add a special package. Each of your maintained packages depends on it and it Conflicts will all versions of packages you dont maintain/need anymore | 11:35 |
| stdin | Le-Chuck_ITA: yeah, but there's no way (from a packaging point of view) to say "use this repo for this package and ignore others" | 11:35 |
| stdin | uses can set up apt pinning to do it on their end, but can't be done on the packaging side | 11:36 |
| wgrant | Le-Chuck_ITA: Why not get the bug fixed in Ubuntu?" | 11:36 |
| Le-Chuck_ITA | wgrant: sometimes it just takes time | 11:36 |
| Le-Chuck_ITA | and I want to provide a bugfix in the meantime | 11:37 |
| Le-Chuck_ITA | without becoming a developer | 11:37 |
| Le-Chuck_ITA | wgrant: some other times there's no agreement with developers | 11:37 |
| wgrant | Le-Chuck_ITA: You can get a patch sponsored... | 11:37 |
| wgrant | PPA is *not* a workaround for slow bugfixing on the Ubuntu side. | 11:37 |
| Le-Chuck_ITA | wgrant: | 11:38 |
| stdin | PPAs can be a tool though, upload a patch to the bug and call for testers for the PPA | 11:38 |
| Le-Chuck_ITA | wgrant: on one side there's testing as stdin says, on the other hand, I often can fix a bug in 20 minutes (maybe because other people already posted a patch somewhere else), but then it takes ages to convince developers to look at it. Since I have very few time, I am happy to contribute a fix in my spare time, but can't afford the rest :( | 11:39 |
| Le-Chuck_ITA | so I have decided to upload things on a ppa and on the bug report | 11:40 |
| wgrant | Le-Chuck_ITA: File bug. Attach debdiff. Subscribe ubuntu-universe-sponsors. Wait a day or two. ???. Profit. | 11:40 |
| slytherin | wgrant: +1 | 11:40 |
| slytherin | In fact profit for everybody. | 11:41 |
| wgrant | Yep. | 11:41 |
| Hobbsee | u-u-s is known slow, though | 11:41 |
| Le-Chuck_ITA | wgrant: I still have to follow every detail | 11:41 |
| wgrant | Le-Chuck_ITA: What do you mean? | 11:41 |
| wgrant | Hobbsee: At times, true. | 11:41 |
| Le-Chuck_ITA | the upload may be good for testing but not completely respect ubuntu policy | 11:41 |
| wgrant | It's not good for testing, then. | 11:41 |
| wgrant | You shouldn't be distributing known-bad packages to innocent users. | 11:42 |
| Le-Chuck_ITA | well: suppose I didn't understand the versioning policy correctly, which in fact I didn't | 11:42 |
| Le-Chuck_ITA | I am still able to upload a fix for the bug | 11:42 |
| wgrant | Then you take approximately 30 seconds to learn the versioning policy, once off, and save lots of time, and make everybody happy. | 11:43 |
| === Ng_ is now known as Ng | ||
| Le-Chuck_ITA | wgrant: I perfectly understand your point but it is easier to provide a small fix than to learn all the ubuntu policies | 11:43 |
| Le-Chuck_ITA | and if I can't do more, I can still attach the patch to a bug | 11:43 |
| Le-Chuck_ITA | but it's different than following the entire official upload process | 11:44 |
| wgrant | What Ubuntu policies do you need to know? | 11:44 |
| Le-Chuck_ITA | the latter is much more time consuming | 11:44 |
| Le-Chuck_ITA | each time I discover something new :) | 11:44 |
| wgrant | You should be following all processes if you upload to your PPA, too. | 11:44 |
| Le-Chuck_ITA | and forget the old ones! | 11:44 |
| wgrant | Policies are there for a reason, not just to annoy people. | 11:44 |
| Le-Chuck_ITA | wgrant: for lyx I did all the steps | 11:44 |
| Le-Chuck_ITA | you may remember this | 11:44 |
| Le-Chuck_ITA | but for xournal I didn't have the time, one year later | 11:44 |
| Le-Chuck_ITA | to do that again | 11:44 |
| Le-Chuck_ITA | Then, I uploaded new upstream release to a ppa | 11:45 |
| wgrant | Why does it take more than a couple of minutes more? | 11:45 |
| Laney | How do I install the build-deps for a source package? | 11:46 |
| wgrant | Laney: sudo apt-get build-dep somepackage | 11:46 |
| Laney | wgrant: That'll get them for the version in the repos | 11:46 |
| Le-Chuck_ITA | wgrant: how do I subscribe ubuntu-universe-sponsors? | 11:46 |
| Le-Chuck_ITA | I will do that for xournal | 11:46 |
| wgrant | Le-Chuck_ITA: Click `Subscribe someone else'. | 11:46 |
| wgrant | And enter ubuntu-universe-sponsors. | 11:46 |
| wgrant | Laney: Use pbuilder or sbuild or similar, as that's how you should be building things. | 11:47 |
| Le-Chuck_ITA | ok I will try and see if I am able to be a proper bug fixer in universe :) | 11:47 |
| wgrant | Le-Chuck_ITA: That would be great. We need as much manpower as we can get! | 11:47 |
| Laney | wgrant: Ah, this is my problem. The package was building fine in pbuilder but not with debuild. So I want to test my new build-deps | 11:47 |
| wgrant | Laney: Install them manually, I guess. | 11:47 |
| Laney | bah | 11:47 |
| Le-Chuck_ITA | wgrant: still, the problem of properly maintaining a forked package for a limited amount of time and then switch my users back to ubuntu if I don't want to maintain the patch anymore exists | 11:48 |
| wgrant | Le-Chuck_ITA: Pinning is the only way to do that safely. | 11:48 |
| Le-Chuck_ITA | wgrant: should I add a repository package with pinning to my ppa? | 11:49 |
| Le-Chuck_ITA | this is indeed possible | 11:49 |
| wgrant | Le-Chuck_ITA: I don't know. I don't deal in such evils. | 11:49 |
| Le-Chuck_ITA | wgrant: forks are never evil :) | 11:50 |
| === stgraber1 is now known as stgraber | ||
| Le-Chuck_ITA | cause: if a fork is wrong, it will die and rest in peace, if it is good, it will influence the original project | 11:50 |
| Le-Chuck_ITA | ubuntu is a fork after all | 11:50 |
| Le-Chuck_ITA | properly maintained | 11:50 |
| Le-Chuck_ITA | wgrant: still, I think there is a very good reason to provide both a ppa and a request for sponsorship: my new xournal release will go (if everything is fine which I doubt) into intrepid. Instead, I provide a package for hardy. | 11:56 |
| wgrant | Le-Chuck_ITA: And Hardy versions won't increase. | 12:00 |
| Le-Chuck_ITA | ? | 12:00 |
| Le-Chuck_ITA | I think it is difficult to get a new upstream release in hardy | 12:00 |
| Le-Chuck_ITA | or am I wrong? | 12:01 |
| wgrant | You are correct. | 12:01 |
| wgrant | That was my point. | 12:01 |
| wgrant | Hardy versions won't increase, so you don't need a kludge to keep your version above it. | 12:01 |
| Le-Chuck_ITA | while you think that a proper backport would be easily accepted into hardy and there's no need to maintain it separately | 12:02 |
| Le-Chuck_ITA | (I mean a backport of specific fixes) | 12:03 |
| wgrant | Right, so properly backport it. | 12:04 |
| Le-Chuck_ITA | wgrant: in fact the most important case I can think of where I would still have this need (assuming that I can do proper sponsorship requests) is a case of disagreement with the ubuntu-developer | 12:05 |
| Le-Chuck_ITA | however I am waiting uds and next release of hardy before drawing conclusions | 12:06 |
| wgrant | Next release of Hardy? | 12:06 |
| Le-Chuck_ITA | I mean the .1 release of june, 03 :) | 12:08 |
| wgrant | Ah. There's nothing at all special about that. | 12:09 |
| Le-Chuck_ITA | wgrant: there has a meeting (UDS?) recently | 12:11 |
| Le-Chuck_ITA | the issue *should* have been discussed there | 12:11 |
| wgrant | What issue? | 12:11 |
| wgrant | I don't seen an issue. | 12:11 |
| Le-Chuck_ITA | the tablet input | 12:11 |
| wgrant | Ah. | 12:12 |
| Le-Chuck_ITA | Tablet by default was disabled for *very good reasons* but without any discussion by the person who has stopped replying to any comments of mine on launchpad. There is a possibility of fixing input ONLY for tablet pcs, not for all tablets. I was a bit rude on the ubuntu-devel mailing list (you probably know). However the result is that nobody cared about the issue any further and the developer stopped replying *any* of my commen | 12:13 |
| Le-Chuck_ITA | I see that everybody will agree, it is completely my fault. However I still think is very bad respect of the policy to disable an important feature without any discussion. | 12:15 |
| Le-Chuck_ITA | and this does not actually belong to MOTU | 12:15 |
| Le-Chuck_ITA | however, this and many other problems in main led me to the conclusion that I can only be outside or inside the devel team. | 12:16 |
| Le-Chuck_ITA | there is no half way | 12:16 |
| dholbach | Laney: pong | 12:19 |
| Laney | dholbach: I was going to ask you about that ygraph sync that failed to build, but I've got it now. | 12:20 |
| Laney | Weird that it worked in pbuilder but not with debuild :( | 12:20 |
| dholbach | Laney: I built it with debuild, because I installed pkgstriptranslations locally | 12:21 |
| Laney | It looks like the build-dep on docbook was pulled in with pbuilder but not with debuild | 12:21 |
| Laney | dholbach: Also, I uploaded a patch to that 5-a-day bug if you want to use it | 12:22 |
| norsetto | dholbach! | 12:22 |
| dholbach | heya norsetto | 12:23 |
| dholbach | Laney: I got the mail - I need to triage my inbox some more, then will get back to it - thanks for your work on it | 12:23 |
| Laney | OK, no probs :) | 12:23 |
| dholbach | Treenaks' memories of UDS: http://foodfight.org/zut/holbach-dance.gif | 12:23 |
| * Laney uploads the merge for ygraph | 12:23 | |
| persia | dholbach: Your hands are too close together to make that believable. | 12:25 |
| dholbach | when I read the URL I thought "oh no, this must be a crazy video of friday night" but luckily it wasnt :) | 12:25 |
| Laney | dholbach: Uploaded the merge, thanks for your review | 12:29 |
| persia | lionel: Rhonda (of Debian fame) has prepared an update for pgadmin3 for sync from experimental, if you have time to review. | 12:29 |
| norsetto | persia: hi there, glad tyou are back, and glad to have met you "in person" | 12:30 |
| dholbach | Laney: no problem | 12:30 |
| persia | norsetto: Yes indeed. Good to attach the face, the voice, and the nick :) | 12:30 |
| lionel | persia: yes, I can review. Is it in the UUS queue ? | 12:30 |
| norsetto | dhlbach: hehe, you had your mixing table hidden in your laptop then | 12:31 |
| dholbach | ... and have a few beer together | 12:31 |
| dholbach | :) | 12:31 |
| persia | lionel: Nope. Still in incoming, but http://rhonda.deb.at/debian/pgadmin3/ has a snapshot. | 12:31 |
| lionel | Ok | 12:31 |
| lionel | thanks | 12:31 |
| persia | lionel: Thanks for watching it :) | 12:31 |
| * persia should really build an intrepid chroot one of these days | 12:31 | |
| * norsetto -> lunch | 12:55 | |
| slytherin | persia: I have one ready if you care for about 70MB transfer. :-) | 12:56 |
| persia | slytherin: -ECONTEXT | 12:56 |
| slytherin | persia: intrepid chroot, base.tgz | 12:57 |
| persia | slytherin: Ah. No, my issue is mostly that I need to re-juggle my volumes to arrange space for the chroots that would be most convenient for me, rather than a lack of content. Thanks though. | 12:58 |
| slytherin | oks | 12:58 |
| slytherin | persia: But you can have the chroot created on any partition, right? | 12:59 |
| persia | slytherin: Yes, but for my use case, it's best to have them in LVM, so as to be able to pull snapshots, etc. | 12:59 |
| slytherin | hmm | 13:00 |
| === Czessi_ is now known as Czessi | ||
| slytherin | I have one question. Should we really keep adonthell in repositories? The game has seen no development for last almost 3 years | 13:08 |
| StevenK | I've heard people talking about a few command line wrappers that limit download and upload speeds, can anyone actually tell the name of one? | 13:08 |
| StevenK | Never mind, rsync does it internally | 13:09 |
| * persia likes adonthell, although Waste's edge is getting buggy, and upstream is slow | 13:09 | |
| sebner | persia: got my mail? | 13:15 |
| persia | sebner: Yes. See above :) | 13:16 |
| sebner | persia: hmm, sorry? | 13:18 |
| emgent | uh? | 13:19 |
| emgent | hi Hemmet | 13:19 |
| emgent | s/Hemmet/Emmet/ | 13:19 |
| * persia steals all the 'H' keys, and reserves them for more careful typists | 13:20 | |
| emgent | lol | 13:22 |
| slytherin | norsetto: Do you mind if I work on gnomeradio merge? At first look it seems like it will be a sync. | 13:22 |
| emgent | persia: check your mailbox :) | 13:22 |
| * persia discourages people from equating reading mail to responding to mail | 13:23 | |
| * emgent remember persia to trust gpg key | 13:24 | |
| norsetto | slytherin: I think I already requested a sync for that | 13:30 |
| sebner | huhu norsetto =) | 13:31 |
| slytherin | norsetto: Yes, I checked that just after I asked you. :-) | 13:31 |
| norsetto | hi sebner | 13:36 |
| === tb1 is now known as tbf | ||
| cheatr | Could someone explain to me what a Fakesync is? I was unable to find much info on it in the wiki | 14:31 |
| norsetto | cheatr: its a sync done by uploading a source package | 14:36 |
| cheatr | norsetto: From the little info I found, I read that the .orig.tar.gz is modified. Is this true? If so, how do you figure out what changes were made to it/why they did a fakesync? | 14:37 |
| norsetto | cheatr: the orig.tar.gz should not be modified, a fakesync is just a manual sync. It could be possible that you need to do that since the .orig.tar.gz in Debian is different from the one in Ubuntu | 14:38 |
| norsetto | cheatr: if thats the case, an archive->archive sync is rejected, you need to check manually what are the changes and if acceptable do a manual sync | 14:39 |
| Laney | dholbach: When you ask me to not use "merge" in the changelog, do you mean that the entry should not mention it at all, or just that the additional change should be as a separate item? | 14:42 |
| cheatr | norsetto: So are you saying I need to manually check the changes between the .orig.tar.gz from Debian and Ubuntu? Or just check the other changes (like the ones listed in the changelog) | 14:42 |
| norsetto | cheatr: what is it you are actually doing? | 14:42 |
| cheatr | norsetto: https://bugs.edge.launchpad.net/ubuntu/+source/sword/+bug/234580 | 14:43 |
| ubottu | Launchpad bug 234580 in sword "Please sync sword 1.5.9-8.1 (universe) from Debian unstable (main)" [Undecided,In progress] | 14:43 |
| norsetto | cheatr: check with the previous uploader why a fakesync was needed, perhaps there is another reason than a difference in tarballs | 14:45 |
| dholbach | Laney: basically you "sync" the debian package, then add a new change to it - merging always contains "old changes" - it was just me nit-picking | 14:45 |
| slytherin | is it possible to have 2 binary packages built from same source package but with different jdk ex. one is built with gcj and has limited functionality and other with sun java but has full functionality. | 14:46 |
| cheatr | norsetto: Ok, thanks for your help. I'll send the person who made the fakesync an email | 14:47 |
| bddebian | Heya gang | 14:47 |
| Laney | dholbach: Ah, OK then. How about this? http://pastebin.ubuntu.com/14784/ | 14:48 |
| dholbach | Laney: that's fine - can you ask in #ubuntu-devel if somebody knows why you now might have to add a docbook build-depends? to me it's not exactly clear why that happens, but it shouldn't be necessary | 14:49 |
| norsetto | cheatr: if it is a difference in tarballs, than we cannot sync, we need to do another fakesync, that is, your sponsor needs to manually upload a source package. You need to attach a debdiff with the relevant changes in changelog and control in that case | 14:49 |
| Laney | Yeah, I don't understand it either. I'll ask. | 14:49 |
| norsetto | cheatr: also, check it yourself, download both tarballs and see if they differs | 14:50 |
| cheatr | norsetto: Where can I get the other .orig.tar.gz? grab-merge.sh only downloads one .orig.tar.gz file | 14:50 |
| norsetto | cheatr: you can wget it from the debian/ubuntu archives or use puc/pdo or even LP or the PTS | 14:51 |
| cheatr | norsetto: Ok, I'll take a look at it now | 14:52 |
| crimsun | Laney: you shouldn't need to add docbook as an explicit b-d. The necessary bits are pulled in via docbook-dsssl, which is an existing b-d. | 14:53 |
| crimsun | (the b-d chain being via docbook-utils) | 14:53 |
| norsetto | bddebian: do you know what DPMT is? | 14:55 |
| Laney | crimsun: -dsssl does get pulled in, but it still fails unless I add the build-dep for docbook. | 14:55 |
| crimsun | norsetto: the python modules team? | 14:56 |
| norsetto | crimsun: ok, that should be it | 14:56 |
| crimsun | Laney: where does it fail? | 14:57 |
| Laney | crimsun: dholbach's build log is here https://bugs.edge.launchpad.net/ubuntu/+source/ygraph/+bug/234457/comments/1 | 14:57 |
| ubottu | Laney: Error: Could not parse data returned by Launchpad: The read operation timed out | 14:58 |
| norsetto | can somebody kick ubottu in the cogs? | 14:58 |
| cheatr | norsetto: Is there a way to do a diff of two .tar.gz files to see what changes were made? | 14:58 |
| norsetto | cheatr: there should be some switch to use with diff, check man diff, otherwise just untar them and do a diff -Nurb, check also md5sums | 14:59 |
| === phoenix24_ is now known as phoenix24 | ||
| * norsetto -> away | 15:02 | |
| Laney | crimsun: Any clue? | 15:18 |
| Laney | Also, does anyone know what a pipe means next to a particular package in apt-cache depends output? | 15:18 |
| Laney | |Depends: foo"" | 15:18 |
| mok0 | tar --compare | 15:18 |
| Laney | Oh, it means alternatives | 15:19 |
| persia | slytherin: It's possible, but it's an annoying complex debian/rules | 15:20 |
| persia | Laney: Alternate dependencies, which are slightly different from alternatives, but essentially. | 15:21 |
| sebner | persia: is japanese written language similar to chinese one? | 15:21 |
| persia | sebner: Not really. Japanese and Chinese share some characters, and for those characters, the meaning is about the same, but the grammar is very different, and Japanese use sound-only characters for lots of things. | 15:22 |
| persia | (Note that some is between 1900 and 7000, depending on who you ask) | 15:23 |
| sebner | persia: ah ok. just asking because I got a chinese (spam?) mail with a picture of a card with chinese characters (at least I think so) and I'm looking for somebody translating for me =) | 15:24 |
| persia | sebner: I'm entirely the wrong person to translate anything. Maybe loosely gloss stuff, but... | 15:24 |
| sebner | persia: nvm then. thx anyway | 15:24 |
| pochu | nxvl: care to switch bug 233953 to a sync request, given the discussion in it? | 15:26 |
| ubottu | Launchpad bug 233953 in kiwi "Please merge kiwi 1.9.21-1 from debian sid" [Undecided,Confirmed] https://launchpad.net/bugs/233953 | 15:26 |
| pochu | nxvl: nevermind, I've done it | 15:34 |
| Laney | dholbach: I think I figured it out. docbook-dsssl depends on (docbook | docbook-xml). At least on my system, docbook-xml was already installed and therefore docbook wasn't being pulled in. docbook is needed as the ygraph module is sgml not XML. pbuilder must be pulling in the first alternative, which just happens to be the correct one here. | 15:42 |
| persia | Laney: This is one of many reasons it is best to use pbuilder and sbuild, rather than debuild. Spread the gospel. | 15:43 |
| Laney | persia: Yeah! I only did the test build with pbuilder, but when dholbach was reviewing he noticed the failure when doing his test with debuild | 15:43 |
| * persia looks down upon deprecated build methods for package review, and encourages the installation of all packaging mangling packages in build-test chroots | 15:44 | |
| dholbach | persia: I wanted to see if it still builds with pkgstriptranslations | 15:45 |
| dholbach | because that was fixed in an earlier upload | 15:45 |
| persia | dholbach: Right. Chroot. Install pkgstriptranslations, pkgbinarymangler, and pkg-create-dbgsym :) | 15:46 |
| dholbach | persia: KVM instance, install pkgstriptranslations. build :-p | 15:46 |
| persia | dholbach: I guess. I'd hate to clean the kvm each time, or wait for boot. | 15:46 |
| dholbach | *shrug* | 15:47 |
| * persia doesn't really see the use case for building without all three manglers for an Ubuntu upload. | 15:47 | |
| Laney | persia: I've never actually heard about these. Can you point me in the direction of some docs? | 15:48 |
| persia | Laney: Not really. You might look in /usr/share/doc/$(package) after installing them. They are special build-manglers that run on the Ubuntu buildds. | 15:49 |
| persia | pkgstriptranslations integrates with the Ubuntu language packs, pkgbinarymangler does Maintainer and a couple other bits. pkg-create-dbgsym wraps dh_strip to create the separate -dbgsym packages. | 15:50 |
| Laney | persia: Right. Do I have to do anything special to build with them? | 15:50 |
| persia | Laney: Install them in your build chroot (or KVM instance, or whatever). | 15:51 |
| Laney | I think I can manage that ;) | 15:51 |
| geser | dholbach: don't forget to enable pkgstriptranslations inside your chroot else it does nothing (like pkg-create-dbgsym) | 16:09 |
| persia | geser: How? pkg-create-dbgsym seems to work for me, and I don't remember enabling it. What must be done? | 16:12 |
| soren | Nothing. pkg-create-dbgsym diverts dh_strip and does its thing. | 16:13 |
| * persia is baffled by conflicting information, and wishes a nice summary to pass on to others | 16:14 | |
| Laney | I think you have to enable pkgstriptranslations, at least according to its man page. | 16:15 |
| geser | persia: right, pkg-create-dbgsym doesn't need enabling but pkgstriptranslations (see /etc/pkgbinarymangler/striptranslations.conf) | 16:19 |
| Laney | Ah, good job I did try it with that, it still FTBFS with pkgstriptranslations on ;) | 16:19 |
| persia | Laney: Excellent. Now you have an issue to solve, rather than confusion :) | 16:20 |
| slavik | I have an archive that has to be extracted into / to be installed, what is the best way to make a deb out of such an archive? | 16:20 |
| slavik | it is the nvidia cg toolkit | 16:20 |
| slavik | nvm, found it in repo | 16:21 |
| bersace | Seems like ubuntu does not build anymore ppc packages :( | 16:21 |
| * bersace have to switch back to debian | 16:21 | |
| Hobbsee | bersace: it's on ports.ubuntu.com | 16:22 |
| Hobbsee | has been for a few releases. | 16:22 |
| bersace | thx | 16:23 |
| persia | geser: Sorry. Lost sync. Thanks :) | 16:29 |
| ScottK | What's the process for getting a wiki page deleted? | 16:39 |
| ScottK | It's in h.u.c/community if that makes a difference. | 16:39 |
| mathiaz | ScottK: try to ask ubuntu-doc | 16:40 |
| mathiaz | ScottK: I think only the admins of a wiki can delete a wiki page | 16:41 |
| mok0 | Anyone can delete a wiki page | 16:41 |
| ScottK | mok0: h.u.c has some restricted permissions. I can't delete it. | 16:42 |
| ScottK | mathiaz: Thanks. | 16:42 |
| mok0 | ScottK: Ah, that, you probably have to be a member of the doc team | 16:43 |
| ScottK | I'm guessing. I'm going to follow mathiaz's suggestion and see. | 16:43 |
| mok0 | yeah | 16:43 |
| highvoltage | howdy. | 17:19 |
| \sh | who is Matvey Kozhev <sikon@ubuntu.com> on irc... | 17:29 |
| LucidFox | \sh> me | 17:30 |
| \sh | LucidFox, why didn't you merge libpcre3 first? subtitleeditor is a sync | 17:30 |
| LucidFox | libpcre3 is in main | 17:30 |
| \sh | LucidFox, so? | 17:31 |
| LucidFox | I've reopened a merge request for it | 17:31 |
| \sh | LucidFox, the problem is, with the libpcre3 merge we could have synced subtitleeditor..and you never asked me before ... | 17:31 |
| LucidFox | The libpcre3 versioning isn't even needed in Debian - it was temporarily there as a workaround for an ABI breakage, the Debian maintainer was supposed to remove it and indicated it in debian/changelog and for some reason didn't actually do it | 17:33 |
| LucidFox | Perhaps we should ask Debian to actually remove the versioned dependency, and then sync | 17:33 |
| \sh | the other way would have been easier...but please ping me the next time you take a merge/sync package I already tested ;) | 17:35 |
| LucidFox | \sh> okay... I'm sorry | 17:36 |
| \sh | LucidFox, no need to be sorry... | 17:36 |
| slytherin | geser: FYI ... I had uploaded the updated xml-commons-external to wrong host yesterday. I have uploaded it today to revu. | 17:38 |
| Laney | pochu: How did you build gnome-lokkit? I can't get it to FTBFS... | 17:48 |
| pochu | Laney: I used this debdiff, and then dpkg-buildpackage -us -uc in Hardy. http://emilio.pozuelo.org/~deb/gnome-lokkit_0.50.22-7.2.debian-ubuntu-changes.debdiff | 17:51 |
| Laney | Ah, I'd only tried it in pbuilder/intrepid VM. | 17:51 |
| Laney | pochu: I can't get it to FTBFS :( | 17:56 |
| pochu | Laney: with my debdiff? | 17:57 |
| Laney | pochu: Is it the same one I put on the bug? | 17:57 |
| pochu | Laney: nope | 17:57 |
| Laney | I downloaded it from LP | 17:57 |
| Laney | Oh! | 17:57 |
| pochu | I said it in my comment | 17:57 |
| Laney | I don't see it | 17:58 |
| pochu | Your debdiff has changes to config.guess, config.sub, Makefile... | 18:01 |
| pochu | I've removed them | 18:01 |
| Laney | I just thought you were asking me to do that | 18:02 |
| Laney | pochu: You killed the change to Makefile.am which is necessary | 18:02 |
| pochu | Laney: you didn't mention it in debian/changelog :P | 18:02 |
| Laney | I did | 18:03 |
| Laney | - debian/gnome-lokkit.files, Makefile.am: | 18:03 |
| Laney | + Install .desktop file to the correct location | 18:03 |
| pochu | bah | 18:03 |
| pochu | my fault then | 18:03 |
| pochu | Laney: can you attach a good debdiff? | 18:04 |
| Laney | pochu: Killing the config changes and updating the maintainer? | 18:04 |
| pochu | yep | 18:04 |
| Laney | Sure | 18:04 |
| pochu | and I'll upload | 18:04 |
| Laney | Is just a debian-ubuntu diff OK? | 18:04 |
| Laney | Or do you want both? | 18:04 |
| pochu | debian-ubuntu | 18:05 |
| Laney | OK | 18:05 |
| * Laney does it now | 18:05 | |
| Laney | pochu: Done | 18:16 |
| Laney | FYI, I asked in here and was told to leave those config changes in... | 18:19 |
| Laney | But never mind | 18:19 |
| norsetto | any motu-sru member around? | 18:20 |
| norsetto | come on, be brave, we know you are lurking .... | 18:20 |
| siretart | norsetto: AFAIUI, the team needs reinforcments | 18:21 |
| norsetto | siretart: AFAIUI, we need a team ;-) | 18:22 |
| siretart | can someone please point me to the 'initial mail' that dholbach is referring to in https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025388.html? | 18:22 |
| siretart | alternatively actually answering my question is okay as well | 18:22 |
| siretart | ;) | 18:22 |
| norsetto | siretart: this: https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025383.html ? | 18:23 |
| norsetto | siretart: btw, it was good meeting you at UDS! | 18:23 |
| siretart | norsetto: and it was great to meet you! | 18:25 |
| siretart | norsetto: does that mail answer my question? | 18:27 |
| norsetto | siretar: I don't know, but its his first email | 18:28 |
| siretart | norsetto: I mailed him in private for clarification now | 18:34 |
| norsetto | siretart: if you wrote that in German you cheated ;-) | 18:35 |
| pochu | Laney: ideally the package should clean the stuff it touches in the clean target | 18:38 |
| pochu | Laney: but it doesn't for the autoreconf changes | 18:38 |
| pochu | anyway, uploaded :) | 18:39 |
| pochu | thanks for the work | 18:39 |
| norsetto | Hola pochu | 18:43 |
| Laney | Thanks pochu | 18:43 |
| pochu | hola norsetto :) | 18:44 |
| * slytherin wonders why motu mailing list is receiving too many "why don't you update package x to latest version" mails. | 18:44 | |
| * pochu is tempted to reply 'why dont you do it yourself and submit a patch?' ;) | 18:45 | |
| * norsetto is glad that the ubuntu-motu m.l. is heavily spam-filtered by his ISP | 18:45 | |
| === dpm_ is now known as dpm | ||
| slytherin | pochu: I think there is a need to make it clear what is purpose of motu ml. Also people don't seem to understand update policies. They expect every new version to land in whatever ubuntu version they are using. | 18:46 |
| siretart | norsetto: I did. why? ;) | 18:47 |
| norsetto | slytherin: since we are discussing this, can you guys please update foo-scit to version 2.1.0? I really need that in gutsy | 18:47 |
| norsetto | siretart: verboden! :-) | 18:48 |
| siretart | :-) | 18:48 |
| slytherin | :-D | 18:48 |
| norsetto | really, I mean it, I'll just drink a beer while you do that, and if you don't I'll go back to windoze | 18:49 |
| slytherin | norsetto: In any case you will get headache. :-P | 18:53 |
| ScottK | I particularly love the do X or I'll got back to windows posts. | 18:55 |
| ScottK | Go ahead and shoot yourself in the head, it's not my problem. In Ubuntu I've promised to be nice, not care about users. | 18:56 |
| norsetto | hey scottk, you ARE nice :-) | 18:57 |
| ScottK | I just don't respond well to threats. | 18:57 |
| ScottK | Particularly not ones like that. | 18:57 |
| * norsetto hands over a budweiser to scottk | 18:58 | |
| ScottK | norsetto: I'm back in the US. It's a very different experience here. Imgine "not very good". | 18:59 |
| * siretart hugs ScottK | 18:59 | |
| ScottK | Thanks. | 19:00 |
| * norsetto everybody who is back from uds! | 19:00 | |
| siretart | how was your flight home? | 19:00 |
| ScottK | No trouble at all. I even got my bad despite going through Terminal 5 at Heathrow. | 19:01 |
| ScottK | bad/bag | 19:01 |
| siretart | ScottK: whoooho! :) | 19:05 |
| ScottK | siretart: Was there a gobby document on the documentation process discussion the cjwatson led the last day of UDS? | 19:05 |
| siretart | there was, I saved a copy | 19:05 |
| ScottK | Do you recall the name? I'm looking now and can't find it. | 19:06 |
| * norsetto -> dinner | 19:06 | |
| siretart | policy-and-standards | 19:06 |
| siretart | I managed to locate it in gobby | 19:07 |
| ScottK | Thanks. | 19:07 |
| === fta_ is now known as fta | ||
| === rzr is now known as rZr | ||
| ScottK | https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025390.html for those interested in the recent developer/bugsquad flailing. | 20:51 |
| \sh | ScottK, http://www.sourcecode.de/content/phyton-world | 20:54 |
| * ScottK heh's | 20:55 | |
| jpds | \sh: Did he know he got it wrong? Or is it deliberate? | 20:56 |
| \sh | hidden bugs? | 20:56 |
| \sh | jpds, the orga of the fair did print them totally wrong | 20:56 |
| \sh | but it's a nice one actually... | 20:57 |
| jpds | \sh: hehe, and he has the right spelling right behind him... | 20:57 |
| \sh | "Phyton the world" (Curtesy ManOWar), "Don't talk about the Phyt Club" | 20:57 |
| \sh | now you know why launchpad is closed source... | 20:57 |
| yannick | Does someone know how I can fix this: "dpkg-genchanges: not including original source code in upload"? | 20:59 |
| jpds | yannick: use -S with debuild | 20:59 |
| yannick | jpds, I did | 20:59 |
| jpds | yannick: erm, -sa then | 20:59 |
| yannick | jpds, -sa brings another error | 21:01 |
| jpds | yannick: did you do debuild -S -sa? Pastebin the error at paste.ubuntu.com | 21:02 |
| yannick | jpds, I did debuild -sa, and it failed, now with debuild -S -sa it seems ok, thank you :) | 21:04 |
| \sh | ScottK, is this proposal agreeable by lp people? | 21:05 |
| ScottK | \sh: They were in the room and didn't scream. Beyond that I'm not sure. | 21:06 |
| jpds | yannick: you're welcome :) | 21:07 |
| \sh | ScottK, if it's ok for all parties involved...go | 21:07 |
| ScottK | \sh: Thanks. We'll see what happens on the ML for a while. | 21:08 |
| \sh | ScottK, or LP Devs are adding some worktask module | 21:09 |
| * RainCT doesn't really like it but he is just an insignificant dev and will shut up :P | 21:09 | |
| ScottK | RainCT: Don't want you to shut up. | 21:09 |
| sebner | ScottK: courier? \o/ | 21:10 |
| \sh | RainCT, raise your voice and your critics...it's more important then you think | 21:10 |
| ScottK | RainCT: We're caught between triagers not knowing what to keep their hands off of and insistence that it's to hard for them to figure it out. | 21:10 |
| ScottK | sebner: Maybe tomorrow. | 21:10 |
| sebner | ScottK: I'm just curious if -3 will arrive earlier ^^ | 21:10 |
| ScottK | RainCT: Please propose alternatives if you have them. This idea is not perfect, but it's the best one I've heard so far. | 21:10 |
| ScottK | sebner: Probably not. He's usually pretty slow about such things. | 21:11 |
| sebner | ScottK: well you konw -2 arrived not that slowly | 21:11 |
| ScottK | Usually when that happens something was really messed up. | 21:11 |
| * ScottK is still trying to get back on the right time zone. | 21:11 | |
| RainCT | Heh. Nah, if you're happy with it I won't object.. But I don't think it's a good idea to restrict access to bugs to developers (or people having joined a special group) only, and neither do I really see an use case for this (it shouldn't be that difficult to learn that bugs with "sync" or "merge" in the title shouldn't be touched.. or am I missing something?) | 21:12 |
| sebner | ScottK: ^^. no rush =) Just want to get this done *soon* =) | 21:12 |
| \sh | RainCT, those reports are not bugs in the general meaning of "bug reports" | 21:12 |
| \sh | RainCT, they are workflow reports...like "sync this", "merge that" , "do this"... | 21:13 |
| ScottK | RainCT: It's also removals, main inclusion reports, and others too. | 21:13 |
| \sh | RainCT, and yes it's difficult for new triagers to determine the diff between "package X is broken" and "please sync..bla " wishlist bug | 21:14 |
| \sh | RainCT, it's a layer 8 problem and sometimes for repeating violations a layer 9 bug | 21:14 |
| pwnguin | why file a bug for syncs? | 21:15 |
| RainCT | \sh: (answering to your first msg) yes, sure. call them what you want, but I think people should be able to see them - I guess this is going to give a lot of "please upgrade to new version" duplicates if syncs/merges are hidden | 21:15 |
| pwnguin | the kernel team sends an emai | 21:15 |
| pwnguin | 21:15 | |
| pwnguin | "please pull blah" | 21:15 |
| \sh | RainCT, people should be able to not assign randomly other people to bugs...but they do... | 21:16 |
| \sh | RainCT, so we need to make somehow sure, that they won't get their hands on those things... | 21:16 |
| RainCT | pwnguin: because by mail it would become a mess.. with requests needing sponsors and everything. | 21:16 |
| \sh | RainCT, or we find another system to deal with workflow things | 21:16 |
| RainCT | pwnguin: although if LP would implement a proper page for sync requests and that like that would be better, of course | 21:16 |
| pwnguin | indeed, it would be nice to seperate bugs from tasks | 21:17 |
| ScottK | pwnguin: That's the path to an archive admin doing the syncs. | 21:17 |
| pwnguin | ScottK: email? | 21:17 |
| pwnguin | ScottK: or seperating them from bugs? | 21:18 |
| norsetto | what about un ubuntu-dev (or ubuntu-motu) project? To be used solely for all the motu stuff. | 21:18 |
| ScottK | pwnguin: We've got a process that's worked for a long time, I think disrupting it isn't a great plan. | 21:18 |
| pwnguin | ScottK: i think unifying the hundred processes at some point might be a good idea | 21:18 |
| ScottK | norsetto: It's not just MOTU. It's all Ubuntu developers. | 21:19 |
| \sh | it's sad that we have hundreds of processes :( | 21:19 |
| norsetto | scottk: ok, then ubuntu-dev, to be used solely for ubuntu devs stuff | 21:20 |
| pwnguin | its annoying to me to have to go out and learn whatever team process is being used when i want to file / triage / fix bugs =( | 21:20 |
| pwnguin | "oh well confirmed means we've accepted to fix it" | 21:20 |
| ScottK | pwnguin: Kernel team is AFAIK the only one with really different team policies. | 21:21 |
| \sh | pwnguin, that's a problem being a) a user b) someone with knowledge and c) the guy with the power to fix | 21:21 |
| ScottK | norsetto: One problem with a separate project is then merge bugs can't be closed by an upload. | 21:21 |
| pwnguin | ScottK: doesn't Kubuntu have something different too? | 21:22 |
| norsetto | scottk: why not? | 21:22 |
| \sh | pwnguin, while a) is a must, b) is not needed to be a bug triager and c) well, this really needs some nerves ;) | 21:22 |
| ScottK | norsetto: Because it's not a bug in Ubuntu. | 21:22 |
| ScottK | pwnguin: Not radically different. It does have a few differences due to upstream. | 21:22 |
| * RainCT -> away (brb) | 21:23 | |
| ScottK | norsetto: Changelog can only close a bug that's open against that package in Ubuntu. | 21:23 |
| norsetto | scottk: oh, you mean the LP: #xxxxx tag ... hmmm, I thought that worked on bug numbers, and those are unique | 21:23 |
| ScottK | The but has to be open against the distro/package or it doesn't work. | 21:23 |
| ScottK | but/bug | 21:23 |
| ScottK | Which is why needs-packaging bugs won't auto close. | 21:23 |
| \sh | norsetto, no....(LP: #xxxx) closes only bugs which are filed against packages in ubuntu...but not in e.g. baltix | 21:24 |
| norsetto | well, I 'm not familiar with the intricacies of LP but I would have thoguht that a package is a package | 21:24 |
| \sh | norsetto, that's why you see the whole crap of baltix bugs, which are already fixed/invalid in ubuntu | 21:25 |
| \sh | norsetto, no a package can be in ubuntu, baltix, nexenta | 21:25 |
| ScottK | norsetto: Think about the case where a bug affects multiple packages. Closes in changelog needs to just mark the right package fixed. | 21:25 |
| \sh | and you file reports against distro+package not only package | 21:26 |
| pwnguin | since each repackaging can introduce bugs | 21:26 |
| pwnguin | its the same reason we dont just file everything upstream or to debian ;) | 21:26 |
| norsetto | so, what is the idea, to use a special team which is "private"? | 21:27 |
| ScottK | So that bugsquad can't see the workflow bugs and then can't mess them up. | 21:27 |
| norsetto | I must admit, it happened only once to me, are we sure this is not blowing out of proportions? | 21:29 |
| \sh | anyways preparing for linuxtag | 21:30 |
| \sh | cu tomorrow | 21:30 |
| sebner | \sh: hf | 21:30 |
| norsetto | \sh: gute nacht | 21:30 |
| sebner | norsetto: \o/ | 21:30 |
| norsetto | sebner: \O/ | 21:31 |
| sebner | norsetto: buona notte :P | 21:31 |
| norsetto | sebner: fiorellino .... | 21:31 |
| sebner | norsetto: un regalo per me? | 21:32 |
| norsetto | sebner: we better stop speaking Italian before scottk scold us ... | 21:33 |
| sebner | norsetto: heh | 21:34 |
| * norsetto wonders if it is better to upload a package now, knowing it will ftbfs for hppa, or wait until (hopefully before the end of the year) hppa deps will be available | 21:38 | |
| ScottK | norsetto: I'd go ahead. It can always be retried if hppa magically grows the needed bits. | 21:39 |
| norsetto | scottk: yes, I'm very tempted | 21:39 |
| * ScottK is not kidding. There's no point in depriving all other archs of something. | 21:40 | |
| ScottK | As an example, java is totally broken on hppa. Should we upload no java apps until that's fixed? | 21:40 |
| pwnguin | i thought there was talk about dropping hppa? | 21:41 |
| ScottK | No. It was dropped and then came back. It's not official though. | 21:41 |
| ScottK | It was (IIRC) sparc that was just dropped as an official arch. | 21:41 |
| norsetto | scottk: I guess that will be in deps_wait state? | 21:42 |
| ScottK | In theory. In some cases packages are there, but not working. | 21:42 |
| * ScottK heads out for a while. | 21:43 | |
| \sh | fck fck fck fck | 21:57 |
| sebner | \sh: you are missing a "u" right? ^^ | 21:57 |
| \sh | sebner, yes.. | 21:58 |
| sebner | \sh: could also be a "s" ^^ | 21:59 |
| \sh | now I have real problems...trying to sing "whisky in the jar" with kwwii won't be fun | 21:59 |
| emgent | heheh hi \sh :) | 22:00 |
| crimsun | \sh: have you been experiencing problems w/ PulseAudio and non-Free Flash? | 22:00 |
| \sh | crimsun, sometimes | 22:00 |
| crimsun | \sh: anything more deterministic than that? | 22:00 |
| sebner | crimsun: pulseaudio + flash 10 is rocking and working but still crashing ^^ | 22:01 |
| crimsun | sebner: with/out libflashsupport? | 22:01 |
| \sh | crimsun, at work, without libflashsupport == no sound when using PA | 22:02 |
| \sh | crimsun, still on flash9 | 22:02 |
| RainCT | actually, what was the rationale to switch to pulseaudio? | 22:02 |
| sebner | crimsun: with. not possible without since it flash depends on it | 22:02 |
| \sh | sw mixing for cheap sound cards | 22:02 |
| \sh | sebner, it doesn't anymore | 22:02 |
| sebner | RainCT: hrhr | 22:02 |
| crimsun | \sh: right, known. If you have a chance, please test flashplugin-nonfree, libasound2, and libasound2-plugins from intrepid. You'll need to remove libflashsupport and also run `asoundconf set-pulseaudio'. | 22:02 |
| sebner | \sh: hmm? | 22:03 |
| crimsun | sebner: see what I mentioned immediately above to \sh, please. | 22:03 |
| * RainCT switched back to ALSA on all his Ubuntu installation, because with PulseAudio only one application could use the sound card | 22:03 | |
| \sh | crimsun, any ppa stuff for hardy backports? or should I just recompile it for hardy? | 22:03 |
| sebner | crimsun: but when I remove libflashsupport it also removes flashplugin-nonfree ;) | 22:03 |
| crimsun | \sh: recompiling will suffice. | 22:03 |
| \sh | crimsun, just a note: I can only test it after LT | 22:03 |
| crimsun | sebner: hence why I mentioned you need the intrepid versions of those packages. | 22:04 |
| \sh | crimsun, good...this can be done during LT.. | 22:04 |
| crimsun | it is extremely unfortunate that the Flash 10 beta was released after 8.04. | 22:04 |
| \sh | crimsun, no :) | 22:04 |
| crimsun | anyhow, we don't need libflashsupport anymore, and I intend to make it disappear in 8.10. | 22:05 |
| \sh | crimsun, flash 10 beta has other flaws do they ship now vp6 encoding with the flash plugin? | 22:05 |
| sebner | crimsun: I'm using intrepid ;) | 22:05 |
| crimsun | \sh: no idea WRT vp6, and I'm aware of the focus issues. | 22:05 |
| \sh | crimsun, vp6 encoding was promised for flash 10 at the end of this year | 22:06 |
| \sh | would make my life much easier | 22:06 |
| crimsun | sebner: the next upload of alsa-plugins likely will Conflict with libflashsupport (with the corresponding change to flashplugin-nonfree's source package, of course) | 22:06 |
| sebner | crimsun: nice to know, when to expect? | 22:06 |
| \sh | ah woman is coming | 22:07 |
| crimsun | sebner: no ETA, I need to discuss it with others. However, if you're currently running intrepid, you can already get rid of libflashsupport. Just install libasound2-plugins and run `asoundconf set-pulseaudio'. | 22:07 |
| crimsun | (and then remove libflashsupport) | 22:07 |
| sebner | crimsun: that will stop firefox from crashing? | 22:08 |
| crimsun | sebner: it has in my unscientific/non-rigourous tests. | 22:08 |
| crimsun | bug reports otherwise are, of course, appreciated. | 22:09 |
| crimsun | (in which case you'd file against flashplugin-nonfree source and alsa-plugins source) | 22:09 |
| sebner | crimsun: I'll give it a try =) thanks | 22:09 |
| crimsun | thank you for testing! | 22:10 |
| sebner | crimsun: a pleasure. Now I'll annoy youtube =) | 22:11 |
| === TheMuso_ is now known as TheMuso | ||
| sebner | crimsun: I just tested ~15 vids but it seems to be rockstable. thanks for that =) I'll give it a harder testing tomorrow :) | 22:46 |
| crimsun | sebner: thanks for the feedback | 22:46 |
| sebner | crimsun: is also positive feedback a good feedback? Nothing to fix is boring :P | 22:47 |
| crimsun | sebner: there's plenty to fix, e.g., how to get this workaround into hardy-*. | 22:49 |
| sebner | crimsun: that's something I wanted to ask =) | 22:50 |
| crimsun | unfortunately, it requires significant updates | 22:50 |
| crimsun | namely, you need alsa-lib 1.0.16 and Debian-specific changes to alsa-plugins 1.0.16 | 22:51 |
| sebner | crimsun: nothing for 8.04.1/2 ? | 22:51 |
| crimsun | and there are instances documented on Debian BTS (for alsa-lib) where 1.0.16 breaks a lot of apps compiled against older -lib versions | 22:51 |
| crimsun | as you might can see, putting them in via -proposed/-updates is not feasible. | 22:52 |
| crimsun | sebner: if Flash 10 final is available by the time 8.04.1 is slated, we might can do a newer flashplugin-nonfree, but the libflashsupport that we have will still affect us. Thus, we should not go the libflashsupport route for hardy-*. | 22:53 |
| sebner | crimsun: I see. damn | 22:55 |
| crimsun | yes, it's quite fun. And not in the hug sense. | 22:56 |
| sebner | crimsun: but flash 10 is really a step in the right direction | 22:56 |
| pwnguin | how so? | 22:57 |
| crimsun | pwnguin: I'm missing some context for your question. | 22:58 |
| pwnguin | sebner: how is flash10 a step in the right direction | 22:58 |
| crimsun | ah. | 22:58 |
| pwnguin | ? | 22:58 |
| sebner | pwnguin: it's working with pulseaudio ^^ flash is still crap though xD | 22:59 |
| crimsun | well, if nothing else, it abuses the ALSA API less. | 22:59 |
| pwnguin | heh | 23:00 |
| pwnguin | i should try gnash out again | 23:00 |
| sebner | pwnguin: well if it leaves the beta status I'll too | 23:02 |
| pwnguin | but you'll try flash10 in beta status? | 23:02 |
| sebner | pwnguin: what's the best if you use intrepid, firefox b5? Yes flash 10 beta | 23:03 |
| sebner | xD | 23:03 |
| pwnguin | well, I don't know about intrepid, but if neither of us have even tried gnash recently, I don't see the point of calling flash10 "best" | 23:05 |
| sebner | pwnguin: not best, it's clearly better than flash9 | 23:06 |
| RAOF | crimsun: Were you doing anything about the lib{32,64}asound2-plugins debdiff on the BTS? It occurs to me that I haven't heard anything about it. Maybe it's time for a ping? | 23:13 |
| RAOF | Alternatively, this could be me once again mistakenly assuming that the BTS subscribes you to any bug you comment on. | 23:13 |
| crimsun | RAOF: no, I am subscribed, and thanks for pinging. | 23:14 |
| crimsun | I'll get with Elimar about it | 23:14 |
| sebner | gn8 folks :) | 23:14 |
| * RAOF goes back to unbreaking his laptop. | 23:16 | |
| RAOF | Turns out there are a number of flaws in our netboot image :| | 23:17 |
| norsetto | good night all | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
