[00:28] <personal> hi
[13:19] <cariveri> Hi. anyone there. I have got a question on a teach-server/pupil-clients setup using edubuntu.


[00:01] <poolie> done!
[00:02] <poolie> low latency fwt
[00:02] <poolie> ftw*
[00:11] <poolie> igc: i commented - what do you think?
[00:16] <igc> poolie: can you explain more?
[00:17] <poolie> it seems unfortunate to me that the tests would need to mutate and then restore a library-wide variable
[00:17] <poolie> as opposed to just changing their instance of the tree
[00:17] <poolie> maybe i'm massively confused?
[00:18] <poolie> or apparently you're relying on python looking up the name both instance-wide and class-wide?
[00:19] <poolie> that works, but we really discourage it
[00:19] <poolie> it can be confusing or fragile
[00:19] <igc> poolie: none of that is new. content-filters are registered library-wide and that was the easiest way to test them
[00:19] <poolie> i don't see anything else accessing WorkingTree._content_filter_stack
[00:19] <poolie> only on particular instances
[00:20] <igc> poolie: in testing, I need fine control over when filtering is on vs off
[00:21] <igc> poolie: from memory I need to patch in at the class level ...
[00:21] <igc> because the tree is implicitly created by branching
[00:22] <lifeless> igc: filters are registered, but what about being enabled?
[00:22] <lifeless> igc: I mean, say I have two WorkingTree instances
[00:22] <lifeless> surely they don't have the same filter stack
[00:22] <lifeless> if one tree has eol conversion enabled and the other doesn't
[00:23] <igc> lifeless: we don't have per tree filtering
[00:23] <lifeless> I thought that that was all we had
[00:23] <poolie> igc, so it's a bit weird and likely to break eventually
[00:23] <poolie> i think at least you should add a comment there
[00:24] <igc> lifeless: we only have global rules (much to my frustration)
[00:24] <poolie> but it's not new code, so you don't need to clean it up to land this
[00:24] <poolie> therefore +1
[00:24] <poolie> hth
[00:24] <igc> poolie: it does. I'll submit the next patch after this one lands
[00:26] <igc> poolie: can you update the review? I'll add the comment to the tests as requested
[00:31] <poolie> k
[00:52] <lifeless> james_w: around?
[00:54] <lifeless> igc: I must say I'm confused as to why we have global filters only; I was sure we had agreed on an initial locations.conf/bazaar.conf based setup - which doesn't imply global library state at all
[00:56] <igc> lifeless: it never got off the ground. I tried a patch along those lines and the design didn't hold up. I can't remember all the details now
[00:58] <lifeless> ok
[02:01] <jelmer> johnf: hi
[02:01] <johnf> jelmer: howdy. Did you see my bzr check question?
[02:02] <jelmer> johnf: no
[02:02] <johnf> one sec
[02:02] <johnf> johnf: anyone know if there is a solution to this problem when running bzr check "reason: Parent not in inventory." It is from a branch that was originally branched from SVN
[02:04] <johnf> jelmer: ^
[02:04] <jelmer> johnf: sorry, haven't seen that before
[02:05] <jelmer> johnf: can you reproduce this somhow with a fresh import?
[02:06] <johnf> jelmer: problem is we moved on from using SVN as a backend. I suppose I could import and then apply all patches since
[02:06] <jelmer> johnf: Does reconcile fix it perhaps?
[02:07] <johnf> let me try that
[02:08] <tedg> igc: So I can't get the svn-import to work.  How did you run the svn-import?  (what parameters)
[02:09] <tedg> igc: I've been figuring it was me, but I'm getting ready to blame bzr-svn :)
[02:09] <johnf> jelmer: nope http://pastie.org/672762
[02:10] <johnf> tedg: Initially I didn't do an import since we where backing onto svn. I branched it
[02:10] <igc> tedg: I can't remember. Let me try again and see if that jolts my memory ...
[02:11] <tedg> johnf: ?  I'm not sure what you're saying.  I'm trying to do an import.
[02:11] <arjenAU> ahoy oh gurus of bzr land, I come to you in a quest for enlightenment
[02:11] <johnf> tedg: sorry thought you where referring to my problem. Just ignoe me
[02:11] <arjenAU> oh hi igc
[02:12] <tedg> johnf: Ah, okay.  No problem :)
[02:12] <igc> hi arjenAU
[02:12] <arjenAU> so, I have a branch with 2 extra local revisions (committed) and 1 remote revision committed. so pull says branches have diverged. fine. so I merge from the remote branch and it says nothing to do. guh?
[02:12] <igc> tedg: I think I used bzr svn-import --all source dest
[02:13] <jelmer> johnf: You might want to do a clean import using a new version pof bzr-svn and then branch your new work into that
[02:13] <johnf> jelmer: sounds like a good idea
[02:13] <tedg> igc: Okay, let me try that.  I wasn't using --all, I thought you were grabbing one branch.
[02:13] <igc> tedg: which version of bzr abd bzr-svn do you have?
[02:13] <igc> and
[02:14] <igc> bzr plugins will tell you
[02:14] <igc> the bzr-svn version
[02:14] <johnf> arjenAU: what does bzr missing --theirs-only say?
[02:14] <tedg> igc: 1.0.0dev
[02:14] <jelmer> johnf: you'll want to use a new shared repository
[02:15] <arjenAU> johnf: that i'm missnig one rev.
[02:16] <johnf> arjenAU: does bzr status say you have merges pending?
[02:16] <arjenAU> nops
[02:16] <tedg> igc: That gets me to an exception: AssertionError: Unable to find direct lhs parent for <CachingRevisionMetadata for revision 7680, path tags/start/experimental ...
[02:16] <arjenAU> johnf: nop it seems cleanly committed on both ends, just diverged. so a merge should work I'd say.
[02:17] <johnf> arjenAU: ok if "bzr check" says everything is OK then I'm out of ideas and will hand over to a higher power :)
[02:17] <arjenAU> johnf: yep ok
[02:18] <igc> arjenAU: sounds weird ...
[02:18] <arjenAU> igc: hehe yea. running 2.0 on jaunty from ppa.
[02:19] <igc> arjenAU: here's what I'd do ...
[02:19] <arjenAU> igc: i possibly forgot something, just can't think of what. it look sfine just doesn't fly
[02:19] <arjenAU> ok listening
[02:19] <igc> grab a copy of the remote branch locally
[02:19] <igc> try merging from that copy into your branch
[02:19] <arjenAU> ahye and pull merge. ok
[02:22] <igc> arjenAU: I recall some weirdness ages ago where the branch had a change but the working tree wasn't refreshed
[02:22] <igc> so merge got confused and said nothing to do
[02:22] <arjenAU> nothing to do still...
[02:23] <arjenAU> should I try merging the other way?
[02:23] <igc> arjenAU: one way to ensure the tree is in sync with the branch is to 'bzr revert', assuming you have no local changes
[02:24] <arjenAU> well I do have local changes is the ponit
[02:24] <arjenAU> but not uncommitted
[02:24] <igc> revert is safe if your local changes are committed
[02:24] <lifeless> arjenAU: run 'bzr revision-info' in your local branch
[02:24] <lifeless> and with the url of youre remote branch
[02:25] <lifeless> also pastebin 'bzr info' for both branches
[02:25] <arjenAU> url of remote branch where?
[02:25] <arjenAU> revision-info doesn't accept the bzr+ssh syntax
[02:26] <tedg> igc: Okay, it seems that appending part of the svn path helps.  Then it's not looking for the odd repository layout from the CVS import.  It's coping revisions now.  Which means my lap is getting hot from the laptop :)
[02:27] <igc> tedg: :-)
[02:27] <tedg> Oh my, bzr is using 1.5GB of RAM...
[02:28] <igc> tedg: trunk has lots of memory improvements thanks to jam
[02:28] <igc> tedg: if required, you can convert using that (safely)
[02:29] <tedg> I might have to... we'll see.  I only have 2GB physical.  If it hits swap, it'll never finish :)
[02:30] <tedg> Nope.  Error'd out :(
[02:31] <tedg> Hmm, why don't errors generate crash files?
[02:31] <igc> tedg: if you throw the error in a bzr-svn bug report, jelmer is pretty good at solving them
[02:32] <tedg> I can't imagine this error is very useful: ERROR: Must end write group before releasing write lock on CHKInventoryRepository
[02:32] <tedg> Without even a backtrace.
[02:33] <tedg> That's all I got.
[02:33] <igc> tedg: if you run with -Derror, you should see a backtrace
[02:33] <igc> tedg: though it's surprising you didn't get one anyway
[02:34] <arjenAU> lifeless: revision-info doesn't accept the bzr+ssh syntax
[02:35] <fullermd> arjenAU: You'd have to use the '-d' arg.
[02:43] <arjenAU> lifeless: http://pastebin.org/48867
[02:44] <fullermd> arjenAU: What branch are you merging?
[02:45] <arjenAU> fullermd: remote into local
[02:45] <fullermd> Yeah, but what's 'remote'?
[02:45] <arjenAU> the one with the url
[02:45] <fullermd> There are two URLs, and they're different.
[02:45] <arjenAU> oh both
[02:45] <arjenAU> bother sorry
[02:45] <arjenAU> hang on
[02:46] <fullermd> Are you sure you're missing'ing the same branch you're merge'ing?
[02:46] <arjenAU> indeed apparently not.
[02:46] <tedg> igc: Not enough memory to get the backtrace.  Tried to upgrade to nightly, but now bzr-svn won't work because of API version issues.  :(
[02:47] <tedg> Why can't this information be encoded in to the packaging so that it's known at install?
[02:47] <tedg> It's really annoying that bazaar breaks even when apt is happy.
[02:47] <arjenAU> fullermd: the plot thicken
[02:47] <arjenAU> +s
[02:48] <SamB_XP_> tedg: I'm going to blame jelmer ;-P
[02:48] <lifeless> tedg: what ppa are you using?
[02:48] <SamB_XP_> if only for not setting the PPA managers straight
[02:48] <igc> tedg: ok, I have plenty of memory here. I'll try doing some of the conversion now
[02:48] <tedg> lifeless:  http://ppa.launchpad.net/bzr-nightly-ppa/ubuntu
[02:49] <lifeless> so, nightly friction
[02:49] <tedg> igc: This is what works for me: $ bzr svn-import --all -Derror inkscape.svn/inkscape inkscape.bzr
[02:49] <tedg> igc: Well, where "works" is generates an out of memory error :)
[02:49] <arjenAU> ok fullermd lifeless igc the prob came from the fact that we have push, parent and submit branch urls... so it gets confusing.
[02:50] <tedg> lifeless: Sure, but apt should stop bzr from installing then.  Or atleast warn me that the others need to be removed.
[02:51] <lifeless> tedg: nightlies dont have the right metadata
[02:52] <lifeless> tedg: they are pulling trunk, and there isn't a connection between trunk commits changing deps and the apt packaging
[02:52] <lifeless> tedg: same issue that bobthebuilder recipes need updating for
[02:54] <tedg> lifeless: yes, but it seems that the API version is related to the bzr version.  So it would seem that the bzr-svn package in Karmic should have a depends on bzr (= 2.0.0) if it's going to only request and deal with a specific version.
[02:54] <lifeless> tedg: no, the API version is like a soname, it changes when we break things, not when a release is done per se
[02:55] <lifeless> tedg: what does dpkg -l bzr
[02:55] <lifeless> show?
[02:55] <tedg> bzr            2.0.0+4766+129
[02:55] <lifeless> so
[02:55] <lifeless> dpkg thinks that you still have bzr 2.0.0 on your system
[02:55] <lifeless> as I said, metadata mismatch
[02:57] <SamB_XP_> lifeless: perhaps this metadata should be derived from something within the bzr tree somehow ?
[02:57] <lifeless> SamB_XP_: perhaps
[02:57] <SamB_XP_> like, maybe the API version ;-P
[02:57] <lifeless> tedg: you shouldn't use nightlies unless you're willing to deal with such mismatches, which will occur
[02:58] <tedg> lifeless: Believe me, I don't want to use nightlies :)
[02:58] <lifeless> so why are you?
[02:58] <tedg> lifeless: Because apparently they have memory fixes in them, that might bring down the memory of my import.
[02:58] <tedg> As apparently I don't have enough physical memory.
[02:59] <SamB_XP_> tedg: why are you using physical memory anyway ?
[02:59] <lifeless> there are significant memory improvements in trunk, thats true
[02:59] <lifeless> however igc is doing it now, right?:)
[02:59] <tedg> lifeless: And I'm uninstalling the nightly as we speak :)
[02:59] <igc> lifeless, tedg: rsynch'ing the inkscape svn repo as we speak
[03:03] <tedg> igc: If you could casually watch the memory usage as you're running, that'd be helpful.  If I'm close, I'd like to get this working as we're going to have to update with the final release hopefully in a couple days as well as pulling other sub-repos out of the SVN tree.
[03:03] <tedg> (website, docs, etc.)
[03:03] <igc> tedg: sure
[03:06] <igc> bbiab
[03:38]  * igc lunch
[04:01] <MTecknology> So.. loggerhead
[04:01] <MTecknology> better installed from bzr instead of apt?
[04:05] <spiv> MTecknology: hmm, I've never tried installing it :)
[04:07] <MTecknology> spiv: I'm trying to remember this and from what I recall from a year ago you run it and you don't really have control over what it listens to; I want it to run throguh apache..
[04:08] <spiv> I'm pretty sure you can control that.
[04:08] <MTecknology> ok, cool
[04:08] <spiv> See the loggerhead.conf.example
[04:09] <spiv> (http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/loggerhead.conf.example)
[04:09] <MTecknology> thanks :)
[04:09] <spiv> The README has a section on serving it from behind apache, too.
[04:11] <MTecknology> OH!
[04:11] <MTecknology> I remember this now... apache proxy
[04:21] <MTecknology> spiv: what's with the .1 files in there?
[04:22] <MTecknology> like serve-branches.1
[04:22] <spiv> No idea.
[04:22] <mwhudson_> man pages!
[04:22] <spiv> Oh, man pages.
[04:23] <MTecknology> mwhudson_: the readme file?
[04:25] <mwhudson_> MTecknology: no
[04:25] <MTecknology> mwhudson_: install from repos and use the man page then..?
[04:26] <mwhudson_> MTecknology: i may be missing bits of this conversation, i was updating the firmware on my router
[04:28] <MTecknology> mwhudson_: I'm using the head branch of loggerhead and I'm going to have it proxy throuch apache and hopefully make apache use system accounts to log into that (force ssl of course)
[04:28] <MTecknology> mwhudson_: I was just wondering whta th .1 files were for in the branch
[04:28] <mwhudson_> MTecknology: the .1 files are source for the man pages (as in the unix comand 'man')
[04:28] <MTecknology> oh
[04:28] <MTecknology> mwhudson_: OH!
[04:28] <MTecknology> LOL
[04:29] <MTecknology> that's just funny now - I thought you were telling me to look at the man pages
[04:29] <mwhudson_> aaa
[04:29] <mwhudson_> sorry :)
[04:29] <MTecknology> :P
[04:30] <MTecknology> now make ssh work for this other guy I'm trying to help. I'm looking on the server and the permissions are perfect - just not logging in using the key
[05:21] <poolie> hi spiv?
[06:19] <MTecknology> How can I remove loggerhead? I ran the setup install but I'd rather run it right from teh directory..
[06:25] <MTecknology> loggerhead is acting like it's running correctly, but it seems to be lying
[06:43] <MTecknology> I'm getting this error now... I'm getting close :) Unsupported configuration: PasteDeploy not available, but loggerhead appears to be behind a proxy.
[06:45] <MTecknology> YES!
[06:47] <MTecknology> Now.... Is there any way you guys can have loggerhead show commit messages the way launchpad does on the project page?
[06:48] <MTecknology> I know you can view a revision; it just won't let you see all the commit messages in one nice pretty list
[07:10] <MTecknology> hurray....
[07:11] <MTecknology> permission errors
[07:13] <MTecknology> I really with there was an easier way to manage permissions - like the ability to manage permissions over http the way svn lets you...
[07:13] <MTecknology> I'm going to need to look at how launchpad does it because this isn't working....
[07:14] <fullermd> Permissions...   pah.  Yet another pointless attempt to solve a social problem via technical means...
[07:15] <fullermd> You can totally skip worrying about that sort of thing if you just kill off everybody who isn't authorized to access $WHATEVER.
[07:15] <MTecknology> or can i... use apache permissions to manage directory access (which is already there) and run bzr over http
[07:15] <MTecknology> fullermd: hm?
[07:16] <fullermd> It's uncanny how many problems can be solved by the judicious application of mass murder.
[07:16] <MTecknology> fullermd: The group is staying the same because I set the 'sticky bit' on the bzr directory. But that doesn't work because the sticky bit doesn't retain owner
[07:16] <AfC> fullermd: there's good money in that line of work, death-as-enforcement-of-filesystem-permisions
[07:17] <MTecknology> I like the idea of being able to trust all developers.....
[07:17] <fullermd> chmod u+leadpipe colonelmustard.
[07:18] <fullermd> I suspect you're setting the setgid bit, not the sticky bit...
[07:18] <MTecknology> I'd like to manage permissions the same way launchpad does but.... that would be hard
[07:19] <MTecknology> drwsrws--t 5 shane kalliki-suite 4096 2009-10-27 23:56 .bzr
[07:19] <fullermd> The sticky bit is unlikely to do anything useful for you there (and the setuid probably does nothing at all)
[07:20] <awilkins> bzr-migration-docs : not building properly for me ... it leaves the body of the text out of the html page ; what's wrong? Wrong version in my toolchain?
[07:21] <fullermd> Actually, ISTM I've heard of some combinations of VFS patches and config files on some OSen that cause the FS to force user ownership based on setuid dirs...
[07:21] <fullermd> But that's pretty niche stuff.
[07:22] <MTecknology> I was going for simple
[07:22] <MTecknology> I was hoping I set permissions once and it just works
[07:22] <AfC> I'm not sure why sticky group isn't working for you, though
[07:22] <MTecknology> but since you're right that setuid isn't doing jack.....
[07:23] <AfC> that's what we use
[07:23] <MTecknology> the gid is being retained
[07:23] <MTecknology> just not the uid
[07:23] <fullermd> AfC: On a current project, I've actually roped my neighbor into doing some work; by a weird coincidence, she happens to have some experience we can use on this project.
[07:24] <fullermd> In giving her access to some files last week, she was all asking me what sort of legal blahblah I wanted her to sign about not touching unrelated stuff etc.
[07:24] <AfC> shared repository is mode 02775 group "bzr" and we make sure users' umask is 0022 and that they're all in group "bzr". Works like a charm
[07:24] <fullermd> I just gave her this quizzical look, and said "I know where you live."
[07:24] <AfC> heh
[07:25] <AfC> fullermd: yes, exactly. You don't need elaborate legal structures when the practical consequences are self-evident.
[07:25] <MTecknology> AfC: can anyone at all touch any repo?
[07:25] <fullermd> Don't need to worry about umask [for commits in an existing repo], since bzr will handle retaining those perms itself based on...  uh...   not entirely clear.  Either .bzr or .bzr/repository or .bzr/repository/packs...
[07:26] <AfC> MTecknology: you mean any Branch in that Repository? Yes. But it is of course plain courtesy not to mess with other peoples' branches
[07:26] <AfC> MTecknology: without explicit permission
[07:26] <AfC> MTecknology: otherwise, fullermd's "I know where you live" kicks in quite admirably
[07:26] <AfC> MTecknology: not to mention `userdel offender`
[07:26] <vila> hi all
[07:27] <MTecknology> AfC: I was referring to the repository, like /bzr/repo1 /bzr/repo2
[07:27] <AfC> fullermd: not sure I'd trust that, even if I believed it, but good to know. Thanks.
[07:27] <fullermd> There's no problem so big it can't be solved by killing the user off, removing their account, and reporting their REAL income to Internal Revenue.
[07:27]  * fullermd waves at vila.
[07:28] <MTecknology> AfC: Each repo will have a different group, but I want the uid to always be the same
[07:28] <AfC> MTecknology: in this case the repository in question is /bzr/java-gnome/hackers/...
[07:28] <MTecknology> AfC: once uid is retained when a new file is created, I'll be happy and set
[07:28] <fullermd> MTecknology: You're going to have an...  'interesting' time sweet-talking a *nix system into letting you create a file as a user other than yourself...
[07:29] <AfC> ie /bzr/java-gnome/hackers/andrew/enchant-updates and /bzr/java-gnome/hackers/guillaume/bug-455532-fixes
[07:30] <MTecknology> fullermd: this kinda sucks - I need to keep this fine grained because I'll have to deal with people handling touchy info that I won't be able to fight back if they screw around
[07:30]  * fullermd . o O ( cp /bin/sh /tmp/sh ; chmod +s /tmp/sh ; chown root /tmp/sh ; <fun> )
[07:30] <lifeless> MTecknology: bzr doesn't edit files, why do you need the uid kept?
[07:30] <MTecknology> fullermd: My only other idea is to run it over apache
[07:30] <MTecknology> lifeless: when a user adds data, the next user can't pull it
[07:30] <lifeless> MTecknology: I think what you what is umask, not super special uid magic
[07:30] <fullermd> The only way to get the files owned by a single uid is to only have them accessed by a [bzr] process running as that uid.
[07:30] <lifeless> MTecknology: uhm, details please
[07:31] <MTecknology> lifeless: h on
[07:31] <MTecknology> http://paste.ubuntu.com/303413/
[07:31] <MTecknology> actually... I'm not sure if that is a permission issue anymore
[07:33] <MTecknology> umask helped a lot
[07:35] <MTecknology> lifeless: for something like this, do you think running the permissions over http might be better?
[07:35] <MTecknology> or not really
[07:35] <lifeless> MTecknology: well, over http all your users would be the same user
[07:36] <lifeless> so have identical access and so forth
[07:36]  * igc dinner
[07:36] <lifeless> MTecknology: that error is on push, in insert_stream
[07:36] <lifeless> check that the upload directory (.bzr/repository/upload) has group +w
[07:36] <MTecknology> lifeless: except that I could make each user authenticate as themselves
[07:36] <lifeless> you'll want chmod -R g+w .bzr
[07:36] <MTecknology> nothing in there
[07:36] <lifeless> MTecknology: then it would be the same as ssh, wouldn't it?
[07:37] <MTecknology> except same user/group on the system
[07:37] <lifeless> MTecknology: permissions, not content ;)
[07:37] <MTecknology> drwsrws--t 2 root kalliki-suite 4096 2009-10-28 02:33 upload
[07:37] <lifeless> MTecknology: thats what I said though, 'all your users would be the same user'
[07:37] <MTecknology> why's that?
[07:37] <lifeless> MTecknology: so, is the user getting the error a member of kalliki-suite
[07:37] <MTecknology> yup
[07:38] <lifeless> ok
[07:38] <lifeless> check their ~/.bzr.log
[07:38] <lifeless> may have more detail
[07:39] <MTecknology> http://paste.ubuntu.com/303417/
[07:40] <MTecknology> oh... it was svn that I remember being able to handle granular permissions
[07:40] <poolie> spiv: nice mail re imports, thanks!
[07:40] <lifeless> MTecknology: on the server, the .bzr.log
[07:41] <MTecknology> http://paste.ubuntu.com/303419/
[07:42] <MTecknology> almost 3am again
[07:42] <MTecknology> I really never can just sit down and hammer something out quick
[07:42] <MTecknology> Isn't there any documentation to handling groups that access bzr repos?
[07:42] <lifeless> MTecknology: its permissions
[07:42] <MTecknology> I'd have no issues starting fresh
[07:42] <lifeless> chmod group write access within the repo
[07:43] <MTecknology> g+w?
[07:43] <lifeless> yes
[07:43] <MTecknology> same thing
[07:44] <MTecknology> it was already that way :(
[07:44] <lifeless> ls -lR .bzr/repository
[07:44] <lifeless> pastebin that
[07:45] <MTecknology> http://paste.ubuntu.com/303421/
[07:46] <AfC> root?
[07:46] <MTecknology> oh...
[07:47] <lifeless> MTecknology: and the directory itself
[07:47] <lifeless> MTecknology: ls -ld .bzr/repository
[07:48] <MTecknology> drwsrws--t 7 root kalliki-suite 4096 2009-10-28 02:06 bzr/suite-dev/.bzr/repository/
[07:50] <lifeless> ok
[07:50] <lifeless> so
[07:50] <lifeless> -rw-rwx--- 1 michael kalliki-suite  181 2009-10-28 02:31 3c29bfe02aba60925bb1e0d04349b994.rix.1864.carpo.jr7tsonnb7.tmp
[07:50] <lifeless> is noise from one of the errors
[07:51] <lifeless> you can see that its an index that your root user has already written
[07:51] <MTecknology> lifeless: can I just delete it?
[07:52] <lifeless> MTecknology: hell no
[07:52] <MTecknology> ok
[07:52] <lifeless> so, you definitely don't want the s bit set
[07:52] <lifeless> thats setuid
[07:53] <MTecknology> u-s
[07:53] <MTecknology> or ug-s ?
[07:53] <lifeless> on files
[07:53] <lifeless> on dirs +s is ok
[07:54] <lifeless> the t bit is what is making you get errors
[07:54] <MTecknology> oh
[07:54] <lifeless> "For directories, it prevents unprivi‐
[07:54] <lifeless>        leged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag
[07:54] <lifeless>        for  the  directory"
[07:54] <lifeless> (see man chmod)
[07:54] <MTecknology> that was the problem.........
[07:55] <lifeless> yes
[07:55] <MTecknology> so, when a different user tries to commit, will there be an issue?
[07:55] <MTecknology> if one user commits a brand spankin' new repo and another user tries to make a commit over it
[07:57] <MTecknology> I suppose as long as the group is retained
[07:57] <MTecknology> lifeless: thanks - I love you
[08:02] <poolie> lifeless: good night
[08:03] <lifeless> niht poolie
[11:01] <bialix> hi all
[11:40] <jml> Number of times I have run pqm-submit, got an "public branch out of date" error and _not_ wanted to immediately push to the public branch:
[11:40] <jml> Zero.
[11:42] <spiv> jml: shell scripting to the rescue! ;)
[11:43] <spiv> jml: btw,
[11:43] <SamB_XP> spiv: how is shell scripting going to help? you can't integrate that into bzr very easily ...
[11:43] <spiv> jml: https://code.edge.launchpad.net/~spiv/bzr-pqm/non-local-submission/+merge/13333
[11:43] <spiv> SamB_XP: it has while loops, bzr has exit codes, ta da!
[11:44] <spiv> SamB_XP: (also, note the wink...)
[11:45] <SamB_XP> but it's not an 0.6 wink ...
[11:46] <spiv> Indeed.  Perhaps I should segment my eyelids...
[11:46] <spiv> Until then, I think I'll stick with whole winks.
[11:48] <jml> spiv, I notice that that patch doesn't change any tests
[11:49] <spiv> jml: true, and I didn't even try running them.  I just bashed it into shape enough to solve my immediate problem.
[11:50] <jml> spiv, heh :)
[11:50] <spiv> (Which was there were a handful of things in bzr's review queue ready to land that I wanted to send to PQM without mucking about... I guess hacking on bzr-pqm means I failed ;)
[11:51] <spiv> I expect the next person (possibly me) that needs this will bash on it again, hopefully touching tests :)
[11:53] <jml> spiv, I've reviewed your patch, fwiw.
[11:54] <spiv> jml: heh, ta
[11:55] <spiv> Wow, I'd already forgotten most of this patch :)
[11:56] <spiv> I really should extract the config improvements, they'd be handy for writing some kinds of hooks I think.
[11:57] <spiv> Anyway,
[11:57] <spiv> g'night
[12:14] <Bear10> When does bazaar lock files?
[14:14] <vila> jam: ping
[14:15] <jam> morning vila
[14:15] <vila> mornign jam !
[14:21] <awilkins> Mmmm. Morning jam. On toast.
[15:22] <matkor> where is doc explaining what is needed when migrating from 1.x to 2.x ? And what are gains (except being in supported version), and potential pitfalls ? TIA
[15:29] <Peng_> matkor: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html
[15:30] <Peng_> matkor: You mean upgrading your bzr install or your files?
[15:32] <matkor> Peng_: Yes, thank you
[16:52] <faheem> hi. was running bzr upgrade on the mysql repos from lp. been running overnight and is consuming 1.6G memory. is this normal?
[17:01] <cjwatson> how do I find out what version of bzr is running on a remote smart server?
[17:01] <cjwatson> I don't have shell access, but do have bzr+ssh access
[17:05] <cjwatson> never mind, hacked bzrlib to tell me :-)
[17:07] <beuno-lunch> faheem, it is
[17:07] <beuno-lunch> if it fails, maybe we can help you and upgrade it in the datacenter
[18:35] <faheem> beuno: ok
[18:36] <faheem> thanks
[18:38] <faheem> i'm not clear what this bzr upgrade is for, though. can someone clarify?
[18:38] <faheem> i'm using bzr 2.0.1. just bzr branched mysql repos from lp
[18:39] <faheem> bzr: ERROR: Views are not supported by <WorkingTree4 of /tmp/mysql-server>; use 'bzr upgrade' to change your tree to a later format.
[18:40] <faheem> that's the error message i get
[18:40] <faheem> i think i was trying to do bzr view or some such
[18:47]  * awilkins has never used `bzr view` and only just learned of it's existence
[18:48] <awilkins> Looks like it's the bzr answer to the "staging area" in git
[18:48] <awilkins> Or something like it
[18:49] <awilkins> faheem: It may be that `view` requires an experimental working tree format
[18:52] <awilkins> But it seems to work on Working Tree Format 6
[19:04] <igc> morning
[19:05] <igc> awilkins: views will work in 2a
[19:05] <awilkins> Morning Ian
[19:05] <igc> awilkins: it's a bit rough around the edges though - some edge cases don't work frm memory
[19:06] <igc> e.g. shelve?
[19:06] <faheem> yes, but i'm not sure from what to what the upgrade is. it's not very explicit
[19:06] <faheem> i assume there are repos formats?
[19:06] <igc> awilkins: for simple stuff, it should be fine
[19:06] <awilkins> faheem: Ah, that's an upgrade of repository and working tree to the newer format. For MySQL it could take a while....
[19:07] <igc> faheem: MySQL are upgrading soon I believe
[19:07] <igc> faheem: if you branch in bzr, it keep the source format
[19:07] <igc> keeps
[19:07] <faheem> awilkins: i think it has been running overnight.
[19:07] <faheem> looks relatively close to completion
[19:08] <faheem> how many different active repos formats does bzr have?
[19:08] <awilkins> igc: Looking at the VSS converters I think vss2svn is clearly the best of the bunch... all the ones that depend on SS.exe are hobbled by the privacy of much of the code in the stack
[19:08] <faheem> is bzr view a builtin?
[19:08] <igc> faheem: there's only 1 default at a time
[19:08] <awilkins> igc: It's come on a lot since I last used it - full rewrite :-)
[19:08] <faheem> i recompiled on debian lenny with unstable sources
[19:09] <igc> faheem: for bzr 1.x, it was "pack-0.92"; for bzr 2.x, it's 2a
[19:09] <faheem> didn't ask me for anything for viewing stuff
[19:09] <igc> faheem: bzr view is builtin, but only supported on 2a formats
[19:09] <faheem> igc: how many of these are supporting wrt to conversion?
[19:09] <awilkins> faheem: view is native ; but it's new to me, I've never really had a need for it
[19:09] <igc> faheem: you can forward convert from pack-0.92 to 2a but not go back the other way
[19:10] <faheem> igc, awilkins: i see
[19:10] <faheem> so two formats?
[19:10] <igc> faheem: there were additional formats released over the 1x timeframe but they never became the default
[19:11] <faheem> igc: what happens if a repos is using them?
[19:11] <faheem> i mean wrt conversion?
[19:11] <awilkins> faheem: If your local repository is a different format, it converts revisions on the fly
[19:11] <igc> faheem: and it was messy - some had "rich roots" as needed by bzr-svn while others didin't
[19:11] <awilkins> faheem: This won't work backwards from 2a to 0.92 though
[19:12] <igc> faheem: 2a fixes that mess - everything is "rich root" from now on
[19:12] <awilkins> 2a is a rich-root format, 0.92 is not
[19:12] <faheem>  awilkins,  igc : i see. thanks.
[19:12] <faheem> so you are stablizing on the 2a format?
[19:12] <faheem> any further repos format changes anticipated?
[19:13] <awilkins> On past history, you can expect more optional formats that add performance or features
[19:13] <faheem> is there a history of these changes on the net? just curious.
[19:13] <awilkins> In newer versions of Bazaar... I don't think they'll be backported to 2.0.x series releases
[19:14] <awilkins> faheem: `bzr help formats`
[19:14] <faheem>  awilkins : great! thanks.
[19:15] <awilkins> Looks like that help doc needs a bit of tickling, it's out of date WRT to 2.0.x
[19:18] <igc> faheem: we may introduce another format in the future but that won't happen for at least 12 months
[19:19] <awilkins> what, no 2.1-super-fast-omg-ponies  ??  :P
[19:19] <igc> faheem: if we do, it will be to add new features (and there will be some performance/storage benefits most likely as well)
[19:19] <igc> awilkins: no, not new format in 2.1
[19:20] <awilkins> igc: I think the only thing I really want to see improve right now is nested tree support and packing times
[19:20] <igc> awilkins: nothing public at least - there may be some evolution of the "development" one
[19:21] <awilkins> bzr pack is significantly slower on 2a than the equivalent 1.14-rich-root for a fairly minimal space gain in most of my own cases.
[19:21] <igc> awilkins: can you report a bug with the figures re pack?
[19:22] <igc> awilkins: jam or lifeless will take a look most likely
[19:24] <jam> awilkins: 'bzr pack' on 1.14 rich-root probably had 0 space gains
[19:24] <jam> 'bzr pack' in 2a has huge wins, except we recompress on the fly, and recompress after a conversion
[19:24] <jam> so all the gains have already been 'one'
[19:24] <jam> 'won'
[19:25] <jam> if you give it a couple months, you could see more significant changes
[19:25] <jam> though we certainly could have a "bzr pack --lite" which uses our current 'recompress-on-the-fly' code
[19:26] <awilkins> jam: I think I saw about 100MB -ve delta out of 800M repo size which is definitely smaller, but the packs take a lot longer
[19:26] <jam> (recompress only groups that don't look compressed)
[19:26] <jam> awilkins: well as we are actually doing real work in 2a, I expect the time to go up :)
[19:26] <jam> 'bzr pack' is ~ git repack -a -f
[19:27] <awilkins> jam: It was enough to provoke me to split the repo into mutliple repos (one for each tree) instead of hosting all the trees in a single repository
[19:27] <jam> awilkins: why the need to force repack?
[19:27] <awilkins> jam: Not just forced repacks, autopacks too
[19:27] <jam> (as in, it shouldn't be something that you really need to do)
[19:27] <awilkins> jam: They're noticeably a lot longer
[19:27] <jam> autopacks would be slower than before, but not something I would expect to be noticeable except on major boundaries
[19:28] <jam> the 1 time I've seen it is when I rolled over 1k revisions to repack
[19:28] <faheem> who is the current bzr lead developer? is martin pool still working on it?
[19:28] <awilkins> jam: I might be an opposite corner case ; my trees are not that deep, but they are quite wide in many cases
[19:28] <jam> faheem: poolie is our leader, yes, though he doesn't do quite as much coding as he used to
[19:29] <awilkins> Some of those trees have 1.9GB of text files in them :-)
[19:30] <jam> awilkins: sure, but how much 'churn' do you have in that 2GB?
[19:30] <awilkins> jam: Oh, not a lot, except when a new folder with 150MB of text gets added... but just it's presence in the same repo as other trees seemed to slow down autopacks
[19:31] <awilkins> I know this is all wishywashy with no metrics, but it's an assertion based on 1.14-rich-root autopack times never bothering me enough to go "grr"... and 2a does on occasion.
[19:32] <gioele> will 2.1 be the next stable version or are you adopting a odd-dev/even-stable numbering scheme?
[19:32] <awilkins> Right, time to eat some pizza.... sorry to duck out, back later
[19:32] <jam> gioele: 2.1 will be next stable, 2.1.0b1 is the 'unstable' new release
[19:32] <jam> followed by b2, b3? rc1 then 2.1.0 final
[19:33] <gioele> time based betas?
[19:33] <jam> gioele: yeah, monthly releases
[19:33] <gioele> I see
[19:33] <jam> same as before, we are just labeling them differently now that we hit 2.0
[19:33] <jam> we'll also be doing ~ monthly 2.0.x releases
[19:33] <jam> with only bugfixes
[19:34] <gioele> That seems a very good thing to do. Suggests more stability than the 1.x cycle
[19:35] <gioele> another question: what is the correct way to generate the apidocs? pydoctor refuses to work and "make api-docs" seems no longer supported
[19:36] <jam> gioele: use epydoc < 3.0?
[19:36] <jam> ISTR you filing a bug report about epydoc 3.0 not working
[19:36] <jam> :)
[19:37] <jam> I would guess 'make api-docs' is supposed to be the way to do it, and we just need a patch to ensure compatibility with newer epydoc versions
[19:37] <gioele> jam: that is available only on dapper
[19:37] <mwhudson> gioele: in what way is pydoctor barfing?
[19:38] <jam> ISTR we had to monkeypatch some doc generation tools because they didn't handle some of our formatting
[19:38] <jam> we had a 'foo-bar' in one of our keys that wasn't liked
[19:41] <gioele> mwhudson: I created this .cfg following other bzr plugins: http://pastebin.com/d3c084a79
[19:41] <gioele> then pydoctor quits with Exception: you must pass a package directory to preprocessDirectory
[19:42] <mwhudson> gioele: you don't want the "prependedpackage" bit for bzrlib itself
[19:42] <gioele> mwhudson: even without it complains in the same way
[19:43] <mwhudson> gioele: what commandline are you using?
[19:43] <jam> mwhudson: would it be "packages: bzrlib" and no prependpackage?
[19:43] <gioele> mwhudson: pydoctor -c bzr.cfg --make-html
[19:44] <mwhudson> jam: ah, yes, probably
[19:44] <gioele> jam: yes, that seems to work
[19:44] <mwhudson> ah man, i need to find some time to give pydoctor some love :/
[19:45] <jam> mwhudson: you have 10 minutes starting....
[19:45] <jam> now
[19:45] <jam> :)
[19:48] <gioele> re
[19:51] <mwhudson> dear me, i'd forgotten how slow the rest parser is
[19:51] <mwhudson> "1320/3756 pages written"
[19:54] <gioele> may I suggest this tiny patch to Makefile: http://pastebin.com/d37a5e57a ?
[20:32] <meoblast001> wtf does this mean "This transport does not update the working tree of<EMAIL_ADDRESS>See 'bzr help working-trees' for more information."
[20:39] <luks> meoblast001: that the remote working tree on the server will be out-of-date
[20:39] <luks> but in the case of launchpad, I don't know :)
[20:39] <meoblast001> luks: i just downgraded the new tree to 1.9
[21:25] <nyu> while importing svn into a pristine 1.14-rich-root using bzr 2.0.1: http://pastebin.com/m2f1454f3
[21:25] <poolie> hi jam
[21:25] <nyu> and bzr-svn 1.0.0
[21:25] <jam> hey poolie
[21:31] <thumper> poolie: can I have a call with you soonish?
[21:31] <jam> igc: are you around?
[21:34] <poolie> thumper, yes, i was just going to suggest that
[21:34] <poolie> now works for me
[21:54] <Peng_> jam: Congrats on the releases. :)
[21:56] <jam> yeah, finally
[21:56] <jam> only took me 2 weeks
[21:58] <Peng_> jam: The CHK index thing sounds awesome too. Have I mentioned that I love you? :D
[22:06] <jam> and now that 2.1.0b2 was supposed to be released yesterday...
[22:06] <Peng_> Heh, oops.
[22:07] <Peng_> How current is the code in 2.1.0b1? Is it mostly 2 weeks old?
[22:09] <jam> Peng_: 2.1.0b1 was 'cut' 2 weeks ago
[22:09] <jam> so no changes since then
[22:09] <Peng_> Ah.
[22:09] <jam> just had to get the installers built
[22:09] <jam> and announcements made
[22:09] <jam> 2.1.0b2 will include the StaticTuple stuff
[22:09] <Peng_> When are you going to do 2.1.0b2, then?
[22:10] <jam> I posted to the list
[22:10] <jam> We'll find out
[22:10] <jam> 2.1.0b1 was already 2-weeks behind when it went gold, so it is officially 1 month late
[22:10] <jam> so either we'll release 2.1.0b2 right away to catch up, or wait a month
[22:10] <jam> anyway /me gone
[22:10] <Peng_> jam: See you later. :)
[22:13] <Stavros> hello
[22:13] <Stavros> has anyone managed to push to github with bzr-git?
[22:17] <Stavros> anyone?
[22:20] <Stavros> jelmer?
[22:22] <hno> Download link for 2.1.0b1 is wrong on the home page.. links to /2.0/ instead of /2.1/..
[22:26] <Stavros> is bzr-git also supposed to be able to commit to git branches?
[22:27] <lifeless> jam: do you think chk specific index is a big enough win to be doing another repo format?
[22:27] <lifeless> jam: or are you just tracking down all the memory inefficiencies as aggressively as possible?
[22:27] <lifeless> Stavros: I believe so
[22:28] <Stavros> lifeless: turns out i have to do git+ssh, but then it can't find the repo :/
[22:28] <lifeless> Stavros: the path is from /, not ~
[22:29] <Stavros> oh good, it works
[22:29] <Stavros> what do you mean?
[22:29] <Stavros> oh right
[22:29] <Stavros> so /Stavros instead of :stavro
[22:29] <Stavros> that's how it worked, thanks
[22:29] <Peng_> hno: Eh. I'll send a merge proposal, unless someone else gets to it first.
[22:38] <Peng_> lifeless: ping
[22:38] <lifeless> Peng_: ?
[22:40] <Peng_> lifeless: I'm being pushy, but if you have rights to the website, could you land a trivial patch that fixes a broken link on the homepage? It's kind of bad. :\ https://code.edge.launchpad.net/~mnordhoff/bzr-website/2.1.0b1-link/+merge/14121
[22:40] <lifeless> I'm not entirely sure where the new site is deployed to
[22:40] <lifeless> poolie: ^
[22:41] <hno> heh, not every day I stir up this much over a single digit..
[22:41] <lifeless> Peng_: it would be good if you can also submit a merge to update the docs to note that:
[22:41] <lifeless>  - releasing requires access to deploy a new website
[22:41] <Peng_> hno: :D
[22:41] <lifeless>  - the release manager needs to do this
[22:41] <Peng_> Eh.
[22:41]  * lifeless loathes static websites
[22:42] <lifeless> Peng_: have I misunderstood whats wrong?
[22:42] <Peng_> Yeah, me too. I don't have an anti-static wrist strap.  (Sorry, that was terrible.)
[22:42] <Peng_> lifeless: No.
[22:42] <Peng_> Well, the website *was* deployed. There was just a typo.
[22:42] <hno> hi lifeless btw
[22:42] <lifeless> ok
[22:42] <lifeless> hi hno :)
[22:42] <poolie> you just need to merge it to the branch
[22:43] <poolie> to the bzr-website trunk
[22:43] <poolie> nothing else is required
[22:43] <lifeless> oh ok
[22:43] <lifeless> thats good
[22:43] <poolie> patches to make it dynamic welcome ;)
[22:43] <Peng_> releasing.txt already mentions it:
[22:43] <Peng_> #. Announce on the `Bazaar website <http://bazaar-vcs.org/>`_. This page is edited via the lp:bzr-website branch. (Changes pushed to this branch are refreshed by a cron job on escudero.)
[22:43] <lifeless> Peng_: are you able to push to the trunk ?
[22:44] <lifeless> (and if not, why not :P)
[22:44] <Peng_> lifeless: I'm not a member of ~bzr.
[22:44] <lifeless> hmm, we should fix that
[22:44] <lifeless> nevertheless
[22:45] <Peng_> (That was three lines on my clipboard. How did it get magically converted into one nicely-formatted line?)
[22:45] <Peng_> lifeless: Well, I wouldn't mind joining. I never thought about it before.
[22:48] <lifeless> your branch is pushed
[22:48] <Peng_> lifeless: <3
[22:48] <lifeless> and you should join, I think.
[22:48] <lifeless> poolie: ^
[22:48] <Peng_> I wonder how often the cronjob runs?
[22:52] <poolie> +1
[22:52] <poolie> lifeless: you already merged it to trunk?
[22:52] <poolie> roughly every hour
[22:52] <poolie> this is a great example of why it should be scripted btw
[22:52] <poolie> and why a wiki is no better
[22:53] <lifeless> poolie: yes
[22:54] <lifeless> I'm popping out to get my hair cut; mobile is on.
[23:16] <Peng_> Ah, the website was rebuilt at XX:50:03, which was immediately after the new revision was pushed.
[23:17] <Peng_> So the cronjob runs at least every 10 minutes.
[23:21] <hno> bzr+bzrtools 2.1.0b1 now packaged for Fedora-13/Rawhide.. and 2.0.1 pushed for Fedora-12 which means it should make it into the final release (2.0.0 currently there).
[23:24] <Peng_> Cool. :)
[23:43]  * igc out for a while


[00:12] <ScottK> Someone looking for some useful porting work might want to port pinentry-qt4 to Qt5.
[00:26] <valorie> ScottK: what is pinentry?
[00:26] <valorie> is it literally pin entry?
[00:27] <ScottK> Pretty much
[00:27] <ScottK> The little window the pops up to enter your gpg passphrase is pinentry.
[00:27] <valorie> ah, that seems useful indeed
[00:29] <ScottK> So we'll need it eventually as we migrate off Qt4.
[00:30] <ScottK> The Qt4 part is about 6.5 KSLOC.
[00:30] <ScottK> Not sure how much change it'll require.
[00:34] <valorie> is the lack of that a blocker for vivid?
[00:34] <valorie> if so, you might want to send up the flags on some lists
[00:36] <ScottK> No, it's not a blocker for vivid.
[00:36] <ScottK> It's probably a 16.04 blocker though.
[00:37] <ScottK> Not sure when we'll got for all Qt5 desktop as a goal.
[00:39] <valorie> I assume that is not a big enough job for a GSoC project
[00:39] <valorie> perhas a SoK?
[00:40] <valorie> if it's not done by this summer
[02:07] <ScottK> Sput: https://bugs.launchpad.net/bugs/1424256
[02:33] <Sput> ScottK: https://codereview.qt-project.org/#/c/106409/
[02:33] <Sput> (not sure if that's gonna hit 5.4.1 or 5.4.2 though)
[02:33] <ScottK> Thanks.
[02:34] <Sput> Qt 5.4.0 seems to be kinda broken in several ways :/
[02:34] <ScottK> Mirv or mitya57: Do you think we could cherrypick ^^^?
[05:34] <Mirv> that could be included together with what sitter is going to have MP for
[05:35] <Mirv> as it's albert he'll probably ping to cherry-pick as well
[06:15] <mitya57> ScottK: it will be in 5.4.2. Feel free to cherry-pick it (or wait for me to do it)
[09:43] <Evpok> Hello, people. Someone here tried to build/install from the kdeconnect-kde frameworks branch ?
[09:51] <Evpok> Anyway, I tried to do what I used to on master / kde4 : cmake -DCMAKE_INSTALL_PREFIX=/usr ; make ; sudo make install ; qdbus org.kde.kded /kded loadModule kdeconnect ; kbuildsycoca5
[09:52] <Evpok> I then added the plasmoid to systray. But it show an error message, saying it can't import the org.kde.kdeconnect module
[09:53] <Evpok> I looked for the associated qmldir, which is in /usr/lib/x86_64-linux-gnu/qml/org/kde/kdeconnect/qmldir so probably not the right place. But I can't find out where it is supposed to be
[10:09] <lordievader> Good morning.
[10:09] <Evpok> OK, I found it, it needed  `cmake -DCMAKE_INSTALL_PREFIX=/usr -DKDE_INSTALL_QMLDIR=/usr/lib/x86_64-linux-gnu/qt5/qml`
[10:29] <ovidiu-florin> jose: ping
[10:42] <Evpok> For the record, I put a full build script at https://gist.github.com/Evpok/61ac7827ad8c5ed7e632 as the cmake recipies are still pretty much black magic to me it could probably be optimised
[11:02] <ovidiu-florin> jose: ping
[12:58] <BluesKaj> Hiyas all
[14:55] <shadeslayer> Riddell: who has admin access to forums?
[18:48] <ScottK> Mirv: I pushed the qtbase patch to bzr.  It didn't apply 100% due to other changes, so please double check I did it right.
[20:15] <Riddell> buenos noches
[20:16] <soee_> hiho Riddell
[20:17] <shadeslayer> Riddell: a tu tambien
[20:19] <BluesKaj> bonsoir
[20:21] <BluesKaj> I've asked this question in ##linux and #qemu , but so far 30mins and no response... how to copy an HTML bookmarks file from host (Kubuntu OS) to guest OS (Windows7) in qemu?
[20:21] <Riddell> sgclark: plasma 5.2.1 didn't get uploaded
[20:21] <Riddell> ?
[20:22] <BluesKaj> VB had those options, but I haven't found them in kvm-qemu
[20:25] <Riddell> BluesKaj: scp?
[20:29] <BluesKaj> the guest doesn't see the host OS at all , Riddell
[20:30] <Riddell> then it probably needs networking fixed first
[20:41] <soee> Riddell: is there some proggress with breeze icons for ibre office ?
[21:22] <Riddell> soee: not from me, unless Quintasan has done anything
[21:22] <Quintasan> I got stuck on how Riddell script parses that wiki format
[21:24] <soee> :D
[22:51] <soee> Riddell: ping
[23:03] <Riddell> hi soee
[23:05]  * Riddell sleeps
[23:06] <soee> ah ok, than good night :)
[23:23] <sgclark> Riddell: no it got late and was still rejected. Will try again here shortly


[03:57] <Cheri703> Unit193: around?
[04:00] <Unit193> Cheri703: No
[04:00] <Cheri703> k
[04:01] <Unit193> What ya need?
[04:01] <Cheri703> you use kword in kde?
[04:02] <Unit193> No, last time I used OO.o, next/this time LO
[04:03] <Unit193> Why?
[04:03] <Cheri703> apparently kword has an "import pdf" feature, that keeps the formatting. I want to utilize it without installing kde stuff
[04:03] <Cheri703> BiosElement:  you use kde, do you use kword? /me is just going to ping people who use kde: )
[04:03] <Cheri703> * :)
[04:04] <BiosElement> Yeah, I sometimes do. Usually just use kate though
[04:05] <Unit193> Right now I'm more XFCE/Xubuntu and LXDE/Lubuntu
[04:06] <Cheri703> k
[04:11] <Cheri703> do you HAVE kword? BiosElement
[04:12]  * Cheri703 needs a file converted...
[04:12] <BiosElement> Yeah. Checked for the import pdf thingy, didn't see anything.
[04:12] <Cheri703> :(
[04:12] <Unit193> OO.o can
[04:12] <Unit193> LO should be able too
[04:12] <Cheri703> http://kpdfimport.sourceforge.net/
[04:12] <Cheri703> I need to convert it
[04:13] <Cheri703> I want to change font color and background color to make it more eye friendly (reduce eye strain reading on computer screen)
[04:13] <Cheri703> BiosElement: that link (if you're inclined to help, if not, totally fine :) )
[04:14] <Unit193> Cheri703: Does TeamViewer need to be run as root? (#lubuntu question)
[04:14] <Cheri703> not to my knowledge
[04:14] <Cheri703> I do know it's happier in 10.10 than 10.04, at least with gnome
[04:15] <BiosElement> Old as sin, but I'll give it a shot anyway
[04:15] <Cheri703> k
[04:16] <Cheri703> try it with a pdf you have, and then I'll email mine (if you have a few minutes)
[04:18] <BiosElement> I'll see if I can get it working
[04:19] <Cheri703> k, thanks. I'm not trying to be all "BiosElement! DO THIS FOR ME NOWWW!" I hope I'm not coming across that way :/
[04:25] <Cheri703> BiosElement: this one perhaps? http://sourceforge.net/projects/kpdfimport/
[04:33] <Cheri703> BiosElement: that second one was updated MUCH more recently
[04:39] <Cheri703> BiosElement: I may have found one that will work with libreoffice
[04:46] <BiosElement> Great Cheri703
[04:46] <Cheri703> trying to get it working, not sure how :/
[04:46] <BiosElement> Nah, I don't mind testing
[04:47] <Cheri703> I appreciate it :)
[05:37]  * Unit193 Akron tomorrow
[05:37] <Unit193> today? tomorrow? hrm...
[05:37] <Cheri703> ?
[05:38] <Unit193> I be going to akron tomorrow/today/17th
[05:39] <Cheri703> ah, exciting
[05:39] <Cheri703> and happy saint patrick's day!
[05:40] <Unit193> You going in green or orange? ;)
[05:41]  * Cheri703 is probably not leaving the house
[05:50] <Cheri703> anything exciting happening in akron?
[05:52] <Unit193> Relatives...
[05:53] <Cheri703> fun fun


[02:16] <czajkowski> aloha
[02:16] <czajkowski> booo timezones :(
[06:00] <Tm_T> czajkowski: where?
[17:36] <czajkowski> Tm_T: Oregon currently


[07:08] <MauroGaspari[m]> Since I could not break it on a VM, I installed 21.04 on my desktop.  Studio-Controls, Carla, and the audio stack works great. Plasma theme maybe needs some tweaking. And I am getting segmentation fault when trying to load nextcloud desktop sync client. Which is strange because I did not have that error on UB 21.04 . I will try to learn more about that error.
[15:28] <RikMills> plasma 5.21.4 bugfix and translation updated should be hitting the hirsute release pocket soon. please test, and shout if there are any issues
[15:28] <RikMills> *update


[03:50] <seiflotfy> DBO, u there
[03:50] <seiflotfy> ?
[03:51] <seiflotfy> I have a dock question
[03:51] <DBO> ya, whats up?
[03:51] <DBO> ya?
[03:51]  * spikeb ponders the appmenu change
[03:51] <seiflotfy> ok
[03:52] <seiflotfy> can i access items in the dock over dbus
[03:52] <seiflotfy> DBO, just like in docky
[03:52] <seiflotfy> I would like to add the zeitgeist jumplist
[03:52] <seiflotfy> (I also just updated the docky version -- very awesome now)
[03:53] <DBO> we are planning on implementing dock manager eventually
[03:53] <DBO> I dont have time yet
[03:54] <seiflotfy> DBO, awesome
[03:54] <seiflotfy> DBO, so i updated the zeitgeist_menu to be more dynamic and intelligent
[03:54] <seiflotfy> so it updates itself on the fly using the zeitgeist-monitors
[03:54] <DBO> awesome
[03:54] <seiflotfy> so if u open someting it appears in the jumplist under latest instantly
[03:55] <seiflotfy> also folders jumplists are generated by recusring through all subfolders :)
[03:55] <seiflotfy> and if 2 files in the jumplist have the same name i attach the path
[03:55] <seiflotfy> u wanna try it
[03:55] <seiflotfy> ?
[03:57] <DBO> not right now :)
[03:58] <seiflotfy> u will find a merge request
[03:58] <seiflotfy> just feel free to pull the code when u feel like it
[12:09] <coz_> good day


[12:50] <hughsie> PowerManagement guys -- opinions please.
[12:50] <hughsie> in reference to https://wiki.ubuntu.com/PowerManagementConfiguration
[12:50] <hughsie> the battery critical sliders are per-time, rather than per-percent.
[12:51] <hughsie> now I've got a bit of time, i've been fixing the issues ubuntu has with g-p-m to more match this mockup
[12:51] <hughsie> but, i need some rational about the per-time thing
[12:54] <ogra_ibook> hughsie, i guess nobody of the guys that have written this spec is around ...
[12:54] <ogra_ibook> (and i disagree with it to be honest, i think g-p-m is fine as is)
[12:55] <hughsie> ogra, cool, cheers!
[12:55] <hughsie> ogra_ibook, you mind if I scribble on your wiki?
[12:55] <ogra_ibook> put a comments section at the bottom and make your suggestions there
[12:56] <ogra_ibook> but in the end its mjg59 who will implement it and i think he'll take g-p-m as well as it is now ;)
[12:57] <hughsie> ogra_ibook, I figured if you really dont likethe hal actions thing, you can just wrap g-p-m around PowerManager init.d service like i did before hal had actions support
[12:57] <hughsie> ogra_ibook, but that's hassle :-)
[12:57] <ogra_ibook> gah, got a horrible lag here
[12:58] <hughsie> ogra_ibook, You should see the mount(), unmount(), eject() methods in HAL CVS.
[12:58] <ogra_ibook> mjg59 cares for this part, i think he'll just write a dbus service
[12:58] <ogra_ibook> at least it sounded like it ...
[12:58] <hughsie> they rock for fedora (as gnome can just call a dbus method) but I'm not sure how easily pmount and the ubuntu stuff will work.
[12:59] <hughsie> he can use PowerManager as a start, or just do a quick daemon in python or something
[12:59] <ogra_ibook> currently he calls the gdm functions directly, which works like a charm ...
[12:59] <ogra_ibook> but wont match the security requirements i guess
[12:59] <hughsie> yes, i guess.
[01:00] <ogra_ibook> i'd love to have it like it is now ...
[01:00] <hughsie> :-), well, wait and see
[01:00] <hughsie> you been following g-p-m cvs at all?
[01:00] <ogra_ibook> but somehow there were some people that didnt like the implementation at all and wrote this spec
[01:00] <ogra_ibook> only the releases ... my focus moved to ltsp ...
[01:01] <hughsie> I think Corey Burger has some problems with some stuff, but Jaap sent a few patches to make him happier.
[01:01] <hughsie> Like the Shutdown button now brings up the logout dialogue
[01:01] <hughsie> rather than just blindly shutting down the system
[01:01] <ogra_ibook> yes, Burgwork is a hard bone if it comes to usability, he's a perfectionist ;)
[01:02] <ogra_ibook> cool
[01:02] <hughsie> Yes, he's cool.
[01:02] <hughsie> Exams finsihed last week, and so far I've been committing patches like ther eis no tmw.
[01:02] <hughsie> today I've made 11 commits to gnome cvs
[01:02] <ogra_ibook> heh
[01:03] <hughsie> how's work?
[01:03] <mjg59> hughsie: Hi
[01:03] <ogra_ibook> cool
[01:03] <ogra_ibook> i just get a nightly meal ...
[01:03] <schlomo> Hi
[01:03] <schlomo> sorry to bother
[01:03] <hughsie> mjg59, hi, you got a min?
[01:03] <ogra_ibook> bbl
[01:03] <mjg59> hughsie: Basically, we're going to be using g-p-m as is
[01:03] <ogra_ibook> yay
[01:03] <hughsie> mjg59, with the hal methods?
[01:03] <mjg59> hughsie: I've hacked dbus lightly to get the semantics right for our security model
[01:03] <schlomo> which version has been used to compile kernel <IP_ADDRESS>-386 ?
[01:03] <mjg59> hughsie: Yup
[01:03] <hughsie> mjg59, *sweet*
[01:04] <schlomo> I have to recompile alsa driver for snd-hda-intel
[01:04] <hughsie> mjg59, there's lots of source tidy ups and code reduction in CVS.
[01:04] <hughsie> but CVG g-p-m depends on CVS hal...
[01:04] <hughsie> :-)
[01:04] <schlomo> any idea ?
[01:04] <mjg59> hughsie: I've got a pam module that creates a lockfile when a user logs in, which includes the console
[01:05] <hughsie> mjg59, like the rh at_console thing?
[01:05] <schlomo> don't tell me gcc-3.5 because it's virtual package right now :)
[01:05] <mjg59> hughsie: It's the at_console thing, except we check that the user is at the foreground console
[01:05] <mjg59> Rather than just at /a/ console
[01:05] <schlomo> please any tips ?
[01:05] <hughsie> mjg59, so better than at_console :-)
[01:05] <mjg59> So if there are two users at the console, only the current one can trigger suspends and play with the network and so on
[01:06] <mjg59> hughsie: Yes :)
[01:06] <hughsie> mjg59, makes sense
[01:06] <hughsie> i ight steal the idea and bugzilla rh about it.. :-)
[01:06] <hughsie> mjg59, I think i've solved the "gpm won't run at the login screen" problem
[01:07] <schlomo> hum
[01:07] <mjg59> hughsie: So the only thing I need to add now is a suid app that hal can call
[01:07] <schlomo> thanks anyway
[01:07] <mjg59> hughsie: Oh, coo
[01:07] <schlomo> :)
[01:07] <hughsie> using dbus activation, one instance of g-p-m can replace another.
[01:07] <hughsie> and one instance can be gnome-power-console and have no GUI.
[01:07] <mjg59> schlomo: cat /proc/version
[01:07] <mjg59> hughsie: Ah, excellent
[01:07] <hughsie> mjg59, that sound likea plan?
[01:07] <hughsie> mjg59, one problem tho,
[01:08] <mjg59> hughsie: Yes
[01:08] <schlomo> gcc version 3.4.5 20050809  :)
[01:08] <schlomo> mjg59 : thanks for the tips ;-)
[01:08] <hughsie> mjg59, g-p-m has to use the system dbus connection, not the session connection
[01:08] <mjg59> hughsie: Ah
[01:08] <hughsie> as session gets created and destroyed all the time with login and logout
[01:08] <mjg59> Yes
[01:08] <mjg59> Hmm
[01:08] <mjg59> We want to be able to have more than one g-p-m running, though
[01:09] <hughsie> no big problem, same shit, different connection that's all
[01:09] <hughsie> mjg59, what for?
[01:09] <mjg59> Since more than one user may have a session
[01:09] <mjg59> Or are we back to a system-wide g-p-m now?
[01:09] <hughsie> mjg59, no -- :-)
[01:10] <mjg59> With fast-user-switching, there may be two or more users with gnome sessions at once
[01:10] <hughsie> mjg59, when the user is no longer at_console, the instance of g-p-m attached to that console quits, and the at_console instance gets started
[01:10] <hughsie> but with fusa, only one should be at_console, no?
[01:10] <mjg59> hughsie: With RH, multiple people can be at_console
[01:10] <mjg59> With us, only one
[01:10] <hughsie> mjg59, yes, but that is busted and wrong in my opinion
[01:10] <hughsie> the rh case that is
[01:11] <mjg59> But users can switch just by hitting ctrl+alt+F?
[01:11] <mjg59> How do you catch that?
[01:11] <schlomo> configure: error: You have built-in ALSA in your kernel. ?
[01:11] <schlomo> I have to get source ?
[01:12] <schlomo> why I can compile a module ?
[01:12] <mjg59> schlomo: What are you trying to do?
[01:12] <schlomo> on Hoary kernel I can
[01:12] <mjg59> schlomo: You should probably be asking this on #ubuntu
[01:12] <hughsie> mjg59, not sure of the details at the moment, i'm waiting for somebody to fix https://bugs.freedesktop.org/show_bug.cgi?id=4637
[01:12] <schlomo> sorry
[01:12] <hughsie> so I can test it myself and get all the corner cases out
[01:12] <schlomo> Ihave to recompile alsa module for snd-hda-intel
[01:12] <hughsie> but at the moment session/system dbus is one #define change ;-)
[01:13] <schlomo> on <IP_ADDRESS>-i386
[01:13] <crimsun> schlomo: ask in #ubuntu, I'll help you. This is the wrong channel.
[01:13] <mjg59> hughsie: Ok, cool
[01:13] <schlomo> ok sorry
[01:14] <hughsie> mjg59, whats the release date for dapper?
[01:14] <mjg59> hughsie: April
[01:15] <hughsie> no problem. new hal is expected in jan, so my big release is going to be a bit after that
[01:15] <hughsie> Assuming fd#4637 gets fixed in time....
[01:18] <hughsie> mjg59, one last question (then i sleep) for the critical low sliders, currenly per-percent, in the discussion with Corey, he wanted then per-time (i.e. 5 minutes remaining, rather than 5% remaining) -- what's your take on this?
[01:18] <mjg59> hughsie: I think per-time is sensible
[01:18] <mjg59> But I think I've said that before :)
[01:19] <hughsie> mjg59, i'm thinking so at the moment, but some batteries give wildly inaccurate times at low charges... is that not a worry?
[01:19] <mjg59> hughsie: Hmm. How is the time less accurate than the percentage?
[01:20] <hughsie> mjg59, if the resolution is say 2 minutes, and the battery dischange is non-linear (old/knackered batteries) then the time goes completely non-linear less than about 10 minutes
[01:21] <hughsie> my new laptop battery is okay, but my old battery is accurate for the first 30 minutes, then exponentially crashes!
[01:21] <mjg59> hughsie: Oh - so when we say "10 minutes" that might be entirely inaccurate? Hrm.
[01:21] <hughsie> yes
[01:21] <mjg59> I wonder if hal ought to learn
[01:21] <hughsie> i normally hibernate at 1% (critical low)
[01:21] <mjg59> Since spec-compliant batteries provide a model number and serial number
[01:21] <hughsie> but one minute is not accurate enough at all.
[01:22] <hughsie> mjg59, my batteries only differ by age.
[01:22] <mjg59> hughsie: The serial number is identical?
[01:22] <mjg59> Tch.
[01:22] <hughsie> you can do some fancystuff in hal for non-linear discharges, but then you need a backing store for the data
[01:22] <hughsie> not serial no, but model etc
[01:22] <mjg59> Ok. Percentage based, but set the default based on the battery information?
[01:22] <mjg59> hughsie: Right, that was what I meant
[01:23] <mjg59> hughsie: hal could record the curve for individual batteries
[01:23] <mjg59> That's quite advanced, though :)
[01:23] <hughsie> mjg59, yes, but that requires a backing store for about 16k of data. I've thought about this one before
[01:23] <mjg59> hughsie: Yeah. We have no mechanism for that now?
[01:24] <hughsie> the percentage change should be set on the capacity, you're right.
[01:24] <hughsie> i'll do that.
[01:24] <hughsie> at the moment, g-p-p gives a "esimated time value" in small italics under the percentage slider.
[01:24] <mjg59> Ok, that sounds good
[01:24] <hughsie> you can see it in the glade file, but it only works (obvioulsy) when discharging.
[01:25] <mjg59> As long as it doesn't default to warning me at a ridiculous time when I've got a big battery :)
[01:25] <hughsie> yes, i'll fix that. defaults to 5% at the moment
[01:27] <hughsie> mjg59, okay, thanks for the input. I sleep now. Happy Christmas all you Ubuntu'ers!
[01:27] <mjg59> hughsie: Happy christmas!
[02:36] <schlomo> Hi
[02:36] <schlomo> I have take some quotes from an article
[02:36] <raphink> yop schlomo
[02:36] <raphink> faut dormir il est tard ;)
[02:37] <schlomo> about friendly documentation
[02:37] <schlomo> and support options
[02:37] <schlomo> yep
[02:37] <schlomo> I think it very interesting
[02:37] <schlomo> http://paste.ubuntu-nl.org/6100
[02:37] <schlomo> just 3 rows
[02:37] <schlomo> can you read please
[02:38] <schlomo> does launchpad.net has been done for that purpose ?
[02:38] <raphink> where is that from ?
[02:38] <raphink> schlomo: demande sur #launchpad si tu veux parler de launchpad c'est mieux, c'est fait pour :)
[02:38] <schlomo> ok :)
[02:39] <schlomo> ACM
[04:20] <lunitik> Is there any work around for the locales issue?  (bugzilla #21436)  - I'd ask in #ubuntu but I'm banned....
[04:22] <lunitik> k... thanks for your help  :/
[04:38] <Amaranth> liar, he isn't in the ban list
[07:45] <pef> hello
[11:41] <pvanhoof> I recently upgraded to ubuntu dapper, but list my cute X11 mouse cursor
[11:41] <pvanhoof> how do I regain it? :)
[11:41] <pvanhoof> s/list/lost
[11:41] <pvanhoof> I'm addicted to that cute thing!
[11:42] <pvanhoof> oh, and there's some problems with the cups packages. Some rc.invoke script fails
[11:42] <pvanhoof> and the latest kernel has it's include files installed wrongfully. But I simply installed the kernel source package, changed the version in version.h and used that to build my VMWare modules (which works)
[11:43] <pvanhoof> would be nice if it would get fixed ;0
[11:43] <pvanhoof> ;)
[11:57] <mpt> pvanhoof, this is a developer channel, and most of the developers are on holiday
[11:57] <mpt> Besides, dapper is not an "upgrade" as long as it's not finished :-)
[11:58] <pvanhoof> ok :)
[11:58] <mpt> You'd probably have better luck reporting bugs in bugzilla.ubuntu.com
[11:58] <pvanhoof> yeah, was going to do that
[11:59] <Pygi> pvanhoof: after all, you can always try to uninstall it first. then install it
[11:59] <pvanhoof> oh, but I just installed it. Why would I want to uninstall it? :)
[11:59] <Pygi> I meant the mouse cursor :)
[12:00] <pvanhoof> ah, is it a package?
[12:00] <pvanhoof> that might have slipped during the install then
[12:00] <pvanhoof> err, upgrade
[12:01] <Pygi> heh :)
[12:01] <Pygi> try do that, it may fix it :)
[12:01] <pvanhoof> which package?
[12:05] <Pygi> try xcursorgen with all it's dependencies
[12:16] <Pygi> wb
[12:19] <Yagisan> Is there some lag on the mirrors atm ? I received  pitti's notice about new kernels 2 days ago, and still don't see them @ au.archive.ubuntu.com
[12:19] <jbailey> Yagisan: I would expect them to be on security.ubuntu.com
[12:21] <Yagisan> jbailey: by default apt was set up with a  breezy-security line and my "local" mirror
[12:22] <Yagisan> I'd assume that should have taken care of it
[12:23] <jbailey> *shrug* I don't have good answers, only answer.
[12:25] <Yagisan> jbailey: thanks anyway, being less the 2 hours until christmas, I didn't expect anyone to answer
[03:25] <zul> merry christmas
[03:26] <zakame> merry christmas too zul :) 'tis only an hour and a half away here :)
[03:26] <zakame> in .ph
[03:26] <zul> cool
[03:37] <zakame> hi smurf
[03:39] <HiddenWolf> jdub, nice job bringing reason to the spatial debate on gnome-desktop-devel. Thumbs up.
[03:52] <alejandro> hi
[03:57] <mhz> hi alejandro
[05:17] <lamont> configure.in:220: error: possibly undefined macro: AM_PROG_LIBTOOL
[05:17] <lamont> poor dbus
[05:17] <BenC> anyone with a UP amd64 want to test a kernel for me?
[05:18] <lamont> BenC: I have 32-bit user space, but I could test it later today if you want
[05:18] <BenC> lamont: http://people.ubuntu.com/~bcollins/kernels/amd64-alternative-smp/
[05:18] <lamont> I'm assuming that you'reconfident it won't trash my filesystem or anything like that...
[05:18] <BenC> it's an SMP kernel
[05:18] <BenC> yes, all should be safe
[05:18] <BenC> it will either crash or boot :)
[05:19] <lamont> model name      : AMD Athlon(tm) 64 Processor 3500+
[05:19] <lamont> which beast do I want for that?
[05:19] <BenC> after you boot it do "dmesg | grep SMP" and see if you see a message like "SMP alternatives: switching to UP code"
[05:19] <BenC> -k8-smp
[05:20] <lamont> fetching now - holler if someone beats me to testing it..
[05:20] <BenC> the more testers the better
[05:20] <lamont> otherwise, I'll munge it and install once I get back from running to town and such.
[05:20] <lamont> ok
[05:20] <lamont> I'll plan on testing in any case then
[05:20] <BenC> no one has tested it yet
[05:20] <BenC> thanks
[05:21] <lamont> of course, if it comes up and tells me I have 2 processors, that'll be cool too.:-)
[05:40] <lamont> dpkg-deb: building package `linux-image-2.6.15-10-amd64-k8-smp' in `../linux-image-2.6.15-10-amd64-k8-smp_2.6.15-10.15_i386.deb'.
[05:43] <neuralis> BenC: ping
[05:49] <tseng> lamont: is there a default -j to MAKEOPTS in the builders?
[05:49] <tseng> lamont: > 1
[06:06] <BenC> neuralis: pong
[06:07] <neuralis> BenC: can you take a look at wiki/ServerTesting (bottom of page) and see what else you'd like on there?
[06:07] <neuralis> i wrote that in 10 minutes at 4am, so i quite likely missed several things
[06:09] <BenC> reading...
[06:13] <BenC> neuralis: When reporting bugs, tell them to make sure to include atleast dmesg, and also check https://wiki.ubuntu.com/DebuggingProcedures for other things they can do prior to submitting the bug report
[06:15] <neuralis> will do. anything else they should be testing?
[06:18] <tseng> lamont: also, im told mvo can not build mono in even a breezy chroot on ppc buildd, which built fine before.. is something amiss with the system?
[06:19] <tseng> lamont: its not reproducable on similar systems
[06:20] <slomo> lamont: and it does also happen now for versions that worked before on that machine
[06:32] <BenC> neuralis: that's pretty close to it
[06:53] <decklin> where is the 'component' box in bugzilla? (when entering a new report)
[07:00] <slomo> decklin: for new bugreports you should use launchpad.net/malone
[07:01] <decklin> oh, ok. thank you.
[07:09] <decklin> argh. ok, i created a bugzilla account 10 minutes ago, and that generated password does not work on malone, but malone also says my email is already registered.
[07:11] <Amaranth> decklin: your wiki account should be your launchpad account
[07:11] <Amaranth> slomo: all new bugs are going to malone now?
[07:12] <slomo> Amaranth: afaik yes
[07:12] <decklin> Amaranth: i'm pretty sure i don't have a wiki account.
[07:12] <decklin> this is for an address i use on Debian packages, if that matters
[07:18] <decklin> (well, a reset worked. ok, sorry to bother everyone.)
[07:24] <\sh> evening
[08:07] <lamont> tseng: no.  gcc has certain options (-pipe) forced, and defaults certain others (but not on ppc)
[08:07] <lamont> tseng: what did change is possibly ppc vs ppc64 on the base system
[08:08] <lamont> there could also be toolchain diffs between when it built and when it shipped.
[08:09] <lamont> BenC: hrm... that new kernel requires a dapper initramfs-tools... what else does it need from dapper?
[08:10] <\sh_away> merry christmas to all of you :)
[08:23] <xhaker> \sh, to you too
[08:51] <siretart> merry xmas to you all!
[08:51] <siretart> does anyone happen to have an older version of xserver-xorg-driver-ati than xserver-xorg-driver-ati_<IP_ADDRESS>-0ubuntu1_i386?
[08:55] <\sh> whiprush: your christmas present is on its way :)
[08:55] <whiprush> heh
[08:56] <\sh> ah well...dapper-changes message is already there :)
[08:58] <whiprush> heh
[08:58] <whiprush> neato, thanks!
[08:59] <\sh> ok..guys ... have some nice presents...nice celebrations :) cu later these days :)
[09:17] <xhaker> siretart, i got xserver-xorg-driver-ati_6.5.7-0ubuntu3_i386.deb
[10:12] <tseng> lamont: hm i ruled out toolchain on account of it failing the same on breezy chroot
[10:12] <tseng> lamont: and merry christmas, you have the patience of a saint
[10:12] <tseng> :P
[10:22] <BenC> lamont: probably udev
[10:34] <hub> the locales package does not want to install
[10:34] <hub> it is a dapper upgrade from flight CD 2
[10:35] <hub> any take?
[10:37] <tseng> dist-upgrade agaain
[10:37] <slomo> yes... a second try fixed it for me too ;)
[10:38] <hub> I tried it several time
[10:38] <hub> I'll try again
[10:38] <hub> still the same
[10:38] <hub> I tried 2 times in a row
[10:38] <hub> all it says is
[10:38] <hub> dpkg: error processing /var/cache/apt/archives/locales_2.3.7-1_all.deb (--unpack):
[10:38] <hub>  subprocess pre-installation script returned error exit status 1
[10:38] <hub> Errors were encountered while processing:
[10:39] <Sepheebear> its the preinst script
[10:39] <Sepheebear> it doesnt check for the target dir before trying to write a file
[10:39] <hub> oh
[10:39] <hub> so?
[10:39] <hub> is there a workaround?
[10:40] <tseng> (make the directory?)
[10:40] <hub> mpitt email on ubuntu announce was not really clear
[10:40] <hub> which directory?
[10:40] <Sepheebear> yeah: sudo mkdir -p /var/lib/locales/supported.d
[10:40] <Sepheebear> then it goes smoothly again
[10:40] <hub> still
[10:40] <tseng> its not clear because its only a problem with dapper -> dapper
[10:41] <tseng> which isnt supported
[10:41] <hub> yeah I knoe
[10:41] <Sepheebear> bugzilla #21419
[10:42] <hub> sure
[10:42] <hub> but the mkdir does not do anything
[10:42] <hub> the directory already did exists
[10:44] <Sepheebear> check the output of "dpkg -i /var/cache/apt/archives/locales_2.3.7-1_all.deb"
[11:21] <Gatorade> I have a problem with my live cd can anyone help?
[11:21] <Gatorade> When I load the cd my mouse does not respon
[11:21] <Gatorade> repond*
[11:22] <Gatorade> and the optical lights inside don't work
[11:24] <Gatorade> help
[11:58] <JanC> Gatorade: this is a channel for the developers to work together, try asking on #ubuntu


[01:12] <roadrunner56> I've been having issues with updating in Kubuntu 22.04. I have a Dell XPS 17 9700, and I found in Discover that I had a Dell firmware update. I installed this update, which appeared to update the BIOS successfully. I then booted into Kubuntu and saw that Discover wanted me to restart the computer again so that I could install updates. I did so, but the message to restart was still there. It appears that the updates are not actually
[01:12] <roadrunner56> responding when I restart. Is this a known issue? Are there any workarounds?
[01:15] <roadrunner56> Sorry, I think I disconnected there for a moment.
[07:22] <lordievader> roadrunner56: Not sure if Discover does things differently, but normally in Linux you update your system while it is running. You only need to restart for certain things like kernel updates, kernel module updates, libc, that sort of thing. You could check with `apt list --upgradable` which packages can be upgraded (and upgrade them with `sudo apt full-upgrade`).
[10:40] <iomari891> greetings, I have not been able to find a solution for why my password does not work on lock screen. I'm running kubuntu 22.10 but this starting happening when I was on 22.04. Any suggestions will be greatly appreciated. I currently can only unlock using loginctl on a console.
[12:24] <karstenk> Kernel driver in use: ahci for my intel Sata Controller  when lspci -v and no result when dmesg | grep -i --color ahci .  My rsync is very slow.  Any idea?
 Hi guys. Anyone having problems with krdc? not connecting. it doesn't give an error either.
 2SK0 (re @join_captcha_bot: )
 Hi guys. Anyone having problems with krdc? not connecting. it doesn't give an error either.
[14:06] <BluesKaj> Hi all
 @dralex20 try starting it via terminal and see what happens if you  haven't tried that yet. Might get some error messages that way
 Hello, everyone! I'm on Kubuntu 20.04 and the update tool says my version will no longer be supported in 106 days. That's strange because the long term support states this version will be maintained until 2030. I'm confused.
 Ubuntu flavours are only supported for 3 years (re @rcpp85: Hello, everyone! I'm on Kubuntu 20.04 and the update tool says my version will no longer be supported in 106 days. That's strange because the long term support states this version will be maintained until 2030. I'm confused.)
 https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/Kubuntu#Support_lifespan
 Thank you! I tried finding something on the wiki looking for "LTS" but did not see this note. Could it be because I had 2 bad nights of sleep in a row? Probably! Cheers! (re @RikMills: https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/Kubuntu#Support_lifespan)
 No problem. The context is that main Ubuntu is maintained by the community AND paid employees of Canonical. So they can promise to be mainstained for a long time. Flavours are maintained by community volunteers, so can only really commit to the 2 years between each LTS release + 1 overlap year. (re @rcpp85: Thank you! I tried finding something on the wiki looking for "LTS" but did not see this note. Could it be because I had 2 bad nights of
 No problem. The context is that main Ubuntu is maintained by the community AND paid employees of Canonical. So they can promise to be maintained for a long time. Flavours are maintained by community volunteers, so can only really commit to the 2 years between each LTS release + 1 overlap year. (re @rcpp85: Thank you! I tried finding something on the wiki looking for "LTS" but did not see this note. Could it be because I had 2 bad nights of s
 Makes sense!
 I will see if I upgrade to 22.04 or go to Ubuntu "vanila". I like
 KDE/Plasma a lot, but since this is my work machine, I don't feel too inclined to upgrade that often due issues it can arise with proprietary tools we have to use (hi, ESET!).
 Hello, good afternoon. I have an error when trying to open my safe with CryFS where even if I put my password, it throws an error 9 making it impossible to access the directory, any solution?
 https://irc-attachments.kde.org/34d41e9b/file_62636.jpg
[22:16] <jj5> how can I switch sddm from Wayland back to X11?
[22:18] <jj5> I'm running Ubuntu 22.04 and Wayland doesn't support high resolution on my monitor
[22:23] <oerheks> jj5, logout, change wayland to x11, login again
[22:27] <jj5> in sddm the only option for me is Plasma(X11). But when I login and go to display settings it says that it's running Wayland
[23:53] <skorrborg> Trying to update Kubuntu 20.04 to 22.04. Getting 'Broken packages after upgrade: kubuntu-desktop, ubuntu-desktop' which the release upgrade cannot "mark for upgrade." Looking in the Synaptic pkg mgr ubuntu-desktop version is 1.450.2 and kubuntu-desktop is version 1.398.1. Is there a write-up on this? Need a fix to upgrade. Thanks.


[07:14] <mup> PR snapd#13089 opened: snap: add components field to snap.yaml <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/13089>
[08:04] <mup> PR snapd#13061 closed: o/restart: support for deferred restarting <Created by Meulengracht> <Closed by Meulengracht> <https://github.com/snapcore/snapd/pull/13061>
[08:09] <mup> PR snapd#13090 opened: o/restart: support for deferred restart <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/13090>
[08:54] <mup> PR snapd#13091 opened: daemon: enable --purge on multi-snap remove <Simple 😃> <Needs Documentation -auto-> <Created by ZeyadYasser> <https://github.com/snapcore/snapd/pull/13091>
[16:41] <mup> PR snapd#13092 opened: cmd: detect if -Wno-missing-field-initializers is needed <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/13092>
[17:00] <iomari891> greetings, I'm running low on disk space in my / folder. But I have plenty of space on another drive. How can I move my /snap folder to that drive to free up space? I'm thinking of booting to a live usb then move the snap folder and link it back to /snap then boot back to my ubuntu. Will that work.
[18:18] <mup> PR snapcraft#4327 opened: requirements: update craft-parts to 1.23.1 <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/4327>
[20:39] <mup> PR snapcraft#4297 closed: Rust plugin: rewrite the Rust plugin using the new plugin system <Created by liushuyu> <Closed by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/4297>


[00:29] <bazhang> * trainengine<EMAIL_ADDRESS>has joined #ubuntu
[00:29] <bazhang> heads up
[00:33] <bazhang> * Snardbafulators<EMAIL_ADDRESS>has joined #ubuntu
[00:38] <bazhang> good call on that one. he just spammed a huge amount of personal info in another channel
[00:47] <bazhang> just got the same PM spam from that user
 im sorry why am i getting offtopic harrassment again?
[00:59] <bazhang> getting called on being OT is harassment?
[01:00] <IdleOne> the cool thing to do now when you get told about something is to cry harassment
[03:06] <bazhang> avis hi
[03:15] <bazhang> avis are you there? did you need help with something?
[03:51] <okfinethan> Hey apparently i've managed to offend someone in #ubuntu and i'd like to try and solve this issue as that channel is indespensible usually.
[03:51] <okfinethan> although tolerance for an extra word or two about a subject outside of the scope of what other people think is ubuntu related chat is immediately warrenting a !ot
[03:52] <okfinethan> i clearly didnt get this memo.
[03:52] <okfinethan> im sorry if i sound a bit ragey.
[03:53] <bwat47> there's a dude spamming the ubuntu support channel
[03:54] <bwat47> (11:52:54 PM) sluh: someone use elite google skills and find a free d/l of Juvenile - Back That Ass Up.mp3
[03:54] <okfinethan> and they're not banned?
[03:54] <bwat47> 11:48:01 PM) sluh: who wants to jerk off together to 3 Guys 1 Hammer while we listen to: Duran Duran - girls on film
[03:54] <okfinethan> are you kidding me.
[03:54] <bwat47> apparently not
[03:54] <okfinethan> I go off topic for one bloody sentence and get grumpy about it and im banned.
[03:54] <okfinethan> I think i dropped an single fbomb.
[03:55] <okfinethan> i didnt know children knew how to use irc hence my figuring it was fine to curse.
[03:55] <okfinethan> I wasnt even trying to offend anyone.
[03:55] <genii-around> bwat47: They left
[03:55] <bwat47> k
[03:56] <genii-around> bwat47: Better to use !ops problemdescription from the channel , faster response
[03:56] <bwat47> thanks, didn't know about that
[03:58] <okfinethan> is there anything that I can do about this problem?
[04:01] <okfinethan> I've got no issues just giving up on this and leaving if someone provides me a decent response to this.
[04:02] <okfinethan> im not trying to troll here I just installed this distro again for the first time in a while and would like to speak with some people about it.
[05:50] <IdleOne> avis: Can we help you?
[05:52] <IdleOne> avis: We don't allow idling in this channel. Please tell us how we can help you or part this channel.
 Is the Raspberry Pi Supported here
[13:59] <bazhang> does that run ubuntu yet?
[13:59] <Tm_T> we don't support hardware, if that was the question
[14:05] <bazhang> he never joined #raspberrypi
[14:16] <bazhang> he's just fishing/random questions
[14:16] <ikonia> agreed, looking at ##hardware also
[14:49] <bazhang> heads up on tuxythe penguin; he's basically admitted to trolling/time-wasting being too lazy to search for these very easy to find things
[14:49] <ikonia> bazhang: where ?
[14:50] <bazhang> ikonia, in ##hardware
[14:50] <ikonia> great
[14:51] <Fuchs> looking at him in #ubuntu-offtopic, trolling seems reasonable
[14:58] <IdleOne> The only way they could make the installer easier is if Canonical sends someone to your house to install it for you, and stay for a week to make sure you know how to use your shinny new OS
[14:58] <IdleOne> You will have to have an ample supply of cookies and bacon.
[15:09] <DJones> And cake
[15:11] <bazhang> what's with all the free-speechers of late
[15:12] <IdleOne> presidential elections coming up, people get all First Amendment and stuff
[15:12] <bazhang> * benjamingwynn has quit (Quit: See ya later shit lords!)
[15:14] <oCean> awww :(
[15:15] <ikonia> should ubottu be looking at 12.04 repos in #ubuntu+1 ?
[15:19] <IdleOne> no
[15:20] <ikonia> I thought not
[15:29] <ikonia> hello avis
[15:51] <ikonia> avis: can you respond please
[15:56] <Chamunks> hey can i get myself unbanned yet on #ubuntu?
[15:56] <Chamunks> is there a way to appeal bans.
[15:56] <IdleOne> hello Chamunks
[15:56] <IdleOne> There is a way, you are doing it now :)
[15:56] <Chamunks> i know i was a bit grumpy yesterday i apologize about my foul language.
[15:56] <Chamunks> I'm just used to the old #ubuntu
[15:57] <IdleOne> Chamunks: The reason I banned you yesterday was not because of the off topic chit chat, but because you chose to swear and rage at the channel for letting you know you were off topic.
[15:57] <ikonia> #ubuntu has never allowed bad language
[15:57] <Chamunks> way back it was tolerated.
[15:57] <IdleOne> never
[15:57] <IdleOne> not in the 7 years i have been using it
[15:57] <Tm_T> ^
[15:57] <Chamunks> maybe i've just seen it when the "ops were asleep" as some call it.
[15:58] <Chamunks> but i've not really gone out of my way to offend people there before.
[15:58] <IdleOne> mice play...
[15:58] <Chamunks> either way.
[15:58] <Tm_T> there's no excuse for bad behaviour, as I've used to say
[15:58] <Chamunks> i've just been kindof grumpy because at the speed which people seem to jump at you in #ubuntu these days to keep the channel from being flooded with ot chat.
[15:59] <ikonia> so don't chat offtopic stuff ?
[15:59] <ikonia> if you know people jump on you for doing it....don't do it
[15:59] <Chamunks> ok but you see
[15:59] <IdleOne> Chamunks: Anyway, you stated yesterday that you were using Mint and were going on and on about some hardware (graphics?) topic which had nothing to do with Ubuntu. I think we allowed you a lot of room to chat, but at some point we do have to stop it or the channel becomes unusable.
[15:59] <Chamunks> i was only offtopic for like a sentence or two
[15:59] <Chamunks> and immediately
[15:59] <Chamunks> i was getting !ot'd
[15:59] <ikonia> Chamunks: then don't be offtopic for a sentence or two
[15:59] <ikonia> it's a really simple solution
[16:00] <Chamunks> well the thing is
[16:00] <IdleOne> Chamunks: it sucks that we have to be so strict about it.
[16:00] <IdleOne> if we aren't people abuse.
[16:00] <Chamunks> no i get it.
[16:00] <ikonia> I do'nt think it sucks
[16:00] <ikonia> I don't want to hear about you downloading torrents for friends
[16:00] <ikonia> I don't care
[16:00] <Chamunks> i admin some gaming servers i hate telling kids to obey silly rules
[16:00] <ikonia> I want to help people having a problem
[16:00] <Chamunks> there there to have fun bla bla but anyways.
[16:01] <Chamunks> all that aside its to the point sometimes where when im trying to explain a problem in detail sometimes.
[16:01] <IdleOne> ikonia: what I mean is that I wish we didn't have to enforce the rule at all because people just respect the channel policies from the get.
[16:01] <ikonia> IdleOne: that would be the ideal situation
[16:01] <Chamunks> and im immediately getting an !ot from someone who's not even paying attention to the relevance of the satements im making.
[16:01] <ikonia> Chamunks: then don't be offtopic
[16:01] <ikonia> it's really simple
[16:01] <ikonia> if you don't want to get told "don't be offtopic" - don't be offtopic
[16:02] <IdleOne> Chamunks: I'm willing to remove the ban if you are willing to follow the channel guidelines
[16:02] <IdleOne> !guidelines
[16:02] <Chamunks> ikonia, could you please read my last message instead of just repeating yourself?
[16:02] <ikonia> Chamunks: I did
[16:02] <ikonia> it doesn't change the situation
[16:02] <Chamunks> im not retarded i understand the situation and i understand what not to do.
[16:02] <ikonia> great, so why are you making pointless comments
[16:02] <IdleOne> Chamunks: nobody said anything of the sort
[16:02] <ikonia> you understnad, problem solved
[16:03] <Chamunks> ok well anyways
[16:03] <IdleOne> Chamunks: Can you agree to follow the guidelines that are linked a couple lines up?
[16:04] <Chamunks> IdleOne,  yeah i'm going to read those carefully this time.
[16:04] <IdleOne> Please read them if you haven't. I don't want to have to ban you again for something and then have you say "I didn't know"
[16:04] <Chamunks> oh its not that i didnt know
[16:04] <Chamunks> i know i should never be a foul mouthed child about things i was just grumpy about it and i apologize.
[16:05] <IdleOne> happens to the best of us. So, you agree to follow the guidelines?
[16:05] <Chamunks> absolutely
[16:05] <IdleOne> gimme a minute please
[16:06] <Chamunks> #ubuntu is still a pretty expedient and helpful place for solving the i've been googling too long eyes.
[16:06] <IdleOne> You should be able to rejoin #ubuntu now. have a great day.
[16:06] <Chamunks> cheers
[16:06] <IdleOne> Please part this channel. :)
[16:07] <IdleOne> heh
[17:48] <Tm_T> avis: hello?
[19:30] <Myrtti> !cloak
[19:30] <Myrtti> !cloak > sleax