[15:59] <ddstreet> o/
[15:59] <teward> *yawns*
[16:00] <teward> i have my opinions RE: your initial post ddstreet and i'll share here - been a busy week so i didn't get a chance to actually reply heh
[16:01] <ddstreet> sounds good yeah, one good thing about realtime mtgs is it lets you carve out a bit of time, otherwise it's really hard to make time for all the things
[16:01] <teward> yup
[16:01] <teward> welcome to my world where the work got busy this week xD
[16:02] <ddstreet> i'm cautiously optimistic this mtg might not be too long, i think we are all mostly in agreement on most things
[16:02] <ddstreet> mapreri you around for us to start?
[16:02] <mapreri> aye
[16:02] <teward> i also have a few questions re: clarificationof things too but :P
[16:02] <ddstreet> ok let's do the official first
[16:02] <teward> again putting out fires at work so i'm probably going to rapidfire my concerns and statements first if you will let me
[16:02] <mapreri> but I'd like to ask one thing: how is it that, technically, does one accept/reject packages in a launchpad queue?
[16:03] <ddstreet> #startmeeting Ubuntu Backporters meeting
[16:03] <meetingology> Meeting started at 16:03:01 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[16:03] <meetingology> Available commands: action, commands, idea, info, link, nick
[16:03] <teward> mapreri: we could ask anyone who might know, i.e. vorlon who I know does AA tasks for accept/reject stuff
[16:03] <teward> but that's a separate discussion of what we'd need after implement.
[16:03] <teward> oops meeting started :)
[16:03] <mapreri> oh good, it felt like I was alone in having this technical doubt :D
[16:03] <ddstreet> just quickly for the record, we do have the action item of figuring out membership process/etc but i think we should punt that
[16:03] <teward> lets push that until we have full details of how backports will work
[16:04] <ddstreet> and jump right into general discussion
[16:04] <mapreri> k
[16:04] <teward> i'll wait before i rapidfire my clarification requests/concerns for you to give me the floor :P
[16:04] <ddstreet> yeah re: accept/reject i think they use tools from the ubuntu-archive-tools repo https://pad.lv/p/ubuntu-archive-tools
[16:05] <ddstreet> i *think* we may have the ACLs now to do that? but i'm not sure, i of course haven't actually tried it yet
[16:05] <ddstreet> let's put an action to ask someone about it
[16:06] <ddstreet> #action clarify how to accept/reject uploads to -backports queues
[16:06] <meetingology> ACTION: clarify how to accept/reject uploads to -backports queues
[16:06] <ddstreet> ok i'm done witht he floor, you guys jump in
[16:06] <teward> ok so
[16:06] <teward> first
[16:06] <teward> back when I was championing this process BEFORE I was on all the boards with all the hats...
[16:07] <teward> I had suggested that requests can ONLY come from developers willing to watch the package and handle sec updates, etc. to it.  NOT the backporters team, so that Backporters simply have the request/reject.
[16:07] <teward> I see references to torching the 'anyone can request' part of the existing process and to torch the entire current process which I agree with
[16:07] <teward> but are we going to limit requesting backports for approval, etc. to people who have upload rights (which would then need accept/reject for backports pocket from us)>
[16:07] <teward> but are we going to limit requesting backports for approval, etc. to people who have upload rights (which would then need accept/reject for backports pocket from us)?
[16:08] <teward> and therein require a request still to be filed for *approval* with justification therein as to why, and that that developer has still done testing to validate the program/package will still function?
[16:08] <teward> (I didn't see any explicit definitions to this point, either that or i missed it in the thread of discussions)
[16:10] <mapreri> mh
[16:10] <mapreri> we don't have such thing in debian, and I believe that, depending on the amount of requests, would still risk to be too much for us to handle
[16:11] <mapreri> otoh, we might want to also prevent people from filling up the bpo pocket
[16:11] <mapreri> I don't think we should require people to give us explanation unless we see something fishy going on
[16:11] <mapreri> but of course, uploading implies that the uploader did test properly before
[16:11] <teward> ack.
[16:12] <teward> so we would be limiting it, then, to those who can upload the given package, just that it'd require us to approve/reject the upload?
[16:12] <teward> and certain things would be rejected based on where it sits?
[16:12] <mapreri> i'm happy to write down in the rules that in case somebody regularly uploads stuff that then comes out it's not actually working will then be prevented (by us, manually) to contribute again or so.
[16:12] <teward> yeah I would suggest that, regardless, we dictate the rules and write it down
[16:12] <ddstreet> i think it's ok if someone wants to upload and finds a sponsor to upload for them, right?
[16:12] <teward> that's where it gets tricky
[16:13] <mapreri> as usual the sponsor is also responsible for not uploading shit
[16:13] <ddstreet> yeah
[16:13] <teward> ddstreet: if a Sponsor uploads it that's fine, but then SPonsored is required to make sure relevant patches, etc. are submitted for critical security bugs
[16:13] <teward> and as for scope of what people can upload, obvious things (core bits, etc.) are not permitted except in SPECIAL CASES
[16:13] <teward> (there are special cases for certain openstack things I think?)
[16:13] <mapreri> teward: that's the same of the rest of the archive, isn't it?
[16:13] <teward> s/think/think already/
[16:14] <teward> mapreri: well technically
[16:14] <teward> I'm a Core Dev
[16:14] <teward> if I try and upload a kernel package, i'm pretty sure it might let me, despite not being on the Kernel team, i'd get hell for it thoug
[16:14]  * mapreri is planning on writing the application for thatt one of these days, btw.
[16:14] <teward> so technically i can upload to any pocket
[16:14] <teward> not that I WOULD but in case of certain things it'd raise Hell
[16:14] <teward> so we need to be clear what 'not allowed to touch' is
[16:15] <mapreri> sure, then what? :)
[16:15] <teward> as long as Sponsor or Uploader isn't stupid anddoesn't abuse it it's not aprolbme, but it was discussed setting limits
[16:15] <mapreri> for some reason neither debian nor ubuntu had the principle of least privilege applied to upload permissions :3
[16:15] <teward> i'd like those limits to be more clearly defined is all
[16:15] <teward> mapreri: so i'm going to stop you there briefly.
[16:15] <teward> on the basis of "We need to tread careful here"
[16:15] <teward> whether upload rights are a thing or not
[16:16] <teward> we need to set the standard for the scope of what Backports covers
[16:16] <teward> or we're going to end up in Sqaure One of backports that we had that led to the death of Backports in general again
[16:16] <teward> so my question is: do we have a clearly defined scope of what we will/won't permit to be put into backports?
[16:16] <mapreri> that was part of what was in ddstreet's mail as well.
[16:17] <ddstreet> and there certainly wasn't one before, and it may be hard to come up with one
[16:17] <mapreri> my take, is that we'll blacklist thing as we go.  starting with stuff that is already covered by HWE, and the cloud archive.
[16:17] <ddstreet> i do agree the kernel should be excluded
[16:17] <mapreri> but I wouldn't go with a whitelist, except for the non-LTS releases where we don't want to hassle.
[16:18] <teward> HWE, Cloud Archive, snapd and things that underwent deb-to-snap transitions
[16:18] <teward> HWE, Cloud Archive, snapd and things that underwent deb-to-snap transitions, packages that are so mission critical we can't update those without a full migration type task, etc.
[16:18] <teward> (Python comes to mind here...)
[16:18] <ddstreet> yep
[16:18] <mapreri> ack
[16:18] <ddstreet> it would probably be easier to add to the list as people request pkgs as mapreri is suggesting
[16:18] <teward> (certain python3 *packages* which are just modules packaged up could be different, but I mean core python version etc.)
[16:19] <teward> agreed.
[16:19] <mapreri> I'd also blacklist compilers at large perhaps?
[16:19] <teward> mapreri: agreed
[16:19] <teward> PHP and Web scripting language versions as well
[16:19] <mapreri> "interpreters"
[16:19] <teward> (Server Team would balk at that if we tried ti push updated PHP to an older release, without them handling it)
[16:19] <teward> mapreri: yep.
[16:20] <ddstreet> so we're all agreed to in principle having a list of excluded packages, that we update on an ad-hoc basis as a team?
[16:20] <teward> BASICALLY< when we first get started, I want a known "This stuff will not be accepted", which we'll update a specific list going forward as a team
[16:20] <teward> interpreters, core packages, stuff in Cloud archive, snapd, kernel, deb-to-snap packages, etc. would be automatically excluded to begin with.
[16:20] <teward> (includes compilers)
[16:20] <teward> so that we don't get innundated with requests for things that we wouldn't accept anyways
[16:20] <teward> (sponsored or otherwise)
[16:21] <ddstreet> i suggest we move the specific discussion of what's on the list to ML discussion, as i suspect it'll take time
[16:21] <mapreri> yes, we all seem in agreement on this.
[16:21] <teward> yup
[16:21] <teward> agreed we move specific discussion to the ML just wanted to make sure we had a basic thing of "this base category is a no-go" to start.
[16:22] <teward> rather than point at specifics specifically
[16:22] <mapreri> that's easily just a list in the wiki, let us subscribe to the wiki to make sure nobody mess with it, done.
[16:22] <ddstreet> #agreed maintain a list of excluded packages, to be updated on ad-hoc basis and/or updated from mailing list discussion
[16:22] <meetingology> AGREED: maintain a list of excluded packages, to be updated on ad-hoc basis and/or updated from mailing list discussion
[16:22] <ddstreet> yep definitely, should just go into the wiki page
[16:22] <mapreri> ddstreet: I think it would be best if you lead the discussion based on your agenda :)
[16:22] <ddstreet> ok
[16:22] <teward> one more thing in my dossier then i'll be silent
[16:22] <ddstreet> lemme pull up the email
[16:23] <ddstreet> sure go for it
[16:24] <teward> the security component is one thing I want to make sure we agree on: Neither the Backporters team nor the Security Team will be responsible for security updates and patches to Backported programs.  Like security updates in Universe packages, it is up to the uploader (or sponsored individual) to make sure teh backported package receives relevant security patches and drive them to land in the backports queue for the package.
[16:24] <teward> or similar wording, however we word it we make sure it's not our obligation nor Security obligation for items in -backports
[16:24] <teward> (there will be exceptions I think in certain cases but generally speaking)
[16:24] <teward> that's it on my radar for concerns/thoughts
[16:25] <mapreri> I think both me and ddstreet are on the same page, according to the mail :)
[16:25] <teward> just making sure ;)
[16:25] <ddstreet> +1 and i think we should also clarify to potential users of the package that neither our team nor the security team will monitor or enforce that the package requestor actually keeps it up to date
[16:25] <mapreri> but
[16:26] <teward> ddstreet: there may be exceptions if a specific team drives the backport
[16:26] <teward> but at that point that Team would be monitoring it
[16:26] <teward> (but yes in general principle I agree ddstreet)
[16:26] <mapreri> we write clearly to users to not expect anything.  otoh we write clearly to developers that we team expect them to do good and provide them.
[16:26] <ddstreet> #agreed ubuntu backporters team is not responsible for future security updates to packages, nor is the security team, the package requestor (and/or their sponsor) should expect to maintain it
[16:26] <meetingology> AGREED: ubuntu backporters team is not responsible for future security updates to packages, nor is the security team, the package requestor (and/or their sponsor) should expect to maintain it
[16:26] <teward> mapreri: agreed.
[16:27] <ddstreet> ok let me get to the agenda items from the email thread
[16:27] <ddstreet> #topic how the community requests backports
[16:27] <teward> we can expect that a given team or developer driving a package in would know this, but we do need to write it clearly for users to see "There is no guarantees of stuff here"
[16:28] <teward> ddstreet: -1 on 'community' requests in general, they have to do the work to get it sponsored for a backport upload, or a developer has to take that task, we should not just allow general 'requests' for backports.
[16:28] <teward> my 2 cents (this was mentioned before in the email)
[16:28] <teward> (but not by me)
[16:28] <ddstreet> +1 on updating the docs, and tooling, to reflect this
[16:29] <teward> agreed, +1 on updating docs and tooling
[16:29] <mapreri> ack.  Though I'm fine if community write to the ML saying "I'd like this bpo, could somebody pretty please provide it", without expecting the service :)
[16:29] <teward> mapreri: that's a given.
[16:29] <mapreri> but probably best to just not talk about "requests"
[16:29] <teward> but i think that should go to -devel-discuss
[16:29] <ddstreet> yeah i agree ML requests for help are fine
[16:29] <teward> because at that point if they're *requesting* someone to backport it, then it needs to go to a point where a dev has to actually be interested
[16:29] <teward> agreed on ML requests as well
[16:29] <ddstreet> just as long as they don't expect our team to do it
[16:29] <teward> just my 2 cents it shouldn't be sent with the expectation of being done/responded to
[16:30] <mapreri> there was such request in July fyi
[16:30] <teward> to backporters?
[16:30] <mapreri> https://lists.ubuntu.com/archives/ubuntu-backports/2021-July/021758.html
[16:30] <ddstreet> i think we should update our wiki page to clearly state the 'requestbackport' tool is deprecated, and also we should remove the tool from ubuntu-dev-tools package, to avoid confusion
[16:30] <teward> ddstreet: agreed
[16:31] <mapreri> I'd be for replacing it with a stub that print() a message and url to the wiki though
[16:31] <mapreri> rather than removing it right away
[16:31] <teward> i'm actually OK with that as well
[16:31] <teward> do a transitional removal - replace the code with a warning
[16:31] <teward> like we did for bitcoin when it was blacklisted/removed
[16:31] <teward> s/bitcoin/bitcoin and bitcoind/
[16:31] <ddstreet> ack, deprecation/stub is likely better
[16:32] <teward> i also think we should reply to the July request and indicate that we are redesigning Backports and to check back once we've published updated processes and documentation
[16:32] <teward> or at least wait until we have that stuff decided/published and then reply
[16:32] <mapreri> they also filed a bug, so that can happen together with when we'll handle (somehow) all the open bugs
[16:33] <ddstreet> #action update wiki/docs to reflect users can't just request a backport, and deprecate 'requestbackport' tool to print message and url indicating same
[16:33] <meetingology> ACTION: update wiki/docs to reflect users can't just request a backport, and deprecate 'requestbackport' tool to print message and url indicating same
[16:33] <ddstreet> either of you want to take an action to reply to the previous ML requests and/or bugs?
[16:33] <ddstreet> i can take it as administrative work otherwise
[16:34] <ddstreet> #action ddstreet reply to previous ML requests and open backport request bugs indicating change in process
[16:34] <meetingology> ACTION: ddstreet reply to previous ML requests and open backport request bugs indicating change in process
[16:34] <mapreri> i can take it, but not do it these few days
[16:35] <mapreri> as you prefer
[16:35] <ddstreet> sure feel free to do it, i probably would not get to it for a couple weeks :)
[16:35] <mapreri> well then, whoever starts first
[16:35] <ddstreet> i'll leave the action on me but not actually do anything for it
[16:35] <ddstreet> yep
[16:36] <ddstreet> ok i think we're cleared up on item #1, of how people initiate backports, right?
[16:36] <mapreri> ye
[16:37] <ddstreet> i think we should have an action to clean up the wiki page with the new process steps, either of you want to take that?
[16:37] <teward> ddstreet: if we have no objection to me updating the tooling i can handle tooling rejiggering for leaving requestbackport to just print the message
[16:37] <ddstreet> perfect go for it
[16:38] <mapreri> atm I'd prefer to leave at least the first round of wiki cleanup to others
[16:38] <ddstreet> ok i'll take the first round of wiki updates
[16:38] <ddstreet> #action teward update tooling, requestbackport
[16:38] <meetingology> ACTION: teward update tooling, requestbackport
[16:38] <ddstreet> #action ddstreet update wiki docs with new process
[16:38] <meetingology> ACTION: ddstreet update wiki docs with new process
[16:38] <teward> ddstreet: you can take it for the previous requests, but we could mass close all the old requests as "The Backports process has undergone radical changes and as such existing requests are being cancelled for resubmission under the new process"
[16:38] <teward> just as a suggestion ;)
[16:39] <teward> remind me which repo has the tooling?
[16:39] <ddstreet> ubuntu-dev-tools
[16:39] <teward> been a while since i double checked (three upgrades in place XD)
[16:39] <teward> thanks
[16:39] <ddstreet> #topic review of tooling, requestbackport and backportpackage
[16:39] <ddstreet> i think we covered requestbackport already
[16:40] <mapreri> teward: in case you are going to open a MR for u-d-t, I promise to be quick to review it :P
[16:40] <ddstreet> i guess one of us should just review the code for backportpackage, teward you want to do that review to see if anything needs changing there?
[16:40] <teward> mapreri: yep.  we may need to push some updates to retroactive releases if it's released as a package in the repos though
[16:40] <teward> ddstreet: yeah i'll handle that
[16:40] <ddstreet> #action teward review backportpackage tool
[16:40] <meetingology> ACTION: teward review backportpackage tool
[16:41] <teward> to my knowledge it's fine as it is, i still use it to backport packages even for PPAs when I do it, it's a fast way to snag from devel or SOURCERELEASE and prep for TARGETRELEASE regardless of if it's the main repos or not xD
[16:41] <teward> (I just change it to not use -backports before upload to PPAs)
[16:41] <ddstreet> #topic what releases are allowed/required to backport into
[16:42] <teward> *forks ubuntu-dev-tools to his account on LP to begin with*
[16:42] <teward> ddstreet: i suggest LTS only, because interim releases only have 9 months of coverage.
[16:42] <teward> as was stated in the email chain
[16:42] <mapreri> teward: yeah, I can handle the SRUs later on myself
[16:42] <teward> there may be exceptions where we have to accept for an interim release, again in edge cases
[16:43] <teward> but in general I'd say to the LTSes only, not to interim releases
[16:43] <teward> and not to LTSes that have entered ESM
[16:43] <ddstreet> so sounds like we agree on backports to interim releases are *allowed* on a case-by-case basis, but not required, right?
[16:43] <teward> ddstreet: i would say 'yes'
[16:43] <ddstreet> #agreed backports to interim releases are allowed on case-by-case basis, but not required
[16:43] <meetingology> AGREED: backports to interim releases are allowed on case-by-case basis, but not required
[16:44] <teward> generally speaking the backport target should be an LTS release that has not entered ESM or EOL yet, in my opinion, with case by case bases for interim releases
[16:44] <mapreri> I'd say that many dev tools are fine to have in interim releases
[16:44] <mapreri> like, debhelper, pbuilder, u-d-t, devscripts, sbuild, …?
[16:44] <ddstreet> yep dev tools will likely be the most common thing in interim releases
[16:44] <mapreri> me being involved in 3 out of the 5 above means I'm quite biased :)
[16:45] <teward> yep
[16:45] <ddstreet> should we start a ML thread on dev tools that we may want to proactively put into -backports?
[16:45] <teward> i think so, yes.
[16:45] <teward> or rather, proactively approve you mean, because it's still not on *us* to make sure they're all backported
[16:45] <mapreri> I'm happy to take the task of doing the first 4 of the above btw.
[16:45] <mapreri> because, at the very least, I'd like to have them for my own use (!)
[16:46] <ddstreet> sure, though for the tooling it's quite possible one of us would actually be doing the work of uploading the tools
[16:46] <teward> agreed
[16:46] <teward> mapreri: if you also take sbuild I'll send you some beer
[16:46] <teward> I regularly use sbuild in my test build envs and I like that being up to date xD
[16:46] <ddstreet> #action mapreri start ML discussion for list of dev tools to proactively put into -backports
[16:46] <meetingology> ACTION: mapreri start ML discussion for list of dev tools to proactively put into -backports
[16:46] <teward> all five of those stated are good candidates
[16:46] <teward> but we'll move to ML for that
[16:46] <mapreri> I don't use sbuild, so I can't really test it decently.  but I'm sure plenty of people will throw me darts if I break it so I'll know very quickly heh
[16:47] <teward> mapreri: if you can prep it and PPA it I can test
[16:47] <ddstreet> i gave you the action to start the ML discussion mapreri :)
[16:47] <mapreri> sure (to both)
[16:47] <ddstreet> and of course, I don't think any tool has to be pre-discussed, it should also be fine just to upload something as long as another team member is the reviewer
[16:48] <mapreri> this was more like pre-allowing things into interim releases
[16:48] <ddstreet> yeah
[16:48] <ddstreet> ok for this topic, we also should clarify the LTS->LTS and LTS->interim upgrades as briefly discussed in the ML
[16:49] <ddstreet> i think mapreri and i are in agreement on this
[16:49] <ddstreet> teward you as well?
[16:49] <teward> agreed
[16:49] <ddstreet> ok let me try to capture it as agreed statement
[16:49] <teward> no concerns there.
[16:49] <mapreri> one thing we aren't sure on is
[16:50] <mapreri> what to support: LTS+bpo → LTS², or LTS+bpo → LTS²+bpo ?
[16:50]  * ddstreet has thunderstorm outside fyi, hopefully i won't lose power
[16:50] <teward> mapreri: as in source + destination?
[16:51] <teward> and LTS^2 as in, "Previous LTS"?
[16:51] <mapreri> as in supported upgrade path
[16:51] <teward> oh
[16:51] <mapreri> which also means which source to take from I suppose, yes
[16:51] <teward> i think we can handle those slightly differently
[16:51] <teward> but here's my thoughts
[16:51] <teward> any later release can be a source even an interim to a given LTS's backports repo.
[16:52] <teward> i.e. Impish -> CurrentlySupportedLTSes
[16:52] <teward> but if you skip over an LTS it has to be supported in that other LTS as well
[16:52] <teward> as for upgrade path, we should disable backports entirely, and whatever's in TargetRelease should be force-installed to supersede backports
[16:52] <mapreri> right.  but I want to be sure that whatever you backport is going to be upgradable to 22.04 then even if taken from impish (which should be the case)
[16:52] <teward> because backports are NOT guaranteed to upgrade properly
[16:52] <teward> that's what i just indicated here.
[16:53] <teward> as my second point/suggestion
[16:53] <mapreri> I don't want that
[16:53] <mapreri> force-installing to supersede backports sounds like something wasn't done properly
[16:54] <mapreri> why can't we guarantee proper upgrade paths?
[16:54] <teward> mapreri: define the scope of "We"
[16:54] <mapreri> I believe part of the check we need to do before approval is to make sure that the versioning is right.  and we are going to consider a bug if an upgrade fail, bug that's going to be assigned to the last uploader.
[16:55] <teward> that i agree, provided that the 'last uploader' (not the sponsor) is the one who handles fixing it
[16:55] <teward> and yes, verifying versioning is right is critical for any approvals
[16:55] <mapreri> so, why do you say "because backports are NOT guaranteed to upgrade properly" ?
[16:56] <mapreri> we are not going to be responsible in the same way AA is not responsible for regular upgrade failures, are they
[16:56] <teward> mapreri: well if you tried to upgrade my computer to Impish even if you could, Wireshark backported is 'newer' than the version in Impish right now on my system, and that means Wireshark could break
[16:56] <teward> that's what i want to make sure
[16:56] <teward> that it's not on the Backporters team to *fix* a broken package
[16:56] <teward> that brings one other question:
[16:56] <mapreri> ah yes, the only upgrade path starting from an LTS+bpo system is the next LTS
[16:56] <teward> how do we guarantee the upgrade path if OriginalUploader has gone missing or has no more interest.
[16:57] <teward> (short of removing the package from -backports which doesn't solve the problem)
[16:57] <mapreri> I guess it "falls on the community" like for all the other packages in the archive?
[16:57] <teward> i'm actually OK with that.
[16:58] <ddstreet> we're specifically talking about version numbers here, right?
[16:58] <teward> more or less
[16:58] <teward> more or less yess
[16:58] <teward> more or less yes
[16:58] <teward> blah i can't type to save my butt >.>
[16:59] <ddstreet> i think at the point of reviewing the backport, we can see if the LTS-backports version is < next-LTS version (both next-LTS-updates and next-LTS-backports)
[16:59] <ddstreet> i think that should be a hard rule
[16:59] <mapreri> yes, we agreed on it
[16:59] <teward> agreed
[16:59] <teward> as long as that is a hard rule that should rule out edge cases.
[17:00] <mapreri> and we are not going to support upgrades from LTS to interim
[17:00] <teward> agreed, not for backports.
[17:00] <mapreri> (which the current bpo rule support, btw)
[17:00] <teward> works for me
[17:00] <ddstreet> right, if someone upgrades into an interim, it's undefined if their -backports version would remain or be replaced
[17:00] <mapreri> but we should agree in only one of
[17:00] <mapreri> "(both next-LTS-updates and next-LTS-backports)"
[17:01] <mapreri> I mean
[17:01] <ddstreet> well next-LTS-backports should *always* be > next-LTS-updates
[17:01] <ddstreet> right?
[17:02] <ddstreet> so LTS-backports should, by rule, be < next-LTS-updates
[17:03] <mapreri> so it means that backports can't span 2 LTSs?  for example, backporting something from 22.04 all the way to 18.04.  is it possible, or no?  and if it is, we force people to *also* upload to 20.04-bpo?
[17:03] <ddstreet> for comparison, what the UCA archive does is just take the newer release package version and append '~cloud0' to force the version to be 'under' the version it's taken from
[17:04] <teward> technically speaking I think for our purposes if we do a backport we need to include the target release codename/number
[17:04] <teward> similar to how we have SRUs or updates that bump version numbers currently in all releases, we add on the version number in the version string
[17:04] <ddstreet> no i think backporting to multiple LTS should be ok, it should just follow similar versioning for srus, like if version 1.2.3 is backported to 18 and 20, then use versions '1.2.3~18.04.1' and '1.2.3~20.04.1' or something
[17:04] <ddstreet> yep
[17:04] <ddstreet> as teward said
[17:04] <teward> yeah that way we can have the same thing in multiple releases, following SRU Versioning Behavior
[17:05] <teward> that way if a later version shows up it'd still be superseded
[17:05] <ddstreet> we could probably require specific version formatting for backports
[17:05] <teward> agreed.
[17:05] <ddstreet> mapreri sound ok?
[17:05] <mapreri> right, so then the supported upgrade path is LTS+bpo → LTS²+bpo, not LTS² (ex. bpo).  fine, let's write it down properly in the doc
[17:05] <mapreri> so users are expected to *not* disable the bpo pocket from their sources.
[17:06] <ddstreet> i think it's ok either way for them to, isn't it?
[17:06] <mapreri> if we allow backports from 2 LTSs away, it might not be ok for them.
[17:07] <mapreri> even if it's not from LTSs away, just from the interim after the next lts
[17:07] <mapreri> like bpo from impish to bionic, we mandate also a bpo to focal to preserve the upgrade path, and users of bionic+bpo needs to have focal+bpo to be able to upgrade.
[17:08] <ddstreet> first part i agree with, bpo to focal before or along with bpo to bionic
[17:09] <ddstreet> but if they upgrade b->f, and they had version 1.2.3~18.04.1 in b, and f has version 1.2.2, they'll keep version 1.2.3~18.04.1 even if they disable -backports right?
[17:09] <ddstreet> i supposed if there are changing dependencies/libs that might break if they don't upgrade to 1.2.3~20.04.1
[17:09] <mapreri> then they'll find themself with, if they are lucky, an out-of-repo local package. if they unlucky some Breaks will prevent them from fully upgrading.
[17:10] <mapreri> neither of which is a proper system to have in my books
[17:10] <ddstreet> ok so we should require continuing to use -backports then, across release upgrades
[17:10] <ddstreet> i'm fine with that
[17:11] <mapreri> cool
[17:11] <mapreri> teward: are you fine too?
[17:11] <teward> sorry my boss called.
[17:11] <teward> i'm fine with that
[17:12] <ddstreet> #agreed LTS->LTS upgrades must be supported, and -backports should remain enabled/used
[17:12] <meetingology> AGREED: LTS->LTS upgrades must be supported, and -backports should remain enabled/used
[17:12] <mapreri> regarding the version string.  are we going to keep using the same namespace as SRUs and sec updates like I believe in the past?
[17:12] <teward> mapreri: i think we would have to, to avoid archive collisions, unless we intentionally want to update default policy to supersede backports, which sounds bads.
[17:12] <teward> s/bads/like it'd cause more harm than good/
[17:13] <mapreri> I'm mostly used to debian, where backports use ~bpoX+Y, whilst SRUs ~debX+Y
[17:13] <teward> we COULD use ~bpo-X.Y.Z if we wanted to be distinct
[17:13] <teward> but we have to be careful we don't collide
[17:13] <mapreri> which sorts nicely for them.  if would for us as well, but honestly besides being nice to distinguish the source of the package with only one glance, there is no much benefit ime
[17:13] <ddstreet> i'm fine with requiring ~bpo version suffix
[17:14] <teward> ddstreet: while also still providing the target version in the string in case the backport goes to two releases
[17:14] <teward> (i.e. both current LTSes)
[17:14] <teward> so we'd still have the bpo suffix but would stil be able to obey the versioning policy we already have used
[17:14] <ddstreet> so for example, if bionic had version 1.0.0 and focal had 1.2.3, a backport from f-> would be 1.2.3~bpo1 right?
[17:15] <ddstreet> or something like that?
[17:15] <teward> i think that works fine
[17:15] <mapreri> I'd hardcode the target release tbh
[17:15] <teward> mmm, now that i think about it
[17:15] <teward> we should hardcode the target release in the string too
[17:15] <ddstreet> right so 1.2.3~bpo18.04.1
[17:15] <mapreri> in some form, like ~bpo18.04.1 ?
[17:15] <ddstreet> ok yep
[17:15] <teward> so ~bpo18.04.1 would be suitable
[17:16] <teward> and must be present even if we're not sending to other releases.
[17:16] <mapreri> also, backporting version 1.2.3-2ubuntu20.04.1 to bionic, how would that go?
[17:16] <mapreri> (i.e., backporting from focal-updates)
[17:16] <teward> wouldn't that just be ~bpo18.04.1 at the end of that then?
[17:16] <teward> that could be confusing but it's a relevant question
[17:16] <mapreri> that's also in my mind, I'm double checking with you :)
[17:17] <teward> we might have to sit on that and think a bit, thoughts ddstreet ?
[17:17] <mapreri> (launchpad doesn't have length restrictions in the version string right?)
[17:17] <teward> (I'm running on the end of the 1 hour meeting and work needs me for a call)
[17:17] <ddstreet> #agreed backported package versions must use suffix ~bpo along with target release version and .1, or as refined in ML discussion and stated in wiki docs
[17:17] <meetingology> AGREED: backported package versions must use suffix ~bpo along with target release version and .1, or as refined in ML discussion and stated in wiki docs
[17:17] <ddstreet> yeah let's defer the specifics of it
[17:17] <teward> agreed, defer specifics for now
[17:18] <mapreri> we should write a table with all cases like https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[17:18] <teward> agreed, once we get there.  it won't all be decided in a single meeting
[17:18] <ddstreet> yes definitely
[17:18] <ddstreet> ok let's see if we can get thru the last 2 topics quickly, we're going long
[17:18] <ddstreet> #topic security updates
[17:19] <mapreri> I think we already covered it above?
[17:19] <ddstreet> i think we covered this; the requestor/uploader is responsible for this
[17:19] <ddstreet> yep
[17:19] <ddstreet> #topic cleaning up wiki docs
[17:19] <ddstreet> i think we covered this
[17:19] <ddstreet> all the old 'enabling backports' stuff needs to be removed
[17:19] <ddstreet> and we'll update the wiki with the new process
[17:20] <ddstreet> oh and the last topic sorry
[17:20] <ddstreet> #topic restrictions on eligible packages
[17:20] <ddstreet> i think we covered this
[17:20] <ddstreet> and moved the details of it to the ML
[17:20] <ddstreet> right?
[17:20] <mapreri> pretty much yes
[17:20] <mapreri> i think we need distinct ML threads to follow up :3
[17:21] <ddstreet> yep
[17:21] <ddstreet> ok i think we made it thru all the topics
[17:21] <mapreri> how does one edit help.u.c btw?  trying to log in myself gives a gateway timeout
[17:22] <ddstreet> i think only people on the doc team can edit it?
[17:23] <ddstreet> https://wiki.ubuntu.com/DocumentationTeam
[17:23] <mapreri> https://launchpad.net/~ubuntu-community-wiki-editors so these?
[17:23] <mapreri> 3 people?
[17:24] <mapreri> oh, that's "editorial rights" which is the superpowers
[17:24] <teward> For information on contributing see the Ubuntu Documentation Team wiki page.  <-- so yeah refer to the Documentation Team's wiki for things?
[17:24] <teward> and for proper contacts
[17:24] <teward> (in the footer of help.u.c)
[17:24] <ddstreet> yep i think https://wiki.ubuntu.com/DocumentationTeam/Organization
[17:24] <ddstreet> for the various teams, looks like they have a few
[17:24] <teward> https://wiki.ubuntu.com/DocumentationTeam/Contact has the contact mechanisms right now to use
[17:25] <teward> they have a general mailing list we can use too and let them handle delegation to the proper subteam
[17:25] <mapreri> so it's probably https://launchpad.net/~ubuntu-doc-contributors looking at the descriptions mh
[17:26] <ddstreet> ok anything else before we wrap up?
[17:26] <mapreri> I suppose we just either email them or join #-doc with the changes we'll need to do later on
[17:26] <teward> ^^
[17:26] <mapreri> I think we're good for now!
[17:26] <ddstreet> i guess, do we need another irc meeting?
[17:26] <teward> i have nothing more, unless more stuff comes up via ML, I think we're good for now
[17:26] <mapreri> I think we should at least schedule it yes
[17:26] <ddstreet> or are we good to just work in irc/ml now?
[17:26] <teward> at least schedule it, agreed
[17:26] <ddstreet> ok i'll schedule one for 2 weeks
[17:27] <teward> that way we can just cancel it if we have no action discussion items
[17:27] <teward> otherwise irc/ml
[17:27] <ddstreet> #action ddstreet schedule mtg in 2 weeks
[17:27] <meetingology> ACTION: ddstreet schedule mtg in 2 weeks
[17:27] <mapreri> everybody will start their own thread in the ML to continue, but we'll probably need to sync
[17:27] <ddstreet> great, thanks mapreri teward !
[17:27] <mapreri> should I take an action to ask vorlon or other AA on how to actually handle the archive?
[17:27] <ddstreet> sure yeah
[17:28] <ddstreet> #action mapreri ask AA how to handle archive -backports approval/rejection
[17:28] <meetingology> ACTION: mapreri ask AA how to handle archive -backports approval/rejection
[17:28] <ddstreet> i'll update the agenda page with the agreeds and actions
[17:28] <ddstreet> #action ddstreet update agenda page from today's meeting items
[17:28] <meetingology> ACTION: ddstreet update agenda page from today's meeting items
[17:28] <mapreri> then well, let's see this thing progress :)
[17:28] <teward> mapreri: i have to bug vorlon anyways on a couple things - Sponsors vs. Foundations related - if you don't reach out to AAs I'll reach out to vorlon :P
[17:29] <teward> as an aside when the stuff I have to bring up (in the next couple days, unless I figure it out myself) is done
[17:29] <mapreri> we have highlighted vorlon so many times here already that we could just wait and see what he does here :D
[17:29] <teward> lol
[17:29] <teward> true
[17:29] <ddstreet> lol
[17:29] <teward> unless they've muted here
[17:29] <ddstreet> indeed i tried to avoid that in the action item :)
[17:29] <teward> yep
[17:29] <mapreri> everybody talk about vorlon during meetings yep
[17:29] <ddstreet> haha lol
[17:29] <teward> v orlon gets all the pings always xD
[17:30] <ddstreet> ok we're only 50% over time so perfect mtg length :)
[17:30] <ddstreet> #endmeeting
[17:30] <meetingology> Meeting ended at 17:30:14 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-22-16.03.moin.txt
[17:30] <ddstreet> thanks! o/
[17:30] <mapreri> heh that's fine for me
[17:30] <mapreri> btw, in which TZ are you 2 again?
[17:30] <mapreri> (CEST here)
[17:30] <ddstreet> i'm USA eastern (EDT, UTC-4 now, UTC-5 in the winter)
[17:31] <ddstreet> i think teward is USA central time?
[17:31] <teward> US Eastern
[17:31] <teward> you're off by one timezone ;)
[17:31] <ddstreet> lol i was close :)
[17:31] <teward> ddstreet: you and I are same timezone so :P
[17:32] <ddstreet> so same tz as me
[17:32] <mapreri> alright, so not _too_ far like the PT people
[17:32] <ddstreet> yeah, western usa and europe don't have much overlap
[17:33] <ddstreet> usa eastern tz is the 'sweet spot' for overlap with both europe and the americas
[17:33] <ddstreet> unfortunately we have no overlap with most of asia, though
[17:34] <teward> true statement
[17:35] <mapreri> don't worry, not even we europeans have overlaps with the relevant east zones so....
[17:36] <mapreri> or that one guy from australia that I manage to chat with only when I totally screw my sleeping time
[17:38] <mapreri> going to dinner o/
[20:24] <vorlon> mapreri, teward: I mean, I was going to ignore it to not muddle things in the channel, but :)  Anyway, as far as backport queues are concerned, it's been long enough that I very much don't remember how this works.  https://launchpad.net/ubuntu/focal/+queue?queue_state=1 exists and can be managed with the 'queue' command from ubuntu-archive-tools but I don't remember if this is where backports
[20:24] <vorlon> uploads end up
[20:26] <bdmurray> aren't there some in there now?
[20:26] <vorlon> oh sure enough
[20:26] <vorlon> :)
[20:26] <teward> *was pinged*
[20:26] <teward> *ping startled him while his head was in a rack cabinet for servers and has officially smacked himself*
[20:27] <teward> vorlon: i think the question more is how one would approve/reject something in the queue, assuming they had the rights to approve (i.e. backports).  We're redoing a lot so :P
[20:28] <vorlon> teward: well if you have the rights to do so, you get checkboxes etc on that page that you can use to submit; or you can use the queue accept / queue reject commands.  But my recollection is also that the backporters team would upload and it required an SRU team (?) member to accept
[20:29] <vorlon> if the expectation is that this will be self-service by the backports team then that's a per-pocket ACL that the launchpad team might need to adjust (and the TB should probably sign off on first)
[20:29] <teward> ddstreet: mapreri: ^^
[20:29] <teward> probably relevant to what we've discussed
[20:32] <ddstreet> we (or at least, i) do have accept/reject buttons on the release queue pages now, presumably since being added to the ~ubuntu-backporters team, so it seems we do have acl now
[20:33] <teward> i see that as well now
[20:33] <teward> ... did getting added to -backporters give us the same access as SRU? o.O
[20:33] <ddstreet> technically it looks like we have acl to -backports uploads as well as -proposed uploads, so we should be careful not to touch anythign besides -backports
[20:33] <ddstreet> yeah looks like it
[20:34] <vorlon> it certainly should not have given access to the non-backports pockets, and it's my understanding of the data model that it would not have; you should get a permissions error if you actually try to accept or reject something on -proposed
[20:34] <teward> oh hey lookit xca's in backports xD
[20:34] <teward> i forgot i backported that
[20:34] <teward> XD
[20:34] <vorlon> (feel free to attempt to reject a package from -proposed to confirm, and we can follow up w/ launchpad team as needed if it works)
[20:34] <ddstreet> ok that's good, we definitely shouldn't have acl for -proposed
[20:34] <teward> vorlon: i'll test but tell me which one to reject so you can follow up xD
[20:34] <teward> because then I can say "because vorlon said to test"
[20:35] <ddstreet> teward you could upload a pkg and then try to reject it
[20:35] <teward> good point
[20:35] <ddstreet> so it doesn't mess with someone else's upload
[20:35] <vorlon> teward: you can reject the older dwarves-dfsg upload from hirsute
[20:36] <ddstreet> teward i assume you tried that and it didn't let you reject it?
[20:36] <teward> i haven't tested yet, ERR: Multitasking
[20:37] <teward> > FAILED: dwarves-dfsg (You have no rights to reject component(s) 'universe')
[20:37] <ddstreet> i'll give it a try
[20:37] <teward> so yes it rejected
[20:37] <ddstreet> ah ok cool
[20:37] <ddstreet> perfect then
[20:37] <vorlon> it rejected you rather than you rejecting the package, check ;)
[20:37] <teward> correct.
[20:38] <teward> ddstreet: i didn't have a package ready to upload so :P
[20:38] <teward> vorlon: hence why i asked you what to reject in the off chance it DID let me reject, and we have to fix ACLs, because if you're saying reject it that means it'd have been rejected anyways xD
[20:38] <teward> basically though, we get Access Denied for universe targeted pocket
[20:38] <teward> i haven't tested Backports yet but i'm assuming the ACL is accurate then and would give us Backports target pocket access
[21:00] <bdmurray> I'd guess the youtube-dl backport is old by now
[21:00] <bdmurray> so no longer relevant and safe to reject
[21:10] <teward> bdmurray: in which OS?  The way I think we were going to do was reject all current backports in the queue and 'start fresh' but I'm happy to test our ACL powers by rejecting a youtube-dl backport
[21:10] <teward> oop there it is in Focal
[21:11] <teward> yep that reject worked, so we know we have Backports acl


[09:31] <jtv> henninge, care to review my fix?  https://code.edge.launchpad.net/~jtv/launchpad/bug-487445/+merge/15185
[09:31] <henninge> jtv: let's see what you are fixing ...
[09:32] <henninge> jtv: wow, you are quick!
[09:32] <jtv> henninge: I wrote the fix this morning
[09:33] <jtv> when I saw that stub was ahead of me I marked my bug invalid, but kept the branch around
[09:33] <henninge> jtv: still waiting for the diff to appear.
[09:33] <jtv> http://paste.ubuntu.com/326709/
[09:34] <henninge> jtv: Actually, I was not sure if all the dependcies are needed but lazr.choiceedit is needed for sure.
[09:34] <jtv> henninge: it can sometimes be worth whittling that down... not a job for this branch though I think
[09:34] <jtv> we want a quick fix here
[09:35] <henninge> jtv: true, r=me
[09:35] <jtv> thanks
[09:36] <henninge> jtv: I was starting on a branch to fix that when I hit the APR_CONFIG problem.
[09:37] <jtv> stuart hit that one too
[09:38] <jtv> oops, I'm running out of time... have a bunch of things to do outside
[09:38] <jtv> started work far too early; various little brush fires
[09:38] <henninge> jtv: go ahead, see you later, then
[09:38] <jtv> my branch is in pqm... please watch it for me!
[09:38] <henninge> jtv: thanks, I will
[12:11] <bac> good morning gmb
[12:11] <gmb> Hi bac.
[12:11] <gmb> Another quiet day today, it seems.
[12:11] <gmb> Well, so far anyway.
[12:12] <bac> quiet is good
[12:15] <gmb> Indeed.
[12:15] <gmb> So good, I think I'll grab some lunch.,
[12:27] <jtv> gmb: thanks for the review
[14:59] <barry> gmb, bac if you're looking for something to review, would you like to take my lazr-js branch?  https://code.edge.launchpad.net/~barry/lazr-js/482298-picker-batching/+merge/15176
[14:59] <bac> barry i'd love to!
[14:59] <barry> bac: awesome, thanks
[15:03] <bac> barry: is there an URL that demonstrates it?
[15:08] <barry> bac: the best thing to do is load the examples/picker/index.html file
[15:08] <bac> barry: ok
[15:08] <barry> bac: by choosing "numbers" you get the simplified api; "letters" gets you the more complex api
[15:08] <bac> rt
[15:14] <bac> barry: i've loaded that page.  the 'show widget' button is disabled.  have i done something wrong?
[15:14] <barry> bac: hmm...
[15:14] <barry> bac: did you run 'make'?
[15:15] <bac> nope
[15:15] <bac> doing so now
[15:16] <barry> bac: i just tried it.  it doesn't seem to help
[15:16] <bac> oy
[15:16] <barry> bac: something's changed/broken in trunk i think.  let me ping the rhinos
[15:17] <bac> ok
[15:21] <bac> barry: after the make the picker example now loads
[15:21] <barry> good!  unfortunately it still doesn't for me :(
[15:22] <bac> reloaded the page?
[15:23] <barry> yep, js errors
[15:23] <barry> i'm trying the trunk now
[15:24] <barry> trunk works.  i'm chatting w/ noodles775 in rhinos to try to fix my branch
[15:27] <bac> barry: what's the deal with the roman numerals in index.html?  is it used?
[15:27] <barry> no, it's just sample code
[15:27] <bac> ah, ok
[15:29] <barry> bac: make clean & make fixed my local problem
[15:29] <bac> ok
[15:32] <bac> barry: it looks good to me.
[15:33] <barry> bac: thanks
[17:10]  * gmb EoDs
[20:37] <abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/errorlog-context/+merge/15217 ?
[20:43] <bac> abentley: certainly
[20:52] <bac> abentley: r=bac
[20:52] <abentley> bac: Thanks!
[21:03]  * bac -> EOD
[22:24] <bigjools> wgrant: after you finish checking the source format in your change, why is there an assertion error instead of an upload error if the format is not recognised?
[22:25] <wgrant> bigjools: Let me check.
[22:26] <wgrant> bigjools: We've already checked that the distroseries supports the format, so if the case isn't handled there it is a bug.
[22:27] <wgrant> We will not get into that method unless Soyuz knows about the format.
[22:27] <bigjools> okay, then it makes more sense to me to be checking enum values instead of strings then
[22:27] <bigjools> I'll add that to the review
[22:27] <wgrant> bigjools: True.
[22:28] <wgrant> That code pre-dates the enum.
[22:28]  * wgrant fixes.
[22:28] <bigjools> right
[22:36] <bigjools> wgrant: what are these new orig tarball "comp" files for?
[22:36] <bigjools> component, I mean
[22:36] <wgrant> bigjools: If I have foo_1.2-3.orig-bar.tar.gz, it will be extracted into bar/ in the new source tree.
[22:37] <bigjools> ah interesting
[22:40] <nhandler> Could someone help me with the test section of the merge proposal for https://code.launchpad.net/~nhandler/launchpad/bugfix151113 ? I'm not really sure what test would be appropriate for this (I think I've spent more time looking into what test to use than it took to patch the actual bug)
[22:41] <bigjools> nhandler: If I have time I can take a look in a while when I've finished reviewing wgrant's branch
[22:41] <wgrant> nhandler: lib/lp/blueprints/doc/specification-notifications.txt
[22:42] <nhandler> Thanks wgrant
[22:50] <nhandler> I might be mis-interpreting the test result, but it looks like it is failing because I fixed the bug. It is expecting a notification with the incorrect white space. In this case, should I just patch the test?
[22:51] <wgrant> nhandler: Exactly.
[23:03] <nhandler> Alright, I just proposed the branch for merging
[23:31] <bigjools> nhandler: I approved it but I can't land it right now, can you find someone else who will do it for you please
[23:32] <nhandler> bigjools: Yeah, I'll try. Thanks for approving it
[23:32] <bigjools> np - perhaps... /me looks around.... barry or bac can do it?
[23:32] <wgrant> bigjools: I considered using lambdas, but I think I really need statements.
[23:33] <bigjools> wgrant: the other option is to slap it all in a new class
[23:33] <bigjools> but it's up to you
[23:33] <bigjools> I just don't like a gazillion chained elifs :)
[23:34] <wgrant> Right.
[23:34] <bigjools> and on that note, I need to EOD
[23:34] <wgrant> Thanks.
[23:34] <bigjools> as the sun sets over Austin
[23:35] <bigjools> no prob - I'll check it first thing tomorrow.  I'm not sure if we ought to land it just yet in case some 3.0 packages hit the builders before they're ready
[23:36] <bigjools> although I guess the lack of a new dpkg on cocoplum would prevent that
[23:36] <wgrant> bigjools: We just won't allow the new formats in any serie yet.
[23:36] <bigjools> ah of course
[23:36] <bigjools> ok, cool, then I'll get it landed in the morning if it looks good
[23:36] <wgrant> Great.
[23:37] <bigjools> thanks a bunch for making the change
[23:37] <wgrant> np
[23:40] <bac> bigjools: wha? you're in austin?
[23:40] <bigjools> yes
[23:40] <bigjools> bac: I went to the last UT home game on Saturday :)
[23:42] <nhandler> bac: Would you be up for landing https://code.edge.launchpad.net/~nhandler/launchpad/bugfix151113/+merge/15225


[01:55] <dany1977> hi
[01:55] <dany1977> help pls
[02:00] <Bashing-om> dany1977:  Real hard to help when the problem is unknown .
[02:00] <dany1977> 10x
[02:01] <dany1977> i have wifi signal week
[02:01] <dany1977> but em windows its fool
[02:02] <dany1977> RTL8187SE


[12:09] <shawarma> crimsun: Have you looked at axiom at all?
[12:09] <crimsun> no
[12:10] <shawarma> crimsun: mkay.
[12:10] <ryanakca> crimsun: you stutturing at me? or at someone else ???
[12:11] <ryanakca> hmmm... most of the ones on "candidates" look difficult...
[12:11] <shawarma> whiskey... tango.. foxtrot...
[12:12] <shawarma> I'm building axiom.. I'm looking at the build log and nothing is happening. I get curious and check ps.. There's a "sleep 1800" running. Owner: 1234 (the pbuilder uid)..
[12:13] <ogra> sounds like it takes a deep breath before it explodes :P
[12:14] <shawarma> ogra: Yeah. good thing the server's at the other end of the country, so I'm not around when she blows. :-)
[12:15] <shawarma> ah... it appears that debian/rules binary target echoes a tick every 1800 seconds to show that it's still running.
[12:15] <crimsun> ryanakca: I'm musing over your "easy to package packages that need packaging".
[12:15] <ryanakca> lol
[12:15] <shawarma> I get the feeling this is going to be a slooooooooow build.
[12:15] <ryanakca> thought so :)
[12:15] <ryanakca> most of the one's I've attempted so far are error galore
[01:01] <ryanakca> hmmm... the source directory has ./configure, Makefile.am & Makefile.in, but no "Makefile"... what do I do?? (If you feel like forwarding me to a HOWTO, that's fine :) )
[01:04] <TheMuso> ryanakca: Thats how it should be. Many packages come like that.
[01:04] <TheMuso> the configure script creates the Makefile.
[01:04] <ryanakca> ./configure didn't create one :)
[01:05] <TheMuso> Well it may have failed. Did you see any error messages?
[01:05] <ryanakca> nevermind :)
[01:05] <ryanakca> ignorance on my part :)
[01:09] <kmilo> ryanakca, welcome to autotools http://en.wikipedia.org/wiki/Autotools
[01:11] <ryanakca> :)
[01:12] <kmilo> there are strange and complicated but very popular
[01:12] <zul> wohoo...amd64 is building now
[01:14] <ryanakca> hmmm... this app is wonderfull... it has a dependency that isn't in the repositories.... how would I test it with pbuilder if the dependency isn't in Universe/repos?
[01:14] <zul> you would have to create a package for the dependency
[01:15] <ryanakca> that's what I'm doing :)
[01:15] <ryanakca> but pbuilder gets all dependencies from Universe/Multiverse... so once I've packaged dependency, how will I pbuild the app?
[01:15] <ryanakca> or do I have it all wrong?
[01:23] <LaserJock> there are a couple things you can do I think
[01:24] <LaserJock> what I've done in the past was set up a mini repo that I put the first package in and gave that in the OTHERMIRROR line with Universe and Multiverse
[01:25] <LaserJock> but I think you can actually install the first package into your pbuilder or use a bindmount or something
[01:25] <ryanakca> bindmount? install the first package into my pbuilder? I'm lost :)
[01:26] <ryanakca> I think setting up a mini repo is probably easier... Se veas has some kind of app for doing that I think.. right?
[01:26] <ryanakca> he uses it for his repos...
[01:27] <LaserJock> ryanakca: I used mini-dinstall I think
[01:28] <LaserJock> the other ways I've seen are easier but you have to know what to do and my brain seems unable to remember what it was
[01:31] <shawarma> ryanakca: has he released it now?
[01:32] <shawarma> ryanakca: Anyhow, I use reprepro. It works really well.
[01:36] <ryanakca> shawarma: dunno
[01:38] <shawarma> ryanakca: I talked to him about it about six months ago, I think. He was just about to release it, but I needed something right away.
[01:39] <ryanakca> shawarma: I don't see any link to it on his page
[01:40] <ryanakca> reprepro it is :)
[01:41] <shawarma> ryanakca: Feel free to steal my configuration file: http://www.linux2go.dk/ubuntu/conf/distributions
[01:42] <shawarma> Gah... I need to get some sleep. It's almost 2am here.
[01:42] <shawarma> G'night, guys!
[02:08] <jabra> if I have a package I would like to submit for review is dapper still ok or do I need to dist-upgrade to a newer version?
[02:18] <crimsun> jabra: edgy. Nothing new goes into dapper, which is a frozen, released distro.
[02:18] <ajmitch> hi
[02:18] <crimsun> hi ajmitch
[02:20] <jabra> k
[02:20] <jabra> I will switch to edgy then
[02:20] <jabra> thanks
[02:20] <crimsun> jabra: you don't have to switch to edgy, but be aware that packages will have to be targetted for edgy.
[02:21] <jabra> well i'm buildin a vm
[02:22] <jabra> wait this might actually solve my problem
[02:23] <jabra> if I get this package accepted into debian how long would it take to get into edgy
[02:24] <crimsun> it can just be synced in
[02:24] <crimsun> until late Sept., that is
[02:25] <jabra> so I guess I should just focus on that
[02:25] <jabra> anychance you could review a debian package?
[02:59] <crimsun> jabra: more context/URL?
[03:00] <ryanakca> shawarma: back, ty
[03:10] <LaserJock> \o/
[03:19] <kmilo> bye
[03:19] <LaserJock> bddebian!
[03:19] <ajmitch> hey LaserJock
[03:20] <ajmitch> LaserJock: can you make some changes to the packaging guide about REVU?
[03:20] <bddebian> Heya gang
[03:20] <bddebian> LaserJock!!!!!!!!
[03:20] <LaserJock> ajmitch: perhaps, what's on your mind?
[03:20] <ajmitch> since at the moment it's telling people to send their key in - it needs updated to mention joining the launchpad group
[03:20] <LaserJock> bddebian: I'm in xchat, in Ubuntu, on my intel mac!
[03:20] <bddebian> Sweet
[03:21] <ajmitch> we're getting a number of people still sending their keys to us
[03:21] <LaserJock> ajmitch: ok
[03:21] <ajmitch> updated details should be on the REVU wiki page
[03:22] <LaserJock> !revu
[03:22] <ubotu> 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:23] <jabra> crimsun: trying to upload it to the mentors site but it is saying the gpg key is failing
[03:26] <LaserJock> ajmitch: ok, added it to my TODO
[03:26] <ajmitch> thanks
[03:26] <LaserJock> bbl
[03:27] <jabra> crimsun: it said my public key was not found
[03:27] <jabra> though when I logged in it has it right
[03:28] <jabra> and i'm using the same key to sign the packages
[03:28] <ryanakca> dunno if this is the right channel to ask this, but oh well :)
[03:28] <ryanakca> "sudo reprepro -Vb /etc/reprepro includedeb edgy /var/cache/pbuilder/result/typespeed_0.5.1-1_i386.deb" gives me this error: "gpgme gave error: No Passphrase". What's wrong?
[03:28] <crimsun> jabra: are you referring to REVU or mentors.debian?
[03:29] <jabra> mentors
[03:31] <crimsun> jabra: I'm not familiar w/ mentors.debian, sorry.
[03:31] <crimsun> a few others here are
[03:32] <jabra> anyone know what i'm doing wrong
[03:33] <jabra> the error that was in the mail was gpg: Can't check signature: public key not found
[03:34] <jabra> wait I think I know why
[03:40] <jabra> nopes
[03:44] <bddebian> shawarma: ping?
[04:02] <ajmitch> oh goody, Xgl at least starts now
[04:18] <Lathiat> i upgraded to edgy and this new fandangled UUID stuff renders my system unbootable :)
[04:18] <jabra> crimsun: got it uploaded
[04:18] <Lathiat> i did manage to boot by going back to my way oldest dapper kernel adn changign to root=/dev/md2
[04:19] <Lathiat> but root=/dev/md2 on a new kernel just sits there forver 'waiting for rootdevice'
[04:19] <Lathiat> ;p
[04:19] <jabra> http://mentors.debian.net/debian/pool/main/p/pbnj
[04:19] <jabra> http://mentors.debian.net/debian/pool/main/l/libnmap-parser-perl/
[04:21] <ajmitch> Lathiat: lucky you
[04:21] <ajmitch> Lathiat: I haven't tried rebooting with the new kernel yet
[04:30] <bddebian> OK, where the hell is acidrip in Debian?
[04:31] <tseng> if you are going to continue posting your random thoughts on irc, do you really have to swear at us?
[04:32] <tseng> it doesnt appear to be in debian
[04:32] <tseng> its in marillat
[04:32] <bddebian> Swear AT you?
[04:32] <tseng> which probably means its too scary to distribute.
[04:33] <tseng> oh
[04:33] <tseng> I thought you were bluefoxicy
[04:33] <tseng> very sleepy.
[04:33] <bddebian> :-)
[04:33] <bluefoxicy> what
[04:33] <bddebian> wb LaserJock
[04:33] <tseng> he usually runs through with random comments like that swearing up a storm
[04:33] <bluefoxicy> tseng what the hell are you talking about
[04:33] <tseng> haha.
[04:33] <bddebian> Hmm, it seems a few of the packages on slomo's list are from Marillat, etc
[04:34] <ajmitch> tseng: no, bddebian usually says 'WTF??'
[04:34] <bddebian> Yep
[04:34] <tseng> haha.
[04:34] <bddebian> I honestly get no freakin' love around here..
[04:35] <ajmitch> you'll survive
[04:35] <whiprush> I love you dude.
[04:39] <LaserJock> bddebian: hmm, have you looked at the build logs for the packages up synced/merged?
[04:40] <LaserJock> bddebian: in particular regina-normal isn't building on much
[04:41] <bddebian> LaserJock: No not yet
[04:42] <bddebian> I hate not having other archs to build on
[04:42] <LaserJock> it looks like i386 is really backed up
[04:43] <bddebian> Aye :-(
[04:43] <ajmitch> OOo
[04:44] <ajmitch> when 3+ uploads are made in a short time, nothing else has a chance
[04:45] <LaserJock> but wouldn't that hit all the arch's the same or is OOo only built i386?
[04:46] <ajmitch> ppc & sparc are both building OOo at the moment
[04:46] <ajmitch> https://launchpad.net/+builds
[04:46] <ajmitch> oh, and amd64, except amd64 has 1 idle buildd
[04:46] <bddebian> Does marillat have a web site?
[04:47] <ajmitch> bddebian: talk to slomo before touching them
[04:47] <bddebian> He's the one that asked me to look at them
[04:47] <LaserJock> ah, so so you became somebody else's slave?
[04:48] <LaserJock> ;-)
[04:49] <bddebian> Well you told me to stop requesting syncs :-)
[04:52] <Laser_away> fine, be that way ;-)
[04:54] <bddebian> Ack, oleo
[04:59] <ajmitch> ah, my fonts are so very messed up
[04:59] <bddebian> fonts suck
[04:59] <ajmitch> such a helpful remark
[04:59] <bddebian> :-)
[05:00] <bddebian> That's me, Mr. Helpful
[05:21] <LaserJOck> bddebian: lol
[05:21] <LaserJOck> what a comment in -devel :-)
[05:21] <ajmitch> odd people
[05:21] <bddebian> LaserJOck: :-)
[05:21] <bddebian> I love you too ajmitch
[05:21] <ajmitch> I really hope mvo speeds up apt again
[05:22] <ajmitch> pbuilder checking lots of build-depends takes about as long as the compile itself
[05:22] <bddebian> Aye
[05:22] <ajmitch> especially with this many split X packages
[05:24] <ajmitch> all that waiting for pbuilder, and I forgot to update the patch
[05:27] <bddebian> heh
[05:27] <ajmitch> I should really move it to bzr
[05:27] <ajmitch> or git
[05:28] <ajmitch> git may be a better choice, since it's a snapshot of a git tree
[05:29] <crimsun> edgy's git knocks the pants off dapper's (unsurprisingly)
[05:30] <ajmitch> I've never got to learn it properly
[05:35] <LaserJOck> is git pretty user friendly?
[05:36] <LaserJOck> for somebody who has used svn and bzr before?
[05:36] <ajmitch> I never found it that friendly
[05:37] <LaserJOck> hmm, that's not a good sign
[05:37] <ajmitch> crimsun has used it a lot more :)
[05:38] <crimsun> git-core is the 'plumbing'; I recommend trying a gui frontend ('porcelain')
[05:39] <ajmitch> like cogito?
[05:39] <crimsun> yep
[05:39] <ajmitch> it'd probably make my life easier
[05:39] <crimsun> LaserJOck: git's really good at certain things and not very good at others; I've only used it for kernel stuff
[05:39] <bddebian> A GUI?  Sacrilege :)
[05:44] <LaserJOck> bddebian: sometimes it's the only thing we've got ;-)
[05:45] <bddebian> I like GUIs for a lot of things, I am just being my normal irritating smart-alec
[05:46] <LaserJOck> today I tried out a nice GUI OS X app for scp and sftp out
[05:46] <LaserJOck> very nice
[05:46] <LaserJOck> called fugu
[05:47] <ajmitch> nice, X fails to start on the laptop. things are looking up
[05:48] <bddebian> heh
[05:49] <ajmitch> I suspect it's the module ABI problem, since it can't load the i810 driver
[05:50] <crimsun> there's a deb in tiber:~ built against the newest ABI if you want to use it
[05:51] <crimsun> though it's for i386
[05:51] <ajmitch> crimsun: too late, it's already building here
[05:51] <crimsun> :)
[05:52] <crimsun> AIGLX seems to be much more 'responsive' than XGL thus far (using xfwm4's compositor)
[05:52] <ajmitch> crimsun: you have AIGLX enabled?
[05:52] <crimsun> yeah, it's enabled by default in the new xserver-xorg-core
[05:52] <ajmitch> I didn't think that rodarvus was enabling that in his initial upload
[05:52] <ajmitch> interesting, will try that
[05:53] <crimsun> the only change I made to xorg.conf was to load the composite extension
[05:54] <ajmitch> amazing how much slower the laptop's disk is
[05:55] <ajmitch> recompile of driver worked though
[05:55] <ajmitch> ah, I already had composite enabled
[05:56] <ajmitch> crimsun: does AIGLX show up in xdpyinfo?
[05:56] <crimsun> not that I can tell
[05:56] <ajmitch> hm, interesting
[05:56] <ajmitch> bug 54205 only shows on my amd64
[05:56] <Ubugtu> Malone bug 54205 in gtk-engines "font rendering broken in edgy" [Medium,Needs info]  http://launchpad.net/bugs/54205
[05:57] <ajmitch> (could be freetype)
[05:57] <crimsun> hmm, quite possibly
[05:57] <crimsun> the first line from ``grep -i aiglx /var/log/Xorg.0.log'' shows AIGLX enabled here
[05:57] <ajmitch> happens in konsole as well, so I doubt it's gtk2-engines
[05:57] <Amaranth> now i just need a driver that supports GLX_EXT_texture_from_pixmap (damn nvidia)
[05:58] <ajmitch> crimsun: yes, enabled here too. good
[05:59] <ajmitch> current spiftacity package breaks impressively
[06:00] <ajmitch> I'm guessing xubuntu-desktop seed needs updated for gtk2-engines?
[06:02] <crimsun> ah, it's libthunar-vfs-1
[06:06] <ajmitch> odd, the font rendering bug goes away when I use Xgl
[06:17] <ajmitch> crimsun: xfce looks really nice, it's improved a lot since I last tried it :)
[06:18] <ajmitch> compositing is quite fast, too
[06:18] <crimsun> :)  Mostly Jani's and Gauvain's poking, along with nomed's.
[06:18] <crimsun> yeah, I'm very impressed.
[06:19] <ajmitch> do you know how to get xfce4-terminal to respect alt+left/right?
[06:19] <ajmitch> for irssi+screen, that is
[06:20] <crimsun> no, may be a compat issue
[06:20] <ajmitch> most terminals don't let me do it
[06:21] <crimsun> since alt+# changes xfce4-terminal tabs instead of irssi buffers
[06:21] <ajmitch> alt+number works
[06:28] <whiprush> ajmitch: stupid question.
[06:28] <ajmitch> yessir?
[06:29] <whiprush> but doesn't aiglx come with xorg 7.1 built in?
[06:29] <ajmitch> other way round
[06:29] <whiprush> yeah
[06:29] <whiprush> wow, that was a horrible sentence
[06:29] <bddebian> Gnight folks
[06:29] <ajmitch> however it's a build-time option
[06:29] <whiprush> ah, I see
[06:29] <ajmitch> and I thought rodarvus may not have enabled it yet
[06:29] <whiprush> now that makes sense
[06:30] <ajmitch> given his answer yesterday of:
[06:30] <ajmitch> 13:56 < rodarvus> mjg59, not right now (it wasn't specced), but I plan to, if time allows
[06:31] <ajmitch> 13:56 < rodarvus> not sure if its going to happen for Edgy, though
[06:31] <whiprush> cool
[06:31] <imbrandon> moins all
[06:31] <ajmitch> but yeah, all you need to do is enable the composite extension, if it wasn't already
[06:31] <ajmitch> hi imbrandon
[06:31] <imbrandon> heya ajmitch
[06:31] <whiprush> hi imbrandon
[06:31] <imbrandon> hiya whiprush
[06:32] <imbrandon> looks like good news on the ML ;)
[06:32] <whiprush> signs point to a sweet Fridge in the future!
[06:32] <ajmitch> more shady dealings?
[06:32] <whiprush> nah, opening it up to the community
[06:32] <whiprush> lots of volunteers.
[06:33] <whiprush> really good stuff happening
[06:33] <imbrandon> yea , tis lookin good
[06:34] <imbrandon> hrm ....
[06:35] <LaserJOck> hi imbrandon
[06:35] <imbrandon> hey hey LaserJOck
[06:35] <imbrandon> heh i was wondering about the O
[06:35] <imbrandon> ;)
[06:37] <LaserJock> typo
[06:37] <imbrandon> sure <eg>
[06:38] <imbrandon> i found 3 more laptops for good prices on craigslist today, might go pick them up and load dapper on them and resell them ;)
[06:41] <ajmitch> hi viviersf
[06:42] <viviersf> lo ajmitch
[06:42] <viviersf> i cant believe im at work this early :/
[06:42] <imbrandon> heh
[06:42] <ajmitch> heh, how early is it?
[06:42] <viviersf> 6:30 am
[06:42] <imbrandon> ahh thats not tooooo bad
[06:43] <imbrandon> 5:30 sucks
[06:43] <ajmitch> 6:30 still hurts
[06:43] <viviersf> im not used to it tho
[06:43] <ajmitch> that's more like time to go to bed
[06:43] <imbrandon> hahah how true
[06:43] <imbrandon> its about midnight here and i'm just really getting going for the night
[06:43] <imbrandon> ;)
[06:45] <imbrandon> any irssi users here ? is there a way to have sound notification when your name is hilighted ?
[06:45] <ajmitch> I doubt it
[06:46] <imbrandon> becouse colloquy isnt cutting it
[06:46] <ajmitch> maybe you could hack some script together for it
[06:46] <imbrandon> yea true , trigger mpg123 to play a short mp3 or something
[06:47] <LaserJock> I wonder if macirssi would do it
[06:47] <imbrandon> osx really lacks alot, what it does do it does good but alot of simple things i miss , probbaly time to just go 100% linux
[06:48] <imbrandon> LaserJock: yea thats what i'm using colloquy atm but need something better , was thinking irssi from fink
[06:49] <imbrandon> colloquy was supose to be based on irssi in some strange way but i dont think thats the case anymore
[06:50] <imbrandon> really honestly the only reason i keep osx on here is becouse of quicktime player
[06:50] <imbrandon> guess i could try to get all that working on ppc in linux ;)
[06:50] <crimsun> http://lists.debian.org/debian-user/2004/07/msg04246.html
[06:50] <imbrandon> you rock crimsun
[06:50] <crimsun> google rocks.
[06:51] <ajmitch> scary
[06:51] <imbrandon> heh
[06:51] <ajmitch> I could never handle that turned on in irssi
[06:51] <ajmitch> not when my computer is in my room
[06:52] <imbrandon> well you could turn beeps when away off
[06:52] <imbrandon> probably be good
[07:51] !lilo:*! early morning service is occurring on one of our temporary main rotation servers; about 1,419 users affected
[09:53] <dholbach> good morning
[10:13] <Toadstool> 'morning everybody
[10:41] <shawarma> ryanakca: did you figure out the reprepro error?
[11:04] <Arbiter> good day
[11:40] <ajmitch> great, box is moderately unbootable now
[11:41] <ajmitch> out with the stack of live cds
[11:44] <viviersf> lol ajmitch
[11:44] <viviersf> same old same old
[11:47] <ajmitch> fun time to upgrade to edgy
[11:47] <viviersf> :/
[11:48] <viviersf> i think ill stick with dapper ;P
[11:48] <shawarma> Which $TZ is bddebian in? (aka: when does he usualy show up here?)
[11:48] <ajmitch> initramfs isn't loading my LVM volumes on RAID
[11:48] <ajmitch> shawarma: he's in the US
[11:49] <ajmitch> shows up at random times
[11:49] <shawarma> ajmitch: Heh. It would appear he logged off no more than 5 hours ago, so it'll probably be a few hours still.
[11:52] <ajmitch> ah, bug 72740
[11:52] <ajmitch> bug 52740, that is
[11:52] <Ubugtu> Malone bug 52740 in initramfs-tools "[EDGY]  Regression: can't boot from lvm root on raid anymore" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52740
[11:58] <snowblink> hi - is anyone working on Apache 2.2?
[12:05] <Mithrandir> snowblink: yes.
[12:06] <snowblink> Mithrandir, thanks. Is there a deb yet?
[12:07] <Mithrandir> snowblink: yes and no.  It's not suitable for general consumption without a fair amount of testing of modules, but the apache debs themselves are almost there.
[12:08] <snowblink> Mithrandir, okay thanks. Will continue on with Apache 2.0 + Pound for the time being then. :)
[02:40] <zul> hey
[02:40] <shawarma> hey, zul
[02:51] <lloydinho> hey shawarma, did you get my message?
[02:53] <Hobbsee> hi all!
[02:53] <Hobbsee> hi bjp :)
[02:56] <Arbiter> heya Hobbsee :D
[02:56] <ajmitch> good evening Hobbsee
[02:57] <Hobbsee> hi Arbiter, ajmitch
[02:57] <Hobbsee> a friend at a gaming forum has posted about how involved i am with ubuntu.  interseting.
[02:57] <Arbiter> ??
[02:57] <zul> oooh...link?
[02:57] <Hobbsee> http://www.moreawesomethanyou.com/smf/index.php/topic,5071.0.html
[02:59] <Arbiter> Hobbsee, btw, can you review kdocker?
[02:59] <Arbiter> :)
[02:59] <Hobbsee> hey now, i just got home!
[02:59] <Hobbsee> i've got no idea what's happening around here.
[02:59] <Arbiter> :D
[03:01] <bjp> Nice hobbsee :)
[03:02] <zul> well...not much *is* happening
[03:02] <Hobbsee> ah.
[03:02] <Hobbsee> just that forum thread
[03:06] <shawarma> lloydinho: Sure did. Right now it doesn't look like I'm going..
[03:06] <lloydinho> aw, shame!
[03:06] <shawarma> lloydinho: Going to Italy for 10 days (7th - 17th), so another week on the go doesn't seem all that likely.
[03:07] <lloydinho> shawarma: yes, that does seem a bit on the steep side.
[03:07] <lloydinho> Would be fun, tho...
[03:12] <shawarma> lloydinho: definitely!
[03:13] <lloydinho> I'll guess if you're unavailable, I'll have to extend the offer to the MOTU mailing-list and see if anybody would interested...
[03:14] <lloydinho> shawarma: BTW I still owe you the money, so send me some details so I can transfer them to you..
[03:17] <shawarma> lloydinho: Will do.
[03:19] <lloydinho> shawarma: cool.
[03:20] <Hobbsee> hi shawarma
[03:23] <shawarma> hi Hobbsee !
[03:29] <shawarma> Oh, it's late. gotta run!
[03:59] <bddebian> Heya gang
[04:00] <Hobbsee> Laser_away: ping, at some point
[04:00] <ajmitch> hello bddebian
[04:01] <bddebian> Heya ajmitch
[04:01] <bddebian> Hi Hobbsee
[04:01] <bddebian> Hobbsee:
[04:01] <bddebian> hamlib (1.2.5-7) unstable; urgency=low
[04:01] <bddebian>  .
[04:01] <bddebian>    * Update to new python policy
[04:01] <bddebian>    * Update standards version 3.7.2
[04:01] <bddebian>    * This work by Barry deFreese of Ubuntu, thanks! Closes: #379191.
[04:01] <Hobbsee> bddebian: yep, just saw in -devel :D
[04:01] <ajmitch> yay, spammed in 2 channels! :)
[04:01] <Hobbsee> ajmitch: hush you.
[04:01] <Hobbsee> good ajmitch.  dont rain on the parade.
[04:01] <bddebian> ajmitch: Yeah, sorry, I didn't think about Hobbsee being in both
[04:05] <ryanakca> shawarma: nope... I made my own repo from scratch :)
[04:06] <ryanakca> shawarma: join #debian and go "/msg dpkg own repo"  :)
[04:11] <bddebian> Crap, hamblib -7 isn't on the ftp yet :-(
[04:12] <ajmitch> bddebian: it can take up to a day
[04:12] <ajmitch> I see it on incoming.debian.org
[04:12] <bddebian> Ah, thx
[04:13] <ajmitch> hm, not the .deb though
[04:13] <ajmitch> what are the binary names?
[04:13] <bddebian> I don't want the .deb, just the .dsc, etc
[04:13] <ajmitch> never mind, they're there also
[04:13] <bddebian>  libhamlib4-dev or some such
[04:17] <ryanakca> automake generates beautifull makefiles </sarcasm>
[04:18] <bddebian> hehe
[04:27] <ryanakca> in a makefile, when editing for packaging,   sbindir = $(DESTDIR)/sbin     ?
[04:32] <Gloubiboulga> I'd say '$(DESTDIR)/$(PREFIX)/sbin'
[04:33] <bddebian> Gloubiboulga!  I got prismstumbler 0.7.3 to build but still have a couple issues
[04:34] <Gloubiboulga> bddebian, coool :)
[04:34] <ajmitch> Gloubiboulga: currently trying out xfce, looking very nice
[04:35] <Gloubiboulga> ajmitch, I bet you'll switch to xubuntu very soon ;)
[04:35] <ajmitch> Gloubiboulga: still many things in GNOME that I like :)
[04:40] <Gloubiboulga> ajmitch, I've not tried Xgl, does it work fine?
[04:41] <Gloubiboulga> (with xfwm)
[04:41] <ajmitch> Gloubiboulga: seems to, things seem a bit slow here on this nvidia card
[04:41] <ajmitch> I'm using packages built form the latest git checkout
[04:44] <ryanakca> so... sbindir = ${prefix}/sbin    and        prefix = $(DESTDIR)/usr
[04:45] <Gloubiboulga> ryanakca, I guess
[04:53] <Hobbsee> !packagingguide
[04:53] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
[04:56] <bddebian> Heya tuxmaniac
[04:56] <ryanakca> is the wiki down? I keep getting "timeout on server"...
[04:56] <tuxmaniac> bddebian> heya man
[05:46] <bddebian> slomo: ping?
[05:46] <slomo> pong
[05:46] <bddebian> slomo: On your list of merges that you showed me, many of them appear to be from Marillat or so.  Where should I get the source from?
[05:47] <Hobbsee> Laser_away: we need to add http://www.debian.org/doc/packaging-manuals/menu-policy/ch2#s2.1 to the packaging guide, somewhere.  it's incredibly useful, and i've only just found it.
[05:47] <slomo> bddebian: the list _is_ a comparson between marillat (now known as debian multimedia) and ubuntu ;)
[05:47] <slomo> bddebian: sources are at debian-multimedia.org/pool/main
[05:47] <bddebian> Ack.
[05:48] <slomo> no need to feel stupid :)
[05:49] <bddebian> slomo: Anything in the Outdated in Edgy list you don't want me to touch?
[06:09] <slomo> bddebian: unace, faac, faad, autopano-sift
[06:09] <shawarma> bddebian: Did you figure axiom out?
[06:10] <hub> what is wrong with autopano-sift?
[06:10] <slomo> bddebian: and acroread, transcode, mjpegtools, avidemux would be the most important ones for now :)
[06:10] <shawarma> ryanakca: If you go back to reprepro, the trick is to use either gpg-agent or pass the --ask-passphrase option to reprepro
[06:11] <ryanakca> ah
[06:11] <ryanakca> shawarma: I switched to Falcon :)
[06:12] <shawarma> ryanakca: I see. Never heard of it.
[06:12] <ryanakca> shawarma: .Seveas wrote it.... http://mirror.ubuntulinux.nl/dists/dapper-seveas/all/
[06:12] <shawarma> bddebian: I managed to get it to compile and create packages just fine by tweaking it while it's building, but to get it to do it automagically? Sheesh.. that build system is SO messed up!
[06:14] <hub> slomo: what is wrong with autopano-sift?
[06:14] <slomo> hub: do you want your package replaced with one from marillat which has broken packaging? ;)
[06:15] <shawarma> ryanakca: Ah.. I see.
[06:15] <shawarma> ryanakca: Maybe I should look into it. I really like the webpage generation bit.
[06:16] <ryanakca> :)
[06:16] <hub> slomo: no I don't
[06:16] <slomo> hub: (so nothing is wrong... but i don't want bddebian to merge it from marillat)
[06:16] <hub> ah yeah
[06:17] <slomo> it's amazing how bad packages a DD can create *sigh*
[06:18] <hub> yeah
[06:18] <hub> I'm not DD
[06:20] <shawarma> slomo: Yeah. Especially considering the NM process. They're REALLY picky about who they take on, but as soon as you're a DD, apparantly you can get away with even the most broken packaging.
[06:20] <bddebian> slomo: acroread, etc, you DO want me to do?
[06:21] <Seveas> shawarma, you can use the webpage thingie without using falcon for actually managing the repo
[06:21] <bddebian> shawarma: No, I haven't gotten back to it.  How did you get it to build?
[06:21] <shawarma> Seveas: I see.
[06:21] <slomo> bddebian: yes... acroread, transcode etc are stuff we want to sync :)
[06:21] <shawarma> bddebian: I fixed the LISP code as it went along.
[06:21] <bddebian> shawarma: Well I could do that but it wasn't building hash.o in obj/linux/interp ?
[06:22] <shawarma> bddebian: But to make it build automatically I need to figure out where the list-files are coming from. I can't even figure that out. There are tons of makefiles and they ALL get overwritten during the build, so adding debugging and stuff is hell.
[06:22] <shawarma> bddebian: No, I had to fix hash.lisp to make that build.
[06:23] <bddebian> shawarma: src/interp/hash.lisp.pamphlet generates the C code for example
[06:23] <shawarma> bddebian: Not quite. It generated the lisp code, that generates the c-code.
[06:23] <bddebian> Wel aye
[06:23] <shawarma> bddebian: AFAIR anyway.
[06:23] <bddebian> *Well
[06:24] <shawarma> bddebian: That's what all the other .pamphlet files do.
[06:25] <bddebian> shawarma: What did you change in hash.lisp to make the obj file build?
[06:25] <shawarma> If anyone want's to see some SERIOUSLY messed up packaging: go see axiom.
[06:25] <bddebian> shawarma: Hehe, no kidding
[06:25] <shawarma> bddebian: don't quite remember, but it was a minor thing. There are 3 more fixes along the way.
[06:26] <bddebian> Well I know the mem_value thing
[06:26] <shawarma> bddebian: Are you the stubborn kind who wants to finish this now that you've started, or can I just take it from here and we'll both be happy?
[06:26] <shawarma> bddebian: How did you fix that one?
[06:26] <bddebian> But it still doesn't build hash.o
[06:26] <shawarma> bddebian: ah, you tried removing it from hash.h?
[06:27] <Hobbsee> night all..
[06:27] <bddebian> shawarma: No, I fixed it in src/interp/hash.blah.pamphlet
[06:27] <shawarma> bddebian: Ah.. I hadn't even gotten as far as finding that file.
[06:27] <shawarma> bddebian: that's why I had to do this stuff iteratively while it tried to build it.
[06:28] <shawarma> bddebian: Yes, VERY messed up.
[06:28] <bddebian> shawarma: I will post my fixes to my webserver for your review if you would like
[06:29] <shawarma> bddebian: Sure. The more the merrier. :-)
[06:29] <shawarma> bddebian: I'm asking about your stubbornness, because I'M the stubborn kind, so I'd like to fix this thing. :-)
[06:29] <bddebian> Yes, that is why I have been fighting this stupid thing :-)
[06:30] <shawarma> bddebian: Does this thing build on Debian?
[06:30] <shawarma> bddebian: Apparantly, it does.
[06:31] <bddebian> shawarma: I can't believe that it would.  Especially build-depping on xfree86-common
[06:31] <shawarma> bddebian: Yeah. What's up with that?
[06:32] <shawarma> bddebian: I have a hidden agenda, by the way. :-) I'm saving up to become a MOTU, so having a killer package like axiom on my packages list on Launchpad would be really good. :-)
[06:33] <shawarma> bddebian: So it's not pure stubbornness.
[06:34] <bddebian> shawarma: Nothing wrong with that :-)
[06:36] <shawarma> bddebian: :-) I figure that if I get my act together, it should be feasible within this release cycle.
[06:36] <bddebian> Absolutely
[06:36] <bddebian> Stupid makefiles.. Grr
[06:44] <bddebian> shawarma: http://www2.bddebian.com:8000/packages/axiom/
[06:46] <shawarma> bddebian: And that wasn't enough?
[06:46] <bddebian> shawarma: No, it doesn't build hash.o for some reason, even though I get no errors
[06:47] <shawarma> bddebian: Oh, right. I remember that one. :-)
[06:48] <shawarma> shawarma: Instead of chaning the "int" to "unsigned int" i did it the other way around.
[06:49] <bddebian> that should work too
[06:49] <shawarma> bddebian: No wait... That' was cfunc.
[06:49] <shawarma> bddebian: Well, I managed to do it yesterday.
[06:50] <bddebian> Hmm
[06:50] <shawarma> bddebian: I SHOULD be able to do it again.
[06:50] <bddebian> Heh
[06:50] <bddebian> I e-mailed the Debian maintainer but haven't heard anything back :-(
[06:51] <shawarma> bddebian: What makes you thing hash.o doesn't get built?
[06:52] <shawarma> bddebian: It's not that I don't believe you, I just don't see it.
[06:52] <bddebian> shawarma: I will have to start a build again and get you the error
[06:54] <shawarma> bddebian: Er.. i thought you said you didn't get any errors?
[06:55] <Viper550> Someone here liked my Kubuntu theme?
[06:55] <shawarma> Viper550: screenshot?
[06:56] <bddebian> shawarma: I don't get any errors on building hash.o but I get an error that it can't find it when it tries to load it
[06:56] <Viper550> https://wiki.ubuntu.com/Artwork/Incoming/Kubuntu-Edgy-Ideas
[06:56] <shawarma> bddebian: Oh... I'll just let it finish.
[06:57] <bddebian> Error: Cannot open the file /home/bdefreese/edgy/axiom-20050901/obj/linux/interp/hash.o.
[06:57] <bddebian> Fast links are on: do (si::use-fast-links nil) for debugging
[06:57] <bddebian> Error signalled by LOAD.
[06:57] <bddebian> Broken at BUILD-INTERPSYS.  Type :H for Help.
[06:57] <Viper550> (on the bottom)
[06:58] <shawarma> bddebian: Ah, right. I got that one with cfunc at one point.
[07:00] <shawarma> bddebian: Well, I've just dput it to my build server. I'll go grab something to eat and see how it's going when I get back.
[07:01] <shawarma> cya!
[07:01] <LaserJock> Viper550: what am I supposed to look at
[07:01] <Viper550> The last one on the bottom
[07:01] <LaserJock> Viper550: I see a sreenshot.jpg
[07:01] <Viper550> Where?
[07:02] <LaserJock> in the tarball at the end of the page where it says "Viper550"
[07:03] <Viper550> that's the GDM theme
[07:03] <Viper550> Do you even use KDE Laserjock?
[07:04] <LaserJock> sure
[07:04] <LaserJock> I use Gnome, KDE, Xfce, and screen
[07:04] <bddebian> shawarma: Later, thanks
[07:04] <LaserJock> some more than others I guess
[07:04] <Viper550> For the best look, use the KDE color scheme with the Polyester Style and Window Decoration
[07:05] <Viper550> The KDE color scheme file...I meant
[07:05] <bddebian> slomo: WTF?  Everything I wget from debian-multimedia.org comes back as index.html?
[07:05] <slomo> bddebian: get it with your browser... there's something broken :(
[07:05] <bddebian> I don't have my browswer in ssh :-)
[07:06] <LaserJock> bddebian: lynx?
[07:07] <bddebian> LaserJock: Ack :)
[07:09] <LaserJock> grrr
[07:09] <LaserJock> I *want* to like evo, I really do.
[07:10] <LaserJock> evo seems to be the worst IMAP email client I've seen
[07:16] <^ohoel> anyone aware of mplayer bugs between edgy -3 and current -4 ?
[07:18] <zul> LaserJock: use mutt
[07:18] <slomo> ^ohoel: no... which ones?
[07:21] <^ohoel> slomo: no idea really, I'm just experiencing some regressions, errors about mp3lib not available, and problems playing raw avi streams that work with -3
[07:21] <slomo> ^ohoel: mp3lib is not available... right... it was disabled from 3 to 4 because of great bugs in it that made it unusable on all machines with 3dnow
[07:22] <LaserJock> zul: I've tried. Really the only thing I don't like about mutt is that it's hard for me to see where all my new mail is. It doesn't seem very easy to go from folder to folder
[07:22] <slomo> ^ohoel: but mad and ffmpeg can do the same and are used as replacement automatically
[07:22] <slomo> ^ohoel: could you paste the output when trying to play broken stuff that worked before to a pastebin?
[07:22] <^ohoel> slomo: yeah, things seem to work regardless of the error popup. will give you the broken output, gimme a sec ;)
[07:23] <slomo> ^ohoel: ok then ignore the mp3lib stuff :)
[07:25] <Arbiter> Gloubiboulga, ping
[07:26] <^ohoel> slomo: pastebin.com doesnt want to be my friend... got an alternative?
[07:26] <slomo> ^ohoel: pastebin.ca
[07:28] <^ohoel> slomo: http://pastebin.ca/102543
[07:29] <^ohoel> works like a charm once I downgrade to -3
[07:29] <slomo> ok, so it's most probably a ffmpeg regression *sigh*
[07:29] <slomo> please file a bug and assign it to me :)
[07:29] <^ohoel> willdo ;]
[07:32] <ryanakca> how do you enable universe for pbuilder? I would look on the wiki, but it's so slow that I get "connection timed out"...
[07:34] <^ohoel> is it okay to paste terminal output directly into a malone bug description?
[07:35] <zul> its  better as an attachment
[07:39] <Arbiter> i have a question
[07:39] <Arbiter> if a package was uploaded to REVU
[07:39] <^ohoel> I wish it were more obvious how to post an attachment :]
[07:40] <Arbiter> and is not updated/reviewed since (for example) December or January
[07:40] <Arbiter> can I adopt the package and upload && maintain my version?
[07:40] <Arbiter> (in order to get it into universe)
[07:40] <siretart> Arbiter: sure
[07:41] <Arbiter> well
[07:41] <siretart> Arbiter: probably you should contact the original contributor, though
[07:42] <Arbiter> there are a lot of unmaintained packages around in REVU
[07:42] <Arbiter> gtkwifi<EMAIL_ADDRESS>  December 02 21:20    3 (0) (for example)
[07:43] <Arbiter> siretart, but.. is a REVU cleanup ever planned?
[07:43] <zul> i believe so
[07:44] <siretart> yes, among other things
[07:46] <Arbiter> siretart, uhm... and when revu2 will be released? :)
[07:47] <^ohoel> slomo: done, bug 54269 - hope I've done everything right ;]
[07:47] <Ubugtu> Malone bug 54269 in mplayer "[edgy]  Regression between mplayer 2:0.99+1.0pre8-0ubuntu3 and mplayer 2:0.99+1.0pre8-0ubuntu4" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54269
[07:48] <slomo> ^ohoel: no that's fine :) i hope i find some time for it soon...
[07:49] <^ohoel> slomo: I'm sure you have more urgent tasks than this ;)
[07:51] <siretart> Arbiter: when its done [tm]
[07:51] <Arbiter> siretart, hehe :)
[07:53] <nexu> anyone knows whats going on with ubuntu wiki site?
[07:53] <nexu> its terribly slow here
[07:55] <ryanakca> same here
[07:55] <ryanakca> so is wiki.kubuntu.org...
[07:56] <nexu> its like the 2nd time this week its being this slow ..
[07:56] <nexu> ..or actually the first time it was gone completely
[08:02] <LaserJock> everything is slow here :(
[08:02] <LaserJock> my nice uni line has gone to dial-up speeds
[08:06] <ryanakca> heh...
[08:08] <LaserJock> well, my problem seems to be with the uni since Yahoo! even takes a while to load :(
[08:08] <zul> im gine
[08:08] <zul> fine even
[08:08] <LaserJock> darn, and I was going to install kubuntu-desktop :-)
[08:08] <LaserJock> must be some higher power is preventing me from going to the darks side ;-)
[08:10] <zul> yep its called jebus
[08:10] <crimsun> you need to use an I2 mirror, LJ|
[08:10] <tseng> Alvis
[08:12] <ryanakca> everything here is fine, except the wiki
[08:13] <ryanakca> LaserJock: "Come to the dark side, we have cookies" - <personwhoinventedthisoverlyquotedquote>
[08:14] <Gloubiboulga> Arbiter, pong
[08:18] <Arbiter> Gloubiboulga, i have to go now :)
[08:18] <Gloubiboulga> Arbiter, ok, sorry for the delay...
[08:18] <Arbiter> Gloubiboulga, but the question is always the same "can you review my packages?" :D
[08:18] <Gloubiboulga> Arbiter, sure, I'll have a look... NOW :)
[08:18] <Arbiter> heheheh
[08:18] <Arbiter> see you tomorrow Gloubiboulga
[08:19] <Arbiter> and thanks :)
[08:19] <Gloubiboulga> see you Arbiter
[08:19] <ryanakca> how do you make an edgy pbuilder? errors I got at my attempt: http://pastebin.ca/102588
[08:21] <Gloubiboulga> ryanakca, if you run dapper you have to create a dapper chroot first, then upgrade it to edgy
[09:47] <bddebian> re
[09:47] <bddebian> slomo: Around by any chance?
[09:47] <slomo> yes
[09:49] <slomo> bddebian?
[09:50] <bddebian> slomo: Do any of the deb-src links for debian-multimedia work?
[09:51] <slomo> no idea
[09:51] <slomo> i simply get it from my browser :)
[09:53] <LaserJock> do you guys use debget at all?
[09:54] <bddebian> Not I
[09:54] <bddebian> slomo: You're killing me man.. :-)
[09:55] <slomo> bddebian: :P
[09:56] <LaserJock>  whatever
[09:57] <LaserJock> slomo: the trick is you need to give him treats every once in a while ;-)
[09:58] <bddebian> hehe
[09:58] <bddebian> Ack, acroread is 44Mb, it's as bad as those damn science packages
[10:01] <LaserJock> except perhaps more useful
[10:01] <bddebian> heh
[10:01] <bddebian> slomo: Will ubuntu-archive sync those, or do you fakesync them?
[10:02] <slomo> bddebian: until now i had to make changes to all packages... but i assume that they can fakesync if you give them the url in the bugreport
[10:11] <bddebian> Hmm, well acroread 7.0.8 seems to build clean in Edgy
[10:12] <slomo> bddebian: then ask for a sync :)
[10:13] <bddebian> I'm scared :-)
[10:13] <slomo> why? :)
[10:13] <bddebian> Because I ph3ar Kamion/Keybuck :-)
[10:13] <tseng> jeez
[10:13] <tseng> they are easy
[10:14] <slomo> bddebian: why?
[10:14] <tseng> mdz is the intimidating one
[10:14] <tseng> doesnt bother me much anymore
[10:14] <bddebian> Well I'm usually getting grief for doing something wrong and these aren't straight from Debian :-)
[10:15] <slomo> bddebian: just put the repository url there... and which version of what you want
[10:21] <bddebian> slomo: Aye, I'm just making sure it install
[10:21] <bddebian> =s
[10:22] <bddebian> gah
[10:34] <bddebian> Install fine too
[10:35] <bddebian> *Installs.. Sheesh
[10:39] <bddebian> slomo: submitted
[10:40] <slomo> bddebian: nice :)
[10:40] <bddebian> Is i386 still plugged up with OOo?
[10:46] <slomo> bddebian: partly
[10:47] <slomo> https://launchpad.net/+builds
[10:52] <bddebian> Well hamlib is going to fail
[11:06] <crimsun> bddebian: why?
[11:09] <bddebian> crimsun: python2.3
[11:09] <bddebian>  -7 is in Debian now that is python policy compliant
[11:09] <crimsun> it runs fine under python2.4 according to Fedora Core
[11:10] <bddebian>  -6 specifically builds python2.3
[11:10] <bddebian> *builds with
[11:10] <crimsun> right
[11:12] <bddebian> crimsun: Am I missing something?
[11:12] <crimsun> bddebian: I don't know, are you?
[11:12] <bddebian> crimsun: I mean, what spawned that?
[11:13] <crimsun> 'fail' is highlighted for this channel.
[11:14] <bddebian> crimsun: Oh, sorry
[11:18] <Windkracht8> Hello could someone please explain, or point to an explanation how the packages in the Ubuntu repository's are numbered?
[11:19] <bddebian> Later gang
[11:21] <sistpoty> hi folks
[11:23] <crimsun> Windkracht8: see the first note in http://doc.ubuntu.com/ubuntu/packagingguide/C/basic-scratch.html#id2550897
[11:23] <crimsun> Windkracht8: it's also available in System> Help> System Documentation> Packaging Guide  (in the same section, same note, etc.) if you're using Ubuntu Dapper.
[11:24] <Windkracht8> Thanks crimsun, I'm having a look at it now
[11:27] <Windkracht8> So that are Debian and Ubuntu numbers there, now it's clear thanks
[11:27] <crimsun> np
[11:29] <Lt-Elmo> hi does anyone have a idea when the new firefox and thunderbird will hit the repos
[11:33] <crimsun> when the security team applies the fixes.
[11:33] <Lt-Elmo> ahh i see
[11:33] <Lt-Elmo> was not sure how that work in linux
[11:33] <Lt-Elmo> thank you
[11:33] <LaserJock> hmm, there is a new firefox and thunderbird out?
[11:34] <Lt-Elmo> yes relesed today
[11:34] <LaserJock> why am I always missing these things
[11:34] <Lt-Elmo> 1.5 05 i think
[11:34] <LaserJock> but it's still 1.5?
[11:34] <Lt-Elmo> yes
[11:34] <Lt-Elmo> security and bugfixes
[11:34] <LaserJock> k
[11:35] <Lt-Elmo> seamonkey went 1.02 to 1.03
[11:36] <sistpoty> ubotu: please tell me the pbuilder howto link
[11:36] <ubotu> I know nothing about please tell me the pbuilder howto link - try searching http://bots.ubuntulinux.nl/factoids.cgi?db=ubuntu
[11:36] <LaserJock> !pbuilder
[11:36] <ubotu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
[11:36] <sistpoty> thanks ubotu ;)
[11:37] <LaserJock> you're welcome ;-)
[11:37] <sistpoty> hey LaserJock btw ;)
[11:37] <sistpoty> is the wiki that slow for you as well?
[11:37] <LaserJock> yes
[11:37] <crimsun> please use http://<IP_ADDRESS>/search?q=cache:2qoe1Zc4EZIJ:https://wiki.ubuntu.com/PbuilderHowto+wiki.ubuntu.com/PbuilderHowto+cache&hl=en&lr=&client=firefox&strip=1
[11:38] <crimsun> basically, "URL cache" -> cached text only
[11:38] <ryanakca> LaserJock: the maintainer of typespeed in debian seems to have vanished off this face of the earth... so I'm asking in #debian-devel
[11:38] <sistpoty> crimsun: nice, thanks... I actually just needed the url
[11:38] <LaserJock> ryanakca: ok
[11:39] <crimsun> right, the URL probably appears sluggish, hence google cache :)
[11:39] <sistpoty> hehe
[11:47] <sistpoty> ryanakca: the typespeed maintainer doesn't seem to be mia afaict... his last upload was two weeks ago
[11:48] <ryanakca> mia?
[11:48] <tseng> missing in action
[11:49] <ryanakca> I had talked to him a month and a half ago about it... he looked at the source... but still hasn't upgraded to new upstream... new upstream has been around for a while now...
[11:49] <ryanakca> ah
[11:52] <ryanakca> meh, I'll try /msging daf again :)
[11:53] <LaserJock> well, not upgrading to the latest version doesn't exactly mean mia
[11:53] <LaserJock> it could be he has good reason to not do it yet
[11:54] <ryanakca> ???
[11:56] <LaserJock> !info typspeed
[11:56] <ubotu> Package typspeed does not exist in dapper
[11:56] <LaserJock> !info typespeed
[11:56] <ubotu> typespeed: Zap words flying across the screen by typing them correctly. In repository universe, is optional. Version 0.4.4-8 (dapper), package size 41 kB, installed size 184 kB
[11:56] <slomo> !info hello
[11:56] <ubotu> hello: The classic greeting, and a good example. In repository main, is optional. Version 2.1.1-4 (dapper), package size 47 kB, installed size 472 kB
[11:56] <slomo> huh why is it in main? =)
[11:57] <LaserJock> ryanakca: ok so the current version in Dapper is 0.4.4 and what do you want?
[11:57] <ryanakca> 0.5.1
[11:58] <LaserJock> ok, so on the website I find this: "My first release will be 0.5.0. In 0.5.x I want to rewrite big chunks of code, in a developer's view, 0.5.x will be rather unstable because code moves a lot..."
[11:59] <LaserJock> perhaps that has made the Debian maintainer a bit hesitant to just hop in there and upload it
[11:59] <ryanakca> Typespeed v0.5.1 has been released, most important change is a fix of an off-by-one in file.c. I am not sure if this could be exploited, but it's a bug and it should be fixed as soon as possible. Beside of that wordfiles and highscorefiles can be in different places and typespeed should compile on systems with glibc 2.4 now...
[11:59] <ryanakca> meh... I'll try to find that virtue called patience :)
[11:59] <crimsun> what LJ quoted is a perfectly legitimate reason /not/ to update
[11:59] <LaserJock> ryanakca: dude, I'm not saying it's not worth it, you just might need to see it from the other side too
[11:59] <crimsun> or rather, to not update
[12:00] <ryanakca> LaserJock: I see your point of view :) Hadn't seen that :)
[12:00] <ryanakca> you have a point :)
[12:01] <LaserJock> so while it is wonderful to have the latest crack sometimes, I can't be mad if the Debian maitainer is hesitant
[12:01] <LaserJock> although it would be nice to get *some* feedback
[12:01] <ryanakca> I agree on the later part :)
[12:02] <ryanakca> bbl... supper
[12:02] <crimsun> hmm, notes would be good.
[12:06] <sistpoty> ryanakca: the bug seems to have been fixed in 0.4.4-10 on the debian side