[00:13] Im patching a semi-broken security in svn. Anyone wants to give me a hand about the tools to quickly rebuild&test (hand holding ;) [00:26] LimCore, what do you mean by "quickly rebuild&test"? [00:26] LimCore, ccache would probably speed up rebuilding [00:27] well, I have very limited time, so I hoped I will do what I do well (fix this bug, assuming the code base is readable) and someone will help me build/test/and all other ubuntu specyfic stuff [00:30] upsteam uses variable names like "b". No, its not for index variable. Neat [06:05] hi [06:06] Looking for either the "Debian New Maintainers' Guide" or a different Debian package creation guide in a fully-downloadable format, eg; HTML [06:06] Could you please provide a link/command to one? [06:24] persia: ping === nenolod is now known as happinessturtle === happinessturtle is now known as nenolod [08:09] good morning [10:08] Hi MOTUs, I just filed a requestsync for usb-modeswitch (#519216), which needs sponsorship from you (if I understood it correctly). Could anyone take a look after it ? [10:14] OdyX: Acked [10:15] geser: great. Thanks. [10:28] Is there something like "bts" for launchpad? [10:29] Rhonda: Launchpad bugs in Launchpad? [10:29] i.e., a soap interface or commandline query client? [10:29] jpds: Yes. [10:29] There's an API for Launchpad. [10:30] Rhonda: https://help.launchpad.net/API [10:30] That sounds like there isn't a tool yet, right? [10:30] and there's https://launchpad.net/bughugger [10:38] jpds, dholbach: Thanks. :) [10:38] no worries [11:06] when using dpkg-buildpackage is there a way to restart it from a specific step? (there was an error in my make install) [11:07] dpkg-buildpackage -b -nc [11:08] Note that this doesn't always behave entirely as expected, depending on the names of various files and various rules. [11:08] hmm, ok [11:15] i'm guessing i also need -rfakeroot too if my original build was using it right? (this package takes about 5 hours to build so i really don't want to end up starting all over) [11:17] guess i can just make a backup copy and give it a try [11:18] phek: Aside from the -nc, you'll want to use all the same options. [11:18] -nc just doesn't run debian/rules clean [11:19] ok cool. thanks [11:28] now i'm getting an architecture error (now that i'm doing -b -nc which seems strange). dpkg-gencontrol: error: current host architecture 'powerpc' does not appear in package's architecture list (cell) [11:29] cell? [11:30] well, i use -mtune=cell -mcpu=cell during the configure (this is on a ps3) [11:31] that wouldn't make dpkg to think you're trying to build for cell [11:31] pastebin your debian/control [11:31] k [11:32] phek: and the output of "dpkg-architecture" [11:33] https://www.securepaste.com/decrypt_data.php?id=5e2r597m&password=2Y81h [11:33] thats the control and i just noticed that cell is the architecture: [11:34] that'd be it [11:34] https://www.securepaste.com/decrypt_data.php?id=79wcD&password=2Y81h [11:34] OK, i guess as long as i can keep the optimizations it's fine to change it [11:35] is this a new package? [11:35] change it to what? [11:35] yeah [11:35] change the control Architecture line to powerpc [11:35] does it compile on amd64? [11:36] the software does, but with the optimizations it would probably crash [11:36] (using the cell optimizations) [11:36] which i guess is obvious [11:37] eh, you're putting the optimizations into debian/rules? [11:37] yeah [11:38] using a if statement to check for powerpc I hope? [11:38] hi [11:38] nope. probably would have been a good idea [11:39] yes [11:39] then the package wouldn't be powerpc-specific and you can set Architecture: to any, as it should be [11:39] i need help to create a debian package for hunspell-ta , i'm having the dictionary file and aff file [11:39] hi all, i am packaging a software for debian, i have already uploaded to mentors-debian.net ... & i'm waiting for a mentor to handle, but i would like to make the .deb package available for ubuntu too ..... i've totally followed the debian policy ... what must i do now for ubuntu ? [11:39] phek: ooi, does -mcpu=cell make that much difference? [11:40] sistpoty|work, yeah. well either that or the -O2 does. but full screen with that package and no optimizations is almost unusable [11:40] meanwhile, i would like to create a wiki in ubuntu website where i could give instructions about installing that software [11:40] sistpoty|work, but with the optimizatioins its usuable [11:41] the regular package should use -O2 already [11:41] here is the soft -> http://code.google.com/p/ps3mediaserver/ [11:41] phek: interesting. wouldn't have thought that [11:42] azeem_, there's no regular package for this. the 1.51 version couldn't do full screen at all due to some file permissions thing. [11:42] sistpoty|work: well, if it's an emulator, it might take advantage of advanced platform features [11:42] (there's a package for 1.51) [11:42] phek: then I suggest you test yourself with and without the -mcpu=cell and see whether that's it [11:43] azeem_: afaict cell is a ppc + 8 spu's (good at floating point, but extremely hard to program), so I didn't expect that gcc could automatically optimize the code to make use of the spus... [11:43] yeah, i may do that. like i said it takes 5 hours to install (at least) so it's not something i can just spend 10 minutes testing [11:44] sistpoty|work: it might just turn on altivec [11:44] as opposed to the regular GCC -O2 [11:44] azeem_: ah, right. had totally forgotten about altivec, thanks [11:44] phek: to *install* [11:44] ? [11:45] err i mean build [11:45] ok [11:46] Hi, I updated the bug report asking for sync of poker-network in lucid, because a new version was recently uploaded to debian [11:46] https://bugs.edge.launchpad.net/ubuntu/+source/poker-network/+bug/509677 [11:46] Ubuntu bug 509677 in poker-network "Please sync poker-network 1.7.7-1 from unstable to lucid" [Undecided,New] [11:47] let me know if it needs more informations [11:48] slytherin: hi, did you have a chance to try that ppc build? [11:49] Laney: No. I couldn't get online yesterday due to some problem on ISP side. Iwill try today if you want. [11:50] if you get some free time, please [11:50] sure [11:51] Laney: Can you please send a link of the .dsc file to my email address? I do not have yesterday's logs. https://edge.launchpad.net/~onkarshinde [11:51] sure, here goes [11:52] got to go now. Going home. [11:52] there you go [11:52] see you later [11:53] Laney: ~o¨ [11:53] * Laney pounces on sebner [11:53] * sebner hides [12:00] well, guess i one of those unexpected behaviors from using -b -nc [12:25] Laney: I've addressed your comments on sqlite3-pcre, would you be able to take another look at it when you get a chance please? [12:27] oojah: You'll end up with a much better package if you get lots of different reviewers, rather than chasing people who reviewed it before. [12:31] persia: do MOTU applications via DMB require announcing on developer-membership-board@l.u.c [12:31] ? [12:31] persia: I'm sure you're right. [12:32] * hyperair is still wondering when exactly the next DMB meeting is [12:32] hyperair: No. I'm not sure precisely how it does work, but https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess is likely your best guideline. [12:32] Next Tuesday. [12:32] hmm tuesday [12:32] At 14:00 UTC, so late for you. [12:33] 2200 my time. [12:33] perfect. [12:33] i'm spending most of the day in a bus [12:33] persia: not 15 UTC? [12:34] my chinese new year break ends on tuesday so i have to scramble back across the country to campus [12:35] geser: Oh, right. 15 UTC. [12:37] 2300 local time. still great =D [12:37] * hyperair is nocturnal anyway [12:41] oojah: A get-orig-source target which reconstructs the .orig.tar.gz from upstream's git repo would be nice [12:41] (but not essential) [12:41] I can look maybe later if you don't find anyone else [12:42] * oojah nods [12:42] I'll look into that and repost later, thanks. [14:18] How can I find out the package version that is currently being built for a get-orig-source rule? [14:25] oojah: You can't usefully. The semantics of get-orig-source are such that it always gets the *newest* available version. Depending on how usptream releases, you may be able to use hints from tarball names, VCS tags, or similar. [14:25] But, except in the case of tarball names, it may be tricky to determine the version that will be pulled in advance of pulling it. [14:26] (with tarballs, uscan does an admirable job) [14:26] Hi, I have a new package that was just uploaded to sid a few minutes back. I just wanted to know, is the Import Freeze day after for sid or testing? (There seem to be conflicting information on the wiki). [14:27] Also, if it is for testing, then does the package wait for 10.10? [14:27] umang: It's usually for sid, but we're doing testing this cycle. [14:28] persia: So I'll have to wait for the 10.10 freeze before filing a bug? [14:28] For an upload today, it would probably wait for 10.10, but if you *know* it works in current lucid after being recompiled, you can request a sync directly from unstable. [14:28] No, it would be automatically pulled when the 10.10 archive opened. [14:28] I know it works on Karmic [14:28] You only need a bug if you want it before that. [14:28] Yeah, but it needs to be known to work in lucid to be included in lucid :) [14:29] You may find that a VM or chroot can help test that. [14:29] persia: I can do that, but by when would I have to file a bug? [14:29] I mean it has just been uploaded, not even accepted by the ftp. [14:30] You'd have to file the bug after it gets through Debian NEW, and before FeatureFreeze. [14:30] It's potentially possible to do after FeatureFreeze, but that requires a Freeze Exception, which is a much higher bar. [14:30] OK. I hope I get some time in between. :) [14:31] It's just a day I think. [14:31] persia: Ah, ok. I was thinking about it the wrong way round. So for a git repo I should pull the code and create a tarball based on the version there and it's at that point that the new changelog entry would be created? [14:32] persia: So a needs-packaging, right? [14:32] oojah: Well, there's not usually that much automation. Someone updating the package would usually run debian/rules get-orig-source to generate a new tarball, and then dch -i separately to add a new changelog entry, manually setting the version in the changelog. [14:33] umang: If you've uploaded it to Debian, surely it's already packaged :) You'd file a sync bug. [14:33] Oh yes. :P [14:33] "Please sync from debian " where " [14:33] Right? [14:34] I mean, "Please sync from debian " [14:34] Hello, I am preparing a package for a library , some symbols are not hidden although they are not in the official API, the question is, should I remove those symbols from debian/libname.symbols file ? [14:34] Something like that. Most people use requestsync. I recommend searching for one in the ~ubuntu-archive subscription list, and following that sort of pattern. [14:36] AnAnt: All the symbols file does is help set appropriate dependencies and help you notice when the ABI changes. If you think these symbols don't matter, then you can hide them. If you think they will be used, even if undocumented, you may want to include them. Be careful that no symbols are exposed that properly belong to other libraries. [14:36] thanks [14:37] persia: Yes, that's what I meant - no automation of dch -i. [14:40] persia: well, thing is that they were supposed to be hidden in previous releases, yet some packages used a few of those symbols, so upstream kept them (but is considering hiding them) to keep API [14:41] In that case, there are users, and they *should* be shown in the symbols file. If they are hidden, that's an API change, and you will benefit from dpkg-gensymbols telling you so. [14:41] persia: Thanks. I will use that tool if it clears new before the 11th. [14:41] are unmodified packages still automatically synced from Debian testing ? [14:42] c_korn: Until DIF *) [14:44] persia: ah, it is the LTSDIF on the 11th, right ? https://wiki.ubuntu.com/LucidReleaseSchedule [14:44] Indeed. [14:44] persia: but those users used symbols that they weren't supposed to use [14:45] persia: ie. it is not actually an API change [14:45] well, then I have not much time to get scilab in :) thanks persia [14:45] AnAnt: It's not supposed to be an API change, but it *is* an API change. The offending applications need to be patched, and so it needs to have a new soname, to break the dependency. [14:48] persia: or patch to offending apps? [14:49] persia: especially that they are a few [14:51] AnAnt: Well, you *could* patch all the offending applications for which you can get the source, but you can't do it for stuff you can't see. [14:52] So you might see bug reports if you don't adjust SONAME when the API changes. [14:52] persia: upstream of the lib doesn't want to bump SONAME [14:52] Then keep the symbols public. [14:52] persia: especially that the problem I mentioned is very a very few apps [14:53] I argue that it's not possible to know how many applications are affected, because it's not possible to determine what all users are doing in their local environments. [14:53] It's more responsible to just leave those included in the undocumented but official API until there's some other reason to bump the SONAME, and drop them then. [14:59] AnAnt: is the package already in the repos? if not, and if upstream seems to plan to hide those symbols, maybe you should do this too (not in the symbol files, but rather by unexporting them e.g. via __attribute__((__hidden__))) === andreas__ is now known as ahasenack === asac_ is now known as asac [15:52] I've got a package that is near inclusion into fedora, but I can't seem to get anyone to review it for ubuntu [15:52] I've got it uploaded into revu and a launchpad bug opened for packaging [15:53] what can I do to get it reviewed? [15:53] the package is rinputd [15:55] cnd: are you Chase Douglas? [15:55] EagleScreen, yep [15:56] why has you package a -4 debian revision? === Tonio__ is now known as Tonio_ [15:56] I don't know specifics of how packages versions SHOULD work, but my idea is that the 1.0.2 is the version of the source code [15:57] whereas the -4 is the 5th version of the packaging [15:58] cnd: If it hasn't already reached ubuntu, then you should stick to -1. That's what I was told on Debian. [15:58] I can certainly change the version to fit ubuntu standards [15:58] cnd: if you package for Ubuntu a package which is not still in Debian, you cannot set a debian reviison grather than zero [15:58] EagleScreen: cnd, Yes that true. (So I was wrong) [15:59] cnd: upstream version is 1.0.2 [15:59] cnd: Also, why is your package native? [15:59] EagleScreen, ok, so the revision should just be rinputd_1.0.2 [15:59] the first Debian revision would be 1.0.2-1 [15:59] second 1.0.2-2 [15:59] umang, because I originally developed it in bzr and used bzr builddeb to build packages [16:00] I can repackage it as a non-native, but I'm upstream so its easier if I could leave it that way [16:00] cnd: Ah. But I don't think you should do that unless the package is irrelavant outside Debian/Ubuntu [16:00] e.g. Lintian [16:00] umang, why not? [16:01] when I ship the source tarball, I filter out the debian directory [16:01] cnd: if this package is not still in Debian and you package it for Ubuntu, you has to version it like this: 1.0.2-0ubuntu1 -> 1.0.2-0ubuntu2 etc.. [16:01] Just a sec, I'll find the documentation [16:01] EagleScreen, so if I resubmit as 1.0.2-0ubuntu1 then I should be good on the versioning front? [16:01] yes [16:01] /sponsoring could interface with LP to provide a list of packages-you-can-sponsor [16:02] cnd: please merge all your entries in the ubuntu chagelog (debian/changelog) in just one [16:02] and verison it 1.0.2-0ubuntu1 === yofel_ is now known as yofel [16:03] EagleScreen, every single entry in the changelog? [16:03] or just since 1.0.2? [16:03] cnd: For now, you can see this, I'll find a doc that says it more specifically (I'm sure there was one): http://www.debian.org/doc/manuals/maint-guide/ch-update.en.html#fr5 [16:04] section 9.4 [16:04] ok, I'll just make a separate non-native package then [16:04] since 1.0.2 [16:05] but upstream version always must be continued by an ubuntu revision [16:05] never submit an entrie with just 1.0.2 [16:05] ok [16:05] do the same for previous versions [16:06] cnd: have you packaged it using a Debian system? [16:06] I currently do my packaging using bzr builddeb [16:06] and upload to my ppa [16:07] ok [16:07] I'll probably continue to do that for development [16:07] and have a separate tree for the debian/ files for a non-native package submitted for inclusion into ubuntu [16:07] cnd: found it http://people.debian.org/~mpalmer/debian-mentors_FAQ.html [16:07] You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native. [16:08] thanks umang [16:08] ^ quoted from the debian-mentors faq [16:08] cnd: Welcome [16:08] :) [16:09] cnd: you should ideally include your package in Debian, with a debian revision 1.0.2-1 -> 1.0.2-2 etc.. then it will be automatically synchronized from Debian to Ubuntu [16:09] EagleScreen, I will look into that [16:10] where is the process documented for inclusion into debian? [16:10] also, is it ok if I'm listed as the maintainer in the control file [16:10] since I have an @ubuntu.com address [16:10] cnd: Some people in Debian grumble, but if you're a good maintainer, nobody seems to mind that much. [16:11] ok [16:11] cnd: all ok you are the maintainer [16:11] cnd: visit and read http://mentors.debian.net/cgi-bin/welcome [16:12] EagleScreen, thanks [16:12] you have to make a good quality package, upload it to debian.mentors repository as if it were a PPA, and then look for a sponsor in #debian-mentors [16:13] ok [16:13] Sorry, I'm curious to know, what does the @ubuntu.com change at debian? [16:14] nothing [16:14] umang: Just some people in Debian are sore because Ubuntu is a derivative. [16:15] Most people in Debian aren't, but it's worth noting in case one bumps into someone particularly opinionated. [16:15] cnd: #debian-mentors channel is in server irc.debian.org [16:15] giving back (by maintaining a package there) should make them less sore really [16:15] But ubuntu encourages upstream contribution to debian instead of only to ubuntu [16:15] cnd: update standars version to 3.8.4 [16:16] will do [16:16] I guess I've met only the most people. :) debian-mentors and debian-python have been pretty friendly to me (newbie + ubuntu user) [16:16] umang: That's been my experience as well, although I hear stories, so like to caution people just in case. [16:17] dholbach, ping [16:17] rockstar: pong [16:18] Oh yes. I have a related question. If you bump the standards, Lintian fussed about 3.8.4, because Karmic doesn't have the version in sid. So do we have to manually build the lintian source package from sid and then install onto the karmic installation, or do you always run lintian under a chroot? [16:18] hyperair: You were asking about procedures to apply to MOTU earlier. A decision has been reached, and the wiki is now up-to-date (I believe). [16:18] dholbach, can you take a look at https://bugs.edge.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/516744 [16:18] Ubuntu bug 516744 in tahoe-lafs "please upgrade Tahoe-LAFS to v1.6" [Undecided,New] [16:18] persia: cool [16:19] !motu [16:19] motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See http://wiki.ubuntu.com/MOTU [16:19] umang: I tend to run lintian in the target environment. Whether you choose to use a chroot, a full install, a VM, etc. depends on your available hardware and preferred workflow. [16:20] rockstar: will do in a sec [16:20] persia: OK. But for convenience, is it likely to break something if I downloaded the lintian source package and built it myself? [16:20] (or karmic) [16:20] rockstar: usually attaching a .diff.gz should be enough and have a look at https://wiki.ubuntu.com/SponsorshipProcess [16:20] *on karmic [16:20] dholbach, great. I thought I'd bug you since it was you specifically I talked to about getting started in packaging. Eventually I'll find someone else to harass about getting my into Ubuntu. [16:20] rockstar: will review now [16:21] dholbach, okay, great. [16:21] yeehaw [16:21] umang: No. lintian is frequently backported. But there are differences in lintian between Ubuntu and Debian. It's worth pulling the right one. [16:21] umang: just isntall the lintian in Debian sid [16:21] Mind you, ubuntu-policy doesn't get updated as much as it might, so oddly Ubuntu lintian supports a policy version in excess of that documented. [16:22] EagleScreen: How, you mean download a binary? [16:22] yes, use the Debian package in sid [16:23] persia: Karmic is still at 2.2.17, if I'm going to submit to debian, I'd like 2.3.3 [16:23] http://packages.debian.org/sid/lintian [16:23] EagleScreen: Thanks. :) [16:23] umang: Right, but my point is that if you're submitting to Debian, you want *Debian's* lintian, rather than Ubuntu's. [16:24] The changes are relatively minor, but sometimes surprising. [16:24] persia: The part I'm confused about is how. Build the source package or run in chroot? [16:24] Or download binary [16:24] from sid [16:25] I think you'd do best to either run in a chroot or build a cross-port binary given those choices. [16:25] persia: Thanks. [16:25] :) [16:25] But you could also run it in a VM or on hardware, if you have those available. Whatever works best for you is best. [16:26] persia: I'm not experienced enough to run sid like that. :P I'll stick to chroot. :) [16:26] for standars 3.8.4 you need lintian 2.3.3 [16:26] it is in sid [16:26] EagleScreen, umang: Please notice that 2.3.2 on that sid page is outdated, 2.3.3 is current. packages.debian.org still seems to not have recovered from its harddisk issues. [16:27] * Rhonda . o O ( see output of "rmadison lintian" ) [16:27] yes it is outdated [16:27] Or, rather `rmadison -u debian lintian` when running on karmic :) [16:27] Yes. I have actually been checking it on a chroot, I just wanted to know what's best. :) [16:27] umang: chroot is fine, if it works for you. [16:27] persia: Oh, makes sense that ubuntu patched devscripts to use -u ubuntu by default. Should have thought of that. :) [16:28] Thanks all. :) Going to get some sleep now. Good Night. [16:28] Rhonda: That was why I had the "nifty ..." comment a couple days back: I thought the entirety of -u was an Ubuntu patch. [16:28] if you only package for Ubuntu you can use standars 3.8.3 [16:28] * persia should probably use the Debian system for more than a NAS more often [16:28] persia: No, there is also -u bpo :) [16:29] For backports.rog [16:29] org [16:29] Right. madison.cgi in Soyuz includes backports by default (but unfortunately only includes 2 architectures for binary results) === micahg1 is now known as micahg [16:29] (or at least I *think* it's Soyuz) [16:30] EagleScreen: One can also use standards 3.8.3 for Debian, there is nothing really wrong with doing so. The changes aren't relevant for most parts, and it's technically the same, most of the times. [16:30] most packages, that is. [16:30] yes [16:31] ofcourse, but some uploaders take care about 3.8.4 [16:33] hey [16:33] the newer linux kernels come with tools, specifically "perf" [16:33] i can't seem to find a package containing it [16:34] what's the opinion on how to package that? [16:34] corecode: You might want to ask in #ubuntu-kernel : that team has more experience in that area. [16:35] thanks [16:35] (assuming it's part of the kernel distribution, rather than just being some other tool distributed from kernel.org) [16:35] so many different chans [16:35] Lots of different teams :) [16:36] MOTU: Signposts into Ubuntu development [16:37] Laney: Well, #ubuntu-devel is probably better for that, but most of us end up working with several teams, just in the nature of what we do :) [16:37] persia: Indeed. Just that recent discussions have me considering how the future looks... [16:38] With today's TB decision, I think there is now a clear path forward. [16:38] Laney: ultra uploader everywhere [16:38] MOTU may be less broad than it was, and more QA focused, but at least we know it has a future, and how that works. [16:40] * Laney ITA: sebner [16:48] Laney: hm? [16:49] never mind :) [16:52] Laney: I just wanted to point out that there is a new developer position, comparable to core-dev, with upload rights nearly everywhere [16:59] sebner: Hrm? What sort of developer? [17:00] persia: I forgot the correct spelling -.- [17:01] sebner: I just reedited UbuntuDevelopers, and I'm fairly sure we only have six types, which doesn't include anything like that. [17:01] are most package sets restricted? [17:01] None so far. [17:01] persia: really? I've heard about that kind of thing. Let me check [17:02] sebner: Please. I'd like that everyone had a single shared understanding about these things :) [17:02] well... [17:02] https://wiki.ubuntu.com/ArchiveReorganisation/Permissions#Resolving%20upload%20permissions the second bullet here [17:03] That probably needs revision now that MOTU exists. [17:03] But it basically just says that people can upload to the stuff to which they have permisison to upload, except from the packages' perspective. [17:03] persia: ah, it was "generalist developer" [17:04] so "generalist" is like core-dev, right [17:04] Laney: aye [17:04] Laney: like core-dev, upload rights everywhere except special stuff like kernel ,.. [17:04] and "MOTU" is P(generalist) \ U (packages in sets) [17:05] heh [17:05] Laney: At the time that document was written, it included an understanding the "MOTU" and "core-dev" would both be replaced by "Generalist". I do not believe this is still the case. [17:05] A proposal for a definition of MOTU under ArchiveReorg has been submitted and approved. [17:06] The definition of "core-dev" is still a bit unclear, but I suspect it will end up being close to the "Generalist Developer" of the prior documentation. [17:06] Good, that's how I understand it [17:06] so I don't think it really affects current permissions that much [17:06] Where I'm less certain is whether "core-dev" will have access to restricted sets, or whether some other group will be created that has access to everything, or whether core-dev will have access limited only by restricted package sets. [17:07] No. For us (MOTU), the next big permissions change is when we move from being able to upload to the universe component to only being able to upload to packages that don't belong to package sets. [17:07] Which means we can't upload to as much stuff, but also means we don't have to feel responsible for as much stuff. [17:08] Those of us who have interests in packages belonging to package sets would likely be welcomed as members of the teams responsible for those package sets. [17:08] persia: I'm wondering if a MOTU can join freely or also has to make some applications as non-MOTU folks [17:09] sebner: I personally consider membership in MOTU entirely separate from membership in any other development team. I don't see any conflict in belonging to several of them, nor any dependencies between them. [17:10] Until today, I considered MOTU just another delegated team, but the TB has determined that MOTU is a bit special for now. [17:10] persia: Is there a link where I can read about that? [17:10] persia: yeah, I just thought about the technical skill question [17:11] Well, being the "default" uploaders to the distribution does put MOTU in a bit of a special position AFAICS [17:11] oojah: About which? [17:11] Laney: Indeed. I don't argue with the TB decision, it just is different than my previous opinion :) [17:11] The TB stuff. [17:12] the minutes just went out to u-d-a [17:12] Ok [17:12] and the logs in the usual place... [17:12] !logs [17:12] Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/ [17:16] \sh, thanks for the rootstock fix, why wasnt there a bug [17:19] what's the TB decision? [17:21] corecode: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000673.html [17:25] what is the solution for sync, if package's name has been changed? [17:26] hi #ubuntu-motu. I'm trying to upload my first package to REVU, and am dubious of the dput documentation. am I really only uploading the source.changes file? [17:26] nope [17:26] have a look at the contents of the changes file [17:26] kreuter: dput will pull the rest from the same directory [17:27] i think... [17:27] there is a Files: section [17:27] it all it makes it there [17:27] but the only command I need to execute is "dput revu _source.changes"? [17:27] yes maco2 and kreuter, only the .changes [17:27] great. thanks! [17:27] kreuter: right [17:27] that's all you need to type, but it's not all you are really uploading [17:28] ok. I guess I expected something more involved. [17:28] EagleScreen: well now im wondering about teh insides of dput. i know i only need to tell it the .changes, but i think the way it works is it then looks for the rest of the files in the same directory, and grabs those too, right? [17:28] I just said [17:28] maco2: I'd read what Laney said. [17:28] yes maco2 [17:29] that's why you pass -sa or -sd to dpkg-buildpackage. [17:29] Laney: could you take a look @ http://packages.debian.org/changelogs/pool/non-free/f/frobtads/frobtads_0.13-2/changelog [17:29] and how we can sync it [17:29] -sa is needed when a new upstream tarball is used [17:29] ari-tczew: The common way is to request inclusion of the new package and removal of the old package. [17:30] Most of the time the old package is removed in Debian already, but I've ended up filing a few removal requests there when that didn't happen. [17:30] -sa is needed when you need to have the .orig.tar.gz included in the changesfile and it isn't by default [17:30] most commonly when uploading a merge which contains a new upstream version [17:30] persia: how are you think, can be done this before FFe? [17:30] ari-tczew: do it now [17:31] ari-tczew: Quite possibly. I handled a new-package-addition and removal last week. Dunno why someone couldn't do it this week. [17:31] what's the proper short for for replaces/provides/conflicts if any? [17:31]