[00:00] who would care ? [00:00] I'm sorry, you mean I'm not supposed to put my own email address in the maintainer field ? [00:00] thats only for compliance to an agreement we have with debian [00:00] you surely wont see me putting XSCB-Original-Maintainer in an ubuntu only package [00:01] ogra, you have a ubuntu e-mail address? [00:01] (despite being totally pointless) [00:01] cody-somerville, sure [00:01] ogra, and is that the e-mail you put as the maintainer? [00:02] in the packages i build for ubuntu only i do, yes [00:02] so you're already following the policy :P [00:02] h, indeed [00:03] sorry for the noise then :) [00:03] flabber is an original package, so ... in this case what should I do ? [00:03] Falken, since you don't have a Ubuntu e-mail address, set the maintainer to Ubuntu MOTU Developers [00:03] and set yourself as XSBC-Original-Maintainer [00:03] oh ok I see [00:04] thank you ! [00:04] No problem. :) [00:05] _##(&@_#(%&@+#% took me a minute to find where they have hidden the "subscribe somebody else" button now [00:07] Hi guys. Is this the right/wrong channel to ask about a problem I am having backporting a package, and a specific issue I am having with the resultant package? === asac_ is now known as asac [00:09] as good as any given good debugging information. [00:10] norsetto: i already patched eggdrop with ssl support and uploaded the debdiff to the merge bug... (in case you where wondering... i told emgent i wanted the merge :) ) [00:11] RoAkSoAx: ok, thanks, have you subscribed u-u-s? [00:11] norsetto: yep :) === Amaranth_ is now known as Amaranth [00:11] RoAkSoAx: perfect [00:12] Alright, It comes back to my mission to backport the Subversion 1.5 package put up to Intrepid (by Doku). I have rebuilt his package source under Hardy, and am experiencing an SSL problem, which is a noted bug in the Debian package people. The problem is reportedly an issue with libneon27-gnutls. So I rebuilt my package against libneon26-gnutls, but am experiencing the same issue. Is there something I should look at to find more info on why this [00:12] is happneing?\ === pwnguin is now known as jldugger [00:17] where to ask about python packaging ? [00:18] ScottK, I just uploaded the modified package, is there a need for a revu admin to sync each time we upload, to actually see it on the website ? [00:18] Hi tacone, did you check https://wiki.ubuntu.com/PackagingGuide/Python ? [00:18] moosepants: what issue? How have you been debugging (gdb, ...)? [00:19] Falken: that's my bible but doesn't answers my questions [00:19] :D [00:19] ok, switching to #python === jldugger is now known as pwnguin [00:21] crimsun_: I think the issue is with client certificate validation. The server is asking for a resend of the certificate, and something is going wrong somewhere. http://www.nabble.com/Bug-480041:-subversion:-Breaks-client-certificate-negotiation-td17111865.html details the Debian Bug. [00:21] moosepants: ok, I'll look when I'm less busy. In the meantime, don't block on me (don't wait for me to respond immediately, as someone else likely will help). [00:22] crimsun_: it's ok, i don't spinlock ;) [00:25] cody-somerville : do you mind checking it again ? :D [00:27] Could someone running hardy and the subversion off the repo (1.4.x) please pastebin me an ldd of their /usr/bin/svn? [00:28] !paste [00:28] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [00:29] moosepants: http://paste.ubuntu.com/22976/ [00:29] (amd64) [00:29] Laney: Thanks very much :) === Amaranth_ is now known as Amaranth [00:39] I'm sorry I'm being impatient with my first package ever :P should I just wait for someone to review it someday ? or hassle everyone with it until it's done ? :D [00:47] * tacone votes for hassling [01:00] If I want to create a modified version of an ubuntu package for uploading to a PPA, is there a particular naming scheme I should use for the package? [01:03] tacone: #python isn't going to know about Debian packaging for Ubuntu. [01:03] What's the problem? [01:04] ScottK: to my knowledge there are 2 chances: packaging with or without distutils. [01:04] Yes. [01:04] ScottK: I had a setup.py problem, including recursively a dir. [01:04] If you use distutils it's generally dead easy. [01:04] I couldn't find anything about it. [01:05] How many levels of recursion and why? [01:05] at least 3 levels of recursion. it's a theme directory. each theme as subdirs. and I would like to not impose limits, as they could require maintenance. [01:06] ScottK: on the other hand debian/rules should handle that nicely. Am I wrong ? [01:07] You can do it in setup.py too. [01:07] just checked, no I ain't. [01:07] ScottK: how ? [01:07] ScottK: to my knowledge I have to write python code to do that. [01:07] Yes. [01:07] But it's not hard. [01:08] For debian/rules you'd have to write shell to do it. It's about the same. [01:08] not really [01:08] I've mistaken [01:09] hello people [01:10] emgent: hello person [01:10] ScottK: I am trying to adapt the previous package. there's a .install file which contains the required dirs [01:10] Yes. [01:10] seems like the list get passed to a cp command or something like that. [01:10] I that'd do it too. [01:10] mkdir actually. [01:11] err, yes. cp. [01:11] I have also a .dirs file, which doesn't seem strictly required (but for empy dirs I guess) [01:12] Yes. That's what it's for. [01:12] For making directories, not necessarily empty. [01:12] ScottK: now package installs.but python files are putten in /usr/share/pyshared//* [01:12] is that correct ? [01:13] If you are using python-central, yes. [01:13] ScottK: yes I am. [01:31] Hiy'all, whats the major difference between libneon and libneon-gnutls ?? [01:33] moosepants: the former is compiled against OpenSSL; the latter is compiled against GnuTLS. [01:34] crimsun_: Why then, would the 1.4 subversion package be compiled against libneon, whereas the 1.5 package in Intrepid (by Matthias), is compiled against libneon-gnutls [01:35] I just compiled my 1.5 package against libneon and it works fine [01:37] moosepants: documented in Debian 478142 [01:37] Debian bug 478142 in subversion "subversion: svn "SSL negotiation failed:" in lenny since 4/15/2008" [Normal,Closed] http://bugs.debian.org/478142 [01:45] crimsun_: Hmm interestingly I got the same results as Debian 480041 until I switched back to using libneon (openssl). I wonder if I can be bothered tracking this down or just waiting to see what becomes of 480041... [01:45] Debian bug 480041 in subversion "subversion: Breaks client certificate negotiation" [Important,Open] http://bugs.debian.org/480041 [01:49] In fact, I think I'll put my findings down in 480041 and see where we go from there. Thanks all. [02:12] should the ubuntu version number be incremented when packaging a new upstream version ? [02:14] tacone: Typically it should be reset. For example 0.1-2ubuntu1 becomes 0.1-0ubuntu1 for a direct upstream update. [02:14] Err. 0.2-0ubuntu1 [02:14] It's generally considered better to try to coordinate with Debian, and then merge with 0.2-1 creating 0.2-1ubuntu1 [02:15] persia: the package is not from debian [02:15] tacone: In which case, there's no expectation of coordination. 0.2-0ubutnu1 will do fine. Just attach the diff.gz to a bug, and make sure that orig.tar.gz is generated from debian/rules get-orig-source [02:16] persia: should I generate the diff even if upstream source structure changed totally ? [02:17] tacone: The diff.gz, not a package diff. [02:18] err. ok. (gosh) I am going to document my self a little about that. [02:19] tacone: More expansively, the debdiff against the previous version of the package is not likely to be comprehensible, due to upstream changes. On the other hand, there will still be packaging, so you'll get a diff.gz and an orig.tar.gz. when you build the source package. It's this diff that is useful for the sponsors. [02:20] ok [02:20] thanks [02:46] kees: around? [02:58] #ubuntu-meeting === jeff__ is now known as SEJeff_home [03:15] if I change my pbuilderrc so that I am building for Feisty for instance (on my Hardy), will this delete all of the packages etc it downloaded for my Hardy pbuild environment? [03:16] (Or will they remain in cache) [03:16] moosepants: I don't use pbuilder, so I may be incorrect, but I believe that it supports multiple parallel chroots, as long as you give them different release names. [03:17] persia: Thanks. I guess I'll suck it and see [03:17] So you'd do something like pbuilder --create again for Feisty, and then you'd be able to target either environment when you build something. [03:17] What you *really* don't want to do is try changing /etc/apt/sources.list inside pbuilder, which will confuse the link between contents and names. [03:20] persia: Yeah I just wondered if I needed to do something so that there was a base.tar.gz for Feisty, and one for Hardy, but it might be clever enough to handle it all internally [03:21] In my experience it is, but I don't do it exactly that way, so no promised. [03:21] I think if you have two different base.tar.gz files, you're all set, although no promises, given my unfamiliarity with pbuilder. [03:21] promised/promises. [03:25] We'll see... Cheers [03:37] Amaranth: you are the man i was looking for! [03:38] Amaranth: i need some help on graphics programming [03:38] Amaranth: i need an easy way to do a ball which moves on a b-spline curve [03:38] (prefered in python, but not limited to) [03:45] ScottK: /me chokes. Does somebody really think they can get ClamAV into main? [03:46] wgrant: Yes. I was sitting next to kees when I brought it up at UDS and he didn't even hit me. [03:46] wgrant: Bottom line is that it'll be painful, but if we want to be taken seriously as a server distro, Canonical needs to suck it up and support it. [03:46] ScottK: I can't see how it can even slightly be considered. [03:47] If we have to backport every minor upstream release to every series... [03:47] * persia suspects ScottK of being the person who ends up sucking up and supporting it [03:47] ScottK: How do other distros do it? Backport new versions? [03:47] That's how opensuse does it. [03:47] They don't seem to worry about what it breaks. [03:48] Maybe some almighty Canonical folks can talk sense into ClamAV folks? [03:48] * ScottK has some hopes on that front. [03:48] And maybe I should attack the Intel driver in Intrepid for reducing my monitor brightness often. [03:48] That's probably not even the most shocking MIR that will be in the stack. [03:48] * ScottK just finished a MIR for Sendmail. [03:48] What's worse? [03:49] WHy!? Milters need it? [03:49] Yes. [03:49] Haha. [03:49] Promote the source and libmilter [03:49] They couldn't be split? [03:49] Then I can unsplit amavisd-new and don't have to split clamav. [03:49] Since the binary stays in Universe no split is needed. [03:50] I discussed it with pitti today and he was OK with no split. [03:50] OK. [03:51] With clamav we probably want to roll to new versions if we can do it safely as even with security patches, the old versions don't find viruses very well. [03:51] So the big thing is getting the regression testing right. [03:52] I suspect you'll be asked to write some thorough qa-regression-tests suites for it... [03:52] Many of the libclamav rdepends are unmaintained/minimally maintained in Debian, so I'm going to see about getting them removed. [03:52] Actually kees already has one that's pretty decent. [03:52] That's an interesting way to solve it. [03:52] I saw it. [03:52] It's pretty basic, but covers things like RARs and mboxes... [03:53] The trick here is that clamd has a stable interface and so is safe to update, but libclamav does not. [03:54] So if the packages that use libclamav are either robustly maintained or removed, then jumping versions isn't so hard. [03:54] Right. [03:54] My record on that so far is pretty good. [03:54] Does the interface really need to change, or are they just doing it to be annoying or not knowing what they're doing? [03:54] I got two complaints taking dapper from 0.88 to 0.92 and none updating Feisty and Gutsy. [03:54] Not bad. [03:54] What broke in Dapper? [03:55] Their position is "We aren't 1.0 yet, so we can do whatever we want." [03:55] ScottK: Are they ever going to go 1.0? [03:55] There was a function that python-clamav dropped due to a clamav change that broke a custom 3rd party package and one person had a dansguardian configuration problem. [03:56] wgrant: WINE went 1.0. Anything can happen. [03:56] ScottK: True. [03:56] The python-clamav problem was solved by packaging and backporting python-pyclamd that did something similar. [03:56] ScottK: Ah good. Local issues only. [03:57] Yes. We tested the cr@p out of it and the rdpends before jumping back to Dapper. [03:57] I'm not sure I like seeing this in an upstream changelog: 'Dates can now be in the year-range 1-9999' [03:57] ScottK: I'm sure the users appreciate it deep down [03:57] I wonder what on earth they're doing that means implementing their own date storage format... [03:58] if they even knew what the issues where [03:58] The guy with the dansguardian problem asked me what the heck had motivated us to update. I said 19 fixed CVEs and he thanked me even though it broke his sysytem. [03:59] It should probably be noted somewhere prominent in the packaging that such updates will occur... [03:59] (and why) [03:59] Package long description even? [03:59] That is one place I was thinking of. [04:00] Except that clamav is currently a sync from Debian. I'd like to keep it that way and they handle it differently. [04:00] sgran just points at volatile. [04:00] * ScottK had a grave bug filed against the klamav package in etch (I'm the maintainer) that it didn't work with the packages from volatile. [04:01] * ScottK closed it. [04:03] grave? that's interesting, to say the least [04:03] saying that a release version doesn't work when you upgrade stuff underneath it [04:03] I don't think the reporter understood different repos. [04:04] I tried to explain it in a reasonably nice way. === santiago-php is now known as santiago-ve [06:13] how do i edit .bashrc [06:14] Gralco: By asking in #ubuntu. This isn't a support channel. [06:15] I can't figure out how to procede when dealing with a new upstream version. It has a complete different source tree. I can successfully build it with pbuilder, but I don't know how to generate the diff from the previous package. I also can't figure out reading the wiki. [06:16] does anyone has some url to read or the time to indicate me the right route ? [06:17] tacone: When you make the source pacakge (debuild -S -sa) that will produce the diff.gz you need to provide. [06:18] ScottK: do I need an original tarball somewhere to base the diff on ? [06:19] You will need to have it locally, but the MOTU that reviews the package will fetch it from upstream themselves. [06:20] ScottK: a pastebin is worth thousand words. http://pastebin.com/m17d5b16b is that ok ? [06:20] should I keep memaker-0.9.4 and memaker-0.9.5 in the same dir like that ? [06:21] That's not a problem. You want to provide the 0.9.5 version of memaker_0.9.4-0ubuntu1.diff.gz [06:21] It's way late here, so I need to get to bed. [06:22] ok, good night. [06:23] good morning [06:26] dholbach: hi! [06:27] hello [06:27] hi nxvl, hi ajmitch [06:29] dholbach: i was thinking today while reading a lot of mails [06:29] dholbach: for intrepid we have a lot of contributors (more than i see for hardy) [06:30] and the sponsoring queue is growing and growing [06:30] it may be because the old devs are focused on 8.04.1, but since your work is to bring more developers i feel like i need to talk to you abut this [06:31] since the queue is a bottle neck for some new contributors [06:31] nxvl: That is always the way, for each release. Since feisty, the sponsor queues have grown faster in each release. [06:31] persia: yes, but last release was manageable [06:31] nxvl: I realised this too and am going to push for more sponsoring and more review [06:31] The queue is fairly short now. [06:31] We're at least keeping up. [06:32] persia: this time is growing at surprising speed [06:32] nxvl: As will this release. It tends to be worst a little before DIF, and then get much better. It gets messy again around betafreeze, and then gets better [06:32] dholbach: maybe (as i raised the idea earlier on the cicle) there can be some sponsor days, as we have (or use to) revu days [06:33] nxvl: For me, each release since feisty has grown faster than the previous. I'm not surprised, but it is fast. [06:33] nxvl: We discussed sponsoring days in the past, and even tried it for a bit. [06:33] persia: yes, but for example i have a diff waiting since 30 Abril [06:33] The finding was that scheduled sponsoring days reduced regular sponsoring by the sponsors. [06:33] nxvl: Which queue? [06:34] main one [06:34] Right. [06:34] Bug #225005 [06:34] Launchpad bug 225005 in gnupg "Please merge gnupg 1.4.6-2.1 from debian sid" [Undecided,Confirmed] https://launchpad.net/bugs/225005 [06:34] Someone ought sort the main queue, and have a process :) [06:34] if you mean the gnupg merge, well, I think I need to be more proactive about refusing merges that dholbach assigns to me [06:34] at least during 8.04.1, I just haven't had any time to get to them all :/ [06:35] slangasek: i'm not complaining about you, just the whole process, it was just the first example which comes to my mind [06:35] slangasek: sorry if you understand otherwise [06:35] nxvl: well, I'm suggesting that I may not be representative of the process either [06:35] I suspect that currently, most of the main sponsors are doing a much better job than I am personally [06:36] and also i'm not trying to say that the people aren't doing a good job [06:36] because thay are [06:36] i have got packages sponsored really fast [06:36] slangasek: For main, it has historically depended heavily on the specific package, with some packages getting sponsored quickly, and some bugs languishing in the queue for over six months. [06:36] but the number of contributor are growing to fast now [06:37] and based on what persia said it will grow more for intrepid+1 [06:37] well, if it's a question of the number of contributors growing too fast, then I think we need a better model than having each of them repeatedly requesting individual sponsorship for package uploads... [06:37] Hopefully the number of MOTU will also grow. [06:38] Personally, I'm of the opinion that Ubuntu has outgrown main/universe, and that this is part of the issue. [06:38] persia: We have a spec to solve that, as I believe you've seen. [06:38] wgrant: Yep. [06:38] it will always require people willing to review and sponsor :) [06:39] dholbach: yes, and there is where i was going [06:39] slangasek: It's mostly an issue for those packages that aren't cared for by a specific team, and are just in main. Nobody tends to merge those patches, and as a result, it gets skewed. [06:39] nxvl: oh, actually, I'm afraid that your merge in 225005 is no longer valid, it's against a version of gnupg that's no longer in the Debian archive :/ Could you update to a more recent version (either current testing, or current unstable), or do you want me to fish -2.1 out of snapshot.debian.net? [06:39] dholbach: you are making a wonderful job making new people come into the community, but you have somehow forgot developers, and making them review and sponsor [06:39] We've had a couple people be mostly main sponsors, but not for very long each: it's not always clear whether any given package fits into that category. [06:40] nxvl: I haven't forgotten that - I look at the queue every day and poke people every day [06:40] but I agree that we need more efforts there [06:40] nxvl: Unfortunately we can't really be made to sponsor, and it's not always the funnest of tasks. [06:40] persia: I'm saying that if the number of contributors is growing fast enough that they're overloading the sponsorship queue in general, then having more sponsors is not a very appropriate answer, because you eventually run into scalability problems there too (problems that can be mitigated by ubiquitous revision control, but we're not there yet) [06:40] dholbach: yes, that i know, remember that i'm always in that queue, and i always see your comments first [06:41] dholbach: but it will we awesome if more people like you triage the bugs on the sposoring queue [06:41] NMSP would make everything very nice, slangasek. [06:41] NMSP? [06:41] no more source packages. [06:41] slangasek: ubiquitous version control doesn't solve it alone, as most of the potential contributors aren't likely to look at the same package twice, so wouldn't have VCS access. [06:41] Everything done in a VCS. [06:42] certainly, looking at why we have inactive people, particularly in teh areas of sponsoring, would be a good idea. [06:42] If it's just proposed branches, that might make sponsoring simpler for some people, but it still leaves sponsoring to be done. [06:42] slangasek: It was an Ubuntu/Launchpad spec some time ago, but it seems to have faded into distant memory. [06:42] but i say that as a case of 'armchair development' === dholbach_ is now known as dholbach [06:43] persia: I'm just saying that there's a built-in scalabilty limit to the "one contributor, one sponsored upload" model, which is that at some point you have too high a rate of collisions between multiple uploads being prepared at the same time. [06:44] slangasek: Understood. We've rarely had that conflct: the conflict is more often that someone who could sponsor doesn't bother to check if there is anything available to sponsor and duplicates the work. [06:44] That said, as we grow, we may encounter that issue. [06:44] also if the contributors continue growing more than the MOTU's (which is an obvious bahavior) you will have more problems [06:45] and you will end with a the MOTU's just reviewing the contributors work [06:45] and not making things done [06:45] nxvl: More problems, or just more unsponsored upload candidates? [06:45] which is also a bad thing [06:45] persia: i mean if we start trying to have more sponsors [06:46] nxvl: We've traditionally had about three times as many contributors as members of ubuntu-dev. If about 10% of ubuntu-dev does sponsoring, we tend to keep up. [06:46] (with exceptions, and occasional lapses) [06:47] well, yes [06:47] but the thing is that some work is needed on these side [06:47] s/side/front/ [06:47] If we're seeing faster relative growth of contributors than ubuntu-dev (e.g. more than 3:1 new starter rate), I suspect the problem is that there is some issue with people joining MOTU, and would like to see that addressed. [06:47] and it also isn't a good idea to depend on dholbach doing to [06:48] something is needed [06:48] and we need to thing about why and how [06:48] nxvl: I don't: I'm one of the UUS admins, and wrote the UUS policy. That said, I think there could be improvement in UMS, but am not sure of the right solution given the sensitivity of some packages. [06:49] well [06:49] UMS is more sensitive and not much new contributors use it [06:49] UUS lags sometimes, but I don't think the issue is growth, but rather interest. I've seen less traffic in this channel during this release cycle than any previous, which makes me wonder about activity. [06:49] i'm thing more on UUS [06:49] * dholbach takes a look at creox and vtk [06:50] * wgrant has been far too inactive recently. [06:50] * persia thinks UUS is doing OK, if it maybe has a few days of lag [06:52] Or maybe not. Three weeks is a little long. Still, I expect it to catch up soonish. [06:53] * Hobbsee vaguely wonders how to make MOTU, and sponsorship, more interesting. [06:53] that's what i'm saying [06:53] is not that it's doing wrong [06:54] just that in not a far away future it won't be enought [06:54] and better to start thinking on how to better it now that later [06:55] We could use the Canonical mind control ray to steal DDs. [06:55] heh [06:55] That hasn't tended to improve MOTU activity in the past though. [06:55] why it must be so funny when someone mentions DD's in this channel [06:56] persia: no, as they tend to get paid to work on a specific part of main [06:56] That wasn't the mind control ray I was thinking of. [06:57] Hobbsee: Well, I was thinking that DDs not already hopelessly busy tend to have a focus on specific packages, rather than hitting tens or hundreds as MOTU tend to do. [06:57] persia: true [06:57] persia: i wonder if our MOTU's have transitioned to act more like DD's, then. [06:58] Some of them seem to have done so. [06:58] TIL can induce that. [06:58] i guess it's natural that most would, though [06:58] Personally I feel that concepts like "touched-it-last" and "ping the last uploader" and "assigned merges" have contributed to that. [06:58] Part of why I dislike all of those. [06:59] persia: but to "split" one or other way the MOTU team into subteam will also make it more scalable [07:00] nxvl: Perhaps - we'll see what happens if the archive is reorganised... [07:00] nxvl: We did a lot of that in Feisty, and it didn't tend to work. [07:00] well i mean to do subgroups like pythonistas [07:01] wgrant: that won't really affect motu, though? [07:01] not to split the archive [07:01] well, it will a bit with flavours, but not otherwise. [07:01] Hobbsee: Well, it affects MOTU in that it's about upload permission, but it oughtn't affect MOTU targets. [07:01] Hobbsee: It will take a few large chunks of packages and give them a set of specific uploaders of significant size [07:02] nxvl: That's exactly the sorts of subgroups we used in Feisty. Most of them were dead teams in Gutsy, and there were lots of complaints about lack of active MOTU. [07:02] https://wiki.ubuntu.com/MOTU/Teams [07:02] like this [07:02] i don't think even the half of them are active [07:02] As persia said, that seems to generally fail. [07:02] Regrettably. [07:02] Because it should have been a good idea. [07:02] It seems to work in Debian. [07:02] It certainly sounded good. [07:03] I think it works in Debian because it is bringing people together, rather than splitting them apart. [07:03] hyeh [07:03] I think there is value to having ubuntu-python, ubuntu-ruby, ubuntu-java, etc. [07:03] yes it could be [07:03] I think there is also value in having MOTU. On the wiki, on the Teams page, MOTU is described as the QA developers. [07:04] We are the people who fix the bugs in all the packages that aren't getting enough attention: some of these packages have no Ubuntu maintainer, some just aren't watched carefully enough. [07:04] yes [07:04] which packages have ubuntu maintainers? [07:04] I like to think of MOTU as being a sort of super Debian QA team, with every day being open for 0-day NMUs. [07:04] pwnguin: Those will be more obvious once the reorganisation occurs. [07:05] well, i tend to watch the packages i'm interested in back from debian [07:05] pwnguin: Some packages are specifically maintained by the Desktop team or the Mobile team or the Kubuntu team, etc. Most packages don't have specific maintainer teams. [07:05] wgrant: For some subset of packages, it is encoded in the Maintainer field of the source package... [07:05] so mostly main [07:05] pwnguin: nop [07:06] pwnguin: Well, not those maintained by the Xubuntu, Mythbuntu, or Xubuntu Studio teams. [07:06] pwnguin: there are a lot of packages maintained by those teams on universe [07:06] nxvl: Good point. Desktop and Server teams both have a few packages in universe, don't they? [07:06] so we do have successful teams in MOTU [07:06] persia: True, but that's not overly reliable. [07:06] persia: yes we have [07:06] wgrant: True. [07:06] they're just not what you thought they'd look like [07:06] most of my contributions to the server team are in universe [07:07] pwnguin: Which? You mean the flavour teams? None tend to be exclusively MOTU. [07:07] so a quick round of feedback: what keeps YOU from doing sponsoring right now? :-) [07:08] * persia has a long list of things needing to be done, and keeps leaving sponsoring near the bottom [07:08] all you upload-privileged folks in here :-) [07:08] dholbach: i'm not a motu :D [07:09] * RAOF is actually looking at aptoncd sponsorship right now, but generally it's time or the lack thereof. [07:09] I wish I know a think or two about package managing [07:09] dholbach: and don't have upload privileges [07:09] :P [07:09] knew* [07:09] dholbach: It's not the most interesting of tasks, and what limited time I have at the moment goes to other tasks. [07:09] Gralco: it's not hard [07:10] Also, there's a fair amount of context switching involved in sponsoring other people's packages. I need get up to speed with the current package, what needs to be done, _and_ work out how it's been done. [07:10] well your probably much older than me [07:10] Gralco: it just need one or 3 weeks of dedicated work playing, reading and learning, and then just practica [07:10] Gralco: don't bet [07:11] me and dedication are not very good friends [07:11] although I've tried [07:11] but you've all done sponsoring before - do you think anything changed along the way? [07:12] Gralco: same here [07:12] Gralco: but it's really funny [07:12] :D [07:12] Gralco: also you can see dholbach's videos [07:12] nxvl wanna help me [07:12] Gralco: they are very intructive [07:12] I think I have [07:12] Gralco: well, since you are here i think you are in europe or some tz near [07:13] I got lost, I understand gpg pretty well [07:13] Gralco: i use to be here until this time [07:13] it's 1 o'clock here [07:13] I live in the US [07:13] 2 here [07:13] heh [07:13] so i can [07:13] :D [07:13] but not now [07:13] huh [07:14] i will go sleep in a bit [07:14] oh [07:14] dholbach: not me [07:14] :D [07:14] btw [07:15] did someone know a ToDo list tool that manages priority? [07:15] evolution [07:15] it integrates into the gnome clock too [07:15] to bloat for todo list [07:15] na [07:15] * nxvl give it a try [07:15] what does UDS do [07:16] it has progress, categories, due dates and more. it doesn't have bloat, it has features ;) [07:16] * nxvl doesn't find the priorities [07:17] the default is not good for mere mortals [07:17] theres a column you can add [07:17] just right click on the coluumn tabs [07:18] it only supports 3 priorities but [07:19] you could file a bug asking for closer compliance with LP status [07:19] i only need 3 priorities [07:19] well, maybe whislist [07:19] but 3 are fine [07:19] i can use low as whislist [07:20] i saw a tech talk at google about assigning a dollar value to your todo list [07:20] mm [07:20]