[00:00] <jelmer> helloooo spiv
[00:05] <spiv> Hey, go enjoy your weekend while you still have it :P
[00:05] <spiv> Morning poolie
[00:09] <poolie> hi there spiv
[00:17]  * jelmer waves from DebConf
[00:17] <poolie> hi jelmer
[00:17] <poolie> have fun
[01:32] <spm> heya jelmer
[01:42] <poolie> spiv, so you're going to be pilot this week?
[01:43] <spiv> Apparently so! :)
[01:47] <poolie> it's negotiable :)
[01:55] <kgoetz> jelmer: in bug 811460 you link me to bug 811460. is 811460 a  'please allow import-dsc to only bring in debian/' , or would that be a separate issue?
[01:55] <kgoetz> oh, i pated it three times
[01:55] <kgoetz> bug 331986  is what the send and third references were meant to be
[03:02] <thomi> Hi, I've just proposed a merge (https://code.launchpad.net/~thomir/bzr/fig-bug-747958/+merge/69023) to fix bug #747958. I'd welcome any feedback.
[03:11] <poolie> thanks for the patch thomi, i'll have a look after lunch, or spiv will
[03:40] <kgoetz> can bzr compress its repo? or parts of its repo? i've not found anything obvious in the commands list
[03:52] <spiv> kgoetz: it's already compressed (and it automatically repacks it gradually from time-to-time to keep it well compressed)
[03:53] <spiv> kgoetz: but you can use 'bzr pack' to trigger that manually, although it's unusual to do so.
[03:57] <kgoetz> spiv: ok. i'll just put up with it then.
[04:47] <poolie> kgoetz: 'put up with'...?
[04:50] <kgoetz> poolie: 870kb of .bzr when i have 8kb of text 'top level' (it tar cjf's down to 250k, so i thought some of the old history might be properly compressable. other then historical interest itsnot useful for reference anymore)
[05:07] <poolie> kgoetz: you can see if there are files in obsolete_packs
[05:07] <poolie> they can safely be deleted
[05:07] <poolie> bzr will delete them itself later
[05:39] <lifeless> jelmer: given you're patching lp, you might like to idle in #launchpad-dev
[05:39] <lifeless> jelmer: we're talking sprdata atm :>
[06:08] <poolie> spiv i might send my einval patch to 2.4
[06:26] <kgoetz> oh, poolies gone
[06:26] <kgoetz> well, thanks for the tip :)
[06:26] <kgoetz> half the repo size is obsolete_packs
[06:27] <bob2> it'll get cleared up shortly-ish
[06:27] <kgoetz> if bzr handles it i'll leve them alone. thanks
[06:27] <lifeless> every 10 commits at most
[06:29] <bob2> hm, i thought it only stuck around at all to avoid races
[06:29] <spiv> bob2: sure, but we don't check obsolete_packs on every write to the repo, just on every repacking of it.
[06:30] <AfC> spiv: why not? Once the repack is done, why further waste the disk space?
[06:30] <lifeless> AfC: many popular OSes lie about persistence, and / or have no cheap way to record that something matters without triggering immediate IO
[06:31] <bob2> spiv: ahhh, right
[06:31] <lifeless> bob2: checking on every write would itself be a race condition :>
[06:32] <kgoetz> i've seen the $magic happen every 10 commits. i'm on 172 atm, so i'll see what happens in 8 commits (:
[06:32] <lifeless> kgoetz: is this a project with many (k's) or large (10's of MB's or more) files ?
[06:35] <kgoetz> lifeless: no, nothing like it. its my cv. formerly (until 3 commits ago) stored in xml (+~20 supporting files), now in rst
[06:35] <kgoetz> lifeless: so two files, one 8kb one 1kb
[06:35] <kgoetz> got to dash, catch you later
[06:35] <kgoetz> and thanks for the help :)
[06:36] <lifeless> kgoetz: so thats why 50% space is in the obsolete packs
[06:37] <lifeless> kgoetz: because your data is small, and the individual commits don't contain compressed data - its only as they repack that compression happens.
[06:37] <lifeless> kgoetz: obsolete_packs isn't transmitted on push/pull.
[06:45] <KombuchaKip> Is it possible to just commit a portion of the changes of a modified working branch to the checkout branch? e.g. just the contents of one subdirectory, as opposed to them all that have changed.
[06:45] <spiv> lifeless: can I ask a favour?  I have an approved branch for bzr-builddeb, but it turns out I'm not in the (moderated) team that can commit to it and you are.  Would you mind pushing lp:~spiv/bzr-builddeb/trunk-merge-of-use-dpkg-mergechangelogs to trunk?
[06:46] <spiv> lifeless: normally I'd just join the team, but I'm fairly sure this is the last change I'll be making to that code :)
[06:46] <poolie> KombuchaKip: sure, just 'commit SUBDIR'
[06:46] <KombuchaKip> poolie: Roger. Thanks.
[06:46] <KombuchaKip> poolie: What about if I've unbound and I rebind to the upstream? Still ok to do that?
[06:47] <poolie> hm
[06:47] <poolie> commit makes a new revision on whatever branch the tree addresses at the time you run it
[06:47] <poolie> what's the concern?
[06:48] <KombuchaKip> poolie: If I've made many commits to my unbound local branch, when I rebind and commit to upstream, will the upstreams revision number be incremented just by one, or by N, N being the number of local commits I've made since unbinding?
[06:49] <poolie> you will make one new upstream commit (which will be numbered N+1) which will be a merge of all your local commits
[06:49] <poolie> it doesn't matter what's in the comimts
[06:54] <jam1> poolie: /wave
[06:55] <poolie> hi jam
[06:55] <jam1> I'm feeling a bit ill today, so I'm probably going to be a bit in-and-out.
[06:55] <jam1> But I figured I could say hi, at least.
[06:55] <poolie> i'm finishing the fdatasync branch
[06:55] <poolie> sorry to hear that; it's nice to see you
[06:56] <poolie> hm if this is always on, it's probably going to slow down the test suite on magnetic disks
[06:56] <jam> anyway, off to take the kid to school, I'll see you in a bit
[06:56] <KombuchaKip> poolie: Thanks.
[07:21] <lifeless> spiv: am really EODish now, but will dig around for a branch etc tomorrow if jelmer doesn't do it.
[07:21] <spiv> lifeless: thanks!
[07:43]  * jelmer waves
[07:44] <thomi> poolie: thanks for the feedback - I've made the changes and re-pushed.
[07:44] <poolie> thanks thomi
[07:44] <thomi> no worries. It'll be good to get that fixed... means I can clean up some work-around code in sloecode :)
[07:48] <poolie> cool
[07:49] <spiv> thomi: thanks for returning to that bug!
[07:49] <poolie> what was the selftest error you got?
[07:49] <poolie> you can file a bug or question for that
[07:49] <poolie> it's supposed to be clean, or at least to give a clean message if you're missing something we need
[07:49] <thomi> spiv: it snowed, so I couldn't go to work. I was bored ;)
[07:52] <spiv> thomi: I hope it snows more often then ;)
[07:53] <thomi> I'm browsing the bzr bug list right now. Can't find any more easy looking ones though ;)
[07:53] <thomi> Although I regularly run into #82555
[07:58] <poolie> thomi there are some bugs tagged easy
[07:58] <poolie> bug 82555
[07:59] <jelmer> spiv: while you're looking at bzr-builddeb, can you perhaps review https://code.launchpad.net/~jelmer/bzr-builddeb/contains-upstream-source/+merge/69017? It's a one line change (and some tests)
[08:02] <spiv> jelmer: done!
[08:02] <jelmer> thanks :)
[08:06] <poolie> thomi: i have an easy fun useful bug which is to add a system-wide configuration file
[08:06] <poolie> you just need to arrange for it to be opened and then to go into the Stack objects in config.py
[08:08] <Riddell> hola chicos
[08:08] <poolie> och aye
[08:09] <spiv> salut
[08:10] <spiv> jelmer: if you could land my bzr-builddeb change that'd be great (should just be a simple push, see mp comments)
[08:10]  * spiv is done for the day.
[08:15] <jelmer> spiv: will do
[08:27] <jo-erlend> dch keeps adding username@hostname instead of using my email address. Where do I configure that?
[08:27] <poolie> EMAIL or DEBEMAIL should do it?
[08:27] <jo-erlend> no configuration file?
[08:28] <Riddell> no
[08:35] <mgz> morning all!
[08:39] <poolie> hi mgz
[08:39] <poolie> i'm just reading your test patch
[08:39] <poolie> it sounds good
[08:40] <mgz> hey poolie
[09:20] <poolie> mgz i might have another go at https://code.launchpad.net/~mbp/bzr/test-errors/+merge/64485
[09:20] <poolie> thanks for narrowing it down
[09:27]  * fullermd slaps qdiff for not having any exit function.
[09:37] <jimis> jelmer: you had told me lp:gcc has about 2K tags... More like 200K it seems :-) http://launchpadlibrarian.net/73597623/vcs-imports-gcc-trunk.log
[09:50] <jelmer> jimis: the numbers there are a progress indicator
[09:50] <jelmer> jimis: it's the number of revisions
[10:00] <jimis> jelmer: I see, it was too much to be real :-)
[10:04] <kgoetz> lifeless: thanks for rthe info above
[10:23] <maxb> Gah. The new package branch up-to-dateness checking throws an exception in foreign branches
[10:27] <jelmer> maxb: that shouldbe fixed in the foreign branch plugins
[10:29] <maxb> Seems like a workaround in the new code would be the friendly thing to do, to avoid making compatibility more bumpy than it needs to be
[10:30] <jelmer> well, arguably this was a big in the foreign branch plugins
[10:31] <jelmer> *bug
[10:42] <jimis> can I permanently set (with some config file) the option --diff-options=-p?
[10:50] <jelmer> jimis: you can set an alias for diff that sets that option
[10:50] <jelmer> see 'bzr help alias'
[10:50] <jam> jimis: bzr alias diff="diff --diff-options=-p"
[10:58] <jimis> thanks
[11:07] <jimis> Is there a way to apply a specific commit from another branch?
[11:08] <jelmer> jimis: bzr merge -c REVNUM BRANCH
[11:10] <jimis> jelmer: thanks, I was using merge -r and I got all changes until that revision :-)
[11:12] <jimis> "bzr help merge" is not clear about the difference
[14:31] <notmyname> Is there any estimated timeframe for getting OS X (py2.7) installers up?
[15:51] <mgz> afternoon.
[16:16] <jelmer> hi mgz
[17:34] <lxsameer> what is the difference between bzr pull and bzr merge
[17:42] <LeoNerd> pull is for updating when you are strictly-behind in progress
[17:43] <LeoNerd> merge is for re-combining two divergent trees of history.
[17:59] <Anteru> Hi
[18:00] <Anteru> What representations of the file contents exist in bzr at run-time? Is it only passed around as plain strings in-memory, or is there some stream-based abstraction somewhere?
[18:05] <mgz> they tend to be passed around as chunks, but still tend to be held in entirety in memory
[18:05] <Anteru> Hm
[18:05] <mgz> there are a bunch of different problems on the really-big-files angle
[18:06] <Anteru> Yeah, I start to understand what's going on.
[18:07] <Anteru> I assume having a real "chunk" class which can convert to string if required but tries not to would require an extensive rewrite?
[18:09] <mgz> perhaps not, part of the issue with the content filtering line you're trying is that they've just not been widely used yet,
[18:09] <mgz> so there are probably a whole bunch of little issues that need ironing out with the core bzr code
[18:10] <mgz> big files generally don't work well because there's no benefit using any of the VCS techniques on them
[18:10] <Anteru> Hm. I'll be trying to get a prototype working which side-steps the issue and handles large-files manually (using a stream approach) but it would be much easier if the content filter wouldn't get the complete file contents as input.
[18:11] <Anteru> Yeah, I see your point, that's why I thought that a thin wrapper which behaves like a string but optionally allows you to query the size would be the easiest/fastest-to-add solution.
[18:11] <Anteru> In 99% of the cases, you would just pass it around but if needed, you could try to use the stream interface (diff, content filters.)
[18:12] <Anteru> For instance, I'm using a checkout with Bzr to store large binary files.
[18:12] <mgz> yeah, and you (and others on the mailing list) are right that there are benefits from being able to keep your not-usefully-versioned files in the repo along with the rest of the stuff
[18:13] <mgz> I wonder if you could get your code working against the current chunks interface, then see what changes would be needed to work against an iterable rather than a list
[18:13] <Anteru> Ok
[18:13] <Anteru> The problem with the chunks interface is that I'll be storing only a hash in the file so I can keep the binary blobs completely off the repository.
[18:14] <Anteru> This is going to be a glorified hack which creates the bin files on update and uses a pre-commit hook to check/update the hash file.
[18:14] <jelmer> 'evening Anteru, mgz
[18:14] <Anteru> Evening jelmer
[18:15]  * mgz waves at jelmer
[18:19] <Anteru> Anyone here who developed a plugin on Windows?
[18:20] <jelmer> Anteru: it shouldn't be all that different than on linux
[18:20] <Anteru> I'm wondering how to debug it; tried to print from the plugin but either it doesn't get called or the print goes elsewhere.
[18:20] <Anteru> And I can't get PyDev/Eclipse to run bzr commands ... should I get bzr source + a python 2.6 interpreter?
[18:23] <mgz> trace.mutteras you noted in your list post plus tail on .bzr.log should work
[18:23] <Anteru> Thanks
[18:50] <timrc> I think "bzr duff" should return ascii art of Duff beer
[18:51] <mgz> you could write a plugin for that :P
[18:52]  * timrc is tempted
[18:53] <jelmer> timrc: I think it should punish you as well, by making you wait - like sl
[18:57] <timrc> jelmer, lol.. the sad truth is, sometimes I find myself intentionally typing 'sl'
[22:22] <poolie> hi all
[22:46] <teratorn> any way to remove a tag from a local commit?
[22:47] <teratorn> ah, I found it
[22:58] <jelmer> hey poolie
[22:59] <poolie> hi jelmer


[14:18] <jrwren> User INterface Freeze? I don't remember these in years past.
[14:18] <cmaloney> for 18.04?
[14:18] <cmaloney> or something else?
[14:27] <hpucks> Wouldn't surprise me.  This is the first LTS release without Unity in what?  Five years?  Something like that.
[14:28] <Scary_Guy> good, now if we can just get rid of gnome and KDE that would be amazing
[14:28] <Scary_Guy> small DE's FTW
[14:29] <Scary_Guy> unless we're talking about VR, then sure make it pretty
[14:33] <hpucks> I've been using 17.10 with gnome, I don't hate it.  Seems like they tried to recreate the functionality of Unity in Gnome.
[14:35] <jrwren> yes, 18.04 did User Interface Freeze, I just don't remember it in yeras passed.
[14:35] <Scary_Guy> exactly, that's why they made MATE, because they hated what Gnome became
[14:36] <jrwren> I hate any UI which removed the menu. Hiding it, as is hte case for web browsers is an acceptable alternative.
[14:37] <jrwren> `File Edit View Window Help` is such a well known UI, it is inexcusable to throw it away without strong justification.
[14:39] <Scary_Guy> I think a lot of people want to part from that because it seems antiquated to them and they want to "revolutionise the UX" or some crap
[14:39] <jrwren> That is fine. Let them, as long as they know that they are experimenting in UX
[14:40] <Scary_Guy> the menu is like it is because it works.  fine make it dynamic like Apple but at least leave it in there
[14:40] <jrwren> when gnome.org claims, "An easy and elegant way to use your computer, GNOME 3 is designed to put you in control and get things done."  and then ignores 30 yrs of UI and throws familiarity out the window, they should admit their hypocracy.
[14:44] <Scary_Guy> that and everything is a bloated memory hog too.  https://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/
[14:44] <Scary_Guy> although that is a bit out of date now
[14:45] <jrwren> i love how e17 is listed. e used to be the most bloated.
[14:47] <jrwren> that article you linked uses "free" to measure ram before and after. That is rather pointless.
[14:47] <jrwren> unused ram is wasted ram.
[14:47] <jrwren> linux bufcache and mmap make "free" a useless tool for this type of analysis.
[14:47] <jrwren> All numbers in that article should be ignored.
[14:49] <Scary_Guy> https://www.linuxquestions.org/questions/slackware-14/linux-distros-ram-consumption-comparison-4175609369/ this one is more up to date
[15:11] <jrwren> again using free output. not very useful.
[15:11] <jrwren> yay, people in that thread saying the same thing.


[00:22] <axw> wallyworld: gtg take kids to school, can you please babysit https://github.com/juju/juju/pull/6996 and let sinzui know if/when it's landed?
[00:23] <wallyworld> axw: wil do, i'll also forward port to develop
[00:33] <anastasiamac> PR 6996 and 6998 landed. wallyworld, thumper, menn0, axw, sinzui - rc2 is good to go, right?
[00:34] <wallyworld> anastasiamac: yeah, i just let sinzui know in #juju
[00:34] <wallyworld> one step pahead of you :-P
[00:34] <menn0> nice
[00:34]  * wallyworld merges 2.1 into develop
[00:35] <anastasiamac> wallyworld: one step and probably many years :D
[00:35] <wallyworld> :-( :-( :-(
[00:35] <wallyworld> about 9 :-(
[00:36] <anastasiamac> just keep "experienced" in mind
[00:36] <anastasiamac> :D
[00:36] <anastasiamac> and hey! I am still somewhere in my 20s \o/
[00:37] <wallyworld> sinzui: wait
[00:37] <wallyworld> looks like the merge was done into 2.2 branch
[00:37] <wallyworld> let me check
[00:38] <wallyworld> sinzui: yeah it was :-(
[00:38] <wallyworld> i'll have to quickly backport
[01:04] <axw> doh
[01:05] <axw> wallyworld: sorry, didn't notice that
[01:05] <wallyworld> axw: no worries, backporting now but lots of conflicts to sort out, i'll propose soon, just getting tests to pass
[01:38] <wallyworld> axw: i have a failing test in tools/lxdclient. it may be due to the changed socket stuff? i've resolved all the conflicts, diff looks ok, local lxd provider test with IP4 is ok. you may know immediately what issue is? https://github.com/juju/juju/compare/2.1...wallyworld:backport-pr-6996?expand=1
[01:38]  * axw looks
[01:38] <axw> wallyworld: pastebin the failure?
[01:39] <wallyworld> axw: http://pastebin.ubuntu.com/24010792/
[01:40] <wallyworld> ipv6
[01:40] <wallyworld> code looks ok to me at first glance
[01:40] <wallyworld> there's a bit there in fixAddr to sort out IPv6
[01:41] <axw> wallyworld: fixAddr isn't even used? :/
[01:42] <axw> wallyworld: delete addserver*.go I think
[01:42] <wallyworld> axw: huh, yeah, i think you're right
[01:42] <wallyworld> hmmmm
[01:44] <wallyworld> axw: doesn't appear used in develop branch either
[01:44] <axw> wallyworld: chop it. I've never come across it before
[01:45] <axw> hasn't been touched since 2015
[01:47] <wallyworld> axw: https://github.com/juju/juju/pull/6999
[01:49] <wallyworld> thumper: free for 1:1?
[01:49] <thumper> yeha
[01:50] <axw> wallyworld: LGTM, thanks
[01:50] <wallyworld> yay
[01:51] <wallyworld> axw: talking to tim so will be late for 1:1
[01:57] <axw> wallyworld: np, ping when
[02:14] <wallyworld> axw: free now
[02:14] <axw> wallyworld: just a minute
[02:30] <babbageclunk> thumper: easy review? https://github.com/juju/juju/pull/7000
[02:37]  * thumper looks
[02:38] <menn0> axw: i'm still looking but goswagger is looking like the best fit so far
[02:38] <thumper> babbageclunk: code looks fine, but left a comment for you to check
[02:39] <axw> menn0: it would be great if that can be made to work, it's pretty much the de facto standard now
[02:39] <babbageclunk> thumper: thanks
[02:39] <axw> menn0: are there any existing examples of mapping between RPC-style and REST-style with it?
[02:40] <menn0> axw: for the existing rpc API I'm wondering about either generating it from the same swagger yaml or having an RPC to REST layer
[02:41] <axw> menn0: not sure, I have no hands on experience
[02:42] <babbageclunk> thumper: yeah, I tried that as well, it worked fine.
[02:43] <thumper> ok, lgtm
[02:47] <axw> menn0: somewhat related: https://github.com/OAI/OpenAPI-Specification/issues/523
[03:03] <axw> menn0 babbageclunk: did either of you fix some proxy related bugs recently? anything that would affect bootstrap on lxd?
[03:04] <menn0> axw: babbageclunk did make some proxy fixes recently. not sure how they would affect bootstrap though. what's happening?
[03:04] <axw> menn0: https://bugs.launchpad.net/juju/+bug/1633788/comments/30
[03:05] <mup> Bug #1633788: juju 2.0.0 bootstrap to lxd fails (connect to wrong "remote" IP address) <canonical-is> <juju> <lxd> <lxd-provider> <s390x> <uosci> <OpenStack Charm Test Infra:Confirmed for 1chb1n> <juju:Fix Released by axwalk> <https://launchpad.net/bugs/1633788>
[03:05] <axw> menn0: 2017-02-16 12:00:56 ERROR cmd supercommand.go:458 new environ: Get https://<IP_ADDRESS>:8443/1.0: Service Unavailable
[03:06] <axw> menn0: AFAICS, lxd won't return 503. so I'm thinking it's going through the proxy
[03:06] <menn0> axw: I don't think the proxy settings would ever have been used during bootstrap b/c the proxyupdater worker doesn't run during bootstrap
[03:07] <axw> I just tested, but now I realise I didn't set https_proxy, only http_proxy
[03:07] <axw> hmm ok
[03:08] <babbageclunk> it should use the http_proxy for https if there's no https_proxy set.
[03:09] <babbageclunk> menn0: would the proxy settings be set in the env for jujud after bootstrap?
[03:10] <axw> babbageclunk menn0: looks like we do set the proxy settings in cloud-init
[03:11] <axw> babbageclunk menn0: so they would also affect the bootstrap command
[03:11] <babbageclunk> axw: gah, that'll be it then.
[03:13] <babbageclunk> axw: I think you could fix it by initialising juju/juju/utils/proxy.DefaultConfig utils.proxy.DetectProxies()
[03:13] <babbageclunk> want me to do a diff for it?
[03:14] <axw> babbageclunk: what will that do?
[03:15] <babbageclunk> It will set the initial values of the proxy config to whatever's in the env vars.
[03:19] <babbageclunk> axw: Then after that any changes can be made from the proxyupdater.
[03:19] <axw> babbageclunk: that sounds sane I think
[03:20] <axw> babbageclunk: if you would, that'd be good - thanks
[03:25] <babbageclunk> axw: what should I do about an error from initialising a package variable? There's probably no logging available and panicking seems nasty.
[03:26] <axw> babbageclunk: can we just do it in cmd/jujud/main.go, and error out if it fails?
[03:26] <axw> babbageclunk: before we install the proxy thing into the default transport?
[03:28] <babbageclunk> axw: yeah, sounds good
[03:36] <babbageclunk> axw: I'll make the PR against 2.1
[03:42] <babbageclunk> axw: https://github.com/juju/juju/pull/7002
[03:42] <babbageclunk> axw: trying it out here
[03:51] <babbageclunk> axw: Sorry I missed that - because the original problem was about cached env vars, my QA steps were "bootstrap without proxy set up, deploy something, set proxy, deploy something else"
[03:51] <babbageclunk> axw: I should've thought to check bootstrapping with proxy
[03:51] <axw> babbageclunk: all good
[03:51] <babbageclunk> axw: also, menn0 misled me. :)
[03:51] <axw> this is why we have RCs :)
[03:52] <menn0> babbageclunk: wat?! :)
[03:54] <babbageclunk> menn0: well, I should've checked anyway
[03:55] <babbageclunk> axw: so should I ping sinzui so he knows that this should be included in the release?
[03:56] <axw> babbageclunk: wouldn't hurt, I'm not sure if it's too late
[03:56] <menn0> babbageclunk, axw: it just occurred to me that what might be confusing to people is that if they bootstrap with --config http_proxy=.... but with $http_proxy not set on the host machine, that proxy on the command line isn't going to get used
[03:57] <menn0> I guess that's ok
[03:57] <menn0> you don't necessary want the client doing the bootstrap to use the same proxy as the juju deployment
[03:57] <axw> menn0: I think we need to support that case too. i.e. the client goes direct, but the env goes thru proxy
[03:57] <axw> right
[03:58] <sinzui>  babbageclunk change the proxy config after deploy and expect it to be honoured?
[03:58] <babbageclunk> sinzui: oh hai
[03:58] <babbageclunk> sinzui: wasn't expecting you to be up
[03:59] <sinzui> I was just checking in on the possible last commit
[04:00] <babbageclunk> sinzui: axw just pointed out a comment that showed my proxy fix didn't work with bootstrapping.
[04:00] <babbageclunk> sinzui: the fix is building now
[04:00] <babbageclunk> sinzui: is it too late?
[04:01] <sinzui> babbageclunk: building as in not merged?
[04:01] <axw> babbageclunk: it's not 100% clear that's the issue there, but it will be in other scenarios at least
[04:01] <babbageclunk> axw: true
[04:01] <babbageclunk> sinzui: yes
[04:01] <babbageclunk> sinzui: https://github.com/juju/juju/pull/7002
[04:02] <sinzui> babbageclunk: :/
[04:02] <babbageclunk> sinzui: sorry :(
[04:02] <sinzui> babbageclunk: not too late.
[04:07] <sinzui> babbageclunk: The maas I was worked about is still up so I hope all eill be tested when I wake. I expect to need to reest a few bad substrates like a maas or azure
[04:33] <babbageclunk> sinzui: it's landed on 2.1 now
[04:34] <sinzui> thank you babbageclunk . I ma still reetting a maas so that you branch will pass first time
[04:35] <sinzui> though I think I just worked out how the maas 1.9 is breaking. the squid might be omming
[04:49] <babbageclunk> the squid might be nomming. On some Patagonian toothfish or something.
[05:16] <wallyworld> babbageclunk: your latest PR just missed my forward port of 2.1 into develop
[06:06] <babbageclunk> wallyworld: ok - I'll pull it forward into develop now
[06:39] <babbageclunk> wallyworld: ping?
[06:42] <wallyworld> babbageclunk: hey
[06:43] <babbageclunk> wallyworld: sorry - was having trouble with a merge but I think I sorted it - magit was leading me astray.
[06:43] <wallyworld> no worries, i was just at school pickup
[06:43] <babbageclunk> get anything good?
[06:45] <wallyworld> nope, just a surly 15 year old
[06:45] <wallyworld> axw: lgtm on your pr
[06:46] <axw> wallyworld: ta
[06:46] <babbageclunk> wallyworld: actually, I'm still having trouble. How should I be doing the merge? My branch is reporting heaps of weird differences with develop.
[06:47] <babbageclunk> wallyworld: https://github.com/juju/juju/compare/develop...babbageclunk:merge-proxy-fix?expand=1
[06:47] <wallyworld> i'd use cheery pick
[06:47] <wallyworld> git cherrypick -m 1 <sha>
[06:47] <wallyworld> merge will give you grief
[06:47] <babbageclunk> wallyworld: ah, ok - that's how I'd normally do it, but I thought jam preferred using a merge
[06:48] <babbageclunk> wallyworld: that it is
[06:48] <wallyworld> yeah, i merged 2.1 this morning and it was ok
[06:48] <babbageclunk> wallyworld: ok, cherry picking I can do
[06:48] <wallyworld> for a single commit i tend to cheery pick
[06:48] <wallyworld> but that's just me
[11:51] <perrito666> morning
[14:17] <alexisb_> morning perrito666
[14:19] <perrito666> alexisb_: morning
[16:07] <jam> babbageclunk: so you can cherry pick, but that makes future merges harder
[16:07] <jam> as long as it is 2.1 => develop, I wouldn't try develop => 2.1
[19:28] <babbageclunk> sorry jam, sounds like I just contributed to the problem again then. Next time I need to do it I'll try to pick your brains. It sounds like I should have just accepted the differences it was reporting?
[19:40] <perrito666> I believe EOD/EOW reached me, I am really tired
[19:40] <perrito666> cheers all


[21:41]  * popey waves
[21:44] <mhall119> popey!
[21:47] <mhall119> most activity this channel has seen in a year
[22:05] <popey> sorry. I'll be quiet


[03:35] <RikMills> ahoneybun[m]: was bound to happen
[03:49] <arraybolt3[m]> This gives me even more incentive to continue plastering my PPAs with dire warnings unless I want people to try and use them :P
[14:19] <BluesKaj> Hi all
[15:56] <santa_> good afternoon everyone
[15:58] <santa_> RikMills (and everyone else): FYI in case you are around, I'm going to proceed with frameworks 5.104 for lunar today
 "RikMills (and everyone else..." <- Ok with me


[00:13] <Sarvatt> definitely something to ask in #ubuntu-kernel though, i'm not sure. looks like the only requirement to show it is CONFIG_LOCKDEP but we dont have that set and i dont see what selects it, doesn't seem to be CONFIG_LOCKDEP_SUPPORT though
[00:14] <Sarvatt> hmm FTRACE might disable it
[00:18] <Sarvatt> ilmari: are you having that problem still with xserver 2:1.7.6-2ubuntu7?
[00:19] <ilmari> yes
[00:31]  * ilmari builds a kernel with LOCKDEP, LOCK_STAT and PROVE_LOCKING enabled
[01:22] <ilmari> yeah, now sysrq-d works
[01:24] <ilmari> Sarvatt: thanks
[01:38] <bryceh> Sarvatt, http://www.happyassassin.net/2010/04/27/when-qa-works-x-org-and-memory-leaks-and-crashes-oh-my/
[01:41] <Sarvatt> ignoring the fact it's still broken in F-12/RHEL-6 where they originated from then I guess?
[01:41] <bryceh> hah
[01:42] <RAOF> And as far as I'm aware, the issues with compositing managers *still* haven't been resolved.
[01:42] <RAOF> Unless that changed since yesterday evening.
[01:42] <Sarvatt> it's working fine here now, i added another patch to xorg-edgers a few days ago thats fixing it
[01:42] <bryceh> Sarvatt, you're messin' with his righteousness
[01:43] <RAOF> Sarvatt: Was that the incorrect-but-works-ok patch on xorg-devel?
[01:45] <Sarvatt> bryceh: not trying to sign up to that person's blog to say that, but it sounds like they don't consider it an issue because they don't ship clutter 1.2 with it so the only people reproducing the bug are people compiling things themselves. the crash bug is still there in the server though..
[01:45] <Sarvatt> RAOF: yeah
[01:45] <bryceh> I did find one interesting bit on that post... redhat uses something called 'bodhi' to help with their QA
[01:46] <bryceh> Sarvatt, you're probably right.  that's funny in a way
[01:46] <RAOF> That's their equivalent of *-proposed, IIUC, but it's got a dedicated UI, package karma, and such.
[01:46] <bryceh> bodhi - http://fedoraproject.org/wiki/Bodhi_Guide
[01:46] <bryceh> RAOF, interesting; is that turned on for the whole development process?
[01:47] <bryceh> or is that only used for testing post-release ala our SRU mechanism?
[01:48] <RAOF> bryceh: It's not clear to me.  I don't *think* rawhide goes through bodhi, so it'd be equivalent to our SRU mechanism.
[01:49] <bryceh> kind of reminds me of our http://qa.ubuntu.com/reports/xorg_prop_drivers/
[01:49] <bryceh> kind of a mashup of that and PQM
[01:49] <RAOF> Since when has *that* existed?
[01:50] <RAOF> That's the result of our call for dedicated restricted driver testing?
[01:50] <bryceh> yep
[01:50] <bryceh> sorry, assumed it was general knowledge.  alberto and I have been fielding questions from the testers all release
[01:51] <RAOF> Either there's an X development list I'm not subscribed to or you've been fielding questions in private :0
[01:51] <RAOF> Or maybe while I'm sleeping, I guess :)
[01:51] <bryceh> heh, yeah ara set up a separate mailing list for this
[01:52] <bryceh> which is just as well, a lot of the questions were really pedestrian
[01:52] <bryceh><EMAIL_ADDRESS>[01:52] <bryceh> https://launchpad.net/~xorg-prop-drivers-testers
[01:53] <bryceh> RAOF, you might want to browse through the archives.  This turned out to be a pretty successful little effort
[01:53] <bryceh> I'd suggest repeating it for MM, and maybe even expand it to additional drivers if you'd like
[01:54] <Sarvatt> that fallback testing result list is as expected since the test case had no chance of working in the first place..
[01:54] <bryceh> yeah
[01:55] <bryceh> the test plan needs some tuning up
[01:55] <bryceh> I wrote it back before the alternatives system went in and some things I thought would work ended up not being implemented
[02:02] <RAOF> bryceh: Thanks for that pointer.
[02:06] <bryceh> heh, bug #568475
[02:06] <bryceh> he couldn't take a photo of the screen to show the corruption, so he *drew* it
[02:07] <bryceh> first time I've seen that :-)
[03:49] <rafiyr> bryceh: if you have a moment, take a look at https://launchpad.net/bugs/556761, the ntrig pen support needs a couple lines updated in 10-wacom.conf
[04:30] <Sarvatt> note to self: reboot and make sure you can mount the luks encrypted partition before you move things onto it in the future... :(
[04:44] <RAOF> I've not had *that* particular problem with luks :)
[05:02] <Sarvatt> only thing I can think of was I typoed the passphrase both times while creating it
[05:03] <RAOF> Oh, you can't open it *at all*?
[05:03] <Sarvatt> nope, tried every possible typo I can think of too
[05:04] <RAOF> :(
[05:51] <lapion> ilmari you there ?
[05:59] <lapion> my system can be running for days with tvtime activity the whole time, occasionally using firefox as well, but then if I want to use the update-manager the system crashes.(hangcheck-crash) while updating or getting package information.
[06:02] <lapion> of course I also get the crash on occasions when I am not using the update manager manually, I have never thought of checking if it started up autamatically
[17:55] <Sarvatt> looks like the --with-dri-searchpath change to accommodate gallium isn't ideal, aiglx must be hardcoded to load from /usr/lib/dri and doesn't honor that. for now i'm just keeping things that only have gallium drivers in libgl1-mesa-dri (/usr/lib/dri) as well
[18:19]  * bryceh waves
[18:19] <Sarvatt> morning bryceh
[19:02] <bryceh> Sarvatt, heya I notice RAOF committed a 2:1.7.6-2ubuntu7.1 to git last Saturday with the glx patches and the updated upstream fix
[19:03] <bryceh> Sarvatt, however I don't see signs that a matching SRU was filed, or that it was uploaded to lucid-proposed yet
[19:04] <bryceh> Sarvatt, I'm going to prep an SRU xorg-server today so am wondering if I can just drop that 7.1 or if I'd be stepping on RAOF's toes impolitely if I did that
[19:05] <Sarvatt> i don't know what the deal is with that, fixing savage at the expense of breaking all swrast users again doesn't seem like a good idea to me though :)
[19:06] <bryceh> Sarvatt, how does savage come into this?
[19:07] <Sarvatt> savage had a regression with clutter apps not starting with 2ubuntu7
[19:07] <bryceh> ah
[19:08]  * bryceh boggles at people running clutter on savage
[19:09] <Sarvatt> but swrast is broken with clutter when the server has glx 1.3+ and I can't find anything but clutter people saying its mesa and mesa people saying its clutter's fault
[19:09] <bryceh> heh
[19:10] <bryceh> which means probably either one could be patched but neither wish to do it
[19:12] <Sarvatt> yup :) if it's only savage RAOF was doing it for I'd like to try to fix up savage instead of breaking swrast again which affects a huge amount more people comparatively
[19:13] <bryceh> no my guess is that this was a shot at fixing the memleak without sacrificing glx
[19:13] <bryceh> fortunately he did it on a branch (ubuntu-linux) so looks like I can just do my changes on the main ubuntu branch
[19:14] <Sarvatt> yeah need to ask RAOF what his thoughts are on it, savage is the only regression I have heard of so far
[19:15] <Sarvatt> and that's been broken in many ways with clutter since the beginning :)
[19:16] <bryceh> yeah and there's been a couple corruption bug reports I've seen which resolved when we moved to 1.2
[19:22] <Sarvatt> bryceh: IMO those other SRU's (exa one in there?) should go in first since they're important crash fixes and the glx one is more of a wishlist thing that will probably need more lengthy testing and hold it up
[19:24] <Sarvatt> the exa one is affecting everyone using radeon and the noscript extension that's really popular
[19:24]  * bryceh nods
[19:24] <bryceh> pitti also has one change I'll include
[19:25] <bryceh> Sarvatt, on another topic...  have you looked into packaging -intel 2.11?
[19:26] <Sarvatt> yeah I have been meaning to ask if you think it is something we should put in x-updates, but then I started questioning libdrm updates too and am unsure how much to put in that PPA :)
[19:26]  * bryceh nods
[19:27] <bryceh> do you know if anything besides libdrm needs updated?
[19:27] <bryceh> if it's just libdrm I'd be game to include that
[19:28] <bryceh> but if it starts needing mesa or other bits to be updated, maybe we should skip it and leave it to xorg-edgers
[19:28]  * bryceh breakfasts... bbiab
[19:30] <Sarvatt> nah, libdrm doesn't need to be updated for just intel 2.11
[19:36] <Sarvatt> i'll package it up and upload it to x-updates, mainly I was thinking a PPA that had just libdrm/ddx/mesa stable branch in it would be useful for bug reporters to test against to check for things that need backporting, xorg-edgers is a bit drastic of a change :)
[19:39] <Sarvatt> mesa stable seems safe to me, I mean look at the changes post 7.7.1 :) http://cgit.freedesktop.org/mesa/mesa/log/?h=mesa_7_7_branch
[19:50] <bryceh> yeah a lucid-oriented ppa wouldn't be a bad idea
[19:52] <bryceh> Sarvatt, ignoring the apple stuff, yeah looks like a few things maybe worth backports there
[19:52] <Sarvatt> 2.11 uploaded
[19:53] <bryceh> Sarvatt, key is to be able to tie those fixes to bug reports in LP, else justifying a SRU will be hard
[19:54] <Sarvatt> meego has a copy-fb patch that applies to 2.11 at least :P
[19:58] <Sarvatt> the blobs are pretty important to have in x-updates for sure since installing from the vendors websites doesn't work anymore, i put 195.35.24 in there the other day which is needed to support the whole new generation of cards that just came out
[19:58] <bryceh> I've spoken with nvidia about that, and sounds like they're open to helping us out there
[19:59] <bryceh> dunno about fglrx
[20:03] <bryceh> thanks for uploading 2.11
[20:03]  * bryceh crosses off the todo list
[20:06] <Sarvatt> what are the policies regarding nvidia blob updates in a stable release given that it is unrealistic to keep one version for 3 years with how they do things? makes me wish there was a restricted-updates :)
[20:06] <bjsnider> why couldn't there be a restricted-updates?
[20:11] <Sarvatt> hardy could update from nvidia.com or use envyng or whatever but i can see it being a problem in lucid since by the end of desktop support 6 new generations of cards wont be supported at all
[20:12] <bryceh> Sarvatt, so far the policy has been o/~ no, no no o/~
[20:13] <bryceh> good question though
[20:13] <bryceh> restricted-updates seems a sane idea as well
[20:16] <bjsnider> nvidia sometimes introduces regressions in the blob, like the current problem with hdmi audio, but generally updates are necessary to support new hardware. and that should override other considerations
[20:18] <Sarvatt> having it in the partner repo would be nice
[20:21] <bryceh> maybe the right way is to have each driver update in x-updates as they're available
[20:21] <Sarvatt> i *really* need to move ppa-purge over to python and look into integrating it with things so it purges ppa's on upgrade instead of just disabling them, this seems to be a really big problem with PPAs
[20:21] <bryceh> and if there is an update which is found to be all good, no regression, suggest it for restricted-updates (assuming one was made to exist)
[20:25] <Sarvatt> yeah I was just thinking it would be nice if there were "blessed" ppa's that could be enabled graphically with software sources to make that easier without requiring archive shuffling, but it seems like something that would be right for the partner repo since its proprietary and required with how they do updates. i'm not aware of all of the limitations on partner though
[20:25] <bryceh> me either
[20:25] <bryceh> well, in any case this is totally what I'd had in mind for x-updates
[20:32] <imbrandon> i think i'm bitten by the intel kms bug but i'm not really good at truble shooting X problems , anyone arround to bounce some ideas off from to see if i need to file a new bug or if its an existing one ( i'm fairly confident its the latter but not 100% )
[20:32] <Sarvatt> yeah for sure, same here, it's just the policies for what we put in x-updates that I am sketchy about. We should probably avoid libdrm if at all possible in there since it complicates things (new drivers will require the updated libdrm as well if built against it) but we're at the mercy of upstream there
[20:33] <Sarvatt> like the blob will require the updated libdrm too if its built against it even if it doesn't use it..
[20:33] <bryceh> Sarvatt, true
[20:34] <bryceh> Sarvatt, yeah my original thinking had been drivers-only
[20:34] <bryceh> although esp. with intel, it seems deps change a lot
[20:34] <imbrandon> basicly here is what happens ( lucid upto date laptop as of an hour ago , no special ppa or anything ) , normal boot i get a blank screen after plymouth but before X ( i see plymouth ) , but if i add i915.modeset=1 i can get into X and everything seems normal until i goto play video ( with any player ) X crashes
[20:35] <imbrandon> sooo am i bit by the same bug, isnt there a ppa to fix it , i'm REALLY bad at X trubleshooting
[20:35] <bjsnider> Sarvatt, i don't think the blob is build against libdrm
[20:36] <Sarvatt> imbrandon: sounds like you have a 8xx generation intel? :)
[20:37] <imbrandon> Sarvatt: yes, 845 i think, i can look if it matters
[20:37] <imbrandon> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
[20:37] <Sarvatt> theres no magical PPA that can fix 8xx at the moment unfortunately, it's horribly broken in general everywhere
[20:38] <imbrandon> Sarvatt: ahh ok, so no better work arround than the i915.modeset thing ? is there as bug i can subscribe to to watch ?
[20:38] <Sarvatt> yeah there are quite a few bugs, one sec I'll dig some up
[20:38] <imbrandon> anything i can do to help test ? being a ubuntu dev i'm pretty familiar with the process, just not X ;)
[20:39] <imbrandon> lol
[20:39] <Sarvatt> this will be a problem on any modern distro though, its not ubuntu specific
[20:39] <imbrandon> Sarvatt: yea i figured
[20:39] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/541511
[20:39] <imbrandon> seems like an intel driver thing, but i wasent 100% sure thus comming in here
[20:40] <imbrandon> fix released ?
[20:40] <imbrandon> ohh fixed in the release notes
[20:40] <imbrandon> :)
[20:41] <imbrandon> Sarvatt: great, gives me a place to start, thanks
[20:43] <Sarvatt> imbrandon: the first thing I would try is i915.modeset=1 + manually changing the driver to fbdev in your xorg.conf. you won't have multiple monitors or acceleration but it should work at native resolution. if that has problems I would try without KMS (which is the default) and use the vesa driver
[20:44] <Sarvatt> both options are ugly but if you don't want to use an older release and cant upgrade the GPU there isn't much choice at the moment :(
[20:45] <imbrandon> right now just the modeset seems to be working with justa a few artafacts in X
[20:45] <imbrandon> i'm typing on this laptop ( screen + irrsi )  now so its not 100% lost
[20:46] <imbrandon> might try the fbdev driver, dont care about accel or multimonitors
[20:46] <imbrandon> Sarvatt: how can i turn KMS off though without recompiling the kern ?
[20:46] <jcristau> boot with i915.modeset=0
[20:47] <imbrandon> k
[20:47] <Sarvatt> kms is defaulted to off on 8xx in lucid, just dont add i915.modeset=1
[20:47] <imbrandon> ahh well without i915.modeset=1 i get a hard lock after plymouth
[20:48] <Sarvatt> have you tried disabling splash?
[20:48] <imbrandon> yes
[20:48] <Sarvatt> how about blacklisting vga16fb?
[20:48] <imbrandon> that i havent tried
[20:50] <Sarvatt> echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-framebuffer.conf && sudo update-initramfs -u and try booting without splash. worth a shot :)
[20:50] <imbrandon> ok so let me get this clear ( in my head ) what i should try ( gonna reboot in a sec to try it ) is blacklist that module, leave the modeset in the grub kernel line and switch to the fbdev driver ?
[20:50] <imbrandon> Sarvatt: kk i'll try that first
[20:51] <Sarvatt> in UMS there are a lot of options you can play with to see if you can get it usable, man intel in a terminal will list them, i'd start by disabling tiling
[20:51] <imbrandon> ok i'm detaching screen, bbiab , thanks for the pointers guys
[20:52] <Sarvatt> dont use fbdev unless you're using KMS
[20:53] <imbrandon> got it
[20:53] <jcristau> kms+fbdev should work fine afaik
[20:55] <Sarvatt> yeah vga16fb is only used with plymouth without KMS so it sounded like he was going to use that on top of dropping i915.modeset=1 (which would make him use UMS) and fbdev wouldn't work
[20:55] <imbrandon> yea no i'm blacklisting it , leaving the modeset to 1
[20:55] <imbrandon> and switching to fbdev
[20:55] <imbrandon> first two done, making an xorg.conf now
[20:56] <Sarvatt> blacklisting wouldn't matter there, was suggesting that to try to get intel working with UMS since you said that wasn't working
[20:57] <Sarvatt> UMS+intel would be the ideal combination if you could get it working, the vesa or fbdev options are worst case scenarios
[20:58] <imbrandon> ahh ok
[20:58] <imbrandon> soo since i have it blacklisted i should "try" UMS and intel ?
[20:58] <Sarvatt> yeah
[20:58] <imbrandon> k lemme do that, its done now, brb
[21:02] <bryceh> imbrandon, your questions make me wonder a bit...  a number of people have come here with similar questions, and I imagine there are going to be more once the release is out
[21:02] <imbrandon> bryceh: probably :)
[21:02] <imbrandon> ok so i'm back
[21:02] <bryceh> I'd sort of like to figure out a way to address questions for folks higher up, prior to them coming here
[21:02] <bryceh> imbrandon, can I ask you a few questions in relation to this
[21:03] <imbrandon> ums+blacklist+intel dident work
[21:03] <bryceh> imbrandon, what places did you look for a solution before coming here?
[21:03] <imbrandon> so now i'm gonna try kms+fbdev
[21:03] <imbrandon> bryceh: LP, but the intel driver stuff is a maze
[21:03] <bryceh> imbrandon, how did you identify #ubuntu-x as a channel to ask on?  Did someone refer you, or a website, or just a guess?
[21:03] <imbrandon> bryceh: i'd be happy to help maintain a wiki since i have the hardware to test it too
[21:04] <bryceh> imbrandon, ok in LP what specifically were you looking for?  (The bug report is there, but evidently not in a form which you found easily digestible)
[21:04] <imbrandon> bryceh: i'm a ubutnu-core-dev i just "knew" lol , but i'm just not a good X person
[21:04] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=[i855] is a good list of similar bugs, the ones numbered 500000 and up are lucid ones mostly
[21:04] <bryceh> ok, so #ubuntu-x based on past experience
[21:04] <imbrandon> ( about the channel that is )
[21:04] <imbrandon> yea
[21:05] <bryceh> imbrandon, by chance did you look at the release notes or the Ubuntu-X wiki pages before coming here?
[21:05] <bryceh> if not, is that because you didn't know about them, or because you knew but didn't think they'd have the answers?
[21:05] <imbrandon> bryceh: yea, berifly, thats why i knew it was a wider problem that there might be a work arround for, just wasent clear on what the workarround was
[21:05] <imbrandon> release notes, not the wiki
[21:05] <Sarvatt> it helps a lot having someone willing to test things in real time not having access to the hardware myself :)
[21:06] <imbrandon> wiki pages for teams i rarely check as from experice ( maybe not in X's case ) havent had awnsers about bugs, only the team
[21:06] <bryceh> imbrandon, ok good to know - did you spot the wiki link from the entry about it in the release notes?
[21:06] <imbrandon> yea
[21:07] <imbrandon> Sarvatt: heheh yea , an i love this laptop, its my "main" dev machine, i hate to replace it ;)
[21:07] <Sarvatt> imbrandon: if you want to test UMS more later it might be worth trying the version of xserver-xorg-video-intel thats in this PPA -https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-retro
[21:07] <bryceh> Did you follow the link?  Why or why not?  If you followed it, did you find it useful or not?  (too technical? too general?)
[21:08] <imbrandon> Sarvatt: sure i'm down for testing whatever, i have a few working desktops and servers should i totaly fubar something
[21:08] <imbrandon> ;)
[21:08] <imbrandon> bryceh: i followed it but it was too general it seemed so i quickly ( without a through look ) dismissed it
[21:08] <imbrandon> maybe wrongly but i did
[21:08] <imbrandon> ;)
[21:09] <bryceh> ok
[21:09] <Sarvatt> imbrandon: since you're on 855 there are some promising kernel changes that are much too invasive to backport right now that might fix things up too, i can dig you up a link and I think Geir has made kernel debs out of it
[21:09] <bryceh> I'll have to firm it up
[21:09] <imbrandon> Sarvatt: k
[21:09] <imbrandon> bryceh: k
[21:10] <imbrandon> bryceh: if there is anything else i can do wiki wise lemme know, i'm more than willing to help, just a bit behind the X curv, untill today its always "just worked" for me since warty on all my hardware ;)
[21:11] <Sarvatt> karmic worked?
[21:11] <imbrandon> well there was that one thing in early dapper but that bit everyone ;) shhhh
[21:11] <Sarvatt> using the kernel in karmic is an option :)
[21:11] <imbrandon> Sarvatt: yea, karmic worked like a charm on this laptop for months
[21:11] <imbrandon> Sarvatt: hum, never thought about that
[21:12] <bryceh> imbrandon, cool, yeah we could definitely use help improving the wiki pages at wiki.ubuntu.com/X, especially the Troubleshooting section
[21:12] <bryceh> imbrandon, a lot of what we need help with is just basic copyediting.  I tend to be overly verbose in my wordings so a second set of eyes to boil stuff down to simplify it would likely improve it
[21:12] <imbrandon> so just to be clear in my head here, is this a kernel problem or an intel/X problem or a mix
[21:12] <imbrandon> lol
[21:12] <bryceh> less is more, 'nat
[21:13] <imbrandon> bryceh: cool, i can do that
[21:13] <Sarvatt> mostly the kernel
[21:14] <imbrandon> ok so if i un-backlist that module ( just to be clean ) and install the latest karmic kernel ( via apt pinning ) i "should" be ok ?
[21:14] <imbrandon> and obviously boot form it via grub
[21:14] <Sarvatt> possibly :)
[21:15] <imbrandon> that is assuming karmic worked for me , that might be an option for the general public too since karmic will be supported kernel wise for a nother year, hum
[21:15] <imbrandon> apt pinning is a bit above most ppl but i bet it could be made easy via a wiki
[21:16] <Sarvatt> don't need to pin anything, just have to select it from the list in grub :)
[21:16] <imbrandon> Sarvatt: hum true, i forget kernel is one that can be installed side by side
[21:17] <imbrandon> ok let me try that next, if that dont work i'll go down the fbdev route
[21:23] <imbrandon> Sarvatt: how can i tell what -video driver i have loaded ?
[21:24] <Sarvatt> /var/log/Xorg.0.log should make it obvious
[21:25] <imbrandon> ok bbiab, gotta get the kids from school
[22:01] <bjsnider> Sarvatt, what's the deal with poulsbo on lucid?
[22:10] <bryceh> Sarvatt, while I finish up this xorg-server upload... any other changes you know of which we know we need?
[22:11] <bryceh> bjsnider, no deal at the moment
[22:11] <bryceh> bjsnider, use vesa, unless you feel like working on porting over the mandriva psb kernel patches
[22:12] <bjsnider> mandriva is using an old x server
[22:16] <bryceh> sorry I meant s/mandriva/meego/
[22:17] <imbrandon> back
[22:17] <imbrandon> well both the old kernel and kms+fbdev both are good worksarounds
[22:17] <imbrandon> bryceh Sarvatt ^^
[22:18] <imbrandon> bryceh: i'll touchup over the wiki some this evening after everyone is asleep in the house and I can concentrate a bit more
[22:20] <bryceh> imbrandon, great, thanks :-)
[22:53] <bryceh> gahh, writing up srus is so time consuming....
[23:17] <bryceh> Sarvatt, RAOF, xserver uploaded, sru's filed.  3 fixes included.
[23:17] <bryceh> and git pushed
[23:17] <BUGabundo> iihhhh
[23:17] <BUGabundo> I see we are going to have huge updates post release
[23:17]  * BUGabundo refreshs SRU page
[23:18] <bryceh> BUGabundo, are you complaining?
[23:18] <BUGabundo> I'm not
[23:18] <BUGabundo> I'm use to it
[23:19] <bryceh> yeah it's pretty standard operating procedure, esp. for an LTS
[23:19] <bryceh> if anything I think it's going to be light compared with hardy, at least for X stuff.  But we'll see.
[23:20] <BUGabundo> ehe
[23:20] <BUGabundo> well, the 6th ill upgrade to 10.10
[23:21] <bryceh> good man :-)
[23:22] <BUGabundo> some one must keep tabs on your guys works
[23:59] <bryceh> imbrandon, Sarvatt, I've refactored https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes to hopefully be less generic


[15:54] <santa__> hello everyone
[15:56] <santa_> valorie: I don't have a strong opinion about the flatpak thing, but thanks for counting on me
[21:08] <valorie> santa_: <3
[21:08] <santa_> :)
[21:08] <valorie> it's not so much that I have an opinion, as that I see the history and *positions* that others have taken
[21:09] <valorie> Canonical /Mark have a different view of "freedom" in the linux ecosystem than some other players
[21:13] <valorie> and walking through minefields is not a fun sunday afternoon stroll
 Hi folks, I am trying to work through getting my packaging rig set up, so that I can turn my hand to help out. Hi santa_, @RikMills, @tsimonq2  would be good to work with you on this, I'll reach out when I get stuck.
 I do feel we have to focus on user experience, we have some derivatives that will make their user experience better than Kubuntu, and I think we'll need to find a way to address this. Of course, we also want to stay aligned with Ubuntu main, and the TN of course, so communication will be key
[21:18] <valorie> nice to hear, Rick!
 {{{hugs}}} @Valoriez 🤗
 We need a roadmap with those goals setup.
[22:37] <valorie> {{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}}}}}}}}} to Rick
[22:37] <valorie> ahoneybun, how about floating a draft to the ML?
[22:39] <ahoneybun[m]> I believe I did that but didn't get any replies.


[00:49] <RainCT> uhm.. if I've created a presentation from a template and choosed a certain transition effect to do between slides, how can I later change that effect?
[00:52] <RainCT> ah, found it
[08:07] <jpds> Moin.
[08:10] <pochu> hi jpds
[08:12] <jpds> Hola pochu.
[08:23] <iulian> Hiya guys.
[08:28] <jpds> Hey iulian.
[08:46] <AndrewGee> Hi. Anyone available to look at giving the second advocation to osm-gps-map - A GTK widget to embed openstreetmap? http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[08:54] <jpds> AndrewGee: OK; looks good to me, but why did you have so many spaces in the Dependency lines?
[08:55] <AndrewGee> jpds: Not sure actually. Shall I sort that out and re upload?
[08:55] <jpds> AndrewGee: No, I'll fix it before I upload to the archive
[08:55] <AndrewGee> jpds: Ah okay. Thanks :)
[08:56] <jpds> Just have to wait for my key machine to come up.. :/
[09:02] <jpds> stdin: Could you possibly look into bug #322051 ? I've tried fixing it myself but can't get it to work.
[09:04] <jpds> It works with http:// URLs, but I can't get it to work with https://
[09:26] <slytherin> does anyone have some time to review a license (actually multiple) to see if the package is fit for archive?
[09:36] <hyperair> mok0: ping. could i bother you with a package today? http://revu.ubuntuwire.com/details.py?package=geanyprj
[09:40] <iulian> hyperair: I will take a look at it later.
[09:40]  * iulian is having breakfast now.
[09:40] <iulian> mok0 is already overloaded ;)
[09:41] <hyperair> iulian: ah thanks =)
[09:43] <pochu> slytherin: link?
[09:44] <slytherin> pochu: let me find. I was reading a local copy of license
[09:44] <slytherin> pochu: http://offo.sourceforge.net/hyphenation/licenses.html
[09:45] <slytherin> pochu: these are the hyphenation patterns which are not part of fop main distribution anymore. I want to package them provided they can go in one bundle.
[09:46] <mok0> Hi hyperair
[09:46] <pochu> slytherin: at least English hyphenation patterns are non-free
[09:47] <pochu> "Restriction:  These hyphenation patterns may not be changed in any way"
[09:47] <mok0> I uploaded one of your geany packages last night
[09:47] <slytherin> pochu: you mean en_GB right?
[09:48] <pochu> slytherin: yes
[09:48] <slytherin> pochu: what about en_US 'Can be used freely for non-commercial purposes'?
[09:50] <a|wen> hi, if i have a security update for a package in universe, is it then enough to subscribe motu-swat or should i subscribe ubuntu-universe-sponsors as well?
[09:50] <pochu> slytherin: the LaTeX Project Public License is free (and GPL and Apache are too, of course :)
[09:50] <hyperair> mok0: yeah i saw. thanks =)
[09:50] <fabrice_sp> Morning! (well, not so morning :-) ).  Is it worth packaging an app that is already in Ubuntu, but using Mono, so that it doesn't use mono anymore? A C port of autopano-sift has been written (Bug #323836)
[09:51] <pochu> slytherin: the link doesn't exist, but that would be non-free if you can't use for commercial purposes (e.g. sell it)
[09:51] <mok0> fabrice_sp: interesting
[09:53] <slytherin> a|wen: First subscribe motu-sru (not motu-swat)
[09:54] <geser> slytherin: en_US is non-free
[09:54] <slytherin> pochu: assuming that en_GB and en_US are non-free, are they at least fit for multiverse?
[09:54] <a|wen> slytherin: oh, i'll do that (tried to look at how similar bugs was subscribed)
[09:54] <slytherin> or should I exclude en_US and en_GB from the binary?
[09:58] <fabrice_sp> mok0, I haven't found any references of autopano in Debian (only in multimedia-debian), so no sync possible :-)
[09:58] <pochu> slytherin: from reading only that description, I'd say en_US fits for multiverse. I think en_GB does too, but am less sure about that. But I haven't read the licenses, that's only from reading that restrictions line :)
[09:58] <mok0> fabrice_sp: what's it for?
[09:58] <slytherin> hmm
[09:59] <a|wen> slytherin: should i do anything else apart from that to brig attention to it as a security issue?
[09:59] <slytherin> a|wen: mark it as security issue and add a link to CVE
[09:59] <pochu> slytherin, a|wen: I thought for security issues you could subscribe motu-swat directly, as if it's going to go to $distro-security, it doesn't need an SRU approval
[10:00] <slytherin> ahh, I got confused. I thought it was similar to SWAT team for X packages
[10:00] <fabrice_sp> mok0, it is used in hugin to find matching points between pictures, to make panoramas.
[10:00] <fabrice_sp> mok0,  Also, from a patent stand point, I discovered that the sift algorithm is patented in the USA. :-/
[10:01] <slytherin> pochu: geser: I am now thinking if I should put each pattern in separate binary. That way all the binaries except en_GB and en_US will live in universe.
[10:01] <a|wen> pochu: okay, thx ... right now both motu-sru and motu-swat ended up being subscribed, then it should have a chance
[10:01] <geser> slytherin: fi is also for multiverse, hu isn't redistributable at all,
[10:02] <pochu> slytherin: in any case put all the free ones in one binary, and all the non-free that fit for multiverse in another one... but not one binary per package, I'd say
[10:02] <geser> slytherin: you can't put the source into universe
[10:03] <a|wen> pochu: i should keep the bug as private, right?
[10:04] <slytherin> geser: I know. source will still go into multiverse.
[10:04] <geser> a|wen: no need to keep the bug private if the issue is already public (known)
[10:04]  * a|wen makes it public ... thx
[10:35] <stdin> jpds: launchpadlibrarian.net is http, I've never seen a https link for it, and dget will handle the https://launchpad.net/ubuntu/<release>/+source/<source>/<version>/+files/<file> links
[10:41] <iulian> fta: Have you tested geany-plugin-prj to see if it works?  I don't have geany installed on my system.
[10:49] <hyperair> iulian: i've tested it on intrepid, it woks fine.
[10:49] <hyperair> iulian: haven't tested on jaunty though
[10:53] <iulian> I'm testing it right now.
[10:54] <hyperair> iulian: alright. brb i'm gonna log out to test a bug with gnome-keyring
[11:05] <iulian> hyperair: I have just uploaded it.  Thank you.
[11:06] <hyperair> iulian: thanks
[11:31] <soc> hi
[11:31] <soc> someone from debian online?
[11:31] <soc> my package is now in ubuntu and i filed an itp for debian ... how do i have to proceed?
[11:32] <iulian> soc: Look for a DD to sponsor your package.
[11:32] <iulian> soc: Send an email to<EMAIL_ADDRESS>[11:35] <soc> and aksing for a sponsor?
[11:35] <Laney> soc: Also visit #debian-mentors on OFTC
[11:35] <soc> what does sponsor mean?
[11:35] <soc> ah ok
[11:36] <quadrispro> could anyone take a look at here? http://revu.ubuntuwire.com/details.py?package=gnome-format
[11:38] <stdin> jpds: do you know/work with python?
[11:40] <jpds> stdin: Yes.
[11:41] <stdin> jpds: I wrote a python rewrite of dgetlp a while ago, but I forgot about it. could you give it a look over: http://pastebin.com/f284785b5
[11:42] <Laney> Where on LP does dget not work?
[11:43] <stdin> Laney: the +queue
[11:45] <jpds> stdin: Looks good, should I put it into u-d-t  replace the bash script?
[11:46] <stdin> jpds: IMO it works better than the bash script and provides better error handling. so I'd say yes :) I've tested it a little but not rigorously
[11:47] <stdin> it "Works For Me"
[11:48] <stdin> and I'll probably smooth out the code some time, just to make it look nicer
[11:55] <jpds> stdin: Pushed to main branch, let me know if you want changes added.
[11:56] <stdin> jpds: sure :)
[11:59] <Laney> stdin: Gives a traceback when run with no args
[11:59] <Laney> and you should consider updating the manpage ;)
[12:12] <stdin> Laney: right, so how does one edit the manpage without knowing the language it's written in?
[12:13] <Laney> stdin: It shouldn't be too hard to edit the existing one, following that syntax, should it?
[12:13] <stdin> sure, but I was wondering if there was  and "easy" way ;)
[12:14] <geser> stdin: I don't know the manpage syntax either but I managed to update manpages just by looking how it's done at other places in the manpage and copy that
[12:15] <geser> !info gmanedit
[12:15] <Laney> ^
[12:15] <geser> you could also try this app out (never used it myself)
[12:17] <stdin> ok, give me a minute to change it
[12:22] <AnAnt> Hello, I am installing a font, how do I make the defoma hints file for it ?
[12:44] <stdin> hah, gmanedit segfaults on exit
[12:57] <iulian> stdin: Please file a bug.
[12:57] <stdin> iulian: already have
[13:03] <stdin> jpds: here's a patch to fix the error Laney mentioned and updated manpage http://stdin.me.uk/diffs/dgetlp.diff
[13:03] <Laney> stdin: I suggest displaying the usage info
[13:03] <stdin> Laney: it does now
[13:03] <Laney> Oh, maybe I misunderstand what parser.error is then
[13:04] <stdin> http://paste.ubuntu.com/112431/
[13:05] <AnAnt> defoma-hints is not working !
[13:09] <AnAnt> should a font package build-depend on fontforge ?!
[13:10] <Vest> Hello to everybody. I'm new here and I have a question.
[13:10] <Vest> My situation is the next one. I'm a developer of my own game, called "Gnome Quod", I've published it in ppa.launchpad.net. But I want to know, can my program be placed in official Ubuntu Repositories?
[13:12] <pochu> Vest: under what license is it released?
[13:12] <Vest> pochu: I release it with GPL v3 license
[13:12] <Vest> http://sourceforge.net/projects/gquod
[13:14] <Vest> and it was sucessfully build with launchpad, https://launchpad.net/~vest-84/+archive
[13:15] <pochu> Vest: then yes (because of the license)
[13:15] <pochu> Vest: would you like to maintain it?
[13:16] <Vest> yes, of course.
[13:16] <pochu> Vest: then you want to upload it to REVU, so that MOTUs can review it and upload to the archive if it's right
[13:16] <pochu> !revu
[13:18] <Vest> pochu: thank you for help. I'll read it
[13:19] <Vest> pochu: what kind of ristrictions will I have in future, if I become a maintainer of my own game?
[13:21] <__Ali__> anyone knows an library debian packaging which installation path of /usr/lib/MyLib rather than /usr/lib?
[13:21] <geser> don't mix packaging and upstream code
[13:21] <__Ali__> whatever i tried, the outcome debian package does not hold any shared objects
[13:21] <vadi2> Hi, can someone help this person in regards to gpl, a proprietary piece and packaging: http://ubuntuforums.org/showpost.php?p=6656152&postcount=63
[13:46] <Vest> pochu: do you know, should my debian/changelof have version (0.2.1-7ubuntu0(1,2,3...)) instead of simple (0.2.1-7)?
[13:47] <AnAnt> ahem, should a font package build-depend on fontforge ?!
[13:59] <AnAnt> Hello, can anyone confirm a bug ?
[13:59] <AnAnt> I mean, I found a bug, after searching launchpad, I found that someone else reported the same bug
[14:00] <AnAnt> can I set the bug status to confirmed then ?
[14:00] <jpds> stdin: Pushed. Thanks!
[14:03] <loic-m> Vest: if the package doesn't exist dor Debian yet, end it with -0ubuntu1
[14:04] <loic-m> s/dor/for/
[14:05] <Vest> loic-m: my package isn't published yet in debian archive. so, I have to add the ending manually?
[14:07] <loic-m> Vest: the ending should be created when you use tha packaging tools, like dh_make
[14:08] <loic-m> Vest: have a look at https://wiki.ubuntu.com/MOTU/Videos especially http://videos.ubuntu.com/motuvideos/packaging_101.ogg
[14:08] <Vest> loic-m: thank you, I understand. can you tell me, should I use jaunty version instead of intrepid when I want to publish my project in official repos?
[14:08] <loic-m> Vest: it's a step-by-step, follow it while packaging from scratch, pause for each step
[14:09] <loic-m> Vest: always use the development version
[14:09] <loic-m> Vest: if you can watch the video while doing it, it makes it really easy
[14:10] <loic-m> Vest: dev version = jaunty for teh moment
[14:10] <Vest> can I people with intrepid use jaunty versions?
[14:10] <Vest> *can people
[14:11] <geser> in most cases no because of the dependencies
[14:11] <zpowers> geser: not true
[14:11] <StevenK> He said most cases'
[14:12] <zpowers> Package pinning is not very difficult to do
[14:12] <zpowers> Not even for most cases, I'd say it'd be more like a few
[14:12] <StevenK> zpowers: Sure, and when you pulled in libc6 from Jaunty or something else like d-bus, it's essentially game over
[14:12] <Vest> I asked, because I have repos in ppa.launchpad. and changelog allows to use only one version of ubuntu (by the way I've tried the situation "intrepid jaunty", as described in help.lanchpad)
[14:13] <AnAnt> StevenK: nice one, especially that Vest is developing a game
[14:13] <StevenK> It's just an expression
[14:13] <loic-m> Vest: if you want it in the repositories for intrepid, upload to revu for Jaunty, then request a backport
[14:14] <AnAnt> StevenK: yup
[14:14] <Laney> revu isn't for backports...
[14:14] <Vest> a! so... that is how I have to do... I see... how interesting
[14:15] <loic-m> Vest: if you want to upload to your PPA, once your packages is ok for jaunty, just edit the changelog, change the version by appending something like ~intrepid1 (note the ~) after -0ubuntu1
[14:15] <loic-m> Vest: then create an entry for intrepid (your ppa of course) in your .dput.cf and upload to it
[14:16] <Laney> Vest: PPAs support copying between different releases, so you can upload to Intrepid and then copy the sources to Jaunty to have it build there too
[14:17] <Vest> aha... good. and, do you know, if I upload my sources to REVU, they will have a status "Needs Review". Can I continue the work under my application and reupload the new version over the old one?
[14:18] <loic-m> Laney: was that fixed? Last week when I ask in #launchpad, it was still only possible between different ppa (if you want to rebuild from source)
[14:18] <geser> Laney: doesn't it only work when he copies the debs too?
[14:18] <geser> Vest: yes
[14:18] <loic-m> Laney: just checked, and it's not possible yet, at least on my ppa
[14:19] <Laney> loic-m: Hmm? Set destination to "this PPA", series to "Jaunty" and ask to rebuild?
[14:19] <Laney> I admit I've only seen the UI, not actually tried it
[14:20] <loic-m> Laney: it throws an error. Try it and you'll see it doesn't work
[14:20] <geser> Laney: this won't work because of the pool structure
[14:20] <Vest> geser, should I use the option -f (dput -f) to overwrite the package with the same name, or not?
[14:21] <Laney> geser: That's disappointing then
[14:21] <geser> yes (or remove the <pkg>.upload file)
[14:22] <Vest> geser, and afterwards I remove my package and upload it again. will it's queue changed to last? :)
[14:23] <geser> Vest: I don't know how the sorting on REVU really works
[14:33] <Vest> sorry, guys, can you help me with this problem? http://revu.ubuntuwire.com/revu1-incoming/gnome-quod-0902011503/lintian  I can't understand what's wrong (I don't write build-essential as dependency)
[14:35] <geser> Vest: you build-depend on (unversioned) libc6-dev which is part of build-essentials -> you don't need to specify it
[14:36] <geser> and the other error is, that you source package is native (has no .diff.gz)
[14:36] <Vest> hm
[14:36] <Vest> thankx
[14:36] <Vest> *thanks
[14:48] <AnAnt> is defoma still to be used ?
[14:48] <AnAnt> LP 308539
[14:54] <MaduserTr> The legal check from revu.ubuntuwire.com. Is this a program I can ran localy on my maschine?
[14:56] <jpds> MaduserTr: lintian, I think it is.
[14:58] <pochu> it's licensecheck
[14:58] <pochu> `licensecheck -R *`
[14:58] <pochu> but that's not enough, it's just a tool to help you
[14:59] <MaduserTr> jpds, pochu: Thnaks
[15:06] <BiNaRi0> hi everyone
[15:06] <BiNaRi0> keyserver.ubuntu.com is down
[15:06] <BiNaRi0> does anyone know what happened about it ?
[15:07] <pochu> BiNaRi0: I think #canonical-sysadmin is where the people maintaining that service hang
[15:07] <BiNaRi0> thanks
[15:07] <pochu> np
[15:08]  * directhex wonders who did funny things to one of his sync bugs
[15:09] <Laney> check the activity log
[15:13] <directhex> i did. someone marked it invalid & converted it to a question, but didn't say, i dunno, WHY
[15:13] <iulian> Hmm, that's odd.  What is the bug #, directhex?
[15:14] <directhex> 323948
[15:14] <directhex> i reopened it. which i know is poor form, but so is closing bugs without comment
[15:15] <sebner> bug #323948
[15:16] <sebner> directhex: funny ^^
[15:17] <iulian> Well, it's not funny...
[15:17] <iulian> Bleah
[16:29] <henrik-hw0> superm1: fixed FTBS in rt2860-linux-sta and rt2870-linux-sta packages just now.
[17:31] <bmhm> hi, I need a clue what pbuilder tries to do here: http://paste.ubuntuusers.de/393976/
[17:31] <bmhm> I don't see why it wants to copy a .gnome-file
[17:34] <geser> use pbuilder on the .dsc file and not on the .changes file
[17:36] <bmhm> oh my, that did it
[17:36] <bmhm> how embarrassing
[17:37] <bmhm> thanks
[17:39] <hyperair> lol
[17:43] <bmhm> well just another question: How do I build same releases for different distros? Do I need to change debian/changelog somehow?
[17:43] <hyperair> depends
[17:43] <bmhm> using dpkg-buildpackage and pbuilder and dput
[17:44] <hyperair> if you're uploading to a PPA, then you need to alter debian/changelog
[17:44] <hyperair> set the distro
[17:44] <hyperair> otherwise, just run it thorugh pbuilder
[17:44] <hyperair> the appropriate pbuilder
[17:44] <bmhm> yeah I want to use dput
[17:45] <bmhm> just like sed 's/intrepid/jaunty/g'?
[17:45] <hyperair> um
[17:45] <hyperair> no
[17:45] <hyperair> just the top one will do
[17:45] <hyperair> don't change every single instance of it
[17:45] <hyperair> oh if you're uploading to PPA, you'll need different version numbers
[17:45] <hyperair> just mangle them by adding ~distro1 or something
[17:46] <hyperair> you can't upload the same version to different distros in PPA
[17:46] <bmhm> ah so like ubuntu1 for intrepid and ubuntu2 for jaunty? thats why i asked
[17:47] <bmhm> I need kind of a concept
[17:48] <geser_> or use ubuntu1 for jaunty and ubuntu1~intrepid1 for intrepid
[17:48] <bmhm> ok
[17:50] <hyperair> geser: i still wouldn't use ubuntu1 for jaunty
[17:50] <hyperair> you often want the new versino to override the old
[17:51] <bmhm> anyway, that did it for intrepid so far: https://edge.launchpad.net/~globalmenu-team/+archive/ppa
[17:51]  * RainCT ponders creating a printers-are-evil LP group :P
[17:52] <geser> hyperair: ubuntu1 > ubuntu1~intrepid1
[17:52] <bmhm> Hmm. I haven't seen a guide or something explaining how to name versions.
[17:52] <bmhm> why not put a name to each distribution like ubuntu1~jaunty1
[17:52] <hyperair> geser: ubuntu1 (from main repos) > ubuntu1~jaunty1 (jaunty PPA) > ubuntu1~intrepid1 (intrepid PPA)
[17:53] <hyperair> bmhm: there's a PPA guide somewhere
[17:53] <hyperair> bmhm: go read that one
[17:53] <bmhm> iss ppa1~jaunty1 > ubuntu1 ?
[17:53] <hyperair> rule is always mangle your versions to enter PPA unless you want to screw up your upgrade path
[17:55] <bmhm> hyperair: where is somewhere? Ubuntu docs? Launchpad docs? Some hidden dev docs?
[17:55] <bmhm> I read docs almost everywhere by now
[17:55] <geser> bmhm: no, as p < u
[17:56] <bmhm> then why not just leave the "ubuntu" out, like "gnome2-globalmenu~intrepid1" "gnome2-globalmenu~jaunty1"
[17:56] <geser> the debian policy has a description of how version sorting works
[17:56] <bmhm> kk
[17:56] <bmhm> I was just looking for a recommendation how to name my changes ^^"
[17:56] <hyperair> bmhm: launchpad docs
[17:56] <geser> don't mix upstream version and ubuntu revision, that are two different fields
[17:57] <bmhm> that's how I did it by now: https://bugs.edge.launchpad.net/~globalmenu-team/+archive/ppa
[17:57] <bmhm> hyperair: I will take a look at it
[17:58] <hyperair> bmhm: you shouldn't do that.
[17:59] <bmhm> so what's wrong?
[17:59] <bmhm> err... what can I do better
-0ubuntu1~ppa<your ppa revision>
[18:00] <hyperair> assuming that debian and ubuntu dont have it
[18:01] <bmhm> they don't have it, correct
[18:01] <bmhm> I found the guilde: https://help.launchpad.net/Packaging/PPA#Versioning
[18:02] <bmhm> myapp_1.0-2~ppa1~intrepid1 contra myapp_1.0-2~ppa1~hardy1
[18:02] <bmhm> oh I did use a hyphen instead of a tilde
[18:05] <hyperair> and htat makes all the differecne
[18:06] <bmhm> ah there's a dead link
[18:06] <bmhm> https://help.launchpad.net/Packaging/PPA#copyingpackages
[18:06] <bmhm> a link to  Ubuntu Mobile team's PPA copy packages
[18:10] <bmhm> is this better? https://bugs.edge.launchpad.net/~globalmenu-team/+archive/ppa
[18:11] <hyperair> very much so
[18:12] <bmhm> ok, thanks a lot then for helping
[18:12] <hyperair> no problem
[18:13] <hyperair> gtk2-globalmenu...
[18:13] <hyperair> is that the one where you strip the menus out from the windows and stick it onto the panel?
[18:24] <bmhm> re
[18:24] <bmhm> exactly
[18:24] <hyperair> awesome. the next time i feel bored with my current interface i'll check it out
[18:24] <hyperair> i accidentally installed it once on arch
[18:25] <bmhm> hyperair: I joined for building packages only. As far as I can see, preferences won't work yet and there's no icon for switching apps etc.
[18:25] <bmhm> but screenshots on http://code.google.com/p/gnome2-globalmenu/ look promising
[18:26] <hyperair> hahah
[18:26] <hyperair> you know what?
[18:26] <hyperair> that sounds like me
[18:26] <hyperair> one and a half years ago
[18:26] <hyperair> ;)
[18:26] <hyperair> no wait
[18:26] <hyperair> less than a year
[18:26] <hyperair> i joined the Banshee Team
[18:27] <hyperair> and founded the Banshee Unstable Team
[18:27] <hyperair> for packaging
[18:27] <bmhm> yeah
[18:28] <Laney> banshee <3
[18:29] <Laney> hyperair: Do you know when the next release will be? I read that it'll enable gnome-do to have a full plugin
[18:29] <hyperair> Laney: =)
[18:29] <bmhm> hyperair: does banshee support MPRIS?
[18:29] <hyperair> bmhm: no it doesn't
[18:29] <bmhm> that's sad
[18:29] <bmhm> I should submit a patch
[18:30] <hyperair> go ahead =)
[18:30] <bmhm> Audacious does, but it doesn't integrate at all into gnome :(
[18:30] <hyperair> bmhm: you know enough C# to do so?
[18:30] <bmhm> it's C#? :-/
[18:30] <hyperair> bmhm: what's mpris used for anyway? i only see it used in pidgin-mpris
[18:30] <hyperair> bmhm: and yes it's C#
[18:30] <bmhm> I can code C, IBM Mainframe Assembler and Java.
[18:31] <hyperair> bmhm: that's the reason why i've only submitted one patch for banshee before, and that's for their at-that-time defunct shell loader script
[18:31] <bmhm> well I can code a little object pascal, too :D
[18:31] <hyperair> i can do C, C++, shell, python, but i've only really done major patching in shell and C/C++
[18:32] <hyperair> i hate pascal and everything to do with it
[18:32] <bmhm> really??
[18:32] <hyperair> yep
[18:32] <bmhm> I LOVE it <3
[18:32] <bmhm> it's so clean and straight-foreward
[18:32] <hyperair> well i think it has omething to do with me starting with turbo pascal
[18:32] <hyperair> *shudder*
[18:32] <bmhm> So did I, in school
[18:32] <hyperair> what a strange syntax
[18:33] <bmhm> I call it beautiful. That's why I like python, too, I gues ;-)
[18:33] <hyperair> i like python
[18:33] <hyperair> python's syntax is clean
[18:33] <hyperair> but not pascal's =\
[18:33] <bmhm> yeah, I should have bought a python book by now
[18:33] <bmhm> ok let's try banshee
[18:33] <hyperair> no wai
[18:34] <hyperair> i learnt python from the internet
[18:34] <hyperair> just as i learnt C and C++ from the internet
[18:34] <hyperair> and shell
[18:34] <bmhm> wow
[18:35] <bmhm> I like books, I mean "real" books :)
[18:35] <pochu> bmhm: me too :) I print stuff from internet to read it in the bed ;)
[18:36] <pochu> that's not exactly a real book, but it's closer than reading it from the screen :)
[18:36] <bmhm> :D
[18:36] <RainCT> pochu: you kill trees!!    :P :P
[18:37] <pochu> heh
[18:38] <pochu> I was looking to buy a book this evening from Oreilly, but the transport fee is actually more expensive than the book itself :(
[18:38] <bmhm> nah banshee is not good for me
[18:38] <pochu> so if someone is coming to Spain from the US, tell me ;)
[18:38] <bmhm> ... or to germany :D
[18:38] <pochu> bmhm: rhythmbox is C! :-)
[18:38] <bmhm> i know pochu, but rhythmbox has other problems
[18:39] <bmhm> I stick with amarok i think
[18:39] <hyperair> rhythmbox has this annoying "feature" where it bugs me to install codecs which can't be fuond upon startup everytime
[18:39] <hyperair> and leaks memory faster than a sieve leaks water
[18:39] <pochu> bmhm: but amarok doesn't integrate well into GNOME! ;)
[18:39] <RainCT> pochu: right.. I ordered my research project as a book (from lulu.com) and transport was the same prize as the book
[18:39] <pochu> that sucks :(
[18:40] <bmhm> yeah i know. But still better than audacios. Rhythmbox and banshee lack expert settings :(
[18:40] <hyperair> bmhm: what are you looking for exactly?
[18:40] <bmhm> like choosing specific folders to scan for media, or setting more advanced options for ogg/flac encoding
[18:40] <pochu> hyperair: how much memory does banshee waste?
[18:40] <hyperair> regarding that, poke around in gconf
[18:40] <pochu> here rhythmbox is eating 40MB after several hours (I think more than a day)
[18:41] <hyperair> pochu: somewhere aruond 50-90MB on my notebook
[18:41] <pochu> heh
[18:41] <hyperair> after a week
[18:41] <hyperair> no, more than that
[18:41] <hyperair> i don't shut down
[18:41] <pochu> and you say rhythmbox leaks? ;)
[18:41] <hyperair> i hibernate and restore
[18:41] <hyperair> oh yeah sure i do
[18:41] <RainCT> wow.. 40MB here too (after 6 hours)
[18:41] <hyperair> it reached 500MB on my notebook
[18:41] <hyperair> >=(
[18:41] <pochu> heh
[18:41] <hyperair> you call that _not_ leaking?
[18:41] <RainCT> but I still have 3GB free anyway :P
[18:41] <bmhm> yay
[18:41] <pochu> that's probably fixed now :)
[18:42] <hyperair> i have 2GB total
[18:42] <pochu> RainCT: lol
[18:42] <bmhm> I got 2 in total :/
[18:42] <bmhm> xD
[18:42]  * pochu has 2 too
[18:42] <hyperair> besides, banshee's got a more shiny look to it
[18:42] <hyperair> with the custom treeview
[18:42] <bmhm> yeah thats nice
[18:42] <bmhm> but I still struggle with the media library
[18:42] <bmhm> ah
[18:42] <bmhm> purging...
[18:42] <hyperair> what's wrong?
[18:42] <hyperair> oh yeah banshee has awesome searching support
[18:43] <bmhm> I can't choose a specific folder to import
[18:43] <hyperair> yes you can
[18:43] <hyperair> set your media library folder
[18:43] <bmhm> I did
[18:43] <bmhm> nothing to be imported
[18:43] <hyperair> and import from folder
[18:43] <bmhm> oO
[18:43]  * pochu likes rhythmbox interface
[18:43] <hyperair> ctrl+i
[18:43] <RainCT> bmhm: memory is cheap nowadays... 4GB instead of 2GB was just 10€ iirc (+15€ more to switch from 6xx to 800 Mhz)
[18:43]  * hyperair likes banshee interface
[18:44] <bmhm> RainCT: I got DDR1 - it's not that cheap
[18:44] <pochu> RainCT: as long as it's not from manufacturers, yes ;)
[18:44] <hyperair> bmhm: same here
[18:44] <bmhm> ah it's "open location" in german
[18:44] <bmhm> I thought that's for URIs
[18:44] <hyperair> DDR1 1GB RAM on my desktop was twice the price that of DDR2
[18:44] <bmhm> bloody translations
[18:45] <bmhm> hyperair: yeah, I bought 1GiB for € 35 some months ago
[18:45] <RainCT> (DDR1 = old memory?)
[18:45] <hyperair> um it was RM300 here
[18:45] <hyperair> MYR
[18:45] <hyperair> i'm not sure about the conversion
[18:45] <hyperair> either x4 or x7
[18:46] <pochu> RainCT: yeah
[18:46] <bmhm> hyperair: banshee didn't ask me to choose a folder a second ago...
[18:46] <bmhm> anyway now it's working
[18:46] <hyperair> lol
[18:46] <pochu> bmhm: DDR1 is the same as DDR400?
[18:46] <bmhm> yeah
[18:46] <hyperair> 227
[18:47] <hyperair> or was it 3something
[18:47] <bmhm> I got dual channel, so it's called 800 (but it's wrong in fact)
[18:47] <pochu> this friday I bought a 512MB DDR400 for 16€ ...
[18:47] <bmhm> fastest DDR1 is PC3200 with 400 Mhz
[18:47] <pochu> that's what I bought
[18:47] <bmhm> thats cheap
[18:48] <bmhm> bloody h*** not again
[18:48] <bmhm> Ppl always forget to cross-sign my key :/
[18:48] <pochu> they had a 512MB module for 12€ too, but it was out of stock, and the 16€ one was from Kingston, so I thought I didn't want to wait for the other to be available ;)
[18:48] <bmhm> so i sign theirs
[18:49] <bmhm> but I won't get mine signed
[18:49] <pochu> heh
[18:49] <hyperair> bmhm: you're supposed to only get signed if you've met in person
[18:49] <bmhm> I did!
[18:49] <hyperair> and exchanged keys on pendrive or something
[18:49] <pochu> hyperair: that's not necessary
[18:49] <Laney> huh, no technology required
[18:49] <bmhm> we do it by mail and check printed fingerprints
[18:49] <hyperair> =O
[18:49] <bmhm> just get sure not to buy ram from MDT
[18:49] <hyperair> i don't know, i don't have any signatures on my key
[18:50] <hyperair> and i haven't signed anyone's keys
[18:50] <RainCT> pochu: you just need to compare the fingerprint, and knowing for sure that he is who he says he is
[18:50] <pochu> right
[18:50] <bmhm> then you don't have a web-of-trust, hyperair
[18:50] <RainCT> (that is, having meet and seen a ID or already knowing him)
[18:50] <pochu> but you can have your fingerprint in a piece of paper, and give it to the other person, showing you your ID card or passport
[18:50] <bmhm> RainCT: you should check his ID-Card if you don't know him
[18:50] <bmhm> yeah exactly
[18:51] <RainCT> bmhm: that's what I said ^^
[18:51] <pochu> then the other person knows who are you, and when he arrives home, he checks that the key he's going to sign has your name
[18:51] <bmhm> I was going to write a big PDF explaining PGP and web-of-trust and signing partys in detail, step-by-step
[18:51] <pochu> (the key with the fingerprint you gave to him)
[18:51] <bmhm> banshee hung up while indexing my files :P
[18:51] <hyperair> =O
[18:52] <bmhm> again
[18:52] <bmhm> it happens when the error tab wants to show up
[18:53] <geser> keysigning parties are fun
[18:53] <hyperair> nobody i know really bothers with their keys
[18:53] <bmhm> I've never been on one
[18:53] <geser> the next one I will participate is during FOSDEM
[18:54] <bmhm> I got a sign from c't, the best-known german computer magazine
[18:54] <bmhm> http://www.heise-online.co.uk/
[18:54] <bmhm> it's better than /.
[18:54] <bmhm> I think
[18:55] <oojah> http://www.lysator.liu.se/~jc/wotsap/leafoftrust.html <- interesting read on pgp web of trust.
[18:55] <bmhm> check out sig2dot
[18:55] <bmhm> you can draw graphs
[18:57] <geser> my public keyring is already to big for sig2dot, it takes forever to get a graph
[18:59] <bmhm> geser: you can strip it
[18:59] <bmhm> create a new temp-key
[18:59] <bmhm> or use a 3D-graph
[19:00] <bmhm> (which will take even longer) :P
[19:03] <bmhm> [Debug 19:57:40.328] Downloaded cover art from Amazon
[19:04] <bmhm> wtf banshee didn't even ask me!
[19:04] <hyperair> you could disable the cover art extension
[19:04] <bmhm> :P
[19:04] <hyperair> no actually, it should show a progress bar
[19:04] <bmhm> I think I'm going to switch to mpg321 ;-)
[19:04] <RainCT> hyperair: what's the problem with it?
[19:04] <hyperair> and more often than not, it'll hang taking 100% of your cpu
[19:05] <hyperair> RainCT: problem with what?
[19:05] <geser> I've 143 signatures on my key. If I want to graph it with all the other keys, it really takes long.
[19:05] <geser> don't even try to use sig2dot on the Debian keyring :)
[19:05] <RainCT> hyperair: cover art enabled
[19:05] <bmhm> no, I just wanted to net :P
[19:05] <bmhm> *nag
[19:05] <bmhm> geser: the deb keyring has already been done
[19:05] <hyperair> RainCT: well it likes to hang and eat my cpu.
[19:05] <RainCT> hyperair: Ah. Use Rhythmbox :P
[19:06] <hyperair> RainCT: no. frigging. way.
[19:06] <hyperair> =p
[19:06] <RainCT> hehe
[19:06] <hyperair> hmm i need to figure out all the bugs i've fixed in the past so i can decorate my wiki page
[19:07] <bmhm> :D
[19:07] <hyperair> many of them are long lost and i don't remember them
[19:07] <bmhm> banshee uses libnotify, I am beginning to like it =)
[19:07] <hyperair> yeaa
[19:08] <hyperair> hmm.
[19:08] <hyperair> 3am
[19:08]  * hyperair begins counting
[19:08] <Laney> are banshee's notify balloons a custom widget?
[19:08] <hyperair> 5h 30 minutes to class. time to go to sleep
[19:08] <Laney> Or does libnotify provide the sexy countdown thing
[19:08] <bmhm> first one Laney
[19:08] <hyperair> Laney: yes they are
[19:08] <hyperair> Laney: custom
[19:08] <bmhm> yes it does
[19:08] <bmhm> libnotify CAN countdown
[19:08] <bmhm> at least I am pretty sure
[19:08] <geser> bmhm: how long did it take?
[19:08] <hyperair> Laney: wait, you mean the notification thing?
[19:08] <hyperair> Laney: or the timer?
[19:09] <hyperair> eh i mean the progress tooltip thing
[19:09] <Laney> any of it
[19:09] <bmhm> the first one
[19:09] <bmhm> the tooltip bubble
[19:09] <hyperair> the bubble that looks like a dialog box?
[19:09] <bmhm> popping out of your applet icon
[19:09] <hyperair> when you switch songs, or when you hover over the icon?
[19:09] <hyperair> one of them's a tooltip on steroids
[19:09] <hyperair> the other is a libnotify thing
[19:10] <hyperair> and yes libnotify can do countdowns.. in the form of a pizza like thing that gradually disappears
[19:10] <hyperair> or was it gradually fills up
[19:10] <hyperair> disappears
[19:10] <bmhm> For me it's filling: Blue is the background, white the filling color ;-)
[19:10] <Laney> yeah, the pizza was what I meant
[19:10] <bmhm> yeah
[19:10] <hyperair> if pizza slices were continuous and not discrete, and people ate at a constant pace, that's how it would look
[19:10] <bmhm> it's built in
[19:10] <hyperair> that's libnotify
[19:10] <bmhm> :D
[19:10] <Laney> oh, hot
[19:10] <hyperair> i see it with pidgin-libnotify
[19:10] <bmhm> yeah built in into libnotify
[19:11] <hyperair> xchat doesn't have it though
[19:11] <bmhm> ^^
[19:11] <hyperair> i'd like xchat to set timeouts too
[19:11] <hyperair> i remember one thing i like about ubuntu's libnotify... it has rounded corners.
[19:11] <hyperair> archlinux's doesn't, for some strange reason
[19:12] <bmhm> aptitude install pidgin-libnotify
[19:12] <bmhm> brb ^^
[19:13] <hyperair> heh
[19:13] <Laney> I don't have rounded corners (:
[19:13] <Laney> :(
[19:13] <hyperair> hmm strange
[19:13] <hyperair> it should have by default
[19:13] <bmhm> yeah
[19:14] <Laney> probably my theme
[19:14] <hyperair> no it's not the theme
[19:14] <hyperair> when i was in arch i was using this same theme
[19:14] <hyperair> and there weren't rounded corners
[19:16] <bmhm> try "notify-send"
[19:16] <bmhm> it's got rounded corners for me
[19:16] <Laney> nope
[19:18] <hyperair> notify-send doesn't have the pizza thing
[19:18] <hyperair> Laney: what's your version of notification-daemon
[19:19] <hyperair> 0.3.7-1ubuntu15 here
[19:19] <Laney> Version: 0.3.7-1ubuntu15
[19:19] <hyperair> hmm how very strange
[19:19] <hyperair> try another theme?
[19:19] <hyperair> you're using what?
[19:19] <hyperair> human?
[19:19] <Laney> I'd rather not
[19:19] <hyperair> why not?
[19:19] <Laney> because I like my current one :(
[19:19] <hyperair> just test it
[19:19] <Laney> I don't know what it was originally called - I've customised it
[19:19] <hyperair> try with human or something
[19:19] <hyperair> aah i see
[19:19] <Laney> k :<
[19:19] <hyperair> save it first?
[19:20] <hyperair> hmm e-jat eh? that's a familiar nick.
[19:20] <Laney> no change
[19:21] <hyperair> how strange
[19:21] <hyperair> maybe some package is making it act up
[19:21] <hyperair> one way to check would be to try a clean home directory -- the guest session perhaps
[19:22] <Laney> rofl
[19:22] <Laney> I didn't even know it was a problem until 10 minutes ago
[19:22] <Laney> I think I'll leave it ;(
[19:23] <bmhm> xD
[19:26] <hyperair> lol
[19:28] <bmhm> I hate half-translated things. Our LUG Forum says "Post new Forenbeitrag" XD
[19:29] <directhex> das ist sucky
[19:30] <bmhm> =)
[19:30] <RainCT> omg :P
[19:31] <iulian> directhex: That's in German, right?
[19:31] <RainCT> iulian: yep
[19:31] <iulian> I mean, "das" and "ist"
[19:31] <iulian> = this is?
[19:31] <RainCT> and "Forenbeitrag"
[19:31] <iulian> OK, calm down.
[19:31] <RainCT> iulian: yep
[19:32] <iulian> ;)
[19:32] <RainCT> uhm?
[19:32]  * RainCT is just doing time to not do homework :P
[19:33] <iulian> Those are the only two words I know in German and you come with complicated words like "Forenbeitrag".
[19:33] <iulian> s/words/word.  It is actually one word.
[19:33] <henrik-hw0> eng: forum contribs.
[19:33] <RainCT> lol
[19:33] <RainCT> or, better, "post" :P
[19:34] <iulian> Oh, I know one more.  "und", which means "and", if I'm not wrong.
[19:35]  * iulian hides from German people.
[19:35] <RainCT> :D
[19:35] <bmhm> lol
[19:35]  * bmhm slaps uilian
[19:35] <bmhm> damn, missed =)
[19:35] <bmhm> I mean the key :P
[19:35] <iulian> Haha
[19:35] <hyperair> the only thing german i know is the food.
[19:35] <iulian> Ouh
[19:36] <iulian> Actually, I know some more words in German.
[19:36] <bmhm> of cause
[19:36] <bmhm> kindergarten
[19:36] <bmhm> Poltergeist
[19:37] <bmhm> Blitzkrieg
[19:37] <bmhm> U-Boot (-boat)
[19:37] <bmhm> zigzag (zickzack)
[19:37] <bmhm> etc.
[19:37]  * hyperair loves having a complete archive mirror on LAN
[19:37]  * RainCT misses german bakery :P
[19:38] <bmhm> ?
[19:38] <bmhm> meaning what?
[19:39] <RainCT> bmhm: stuff like this http://www.otstrasbourg.fr/IMG/jpg/Picto_bretzel_1.jpg and this http://www.biomalz-back.de/produkte/einzelne_produktseiten/rezeptur_feine_backwaren/berliner400.jpg :P
[19:39] <bmhm> ah misses = I miss
[19:39] <RainCT> xD
[19:39] <bmhm> i was thinking at Mrs.
[19:39] <bmhm> :D
[19:39] <RainCT> LOL
[19:40] <bmhm> yeah german cuisine is tasty
[19:40] <bmhm> Schnitzel, Curry-Wurst (= Sausage) and so on
[19:40] <bmhm> ha I once visited australia, BBQ-Nation. I traveld all the way and the first thing I got was Schnitzel.
[19:42] <RainCT> well, I guess I should poweroff the screens and get some work done :P
[19:42] <bmhm> =)
[19:43] <hyperair> and i should poweroff my notebook and get some sleep
[19:43] <Laney> yes you should!
[19:47] <bmhm> it's 8:47 pm here :>
[19:51] <hyperair> it's 3:51AM here
[19:51] <bmhm> wow
[19:51] <hyperair> good night-uh-morning!
[19:51] <bmhm> you should really get to bed! :P
[19:52] <pochu> hyperair: from?
[19:52] <pochu> hyperair: night
[19:52] <hyperair> pochu: GMT+8
[19:52] <hyperair> pochu: singapore
[19:52] <hyperair> now off to bed i go
[19:52] <pochu> oh
[19:52] <hyperair> class in 4h 40 mins
[19:52] <pochu> hyperair: if I ever go to singapore, I'll tell you :)
[19:53] <bmhm> I've been at the main airport
[19:53] <bmhm> wow it's hot there
[21:23] <__Ali__> does this room's log available somewhere?
[21:23] <Laney> http://irclogs.ubuntu.com
[21:23] <__Ali__> i think someone tried to answer my question, but i was away
[21:36] <savvas> __Ali__: they usually highlight you, if you have a script or a client that can detect your nickname and highlight, that's great :)
[21:38] <__Ali__> savvas, yes it was highlighted, but the log buffer was too small
[21:39] <savvas> bummer
[21:39] <savvas> no local logs?
[21:39] <__Ali__> what's the alternative of using .install files wiyj cdbs?
[21:39] <bmhm> if it were important, __Ali__, they would have said your name again
[21:39] <__Ali__> with*
[21:40] <savvas> it's a bit easier to do local search: grep -i "_ali_" ~/irclogs/Freenode/#ubuntu-motu.log
[21:40] <__Ali__> seems DEB_INSTALL_DIRS_ALL creates a directory, which cdbs command actutally copies the files?
[21:40] <savvas> (for irssi client that is)
[21:42] <__Ali__> and, where the heck is the detailed cdbs manual? in the source code? just google DEB_INSTALL_DIRS_ALL and all u get is patch files
[21:44] <savvas> that's the question I was about to ask :P
[21:45] <savvas> __Ali__: I know there's a way to use "install:" in debian/rules to override the default stuff
[21:45] <savvas> or do additional commands, not sure
[21:45] <savvas> you have to use dh_install for that
[21:46] <geser> __Ali__: have you looked inside /usr/share/doc/cdbs/? I've there cdbs-doc.html and cdbs-doc.pdf.gz
[21:47] <savvas> firefox /usr/share/doc/cdbs/cdbs-doc.html
[21:47] <savvas> oh, too late :)
[21:48] <__Ali__> thanks, wiered it's not online
[21:48] <jpds> It is, madduck has it up somewhere.
[21:49] <__Ali__> actutally it's the samedoc which is online
[21:49] <__Ali__> but no command details
[21:50] <__Ali__> it's only in the code: http://www.google.com/codesearch/p?hl=en#WRVRMSS8dPQ/cdbs-0.4.48/1/rules/debhelper.mk.in&q=DEB_INSTALL_DIRS_ALL&l=23
[21:51] <__Ali__> is dh_install used for copying lib* files o should one of dh_install* family members be called for that?
[21:53] <Tonio_> hi there
[21:53] <Tonio_> anyone available for revuing kmplayer please ? that would be nice since the konqueror component of the kde3 currently packaged version is broken with kde4...


[23:38] <imMute> well, the stuff I'm interested in is in a device driver which doesn't get autoloaded (on purpose) so it's only an annoyance when the system crashes and I can't run dmesg to see what happened.