[18:31] <Eickmeyer> OvenWerks: The Papirus team made custom icons for Carla, Carla Controls, and Ubuntu Studio Controls.
[18:38] <OvenWerks> cool
[18:38] <OvenWerks> Eickmeyer: how is you sh/bash fu?
[18:38] <Eickmeyer> Not sure about how I feel about the Ubuntu Studio Controls one, since it's just the CoF.
[18:39] <Eickmeyer> Define sh/bash fu (I feel like I'm novice, but I'm probably better than I think I am).
[18:39] <OvenWerks> I have a line:
[18:39] <OvenWerks> while [ "x$list $list2" != "x" ] ; do
[18:40] <Eickmeyer> Eek... seems a little clumsy if you're doing a while...do.
[18:41] <Eickmeyer> Unfortunately, that's a bit over my head. :/
[18:41] <OvenWerks> I am thinking that $list and $list2 are evaluated when that line is run the first time. so if I then make list="$list $list2" that should not affect that line's work.
[18:42] <Eickmeyer> teward: Can we pick your brain? ^
[18:43] <OvenWerks> I think I have my answer...
[18:43] <Eickmeyer> Oh?
[18:43] <OvenWerks> a few lines down they redo list
[18:44] <OvenWerks> They remove the part of the list they have already dealt with
[18:44] <Eickmeyer> Oh, okay.
[18:44] <OvenWerks> so, if I combine list and list2, I have to make list2=""
[18:44] <Eickmeyer> That makes sense, therefore removing items from the list as it progresses.
[18:45] <OvenWerks> Basically, list is the list of *lowlatency and list2 is the list of *generic kernels
[18:46] <OvenWerks> So I want to make sure there is still some kernel to add to the list
[18:46] <Eickmeyer> Ok, I get it now.
[18:46] <Eickmeyer> Had no idea what you were trying to accomplish until I got the context. :P
[18:46] <OvenWerks> But after I have done the first two entries I then want to combine the lists for the submenu.
[18:48] <OvenWerks> Basically, if there is only a generic kernel I still have to have a default selection
[18:49] <Eickmeyer> Right.
[18:56] <teward> Eickmeyer: still need to pick my brain?
[18:56] <teward> sorry i missed the highlight (@teward001 so it shows up always on my telegram pings too btw)
[18:56] <Eickmeyer> teward: Nah, OvenWerks figured it out.
[18:56] <teward> OK
[18:56] <teward> i pay attention to my telegram pings more than my IRC pings heh
[18:57] <Eickmeyer> No worries.
[18:57] <teward> right now I need the SRU team to let a no-changes rebuild through to bionic-proposed for NGINX :p
[18:57] <teward> for OpenSSL 1.1.1 stuff
[18:57] <Eickmeyer> Oh, fun. :P
[18:58] <teward> well thankfully it's a no-brainer since there's no changes, we just need to queue a rebuild xD
[18:59] <Eickmeyer> Oh, that's good.
[18:59] <Eickmeyer> Triggering no-changes rebuilds. Fun.
[19:00] <teward> yep.  nginx inherits whatever OpenSSL is available to it, in this case it was built on 1.1.0 so it needs to rebuild for some TLS 1.3 fun
[19:01] <teward> but no changes in NGINX, just needs to get OPenSSL 1.1.1 libs for its build :P
[19:01] <Eickmeyer> And, of course, then the pain of getting something simple like that through an SRU. :P
[19:01] <teward> pain for you maybe
[19:01] <teward> but the OPenSSL SRU was already done :p
[19:01] <teward> this is just one of fifty things that still need a rebuild :P
[19:05] <Eickmeyer> Joy. /s


[04:30] -lugito:#lubuntu-devel- [rMANUAL1a9280019ac1: Add changing driver] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL1a9280019ac1
[04:33] -lugito:#lubuntu-devel- [rMANUAL849c1e4f0a93: Add how to add users to a list of not being allowed to print] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL849c1e4f0a93
[04:36] -lugito:#lubuntu-devel- [rMANUALe40d6003323e: Add removing user from list of not being able to print] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALe40d6003323e
[05:14] -lugito:#lubuntu-devel- [rMANUAL2c5e8e46ee6f: ADd Deny printing for everyone except] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL2c5e8e46ee6f
 Did you guys check the latest message in devel mail list?
 I think someone should comment there and explain that font settings in lxqt desktop, openbox settings and desktop configurations are for different things.
 https://fosspost.org/amp/reviews/distributions/lubuntu-19-04-review … Here's a link to the post.
 Honestly Lubuntu is fine
 And AFAIK, transparency is fine only right?
 All the flavors are kind of falling behind
 They think LXDE/LXQt is old
 and ugly
 honestly a bs post
 @ItzSwirlz [honestly a bs post], Yeah I know. But the user sent it to devel list to bring issues to our notice. Atleast we can reply to the mail and inform that most of these are fixed in eoan na?
 The brightness and min/maximize issues he pointed are good.
 @The_LoudSpeaker [Did you guys check the latest message in devel mail list?], I'm going to respond later in a personal capacity
[17:57] -lugito:#lubuntu-devel- [T122: New Manual URL Design] tsimonq2 (Simon Quigley) commented on the task: https://phab.lubuntu.me/T122#2418
[18:05] -lugito:#lubuntu-devel- [T41: Lubuntu 19.10] tsimonq2 (Simon Quigley) commented on the task: https://phab.lubuntu.me/T41#2420
[19:33] -lugito:#lubuntu-devel- [rMANUALe44e57a819c3: Add prop settings screenshot] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALe44e57a819c3
[19:34] -lugito:#lubuntu-devel- [T54: Properly implement different wallpapers for different monitors] hmollercl (Hans P. Möller) commented on the task: https://phab.lubuntu.me/T54#2421
 what's the difference for upgrading for development between changin sources or "sudo do-release-upgrade -d"
 ?
[19:55] -lugito:#lubuntu-devel- [rMANUAL7bfba6652b67: Add prop=access-control screenshot] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL7bfba6652b67
[21:13] -lugito:#lubuntu-devel- [rMANUALa5b831e17988: Add Policies tab summary] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALa5b831e17988
[21:14] -lugito:#lubuntu-devel- [rMANUAL7c43fd879e96: Add how to disable printer] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL7c43fd879e96
[21:16] -lugito:#lubuntu-devel- [rMANUAL02250f745894: Add disabling accepting jobs for a printer] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL02250f745894
[21:18] -lugito:#lubuntu-devel- [rMANUAL8f116f2d8f32: Add not to sahre a printer] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL8f116f2d8f32
[21:26] -lugito:#lubuntu-devel- [rMANUALdfb12fa6d7d1: Add starting banner] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALdfb12fa6d7d1
[21:27] <guiverc> tsimonq2, T56 testcases is up for review; to my knowledge my stuff is done
[21:31] -lugito:#lubuntu-devel- [rMANUAL888e2b806ea6: Add Ending banner to printing] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL888e2b806ea6
[21:38] -lugito:#lubuntu-devel- [rMANUAL40543e4d7dc8: Add prop polices screenshot] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL40543e4d7dc8
[21:40] -lugito:#lubuntu-devel- [rMANUAL0f54296b1309: Fix typo] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL0f54296b1309


[09:43] <frickler> I'm having issues opening a kernel bug, getting a very fast Timeout error every time, can anyone take a look? latest Error ID: OOPS-291b189de43eaeb841cd62083c38bbb7
[10:04] <cjwatson> that one's some kind of weird internal database maintenance job that occasionally blocks us from executing trigger functions, but so far it's always gone away after ten minutes or so
[10:05] <cjwatson> have you already tried "wait ten minutes and try again"?
[10:45] <frickler> cjwatson: sorry, didn't spot your reply earlier. I did retry a couple of times, not sure about the timespan though. I was then successful using the URL provided by "ubuntu-bug linux" instead
[12:47] <vila> cjwatson: qastaging looks really dead now (haven't used it for > a week now, just checking the timeouts from time to time)
[21:02] <cjwatson> vila: It must have been made sad by some recabling work.  The site is back now (though timeouts are no better).


[14:30] <thegodfather> hey tmarble
[15:00] <tmarble> thegodfather: ciao!
[15:16] <thegodfather> tmarble: hey
[15:16] <tmarble> hows the new man?
[15:17] <thegodfather> seems ok.. waiting the blood test results from today
[15:39] <tmarble> i'll keep my fingers crossed!
[19:28] <jbailey> lamont: Have you had a chance to try that glibc on a UP kernel?
[19:50] <lamont> jbailey: no
[19:50] <jbailey> 'k


[02:22] <Noskcaj> Can we get one of the xubuntu members as an admin on the xubuntu sub-reddit? Then we could get a flair like the ubuntu subrddit
[02:23] <pleia2> I won't go near reddit, so if someone else wants to they are welcome to
[02:24] <GridCube> i don't understand reddit
[02:24] <GridCube> it makes no friggin sense
[02:25] <Unit193> Man that site can be funnah. :D
[02:26] <Unit193> Not looked at any subs on there for a while though.
[02:27] <Noskcaj> GridCube, It's one of the best (and if well used, best for promotion) websites. It is difficult to learn though
[02:27] <Noskcaj> pleia2, I could try and contact the mods. I'm looking into a similar thing for kubuntu and lubuntu
[03:46]  * skellat notes far too late that he outright abandoned reddit as he found little use for it in the end game as it was full of...nothing...
[11:11] <brainwash> ochosi: regarding the greeter -> xfce transition, http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c#n806
[11:12] <brainwash> ochosi: you can build xfwm4 with MONITOR_ROOT_PIXMAP defined
[11:12] <brainwash> ochosi: I'll test it and report any drawbacks
[12:17] <brainwash> the xfce4-panel app menu is able to scale pixmap icon files properly (now), but the xfdesktop app menu still isn't
[12:18] <brainwash> it also does not display the missing-icon-file symbol
[12:19] <brainwash> strnage inconsistency
[12:39] <ochosi> yeah, separate menus
[12:40] <ochosi> brainwash: i'm very interested to hear about that xfwm4 thingy
[13:41] <brainwash> ochosi: I don't notice any change
[13:43] <brainwash> ochosi: I even compiled it a second time after editing the source file directly
[14:28] <ochosi> brainwash: hm, right, well xfdesktop's maintainer is aware of the issue
[14:33] <brainwash> ochosi: of what? the general issue?
[14:34] <ochosi> the slow startup of xfdesktop
[14:34] <brainwash> and the missing pixmap scaling?
[14:34] <brainwash> did you talk to him/her?
[14:36] <brainwash> (you can test it with gcolor2 for example)
[14:39] <ochosi> missing pixmap scaling?
[14:40] <ochosi> (there's just been the first 4.11 release of the desktop today, btw)
[14:44] <brainwash> install gcolor2, right-click the desktop > app menu > graphics
[14:46] <ochosi> that menu is gone in 4.11
[14:47] <ochosi> (which is what i'm using atm)
[14:47] <ochosi> so you have to be more concrete with the pixmap scaling issue
[14:47] <brainwash> gone?!
[14:47] <ochosi> yeah, there's only the app-menu
[14:48] <brainwash> what I'm trying to tell you is, that xfdesktop is still affected by bug 1061037
[14:48] <ochosi> aha
[14:49] <brainwash> the normal panel menu isn't anymore
[14:49] <ochosi> true
[14:50] <brainwash> I guess we simply ignore this :)
[14:50] <ochosi> well xpm icons are very retro ;)
[14:50] <ochosi> but yeah, it should be fixed at some point
[14:50] <ochosi> ideally for 4.12
[14:51] <brainwash> and only few apps ship a launcher with full path xpm icon specified in their .desktop file
[14:51] <brainwash> IDLE, gcolor2, gnome disk analyzer
[14:52] <ochosi> are there bugreports for those apps upstream?
[14:52] <ochosi> (or are all of them still maintained?)
[14:55] <brainwash> don't fix the apps, fix the broken app menu :D
[14:55] <brainwash> which will be gone soon anyway :/
[14:56] <ochosi> no, that app-menu is still there
[14:57] <ochosi> there were 2 variants in the 4.10 desktop-menu
[14:58] <brainwash> ah, so 1 menu implementation remains
[14:58] <brainwash> for both
[14:58] <ochosi> one that was solely for apps and one that had some desktop-specific stuff
[14:58] <ochosi> now there's only the one for apps
[14:58] <ochosi> at least as far as i can say
[15:16] <brainwash> ochosi: should I file the bug report about the non smooth greeter -> desktop transition against xfwm4, xfdesktop, xfce4-session or xubuntu-meta?
[15:17] <ochosi> i'm not sure :}
[15:26] <Pwnna> it must be said
[15:26] <Pwnna> ubuntu 13.10 is stil lreally unstable :P
[15:50] <brainwash> Pwnna: what exactly is unstable?
[15:51] <Pwnna> everything
[15:51] <elfy> nope
[15:51] <elfy> not so here
[15:51] <Pwnna> cannot go to sleep. if i play video games for a while (couple minutes), my computer will slow down and frame rate drops by about 60%.
[15:51] <Pwnna> no reason either, there's no overheating and such
[15:52] <elfy> I assume you've posted bugs where appropriate
[15:52] <Pwnna> not a lot of logs. the only thing i can see is this: https://bugzilla.kernel.org/show_bug.cgi?id=53571 but that's related to lock up
[15:52] <Pwnna> elfy: i don't have logs..
[15:52] <Pwnna> like. nothing in the logs
[15:53] <Pwnna> bluetooth mouse does not reconnect like it did in 13.04
[15:53] <elfy> ubuntu-bug blueman
[15:54] <Pwnna> but i don't have logs.. so like it's like saying.  hey my bluetooth requires me to manually reconnect sometimes, not all the time. also i don't have logs
[15:54] <Pwnna> in 13.04 it worked!
[15:54] <Pwnna> that kinda bug report is not really useful :3
[15:54] <elfy> ubuntu-bug blueman
[15:55] <elfy> and saying 'everything is unstable' is useful?
[15:55] <Pwnna> it's not
[15:55] <Pwnna> i was hoping someone can help me get logs
[15:55] <Pwnna> the graphics/processing issue is the critical one
[15:55] <Pwnna> but i can't get any logs
[15:56] <Pwnna> i can reproduce everytime
[15:58] <elfy> then report it - use ubuntu-bug and it'll grab what it needs afaik - then watch the bug and see if anything else is required
[16:03] <Pwnna> well for the graphics one idk what the component maybe
[16:03] <Pwnna> it might be the kernel, mesa, idk
[16:03] <brainwash> there are plenty of log files located in /var/log
[16:03] <Pwnna> nothing relating to the grapics issue.
[16:04] <Pwnna> other than that bug that i found upstream, but that one is a) relating to lockups (which it did on my system) and b) present for a long time, but didn't show before. so i doubt that whatever is happening now is related to that..?
[16:06] <elfy> Pwnna: so what grpahics card is it
[16:06] <Pwnna> happens on both my intel HD 3000 and the nvidia card
[16:07] <Pwnna> i think that one is quadro 4200
[16:07] <elfy> so how long has this been going on then with saucy?
[16:07] <Pwnna> ever since i upgraded to it
[16:07] <elfy> right
[16:08] <elfy> I'm not psychic enough to be able to guess when that was
[16:08] <Pwnna> oh. 4 days ago
[16:08] <brainwash> can you still boot one of the raring kernels or are they gone already?
[16:08] <Pwnna> i see stack traces... probably relating to the sleep issue
[16:08] <Pwnna> brainwash: gone
[16:10] <brainwash> not sure, if this is the right channel for this kind of issue
[16:10] <brainwash> does not seem to be xubuntu specific
[16:11] <brainwash> did you already ask in #ubuntu+1?
[16:11] <elfy> Pwnna: you might well find someone who can help in #ubuntu+1
[16:12] <Pwnna> yeah
[16:12] <Pwnna> maybe
[16:44] <brainwash> Notice(queuebot): Unapproved: rejected libxfce4ui [sync] (saucy-proposed) [4.10.0-4]
[16:48] <elfy> saw that ...
[16:50] <elfy> brainwash: confirmed thge xfwm4 bug
[16:51] <ochosi> what xfwm4 bug?
[16:51] <brainwash> more like a wishlist thingy
[16:51] <elfy> the one you two were talking about earlier - "If the built-in compositor is enabled, xfwm4 will draw a plain grey background over the lightdm greeter background on session login"
[16:52] <brainwash> bug 1232804
[16:53] <ochosi> ah ok
[16:54] <ochosi> yeah, as i said, not sure what component this bug should actually be filed against
[16:54] <brainwash> did some more code hacking, but no success so far
[16:54] <ochosi> have you tried enabling the splash-screen?
[16:54] <ochosi> i mean the xfce-splash-screen
[16:54] <brainwash> no, isn't that some ancient stuff?
[16:55] <brainwash> and could it help?
[16:55] <ochosi> well, it might still help to create a custom splash-screen that shows the user's wallpaper
[16:55] <ochosi> for me it's hard to test anyway, the ssd makes the session load very quickly, so i don't see your bug
[16:56] <brainwash> compositing enabled?
[16:56] <ochosi> yup
[16:56] <ochosi> i also use autologin
[16:56] <ochosi> that might contribute
[16:56] <brainwash> yea
[16:58] <brainwash> it's just an idea for the next milestone
[16:59] <elfy> maybe tag it brainwash
[16:59] <elfy> though it might be useful to sort out an official xubuntu tag of some sort
[16:59] <brainwash> don't know how
[17:00] <brainwash> or which tag
[17:02] <elfy> no idea how to create a new one - we were talking about this the other day
[17:02] <elfy> or at least someone and me was lol
[17:03] <skellat> We got libxfce4ui rejected in queue.  Somebody may need to pop over to #ubuntu-release to discuss that.
[17:13] <ochosi> what version of libxfce4ui is that and why was it uploaded?
[17:13] <ochosi> connected to a bugreport?
[17:13] <ochosi> brainwash: just to add that, xfwm4 is not currently in active development
[17:13] <ochosi> at least not really
[17:15] <brainwash> bug 1228731
[17:15] <elfy> ochosi:  connected with bug 1055407 and bug 1198746
[17:16] <elfy> bug 1054407
[17:16] <elfy> I mean :)
[17:16] <ochosi> ah right
[17:16] <ochosi> xfhelp stuff
[17:16] <elfy> yup
[19:41] <Unit193> xnox: Howdy.  Do you know where I should go for questions with ubiquiry and casper?
[20:12] <Noskcaj> hey mr_pouit
[20:19] <mr_pouit> hey Noskcaj
[20:20] <Noskcaj> xfwm4 just got merged and libxfce4ui will be synced very soon
[22:05] <xnox> Unit193: #ubuntu-installer
[22:32] <brainwash> any idea, how I could debug bug 1206739 ?
[22:36] <Noskcaj> brainwash, install the -dev and -dbg packages for it if they exist, then run it from a terminal (with debug enabled, if possible). That's at least where to start
[22:38] <brainwash> sadly no debug mode available, and running it from another terminal window will instantly crash both when the bug gets triggered
[22:39] <brainwash> running it from a different terminal app will freeze the session (partially)
[22:40] <Noskcaj> brainwash, maybe add "| tee FILENAME" at the end to get the logs (where FILENAME is whatever you want), but i assume the logs get recorded anyway
[22:40] <brainwash> well, actually it does freeze the session completely, a working cursor does not help that much :)
[22:42] <brainwash> tee redirects only stdout
[22:42] <brainwash> I'll try it
[23:00] <ochosi> brainwash: i think the most effective thing you can do is file a bug upstream
[23:00] <ochosi> or check whether there's already one
[23:01] <ochosi> and as soon as NSchermer is around again, you can ask him whether he can reproduce it
[23:01] <ochosi> but it's possibly ubuntu-specific
[23:02] <brainwash> maybe it needs to be rebuilt against a recent version of glib
[23:03] <brainwash> I want to improve my debugging skills... but thus particular bug is strange
[23:03] <brainwash> this
[23:11] <brainwash> ochosi: are there any Xfce (core) developers which are also members of the Xubuntu team?
[23:17] <ochosi> not really
[23:17] <ochosi> bluesabre, mr_pouit and me contributed a bit to the display settings
[23:18] <ochosi> but at the moment there aren't even that many core devs of xfce
[23:22] <brainwash> ok :/
[23:22] <brainwash> I guess they could need some man power for the gtk3 transition
[23:23] <brainwash> and wayland support
[23:24] <ochosi> indeed
[23:24] <ochosi> feel free to start contributing!
[23:25] <ochosi> or even start to motivate/recruit others ;)
[23:26] <brainwash> I'm trying to get started, but the source code seems be quite complex and it's not easy to understand what's going on :)
[23:27] <brainwash> and the whole api mess
[23:27] <brainwash> hundreds of different apis
[23:30] <ochosi> trying to fix bugs is always a good start


[11:08] <Wiz_KeeD> hello guys, can someone please tell me if bzr qlog should be readily available when installing bzr or is it a third-party that i need to isntall? (Ubuntu 32bit 12.04 LTS)
[11:13] <Peng> Wiz_KeeD: Ought to be the, uh, qbzr package. I think.
[11:13] <Wiz_KeeD> i tried installing it with apt-get and i got The following packages have unmet dependencies:
[11:13] <Wiz_KeeD>  qbzr : Depends: python-qt4 but it is not going to be installed
[11:13] <Wiz_KeeD> E: Unable to correct problems, you have held broken packages.
[11:14] <Peng> Sorry, apt is not my thing.
[11:14] <Wiz_KeeD> heh,thanks anyway man
[11:51] <ychaouche> Wiz_KeeD: there should be an apt command to fix your packages
[11:52] <Wiz_KeeD> tried several, none worked ychaouche
[12:09] <ychaouche> Hi #bzr. I want to start with bazaar, I just read the 5min tutorial and the getting started guide and I have a few questions : So suppose I have my code in code. I'd cd to code, then the getting started guide tells me to bzr init. bzr help init tells me that This creates and empty branche. How come I can create a branch without creating a repository first ?
[12:10] <ychaouche> Or is the repository created along with the branch and everything is put inside the .bzr directory ?
[12:11] <ychaouche> I have the feeling that source code (files) are mixed with the "revisions", i.e bzr files. They're all put inside the source code. Am I right ?
[12:12] <ychaouche> I'm coming from subversion where source code is checked out from a repository, where svn stores branches/revisions etc.
[12:21] <ychaouche> Please tell me if this is correct : http://pastie.org/pastes/5501937/text
[12:28] <fullermd> You can do init without init-repo just fine.  It'll just colocate and use an internal repo.
[12:28] <fullermd> Which is a related, but not identical, construct to svn's repo.
[12:37] <ychaouche> fullermd: ok suppose I do init-repo to create a repo, then init to create a branch. Is this workflow correct ?
[12:37] <fullermd> Assuming there's a "cd" in the middle, so the branch is under the repo.
[12:37] <fullermd> But really, if you're just starting out working with bzr, I'd ignore it.
[12:38] <fullermd> Using repos properly makes things a lot nicer, but it's not a semantic difference, and thinking about it at this point is likely to overcomplicate things.
[12:39] <fullermd> You're thinking svn; in svn, the repo is an important (or _the_ important) boundary/unit.  In bzr, it's completely irrelevant; the _branch_ is the important unit.
[12:39] <ychaouche> ah ok
[12:40] <ychaouche> thanks for this _important_ information
[12:40] <ychaouche> no pun intended
[12:40] <ychaouche> So one doesn't really need a repository right ?
[12:41] <fullermd> Not an explicitly-created one, no.  If you don't make one (with init-repo), each branch (made with init) will create and use an internal one.
[12:41] <ychaouche> fullermd: So I'll just create a normal directory with mkdir foo instead of bzr init-repo foo and put my branches there
[12:41] <fullermd> All that a shared repo does is save you disk space/IO/etc by sharing storage between branches.  Everything works the same either way.
[12:42] <ychaouche> ok, I'll do that in a second stage
[12:42] <fullermd> And you can use reconfigure to switch things around to using a shared repo later, so I'd recommend ignoring it for the moment, just to cut down on the number of things you're thinking about.
[12:42] <ychaouche> ah cool
[12:43] <ychaouche> So, suppose I want to work on a dev branch, and from times to times, when features are ready, create a production branche. How do I create a production branche ?
[12:43] <fullermd> `bzr branch dev production`
[12:43] <ychaouche> fine
[12:44] <ychaouche> let me try this
[12:44] <fullermd> You may find some of the stuff in and around <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief> useful.  Or maybe not.
[12:44] <fullermd> Won't mean much until you use the commands for a little while, probably; doesn't help with that.  But it does talk about the abstract pieces underneath that you're manipulating.
[12:45] <ychaouche> ok let's leave that for later.
[12:45] <ychaouche> ok I created a branche. How cool is that.
[12:46] <ychaouche> fullermd: so if I just copy everything inside a branch and give it to someone, it contains everything he needs to branch/merge and do stuff, right ?
[12:47] <fullermd> Normally, you'd do that by having the branch somewhere they can read, and let them use it as the source for a `bzr branch` invocation of their own.
[12:47] <ychaouche> do I need to setup a webserver for that ?
[12:47] <ychaouche> or a bazar server ?
[12:48] <fullermd> Most common is probably ssh access.  Though that's more of a bother when people don't already have shared access to a system somewhere.
[12:48] <fullermd> You can run over dumb http; it'll be slower than over a smart transport, though you probably won't notice the difference with small branches.
[12:49] <fullermd> And there's the bzr:// server, which works OK for ad-hoc or global readability.  It doesn't have any AAA support or hooks, so it won't suit a lot of cases.
[13:24] <ychaouche> bzr explorer : bzr: ERROR: No module named explorer.lib.commands http://pastie.org/5502113
[13:25] <ychaouche> I'm using bzr 2.4.1
[15:42] <ychaouche> Is it problematic if the parent branch is not where bzr thinks it is ? http://pastie.org/5502524
[15:50] <jelmer> ychaouche: no, that shouldn't matter
[15:50] <jelmer> ychaouche: it just means that it will do the wrong thing if you don't specify a branch explicitly to 'bzr pull'
[15:50] <ychaouche> jelmer: fine
[15:50] <ychaouche> Same for merging, right ?
[15:50] <ychaouche> should I merge back dev to prod.


[03:05] <mfisch> hggdh: you around?
[14:16]  * TheLordOfTime sighs
[14:16] <TheLordOfTime> https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1088908  <-- this isnt a MySQL bug.  Unity perhaps?
[14:16] <ubot2`> Launchpad bug 1088908 in mysql-5.5 (Ubuntu) "Unable to manually lock screen when specific item has focus" [Undecided,New]
[14:20] <mdeslaur> TheLordOfTime: same root cause as bug 49579
[14:20] <ubot2`> Launchpad bug 49579 in gnome-screensaver (Ubuntu) "screen doesn't lock when some menu is open" [Low,Triaged] https://launchpad.net/bugs/49579
[14:21] <TheLordOfTime> mdeslaur, so, repoint to gnome-screensaver and mark as dupe?
[14:22] <mdeslaur> yeah, I guess...it's really an X issue though
[14:22] <mdeslaur> but yeah, gnome-screensaver is good enough...doesn't really matter on bugs that are completely ignored :P
[14:22] <TheLordOfTime> :P
[14:24] <TheLordOfTime> done
[14:24]  * TheLordOfTime returns to poking his computer
[14:36] <hggdh> mfisch: now I am


[00:06] <ajmitch> lfaraone: I see you mentioned the RC bugs stuff in the DMB meeting, what were you using to do that?
[00:06] <lfaraone> ajmitch: http://qa.ubuntuwire.org/bugs/rcbugs/maverick/ and http://qa.ubuntuwire.org/bugs/rcbugs/lucid/
[00:06] <ajmitch> OK, you have any suggestions for improving those?
[00:07]  * ajmitch wrote & maintains that lot
[00:07] <ajmitch> I see you mentioned AJAX in there, something that's been on my TODO list, especially as I've been doing a lot of that at work lately :)
[00:12] <ajmitch> lfaraone: nothing to change then? :)
[00:14] <lfaraone> ajmitch: it has no deficencies as it currently is. What would be nice is a page that would allow us to tell at a glance what the delta is, in terms of changelogs. Pie in the sky feature request:a full diff, which we might be able to extract from bzr or manually.
[00:14] <ajmitch> no reason why that can't be cached & calculated
[00:15] <ajmitch> I'll see what I can do
[00:15] <lfaraone> ajmitch: awesome, thanks!
[00:15] <ajmitch> there are a few other things I'd like, such as giving some information on the bug without having to click through everywhere
[00:15] <ajmitch> it's currently generated through cron, and doesn't change that rapidly
[00:33] <Rhonda> Can someone explain these two things to me? https://bugs.launchpad.net/bugs/6556 and https://bugs.launchpad.net/bugs/6477
[00:34] <ajmitch> somehow/somewhen the bug was assigned to that time & it was getting set back
[00:35] <ajmitch> registry administrators is a launchpad team that sort of ends up as a default owner for stuff, I think
[00:47] <Rhonda> ajmitch: Ah, confusion on my part anyway. But still awkward a bit for 4 year closed bugs. %-)
[00:59] <ajmitch> yeah, it looks rather strange, I wonder why it was done
[01:03] <Rhonda> ajmitch: Just received a third mail about Bug 5606 :)
[01:04] <Rhonda> Seems like someone is doing historical cleanup
[01:19] <pabelanger_> I was hoping somebody could help me and see if I have completed Bug #579045 properly?  I'm trying to get a package from Debian merged into Ubuntu
[01:21] <Rhonda> pabelanger_: I would expect the package should automatically get synced into maverick once that job works again.
[01:22] <pabelanger_> Rhonda: Where can I learn more about the sync process between Debian and Ubuntu
[01:25] <Rhonda> pabelanger_: https://wiki.ubuntu.com/SyncRequestProcess - but like said, that's only needed after DIF.
[01:28] <pabelanger_> Rhonda: ok, thanks for the information.
[03:05] <lfaraone> I prepaired a security upload a while back. I don't think I can upload to that queue, but nobody has taken a look at the bug.
[03:06] <lfaraone> (rather, no actionhas been taken on it)
[03:08] <nigelbabu> lfaraone: poke kees if you can catch him or ask in #ubuntu-hardened
[03:08] <nigelbabu> someone should reply
[03:09] <lfaraone> nigelbabu: thanks.
[03:09] <nigelbabu> :)
[03:10]  * ajmitch suspects that most of the people who could upload it will be at UDS right now
[03:10]  * nigelbabu is pretty sure
[03:10] <nigelbabu> but they can assign it to themselves and take care fo it later
[03:10] <lfaraone> ajmitch: mk. the bug is about two months old, and the embargo ended 1.8 months ago :)
[03:11] <ajmitch> yeah, I can see that, hopefully someone will see it when they get online in the morning
[03:39] <lfaraone> ajmitch: are fake syncs frowned upon? I remember some discussion earlier in this channel about them.
[03:40] <ajmitch> generally yes, why do you need to do one?
[03:40] <lfaraone> ajmitch: just wondering, I don't.
[04:10] <bcurtiswx3> http://paste.ubuntu.com/432007/ anyone know what i need to do?
[04:16] <lfaraone> Hm. I'm having trouble determing the utility of the patch in https://edge.launchpad.net/ubuntu/+source/sablotron/1.0.3-1ubuntu1. Does anybody have an idea what exactly it does? (it touches a bunch of files, but I don't see the utility of it)
[04:17]  * bcurtiswx3 waves to luke
[04:22] <lfaraone> hey bcurtiswx3, let me take a look.
[04:23] <lfaraone> bcurtiswx3: well, the package requires that the version of telepathy-logger be *exactly* 0.1.1. If that is a real (insofar as the newer version does not work) dependency you are screwed, otherwise you may be able to change it to a >= without problems.
[04:23] <lfaraone> bcurtiswx3: I'm not sure where that's expressed in the package code, esp since I don't know the package this comes from :)
[04:24] <bcurtiswx3> telepathy-logger
[04:24] <bcurtiswx3> its simple actually
[04:24] <bcurtiswx3> maybe i can find it
[04:25] <lfaraone> bcurtiswx3: no, I mean what are you trying to build?
[04:25] <bcurtiswx3> empathy
[04:28] <lfaraone> bcurtiswx3: from the source in ubuntu, or some odd version?
[04:28] <bcurtiswx3> source in freedesktop
[04:32] <lfaraone> ajmitch: oh, it'd be nice to add comments to RCbugs marked as unimportant. I just did some research on syncing "lash" over, but I'll have to remove it from unimportant before commenting.
[04:33] <ajmitch> lfaraone: that should be trivial enough
[04:35] <MTecknology> Is it possible to uncompress a .deb and see the debian/ directory? Or is that completely separate?
[04:37] <lfaraone> MTecknology: there is no longer a "debian" directory. There is "DEBIAN", but it's not the same.
[04:39] <MTecknology> lfaraone: oh.. is it possible to reconstruct it or is it more of a binary form?
[04:39] <lfaraone> MTecknology: I'm not sure, I try not to touch it :)
[04:40] <MTecknology> lfaraone: alrighty- I'll try to find another way to get the stuff I'm looking for :P - thanks
[04:40] <lfaraone> Why is it that running "rmadison -u qa libtinyxml-dev" gives me results while "requestsync -n --lp libtinyxml-dev" says it's not in sid?
[04:40] <lifeless> rmadison hits a debian website; requestsync hits ubuntus mirror of sid
[04:41] <ajmitch> ubuntu's mirror of sid is not being updated properly, mostly due to files not being generated properly on ftp.debian.org
[04:42] <ajmitch> alsmot, requestsync probably requires the source package (tinyxml)
[04:46]  * ajmitch is hoping that someone is able to fix it there soon
[04:46] <ajmitch> it's a little annoying trying to do merges for maverick & having the branches on LP be out of date, which I suspect is related to this
[04:48] <lifeless> yes
[04:49] <lifeless> the debian branches are driven by the info about debian that lp holds
[04:56] <lfaraone> ajmitch: just for clarification, what I was talking about earlier was http://people.canonical.com/~pitti/scripts/syncpackage.
[04:59] <ajmitch> right, fake syncs are something different
[04:59] <lfaraone> ajmitch: okay, bug syncpackage is kosher, though? I guess I misunderstood.
[05:00] <ajmitch> I think it's ok, I know that some people have been changing that script around though, and will put it in ubuntu-dev-tools
[05:01] <ajmitch> apart from that, I don't know the current status of it
[05:04] <lfaraone> Mk. Long term there will be a LP button to do the same, so I understand.
[05:48] <carstenh> lfaraone: utility of the patch? like cdbs' simple patch system?
[06:02] <MTecknology> how can I uncompress a .deb?
[06:03] <tsimpson> ar x file.deb
[06:03] <ajmitch> dpkg-deb -x package.deb /path
[06:03] <tsimpson> bah, that's just the long version
[06:04] <carstenh> | dpkg-repack - puts an unpacked .deb file back together
[06:04] <ajmitch> while you'll see the generated control file, maintainer scripts, etc, you won't h ave debian/rules & the other important biuts for reconstructing the package from source
[06:06] <MTecknology> thanks
[07:34] <wrapster> if i have pre built libraries.. and i use lets say i build a pkg around these libs to put them into respecitve locations.. would it make a differnce if i just copied these prebuilt libs than actually using the 'install' cmd?
[08:16] <slytherin> is there any nice howto on using sbuild in lucid? Last time I tried it in karmic it wasn't as easy to setup as pbuilder.
[08:18] <Rhonda> slytherin: It never is "as easy to setup as pbuilder". It's different and more powerful after all.
[08:18] <slytherin> Rhonda: more powerful does not necessarily have to be complex to setup.
[08:19] <Rhonda> Depends. More things to know about and consider. :)
[08:25] <Rhonda> slytherin: Did you read sbuild-setup(7)? Are there specific issues? That manpage is mentioned in the README.Debian doc file.
[08:26] <slytherin> Rhonda: I am still installing packages. Will check manpage after that.
[08:27] <Rhonda> Regularly enough packages do come with documentation included. :P
[08:49] <slytherin> siretart: is there any plan on working on mplayer in lucid-backports once updated version lands in maverick?
[08:52] <siretart> slytherin: the problem is that a newer mplayer will not work with lucid's ffmpeg
[08:52] <slytherin> :-(
[08:53] <siretart> slytherin: I intend to create packaging scripts for a package called 'mplayer-snapshot', which will a) be in upstream's svn, and b) use the internal copy of ffmpeg
[08:53] <siretart> and autoupload it daily or biweekly or something
[08:53] <slytherin> that will be nice.
[08:54] <siretart> that package will always be up-to-date but not really a candidate for a distro release
[10:32] <ari-tczew> why http://qa.ubuntu.com/reports/bug-fixing/ maverick-fixes-report doesn't exist?
[12:33] <mirsal> hey there :)
[13:34] <bilalakhtar> Hi people, can anyone review my package gnome-media-player? its here http://revu.ubuntuwire.com/p/gnome-media-player and needs-packaging bug #551702
[13:35]  * slytherin hopes moovida gets faster UI in new version. :-(
[13:37] <nickbnf_> Hi, quick question for you guys: does REVU supports the new 3.0 (quilt) format?
[13:37] <slytherin> nickbnf_: don't think so
[13:37] <bilalakhtar> nickbnf_: no. see bug #500753
[13:37] <nickbnf_> aaw... now my package is "This package could not be extracted; there's no browsable directory for it on REVU."
[13:37] <nickbnf_> ok, thanks!
[13:39] <nickbnf_> So do you think it's better for me to re-add the quilt boilerplate in debian/rules and builddeps just so that my package displays nicely in REVU?
[13:41] <bilalakhtar> nickbnf_: As you can see my package on http://revu.ubuntuwire.com/p/gnome-media-player , I have left it like that, and a motu has advocated. no need to do that
[13:42] <bilalakhtar> sponsors don't care, they simply dget and dpkg-source
[13:42] <nickbnf_> bilalakhtar: ok thanks!
[13:44] <lfaraone> carstenh: no, like what it actually does.
[13:45] <ari-tczew> bdrung: what about comment "ACKed." in syncpackage script? not necessary?
[13:46] <azeem>  /W 36
[13:46] <azeem> oops
[13:46] <ari-tczew> near change importance to wishlist
[13:48] <bilalakhtar> Hi people, can anyone review my package gnome-media-player? its here http://revu.ubuntuwire.com/p/gnome-media-player . Its lintian clean and a motu has already advocated it
[13:53] <BlackZ> bilalakhtar: I suggest you to subscribe ubuntu-sponsors for your bug
[13:54] <bilalakhtar> BlackZ: After I do that, will a message go to ubuntu-sponsors?
[13:55] <BlackZ> bilalakhtar: Yes. But please, keep in mind you're in a queque.
[13:55] <bdrung> ari-tczew: why should there be an "ACKed." comment?
[13:55] <nickbnf_> BlackZ: a queque?
[13:56]  * bilalakhtar asks the same question as nickbnf_
[13:56] <bdrung> bilalakhtar: are you the guy who filed the ITP in debian?
[13:56] <BlackZ> s/queque/queue
[13:56] <astraljava> nickbnf_: bilalakhtar: a queue
[13:57] <bilalakhtar> bdrung: yeah
[13:57] <nickbnf_> BlackZ: :-)
[13:57] <bdrung> bilalakhtar: i can have a look at the package later this day
[13:57] <bilalakhtar> bdrung: But I have to maintain different versions in both distros, because of libgstreamermm missing in debian unstable. no problems so far for ubuntu
[13:58] <nickbnf_> bilalakhtar: how is your pkg progressing on debian side?
[13:58] <ari-tczew> bdrung: because you as sponsor give ACK for sync approv
[13:58] <bilalakhtar> nickbnf_: Have to disable a feature in debian, as debian unstable doesn't include libgstreamermm (yet)
[13:58] <bdrung> ari-tczew: instead of acknowledging the sync, i am doing the sync. you can see that the upload was sponsored by me.
[13:58] <BlackZ> bilalakhtar: So you could package it :)
[13:59] <bilalakhtar> BlackZ: I am one of the upstream authors as well
[13:59] <BlackZ> bilalakhtar: Another reason for do that.
[14:00] <bilalakhtar> yeah
[14:00]  * bilalakhtar and BlackZ think the same
[14:01] <ari-tczew> bdrung: ok. I'm thinking about link a branch to sync bug request. does will be done automatically, or your script can handle linking a branches?
[14:03] <bdrung> ari-tczew: linking a branch?
[14:04] <ari-tczew> bdrung: lp:ubuntu/current-development/package
[14:06] <bdrung> ari-tczew: i doubt that this will work in the script, because the branch needs some time to pick up the uploaded package
[14:06] <ari-tczew> bdrung: just only link to branch, not handling code in bzr
[14:08] <bilalakhtar> bdrung: Thanks for your interest. I hope you look at the package whenever you are free.
[14:19] <carstenh> lfaraone: the patch in debian did fix/prevent ftbfs bugs ages ago by re`libtool'izing. jbailey removed useless stuff from this patch when 1.0.2 was the current version (you see that it is based on 1.0.2 when you look at the filenames in the patch). the patch from jbailey is mentioned in the debian changelog version 1.0.2-4 and was included in debian until (including) version 1.0.2-5.2, whilst packaging the new upstream in debian the patch ...
[14:19] <carstenh> ... has been recreated without the care a gnu maintainer like jbailey takes when doing such things.
[14:19] <lfaraone> carstenh: okay, so can it be dropped?
[14:20] <carstenh> lfaraone: debian did drop it when 1.0.3 was released and it did not break anything since then ;)
[14:22] <bilalakhtar> People, can anyone over here review my (second) package for Ubuntu? Its liboauth,found at http://revu.ubuntuwire.com/p/liboauth
[14:22] <carstenh> lfaraone: i would drop it, it might be cleaner when less files are patched but i consider having the packages in sync and avoiding such discussions twice a year more important than a "clean and minimal patch"
[14:26] <lfaraone> What should we do about packages depending on a virtual package? (libmagickcore-extra
[14:26] <lfaraone> What should we do about packages depending on a virtual package? (libmagickcore-extra is depended on by xpad, but only libmagickcore2-extra exists)
[14:28] <carstenh> lfaraone: in debian sid it's libmagickcore3-extra.
[14:28] <bilalakhtar> Sorry, people, had a connection problem
[14:30] <bilalakhtar> People, can anyone over here review my (second) package for Ubuntu? Its liboauth,found at http://revu.ubuntuwire.com/p/liboauth . I have run a test build using pbuilder, no problem with build-depends
[14:35] <lfaraone> bilalakhtar: "the MIT license" is ambiguous, quote the entire license text.
[14:36] <bilalakhtar> lfaraone: But isn;t this much obvious?
[14:37] <bilalakhtar> lfaraone: Can I give an internet address to the license ?
[14:37] <lfaraone> bilalakhtar: "Several variants of the MIT license exist: (1) the standard version with three paragraphs (blanket permission, keep this notice, NO WARRANTY), (2) a version with a no-endorsement clause, and (3) other versions with slight wording differences."
[14:37] <lfaraone> bilalakhtar: No.
[14:38] <bilalakhtar> lfaraone: This is the 1st one
[14:39] <lfaraone> bilalakhtar: by the way, your debian/copyright MUST declare the authorship and copyright of xmalloc.c, which it currently does not.
[14:40] <bilalakhtar> lfaraone: Whenever I have been asked to correct a mistake in a package, it has always been a copyright error
[14:41] <lfaraone> bilalakhtar: hehe, it's hard to get right.
[14:41] <bilalakhtar> lfaraone: you are a motu, right?
[14:42] <lfaraone> bilalakhtar: yes, I am. I'm currently checking other parts of your package.
[14:48] <lfaraone> bilalakhtar: also, you need to reference /usr/share/common-licenses/LGPL-2 rather than /usr/share/common-licenses/LGPL. Use © instead of (C). The first line of your package's description MUST not exceed 80 characters. Lintain also reports "spelling-error-in-manpage usr/share/man/man3/oauth.3.gz recieve receive" as well as "liboauth-dev: spelling-error-in-manpage usr/share/man/man3/oauth.3.gz paramater parameter".
[14:49] <lfaraone> bilalakhtar: let me know if you'd rather I post these comments on REVU, poke me when you update the package.
[14:50] <bilalakhtar> lfaraone: ok, put the comments up on revu, in the meantime, I had updated the package on revu twice, since you began. check the lastest version for errors
[14:54] <ari-tczew> in the shop
[14:57] <bilalakhtar> lfaraone: I have made all these changes. uploading now. changes should be visible soon
[14:59] <bilalakhtar> looks like lfaraone has gone away
[15:02] <bilalakhtar> I am also going away, incase you come back, please be patient. shall be back in 20 minutes.
[15:11] <bilalakhtar> lfaraone, the new upload is visible now. When you come back, please see 'em. If you find them to be ok, please advocate. else, comment
[15:21] <lfaraone> If someone else has advocated a package, can I be the second advocate *and* uploader?
[15:25] <bilalakhtar> lfaraone: see the package now. http://revu.ubuntuwire.com/p/liboauth
[15:26] <lfaraone> bilalakhtar: building now.
[15:31] <lfaraone> bilalakhtar: looks good. you might want to consider using a patch system rather than modifying the upstream source directly, but what you have is fine.
[15:31] <bilalakhtar> lfaraone: so should I change it to 3.0 (quilt) or leave it like this?
[15:32] <geser> I've seen that the software has also a test suite. I would be good to run it after build
[15:33] <lfaraone> Hm. For some reason REVU does not realize I'm a MOTU, or I don't realize how to work it properly :)
[15:33] <geser> and you can remove the commented out dh_* calls that you don't need
[15:34] <bilalakhtar> lfaraone: yeah, I noticed that earlier. Are you a member of motu team in lp? then it should recognise you
[15:34] <lfaraone> bilalakhtar: Yes, as of yesterday.
[15:34] <geser> lfaraone: I'm not sure if REVU recognizes it itself or if you need to poke an REVU admin
[15:34] <lfaraone> bilalakhtar: By the way, have you noticed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496737 ?
[15:35] <bilalakhtar> lfaraone: oops, no
[15:35] <lfaraone> bilalakhtar: your preference. I personally like using a patch system since it makes uploading new upstream versions easy.
[15:35] <bilalakhtar> lfaraone: let this one go by, I will use quilt in the future
[15:35] <lfaraone> bilalakhtar: no worries. that was opened upstream by the author, and is a "Request for Package", so don't worry, your work is not for naught.
[15:36] <lfaraone> bilalakhtar: you might want to consider uploading the package to Debian rather than Ubuntu. In Debian, it will automatically be synced to Ubuntu. And maybe you can find a MOTU who's also a DD who will upload it for oyu...
[15:37] <lfaraone> geser: where would I find such a creature?
[15:37] <bilalakhtar> lfaraone: Fine, I will upload it to debian afterwards.  If you find it fit, and are able to (revu is the roadblock right now) then please advocate.
[15:43] <bilalakhtar> thanks for your help and interest!
[15:43] <lfaraone> bfiller: no problem.
[15:43] <geser> lfaraone: usually in this channel, but I don't remember who is an REVU admin
[15:46] <Laney> REVU says, doesn't it?
[15:48] <lfaraone> Laney: hm?
[15:48] <sebner> geser: RainCT persia ?
[15:49] <RainCT> What's up?
[15:49] <RainCT> ok
[15:50] <RainCT> lfaraone: done
[15:51] <Laney> http://revu.ubuntuwire.com/stats
[15:51] <Laney> down there
[15:54] <lfaraone> RainCT: thanks :)
[15:56] <RainCT> no problem :)
[16:21] <ari-tczew> on lucas merges red colorized packages seems to got a new upstream release?
[16:23] <lucas> ari-tczew: yes
[16:23] <ari-tczew> thanks lucas
[16:24] <lfaraone> RainCT: speaking of REVU, if one other MOTU has advocated a package, and I want to advocate it as well, can I go ahead and upload, or does another MOTU have to do the upload after I sign off?
[16:28] <RainCT> lfaraone: Usually the second MOTU to advocate uploads the package (so you) :)
[16:33] <kklimonda> hey guys, do you have a working watch file for projects hosted on google code ?
[16:34] <lfaraone> kklimonda: Yes, one moment please.
[16:35] <lfaraone> kklimonda: http://svn.debian.org/wsvn/python-apps/packages/autokey/trunk/debian/watch
[16:35] <kklimonda> lfaraone: thanks
[16:41] <ari-tczew> zul: I saw that you did sponsor on bug 578729 you can sync package using script syncpackage
[16:41] <ari-tczew> and where is confirmed status if ACKed?
[16:42] <zul> ari-tczew: no i didnt request the sync
[16:43] <ari-tczew> zul: I know, I wrote: you did sponsor (ack comment)
[16:47] <kklimonda> lfaraone: unfortunately it doesn't work anymore :/
[16:57] <kklimonda> didrocks: can we sync vala now that debian has 0.8.1 ?
[16:57] <kklimonda> or do they still have tests disabled?
[17:10] <bilalakhtar> lfaraone: Hi. I saw your comment. do I need to remove the extra lines? is it important?
[17:10] <bilalakhtar> lfaraone: I am currently installing the built deb and testing
[17:12] <kklimonda> hmm, tests are enabled but they fail because buildd has no dbus running..
[17:12] <lfaraone> bilalakhtar: well, it makes for a more readable rules file.
[17:13] <lfaraone> bilalakhtar: but running the test suite is *definitely* a Good Idea™.
[17:13] <bilalakhtar> lfaraone: I am running the test suite right now
[17:13] <bilalakhtar> lfaraone: My question is about the rules file
[17:14] <lfaraone> bilalakhtar: what geser means is that you should call the test suite in the rules file to verify the build worked as expected.
[17:15] <bilalakhtar> ohk
[17:16] <bilalakhtar> lfaraone: how do I do that? fakeroot debian/rules (what should be here) ?
[17:18] <kklimonda> how stupid is launching dbus server at build time to make unittests pass? should I rather just comment out all tests related to dbus?
[17:19] <lfaraone> kklimonda: as long as it doesn't require root, it's fine.
[17:19] <bilalakhtar> lfaraone: how do I run the test suite? fakeroot debian/rules (what should be here) ?
[17:20] <kklimonda> check
[17:20] <lfaraone> kklimonda: he'd add it to the build-stamp rule, right?
[17:20] <BlackZ> lfaraone: when you upload a package, you should set the status of the bug in "fix committed"
[17:22] <lfaraone> BlackZ: In Debian, uploading a package which goes to NEW automatically sets the bug "pending", I'd expect Ubuntu to have something similar, but I could be mistaken.
[17:22] <bilalakhtar> kklimonda: not working. `No rule to make target `check`. Stop.1
[17:22] <kklimonda> lfaraone: hmm.. I'd add check-stamp to install-stamp as you can build package but not be interested in running unit tests..
[17:23] <lfaraone> kklimonda: well, dh_auto_test honors "nocheck" in DEB_BUILD_OPTIONS
[17:24] <kklimonda> lfaraone: shouldn't dh_auto_test be called automatically anyway if you don't override too much?
[17:24] <bilalakhtar> lfaraone: I ran build-stamp. Is that what we need?
[17:24] <lfaraone> kklimonda: he's using the old-style debhelper rules.
[17:24] <BlackZ> lfaraone: nope, when you have uploaded the package and it's in the NEW queue, you should set the status of the bug in "Fix Committed", check that here: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[17:24] <bilalakhtar> yeah, guys, I am not using dh7
[17:24] <BlackZ> "Once the approved package is uploaded, the uploading MOTU will set the bug status to Fix Committed."
[17:25] <lfaraone> bilalakhtar: you neeed to add "dh_auto_test" as a command to the "build-stamp" rule.
[17:26] <lfaraone> BlackZ: If you'd rather, I can get an Archive Admin to cancel the upload so we can solve this policy inconsistency. Or, you can change the flag in the bug yourself, I don't have it on hand.
[17:26] <BlackZ> lfaraone: you can set the status now: https://bugs.launchpad.net/ubuntu/+bug/503436
[17:26] <BlackZ> :)
[17:27] <lfaraone> bilalakhtar: does that make sense?
[17:28] <bilalakhtar> lfaraone: yeah, done, no probs, removing the bummy commented lines now
[17:31] <BlackZ> lfaraone: however I have few packages which needs review/advocation: http://revu.ubuntuwire.com/p/anomos and http://revu.ubuntuwire.com/p/ppa-purge - I'd be glad if you can help me ;)
[17:31] <bilalakhtar> lfaraone: uploading now. should be available soon on revu
[17:32] <kklimonda> hmm, ppa-purge is worth advocation
[17:34] <bilalakhtar> I hate revu for one thing: It never extracts 3.0 (quilt) packages
[17:34] <bilalakhtar> lfaraone: upload available on revu now. just dget http://revu.ubuntuwire.com/revu1-incoming/liboauth-1005121833/liboauth_0.6.0-0ubuntu1.dsc
[17:36] <bilalakhtar> people, will come back after some time (30 minutes) advocate if you find it fit
[17:36] <BlackZ> bilalakhtar: dget -xu is more comfortable
[17:56] <bilalakhtar> lfaraone: Hi there! I m back. Did you see the recent changes?
[18:00] <DeeJay1> hi. Can someone point me to a reasonable guide how to make daily builds if the debian directory for a package is in bzr on launchpad?
[18:02] <bilalakhtar> DeeJay1 I didn't completely understand it. Do you want every push to the branch to be pushed to the ppa also? or you want to build someone else-s branch?
[18:04] <DeeJay1> no, I want a make a script running from cron which would pull the sources from launchpad, build it then push to a ppa
[18:05] <DeeJay1> seems like I should use bzr-builder but Google doesn't return any serious results for me
[18:05] <bilalakhtar> DeeJay1: ohk, thats somewhat long. ask someone else.
[18:06] <DeeJay1> hehe, ok :)
[18:27] <bilalakhtar> lfaraone: Are you there?
[19:09] <RainCT> sebner: btw you were right that Java is better than C++, this thing sucks balls :P
[19:10] <sebner> RainCT: hahaha, I told you :D
[19:25] <stevecrozz> I've already built a package in my PPA for karmic, now I want to update it for lucid
[19:26] <stevecrozz> I tried grabbing the source for the karmic package and doing debuild -S again using my new lucid install, but it was rejected
[19:26] <stevecrozz> "File nginx_0.7.65-0ubuntu1~stevecrozz~ppa0.diff.gz already exists in stevecrozz, but uploaded version has different contents"
[19:27] <ari-tczew> stevecrozz: change version to ~ppa1
[19:28] <stevecrozz> ari-tczew: thanks, ill do that
[19:30] <stevecrozz> ari-tczew: is there a better way to maintain current packages for multiple versions of ubuntu?
[19:32] <ari-tczew> stevecrozz: on ppa? I don't think so. You can upload a head package to latest development or stable release, then backporting to older releases versioning ~backport~karmic1 ~backport~jaunty1 etc.
[19:53] <wfaulk> what's the proper way to suggest a piece of software to be included in Ubuntu?
[19:54] <jpds> File a needs-packaging bug.
[19:55] <wfaulk> cool.  thanks.