[00:02] evening [00:03] afternoon [00:32] hi all [00:44] hey all [00:46] hi people [00:46] hi Hobbsee [00:46] greetings mruiz! [00:47] :-) [00:48] Hobbsee, Did you read my comment about bug 178869? [00:48] Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Undecided,New] https://launchpad.net/bugs/178869 [00:49] mruiz: no [00:50] Hi Hobbsee [00:50] heya tritium [00:59] * tritium wonders what part of the topic changed... [00:59] hey Hobbsee [00:59] hiya zul [01:00] good christmas? [01:00] yeah [01:02] How often is it appropriate to request packages to be reviewed if the previous request wasn’t noticed or acted upon? I asked about http://revu.tauware.de/details.py?package=hardware-connected and http://revu.tauware.de/details.py?package=apt-mark-sync five hours ago. [01:03] ion_: well it is the christmas break for most developers so you kind of have to be patient [01:03] I am in no hurry. I’m just asking not to offend anyone by spamming the request. :-) [01:04] ion_: normaly once a week ( mondays ) [01:04] imbrandon: Okay, thanks. [01:05] hey imbrandon [01:05] heya zul [01:33] psus: -sa will probably solve your problem. [01:33] jonnymind: -0falcon1 would be a good way to be lower than either an upcoming Ubuntu or Debian release. [01:34] ion_: Once a day, but people may well not look except on Mondays. On Mondays (any time zone) maybe every 6 hours is acceptable. [01:35] persia: Thanks. [01:36] imbrandon: There's some further oddity in the buildd chroot. I can't even get a manual apt-get dist-upgrade to work from a chroot into the buildd tarball: it seems to be more complicated than just a normal update. [01:37] Greetings all. [01:38] hey TheMuso [01:39] Hey zul. [01:39] Have a good break? [01:39] ion_: What is ./.gpb.conf ? [01:39] yeah was kind of sick the past couple of days ago [01:40] Ah that sucks. [01:40] persia: The ”upstream” source and the packaging are in a single git repository but in different branches. That config file tells git-buildpackage which branch to generate the orig.tar.gz from and which branch to get debian/ from, so you can just cd to the repository tree and run git-buildpackage. [01:41] ion_: OK. VCS leftovers then. Thanks. [01:43] persia: It *can* be removed, then one just needs to supply the branch names to git-buildpackage as parameters. [01:44] ion_: I haven't used git-buildpackage, but I've been advised that for svn-buildpackage, it's best practice to strip all the VCS stuff when making the package. [01:45] persia: ahh that sucks [01:46] imbrandon: Does it? If there are enough people who believe that .gbp.conf should normally be included in a source package, I don't see any reason why it couldn't, but I haven't seen that file in many packages (even ones I know to be managed in git) [01:46] * persia realises that the wrong context was chosen :( [01:48] ion_: apt-mark-sync commented. Only GPL version, priority, and missing mechanism for collecting upstream code are blockers. [01:49] persia: Thank you. I’ll take care of the same issues for the other package as well. [01:49] ion_: OK. I won't review it now then :) [01:49] I’ll also make sure .gbp.conf doesn’t spill into the package. [01:50] persia: i ment about the buildd [01:50] imbrandon: Right. Sorry :) The buildd tarball is available from http://launchpadlibrarian.net/10891721/chroot-ubuntu-hardy-i386.tar.bz2 if you want to have a play. [01:51] maybe here in a bit, i doubt i can do much better than yall did though [01:51] (warning: 50MB behind that link) [01:51] onyl 50? wow [01:51] i figured much more, i just downloaded 6gb so another 50 wont be bad [01:51] A lot of base is text, and bz2 does a pretty good job. [01:52] yea [01:55] Hrm. New Debian audacity doesn't work with JACK for some architectures, and current Ubuntu audacity doesn't seem to work with pulseaudio. Anyone have any thoughts on how audacity should work? [01:57] it should _just_ work :-P [01:58] persia: imho whatever is default for hardy [01:58] but i dislike JACK sooo [01:59] brandonperry: Yes. I'm just not sure pushing through padsp is the right answer. To me it makes sense to either whitelist audacity to block pulse, or to ignore the possible portaudio issues and force JACK. [01:59] imbrandon: Do you use audacity? What is your typical input source? [02:00] persia: What are `some architecture'? [02:00] persia: files [02:00] eg ogg or mp3 or something other [02:01] Debian bug #406754 [02:01] Debian bug 406754 in portaudio19 "portaudio19: FTBFS: #error Memory barriers are not defined on this system." [Serious,Fixed] http://bugs.debian.org/406754 [02:01] if i use "live" input its generaly with jokosher+gst [02:01] Err.. That's not right. [02:01] and yea i use it once or twice a week [02:01] persia, sorry, I not exaclty sober right noww [02:01] ignore me [02:01] but not a "ton" [02:02] Fujitsu: all !i386 !powerpc [02:02] Not even amd64? [02:02] imbrandon: Ah. So for your usecase, padsp would work fine. Thanks. [02:02] Fujitsu: Nope. [02:04] Fujitsu: Actually, on review, it seems the bug I mentioned before is correct, just that the exposure in audacity is due to a private included library (Grr...) === harrison1 is now known as harrisony [02:05] Woo! [02:11] persia: I take it i should file a bug at launchpad so that i can close it with the initial release? [02:12] ion_: If there isn't already one there. I tend to see lots of needs-packaging dupes, so please search to help reduce the count. [02:12] Ok [02:20] * Fujitsu wonders what the heck is wrong with the buildd chroot. It certainly won't dist-upgrade, but after installing (dpkg -i from /var/cache/apt/archive) bits of the dependency chain (from the new tzdata through libc6 through libc6-amd64...) it dist-upgrades fine... [02:23] Fujitsu: Does it dist-upgrade fine for you? I was getting an error about immediate configuration. If it works for you, someone just needs to publish the upgraded chroot on launchpad. [02:24] persia: Not from the start - I had to install a couple of bits (including libstdc++6) manually, then dist-upgrade worked. [02:24] * Fujitsu pokes harde.r [02:25] Fujitsu: In that case, it just needs to be adjusted not to need manual installation (maybe a dependencies chain?) or needs the results of the manual push to be published. [02:26] persia: Now I know how to unbreak it like that, I'm working out exactly what is wrong. [02:28] OK, upgrading libc6(-dev) is enough to get it working, but that wants a new tzdata too. [02:29] persia: Is “and is licensed under the same terms as the upstream package, see above.” okay? [02:30] ion_: Entirely. I was asking for the addition of the text "v2", but that works just as well (if a bit more work). [02:30] * Fujitsu forgets when the problem appeared. Was it after the 24th? [02:30] persia: I was thinking of writing that to have no ambiguity about whether it’s “v2” or “v2 (or any later version”. :-) [02:31] * persia looks at logs [02:31] ion_: Good choice [02:32] Fujitsu: First reference to the problem I can find is 2007 December 25 09:37 UTC [02:33] persia: So just after the new libc6 upload. [02:33] Fujitsu: ~ 24 hours later. [02:33] RIght. [02:47] Simply adding to libstdc++6 a Pre-Depends on the new libc6 makes everything work perfectly. [02:50] Fujitsu: Excellent. Is that likely to break anything else? [02:51] persia: I've no idea. It should be necessary, though. [02:52] *shouldn't [02:53] Fujitsu: As I understand it, our choices are to either upload an automagical fix (like that), or wait for someone to publish the results of a manual dist-upgrade. I wonder why it worked for most people's local chroots. === harrison1 is now known as harrisony [02:54] * persia realises that the upgraded libstdc++6 probably can't build on the current buildds, so the manual path may be the correct choice. === harrison1 is now known as harrisony [02:56] I'm trying to reproduce it in a clean chroot here. [02:56] But it will need to be done manually on the buildds, right. [03:07] * Fujitsu shrugs, and decides that cosmic rays did something bad to the buildd chroots. [03:07] ion_: Don't worry about it this time, but in general it's nice to have a little advertisement for the package and a link to the homepage in the needs-packaging bugs. [03:07] I guess we poke somebody to upgrade libc6 manually and dist-upgrade all of the broken ones. [03:07] Fujitsu: That sounds about right. Monday, I'd think. [03:07] I can't work out what makes them fail when a similarly versioned one here works fine. [03:09] persia: I doubt anybody will be here on the 31st... [03:10] It's part of the official Holiday break? I thought it was considered a working day. [03:13] persia: Ok :-) [03:14] persia: I made the changes to apt-mark-sync. They should be visible in REVU soonish. [03:16] Oh, i accidentally uploaded a .changes file with both source and binary files. I wonder how REVU handles it? [03:16] It won't even see it. [03:16] It globs for *_source.changes [03:21] imbrandon: are kdebindings going in /usr/lib/kde4/* ? [03:37] Heya gang [03:39] boo [03:43] Heh, hi nixternal [03:43] * nixternal kicks imbrandon in the shin! [03:44] imbrandon: I updated kde.mk to the latest from debian, removed utils.mk, and updated the .install files to follow the kde.mk, and all is seeming well thus far === cheguevara_ is now known as CheGuevara === bigon is now known as bigon` [03:59] Blergh, I think apt is doing stupid things on the buildds. It's not even trying to upgrade libc6 until the end, so libc6-amd64 won't configure, so lib64gcc1 won't configure, so apt can't find anywhere to configure libstdc++6. [04:00] Fujitsu: ya, been doing that for a few days now [04:00] Right, but I'm trying to work out *why*. [04:00] apt-get's debug output isn't the best. [04:02] * Fujitsu wishes he could manipulate apt's TODO list after it had calculated it. [04:02] persia: In case you still feel like reviewing, i (think i) implemented the changes you requested in http://revu.tauware.de/details.py?package=apt-mark-sync and http://revu.tauware.de/details.py?package=hardware-connected :-) [04:11] nixternal: sorry was afk [04:11] nixternal: sounds good [04:12] my build box just over heated :) [04:12] heh [04:12] did you add install files for the other packages ? [04:12] or just what was there already ? [04:13] just what was there so far...I will add the rest as needed [04:13] killer ok [04:13] rules just includes the debian/cdbs/kde.mk now, as it controls everything for kde4 [04:13] basicly just each of the top level dirs ( its a checkout of trunk in kdebinding ) [04:13] kk [04:18] So no package is being built now? [04:20] minghua: The four big architectures have broken buildd chroots, right. [04:20] Fujitsu: Thanks. [04:21] This naturally happens a day or two after the Canonical world vanishes for a week. [04:21] why do people mess with core packages like glibc right on christmas eve :P [04:21] Well, not a convenient time for buildds to break, of course. [04:21] But maybe they break every now and then, it's just we are noticing now because of the holiday. :-P [04:22] gnight all [04:23] night imbrandon [04:23] Night imbrandon. [04:35] Oh blergh. LP is being braindead, yay. [04:36] Any of the links on https://edge.launchpad.net/ubuntu/+source/gcc-4.2/4.2.2-4ubuntu1/+files/ work for anybody? [04:37] Fujitsu: Not for me. I get 404 with OOPS numbers. [04:38] minghua: That's what I thought. [04:38] * Fujitsu attacks kiko. [04:39] persia_: Hello there. === fifoi is now known as CheGuevara [04:39] minghua: Hey. [04:40] persia_: In case you remember my problematic (or in your words, incorrect) test case about dates we talked about the other day, I changed my test case and enumerated all possible dates for testing. [04:40] :-) [04:40] * minghua is now much more confident about his code's correctness. [04:41] minghua: Excellent. That sounds like the right question to be asking :) [04:46] * Fujitsu kicks apt. [04:47] (both for having too little debugging output, and needing to be debugged in the first place) [04:47] * persia_ is unable to suspend disbelief that there is code which does not need to be debugged [04:50] Shouldn't it be smart enough that if `apt-get install libc6' can't happen due to conflicts with the currently installed tzdata, it will install the new one which isn't conflicted with? [04:51] Fujitsu: Isn't that why aptitude was written? [04:52] I thought that's why apt was written in the first place... [04:52] I would have thought that that case wouldn't have been too uncommon, but perhaps so. [04:53] There are a couple cases where apt dependency resolution can cause issues, which is part of why it became common to use `apt-get dist-upgrade` in sid, rather than `apt-get upgrade`. aptitude is smarter about these things, and handles several cases better. Updata-manager is even better, but only tuned for full release upgrades. [04:53] Fujitsu: It's probably very uncommon for daily (i.e., not buildd) use, as people would have used "apt-get upgrade" instead. [04:54] persia_: Hey man. I assume wx-config --ldflags is now wx-config --ld ? [04:54] Hmm, update-manager looked pretty stupid to me last time I used it for gutsy->hardy upgrade. [05:07] * Fujitsu wonders why libstdc++6 needs lib64gcc1 on i386. Removing that dep makes a dist-upgrade work fine. [05:08] * minghua can only say that listdc++6 on Debian i386 does NOT depend on lib64gcc1... [05:09] Only -4ubuntu2 does here, where it appears we moved to symbol-based shlibs. [05:09] Didn't -4ubuntu3 get built? [05:09] StevenK: It got killed by the chroots. [05:10] chroot failures, that is. [05:10] Ahhh, it was killed by -4ubuntu2 [05:10] * Fujitsu thought -4ubuntu2 FTBFS on amd64, which -4ubuntu3 was meant to fix, but didn't, because the chroot was borked. [05:10] * Fix typo in lib32gomp1 symbol file. [05:11] That's in -4ubuntu3's changelog, probably why. [05:11] Oh, -4ubuntu3 built on amd64. [05:11] But then why isn't amd64 unbroken? [05:12] Errr... because amd64 is 64bit? [05:12] StevenK: If -4ubuntu2 was the thing that killed it, why is amd64 dead? [05:12] (if libstdc++6 depending on lib64gcc1 was the reason buildds got broken, that is) [05:13] Ahh, I apparently misread Fujitsu. [05:13] * minghua shuts up. [05:15] minghua: The upgrade program for gutsy->hardy hasn't been written yet, thus update-manager won't do a very good job with it [05:15] Amaranth: Oh. Thanks. [05:15] Gah, how the hell does 'g++' just all of the sudden stop working in a build? [05:16] Right, why does amd64 libstdc++6 want lib32gcc1, while the i386 one wants lib64gcc1? That sounds wrong. [05:16] * Amaranth cries [05:17] * bddebian too [05:17] multiarch causes pain [05:17] Fujitsu: multiarch [05:17] That's for cross compiling, right? [05:21] wha, multiarch is in apt now? [05:21] no [05:21] Amaranth: Well, also to support a mixed 32/64 bit environment. There are applications that do better with 32-bit due to odd code assumptions, and it'd be nice to be able to generate a binary for amd64. Similarly, there are applications that really want 64-bit, and it would be nice to provide an i386 binary (even if it runs slowly). [05:22] at this point by the time apt would grow multiarch support it probably wouldn't be worth having anymore :P [05:22] How very odd. In the broken chroot, one must install tzdata before everything else, for the moment. After that, installing lib64gcc1 then dist-upgrading works, but dist-upgrading without manually installing lib64gcc1 (even though the dist-upgrade tries to install it) fails. [05:25] It seems the dist-upgrade just for some reason doesn't get around to installing libc6 before it tries to install lib64gcc1... Blah. [05:28] Fujitsu: Interesting case. Did you test in a buildd yourself, or did you just read the logs? [05:30] minghua: I have the chroot tarball and am trying things on it here. [05:31] Fujitsu: Would aptitude fare any better than apt-get? [05:31] minghua: Oh yes, the upgrade works flawlessly there. [05:32] Fujitsu: Hmm. I remember similar things happening when people tested woody->sarge upgrades. [05:33] That, among others, was the reason release notes start recommending aptitude for upgrading over apt since sarge. [05:33] Oh, oops, I must have done something different last time. [05:33] aptitude fails similarly this time. [05:33] I'm sure I tried it before. [05:34] aptitude has the sanity to install the new tzdata, however. [05:36] :) [05:36] one thing i have found disappointing (and should be fixed) is multilib in ubuntu [05:36] there should be lib32 packages for all libs that are shipped [05:36] i should probably make a blueprint about this ;) [05:37] That sounds like a fairly big job, really. [05:39] nenolod: Are they really needed? Unless there is a useful rdepends, I'm not sure we need it. If there is a useful rdepends, adding another binary to the existing libs package seems appropriate. [05:40] persia_, well, zsnes depends on lib32 of ncurses and such [05:40] Where's 64-bit zsnes? [05:40] Fujitsu, it's 32-bit. [05:41] Why? [05:41] Fujitsu, because it's x86 assembly. [05:41] Ah. How silly. [05:41] * nenolod waits for the next "Why?" [05:41] "because the developers are morons" [05:41] actually, most emulator developers seem to be like this [05:41] especially in playstation world [05:42] Writing an emulator such that you need an emulator to run the emulator after a few years? [05:42] yeah [05:42] Fujitsu, i recently forked PCSX-df because it has died [05:42] Fujitsu, i'm rewriting it with SDL. it's a disaster. [05:42] :D [05:42] No idea what that is. [05:42] Hah. [05:42] Fujitsu, PCSX-df is the "debian fork" of PCSX, which is a playstation1 emulator. [05:43] Fujitsu, the in progress rewrite is UPE ( http://nenolod.net/upe ) but it's so insane, that i haven't gotten to a point where it's releasable yet. [05:43] UPE is 64-bits safe though, which is something PCSX{-df} is not. [05:51] nenolod: Does it even run on amd64? I've found not a few assembler issues when trying to port code. If it would otherwise run, adding libcurses to ia32libs doesn't seem unreasonable. [05:52] persia, it runs when compiled with -m32 [05:52] obviously it's not going to build with -m64 [05:53] cause it is dependant on 32-bits architecture [05:53] nenolod: In that case, generate a bug & candidate for ia32libs, and add a bug task and candidate for the emulator. My concern is more that register handling is different, and some things break (especially for SMP). [05:53] persia_, i'll work on trying to patch the debian package of zsnes to run on amd64 [05:54] persia_, it runs fine when chrooted into a 32bit environment [05:54] Shouldn't we be thinking about replacing emulators that need emulation? [05:54] Fujitsu, snes9x is the other emulator and it crashes on many obscure titles [05:55] Fujitsu: One would think this would be a natural step due to speed, but as in the case of xmms, it's not as easy as one would hope. [05:55] (of course, ZSNES includes a 64-byte SPC700 ROM) [05:55] (pagefault even says this publically) [05:55] (so perhaps removal altogether of ZSNES is the only option since it contains blobs which are not DFSG free) [05:56] * persia_ encourages removal of non-free [05:56] well, 64-byte SPC700 ROM is something that nobody cares about [05:57] but technically, it makes ZSNES DFSG non-free. [05:57] Seriously? 64 byte? How do you claim copyright on that? [05:57] minghua, well they dumped the microcode from the Super Nintendo's DSP [05:57] so i imagine SONY still holds a copyright on it [05:57] minghua: You can claim copyright on 1 bit, but defending it is the hard part: one has to show that it is the result of an independent creative process. [05:58] Can't some people do a clean-room re-implementation of that? [05:58] i could try to patch out the microcode. [05:58] it's not really needed [05:58] i don't think [05:58] nenolod: That'd be need. If you succeed, consider a repack for universe. [05:58] s/need/neat/ [05:59] minghua, hehe. i did a cleanroom reimplementation of the PS1 BIOS. [05:59] minghua, including software executive layer [05:59] :D [06:00] nenolod: that sounds fun [06:01] joejaxx, it kind of works too. there's a long ways to go though. [06:01] nenolod: clean-room rev-eng is always fun [06:04] at any rate, the binary blob starts at line 47 in zsnes/src/cpu/spc700.asm [06:05] * nenolod works on it [06:45] * Hobbsee waves [06:48] Hello Hobbsee. [06:48] minghua: how gose it? [06:49] Hey Hobbsee. [06:49] hiya Fujitsu [06:50] Hobbsee: Quite well, although nothing really on Ubuntu front. What about you? School vacation time? [06:50] minghua: yeah, on uni vacation. nothing really ubuntu-related either, partly because all the buildds are dead, and no one cares enough to fix them, who actually can. [06:50] minghua: work, etc. sucky :) [06:50] * Hobbsee should do ubuntu stuff [06:52] Yeah, work. [06:52] * minghua needs to install Debian on a new box and migrate a server tomorrow. [07:10] so quietly~~ [07:19] seems that lib32sdl is broken depends [07:19] :D === wolfger_ is now known as wolfger [08:14] if anyone who works on ia32-libs is here, please look at https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/179031 as soon as you have time :) [08:14] Launchpad bug 179031 in ia32-libs "lib32/libSDL depends on old libraries and needs to be rebuilt" [Undecided,New] === \sh_away is now known as \sh [09:47] <\sh> moins [10:16] Hiya \sh === \sh is now known as \sh_away [11:19] * Hobbsee waves === \sh_away is now known as \sh [11:20] Hi. Upstream released a new version for a package that I created. What do I have to do to get that in the repos? Upload the new one to revu? I saw someone who used bugs with interdiffs attached. What's the preferred way? [11:28] <\sh> afflux:well both ways :) === dfiloni_ is now known as dfiloni [11:30] okay, I'll upload to revu [11:34] hi all [11:35] afflux: interdiff is preferred [11:35] oh, okay. === asac_ is now known as asac [12:13] hi all. MOTU Q&A today? [12:13] None scheduled in -classroom, but you're welcome to ask questions here anytime (and someone may well answer). [12:15] persia, you're my MOTU hero :-) [12:15] mruiz: dholbach is on vacation so unless someone jumps in for him, there won't be a session today [12:16] thanks geser [12:27] bug 164166 [12:27] Launchpad bug 164166 in ebug-http "FTBFS: tries to download from CPAN" [Critical,Confirmed] https://launchpad.net/bugs/164166 [12:27] can someone check this one [12:27] i've attached a debdiff [12:27] it builds fine in my pbuilder.. [12:28] ups.. i need to create a patch to the patches directory [12:30] I need an opinion of the bug 178869 [12:30] Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Undecided,New] https://launchpad.net/bugs/178869 [12:30] mruiz: What sort of opinion would you like? [12:33] <\sh> mruiz: the problem is not gnome-voice-control...the problem is pbuilder-satisfy-depends-dummy [12:33] \sh: Are you sure? "automake-1.9" vs. "automake1.9". [12:34] <\sh> persia: check the buildlog... [12:34] (and yes, pbuilder-satisfy-depends-dummy is broken) [12:34] <\sh> it fails at this point...and not in the build-dep of g-v-c [12:35] <\sh> so p-sd-d is wrong assuming automake-1.9 is existing...automake1.9 is most likely more correct [12:35] \sh: Yes, but it still FTBFS for me with sbuild. [12:35] \sh: "automake-1.9" is defined in debian/control [12:36] <\sh> persia: so pbuilder is again wrong...wrong error message [12:36] mruiz: As a general note, usually we don't bump the standards version unless it's required, or the package isn't in Debian, as it would be unnecessary deviation. Also, it's nice to not include config.guess or config.sub variance in the debdiff, as it makes it easier to read. [12:37] \sh: Right. There are two bugs: the pbuilder bug, and the FTBFS in gnome-voice-control. The pbuilder bug is already recorded as bug #125107, but bug 178869 seems a good way to address the gnome-voice-control bug. [12:37] Launchpad bug 125107 in pbuilder "[gutsy] pbuilder-satisfydepends-gdebi can't resolve pure virtual build-depends" [Undecided,New] https://launchpad.net/bugs/125107 [12:37] Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Undecided,New] https://launchpad.net/bugs/178869 [12:38] <\sh> well, change automake-1.9 to automake1.9 (normally this could be done with automake, because it should point to 1.9 nowadays, right?) [12:40] persia, just delete the config.{sub,guess} variance (if appears) from the debdiff? [12:40] \sh: I thought the default was 1.10 these days (although I may be mistaken) [12:41] mruiz: Right. Personally, I prefer to move the autocopy from clean to configure if the autotools hints are to be autocopied, as it makes debdiffs nicer (although there are strong arguments against autocopy, which deserve respect). [12:44] persia, I was reading your opinions about that and, in this case the autocopy is in "clean" section :-) [12:45] mruiz: Right. That's the part I don't like (although I'm not sufficiently in favor of arbitrary variance from Debian to encourage fixing it). Specifically, if the files are to be copied at build time, they should be copied for configure: and not for clean: as the copy actually makes the package less clean. [12:45] :-) [12:46] persia, you're a debian/rules magician ;-) [12:46] This is especially annoying for SRUs, as it means that the source package candidate for upload must be prepared in the target release, or it will not have the right hint files to properly compile for the target. [12:47] Further, given sufficient variance in the hints files, there is a possibility of creating a FTBFS situation when backporting. Anyway, enough ranting about that :) [12:47] <\sh> persia: could be...gutsy was 1.9 [12:48] \sh: Really? I thought I saw a bunch of 1.10 stuff during gutsy. Maybe just pushing the leading edge. [12:50] RainCT: didn't you mix source and binary packages in bug #179085 ? [12:52] indeed :P [12:53] afflux: thx, changed that [12:56] RainCT, o/ [12:56] hi totopalma :) [12:56] :) === persia changed the topic of #ubuntu-motu to: Masters of the Universe https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com [13:04] :) [13:04] persia: how about to add REVU ? [13:04] There seems to be an extra space there. [13:04] yeah === Kmos changed the topic of #ubuntu-motu to: Masters of the Universe https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com [13:04] Kmos: I'm not in favor of encouraging lots of NEW packages at this point. [13:05] persia: you're right.. bug fixing is better [13:05] Kmos: Have you uploaded ebug-http to your PPA without testing it? [13:08] Fujitsu: i also use my ppa for testing :) [13:08] Kmos: So you'll kill off the PPA buildds. Great. [13:09] Kmos: Best to work locally first. Something like that can take down the PPA for everyone. [13:09] Fujitsu: no.. it won't kill it =) [13:09] Kmos: Why not? [13:09] it will fail with another build problem [13:09] not the cpan one [13:09] Kmos: Did you know that before you uploaded? [13:09] You sure it'll fail there first? [13:09] persia: yep [13:09] ... [13:09] Fujitsu: yes, I am [13:09] Kmos: Why upload to a PPA if you know if FTBFS? [13:09] You uploaded a known-dodgy package? [13:10] i fixed it manually in the code [13:10] but after I saw it fails in testing because of the required module [13:10] not about the download from cpan [13:10] Kmos: does the package you uploaded to PPA build now or still FTBFS? [13:11] Fujitsu: because of the !~ problem [13:11] Kmos: Right, but why upload to a PPA when you know it will FTBFS? That's just a waste of resources. [13:11] qa.ubuntuwire.com is not loading (at least, the two links in the topic) [13:11] geser: still FTBFS.. [13:11] wolfger: Works for me. [13:11] persia: i thought it won't FTBFS [13:11] :-( [13:11] wolfger: works from here [13:11] wolfger: works for me. [13:12] hmm. works now. Maybe a hiccup on my end [13:12] it won't break the buildds [13:12] Kmos: You're meant to *know* that it won't FTBFS. [13:12] You should test build before letting a package leave your system. [13:13] wolfger: same happened here [13:13] Further, only packages expected to work should be uploaded to a PPA [13:14] right.. i won't do it.. i really thought it was fixed. :( === bigon` is now known as bigon [13:16] Kmos: An easier solution is probably to just depend on libtest-expect-perl, or whatever the package is likely to be. [13:17] libtest-deep-perl [13:17] That sounds wrong. [13:18] it's Test::Deep [13:19] Didn't I see it wanting Test::Expect? [13:19] * Fujitsu rereads. [13:19] requires Test::Expect [13:20] libtest-expect-perl [13:20] it's this one.. but isn't available at gutsy [13:20] !info libtest-expect-perl hardy [13:20] libtest-expect-perl: Automated driving and testing of terminal-based programs. In component universe, is optional. Version 0.30-2 (hardy), package size 6 kB, installed size 68 kB [13:20] ah nice [13:21] * Kmos testing build [13:22] - Test::Expect ...loaded. (0.30) [13:22] That looks better. [13:22] but it fails in the same thing that my package will fail in PPA [13:22] Which is..? [13:23] http://rafb.net/p/H8Lhkv41.html [13:24] there isn't any patch upstream [13:24] None of the subtests failed, but it failed anyway. Nice of it, really. [13:26] hehe [13:27] i've reported to debian the missing package on build-depends.. [13:27] I hope you used the existing bug. [13:27] Fujitsu: yes :) [13:28] Kmos: why not actually get the package to build, before reporting it to other distros? [13:28] in case there is more [13:28] Hobbsee: i reported about one specific bug.. this one is a new one =) [13:29] http://rt.cpan.org/Public/Bug/Display.html?id=17988 [13:29] here it fails with 0.00% not 0.100% [13:29] lol === cprov is now known as cprov-out [13:39] Kmos: ... your build succeeded. [13:39] So you were expecting it to fail to avoid the hang, but it succeeded. [13:40] So both failure conditions failed to be satisified. === \sh is now known as \sh_away [13:40] * persia is somewhat confused as to whether failing to fail is entirely bad, although the consequences might be worse [13:41] Fujitsu: really strange [13:42] persia: I am a little glad that he mis-predicted both failure conditions, as if one of them had actually failed, we'd have one buildd out of action. [13:42] i should make a debdiff with the b-p package ? [13:42] Kmos: b-d? [13:42] libtest-expect-perl [13:42] with this [13:43] Fujitsu: Yes. It just will look odd when collated: I'll need to think of appropriate phrasing. [13:43] * Hobbsee thinks Kmos should trash his own machine, not someone else's. [13:43] persia: It is a little confusing like that, yes. [13:44] Hobbsee: my machine isn't too new.. more old =) [13:45] Kmos: and that's any excuse? [13:45] * Fujitsu pities the buildds. [13:45] Kmos: That might mean it takes a while, but you can at least reset your machine easily, whereas it's not so easy for a machine in a data centre [13:45] Hobbsee: it isn't [13:46] Kmos: so, uh, why do you choose to act that way then? [13:46] Hobbsee: I want to test it with buildd machines.. like this case [13:47] it builds fine there [13:47] and it fails in pbuilder [13:47] :( [13:47] Kmos: You might try running sbuild against a buildd chroot if you want a real test. [13:48]