| KillerKiwi2005 | Whats the correct way to add a user to the fuse group? | 00:01 |
|---|---|---|
| somerville32 | KillerKiwi2005, See #ubuntu for support | 00:01 |
| KillerKiwi2005 | I mean for an installer... not as a user | 00:01 |
| KillerKiwi2005 | we're working on a deb for the klik2 project | 00:01 |
| ScottK | KillerKiwi2005: It's still OT for here and #ubuntu-devel as these channels are about development OF Ubuntu, not on Ubuntu. | 00:05 |
| saivann | andi5 : Sorry for the time it took, I'm here now | 00:07 |
| KillerKiwi2005 | scottKthats what im asking how would an "ubuntu" MOTU do that? | 00:07 |
| * andi5 is here | 00:08 | |
| saivann | andi5 : bug 184176 is probably about a change in a library in hardy because the same package builded without any problem 4 days before, and now there's a lot of errors during the compilation process | 00:08 |
| ubotu | Launchpad bug 184176 in gnucash "[hardy]Gnucash fails to build" [Medium,New] https://launchpad.net/bugs/184176 | 00:08 |
| saivann | andi5 : I suggest that we look to find what library has been updated/changed in the last 4 days that can have an impact on gnucash | 00:09 |
| andi5 | yep | 00:09 |
| blueyed | jonnymind: you need to adjust Suggests in debian/control. | 00:09 |
| andi5 | i thought of pango, but that was last changed in december | 00:09 |
| jonnymind | Immediately: | 00:09 |
| jonnymind | blueyed: immediately. What's wrong? | 00:10 |
| KillerKiwi2005 | scottK: Who/Where should I ask... ? | 00:10 |
| saivann | andi5 : I must admit that I'm pretty new to this so I might be wrong, but since it builded OK 4 days ago, I think that it makes sense | 00:10 |
| jonnymind | arg | 00:10 |
| blueyed | jonnymind: seen it? :) | 00:10 |
| jonnymind | sorry. | 00:10 |
| saivann | andi5 : libgif changed today | 00:10 |
| andi5 | libgif is irrelevant, from my perspective :) | 00:10 |
| jonnymind | hehe, you never get rid of all those details. | 00:10 |
| saivann | andi5 : Okay :) | 00:10 |
| jonnymind | blueyed: fixed and reuploading. | 00:11 |
| andi5 | it touched gnucash mainly because bit-rotten build dependencies, i guess :) | 00:11 |
| saivann | andi5 : If you build gnucash in ubuntu hardy, do you also get a lot of errors? | 00:11 |
| andi5 | +of, please keep ignoring my spelling :) | 00:11 |
| andi5 | saivann: i tend to build gnucash from a self-compiled gnome stack, so i cannot readily answer that question :( | 00:11 |
| saivann | andi5 : Ok | 00:12 |
| blueyed | jonnymind: typo in README (s/OPERTION/OPERATION/) | 00:12 |
| jonnymind | Ok, thanks. | 00:12 |
| saivann | andi5 : I planned to look at each gnucash dependency to find which one were updated in the last 4 days and find which one cause this problem, unless you want to take care of this | 00:12 |
| andi5 | how do you do that? open up launchpad on the corresponding source package? | 00:13 |
| blueyed | jonnymind: same file, s/ad runs/and runs/ | 00:13 |
| ScottK | A large number of graphics related packages have recently been upgraded for the recent libungif/libgif transition. | 00:13 |
| saivann | andi5 : Yes, just by looking at the debian changelog, I can see each updates with the date | 00:13 |
| andi5 | saivann: feel free to do that... i still hope to see something from the compiler errors :) | 00:14 |
| jonnymind | blueyed: ack. repacking | 00:14 |
| ScottK | KillerKiwi2005: Support is on topic in #ubuntu-server | 00:14 |
| saivann | andi5 : Great thanks for your help on this! I should start working on that problem in approximately 5 hours, I'll keep you aware if I find something relevant | 00:15 |
| === \sh is now known as \sh_away | ||
| andi5 | saivann: what time zone is yours? .. i am UTC+1 here, so i will be sleeping in 5 hours :) | 00:15 |
| saivann | andi5 : Oh, bad :P So I'll post informations on the bug report ( it's weekend here and my brother want to eat pizza :) ) | 00:16 |
| andi5 | saivann: have fun then :-D | 00:16 |
| saivann | andi5 : Thanks :) I'll keep the bug updated and I'll work on this, thanks a lot for your work on gnucash | 00:17 |
| * saivann is gone | 00:17 | |
| andi5 | bye | 00:18 |
| saivann | bye | 00:18 |
| === n3xu|laptop is now known as nexu | ||
| jonnymind | ScottK: I have reuploaded after a couple of suggestion made by blueyed. | 00:35 |
| jonnymind | Good night and sweet dreams to all. | 00:35 |
| jonnymind | *suggestions | 00:35 |
| Legendario | hi, i would like some to answer me some doubts... i want a certain program to be in universe but i saw that there is already a .deb package on the authors homepage. Can it be placed on the REVU or do i need to build it again to place it on REVU | 02:06 |
| bddebian | You need to upload a source package, not a .deb | 02:08 |
| Legendario | bddebian, i know. but do i need to get through all the process of changing /debian files, signing and building it? | 02:14 |
| imbrandon | Legendario: its recomended yes | 02:15 |
| === bigon is now known as bigon` | ||
| Legendario | ok... that's what i wanted to know. I can't just send the .change file with the dput? right? | 02:16 |
| imbrandon | correct, it has to at very leaste be signed by the uploader , thats also on the REVU keyring | 02:17 |
| Legendario | imbrandon, thanks a lot, dudes... | 02:18 |
| === Pricey is now known as PriceChild | ||
| Legendario | is anyone here a reviwer at REVU? | 02:30 |
| Legendario | anyone? | 02:42 |
| minghua | Legendario: Just paste the REVU URL to advertise here generally, don't ask for any specific reviewers. | 02:43 |
| minghua | Legendario: Describing what the package does also helps. | 02:43 |
| Legendario | minghua, ok thanks... | 02:44 |
| Legendario | will do it right now | 02:44 |
| Legendario | http://revu.tauware.de/details.py?package=odfviewer is a simple odf viewer and my first package build | 02:54 |
| Legendario | http://revu.tauware.de/details.py?package=sive it's simple ipod video encoder and my second package build | 02:55 |
| Legendario | i would apprecite if anyone can take a look at it... | 02:55 |
| LaserJock | hmm | 03:25 |
| Legendario | let me ask one more thing. Are the packages I build supposed to have their distro on its name? | 03:38 |
| minghua | Legendario: All REVU packages should target hardy, if that's what you're asking. | 03:39 |
| Legendario | mingha, that was not what i was asking, but it's nice to know... so i should set my pbuilder and chroot for hardy? | 03:41 |
| Legendario | minghua | 03:43 |
| LaserJock | Legendario: yep, new packages into Hardy so that's what you want to build for | 03:44 |
| Legendario | what i really wanted to know was if my resulting packages are supposed to have the distribution listed on the output .deb file name | 03:45 |
| LaserJock | nope | 03:46 |
| Legendario | ok... | 03:46 |
| Legendario | thanks a lot everyone ;-) | 03:46 |
| zul | nerds! | 03:52 |
| LaserJock | yes ... and? | 03:55 |
| Legendario | no nerds... only geeks... | 03:55 |
| LaserJock | speak for yourself ;-) | 03:56 |
| bddebian | heh | 03:56 |
| Legendario | i geek is better than a nerd, right?! :-D | 03:59 |
| LaserJock | no way man | 04:00 |
| * zul hands LaserJock his pocket protector | 04:00 | |
| LaserJock | geeks == Trekies, nerds == the people who put a man on the moon | 04:01 |
| LaserJock | zul: to go with my sliderule? nice! | 04:01 |
| bddebian | hehe | 04:01 |
| * nenolod files a bug against zsnes with a debdiff to make it build an amd64 version. | 04:13 | |
| nenolod | ;) | 04:13 |
| nenolod | (ia32-libs-dev would be nice *hint hint*) | 04:13 |
| * nenolod headdesks as he notices that zsnes was bumped recently. | 04:25 | |
| LucidFox | Yay! Qt under GPLv3! | 04:27 |
| ToyKeeper | ... only a decade late. :) | 04:27 |
| * nenolod headdesks at Qt being under GPL3. | 04:28 | |
| LucidFox | nenolod> GPLv2 + GPLv3 | 04:28 |
| nenolod | LucidFox, oh, ok. | 04:28 |
| nenolod | fantastic | 04:29 |
| nenolod | i succeeded in merging my ugly patch to make zsnes build on amd64. | 04:29 |
| ToyKeeper | I hope the ugly patch wasnt required for making the water effect work. :) | 04:31 |
| nenolod | ToyKeeper, zsnes uses x86 assembly, so is not buildable using 64bit libs. | 04:31 |
| nenolod | so .. off to play with ia32-libs it goes on amd64 ;) | 04:31 |
| ToyKeeper | Ah, okay. :) | 04:31 |
| ToyKeeper | I was just hoping I hadn't contributed to making it painful... | 04:32 |
| saivann | andi5: ping | 04:40 |
| LaserJock | LucidFox: Qt is v3 and v2? | 04:41 |
| LucidFox | LaserJock> Qt3, starting with just-released version 3.3.8b | 04:43 |
| LucidFox | Qt4 is underway | 04:43 |
| nenolod | can someone test that my debdiff in https://bugs.launchpad.net/ubuntu/+source/zsnes/+bug/184255 has no undesirable effect on x86? | 04:44 |
| LaserJock | LucidFox: I meant it is GPL v3 and v2? | 04:44 |
| ubotu | Launchpad bug 184255 in zsnes "[patch] build amd64 package of zsnes" [Undecided,New] | 04:44 |
| LucidFox | LaserJock> yes | 04:44 |
| LucidFox | previously, it was just GPLv2 | 04:44 |
| LaserJock | I thought Qt4 was going to be GPLv3 only | 04:44 |
| LucidFox | er, no | 04:44 |
| nenolod | LaserJock, lets hope so. | 04:45 |
| nenolod | LaserJock, that way there will be incentive for people to use a superior toolkit. :)) | 04:45 |
| LaserJock | LucidFox: you sure, upstreams are starting licensing wars | 04:45 |
| nenolod | e.g. GTK. | 04:45 |
| nenolod | :P | 04:45 |
| LucidFox | Lies! Qt > GTK! :p | 04:45 |
| LucidFox | (Disclaimer: GNOME user) | 04:45 |
| LaserJock | wx > * | 04:45 |
| LaserJock | I've grow to dislike GPLv3 immensely | 04:46 |
| LaserJock | *grown | 04:46 |
| LucidFox | Why? | 04:47 |
| nenolod | ISC license \o/ | 04:47 |
| nenolod | nobody can say bad about such a simple license | 04:47 |
| LaserJock | because it is going to cause an upstream I work with to have to reimplement a large chunk of code | 04:47 |
| LaserJock | a whole library | 04:47 |
| LaserJock | which just gonna be no fun at all | 04:47 |
| LucidFox | LaserJock> Why? They're GPLv2 and depend on something that's GPLv3? | 04:48 |
| LaserJock | yep | 04:48 |
| LaserJock | well, the library is GPLv2-only | 04:48 |
| LaserJock | and other libraries/tools are going to go to GPLv3 | 04:48 |
| LucidFox | Ah, so it's vice versa then. | 04:49 |
| LaserJock | so we have to pick which one to reimplement, basically | 04:49 |
| minghua | LaserJock: Why? Did they use said library before? | 04:50 |
| LaserJock | yep | 04:50 |
| minghua | Oh, should have read everything before replying... | 04:50 |
| LaserJock | it's one of the largest and most used chemistry libraries | 04:50 |
| LaserJock | we have 15+ packages in Universe depending on it | 04:51 |
| minghua | GPLv3 is going to fragment the FLOSS map, that was predicted. | 04:51 |
| nenolod | stupid GPLv3 | 04:51 |
| nenolod | actually, | 04:52 |
| nenolod | there is a solution | 04:52 |
| nenolod | if you control the copyrights to the main program | 04:52 |
| minghua | If I were the developer, I would have decided to stay at v2 rather than reimplement stuff. | 04:52 |
| civija | hey guys | 04:52 |
| civija | i'm preparing debdiff for slrnface package and I've changed Maintainer: to XSBC-Original-Maintainer:, but don't know now what i should put in new Maintainer: field? | 04:53 |
| nenolod | you can go to gpl3, and have a "linking exception" which says: "Modular code linking at runtime to this program is not affected by the GPL license on this program." | 04:53 |
| nenolod | then, dlopen the GPL2 library. | 04:53 |
| nenolod | problem solved. | 04:53 |
| nenolod | ;) | 04:53 |
| minghua | !info slrnface | 04:53 |
| ubotu | slrnface: shows X-Faces from a newsposting on an X11 terminal emulator. In component universe, is optional. Version 2.1.1-6 (gutsy), package size 25 kB, installed size 104 kB | 04:53 |
| minghua | civija: You should put Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>. | 04:54 |
| minghua | civija: And please read https://wiki.ubuntu.com/DebianMaintainerField | 04:54 |
| civija | minghua: aha, tnx! | 04:54 |
| nenolod | hmm, many of the packages i have encountered say "Ubuntu MOTU Team" | 04:55 |
| minghua | nenolod: That doesn't work, it's still violating the GPLv2 library's license. | 04:56 |
| nenolod | bummer. | 04:56 |
| minghua | nenolod: Unless the GPLv2 library's copyright holder acknowledge the "dlopen() is not derivative work" position as well. | 04:56 |
| persia | nenolod: Those ought be updated, but it's not worth an upload just for that. Maybe you can find another trivial bug, lintian warning, etc. in one of those packages and fix them? | 04:56 |
| nenolod | well | 04:57 |
| nenolod | i need to fix my debdiff for zsnes again :P | 04:57 |
| LaserJock | minghua: we can't 'cause we'll lose other, more fundamental libraries | 04:57 |
| minghua | LaserJock: What are they? | 04:58 |
| LaserJock | I can't remember | 04:58 |
| LaserJock | but with another project it's the toolkit, etc. | 04:58 |
| minghua | I assume you can always fork the old GPLv2 version... | 04:58 |
| LaserJock | well, that wouldn't be great | 04:59 |
| LaserJock | forking software all over the place | 04:59 |
| * nenolod yawns | 04:59 | |
| minghua | Ah, toolkit is going to be tough. Probably they should have used GTK or | 04:59 |
| LaserJock | we're hoping we can eventually get the GPLv2 library changed | 04:59 |
| minghua | ... or Qt in the first place. :-) | 04:59 |
| nenolod | there we go. | 04:59 |
| LaserJock | but a company controls much of the copyright and doesn't seem willing | 04:59 |
| nenolod | http://launchpadlibrarian.net/11437565/zsnes_1.510-2ubuntu1.debdiff is a great example of why ia32-libs-dev would be a nice package. | 04:59 |
| LaserJock | license changes are really rough | 05:00 |
| LaserJock | I don't see why FSF would make GPL version non-compatible :( | 05:00 |
| * minghua would rather see the forked GPLv2 version gets traction. :-) | 05:00 | |
| nenolod | LaserJock, because richard stallman has an agenda | 05:01 |
| minghua | Because for FSF (RMS?), the license is a tool for advancing their belief/agenda, not (so much of) a tool for development collaboration. | 05:02 |
| nenolod | LaserJock, the agenda is that "only his way is free software", so you either can do GPLv3 or get screwed over | 05:02 |
| nenolod | LaserJock, it's their intentional goal | 05:02 |
| minghua | I don't think RMS really wanted to say that. | 05:03 |
| persia | LaserJock: It wasn't intended to make them incompatible, just address what were perceived as "weaknesses" in GPLv2. These happen to include additional restrictions, which are not permitted to be applied to GPLv2 work. | 05:03 |
| nenolod | minghua, no i'm pretty sure the FSF guys want GPLv3 to be the only open source license | 05:03 |
| minghua | I see it rather as "When I say certain things are not Free, they are not", such and Tivonization, etc. | 05:03 |
| minghua | nenolod: They want (or rather, RMS wants), but he know it's not a practical goal. There is pretty much no way to get rid of BSD/MIT/X11 style license. | 05:04 |
| nenolod | minghua, i don't know, Eben Moglen seems to be doing a great job of incorrectly convincing people that it is legal to slap the GPL on BSD/MIT/ISC/X11 licenses | 05:05 |
| nenolod | minghua, or at least he was | 05:05 |
| minghua | Slap the licenses? | 05:05 |
| nenolod | he may have stopped after the ath5k disaster. | 05:05 |
| LaserJock | I'm fairly fond of MIT myself | 05:05 |
| nenolod | minghua, yes, as in bolting a GPL on top of the a trivially modified work | 05:06 |
| nenolod | i'd like the FSF & friends better if their associates didn't do such things | 05:07 |
| minghua | Well, if you are talking about the statement from SFLC after the fiasco about the wireless driver code between OpenBSD and Linux kernel people, I skimmed that statement and didn't see anything particularly wrong, or anyone pointing out such thing. | 05:07 |
| nenolod | minghua, before | 05:07 |
| nenolod | minghua, before the OpenBSD guys got ticked, eben moglen told the ath5k guys that it was "perfectly fine" to bolt a GPL license on top of the modified code | 05:08 |
| minghua | And as IANAL, I would consider Eben Moglen's opinion with very high respect unless another lawyer (or a judge on court) says otherwise. | 05:08 |
| LaserJock | in any case, it's really going to be difficult with the transition | 05:09 |
| minghua | nenolod: So? I think it's perfectly fine, too. | 05:09 |
| LaserJock | another one I think I'll have to deal with is squeak | 05:09 |
| minghua | It may be not quite moral, but I don't see anything illegal. | 05:09 |
| nenolod | minghua, it's legally fine yes, but ethically questionable | 05:09 |
| LaserJock | Apple agreed to relicense as MIT, which is sweet | 05:09 |
| LaserJock | but there's like hundreds of authors to track down and agree | 05:09 |
| persia | LaserJock: How is MIT better than ISC? | 05:10 |
| nenolod | persia, more words | 05:10 |
| nenolod | ;) | 05:10 |
| LaserJock | persia: I didn't say it was did I? | 05:10 |
| minghua | nenolod: There are ways to do it so that I feel it's ethnically/morally fine. And ethnics and moralities are always subjective anyway. | 05:11 |
| nenolod | minghua, i agree that there are ways to do it that are ethically and morally fine. | 05:11 |
| persia | LaserJock: You said "I'm fairly fond of MIT myself". You're the only non-rubyist I've seen say that, and I wondered why. | 05:11 |
| LaserJock | hmm | 05:11 |
| minghua | Maybe LaserJock is just a closet-Rubyist. :-) | 05:12 |
| LaserJock | I guess I'd say MIT-like | 05:12 |
| LaserJock | BSD, ISC, and MIT are all quite similar in my book | 05:12 |
| tuxmaniac | hello all | 05:12 |
| LaserJock | I hadn't even heard of ISC until the other day | 05:12 |
| LaserJock | but I really dislike GPL | 05:12 |
| minghua | LaserJock: "Quite similar", or "I don't know the real difference anyway"? ;-) | 05:13 |
| minghua | The latter for me. | 05:13 |
| LaserJock | I think they are related | 05:13 |
| LaserJock | as in BSD -> MIT -> ISC sort of roughly | 05:13 |
| persia | I don't like BSD because most people don't actually notice the bit about the Regents of the University of California, and just point at /usr/share/common-licenses/BSD. For MIT/ISC, it's just wordiness. | 05:14 |
| LaserJock | persia: I agree | 05:15 |
| LaserJock | I don't know a whole lot about LGPL but it seems sort of failed in some ways | 05:15 |
| nenolod | I think the GPL is becoming less popular because it is too complex | 05:15 |
| persia | Failed? How. There's lots of LGPL stuff, and some people seem quite happy with it. | 05:15 |
| LaserJock | I can't figure out if FSF want people to use it or not | 05:15 |
| jsgotangco | the LGPL is much friendlier (hence liberal) | 05:16 |
| nenolod | a lot of the new projects i have looked at which were not forks, have been ISC or BSD or MIT license | 05:16 |
| LaserJock | I certainly wish the library I'm talking about was LGPL but the company that first developed it wanted it GPL | 05:16 |
| persia | LaserJock: I believe they don't like people to use LGPL, but think it's better than using ISC (or the like) if you want people to use the source as infrastructure for a source-denied product. | 05:17 |
| LaserJock | I just kinda figure if I'm gonna through it out there I might as throw it out there and make MIT-ish | 05:18 |
| LaserJock | ah well | 05:19 |
| nenolod | the common public license is interesting too | 05:19 |
| nenolod | but i don't think i would use it. | 05:19 |
| LaserJock | in the mean time we'll have to figure out what to fork/reimplement and go through lots and lots of licensing wars | 05:19 |
| LaserJock | seems like libraries are just a real pain | 05:22 |
| LaserJock | sometimes with the cheapness of disk space i wonder if it'd just be better to do static linking more | 05:22 |
| minghua | LaserJock: Yeah, and when there is a security hole in the library... | 05:23 |
| LaserJock | or just writing everything with the app | 05:23 |
| LaserJock | it just seems to be all the rage to create a library even if only one app uses it | 05:24 |
| LaserJock | wb persia | 05:29 |
| pwnguin | also note that static linking takes more RAM | 05:30 |
| persia | LaserJock: Thanks. | 05:30 |
| persia | ScottK: sbuild still fails. Updating the bug. | 05:31 |
| LaserJock | pwnguin: I wonder how it would affect most apps | 05:31 |
| LaserJock | I can imagine things like tookits and DE libs would save a lot | 05:32 |
| LaserJock | but a great many probably don't save much of anything by dynamic libs | 05:32 |
| pwnguin | glibc | 05:32 |
| LaserJock | given | 05:33 |
| ScottK | persia: Thanks. | 05:33 |
| * nxvl *HUGS* persia and ScottK without a reason | 05:34 | |
| LaserJock | phew, 177 updates to install right out of the box | 06:18 |
| * persia cheers the SRU team for effective work in coordinating updates | 06:18 | |
| * LaserJock hopes MOTU SRU goes out of business ;-) | 06:19 | |
| persia | LaserJock: Why? | 06:19 |
| LaserJock | because that means we did it right *before* release | 06:19 |
| * ScottK cheers the MOTU SRU team for saying no so he could out of one with a clear conscience. | 06:19 | |
| LaserJock | time for bed | 06:20 |
| LaserJock | I'm off, have a good night/day | 06:20 |
| persia | LaserJock: I guess. Given the number of lines of code, I'm not sure that's possible, although some cases (FTBFS, cannot-install, etc.) are being improved as we develop better tools to see the problems. | 06:20 |
| LaserJock | it'd be nice if security was the only thing we had to really worry about post-release though | 06:21 |
| LaserJock | but yeah, it's only a dream ;-) | 06:21 |
| persia | We'd need a much larger universe-testing team. The number of possible interactions between the number of packages is fairly high. | 06:22 |
| ScottK | Speaking of testing ... https://wiki.ubuntu.com/MOTU/Clamav?action=show | 06:27 |
| warp10 | Hi all! | 06:29 |
| === \sh_away is now known as \sh | ||
| \sh | moins | 07:51 |
| \emgent | heya | 07:57 |
| \sh | moins \emgent | 07:58 |
| minghua | "Is this possible" is really a bad choice of Email subject... | 08:47 |
| persia | Yep. Spam-like. I wasn't sure of a better one though. | 08:49 |
| minghua | persia: "Possible for MOTU to only maintains a single package?", perhaps? | 08:54 |
| minghua | Verbosity seldom hurts, I would hope. | 08:55 |
| persia | minghua: Maybe, although that still doesn't parse. Perhaps "It is possible to become MOTU while only maintaining a single package?", but that seems overlong. | 08:55 |
| persia | Now if only I had thought of that half an hour ago :( | 08:55 |
| minghua | Anyway, if not for persia's reply, I probably would have just labeled it as spam without looking. | 08:56 |
| persia | Right. I'm now confident that ubuntu-bugs@ is used for spam harvesting. There is a direct correlation between any LP activity and the receipt of spam to the primary address listed in LP. | 08:56 |
| minghua | (Oh, and not having a full name doesn't help either.) | 08:57 |
| persia | minghua: There's been several REVU submissions from that email address, which is part of why I read it in the first place. | 08:57 |
| minghua | There have been two posts on planet complaining about the @ubuntu.com address attracting a large amount of spam, I think. | 08:57 |
| persia | I don't think it is the @ubuntu address, except insofar as many people list that as the primary address in LP. | 08:58 |
| persia | I think rather that one of the subscribers to ubuntu-bugs@ is reading headers, and passing them to somewhere. My reasoning is that I don't get much spam to the primary address during REVU day, but always get 30-40 messages when doing bug triage or sponsoring (regardless of time of day or day of week, etc.). It feels like a realtime system. | 09:00 |
| minghua | persia: Well, for me, plenty of spam goes directly to the @u.c address. | 09:00 |
| TheMuso | RainCT: Sorry I haven't gotten to merge your changes yet. If they haven't been done, I'll take care of it now. | 09:00 |
| minghua | Sounds a quite clever spam system... | 09:00 |
| persia | minghua: Do you not see as much to sbcglobal? | 09:01 |
| sistpoty | morning everyone | 09:02 |
| minghua | persia: I don't really have a hard number, I delete them before downloading them through POP3. But the general impression is that ~90% spam are to the @u.c address. | 09:02 |
| RainCT | TheMuso: Do so, please :) | 09:02 |
| TheMuso | RainCT: Ok, whats the URL for your branch? | 09:02 |
| persia | minghua: Ah. The delete-before-download and use of POP3 perhaps makes it hard to check the timing and source relationship to LP activity. | 09:03 |
| minghua | persia: But then again, the mails I send to mailing lists has @u.c address in From: line too, so it's many factors. | 09:03 |
| RainCT | TheMuso: http://bazaar.launchpad.net/~rainct/ubuntu-dev-tools/dev | 09:03 |
| TheMuso | RainCT: Thanks. | 09:04 |
| sistpoty | library packaging session in #ubuntu-classroom now (repetition of the session from Thursday) | 09:04 |
| Elly | ê/win 10 | 09:05 |
| Elly | er, sorry | 09:05 |
| minghua | SBC (southwestern bell) doesn't support IMAP, so I don't really have many choices. | 09:06 |
| minghua | Although I am starting to realize that using the same email service as the DSL company is probably not the best idea... | 09:06 |
| persia | sistpoty: Thanks for the reminder | 09:07 |
| sistpoty | np | 09:07 |
| \sh | ok..let's check...wife is in berlin for two days, enough coffee powder in the cupboard...nicotine is also on board...let's have some ubuntu fun :) | 09:08 |
| \sh | ScottK, do you have a mail with a virus? | 09:12 |
| === Lure_ is now known as Lure | ||
| minghua | Huh. What is the point of this "Debian Users" LP team? | 09:33 |
| persia | More emblems :) | 09:37 |
| Hobbsee | more shiny! | 09:38 |
| \sh | more teams...for whatever reason ;) | 09:41 |
| TheMuso | RainCT: Your changes have been merged. | 09:55 |
| RainCT | TheMuso: thanks :) | 09:55 |
| LucidFox | Which package is responsible for KDE automounting? | 10:37 |
| === asac_ is now known as asac | ||
| sistpoty | geser: btw.: rocking work on the haskell transition front! Thanks a lot! | 12:11 |
| LucidFox | What would be the Ubuntu equivalent of the "grave" severity in Debian? | 12:17 |
| LucidFox | for bugs | 12:17 |
| sistpoty | LucidFox: Debian severities don't map to ubuntu, because debian severity refers to *one particular* package, while ubuntu's severity is the severity in the whole project | 12:21 |
| LucidFox | Ack. | 12:21 |
| geser | sistpoty: I'm preparing now the next batch of sync request for haskell packages | 12:22 |
| sistpoty | geser: excellent! | 12:23 |
| sistpoty | you rock! | 12:23 |
| geser | sistpoty: have you an idea how to fix the haskell-opengl FTBFS on i386? | 12:24 |
| sistpoty | geser: not at the moment... does it only FTBFS on i386 (I'm on amd64) | 12:25 |
| geser | yes, only on i386 | 12:25 |
| sistpoty | geser: darn... | 12:26 |
| geser | I'm on amd64 too, where it builds successfully (I've tested the build on amd64 before filing the sync request) | 12:27 |
| geser | sistpoty: haskell-{glut,openal,alut} depwait now on haskell-opengl on i386 | 12:27 |
| sistpoty | geser: I'll take a look (and maybe upgrade my old laptop to hardy today)... but my first work is to try to get ghc6 built on sparc and bootstrapped on hppa, lpia | 12:28 |
| sistpoty | geser: urgh... the haskell-opengl FTBFS that looks like a problem with ghc6's splitobjs thingy | 12:33 |
| sistpoty | geser: from debian bug: "I can compile haskell-opengl fine by removing --enable-split-objs from CONFIGURE_OPTS." | 12:36 |
| sistpoty | geser: I'll apply this fix and upload a new version (even if only tested on amd64 *g*) | 12:37 |
| geser | sistpoty: no i386 pbuilder? | 12:38 |
| sistpoty | geser: nope, and my i386 chroot is totally out of date | 12:38 |
| geser | is it only removing that option? | 12:41 |
| sistpoty | yes... (actually I've only removed i386 from the switch in debian/rules) | 12:42 |
| geser | ok, I'll build it in my i386 pbuilder and check if haskell-opengl builds then | 12:43 |
| sistpoty | geser: excellent, thanks. Do you upload it then as well? | 12:44 |
| \sh | hmm..does canonical has a rsync mirror of the archives? | 12:45 |
| geser | sistpoty: can do it | 12:46 |
| sistpoty | geser: thanks a lot | 12:46 |
| sistpoty | \sh: iirc there used to be one. If have a very vague memory that it was shut down though. | 12:47 |
| \sh | sistpoty, hmm...I wonder if using the http method gives me just the updated packages when I redo debmirror | 12:48 |
| the_belgain | apologies if i'm double-posting, but my connection to IRC just dropped and i don't know if the following made it... | 12:48 |
| sistpoty | \sh: no idea really... haven't used debmirror in a while | 12:48 |
| the_belgain | hi there - i'm having a little trouble with the <package>.install file for a pacakge i'm making | 12:48 |
| the_belgain | dh_install is failing because it can't find the directory i'm trying to get it to install. my <package>.install file looks like this: http://paste.ubuntu-nl.org/52573/ | 12:48 |
| the_belgain | and debian/rules runs the makefile's installer to install in debian/tmp | 12:48 |
| geser | sistpoty: what exactly must be changed in debian/control in ghc6? | 12:49 |
| sistpoty | the_belgain: either use --source-dir=debian/tmp for dh_install or add debian/tmp as prefix | 12:50 |
| the_belgain | thanks | 12:50 |
| sistpoty | geser: line 25, remove i386 there | 12:50 |
| sistpoty | (that *should* do the trick) | 12:51 |
| geser | sistpoty: line 25 is "configure: configure-stamp" here. | 12:52 |
| sistpoty | geser: we're talking about haskell-opengl, aren't we? | 12:53 |
| geser | sistpoty: ah, so only haskell-opengl needs to be changed? | 12:54 |
| sistpoty | geser: yes... though the bug *might* be in ghc6 | 12:54 |
| sistpoty | geser: but the only fix for ghc6 that I could produce right now would be to disable object splitting for i386 in general, and that would mean a rebuild of all libs again :( | 12:55 |
| === LucidFox is now known as Strong_Bad | ||
| === Strong_Bad is now known as LucidFox | ||
| \sh | persia, ping freqtweak | 13:25 |
| \sh | persia, you added yourself with the last new upstream version for ubuntu as original maintainer, should I leave it, or should I use the debian maintainer now? (which is qa group because of debian package maintainer orphaning it) | 13:28 |
| db-keen | A week or so ago, I asked about versioning 3rd party packages, people said NOT to use a '~'. However, backports.org and getdeb.net both use them. Was I misled? Should I use them too? | 13:31 |
| man-di | backports.org is not 3rd party | 13:32 |
| * Hobbsee wonders why not to use a ~ | 13:32 | |
| man-di | not really | 13:32 |
| Hobbsee | man-di: for ubuntu it is? | 13:32 |
| man-di | but I wonder about the reason | 13:32 |
| man-di | Hobbsee: you right, for Ubuntu. I wear my Debian hat too often | 13:32 |
| man-di | sorry | 13:33 |
| * man-di better shuts up | 13:33 | |
| Hobbsee | db-keen: 3.0~foo is less than 3.0, so you need to name carefully | 13:34 |
| db-keen | it's more of a 3.0-0~foo1 | 13:35 |
| db-keen | versus ubuntu might name it 3.0-0ubuntu1 | 13:35 |
| db-keen | versus Debian might name it 3.0-1 | 13:35 |
| db-keen | right? | 13:35 |
| Hobbsee | yeah | 13:35 |
| db-keen | so should I call it 3.0-0foo1 or 3.0-0~foo1 | 13:36 |
| emgent | jdstrand, ping for remember drupal fix sponsorization :P | 13:39 |
| \sh | emgent, it's on their eyesight :) patience :) | 13:40 |
| emgent | hehehe sure :P | 13:40 |
| jdstrand | emgent: did you see my comments from yesterday? | 13:50 |
| jdstrand | emgent: hi btw | 13:50 |
| emgent | hippu, no sorry :( | 13:50 |
| emgent | s/hippu/hi/ | 13:50 |
| jdstrand | I was thinking of adding them to the bug, but thought you might have irc logs | 13:51 |
| jdstrand | anyway... let me get them | 13:51 |
| emgent | jdstrand, i think screen deattached. | 13:51 |
| jdstrand | from beofre: | 13:51 |
| jdstrand | 14:46 < jdstrand> emgent: I was just reviewing your drupal update for SA-2007-031 | 13:52 |
| jdstrand | 14:47 < jdstrand> emgent: I see that the upstream patch listed on http://drupal.org/node/198162 is different than SA-2007-031-5.3.dpatch (I've only looked at gutsy so far) | 13:52 |
| jdstrand | 14:48 < jdstrand> was this the 'Upstream re-fix SA-2007-031 patch' as referenced in bug #181984 ? | 13:52 |
| ubotu | Launchpad bug 181984 in drupal5 "Drupal5: SA-2007-031, SA-2008-005,SA-2008-006: SQL injection and XSS " [Undecided,Confirmed] https://launchpad.net/bugs/181984 | 13:52 |
| jdstrand | 14:49 < jdstrand> emgent: if so, can you provide the link to the updated patch (the changelog still has http://drupal.org/node/198162) | 13:52 |
| \sh | jdstrand, yepp...Re: SA-2007-031 | 13:52 |
| \sh | jdstrand, patch in 5.4 for SA-2007-031 was broken and was fixed in 5.5 with the change in this very special line | 13:52 |
| emgent | \sh, ++ | 13:53 |
| \sh | jdstrand, http://drupal.org/files/issues/db_query_range.patch is the corrected fix for broken 5.4 SA-2007-031 patch | 13:53 |
| jdstrand | \sh is that referenced in the later patch urls? | 13:53 |
| \sh | jdstrand, discussion was on http://drupal.org/node/198321 and report about if officially is on http://www.drupal.org/drupal-5.5 :) | 13:54 |
| \sh | s/if/it/ | 13:54 |
| jdstrand | \sh, emgent ok thanks, I'll just add that in | 13:54 |
| emgent | ok cool jdstrand :P | 13:54 |
| jdstrand | (the references that is) | 13:54 |
| \sh | emgent, ok my fault..I should have told you to add all references to debian/changelog...because it's important for reviewing the fixes | 13:55 |
| jdstrand | emgent: and I had a comment on wordpress | 13:55 |
| jdstrand | 15:24 < jdstrand> emgent: regarding wordpress, the version and changelog entry does not conform to https://wiki.ubuntu.com/SecurityUpdateProcedures. Can you look at 'Preparing an update' at section '4' and '5' and resubmit your debdiff (please also give the url of the patch you used). thanks for your hard work! | 13:55 |
| emgent | jdstrand, ok | 13:56 |
| \sh | now where was I | 13:56 |
| jdstrand | emgent: fyi-- I will be travelling today and tomorrow and probably won't get to these until tomorrow night at the earliest | 13:56 |
| emgent | no problem :P | 13:57 |
| emgent | thanks jdstrand ! | 13:57 |
| jdstrand | emgent: absolutely! :) | 13:57 |
| \sh | jdstrand, it's weekend..you shouldn't work at all ;) | 13:57 |
| jdstrand | \sh: ;) | 13:58 |
| emgent | hahaha | 13:58 |
| \sh | jdstrand, go go go ... and drink one or two beer for us ;) | 13:58 |
| jdstrand | heheh | 13:58 |
| emgent | no beer, rum&&Cola ++ | 13:59 |
| jdstrand | if truth must be told, I actually like pink drinks | 13:59 |
| jdstrand | go figure *shrug* | 13:59 |
| emgent | ;) | 13:59 |
| ion_ | Turkish Pepper (the candy) + vodka = teh awesome | 13:59 |
| jdstrand | (strawberry margarita) | 13:59 |
| emgent | hehehe | 13:59 |
| ion_ | A.k.a. Salmiakkikoskenkorva in Finland. | 14:00 |
| * emgent like Cubalibre. | 14:00 | |
| \sh | jdstrand, hmm...I'm more the caipi type of guy...and then a lot of them;) | 14:01 |
| * sistpoty needs to go and buy beer | 14:03 | |
| \sh | sistpoty, kein bier vor vier ;) | 14:04 |
| sistpoty | hehe \sh | 14:04 |
| \sh | or was it the other way around... | 14:04 |
| ScottK | \sh: No, but I could send you a clamav test file. | 14:11 |
| \sh | ScottK, please :) | 14:13 |
| \sh | hmmm | 14:18 |
| \sh | can someone with sparc access check this http://launchpadlibrarian.net/11440832/buildlog_ubuntu-hardy-sparc.cyrus-imapd-2.2_2.2.13-13ubuntu1_FAILEDTOBUILD.txt.gz | 14:18 |
| Hobbsee | \sh: log into sparky. | 14:18 |
| \sh | hmm... | 14:19 |
| \sh | sparky.ubuntuwire.com? | 14:19 |
| Hobbsee | yes | 14:19 |
| Hobbsee | sparky.tauware.de and revu.tauware.de also resolve at the same place | 14:19 |
| Hobbsee | \sh: | 14:20 |
| Hobbsee | give me a yell if you don't have permissions to run pbuilder there | 14:20 |
| \sh | Hobbsee, looks like I don't have the permission (public key) | 14:20 |
| Hobbsee | ah | 14:20 |
| \sh | well public key is on LP and it works normally :) | 14:21 |
| \sh | ScottK, forget about the testfile...I see now it works :) | 14:22 |
| \sh | just catched 4 of those nasty mails ;) | 14:22 |
| Hobbsee | \sh: you changed keys did you? | 14:24 |
| \sh | Hobbsee, a couple of weeks yes | 14:24 |
| mok0 | ScottK: Starting to work on avscan now | 14:26 |
| Hobbsee | \sh: you should be able to log in now | 14:28 |
| \sh | Hobbsee, cool thx :) | 14:30 |
| Hobbsee | you're welcome | 14:30 |
| \sh | Hobbsee, pbuilder <- hardy? | 14:32 |
| Hobbsee | \sh: er, i think it uses pbuilder-dist from memory | 14:32 |
| \sh | well..pbuider-dist is not in there..and pbuilder-hardy also not | 14:33 |
| geser | does somebody know how to add input line editing for a python cli program? | 14:33 |
| mok0 | geser: you probably need to use the readline module | 14:34 |
| emgent | bye people | 14:35 |
| geser | mok0: I've read the online help for the readline module but it's not obvious for me how to use it | 14:37 |
| mok0 | Hmm, I've never used it either | 14:37 |
| ScottK | mok0: Great. | 14:39 |
| StevenK | I thought you just had to import it and it dealt? | 14:40 |
| ScottK | geser: http://docs.python.org/lib/module-readline.html | 14:42 |
| geser | ScottK: I've read that already (it's the same as the online help). | 14:43 |
| ScottK | Oh. | 14:43 |
| geser | it seems to be more about input history but not about input editing | 14:43 |
| geser | I want to add line editing support to requestsync when asking for the rationale to drop Ubuntu changes | 14:44 |
| StevenK | Ewww | 14:44 |
| geser | btw: I've added python-launchpad-bugs support to requestsync in bzr. requestsync --lp uses it to file the bug instead of mailing it. | 14:46 |
| geser | it works for me, but I would like if other people could also test it before ubuntu-dev-tools gets uploaded the next time. | 14:47 |
| ScottK | geser: Consulting my Python in a Nutshell, it seems the module is a wrapper for standard readline command, so it's hard to do much with it without also using the readline documentation. http://tiswww.case.edu/php/chet/readline/rltop.html | 14:48 |
| === bigon` is now known as bigon | ||
| \sh | what was the proposed way to change the complete system language including keyboard layout for the console? | 14:56 |
| bddebian | Heya gang | 14:57 |
| ScottK | \sh: On another topic, did you notice gnuchash FTBFS now? You upload built, but something changed underneath it since. | 14:57 |
| ScottK | heya bddebian | 14:57 |
| \sh | ScottK, yeah I read the bugreport... | 14:57 |
| bddebian | Hi ScottK | 14:57 |
| geser | heya bddebian | 14:57 |
| bddebian | Hi geser | 14:57 |
| \sh | ScottK, the reporter found out that is was one lib after Jan 13th | 14:58 |
| ScottK | Which? | 14:58 |
| \sh | libgconf2-dev january 14th <---------- BUILD FAILED with this dependency installed hardy version 2.21.1-0ubuntu1 | 14:59 |
| \sh | the complete bug doc: bug #184176 | 14:59 |
| ScottK | Thanks | 14:59 |
| ubotu | Launchpad bug 184176 in gnucash "[hardy]Gnucash fails to build with libgconf2-dev 2.21.1-0ubuntu1" [Medium,New] https://launchpad.net/bugs/184176 | 15:00 |
| geser | ScottK: looks like raw_input() does what I want (currently requestsync uses sys.stdin.readline()) | 15:02 |
| \sh | hmm now I'm fcked | 15:15 |
| \sh | something generates a nose-0.10.1-py2.4.egg which shouldn't be in the package tree after debuild -S | 15:16 |
| \sh | can I just clean it during clean target? | 15:17 |
| slavi1 | there is a problem with the new xserver-xorg-core package, mainly I get a 403 error trying to get it | 15:40 |
| geser | slavi1: the update is broken, so it got prevented from being installed | 15:40 |
| * Hobbsee notes that hte new one is also up, too | 15:42 | |
| slavi1 | ahh, ok | 15:43 |
| slavi1 | is it possible to tell apt to use another mounted system to perform operations on? | 15:43 |
| slavi1 | the way that arch linux pacman can | 15:43 |
| LucidFox | Is anyone going to upload yakuake-kde4 from REVU? It has gathered its 2 votes, it's not my package but I'm interested in it :) | 15:44 |
| * Hobbsee thought it did get uploaded, and was in new? | 15:45 | |
| mok0 | slavi1: I suppose you can write an alternative apt.conf file, and have apt-get use it via the -c switch | 15:46 |
| geser | slavi1: what do you want to achieve? | 15:47 |
| slavi1 | more like install ubuntu on a removable hard drive without booting off the livecd | 15:51 |
| geser | slavi1: simply chroot into the mounted system and call then apt-get | 15:54 |
| geser | slavi1: but you need to have there already at least a minimal installation | 15:55 |
| mok0 | slavi1: and how will you make a bootable system using apt-get? | 15:55 |
| slavi1 | geser: that's the reason why chroot won't work | 16:10 |
| slavi1 | mok0: by installing grub onto it | 16:10 |
| sistpoty | you can tell grub to install somewhere else, can't you? (iirc -R or -r) | 16:10 |
| sistpoty | he, no, that was lilo *g* | 16:11 |
| geser | slavi1: use debootstrap to install a base system there so you can chroot | 16:11 |
| \sh | sistpoty, grub-install --root-dir for telling grub to install grub imstages instead of root dir | 16:13 |
| slavi1 | sistpoty: it is possible with grub, just set different root and do "install" | 16:13 |
| geser | sistpoty: with the grub-shell it should be possible | 16:13 |
| slavi1 | I think | 16:13 |
| === bigon is now known as bigon` | ||
| \sh | ./grub-install --root-dir /mnt/foo/boot /dev/<your new boot device> | 16:15 |
| \sh | ./grub-install --root-dir=/mnt/foo/boot /dev/<your new boot device> <--- sorry that's the correct syntax.. | 16:15 |
| slavi1 | ty | 16:15 |
| slavi1 | but apt is a bigger issue | 16:16 |
| \sh | slavi1, hmm? | 16:16 |
| \sh | sudo chroot /<our chroot dir> | 16:16 |
| \sh | vi /etc/apt/sources.list -> change it | 16:16 |
| \sh | apt-get update && apt-get dist-upgrade doesn't work? | 16:16 |
| geser | \sh: he needs to install a base system with debootstrap there first | 16:17 |
| slavi1 | yes | 16:17 |
| \sh | geser, sure :) | 16:17 |
| slavi1 | so it is possible ... | 16:17 |
| sistpoty | debootstrap hardy /some/where doesn't work? | 16:18 |
| sistpoty | or maybe gutsy *g* | 16:18 |
| === Ubulette_ is now known as Ubulette | ||
| \sh | ScottK, I'm having the new upstream version of gnucash on my todo ... let's see if it's building | 16:22 |
| \sh | ScottK, well no | 16:25 |
| \sh | gncmod-gnome-search.c:92: error: old-style parameter declarations in prototyped function definition | 16:27 |
| mohammad | Hi, does anyone know whether swt3.3 (source package is eclipse 3.3) will be added to ubuntu hardy? | 16:39 |
| === bigon` is now known as bigon | ||
| === bigon is now known as bigon` | ||
| jdong | mohammad: depends on if anyone will work on packaging them. | 16:56 |
| jdong | mohammad: at the rate things are going now, I think there was a handful of volunteers looking into it, I haven't heard much for the past month, so unless more people pitch in, I'd guess no, it would not reach Hardy. | 16:57 |
| === _czessi is now known as Czessi | ||
| LucidFox | jdong> Marillat has merged some changes of mpeg4ip back into DMO | 17:04 |
| LucidFox | including your debian/copyright | 17:05 |
| jdong | LucidFox: cool, yeah, we e-mailed him about it :) | 17:16 |
| LucidFox | ah, didn't know | 17:17 |
| jdong | he's not interested in repacking the orig.tar.gz for the licensing issues though, so we won't be able to directly sync from him | 17:17 |
| jdong | (I don't blame him :D) | 17:17 |
| jdong | grr why doesn't cygwin support UTF-8? | 17:17 |
| crimsun | http://www.okisoft.co.jp/esc/utf8-cygwin/ | 17:19 |
| jdong | uname -a | 17:19 |
| jdong | oops | 17:19 |
| yamal | MOTUs, the new sabnzbd package is awaiting your expert review @ http://revu.tauware.de/details.py?package=sabnzbdplus | 17:23 |
| LucidFox | IANAMOTU, but: | 17:27 |
| LucidFox | is (Closes: LP #xxx) accepted by LP? I've _never_ seen anything but (LP: #xxx) | 17:27 |
| jdong | LucidFox: no, you shouldn't use Closes: LP | 17:27 |
| LucidFox | and I think debian/changelog is overly verbose, just "Initial release (LP: #xxx)" would be sufficient | 17:27 |
| jdong | LP: #xxxx is the best form | 17:28 |
| LucidFox | also, Ubuntu never had Python 2.3, so python-all-dev (>= 2.3.5-11) seems sort of pointless | 17:29 |
| xhaker | Hey, what if in an .install file i want to conditionaly install files depending on the distribution? | 17:29 |
| LucidFox | xhaker> What do you mean, depending on the distribution? | 17:29 |
| LucidFox | If that is the case, package separately for each distribution | 17:29 |
| xhaker | as in, we no longer support hotplug, debian does. i want it to build correctly for both | 17:30 |
| LucidFox | yamal> Consider using dh_install and debian/install instead of cp | 17:30 |
| LucidFox | by extension, it will make debian/dirs redundant | 17:30 |
| xhaker | LucidFox: what about adding the files needed in debian but not in ubuntu through rules? | 17:30 |
| \sh | what is different between debian and ubuntu then? | 17:31 |
| LucidFox | If Debian and Ubuntu need different handling, I think it's best to have two different packages: one for debian, the other for Ubuntu | 17:31 |
| * \sh needs food...asap | 17:32 | |
| yamal | LucidFox: tx | 17:32 |
| LucidFox | yamal> The debhelper build-dependency seems overly precise, is there a reason why you require this specific minimal version? | 17:33 |
| LucidFox | (for example, how dh_icons requires >= 5.0.51) | 17:34 |
| LucidFox | also, patches 03 and 04 are logically connected - their purpose is to make the program find files in /usr/share. Perhaps it would make sense to merge them? | 17:37 |
| LucidFox | There's a freenode team called "upstream"? o_O | 17:41 |
| yamal | LucidFox: might make sense to join those patches. | 17:41 |
| yamal | LucidFox: what do you mean with that last remakr | 17:41 |
| LucidFox | yamal> that's not directed to you :) | 17:42 |
| yamal | oh ok :) | 17:42 |
| LucidFox | For your package, that's all I see. MOTUs may catch more stuff. | 17:42 |
| yamal | it's a nice start, and luckily all quite fixable too ;) | 17:42 |
| === apachelogger_ is now known as apachelogger | ||
| jonnymind | Good evening. | 17:51 |
| xhaker | What if the new Debian version changed things a bit, and doing a merge, the remaining changes are the same but in differente places? can someone enlighten me | 17:52 |
| sistpoty | xhaker: if they have the same effect, sync it | 17:53 |
| xhaker | sistpoty: the remaining changes! :) Some stuff had to be changed in ubuntu to obtain the same effect from before. | 17:55 |
| xhaker | effect is the same.. diff is not | 17:56 |
| crimsun | it's still a merge if there are remaining changes. | 17:56 |
| sistpoty | xhaker: so you still need ubuntu changes? Then I'd say re-merge the remaining changes so that they work again ;) | 17:56 |
| sistpoty | on top of the debian package | 17:57 |
| sistpoty | (that's what I usually do... reapplying ubuntu changes on top of the new debian version) | 17:57 |
| xhaker | and what about the changelog.. should I say I dropped and readded accomodated to the new debian package, or should i just keep the usual remaining changes bit? | 17:58 |
| LucidFox | xhaker> There's no need to keep debian/changelog when doing a sync | 17:59 |
| LucidFox | when doing a merge, keep only entries since the last sync | 17:59 |
| geser | xhaker: just the usual remaining bits | 17:59 |
| ups | hi | 17:59 |
| LucidFox | ups> welcome :) | 18:00 |
| ups | thanks :) | 18:00 |
| === bigon` is now known as bigon | ||
| LucidFox | Heh, I just searched Google for "libtool sucks" and the second result is: 'Google doesn't show even nearly enough hits when you search for "libtool sucks".' | 18:00 |
| sistpoty | xhaker: you can drop them, but make sure to have every detail listed in the new changelog entry (e.g. bug numbers, from who's what patch etc.) | 18:00 |
| ups | i added debian/copyright and did an "svn diff" for the patch - will it take care of the new copyright file as well? | 18:01 |
| LucidFox | ups> What do you mean? | 18:01 |
| LucidFox | What are you trying to do? | 18:01 |
| ups | LucidFox: create a package from svn source - i took care of the build-depends and warnings etc given by the packaging scripts | 18:03 |
| ups | one of the warnings were missing copyright file | 18:03 |
| ups | so i put it there | 18:03 |
| ryanakca | is there a reason why bzr is still at 1.0 in hardy? (1.1.0 came out in early november iirc) | 18:03 |
| ups | now i'm trying to create a patch to send to the upstream developer, using "svn diff" | 18:03 |
| LucidFox | Why would upstream be interested in debian/copyright? | 18:04 |
| ups | but i don't see any mention of the copyright file in the diff | 18:04 |
| xhaker | thanks for the help folks.. will pursue to comply :) | 18:04 |
| LucidFox | Upstreams shouldn't generally include the debian directory, that's the packager's job | 18:04 |
| jonnymind | ScottK: I uploaded another Falconpl package yesterday. I'd like to be sure it's ok, so it can pass next REVU day... | 18:04 |
| ups | well it is already there | 18:04 |
| LucidFox | ups> WHAT?! | 18:05 |
| LucidFox | Ask upstream to remove it. | 18:05 |
| sistpoty | ryanakca: maybe bzr-tools? | 18:05 |
| \sh | hmmm...am I blind or liboglappth is not existing in ubuntu? | 18:05 |
| ups | LucidFox: why? it will be useful for anyone who wants to build a deb from source himself, don't you think? | 18:05 |
| sistpoty | ups: did you checkout an upstream project or from debian/ubuntu somewhere? (what apt-get source hints you in case there is a Vcs-* thingy in debian/control) | 18:06 |
| ryanakca | sistpoty: eh? its at 1.0.0 too... is it because there isn't a 1.1.0 version of it yet? | 18:06 |
| ups | LucidFox: since the control file is already there | 18:06 |
| === bigon is now known as bigon` | ||
| sistpoty | ryanakca: yes, that's my guess that both should be uploaded at the same time... but I have no idea about bzr-tools (or if there is a new version yet) | 18:07 |
| LucidFox | ups> Oh no, not the same argumentation again | 18:07 |
| LucidFox | I'm tired of avidemux advocating that | 18:07 |
| ups | LucidFox: hmm... not aware if this is a debated topic - i'll be happy to read if you have any pointers ;) | 18:07 |
| LucidFox | If upstream wants to distribute a debian directory, it must be at least renamed. | 18:08 |
| LucidFox | Like smplayer does. | 18:08 |
| crimsun | \sh: it has yet to be synced in. | 18:08 |
| LucidFox | If they want everyone to be able to build their own debs, that's fine, but it shouldn't interfere with distribution packaging. | 18:08 |
| \sh | crimsun, yeah...there is no bug open for it I guess | 18:08 |
| LucidFox | so, ups, please ask upstream to move the debian directory out of the way. Like, rename to debian-upstream. | 18:08 |
| ryanakca | sistpoty: ok. I'll check in #bzr ... if there is a bzrtools thats available at 1.1.0, I'll update debian's 1.1~rc1-1 to 1.1.0-1 ... and I'm guessing it wouldn't be too late to sync/merge into Ubuntu? | 18:09 |
| ups | LucidFox: thanks, i'll see what can be done | 18:10 |
| sistpoty | ryanakca: no, it's not yet too late, there is still some time until FeatureFreeze | 18:11 |
| ryanakca | sistpoty: ok, thanks. *gets to it* | 18:11 |
| sistpoty | ryanakca: but please make sure that bzr-buildpackage still works... I guess otherwise a lot of people would be unhappy ;) | 18:11 |
| * LucidFox never even used [vcs]-buildpackage... | 18:12 | |
| ryanakca | sistpoty: hehe... I've never used it... so I guess I'll pass it by someone who does use -buildpackage to test it | 18:12 |
| sistpoty | ryanakca: that seems prudent :) | 18:12 |
| LucidFox | By the way, may I assume that NEW is going to stay untouched until Monday? :) | 18:13 |
| sistpoty | LucidFox: that's a smart guess ;) | 18:15 |
| LucidFox | heh, I see | 18:15 |
| LucidFox | so libmp4v2 builds are still going to stay broken for a while | 18:15 |
| zul | afternoon | 18:17 |
| geser | Hi zul | 18:17 |
| zul | hey geser | 18:17 |
| \sh | hmmm what was the url again for viewing the new queue? | 18:18 |
| geser | \sh: https://edge.launchpad.net/ubuntu/hardy/+queue | 18:19 |
| \sh | geser, thx | 18:19 |
| \sh | well...filing a bug against liboglappth | 18:20 |
| \sh | TheMuso_, ping gnubiff...do you know exactly why debian upstream maintainer doesn't want to change from fam to gamin? | 18:25 |
| \sh | oh ... infinity did the change in the first place | 18:27 |
| \sh | crimsun, bug #184389 | 18:39 |
| ubotu | Launchpad bug 184389 in ubuntu "Sync liboglappth from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/184389 | 18:39 |
| ryanakca | sistpoty: hmmm... bzrtools is already at 1.1-1 in Debian... | 18:39 |
| crimsun | ryanakca: just ask for a sync | 18:40 |
| ryanakca | and it looks like hardy's bzr-builddeb is 0.92 while bzr is 1.0 ... so I'm guessing backward / forward / whatever compatibility or somewhing | 18:41 |
| ryanakca | crimsun: *nods* ... I'm updating Debian's bzr from 1.1~rc1-1 to 1.1-1... dunno if they'll take it though, but if they do, I guess I'll sync it too? | 18:42 |
| sistpoty | ryanakca: try it out and if nothing breaks, ask for sync... (I assume you've also asked at bzr what they think is the best, do you?) | 18:42 |
| ryanakca | sistpoty: I have. haven't received an answer yet, but if its a go, it'll just be a matter of submitting it to debian... | 18:43 |
| sistpoty | does anyone mind me breaking revu? I'd like to get non-motu comments finally enabled :) | 18:44 |
| crimsun | sistpoty: I don't mind. | 18:45 |
| sistpoty | hey crimsun btw :) | 18:45 |
| * ryanakca doesn't... but since I'm not an active user, my vote doesn't count for much... | 18:45 | |
| zul | sistpoty: noooo....:) | 18:48 |
| sistpoty | heh | 18:48 |
| sistpoty | zul: no about non-motu comments or about breaking revu :P | 18:48 |
| zul | sistpoty: heh | 18:48 |
| sistpoty | btw.: how can I do a diff between two bzr branches? (want to see how much revu-production is diverged from trunk) | 18:50 |
| sistpoty | urgh... revu-production is so wrong according to bzr st | 18:52 |
| asabil | hi all | 18:52 |
| crimsun | 'lo sistpoty, zul | 18:52 |
| geser | sistpoty: bzr help diff suggest that "bzr diff one_branch other_branch" might work | 18:52 |
| sistpoty | geser: I assume that then bzr st should be clean in revu-production? (trying nevertheless) | 18:53 |
| bddebian | Hmm, what replaces libglade-gnome0-dev for gnome2? | 18:54 |
| asabil | I would like to contribute a package, how do I do so ? | 18:54 |
| geser | !revu > asabil | 18:55 |
| geser | bddebian: are you porting from gnome1 to gnome2? | 18:56 |
| asabil | and am I allowed to upload to Revu ? | 18:56 |
| bddebian | geser: Trying to yes | 18:56 |
| zul | hey crimsun how is it going? | 18:56 |
| sistpoty | thanks geser, output looks sensible | 18:56 |
| bddebian | geser: Well actually the new upstream is supposed to be gnome2, I'm just trying to fix the build-deps :) | 18:57 |
| geser | bddebian: check which header is missing and search then the package for it | 18:57 |
| crimsun | zul: not bad, you? And the kid? | 18:58 |
| geser | asabil: everybody from the ubuntu-universe-contributors team is allowed to upload to revu and that team is open for everyone | 18:58 |
| zul | crimsun: everyone is doing good, now that im working again | 18:58 |
| crimsun | zul: belated congrats! | 18:58 |
| zul | crimsun: thanks.. | 18:58 |
| \sh | bddebian, just try libglade2-dev ? | 18:59 |
| sistpoty | emgent: you told me you fixed a security bug in revu? do you still have the patch? (looking at the diff right now, and not yet understanding everything) | 18:59 |
| sistpoty | i.e. diff between production and trunk, which is *erm* big | 19:00 |
| \sh | desktop-file-validate is a nice tool ,-) | 19:03 |
| sistpoty | emgent: nevermind, found out the changes, thanks! | 19:03 |
| === Skiessl is now known as Skiessi | ||
| CyberMatt | test | 19:11 |
| bddebian | OK, what is an XML perl parser for intltool? | 19:12 |
| bddebian | Hello CyberMatt | 19:12 |
| CyberMatt | sorry my lag was way up for asec | 19:12 |
| CyberMatt | hello though | 19:13 |
| nenolod | DktrKranz, yo | 19:15 |
| DktrKranz | nenolod, hey :) | 19:16 |
| nenolod | DktrKranz, debian has been "working" on getting zsnes on amd64 for some time, but it's not really possible because debian does not do multilib, but instead does an emulation chroot | 19:16 |
| nenolod | or at least, that's my understanding of things | 19:17 |
| === _stefan_ is now known as sistpoty | ||
| DktrKranz | nenolod, unluckily I haven't any amd64 box to test if your fix works, though :( | 19:18 |
| nenolod | DktrKranz, it works | 19:18 |
| nenolod | DktrKranz, my concern is "does it work on x86 still" | 19:18 |
| nenolod | which it "should", but i don't have any x86 pbuilder set up at the moment ;) | 19:19 |
| DktrKranz | nenolod, for x86, I can test it. Since I don't use zsnes, is there any tests to be done? | 19:19 |
| nenolod | DktrKranz, just see if it starts up :) | 19:20 |
| nenolod | DktrKranz, if it starts, then it's ok | 19:20 |
| DktrKranz | ok, thanks for the pointer. I'll start a test build now | 19:20 |
| \sh | guys, if anyone has a quad core desktop for me, please mail it to me ,) | 19:21 |
| DktrKranz | \sh, I don't even know what a quad core is, my hardware is so old it will ask for retirement soon, I guess :) | 19:22 |
| \sh | DktrKranz, amd opteron 2x dual core ,-) | 19:23 |
| \sh | bddebian, xml perl parser for intltool? | 19:23 |
| DktrKranz | what about amd 900? :) | 19:24 |
| bddebian | \sh: I got it, thanks | 19:24 |
| \sh | bddebian, intltool depends on libxml-parser-perl ;-) | 19:24 |
| bddebian | Yeah | 19:24 |
| \sh | DktrKranz, well, this is far below my desktops what I have here | 19:24 |
| \sh | I wonder if I can use a ccache between an emt64 and x86 compiling 64bit code | 19:25 |
| DktrKranz | \sh, this is my main desktop, I've some p133 toys around, maybe with some clustering... | 19:25 |
| DktrKranz | nenolod, FYI, test build will be available here: http://packages.linuxdc.it/hardy/result/zsnes_1.510-2ubuntu1/ | 19:27 |
| * nenolod has a bunch of AMD equipment. | 19:34 | |
| * \sh has a high load.... | 19:35 | |
| \sh | w | 19:36 |
| \sh | 20:35:37 up 2 days, 7:08, 7 users, load average: 8,68, 6,51, 4,78 | 19:36 |
| Nafallo | that's not high :-) | 19:36 |
| \sh | Nafallo, for a P4 emt64 3.0GHz Desktop it is ;) | 19:36 |
| \sh | but most probpably it's io load | 19:36 |
| Nafallo | top would tell | 19:37 |
| Nafallo | iostat as well ;-) | 19:37 |
| \sh | Nafallo, io load... | 19:38 |
| \sh | Nafallo, less ram == more swap | 19:39 |
| Nafallo | :-) | 19:39 |
| \sh | well, starting up my p4 i386 :) | 19:41 |
| DktrKranz | \sh, play with swappiness a bit, then | 19:41 |
| \sh | DktrKranz, na I'm sharing the builds between two workstations now :) | 19:42 |
| nenolod | virtualbox-ose needs a nochange rebuild | 19:42 |
| DktrKranz | \o/ to clusters | 19:42 |
| \sh | two merges on the emt64 box, the next two on the second computer...and when I have time, I'm starting up again my laptop to buildd two more packages | 19:43 |
| \sh | actually I could setup one of the two 1U servers with dual PIII 1Ghz power :) | 19:44 |
| \sh | well it's noisy but who cares ;) | 19:44 |
| geser | \sh: grid pbuilder? | 19:44 |
| DktrKranz | some who thinks noise is irritating | 19:44 |
| DktrKranz | some neighbours, for instance | 19:45 |
| \sh | DktrKranz, na not so noisy :) | 19:45 |
| DktrKranz | heh | 19:45 |
| \sh | geser, is it working ? ,-) | 19:46 |
| * DktrKranz is playing with qemubuilder, but with weak results | 19:46 | |
| \sh | geser, will you go to FOSDEM this year? | 19:50 |
| geser | \sh: I plan but I don't know yet, as I've 4 exams in the week after FOSDEM | 19:51 |
| geser | it depends how good my learning goes | 19:52 |
| \sh | geser, well exams are more important then fosdem :) I hope I could make it...My wife could visit her sister in belgium and I would travel to bruxelles | 19:53 |
| sistpoty | wohoo, contributor comments activated, and I didn't break revu once doing that :) | 20:01 |
| asabil | hi all | 20:01 |
| asabil | how do I change a filename using *.install files | 20:01 |
| \sh | sistpoty, grats :) | 20:01 |
| sistpoty | thanks \sh :) | 20:02 |
| asabil | I am making a package contains a small file extention bug | 20:02 |
| sistpoty | asabil: not too sure if that's possible at all... did you look at the manpage of dh_install yet? | 20:02 |
| asabil | sistpoty: the man page says it is not possible | 20:03 |
| asabil | any workaround ? | 20:03 |
| sistpoty | asabil: mv in debian/rules before calling dh_install? | 20:03 |
| asabil | sistpoty: I am using cdbs | 20:04 |
| sistpoty | asabil: then you're doomed :P... (consider not using cdbs or ask someone who knows cdbs better than I do) | 20:04 |
| asabil | oki | 20:04 |
| \sh | damn...now I know why I got doomed | 20:09 |
| \sh | I switched off trackerd completly from session administration in gnome... | 20:09 |
| \sh | but it comes back all the time | 20:09 |
| sistpoty | trackerd is the indexing thingy, right? | 20:10 |
| \sh | yepp | 20:10 |
| * sistpoty hopes that kde won't add such a thing by default | 20:10 | |
| \sh | sistpoty, it will :) | 20:10 |
| \sh | desktop search is a hype | 20:11 |
| sistpoty | damn, I'm doomed as well *g* | 20:11 |
| sistpoty | at least I have atm. not got that update notifier thingy (whatever its called in kde) installed and don't have regressions yet (at least none that I think come from there) | 20:12 |
| \sh | sistpoty, you mean this adept nightmare? | 20:12 |
| sistpoty | \sh: no, rather that "I've got new updates for you... click here. I'll remind you on every new login again" *g* | 20:13 |
| sistpoty | btw.: I've got somehow icons for the contents of my root directory on my desktop... is this a known bug? | 20:13 |
| sistpoty | (they just landed there instead of my desktop dir, didn't find out even what to change for this *g*) | 20:14 |
| ScottK | sistpoty: KDE has Strigii for thrashing your hard drive, but it's better bavhed than tracker. | 20:14 |
| sistpoty | ScottK: ah thanks. | 20:14 |
| sistpoty | ScottK: hah, not installed :) | 20:15 |
| somerville32 | Is there a motu-security ml? | 20:23 |
| somerville32 | (ie. security announcements for universe packages) | 20:24 |
| jpatrick | somerville32: I didn't know universe packages got security updates | 20:24 |
| somerville32 | jpatrick, Of course they do | 20:24 |
| somerville32 | jpatrick, Just not from Canonical | 20:25 |
| jpatrick | ah | 20:25 |
| somerville32 | :) | 20:25 |
| sistpoty | somerville32: none that I'm aware of | 20:27 |
| somerville32 | I'm thinking that maybe we should get them sent to ubuntu-security-announce | 20:28 |
| somerville32 | Should also be on the Ubuntu website | 20:28 |
| persia | \sh: The current state of freqtweak is the result of an ITA race for which neither competitor currently feels like doing anything. The latest Debian upload was a merge of Ubuntu patches, but the Debian tarball is still constructed in an ugly manner (and the code is the same). If you're merging, I'd recommend either grabbing a new SVN snapshot, or using the Ubuntu tarball. On the other hand, I'm not convinced there is a benefit other than to re | 20:52 |
| \sh | persia, ok...so do you still want to be mentioned in the XSBC-Orig-Maintainer? | 20:54 |
| persia | \sh: Not really. I vaguely feel I ought to file an ITA and update Debian, but until I am motivated to do that again, I probably shouldn't be the O-M. | 20:56 |
| \sh | persia, ok... | 20:57 |
| persia | Debian has a better copyright, but their icon varies from upstream for no adequately explained reason. Debian README.Debian is really not an ideal way to pull from upstream: please use Ubuntu get-orig-source (with dates adjusted). A new snapshot won't mean anything, as upstream hasn't gotten around to committing the local branch to SVN in the last couple years. | 20:57 |
| persia | \sh: Just out of curiosity, what prompts you to try this merge? Given that two different people completely rewrote the packaging (in a similar way) from the last common copy, I don't imagine it will be fun (although a good test of merging skills) | 21:03 |
| ScottK | sistpoty: Thanks for your work on REVU. | 21:03 |
| sistpoty | ScottK: you're welcome... I had these patches lying around for ages actually, but didn't come to comitting them to production :( | 21:03 |
| \sh | persia, just to clean the merge list | 21:04 |
| sistpoty | ScottK: and of course any beautification of the motu icon is more than welcome (/me sucks at html) | 21:04 |
| === bddebian2 is now known as bddebian | ||
| ScottK | Probably not as bad as I do. | 21:04 |
| sistpoty | heh | 21:04 |
| \sh | persia, as you can see on changes and ubuntu-archive sync reports I'm trying to clean the list...everything which is not as clear as it should, I'm asking the last uploader | 21:05 |
| persia | \sh: OK. Just checking :) Feel free to ask me if you have any questions, and feel free to skip if you have any problems (as the only new patch in Debian is the menu structure change). | 21:05 |
| \sh | persia, na .. I was just confused because of the QA upload and your last setting of Original-Maintainer :) | 21:06 |
| persia | \sh: Some history: | 21:06 |
| \sh | persia, gnucash and gfpoken are giving me more pain :) | 21:06 |
| persia | Upstream is mostly dead, and the last released version FTBFS. The package was orphaned. I repackaged, and forwarded to a sponsor. Bart repackaged during sponsor review, and uploaded a version that didn't include the patches. As upstream is dead, the package was again orphaned, after applying the patches I submitted upstream. | 21:08 |
| \sh | persia, bah | 21:09 |
| persia | \sh: I don't know much about either gnucash or gfpoken. Sorry. | 21:09 |
| \sh | persia, gnucash is broken because of something new in the last gnome upload... | 21:29 |
| \sh | persia, and gfpoken needs a imlib2 source change | 21:29 |
| persia | \sh: Really? I thought gnucash was still gtk1 | 21:30 |
| ScottK2 | StevenK: Ondrej (who has been upating python-numpy and python-scipy in Debian) mentioned to me that he thinks he's done updating the packages for a bit and this might be a good time for an update in Ubuntu. | 21:30 |
| ScottK2 | persia: No. The updated it. | 21:30 |
| persia | \o/ | 21:30 |
| ScottK2 | persia: It was done the last time gtk was threatened to be removed from Debian. | 21:30 |
| persia | I'm looking forward to xmms removal :) | 21:30 |
| persia | \sh: Thanks for becoming TIL for gaphor :) Have fun! | 21:31 |
| \sh | persia, TIL? | 21:31 |
| \sh | persia, gnucash depends on gnome and gtk2 | 21:32 |
| persia | \sh: Touched-it-last (that being why I've been watching upstream since Dapper: I don't use the package, really understand the code, or understand python packaging) | 21:32 |
| \sh | persia, well, the fun part was the .egg directory after debuild -S | 21:34 |
| \sh | persia, and hopefully zope3 will switch to 2.5 soon...so we can be in sync with debian | 21:35 |
| persia | \sh: You shouldn't be getting that if ez-setup was disabled properly. Are you sure Cédric applied the don't-access-the-internet patch all the way? | 21:35 |
| * persia notes that pattern here, that changes in Debian already present in Ubuntu aren't always merged | 21:36 | |
| \sh | persia, #from ez_setup import use_setuptools | 21:38 |
| persia | \sh: Hmm. I wonder why clean was updating ,egg then. Anyway, fixed now :) | 21:38 |
| \sh | persia, but debian upstream has it still in its setup.py | 21:39 |
| \sh | persia, and it was nose*.egg | 21:40 |
| persia | \sh: uncommented? In that case, I think it's cleaner to tell the package not to try to talk to the cheeseshop, rather than deleting the results in clean:, as otherwise there's no guarantee of build repeatability on a system connected to the internet. | 21:40 |
| ScottK | That sounds reasonable to me. | 21:41 |
| \sh | persia, the merge I did has it commented in...the debian upstream still has no comment sign before this line | 21:41 |
| persia | \sh: That's what I thought. If you've commented it out (and also the call to use_setuptools), I don't understand how you would be downloading nose.egg. Maybe python-nose needs to be Build-Depends: rather than Build-Depends-Indep: to avoid this. | 21:42 |
| \sh | persia, I check...give me a sec | 21:43 |
| \sh | persia, ok...found the bugger | 21:50 |
| \sh | persia, first mom was totally wrong, regarding setup.py ... from ez_setup import use_setuptools is now commented out | 21:51 |
| \sh | persia, debian/control: move python-nose from b-d-i to b-d helps | 21:51 |
| persia | \sh: Thanks for tracking that down. I'm really happy not to have another changelog entry in that package :) (also, this is part of why I don't use MoM: I hope you're not trying MoM for freqtweak) | 21:51 |
| \sh | persia, nope... | 21:52 |
| \sh | persia, normally I'm checking debian orig source and ubuntus old source but I have to admit, I should do it all the time :) | 21:53 |
| sistpoty | heh, MoM is like CDBS... you'll never know what you get and how it was assembled *g* | 21:53 |
| sistpoty | (at least for me, haven't mastered both yet) | 21:54 |
| persia | Well, you can look at the source for both in an attempt to discover this. | 21:54 |
| jpatrick | sistpoty: you can always look at the source | 21:54 |
| sistpoty | persia, jpatrick: sometimes the source doesn't give too much insight ;) | 21:55 |
| persia | \sh: I'll warn you that things I touch (especially things I touch post FeatureFreeze) tend to be adaptations of patches upstream or in Debian (admittedly, sometimes before they are adopted upstream or in Debian), and a such, are very likely to confuse MoM. | 21:55 |
| persia | sistpoty: I've not tried with MoM, but I've yet to find a CDBS confusion that wasn't resolved by looking at the make include files. | 21:56 |
| sistpoty | I guess I just like it simple :) | 21:57 |
| \sh | persia, I'm telling you, with b-d: python your patch works | 21:58 |
| \sh | persia, with py2.4 it gives all the way this .egg dir | 21:58 |
| persia | \sh: Umm. You have to build with python2.4 or setuputils replaces the #! lines, and you lose zope3 compatibility | 21:59 |
| \sh | persia, I know... | 21:59 |
| * \sh needs a smoke first...this is really...well..strange | 21:59 | |
| \sh | grmpf | 22:02 |
| \sh | well yeah | 22:03 |
| \sh | if python-nose on the build-host is not pre-installed, it gives the .egg directory | 22:03 |
| persia | Which should be handled by build-depends, no? | 22:03 |
| \sh | build-host == where you start debuild -S | 22:03 |
| \sh | nope | 22:04 |
| \sh | build-depends will be pulled in during pbuilder build... | 22:04 |
| persia | \sh: Build-Depends: , not Build-Depends-Indep: There is no guarantee that debian/rules clean: works properly without Build-Depends: installed. | 22:04 |
| \sh | but debuild -S calls make -f debian/rules clean and then you need for setup.py python-nose and python-setuptools | 22:04 |
| persia | (this is why debhelper is Build-Depends: even for arch-all packages) | 22:04 |
| \sh | well, I should use dpkg-source and dpkg-genchanges not debuild | 22:06 |
| persia | If you don't want to install the Build-Depends, yes :) | 22:07 |
| \sh | or pdebuild | 22:07 |
| \sh | gnarf... | 22:07 |
| persia | \sh: On the other hand, the package should be patched harder to never download nose from cheeseshop: you should get an error, rather than a populated .egg directory. | 22:08 |
| persia | (and please pass the patch to Cédric, who has to make a binary package every time, and doesn't find these things easily) | 22:08 |
| \sh | persia, well, he applied your patch correctly...I was the one who was fooled by MoM ... that's it | 22:09 |
| \sh | and using debuild is bad....noted....please bang my head 10 times on the desk and put me in the corner for stupid pupils..kthx ;) | 22:10 |
| persia | \sh: I thought the patch was applied correctly, but I'm not enough of a python person to be sure the patch is sufficient in every case. Before my patch, it always downloaded from cheeseshop. Now it appears to only do so if python-nose is not available when running debian/rules clean, but that's only a partial solution. | 22:11 |
| \sh | persia, I wonder if there is something like Pre-Build-Dep | 22:11 |
| persia | \sh: Nope. | 22:12 |
| \sh | persia, the only thing what makes the download happen is python setup.py clean | 22:13 |
| \sh | we can avoid it when removing this call and doing the cleanup manually | 22:13 |
| persia | \sh: That's not the right solution. The right solution is to adjust setup.py to not try to get stuff from the cheeseshop. My first attempt was to comment out the use_setuptools line. This is apparently not always sufficient. | 22:14 |
| POX_ | persia: let me guess: ez_install? | 22:14 |
| soren | \sh: What would pre-build-dep do? | 22:15 |
| ScottK | I was waiting for you to show up ... | 22:15 |
| ScottK | POX_: ^^ | 22:15 |
| POX_ | persia: do you have "from ez_setup import use_setuptools" in setup.py? | 22:15 |
| POX_ | if yes, remove it | 22:15 |
| persia | POX_: Yep. First attempt is the second patch listed at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461157, but this apparently still downloads if python-nose isn't installed when running debian/rules clean | 22:15 |
| ubotu | Debian bug 461157 in gaphor "gaphor: FTBFS in sbuild" [Serious,Fixed] | 22:15 |
| persia | POX_: That was commented out, but it still does it :( Also, \sh is taking over gaphor :) | 22:16 |
| \sh | soren, telling the maintainer to install this dependency first, because the maintainer needs it to call debian/rules clean e.g. | 22:16 |
| POX_ | do you call setup.py clean before or after patching? | 22:17 |
| POX_ | and why before? :) | 22:17 |
| soren | \sh: And this is different from Build-Depends how? | 22:17 |
| persia | POX_: No patch target. Patch is inline | 22:17 |
| POX_ | ok, where are up to date sources? | 22:18 |
| persia | soren: For arch:any packages, Build-Depends also contains things not required to run debian/rules clean | 22:18 |
| \sh | soren, well, everything is ok, when your debuild -S complains about a missing build-dep, e.g. when cdbs is missing it complains...but now it just goes over this, and downloads something | 22:18 |
| persia | POX_: http://ftp.debian.org/debian/pool/main/g/gaphor/gaphor_0.12.5-1.dsc should exhibit the issue | 22:18 |
| persia | \sh: Do you have a better link for POX_ for the ez_setup issue? | 22:19 |
| \sh | persia, nope...just download the package and apt-get remove python-nose (if you have it installed) | 22:19 |
| soren | persia: And how does *pre*-b-d change this? | 22:20 |
| persia | soren: pre-b-d would be the list of things for debian/rules clean. b-d would be the list of things when building arch:any, and b-d-i would be the list of things for building arch:all. Note that I don't see the point of pre-d-b, but am only explaining how it could be used. | 22:22 |
| \sh | soren, let's state a Pre-Build-Dep as PreReq in a rpm.spec...your build-system-host needs it before it can start with anything" it tells you "listen, before you can work with my rules file or with my build instruction in my .spec, you need to install this...when you did, I can go on with my usual work and clean your code" (just as an example)... like an user extension to a minimal installed packagelist for building packages | 22:22 |
| * persia notes that the very concept of pre-d-b is Ubuntu-only, as it only has meaning when one is building source packages and not when building binary packages. | 22:23 | |
| \sh | especially for packages who are calling ./configure before they can execute make clean | 22:23 |
| \sh | persia, well, rpm based distros are building source packages and binary packages from the very same .tar.gz/.patch/.spec directory ;) | 22:24 |
| soren | Erm... B-d's need to be fulfilled before you can be sure your can even execute debian/rules properly. | 22:24 |
| persia | soren: in most cases, build-essential handles that | 22:24 |
| soren | You need debhelper to be installed, for instance, before most debian/rules will do anything at all without breaking all over the place. | 22:24 |
| soren | persia: No. | 22:25 |
| \sh | soren, yes...this is not the question...this belongs to your package building tools... | 22:25 |
| persia | \sh: pre-d-b would only mean anything for .dsc based distros. RPM doesn't matter. | 22:25 |
| persia | soren: Ah right. Thanks. You've pushed me to take an opinion :) | 22:25 |
| \sh | persia, redhat and suse are working with such a system | 22:25 |
| soren | \sh: debhelper is not a required component when building a debian package. | 22:25 |
| persia | \sh: pre-d-b is bad because it requires far too much variance from Debian, for no extra benefit except to protect lazy packagers. | 22:26 |
| soren | And it doesn't make sense anyway. | 22:26 |
| persia | \sh: Neither Fedora nor OpenSUSE pay any attention to debian/control. | 22:26 |
| soren | Give me an example of something that should be p-d-b and not b-d(-i, perhaps). | 22:26 |
| persia | soren: debhelper would be a common example. python-nose would be the example \sh wanted to work around the ez-setup annoyance. | 22:27 |
| \sh | soren, I think the bug here was: debuild -S behaves differently from dpkg-buildpackage... | 22:27 |
| \sh | dpkg-buildpackage complains directly about the missing b-ds | 22:28 |
| soren | persia: Ah, you want to move things from b-d to p-d-b? Not copy them to it? | 22:28 |
| persia | \sh: Even with -S? | 22:28 |
| persia | soren: That would seem right to me, if I hadn't come to the opinion that it was a waste of time. | 22:29 |
| soren | persia: Heh :) | 22:29 |
| soren | The point is, you can expect a call to debian/rules (even to clean) to work properly if your b-d's aren't fulfilled. | 22:29 |
| persia | Or to put that another way, that would make sense to me if Debian were to migrate to source-only uploads. | 22:29 |
| persia | soren: Right. Another way to handle it would be to have b-d-arch: to handle things that aren't required to build a source package. | 22:30 |
| \sh | persia, nope...the -S is the problem in general | 22:30 |
| persia | \sh: OK. Just making sure that there wasn't a behavioural difference between debuild and dpkg-buildpackage. | 22:31 |
| \sh | persia, reading the manpage of dpkg-buildpackage again and again, -S should just build the source package...nothing else.. | 22:32 |
| persia | \sh: Running clean is considered part of building a source package. | 22:32 |
| soren | From Debian Policy: "The Build-Depends and Build-Conflicts fields must be satisfied when any of the following targets is invoked: build, clean, binary, binary-arch, build-arch, build-indep and binary-indep. " | 22:32 |
| soren | There you have it. Grey on green. | 22:33 |
| ScottK2 | Are the brackets in "mv debian/libspf-doc/usr/share/doc/libspf-doc/{html,api}" a bashism? | 22:33 |
| persia | soren: Right. Note 1) policy follows practice, and 2) Debian doesn't use sourceful uploads, so the condition under discussion should never occur | 22:33 |
| persia | ScottK: Yes. | 22:33 |
| \sh | persia, yeah...but then it should complain about not fullfilled b-ds | 22:33 |
| ScottK2 | persia: Thanks. | 22:34 |
| soren | persia: Er.. Yes, they do. | 22:34 |
| ScottK2 | That'd explain why the package won't build now. | 22:34 |
| soren | persia: They just don't do source-only uploads. | 22:34 |
| soren | \sh: What should complain? | 22:34 |
| persia | soren: Maybe terminology. Perhaps "Debian doesn't use source-only uploads"? | 22:34 |
| soren | persia: Much better :) | 22:34 |
| \sh | soren, dpkg-buildpackage -S | 22:35 |
| \sh | soren, dpkg-buildpackage -S is for building the source package, clean target needs to be called during this source package creation, so regarding your quoted policy, it should complain by default when a b-d is missing, right? | 22:35 |
| persia | \sh: I'd argue that due to the source-only nature of Ubuntu, that's not an Ubuntu bug, and that build-dep-arch is more correct (but not worth the trouble). It might be a Debian bug. | 22:36 |
| soren | I guess dpkg-buildpackage is high-level enough to do that. | 22:37 |
| soren | \sh: Write a patch :) | 22:37 |
| \sh | persia, I don't say at all that's bug in ubuntu or debian...it's just a logic bug in dpkg-buildpackage... | 22:38 |
| \sh | soren, hehe :) | 22:38 |
| === janito_ is now known as Lamego | ||
| \sh | persia, source package creation with dpkg-buildpackage -S should include the -D switch of the tool...to check the b-ds correctly before calling clean target...so the policy is correct at least ;) | 22:39 |
| * soren has an early start tomorrow morning and has to pack before the sprint on Monday | 22:40 | |
| soren | G'night, guys. | 22:40 |
| sistpoty | gn8 soren | 22:40 |
| persia | \sh: Sure. I'm just not sure if that part of policy is ideal for Ubuntu. I like the idea of Build-Depends-Arch:, but just don't see the point of carrying it as a variance. | 22:40 |
| persia | good night soren | 22:40 |
| sistpoty | \sh: imo dpkg-build-package is the wrong place... | 22:41 |
| sistpoty | dpkg-buildpackage is low enough to assume that anything is installed needed for building | 22:41 |
| sistpoty | so either pbuilder or sbuild would be to blame | 22:41 |
| \sh | sistpoty, nope... | 22:41 |
| sistpoty | \sh: dpkg-buildpackage doesn't know anything about what you've got installed in your system, and imo that's correct for *this* tool | 22:42 |
| persia | sistpoty: No. 1) This is source packages only, so neither pbuilder or sbuild has been involved yet, and 2) dpkg-buildpackage does complain for other required targets. | 22:42 |
| sistpoty | persia: it does? | 22:42 |
| \sh | sistpoty, dpkg-buildpackage -D checks the b-ds from debian/control if those are on your build host | 22:42 |
| persia | sistpoty: Yep. Try running dpkg-buildpackage -B without build-depends satisfied. | 22:42 |
| sistpoty | ok, if that's the case, then I'll take back my argument and vouch for the opposite *g* | 22:43 |
| persia | \sh: pass your -S implies -D patch to sistpoty :) | 22:44 |
| \sh | sistpoty, when you check the buildlogs of soyuz, you can see that sbuild is checking the b-ds of the source package before any call is made to debian/rules | 22:44 |
| \sh | persia, well the bug is, that -S doesn't imply -D ,-) | 22:44 |
| persia | \sh: Right, so the patch is -S implies -D, no? | 22:45 |
| sistpoty | \sh: sure for sbuild, that's where I put it... because I assumed that dpkg-buildpackage wouldn't handle this case | 22:45 |
| \sh | persia, well this should be done, yes ... it would help people to not use debuild -S (which is written in several documentations) | 22:45 |
| sistpoty | but it obviously knows about b-d's so you're right ;) | 22:46 |
| persia | \sh: debuild -S just calls dpkg-buildpackage -S. It should do the right thing. | 22:46 |
| \sh | persia, well after the patch yes *eg* | 22:46 |
| persia | sistpoty: How do you build source packages with sbuild? | 22:46 |
| sistpoty | persia: you cannot... build e.g. debuild could handle that... how do you build these w.o. dpkg-buildpackage? | 22:47 |
| sistpoty | s/build/but/ | 22:47 |
| persia | sistpoty: dpkg-source? (and, no, I don't advocate this) | 22:48 |
| sistpoty | heh | 22:48 |
| sistpoty | anyways, you're completely right ;) | 22:48 |
| \sh | persia, but back to gaphor, our buildd is intelligent enough to not fail ;) | 22:50 |
| persia | \sh: That's because it's not trying to build source :p | 22:51 |
| * POX_ is finishing his patch for #461157 (which he will reopen soon) | 22:51 | |
| persia | POX_: Thank you very much :) | 22:52 |
| \sh | I'm waiting for POX ;) | 22:55 |
| * \sh takes a deeper look at sbuild to use it instead of pbuilder | 22:57 | |
| persia | \sh: There's a script in ubuntu-dev-tools to automate setting it up, if you have LVM (even just LVM on a 20GB partition) | 22:58 |
| * sistpoty is off to bed | 23:01 | |
| sistpoty | gn8 everyone | 23:01 |
| \sh | persia, well, I'll have 500GB still free to ise | 23:02 |
| \sh | s/ise/use/ | 23:02 |
| ScottK | geser: I see you once aske for an etpan-ng sync. Do you use the package? | 23:02 |
| \sh | brb | 23:06 |
| \sh | restarting session | 23:06 |
| === \sh is now known as \sh_away | ||
| geser | ScottK: no | 23:07 |
| ScottK | geser: OK. Thanks. | 23:08 |
| geser | ScottK: looking at the old sync request, I guess it was because of unmet deps | 23:08 |
| ScottK | OK. I'm messing with a bunch of mail related packages for backports. I think I'll leave that one alone then. | 23:09 |
| POX_ | a propos sync requests (while updating my pbuilder :) | 23:09 |
| POX_ | ScottK: could you sync all my paste* packages? | 23:10 |
| POX_ | all need to be synced at the same time (I moved to pysupport) | 23:10 |
| POX_ | I will give you package names in a sec. | 23:10 |
| ScottK2 | OK | 23:10 |
| === \sh_away is now known as \sh | ||
| POX_ | paste, pastedeploy, pastescript, pastewebkit | 23:11 |
| ScottK2 | Any particular order? | 23:12 |
| POX_ | paste fixes LP: #184162 | 23:12 |
| POX_ | paste should be first | 23:12 |
| ScottK2 | Bug #184162 | 23:12 |
| ubotu | Launchpad bug 184162 in paste "python-paste missing dependency on python-scgi" [Undecided,In progress] https://launchpad.net/bugs/184162 | 23:12 |
| \sh | persia, give me a hint...mk-sbuild-lv just started ...do I need to mount some lv volumes first before going on? | 23:12 |
| persia | Do need to define a volume group, but I don't think you need to define any volumes. My setup experience predates the script though. | 23:14 |
| geser | are there some stats how much space the average build takes? I plan to run pbuilder on tmpfs once I've 4 GB RAM | 23:15 |
| bddebian | Nice | 23:19 |
| persia | geser: I use a 4GB volume with sbuild, and only have ever had trouble with WX (but I've not tried eclipse, OOo, etc.) | 23:19 |
| \sh | hmm | 23:29 |
| \sh | mk-sbuild-lv --arch=amd64 --name=hardy --source-template=/home/shermann/pbuilder/etc/hardy/apt.conf/sources.list data00 hardy | 23:29 |
| \sh | Specified release not known to debootstrap | 23:29 |
| \sh | wtf? | 23:29 |
| ScottK | \sh: Do you have the one from Gutsy-backports or the regular one? | 23:30 |
| \sh | ScottK, I'm on hardy | 23:31 |
| ScottK | Oh. | 23:31 |
| ScottK | Nevermind | 23:31 |
| \sh | and debootstrap works | 23:31 |
| \sh | # Is the specified release known to debootstrap? | 23:34 |
| \sh | if [ ! -f "/usr/lib/debootstrap/scripts/$RELEASE" ]; then | 23:34 |
| \sh | -EBUG | 23:34 |
| \sh | it's really /usr/share/ not /usr/lib | 23:34 |
| ScottK2 | POX_: There's all requested. | 23:34 |
| POX_ | ScottK2: thanks | 23:34 |
| ScottK2 | There's/There're | 23:34 |
| \sh | now | 23:35 |
| === nikolas_ is now known as nikolas | ||
| \sh | fixing | 23:38 |
| \sh | wow...my first contribution to ubuntu-dev-tools... | 23:44 |
| \sh | hmm...arch:all is simple arch:i386 for sbuild, right? | 23:46 |
| crimsun | essentially. | 23:47 |
| \sh | crimsun, but when my default arch is amd64, how can I tell sbuild to use this as as arch:all replacement? | 23:48 |
| \sh | feedparser_4.1-10.dsc: i386 not in arch list: all -- skipping | 23:48 |
| \sh | ah | 23:49 |
| \sh | -A is the magic switch | 23:49 |
| crimsun | it appears to be, yes. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!