[00:02] then again, i'm pretty sure mono bootstraps from binaries [00:03] hm, perhaps not [00:15] YokoZar: why does wine depend on winbind? [00:17] is the current winbind a version that JustWorks(tm) and gives nice shiny zero-config name resolution when in the same samba workgroup as other people, or one of the delightful versions that barfs in epic style if you're not in an active directory domain? i've lost track === asac_ is now known as asac === Kopfgeldjaeger is now known as Kopfi|offline [01:02] azeem, okay, it seems you were right on how to do it in debian. with any luck the same applies for ubuntu [01:15] directhex: In Debian binary uploads are required. In Ubuntu it's source uploads that are required. I suspect that's relevant to any bootstrapping problem. [01:16] ScottK, i'm more confused than i was before i started :/ [01:18] In Debian you can effectively bootstrap something that's arch all yourself by doing a binary upload. In Ubuntu you need a buildd admin to do it because we only upload source packages. [01:18] Not sure if that helps or not. [01:18] the source package should b-d on itself? [01:27] directhex: I _seem_ to recal a double-upload scenario; one uploads a source package containing the binaries required to bootstrap, then uploads another source package with a b-d on the archive package. I could be mis-remembering, though. === ember_ is now known as ember [01:46] RAOF, it seems a single line change is enough to make this package use the system vbnc instead of the bootstrapping one [01:46] night. [01:49] directhex: That sounds convenient. [01:50] okay, next question. if the build system requires modification in order to not use files removed during get-orig-source, is it appropriate to put appropriate modifications to the source package in get-orig-source to make the package "clean", or should the orig.tar.gz contain a broken build system which is later fixed in debian/rules (e.g. with dpatch)? [01:52] emgent: WRT your libavg merge, isn't the new ffmpeg already uploaded? === superm1|away is now known as superm1 [03:43] hello everyone [03:52] Hello tbielawa [06:04] good morning [06:06] hi daniel :) [06:06] hiya stefanlsd :) [06:07] https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/259453 - i built the new pidgin :) [06:07] Launchpad bug 259453 in pidgin "Please upgrade to pidgin 2.5.0" [Wishlist,In progress] [06:09] * orly_owl is not impressed with the rift in the Pidgin community. [06:10] orly_owl: There's a rift? [06:10] With empathy i assume [06:10] Or was a rift. I don't know. [06:10] Tge textbox size issue. [06:10] *The [06:11] http://tech.slashdot.org/article.pl?sid=08/04/30/1822237&from=rss [06:14] orly_owl: Oh, you mean Pidgin vs funpidgin? Heh. [06:14] orly_owl: There are similar debates for every project, with more or less press. Essentially, it comes down to "sensible defaults" or "allow users to change everything". Each project has it's own opinion about how this debate should be resolved, but there's no clear right answer. [06:15] persia: I thought the right answer was whatever I came up with? ;-) [06:15] That's a lie. My answer is always the clearly right answer! [06:15] RAOF: no *mine* is! [06:16] * persia determines that the point has been made, and wanders off to do something else [06:18] hehe [06:19] I only care because I might recommend pidgin to someone. [06:19] orly_owl: and why would that stop you? [06:20] * jdong logs in via iPhone just to join what seems to be a pidgin war [06:20] Well, I guess it doesn't really. [06:21] It seems they will still be developing Pidgin. [06:22] Of course; it wasn't a *developer* split. [06:22] No, thankfully. [06:23] Except that some potential contributors went and forked funpidgeon. For however long that lasts. [06:23] well I don't think it negatively affects pidgin anyway [06:23] it's a healthy part of the FOSS development cycle [06:23] (pardon -ECONTEXT, iPhone scrollback reading demands more patience than present at 1AM) [06:30] dholbach: good morning [06:31] dholbach: spanish getting started video has a lot of viewers [06:32] yeah, you're popular :) [06:32] today i saw another spanish portal publishing the video [06:33] http://www.vivalinux.com.ar/articulos/video-ubuntu-master-of-the-universe.html [06:33] :D [06:34] it seems that a lot of portals are making echo to the video [06:35] :-) [06:36] If a MOTU has some time. I'd appreciate a REVU on http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber [06:42] time to sleep [06:42] read you later! [06:43] Good morning. === superm1 is now known as superm1|away === Hobbsee` is now known as Hobbsee [07:56] <\sh> dholbach: this harvest thing looks cool...but regarding the patch series for certain packages, e.g. from fedora, without the explicit documentation what they patched and why those links don't make much sense, don't you think? can you link somehow to the VCS of their spec files (for rpm distros??) ,-) [08:07] \sh: if you click on such a link you will see the commit message which is probably as much as you'll get [08:13] <\sh> dholbach: well, the real description e.g. for patches in rpm distros is inside the .spec file...a commit message like "build against 3 layer OOo [08:14] <\sh> " doesn't bring you anymore clue about what the patch actually is doing.. [08:15] \sh: most commit messages had quite a good description themselves, but I can see what I find [08:15] <\sh> while "and adjust for OOo3 3 layer packaging" gives you more clue about what they did..the link is just one more "print" away ,-) [08:16] <\sh> dholbach: for fedora, the .spec file is named ".spec" and can be viewed via cvs.fedora... in the root tree of the source package (means, just remove the .patch file location and add a .spec cvsview link) [08:17] \sh: can you file a harvest-data bug for that? [08:17] <\sh> dholbach: can do that :) [08:17] gracias [08:21] <\sh> dholbach: bug #259655 [08:21] Launchpad bug 259655 in harvest-data "please add a link to the .spec file (e.g. for fedora patches)" [Undecided,New] https://launchpad.net/bugs/259655 [08:21] gracias [08:33] so who's going to run a session at Ubuntu Developer Week? jcastro, bobbo, norsetto, james_w and I are going to :) [08:35] * didrocks is eager to attend to those sessions ;) [08:36] even if there is no session from soyuz team, what pity :/ [08:37] didrocks: I'm pestering them already :) [08:37] I'd like to announce UDW next week [08:37] so it'd be nice if we filled some slots soon :) [08:37] who volunteers? [08:37] dholbach: I'm sure you had :) [08:40] * ajmitch looks for someone to volunteer [08:41] dholbach, me too, together with sbeattie [08:41] DktrKranz: nice... pick a slot before your preferred time is taken! what are you guys interested in talking about? [08:41] DktrKranz: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep [08:42] dholbach, SRU verification and related stuff [08:42] nice one [08:43] we have so many questions about our processes from newcomers, so I appreciate you guys taking the time to talk about that one [08:43] I already hosted one for SRU process last time, this one we'll finish the process and try to coinvolge people in stable release QA [08:43] * dholbach hugs DktrKranz [08:44] * DktrKranz hugs dholbach back [08:44] so... who else will run a session? :) [08:47] mmh, pretty like http://tinyurl.com/5j5ldn :) [08:49] I think that Daniel have really to make a shortcut to paste this question at different time of the day :) [08:50] ... or to implement a ircbot which does the job [08:50] wakeupMOTU!bot [08:51] not a bad idea, with a big header on harvest... [08:52] hang on, I'll try a new tactic now... [08:52] didrocks: why don't YOU give a session at UDW? [08:52] didrocks: you could give one about "make your sponsors happy - things to bear in mind when writing patches" [08:52] or something [08:52] didrocks: you could even give it together with somebody else [08:53] Iulian for example :) [08:53] . o O { I know Iulian is awake right now } [08:53] multiple u-u-s queues, divided by alphabetical order of the contributor [08:55] didrocks and Iulian are so quiet now :-) [08:56] dholbach, do not wake up s_ebner or n_handler :) [08:56] ok nevermind... I was kidding (it's still a good idea though) - don't feel obliged to [08:58] dholbach: sorry I was away :) [09:00] didrocks: so... like the idea? [09:00] dholbach: the issue is that I am (momentanly, I hope), not in a company that really bother with opensource and presently, I am not officially on IRC :) [09:01] So, the session can be cut off for an unexpected meeting [09:02] oh, I didn't see the timetable [09:02] it can be ok so at 18.00 UTC [09:02] let me think about a session I can give [09:02] * dholbach hugs didrocks [09:03] didrocks: be sure to ask a few others, maybe you can deliver a session together [09:03] that'd be awesome :) [09:03] I will get warp10 into it :) (mentor/mentee ;)) [09:03] rock! :) [09:03] or huats ^^ [09:03] good thinking [09:04] dholbach: I was planning a MOTU school session about QA with LaserJock. We could move it into the UDW, probably [09:05] warp10: that'd be nice - just decide on a topic and grab a slot soon :) [09:05] didrocks: nice, let's work on it ;) [09:05] yoohoo! [09:05] I knew I could count on you guys :) [09:05] * dholbach continues pestering the Soyuz folks [09:05] hum, caught :) [09:05] dholbach: you really have to now ;) [09:06] * dholbach doubles his efforts [09:06] dholbach: my only problem is that I am not sure I will be here during UDW (vacation). I'll probably know something more precise within a few days [09:06] thanks warp10 [09:06] didrocks: heh! :) [09:07] warp10: \o/ [09:07] * DktrKranz clones dholbach, it is perfectly legal in FLOSS development [09:07] * warp10 is happy to see both of his mentee delivering a session at UDW :) [09:08] bah... nautilus refuses to start today :/ [09:09] and gedit too [09:12] dholbach: what kind of sessions are planned? [09:12] slytherin: this is the preliminary schedule: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep [09:13] * didrocks is working hard so that huats gets involved into it :) [09:15] morning everyone [09:15] hey dholbach [09:15] :) [09:15] hi huats [09:16] how are you daniel ? [09:16] good - how 'bout you? [09:16] great too [09:19] dholbach: Sorry, I was afk - jogging. [09:21] dholbach: I can be assistant to a java packaging session if there is enough demand for such session. And I think geser is appropriate person to conduct such session. [09:22] slytherin: maybe you could try to round up a bunch of folks of #ubuntu-java and see who of them can attend the session too? [09:23] dholbach: I will propose it in our weekly meeting [09:23] thanks a lot [09:25] slytherin: what? I'm more a universe generalist not a java packaging expert. You know more than me about java packaging (or even how to tweak a java package to build again). [09:25] dholbach: Well, yes. I'm thinking to run a session with someone, not sure about what. Do you have any idea if bobbo is available? [09:25] * Iulian looks at /Prep [09:25] geser: But I have no experience of conducting session in developer week. Considering that you are more experienced in overall packaging I thought you might be ineterested. [09:26] Iulian: bobbo is already giving a session, you could just ask him and see if he has an interest in the session you're intending to run [09:26] slytherin: you could check out a session log of last time's developer week [09:26] will do [09:26] https://wiki.ubuntu.com/UbuntuDeveloperWeek/ still has links to the logs of last time [09:27] if you want to demonstrate something or do a session tutorial-style, best just plan 30 minutes of "show" (or content), people ask a lot of questions :) [09:27] and it's a lot of fun [09:27] lots of excited new people [09:27] dholbach: What session is he giving? [09:28] Ah [09:28] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep - Introduction to BZR -- DavidFutcher (bobbo) [09:28] Yes, I saw [09:28] * dholbach is very happy to see james_w and bobbo delivering talks about the bzr goodness :) [09:29] please all grab slots soon :) [09:39] hi all [09:39] how difficult is it to include a new package in ubuntu repository? === DreamThief is now known as LameSucker === WhiskeySour is now known as DreamThief === LameSucker is now known as WhiskeySour [09:42] treeform: Not that hard, but it may take time. [09:42] treeform: Is the package available in Debian? [09:43] cyberix: no people just get the deb from our site [09:43] we build many deb's and rpms [09:45] treeform, how do they build the debs? [09:45] Do they do something like checkinstall/cmake's cpack, or do they do it the right way? [09:46] i am not sure i did not code the process [09:49] treeform: If you are planning to get your package to Debian, then you should do that first. [09:49] it looks like it uses dpkg-deb -b linuxroot [09:50] treeform: If you are planning to go Ubuntu only, you should upload your package to REVU for review [09:50] http://revu.ubuntuwire.com/ [09:50] no we are planning to go to a everyone who will take us [09:51] treeform: do you have also source packages or only the .debs? [09:51] we have source too [09:51] license? [09:51] BSD [09:51] in that case [09:51] the problem of including is originally was that it had its own license [09:52] first get it to debian [09:52] then request Ubuntu to get it from Debian [09:52] which was kind of wishy washy in some places [09:52] cyberix: oh [09:52] treeform: dpkg-deb -b linuxroot looks fishy [09:53] it sees if there is /usr/bin/dpkg-deb or /usr/bin/rpmbuild and uses one of them [09:53] i dont think it follows any policy [09:57] treeform: "In some cases, the same upstream software is packaged separately in Ubuntu and in Debian, though this is to be avoided unless there is a justifiable reason to do so." [09:58] cyberix: hmm there is probably isnt [09:59] but i think we plan to build them separate [09:59] i dont know if there is any good reasons on doing so [10:00] treeform: This is how you ask Ubuntu to get the package from Debian: https://wiki.ubuntu.com/SyncRequestProcess [10:01] do you know if any other distros work this way? [10:02] I think gnewsense is based on taking a snapshot of Ubuntu every once in a while and then modifying that to produce their product. [10:03] getting the package to debian is a good start [10:03] because there are lots of distros that are rooted to debian [10:04] so negotiating with them will be easier once the package is in debian [10:04] oh [10:04] i did not know that [10:04] Then there are distros that are not based on Debian [10:04] suse, fedora, slackware, ... [10:05] yep [10:05] I'm not an expert on those [10:05] treeform: http://en.wikipedia.org/wiki/Image:Gldt.svg [10:05] it looks like we built fedora, suse, debian and ubuntu [10:07] Are you doing some sort of special support for Ubuntu? [10:07] Something that would not fit into Debian? [10:08] i dont know [10:09] cyberix: i know some times deb pack's work on ubuntu [10:10] but i did not know that was the desirable way to go [10:10] treeform: It is desirable that the same source package work for both [10:10] source [10:10] oh they get compiled differently? [10:11] treeform: Ubuntu builds its own binary packages at Launchpad from the debian source packages [10:11] ok [10:11] so that is what will happen to your source package, if your sync request gets accepted [10:11] the build process is some thing to be improved [10:13] cyberix: thanks you been a great help [10:14] i have to go now [10:14] hopefully ill get every thing included [10:14] hi, how do i make the rules file, pass a parameter in the configure , if it detects the architecture is amd64? [10:14] treeform: no problem [10:18] or rather how do you detect the 64 build in the rules file? [10:18] find $SRCDIR -name *.o [10:18] Something like that [10:20] what package should lintian be run against [10:22] gnomefreak: run lintian *_source.changes and then lintian *_i386.changes [10:23] slytherin, I thought if you ran it against the *_i386.changes (assuming it wasn't abinary only build), it hit both the debs and the source package [10:23] slytherin: thats what i thought thanks [10:24] NCommanderI don't think so === ara_ is now known as ara [10:27] sebner: thanks for syncing :) [10:35] dholbach: I am thinking to give a session about introducing MOTU, similar to what nxvl gave in the last UDW. What do you think? [10:35] NCommander, any progress with gcl? :) [10:35] Iulian: excellent! [10:35] :) [10:36] dholbach: Great. I'll talk to bobbo to see if he's interested, if not I think I can handle. [10:36] dholbach: That shouldn't be so hard :) [10:36] ROCK ON - just make sure to grab the session slot on the wiki you're interested in [10:37] dholbach: I think I should give it in the first day... [10:38] sounds good === Tonio__ is now known as Tonio_ [10:39] Cool then. [10:50] does anybody know what is a mann ? [10:53] huats, how about a bit more context ? [10:54] ogra: sorry [10:54] :) [10:54] ogra: i am making a new package [10:54] and as far as I see, it is not building man but mann [10:54] ah [10:54] and the associated type is foo.n [10:55] and I've never seen that [10:55] well, mann is german for a male person otherwise :) [10:55] so I am wondering wondering :) [10:55] ogra: oh [10:55] that is not related I think :) [10:55] *g* [10:55] but thanks :) [10:56] dholbach: Added myself. [10:56] dholbach: Please poke me if the time isn't the right one. [10:58] DktrKranz, well, ATM, I'm debating if I can take that much pain [11:02] set backspace=indent,eol,start [11:02] Eh, ww [11:23] Iulian: looks good [11:24] Ok === smaftoul is now known as xerxas [11:24] hi all === dholbach_ is now known as dholbach [11:25] I would like to package a soft which : 1/ a simple file in python , 2/ need an init.d [11:25] is there some instructions to do that ? [11:25] python packaging ? init.d scripts instructions ? [11:30] dholbach, Hi ! [11:58] hi folks [11:59] * directhex continues his making-life-complicated effort from yesterday [12:00] what's the right way to deal with REVU on a package that needs bootstrapping? [12:01] directhex: what do you mean with bootstrapping? needing itself to build? [12:01] sistpoty|work, aye [12:01] directhex: usually bootstrapping should be done by buildd-admins [12:02] sistpoty|work, right. but how is anyone going to test a new package, proposed via revu, without already having it built & installed? [12:02] directhex: in rare cases (e.g. only one architecture to bootstrap), it's ok to uuencode the resulting binary after some local bootstrapping, however I'd highly encourage to not do this [12:02] directhex: have an example? [12:03] sistpoty|work, the example is mono-basic. vbnc, the vb.net compiler, is written in vb.net, and needs compiling with a vb.net compiler like, um, vbnc [12:03] sistpoty|work, upstream bundle a binary copy in the source tarball, which is obviously epic DFSG fail [12:04] sistpoty|work, it builds nicely, and is pretty easy to convert from using local bootstrap compiler to system compiler, but i don't see how to bridge the gap via revu [12:04] sistpoty|work, and the lenny freeze means i'm targeting a 0ubuntu1 release first [12:05] directhex: well, it's not necessarily a dfsg fail, in case the bundled binary is indeed the result of the exact source [12:06] sistpoty|work, ideally i'd like to check it with ftpmaster, since joerg originally rejected it. i'm trying to get the package in decent shape since the original packager seems to have gone into hibernation [12:06] directhex: for reviewing, I guess reviewers should do the boostrapping locally. (so adding some doc's/scripts how to do that sounds like a good idea) [12:07] directhex: well, for debian bootstrapping is not much of a problem, as you can simply upload the locally bootstrapped packages together with the source [12:08] directhex: maybe you'd also like to ask infinity for input on this topic? [12:09] sistpoty|work, i'm generally open to input, since i've not encountered this kind of thing before [12:10] sistpoty|work, but generally speaking, the ubuntu and debian mono people are highly collaborative, if not the same people, so i'd prefer to do things the debian way which also fits ubuntu, ratherthan anything ubuntuish that is harder to back from into debian [12:10] and the lenny freeze therefore is a PITA [12:10] should have looked at this sooner, really [12:10] directhex: well, the debian way is not exactly portable for bootstrapping, since we can't do binary uploads in ubuntu. [12:11] directhex: hence I'd suggest you ask infinity for the best ubuntu way to get it bootstrapped ;) [12:11] sistpoty|work, any specific channel? [12:12] directhex: he should be in #ubuntu-devel [12:26] DktrKranz, ping? [12:26] and what needs to be bootstrapped? [12:26] (there are packages that binary depends on themselves in Ubuntu; see GNAT) [12:26] gdc for another example [12:27] NCommander, pong? [12:27] DktrKranz, well, I was going to start looking at the differences between -33, and -34, and then start popping patches off until I find what broke it [12:27] Unless you have a better method [12:28] NCommander, that's the method I chose [12:29] any luck? [12:29] no, but I didn't try combinations :) [12:29] Ow [12:29] ew [12:29] there are four changes (and 11Kb patch, lucky!) [12:29] two can be related [12:29] What happens if you zap all four? [12:29] FTBFS [12:29] Figures [12:30] gnu hash support must be in [12:30] Maybe that's what broke it [12:30] Then the fix must be made in axiom [12:30] remaining one can be omitted safely (given that you compile it with right configure flags to avoid *two* FTBFSes) [12:32] NCommander, oh... I see you added per-package archive functionality, thanks ;) [12:32] (on REVU) [12:32] I did? [12:33] so it seems [12:34] there's a link on top-right corner [12:34] do you want a screenshot? [12:37] * NCommander looks at REVU [12:38] Oh [12:38] (I'm a REVU admin, I can see it myself ;-)) [12:38] RainCT must have added it [12:38] I did it differently in my branch which is unreleased === Kopfi|offline is now known as Kopfgeldjaeger [12:43] NCommander, I guess bug I opened about it should be closed now. [12:44] I can't build axiom at all [12:44] segfaults [12:44] everytime [13:01] someone here ? [13:01] xerxas: questions like these are rarely useful on irc channels with more than three participants [13:02] azeem, I asked a question 2 hours ago , there was no activity and noone answered ... :) [13:02] there was activity, just not about your question [13:02] I would like to package a soft which : 1/ a simple file in python , 2/ need an init.d [13:02] azeem, everyone was idling for 1 hour ... [13:02] anyway .. [13:02] is there some instructions to do that ? [13:02] xerxas: so look at packages that are 1/ python and others that are 2/ have init.d [13:03] python packaging ? init.d scripts instructions ? [13:03] ok [13:03] azeem, do you know a simple package in python ? [13:03] apt-cache search python [13:03] maybe a simple dyndns client in python is a good start [13:03] and for the init.d , a package that have a simple init.d ? [13:03] memcache ? [13:04] xerxas: look at /etc/init.d on your system, find out which package those files belong to, and look at them [13:05] atd seems to be a good example [13:05] azeem, thanks [13:13] didrocks: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep [13:14] hello [13:14] * didrocks hugs dholbach :) [13:15] * dholbach hugs didrocks back [13:15] * emgent propose mass-hugs. [13:15] so... more sessions! [13:15] * emgent hugs dholbach [13:15] * dholbach hugs y'all === metilfenidato is now known as leleobhz [13:42] nhandler: "Fix FTBFS with gtk >= 2.13.1" isn't much of a debian/changelog entry (sylpheed). [13:45] nhandler: Do you think we should ship both sylpheed and sylpheed-gtk1. It seems to me (without knowing much about it) we ought to transition people to the gtk2 package. [13:45] * directhex tries out revu for the first time [13:55] <\sh> ScottK: it's ok for that package [13:56] <\sh> ScottK: ( I was the sponsor ) [13:56] <\sh> ScottK: and it was a merge of the package, so the change was introduced by hmm..someone [13:56] <\sh> ScottK: fedora has the same patch applied...so everything is ok :) [13:57] <\sh> ScottK: btw..we need to find a way of not diverting menpower away from the "general motu team" into the "more specialised teams"...and IMHO that's our social problem , what we are discussing on the ML right now...sad but true... [13:58] \sh: I'd prefer a little more verbosity so the next person has a better chance of understanding it, but that's just me. [13:58] \sh: I agree. I just don't see any benifit to NOT approving people who have mostly a specialized interest. [13:59] i have a very specialized interest which is why i havent applied for MOTU yet [13:59] I would have also preferred we have the discussion without making a particular individual the object lesson. [13:59] ignore me then. [14:00] laga: I don't want to ignore you. [14:00] What's you're specialized interest? [14:00] <\sh> ScottK: I'm not against approving these candidates...because we need to change our workflow anyways...and yes, it's sad that the applicant now in question was the start of the whole topic...but right now I don't like the way we go...the discussion is more and more heated up [14:01] i'm not offended or anything, i understand you want to have a generalized discussion :) === orly_owl is now known as yarly_brb [14:01] ScottK: mostly anything related to mythtv and mythbuntu. XMLTV, ffmpeg. [14:01] laga: I am curious what specialized interest you have and why you think that stops you from being MOTU. [14:01] laga: Personally, I'd love to have someone interested in that stuff to sponsor it if they were otherwise qualified to be MOTU. [14:02] it seems - to me - that MOTUs are also supposed to merge packages from debian etc. and have lots of other responsibilities [14:03] AFAIK, it is now technically possible to sponsor individual packages if you're not MOTU. i'm not sure of the community parts have been implemented yet [14:03] True, but we are virtually all volunteers and so we volunteer as we feel appropriate. [14:03] I think that's true. [14:06] <\sh> let's say it like this: we all have our special interest in doing ubuntu work ... but now, we have many many many small teams, where people are interested in and who work towards it...but they don't work with the "general motu team" .. so people who need to decide "+1 ready for rights, -1 not ready for rights" they are doomed, because they don't know the people, they never worked with them.. [14:07] <\sh> and this is on thing we need to solve...before the discussion explodes [14:07] <\sh> s/on/one/ [14:07] good point [14:08] i still plan on applying for MOTU at some points. i'll be doing some merges and other low work for intrepid+1 so people get to know me better and then probably apply around christmas [14:09] <\sh> and with many many people working not with the "general motu team" it becomes quite difficult to tunnel the work...team 1 work on those packages, team 2 work on these packages, but general motu team ( as the situation is right now ) doesn't have clue about the things going on in team 1 or team 2 and their packages. [14:10] <\sh> as seen with -mobile...ubuntu patches are applied, but people who do the merges for the next cycle don't know anything about this patch, if it's important or not, or how to merge the patch to the new upstream (if it's not applied)...but these issues are social, more communication between the parties is needed [14:13] \sh: do you expect the mobile team to document every patch? [14:13] \sh: See my earlier comment about more verbose debian/changelog entries (not that that is a complete solution). [14:13] laga: I certainly do. That's part of the job. [14:14] ScottK: sure, but where? inside the patch? of course. but on a mailing list? this is not a problem with communication, it's a problem with documentation ;) [14:15] laga: In the package. [14:15] <\sh> laga: well, the most common practice is, the last uploader / sponsored contributor is doing the merge / sync for the next cycle again..if this is not the case, someone else needs to do it in time, so there needs to be some documentation..why and what and when the patch is needed...or at least: "you can drop this patch because upstream applied it now" on irc or mail (ML) or whatever..this is one of the problem with the split of the teams in general [14:15] <\sh> (but this is not OSS related or ubuntu, that's a general conclusion) [14:15] IMO one should be able to read debian/changelog and have a reasonably clear view of what's going on. [14:17] <\sh> ScottK: "debian/patches/foobar.diff: makes the input experience much better on hildon interfaces" ? [14:18] <\sh> ScottK: "debian/patches/fix_cn_config.patch: now cn=config works" [14:18] Yes. [14:19] Or "Build-dep on libfooY instead of libfooX because Ubuntu uses the libfoo currently in Debian Experimental" [14:19] *-dev of course. [14:20] <\sh> (just silly examples I know) but for people knowing the software, they can work out what the patch does, for more general people, this is a pain...so yes, I agree, we will have more specialization in the future..but this obsoletes the purpose of the motu team and yes, we do those changelog entries, too [14:23] <\sh> ScottK: but in general, we need a re-structuring (in the near futures)...what do you think? [14:23] ScottK: when a backported package is affected by a bug now fixed in a sru, is it possible to backport the sru? === superm1|away is now known as superm1 [14:24] Adri2000: Generally just do a new backport. We can backport the SRU if needed, but if we can just do a new backport, that's better. [14:24] \sh: I agree we need to figure out what the archive reorg means to MOTU. === Kopfgeldjaeger is now known as Kopfi|offline [14:31] <\sh> ScottK: sidenote: GEM is EVIL! [14:32] Yeah, well I'm trying to gently point people in that direction. [14:32] <\sh> ScottK: no need...just ask sysadmins who are working with devs who switched from java to ruby ,-) [14:33] <\sh> ScottK: I just replied to the list...I had in my past a gem which distributed a special version of imagemagick... [14:33] I only know about it because I'm providing some system engineering support to a project that uses it. [14:33] <\sh> the source archive I mean, and it build it inside of the gem machine... [14:33] Fortunately for that project I neither need to write the code nor sysadmin the boxes. [14:34] <\sh> without honoring anything from DESTDIR to overrides to ./configure stuff [14:34] Someone can take a look at http://revu.ubuntuwire.com/details.py?package=ircp-tray ? I need a second sponsor for it. [14:34] <\sh> it just destroyed /usr/lib with installing it there...without a notice... [14:35] <\sh> after that I had more clues about gem and not using it [14:35] Heh. I can imagine. [14:36] devfil: Looking. [14:36] <\sh> but the general thing is: devs vs. sysadmin == bloodsport part 666 ;) [14:37] ScottK: thanks [14:41] http://revu.ubuntuwire.com/details.py?package=mono-basic - go nuts. to bootstrap, please use packages in http://retro.apebox.org/mono-basic/ [14:42] devfil: Why do the first two copyright holders not get listed as upstream authors? [14:43] ScottK: I think they were only contributors or the upstreams of ircp, they aren't in AUTHORS file [14:44] OK. Sounds reasonable. [14:46] devfil: Does ircp-tray -h show more options than -h and -v? [14:46] ScottK: what do you mean exactly? [14:47] Your man pages says "A summary of options is included below". [14:47] One of the listed options is -h show a summary of the options. [14:47] The man page only lists -h and -v as options. [14:47] Are there more? [14:48] ScottK: -h is the help and there are only -h and -v [14:48] OK. [14:49] Does -h provide useful information? It would seem a shame to read a man page to learn that I need to go somewhere else to get my question answered. [14:50] ScottK: nothing else [14:50] -h shows version and -h/-v options [14:50] OK. [14:52] * ScottK needs to focus on $WORK for a bit. I'll come back to it later. [14:52] If i find another bug while working on a different bug, should i log a bug for it, or just fix it? [14:53] stefanlsd: Just fix it and document it in debian/changelog unless it will be around for a long time. [14:53] SCottK - how do you mean - it will be around for a long time... [14:54] If you aren't going to get it fixed soon, then file a bug. [14:56] NCommander, you still about? [14:56]