[00:05] james_w: hi, got the next lot — http://dpaste.com/167584/ [00:05] been slacking a bit, sorry [00:06] Laney: LP is taking a nap, ping me tomorrow and I'll process them [00:06] oh, I didn't actually expect you to be around at midnight [00:07] well, you are :-) [00:07] xmonad-contrib is 528803 [00:07] I forgot to -f on agda [01:19] i have done a few patches to fix some easy bugs and posted the patches upstream. I am now wondering what i should attempt next? What would be a good next step? [01:33] duanedesign: Towards which goal do you seek a next step? [01:51] hello persia [01:53] persia: my eventual goal is to be a MOTU and help maintain and add to the Universe and Multiverse [01:53] OK then. [01:53] persia: is that too broad :) [01:54] Two areas which need current work are unmetdeps and patch review. I'd be happy to lead you through getting started with either of those, if you have time. [01:54] No. broad is what MOTU is all about :) [01:54] oh yeah, definetly! [01:55] If you'd no preference, I'd rather point you at patch review, as there are recent logs of my pointing someone at unmetdeps [01:55] Does that sound like something you're up to doing? [01:55] sounds good. [01:56] So, we have millions of users, and they submit thousands of patches, and one of our roles is to process those patches to improve the software. [01:56] This generally involves testing the patch, potentially porting it to the newest revision, determining the state of the patch in upstream, making sure it does things in a sane way, etc. [01:57] If a patch is good, clean, well-reported (or already upstream), we can just upload (freeze observations permitting). [01:57] If a patch needs work, we can either work on it or work with the patch submitter to have them work on it. [01:58] But the idea is to collect all the patches, make sure they are as good as they can be, and get them into the software (either in Ubuntu or upstream). [01:58] There's lots of useful links at http://qa.ubuntuwire.com with stuff that needs attention. One of those is "Ubuntu Bugs with the "patch" tag. This is our target for today. [01:58] I have not done a ton of patches yet, but it seems like most patches go upstream? [01:59] Lots of them, yeah. There are rare cases where we want a patch only in Ubuntu, but most patches should get passed upstream so that everyone benefits. [02:00] I also see a link on /MOTU/TODO/Bugs for Universe and Multiverse bugs with patches attached [02:00] That works too :) There's lots of links to this list. [02:00] I like the "patch" tag because those tend to have gotten some triage, but any of the methods works. [02:00] ill stick with the one you gave for know. Just want to make sure i am understanding :) [02:00] There's about 2000 patches out there, and about 250 with the patch tag. [02:01] ok great persia [02:03] So, once you've gotten to one of the lists, pick a bug. I recommend starting either with a package you've seen before, or with a package that you think doesn't have so many developers working on it: these tend to have easier-to-process patches. [02:04] Please share the bug number once you picked it so I can follow along :) [02:05] Is there an automated way to deal with merge diffs? [02:07] Or should I just delete the lines that I don't want? [02:07] funkyHat: There are a few, but we've not found any that are smart enough that we can remove humans from the loop. The algorithm used on MoM is our best current stable attempt. [02:07] persia: I mean is there a tool I can use to step through the parts that need merging and choose one or the other? [02:08] funkyHat: No, that's the part where we still need human intelligence :) [02:09] * duanedesign is looking through the 'patch' bugs now [02:09] So I have to manually remove the <<<<<<<< blah-version (ubuntu) and ======= and >>>>>>>> blah-version (debian) lines [02:10] If you're using MoM, yes, and you have to think about the other stuff. [02:10] ok [02:10] Also, you'll want to think about *any other* changes. MoM merges some stuff cleanly which needs attention. [02:15] * zul cries [02:15] Why? [02:15] ajmitch: fixed [02:16] zul: I should have done it myself, but it took awhile to update my lucid VM :) [02:17] ajmitch: slacker [02:20] If the debian maintainer has changed, should I update XSBC-Original-Maintainer to match? [02:20] funkyHat: Please. [02:20] duanedesign: Did you find a good bug with a patch? Do you need a suggestion? [02:21] Oh I guess that's what will happen anyway if I keep the debian maintainer headers and then run update-maintainer... [02:21] persia: i think i might of found something [02:22] bug 40925 [02:22] Launchpad bug 40925 in db4.2 "No man pages for db-utils" [Low,Confirmed] https://launchpad.net/bugs/40925 [02:22] Oh, that's a good one! [02:22] looks like there is a patch upstream waiting [02:23] From the description, the manpages might already be included in the upstream tarball. Download the source to check. [02:23] Does it make any sense to use apport-bug to file a merge bug? [02:23] funkyHat: Not really, no. [02:23] persia: kk [02:23] Didn't think so :) [02:25] Oh... launchpad isn't being awkward about filing bugs anymore [02:25] that's nice [02:25] I was just digging for the firefox quicksearch I made to get around it [02:35] if an original tarball already contains debian build scripts [02:35] bjsnider: Are they good ones? [02:35] yeah, good ones [02:35] libxine [02:36] what is the procedure as far as preparing it for the build system [02:37] Typically the same as usual, only one patches (if necessary) upstream stuff rather than starting from scratch. [02:37] what i mean is ordinalrily i would add .orig to the name, then add the build scripts to the local directory and do debuild -S -sa [02:37] But that sounds like a package we've had around for a while. Try looking at what was done last time upstream was integrated. [02:38] Same basic idea. [02:38] or -sd if it's already in the archive somewhere [02:38] so if i do an -S -sa with th orig fie already containing the build scripts, it's fine? [02:39] i have to add a new changelog entry [02:39] i don't see how that would work [02:39] the diff would just change the build scripts? [02:39] instead of creating them? [02:40] Right. [02:40] i see [02:40] debhlper has an --ignore feature if you need to ignore some file provided by upstream. [02:42] Is there a proper format for the contents of debian/changelog? [02:42] Not sure what to put, or how [02:42] use dch -i [02:42] I used dch, yeah, just wondering what else I need to put [02:43] I'm putting (LP: #531681) [02:43] funkyHat: That will parse as the correct syntax to close a bug. Double check by reading your source.changes file when you build the source. [02:54] duanedesign: Were you able to get the code? [02:57] Trying to run debuild but ubuntu one hasn't synced my gpg key -_- [02:57] There should be no need to wait for keyring sync for debuild. What error do you get? [02:59] gpg: skipped "Matt Wheeler ": secret key not available [02:59] gpg: /tmp/debsign.KA3BldE0/amule_2.2.6+debian0-7ubuntu1.dsc: clearsign failed: secret key not available [03:02] funkyHat: The most common issue is that you have a comment in your identity in your GPG key. Run `gpg --list-secret-keys` If you have an entry in parentheses between "Matt Wheeler" and "" you need to include that in debian/changelog [03:02] persia: ~/.gnupg@ is empty [03:04] Then you don't have a key available on that account. This is entirely unrelated to any status on the keyservers. [03:04] Yes I know, the issue is with Ubuntu One [03:05] The lucid VM isn't collecting the contents of .gnupg that I put in my Ubuntu One folder [03:06] You really don't want to put that there. [03:07] What's a better way to move stuff in and out of kvm VMs? [03:07] Unless you have some reason to *know* that the cryptography used for that remote store is sufficient, you may have compromised your key. [03:07] I use ssh. [03:07] But I also don't worry about signing stuff in VMs. [03:07] If I get a good result, I can always use debsign to sign it. [03:08] So I usually use `debuild -S -us -uc` [03:08] persia: ok, looks like the upstream documentaion that was included was in .html format [03:08] (I do the same thing in chroots, which I use more frequently than VMs) [03:08] duanedesign: But no upstream manpages in 4.2? [03:10] duanedesign: not in the package. But the patch is the html files converted and then minor edits by hand. [03:11] duanedesign: OK. So since you've determined that you understand the issue, and can work on it, set the bug to "In Progress" and assign yourself. [03:11] Then make the necessary changes in the source, etc. [03:12] Check the upstream mailing list, and see if someone already submitted db4.2 manpages (which may differ from db4.3 or higher manpages). [03:12] (this could save you some work). [03:12] If they *do* differ, and upstream doesn't have any for 4.2 yet, please submit them. [03:12] Once you have a working solution, add that to the linked Debian bug. [03:13] Once that's done, you get to decide: if you think it's important that Ubuntu fix this, prepare a candidate for upload. If you think it should be fixed in Debian or further upstream, mark the Ubuntu task wontfix with an explanation. [03:13] Any questions? [03:15] the source i got from the oracle9upstream) contains the /doc directory with the .html documentation. The Debian and downstream does not [03:15] Really? So there's a new upstream tarball of db4.2 that isn't yet integrated into Debian and Ubuntu? [03:17] persia: i dont think its new. I think for some reason they just took that directory out. Is there a bias towards .html documentation [03:18] because the Ubuntu/Debian Read Me even references the missing /doc directory. Saying to see the documentation load docs/index.html into your web browser [03:18] guess that needs to be changed too :P [03:18] duanedesign: There's a bias towards manpages. There exists a framework for handling HTML docs, but most developers are neutral about it (use it when it's there,but don't create it when it's not). [03:19] duanedesign: That makes it sound intentional. I'd recommend wontfixing the bug, unless you want to argue with the Debian maintainer about it. [03:19] * persia checks a couple things [03:20] persia: they might of just moved the .html help pages. Ill search [03:23] http://paste.ubuntu.com/388017/ I'm getting an error with pbuilder that I don't understand [03:24] Oh I missed off the bit further up where it says that package is broken... [03:25] funkyHat: So you understand now? [03:25] persia: sort of, I don't know why it's broken [03:25] Or how to fix it [03:26] As it's broken inside the pbuilder thing, not my actual system [03:27] http://pastebin.com/DrnqNGWG Here's the whole output, in case it's any use [03:30] Oh, I've worked it out. I need to configure pbuilder to use universe [03:34] Good identification of the issue :) Just take care to switch back to main-only if you are working on a package in main. [03:34] * persia frequently fails when dealing with main packages due to having enabled universe [03:35] Would it be worth it/possible creating separate base.tgz images for universe and main? [03:36] Depends on how much you work in both areas. [03:36] Some people do that. Some people don't. [03:36] persia: ok, db4.2-utils has no man page. Because there is a seperate package db4.2-doc. Its 9.8 MB of HTML pages, lol [03:37] so thats where they went [03:37] Well so far I've only submitted 5 debdiffs, and pretty sporadically, but I'm planning to do more as time allows ⢁). I'll hold the thought and perhaps do it if I find reconfiguring an issue [03:41] there is a 4.3man page. Should be easy to make a 4.2 manpage by looking at the diff from the 4.2 ->4.3doc package [03:42] This thing is taking so long to build :/ [03:43] Oh, VM. Duh. [03:43] duanedesign: Just make sure to check if there were changes in usage or options between the 4.2 utilities and the 4.3 utilities, and that those are accurately represented as changed in the 4.2 manpages. === vorian_ is now known as vorian [03:43] persia: ok. Thank you for all your help and patience ;) [03:44] duanedesign: Thanks for helping out with the patch review team. [03:47] Oh... I think I might have just wasted a bunch of time there with this merge... [03:48] It looks like there's actually no changes left (which I actually wrote in the changelog, but it didn't click), so we should just take the debian version [03:48] That's the best kind. It means it doesn't need someone to bother with merging it next time. [03:49] Discovering that and asking for a sync is not a waste of time. [03:49] ScottK: Shall I change my merge bug to a sync request, or make a new bug? [03:50] funkyHat: Just change it. [03:50] If I'm interested in ubuntu getting a package of the gerrit code review tool for git, where should I start on that process? [03:54] ScottK: which team should I subscribe? [03:54] Is the package in Main or Universe? [03:54] Universe [03:55] Ah is it ubuntu-universe-sponsors? [03:55] Yes [03:55] Thanks ⢁) [03:56] I updated merge-o-matic too [04:00] ekimmargni: How much effort are you willing to put into creating and maintaining the package? [04:01] persia: None. I've never packaged anything - that's totally beyond my capabilities. [04:01] If MoM hasn't encountered any problems with a merge are there any standard places I should check for issues, or is it enough to simply attempt to build? [04:03] ekimmargni: OK. Let me see if I can dig up the appropriate guidance docuemtnation. [04:03] *nod* thanks :) [04:06] ekimmargni: My apologies: I can't find quite the page I wanted. https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages talks about a general overview. The "Criteria" and "Requesting a new package for Ubuntu" sections are the ones in which you'll likely be ost interested. [04:06] Looks like debian-faq is another one to be synced [04:06] persia: thanks, I'll take a look === ekimmargni is now known as Mike||gone [05:00] I just uploaded debdiffs to https://bugs.edge.launchpad.net/ubuntu/+source/debian-faq/+bug/531711 - it's a really straightforward merge [05:00] Launchpad bug 531711 in debian-faq "Please merge debian-faq 4.0.4+nmu1 (universe) from debian unstable (doc)" [Undecided,Confirmed] [05:06] funkyHat: Cool. And you've subscribed the sponsors. This is a quiet time of day, LP was recently down, and there's about 15 other items in the queue right now, but it ought get hit sometime soon. [05:19] dpkg -l lists out a particular pkg as installed but if i check for the same pkg in /var/cache/apt/archives I cannot find that pkg.. how so [05:20] wrapster: There's no requirement that /var/cache/apt/archives includes any installed package. It starts out empty on a new install, for instance. [05:20] ok. [05:21] the relationship is even weaker [05:21] *apt* is a tool for downloading and installing packages [05:21] the cache has no correspondence to installed or uninstalled packages; its just things that apt has been asked to download, and hasn't deleted yet. [05:22] Oh right. I forgot that apt will happily cache stuff without installing it. [05:22] update-manager can be configured to download but not install security fixes, as an example o f that [05:23] or if you start an install and hit cancel after some things download they stay in the cache. [05:23] Right. [05:33] is it okay to insert line breaks in debian/control fields like Build-Depends? [05:34] yes, if continued properly; see policy for the format specification [05:49] an enum in a .h file that's included should be accessable in a function, right? [05:50] nm... [06:07] G'day — I've had a libvirt bug sitting around a while, and I have a debdiff attached. I was wondering how I could help move it forward, or get the ball rolling. [06:08] I've been told I need to get it into a sponsorship queue of some kind, but not sure how to go about it. [06:14] jayvee: What's the bug number? [06:14] persia: https://launchpad.net/bugs/528934 [06:14] Launchpad bug 528934 in libvirt "IPv6 shouldn’t be disabled by default in libvirt" [Wishlist,Confirmed] [06:16] My debdiff bumps the version number from ubuntu8 to ubuntu9. But 13 hours ago, an update to libvirt also bumped the version to ubuntu9. Would it be useful for me to re-do my debdiff with ubuntu10 instead, or is that not a problem? [06:16] I'm not sure why zul didn't just upload it Monday, really. [06:16] You could subscribe the ~ubuntu-main-sponsors team to add it to a list of stuff to get uploaded. [06:16] * persia will do that now [06:17] But I'd expect the server team to just upload it. [06:17] heh [06:17] Have you also submitted the bug to upstream? [06:17] Yep. [06:17] But obviously that won't get into Lucid in time. [06:17] upstream are a little insane though [06:17] Which is why I'm also submitting it here. [06:18] !sponsorship [06:18] !sponsor [06:18] Grr. [06:19] So https://wiki.ubuntu.com/SponsorshipProcess outlines the process. [06:19] This is likely to change soon as the ~ubuntu-main-sponsors and ~ubuntu-universe-sponsors teams are merged (ideally to make it simpler) [06:20] But unfortunately the main sponsors seem not to get to things quickly. [06:20] Since zul has an interest in this bug (based on his triaging it on Monday), you might ask him if it needs something else to be uploaded. [06:20] You might also check with the folk in #ubuntu-server as they tend to care for libvirt and friends. [06:21] okay [06:21] is pinging zul in here enough to grab his attention? [06:22] Not at this time of day (it's 1:22 there), but when he's awake yes. [06:22] But I'd really recommend trying the ping in #ubuntu-server, as more folk there have an interest in libvirt, so someone else might also grab it. [06:23] Do you think I should re-do the debdiff with the new version number, or is there not much point? [06:26] persia: oh cool, all I have to do to get it magically in the sponsorship queue is add it to ~ubuntu-{main,universe}-sponsors [06:26] now I get it [06:26] jayvee: I think it's a good idea to update the debdiff if it needs updating. In my view, when you submit a debdiff, you *are* an Ubuntu Developer, and should be submitting something that would create precisely what any developer would upload. [06:27] lol, http://qa.ubuntu.com/reports/sponsoring/ is serving utf-8 text with an iso-8859-1 content-type header [06:27] That said, if it's trivial, most sponsors will just fix it (but it's more work for the sponsor, and some folk are picky). [06:27] okay, I'll update it right now [06:27] jayvee: Please file a bug against the sponsoring overview :) [06:27] haha [06:27] Content-Type: text/html [06:28] https://bugs.launchpad.net/ubuntu-sponsoring/+filebug [06:28] actually they don't specify any encoding [06:28] Oh, then it's a bug in your browser that it doesn't default to UTF8 :p [06:29] every browser I know of out there defaults to iso-8859-1 [06:29] you can change it in the settings, but that only fixes it for one person [06:29] I do agree though — utf-8 should be the default everywhere. [06:29] jayvee: on ubuntu ff defaults to your locale [06:30] jayvee: and our locales default to utf8 [06:30] Which is how we solved the bug. Other environments may need other ways to solve it. [06:30] lifeless: I don't know any of the technicalities, but I would have to disagree based on past experience [06:30] For instance, in environments where the locales default to UCS-2, it makes sense to hack the browsers to default to UTF8, because almost nobody sends UCS-2 over the wire. [06:38] Well launchpad.net explicitly defines utf-8, and given that the page scrapes launchpad.net directly, it should do whatever launchpad.net does. ;) [06:40] The page should explicitly report it's charset anyway. There's two bugs: 1) the page not giving enough information to read it, and 2) the browser having non-ideal defaults. [06:40] It's not precisely scraping LP, but using the LP API to collect details. [06:40] * jayvee is testing the shiny new debdiff in pbuilder [06:54] well, shiny new debdiff attached to bug [06:54] Well, now comes the frustrating bit: waiting for someone to upload it. [06:55] yeah :( [06:55] Check with Zul in 9-10 hours in #ubuntu-server (or maybe something more like 18 if you're in a timezone that makes that more convenient) [06:57] well either I'll ping him at like [06:57] 2 AM [06:57] or when I get up tomorrow morning :) [06:58] That's about what I figured :) [07:01] well thanks for the pointers anyway [07:01] I learnt a lot just now. [07:01] persia++ [07:02] jayvee: Thanks for helping fix stuff, and stopping by to ask questions. The folk here and the folk in #ubuntu-server are both likely to be happy to help you with just about anything if you get stuck again. [07:03] hopefully one day when I get enough of these patches in, I can apply to become an ubuntu member === ttx_ is now known as ttx [07:29] I'm trying to make a *simple* script and it's failing because "$plugin" is empty inside the `for` loop (i.e. line #8) - could anyone see why? http://alkisg.pastebin.com/3q22Sxd8 [07:29] for plugin in file1 file2; do echo $plugin <== empty there :-/ [07:31] Ugh sorry I just saw it [07:31] I need to escape $ in \$plugin [07:31] hrm? [07:31] where? [07:32] What sort of script is this? shell? [07:33] persia: yeah it's a shell script, but nm, I found the solution, I needed to escape \$plugin [07:33] Silly me [07:33] Where? [07:33] I gave a pastebin link just above [07:33] Yes, I'm looking at it. [07:33] I'm just not seeing what you needed to escape, and hoping to learn. [07:33] Ah, well, the problem was this: [07:34] $plugin was evaluated while writing to >/tmp/script [07:34] So it was empty [07:34] I should escape it so that cat >/tmp/script < ..so that it gets evaluated later on, at sudo sh /tmp/script... [07:35] persia: if you run the script and then `cat /tmp/script`, you'll see what I mean... [07:40] Well apostrophes make it more readable than < alkisg: Heh. I understand now. I completely ignored that this was a here-file. Yes, you need to escape everything :) [07:40] Why are you doing this as a here file, rather than directly in the script? [07:40] persia: yup, it took me some minutes to see it, tricky... [07:41] persia: I want to put it in a web page for people to copy/paste it directly on the terminal, and sudo makes it tricky, as it kills the clipboard contents [07:41] So I need to put "sudo" at the end... [07:42] I'm generally against putting scripts on web pages. What problem are you trying to solve? [07:42] The new beta flash player finally allows for greek chars [07:42] So I need to provide for an easy way for teachers to upgrade it [07:43] "go to the adobe site, download the tar.gz, extract to /tmp, and run the script" [07:43] And this isn't better achieved by providing updated packages? [07:43] It's beta, so I'm not sure that the download location will stay there [07:43] Just make a custom flashplugin-installer that will be perceived as an upgrade that pulls the beta. [07:44] I.e. `wget http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_1_p3_linux_022310.tar.gz` will fail when they get the new beta out [07:44] Then update the package. [07:44] What package? [07:45] doesn't flashplugin-installer download it on the fly from the adobe site? [07:45] Yeah. [07:45] So, for betas this can't work, since the link isn't stable... [07:45] And anytime you want it to download from a different place, or use a different checksum, you have to update the pacakge. [07:45] Ugh, I wouldn't want to do that each day :D I really prefer to leave some instructions for them to follow :) [07:45] What I'm suggesting is that you make a special beta version to distribute temporarily, and when it comes out, encourage people to use the regular version (which would be updated in the archives). [07:46] I'd need to update the beta package every week or so [07:46] It shouldn't change every day. [07:46] E.g. the tar.gz above is "022310" - 10 days ago... [07:46] Yeah, that's why there's no flashplugin-beta-installer :) It's a lot of work. [07:47] Yup, so in this particular case, putting scripts on a web site is an acceptable way to do it for me :) [07:47] But if you move package-provided files around manually, you end up with a system that can't be reproduced from packages. You may also cause issues with upgrades. A security upgrade could break your updates, etc. [07:47] There are just too many things that can go wrong, and then you have to deal with annoyed users who followed your instrutions. [07:48] Sure, it's something temporary which I do hope to see resolved in Lucid (i.e. a non-beta 10.1 flash) [07:48] Well, OK. I just think it's 1) poor service for users and 2) encourages poor practices in users/ [07:48] good morning [07:51] persia: I completely understand what you're saying, it's just a matter of weighting available solutions & resources. Adobe offers a manual installation of 10.1 beta for now, and I don't have the time to package & keep packaging it, so the users will need to do it the adobe way. I can only give them some instructions on how to do it, I can't help them more.... sure, it's not good practice and it may break on updates, I'll warn them about that. Than [07:52] Folks, this bug is urgent and the fellow who I thought would do it hasn't responded: https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/529350 [07:52] Launchpad bug 529350 in tahoe-lafs "please upgrade Tahoe-LAFS in Lucid to v1.6.1 of Tahoe-LAFS" [Undecided,New] [07:52] OK. I just argue against what I consider poor practice when I see it. If you understand why I think it's poor practice, and are willing to accept the costs, then go ahead. [07:52] It is urgent because it is to upgrade a version of a package for Lucid [07:54] rockstar: Do you need a hand with that, or are you expecting to get to it soon? [07:58] zooko: you're the guy that helped me test Wesnoth for OLPC :-) [07:59] jayvee: :-) [07:59] Me and my son Irby. [07:59] zooko: I seem to remember you confirming that it was 100% bugfix, so it's not incredibly urgent. Let's see if rockstar can get to it (or at least tell us that he needs help) in the next day or two. [07:59] zooko: Just to confirm, rockstar *did* tell you to assign him, right? [08:00] persia: if i add the manpages to the Debian directory, i then need to put install 'instrucions' in the debian/rules folder? [08:01] duanedesign: debian/rules isn't a folder :) [08:02] duanedesign: And you probably want debian/db4.2-doc.manpages (read `man dh_installman`) [08:06] persia: ha ha. d'oh [08:12] persia: yes it is 100% bugfix. [08:13] Just to re-iterate, here is the NEWS file: http://allmydata.org/trac/tahoe-lafs/browser/NEWS [08:13] I *think* rockstar agreed to do it, but he didn't actually say "And please assign that launchpad ticket to me". :-) [08:13] zooko: Cool. That means we aren't under quite as much pressume (no freeze exception required). [08:14] Oh, assigning people when they didn't explicitly ask for assignment and you're not in charge of what they do (e.g. being their boss) is poor form. [08:15] Okay. [08:15] But that makes it mostly up for grabs. [08:15] jayvee: Feel like processing an update? [08:15] I'm familiar with a different work flow where assigning people to a ticket is more like a suggestion and them "accepting" the ticket is the committing thing. [08:15] But now I know. [08:15] We don't have any accept feature, so we double-load assignment. We use subscription for the suggestions. [08:16] No worries. [08:16] persia: what sort of update? [08:16] zooko's update? [08:17] Indeed. Apparently rockstar didn't actually commit to it, and so the assignment was based on different semantics than those we usually use. [08:18] so that would involve basically downloading the new source, moving debian/ across, and making sure it all compiles? [08:19] And updating debian/ if necessary, and adding a changelog entry describing what you've done, yes. [08:19] sure [08:19] I'll have a bash [08:19] Cool! [08:19] Thanks! [08:20] zooko: Please stick around and help jayvee with any tests, etc. to make sure that the update works properly in lucid. [08:20] I'm running karmic myself, but I can test in chroots, pbuilder-dist, etc. [08:20] I will try! However, I might fall asleep in my chair and if m head rests on the keyboard and sends a stream of characters, you'll know what happened. [08:21] zooko, what is the time there? [08:22] 0:21 [08:29] jayvee: if you need help or any questions answered about Tahoe-LAFS, please join the #tahoe-lafs channel. [08:29] I have to fall asleep now. [08:29] sure, no problem [08:30] zooko: There are people likely to be awake in that channel for more hours? [08:31] persia: not sure. [08:34] I want a newer package which is built in lucid, how can i make it depends on the package in lucid while i'm build karmic package? [08:34] rawang: Could you give a little more detail? [08:35] persia, sorry for confusing. I need at-spi >= 1.29, and it's in lucid, but it's 1.28 in karmic [08:36] but i need to build my package for karmic [08:36] rawang: Is the at-spi >= 1.29 a dependency or a build-dependency? [08:36] persia, i think both [08:37] rawang: Use a chroot environment like pbuilder or cowbuilder for that. [08:37] Rhonda, yes, but i want to publish it on PPA [08:37] So? :) [08:37] so i have to handle with the dependency :) [08:38] rawang: I guess you can backport at-spi too then [08:38] I still don't understand why a lucid chroot won't help you then? [08:38] rawang: Well, if it's a build-dependency, go read the upstream changelog carefully. It may not be possible to build against an earlier version. [08:38] Rhonda: backport targeting karmic [08:38] karmic only provides at-spi = 1.28, but at-spi 1.29 that i want is in lucid [08:38] persia: Ah, the "how can i make it depends on the package in lucid" confused me seriously. [08:39] Rhonda, i have to build against for karmic [08:39] rawang: Change that dependency in the source. If it's generated automatically it should get adjusted the same too. [08:39] If it's though in the source as hard depends there probably is a reason behind it. [08:39] So don't change it in the source if you don't know the impact. [08:40] ok, let me explain more clearly, [08:42] i want to build my package for karmic, so i have this "blah (blah) karmic; urgency-low" in changelog, and have dependency like "at-spi (>= 1.29.0)" in control file. but apparently, karmic don't have at-spi >=1.29, but it's in lucid repository. [08:43] karmic repository on ubuntu PPA don't have at-spi >=1.29, but it's in lucid repository. [08:43] rawang: Right. So you need to find out *why* it requires >= 1.29.0 of at-spi. [08:43] rawang: Then it's like I said, yes. Find out why it has >=1.29 in it and what would break if you lower that to 1.28 [08:43] persia, the package source code depends on the newer at-spi :) [08:43] And either patch the source to not need that, or first backport that. If at-spi >= 1.29 is not ABI compatible with at-spi << 1.29 then you have to also backport *all* at-spi rdepends. [08:44] Then you would need to backport at-spi too. [08:45] persia, Rhonda ahhhh, i see, i got your ideas [08:45] thanks :) [08:46] so karmic won't like to have a big number version increased, right? [08:46] it just want to its packages stable [08:47] rawang: Such a change will not happen in the 9.10 release. What you do in some third-party repository is up to you. [08:48] k, i understand :D [09:23] persia: well I reckon it's working [09:23] just attempting to get ubuntu-vm-builder to build a lucid VM for me to test in [09:23] jayvee: Cool! [09:23] zooko will be happy [09:24] uploaded it to my ppa for him to grab [09:25] jayvee: If you're confident it works, attach the diff.gz to the bug and subscribe the correct sponsors queue. [09:25] May as well just dunk it in lucid if it's in good shape and get wider testing. [09:25] persia: Just one question though: the original tarball used the wrong initial directory, allmydata-tahoe-1.6.1, instead of tahoe-lafs-1.6.1. Does that mean I also have to upload a new .orig.tar.gz? [09:26] And if so, is it okay to attach the .orig.tar.gz to the launchpad bug report? [09:27] the dir name in the orig tarball doesn't matter [09:28] directhex: that's good — how does that work? [09:28] --strip-components=1 [09:28] mkdir $package-$version && tar -xvf $orig --strip-components=1? [09:28] oops, insert a "cd $package-$version" in there [09:29] something like that. i don't look at dpkg-source guts [09:29] aha [09:29] just have to rename the tarball, I spose [09:29]