[12:54] <ScottK> mok0: Uh oh.  Please make a comment on the package to that effect.
[01:56] <ScottK> persia: I looked a bit at RegisterClient() and my head spins.  Would you have any interest in looking into fixing that problem with gpg-agent?
[01:59] <persia> ScottK: Very little, mostly because I've a stack of promises to fulfill that are still pending. (also, while I once read the X spec books, I haven't programmed against X in years).  I'll stick it on my list, and if it's not fixed before I get to it, I'll take a look.
[02:00] <ScottK> persia: Thanks.  "Haven't programmed in X in years and once read the X spec books" is light years ahead of where I am on the topic.  I certainly understand aboug having to many promised on the plate.
[03:08] <ScottK> StevenK: I'm curious if you have read/have an opinion on my missive to devel-discuss about gpg-agent?
[03:08] <mok0> ScottK: I've added comment ad kaksi on REVU, and sent letter to upstream author, CCed you. Hope she is still in the same place.
[03:08] <StevenK> ScottK: Nope. Link me?
[03:10] <ScottK> persia: Thanks.
[03:11] <StevenK> Heh
[03:14] <mok0> Scott, if you have time, could you take a look at the mustang package? It is not GPLed. http://revu.tauware.de/details.py?upid=5735
[03:15] <StevenK> ScottK: Sounds fine to me, other than that, no real opinion.
[03:16] <mok0> I am gonna quit now, it's 03:15 here....
[03:16] <mok0> See you later
[03:20] <ScottK> StevenK: Thanks.
[03:24] <StevenK> Yay for "saving" web pages as multi-part MIME, but not telling anything else, including the mail client that it is!
[03:25] <StevenK> This is the first time I've seen this particular type of brain damage, so I thought it was worth a kick.
[03:25] <ScottK> Sure.  IE is always worth a kick if one feels up to it.
[03:26] <StevenK> Now to figure out how to break this file up, without writing my own in Perl.
[03:26] <ScottK> Adri2000/Lutin you ought to look at DaD and libnetaddr-ip-perl.  It's particularly brain damaged.
[03:26] <ScottK> speaking of perl...
[03:32] <StevenK> Yay for mpack
[03:45] <persia> gnomefreak: Are you still working on nspluginwrapper, or is it ready for review?
[03:47] <superm1> _MMA_, ping
[03:52] <persia> Contributors: when submitting merge bugs, please be sure to include the new changelog entries from Debian in the bug description, to aid reviewers in determining if the changes are appropriate for inclusion.  This becomes very slightly more important now that we are in DebianImportFreeze, and will become much more important once we reach UpstreamVersionFreeze and FeatureFreeze.
[04:25] <persia> Does anyone know of a page like http://tiber.tauware.de/~lucas/versions/unimultiverse-outdated-ubuntu.html that is currently up-to-date?
[04:34] <ScottK> persia: Not me.
[04:35] <ScottK> persia: Any thoughts on my mail to devel-discuss on gpg-agent by default?
[04:36] <persia> ScottK: Hmm..  I'm thinking that because the automatic sync is stopped, it would be nice to see lots of sync bugs for good bugfixes in Debian.  I'm also thinking that the "Not in Debian" section of an updated http://tiber.tauware.de/~lucas/versions/all-packages.html would be a good target for investigation to determine which packages were removed from Debian, why, and why they might still be Ubuntu.
[04:36] <ScottK> persia: For the bug fixes, I think you want ajmitch's RC bug fix list.  Dunno if it's up to date or recall the url.
[04:37] <persia> ScottK: Regarding the GPG agent configuration, I don't have a strong opinion, but I don't use gpg-agent, but rather seahorse, and would prefer not to have any problems as a result.  I should probably test or something.
[04:38] <persia> ScottK: At this point, I'm not concerned if it's RC or not - it's not even UVF yet.  it's more that for the 2000 or so packages where we have a local patch, DaD and MoM do a good job of letting us know when there is a new Debian version to merge, but we don't have a tool to let us know when there is a new Debian version to sync.
[04:38] <persia> (for the 13000 or so other packages, that is)
[04:40] <minghua> persia: http://people.ubuntu.org.au/~fujitsu/motuscience/versions/ seems to be up-to-date, but only for science related packages.
[04:40] <ScottK> Right.  I realize the RC list isn't complete, but it'd be a good place to start.
[04:41] <persia> minghua: That's nice.  Only 18 packages outstanding :)
[04:42] <minghua> persia: Yeah, but I imagine most science packages are not updated very frequently anyway.
[04:42] <zakame> hi all
[04:43] <persia> minghua: Perhaps not, but still, it's only about 3-4% sync pending, with no removals pending (despite all the non-free data issues).  I doubt the rest of the archive is so clean.
[04:44] <minghua> persia: What non-free data issues?
[04:45] <persia> minghua: I thought I remembered hearing something about issues with science packages due to data often having odd licenses (even all-rights-reserved, except distribution), but I don't have a handy URL to a reference or anything.  Am I mistaken?
[04:46] <minghua> persia: I don't remember any such discussions on ubuntu-science or debian-science lists.
[04:47] <persia> minghua: It may not have been there (I don't follow those lists).  Hmmm...
[04:48] <minghua> persia: BTW we have a main -> non-free case as bugsx, bug 123640.
[04:48] <ubotu> Launchpad bug 123640 in bugsx "bugsx should be in multiverse" [Undecided,Confirmed]  https://launchpad.net/bugs/123640
[04:49] <ajmitch> ScottK: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html, updated nightly
[04:49] <persia> minghua: That's probably the source of my confusion: moving to non-free/multiverse vs. removing entirely.
[04:51] <persia> ajmitch: Is your parsing case-sensitive?  The entry for xmms2 confuses me.
[04:56] <superm1> _MMA_, are you here, or just a autoreconnect on your IRC client?
[04:56] <ScottK> doko: I'd like your concurrence with Bug #123677 before I subscribe ubuntu-archive.  I think it's the right thing to do.
[04:56] <ubotu> Launchpad bug 123677 in celementtree "Please sync celementtree 1.5-9 from Debian Unstable (Main)" [Undecided,New]  https://launchpad.net/bugs/123677
[04:58] <_MMA_> superm1: Im here
[04:58] <superm1> _MMA_, could you come to #ubuntu-mythtv for a moment?  I wanted to talk to you about some stuff that ubuntustudio had used in preparing the first release
[04:58] <_MMA_> k
[05:14] <ajmitch> persia: no, because it uses a specific (fast) python module for version comparison
[05:14] <ajmitch> so I'd need to lowercase it all before passing it in for comparison
[05:15] <persia> ajmitch: So it *is* case-sensitive (for performance reasons), hence xmms2, right?
[05:16] <ajmitch> I guess so
[05:16] <ajmitch> I preferred not to call out to dpkg for every package
[05:16] <persia> ajmitch: Ah.  Now I understand.  The case-sensitivity is dependent on the underlyining implementation, and invisible to the programmer.  Thanks.
[05:16] <crimsun> ScottK: thanks.
[05:18] <ScottK> crimsun: You're welcome.
[05:20] <StevenK> nixternal: Talk to pitti or keescook about your kvirc security issue.
[05:22] <ScottK> IIRC, keescook said he was going to be offline for a while.
[05:30] <Cybermatt> is there a way to automaticly insert the last line in a changelog entry
[05:31] <Cybermatt> you know --Myname <email@blah> line
[05:31] <RAOF> dch
[05:31] <Cybermatt> forgot what that called
[05:32] <RAOF> That's how you should be editing changelogs, anyway :)
[05:33] <Cybermatt> Problem executing dpkg-parsechangelog:
[05:33] <Cybermatt> uh-oh
[05:33] <Cybermatt> i messed up AGAIN
[05:33] <StevenK> Hey, that's my line!
[05:34] <Cybermatt> lol
[05:35] <ScottK> ajmitch: It's be nice (but not so nice I'm going to invest my meager html skills in it) if we could get comments on the RC bug list like are on DaD.
[05:35] <Cybermatt> first there was the time when i had to lintan | less so many errors
[05:35] <Cybermatt> when will i ever learn
[05:35] <Cybermatt> lol
[05:40] <Cybermatt> badly formated header line
[05:40] <Cybermatt> hmm
[05:42] <RAOF> Cybermatt: Remove all your changes to changelog, and re-add them with dch, it'll be easier :)
[05:44] <Cybermatt> now that funny there is an error in my example package
[05:44] <Cybermatt> dosbox
[05:44] <Cybermatt> fatal error line 432
[05:46] <Cybermatt> funny line 432 doesn't exist
[05:46] <Cybermatt> now what am i doing wrong
[05:48] <ScottK> Amazing how much better I do with passwords when caps lock isn't on...
[05:49] <Cybermatt> yes
[05:49] <Cybermatt> i will get sleep and pick this up tommrrow
[05:50] <Cybermatt> caps lock sucks
[05:50] <nixternal> StevenK: I went ahead and CC'd the MOTU and Security lists, as well as subscribed them to the bug accordingly
[05:51] <StevenK> nixternal: Ah, right.
[05:52] <StevenK> nixternal: Make sure the changelogs contain a fair bit of information about the vulnerability, along with CVE numbers and such.
[05:52] <nixternal> oh ya, they are loaded
[05:53] <nixternal> links and all
[05:53] <nixternal> I used my KTorrent package I did for Breezy-Feisty as a template, plus the security wiki page
[05:56] <nixternal> hehe, I followed keescook on the KTorrent one...w/o his help it would have been in shambles
[05:56] <nixternal> but for my first attempt it got approved, so you know he helped out big time :)
[05:57] <wfarr> Say I'm building a package (via cdbs) from subversion. What would I place inside "makebuilddir/foo" in order to have it run the ./autogen.sh in the source dir?
[06:15] <ScottK> Good night all.
[06:15] <nixternal> g'nite
[06:39] <RAOF> Anyone feel like sponsoring bug #114444
[06:39] <ubotu> Launchpad bug 114444 in gst-plugins-farsight "merge gst-plugins-farsight-0.12.1 from debian unstable" [Wishlist,Confirmed]  https://launchpad.net/bugs/114444
[06:41] <crimsun> I'm surprised you touch configure.ac instead of configure.
[06:41] <crimsun> wouldn't just configure and Makefile.in suffice?
[06:41] <RAOF> Maybe
[06:42] <RAOF> I can check if you like, it was my first "mess with auto*" package
[06:43] <crimsun> I would check, yes.
[06:52] <RAOF> Hm.  Just "configure Makefile.in" result in autoheader being run.  I'll try adding config.h.in, too?
[06:54] <crimsun> ok
[06:56] <RAOF> ok, that's worse :)
[06:56] <RAOF> It now tries to re-run everything
[07:00] <persia> It's all about the timestamps.  For safety, I recommend patching everything so that it doesn't have an issue depending on what actually gets regenerated on the buildd (but then the log isn't up to date, so I may be missing the necessary context for this to matter).
[07:02] <RAOF> Oh, everything is patched.  It'd just be cleaner if it didn't regen
[07:03] <RAOF> This isn't about making it work, fortunately :)
[07:11] <RAOF> Bah.  Is it really worth stripping the touch down to the minimal set, crimsun?  It's just cosmetic :-/
[07:11] <crimsun> I thought you were investigating the "minimal set" last week ;)
[07:12] <crimsun> if the debdiff is correct, however, you likely shouldn't waste any additional time
[07:12] <RAOF> It is correct :)
[07:12] <gpocentek> good morning Universe :)
[07:13] <Hobbsee> morning gpocentek
[07:13] <RAOF> Also, the patch is already upstream :)
[07:13] <gpocentek> hello Hobbsee
[07:31] <persia> Does anyone present have familiarity with ocaml-vorbis?  Liquidsoap depends on the new upstream, and has a couple serious bugs fixed in the BTS, but I'm not familiar enough with ocaml or vorbis to know if a new upstream would be too much headache at this point in the cycle.
[07:32] <minghua> Ocaml has a Debian team and a mailing list.
[07:33] <minghua> (That's probably all I know about Ocaml.)
[07:36] <persia> Well, they're probably focused on Lenny, which is safely further away than Gutsy, so I'm still not sure.  I guess I'll skip to the next on the list :)
[07:37] <man-di> persia: in debian everone except the release team works on unstable
[07:38] <StevenK> And there's one problem as to why it is so hard to release Debian.
[07:39] <persia> man-di: That's true for developers, but not end-users.  The last Debian shop I reviewed (maybe a month ago) was just migrating to Etch.
[07:39] <jmg> all the work i did in the field was using stable
[07:39] <man-di> persia: the Ocaml team are developers
[07:40] <jmg> when sarge went gold the first thing i did was s/stable/oldstable/ on all the boxes until we had validated the upgrade
[07:40] <StevenK> I tend to use the named releases in sources.list.
[07:40] <jmg> debian upgrades between major revisions are surprisingly painless until custom packages are involved.
[07:40] <man-di> jmg: that is why you should have done s/stable/sarge/
[07:40] <persia> man-di: Right.  So, the point remains, would the new upstream version of ocaml-vorbis better serve gutsy endusers?  I don't feel I have enough information to take a decision, although if someone else wants to file a sync, I won't complain.
[07:41] <man-di> persia: aah, you think this way
[07:41] <jmg> man-di: yeah, i think most of them were
[07:41] <man-di> persia: then I dont know
[07:42] <persia> man-di: Yeah.  Personally, I run fairly edgy code on my machines, but I respect the DebianImportFreeze: there'd be no chance of releasing gutsy on schedule if we just kept pushing things in, and hoping they didn't break (or if it was released, it would be like Edgy was, which isn't preferable).
[07:42] <StevenK> I didn't think Edgy was that bad, it was just rushed.
[07:43] <persia> StevenK: Perhaps - it seemed to me that there were more "It's fixed in feisty now" items than there were "It's fixed in Edgy" for Dapper, or "It's fixed in Gutsy" for feisty, but perhaps I have a skewed view of the buglist.
[07:44] <StevenK> Ah, I see.
[07:44] <minghua> Edgy was pretty bad on some fronts.  Input methods, for example.
[07:44] <jmg> heh
[07:44] <man-di> I didnt noticed Edgy was so bad
[07:44] <man-di> ;-)
[07:45] <RAOF> crimsun: Ta
[07:47] <peanutb> just a few weeks would have helped
[07:48] <Hobbsee> i wonder if they'll delay gutsy+1...
[07:48] <minghua> StevenK: Being rushed is exactly the reason it's bad.  There were simply not enough developers, let alone users, running the development branch.  The problem for edgy was particularly bad because the kernel/toolchain/X stuff settled down rather late in dev cycle, which scared away a lot of potential testers.
[07:49] <minghua> As a consequence, the often-used components/packages in edgy was fine because the main developers are using them, the others (such as input methods) are bad because it received little testing during the development cycle.
[07:49] <persia> So, now that it's history, I think the rush plan for Edgy was good.  At the beginning, there was a warning that it would be messy, and it was.  After the LTS work, it was nice to just push things in, and getting back on schedule for Feisty made for a really nice release.
[07:52] <minghua> Maybe we can skip a GNOME release with LTS and have two releases of 10+8 months dev cycles, instead of three release of 6 months each.
[07:53] <zakame> Hobbsee: re: Mithrandir-the-eater, this is a given :)
[07:53] <persia> minghua: There's too much pent-up desire to change after an LTS.  It's like the sid churn after a release, when it's often safer to stick with testing for a couple months.
[07:53] <Hobbsee> zakame: :)
[07:53] <zakame> so REVU-ers haven't been checking the inclusion of COPYING, et al. for some time now?!?
[07:53] <zakame> tsk tsk
[07:55] <minghua> persia: Yes.  The user base is just too diverse and you (at least I) can't tell if they prefer newer software or stability.
[07:56] <minghua> persia: So after LTS there are always going to be debates.
[07:57] <persia> minghua: I think those seeking crack should current-Ubuntu-dev (or sid), those seeking stability should use LTS (or stable), and those looking for a nice environment to try Linux should use the latest Ubuntu release (even LTS+1, despite the warts).
[07:58] <StevenK> I use LTS on server installs, and the current release on desktops.
[07:59] <persia> StevenK: Yes, but you're not a member of the target market for crack :)
[07:59] <StevenK> Heh
[08:05] <minghua> persia: IMHO that would be bad for development if the only non-developer users running dev branch are the crack-seeking people, it distorts the perspective of user needs.
[08:06] <StevenK> I think they're the only vocal ones. :-P
[08:07] <persia> minghua: While testing should be encouraged, my definition of "developer" is not ~ubuntu-dev, but rather the set of people contributing to Ubuntu who have the necessary skills to dig themselves out of most holes during the development process (even if this just means holding a couple packages back or downgrading one or two whilst things happen).
[08:09] <minghua> persia: Sure, but I doubt there are many such people.  Just look how many REVU uploaders are running feisty (seen by the lintian warnings that only gutsy lintian detects).
[08:09] <persia> minghua: For wider testing, the development snapshot CDs seem more appropriate than an actual install.
[08:11] <persia> minghua: That will shift over time.  The first couple snapshots are pretty rough.  After that, more installs tend to happen.
[08:11] <minghua> Yeah.  Usually we get quite some good bug reports immediately after beta CD is released.
[08:12] <Hobbsee> i wonder if we could get the last couple of tribes more stable
[08:12] <minghua> Many users like the word "beta". :-)
[08:12] <Hobbsee> probably tribe 6, where there are no more new packages in at all
[08:13] <persia> Hobbsee: I don't think there's much hope before 5, and there's usually loads of unmetdep processing before 6.
[08:13] <Hobbsee> true - depends how much of it gets done earlier
[08:14] <Hobbsee> which depends how much people get pushed to do it, etc.
[08:15] <persia> Hmmm..  For main, I suspect basic stability could be achieved by 4, if there was enough pressure after the sprint, but I don't think we have the tools in place to get universe in good enough shape by then.
[08:15] <ajmitch> s/tools/people/
[08:16] <Hobbsee> persia: what tools would be needed?
[08:16] <persia> ajmitch: No, tools.  At this point, we have ~10 very active contributors who would be happy to upload everything in sight, but they're all focused on MoM and DaD, as these are the easiest lists from which to grab easy work.
[08:17] <StevenK> I'm not focused on MoM and DaD, and I've been uploading everything I can.
[08:17] <Hobbsee> StevenK: you're doing stuff with the cruft check, etc.
[08:17] <zakame> lol'rents
[08:17] <Hobbsee> persia: what tools would be needed?
[08:18] <StevenK> Hobbsee: I know what I'm working on, thanks. :-P
[08:18] <persia> Hobbsee: Something that had a nice interface to track cruft, something to monitor sync candidates between DebianImportFreeze and UpstreamVersionFreeze, a better bug search interface (we miss *lots* of good patches each release), something to track removal candidates, for starters.  I'm sure there are more, but I haven't thought about it deeply yet.
[08:18] <Hobbsee> StevenK: well, yeah.  what i'm saying is that you're working with a tool that's already there, mostly for main, i believe?
[08:19] <Hobbsee> persia: think about it, and email me with a list, please
[08:19] <persia> StevenK: Yes, you've found a handy tool, but you still need to ask for manual regeneration every few hours, and it doesn't automatically seed.
[08:19] <StevenK> No, the archive cruft checker checks the entire archive.
[08:19] <persia> Hobbsee: OK.
[08:19] <minghua> I'd like to also add a list of upgrade (for feisty) failures.
[08:19] <Hobbsee> StevenK: right.  i thought it had a pretty decent interface it on it too
[08:19] <Hobbsee> minghua: well, we need to do testing, yes.
[08:20] <persia> Hobbsee: Most of the tools are written (or half written) already, they just need better workflow, etc.
[08:20] <Hobbsee> minghua: how's the best way, in your view to do regression testing?
[08:20] <Hobbsee> persia: true that.  or they need an explanation to go with the tools, on how to use each of htem.
[08:20] <StevenK> persia: What do you mean by doesn't automatically seed?
[08:21] <StevenK> persia: And pitti should be cron'ing archive-cruft-checker soonish.
[08:21] <StevenK> Hobbsee: What interface? :-)
[08:21] <minghua> Hobbsee: I don't really have a QA experience.  But is asking for regular piuparts runs (for both installation of gutsy and feisty->gutsy upgrade) too much?
[08:21] <Hobbsee> StevenK: well, the output on the web.  which is hardly an interface, true
[08:22] <persia> StevenK: Perhaps I'm incorrect, but I thought that there was a manual discussion component when deciding what is cruft (although libcurl4 may be a particularly bad example).  Also, the cronification would be part of why I said (written or half-written) before.
[08:22] <StevenK> Maybe upgrading testing should be discussed with mvo.
[08:22] <ajmitch> persia: ok, so what tools are you wanting to work on?
[08:23] <StevenK> persia: I thought it sorted out what was cruft itself, but I could be wrong.
[08:23] <minghua> Hobbsee: I'm sure right now the texlive parts will fail on upgrade spectacularly.
[08:23] <persia> ajmitch: heh.  I've got plenty to do with the tools I have (yours the a source of activity for me today), but it's really that they all need polish, and to be easier to find and use.
[08:23] <Hobbsee> it can find cruft automatically, yes.
[08:24] <ajmitch> persia: what needs improved with mine? case sensitivity & comments?
[08:24] <persia> StevenK: You've been working with it, so perhaps you're correct.  I'm just making wild assumptions based on IRC chatter.
[08:24] <minghua> ajmitch: debdiff would be nice. :-P
[08:25] <ajmitch> minghua: even though debian may be a few upstream versions ahead?
[08:25] <persia> ajmitch: Those two, a link to the Ubuntu changelog would be nice, as well as a copyable URL for dget.
[08:26] <StevenK> A URL that isn't a link so it can be double-clicked in Firefox.
[08:26] <minghua> ajmitch: I was not really working on your list.  So my opinion doesn't matter much.  But maybe only debdiffs with the same upstream version.
[08:26] <ajmitch> StevenK: for both ubuntu & debian versions?
[08:27] <persia> minghua: I don't think debdiffs would help much.  My workflow has been: check for Ubuntu bugs, try a build of Debian, check the rdepends, request a sync.  No debdiff involved.
[08:27] <StevenK> ajmitch: Yeah, I think so.
[08:28] <Hobbsee> persia: see https://wiki.ubuntu.com/ArchiveAdministration
[08:29] <minghua> persia: Okay.  You are the real user.  ajmitch: You can ignore me now. :-)
[08:29] <persia> Hobbsee: What am I looking for?
[08:30] <Hobbsee> persia: cruft check
[08:31] <Hobbsee> persia: as in, that it really is automatic to generate that list
[08:32] <ajmitch> persia: ok, refresh the rc page
[08:32] <persia> Hobbsee: Ah.  I see now.  Thanks.
[08:32] <ajmitch> you'll see that the URL makes it far too wide
[08:33] <Hobbsee> it appears that lucas ran a puiparts run for feisty
[08:33] <Hobbsee> i'm not sure how much we ever did with this
[08:34] <persia> ajmitch: I see how.  How about a link from which I must right-click copy?  Also, I'm generally more interested in the Debian package, as I can use apt-get source for the Ubuntu version.
[08:34] <persia> s/how/now/1
[08:35] <ajmitch> refresh
[08:36] <ajmitch> fwiw, if someone wants to do a different html page for it, feel free
[08:36] <ajmitch> http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.txt <-- a different script generates this
[08:36] <persia> ajmitch: Cool.  Thanks.  The "Debian .dsc" header is missing, but otherwise that looks nice.
[08:37] <ajmitch> fixed that
[08:37] <Hobbsee> persia: sync candidates between DebianImportFreeze and UpstreamVersionFreeze <-- would that just be keeping MOM running?
[08:39] <persia> Hobbsee: As far as I can tell, MoM only reports on things that were once uploaded to Ubuntu (not synced).  Am I incorrect?  If I'm wrong, keeping MoM running would do the job nicely: in fact, I'd like to see it keep running all the way until StringFreeze.
[08:40] <StevenK> MoM reports on things that have current Ubuntu changes.
[08:40] <minghua> We need Sync-o-Matic.
[08:40] <persia> Right.  That's great for the 15-20% of the packages we touch, but doesn't help for the other 80-85%.
[08:41] <ajmitch> persia: what criteria would you use for sync candidates?
[08:42] <persia> ajmitch: I'd just want something like Lucas' multidistrotools output on tiber refreshed daily.  Individuals would be responsible for determining if it was a good candidate.  Having something more advanced (say, with comments), would be better - sync this, we don't need the fixes from 2.7.23-72 (the maintainer uploads every day), etc.
[08:42] <ajmitch> persia: you want me to run mdt on my box as well?
[08:42] <ajmitch> it wouldn't be much overhead
[08:43] <persia> ajmitch: Do you have the space and bandwidth?  If so, that's be great.
[08:43] <ajmitch> I'd probably push pages somewhere with bandwidth
[08:43] <ajmitch> so generate locally & rsync static pages to a remote box with lots more bandwidth than NZ :)
[08:44] <Hobbsee> persia: ah right, yes, i see.
[08:44] <persia> ajmitch: As long as the URL is well advertised (MOTU/TODO maybe), I'd be happy, and I suspect those competing over merges, wouldn't mind hunting sync candidates (plus, it's a good way to demonstrate the ability to review patches for suitability, rather than just applying them).
[08:44] <ajmitch> sure, I'll create motu.ajmitch.net.nz
[08:46] <persia> ajmitch: Great, thank you.
[08:47] <Hobbsee> so far, i'm failing to see what it actually does, that helps us with testing.
[08:48] <persia> Hobbsee: Debian fixes bugs.  If we know they fixed them, (even non-RC bugs), it makes sense to check to see if we've fixed them.  If not, we probably should fix them.
[08:49] <ajmitch> persia: btw my list isn't just for rc bugs
[08:49] <Hobbsee> persia: sure, but how does mdt in particular help with that?
[08:49] <Hobbsee> persia: oh, that's listing the packages that are out of date and whatnot?
[08:49] <StevenK> Debian fixes bugs? I thought they only bitched about things that don't matter.
[08:49] <Hobbsee> heh

[08:49] <Hobbsee> StevenK: BAD DD!!!
[08:49] <persia> Hobbsee: I find it a handy interface to see what is out of date, and can check changelogs.  It's manual, but currently I'm blind except for RC fixes.
[08:50] <Hobbsee> persia: right.
[08:50] <Hobbsee> persia: so put in a script that can be fed to cron would be fairly useful.
[08:50] <persia> StevenK: I see *lots* of bugs fixed in Debian.  Especially for universe leaf packages.  Be bitter for main, but for universe, Debian provides us with 2000 extra MOTUs.
[08:50] <Hobbsee> as opposed ot having to run each bit manually
[08:50] <StevenK> It is nowhere close to 2,000.
[08:51] <StevenK> persia: I was making a joke, too. :-)
[08:53] <ajmitch> examples/all-reports.bash: /home/ajmitch/debian/ubuntu/scripts/multidistrotools/mdt: /usr/bin/ruby1.8: bad interpreter: No such file or directory
[08:53] <ajmitch> badness
[08:53] <StevenK> Ruby isn't pollution!
[08:53] <ajmitch> apt-get --purge remove perl*

[08:54] <StevenK> Works for me.
[08:54] <ajmitch> no doubt mdt would run ok on dapper, which is what the box I'll upload to is running
[08:55] <Hobbsee> but why do we care about dapper?
[08:55] <ajmitch> because I run servers with dapper installed?
[08:55] <persia> Hobbsee: Dapper base, Gutsy data.
[08:55] <Hobbsee> i meant w.r.t mdt
[08:55] <Hobbsee> persia: ah right.
[08:58] <StevenK> I have uploaded far too much over the last two days.
[08:59] <persia> StevenK: Nah.  You're just providing my hard drives with exercise :)
[08:59] <StevenK> The last 45 of 46 mails in my INBOX are Accepted mails, with 1 being a build failure on ia64.
[09:01] <dholbach> good morning
[09:02] <ajmitch> hi dholbach
[09:02] <dholbach> hey ajmitch
[09:03] <Hobbsee> good mornign dholbach!
[09:03] <dholbach> hey Hobbsee!
[09:04] <gpocentek> hello dholbach, ajmitch, StevenK, persia...
[09:04] <persia> gpocentek: Good morning
[09:04] <dholbach> hey gpocentek
[09:04] <dholbach> hey persia
[09:04] <dholbach> how's it going guys?
[09:05] <Hobbsee> dholbach: we're plotting evil things.
[09:05] <ajmitch> world domination
[09:05] <ajmitch> or fixing bugs
[09:05] <ajmitch> whichever is easier
[09:05] <persia> dholbach: Hi.
[09:05] <ajmitch> hello gpocentek
[09:05] <dholbach> neat-o - what's going to happen? where are the new contributors in the world domination plan?
[09:06] <Admiral_Chicago> everning everyone
[09:06] <Hobbsee> dholbach: getting some scripts, etc, run, so we have more of an overview about universe.
[09:07] <dholbach> sounds like a good idea... what would those scripts do?
[09:09] <persia> dholbach: Bascially, track Debian better, so we can take advantage of more Debian work.  There's more that would be good, but we're just getting organised now.
[09:09] <dholbach> track debian better is a good thing - yes
[09:09] <dholbach> what do you think about  https://wiki.ubuntu.com/DesktopTeam/WeeklyTODO ?
[09:10] <dholbach> we plug that in several DesktopTeam pages
[09:10] <dholbach> what about having something like that for MOTU too?
[09:10] <persia> ajmitch: What do your scripts look like now?
[09:11] <dholbach> like clean out all democracyplayer bugs, make abc transition, get 10 REVU uploads into NEW, etc as a weekly goal we invite everybody to help out
[09:11] <dholbach> (and mentor new contributors through those tasks)
[09:11] <persia> dholbach: We need more automation.  10,000 packages are too many for that type of list.
[09:11] <dholbach> persia: that's why that's a manually compiled of select tasks
[09:11] <persia> dholbach: On the other hand, if you're volunteering to compile it, it'd be a great help :)
[09:12] <dholbach> you know that doesn't scale
[09:12] <dholbach> I'm happy to help out with that
[09:12] <ajmitch> persia: oh they generate text, but I turn that into something nicer
[09:12] <dholbach> but we need to think more in terms of 'this is a task, I'd like the whole team and new contributors to work on'
[09:12] <persia> ajmitch: Ah.  mdt is the only thing I've used, so if you're showing something new, I'd likely have interface comments.
[09:12] <ajmitch> persia: of course
[09:13] <dholbach> so if one of the packages you really like has a lot of bugs, ask MOTUs to help with it
[09:13] <ajmitch> that's been something on my wishlist for awhile
[09:13] <dholbach> I got the idea from https://wiki.ubuntu.com/UbuntuBugDay/20070627
[09:13] <dholbach> it's a list of *achievable* tasks
[09:13] <lucas> I think I'll just run multidistrotools on gluck instead of tiber
[09:13] <ajmitch> ah, lucas is alive
[09:14] <Hobbsee> yay, lucas!
[09:14] <Hobbsee> lucas: how portable are those scripts?
[09:14] <lucas> "portable"?
[09:15] <Admiral_Chicago> can they fit in my pocket? run on my DS?
[09:15] <Admiral_Chicago> err...
[09:15] <Hobbsee> as in, they're not tied to one particular machine, presuambly?
[09:15] <lucas> not too much
[09:15] <Hobbsee> right
[09:16] <Admiral_Chicago> if I use a tool like dh_make do I need to change the rules file still or does dh_make do that
[09:16] <Hobbsee> lucas: query?
[09:16] <ajmitch> Admiral_Chicago: dh_make only gives you a template to start from
[09:16] <Admiral_Chicago> it has two lines, one reads "include /usr/share/cdbs/1/rules/debhelper.mk" so i'm curious
[09:16] <lucas> Hobbsee: I don't see a query here:)
[09:16] <Admiral_Chicago> ajmitch: ah
[09:16] <lucas> ah
[09:16] <Hobbsee> lucas: because i only just sent it :P
[09:17] <Admiral_Chicago> i'll ry my hand at that this file then
[09:31] <Admiral_Chicago> superm1: wb, i tried the package and I got the error that pam headers were needed
[09:32] <Admiral_Chicago> ah i see, i didn't include a Depends line :o
[09:35] <Admiral_Chicago> no, still getting the error...
[09:35] <\sh> libpam-dev as build dep?
[09:36] <minghua> Why do we have azureus in REVU?
[09:36] <Admiral_Chicago> its a dependency in the source
[09:37] <Admiral_Chicago> does it need to be in build dep too?
[09:37] <\sh> Admiral_Chicago: a dependency or a build-dependency? there is a difference
[09:37] <\sh> Admiral_Chicago: when you build it, for sure...please read the debian new package maintainers guide about the different fields in debian/control, thx
[09:37] <Admiral_Chicago> i did't include it in the dependency. it was never in build-dep
[09:37] <persia> ajmitch: I just finished my queue of things already downloaded, and the dget URLs for Debian are generating 404s.  No rush, but when you have a chance, adjusting this would be handy.
[09:38] <Admiral_Chicago> and i get the same output regardless when running pbuilder so I'm thinking I missed something
[09:38] <ajmitch> persia: tell me what's wrong with them
[09:39] <\sh> Admiral_Chicago: yes, a build-dep
[09:39] <\sh> Admiral_Chicago: and regarding your error message, it needs libpam-dev as build-dep, without that, you won't include pam include headers  in your build source
[09:39] <Admiral_Chicago> ah that's why then
[09:39] <Admiral_Chicago> okay, i'll give that a shot. thanks \sh
[09:41] <persia> ajmitch: missing pool ("http://http.us.debian.org/debian/main/n/nepenthes/nepenthes_0.2.0-2.dsc" should be "http://http.us.debian.org/debian/pool/main/n/nepenthes/nepenthes_0.2.0-2.dsc")
[09:42] <ajmitch> ah, pool, of course
[09:46] <ajmitch> persia: fixed that
[09:46] <persia> ajmitch: Great.  Thanks  (nepenthes is still building, but I'll use it for the next one).
[09:48] <persia> ajmitch: That works perfectly.  Thanks again.
[09:48] <ajmitch> np
[09:50] <persia> ajmitch: Comments are the next goal - a lot of these FTBFS on gutsy.  It's easy for me to skip them, but it'd be nice if the next person could see when it broke for me.
[09:50] <ajmitch> yeah I know
[09:50] <ajmitch> I'm working on it
[10:13] <BugMaN> hi all
[10:13] <Hobbsee> hi BugMaN
[10:13] <BugMaN> hi Hobbsee :)
[10:13] <Hobbsee> persia, ajmitch, anyone else who was interested ^
[10:18] <ajmitch> yes?
[10:18] <Hobbsee> ajmitch: mailing list post about the archive tools, and waht might be useful.  please look, think, and respond.
[10:18] <ajmitch> k
[10:40] <jerome_> hello all
[10:40] <jerome_> could a motu have a look a bug 51767 ?
[10:40] <ubotu> Launchpad bug 51767 in mosml "can't load Gdbm, missing libmgdbm.so" [Low,Triaged]  https://launchpad.net/bugs/51767
[10:42] <persia> jerome_: I think that's only a tiny portion of bug 78367
[10:42] <ubotu> Launchpad bug 78367 in mosml "extend mosml package to include optional libraries (patch included)" [Wishlist,New]  https://launchpad.net/bugs/78367
[10:43] <jerome_> persia : i'm having a look
[10:44] <jerome_> persia : well you are right :) don't say anyone that i triaged the other bug too...
[10:45] <persia> jerome_: They just need a debdiff, and someone who understands mosml to give them a nod.  If you want to push your testing of 78367 a little further, and spin a debdiff for a new candidate revision, I'd be glad to upload.
[10:46] <jerome_> persia : the problem is that the pach is IMO quite ugly, when I builded it it resulted with a bunch of errors of lintia and linda
[10:46] <jerome_> persia : and I think I don't have the knowledge to clean that mess
[10:47] <persia> jerome_: Yep.  That's why the bugs are open :)  http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html is probably a good source of information on how it could be better.
[10:47] <persia> jerome_: Please ask here with questions - we can help clean the mess, but we don't necessarily know about mosml.
[10:48] <jerome_> persia : ok, I can't do that today, it's too long, but as soon as I have time I'll be on it
[10:48] <persia> jerome_: Great.  Thanks.
[10:48] <jerome_> persia : np
[11:06] <jerome_> persia : i had a look, and for the time being this is too complicated for me
[11:07] <jerome_> persia : i've only packaged once, and it was an easy upgrade
[11:07] <persia> jerome_: Thanks for looking.  I'm happy to help, I just don't know enough about mosml to know if the clean package works.  Let me know when you feel confident enough to get back to it.
[11:08] <jerome_> persia : ok, i will
[11:10] <doko> ScottK: "Add debian/add python-celementtree.install" -> "Add debian/python-celementtree.install", but looks fine otherwise
[11:13] <persia> ajmitch: When you have a chance, consider stripping epochs from dget URLs
[11:17] <lucas> Hobbsee: what does the cruft checker do?
[11:18] <Hobbsee> lucas: http://people.ubuntu.com/~pitti/tmp/cruft/
[11:18] <persia> lucas: Hunts for NBS, and reports rdepends.
[11:18] <Hobbsee> lucas: tells what packages are still dependant on old packages that are about to be removed.
[11:18] <Hobbsee> yeah, that
[11:18] <lucas> ok
[11:26] <jerome_> when there are problems with a .desktop file, it's an upstream problem, or an ubuntu/packaging one ?
[11:26] <white> jerome_: depends
[11:26] <jerome_> on ?
[11:26] <white> jerome_: was it added in the debian dir?
[11:26] <lucas> on who wrotethe .desktop file :)
[11:26] <white> jerome_: it is always great to send it to upstream anyway :)
[11:26] <persia> jerome_: It's an upstream problem, but some don't really care much, in which case it becomes a Debian/Ubuntu problem (or maybe just Ubuntu).
[11:26] <white> jerome_: and if it is broken, even with patch :)
[11:27] <jerome_> white, lucas : having a look :)
[11:30] <persia> lucas: Thank you (for mdt)
[11:30] <lucas> np
[11:30] <jerome_> white, persia, lucas : the .desktop file is created in a patch
[11:31] <jerome_> bug 123708
[11:31] <ubotu> Launchpad bug 123708 in gdhcpd "gnome menu entry incorrect" [Undecided,New]  https://launchpad.net/bugs/123708
[11:31] <white> jerome_: if it is a patch from the packaging, then i would suggest to fix it and send a working .desktop file upstream :)
[11:31] <persia> jerome_: Fix it for Ubuntu (and submit a debdiff), send the patch to Debian, and update the upstream bugtracker with the improved .desktop file.
[11:31] <jerome_> if you think the changes proposed in the bug are ok, i will be happy to rpovide a debdiff
[11:31] <jerome_> but i'm not sure with the fixes proposed, anyone could confirm ?
[11:32] <persia> jerome_: It needs more work than just that: run desktop-file-validate to get a list of issues.
[11:32] <white> launchped is slow :(
[11:33] <white> unified diffs are always nice :)
[11:33] <jerome_> persia : on the desktop file installed by the package on my system ?
[11:34] <persia> jerome_: Either that, or the desktop file included in the debian/ directory in the source.  You'll need to fix it in the source, but the files should be the same.
[11:34] <persia> (excepting possible translations)
[11:38] <persia> ajmitch: Also, your debian dget URL is based on the version that fixed the bug, rather than the current Debian version, which breaks when Debian updates again.
[11:39] <jerome_> persia : if i put Categories=Application;GTK;System;
[11:39] <jerome_> with Network between Application and GTK is it ok ?
[11:40] <persia> jerome_: I'm fairly sure "Application" is deprecated.  Try with desktop-file-validate (from desktop-file-utils) and check http://standards.freedesktop.org/menu-spec/latest/apa.html just to be sure.
[11:42] <jerome_> persia : and gksudo instead of su-to-root -x -c is fine ?
[11:44] <persia> jerome_: That's a harder question.  su-to-root is the generic Debian solution.  A lot of Ubuntu uses gksudo or gksu, but I'm not sure if it works for Kubuntu or Xubuntu.  Look for a ,desktop file for a similar application, or ask someone else.
[11:45] <jerome_> persia : the ouput of validate is http://pastebin.ca/601125
[11:46] <white> ubuntu changed its aims?
[11:46] <persia> jerome_: Right.  So, if you follow those instructions, you'll get a valid desktop file.
[11:46] <white> [WWW]  Ubuntu : Debian team aiming at collaboration between Ubuntu and Debian
[11:46] <white> https://wiki.ubuntu.com/DebianCollaboration
[11:46] <StevenK> That should be Utnubu
[11:46] <StevenK> persia: Beat me to it. :-)
[11:47] <white> :)
[11:47] <jerome_> any pro of gksu/gksudo and desktop files here ?
[11:47] <persia> StevenK: You had more characters to type on IRC first :)
[11:47] <jerome_> for bug 123708
[11:47] <ubotu> Launchpad bug 123708 in gdhcpd "gnome menu entry incorrect" [Low,Triaged]  https://launchpad.net/bugs/123708
[11:47] <persia> white: check again :)
[11:49] <white> persia: bah you fixed it :(
[11:51] <persia> 118 hours to the next REVU day :)
[11:53] <jussi01> good morning everyone!
[11:54] <ajmitch> morning jussi01
[11:55] <jussi01> hiya ajmitch
[11:55] <ajmitch> persia: apologies, I don't actually have the data as to which is the current debian version when that script runs
[11:56] <imbrandon> how do you make a daemon log to its own file rather than messages
[11:56] <imbrandon> hrm
[11:56] <persia> ajmitch: No worries.  If you're keeping a buglist for a future rewrite, please make a note.  If not, that's life :)
[11:58] <persia> ajmitch: I don't suppose you could use the same variable that generates the "current Debian version"?  Perhaps by juggling the columns?
[11:58] <ajmitch> can you try http://motu.ajmitch.net.nz/ & see if it actually works?
[11:58] <persia> ajmitch: It appears to be an advertisement for a photo management system.
[11:58] <ajmitch> 'current' debian version isn't really the current one
[11:58] <ajmitch> hah
[11:58] <ajmitch> you added a comment?
[11:59] <ajmitch> ok, good, it shows up
[11:59] <persia> ajmitch: I added a comment, but it said you added it :)
[11:59] <ajmitch> sure, that's because there's no logging in here...
[12:00] <persia> ajmitch: Makes sense.  I think I'd prefer anonymous comments to logging in, but if the cookies have reasonable persistence, I don't mind.
[12:00] <ajmitch> yeah, this was just whipped together tonight
[12:01] <persia> ajmitch: It's looking nice for an evenings' effort then :)
[12:01] <ajmitch> first time doing anything with django, it doesn't seem too bad
[12:01] <ajmitch> everything is in the database, so I'd need to populate the db by various scripts
[12:01] <ajmitch> probably on a cron job
[12:03] <persia> ajmitch: That'd be cool, but I'd suggest production might want to be somewhere other than NZ if it has all the features :)
[12:03] <ajmitch> other that on my home dsl? ;)
[12:03] <ajmitch> it's nice & fast to load for me..
[12:03] <persia> ajmitch: Not to denigrate your excellent internet provider, but the Pacific is wide...
[12:03] <ajmitch> haha
[12:03] <ajmitch> and the pipes are narrow..
[12:04] <persia> ajmitch: And from about 03:00 my time, completely clogged for nine or ten hours.
[12:05] <persia> OK.  Syncs filed for all the serious bugs that a sync can fix.  Now for grave...
[12:05] <ajmitch> thanks
[12:05] <ajmitch> then you can move onto important & normal
[12:05] <persia> ajmitch: They don't appear on the page :(
[12:06] <ajmitch> http://ajmitch.net.nz/~ajmitch/missing-fixes-important.html
[12:06] <ajmitch> http://ajmitch.net.nz/~ajmitch/missing-fixes.html for the full list
[12:06] <persia> ajmitch: Ah.  Thanks.  Some of the importants are being hit accidentally by the serious ones, so I suspect top-down is definitely the way to go :)
[12:07] <ajmitch> it just happened that the RC list was the most useful, so it got noticed
[12:07] <persia> ajmitch: Rather, that's the URL you pasted earlier when I was trying to find a reason not to merge freqtweak :)
[12:07] <ajmitch> it should be a constant task anyway
[12:12] <imbrandon> ajmitch, if you need a home for that project later lemme know i'm sure i could give ya  bit-o-space with cron access etc
[12:12] <imbrandon> brb smoke break
[12:12] <ajmitch> imbrandon: please, that'd be great
[12:12] <ajmitch> I wanted to put stuff on ubuntuwire.com boxes, but found they were down
[12:12] <gnomefreak> persia: nspluginwrapper is done and asac will sponser it and upload if sane.
[12:13] <imbrandon> np, what all do you need? ssh / cron / web / django ?
[12:13] <ajmitch> yeah, do I not have root access now?
[12:13] <imbrandon> yea you do on everything but my webserver
[12:13] <ajmitch> ah right
[12:13] <imbrandon> if you want to use aurora your more than wecome to use it, i got it back up last night
[12:13] <imbrandon> perminatly
[12:13] <asac> persia: gnomefreak ack ... anyway, if anyone else wants to sponsor ... don't wait for me ... just let me know so we don't dupe it ;)
[12:14] <persia> gnomefreak: Ah.  It's still listed as "In Progress" and assigned to you, but in the sponsors queue.  Do you want it uploaded, or dropped from the queue pending asac?
[12:14] <ajmitch> excellent
[12:14] <ajmitch> aurora might be better
[12:14] <imbrandon> k
[12:14] <asac> persia: what queue are you referring to?
[12:14] <ajmitch> what was wrong with it?
[12:14] <imbrandon> go for it then, its all ready for you to do whatever on
[12:14] <imbrandon> it has some heat issues
[12:14] <imbrandon> had*
[12:14] <persia> asac: https://bugs.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs
[12:14] <ajmitch> ouch
[12:14] <ajmitch> replaced some fans?
[12:14] <imbrandon> yea and a cpu
[12:14] <ajmitch> heh
[12:15] <imbrandon> has a 2.6 p4 in it now
[12:15] <ajmitch> I'll bash it hard & see if if stays up then
[12:15] <imbrandon> :)
[12:15] <ajmitch> still just exploring django, only been using it for a day or two :)
[12:15] <ajmitch> so I don't know if I'll stick with it
[12:15] <ajmitch> but if I need something else I'll install it & make sure it doesn't break
[12:15] <asac> persia: ah i see ... its the debdiff against latest debian ... is that always obvious or should gnomefreak drop that info to the bug?
[12:16] <imbrandon> heheh you might have to install django, apache/lighttpd should be installed but not sure what else as far as web stuff
[12:16] <ajmitch> installing django is simple enough
[12:16] <persia> asac: That's standard procedure for a merge.  It's expected that manual merges (differing orig.tar.gz) will have a note.
[12:16] <ajmitch> tcp        0      0 <IP_ADDRESS>:80              <IP_ADDRESS>:*               LISTEN     4905/lighttpd
[12:16] <ajmitch> ok, I'll see what I can do with this
[12:16] <asac> persia: ok ... thats fine then
[12:16] <imbrandon> ahh you can change to apache if you wish, i use that for -0- websites
[12:17] <asac> persia: i will ack the debdiff then ... and see if anyone else grabs it ... otherwise i will push later today
[12:17] <imbrandon> it was only used when i got dugg and neeed a mirror
[12:17] <imbrandon> for a few hours
[12:18] <persia> asac: No ACK required.  It's just that https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue indicates we're supposed to leave "In-Progress" bugs alone.
[12:18] <ajmitch> doesn't worry me
[12:18] <imbrandon> ajmitch, apache2 is probably installed and is chmod -x /etc/init.d/apache2
[12:18] <imbrandon> anyhow brb smoke break
[12:18] <persia> gnomefreak: If you want it uploaded, just set to "Confirmed", and unassign yourself.  Current queue time is around 12-15 hours, except for things nobody wants to touch.
[12:20] <gnomefreak> persia: he still has to update his branch im waiting to find out saneness of it
[12:21] <persia> gnomefreak: OK.  Sounds fine.  I'll drop it from the queue then (it doesn't sound like you want the debdiff uploaded directly).
[12:21] <gnomefreak> no not yet
[12:21] <bluekuja> heya persia
[12:21] <persia> bluekuja: Hello.
[12:21] <asac> persia: so why hasn't bug 121549 been uploaded by someone? is the state or something wrong?
[12:21] <bluekuja> persia: I'm trying to understand what you mean with quodlibet
[12:21] <ubotu> Launchpad bug 121549 in mplayerplug-in "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec " [Low,Confirmed]  https://launchpad.net/bugs/121549
[12:21] <gnomefreak> it was first merge so im really looking foward to the saneness check
[12:22] <persia> gnomefreak: OK.  No problems.  I just try to keep the queue small :)
[12:23] <bluekuja> persia: it was an ubuntu change, so it needs to be reported as new, not remaining
[12:23] <gnomefreak> persia: understood
[12:23] <bluekuja> persia: as far as we are dropping it (fix included in upstream)
[12:23] <persia> bluekuja: It's my understanding (and I would appreciate correction if I'm wrong), that user-invisible Ubuntu changes that are dropped by a merge do not require a comment in the changelog.
[12:24] <bluekuja> persia: yeah, that's it
[12:24] <asac> persia: actually i think commenting that you dropped an ubuntu change is good
[12:24] <bluekuja> someone got a suggestion for this?
[12:24] <asac> persia: so you can later verify if it has been dropped intentionally
[12:24] <bluekuja> thanks asac
[12:24] <asac> persia: at best stating the reason why the change wasn't needed anymore
[12:25] <persia> asac: Even for user-invisible changes?  OK.  That rationale makes sense.
[12:25] <asac> changelog is not for user
[12:25] <asac> but for mergers/motus
[12:25] <persia> asac: I disagree entirely with that.  As a user, I relied on the changelogs to determine if I wanted to upgrade the package, and what it would mean.
[12:25] <asac> yeah ... anyway ... normal users don't look at changelog
[12:26] <persia> bluekuja: What was the bug number again?  Based on asac's reasoning about the change, I think your last debdiff was probably good.
[12:26] <Fujitsu> persia: For stable updates, perhaps. For development releases users are unlikely to see them.
[12:26] <persia> Fujitsu: True, but what happens when the server is upgraded later :)
[12:27] <Fujitsu> persia: Then you probably don't want to look through several hundred changelogs.
[12:27] <bluekuja> persia: seems 123610
[12:27] <persia> bug 123610
[12:27] <ubotu> Launchpad bug 123610 in quodlibet-plugins "Merge quodlibet-plugins (20070625-1) from debian unstable" [Undecided,Confirmed]  https://launchpad.net/bugs/123610
[12:28] <bluekuja> yup
[12:28] <persia> bluekuja: Thanks.  I'll check one more time, and upload.
[12:28] <bluekuja> persia: k thanks, sorry for that html error
[12:28] <bluekuja> did not mark it as a patch^^
[12:29] <bluekuja> persia: I'm working on mail-notification FTBFS fix
[12:29] <persia> bluekuja: No problem.  You can also delete attachments from launchpad if they no longer apply.  Look in the Bug Attachments menu on the left side.
[12:29] <bluekuja> persia: oh cool
[12:29] <bluekuja> thanks for the hint
[12:32] <persia> bluekuja: Upstream was too fast.  Sorry.  Try again :)
[12:33] <bluekuja> persia: for mail-notif?
[12:33] <persia> bluekuja: For quodlibet.
[12:34] <bluekuja> persia: what's the problem?
[12:34] <persia> bluekuja: New upstream, released in Debian.
[12:34] <bluekuja> lol
[12:34] <bluekuja> cool
[12:34] <StevenK> 1 point uh-oh, too
[12:35] <persia> StevenK: It's better than SVN snapshot though, no?
[12:36] <StevenK> Depends. ;-)
[12:36] <bluekuja> persia: what's latest version?
[12:36] <StevenK> rmadison still reports 1.0-1 in unstable/
[12:36] <StevenK> s/\//./
[12:37] <persia> bluekuja: http://packages.qa.debian.org/q/quodlibet.html
[12:38] <bluekuja> persia: the package was quodlibet-plugins, why you pointed me to that?
[12:39] <persia> bluekuja: Because I can't read.  Let me try that again.  Thanks for the correction.
[12:39] <bluekuja> np
[12:54] <DarkMageZ> LongPointyStick, are you running x64?
[12:58] <persia> DarkMageZ: I believe the wielder of the stick is away for a while.
[12:58] <DarkMageZ> ah. well then, any x64 amarok edgy/feisty users? preferably with a pbuilder environment?
[12:59] <dholbach> Did some of you check out http://www.ubuntu.com/employment#ISVPPS already and see if it'd be something for you?
[01:02] <jussi01> dholbach: yeah, we had that spam the other day :P
[01:02] <persia> heh
[01:03] <dholbach> jussi01: spam? :)
[01:03] <jussi01> hehhe, playing with you ;)
[01:04] <dholbach> where was a mail regarding that already?
[01:05] <persia> (hides9
[01:05] <jussi01> lol
[01:06] <dholbach> I think it'd be great to have applications from Ubuntu contributors who have proved themselves
[01:06] <ajmitch> dholbach: I've already tried applying for a job once, and got a resounding silence after the "thanks, we'll look at it"
[01:07] <ajmitch> so I hold no expectations
[01:07] <dholbach> ajmitch: I'm sorry to hear that - I know that the processes have improved dramatically from then on
[01:07] <imbrandon> ajmitch, same here , hehe
[01:07] <ajmitch> dholbach: from when?
[01:08] <dholbach> when was that?
[01:08] <imbrandon> dholbach, this was at UDS-MTV sooo not that long ago
[01:08] <ajmitch> dholbach: well I got as far as an interview at UDS, 2 months ago
[01:08] <ajmitch> and heard nothing since
[01:08] <dholbach> I'm obviously not involved in that process myself, but I'll hear back what's going on
[01:08] <imbrandon> as did i at uds-mtv and nothing since
[01:09] <imbrandon> hehhe
[01:09] <ogra> imbrandon, UDS-MTV is ages ago
[01:09] <ajmitch> years ago
[01:09] <ogra> :)
[01:09] <imbrandon> lol
[01:09] <imbrandon> moins orga
[01:09] <ajmitch> it's not even within recent memory
[01:09] <ogra> hey hey
[01:09] <ajmitch> but I think that may have been the alcohol speaking
[01:09] <ajmitch> hi ogra :)
[01:10] <imbrandon> ajmitch, hahahaha
[01:10] <dholbach> I merely pointed out that I think the position I mentioned might be a good one for contributing MOTU - over and out :)
[01:10] <ajmitch> dholbach: we're not bitter ;)
[01:10] <persia> dholbach: Thanks for mentioning it :)
[01:10] <imbrandon> dholbach, hehe thanks
[01:11] <imbrandon> ajmitch, i drank wayyyyyy to much some nights
[01:11] <ajmitch> imbrandon: I make sure I don't :)
[01:11] <ajmitch> though that last night was quite fun
[01:11] <imbrandon> :)
[01:12] <imbrandon> i dunno , when jono told me to turn arround in the bar and check out ... " that woman with two, .. count them, ... two teeth" was classic
[01:12] <ajmitch> haha
[01:14] <RainCT> have you seen the "Help with research on Ubuntu community" mail? (the attachment ^^)
[01:16] <dholbach> RainCT: yes, replied to it this morning
[01:17] <RainCT> about the questions or the attachment? :P
[01:18] <dholbach> to the questions :)
[01:18] <dholbach> I was too pragmatic to bother
[01:23] <RainCT> cool, just discovered that GMail can show .doc files as HTML (altough, I'm not a MOTU anyways :p)
[01:28] <imbrandon> dholbach, plus i dont wanna move to canada
[01:28] <imbrandon> heheh
[01:28] <imbrandon> i guess i could request to telecommute
[01:29] <imbrandon> but i dunno if i would be considered "strong" because i'm not a DD only a ubuntu(-core)-dev , hrm *thinks*
[01:29] <Burgundavia> imbrandon: montreal is pretty nice
[01:29] <dholbach> I just wanted to raise awareness of it :)
[01:29] <Burgundavia> plus you get our socialized medicare
[01:30] <imbrandon> Burgundavia, well its not that i dont like canda its i just moved back here and bought a house not many months ago
[01:30] <Burgundavia> right
[01:30] <imbrandon> canada*
[01:30] <imbrandon> trust me anything has to be better than the USA right now
[01:30] <imbrandon> klol
[01:31] <ajmitch> hello Burgundavia
[01:31] <Burgundavia> hey ajmitch
[01:32] <imbrandon> http://www.i-am-bored.com/bored_link.cfm?link_id=10626     classic
[01:32] <imbrandon> wonder if thats gimp'd
[01:34] <jussi01> imbrandon: lol
[01:34] <jussi01> definately gimped...
[01:40] <Burgundavia> dholbach: is Jeff Bailey leaving Canonical?
[01:40] <Burgundavia> http://www.ubuntu.com/employment#OMMONT <-- is this not his job?
[01:41] <dholbach> best you ask HIM :)
[01:41] <Burgundavia> ok
[01:44] <DarkSun88> Hi all
[01:48] <persia> All Grave SYNCs requested.  Moving to important...
[02:00] <imbrandon> Burgundavia, maybe he is just m,oving to a new pos
[02:00] <imbrandon> position*
[02:04] <Sp4rKy> please guy
[02:04] <Sp4rKy> for a merge
[02:04] <Sp4rKy> i got 2 changelog entries which talk about the same section in debian/control
[02:04] <Sp4rKy> debian/control: Add libtunepimp5-mp3 binary; split out so that it will not go onto the Kubuntu CDs
[02:04] <Sp4rKy> and
[02:04] <Sp4rKy> debian/control: Add explicit libmad0 dependency to libtunepimp5-mp3 as dh_shlibdeps does not pick it up due to the nonstandard file extension
[02:05] <Sp4rKy> should i keep both ?
[02:05] <Sp4rKy> or replace by one entry
[02:05] <Sp4rKy> or keep 1 only ...
[02:08] <xxxxx1> morrrning all :)
[02:08] <ajmitch> night
[02:08] <Sp4rKy> hi :)
[02:09] <Sp4rKy> ^^
[02:09] <xxxxx1> :)
[02:12] <Sp4rKy> persia: sorry to disturb you, can you help me ?
[02:14] <persia> Sp4rKy: Not really: there's not enough information.  If these are two separate changes to debian/control (even for the same line), and make sense independently, you want two changelog lines.  If they are related, and can be summarised as a single line, you can get by with one.  It really depends on how the changes interact.
[02:17] <Sp4rKy> persia: both are in the same changes entry
[02:18] <persia> Sp4rKy: Which package?
[02:18] <Sp4rKy> libtunepimp
[02:18] <ScottK> doko: Thanks.  That's what actually in debian/changelog (I guess I messed it up on that end).  I'll file the sync.
[02:18] <zul> morning
[02:23] <persia> Sp4rKy: OK.  Looks to me like the explicit libmad0 dependency was added in 0.5.3-2ubuntu1, and the package split lost in the changelog history (before we adopted the useful comments in merges and the requirement of preservation of old Ubuntu changes).  Given the shlibs issue, it's worth mentioning both, so that someone doesn't wonder why it's there.
[02:27] <Sp4rKy> so ?
[02:28] <Sp4rKy> i keep the both, in the same entry ?
[02:28] <Sp4rKy> both*
[02:29] <persia> Sp4rKy: I think so.
[02:29] <Sp4rKy> ok
[02:29] <Sp4rKy> thanks
[02:39] <luisbg> superm1, ping
[02:52] <ScottK> If a new upload will remove a binary package that was in the old one, I'm guessing I do the new upload and then file a removal request for the orphaned binary.  Is that right?
[02:55] <pygi> bashelier, poke
[02:56] <persia> ScottK: If your new package has the same architecture coverage as the old package, it will be caught semi-automatically.
[02:57] <ScottK> Yes.  It does.  So just upload and wait then?
[02:57] <ScottK> persia: ^^?
[02:57] <CrummyGummy> Hiya, I'm building my first package.Do I use debhelper or cdbs?
[02:58] <persia> ScottK: Right.  The old one will be NBS (Not Build from Source), and will be dropped once it has no rdepends by the cruft analysis scripts.  The only time you need to request a binary removal is when a package stops building a binary only on specific architectures.
[02:58] <persia> s/Build/Built/
[02:58] <ScottK> CrummyGummy: It's up to you.  Using cdbs is generally simpler if it will work.  I'd start with that.
[02:58] <ScottK> persia: Thanks.
[02:58] <persia> CrummyGummy: I recommend CDBS, but it's deep automation.  If you're familiar with make, debhelper might be easier.
[03:00] <CrummyGummy> Thanks guys, I'll try that. Its all pretty murky right now.
[03:07] <jeromeg> can a motu have a look at bug 123708 ? a fix is available
[03:07] <ubotu> Launchpad bug 123708 in gdhcpd "gnome menu entry incorrect" [Low,In progress]  https://launchpad.net/bugs/123708
[03:12] <persia> jeromeg: Ideally, the icon wouldn't contain the .png extension, but it doesn't matter that much, as this package is likely not a popular target for theme designers.  The debdiff is in queue, and should be uploaded in the next 12-15 hours (unless the queue processing window changes significantly in the near future).
[03:13] <persia> jeromeg: Oops.  Rather, processing is pending adjustment of "Status" and "Assignment", but it should be picked up shortly after these are adjusted.
[03:14] <jeromeg> persia : thx
[03:16] <jeromeg> persia : the icon provided in debian/pixmap is a .xpm and the guy who wrote the patch uses a .png, won't this create a problem ?
[03:17] <CrummyGummy> This is a stupid question but most of the docs seem to point at converting from debhelper to cdbs. Do I have to run dh_make and then follow the cdbs instructions after that is finished?
[03:17] <persia> jeromeg: Yes.  In that case, the icon suffix should definitely be dropped.
[03:18] <jeromeg> persia : I submit a new patch or just tell him to correct it ?
[03:18] <persia> CrummyGummy: Not at all.  If you like, you can just start blank, and create copyright, control, changelog, and rules by hand.  dh_make is intended to provide handy examples to make it easier.
[03:19] <norsetto> Any universe sponsor? Patches for bug 123742 and 123708 are available for review and (if acceptable) upload
[03:19] <persia> norsetto: We're talking about the gdhcpd .desktop file - specifically that there doesn't seem to be a .png icon available.  Do you want to respin, or let jeromeg do it?
[03:19] <ubotu> Launchpad bug 123742 in gbindadmin "gnome menu entry incorrect" [Undecided,In progress]  https://launchpad.net/bugs/123742
[03:19] <ubotu> Launchpad bug 123708 in gdhcpd "gnome menu entry incorrect" [Low,In progress]  https://launchpad.net/bugs/123708
[03:20] <norsetto> persia: strange, I didn get any error during the build
[03:20] <norsetto> persia: let me check
[03:20] <persia> norsetto: It doesn't cause a build error.  The user will just get the default icon instead of the preferred icon after installation.
[03:21] <norsetto> persia: there is a gdhcpd.png in pixmaps
[03:23] <CrummyGummy> persia, Cool, but its a good place to start?
[03:23] <norsetto> persia: I see what the problem is
[03:23] <persia> norsetto: Perhaps it just needs an installation poke.  My output of apt-file list gdhcpd doesn't show one, and I don't see a change to include it in the debdiff, but I haven't reviewed it closely.
[03:23] <mruiz> hi all
[03:24] <norsetto> persia: Debian added a .xpm in debian/pixmap but the desktop still refers to the upstream icon, which is not installed in rules
[03:24] <persia> norsetto: I'd recommend installing the upstream icon as well: it probably looks nicer
[03:24] <mruiz> dholbach, please read my comments: http://revu.tauware.de/details.py?upid=5832
[03:24] <norsetto> persia: so, either we change rules or we change the desktop file, let me see what is the difference between the two
[03:24] <persia> CrummyGummy: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml has a section on starting with CDBS
[03:25] <dholbach> mruiz: thanks for looking into the problem
[03:25] <dholbach> mruiz: it's always better to not ship stuff you're not sure about
[03:25] <persia> norsetto: I'd recommend changing both.  If there is no extension in the .desktop file, it will automatically select the best available icon for the theme.  If you install both xpm and png, users will get the best icon depending on their biit depth (24-bit or 8-bit).
[03:25] <dholbach> hi norsetto
[03:26] <mruiz> dholbach, I will remove this dodgy stuff and upload a new version
[03:26] <dholbach> alrighty
[03:26] <norsetto> hi Daniel!
[03:27] <norsetto> persia: this is interesting, the upstream icon is 250x250 and the Debian one is 16x15 :-o
[03:28] <norsetto> persia: so, if you agree I will rescale the upstream one to 48x48 and use it instead of the debian one
[03:28] <persia> norsetto: That's not really surprising - upstream wants it pretty, and Debian wants it clean.  I usually suggest 32x32 for xpm and any of 48x48, 64x64 or 128x128 for png, depending on the source.  More than 128x128 needs a really dense monitor to be worth it.
[03:30] <norsetto> persian: well, if you want I can change to pgn 48x48 but I need to modify the source
[03:30] <CrummyGummy> persia, Thats where the confusion lies. In the  "First steps" it says "Convert pkg to CDBS". Which I assume to mean that you need to have started somewhere else.
[03:32] <persia> CrummyGummy: Ah.  OK.  Replace "Convert pkg to CDBS" with "Prepare pacakge with CDBS" in your head - the doc was written to advertise CDBS to Debian Developers when it was new.  Still, that short rules file should be sufficient, although you might need some supplementary files (pacakge.install, package.dirs, package.manpages, etc.) depending on the upstream build system.
[03:34] <CrummyGummy> persia, Ok, thanks, I'm just looking for a place to start. I'll find out what those other supplementary packages mean and do later.
[03:35] <persia> CrummyGummy: You might try downloading a couple packages that use CDBS as examples.  My browser session was just lost, but someone might be able to point you to the examples wiki page.
[03:37] <CrummyGummy> Good plan. Thanks.
[03:39] <persia> norsetto: I wouldn't modify the source.  If you think the big icon looks good enough, use it.  If not, consider resizing with gimp to 64x64 or so, uuencoding into debian/, build-depending on sharutils, uudecoding during build, and installing it manually.  This is probably why Debian uses the little xpm.
[03:40] <norsetto> persia: if you agree I will just change the desktop to use the xpm and resize the upstream one to 48x48 xpm?
[03:42] <persia> norsetto: the xpm should be 32x32, as otherwise it displays badly in the debian menu.  Otherwise, sounds good to me.
[03:42] <norsetto> persia: ok, 32x32 will do .... will change now and upload new patch to bug report soon. Thanks!!
[03:43] <persia> norsetto: No problem.  Menus are a favorite of mine.  Don't forget to submit the new icon and adjustments to the .desktop file to the Debian maintainer.
[03:46] <izzy_> Hiya, I just built a package for Ubuntu Feisty (there's no package of the prog for any Linux distri yet) and thought about it might be useful to put it in the universe repo. Is that possible?
[03:47] <ScottK> !REVU| izzy_
[03:47] <ubotu> izzy_: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[03:47] <persia> izzy_: Yes, but new packages are only accepted for gutsy currently.  You'll want to rebuild it there.
[03:48] <izzy_> Well, guess that's not an option - since I don't have Gutsy installed somewhere (and not the time to play with it).
[03:49] <Sp4rKy> izzy_: read docs
[03:49] <Sp4rKy> izzy_: pbuilder :)
[03:49] <persia> izzy_: You may be interested in pbuilder or sbuild, both of which allow you to build packages for gutsy whilst running feisty.  Check the wiki.
[03:50] <izzy_> It's about a GPL'd image converter (png to (windows) .ico or favicon.ico) I needed for myself. Since it wasn't available as Linux binary at all, I compiled and packaged it for myself - and just thought it may be interesting for other users too.
[03:50] <ScottK> izzy_: Sure it is.  I build packages all the time for Gutsy using pbuilder on Feisty.
[03:50] <persia> izzy_: Imagemagick should do that as well.
[03:50] <Sp4rKy> doko: so, as i said, just request a sync since there is a new debian update
[03:50] <Sp4rKy> which integrates -dbg
[03:51] <Sp4rKy> doko: http://paste.ubuntu-nl.org/28338/
[03:51] <izzy_> persia: Yepp, but how much dependencies you need for that ;) Not everybody may want to install the whole imagemagick stuff ;)
[03:51] <Sp4rKy> izzy_: it's the pbuilder goal :)
[03:52] <ScottK> persia: You may be talking to someone on another channel that is REALLY unlikely to get whatever it is you are telling him.  It may be a waste of your time.
[03:52] <persia> ScottK: I am well aware :)  It seems to be going OK for now...
[03:53] <persia> (plus I don't want to see a rash of libcurl bugs whilst the new libcurl4 package is slowly filtering over mirrors and onto workstations).
[03:53] <ScottK> persia: OK.
[03:53] <ScottK> Just thought I'd give you fair warning in case....
[03:54] <izzy_> Sp4rKy: Maybe. But I didn't want to join the developers crew - I just wanted to ask whether the package I already built may be integrated into some existing repository. Not too much overhead - I don't have the time ;)
[03:55] <Sp4rKy> izzy_: a package can't be added to repositories 'as it'
[03:55] <Sp4rKy> you have to follow processes and respect 'rules'
[03:56] <izzy_> Sp4rKy: i.e. it's just about the package I already *built* - not about something I want to build. So if that's not possible with the main repositories (universe in this case), is there any other place?
[03:56] <Sp4rKy> as the * policy
[03:56] <Sp4rKy> izzy_: on your personnal repo i guess :)
[03:56] <izzy_> Sp4rKy: I fully understand that - I don't blame you for the rules or want to discuss them, I accept them.
[03:56] <Sp4rKy> except if your package is already matching the policy
[03:57] <doko> Sp4rKy: do you know how to request syncs with debian=
[03:57] <doko> ?
[03:57] <Sp4rKy> doko: a bit yes, why ?
[03:57] <doko> Sp4rKy: please file a bug report
[03:57] <Sp4rKy> yes
[03:58] <Sp4rKy> i wouldjust be sure you're agree with it :)
[03:58] <izzy_> Good question - it is GPL, and the package installs fine on Feisty (dependencies are resolved).
[03:59] <izzy_> It was built in a fakeroot environment, so it should be (technically) fine.
[04:00] <Sp4rKy> i guess it is not ^^
[04:00] <norsetto> persia: ok, done, you may want to have another look at it? Also, any news about rt2500 and bug 123742? :-D
[04:00] <ubotu> Launchpad bug 123742 in gbindadmin "gnome menu entry incorrect" [Undecided,In progress]  https://launchpad.net/bugs/123742
[04:00] <Sp4rKy> izzy_: where can we check it ?
[04:00] <persia> norsetto: It still doesn't build :(
[04:00] <izzy_> If it causes too much trouble, I resign - I just thought others could benefit from what I made...
[04:00] <norsetto> persia::'(
[04:00] <izzy_> Sp4rKy: http://www.qumran.org/ftp/local/linux/misc/png2ico_2.12.8-1ubuntu2_i386.deb
[04:00] <ScottK> izzy_: It takes a little working with the process, but you can get your package into Ubuntu.
[04:01] <persia> norsetto: Rather, rt2500 doesn't.  I haven't looked at gbindadmin (and my browser is having a bad day).  If nobody else gets it, I'll probably have a look in 10-12 hours.
[04:01] <ScottK> izzy_: Here we work with source packages, not binaries.
[04:01] <Sp4rKy> izzy_: source package
[04:01] <izzy_> Grmpf...
[04:01] <ScottK> izzy_: Upload your package to REVU (see the link I had the bot send you earlier) so we can review your package and see if it's good for upload.
[04:01] <persia> norsetto: Remember to set status "Confirmed" and unassign yourself when submitting the candidates to the sponsors queue - they'll probably get grabbed faster that way.
[04:02] <norsetto> persia: yes .. thanks, I understood it was rt2500. Thanks for all your help!
[04:02] <norsetto> persia: thanks also for reminding me that, I tried to remember and wasn'tsure about that anymore ... gotta keep it written somewhere
[04:03] <izzy_> ScottK: The Makefile had no "install" target, so I made it manually. Which means there is no conforming source package, I'm afraid...
[04:03] <izzy_> And I'm not so deep into that stuff to create it.
[04:04] <persia> norsetto: it's on the MOTU/Contributing and the UniverseSponsorsQueue pages on the wiki also, in case you forget.
[04:04] <ScottK> Ah.  Well that makes it tough as source is all we can deal with here.
[04:04] <norsetto> persia: done, thanks again for helping
[04:04] <ScottK> izzy_: It shouldn't be so hard to make a proper source package from what you have.
[04:04] <norsetto> persia: bookmarked :-)
[04:05] <dholbach> would somebody check out http://revu.tauware.de/details.py?upid=5851 and give it a second OK?
[04:05] <izzy_> I understand. To go into details would be beyond my target :)
[04:05] <izzy_> But if you say "not to hard" - does it mean "easy"?
[04:09] <norsetto> would somebody check out http://revu.tauware.de/details.py?upid=5851 and give it a second OK or be flagged to death?
[04:09] <rexbron> hey quick question, if a package was accepted into universe last release and I need to update it, does it need to go through the revu process as per last time?
[04:10] <norsetto> thanks Daniel, really appreciate it mate
[04:10] <rexbron> or can a MOTU just upload the updated package>
[04:10] <persia> rexbron: For a revision to the same upstream, no.  For a new upstream, yes (but you only need one advocate).
[04:10] <rexbron> persia: ty
[04:10] <persia> rexbron: Be sure to mention it's an update in a comment.
[04:11] <rexbron> persia: It already has history, but I will do that.
[04:12] <persia> rexbron: It's more a reminder to the advocate that they have to upload - otherwise someone might wait for the second advocate.
[04:14] <rexbron> to any MOTU, when you get a second could you look at http://revu.tauware.de/details.py?upid=5496? It is an upstream updatde :)
[04:14] <norsetto> dholbach: Daniel, anything else you had in mind after that?
[04:14] <jeromeg> persia : patch for bug 123708 should be ok now, would be great if you could upload it
[04:14] <ubotu> Launchpad bug 123708 in gdhcpd "gnome menu entry incorrect" [Low,Confirmed]  https://launchpad.net/bugs/123708
[04:15] <dholbach> norsetto: in mind regarding what?
[04:15] <norsetto> norsetto hugs jeromeg
[04:15] <persia> jeromeg: I'll take a look when I can, but if it's in queue, someone else might get it first :)
[04:15] <jeromeg> persia : ok thank you
[04:15] <norsetto> dholbach: like, packaging?
[04:16] <dholbach> norsetto: ah - do you have anything you'd like to work on?
[04:16] <dholbach> norsetto: anything from the bug lists on  http://wiki.ubuntu.com/MOTU/Bugs ?
[04:16] <dholbach> norsetto: there should be a couple of upgrade and needs-packaging bugs that you might be interested in
[04:16] <norsetto> dholbach: OK, let me give a look, do you have any preference yourself?
[04:17] <dholbach> no, not at all
[04:17] <dholbach> in fact I prefer if you find something you are interested in yourself
[04:19] <izzy_> Does anybody know whether there will be a fix for the powernow_k8 "CPUID not supported" problem with Feisty soon?
[04:20] <izzy_> On Launchpad there was a note about a patch being available for upstream already.
[04:23] <norsetto> dholbach: Thinking about it, these will not require an upload to REVU. I just did a couple today but didn't ask you since you are not in u-u-s, would it be ok for you to do these too!?
[04:24] <dholbach> norsetto: sure, if nobody gets around to do them quickly, drop me a mail and I'll see what I can do
[04:25] <norsetto> dholbach: okki dooki, will do.
[04:26] <dholbach> rock and roll
[04:26] <norsetto> dholbach: neah, heavy metal all the way
[04:26] <dholbach> hehe
[04:36] <bmm> Any MOTU: ccbuild is looking for comments or it's first advocate after changing to a new source release. Please see http://revu.tauware.de/details.py?upid=5850
[04:38] <persia> bmm: Is this just a new upstream version?  If so, you only need one advocate.
[04:39] <bmm> persia: It's a new upstream version, but it changes the copyright because of problems with the MD5 RSA algorithm. It now depends on libgcrypt
[04:39] <bmm> So it' practically a new package as far as building and checking etc.
[04:39] <persia> bmm: Ah.  In that case, two is probably safe :)
[04:40] <bmm> persia: no problem, should be able to reach that without to much time ;-)
[04:43] <bmm> ScottK: the dpatches have been removed, the copyright edited.. I probably made some mistake somewhere
[04:44] <bmm> Oh, just thought of my first mistake! I left in the dpatch rules in the rules files!....
[04:45] <rexbron> Any MOTU, Got time to revu a new upstream version upload? Have a look at http://revu.tauware.de/details.py?upid=5496. Thanks!
[04:46] <bmm> persia: There is still a problem with the rules, I left the dpatch stuff in there, sorry...
[04:47] <persia> bmm: No worries: just reupload (and I won't look for at least 8 hours, so you might get it advocated and uploaded before I have a chance anyway)
[04:48] <bmm> persia: ah, great. Thanks!
[04:55] <dholbach> orion2012: I added another comment to your gonf-cleaner package
[04:55] <dholbach> orion2012: good work
[04:56] <ScottK> For anyone interested (like maybe dholbach), updated clamav packages (source and i386 binary) can be found at http://www.kitterman.com/clamav/ for testing.
[04:56] <dholbach> rock and roll
[04:56] <dholbach> thanks a lot scott
[04:56] <persia> ScottK: Cool.  Is there a plan yet for the rdepends rebuilds?  Will PPA help?
[04:57] <ScottK> persia: If I could figure out how to use PPA, I'd be glad to put it there.
[04:57] <ScottK> persia: For rdpends, I'm going to do klamav, clamtk, and clamsmpt.  Still looking for volunteers for others.
[04:57] <ScottK> err clamsmpt/clamsmtp
[04:58] <persia> ScottK: Assign me some nobody uses: I don't use them, but I'm happy to build stuff (or track a few failures).
[04:59] <ScottK> OK.  The tricky part I think will be testing more than building.  Maybe you use sylpheed-claws and could check out sylpheed-claws-clamav and sylpheed-claws-clamav-gtk2?
[05:00] <persia> ScottK: Um.  Actually I don't use anything even related to clamav - I just think it's a problem that we can't easily support stable users.
[05:01] <ScottK> OK.
[05:01] <ScottK> persia: Let me get a little more organized and then get back to you.
[05:01] <persia> ScottK: Great.  Thanks.
[05:05] <bmm> Any MOTU: ccbuild's newest upload is now at http://revu.tauware.de/details.py?upid=5856
[05:48] <Cybermatt> yes i did a package that only caused one error in lintian
[05:49] <bluekuja> Cybermatt, huh?
[05:50] <Toadstool> g'morning!
[05:50] <bluekuja> good morning Toadstool
[05:50] <bluekuja> :)
[05:50] <pygi> morning :P
[05:50] <Toadstool> hi bluekuja and pygi
[05:51] <bluekuja> oh pygi
[05:51] <bluekuja> :)
[05:51] <Cybermatt> my first package caused lintian to go nuts
[05:52] <Cybermatt> same story with fith
[05:52] <pygi> bluekuja, what? :P
[05:52] <Cybermatt> and tenth
[05:52] <bluekuja> pygi, :D
[05:52] <bluekuja> Cybermatt, what are you talking about?
[05:52] <bluekuja> which package?
[05:52] <bluekuja> is on REVU?
[05:52] <bluekuja> if yes, post the link
[05:52] <Cybermatt> npt yet
[05:53] <Cybermatt> first fix error
[05:53] <Cybermatt> then wait for prosesser
[05:54] <Cybermatt> to compile 800mhz kills
[05:55] <ScottK> Adri2000 or Lutin: You ought to look at the comment for acpid in Main on DaD.  You've been link farmed.  Ought to think about how to stop that from happening.
[05:56] <bashelier> ScottK: removed, thanks, the comment function is written in php so it won't be hard to add a blacklist or something
[05:57] <Cybermatt> this package dosbox-0.70
[05:57] <Cybermatt> fixing the missing dot in my email
[06:00] <ScottK> bashelier: Yes, I could have removed it myself, but wanted one of you developers to see it.
[06:00] <ScottK> bashelier: You might also add a maximum comment size.
[06:00] <pygi> bashelier, poke?
[06:00] <pygi> bashelier, if I'm not mistaken you did last wine upload. Would you be angry if I updated it? :)
[06:07] <bashelier> ScottK: yes, but it also must be removed from a file on server ;) I'm going to add maximum size and blacklisted words fonctionalities this evening, thanks
[06:07] <bashelier> pygi: yes, a lot, because I'm working on it and I have a sponsor for that ;)
[06:07] <pygi> bashelier, ah, ok then
[06:08] <dholbach> Bixente: good work on gfreqlet
[06:08] <dholbach> Bixente: I commented on it
[06:11] <Bixente> dholbach: thanks
[06:12] <dholbach> anytime
[06:12] <dholbach> it was part of the http://wiki.ubuntu.com/TODO Weekly tasks :-)
[06:16] <ScottK> geser: Why did you upload an svn snapshot of ruledispatch?
[06:19] <geser> the last one didn't work with turbogears <IP_ADDRESS> and python 2.5
[06:23] <ScottK> geser: OK.  It might've been nice to mention that in the changelog.  I'm going through the Debian Python Modules Team packages and seeing if there are ones we can sync if I update them in Debian and I was left wondering why.
[06:25] <ScottK> geser: I'm also curious about your python-tclink upload.  In Debian they explicitly decided not to build it for Python 2.5 due to test failures.  Do those tests pass in Ubuntu?
[06:38] <geser> ScottK: I have to check, I don't remember
[06:40] <ScottK> geser: Thanks.
[06:42] <geser> ScottK: does it have a test suite?
[06:44] <geser> ScottK: the problem with python-tclink was that it depended on python < 2.5 and gutsy has python 2.5
[06:47] <ScottK> Right, but the previous debian/changelog entry says "limiting to 2.4 for now, as the test/example fails for unknown reasons in 2.5"
[06:48] <geser> I didn't check the last upload
[06:48] <geser> is test/examples run during build?
[06:48] <ScottK> geser: I doubt it.
[06:49] <ScottK> I've just looked at the changelog myself.
[06:49] <ScottK> Would you run it and see if it works on Ubuntu?
[06:49] <geser> will do
[06:54] <geser> ScottK: it generates an error
[06:57] <ScottK> geser: Can you fix it?
[06:58] <geser> will look later, I'm in a meeting now
[06:59] <ScottK> OK
[07:14] <ScottK> geser: Bug #123817 filed for your convenience.
[07:14] <ubotu> Launchpad bug 123817 in python-tclink "Tests in test/examples fail with Python 2.5" [Medium,Triaged]  https://launchpad.net/bugs/123817
[07:26] <lousygaru1> a quick c++ question - is std::string unicode?
[07:27] <mok0> lousygaru1: I don't think so
[07:28] <mok0> lousygaru1: ... but it may handle an 8 bit character set
[07:28] <ScottK> mok0: Hear anything back from your upstreams?
[07:29] <mok0> No not yet.
[07:29] <mok0> I mailed the kssh guy too
[07:29] <mok0> ... but his last edits are from 2002
[07:33] <ScottK> Sounds like you are likely repacking kssh then.
[07:34] <mok0> ScottK: kssh is still on kde.org. Perhaps they have a new maintainer there?
[07:35] <mok0> ScottK: In a perfect world, the konsole crew would merge it in
[07:36] <ScottK> mok0: Get it in as a separate package for Gutsy and then work with the Kubuntu devs for that in Gutsy +1
[07:37] <mok0> ScottK: Yes, I think that is a good plan
[07:38] <mok0> ScottK: It's a hurdle to get it accepted, but I guess it's part of a learning process :-)
[07:39] <ScottK> mok0: Exactly.  My prediction is that if you stick with this, you will easliy be MOTU for gutsy +1
[07:40] <mok0> ScottK: ... perhaps it makes life a bit easier, but you still need 2 advocates on REVU, right?
[07:41] <mok0> ScottK: That
[07:41] <ScottK> mok0: Not if you are a MOTU.  Then it's recommended you get one, but it's not strictly speaking required.  Also, for upstream updates and merges from Debian you can just upload them.
[07:41] <ScottK> Much easier (I speak from experience since I just recently became a MOTU myself).
[07:41] <mok0> ScottK: OK! Well I will work hard :-)
[07:42] <mok0> ScottK: But REVU is a real bottleneck. There is a lot of waiting time, after doing your fixes it can still take a while before you get feedback
[07:43] <ScottK> Yes, but once you are known for doing good packages, it takes less time.
[07:43] <ScottK> Also things have been slower than usual recently.
[07:43] <mok0> OK
[07:43] <ScottK> Personally, I've been caught up in some other things and haven't had much time for it in the last few weeks.
[07:44] <mok0> Is there some downstream (?) work going on? Gutsy testing or ...
[07:44] <ScottK> And our most prolific reviewer for Feisty hardly shows up at all now because he's swamped with work for the next several months...
[07:45] <mok0> ScottK: who is that?
[07:45] <ScottK> mok0: I've been spending a lot of my Ubuntu time recently on bug fixes, merges from Debian, and working in Debian to get Ubuntu stuff into Debian.
[07:45] <ScottK> bddebian.  You may not have even seen him.
[07:45] <mok0> ScottK: I've seen his name on REVU
[07:46] <ScottK> He used to be able to hit every new upload usually within 24 hours.
[07:46] <mok0> ScottK: Is he a Canonical employee?
[07:46] <ScottK> mok0: No, just a dedicated volunteer.
[07:46] <mok0> ScottK: Wow.
[07:47] <ScottK> No one you see being really active in Universe works for Canonical.  We're all volunteers just like you.
[07:47] <tsmithe> ScottK, dholbach? i thought he was an employee
[07:47] <mok0> ScottK: So Universe is entirely communtiy driven?
[07:48] <ScottK> mok0: Almost, yes.
[07:48] <ScottK> tsmithe: I don't think so, but I could be wrong.
[07:48] <mok0> ... but when MOTUs upload packages, they are reviewed by Canonical guys, right?
[07:48] <Kmos> mok0: no
[07:48] <mok0> Ah so it
[07:48] <vijay2000> Hi all , I am doing an upgrade of pam-pgsql
[07:49] <mok0> s for main only
[07:49] <ScottK> mok0: The other thing I've been working is getting S/MIME and GPG working out of the box for Kmail for Gutsy.
[07:49] <mok0> ScottK: Cool
[07:49] <ScottK> mok0: NEW packages, yes.  All the archive admins are Canoncial employees.
[07:49] <ScottK> updates to packages, no.
[07:49] <vijay2000> i have the pam-pgsql_0.5.2.orig.tar.gz,pam-pgsql_0.5.2-9ubuntu1.diff.gz ,pam-pgsql_0.5.2-9ubuntu1.dsc
[07:50] <vijay2000> now can anybody tell me how to get a debian folder from these files
[07:50] <tsmithe> ScottK, his wikipage is CategoryCanonicalEmployee
[07:50] <ScottK> tsmithe: OK.  Then he's the exception.  Thanks.
[07:50] <geser> vijay2000: dpkg-source -x pam-pgsql_0.5.2-9ubuntu1.dsc
[07:50] <ScottK> mok0: Revised: Except for dholbach, no one you see here regularly works for Canonical.
[07:51] <tsmithe> ScottK, hehe yep. but to most intents and purposes, it is a community-driven affair
[07:51] <mok0> ScottK: Got it.
[07:52] <ScottK> mok0: The other thing you might want to do if you are interested in Kubuntu is show up in #kubuntu-devel, it's a lot more relaxed than #ubuntu-devel.
[07:53] <mok0> I don't know too much about KDE programming, but I need to learn since I have a programming project on my agenda where I will need it
[07:54] <mok0> I haven't dared to show up in #ubuntu-devel ;-)
[07:54] <vijay2000> geser: thanks geser
[07:56] <ScottK> Gotta run.  Be back later.
[07:56] <mok0> ScottK: See you
[07:56] <ScottK> mok0: Me neither.  All the KDE stuff I've done is packaging related.
[07:57] <mok0> Everybody here uses KDE, so I'm interested in helping out
[08:02] <mok0> Does anybody here know a good autoconf macro to check for libcurses?
[08:10] <axxo> i'm so bore
[08:10] <axxo> d
[08:18] <jussi01> axxo: go fix bug 1
[08:18] <ubotu> Launchpad bug 1 in jl "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
[08:19] <axxo> jussi01: if i knew where to start
[08:19] <jussi01> lol
[08:21] <axxo> i have like 14 hours a day free, but no real interests, it's silly :p
[09:00] <RainCT> how can I enable bug buddy? I think I've it disabled somewhere, don't ask me why :/
[09:02] <moquist> I'm packaging a perl script with its own .pm library. This is a configuration helper script that should probably only be executed once, so it doesn't seem to belong in the usual $PATH - off in /usr/share/ or something might be fine. Any advice on where to put the script and its associated .pm file?
[09:03] <moquist> there are a couple .pm files, actually. maybe 3.
[09:03] <moquist> just 2 .pm files, but also a subdirectory of config-file templates
[09:04] <moquist> it seems like sticking the whole lot off in /usr/share/<projdir> would probably be best, and then the administrator can execute /usr/share/<projdir>/scriptthing to set everything up.
[10:13] <ScottK> leonel: Did you see I posted the clamav package for Dapper for people to use in testing?
[10:18] <leonel> ScottK:  GREAT !    let'me  get back to earth  :)  and  start  with  that   as I've told you  last week  this days have been  really busy  but  I'm really interested in clamav backports  and take that way to see if there can be done for other  packages ..
[10:19] <ScottK> They (source and i386 binary) can be found at http://www.kitterman.com/clamav/ for testing.
[10:27] <tsmithe> yay my first sync request
[10:27] <tsmithe> bug 123849
[10:27] <ubotu> Launchpad bug 123849 in Ubuntu "Please sync ubuntustudio-screensaver from the Ubuntu Studio repository" [Undecided,New]  https://launchpad.net/bugs/123849
[10:48] <badzil> Hi, somebody there ? Could someone experimented have a look on bug n123748 ? I left a comment on it but couldn't take the decision od marking it invalid. Thx.
[10:49] <jussi01> bug 123748
[10:49] <ubotu> Launchpad bug 123748 in j2se1.4-i586 "java doc not at sun website " [Undecided,New]  https://launchpad.net/bugs/123748
[10:54] <jussi01> looks invalid to me, just because their search sucks, doesnt mean its a bug
[10:55] <badzil> okay. Sounds good to me. Thanks !
[10:57] <badzil> My first bug triaged ! Youpi !
[10:58] <ScottK> It's certainly NOT an Ubuntu bug is something isn't on the SUN website.
[10:59] <badzil> and it is on Sun website.
[11:00] <norsetto> Any kind soul wants to review http://revu.tauware.de/details.py?upid=5851 ?
[11:01] <norsetto> Also unkind souls would do ......
[11:04] <_MMA_> Anyone know who mods the -devel list?
[11:06] <norsetto> Come on Steve, give it a go: http://revu.tauware.de/details.py?upid=5851
[11:08] <norsetto> Andrew? Please? Pretty Please? Pretty Pretty Please?
[11:08] <xxxxx1> bye all!
[11:28] <gnomefreak> anyone hav ea hint on how to get cvs working from chroot?
[11:28] <gnomefreak> s/hav ea/have a
[11:33] <blueyed> gnomefreak: have you tried makejail?
[11:33] <gnomefreak> no
[11:33] <blueyed> It's a nice package, which allows to put all necessary libs into the chroot.
[11:34] <gnomefreak> hmm
[11:34] <blueyed> I'm using it for my webserver chroot and it works well. But otoh it's quited patched already and the author did not respond to my emails two times now.
[11:34] <blueyed> It's worth a try though.
[11:35] <blueyed> But if you only want to make cvs working, it may be overkill and you could make it work just by using ldd/strace.
[11:35] <blueyed> Then try ldd and make sure all libs are present in the chroot.
[11:36] <blueyed> What has this to do with motu though? :o)
[11:36] <gnomefreak> blueyed: building packages in chroot
[11:36] <gnomefreak> cant use cvs to grab source
[11:37] <blueyed> ah. Have you considered using pbuilder then?
[11:38] <gnomefreak> i never felt comfortable with pbuilder
[11:41] <ajmitch> morning
[11:41] <ajmitch> gnomefreak: checked /etc/resolv.conf in the chroot?
[11:42] <gnomefreak> checking
[11:43] <ScottK> Good morning ajmitch
[11:43] <jussi01> morning ajmitch
[11:44] <blueyed> morning all :)
[11:44] <gnomefreak> ajmitch: its the same as in my non chroot system
[11:44] <ajmitch> ok
[11:44] <ajmitch> can you give any more details than doesn't work?
[11:44] <gnomefreak> other than network manager comment
[11:44] <gnomefreak> cvs checkout
[11:44] <blueyed> what's the error?
[11:45] <gnomefreak> getting it
[11:45] <cbx33> hey all
[11:45] <blueyed> and couldn't you do this from outside the chroot?
[11:45] <cbx33> anyone here have anything to do with the motu-tools?
[11:45] <gnomefreak> cvs [checkout aborted] : cannot get working directory: No such file or directory
[11:45] <gnomefreak> blueyed: it works fine outside a chroot
[11:46] <blueyed> and the package building process requires you to run this in the chroot?
[11:46] <ajmitch> and what is your current directory?
[11:46] <gnomefreak> (Feisty)gnomefreak@GutsyGibbon:~/feisty_builds/firefox-trunk/trunk
[11:47] <cbx33> hey ajmitch
[11:47] <ajmitch> hey cbx33
[11:47] <gnomefreak> debian being inside trunk
[11:47] <ajmitch> all that is within the chroot?
[11:47] <ajmitch> or how are you running cvs?
[11:48] <gnomefreak> its run from rules file give me a sec
[11:48] <gnomefreak> MOZ_CVS_ROOT := :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
[11:49] <gnomefreak> hmmmmmm
[11:49] <ajmitch> as much as it hurts
[11:50] <blueyed> ouch. cvs sucks.
[11:52] <blueyed> Who wants to move/upload duplicity from -proposed to -updates? See bug 88617.
[11:52] <ubotu> Launchpad bug 88617 in duplicity "incremental backup does not work" [Medium,Fix committed]  https://launchpad.net/bugs/88617
[11:56] <geser> ScottK: got tclink working with python2.5
[11:56] <ScottK> geser: Great.
[11:56] <geser> I replace an int with ssize_t
[11:56] <ScottK> geser: Give me the patch and I'll get it in Debian and then we can just sync it.
[11:57] <geser> the problem was: py_tclink.c:46: warning: passing argument 2 of PyDict_Next from incompatible pointer type
[11:58] <geser> in python2.4 it was an int, in python2.5 an Py_ssize_t
[12:01] <geser> ScottK: do you know which is the correct check for python 2.5 in C?
[12:02] <ScottK> geser: Not off the top of my head, no.
[12:07] <Toadstool> geser: PY_VERSION_HEX and friends from /usr/include/python2.4/patchlevel.h (which is included by Python.h)
[12:07] <Toadstool> s/4/5/
[12:07] <geser> found it already myself
[12:07] <geser> hope I got 2.5.0 translated to 0x020500F0 right
[12:11] <Toadstool> geser: yeah, should be 0x020500F0


[08:48] <ogra> heap, nope, they are typically the exact same packages (unless something could not be made to build on arm for whatever reason)
[17:12] <heap> hello, i installed kernel linux-source-5.8.16-sunxi but i cant see headers for that kernel, isnt that weird?
[17:12] <heap> i mean its armbian ubuntu
[17:12] <ogra> there is no "armbian ubuntu" ... there is ubuntu and there is armbian 🙂
[17:13] <ogra> we dont have a sunxi kernel package in the archive ... so you should ask this in an armbian forum/channel/mailig-list ...
[17:16] <heap> isnt that odd
[17:16] <heap> there is kernel and no headers
[17:22] <ogra> yeah, not sure what armbians way of dealing with that is though and if they require a packager to provide a header package ...
[18:26] <Mekaneck> armbian isn't supported here heap
[19:25] <heap> so is it possible to download or build that kernel headers?
[19:39] <ikonia> ahhh good the channel survived the move
[19:40] <ikonia> I'm using the ubuntu 20.04 raspberry pi image on a pi4, the /forcefsck empty file is not forcing an fsck, is there something different due to the pi boot process that stops this working, how can you force an fsck on boot without changing /etc/fstab
[19:58] <ogra> ikonia, i dont think there is anything special at that stage of the boot
[19:59] <ogra> it should theoretically still work unless it has been dropped for the whole of the distro
[20:05] <ogra> ikonia, you could try to tell systemd to do an fsck by adding "fsck.mode=force" to cmdline.txt
[20:29] <ikonia> interesting idea
[20:29] <ikonia> from what I've read on the systemd unit files, it should still work
[20:29] <ikonia> but for some reason it doesn't on the pi's
[20:29] <ikonia> I'll try the cmdline.txt
[20:30] <ogra> there is nothing special with the Pi in that regard ...
[20:30] <ikonia> that was my thinking also....but then it didn't work on 6 pi's
[20:30] <ogra> the weird bits are before the kernel loads ... anything after is "just ubuntu"
[20:30] <ikonia> yup, once it hits the kernel boot it should be normal
[20:30] <tomreyn> fwiw /forcefsck generally no longer works
[20:31] <ogra> aha
[20:31] <ikonia> tomreyn: oh really ?
[20:31] <ikonia> when did it get pulled ?
[20:31] <ikonia> it's still referenced in the unit files
[20:31] <tomreyn> at least from what i'Ve gathered during tests.since systemd
[20:31]  * ogra knew why he wrote "unless it has been dropped for the whole of the distro" above 🙂
[20:31] <ogra> i wasnt sure though
[20:32] <tomreyn> "fsck.mode=force" does work, though
[20:32] <ogra> (and given 90% of my time is nowadays spent on Ubuntu Core i'm not really up to date with the rest f the distro
[20:32] <ikonia> I'm keen to try ubuntu-core
[20:32] <ikonia> I've kept away from it due to lack of use cases, but I think I actually do now
[20:33] <ogra> well, be aware that *everything* is a snap there
[20:33] <ogra> if you want an app, you need it snapped
[20:33] <ikonia> ogra: yeah, that's one of the things I'm not comfortable with, but perhaps need to get comfortable with
[20:36] <ogra> it is totally awesome once you got used to it ...
[20:37] <ogra> (and indeed i'm *totally* unbiased 😛 )


[04:07] <kubotu> ::qt-bugs:: [1046244] plasma-desktop crashes with SIGFAULT on boot @ https://bugs.launchpad.net/bugs/1046244 (by Francesco Ruvolo)
[12:26] <BluesKaj> Hiyas all
[14:25] <Riddell> gosh, tars!
[14:25]  * apachelogger drops dead
[14:26] <apachelogger> reminds me that I still need to script parallel sc packaging magic -.-
[14:32] <Riddell> Meeting Wednesday 17:00UTC
[15:06] <Riddell> gosh there's loads of kdegames modules
[15:06] <Riddell> including one called kshisen, isn't that a rude word in german?
[15:29] <yofel__> Riddell: well, that would be slang and s/k/g/, but it's close
[15:29] <yofel__> apachelogger: IMO the scripts are fine, I just make initial-upload not fail as easy
[15:29] <yofel__> s/make/made/
[15:29] <kubotu> yofel__ meant: "apachelogger: IMO the scripts are fine, I just made initial-upload not fail as easy"
[15:29] <apachelogger> dunno
[15:29] <apachelogger> we still have not discussed it
[15:29] <apachelogger> ...
[15:30] <yofel__> well... yeah
[15:30] <yofel__> until then, they ~work
[15:30] <apachelogger> lack of discussion annoyes my epically
[15:30] <apachelogger> which is why it annoys me that people are utterly unresponsive in kde-mm -.-
[15:30] <yofel__> didn't we discuss it? (most people don't seem to care)
[15:30] <Riddell> yofel__++ on the move to manual if it doesn't fail
[15:36] <Riddell> apachelogger: what needs discussed?
[15:36] <apachelogger> how it works, how it is supposed to work, how it could be better, why it is not better....
[15:40] <Riddell> yeah, we're too busy packaging at packaging time to discuss much and the rest of the time it's not the most important thing to do
[15:41] <apachelogger> sounds like you just made it a vicious circle :P
[15:42] <Riddell> hey I didn't do anything! that's just the case as I see it
[15:44] <yofel__> Riddell's right though. Even I only fixed the scripts *while* I was packaging because I was rather good at making them fail
[15:45]  * Riddell uploads akonadi 1.8.80
[17:16] <rdieter> a bot OT, but, robert ancell asked me to sign http://www.canonical.com/contributors to contribute to lightdm.  wondered what i'm supposed to fill in on the required "Please add the Canonical Project Manager or contact" field.  ??  (or advice where to find robert on irc?)
[17:25] <debfx> rdieter: he is robert_ancell on IRC but not online atm
[17:26] <rdieter> debfx: ok, mail it is then
[17:26] <rdieter> thx
[23:52] <LyzardKing> what is kubuntu's status, being passed over to bluesystems?
[23:53] <ScottK> LyzardKing: Kubuntu has always been a community led project.  The fact that some people work for a different company, doesn't really affect the work we do.
[23:55] <LyzardKing> ScottK: yes I know. I was just wondering, since the other company has probably different goals and ideas, what was the community's voice in the matter.
[23:55] <ScottK> AFAIK the fact that someone else is paying Riddell hasn't affected anything.
[23:56] <ScottK> Kubuntu Council still controls what happens in Kubuntu and it's elected by Kubuntu members.
[23:56] <ScottK> Actually that's not quite right.  Kubuntu Council is now a legal entity of some sort (I've forgotten the exact terms) and can accept donations directly.
[23:57] <ScottK> We used some of the money we have to send some additional KDE/Kubuntu people to UDS earlier this month.
[23:57] <ScottK> Now that I think about it, the change is we've got more room to do what we collectively agree we should be doing.
[23:58] <LyzardKing> ok, just what I wanted to hear. Thank you! I really like the way kubuntu is headed
[23:58] <LyzardKing> are there any guidelines written somewhere, with development in mind? like the main kde ones
[23:59] <ScottK> Our main goal is to present KDE in line with the way upstream developed it.
[23:59] <ScottK> KDE in Kubuntu looks more like an upstream build from source than (AFAIK) any other major distro and we like this.