[00:00] LaserJock: i dont really think its nessesary as those links arent even correct [00:00] as the disclaimer said [00:00] but i guess it wonthurt [00:01] imbrandon: hmm, those are interesting links though [00:02] not what I thought they were on first reading [00:03] hey guys [00:03] hi huats [00:04] I am making a so called fake sync, I am reporting every debian changes to a ubuntu orig.tar.gz (which differs from the one in debian...). Do I need to put the debian changelog and the debian copyright. Or can I keep the ubuntu ones ? [00:05] huats: how do the tarballs differ? [00:05] Oh by the way, another question (not related to the first one), I am a new ubuntu member ... how can I activate the ubuntu.com address ? [00:06] LaserJock: they are not the same :) [00:06] huats: well, I gathered that ;-) [00:06] huats: what's different about them? [00:06] huats: try sending email to your ubuntu.com address and see if it works [00:06] LaserJock: let me check again, I have started that a long time ago so I have to remember :) [00:07] LaserJock: it was not functionning.... [00:07] yesterday [00:07] I'll try again.. [00:08] huats: you might ask somebody in #canonical-sysadmin on Monday, but if it doesn't work I think you file an RT ticked (rt at canonical.com I think) [00:08] ok [00:08] I'll have a look on monday so [00:12] LaserJock: Ok I hav seen the differecnce... [00:13] what can I telll you about ? [00:13] well, why is there a diff, what kind of stuff is changed? [00:14] in general I would think if you were to do a fakesync I would think you would stay as close to Debian as possible [00:16] ok [00:16] why there is a diff, I don't know... [00:27] huats: I guess you kinda need to know what the changes are and enough about why they are there to see if any changes need to be kept [00:27] ok [00:30] LaserJock: I'll investigate on that thus :) [00:31] LaserJock: thanks :) [00:32] good night all [00:32] cya [00:35] I'd need to make a few minor changes to my package, which now is in the repositories. [00:35] So what is the process? [00:36] cyberix: Main package or universe package? [00:38] Well, multiverse [00:38] I suppose the process is the same as for universe [00:39] cyberix: file a bug, attach a debdiff, subscribe u-u-s [00:40] cyberix: Yeah, basically what LaserJock said. Also see https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue. [01:26] Good night folks! [01:48] Just saw this email on the udd list https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-December/002696.html - discussing the out of sync nature for three packages that is, the source and the binary are not the same. [01:48] The packages discussed are logjam, qemu and aumix. [01:49] I started writing a response to the list but thought it might be smarter to discuss this here first. [01:49] owh: I responded to the bug he filed already. What is there to discus? [01:49] s/discus/discuss/ [01:50] I haven't seen your response in the bug yet, but I'm wondering if there is a procedure to catch this "out of sync" nature because it could potentially be used as a way of introducing more sinister binaries. [01:51] How can sinister binaries be introduced? The worst that can happen is that some are out of date. [01:51] (and we have a page to catch those, now) [01:51] owh: It generally only happens when an older version FTBFS. There's no binary upload, so it's not likely to be sinister. [01:52] Well, the email I linked to specifically states: "the maintainer grabbed from a broken CVS" [01:52] owh: Sure, but "broken" doesn't mean "sinister" [01:52] I wouldn't call that sinister. [01:52] My question is, "could it be?" [01:53] I'm not saying it is. [01:53] ... [01:53] I'm trying to ask if the procedures used have any holes in it that this is showing? [01:53] That is, "Is this the tip of an ugly iceberg?" [01:53] It is the tip of the FTBFS iceberg, but it can't be sinister. [01:54] somerville32: Thanks for reviewing people's packages on REVU. If you don't mind, could you share your comments in this channel when you do so? [01:54] Well, if we have something sinister in the archive, we've got larger problems than out-of-date binaries. [01:54] persia, Alrighty. [01:54] Sure. [01:54] somerville32: Thanks :) [01:55] So Fujitsu, what you're saying is that this is *only* the visible end where source did not build, no other problem? [01:56] owh: What do you mean? This situation only occurs when the source doesn't build... there's nothing to *be* visible in any other case. [01:56] so If the new source package doesn't build, then the old binary still exists? [01:57] Correct. [01:57] It won't be dominated, and will remain published until it is. [01:57] So, the qemu example was a case of poor testing, but successful building? [01:58] Where's this? [01:58] In that email? [01:58] s/?/./ [01:58] Oh, I didn't see that reply. [01:59] Perhaps it would be a good idea for a MOTU to put that into writing on the list to highlight what is going on so no-one jumps to any conclusions and it all explodes in a flurry of emails? [02:00] ... we only have a CVS qemu in Hardy. A broken package in Hardy. Wow. [02:00] I mean that the tone of the two emails could be construed as an issue as I started to do before I came here to talk about it. [02:00] * Fujitsu generally follows a policy of letting -devel-discuss users live in their own little world. [02:01] What issue did you see, exactly? [02:01] Well as I read it, likely from inexperience, I saw three packages where src and binary were out of sync with little reference to where the binary came from. [02:01] Erm, even better, qemu on Hardy does work.l [02:02] What gave you the idea that the qemu binaries were out of sync? [02:02] There seemed to be a tone that there was a problem, but from the discussion here I'm just hearing that its FTBFS. [02:03] There are no qemu FTBFSes (except for archs where it has never built) in any release except edgy, and that's just powerpc. [02:03] The same email. Mind you it had very little on detail and reference, but I thought it would be prudent to ask. [02:04] It's pretty hard to tell if the person sending the email in the first place is talking out of the wrong orifice at the best of times. [02:06] Thanks for your time all. Happy to hear there is no issue. [02:06] owh: Well, there is an issue: packages shouldn't fail to build from source, and should be fixed, but it's not a dangerous issue. [02:07] And, as I said in the bug, we can now see what FTBFSes we have on our plate fairly easily. [02:08] * persia cheers Dktrkranz and geser [02:08] Yep. [02:08] Is there a link that shows those packages so a wider group could assist? Or is that counter productive? [02:09] http://qa.ubuntuwire.com/ftbfs. [02:09] owh: Depends. If the wider group is up to submitting patches to get them to work, it would be helpful. Filing bugs isn't so helpful. [02:09] No kidding :) [02:10] We could really do with a mass-giveback soon, due to bug #160439 [02:10] Launchpad bug 160439 in soyuz "Some builds fail when they should depwait" [Medium,Triaged] https://launchpad.net/bugs/160439 [02:10] So is there any point in me mailing that link to udd, or should I just leave well enough alone? [02:12] Text along the lines of "These are examples of FTBFS, here are some others. If you have patches to fix it, please do so." [02:12] owh: Careful: that might be considered inflammatory. Some people seem to believe there is a distinction between users and developers. [02:12] ROTFL [02:13] Fujitsu: Do we have a means to distinguish which packages are affected? [02:13] Sorry, that sounded flippant, it wasn't intended as such. [02:13] The examples given in the reply to the email are not FTBFSes. [02:13] persia: Not at the moment, but it would be quite easy to grab build logs and grep for them. [02:14] Fujitsu: Ah. True. From what I have seen, I had the impression that a mass-give-back would be considered, if someone were to dig up which were the affected packages and submit the list. [02:14] It would be easier to just throw everything at the buildds again, thought. [02:14] s/thought/though/ [02:15] hppa will all be given back within a couple of weeks anyway, and the others don't have a whole lot of FTBFSes. [02:15] Fujitsu: Yes, but proposing that makes the buildd-admins whine about resources, and point at the fact that we've never caught up (on all archs) [02:16] Grr, Soyuz is being silly again. [02:17] There has been one item stuck in the i386 and powerpc queues for at least several hours now, and I can't see it anywhere. They seem to be up to date, but /+builds says otherwise. Yay. [02:18] persia: hppa should catch up within a couple of weeks, and the other archs are generally fairly up to date. [02:18] Fujitsu: Yes, but you are talking about 1000 packages. I had complaints about that volume when asking about the < Dapper rebuilds. [02:19] * persia isn't convinced by the buildd-load argument, but is just sharing [02:20] Less than 200 packages on each arch is nothing. [02:21] Fujitsu: True. I guess I'm misreading the FTBFS page then. [02:24] There are 1168 packages with issues, but less than around 200 failures on !(lpia|hppa). lpia is always ahead of everything else anyway, and hppa is special... I don't see why anybody would have a problem with it. [02:25] Fujitsu: For the < 200 failures, I don't imagine it would be an issue. Someone might want to get fed 20/day or something, but that's the only issue I can see being raised. [02:45] That looks bad. [02:45] Hey bddebian. [02:46] Heya gang [02:46] Hi Fujitsu [02:54] heya bddebian and Fujitsu. [02:55] Hi ScottK [02:56] Hi ScottK. [03:02] persia: You around by any chance? [03:02] bddebian: Yes [03:03] persia: Got a minute for a /query? [03:10] ScottK: thanks for the firmware-addon-dell comments [03:10] XS-Python-Version and XB-Python-Version are deprecated for use with python-support, per the warnings at build time and http://wiki.debian.org/DebianPython/NewPolicy [03:11] mdomsch: You need either pyversions or XS-Python-Version. Unless I missed it you have neither. [03:11] yeah, I added pyversions to satisfy [03:13] and persia spent quite some time explaining the versioning to me, so I can get that right next time [03:13] Good. [03:14] Did you also take care of python versus python-all-dev? [03:14] You understand the difference? [03:14] mdomsch: Something I failed to mention before, which might be nice next time, is the option of distributing -0dellN from l.d.c, as -0ubuntu1 would always be higher, making the issue transparent. [03:15] indeed [03:15] persia: I saw you recommended a linda over-ride for the package. Why is that? [03:15] * persia looks at REVU again to build context [03:15] just for the piece that's a yum plugin [03:15] it goes into an odd directory, /usr/lib/yum-plugins.d or somesuch [03:16] arguably, as yum isn't the default on debian/ubuntu, I should skip that [03:16] Yes, but why does it go there? [03:16] That too, why install it at all? [03:16] but, yum is available in universe [03:16] * ScottK learns something new every day. [03:16] That is just wrong. [03:16] ScottK: because yum doesn't look in the /usr/share hierarchy (but not installing it is probably a better solution than a linda override) [03:17] ScottK: code sharing. I don't think it's bad to have tools, but you're right that we shouldn't encourage use. [03:17] Well OTOH if yum is in the repos it'd be wrong to work at not supporting it. [03:18] Sounds like a bug in yum then (at least the yum package on Debian). [03:18] ScottK: Yes, certainly. yum should allow packages supporting yum to be policy compliant :) [03:23] brb [03:27] Bug filed. [03:27] Marked another one invalid while I was there. [03:30] ScottK, I thought pysupport didn't require pyversion or the Python-Version fields [03:32] It does AFAIK. [03:36] No, if you don't have pyversions than it uses current [03:36] I'm not saying it won't run, just that it's supposed to be there. [03:37] Not according to the docs for python-support [03:37] You should only have a pyversions file if the module doesn't work with all python versions [03:38] Right. For what definition of all? [03:39] ScottK, ie. If it requires a specific version [03:40] somerville32: Right. So anything without it should work with python < 1.0, right? [03:40] Yes, exactly. [03:41] You mean python > 1.0 ? [03:42] * mdomsch hates "all" in discussion of versions [03:42] you're going to get bit at some point [03:42] somerville32: No, I mean python < 1.0 [03:42] * persia agrees with mdomsch [03:43] I'm using the same semantics the document does [03:43] somerville32: What does the document mean by "all"? [03:44] any? [03:44] >= 0.0 [03:44] `all' simply means anything in the distro, though it gets a little nasty as we add new versions. [03:45] OK. I see. For python-central, I read it as needing XS-Python-Version, and for python-support, I read it as needing XB-Python-Version. [03:45] negative. [03:45] You don't need X[BS]-Python-Version fields. [03:45] You don't need debian/pycompat [03:46] You don't need to call dh_python after dh_pysupport [03:46] Right. Everything needs XB-Python-Version, and python-central also needs XS-Python-Version. [03:46] * persia agrees with not calling dh_python [03:47] X[BS]-Python-Version fields should be removed when using python-support [03:48] the wiki is unclear on this point [03:49] but the code throws warnings for XB-Python-Version present when using python-support [03:49] The docs for python-support are quite clear [03:50] indeed [03:50] * persia suspects the "New Python Policy" of being insufficiently new, and goes back to non-python things. [03:52] The "New Python Policy" is pretty much unmaintained right now. Fixing that has recently been discussed in Debian. [04:28] ScottK, new upload of firmware-addon-dell to revu with your suggested changes, thanks [04:28] mdomsch: You're welcome. [04:28] I made equivalent changes to firmware-tools, but... [04:28] upstream is converting from distutils to autoconf [04:28] and there's some serious breakage in the upstream package right now [04:28] Yummy. [04:29] Right, so let's stick with this one then. [04:29] so until that's resolved, I can't do another upload [04:29] You can continue to upload revisions to the distutils version to REVU [04:29] Moving to autoconf? That sounds a bit odd. [04:29] Fujitsu, I wasn't too pleased to see that [04:30] in fact, it's cost me ~4 hours work trying to fix the breakage so far === asac_ is now known as asac [04:42] I don't suppose you can just write your own distutils setup.py and ignore the upstream autoconf stuff. [04:53] ScottK, no, I'm just going to make upstream fix their brokenness with autotools independent of debian packaging [04:53] and once that's good again, finish whatever is left of the deb packaging [04:53] for now, as you suggested, I'm just redoing the upload [04:53] w/o all of upstream's latest changes [05:00] What is our policy on creating a Homepage field when merging? IMO it's unnecessary delta... [05:00] Fujitsu: imho it should be sent upstream, not here [05:01] maybe a wishlist bug upstream [05:01] (I'm actually doing some sponsoring for the first time in ages) [05:01] imbrandon: Debian, you mean? [05:01] yea [05:01] Fujitsu: I don't see any reason to block sponsoring for it: the tools will be broken one way or the other. [05:02] persia: I guess. I'm sending it back for other changes anyway. [05:03] yea , in my school of sponsoring too ( i'm pretty unique on somethings ) if that is the only change i would just change it myself ( e.g. revert it, then let the contributor know you reverted it ) and upload anyhow [05:03] Fujitsu: If you're kicking it back anyway, maybe it's worth reinforcing the minimal-deviation idea. [05:03] The only exception being .desktop files, due to the magic of app-install-data [05:03] persia: That's what I've done. [05:03] Yes. [05:04] imbrandon: I used to be a member of that school, but it means they don't get upload credit. I'm currently on the fence, and subscribing to push-back in most cases. [05:05] persia: sure they do, you can add something to the changelog etc and still leave them as the person in the changelog [05:05] (although, thinking about it, maybe they shouldn't get upload credit, and will need to hit more bugs to build credits if everyone does the fix & upload thing) [05:05] that added the entrie [05:05] you have to sign the file anyhow [05:05] imbrandon: That would be wrong. [05:05] nah its done quite a bit in both debian and ubuntu, i dont see how its wrong [05:05] imbrandon: The person who closes the changelog should be the last person to touch the package. [05:06] persia: That deliberate loss of upload credit is an interesting idea indeed. [05:06] imbrandon: It's wrong because both the person reporting the changes being completed and the date the changes are completed are incorrectly reported. [05:06] how its always done in the rcs packages i work on its the first person to add an entry [05:07] * mdomsch uploads new firmware-tools [05:07] Fujitsu: It gets more patches through faster too. I think most people would be happy getting their patches in, even without being the Changed-By name, and if they want to get accepted, they need to get it right. Maybe worth discussing Friday? [05:07] I suspect so. [05:07] persia: devede fixed [05:08] imbrandon: It should be the last person to add an entry. dch does the right thing. [05:08] ember: Great. Of course, that means you're at the bottom of the least-recently-touched queue, but it shouldn't be more than a couple days. [05:08] dch dosent account for multi-people editing [05:08] on a single upload [05:08] imbrandon: Yes it does. Try it. [05:08] he hates me [05:08] :o [05:09] ember: No, I just sponsor in least-recently-touched order to avoid anyone having to wait forever for a response. [05:09] okies, i conceed probably wrong, but it is a common practice [05:10] imbrandon: Maybe, but people who do that should be using dch, and follow the new accepted correct practice. [05:11] anyhow new subject, anyone care to give me a 5 minute primer to git ( i'm familiar with svn cvs bzr(kinda) ) so it shouldent take long to get me a basics enough to do a branch and a diff etc [05:11] persia: likely [05:12] i just am trying to do a bit-o-kernel patching from fedora-->suse-->fedora-->xebian-->ubuntu and git seems to be the common link [05:12] ( yes xebian not debian ) [05:15] okies , guess i'm gonna do some trial and error [05:15] imbrandon, are you going to be cherry-picking? [05:16] e.g. grabbing specific commits from one tree to pull into another? [05:16] mdomsch: yea, some xbox specific patches [05:16] yea [05:17] so, you need both trees/branches in the same local git tree [05:17] then you choose the specific commits from say fedora-branch you want [05:17] and you git cherry-pick (from your working-branch) [05:17] well the main thing is .... well ok [05:18] here is the deal, say i can get a "working" local directory [05:18] thats a git branch of our current ubuntu kernel [05:18] yep [05:18] git branch working [05:18] git checkout -f working [05:18] then i make a working-diff dir thats basicly a cp -Rav of the working [05:18] with patches i grab from multi places [05:19] cvs/svn/raw diff [05:19] etc [05:19] sure [05:19] untill i get it "they way i want" [05:19] * persia mistakenly accepted a merge :( [05:19] can i then make a "git bundle" or somehing i can hand to someone with git commit access [05:19] between the two [05:20] well, you're outside of git as soon as you do the cp -rav [05:20] instead do [05:20] persia: I'm sponsoring one too, but that's because it happens to contain a bugfix for a bug that I hit. [05:20] git clone upstreamurl [05:20] git branch working [05:20] git checkout -f working [05:20] apply patch #1 [05:20] git commit -a -m 'message for patch #1' [05:20] repeat [05:21] ok git commits localy like bzr ? [05:21] yes [05:21] Fujitsu: Sponsoring merges isn't bad: personally, I'd like to see merges for any significant Debian bugfixes, I just have to be careful, as I often make mistakes with merges (so usually sponsor other things). [05:21] nice, ok [05:21] then, when you haev it "the way you want" [05:21] you publish the tree somewhere somehow [05:21] yup, thats exactly what i was looking for [05:21] e.g. rsync it to a web server [05:21] cool, yea [05:22] persia: Oh, right, forgot about your general aversion to them. [05:22] thanks mdomsch [05:22] and tell your friend to pull from the working branch of the tree you just rsynced [05:23] nxvl: You don't need "Closes" when closing a LP bug. Rather, it's preferred not to use it (although it works) [05:23] imbrandon, git-request-pull formats the email you can send to request the pull [05:24] nice [05:24] i've just been getting used to the nice things about bzr ( really distributed rcs ) but git ( without having actualy used it yet ) seems nice(er) [05:25] i'm sure they both have their place though [05:25] * mdomsch hasn't used bzr yet [05:25] but I think they're similar conceptually [05:25] bzr rocks, and just reached 1.0. [05:25] I've not used git very much. [05:25] man once i found bzr-svn and bzr-cvs i never looked back [05:25] git is fully distributed [05:25] mdomsch: so is bzr [05:25] yep [05:25] imbrandon: They optimize for different cases, but both are nice in preference to what went before. [05:26] at work, some teams are forced to use clearcase [05:26] and i love the plugins , i can work with a svn tree like its a bzr branch and still push it back too [05:26] * minghua played with both bzr and git, but hasn't known enough to do a comparison. [05:26] never touching svn [05:26] so, when the servers are down, or out of sync in the various geographies [05:26] clearcase! Didn't that die a proper death last decade? [05:26] they can't commit or sync [05:26] Hahahahahaha. [05:26] Clearcase, yay,. [05:27] there's a tool I'm reading about, git-buildpackage [05:27] hrm there might even be a bzr-git, i might have to look heh [05:27] for maintaining debs in git [05:27] imbrandon: I don't believe there is. [05:27] mdomsch: If you decide to use git-buildpackage, you may also be interested in pristine-tar [05:27] mdomsch: yea bzr-buildpacakges and svn-... and cvs-... too ( not positive obut cvs-... ) [05:29] imbrandon: Of course there is a cvs- one, it's the oldest (and probably the root of all these). [05:29] hrm anyone know if someone produces a usb disk that uses real ramchips vs flashchips ? [05:29] imbrandon: Wouldn't that be a bit... volatile? [05:30] Fujitsu: yea, it would be intended to be [05:30] as like say a slow swapdevice when nothing else is avail [05:30] vs swap over ethernet [05:31] imbrandon: I've seen PCI, IDE, and PCIe RAM devices, but never USB. [05:31] persia: ide? [05:31] that might work too [05:31] hrm [05:32] imbrandon: Yep. Generally with a battery to make them less volatile. You could presumably wrap it with a IDE->USB converter. [05:32] yea [05:32] yea i was thinking a batery would be needed in the usb one [05:33] like a thumbdrive + ram + bat [05:33] plus some EE person to make it all work :) [05:33] imbrandon: Of course, I don't have any brands or anything. These are the sorts of kit in the boxes of loose stuff on the bottom shelf at the components shops. [05:33] right [05:33] gives me something to look at though [05:34] ( for context if intrested see "Other Hardware Thoughts" on http://www.not404.com/node/52 , almost at the bottom ) [05:34] imbrandon: Expect a budget of ~ $50 USD (I think) if you can find somewhere that sells cheap unbranded chinese kit. [05:35] yea i'd imagine, but it would make the diffrence between 64mb ram and ++ in a xbox without soder, making the 733Mhz + nvidia box maybe worth using as a workstation, abet slow yes [05:36] and even with soder iirc you can only hit 256 [05:37] imbrandon: You've found a market niche. Find a manufacturer, get an importer to smooth customs for 10-15%, and you've a hobby business. [05:37] :) [05:38] i already make "xbox controler port to usb hub" cables at home for $$ , cheap but still heh [05:38] its funny the controler port on a xbox is just a funny shaped usb port [05:39] thus enabling people to mod their xboxes without opening the case or voiding anything ( not that they even still amek them ) [05:39] or hooking up keyboards and mice [05:40] or using usb thumdrives as memorycards [05:40] or tons of other things [05:43] wow, i hate patents, i searched for it and the first thing that came up was a patent [05:43] http://www.patentstorm.us/patents/6219736.html [05:43] so someone has thought about it [05:46] imbrandon: Move out of US. :-) [05:46] :P [05:46] imbrandon: That only means you can't design or manufacture it without permission from the patent holder. [05:47] I think that wins the prize for the most uses of microcontroller in a paragraph. [05:47] lol [05:47] persia: Really? Even if I make it for myself, instead of selling it for profit? [05:48] minghua: Well, right. One cannot design or manufacture such a device for sale or free distribution. One can use privately, or resell if designed or manufactured by someone else. For more details, seek counsel. [05:49] hrm is this it? it seems like the right keywords but the actual design dosent look like what i ment [05:49] http://www.controlchips.com/usbram.htm [05:50] imbrandon: That appears to be an implementation of the patent you listed earlier, although were one to construct something today, it might make sense to use faster USB. [05:51] right [05:51] that page looks last updated 2004 [05:51] so its not real uptodate [06:35] StevenK: round? [06:40] StevenK: un-ping [06:41] * persia notes that the U-U-S queue has reached single digits again, and encourages someone else to review the rest of them. [06:41] (special points available for anyone willing to do bug #133888) [06:41] Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the 2.8.6.1 release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888 [07:16] imbrandon: Unpong [07:17] imbrandon: Besides, I'm a square [07:23] ember: Are you familiar with watch files? [08:51] hello. [09:06] Hi all [09:46] has anyone compiled Cedega successfully? [09:49] jekos1: it failed for me, i find wine works better anyway [09:59] harrisony: it tried to compile but failed too. I've downloaded it from CVS (53 M), it will be pity to make up with compilation [10:00] then again, i tried it early this year === persia changed the topic of #ubuntu-motu to: Ubuntu Masters of the Universe: https://wiki.ubuntu.com/MOTU | Hardy Heron is in active development. | 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 | It's REVU Day. Packagers, update your candidates. Reviewers, let's get more hammers & hearts on http://revu.ubuntuwire.com [10:00] but i find wine works all the time [10:01] It's REVU day again! [10:01] 30 Candidates today in need of review. [10:02] ARGH!, i was going to try get a package done for revu day, but stupid pbuilder isnt liking me [10:02] harrisony: What's wrong with pbuilder? [10:04] persia: keeps throwing errors when i use pbuilder-dist (from the ubuntu-dev-tools package) some errors about ' in the sources list or something [10:04] (on the initial create) [10:05] harrisony: Ah. Have you hunted down the sources.list it tries to use? Perhaps there's a typo. [10:06] harrisony, have you edited any pbuilder configuration files? what command are you using to create the pbuilder? [10:06] DarkMageZ: pbuilder-dist hardy create (pbuilder-dist is found in ubuntu-dev-tools) [10:07] harrisony, what about "sudo pbuilder create --distribution " [10:08] harrisony, then edit /etc/pbuilderrc and enable universe and multiverse then "sudo pbuilder update --overide-config" [10:08] DarkMageZ: im doing that now, pbuilder-dist is nicer when it comes to mutiple versions [10:08] * pochu has a lot of pbuilder-$distro in his $PATH :-) [10:09] "sudo pbuilder build --basetgz=/var/cache/pbuilder/warty/base.tgz lol.dsc" :P [10:10] * persia thinks warty isn't a very useful base these days [10:10] heh [10:10] i was trying to avoid dapper vs gutsy vs hardy debate :P [10:10] wouldnt mind finding a warty cd to see what it was like in ye old days [10:11] harrisony, ye old days were only 2004... you were 12. this makes you VERY old :P [10:11] DarkMageZ: hahaha very very, what was i doing when i was 12, hmm [10:12] * persia asks the 7 packagers with "Updated Packages" on REVU to submit interdiffs to bugs and subscribe the sponsors queues if they wish to request upload. [10:19] Yes, persia, just saw that, and uploaded interdiff [10:19] so the updated packages section of REVU is going to be phased out? [10:20] LucidFox: Not any time soon, but it only gets looked at on Mondays, and not so often at that. There's a better chance of getting review & sponsorship from the sponsors queue. [10:20] * persia often scans the "Updated Packages" section, and archives candidate revisions that are older than the archive versions [10:23] persia: would it be useful if REVU distingished from main and universe packages? [10:23] so MOTUs concentrate their work in universe packages [10:23] pochu: Not really. All NEW packages go to universe, and updated packages don't really belong on REVU anyway. [10:23] hmm, right [10:24] I was thinking on updated packages, as Ive just seen gnome-terminal there, but you're right [10:24] pochu: If someone has a NEW package for main, best plan is to get it into universe, and file a MIR [10:25] On the other hand, sometimes a sponsor requests a signed upload somewhere, and REVU is a handy resource. Once LP gets proper dget support for PPAs, etc. (very soon now, might even be in edge), this becomes less useful. [10:25]