[00:20] <spiv> rhkfin: perhaps you want the 'bzr-upload' plugin?
[00:44] <Manganeez> mathrick: the problem does indeed seem to be the back-port commits into the 2.7.1 tag in my scenario. I'm having trouble thinking of a way around it.
[00:46] <mathrick> Manganeez: I don't think any exists
[00:46] <mathrick> backports are indistinguishable from conflicting edits
[00:48] <Manganeez> In dreamland, where I live, I'm imagining somehow backing out all of the backport commits by rolling back to the rev when the tag was originally created, then merging to the new tag.
[00:53] <mathrick> that might be possible
[00:54] <mathrick> though it'd likely be somewhat involved
[00:54] <Manganeez> Seems like that falls into the "rewriting history" category, though
[00:55] <mathrick> Manganeez: yes, but it might be possible to coerce pipes / rebase into doing just that somehow
[00:55] <mathrick> I'm not exactly sure, though, I don't have a very good grasp of how pipes work
[00:55] <mathrick> I just know they somehow result in rewritten history without actually having done that
[00:58] <mathrick> Manganeez: http://wiki.bazaar.canonical.com/BzrPipeline <-- maintaining patches on top of upstream branches is one of the listed use-cases
[00:59] <Manganeez> Reading that now... :P
[00:59] <Manganeez> also hadn't heard of bzr-pipes. Like I said, <-- n00b
[00:59] <mathrick> since it works even with tarballs, which have 0 history, svn should be handled with no problems :)
[00:59] <mathrick> Manganeez: pipes are hot new tech, I don't understand it myself yet
[01:00] <Manganeez> the stacking seems a bit like loom, another thing I don't quite get
[01:03] <mathrick> yes, looms are similar
[01:08] <igc> morning
[01:29] <lifeless> morning igc
[01:30] <igc> hi lifeless
[02:09]  * mwhudson is amused to note that hosting weave branches on launchpad has been really broken for a long, long time
[02:09] <mwhudson> or any all-in-one format
[02:16] <Manganeez> <-- n00b still catches himself thinking subversiony
[02:23] <Manganeez> mathrick (if you're still there): based on experimentation, it's really seeming like the easiest way to track vendor svn development is to *not* have bzr-svn installed. Instead, just have a hybrid repo where you svn sw & bzr commit. Branch from that for customization branches.
[02:23] <Manganeez> If it's installed, bzr-svn intercepts and prevents that from working.
[02:25] <Manganeez> for centralized repo, branch from mirror to create the centralized, and branch from *that* for customization work.
[02:25] <Manganeez> never push back to vendor mirror
[02:26] <Manganeez> It just seems like, in spirit, bzr-svn should provide a way that's *easier*, not step on existing possibilities to make it *harder*
[02:41] <Manganeez> anyone: is there a way to get a diff between the current branch and the parent branch? Which I think is the same as asking for the diff that would be applied if I pushed?
[02:43] <spiv> Manganeez: "bzr diff :parent", although if the branches have diverged then "bzr diff -rancestor::parent" is probably more helpful.
[02:43] <spiv> You may also find "bzr merge --preview" to be helpful
[02:44] <Manganeez> ah, thanks spiv. I also just figured out how to do it with "--old"
[02:44] <spiv> :parent is a location alias, "bzr help location-alias" or http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/location-alias-help.html
[02:47] <Manganeez> "bzr diff :parent" produced no output. I think the old/new logic is just reversed from what I was looking for (parent had no missing changed for me, only the other way around). "bzr diff --old :parent" works.
[02:47] <Manganeez> Basically, I want to see my customizations vs. my parent vendor-tracking mirror.
[05:14] <lifeless> spiv: spm: https://code.edge.launchpad.net/~gz/bzr/kindness_to_FAT_and_other_utime_stories_epilogue/+merge/23545
[05:14] <lifeless> merged by pqm, zaroo email involved
[05:14] <lifeless> note the bug at the end :P
[06:42] <igc> back
[06:48] <lifeless> front!
[06:58]  * joyer
[07:01] <joyer> is there new plan to boost bzr's first time clone's low speed & memory exhausted?
[07:02] <joyer> every time a clone emacs repo...The whole system hung up(386M memory unbuntu).
[07:07] <mwhudson> joyer: i filed a but about that last week
[07:07] <mwhudson> bug
[07:08] <mwhudson> joyer: https://bugs.edge.launchpad.net/bzr/+bug/562666
[07:09] <lifeless> joyer: this is cloning over the network or locally ?
[07:14] <igc> lifeless: :-)
[07:19] <rhkfin> spiv: bzr-upload, will check, thanks!
[07:20] <joyer> lifeless: over network.
[07:20] <lifeless> joyer: from which host ?
[07:21] <joyer> 'v no idea. I'm from asia... and type this `bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk'
[07:22] <lifeless> ok, bzr.savannah.gnu.org - thats running plain http
[07:22] <lifeless> so will be slow and use a lot of memory.
[07:22] <joyer> than my CPU will be drain out by bzr for 5 hours or so.
[07:22] <lifeless> This is a) expected, b) a fix will eventually be deployed, but its a configuration issue not a bzr bug
[07:23] <joyer> I see. there may be some storage architectur diff between git/hg/bzr...
[07:23] <joyer> but bzr seems need alot more memory
[07:23] <lifeless> joyer: all three performan suboptimally over plain http; they need a server side component to perform best
[07:24] <lifeless> joyer: try 'bzr branch lp:emacs'
[07:24] <poolie> hi lifeless
[07:24] <lifeless> joyer: its a mirror of the savannah branch, and should be faster and use less memory
[07:24] <lifeless> poolie: hihi
[07:24] <poolie> how's pqm?
[07:25] <lifeless> poolie: pretty good; launchpadlib is very very very slow; I have fixes for the UI for when spm gets back from a out-of-house thingy
[07:25] <poolie> ok
[07:25] <poolie> and other stuff?
[07:25] <lifeless> its happily merging from launchpad though
[07:25] <lifeless> which is great. One small glitch to wrap up and then its can be forgotten about - its not reporting quite right.
[07:25] <joyer> lifeless: i can tolerate the slowness. but memory consume too much.. why not cache out to disk??
[07:25] <lifeless> various bugs looked at.
[07:26] <lifeless> joyer: caching out to disk happens via swap, naturally.
[07:27] <joyer> mwhudson: didn't notice it . i'wll check it .
[07:27] <lifeless> joyer: we dont' caching the bulk of the content. Because you're using HTTP though, more is being kept in memory than if you use a smart server url - like the bzr+ssh://bazaar.launchpad.net/~vcs-imports/emacs/trunk
[07:27] <lifeless> joyer: the bug mwhudson referenced isn't what you're suffering.
[07:27] <joyer> lifeless: I'm behand a big firewall~
[07:28] <lifeless> joyer: do you have ssh access ?
[07:28] <joyer> lifeless: ok.. I'll take a look.
[07:28] <joyer> lifeless: no.  a guess alot people at work are behind FW.
[07:30] <joyer> lifeless: I still hope bzr can run politely on low memory machine (like mine). I'll try hack on the source code, and write a patch.(that will be not short)
[07:31] <lifeless> joyer: we are working to reduce memory use
[07:31] <lifeless> joyer: but emacs is a very large repository
[07:31] <lifeless> joyer: how much memory do you have?
[07:31] <joyer> 386Mb
[07:32] <lifeless> that is a very small amount.
[07:32] <joyer> lifeless: emacs isn't the biggest repo..mozilla is bigger.. also linux kernel.
[07:32] <joyer> lifeless: bzr should scale up..
[07:33] <lifeless> joyer: there are folk using bazaar on both of those as I understand it
[07:33] <lifeless> joyer: heck, current GNOME uses 300 MB or so just booting.
[07:34] <lifeless> joyer: We would like to be leaner on memory use, and there is some work going on.
[07:36] <joyer> lifeless: thanks for the info.. I'll check the source code to gain some prove..
[07:41] <poolie> lifeless: maybe i should try that idea of dumping gc usage into apport
[07:41] <poolie> though maybe apport won't fit
[07:42] <lifeless> poolie: if we get apport MemoryError exceptions, then apport probably will
[07:42] <lifeless> OTOH by the time the exception handler runs, a lot of the memory may have been freed
[07:45] <vila> hi all
[08:04] <lifeless> eoding, time to pack
[08:04] <poolie> cheerio
[08:04] <poolie> hi vila
[08:17]  * joyerh
[08:50] <napster> 'bzr lp:pull panther' returns 'permission denied public key' error :-( what to do?
[08:50] <spm> napster: wild guess, but did you perhaps mean: bzr pull lp:panther?
[08:51] <napster> spm, That what I meant, sorry for mistake :)
[08:51] <spm> heh, is cool.
[10:22] <C2H5OH> hi, is it possible to mix centralized and distributed workflow?
[10:22] <C2H5OH> for example, my work colleages all use bzr in a centralized manner (with checkouts) but I would like to use it as branches
[10:23] <fullermd> Sure.
[10:23] <fullermd> What you do in your workspace has no relation to what they do in theirs (and vice versa).
[10:24] <fullermd> 's kinda the basis of distributed right there   ;)
[10:24] <C2H5OH> ok, so if I have a different branch and take care of merge myself, then it does not conflict with their linear histori, correct?
[10:28] <C2H5OH> ok, I found it
[10:29] <C2H5OH> unbind and bind might do the trick for me
[10:30] <fullermd> I'd avoid that, myself.  It's coloring a bit outside the lines.
[10:31] <fullermd> I'm not really sure what you mean by 'conflict with their linear history', but work is work.
[10:31] <fullermd> They have to 'update' when they get a rev behind, or two revs.  Or 50 revs.  It doesn't much matter whether those revs are all on the mainline, or some of them are off to the right.
[10:31] <C2H5OH> I mean, centralized manner forces linear history
[10:32] <C2H5OH> (without merge commits)
[10:32] <C2H5OH> but I've read that bzr log hides merge commits by default
[10:32] <spiv> Right.
[10:32] <fullermd> Oh, not really.  If you work purely in checkouts without ever using other branches, you won't (aside from some special cases) ever get any right-hand parents.
[10:33] <spiv> Also, the presence of merge commits on the mainline won't interfere at all with someone that is using "bzr up" etc.
[10:33] <fullermd> But that...  what spiv said.
[10:33] <C2H5OH> ok, so then I should not be afraid of that
[10:33] <spiv> (And if they ever do "bzr commit --local" then they will in generate merge commits, i.e. commits with multiple parent revisions, anyway)
[10:33] <spiv> Definitely no need to be afraid.
[10:35] <C2H5OH> I'll have to read more docs
[10:35] <C2H5OH> in order to get familiar with the terms
[10:35] <C2H5OH> coming from git/mercurial does not make it easy
[10:37] <fullermd> It certainly presents different challenges than coming from CVS.
[10:38] <C2H5OH> back to work then
[10:38] <C2H5OH> thank you very much for your help
[10:38] <C2H5OH> ;-)
[10:38] <spiv> You're welcome!
[10:59] <bialix> hmm, C2H5OH perhaps russian guy
[11:03] <millun> hi
[11:04] <millun> how can i list files commited between revisions #3 and #15?
[11:11] <bialix> millun: bzr st -r3..15
[11:19] <millun> thanks
[13:02] <sven_sandberg> hi #bzr! i have a source tree with changes in two files, file1 and file2. i want to commit the changes in two different changesets: cs1 with changes in file1 and cs2 with changes in file2. i have ran 'bzr gci' and typed changeset comments for both files. but when i de-select file2 and commit only file1, the changeset comments for file2 are lost.
[13:03] <sven_sandberg> since we now have the nice feature that changeset comments can be saved when a commit is cancelled, would it be possible that we could save the comments also when a file is not included in the commit?
[13:05] <maxb> Sounds like cause for bug to be filed against bzr-gtk
[13:06] <sven_sandberg> maxb, thanks for confirming that. should bzr-gtk bugs be filed at https://bugs.launchpad.net/bzr/+filebug too?
[13:06] <maxb> I'd imagine it would be better to file against bzr-gtk not bzr
[13:07] <maxb> though that's driven by my _assumption_ that the existing commit comment saving is presumably in bzr-gtk
[13:07] <jelmer> maxb: it's in both bzr-gtk and qbzr
[13:09] <sven_sandberg> maxb, jelmer, iirc, before this was in any official versions, i had to use custom versions of *both* bzr and bzr-gtk in order to save commit comments. i'm not sure which one of them would need to be patched for this to work
[13:16] <sven_sandberg> ok, is it ok if i report it as a bzr-gtk bug?
[13:18] <jelmer> sven_sandberg: I really think the commit message saving should be moved into bzr core
[13:19] <sven_sandberg> jelmer, ok, so i'll report a bzr bug?
[13:19] <nitian> mathrick: i was merging this http://pastebin.com/95Hj6QTP and now it has continued merging again from the last data stored till now!
[13:20] <nitian> now i have got : Read from remote host bazaar.launchpad.net: Connection timed outnserting stream
[13:21] <jelmer> sven_sandberg: against bzr-gtk for now
[13:21] <sven_sandberg> jelmer, ok, will do
[13:22] <mathrick> nitian: looks like your network is hosed
[13:24] <nitian> mathrick: so should i cancel/kill the bzr merge
[13:24] <mathrick> nitian: dunno, didn't it error out?
[13:24] <nitian> mathrick: no it is still fetching revisions!
[13:25] <mathrick> then probably let it do that
[13:25] <mathrick> I don't understand why it'd be so slow, I get almost 2M/s here
[13:25] <nitian> mathrick: but i guess it has gone way beyond the original download size!
[13:25] <mathrick> nitian: then kill it?
[13:26] <mathrick> huh, that thing's large
[14:50] <vila> jelmer: ping, regarding https://code.edge.launchpad.net/~jelmer/bzr/more-colo/+merge/23592 , it seems this mp has already changed from this morning
[14:50] <vila> jelmer: there are conflicts currently, still some None args (which I suspect are name=None)
[14:51] <vila> jelmer: I'd like to review it but given the above... I'm not sure it is stable :)
[14:53] <vila> jelmer: And I saw a branch_name instead of just name.. take your pick :)
[15:03] <nitian> mathrick: i did this   http://pastebin.com/HxWTzx3b   but i am getting this error: Read from remote host bazaar.launchpad.net: No route to host
[15:27] <MvG> vila: I've just replied to your review at https://code.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 and I'm here in case you want to comment. I'd be particularly interested in whether there was a misunderstanding with that cache remark of yours.
[15:28] <jelmer> vila: thanks for the comments, I'll have a look
[15:28] <vila> jelmer: k
[15:29] <vila> MvG: looking
[15:30] <vila> MvG: Wow, indeed, I misread
[15:30] <MvG> I realize I might have avoided a bit of spam to the LP merge tool by trying IRC first and writing the mail afterwards, but it's too late for that now...
[15:31] <MvG> vila: Glad that's solved then. I assume you now approve, so I'll wait for another approval. Thanks!
[15:31] <vila> MvG: wait :)
[15:31] <MvG> Sure.
[15:31] <MvG> After all, what else can I do instead of waiting... :-) But I'll stay tuned here as well.
[15:33] <vila> MvG: my remark still reflects a lack of docstring I think, it's a bit weird to have a parameter ignored like that and ISTM that specifying --author on the command line should take precedence above whatever default the log formatter is using
[15:33] <vila> MvG: may be we don't have the right infrastructure to handle that yet,
[15:33] <vila> MvG: but at least you should document that (a comment or a docstring is fine)
[15:33] <MvG> vila: Please expand ISTM
[15:33] <vila> It Seems To Me
[15:34] <MvG> If the command line wouldn't take precedence, there'd be little point in that whole patch.
[15:35] <vila> MvG: I'm downloading your branch to review it in place, obviously I miss some context here
[15:35] <reyman> hello
[15:37] <MvG> vila: My idea is that there are multiple facets to logs: one is general format, another is authors list, and others (maybe to be implemented in future) might include a distinction between real name, email or account name, or might include a choice between bug URLs, bug numbers or no bug references at all. You surely can think of many other ways to fine-tune any log.
[15:37] <vila> MvG: ooooh yes I can :-/
[15:37] <MvG> vila: So I want --format to choose the format, --authors to choose whom to list as authors, and so on. That way I can tune the format to match my needs, without having to implement a new format for every combination of these aspects.
[15:38] <reyman> i'm starting a project with milestone on launchpad (ex lp:~sproject/1.0/1.0start for first milestone), i don't understand how i can push my code on this milestone, i try "push lp:~reyman64/sproject/1.0/1.0start" but bzr say : "bzr: ERROR: Permission denied: "Cannot create '1.0start'. Only Bazaar branches are allowed.""
[15:38] <vila> MvG: authors should be an option to the format
[15:38] <vila> MvG: bug we can't do that right now
[15:38] <MvG> reyman: Push to ~user/project/name and then register name as the branch for that series. Milestones don't have their own branches.
[15:39] <vila> MvG: you don't want every format to reimplement the author logic right ?
[15:39] <MvG> vila: Look at line 60 of the diff: I made it an option to the format.
[15:40] <vila> MvG: we're in agreement then
[15:40] <reyman> MvG, ok i try
[15:40] <MvG> vila: And no, I don't want to reimplement anything, that's why I want the logic in the base class and all derived classes inheriting from it.
[15:44] <reyman> so MvG i have only one branch for one serie ... i cannot register multiple branche for one serie, isn't it?
[15:45] <MvG> reyman: You're correct. You can have any number of branches associated with the project, and many might be closely related to a specific series on the content level, but only one of them is the official branch for the series as launchpad lists it.
[15:45] <MvG> reyman: By the way: when you reach the milestone, you might want to tag it in bzr. That way users have easy access to it even when the series moves on towards the next milestone/release.
[15:46] <vila> MvG: yet, ShortLogFormatter use short_author which force who to be 'first', so ISTM that doing bzr log --short --authors=all won't work no ?
[15:47] <vila> MvG: Your test cheats to achieve that I think
[15:49] <MvG> vila: the authors method ignores the who if -authors is specified. I'm pretty sure I even tested this on the command line.
[15:50] <vila> MvG: Ha, right, damn I keep getting this backwards, please add a comment there !
[15:50] <MvG> vila: Currently writing... :-)
[15:52] <vila> or may be just reverse the code so it's more obvious that 'who' is relevant only if _author_list_handler is None
[15:54] <reyman> So if i understand MvG , for example if i have 3 milestone for serie 1 : a, b , c . I have three branch 1a 1b 1c or only one branch 1 with tag for release a b c?
[15:56] <vila> MvG: sorry for the late comments...
[15:57] <MvG> reyman: The second one is the preferred setup, I guess. The first one is very svn-style, and might cause confusion in some cases.
[15:57] <MvG> reyman: Of course, you could also have a single branch "trunk", configured as the main branch for all your series... There are a million ways, but some are more common than others.
[15:57] <vila> MvG: bug one more thing: we try to always use keyword arguments as such, and the way to decide if an argument is a keyword one or a positional one is mostly based on whether it has a default value
[15:58] <MvG> vila: Is use of ReST-style ``name`` to mark identifiers in docstrings good practice?
[15:58] <vila> MvG: so, can you use short=Ture and sep=', ' in the short_author call
[15:58] <MvG> Sure.
[15:59] <vila> MvG: yes, not enforced but I think we are leading towards it, to be honest I think I use 'name' myself though
[16:00] <reyman> Mvg, i'm trying to have a layout like bzr :) So you have only one trunk branch for each serie , and you tag it . Which name you associate with trunk of each serie ?
[16:00] <vila> MvG: except when you use the :param name: construct where it's already clear that you're referring the parameter
[16:00] <vila> reyman: we use the series itself: lp:bzr/2.2
[16:01] <vila> reyman: series is always plural (don't ask me why, I'm not a native english speaker :-)
[16:01] <MvG> reyman: The term "trunk" normally is per project, not per series.
[16:03] <MvG> reyman: Looking at https://code.launchpad.net/bzr and looking at the link targets as your browser displays them, you'll see that the 2.2 series branch is in fact lp:~bzr-pqm/bzr/2.2, i.e. belongs to user ~bzr-pqm, project bzr, branch name 2.2.
[16:03] <MvG> vila: pushing.
[16:05] <MvG> reyman: The user is of course called bzr-pqm, not ~bzr-pqm. Sorry there.
[16:07] <reyman> ok thks :) one other question (the last), when lp:bzr/2.2 is ok , all bugs fixed (:p ), you merge it into trunk ? or in fact bzr/2.2 have trunk for parent, and milestone are only for bugs correction ? In this case, you merge bug correction into trunk  AND bzr/2.2 ?
[16:13] <MvG> reyman: I'm not too involved with how the bzr project handles things, but I personally found the following useful for my own, smaller projects: start with a branch "trunk", and a series "1.0" using trunk as its main branch. Work on it, do milestones and releases numbered 1.0.x, improve the code, until things become reasonably stable.
[16:13] <MvG> reyman: Then when I want to work on a feature that might break that stability, I branch: I create a 1.0 branch off current trunk, and make that the main branch for the 1.0 series. I also start an 1.1 series having trunk as its main branch. New features go into trunk. Bug fixes should be written against 1.0 if possible, and I can merge the 1.0 branch into trunk from time to time.
[16:14] <MvG> In the past, I've created the new branch starting with the first release of a series. That caused a lot of troubles, though: people submit fixes against trunk, and it takes more work to get them into the release series. This is the reason why I suggest splitting stable and trunk branches only when you actually introduce new features.
[16:15] <MvG> vila: Have you read the new docsting and comments? Things better now?
[16:17] <vila> MvG: yup
[16:17] <reyman> ok MvG thx a lot for your help :)
[16:20] <MvG> lifeless: As you already did a review of its predecessor, would you like to review https://code.edge.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 as well?
[16:22]  * MvG is afk for a while.
[16:31] <seeg> hello
[16:31] <seeg> i have a small problem
[16:32] <seeg> sometimes when i push a repo, the transfer stops because of some reason. when i try to push again i get file locks and the repo becomes dirty
[16:32] <seeg> how to clean this mess up?
[16:32] <seeg> i mean other than removing the repo and branching it anew
[16:35] <maxb> I seem to remember that that error message actually *tells* you how to clear the locsk
[17:30] <mathrick> seeg: bzr break-lock
[17:31] <seeg> ah, this is what i needed :)
[17:31] <seeg> mathrick, thanks ;)
[17:32] <mathrick> you're welcome
[17:58] <mkanat> spm: ping -- did you see my most recent request for info relating to the last two traces posted to the codebrowse hang bug?
[18:47] <blueyed> what should I do with http://pastebin.com/S4psCNhi ?
[18:49] <maxb> blueyed: line 9, "bzr: interrupted" - you Ctrl-C-ed it or it did that all by itself?
[18:50] <blueyed> maxb:  I did it.
[18:50] <blueyed> but that should just revert to previous state.
[18:50] <blueyed> it feels like "bzr revert" deleting my files!
[18:53] <maxb> Did you do it because the 'bzr up' was taking far too long, or would it be worth moving aside the pending-deletion directory and trying 'bzr update' again?
[18:53] <seeg> what is this error:
[18:53] <seeg> bzr update
[18:53] <seeg> bzr: ERROR: Permission denied: "/home/przemek/Programming/Python/.bzr/branch-format": [Errno 13] Permission denied: u'/home/przemek/Programming/Python/.bzr/branch-format'
[18:53] <seeg> ah, ok, i got it :)
[18:54] <maxb> seeg: "Permission denied" of course.
[18:54] <seeg> yeah, i try to create a branch of files on my disk on a remote computer
[18:54] <seeg> somehow it's difficult
[18:54] <seeg> i do bzr branch xxx@xxx/path
[18:55] <seeg> but this doesn't create a working tree on the remote server
[18:58] <maxb> seeg: Please, don't obfuscate your commands. (I suspect you've changed the meaning of that one by over-obfuscation)
[18:59] <seeg> well, from my local machine i did bzr branch sftp://login@host/path/to/branch
[19:00] <midichlor> i am getting this error while $bzr add: bzr: ERROR: Could not acquire lock "/home/mid/project/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable')
[19:02] <midichlor> i think i accidently edited som file in .bzr
[19:05] <midichlor> what should i do?
[19:10] <blueyed> maxb: I will move it away and try again - but this is distracting / causing data-loss-fear.
[19:11] <maxb> blueyed: Well then, why not just back up your changes via a 'bzr diff' first, and be unfearful?
[19:14] <blueyed> maxb: done so. point remains: why doesn't ctrl-c revert/break the "bzr up"?
[19:14] <blueyed> why do I have to cleanup to dirs after that?
[19:15] <maxb> I am not aware of whether that is supposed to be necessary or not
[19:15] <blueyed> Also: "Conflict adding file blogs/rsc/js/debug.js.  Moved existing file to blogs/rsc/js/debug.js.moved." is no conflict, if the file has the same content IMHO? new bug? reported already?
[19:15] <blueyed> maxb: me neither, but common sense is :D
[19:17] <blueyed> I'll file a new bug about the conflict when adding the same file, ok?
[19:18] <midichlor> maxb: could you help me too?
[19:18] <maxb> midichlor: Are you using Windows?
[19:18] <midichlor> maxb: no, ubuntu 9.10
[19:18] <maxb> hmm
[19:19] <maxb> What does "lsof /home/mid/project/.bzr/checkout/dirstate" print?
[19:19] <maxb> Is NFS or Samba or anything like that involved?
[19:20] <midichlor> maxb: no. i havent been dealing with any of the above
[19:22] <midichlor> maxb: http://pastebin.com/KWnk4LfF
[19:22] <maxb> Find and close both of those processes (one "bzr" and one "editor")
[19:25] <midichlor> maxb: as in kill 15225 ?
[19:26] <maxb> If necessary, but better would be to find the open editor session and quit it cleanly, if you can
[19:30] <RumblePure_> hi lifeless.
[20:24] <blueyed> Hi
[21:13] <wilx> Hi.
[21:14] <wilx> I am slightly confused about Bazaar. Is each working copy a branch effectivelly or does it some concept closer to Subversion branches?
[21:17] <lifeless> wilx: each time you run 'branch' or 'push' you're making a branch (or updating a branch)
[22:32] <LeoNerd> Hrm... I just 'rebase'd in the wrong direction...
[22:33] <LeoNerd> I don't suppose there's any nice easy way to fix that, is there?
[22:38] <LeoNerd> Ah. OK.. managed to fix by some cunning branch/replays... probably broken its hash now but I doubt anyone (else) has it checked out
[22:47] <lifeless> LeoNerd: bzr heads --dead; bzr pull . -rrevid:oldhead
[22:49] <LeoNerd> Ahyes, that would have done it too


[22:25] <flexiondotorg> cyphermox I'm about to submit a merge proposal for Ubuntu MATE slide updates for 17.10.
[22:26] <flexiondotorg> How do I update the .pot for Ubuntu MATE?
[22:33] <cyphermox> make pot
[22:33] <cyphermox> ;)
[22:33] <cyphermox> anyway, if I recall right
[22:34] <cyphermox> yep, looks correct
[22:49] <flexiondotorg> Cool, thanks.
[23:16] <flexiondotorg> cyphermox The merge proposal is here https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-artful/+merge/329488
[23:17] <flexiondotorg> I've test from a PPA. If you approve the merge I'll head to Bileto :-)


[00:00] <ajmitch> there will be others now who aren't included in that 158, but are in kubuntu-dev or similar
[00:00] <LaserJock> ahh, true
[00:01] <lee_> well, the reson for my asking, I'm planning on becomming a developer
[00:02] <LaserJock> ajmitch: actually no, 158 includes those
[00:02] <LaserJock> ajmitch: they are a member of ~ubuntu-dev I see
[00:02] <wgrant> Active developers are going to be well under 100.
[00:03] <lee_> true
[00:03] <LaserJock> I was once going to take a stab on figuring that out
[00:03] <lee_> I'm actually shocked that ubuntu is developed by so many different people and can still run like it does
[00:04] <LaserJock> something like, all the developers who've uploaded more than 1 time in the last release
[00:04] <LaserJock> last time I looked at that it weeded out probably 2/3
[00:04] <lee_> hmm
[00:04] <Daviey> LaserJock: What about people who only do security or SRU?
[00:05] <lee_> I guess it'd be the same
[00:05] <LaserJock> Daviey: what about them?
[00:05] <Daviey> LaserJock: Would they be included in your "uploaded more than 1 time in the last release"
[00:05] <lee_> <--from south, has not perfect english btw
[00:05] <akgraner> kenvandine, ping
[00:05] <LaserJock> oh, I don't know, probably
[00:06] <LaserJock> last time I wrote a script it crawled through <release>-changes
[00:06] <Daviey> ahh
[00:06] <LaserJock> which would include post-release uploads
[00:06] <ajmitch> do security uploads end up on -changes?
[00:07] <lee_> I'm new to c++ language, and I've yet to find something that will help me make a gtk program from it
[00:07] <LaserJock> ajmitch: not sure about that one
[00:07] <wgrant> ajmitch: Yes, but not with a correctly signed changes file.
[00:07] <LaserJock> right, that was the problem last time I did this, syncs, etc. were not counted right
[00:08] <LaserJock> but that was a long time ago, I think the -changes format has changed since then
[00:08] <ajmitch> lee_: if you're looking at making an application, I think #ubuntu-app-devel may have people who can help
[00:08] <wgrant> It's also reasonably easily doable with launchpadlib.
[00:08] <ajmitch> LaserJock: syncs have got attribution of who requested it in the mail
[00:08] <LaserJock> ajmitch: not with C++ ;-)
[00:09] <ajmitch> LaserJock: I don't know, I haven't been there :)
[00:09] <LaserJock> ajmitch: WRT #ubuntu-app-devel
[00:09] <kklimonda|G1> most of #ubuntu-app-devel folks are heavy python users ;)
[00:09] <LaserJock> python lovers
[00:09] <lee_> heh
[00:09] <lee_> figures
[00:09] <ajmitch> maybe some variety could be good then
[00:09] <LaserJock> JavaScript?
[00:09] <kklimonda|G1> please, don't
[00:09] <lee_> true, I've already made a game using just a terminal app
[00:09] <ajmitch> you may as well next suggest php-gtk
[00:10] <LaserJock> well, JavaScript is the new python, right?
[00:10] <LaserJock> gnome-shell is written in it
[00:10] <LaserJock> as are a few of the Gnome games now
[00:10] <wgrant> LaserJock: Only if you are GNOME.
[00:10] <kklimonda|G1> this joke wasn't funny when gnome devs told it and it isn't funny now LaserJock ;)
[00:11] <LaserJock> wgrant: as goes GNOME so goes ... um, GNOME?
[00:11] <lee_> hmm, actually, from all the sources that I learned c++ from (still a beginner at it) python is a rising programming language and is already the most used
[00:11] <kklimonda|G1> introducing JS as a part of core GNOME platform is the weirdest decision i've seen in some time :/
[00:11] <lee_> and the whole, ubuntu developers using python thing, confirms it...
[00:11] <lee_> eh, people are weird
[00:12] <LaserJock> kklimonda|G1: well, they could have picked C# ...
[00:12] <lee_> c++, and this is just my opinion, is better then c# language
[00:12] <lee_> much like ubuntu, being derived from debian, is better then debian...
[00:13] <kklimonda|G1> lee_: well, there are ubuntu developers and developers who writr apps for ubuntu - first are writing lots of glue code to make working on distribution faster and python is great for that.
[00:14] <lee_> ok, I may be a beginner at c++, but I already figured that out
[00:14] <lee_> well, I'd better go learn python...
[00:15] <RAOF> It'll be a good investment of time.
[00:15] <lee_> yup
[00:15] <lee_> cya
[00:15] <kees> ajmitch: they do end up on -changes (it was broken for a long while, but is fixed now)
[00:27] <lee_> ok, I ran across a problem...
[00:28] <lee_> how do you open python after you've installed the compressed file?
[00:43] <kklimonda|G1> is there any way of getting results that are uploaded by people using checkbox? where are they stored?
[00:45] <Guest6565> Hi. I would like to get involved in development. Can anyone give me any pointers on where to start??
[00:45] <kklimonda|G1> !development
[00:45] <kklimonda|G1> Guest6565: ^
[00:46] <Guest6565> Thanks for the Link :-D
[00:46] <kklimonda|G1> no problem
[01:33] <lee_> I need some help with something
[01:44] <ari-tczew> where can I find irc logs of channel #ubuntu-hardened ?
[01:47] <zul> irclogs.ubuntu.com probably
[01:52] <ari-tczew> zul: not found this channel :/
[01:56] <GrueMaster> crimsun: ping - in response to your comment on bug 528524, no change means that pulse is not being bypassed, and sudo speaker-test is still running through pulseaudio with the user as the owner of the device open handle.
[02:05] <GrueMaster> GrueMaster: PULSE_NO_SIMD=1 does however make it work properly, where sudo speaker-test actually grabs the pcm device as root.
[03:12] <persia> lifeless: I am available at your convenience for the next while.
[03:16] <lifeless> persia: ok cool
[03:17] <lifeless> persia: in an empty dir do
[03:17] <lifeless> lmirror init test
[03:17] <lifeless> lmirror serve test
[03:17] <lifeless> start up a tshark or similar session logging traffic on localhost port 8080
[03:17] <lifeless> we want full frame captures, not truncated
[03:18] <lifeless> then run lmirror mirror http://<IP_ADDRESS>:8080/test /tmp/test3
[03:19]  * persia starts reading tshark documentation
[03:24] <lifeless> jpds: around?
[03:24] <wgrant> He's not.
[03:25] <persia> bad timeofday + easter
[03:25] <lifeless> I know both of those things. Sometimes however, people surprise us :)
[03:27] <wgrant> lifeless: Have you put any thought into how we are going to mirror the actual archive with lmirror?
[03:27] <wgrant> With the split and all that.
[03:28] <wgrant> It could be done by maintaining a separate journal for each, but it seems like things could be much more efficient than that.
[03:29]  * persia would like to re-un-split later to save disk space
[03:33] <persia> lifeless: So, tshark documentation follows current practice of not including any examples, and being written without the clarity and concision of the SYSV manpages.  Any pointers as to how to capture?
[03:34] <crimsun> GrueMaster: I was afraid of that being the case. I guess it's time to debug the arm asm.
[03:40] <lifeless> wgrant: yes, I have
[03:40] <lifeless> persia: -i lo host <IP_ADDRESS> and port 8080 -X
[03:40] <lifeless> persia: at a guess, offhand
[03:41] <lifeless> wgrant: I suspect many journals, perhaps as many as one per dr-arch
[03:41] <persia> I finally found an example almost the same time you posted, and `tshark -f "tcp port 8080" -i lo0` seems to do the right thing.
[03:41] <lifeless> wgrant: into the same dir structure
[03:41] <lifeless> persia: ok, grab a capture of it hanging
[03:41] <lifeless> and show me
[03:42] <lifeless> back shortly
[03:44] <persia> lifeless: http://paste.ubuntu.com/409814/
[04:09] <lifeless> persia: uhm
[04:09] <lifeless> persia: that pastebin is garbage
[04:09] <persia> lifeless: You have to "download as text".
[04:09]  * persia puts the file somewhere else
[04:10] <lifeless> persia: 'download as text' gives me garbage too
[04:10] <lifeless> persia: did you use -s 0 ?
[04:11] <persia> lifeless: http://people.ubuntu.com/~persia/tshark.out and no.
[04:12] <persia> Does that seem less like garbage?
[04:13] <lifeless> persia: 403
[04:14]  * persia fights with sftp
[04:14] <persia> Try again.
[04:19] <lifeless> I have it, am looking
[04:20]  * persia 404s it to save precious disk space
[04:21] <persia> Err, 410!
[04:22] <lifeless> hmm
[04:22] <lifeless> the trace is noisy or something
[04:23] <lifeless> persia: please redo it with -s 0
[04:23] <persia> Well, it's the output of `sudo tshark -f "tcp port 8080" -i lo -w /tmp/tshark.out`
[04:23] <persia> OK.
[04:27] <persia> lifeless: http://people.ubuntu.com/~persia/tshark.out updated
[04:32] <lifeless> wow
[04:32] <lifeless> I think I need to tune the tcp interactions a bit
[04:33] <lifeless> nevertheless
[04:34] <lifeless> odd
[04:34] <lifeless> its asking for /1/1
[04:34] <lifeless> did you reuse the target mirror directory ?
[04:34] <lifeless> persia: ^
[04:34] <lifeless> persia: also, is it still hanging ?
[04:35] <persia> I used a new target directory.  I stopped the hang with Ctrl-C
[04:35] <lifeless> ok
[04:35] <lifeless> uhm
[04:35] <lifeless> please repeat, new target dir
[04:35] <lifeless> don't ctrl-C the hung process
[04:36] <lifeless> stop the tshark first
[04:38] <persia> OK.
[04:39] <lifeless> actually
[04:39] <lifeless> nevermind
[04:39] <lifeless> I think I should have enough here, I can see where you waited
[04:43] <persia> lifeless: uploaded new tshark.out for new directory stopping before stopping lmirror.
[04:55] <lifeless> its not seeing the content for the last file
[04:55] <persia> The directory is empty.
[04:56] <lifeless> wireshark shows it being transmitted
[05:00] <persia> Odd.  On the server side, the sequence was `mkdir empty; cd empty; lmirror init test; lmirror serve test`
[05:00] <lifeless> indeed
[05:00] <lifeless> I'm tracking the bug down
[05:01] <lifeless> ok, the content is being seen
[05:01] <lifeless> client side I think
[05:03] <lifeless> data is seen in the client socket
[05:07] <lifeless> ah, found it
[05:08] <lifeless> fixed
[05:08] <persia> Should my symlink still work with a fresh bzr pull?
[05:08] <lifeless> yes, though I haven't committed yet.
[05:09] <persia> OK.  Just let me know when :)
[05:10] <lifeless> ok
[05:16] <lifeless> persia: it should work now
[05:19] <persia> lifeless: Indeed.  empty mirror completed successfully.
[05:19] <lifeless> persia: cool
[05:19] <persia> Now that it runs, did you want me to actually test anything?
[05:20] <lifeless> not especially. I mean if you wanted to init somewhere with a few 10's or 100's of GB's and mirror it around, that would be sweet.
[05:20] <lifeless> but I wouldn't expect much insight from such local ops
[05:20] <persia> I'd expect the behaviour to match what you can do locally.
[05:21] <persia> So I suppose we need jpds, so I can pull against something sensibly large.
[05:21] <lifeless> I don't have the disk space to do tests on that scale locally ;)
[05:21] <lifeless> but i've tested with ~ 4GB datasets
[05:21] <lifeless> found an issue in squid 3.0.8/32bit builds
[05:21] <lifeless> but nothing in lmirror that was an issue
[05:22] <crimsun> doko_: any recommendations for dealing with #554149? Supporting 8.04 LTS -> 10.04 LTS seems thorny.
[05:25] <crypt-0> 0_o quite some activity in here
[05:26] <crypt-0> may i ask why the cryptsetup package in Lucid is *still* a release candidate (rc2) when the stable release was released in Jan ?
[05:28] <lifeless> I don't think anyone will know the answer
[05:28] <crypt-0> IIRC a lot of bugs were fixed, and the version packaged is no longer mirrored. cryptsetup-1.1.0-rc2 is in the repos between 2 and 4 there were substantial bugfixes and then the final non-rc cryptsetup-1.1.0
[05:28] <persia> crypt-0: 1.1.0-2 migrated to debian testing on Sunday, and lucid is pulling from testing.  Given the volume of ubuntu-specific patches, it may be that this will not be upgraded for release.
[05:28] <lifeless> we're in deep freeze
[05:28] <lifeless> so any change is going to be reviewed rather closely
[05:29] <persia> Given that lots of folks took Monday off for Easter, I don't think we're even behind, even if we weren't in freeze.  Given the freeze, nothing is likely to happen prior to beta2, and may well only involve cherrypicks prior to release.
[05:29] <crypt-0> i mentioned it late jan on a mailing list
[05:30] <lifeless> thats not an effective way to get things done
[05:30] <crypt-0> well will it *eventually* be upgraded like within the first month of the stable release?
[05:30] <persia> Unlikely.
[05:30] <lifeless> unless someone does the work to merge the debian and Ubuntu packages
[05:30] <lifeless> and QA the result
[05:30] <persia> It's more likely that some bits of it will be cherrypicked to address bugs.
[05:30] <lifeless> and ask for a FFe for it, no.
[05:30] <lifeless> *you* can do some / all of that work, if you like.
[05:31] <crypt-0> well where can i start?
[05:31] <ScottK> Look at what's in 1.1.0-2 and what we have in Ubuntu and see if there are Ubuntu changes that need to be preserved.
[05:32] <crypt-0> ok
[05:33] <lifeless> ScottK: hey
[05:33] <ScottK> Hello lifeless.
[05:33] <lifeless> ScottK: can you have a look at https://bugs.edge.launchpad.net/ubuntu/+bug/538946
[05:34]  * ScottK looks
[05:35] <crypt-0> ScottK, nothing besides the shell scripts
[05:35] <ScottK> Right, so the question is, are the changes needed.
[05:35] <ScottK> Likely they are.
[05:35] <crypt-0> ill work on getting out 23/64 bit packages built soon after that where should i submit them for review?
[05:36] <crypt-0> ScottK, yes they are but the changes wont effect going from 1.1.0-rc2 to 1.1.0
[05:37] <crypt-0> ScottK, so the scripts already in place will work like they do with rc-2
[05:37] <crypt-0> will just need to be extracted and added to my package
[05:37] <ScottK> crypt-0: Ideally you'd make a debdiff and attach it to a bug asking for the upgrade.
[05:37] <ScottK> lifeless: minus points for edge urls, but approved anyway.
[05:38] <lifeless> ScottK: thanks
[05:38] <lifeless> ScottK: are you also an archive admin, to do the sync, or do I need to hunt someone else down ?
[05:39] <ScottK> I'm an archive admin, but you need the "employed by Canonical and has shell access" kind for a sync.
[05:40] <persia> lifeless: Alternately, you need about 6 weeks of code reviews to fix the bug in launchpad that makes that true, but you may not want to wait that long...
[05:40] <lifeless> ScottK: ok
[05:40] <lifeless> StevenK: ping; I wants a sync done :)
[05:41] <lifeless> crypt-0: so, have you done a merge of the packages yet ?
[05:41] <lifeless> crypt-0: if not, the wiki has good docs on merges - you need to do a merge.
[05:43] <crypt-0> ok
[05:43] <crypt-0> i will get to it
[05:43] <lifeless> if you need pointers just shout
[05:50] <lucas> ScottK: yes, I'm planning to do a rebuild before the week-end, possibly earlier
[05:51] <ScottK> lucas: Excellent.
[05:51] <ScottK> lucas: I don't think I managed to reply to your mail for feedback, but I've found your rebuilds very useful.
[05:52] <ScottK> lucas: Most particularly one case where I fixed a FTBFS that was caused by a problem in a library the package used and I was ably to use the symptom information you provide to find all the other affected packages.
[06:49] <pitti> Good morning
[06:50]  * mneptok hugs pitti
[06:51] <pitti> kirkland: I'm around now
[06:51]  * pitti hugs back mneptok; how are you? found some Easter eggs?
[06:51] <mneptok> pitti: i tried looking for them, but the wife said a scalpel near her abdomen made her nervous, and said to stop. :(
[06:52] <pitti> that sounds a bit early in the processing chain indeed!
[06:52] <mneptok> oh SURE! take HER side!
[06:52]  * mneptok pouts
[06:52] <lifeless> mneptok: you forgot the ether
[06:54] <mneptok> lifeless: we're in a recession. times are tough. i had to stop the ether and switch to "mallet."
[06:54] <mneptok> brb ... police coming through the windows.
[08:17] <dholbach> good morning
[08:19] <persia> jpds: lifeless indicated you had some interesting data sets available to test lmirror.  Please let me know what I might pull that would provide useful information.
[08:26] <lifeless> persia: we're not quite ready for that; pending some machine setup
[08:27] <persia> Oh well.  rsync is is then.
[08:30] <zyga-nc10> hello, anyone affiliated with couchdb around?
[08:34] <zyga> mvo: hello
[08:34] <zyga> mvo: anything I can help you with today?
[08:39] <sladen> oh I fucking hate quilt
[08:40] <maco> sladen: pssst language
[08:40] <mvo> zyga: hello! bug #549011 (probably pretty trivial, but it would be nice to refactor a little bit around it if needed)
[08:40] <maco> sladen: also, hello :)
[08:40] <mvo> sladen: try edit-patch instead
[08:40] <mvo> hey sladen and maco
[08:40] <maco> hi mvo
[08:40] <dholbach> sladen: ubuntu-dev-tools package
[08:41] <mvo> zyga: bug #437709 is fixed I think, but confirmation would be cool
[08:43] <mvo> zyga: and bug #540790 not sure what the best way forward is here, probably to offer a "reload" or "ignore"
[08:44] <zyga> mvo: could you please assign those bugs to me, it'd be easier to track if that's okay with yu
[08:44] <mvo> zyga: sure, thanks!
[08:45] <zyga> mvo: are you aware of the bug that software-center is not usable via keyboard (it's doing synchronous ops on keyboard up-down nav)
[08:45] <zyga> mvo: thanks, I'm checking my bugs now
[08:46] <mvo> zyga: what bit in particular does not work with keyboard?
[08:46] <zyga> mvo: try it, the app quickly hangs (turns gray on compiz)
[08:46] <zyga> mvo: it's probably doing something synchronously and it takes ages
[08:47] <zyga> mvo: just try moving down the list with keyboard
[08:47] <mvo> zyga: ok, so in the software-list?
[08:47] <mvo> zyga: the long listview?
[08:47] <zyga> mmm, yes I think so (if I understand you correctly)
[08:48] <zyga> I can reproduce this each time
[08:48] <zyga> from the initial screen, just scroll down with the arrow key
[08:49] <mvo> zyga: into any paricular category? or just scrolling around in the welcome screen?
[08:49] <zyga> mvo: this is reproducible in each screen, the welcome screen will do
[08:50] <zyga> mvo: I didn't dig through the code yet, I could be wrong on the cause
[08:50] <zyga> mvo: maybe it's the resize of each list item that occurs
[08:51] <mvo> zyga: hm, I can reproduce it when going into "System", not not otherwise
[08:52] <zyga> mvo: my system is slower probably
[08:52] <zyga> mvo: I could record a video and show it to you if you'd like
[08:53] <mvo> zyga: that would be nice
[08:53] <zyga> mvo: in progress, just a moment
[08:54] <zyga> mvo: if you are aware of this problem and know LP # then I'll attach the video there
[08:55] <tkamppeter> pitti, hi
[09:02] <zyga> mvo: I have the video, any place to upload this?
[09:03] <mvo> zyga: I don't have a open bug for this yet, please just open one :)
[09:04] <zyga> ok, moment please
[09:08] <pitti> hi tkamppeter, how are you?
[09:11] <zyga> mvo: #556290
[09:11] <zyga> mvo: istanbul sucks, the video stopped after 20 seconds or so
[09:22] <zyga> mvo:  got it
[09:22] <zyga> mvo: uploading
[09:24] <zyga> mvo: video attached, http://launchpadlibrarian.net/43226843/software-center-unresponsive-with-keyboard-navigation.ogg
[09:25] <mvo> zyga: thanks, its a wee bit small, but I can see the problem I think
[09:26] <zyga> mvo: in the future I think I will be able to capture video off-system
[09:26] <zyga> mvo: but for the moment in-system solution will have to do
[09:27] <zyga> mvo: basically I think the list should be smooth no matter how you navigate - can we make the buttons and other stuff overlay the list item without reflowing/resizing all other items?
[09:28] <mvo> zyga: its not trivial, the gtktreeview does not work well with non-fixed heights like this
[09:29] <mvo> zyga: we had a apply some trickery to make it somewhat fast (a special property)
[09:29] <mvo> zyga: see bug #514879
[09:30] <zyga> mvo: how about we make the view fixed height
[09:30] <zyga> mvo: and then show a overlay window that has the details when you navigate or click
[09:30] <zyga> (focus)
[09:32] <mvo> zyga: interessting idea! if it overlays part of the row below you need to discuss that with mpt if that is ok with him, we have almost fixed-height performance, I wonder if the freeze bug comes from something else, some missing optimization in the way we use the treeview
[09:32] <zyga> mvo: I'll try to poke around, you are right - the first thing is to understand what's slow
[09:33] <tkamppeter> pitti, fine
[09:33] <zyga> mvo: is it possible that there is something downloaded/read from file/ in a non-async way when you focus?
[09:33] <zyga> mpt: what do you think about this?
[09:34] <tkamppeter> pitti, there are still complaints going around that CUPS does not start on boot/stop on shutdown.
[09:34] <pitti> tkamppeter: start on boot, too? that's totally independent from stopping on shutdown
[09:35] <zyga> mvo: what's the proper branch for hacking lp:software-center?
[09:35] <zyga> or some lucid-specific branch?
[09:38] <tkamppeter> pitti, no I have found the bug where there appeared a comment on the weekend: bug 497299, but now I see that the complaint is about Karmic, not Lucid.
[09:38] <pitti> right, that's not cups specific
[09:38] <tkamppeter> pitti, and it is CUPS startup.
[09:40] <mvo> zyga: lp:software-center is the right one
[09:41] <mvo> zyga: if you run it with --debug you should get a lot of info
[09:41] <mvo> zyga: its doing a lot of stuff async :/
[09:41] <zyga> mvo: thanks
[09:41] <mvo> zyga: biggest is probably apt cache reading
[09:41] <zyga> mvo: python softwarecenter/view/appview.py
[09:41] <tkamppeter> pitti, CUPS not shutting down I do not find in the moment, there was a bug report, but I do not know what got down about it.
[09:41] <zyga> if you run that
[09:42] <zyga> and move around
[09:42] <pitti> tkamppeter: I have a list of them, I'll triage them soon
[09:42] <pitti> tkamppeter: we can ignore those for now, I think
[09:42] <zyga> you can see that item view is changed slightly even though nothing visible is changed
[09:43] <mvo> zyga: good idea to test it in isolation - is that freezing for you as well?
[09:44] <zyga> mvo: yes, search for 'x' and scroll away
[09:44] <zyga> mvo: that's good actually :-)
[09:45] <zyga> ExecutionTime, neat
[09:46] <mvo> yeah, I use that all the time :)
[09:49] <mvo> geser: do you plan other ubuntu-dev-tools upload after beta-2 ? I just applied a fix for the bug that sladen had with edit-patch
[09:50] <tkamppeter> pitti, I have also committed a small (trivial) fix to the CUPS BZR repo, to eliminate a warning in error_log. Can you upload CUPS before release? Thanks.
[09:50] <pitti> tkamppeter: yes, of course; I also committed an updated security fix, I'll do an upload right after beta-2
[09:50] <pitti> it'll be well in time for final
[09:50] <tkamppeter> pitti, and also what about taking in the 1.4.3 bug fix release of CUPS?
[09:51] <pitti> tkamppeter: if you can test it, please feel free to commit
[09:51] <persia> mvo: There is almost always a last-possible-moment upload of u-d-t for changing defaults lucid/maverick, but upload earlier if you ave good bugfixes.
[09:52] <tkamppeter> pitti, I do not have much time for testing, the OpenPrinting Summit is next week.
[09:53] <zyga> mvo: strange, if I scroll around I get http://pastebin.ubuntu.com/409920/
[09:53] <mvo> persia: cool, thanks
[09:53] <mvo> zyga: its probably a artifact of it running in isolation, I can have a look
[09:54] <zyga> mvo: it doesn't happen all the time, just if you move around fast
[09:54] <geser> mvo: yes, I plan to do at least one upload.
[09:54] <zyga> timing?
[09:54] <mvo> zyga: I guess
[09:54] <mvo> geser: cool, thanks
[10:00] <zyga> mvo: I added a logger to CellRendererAppView.draw and it keeps logging activity when I drag the window
[10:00] <zyga> mvo: maybe we can save some time with double-buffering?
[10:03] <mvo> zyga: good idea
[10:03] <zyga> mvo: do you know how to enable this on a widget tree?
[10:06] <mvo> zyga: there is a gtk.Widget.set_double_buffered() call
[10:06] <mvo> zyga: but it should be default already
[10:06] <mvo> zyga: but maybe its not for some reason
[10:08] <zyga> mvo: I'll check this in a second, I found something strange with that Cache.ready and None on pango
[10:08] <zyga> mvo: I was moving up and down like crazy and I managed to make a ghost entry without any data inside, I have video
[10:10] <zyga> mvo: http://launchpadlibrarian.net/43229601/ghost-entry.ogg
[10:12] <zubin71> hello, has anyone here worked on iptables? id like some feedback for an idea i had. you can view the idea here at https://wiki.ubuntu.com/GoogleSoC2010/ZubinMithra. Thankx in advance.
[10:19] <zyga> mvo: setting double buffered view on AppView doesn't help
[10:20] <zyga> mvo: either the view always draws cells for some strange reason (on purpose) or it's another bug that prevents this from working
[10:21] <mvo> zyga: I would not be suprised if its a issue with gtktreeview, I saw a lot of drawing in my custom models. I don't know if its a bug in the treeview or in the custom models, but I suspect the former
[10:22] <zyga> mvo: do we have gtk hackers to give us a hand in this?
[10:22] <zyga> mvo: the UI is really slow because of this
[10:22] <zyga> even on core i7 which is insane IMO
[10:24] <mvo> zyga: bratsche is the first who comes into my mind, gimpnet and #gtk+ is probably a good place
[10:36] <TrueTom> does anyone know if 'acpid' is still used for handling events like opening/closing a notebook lid?
[10:38] <pitti> TrueTom: only if gnome-power-manager/the KDE pendant aren't running
[10:39] <pitti> TrueTom: but not for lid closing, only for the power button
[10:41] <zyga> mvo: I managed to remove the slowdown by dropping other columns
[10:41] <zyga> mvo: interesting thing is that the Cache.ready issue is clearly reproducible so it's a separate problem
[10:41] <TrueTom> pitti: so is gnome-power-manager responsible for disabling the backlight of the screen when I close the lid?
[10:42] <pitti> TrueTom: no, it just tells the kernel to suspend, and the kernel does the rest
[10:43] <pitti> TrueTom: oh, if you disabled suspend-on-lid-close, it's gnome-power-manager, yes
[10:47] <zyga> mvo: can you please try to do one thing for me: run python softwarecenter/view/appview.py
[10:47] <TrueTom> pitti: how does gnome-power-manager know the lid is closed? its homepage states that it doesn't use pmud/acpid/apmd anymore but HAL (which isn't used in Ubuntu anymore!?)
[10:47] <zyga> mvo:  and attempt to write "nethack", quickly
[10:48] <pitti> TrueTom: closing/opening the lid produces an input event now (SW_LID)
[10:48] <zyga> mvo: do you get "ehakctn" too?
[10:48] <pitti> TrueTom: so it just needs to listen to that X event
[10:51] <TrueTom> pitti: ah, didn't know that, thanks... i will test if that works... also, acpi_listen shows that there is no event generated when I close my lid but two when i open it... this seems broken but that isn't a problem since nothing is still using acpi anymore?
[10:52] <pitti> TrueTom: that sounds broken, indeed, hm; is the first event after lid opening the "close" event?
[10:52] <pitti> TrueTom: does the machine suspend in between?
[10:52] <mvo> zyga: yes
[10:52] <mvo> zyga: but only in that mode
[10:52] <mvo> zyga: no in s-c itself
[10:55] <TrueTom> pitti: i don't know... i couldn't find out how to parse the output from acpi_listen, however the output is the same for both events (minus the event counter)
[10:55] <TrueTom> pitti: the machine doesn't suspend (which works fine though)
[10:56] <TrueTom> pitti: the problem is that closing the lid doesn't disable the backlight but opening the lid again does
[10:56] <pitti> TrueTom: these effects sound related
[10:56] <TrueTom> pitti: then the backlight stays off and i have to reboot
[10:56] <TrueTom> pitti: yes, hence my question
[10:57] <pitti> I suppose it gets the "lid close" event only after opening
[11:00] <TrueTom> pitti: i agree... but eventually this is a problem with ACPI in the kernel?
[11:04] <pitti> TrueTom: right
[11:06] <TrueTom> pitti: ok, thanks... then i'm going to have to compile a kernel with acpi_debug=y... see you all in a few hours... ;)
[11:28] <zyga> mvo: I have some improved monitoring
[11:29] <zyga> mvo: it shows where execution time of nested ExecutionTime object exceeds given threshold, by default 1.0/24 seconds
[11:29] <zyga> mvo: it's quite easy to spot the slow part now
[11:48] <free> mvo: hey! just wanted to let you know that the hardy->lucid upgrade problem the other day was a transient one
[11:48] <doko_> crimsun: just make it a depends. ubuntu always did ship the files in /usr/lib32, not in /emul
[11:48] <free> mvo: I tried the day after and it worked
[11:50] <free> mvo: now I have another problem though, dapper->hardy using the official Dapper AMI, https://pastebin.canonical.com/30087/ (seems a dependency issue as well)
[12:07] <free> interesting mail from sg
[12:07] <free> oops wrong channel :)
[12:13] <sladen> seb128: https://bugs.launchpad.net/ubuntu/+bug/554652/+subscribe
[12:14] <sladen> seb128: bug trackers are for tracking, bugs...
[12:26] <seb128> sladen, right, but opening lot of tasks on one bug does spam everybody
[12:26] <seb128> the people subscribed to any of the component get emailed for change to any of the components they don't care about in those cases
[12:26] <seb128> which still happens when the task you care about is closed
[12:27] <seb128> ie you might fix the bug on your component and still get spammed for years
[12:27] <seb128> you should open a bug for each component
[12:27] <bluefoxicy> damnit why the hell does gtkpod and rhythmbox both crash on karmic
[12:27] <bluefoxicy> a lot.
[12:28]  * bluefoxicy considers an early upgrade to lucid but he hears it's excessively broken at the moment....
[12:29] <persia> bluefoxicy: Shouldn't be excessively broken.  We're in freeze for beta2 : if you know of some specific source of excessive brokenness, please share.
[12:54] <zyga> mvo: another issue, sorting application list can take long time
[12:55] <zyga> mvo: just click on the "provided by ubuntu" view
[13:19] <mvo> zyga: executiontime> cool, is that in a branch somewhere?
[13:19] <mvo> free: aha, happy to hear that
[13:19] <mvo> zyga: I'm not sure how much we can do at this point to improve sort performance, but we definitely need to keep the UI alive
[13:20] <Riddell> shtylman, ev: waa, manual partitioner doesn't work on ubiquity kde_ui
[13:20] <Riddell> shtylman, ev: partman_edit_dialog() doesn't get past if not self.ctrlr.allowed_change_step()
[13:25] <zyga> mvo: not yet, I tried improving that with python-profiler, I can pass it to You if you want
[13:26] <zyga> mvo: this app needs backend vs frontend rewrite and separation and _async_ stuff all over the place :-(
[13:28] <free> mvo: yeah, any clue about the dapper problem?
[13:29] <mvo> zyga: it certainly needs improvements, but some of this is really hard to fix, e.g. the treeview performance
[13:29] <zyga> mvo: yeah I realize that
[13:29] <zyga> mvo: I wonder if we could -kind-of- get away with several issues by introducing... pagination
[13:30] <mvo> zyga: for the treeview? we have a branch for this if you want to play with it
[13:30] <zyga> mvo: mmm, cool, why isn't it integrated?
[13:30] <zyga> not finished?
[13:30] <mvo> zyga:  lp:~mmcg069/software-center/fastappview-kinda-working
[13:30] <cjwatson> Riddell: whatever the bug is, that's not it.  gtk has the same code and it's necessary
[13:30] <mvo> zyga: well, it will not behave exactly like the treeview and we still ran into performance issues
[13:31] <mvo> zyga: I had hoped that the ubuntu-almost-fixed-height mode patch for gtk would make the problem go away
[13:31] <cjwatson> I wish that the GTK and KDE partman components in ubiquity weren't so unnecessarily divergent
[13:31] <mvo> zyga: but apparently not enough
[13:31] <zyga> mvo: I fear that the problem is much more complicated and is actually a bag of issues that all add up
[13:32] <mvo> zyga: ok
[13:32] <zyga> mvo: is XAPIAN_VALUE_APPNAME guaranteed to be nonempty?
[13:32] <zyga> as in the actual value there
[13:33] <mvo> zyga: no
[13:33] <zyga> oh, okay, that explains it
[13:33] <mvo> zyga: if its there it should be non-empty
[13:33] <mvo> zyga: so ideally the database/update.py would not write it, but I don't think its (currently) enforced
[13:33] <ev> Riddell: looking into it now
[13:34] <zyga> mvo: so that's the preferred solution? not writing entries without app name?
[13:35] <mvo> zyga: let me check the code. is it causing the problem with the empty rows you showed me earlier?
[13:35] <zyga> mvo: no, I'm currently fixing #549011
[13:36] <zyga> mvo: one step at a time I guess
[13:36] <mvo> :)
[13:36] <mvo> sure
[13:37] <mvo> zyga: aha, I think in this particular case the problem is that we use two databases, the app-install-data one and the apt-xapian-index one. only the former has this value set
[13:37] <mvo> zyga: if the package comes from the later we simply need to use the pkgname
[13:37] <zyga> mvo: hum, okay that's easy to fix I guess
[13:38] <mvo> yes
[13:38] <zyga> mvo: I think the architecture could be easier though ;-)
[13:38] <mvo> and it should be :)
[13:38] <zyga> anyway, let's do it one-at-a-time
[13:38] <mvo> feel free to apply medium levels of re-factor
[13:39] <zyga> mvo: I don't want to target lucid but +1 is very sensible
[13:39] <zyga> mvo: remember I wanted to fix some stuff earlier but didn't get permission from my employer
[13:40] <zyga>  mvo: bzr ci -m "...; Fixes LP #number", right?
[13:41] <mvo> zyga: I do remember that, the branch looked very promising
[13:41] <mvo> zyga: you can also just edit debian/changelog and then run "debcommit"
[13:41] <zyga> wow, thanks
[13:41] <zyga> never knew that one
[13:42] <zyga> mvo: UNRELEASED or lucid (I did dch -i)
[13:45] <zyga> mvo: http://pastebin.ubuntu.com/410015/
[13:46] <mvo> zyga: thanks, please just add your entry under the current "UNRELEASED" one with [ Zygmunt Krynicki  ]
[13:46] <zyga> ok
[13:46] <zyga> cool, done
[13:52] <mvo> free: sorry, what dapper problem was that
[13:52] <free> mvo: I have a problem with dapper->hardy using the official Dapper AMI, https://pastebin.canonical.com/30087/ (seems a dependency issue as well)
[13:52] <free>
[13:53] <free> mvo: I think it was fine up to some time a go (though it's the first time I use the Dapper AMI for that, I usually use kvm locally)
[13:54] <pecisk> hi people, I can't get Lucid loaded from LVM, Grub2 complains about not having proper device to load from (aka /dev/mapper/System missing)
[13:54] <pecisk> fresh install
[13:54] <pecisk> is there any known issues about this?
[13:55] <cjwatson> pecisk: should have been fixed a while back.  are you attempting to install beta-1, or a daily build, or what?
[13:55] <pecisk> it was installed in 26th March
[13:55] <cjwatson> date is not important; installed from what image?
[13:56] <pecisk> from daily of that day
[13:56] <cjwatson> that's odd since I believed I'd fixed those problems on 22 March
[13:56] <cjwatson> in any case, you might try a daily build
[13:56] <pecisk> server daily
[13:57] <pecisk> cjwatson: sorry, Empathy crash
[13:58] <pecisk> cjwatson: server daily from 26th or 25th, not quite sure
[13:58] <bdrung> bryce_: do we need a FFe for the 6.13.0 version of ati driver?
[13:58] <cjwatson> pecisk: hm.  do you have logs?
[13:58] <directhex> this is the driver which works on 5000-series cards, yes?
[13:58] <cjwatson> pecisk: and do you mean that it fails on trying to install that image *now*, or that it fails on trying to upgrade a system originally installed from that image?
[13:58] <mvo> free: uh, I think I need to investigate that a bit more, but could you check if it has ubuntu-minimal and ubuntu-standard installed?
[13:59] <free> mvo: both installed
[13:59]  * mvo scratches head
[14:00] <free> mvo: if you want I can grant you access to the machine
[14:00] <free> mvo: it's still running
[14:02] <mvo> free: that would be nice but I doubt I will manage to work on it today :/
[14:03] <free> mvo: okay, it should be pretty easy to reproduce, please could you ping me some time this week when you have time to give it a look? I can fire an instance
[14:09] <m4rtin> hi, I've subscribed ubuntu-sponsors-main to 2 bugfix patches for regressions in bash completion. Do I have to do anything else to get them reviewed?
[14:10] <chrisccoulson> superm1 - just looking at bug 525621, do you not have xulrunner-1.9.2 on your upgraded system?
[14:18] <bdrung> m4rtin: subscribe ubuntu-sponsor (instead of ubuntu-main-sponsors) if you have a debdiff. if you only have a patch, subscribe ubuntu-reviewers.
[14:19] <persia> If you have both, and you're far too lazy to submit upstream, subscribe both, but be prepared to wait :)
[14:32] <cr3> is it new that multi-card readers are appearing as a device, /dev/sdb for example, even when there's no card? I thought they only appeared as a device when a card was inserted
[14:35] <persia> cr3: It depends on the implementation of the reader.  It's not new, although the balance mayhave shifted.
[14:35] <persia> (hardware implementation)
[14:41] <cr3> persia: I find it strange that the reader is reported as a block device when I'm not sure it really is when there's no card
[14:42] <pitti> mdz, cjwatson: is TB in 20 minutes or 80? is it UTC or Northern-hemisphere based?
[14:42] <persia> cr3: Unless something significant changed since I was troubleshooting issues with a card reader that required *reboot* to switch cards a while back, the issue is how the hardware handles stuff.  By indicating there *is* a device there, even when it's not attached, it can handle switching for broken hardware better.
[14:43] <SandGorgon> does anybody know how to debug ubiquity - do I have to pass "debug=" flag to the boot parameters of the livecd and then run "ubiquity -d".. I am not clear on this part
[14:44] <cr3> persia: I can appreciate that since there is indeed a card reader, then it makes sense to have it represented as a device
[14:44] <mdz> pitti: I have it on my calendar in 15m
[14:44] <cr3> persia: does that mean that it's possible for the drive in a system to sometimes be reported as sda and the card reader as sdb, and vice versa?
[14:45] <persia> SandGorgon: https://wiki.ubuntu.com/DebuggingUbiquity
[14:45] <persia> cr3: Sure.  That's why we like UUIDs
[14:46] <cr3> persia: hm, that might be a pickle for the installation process where the alternate images seem to detect the card reader as sda
[14:46] <SandGorgon> persia, I read that... I even read https://wiki.ubuntu.com/Installer/FAQ#How do I debug the installer?   I'm confused on what boot parameters to give.. or where should I  run "ubiquity -d" from ? IS it the boot menu of the livecd ?
[14:47] <persia> SandGorgon: I usually run it from a terminal window in the live session.
[14:47] <m4rtin> persia: it's nothing to do with laziness -- as I explained in MOTU chan; it's a matter of getting it fixed for Lucid -- waiting for upstream to release would be a prohibitive timescale
[14:49] <superm1> chrisccoulson, i dont recall.  that system had some other (worse) upgrade bugs that required a lot of manual interaction at the time of the upgrade
[14:49] <persia> m4rtin: My apologies if my comment was interpreted incorrectly.  Most of the sponsors request that a patch has at least been submitted upstream (if it applies upstream) before sponsoring.  The Reviewers team will do this for you if you don't do it directly, but this can take a while, because of the backlog.
[14:50] <persia> I didn't mean to imply *you* were lazy, but that if you happened to feel that way, you could take the route that took longer.
[14:52] <m4rtin> persia: ok, sorry; didn't mean to jump at you either! Is it worth me putting a note on the report? (It's fixed upstream in version control, but they are not going to release in time and have not done so for a long while)
[14:52] <persia> It is definitely worth noting that in the report.
[14:52] <SandGorgon> persia, my problem is that the live session doesnt boot up for me.. it hangs and that's what I'm trying to debug. Is there a way to hit the terminal window right at the menu ("Install Ubuntu", "Try Ubuntu without trying", etc.)
[14:52] <persia> SandGorgon: I think you have to pass special boot args for that, to stop before starting all the way, but it's beyond my immediate knowledge.  Sorry.
[14:53] <SandGorgon> persia, thanks... I'll try to find it
[14:54] <nigelbabu> m4rtin, if upstream fixes it in their git/svn, that is enough for us to ok to get into ubuntu
[14:55] <persia> Well, no.  Getting it upstream and getting it into Ubuntu are entirely separate, but the path is certainly made smoother for getting it in Ubuntu when it's accepted upstream.
[14:56] <m4rtin> persia and nigelbabu: the functionality is fixed in upstream repos, but they have majorly rewritten components, so it is not fixed in the same way. My fix is a single line change to the latest *stable* codebase (which is synced for Lucid) to give the same functionality; is that acceptable?
[14:56] <persia> Usually.  Depends on the sponsor to a degree.
[14:57] <nigelbabu> can't give a blanket yes/no.  its a grey area.
[14:58] <m4rtin> the short answer is that a future sync from upstream will not cause a regression, but this fixes it for the LTS release
[14:58] <cjwatson> SandGorgon: https://wiki.ubuntu.com/DebuggingCasper may help; hangs may well be before ubiquity even starts
[14:58] <m4rtin> well, I guess we'll see
[15:00] <SandGorgon> cjwatson, very possible - my bug is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/539086 Let me try it
[15:13] <MacSlow> seb128, for fixing the non-composite case of LP: #546650... do you want the full tarball or rather a diff/patch against notify-osd-0.9.27-0ubuntu3 ?
[15:13] <MacSlow> seb128, I sadly have no good news regarding the rb-cover-art issue... :/
[15:14] <MacSlow> seb128, still wasn't able to get around that bug.
[15:14] <seb128> MacSlow, I would prefer a tarball fixing the rhythmbox issue too
[15:14] <seb128> MacSlow, did you figure what the issue is? I think you said something about image ids the other day
[15:15] <MacSlow> seb128, it is an inconsistency between image_data hint and normal icon passing... but what's causing that inconsistency I couldn't pin-point yet
[15:16] <seb128> MacSlow, ok, no need to bother rolling tarball or sending patches for now, I can backport the revision easily
[15:16] <seb128> MacSlow, just focus on finding what cause the inconsistency between image_data and icons
[15:16] <MacSlow> seb128, just grab from lp:notify-osd/lucid
[15:17] <seb128> MacSlow, right, I did that some days ago, I've it locally but we are frozen for beta2 now
[15:19] <MacSlow> seb128, I pushed the change/fix for LP: #546660 5 days ago... so you should be good
[15:20] <seb128> MacSlow, yes, it's all good, thank you
[15:29] <pitti> persia: what went wrong with SDL? I didn't follow that, I think
[15:31] <persia> pitti: The version we have works with some software in our archive, and breaks others.  Going back to the older version has the same effect.  There are upstream bugs about the regression, but we happened to catch a bad combination of pulls from experiemental whist people were paying attention to RCbugs in testing.
[15:31] <persia> With unstable, we tend to be more careful about syncs, which tends to avoid some of this.
[15:31] <persia> Anyway, I agree that this probably needs wider debate and review, rather than being on-topic for the meeting (or even random IRC chatter).
[15:32] <pitti> persia: hm, I don't understand -- if we pulled from experimental, this seems to be the opposite of what we generally wanted to achieve by pulling from testing?
[15:33] <persia> Yes, but we often pull several packages from experimental, which has lower risk in some ways when pulling unstable, because there's no chance of weeks-to-months lag in getting packages into testing.
[15:33] <persia> This is a particular abberrant case, but in general, I think we need to ensure there is clearer guidance to developers, etc.
[15:34] <pitti> persia: hm, my memory seems to be different wrt. "more careful"; they generally are done by the archive admins without a lot of questioning
[15:35] <persia> pitti: Well, the archive-admin view is a peculiar one, as it's mostly administrative.  I mean in terms of developers requesting the syncs.
[15:35] <pitti> right
[15:35] <persia> I don't expect the archive-admins to ask questions, but I think that the developers may have a different view of risk when pulling from unstable or testing (whether merge or sync: doesn't matter).
[15:37] <persia> And since testing can hang indefinitely for some package, the risk of pulling from experimental is much higher than when the default source is unstable, given potential time delays, transition lags, etc.
[15:51] <apw> Keybuk, am i expecting to see plymouth before fsck or always afterwards
[15:51] <Keybuk> apw: how do you mean?
[15:51] <apw> i always see fsck from util-linux-ng flash up, then plymouth appears over it
[15:52] <apw> and in this case its said that, that its doing an fsck, and plymouth has not yet appeared
[15:52] <apw> so i have no option to 'S' it
[15:52] <apw> and it takes an hour ...
[15:54] <mvo> Keybuk: re bug #543580 - can you think of any reason why friendly-recovery would be on the wrong vt and something eats up "ENTER" ? it smells a bit like plymouth has not exited/given up control yet.
[15:54] <psusi> wow... that's a long fsck... you using ext2 or something?  a modern ext4 fs should not take that long to fsck, even if it's very large
[15:54] <apw> Keybuk, all that on an HDD basedmachine
[15:54] <Keybuk> apw: that sounds like plymouth or initramfs-tools is out of date - you should never see the fsck messages
[15:54] <apw> hrm
[15:55] <apw> Keybuk, ok thanks, i'll update _again_ when its done
[15:55] <apw> i must migrate to ext4
[15:55] <Keybuk> mvo: could be bug #551263 - though I can't replicate that
[15:55] <mvo> Keybuk: I can replicate it here, maybe its nvidia releated? I got a nvidia in that machine
[15:55] <mvo> Keybuk: thanks, I check the bug
[15:57] <psusi> oh yea... I forgot about that... I need to file and run down a bug on mke2fs... the man page says it defaults to -E lazy_itable_init=1, but it doesn't... setting this option significantly speeds up mkfs on large disks... also fscking them afterwards
[16:14] <psusi> WD's new 4kb sector drives lie about their sector size reporting 512 bytes when in fact, they are 4kb... would it be possible to override the kernel detected sector size and set it to 4kb?  it seems that the files in /sys that report the size are read only which is a problem, but even if they weren't, what package would be responsible for handling this quirk?  udev?
[16:14] <cjwatson> psusi: how much does it matter given that parted now defaults to 1MiB alignment in such cases?
[16:15] <cjwatson> psusi: there's similar code elsewhere (e.g. fdisk) which could be borrowed
[16:15] <psusi> cjwatson: seems to default to cylinder alignment still to me
[16:15] <cjwatson> psusi: well, not in the installer
[16:15] <cjwatson> and with the parted command line, parted 2.2 should default to optimal alignment across the board
[16:15] <cjwatson> psusi: is this a USB enclosure, or SATA?  my understanding is that it's only USB that acts that way
[16:16] <cjwatson> and that's because usb-storage forces use of the SPC-2 protocol even if the disk advertises better
[16:16] <psusi> it seems to read a few parameters from /sys to decide on alignment, but these parameters are all either 0 or 512 bytes, so when I use parted it seems to still use cylinder alignment since the kernel isn't telling it to use 4kb
[16:16] <psusi> nope, sata
[16:17] <psusi> right, but what is "optimal" alignment?  it seems to base that on the optimal parameter in sysfs, which is 0
[16:18] <psusi> and the drive reports to hdparm -I that it uses 512 byte physical and logical sector size... it seems that if it correctly reported 4kb physical size then the sysfs parameters would indicate that to parted and it would align to 4kb but it doesn't...
[16:21] <cjwatson> psusi: not that simple - see http://git.debian.org/?p=parted/parted.git;a=blob;f=libparted/device.c;h=64da97868ab4e1209906f268690a66f9b0a27c9f;hb=HEAD lines 518-552
[16:21] <cjwatson> your description of what's happening doesn't match my understanding of how parted works; if you're using parted 2.2, I would consider it a bug
[16:22] <cjwatson> it's reasonably well-known that many drives still report 512/512 even though that isn't true, so the 1MiB alignment in such cases is quite deliberate
[16:23]  * psusi looks for the architecture specific get_optimum_alignement()
[16:25] <psusi> hrm... yea, looks like the linux.c one returns NULL so the 1mb default should be used when optimal_io_size and and alignment_offset are 0
[16:26] <psusi> I'll have to test again tonight but I'm pretty sure I got a normal start on sector 63... a 1mb start position isn't ideal either though... would be nice if we could make optimal_io_size be 4kb and then parted would align to 4kb by default
[16:30] <cjwatson> psusi: there was extensive discussion on various upstream lists about it, this was the consensus
[16:30] <cjwatson> psusi: I think there was some concern about portability of disks - and frankly, who cares about a wasted megabyte these days
[16:30] <cjwatson> psusi: also, a 1mb start position is actually kind of nice for grub
[16:31] <cjwatson> so I'm inclined to leave it as-isi
[16:31] <cjwatson> *as-is
[16:32] <psusi> cjwatson: well, it would be nice if it used the extra space... I've been wondering about packing more into the grub core image when you have more than 32kb of space for it
[16:32] <psusi> cjwatson: I was looking over the grub code last night actually and it looked like grub-mkimage will error out if the image is larger than 64kb anyhow
[16:33] <cjwatson> sure, but it might be possible to put it further up to avoid those Windows problems
[16:33] <cjwatson> not that I've seen a definitive analysis of those yet
[16:33] <psusi> you mean like truecrypt wanting to also use the embed area?
[16:34] <psusi> probably best just to use GPT and create the explicit grub boot partition ;)
[16:36] <cjwatson> psusi: in some fantasy world where we can do that everywhere
[16:37]  * cjwatson not big on fantasy worlds :)
[16:37] <psusi> hehe
[16:37] <superm1> cjohnston, i copied the mythbuntu.lucid seed branch from ~mythbuntu to ~mythbuntu-dev.  I figured that -dev better reflects archive permissions and allows all core dev to change mythbuntu seeds.  what other parts of the archive need to be updated to reflect that too?
[16:37] <superm1> cjwatson, ^
[16:38] <cjwatson> it would be nice to get *advance* warning of that sort of thing :)
[16:38] <cjwatson> let me see
[16:38] <superm1> well it's just a copy, i didnt remove the old ones
[16:38] <cjwatson> there's a branch in people.u.c/~ubuntu-archive/ which needs to be re-pointed
[16:39] <cjwatson> superm1: could you do this copy for all the old seed branches as well so that we have consistency?
[16:39] <superm1> cjwatson, sure
[16:40] <cjwatson> cdimage needs a tweak
[16:40] <cjwatson> that's all I can think of; I can take care of all of it
[16:41] <superm1> cool thanks
[16:41] <superm1> i'll push those branches in a few minutes
[16:41] <cjwatson> the change is welcome, certainly
[16:41] <cjwatson> cdimage done
[16:56] <superm1> cjwatson, could you also merge https://code.edge.launchpad.net/~superm1/debian-cd/mythbuntu-improvements so we make sure that makes the beta2 candidates?
[17:06] <cjwatson> superm1: dodne
[17:06] <cjwatson> *done, even
[17:06] <bryce_> bdrung, probably
[17:21] <dholbach> jcastro, bdmurray: can you join #ubuntu-reviews
[17:21] <dholbach> please? :)
[17:22] <nigelb> bryce_, if you've got a few minutes to spare for #ubuntu-reviews, would be great :)
[17:22] <hyperair> hmm ubuntu's sprouted new dev channels
[17:22] <hyperair> it used to be just #ubuntu-motu and #ubuntu-devel
[17:22] <cjwatson> any reason reviews need to be separate, FWIW?
[17:22]  * hyperair shrugs
[17:23] <persia> cjwatson: Not really, it's been around for a while, and we're focusing on digging through the backlog of ignored patches in LP, and getting them upstream, etc.
[17:23] <nigelb> shrug.. it was that way when I came around
[17:23] <cjwatson> oh, that's right, I remember that channel has existed for a while now that you mention it
[17:23] <cjwatson> fair enough
[17:24] <persia> In many ways it would be nice to go back to fewer channels, but I feat they would all be too noisy.
[17:24] <hyperair> is there a list of dev channels?
[17:24] <persia> hyperair: I'm certain no complete one exists, as there's no wiki page that gets updated as part of the process of creating new ones.
[17:25] <hyperair> heh oh well =\
[17:32] <weenus> I'm having a problem compiling a program that was designed for one of the earlier kernels. I found a fix  for it but I don't know how to implement the fix. Could anyone tell me where to go for help on this?
[18:18] <mvo> Riddell: if someone from the kubuntu people could have a look at bug #556535 that would be nice
[18:24] <Riddell> mvo: can do
[18:25] <mvo> thanks
[18:36] <cjwatson> Riddell,shtylman: could one of you review lp:~amichai2/ubiquity/fixes for merging?  it looks fairly good to me, but I'm not really qualified to review the .ui changes
[18:36] <cjwatson> fixes a bunch of beta-2-targeted bugs
[18:37] <cjwatson> and it'd be good to suck him into the #ubuntu-installer cabal if he's sane :) I'll send him a message to that effect
[18:38] <cjwatson> it'll need a copyright assignment :-/
[18:46] <Riddell> cjwatson: yes he's generally a good guy, reviewing that branch is on my todo
[18:46] <cjwatson> Riddell: I've sent mail (via LP) asking for copyright assignment
[18:53] <jtimberman> I have a PPA with a build that finished 16 hours ago that is still not published, should I do a reupload w/ a new version?
[18:54] <Pici> jtimberman: Launchpad is having an issue with PPA publishing at the moment.
[18:54] <jtimberman> Pici: Alrighty.
[18:54] <jtimberman> Pici: Is there a ticket open for that?
[18:55] <Pici> jtimberman: I suppose the topic in #launchpad will be changed when its fixed.  I didn't see a bug # mentioned for it.
[18:55] <jtimberman> ah!
[18:55] <jtimberman> Thanks
[19:03] <bdrung> crimsun: i am not sure if bug #555891 is only a bug in pulseaudio. alsamixer does not show volume slider for every channel for example.
[19:08] <crimsun> bdrung: you stated that stereo is fine, yes?
[19:08] <crimsun> bdrung: right, it's possible there's also a linux component, but I don't have time to chase that currently. Feel free to add the task.
[19:09] <bdrung> crimsun: yes, stereo is fine.
[19:10] <bdrung> crimsun: if i remove pulseaudio and try to play a DVD with 5.1 directly through alsa, it should work, right? otherwise alsa is affected, right?
[19:11] <crimsun> bdrung: well, PA has a known issue with 4.1/5.1, so there's at least a PA task.
[19:11] <psusi> cjwatson: is there a reason that bug #88633 is still hanging around as confirmed/high?  it sounds like you have decided not to change things, so shouldn't be be marked wontfix?
[19:11] <crimsun> bdrung: I don't know what you mean by work. Do you mean "doesn't crackle" and/or "maps correctly"?
[19:12] <crimsun> bdrung: i.e., those are two totally separate bugs.
[19:12] <bdrung> crimsun: doesn't crackle + maps correctly.
[19:13] <bdrung> crimsun: i was unsure, if that are two different issue.
[19:13] <crimsun> yes, those are two different issues affecting possibly two different source packages.
[19:19] <cjwatson> psusi: it's one of those bugs that if I wontfix it somebody will reopen it or file it again, so it hardly seems worth bothering
[19:19] <cjwatson> psusi: and if I downgrade it, somebody will rant at me about why it isn't high
[19:20] <psusi> cjwatson: why would it be filed again?  don't wontix still show up in the default search?
[19:20] <cjwatson> not last I checked, it's a closed status
[19:20] <psusi> ack, that's broken
[19:20] <cjwatson> ICBW
[19:20] <cjwatson> but besides, most people don't necessarily know where installer bugs go
[19:21] <cjwatson> honestly, half the time explicitly wontfixing things is more trouble than it's worth
[19:21] <psusi> that's not good...  it should be used to get the bugs out of the "needs worked on" queue since they won't be worked on
[19:23] <cjwatson> I have bigger problems with my "needs worked on" list :)
[19:23] <cjwatson> sometimes optimising for fewest rants in my mailbox is the least energy-intensive way of working
[19:23] <YokoZar> What package does someone mean when they say "the pthread library" ?
[19:23] <YokoZar> I'm guessing not libpthread-stubs
[19:24] <cjwatson> might just be the one in eglibc
[19:24] <cjwatson> i.e. /lib/libpthread.so.0
[19:36] <YokoZar> cjwatson: Yeah, that seems to be what they were after.  Thanks :)
[19:37] <_UsUrPeR_> hey all. I am having some problems with sshfs and ACLs. When a user creates a file in their own directory, and moves it over to a common directory on the server, it maintains it's own group instead of being changed to the group belonging to the common directory. I am trying to figure out a way to change a file's group without having to resort to a cron job. Does anybody have any suggestions? Thus far I have tried sticky bits and ACL. Stick bits wor
[19:37] <_UsUrPeR_> k if the file is created in the directory, and ACLs don't seem to work at all with sshfs. Can anybody suggest anything to me?
[19:40] <nigelb> can someone please moderate my mail to -devel titled "Patch Day, May 5th 2010"
[19:41] <cjwatson> nigelb: done
[19:41] <nigelb> cjwatson, thank you :)
[19:43] <cjwatson> kees: FYI I moved bzr and bzrtools back to the supported-development-common seed - I don't see why we shouldn't offer 5y support on these given that they're Canonical products, and I definitely think that they should be in the core package set rather than in something like ubuntu-server which is where they ended up
[19:44] <cjwatson> (actually ['kubuntu', 'ubuntu-desktop', 'ubuntu-server', 'unr'])
[19:44] <kees> cjwatson: because they haul in a giant mess of deps :(
[19:44] <cjwatson> I think, honestly, that that's a problem we have to deal with
[19:45] <cjwatson> it doesn't seem *that* bad anyway - bzr, bzrtools, python-paramiko, python-crypto, python-configobj
[19:46] <kees> cjwatson: iirc, it hauls in all kinds of extensive GUI stuff, but I would need to recheck to be sure.
[19:46] <kees> (due to recommends)
[19:46] <cjwatson> that does not appear to be the case
[19:46] <kees> okay
[19:46] <cjwatson> bzr-gtk is a suggests
[19:46] <cjwatson> as is the rsvg/graphviz stuff in bzrtools
[19:46]  * kees goes to re-run the seed thingy
[19:48] <cjwatson> kees: also, can somebody on the security team tell me what to do with http://paste.ubuntu.com/410185/ ?
[19:49] <kees> jdstrand: can you advise on the clamav stuff for -updates ^^
[19:49] <cjwatson> (or indeed Just Do It, since jdstrand's an archive admin)
[19:51] <jdstrand> cjwatson: I got it
[19:52] <cjwatson> thanks
[19:56] <jdstrand> np, done
[19:56] <Keybuk> smoser: btw, I forgot to ask - did your cloud-without-an-initramfs problem go away?
[19:56] <smoser> well, yes it went away, but because we're bundling an initramfs
[19:57] <smoser> did you make a change that may have fixed that properly?
[19:57] <Keybuk> right, but if you switch that off, is it fixed?
[19:57] <Keybuk> yes, I think so
[19:57] <Keybuk> have been studying the effects of code that I got wrong pre-mountall 2.10
[19:57] <smoser> i can test it.  would an image built early this UTC morning have all needed pieces
[19:57] <smoser> http://uec-images.ubuntu.com/lucid/20100406/lucid-server-uec-amd64.manifest
[19:57] <Keybuk> and I think you could well end up in a situation where things got wedged
[19:57] <smoser> (that is manifest)
[19:57] <Keybuk> yes
[19:57] <Keybuk> absolutely
[19:58] <smoser> i'll try it. thanks.
[19:58] <Keybuk> (and in 2.10, you should not get wedged anymore)
[20:06] <lool> slangasek: valgrind/armel: that's news to me; lamont kicked the previous armel build manually because Launchpad had trouble picking up the P-a-s change
[20:07] <lool> lamont: ^ valgrind wasn't attempted on armel for no good reason; would you mind checking it out?
[20:07] <lool> lamont, slangasek: ^ thanks to you two
[20:13] <slangasek> lool: ltsp is in the same state, btw - http://people.canonical.com/~ubuntu-archive/testing/lucid_outdate.html
[20:13] <slangasek> (and likewise-open just FTBFS due to needing manual porting to each platform, bah)
[20:26] <ccheney> if an upload includes new source bits but not all of it is new (eg orig.tar.gz isn't but other tar.gz are) do you still use -sa ?
[20:28] <geser> a multiple tar.gz v3 source package? good question. when in doubt check which files the .changes file mentions
[20:29] <ccheney> geser: it looks like it even included the orig.tar.gz for some reason, without using -sa
[20:30]  * ccheney will see how that works after the freeze is lifted, heh
[20:31] <geser> dpkg-genchanges tries to guess if the .orig.tar.gz is to be included based on the version number (-sa/-sd are for overwrite this)
[20:32] <slangasek> NCommander: what's the trick to get jocote to give me a chroot?
[20:32] <NCommander> slangasek: dchroot -c lucid -q
[20:33] <slangasek> NCommander: and have you gotten a backtrace yet for this OOo segfault?
[20:33] <slangasek> ok
[20:36] <ccheney> slangasek: if it wasn't already clear it failed between 1:3.2.0-4ubuntu1 and 1:3.2.0-4ubuntu2 which is only a 6kb diff
[20:37] <slangasek> ccheney: yep
[20:37] <NCommander> slangasek: not yet. I don't have a board setup locally, and working on jocote is like pulling teeth, plus I'm not 100% convinced this isn't crappy hardware.
[20:42] <ccheney> NCommander: did the toolchain change between the dates when the build worked vs failed?
[20:43] <ccheney> NCommander: it seems to consistently fail now even on different buildds, so if its faulty hardware it seems to be consistently faulty? :)
[20:43] <ccheney> unless it was an issue of faulty hardware miscompiling that OOo then uses to build which caused it to consistently fail on various buildds
[20:44] <ccheney> er ...miscompiling other code that..
[20:50] <NCommander> ccheney: that's the other thought unfortnately. Its going to require some serious debugging to determine what the hell blew up
[20:50] <NCommander> ccheney: I'm greatly annoyed since we fixed OOo just for it to break again
[20:51] <NCommander> ccheney: BTW, I *really* like your use of 3.0 source packaging on OOo, I haven't seen a multi-tarball package before today
[20:57] <doko_> cjwatson, ev: would I break something in the installer if I explicitely check for a mounted /proc and error out in a maintainer script? java/keytool are the two ...
[21:08] <ccheney> NCommander: yea it helps me with uploads a lot :)
[21:09] <ccheney> NCommander: the debian bit is only a 2MB tarball now
[21:13] <NCommander> ccheney: nice
[21:35] <geser> @archive admins: does it cause a licensing problem if old debs are still published but their source got superseded (so no matching source anymore) by a new version which FTBFS or is stuck in DEPWAIT?
[21:35] <smoser> Keybuk, bug 531494 seems to be fixed
[21:45] <slangasek> NCommander: gar, what's this?: Stepping through Thumb-2 IT blocks is not yet supported
[21:45] <slangasek> NCommander: we don't have a gdb that works on Thumb-2?
[21:45] <NCommander> slangasek: ugh, that's the debugger not having full support for Thumb2
[21:46] <NCommander> slangasek: no, its more a newer feature in the compiler that we use to ease thumb2 porting
[21:46] <lee_> hmm
[21:46] <lee_> hello
[21:46] <slangasek> NCommander: well, that's what gdb tells me when I try to step through the code that's segfaulting: )
[21:46] <NCommander> dyfet: HELP!
[21:47] <dyfet> what did you break? ;)
[21:47] <NCommander> slangasek: thats odd, I *never* ran into that problem before, something must have really gone pearshaped
[21:47] <NCommander> dyfet: 16:44:55 < slangasek> NCommander: gar, what's this?: Stepping through  Thumb-2 IT blocks is not yet supported
[21:47] <dyfet> ohh....
[21:49] <NCommander> dyfet: care to shed some light on the situation?
[21:49] <lee_> who here knows python?
[21:49] <NCommander> dyfet: I thought the debugger supportred thumb2
[21:49] <dyfet> I thought so too...
[21:50] <dyfet> So I am now as concerned as you :)
[21:50] <NCommander> dyfet: something is telling me that this is related to the implicat-its we use in GCC
[21:50] <lee_> try python
[21:51] <bdrung> crimsun: i did some more test and can confirm that's bug  #88633 is only caused by pulseaudio.
[21:51] <slangasek> lee_: many people; if you have a specific question, you should probably just ask it
[21:51] <dyfet> what was being debugged?
[21:51] <slangasek> lee: (but bear in mind the note in the topic)
[21:51] <slangasek> dyfet: OOo
[21:51] <lee_> eh, nvm
[21:51] <dyfet> ohhh....I was afraid you would say that :)
[21:52] <bdrung> crimsun: wrong bug, it is bug 555891
[21:52] <NCommander> slangasek: we could build it -marm and hope the issue persists (OOo really benefits from thumb2 complication :-/)
[21:53] <NCommander> slangasek: actually, there's a GDB patch to add the necessary support
[21:53] <slangasek> NCommander: well, I can at least get a partial backtrace here; I'll continue working it from that angle
[21:55] <NCommander> slangasek: http://permalink.gmane.org/gmane.comp.gdb.patches/54862 - this may help, I'll see if I can get my imx51 board up since my dove is down until I get my PSU back from Lexington :-/
[21:55] <dyfet> That sounds like a long rebuild
[21:56] <dyfet> where did it fail?  Is it just in a library?
[22:03] <slangasek> dyfet: it's in libuno_cppu.so.3
[22:03] <dyfet> I just knew you would say uno....
[22:12] <NCommander> dyfet: its about two hours in
[22:12] <NCommander> dyfet: that's a separate module thats now broken -_-;;;;;
[22:12] <NCommander> Thats the part that generates C++ exceptions if memory serves
[22:12] <dyfet> yeah....
[22:13] <dyfet> what we have broken in mono, too...
[22:13] <cjwatson> doko_: I think that should be ok
[22:15] <NCommander> slangasek: I think the toolchain broke us unfortunately based off that. Might be worth doing a rebuild with -marm as a quick and dirty fix, if it works, we can leave it for the rest of lucid and start caring for maverick
[22:18] <dyfet> NCommander: Yes, lets try that first, to see if it works, then we can decide if we really want to do that for lucid and postpone solving it for maverick
[22:18] <NCommander> dyfet: ooh good, you up for building OOo? :-)
[22:18] <lee_> hmm
[22:18] <dyfet> Well, it's not my desire, but we need to see if at least that works
[22:21] <lee_> um, python's not working right on my computer
[22:21] <slangasek> dyfet, NCommander: for the sake of confirmation, where can I find a glossary for thumb2 asm?
[22:21] <lee_> can anyone help?
[22:21] <NCommander> slangasek: I usually use this guide: http://www.keil.com/support/man/docs/armasm/armasm_cihedhif.htm
[22:22] <NCommander> slangasek: if you need a more indepth explination of ARM Thumb2, there's the official reference guide but that's generally overkill
[22:22] <dyfet> slangasek: http://infocenter.arm.com/help/index.jsp
[22:23] <slangasek> I don't need anything indepth, I just need to confirm the semantics of 'strne' :)
[22:34]  * hyperair likes that quote from bryceh in nigelb's email =p
[22:34] <bryceh> heh
[22:34] <hyperair> heheheh
[23:52] <psusi> cjwatson, weird... I checked on the parted alignment thing again and if I specify the start as 0 or 0m, it warns that it is not aligned and creates it, if I specify 0% as the start, it aligns the start at 1mb.