[01:00] <LaserJock> cjwatson: at some point I'd be interested in a blog post on how you use VCS (or would *like* to use VCS) for packaging
[01:02] <cjwatson> LaserJock: I've been meaning to do a developer video at some point
[01:03] <LaserJock> cjwatson: that would be good
[01:04] <LaserJock> cjwatson: I just haven't found a good workflow for bzr-specifically that seemed worthwhile
[01:04] <LaserJock> I'm maintaining packages with git in Debian and it seems to work ok
[01:04] <cjwatson> I'm not doing anything particularly special with bzr for packaging
[01:05] <cjwatson> I think maybe people are just looking too hard
[01:05] <LaserJock> but I'm really kind of struggling to see a lot of improvements for Universe
[01:05] <cjwatson> you don't have to
[01:05] <dmoerner> LaserJock, have you seen this? http://www.eyrie.org/~eagle/notes/debian/git.html
[01:05] <cjwatson> as I've said multiple times in that thread, if you don't like it, you can ignore it
[01:05] <LaserJock> cjwatson: well, I don't think that's exactly accurate
[01:05] <LaserJock> we don't want to have multiple methods around, it's very very confusing for new people
[01:06] <cjwatson> it is necessary
[01:06] <LaserJock> and I don't think we can just ignore it
[01:06] <cjwatson> people will continue to send patches
[01:06] <cjwatson> whatever you do
[01:06] <cjwatson> and, frankly, I have a really hard time saying that our current processes are not horrifically confusing for new people
[01:06] <LaserJock> yeah, but if some people don't take bzr branches
[01:06] <LaserJock> then that's not a cool thing
[01:06] <cjwatson> if you step back and look at them dispassionately, they're horribly complicated
[01:07] <cjwatson> and much of that is directly due to things that revision control precisely fixes
[01:07] <LaserJock> not participating in an archive-wide workflow is going to cause issues
[01:07] <LaserJock> oh, I know they're complicated
[01:07] <LaserJock> but they're largely documented
[01:07] <LaserJock> and consistent
[01:07] <cjwatson> they really aren't
[01:08] <cjwatson> there are two or three different versions of everything spread around the place
[01:08] <LaserJock> you mean like patch systems?
[01:08] <cjwatson> even just things as simple as instructions for formatting and sending patches
[01:08] <lifeless> wow, 38K on using git
[01:08] <cjwatson> patch systems are a particular culprit, certainly, but an inherited one
[01:08] <LaserJock> right
[01:09] <LaserJock> yeah, it's not ideal, I'd agree
[01:09] <LaserJock> but just adding complexity doesn't seem to help
[01:09] <cjwatson> archive-wide workflow: I think that will sort itself out over time, and will certainly be no worse than current reality
[01:09] <LaserJock> if we're gonna move it'd be nice to just move
[01:09] <cjwatson> I ask people (who seem capable of producing them easily) for bzr branches for things, right now
[01:09] <LaserJock> but trying to leave a lot of legacy seems like a mess to document and confusing for new people
[01:09] <lifeless> LaserJock: running two VCS systems is itself complexity :- the source package archive acts as a VCS on its own
[01:10] <LaserJock> lifeless: yeah
[01:10] <cjwatson> LaserJock: IME, real systems that involve real people tend to involve real legacy handling
[01:10] <LaserJock> so far from my experience it's much easier to drop the DVCS and just use the source package VCS
[01:10] <LaserJock> but I'm hopeful there'll be a time when that's not the case
[01:10] <wgrant> lifeless: The thing there is that at least the archive as a VCS has a format shared between us and Debian.
[01:10] <wgrant> bzr is not.
[01:10] <lifeless> LaserJock: nearly all of the complexity in this space is driven by retaining that VCS as primary; I'd like to see it become a read only mirror of a better, primary vcs [e.g. bzr] eventually
[01:10] <cjwatson> wgrant: hence import work
[01:11] <wgrant> cjwatson: As much as I love bzr, importing everything seems rather one-way.
[01:11] <cjwatson> wgrant: but hence also retaining the archive-as-VCS
[01:11] <cjwatson> wgrant: not in the slightest
[01:11] <lifeless> LaserJock: the source package vcs has a number of serious scaling and participation problems. for instance, user assigned revision ids.
[01:11] <wgrant> Say we maintain something in bzr that Debian maintains in git. This is not going to be uncommon. How does this work?
[01:11] <lifeless> wgrant: its kindof-shared, but no deeper than two tailor imports of a CVS repo, when you look closely.
[01:12] <LaserJock> lifeless: I'm not saying it doesn't have problems
[01:12] <lifeless> wgrant: what do you think MoM is, if not a massively large scale tailor for debian source :)
[01:12] <cjwatson> wgrant: regular incremental import from git to bzr. worst case, the other direction goes by patches; best case, you could probably use bzr fast-export | git fast-import to construct a matching git repository
[01:12] <cjwatson> (if you wanted to put that effort in)
[01:12] <cjwatson> note that the worst case is no worse than archive-as-VCS
[01:14]  * lifeless stops his rant on the VCS-design-headaches of the archive
[01:14] <lifeless> I'd just written about three lines of rant :P
[01:14] <LaserJock> lifeless: the problem is, most people don't care :/
[01:15] <LaserJock> people just want easy ways of uploading packages
[01:15] <lifeless> LaserJock: we see prospective developers on  #ubuntu-motu DAILY that struggle with the archive-as-VCS problems
[01:15] <cjwatson> I agree that there is likely to be some difficulty once people are sending bzr branches that some sponsors aren't interested in taking
[01:15] <lifeless> I want those daily problems to stop happening
[01:15] <wgrant> Archive-as-VCS does need to die. But moving to something incompatible with most of Debian seems odd.
[01:15] <LaserJock> wgrant: +1
[01:15] <cjwatson> my suggestion there is that we develop a very simple tool that people can use to turn that bzr branch into a debdiff
[01:16] <LaserJock> cjwatson: sure, but it seems like just adding more "stuff" to the pot
[01:16] <lifeless> wgrant: debian is Archive-as-VCS, those two goals are incompatible unless you get debian to standardise on something not Archive-as-VCS.
[01:16] <cjwatson> wgrant: only for sponsors, who by definition are more capable; and only for those people who deliberately want to avoid easier tools
[01:16] <cjwatson> err
[01:16] <lifeless> wgrant: and that debate has been going on since, *at least* 2004.
[01:16] <cjwatson> s/wgrant/LaserJock/ sorry
[01:17] <wgrant> lifeless: Debian seems to largely be moving to git.
[01:17] <cjwatson> wgrant: I dispute "most"
[01:17] <LaserJock> cjwatson: what happens when somebody comes into #ubuntu-motu and asks how to contribute?
[01:17] <lifeless> wgrant: as a toolchain for managing packages, not as authoritative content.
[01:17] <cjwatson> a sizeable number of developers have moved to git, but very very many developers either use other systems (including bzr and svn) or have ignored version control altogether
[01:17] <wgrant> cjwatson: It is a not insignificant fraction, and it is growin.
[01:17] <wgrant> +g
[01:17] <LaserJock> we say , well you can either use this method or the other method
[01:17] <cjwatson> wgrant: I'm aware of that, but I completely dispute that that means we have to use git
[01:17] <lifeless> wgrant: (and I would dispute 'debian' - some prominent develoeprs sure, but other ones are arguing against git continuously)
[01:18] <lifeless> wgrant: also, svn was very popular at one point, and CVS
[01:18] <cjwatson> LaserJock: we give them a single method on a wiki page, with footnotes in case they run into problems
[01:18] <LaserJock> bzr is hardly used outside of Ubuntu, which means most people will have to learn a new VCS
[01:18] <LaserJock> many people don't know VCSs at all even
[01:18] <lifeless> wgrant: there is a huge difference between 'many packages are maintained in an external VCS' and 'Archive-as-VCS is going'
[01:18] <wgrant> cjwatson: I'd like to see us use bzr everywhere. But I'd like to not diverge unnecessarily from Debian.
[01:18] <cjwatson> "bzr is hardly used outside of Ubuntu" is a fallacy I'm getting tired of
[01:19] <lifeless> I'll say, thats news to me
[01:19] <LaserJock> that's just my experience
[01:19] <lifeless> ubuntu is our smallest user, IME.
[01:19] <LaserJock> I've seen a handful of repos from gnome
[01:19] <LaserJock> but other than that ...
[01:20]  * sistpoty pets good old cvs... stable as a rock, and as many features as a rock
[01:20] <cjwatson> wgrant: I also don't think our directions to new contributors would be especially improved by moving to git
[01:20] <cjwatson> it is by far the hardest of the current major contenders to learn
[01:20] <LaserJock> cjwatson: no, but it'd help them elsewhere at least
[01:21] <lifeless> the last presentation I saw by a git user, on using git, they had a WTF moment on their second command.
[01:21] <lifeless> in front of a lecture theatre. And this isn't unusual.
[01:21] <LaserJock> git's a lot easier for me to use than bzr, though I think bzr will be better in the end
[01:21] <cjwatson> LaserJock: IME, there are as many ways of using git as there are git users
[01:21] <cjwatson> so I don't think it would in fact help them
[01:22] <cjwatson> bzr has been better for me since somewhere around 0.7
[01:22] <LaserJock> I'm not particularly anti-bzr or anything
[01:22] <LaserJock> but it's got some real issues when it comes to packaging, IMO
[01:22] <cjwatson> namely?
[01:22] <azeem> it's not svn
[01:22] <LaserJock> speed and complexity
[01:22] <LaserJock> it takes forever to do anything
[01:23] <LaserJock> and it often require a lot of commands to do anything
[01:23] <LaserJock> formats keep changing
[01:23] <cjwatson> complexity: very similar to svn for regular packaging use
[01:23] <LaserJock> every time I go to do anything I end up spending a couple hours in #bzr getting help
[01:23] <cjwatson> formats: name when bzr last broke an old format
[01:23] <lifeless> LaserJock: No VCS that I know of has finished its formats.
[01:23] <wgrant> I have the opposite experience to LaserJock.
[01:23] <lifeless> LaserJock: even git has been making changes.
[01:23] <cjwatson> speed: have to say it just isn't an issue for me with packaging
[01:24] <LaserJock> lifeless: it's never been a problem for me, that's all I can say
[01:24] <wgrant> cjwatson: The problem with formats is that one needs to be run bzr 1.somethingverylarge or one cannot read most of the repositories.
[01:24] <sistpoty> lifeless: I'd say that cvs has :P
[01:24] <wgrant> But then again, svn broke compatibility with 1.5.
[01:24] <LaserJock> bzr seems a bit more complex than any other VCS I've used
[01:24] <LaserJock> but maybe that's just me :-)
[01:24] <wgrant> git is as complex as you can get.
[01:24] <LaserJock> I do better with git than bzr for sure
[01:25] <LaserJock> though I don't like git
[01:25] <cjwatson> how many git commands need options to do the right thing by default, and how many bzr commands need options to do the right thing by default?
[01:25] <cjwatson> (the same goes for cvs actually; less so for svn)
[01:25] <lifeless> sistpoty: actually, if you look - the atomic changeset UUID added is quite recent
[01:25] <LaserJock> I don't know, I rarely get bzr to do what I want
[01:25] <cjwatson> that truly amazes me
[01:25] <lifeless> sistpoty: only a few years ago now, and I believe there was a locking improvement done too.
[01:26] <LaserJock> and end up deleting my branches and tring something else
[01:26] <cjwatson> the basic commands are trivial and almost identical to svn
[01:26] <sistpoty> lifeless: yeah, it was a bad move in the first place... I'm quite sure the one bug in cvs I saw during the last five years is from the uuid thingy *g*
[01:26] <lifeless> sistpoty: also, back in breezy I think it was, cvs added a race condition to commit, bug is still open.
[01:26] <LaserJock> cjwatson: if the basic commands actually did what I wanted then yeah
[01:26] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/cvs/+bug/12230
[01:26] <cjwatson> LaserJock: they do what I want, reliably and consistently
[01:27] <LaserJock> cjwatson: I'm required to use a much larger "vocabulary" of command in bzr than any other VCS
[01:27] <cjwatson> than git? you have to be kidding me
[01:27] <sistpoty> but also, cvs is as user-friendly as a rock... a particular spikey one, to be precise
[01:27] <LaserJock> git's rather easy
[01:27] <cjwatson> git's vocabulary is outrageous
[01:27] <LaserJock> git has a nasty vocabulary, but I only need a small part of it to do what I want
[01:27] <LaserJock> bzr has a nice vocabulary, but I need to know a lot more of it than I'd like
[01:28] <wgrant> Are you sure that you're not trying to do different things in bzr?
[01:28] <LaserJock> who knows
[01:28] <wgrant> I can't see how anybody could find git easier.
[01:28] <lifeless> rather than going generic here
[01:28] <LaserJock> well, every time I try things in bzr there's some problem, some bug, some great new feature I need
[01:29] <lifeless> how about - LaserJock next time you are willing to give bzr a shot, grab myself, or james_w, and we'll give you a hand
[01:29] <lifeless> with the version in intrepid :)
[01:29] <LaserJock> lifeless: that's precisely the problem
[01:29] <LaserJock> I do that all the time
[01:29] <LaserJock> with git I don't need to
[01:29] <_MMA_> LaserJock: +1
[01:29] <LaserJock> I need hand-holding from bzr experts/devs to use bzr
[01:29] <LaserJock> bzr makes me feel stupid
[01:30] <cjwatson> I have to say, I think you are the exception
[01:30] <LaserJock> git, for the most part, "Just Works"
[01:30] <cjwatson> this is not my experience of other developers
[01:30] <cjwatson> without wishing to denigrate your experiences
[01:30] <LaserJock> hg works somewhat too, though I have some of the same issues with it
[01:30] <lifeless> LaserJock: That offer wasn't for you, it was for me.
[01:30] <wgrant> LaserJock: I've never seen anybody else say that.
[01:30] <lifeless> LaserJock: I want to understand the way you approach your problems, so I can see if there is something I can improve in bzr to fit better.
[01:31] <LaserJock> lifeless: well, I do appreciate that
[01:31] <LaserJock> and I really do believe that bzr is gonna be awesome
[01:31] <sistpoty> now I may be dumb, but I seem to have the same problems as LaserJock with bzr
[01:31] <nxvl> cjwatson: isn't like 3 a.m. in your tz?
[01:31] <_MMA_> lifeless: I have precisely that issue. Where I use Hardy for most of my development but Im told, "Its fixed in Hardy". I dont see this as acceptable. I thing the packages in the current release of Ubuntu should be bleeding-edge or backports keeps up. SOmething.
[01:31] <cjwatson> nxvl: 1:30
[01:31] <_MMA_> gah "﻿Its fixed in Intrepid"
[01:32] <nxvl> cjwatson: oh! not that bad
[01:32] <LaserJock> yeah, I don't to track the bleeding edge in my VCS
[01:32] <sistpoty> and funnily enough, one thing which I first thought would be a problem from me using bzr wrongly, turned out to be a bzr bug... (though I guess that's really the exception *g*)
[01:32] <LaserJock> I've never had to use anything but distro git/hg/svn
[01:32] <lifeless> sistpoty: interesting; bzr is closer to rcs than cvs by default, have you used rcs extensively at any point?
[01:32] <LaserJock> but I'm *constantly* having to get bzr stuff from source
[01:32] <sistpoty> lifeless: nope
[01:33] <cjwatson> I have not had to use non-distro bzr for about two years
[01:33] <LaserJock> cjwatson: I was told by #bzr that I should just use bzr (and any plugins/tools) from bzr branch
[01:33] <lifeless> sistpoty: that could be it; using a shared treeless repo w/switch might suite you better because that 'feels like cvs' pretty closely
[01:34] <cjwatson> LaserJock: that's as may be, but nevertheless many people do not and it works just fine
[01:34] <LaserJock> I find that the formats have changed and I need to upgrade branches to get bzr to work
[01:34] <cjwatson> naturally, it depends what you're doing, but for simple use ...
[01:34] <lifeless> LaserJock: well, its not bad advice, because things do keep improving, but its certainly not mandatory - the vast bulk of bzr users are using packaged versions from their distro.
[01:34] <LaserJock> I'm the most basic of VCS users
[01:34] <LaserJock> I first learned about VCSs in Ubuntu
[01:35] <cjwatson> all current default formats work in bzr/hardy, don't they?
[01:35] <lifeless> LaserJock: we haven't changed the default format since 1.0
[01:35] <cjwatson> unless you're using experimental things
[01:35] <LaserJock> I'm told I don't want to use the default format
[01:35] <wgrant> 1.0 isn't even in gutsy...
[01:35] <sistpoty> lifeless: actually I guess I (ab)used bzr to do this... :) (but then was tempted by the features, like merging, which is a very good thing imho, but just failed since I got it totally wrong)
[01:35] <LaserJock> but some latest-and-greatest
[01:35] <LaserJock> I have no idea what the default format is
[01:35] <cjwatson> LaserJock: by whom, specifically? ("#bzr" is not what I'm looking for)
[01:35] <LaserJock> this is my point
[01:36] <lifeless> gutsy had 0.90, which can't read packs
[01:36] <cjwatson> did you come to #bzr with some particular problem, or just ask for general advice?
[01:36] <LaserJock> I'm just trying to use the thing, but I have to know things about formats and VCS guts to use bzr
[01:36] <cjwatson> you really don't. friends of mine use bzr and have no idea about such things.
[01:36] <LaserJock> git is nasty and has some of that problem too, but there's tons of Howtos around that help
[01:36] <LaserJock> cjwatson: by #bzr I generally mean bzr developers
[01:37] <LaserJock> and bzr-plugin developers
[01:37] <cjwatson> how about we be quite clear: the simplest possible use of bzr involves your system only, with a local repository
[01:37] <LaserJock> right
[01:37] <LaserJock> I do like bzr for local code
[01:37] <cjwatson> bzr init .; bzr add .; bzr commit
[01:37] <wgrant> bzr init, bzr add, bzr commit. Can't get simpler than that.
[01:38] <wgrant> Damn.
[01:38] <cjwatson> there is no need to know anything about formats for that
[01:38] <LaserJock> yep, that's all wonderful
[01:38] <lifeless> cjwatson:  you don't need the '.'s
[01:38] <LaserJock> well, except people tell me that I need repos
[01:38] <cjwatson> then you can push to another system, and you don't need to know anything about formats either
[01:38] <cjwatson> lifeless: distraction
[01:38] <LaserJock> and that my repos need to be some specific format
[01:38] <lifeless> cjwatson: :P
[01:38] <cjwatson> bzr push sftp:///othersystem/...
[01:38] <cjwatson> LaserJock: "people". you're being vague again
[01:38] <cjwatson> you don't need repos
[01:38] <cjwatson> unless you are doing something specific
[01:39] <LaserJock> cjwatson: well, it's happened at least 5 times, I don't remember all who
[01:39] <cjwatson> 01:36 <cjwatson> did you come to #bzr with some particular problem, or just ask for general advice?
[01:39] <LaserJock> usually lifeless, jelmer, and a few others
[01:39] <LaserJock> abently sometimes I talk with I think
[01:39] <cjwatson> it sounds like you were given advice that was more complicated than your needs, and I'm trying to figure out why; for example you might have asked for advice on reducing disk space for very large branches, and been pointed to repositories
[01:39] <LaserJock> mwhudson when it comes to LP related stuff
[01:40] <cjwatson> but if you just say "people" and won't explain what was going on in context at the time, it's hard to say
[01:40] <LaserJock> I usually come with "I can't branch something from LP, help?"
[01:40] <cjwatson> I am amazed that anyone would have advised a repository in that context
[01:41] <lifeless> there is one particular case that bzr gives people grief.
[01:41] <LaserJock> well, it was helpful
[01:41] <lifeless> the bzr-svn integration
[01:41] <cjwatson> right
[01:41] <LaserJock> hmm, maybe that's it
[01:41] <LaserJock> I primarily use bzr through bzr-svn
[01:41] <lifeless> that *does* require a non-default format, and tends to have *very big* branches because it has ancient projects
[01:41] <cjwatson> that's a pain, I agree. that's why I was asking *what LaserJock was doing and he wouldn't tell me!*
[01:41] <LaserJock> as I very very rarely work with code that's in bzr
[01:41] <cjwatson> LaserJock: *now* you tell us, half an hour later
[01:41] <LaserJock> bzr just isn't used that much
[01:42] <LaserJock> lifeless: the other case was the ubuntu-doc repo, which had issues
[01:42] <lifeless> and, to add to the confusion, bzr-svn support has been changing a lot over the last few releases :- and I do mean a _lot_. Fixing major memory leaks
[01:42] <cjwatson> I don't think bzr-svn problems are remotely comparable to how most people would be using bzr for Ubuntu package development
[01:42] <lifeless> ubuntu-doc is another bzr-svn converted repo
[01:42] <LaserJock> ok, but how am I supposed to know?
[01:42] <LaserJock> this is exactly the kinds of problems
[01:43] <LaserJock> "oh, bzr is awesome except X, Y, Z"
[01:43] <LaserJock> and I'm always doing X, Y, or Z
[01:43] <cjwatson> well, is it not fairly obvious that using one revision control to work with another is likely to be a fairly difficult case?
[01:43] <cjwatson> revision control -> revision control system
[01:43] <cjwatson> and worth mentioning up-front in this kind of discussion
[01:43] <LaserJock> cjwatson: difficult yes, common and critically important, yes
[01:43] <cjwatson> sure, but worth mentioning up-front in this kind of discussion
[01:43] <LaserJock> most packages in Debian that use a VCS use SVN
[01:44] <LaserJock> bzr-svn working well will be very important
[01:44] <cjwatson> I'm going to keep battering on about this because you just had us talking for half an hour without mentioning that fact
[01:44] <LaserJock> cjwatson: I didn't know it was relevant?
[01:44] <LaserJock> should I say every plugin I have installed?
[01:44] <cjwatson> I asked several times for anything you could think of
[01:44] <LaserJock> I was told working with bzr-svn ~= working with bzr
[01:45] <cjwatson> you just said you were the most basic of users, which suggested to me that you weren't doing anything very complicated
[01:45] <LaserJock> I didn't think it was
[01:45] <LaserJock> sorry
[01:45] <LaserJock> I just bzr branch, bzr pull, etc.
[01:46] <cjwatson> FWIW, I work with many Debian projects that use svn by means of Launchpad's vcs-imports, which don't involve bzr-svn right now
[01:46] <LaserJock> but my experience is certainly not exclusively bzr-svn
[01:46] <LaserJock> I don't use vcs-imports anymore
[01:46] <cjwatson> I understand there are some plans to move Launchpad to bzr-svn, but I hope that'll involve firming it up and getting the formats to be defaults
[01:47] <lifeless> cjwatson: I've said that bzr-svn is a bad idea for LP until its 'finished' more, including default formats supporting it etc.
[01:47] <lifeless> I hope I'm listened too :)
[01:47] <cjwatson> in any case, as far as this phase of Ubuntu package development in Bazaar goes, interaction with other revision control systems is irrelevant
[01:47] <cjwatson> it will hopefully become relevant later
[01:47] <LaserJock> I had 4 projects that I contribute to imported into LP, and 3 of them died without saying anything
[01:48] <cjwatson> but the first phase will only support it in the kind of way you're thinking of if separate imports have already been done
[01:48] <LaserJock> so I've moved to just using bzr-svn,git-{svn,cvs}
[01:48] <cjwatson> so Ubuntu developers will not encounter this to start with; they'll be using bzr to work with bzr branches, period
[01:48] <LaserJock> cjwatson: why?
[01:48] <LaserJock> I just don't see how that's possible
[01:48] <cjwatson> because we aren't solving every problem simultaneously
[01:49] <LaserJock> if I work on packages maintained by Debichem
[01:49] <cjwatson> to start with, we're just importing package history, not a full fine-grained import from upstream with Debian branches and Ubuntu branches off those
[01:49] <LaserJock> then I need to be able to work with SVN
[01:49] <LaserJock> so it'd make sense to use bzr-svn on that
[01:49] <cjwatson> we aren't solving every problem simultaneously
[01:49] <cjwatson> the reason it has taken four years to get to this point is that we were trying to do it the perfect way
[01:49] <LaserJock> doesn't seem to me that you're solving *any* significant problems
[01:49] <cjwatson> now we are going to get it done, and fill in the perfection later
[01:50] <cjwatson> as it happens, we will be solving many significant problems
[01:50] <LaserJock> I know there are a lot of "down the road" things going on
[01:50] <LaserJock> but it's not really selling well, IMO, for the "right now" case
[01:51] <cjwatson> even just having a web-browsable archive of recent packaging history and current code for every single package in Ubuntu is a big deal
[01:51] <LaserJock> "Launchpad sucks so we'll use a VCS" doesn't really appeal all that well to a lot of people
[01:52] <LaserJock> many people don't care about history, they just want to work on stuff
[01:52] <cjwatson> people will be able to experiment with merge workflows that don't involve tossing diffs around, and figure out something better; people will be able to use multiple branches to handle work-in-progress; etc.
[01:52] <cjwatson> what on earth has this got to do with "Launchpad sucks so we'll use a VCS"?
[01:52] <LaserJock> cjwatson: you said in your emails that LP doesn't give a good view of history so bzr would be better
[01:52] <sistpoty> lifeless: btw, what does "N revisions where removed from the branch" tell me, which I get sometimes from RainCT's commits to revu-trunk as commit-mails?
[01:53] <sistpoty> (where N is usually 1)
[01:53] <pwnguin> launchpad sucking has nothing to do with using VCS
[01:53] <cjwatson> LaserJock: please quote the exact text you're talking about so that I know what you mean, because that is not familiar to me
[01:54] <LaserJock> cjwatson: I'll try. I could be wrong, but that's what I remember anyway
[01:54] <cjwatson> the second phase of the Ubuntu/Bazaar plans involve a parallel import of Debian into bzr, which will mean that everyone can use 'bzr merge' in place of merge-o-matic if they so choose
[01:54] <cjwatson> again, per-upload granularity only, but that's the only level that many people are operating on, certainly for the bulk merge
[01:55] <LaserJock> sure
[01:55] <LaserJock> I know there's a lot of stuff going on, and I like quite a bit of it
[01:55] <cjwatson> while we may not get there for intrepid+1 unfortunately, that stuff is not far off
[01:55] <cjwatson> so I really think it's offensive to say that we're not solving any significant problems
[01:56] <lifeless> sistpoty: the rev number in bzr is done along the left-hand parents in the graph; RainCT is probably pushing to the common branch rather than using a checkout for edits on it.
[01:56] <LaserJock> cjwatson: I don't see it "right now" though, was what I was trying to say
[01:56] <lifeless> sistpoty: which means he may have a shorter path to his new tip, because he's done (say) 2 commits, then merged trunk, committed and pushed.
[01:56] <LaserJock> cjwatson: long term I totally see it
[01:57] <lifeless> sistpoty: but other people have done 5 or 6 commits.
[01:57] <LaserJock> but *right now* I'm trying to figure out what the advantage is for me
[01:57] <lifeless> sistpoty: for things where a strict 'what was in mainline' doesn't matter, its completely normal
[01:57] <cjwatson> LaserJock: "right now" == before it's implemented?
[01:57] <cjwatson> I mean, sure - but I think that's sort of the trivial case
[01:58] <LaserJock> cjwatson: then why is it being talked about if it's not implemented?
[01:58]  * LaserJock is confused
[01:58] <cjwatson> LaserJock: is it not usually traditional to try to design things before finishing implementing them?
[01:58] <LaserJock> cjwatson: hmm, except I've not seen a lot about desgin
[01:58] <LaserJock> it's usually "trust us, we hired somebody to work on it"
[01:59] <cjwatson> hmm, I think that's the sign I should go to bed and give up
[01:59] <LaserJock> I've been talking some with james_w and it does seems exciting
[01:59] <cjwatson> this type of conversation never seems to go well, I'm afraid
[01:59] <lukehasnoname> May I say that I like Hardy's logout screen much more than Intrepid's?
[01:59] <LaserJock> but I'm confused as to what I'm supposed to get out of your thread
[01:59] <cjwatson> it's not my thread
[02:00] <sistpoty> lifeless: I'm not 100% sure yet that I understand it correctly what it means... give me sec, and I'll pastebin you three consequent history events
[02:00] <LaserJock> cjwatson: ok, granted you didn't start most of it, you just posted a lot
[02:00] <cjwatson> it's a discussion about the possibilities for how sponsorship could work given various proposed changes to infrastructure
[02:00] <LaserJock> cjwatson: I'm genuinely interested in how this stuff will work, how it can help me, etc.
[02:01] <LaserJock> that's why I asked for a blog post
[02:01] <cjwatson> which very shortly got derailed into people lobbing bricks about how bzr could never work for Ubuntu development
[02:01] <LaserJock> well, *never* is a long time
[02:01] <LaserJock> ;-)
[02:02] <LaserJock> I'm hopeful for the future
[02:02] <sistpoty> lifeless: http://paste.ubuntu.com/42575/ (in chronological order from top to bottom, separated by #####)
[02:02] <LaserJock> bzr is just not very easy to me, so I'm a bit nervous about it happening soon
[02:03] <lifeless> sistpoty: that looks like RainCT pushed something, realised a mistake, so uncommitted, then pushed a fixed version
[02:03] <LaserJock> in any case, I need to go and I really wasn't looking for a fight
[02:04] <LaserJock> I'm going to try to take lifeless up on his offer
[02:04] <sistpoty> lifeless: ah, ok, thanks for the explanation :)
[02:04] <lifeless> sistpoty: uncommit is different to 'commit the reverse' because we can't necessarily get a diff of what was uncommitted
[02:05] <cjwatson> LaserJock: ok, sorry, maybe I shouldn't have engaged in one at getting on for 2am
[02:05] <LaserJock> cjwatson: np, I learned some stuff
[02:05] <lifeless> sistpoty: in CVS terms, its 'cvs admin -jdead 293 foo.c'
[02:05] <cjwatson> LaserJock: I certainly will be posting something about packaging in bzr at some point, although exactly which areas I'm not quite sure
[02:06] <lifeless> sistpoty: or something like that
[02:06] <LaserJock> cjwatson: thanks
[02:06] <sistpoty> lifeless: heh, thanks
[02:06] <LaserJock> I'd like to hear from the experts :-)
[02:06] <cjwatson> BTW, if distro git is always just fine and stable forever, what's bug 250526 for? :-)
[02:07] <LaserJock> cjwatson: people gotta have crack? I have no idea
[02:07] <sistpoty> well, while I was pretty much impressed by siretart merging with bzr, I doubt it's too practical for what we see in regards to universe sponsoring...
[02:08] <sistpoty> because I saw a number of merges which pretty much just grabbed the MoM output, than thinking about the merge
[02:08] <cjwatson> sistpoty: I honestly think a good deal of that is down to it being impossible to construct a unified process right now because we just don't have branches for everything
[02:08] <LaserJock> sistpoty: yeah, I worry about that too
[02:08] <sistpoty> but of course that's an educational problem, which is imo neither solved by any tool
[02:08] <cjwatson> once we have Ubuntu and Debian branches for every package, 'bzr merge' will be a much more natural thing to do
[02:08] <LaserJock> I heard a few "MoM is down, now I can't do merges"
[02:09] <cjwatson> I can attest to it being *much* easier to merge packages that way
[02:09] <LaserJock> anyway, gotta run
[02:09] <LaserJock> thanks for the discussion, it was helpful to me
[02:09] <sistpoty> cjwatson: that's not really the problem I was thinking of... it's rather the problem of "do the changes still apply" or "I have this tool, it works, though I don't know what I do, but I don't have any conflicts left"
[02:09] <sistpoty> but that's inherant to the tool in question imho
[02:10] <sistpoty> inherent? (it doesn't come from the tool used, but is educational *g
[02:10] <sistpoty> +*)
[02:10] <cjwatson> that's the opposite of inherent
[02:10] <cjwatson> independent of, perhaps
[02:11] <sistpoty> yes. that's it... /me will use only simply words from now on *g*
[02:11] <sistpoty> simple
[02:11] <sistpoty> argh
[02:11] <cjwatson> I have never found merges straightforward to sponsor by any process
[02:12] <sistpoty> *nod*
[02:12] <cjwatson> being able to use 'bzr diff -rancestor:../debian' and such can be a timesaver, but no matter what you end up diffing all over the place to try to figure out whether the change is sane
[02:13] <cjwatson> the cost-benefit ratio is significantly worse than when sponsoring ordinary patches; in terms of time, it's at least a factor of three worse
[02:28] <ScottK> Wahoo.  Looks like I missed all the fun.
[02:28] <StevenK> Hm? There was fun?
[02:36]  * sistpoty heads off to bed, and then off to vacation... cya
[02:36] <lukehasnoname> later.
[05:44] <dholbach> gooooood morning
[06:25] <pitti> Good morning
[06:25] <dholbach> hi pitti
[06:26] <lukehasnoname> good... yes, it is morning, isn't it?
[06:29] <lukehasnoname> holy crap, check this out: http://googlesystem.blogspot.com/2006/03/google-browser.html
[06:29] <lukehasnoname> damnit
[06:29] <lukehasnoname> 5 secs after I post it I see it's fake.
[06:30] <lukehasnoname> well not exactly, I just posted the wrong link
[06:31] <lukehasnoname> http://googleblog.blogspot.com/
[06:34] <StevenK> conftest.c:19: error: 'NULL' undeclared (first use in this function)
[06:34]  * StevenK blinks
[06:34] <StevenK> I could have sworn NULL is a built in ...
[06:34] <jdong> no, it's a #define
[06:35] <jdong> but it is funny to see it not defined
[06:35] <jdong> should be unistd.h
[06:35] <jdong> even stdio.h
[07:38] <\sh> wth? bzr: ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.
[07:38] <\sh> what is that?
[07:39] <lifeless> its a bug in bzr-dbus
[07:39] <lifeless> regression actually I think ,cause by a dbus change.
[07:40] <\sh> nice...I can't branch anything anymore ,)
[07:41] <\sh> on intrepid that is
[07:41] <lifeless> remove bzr-dbus from the machine you are branching from
[07:42] <\sh> lifeless: bzr branch lp:~ubuntu-dev/quassel/ubuntu ,-)
[07:42] <lifeless> \sh: oh!
[07:42] <lifeless> \sh: uhm remove it locally ?
[07:42] <\sh> will do
[07:43] <pitti> lifeless: is there a particular reason why bzr doesn't record/log cherrypicks (bzr merge -c 1234) the same way it logs 'full' merges?
[07:44] <lifeless> pitti: yes, a cherry pick requires a non-transitive reference into the graph
[07:44] <lifeless> pitti: so we need a good,solid, compact, performs well, implementation of that
[07:44] <pitti> lifeless: so in general it is desirable to do so, but is tricky to implement?
[07:44] <lifeless> right
[07:44] <pitti> ok, thanks
[07:45] <pitti> I wondered whether there is a general conceptual reason not to do so
[08:22] <pitti> tkamppeter: is there an STR for 90_include_krb5_h_in_job_h.patch.dpatch ? I didn't find one
[08:51] <tkamppeter> pitti, what is 90_include_krb5_h_in_job_h.patch.dpatch about? The current CUPS does not contain this patch?
[08:52] <pitti> tkamppeter: it does: debian/patches/include_krb5_h_in_job_h.dpatch
[08:52] <pitti> tkamppeter: (the patch header said .patch.dpatch, I fixed this; the file name is fine)
[08:52] <pitti> tkamppeter: look in svn trunk
[08:52] <tkamppeter> pitti, I have found it now, too. You have removed the unneeded numbers one day.
[08:52] <pitti> tkamppeter: please svn update first, btw, I just did some changes
[08:54] <tkamppeter> pitti, I have loaded your last update now.
[08:54] <StevenK> pitti: Can I bug you for source NEW stuff? :-)
[08:54] <pitti> StevenK: if it's urgent, yes, otherwise it'll go with the normal archive days
[08:55] <StevenK> pitti: "Not really"
[08:58] <didrocks> BenC: around?
[08:58] <tkamppeter> pitti, I do not remember whether I have STRed this patch upstream, I think I created it very long ago (to introduce CUPS 1.3 into Ubuntu or so).
[08:58] <tkamppeter> pitti, can you STR it.
[08:59] <pitti> tkamppeter: what was the bug? FTBFS? or it didn't work correctly?
[08:59] <pitti> the changelog fails to document the rationale
[09:00] <tkamppeter> The topic still says "archive: open". So we can still upload CUPS 1.4 (or should we better fix the topic?).
[09:01] <persia> tkamppeter: The archive is open, but developers are expected to exercise caution about updates, and seek guidance from the relevant release teams about major updates.
[09:01] <tkamppeter> pitti, AFAIR it did not build without the patch.
[09:01] <pitti> tkamppeter: we are in feature freeze, so I'd say "no"
[09:01] <pitti> tkamppeter: build> ok, that's easy to check; will have a go at it
[09:02] <pitti> tkamppeter: archive freeze != feature freeze
[09:02] <pitti> the former is whether uploads are allowed, the latter is which kind of uploads
[09:02] <tkamppeter> persia, I am only asking, as for the last version FF was announced in the topic.
[09:03] <persia> tkamppeter: Ah.  Good point.  I'll adjust that.
[09:03] <persia> pitti is faster :)  I was going to say "archive: open, feature freeze in place ..."
[09:03] <pitti> persia: feel free to adjust the wording :)
[09:04] <persia> pitti: All is good :)
[09:26] <pitti> tkamppeter: oh, I just noticed that intrepid's cups is way apart from the svn trunk...
[09:27] <tkamppeter> pitti, yes, I have made one upload during your vacation and was about to ask you for resyncing to Debian now.
[09:27] <pitti> tkamppeter: well, as you saw on pkg-cups ML, I plan to move to bzr anyway, so that we can have proper ubuntu branches
[09:28] <pitti> tkamppeter: I can probably merge kees' PIE hardening to trunk, but the ufw integration is ubuntu specific
[09:28] <pitti> well, I can make that ubuntu specific in debian/ruels
[09:29] <pitti> tkamppeter: I assume yuor changes in 1.3.8-5ubuntu1 are in trunk? do you know whether ion_'s changes in 1.3.8-5ubuntu2 are in trunk as well?
[09:29] <tkamppeter> pitti, the Ubuntu package is the relevent one, with everything which ion_ and me wanted to have inside. I have committed it also into the Debian SVN. Can you check whether I did not forget anything in Debian, Merge everything missing into Debian and then sync Ubuntu and Debian again?
[09:30] <pitti> tkamppeter: yes, will do
[09:30] <didrocks> hum, good news, DD begin to accept the new Ubuntu management of deamon stop links (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495552). Just wait now this to be sponsored by u-m-s
[09:30] <pitti> tkamppeter: btw, the package builds fine without include_krb5_h_in_job_h.dpatch, so I'll kill the patch for now, if that's ok for you?
[09:31] <tkamppeter> pitti, yes, seems to got fixed elsewhere (build system, .h file, ...)
[09:32] <tkamppeter> pitti, I have sponsored the 1.3.8-5ubuntu2 upload, and AFAIR I have taken everything of ion_'s patch also into the Debian SVN.
[09:33] <tkamppeter> But please check.
[09:33] <pitti> tkamppeter: ok, I'll give it a check
[09:39] <pitti> tkamppeter: yep, looks fine; so I'll just commit the rest
[09:39] <seb128> hey pitti
[09:40] <pitti> hey seb128
[09:40] <seb128> pitti: do you have any idea on how we could debug the "the retracer clean some bugs but don't mark those duplicates"? ie, it removes everything as it was going to dup those but doesn't
[09:40] <seb128> doesn't happen that often one every 30 bugs or something
[09:41] <pitti> seb128: hm, I thought we added a workaround for that, for not trying to duplicate to itself?
[09:41] <pitti> (which happened for retagging a bug)
[09:41] <pitti> or does it happen to bugs which we didn't manually retag?
[09:42] <seb128> that is a good question, and I think I forgot to apply the workaround
[09:42] <seb128> you told me what to change but that was just before holidays and I had a busy day and didn't manage to do that
[09:42] <famicom> lo
[09:42] <seb128> bug #263795 is one example
[09:42] <seb128> the first mail I got about this one was the retracer cleanup one
[09:43] <seb128> dunno if somebody retagged it though
[09:43] <pitti> anything in the logs for it? does it say it's a dup?
[09:43] <seb128> the launchpad activity log is not powerful enough
[09:43] <famicom> oh thats a fun one
[09:43] <famicom> mount unmount bugs
[09:44] <famicom> does anyone here know who is responsible for ubiqity
[09:44] <seb128> pitti: Report is a duplicate of #261923 (not fixed yet)
[09:45] <seb128> pitti: oh, it's trying to mark it duplicate from a bug which is already a duplicate and that's doesn't work on launchpad
[09:45] <pitti> aah
[09:45] <pitti> hm, I thought the code would already have a case for that
[09:46] <seb128> that used to work I think
[09:46] <pitti>         # check whether the master itself is a dup
[09:46] <pitti>         m = Bug(master)
[09:46] <pitti>         if m.duplicate_of:
[09:46] <pitti>             master = m.duplicate_of
[09:46] <pitti> maybe that stopped working in current p-lp-bugs?
[09:46] <seb128> most likely
[09:46] <famicom> ok, im going to get flamed for this one, but where in the hell can i get some decent low level info on the ubuntu install process. Everything i've found so far is completely useless
[09:47] <seb128> famicom: try #ubuntu-installer?
[09:47] <famicom> thank you ;)
[09:47] <seb128> pitti: ok, so as always iz p-l-b bog
[09:47] <pitti> bug 261923
[09:48] <pitti> seb128: testing...
[09:48] <seb128> pitti: I can mark it public if you want
[09:48] <pitti> seb128: should be ok
[09:48] <pitti> I can read it
[09:48] <seb128> ok
[09:48] <pitti> I'll do that in some 15 minutes when I am done with wrestling cups
[10:04] <tjaalton> ogra: you had some blank screen issues yesterday, see bug 262605
[10:11] <famicom> ugh
[10:12] <famicom> where exactly is the list of packages to install pulled from
[10:13] <Hobbsee> famicom: http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.intrepid/
[10:14] <famicom> so it's pulled from debconf
[10:14] <wgrant> Not as far as I'm aware.
[10:15] <famicom> so where do you specify this?
[10:16] <Hobbsee> in the seeds.  they're in bzr under ~ubuntu-dev
[10:17] <famicom> then how do i tell the installer which seed to use?
[10:17] <StevenK> Hobbsee: ~ubuntu-core-dev
[10:17] <Hobbsee> oh, core dev, yes.
[10:19] <famicom> anyway, i see things like "ubiqiquity --desktop %k gtk_ui" , /preseed/cli.seed
[10:19] <famicom> and theyre' all not very helpfull
[10:19] <wgrant> ubiquity doesn't know much about seeds, I don't believe.
[10:19] <wgrant> It installs what's on the CD>
[10:20] <famicom> so if i were to remove all unwanted cruft such as openoffice and the gimp
[10:20] <famicom> they wouldnt be installed/
[10:20] <famicom> I know this isn't directly related to development, but this information is so incredibly buried
[10:21] <persia> famicom: Well, it also installs a set of tasks, so you'd have to be sure you weren't defining tasks for installation that included that which was removed.
[10:21] <famicom> ok, so that's tasksel
[10:22] <famicom> d-i	preseed/late_command	string chroot /target /usr/sbin/ltsp-update-sshkeys
[10:22] <famicom> i meant tasksel	tasksel/first	multiselect ubuntu-desktop
[10:22] <famicom> at the same time, i see  /usr/bin/perl -w /usr/bin/debconf-communicate -fnoninteractive ubiquity
[10:23] <famicom> so something tells me that it's pulling info from debconf
[10:24] <dholbach> cjwatson: are the seeds on bazaar.lp.net the ones we use right now? (platform.intrepid, etc)?
[10:24] <dholbach> things might have changed since the last time I touched them (ages ago...) :-)
[10:25] <StevenK> dholbach: Since like Hardy
[10:25] <dholbach> hm hm ok
[10:25] <dholbach> I was just looking into fixing bug 256626
[10:26] <dholbach> does somebody want the honours saving some space on our CDs with that? :-)
[10:26] <wolfe> hmmm
[10:27] <cjwatson> dholbach: yes, they are
[10:28] <dholbach> ok... I'll do it then
[10:29] <cjwatson> persia: ubiquity doesn't really install tasks; that's done at live filesystem build time
[10:30] <persia> cjwatson: Oh.  I thought it went through the whole d-i cycle based on the preseeds, and ubiquity only had a shortcut to the process which worked because of the way the live filesystem was built.
[10:30]  * persia goes back to read more code.
[10:31] <cjwatson> persia: package installation is one of the bits it skips, by just copying the live filesystem
[10:31] <cjwatson> it uses selected bits of d-i
[10:36]  * ogra arghs about us having taken over the sily buerocracy of debian that packages *need* a "needs packaging" bug now ... sigh
[10:37] <Hobbsee> ogra: i highly doubt anyone is going to stomp on your fingers as you didn't write one before packaging it.
[10:39] <ogra> well, i just did a REVU review where it was mentioned explicitly by the former reviewer ... probably https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages needs to be phrased differently then
[10:39] <persia> Hobbsee: No, but lots of people stomp on fingers for not filing one before uploading.
[10:39] <broonie> The Debian one has only been *enforced* relatively recently.
[10:40] <pitti> seb128: confirmed, it's broken
[10:40] <ogra> well, its still buerocracy overhead ... i thought we'd be better  :)
[10:40] <Hobbsee> persia: oh, interesting.
[10:40] <Hobbsee> ogra: when beaurocracy is the replacement for employing actual thought...what else do you expect?
[10:40] <ogra> heh
[10:40] <persia> Hobbsee: It's REVU + the lintian warning that comes from Debian enforcing it.  Patch it out of lintian, and all finger stomping stops.
[10:41] <Hobbsee> persia: ahhh
[10:41] <cjwatson> or teach people to apply human intelligence to lintian warnings, as was always the lintian authors' intention :-)
[10:42] <Hobbsee> cjwatson: gasp.  what a concept!
[10:42] <persia> cjwatson: That would be ideal, but it comes down the the education issue...
[10:42] <pitti> seb128: filed as bug 263933, thanks for pointing out; I guess our grand master thekorn will fix it in no time
[10:42]  * pitti hugs theclaw
[10:43]  * pitti hugs thekorn, too
[10:43] <cjwatson> didrocks: reading that Debian bug you mentioned, note that runlevel 1 isn't equivalent to runlevel S in Debian; runlevel S is equivalent to runlevel S in Debian
[10:43] <seb128> pitti: thank you
[10:45] <didrocks> "runlevel S is equivalent to runlevel S in Debian
[10:45] <didrocks> " ? :)
[10:46] <didrocks> can you point me at any documentation,please? I have not found useful one...
[10:47] <cjwatson> err, well, you can see that there's a runlevel S by looking in /etc/rcS.d
[10:47] <cjwatson> also telinit(8)
[10:48] <cjwatson> switching to runlevel 1 has the effect of stopping lots of processes, and then switching to runlevel S to actually bring up single-user mode
[10:49] <didrocks> so, what runlevel 1 corresponds to in Debian/ubuntu if it is not single-user mode?
[10:50] <didrocks> oh ok
[10:50] <didrocks> I see that in the man now
[10:50] <didrocks> ok, runlevel S doesn't stop the process before
[10:51] <didrocks> cjwatson: thanks a lot to have clarified this :)
[10:51] <ion_> pitti: Yeah, all my changes are in SVN.
[10:51] <cjwatson> no problem
[10:51] <pitti> ion_: thanks for re-confirming
[10:52] <pitti> ion_, tkamppeter: FYI, all remaining ubuntu changes committed to trunk, uploaded to experimental, and (fake-)synced to intrepid
[10:53] <ion_> pitti: 'stg clean' after 'stg rebasing' my patch stack against a branch 'git svn rebased' against SVN trunk deleted the entire patch stack, so everything should be there. :-)
[10:53] <didrocks> cjwatson: so, now, I have just to wait for Ben to be there to see if we can upload all my waiting patches for removing the multiuser tags...
[10:53] <pitti> ion_: heh, you import the svn to stacked git? I import it to bzr :)
[10:54] <pitti> seems that noone is actually using svn...
[10:55] <ion_> pitti: git-svn imports it to 'master', a plain git branch, and i have a stgit stack in 'ion' branch, which i 'stg rebase master' after changes to trunk.
[10:57] <pitti> seb128: I fixed it myself, and committed/pushed
[10:57] <seb128> pitti: you rock!
[10:57] <ion_> stgit is like quilt but without the pain. :-) (That is, having to learn a patch doesn't apply anymore the hard way, without the patch system doing no automatic merging etc.)
[10:57]  * seb128 hugs pitti
[10:58] <pitti> seb128: can you please manually dup the bug above?
[10:58] <pitti> seb128: I'll roll out the fix to the retracers
[10:58] <seb128> pitti: I already did that ;-)
[10:58] <seb128> and an another one which was in the same case since
[10:59] <pitti> [done]
[10:59] <pitti> so, it *shuold* work now
[11:00] <seb128> excellent
[11:02] <pitti> sebner: FYI, doing the eog new upstream version sponsoring now
[11:04] <pitti> sebner: sorry, that should have gone to seb128
[11:05] <tkamppeter> pitti, what means fake-synced? Is real syncing not allowed after FF, even if no new feature gets pulled into Ubuntu by that?
[11:05] <pitti> tkamppeter: it is allowed, I just didn't want to wait until tomorrow
[11:05] <tkamppeter> pitti thanks.
[11:08] <ion_> Ooh, my puppet module that fixes ubuntu fonts has whopping two (2) users. :-)
[11:13] <pitti> seb128: wb
[11:13] <seb128> re pitti
[11:13] <pitti> seb128: FYI, doing the eog sponsoring ATM
[11:13] <seb128> pitti: thanks
[11:25] <\sh> pitti: do you have any update on directfb and tslib?
[11:25] <pitti> I didn't get to MIR processing yet
[11:26] <lool> bryce: running Xvfb in a chroot gives me: (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory); adding libgl1-mesa-dri in the chroot fixes it; is this a dependency issue in xvfb?
[11:27] <\sh> pitti: no worries :)
[11:28] <jcristau> lool: not really, you can run it with '-extension GLX'. also, failing to load swrast_dri shouldn't be fatal, iirc that's fixed upstream
[11:29] <lool> jcristau: Packages using xvfb-run to run X11 testsuites wont pull libgl1-mesa-dri; you're saying it's fixed in that if not available it moves to GLX?
[11:29] <jcristau> lool: if that's not available, it disables glx instead of FatalError()ing
[11:30] <lool> jcristau: That's fine then; I guess I should pull in the fix in our xvfb package
[11:41] <tjaalton> lool: just give the commit-id and I'll add it
[11:43] <tjaalton> lool: found it
[11:43] <tjaalton> lool: do you need it for alpha5
[11:44] <lool> tjaalton: I don't strictly need it; I've worked around in the bdeps
[11:44] <lool> tjaalton: Thanks for adding it
[11:45] <tjaalton> lool: it's included in 1.5-branch, so when it's released later this week we'll have it
[11:46] <lool> tjaalton: Ok; thanks
[11:54] <cjwatson> james_w: https://wiki.ubuntu.com/DistributedDevelopment/Specification moved from private wiki with mdz's OK
[12:03] <Keybuk> pgraner: err, hi
[12:04] <Keybuk> I CAN HAZ BOOTABLE KERNEL ON MAI LAPTOP?
[12:05] <pgraner> Keybuk: sure... got a bug number?
[12:05] <Keybuk> pgraner: no, I can't boot it
[12:06] <pgraner> Keybuk: Need a bit more than that to work with
[12:06] <Keybuk> err, no info
[12:06] <Keybuk> boot kernel => nothing happens
[12:06] <Keybuk> it locks up inside the kernel somewhere
[12:06] <Hobbsee> oh, is this the boot hanging thing?
[12:08]  * Hobbsee wondered what that was
[12:38]  * ogra notices a certain creativity with pitti signing packages today :)
[12:39] <pitti> ogra: WDYM?
[12:40] <ogra> pitti, Changed-By: Martin Pitt <martin.pitt@ubuntu.com> vs Changed-By: Martin Pitt <mpitt@debian.org> :)
[12:40] <pitti> oh, whoops
[12:40] <pitti> I still have my debian DEBEMAIL in one terminal
[12:40] <ogra> heh
[12:43] <Keybuk> pgraner: fully off the phone now
[12:44] <Keybuk> seriously, what debugging information can I provide?
[12:44] <Keybuk> Dell Latitude D420, 2.6.27, if I pick it, nothing happens
[12:44] <Keybuk> it doesn't even get to initramfs
[12:44] <Keybuk> (-2-generic apparently)
[12:45] <asac> ogra: warrens email? just warren@redhat.com?
[12:48] <pgraner> Keybuk: https://wiki.ubuntu.com/KernelTeamBugPolicies
[12:49] <pgraner> Keybuk: lots of techniques there to help you get started
[12:49] <Keybuk> pgraner: all of these appear to rely on me being able to boot the thing ;)
[12:50] <nxvl> good morning
[12:51] <pgraner> Keybuk: https://wiki.ubuntu.com/DebuggingACPI look for the "Trouble Booting" section
[12:53] <pgraner> asac: if you mean warren togmai at redhat then thats the correct address
[12:53] <Keybuk> kk
[12:53] <asac> pgraner: the warren from ltsp
[12:53] <pgraner> asac: thats him
[12:53] <asac> thanks
[12:53] <pgraner> asac: np
[12:59] <james_w> thanks cjwatson
[12:59] <asac> pgraner: didnt work ;)
[12:59] <asac> (the email address)
[13:00] <hyperair> could someone look into bug #246053? it seems to be a packaging problem (wrong path for s2disk). debdiff included.
[13:00] <pgraner> asac: shit sorry, is Fedora is warren Red hat is: wtogami@redhat.com
[13:01] <asac> thanks ill try taht
[13:09] <ogra> asac, 	Warren Togami <wtogami@redhat.com>
[13:09] <asac> ogra: thanks. i think i got it right now ;)
[13:26] <\sh> guys, anyone who has more clue about the buildd then I, please check this buildlog http://launchpadlibrarian.net/17228492/buildlog_ubuntu-intrepid-amd64.kdepimlibs_4%3A4.1.1-0ubuntu2_FAILEDTOBUILD.txt.gz and tell me what's wrong...local sbuild doesn't fail (amd64 only)
[13:37] <ScottK> \sh: The log won't be there anymore because I retried the build.
[13:37] <\sh> ScottK: oh yes
[13:42] <cjwatson> Riddell: don't suppose you got anywhere with oem-config?
[13:44] <didrocks> pitti: I will quote you a couple of time on wednesday's patching session. Don't be surprised of your are hilighted :)
[13:48] <\sh> oh nice...who broke dbus?
[13:53] <asac> amitk: nspluginwrapper 0ubuntu2 should fix the worst issues
[13:53] <asac> (just uploaded)
[13:56] <amitk> asac: nice. Thanks.
[13:57] <skymuss> hi
[13:58] <Riddell> cjwatson: not yet (I'm on holiday until thursday)
[14:00]  * lamont wonders how to get firefox to not "randomly" steal focus
[14:00] <lamont> as in when a page finishes updating, maybe?
[14:00] <cjwatson> Riddell: oh ok, thanks
[14:02] <wgrant> Speaking of Firefox focus stealing...
[14:02] <wgrant> Who is to blame for the *default home page* doing that?
[14:06] <asac> wgrant: a combination of the "online/offline" page feature and the fact that firefox likes to take focus to the website when loaded
[14:09] <wgrant> asac: Wrong.
[14:09] <wgrant> <body onload="focus_search()">
[14:09] <wgrant> That is deliberate.
[14:09] <wgrant> The page steals focus.
[14:10] <asac> oh
[14:10] <asac> well then ;)
[14:10] <cjwatson> I think there ought to be a distinction between "adjust input focus location within firefox window" and "steal desktop input focus"
[14:10] <cjwatson> the former seems quite reasonable
[14:10] <asac> i am not really aware of the latter
[14:10] <asac> unless you open a new browser (window) maybe
[14:11] <wgrant> cjwatson: It's reasonable if you are behind a lightning-fast Internet connection and the focus is stolen immediately.
[14:11] <wgrant> But as it is now, this search box steals focus from the real search box, leaving people with half a word in each.
[14:11] <wgrant> Why there is search-box duplication I do not know.
[14:11] <cjwatson> oh, so your complaint is actually about focus-stealing within firefox?
[14:11] <wgrant> It is, sorry.
[14:12] <cjwatson> again, I actually think it's perfectly reasonable to have a notion of focus within a page that's separate from where your focus in the browser chrome happens to be ...
[14:12] <wgrant> It's not separate.
[14:13] <wgrant> It steals focus from the chrome.
[14:13] <asac> yeah. the focus maybe shouldnt move from chrome to website deliberately. not sure if that breaks usability for others though
[14:13] <wgrant> The default home page shouldn't steal focus to its Google search box which duplicates the widget in the top-right of Firefox.
[14:13] <cjwatson> wgrant: right, and I think that's a firefox bug not a page bug
[14:14] <wgrant> Or the default home page should load in a more trivial amount of time.
[14:15] <cjwatson> anyway, bugs.launchpad.net/ubuntu-website/+filebug would be the best place to object
[14:15] <cjwatson> to something in the page
[14:16] <tseliot> seb128: I have to add some error and information messages to show in dialogs in the gnome control center. How does localisation work for this package?
[14:16] <wgrant> Bug #239831
[14:16] <seb128> tseliot: standard gettext, and please use normal sponsorship for those updates
[14:17] <tseliot> seb128: ok, thanks
[14:18] <seb128> need to talk to kees and bryce about doing random uploads without pinging the desktop team before ;-)
[14:20] <asac> wgrant: i added firefox-3.0 with a soft-milestone to that bug
[14:24] <pitti> didrocks: no problem at all :)
[14:28] <asac> jdong: there?
[14:30] <cjwatson> doko: have you had a chance to reassess bug 261847 in light of the new information? I'm assuming that the bug I referred to (and some other similar ones) were the reason for the recommendation
[14:38] <doko> cjwatson: on my list (remembering an email from lool); can't read my email yet. my luggage including the power adaptor didn't make it until Berlin. they'll deliver it tonight.
[14:39] <didrocks> pitti: thanks a lot :)
[14:40] <saivann> I'd like to request developers to take a look at security bug 55159 . I spoke of this problem with siretart and I attached patches to revert the changes, but I believe that this would need discussion
[14:46] <didrocks> doko: around?
[14:51] <doko> didrocks: just ask
[14:53] <ogra> he's not that round anymore either :)
[14:54] <didrocks> doko: sorry, did you have the time to look at my email (something like 3-4 days before) on java2-runtime-headless which is not present in intrepid archives?)
[14:57] <doko> didrocks: no, not yet, back from vacation today
[14:59] <didrocks> doko: sorry for hearing that :) take your time, there is no rush.
[15:07] <mdz> asac: have you had a chance to look at bug 258552? it might help with NM bugs
[15:09]  * asac looking
[15:09] <fbond> Hi, I read https://wiki.ubuntu.com/OneTruePath.  I'm not sure this is documented anywhere obvious?  That page is also somewhat ambiguous as to whether we should be using /etc/profile or /etc/environment.
[15:10] <cjwatson> the intent is /etc/environment
[15:11] <ogra> hmm, it was never parked as implemented actually
[15:11] <ogra> *marked
[15:12] <Mithrandir> /etc/profile is a shell script, so /etc/environment is the one, yes.
[15:12] <cjwatson> I think "change pam to add default PATH to /etc/profile" was a typo for /etc/environment
[15:12] <cjwatson> Mithrandir: could you confirm that?
[15:12] <cjwatson> since that's what's actually done
[15:13] <Mithrandir> yes, that would be a typo.
[15:16] <cjwatson> I've fixed it
[15:16] <Mithrandir> cheers
[15:20] <ara> hello, does anyone know if it is difficult (in terms of policy) to change the name of a pkg in main
[15:20] <cjwatson> it's not hard in terms of policy, but can be a hassle both for developers and users
[15:20] <ara> the hw certification team have a tool hwtest, and the upstream project changed the name to checkbox
[15:20] <cjwatson> it is usually unwise to change it in Ubuntu if it also exists with the other name in Debian
[15:20] <ara> the ubuntu pkg (only in ubuntu, not in debian)
[15:21] <ara> should be renamed also to checkbox
[15:21] <lamont> cjwatson: you for got to capitalize "UNWISE" ...
[15:21] <cjwatson> ara: you normally just need to upload a new package by the new name that includes Conflicts, Replaces, and Provides fields for the old package name, and once that's in the archive file a removal request for the old package
[15:21] <cjwatson> (subscribing the ubuntu-archive team)
[15:21] <ara> cjwatson: thanks!
[15:22] <cjwatson> 'checkbox' is an exceedingly generic term and does not strike me as a better name, though
[15:22] <ara> cjwatson: i guess it is too late for intrepid, isn't it?
[15:22] <cjwatson> not necessarily, no
[15:22] <asac> mdz: thanks ... i added a comment
[15:23] <ara> cjwatson: the reason is that it is no longer a hw certification only tool, but a generic test framework
[15:23] <cjwatson> I'm not formally objecting to it or anything, it just seems asking for trouble in terms of future name clashes, that's all
[15:24] <cjwatson> but there's nothing by that name in the archive right now
[15:24] <asac> ara: just curious, is there a spec or summary of what the testing framework does?
[15:25] <fbond> cjwatson: Should the preference for /etc/environment be documented anywhere else (i.e. on the system itself)?  ~/.pam_environment is not very obvious, at all, of course.
[15:25] <ara> asac: well, more than a test framework, it is a test runner
[15:25] <cjwatson> fbond: probably, but I'm not sure where would be appropriate
[15:25] <cjwatson> perhaps ask the doc team
[15:25] <fbond> cjwatson: #ubuntu-doc?
[15:25] <cjwatson> I think so
[15:26] <mdz> asac: can you confirm that the gconf command I suggested works?  I don't have any static config on this box
[15:26] <fbond> cjwatson: Thanks.
[15:26] <cjwatson> kirkland: I notice that bug 33649 got reopened with very little new information. Do you know what's going on there?
[15:26] <mdz> asac: then I'll submit it via bzr
[15:26] <ara> asac: https://launchpad.net/checkbox is the upstream project. I am afraid that there isn't many documentation yet
[15:26] <asac> mdz: gconftool-2 -R /system/networking prints out reasonable things for me
[15:27] <mdz> asac: thanks
[15:27] <mdz> pitti: btw, it would be nice to be able to have some non-textual separator in apport report keys
[15:27] <mdz> pitti: I tried NetDevice-wlan0 and it simply vanishes from the report, similar for '_' IIRC
[15:27] <kirkland> cjwatson: i will ask for more information, but tricky1 has been a bit of a pain on this issue
[15:33] <pitti> mdz: that's not a problem with the separator, the ProblemReport class' __setitem__() just checks that key.alnum() is true (dots are allowed, too)
[15:34] <pitti> mdz: that's a pretty arbitrary convention, I can easily allow characters like - and _; I just wanted to avoid potential problems with client-side parsers which might expect identifiers
[15:34] <pitti> (as in programming languages)
[15:34] <mdz> pitti: I can use '.'
[15:36] <mdz> pitti: the parser will be OK with it I assume?
[15:37] <mdz> pitti: it would be nice if __setitem__ threw an exception or something; it was very confusing that it disappeared silently
[15:38] <pitti> mdz: yes, the parser splits on ':', so that should be ok
[15:38] <mdz> asac: I have a bzr branch with the changes; what would you like for me to do with it?
[15:38] <pitti> mdz: it actually should, it uses assert
[15:38] <pitti>     def __setitem__(self, k, v):
[15:38] <pitti>         assert hasattr(k, 'isalnum')
[15:38] <pitti>         assert k.replace('.', '').isalnum()
[15:38] <pitti> mdz: I even have a test suite check for that
[15:39] <pitti>         self.assertRaises(AssertionError, pr.__setitem__, 'a b', '1')
[15:39] <mdz> pitti: weird
[15:39] <pitti> mdz: where exactly did it disappear?
[15:39] <mdz> pitti: that did not trigger for me, or else it did so in a place where I did not see it
[15:39] <cjwatson> kirkland: yeah, I know
[15:39] <cjwatson> kirkland: it was just on my sponsoring list so I noticed it
[15:39] <pitti> mdz: you added something in a hook, and it didn't appear in the .crash file? or when you piped it to/from LP?
[15:40] <mdz> pitti: correct
[15:40] <mdz> pitti: the latter
[15:40] <kirkland> cjwatson: i'll respond, asking for more info, and mark it incomplete?
[15:40] <mdz> after apport had processed the crash file and added the other keys, I noticed that one was missing
[15:40] <cjwatson> kirkland: sure. Have you done an end-to-end test yourself to confirm that it is in fact working?
[15:41] <kirkland> cjwatson: good question; i have not from the latest install media;  i'm downloading the current ubuntu server right now, with the intention of performing that test
[15:41] <pitti> mdz: actually the entire hook should crash on that (which doesn't cause the apport GUI to crash, though, just the hook to be ignored)
[15:41] <pitti> mdz: so maybe it was the last field which was written?
[15:41] <pitti> mdz: to be precise, the hook isn't ignored, but if it throws an exception, that is ignoored, and the hook is terminated
[15:42] <mdz> pitti: it would have been the last in my test, yes
[15:42] <mdz> pitti: would that have shown up in /var/log/apport.log?
[15:42] <pitti> mdz: unfortunately not, since that is only writable by root
[15:42] <cjwatson> kirkland: it's easy enough for something completely distinct to break stuff (e.g. I tried to test an LVM problem yesterday and discovered that lvm2-udeb's dependencies were broken, so had to fix that first)
[15:43] <pitti> mdz: it's just a simple try: execfile(); add_info() except: pass construct right now
[15:43] <asac> mdz: request a merge using the launchpad "merge" feature
[15:43] <pitti> a better error logging would certainly be good here indeed
[15:43] <asac> mdz: or give me the url to fast-track ;)
[15:43] <pitti> mdz: for a start, the UI could just print the exception to stderr, so that calling apport-gtk in a shell will reveal it
[15:45] <mdz> asac: done, https://code.edge.launchpad.net/~mdz/network-manager/ubuntu.0.7/+merge/906
[15:45] <asac> cool lets see
[15:47] <mdz> asac: I forgot to link to the bug when creating the branch; is there a way to add that?
[15:50] <mdz> pitti: that would be helpful when developing hooks
[15:51] <asac> mdz: yes you can add the branch to the bug ... there is a link below description "link to a branch"
[15:51] <mdz> asac: ah, I see it
[15:51] <asac> err "link a related branch"
[15:52] <asac> the launchpad diff view could be improved for the sake of reviewing
[15:52] <mdz> oh, someone already did it
[15:52] <asac> NEW files are not included in the diff
[15:52] <asac> mdz: maybe launchpad can now parse changelog? :)
[15:52] <mdz> asac: that seems worth a bug report on LP
[15:52] <mdz> asac: or maybe mentioning it in the bug comment triggered it?  some magic happened
[15:52] <mdz> there's nothing in the activity log
[15:53] <asac> anyway, whatever that is, it is quite good - though the lack of activity log scares me a bit
[15:54] <mdz> I bet I get a lot of karma for this, it's a new LP feature ;-)
[15:54] <ogra> really ?
[15:54] <asac> any idea what launchpad product the code browser is maintained in?
[15:55]  * ogra uses it in his cmpc product since quite a while
[15:55] <mdz> asac: you can just file on launchpad.net/launchpad
[15:55] <mdz> kiko tells me they triage all the bugs from there and move them to the right place
[15:56] <mdz> asac: but it's launchpad-bazaar for reference
[15:56] <asac> ok ... i'll try ;)
[15:58] <cjwatson> mdz: debcommit
[15:59] <cjwatson> mdz: if you used debcommit for the change, and put an LP: tag in the changelog, debcommit now parses out those LP: tags and uses bzr --fixes lp:bugnum which turns into a related-branch object when the branch is pushed
[16:01] <mdz> cjwatson: *hug* debcommit
[16:02] <cjwatson> it's all really quite nicely joined up now
[16:02] <asac> awesome ;)
[16:02] <cjwatson> thank james_w for that change
[16:02] <asac> cjwatson: is that implemented in bzr itself or in a plugin?
[16:03] <asac> (i mean the --fixes op)
[16:03] <pitti> I recently noticed it as well, thanks to whoever did it
[16:03] <pitti> asac: it's in debcommit, I suppose
[16:03] <cjwatson> asac: bzr commit --fixes is in bzr itself, though the lp: bit may be in the launchpad plugin
[16:06] <pitti> mdz: traceback printing from hooks committed
[16:06] <StevenK> pitti: james_w, with a little of my Python help, if I can borrow some credit.
[16:06]  * pitti hugs james_w and StevenK
[16:07] <cjwatson> StevenK: ah, sorry, didn't realise you'd helped
[16:07] <cjwatson> DYM perl help
[16:07] <cjwatson> ?
[16:07] <StevenK> Hm. Perhaps I'm thinking of something else that also implemented bzr --fixes
[16:09] <StevenK> Ah, yes, I do mean Perl help.
[16:09] <StevenK> Reading the code brings the memories of suggesting it
[16:10] <StevenK> map {} FTW
[16:11] <saivann> tkamppeter : Did you have time to review my patches in bug 251972 ?
[16:13] <saivann> and bug
[16:13] <saivann> 256873
[16:27] <ion_> Have you (people in charge of the DistributedDevelopment spec) considered using pristine-tar? E.g. git-import-dsc imports the extracted tarball to ‘master’ branch, uses pristine-tar to store a binary diff between a tarball exported from the given commit to the master branch and the original tarball to ‘pristine-tar’ branch and branches ‘debian’ branch from the ‘master’ branch and applies the diff.gz to it. cjwatson?
[16:27] <cjwatson> ion_: I believe that pristine-tar is in fact mentioned in there; if not, yes, it's been discussed and I think it's mostly a technical matter of where to store the delta
[16:28] <cjwatson> at least for branches corresponding to .orig.tar.gz
[16:28] <ion_> Oh, i only grepped https://wiki.ubuntu.com/DistributedDevelopment/Specification for pristine-tar and didn’t notice it there.
[16:29] <cjwatson> yeah, it appears not to be there
[16:29] <cjwatson> james_w: ^-
[16:44] <james_w> cjwatson: it was discussed at the last sprint, I haven't written up the proposal yet
[17:16] <cody-somerville> slangasek, Why is Xubuntu failing to build? (Hash Sum mismatch)
[17:26] <kees> seb128: I touched vte and gnome-control-center (both went into bzr).  did I break something?
[17:27] <seb128> kees: hey
[17:27] <seb128> kees: not, just suprised to get a random UI change in gnome-control-center without any discussion on the ubuntu-desktop mailing list or in launchpad first
[17:28] <seb128> kees: usually people don't do random changes without discussing those first or that would be somewhat cahotic ;-)
[17:28] <kees> seb128: ah, heh.  upstream seemed supportive, and I chatted with bryce about it (since he'd done work on that widget)
[17:29] <kees> seb128: I didn't think it was a huge change, but I will try to be more vocal next time.  is the addition of aspect a problem?
[17:32] <seb128> kees: right, I don't say the change is wrong, I'm just not used to have people who don't work on a package usually uploading changes without discussing those with the team which does maintain the package, ie I would not do an xorg change now without asking #ubuntu-x or bryce before
[17:33] <seb128> kees: otherwise the change looks good, I'm just not sure about the alignments
[17:33] <seb128> the combo looks weird, I would probably try to align the ratios in a column or something
[17:39] <kees> seb128: hrm, yeah, I wasn't sure how to do that and still have it be a combo
[17:41] <pwnguin> sounds like a job for a certain usability expert ;)
[18:26] <bigon> could someone have a look at https://bugs.edge.launchpad.net/ubuntu/+source/enchant/+bug/261075 ?
[18:35] <jameswf-home> Anyone know why a seed file takes if placed in initrd but not if refered to externaly + why d-i seems to ignore some debian syntax
[18:36] <jameswf-home> example of ignored line d-i passwd/make-user boolean false
[18:38] <torkel> I'm not sure if using apport-gtk for creating a bug report that apport-gtk has crashed is always a good idea :-)
[18:41] <cjwatson> DktrKranz: bug 71341; please don't recommend a patch system when people are changing files in debian/
[18:42] <cjwatson> jameswf-home: that's only valid if you've also preseeded passwd/root-login to true, otherwise you end up with a system with no users
[18:43] <cjwatson> jameswf-home: certain items can only be preseeded from the initrd or from the kernel command line, as the installation guide notes. This is because the early steps of the installer happen before the installer knows how to fetch files from the CD or the network. passwd/make-user is not one of those items, though.
[18:44] <ogra> cjwatson, oh, wow, you uploaded (and edited) the lsusb thingie
[18:45] <jameswf-home> cjwatson: I understand that but nothing from the seed file takes hold outside but everything (except the user thing) worked inside initrd
[18:47] <cjwatson> ogra: yeah, took a little while
[18:48] <cjwatson> jameswf-home: it does work in general (we rely on loading a preseed file from the CD for Ubuntu installations), so I need to know more details about what you're doing.
[18:48] <ogra> yeah, the patch was hairy i glaced over it shortly but didnt have time for more about two weeks ago
[18:48] <cjwatson> jameswf-home: what you're saying is that it doesn't work *for you*, so I need to understand what's different between what you're doing and the correct approach
[18:49] <cjwatson> ogra: it was on dholbach's list of stuff I was supposed to do. :)
[18:49] <ogra> the sheer size scared me away a bit
[18:50] <ogra> right, but i said i'd review if someone did a patch
[18:51] <jameswf-home> cjwatson: I am doing it "the debian way" which is likely the root issue
[18:51]  * ogra thinks sometimes we should rename bugs.launchpad.net to "sore conscience" ... it so often feels like that
[18:52] <cjwatson> jameswf-home: I don't see why that would be the case
[18:52] <cjwatson> jameswf-home: I'm a Debian d-i developer as well
[18:52] <cjwatson> jameswf-home: first things first: which Ubuntu CD are you using?
[18:52] <jameswf-home> cjwatson: ubuntu-server 8.04
[18:53] <jameswf-home> cjwatson: I tacked on to the default ubuntu-server.seed
[18:53] <cjwatson> jameswf-home: what is your interpretation of "the Debian way"?
[18:53] <cjwatson> and can I see your preseed file?
[18:55] <jameswf-home> cjwatson: all the changes I have made are per the debian docs :: http://pastebin.com/m6a36d263 :: no commenting and I am by no means an expert (obviously)
[18:57] <cjwatson> jameswf-home: could you also post the syslog from the installer? if you've completed an installation, it will be in /var/log/installer/syslog
[18:59] <cjwatson> jameswf-home: you should remove debian-installer/language, console-display/kbd, and console-keymaps-at/keymap; your syntax for console-setup/modelcode is wrong (missing "string", should be all-caps "SKIP", and why are you preseeding that anyway when you're also preseeding a keyboard configuration?)
[18:59] <cjwatson> jameswf-home: the locale and keyboard stuff must be done on the kernel command line or by initrd preseeding, not in a preseed file
[18:59] <jameswf-home> because had no luck with the other so tacked on
[19:00] <cjwatson> jameswf-home: netcfg/get_hostname and netcfg/get_domain preseeding is unfortunately known-broken (bug 218965)
[19:01] <cjwatson> jameswf-home: the rest of it ought to be fine, so if I see the syslog I may be able to figure out why it isn't working for you
[19:02] <jameswf-home> I applied your suggestions I am going to roll an ISO real quick to test I will let it complete
[19:06] <cjwatson> jameswf-home: thanks. I'm afraid I have to step away from the computer for a few hours, but stick around and I'll look at what you've got when I get back
[19:07] <alex-weej> hello
[19:07] <alex-weej> RGBA anti-aliasing seems to have regressed lately
[19:07] <alex-weej> are we still carrying the (legally questionable) freetype/cairo patches?
[19:10] <ion_> alex: My fonts look perfect with the correct settings.
[19:15] <slangasek> cody-somerville: mirror out of date for some reason
[19:43] <LaserJock> is https://code.edge.launchpad.net/~ubuntu-core-dev the best place to see if a package is maintained in bzr?
[19:43] <cody-somerville> no
[19:44] <LaserJock> cody-somerville: ok, what is a better place?
[19:44] <cody-somerville> apt-cache showsrc <pkgname> probably is
[19:45] <LaserJock> doesn't that presuppose that X-VCS headers have been set?
[19:45] <cody-somerville> slangasek, can you sync it and kick it off again?
[19:45] <cody-somerville> LaserJock, Indeed.
[19:45] <LaserJock> s/headers/fields/
[19:46] <cody-somerville> LaserJock, However, looking at ~ubuntu-core-dev is probably less likely of an indicator. Especially for special interest packages such as xfce4
[19:47] <LaserJock> between ~ubuntu-core-dev and ~ubuntu-dev should it cover mostly everything?
[19:47] <LaserJock> or do individual people and teams maintain package branches?
[19:54] <LaserJock> Riddell: is KDEEdu maintained in bzr somewhere? apt-get source says that it's maintained in Debian SVN
[19:55] <jpds> LaserJock: It's under ~kubuntu-members I think.
[19:55] <jpds> ...and I don't think most people use the Bazaar branches there.
[20:00] <Riddell> LaserJock: it's not in bzr
[20:00] <LaserJock> Riddell: ok, thanks
[20:01] <NCommander> persia, you floating around?
[20:08] <RainCT> Is mvo on holiday or something? (because I can't find him on IRC)
[20:10] <Riddell> RainCT: yes
[20:11] <RainCT> Riddell: Ah. Do you know when he will be back, or if I can poke someone else for apturl changes?
[20:11] <DktrKranz> cjwatson, indeed! I misread it, sorry.
[20:12] <Riddell> RainCT: thursday
[20:12] <jameswf-home> anyone have any thoughts? debconf: Obsolete command TITLE
[20:15] <calc> my son turned 1 on sunday :-)
[20:16] <_MMA_> ﻿calc: Congrats! Mine turns 4 this coming Sun. :)
[20:17] <calc> http://www.new.facebook.com/photo.php?pid=30090053&l=f3c21&id=1376832583
[20:17] <calc> _MMA_: wow almost ready for school :)
[20:18] <_MMA_> Yep. Daughter is almost 7. Makes me feel old. :)
[20:18]  * jameswf-home has 7 soon to be 8 and 10 soon to be 11 
[20:19]  * LaserJock has a cat
[20:19] <_MMA_> hehe
[20:19]  * jameswf-home has 2.5 dogs and a cat...
[20:56] <RainCT> Riddell: Ah, I'll wait for him to come back then. Thanks :)
[21:29] <mathiaz> slangasek: is https://wiki.ubuntu.com/PAMConfigFrameworkSpec implemented ?
[21:29] <slangasek> mathiaz: yes
[21:33] <slangasek> cody-somerville: apparently not, I evidently don't know what's causing the mirror sync failure
[21:34] <cody-somerville> : O
[21:34] <slangasek> cody-somerville: and I don't have time to look at it at the moment, I'm afraid; I'll try again late this evening
[21:35] <mathiaz> slangasek: http://paste.ubuntu.com/42831/ <- is this a rather accurate short description of the new pam config framework ?
[21:36] <mathiaz> slangasek: I'm writing up a blog post to recap what happened in the archive for ubuntu-server related packages (which include libpam-ldap and libpam-smbpass)
[21:36] <slangasek> mathiaz: pam_cracklib, pam_ecryptfs, and pam_ck_connector are also included in the list of modules that support it now
[21:37] <slangasek> looks accurate though, yes
[22:31] <emgent`nl> hello
[22:35] <lukehasnoname> hello
[22:57] <Drust> hi
[23:15] <NCommander> cjwatson, hola
[23:36] <jameswf-home> cjwatson: BTW your suggestions and in reading other suggestions by you in google found irc logs have resolved most of my issues...
[23:45] <cjwatson> jameswf-home: obsolete command TITLE> completely unimportant; ignore it
[23:45] <cjwatson> NCommander: hello
[23:45] <cjwatson> jameswf-home: ok, though since you seem to have the syslog I'd be interested in a quick look
[23:45] <cjwatson> jameswf-home: I'm curious what your problem actually was
[23:46] <NCommander> cjwatson, Is it possible we can get a change made to xubuntu hardy seed (or have it moved to our group; we need to make a seed change to resolve a bug)
[23:46] <NCommander> I can cook up the branch to merge in a moment
[23:48] <cjwatson> NCommander: it's late for me now, but please push the branch you want to ~xubuntu-dev and send me a reminder mail, and I'll move it across in the morning
[23:48] <jameswf-home> cjwatson: probably personal stupidity
[23:48] <NCommander> sweet, thanks cjwatson
[23:49] <mathiaz> slangasek: there are two bugs in openldap related to the fact that the openldap user is not part of certain groups (ssl-cert and sasl) and thus upgrades stop working.
[23:50] <mathiaz> slangasek: moreover if slapd is configured to use sasl or TLS the openldap user has to be added to the relevant group
[23:50] <mathiaz> slangasek: what do you think about adding the openldap user to ssl-cert and sasl group automatically at install time ?
[23:53] <jameswf-home> cjwatson: I am doing some more tweaking this is the syslog from the lst iso roll http://pastebin.com/m2f1bfcb3