[02:35] <Eighth_Doctor> would someone be able to process this? https://bugs.launchpad.net/ubuntu/+source/pagure/+bug/1867775
[02:35] <Eighth_Doctor> it's a sync request for a package in focal from debian sid that only contains packaging fixes
[02:36] <Eighth_Doctor> there's basically zero risk to the ubuntu archive
[03:42] <RAOF> Conan Kudo: Hm. What is that actually fixing? You say “basically no risk”, but the second changelog entry suggests that the first one broke the package 😜
[06:04] <ivoks> rafaeldtinoco why not just take over ubuntu-ha? it has more members, ppas, history...?
[06:42] <alkisg> Hi, what's the last date when we can sync bug-fixing-releases from debian without FFEs? FinalFreeze on April 16th? (there's a security issue I'm trying to find the best way to resolve)
[09:35] <LocutusOfBorg> hello tjaalton, did you have chance to test it?
[09:36] <Laney> ddstreet: Just noticed that all(?) systemd-upstream CIs are borked ...
[09:36] <Laney> they seem to randomly terminate with no useful output
[09:38] <tjaalton> LocutusOfBorg: yes, didn't help :/
[09:38] <tjaalton> LocutusOfBorg: filed it upstream as https://github.com/llvm/llvm-project/issues/191
[09:38] <tjaalton> fedora doesn't seem to enable polly, which is why they haven't hit this
[09:51] <LocutusOfBorg> tjaalton, do you have a log?
[09:51] <tjaalton> LocutusOfBorg: looks the same
[09:52] <LocutusOfBorg> mmm strange, the bug and patches looked good to me
[10:27] <tjaalton> something broke the url handler in terminator..
[10:29] <ginggs> hasta la vista url handler
[11:06] <sil2100> Aw crap, the langpack gpg key expired
[11:07] <sil2100> seb128: hey! Do you remember the procedure of getting new gpg keys for Ubuntu Langpack Uploader ?
[11:07] <sil2100> The current key expired 2020-02-10
[11:11] <Eighth_Doctor> RAOF: well, I mean, the package is kind of broken right now, when I meant no risk, nothing important in ubuntu would break :P
[11:12] <Eighth_Doctor> as of right now, the missing dependency and the broken maint scripts means this thing doesn't work at all
[11:55] <sil2100> Oh, and I need to wait for the translation stats to publish, the first focal ones should appear soonish
[11:55] <sil2100> So I'll kick the updates then
[11:57] <ddstreet> Laney it seems like some are currently running ok, did you fix it?
[11:57] <Laney> nope
[11:57] <Laney> they will probably fail out
[11:57] <Laney> or you mean you can see successful results?
[11:58] <ddstreet> no i was jjust looking at currently running ones - i'm pulling the last 40 finished runs now to look at
[12:30] <seb128> sil2100, no idea, I don't think the key ever expired since pitti left
[13:11] <xnox> doko:  have you been working on removal of unversioned python build-deps? or not at the moment? I think I see a few more, but not too sure if they are in progress or not.
[13:18] <doko> xnox: I had the hope I catched them all. what are you seeing?
[13:19] <xnox> doko:  things like https://bugs.launchpad.net/ubuntu/+source/cinfony/+bug/1868259
[13:21] <xnox> doko:  https://paste.ubuntu.com/p/WbcnxrPn8v/
[13:21] <xnox> doko:  lots of Build-Depends-Indep: python (>= 2.*)
[13:21] <ddstreet> Laney yeah it seems like the testbed is hanging while installing the newly built systemd pkgs to test :-/
[13:22] <xnox> and Build-Depends: python (>= 2.*) too
[13:22] <ddstreet> i'll run some tests manually to see if it hangs for me also
[13:22] <doko> hmm, wondering why I didn't catch those
[13:22] <Laney> ddstreet: :(
[13:22] <Laney> cool
[13:22] <Laney> hopefully it does and then you get get into the instance to debug
[13:22] <xnox> doko:  https://paste.ubuntu.com/p/JnbqWMD9xh/ is the pkg list imho
[13:23] <xnox> doko:  but some might be like fixed in -proposed =( i don't have a good way to catch that
[13:24] <doko> crap, some more work :-(
[13:24] <xnox> doko:  do you want to do them? or me?
[13:24] <xnox> doko:  i don't have powers to like RM packages like cinfony above
[13:24] <xnox> (cannot be built anymore, removed from testing)
[13:25] <doko> I'll walk through that list
[13:25] <xnox> thank you, hopefully most of it, is just RM removed from debian
[13:26] <xnox> some we still need for sure, like libaccounts-glib
[13:26] <xnox> but not sure
[13:30] <doko> xnox: edgy-community-wallpapers, naked people?
[13:31] <xnox> doko:  let's see
[13:31] <xnox> doko:  naked people were calendar wallpapers, no?!
[13:31] <xnox> doko:  that one is just a plant
[13:32] <xnox> doko:  which for a static file has setup.py and setup.cfg
[13:32] <xnox> ah to translate <_name>Dawn Of Ubuntu</_name>
[13:32] <xnox> doko:  i'll make that one python3
[13:32] <xnox> doko:  continue with something else
[13:33] <cjwatson> the dubious wallpapers were edgy in nature but not in timing :)
[13:39] <doko> heh
[13:40] <xnox> uploaded port to python3
[15:21] <Eickmeyer> Hi all! I've got some very pressing issues in ubiquity that need to be taken care of. At first I had bug 1851346 back in December, but now bug 1868191 has popped up and they're both related to the manual package selection for Ubuntu Studio.
[15:22] <Eickmeyer> I see two solutions for this: 1) we fix the problem (preferable) or 2) we disable the package selection altogether.
[15:22] <Eickmeyer> Either way, I don't want these bugs landing in an LTS, and I don't have the know-how to fix them
[15:22] <Eickmeyer> bdmurray: ^
[15:24] <bdmurray> Eickmeyer: bug 1851346 is on our list of things to fix
[15:26] <Eickmeyer> bdmurray: I hope so. Looks like 1868191 might be a duplicate? I'm not sure, but it seems to be the same problem.
[15:38] <bdmurray> Eickmeyer: I'll add it to our list to look at as a team
[15:38] <Eickmeyer> bdmurray: I'd appreciate it. :)
[16:14] <bdmurray> vorlon: Is there any duplicate searching to be done for bug 1867431 or did you do that already?
[16:53] <vorlon> bdmurray: I had not looked for duplicates of LP: #1867431
[16:54] <vorlon> coreycb: I was on PTO yesterday; did you get what you needed wrt python-decorator? (did you talk to #ubuntu-release?)
[17:25] <rbasak> bryce: I filed a fairly minor MP with definitely-needed commits that are finished from my branch, to reduce the size of the upcoming one. No rush to review, though it should be trivial.


[06:34] <oSoMoN> good morning desktoppers
[06:35] <duflu> Morning oSoMoN
[06:35] <duflu> (#firstpost)
[06:37] <oSoMoN> hey duflu :)
[07:00] <didrocks> good morning
[07:02] <jibel> Bonjour à tous
[07:03] <duflu> Morning didrocks and jibel
[07:04] <oSoMoN> salut didrocks & jibel
[07:08] <didrocks> hey jibel, duflu, oSoMoN
[07:58] <pieq> Hi everyone
[07:59] <didrocks> salut pieq
[08:00] <pieq> I installed focal this morning on a testing laptop and I noticed the install process UX has changed a little
[08:01] <jibel> pieq, bonjour
[08:01] <pieq> and the option to encrypt the partition is hidden now... so by default, if the user clicks Next, the system is installed without any kind of disk encryption
[08:01] <jibel> pieq, the partitioning page?
[08:01] <pieq> it's alreayd like this in 18.04, but the option to encrypt is visible from the screen, so I figure it's more "findable" by users
[08:01] <jibel> pieq, yes, it's on purpose and it's one of the concerrn that have been raised with this change
[08:01] <pieq> jibel, the page where you're asked if you want to "Erase disk and install Ubuntu"
[08:01] <pieq> OK
[08:02] <pieq> I reckon there are many different installation scenarios for users
[08:02] <pieq> but for someone installing Ubuntu on a laptop without any other partitions, it makes sense to have the disk encryption option available "easily" (if not by default)
[08:04] <jibel> pieq, we probably need to move back everything from a advanced dialog to the main page but then it adds lot of data to the page especially when you have a system already installed
[08:05] <pieq> jibel, yes, that's the kind of tricky thing. I was testing on a laptop that had no dual boot or weird stuff
[08:05] <pieq> I could spend more time investigating this, but I don't have much time now
[08:16] <seb128> gooood morning desktopers! happy friday
[08:29] <didrocks> happy Friday seb128
[08:29] <seb128> lut didrocks, happy friday! how are you?
[08:31] <duflu> Morning seb128. How goes?
[08:32] <seb128> hey duflu, okish, I've a cold/I'm coughing for a few days seems a bit worth today, I feel a bit like if I had fever with my skin by sensitive
[08:33] <seb128> I'm going to try to get it easy, hopefully I'm feeling better to fly to CapeTown tomorrow
[08:33] <duflu> :(
[08:33] <seb128> during my previous trip there I had over 39°C fever and that was no fun at all
[08:33] <seb128> hopefully not a second time
[08:33] <seb128> duflu, how is it going for you?
[08:34] <seb128> ready for the we? :)
[08:34] <duflu> seb128, going OK though gnome-shell is always more complex than you think...
[08:34] <duflu> The weekend will come when I'm ready
[08:40] <didrocks> seb128: I’m fine, thanks, and you?
[08:41] <seb128> didrocks, cf backlog :)
[08:57] <didrocks> good luck! :)
[09:01] <Wimpress> Morning o/
[09:02] <Wimpress> Sorry to hear you feeling under the weather seb128 :-(
[09:02] <seb128> hey Wimpress! how are you?
[09:02] <seb128> Wimpress, I wil take it easy today, hopefully I feel better by tomorrow
[09:02] <Wimpress> seb128: Yes, best to rest up.
[09:03] <Wimpress> All good here.
[09:03] <Laney> morning
[09:03] <seb128> hey Laney, how are you?
[09:03] <Laney> yeah I'm alright
[09:04] <Wimpress> duflu: I noticed the CSD windows and non-CSD window have a different size window shadow.
[09:04] <Laney> are you allergic to Cape Town seb128?
[09:04] <duflu> Morning Wimpress and Laney
[09:04] <Wimpress> A curiosity that caught me out while making screenshots for the sideshow last night.
[09:04] <seb128> Laney, I might be?
[09:05] <Wimpress> Do you know why this might be duflu?
[09:05] <duflu> Wimpress, interesting. Though I have argued for a long time that CSD should get server side shadows, I think I lost that argument. That means it is expected -- different code rendering it
[09:05] <duflu> You would need to modify all toolkits to match your theme
[09:05] <Wimpress> Yeah. I can't see why the inconsistency would be required, from a technical point of view.
[09:06] <duflu> Which code exactly I don't know
[09:06] <duflu> This is partly why I argued for years we shouldn't be in this situation
[09:07] <Wimpress> I wrote a script to resize, cature and scale windows at exactly the right sizes for including in the installer slideshow.
[09:07] <duflu> I feel shadows should not be seen as part of the window, but an artefact of the desktop
[09:07] <Wimpress> That difference between CSD and non-CSD had me scratching my head for a few minutes, until a realised what was going on.
[09:07] <Laney> moin duflu
[09:11] <seb128> brb, going back to my desk now
[09:16] <didrocks> good morning Wimpress !
[09:19] <duflu> Wimpress, hopefully you're only talking about non-Gnome apps. We should be able to make Gnome ones consistent between CSD (Xwayland) and SSD (Xorg)
[09:20] <duflu> I mean CSD (Wayland)
[09:25] <Wimpress> Yeah, I notice the difference with Shotwell, Firefox and LibreOffice.
[09:37] <duflu> Wimpress, if apps are running via X11, including Xwayland, then we have fairly central control over the shadow rendering
[09:38] <Wimpress> I am running on X11.
[09:38] <duflu> And if you configure them to use system titlebars etc, not app-level CSD
[09:40] <Wimpress> When you say configure, you mean a programmatic change to not use CSD?
[09:40] <duflu> Yes, like it's a setting in Chrome
[09:40] <Wimpress> Right.
[09:40] <duflu> Maybe it is in Firefox?
[09:40] <Wimpress> It is. But bugs.
[09:40] <Wimpress> Curved window corners grow ears.
[09:46] <seb128> the arm builders seem unhappy, between that and ffi I think I just give up for this week and see if things automagically sort out during the w.e
[09:47] <seb128> also wth with i386 failing to install build-essential:amd64 :/
[09:48] <duflu> Wimpress, I'm already confusing myself so if you encounter the problem in release please remember to open a bug
[09:49] <oSoMoN> Wimpress, is this bug #1828728 (for firefox) ?
[09:51] <duflu> Yes I think that's it
[11:49] <Wimpress> didrocks: I've prepared a branch for ubiquity-slideshow that implements the new Yaru design and updates screenshots for 20.04.
[11:50] <Wimpress> I've proposed for merging, but not update debian/changelog. Should I?
[12:02] <didrocks> Wimpress: yes. feel free to update the changelog (but keep it UNRELEASED instead of focal'
[12:45] <Wimpress> OK
[15:18] <hellsworth> good morning desktopers!
[15:18] <didrocks> good morning hellsworth!
[15:20] <hellsworth> hi there didrocks ! happy friday :)
[15:21] <didrocks> thx! you too
[15:22] <oSoMoN> good morning hellsworth
[15:23] <oSoMoN> I need a core dev for a trivial code review: https://code.launchpad.net/~osomon/software-properties/+git/software-properties/+merge/377770
[15:27] <hellsworth> looks good oSoMoN !
[15:58] <didrocks> oSoMoN: merged and pushed. Do you think that worth a release or we will have other fixes later on?
[15:59] <oSoMoN> didrocks, thanks! there'll definitely be other changes before feature freeze, so no need to do a release now
[16:00] <didrocks> ack :)
[16:08] <hellsworth> oSoMoN: there's a chromium snap question in #snapcraft that maybe you know the answer to: "Hi, I had the cromium snap on my other computer. I reinstalled all my programms on a new computer. I'm trying to get my bookmarks and settings to the chromium on my new computer. Befor snap it was something like .config/chromium or .local/share/chromium (can't remeber exatcly). What do I have to copy
[16:08] <hellsworth> to my new computer to get all my chromium settings?"
[16:11] <oSoMoN> hellsworth, thanks, I answered the question there
[16:27] <hellsworth> thanks oSoMoN !
[17:27] <oSoMoN> I'm calling it a week, have a good week-end everyone!
[18:06] <Wimpress> hellsworth: o/
[21:03] <hellsworth> hi Wimpress :)
[21:03] <hellsworth> sorry i was out for an appt and lunch


[21:45] <thumper> morning
[21:48] <mwhudson> sooo.... staging update?
[21:54] <lifeless> mwhudson: thumper: - seeking an opinion. Is bug 562931 worth having as a separate bug [doing the API side and web display without doing web attaching], or would you necessarily do the whole enchilada at once?
[21:54] <mup> Bug #562931: attachments in merge proposals <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/562931>
[21:54] <thumper> lifeless: yes I think it is worth it
[21:54] <thumper> lifeless: sorry, not enough coffee yet
[21:54] <thumper> lifeless: well...
[21:55] <thumper> lifeless: two bugs I think
[21:56] <lifeless> would you like me to undup and clarify, or will you ?
[22:04] <lifeless> thumper: ^
[22:05] <thumper> lifeless: you can :)
[22:08] <lifeless> what happens to attachments on emails sent to merge reviews, at the moment?
[22:09] <lifeless> thumper: what importance do you want on it? the 'attachments via web' bug has high
[22:09] <thumper> they should both probably be medium


[00:13] <blizzkid> Would https://edge.launchpad.net/~mcielen/+archive/ppa/+build/1195292 be something that could be included in Ubuntu?
[00:14] <blizzkid> And how would I get it included?
[00:33] <blizzkid> ok, found it, and filed a bug
[03:14] <LLStarks> yo
[03:14] <LLStarks> i need a motu immediately
[03:18] <ScottK> LLStarks: You need air to breathe.  You don't need a MOTU.
[03:18] <LLStarks> wrong.
[03:18] <ScottK> OK, then I'm probably not the one you want.
[03:18] <LLStarks> i need a motu to fix a grand injustice imposed on the karmic community.
[03:18] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/412195
[03:23] <LLStarks> so...
[04:58] <jedc> Hi, could anyone give me a quick rundown on what in the default debian/rules file is needed or unneeded if the package I'm compiling in not written in c and does not use a makefile? Must I use make? just some pointers in the write direction would be appreciated.
[04:58] <jedc> right direction
[04:58] <maco> afaik, dh7 lets you just have a 1-line rules by default and then you can throw in some overrides
[04:58] <maco> i forget the one line though :(
[04:59] <nhandler> maco: http://paste.ubuntu.com/261741/
[04:59] <maco> oh ok. 2 lines.
[05:00] <nhandler> Although, that may or may not work for what jedc wants to do. It all depens on the application
[05:02] <jedc> thats all you need? i thought you needed targets for build clean and everything because the utilities all use them
[05:03] <ScottK> dh 7 provides that behind the scenes.
[05:03] <ScottK> For many standard applications it just works like that.
[05:03] <ScottK> Sometimes you have to over-ride the standard config.
[05:04] <jedc> the default rules generated by dh_make has a lot of stuff in it
[05:05] <ScottK> Yes.  That is what was needed before dh 7.
[05:05] <ScottK> You can still do it that way if you want.
[05:07] <nhandler> jedc: If you do decide to use the newer style, make sure you have an accurate debhelper Build-Depends version in debian/control. http://pkg-perl.alioth.debian.org/debhelper.html has some information about what version a few debhelper functions require
[05:08] <jedc> thanks guys, that looks a lot simpler
[06:50] <RAOF> So, my membership of ~motu is expiring soon.  What's currently happening the launchpad teams?  Is this the team-membership I should renew, or should I let it lapse?
[06:50] <lifeless> just renew
[06:51] <lifeless> can always discard it later
[07:09] <wgrant> RAOF: ~motu is the current universe/multiverse upload privileges team. ~ubuntu-dev is meant to end up with no direct memberships. All this will change within months post-archivereorg.
[07:10] <RAOF> wgrant: Thanks.
[07:55] <pzico> hi, what channel may I get advices related to making setup.py files?
[08:01] <Ademan> entirely out of curiosity, does anyone know where opengl shader source code would best be placed according to the FHS?  I commonly see it thought of as "media" making /usr/share a candidate, however shaders are in fact executable, though by the gpu, making /usr/lib a good placement, I think people would find /usr/lib a bit funny, however I think that's what I lean towards.  anyone else have an opinion?
[08:14] <RAOF> Ademan: I'd treat them as program data, as they're loaded by programs and then shuttled off to the GPU (hence /usr/share).  An alternative way to looking at them is: are they (CPU) architecture-specific?  If not, /usr/share is probably a better spot.
[11:10] <Zhenech> bdrung, I got mail, didnt reply yet (was on VAC)
[11:19] <somaunn> hello everyone
[11:40] <Zhenech> bdrung, replied
[11:58] <shiki-> hi all..anyone can help me with dh / Makefile / package building? :/
[12:00] <Zhenech> if you ask a specific question one could try to :)
[12:00] <dktrkranz> shiki-: just ask :)
[12:01] <shiki-> well.. its a package.. without ./configure.. a really.. uhm FUBAR one?..so to say..
[12:01] <shiki-> http://launchpadlibrarian.net/31005900/buildlog_ubuntu-jaunty-i386.fotoxx_<IP_ADDRESS>-1~jaunty7~ppa1_FAILEDTOBUILD.txt.gz
[12:01] <shiki-> this is the build log..
[12:01] <shiki-> well. it always fails at "No rule to make target 'build-stamp' ...
[12:02] <shiki-> Im not sure where to start.. tried to edit Makefile, that didnt give me any result
[12:02] <Zhenech> how does your debian/rules look like?
[12:02] <dktrkranz> do you have a "build: build-stamp" target in your debian/rules, and no build-stamp target?
[12:03] <shiki-> eeeeeh.. I overlooked this one
[12:03] <shiki-> ty
[12:03] <shiki-> trivial mistake
[12:04] <shiki-> will try to rebuild it ASAP
[12:04] <dktrkranz> just an advice, use pbuilder for local tests, using PPAs is a waste of buildd time
[12:05] <shiki-> okay..ty
[12:05] <shiki-> (I was confused about how to test it before uploading)
[12:05] <shiki-> thanks.
[12:05] <dktrkranz> you're welcome ;)
[12:23] <pzico> I have trouble running python setup.py sdist. The packet I get doesn't install. I have only one source file that can be run directly with python in src/gui folder.
[12:23] <pzico> I'm trying to learn making setup.py and packages, but I'm stuck with this simple problem.
[12:23] <pzico> Do I have to add that only py file in manifest?
[12:24] <dktrkranz> pzico: have you already looked at distutils online documentation?
[12:24] <pzico> yes I have
[12:24] <shiki-> ehm..pbuilder is not really handy on a vm :/
[12:24] <pzico> I was following it.
[12:25] <Zhenech> shiki-, pbuilder does not need a vm
[12:25] <dktrkranz> could you please paste your setup.py?
[12:25] <shiki-> ehm...
[12:25] <pzico> I also tried to add path the way described in documentation, but for some reason can't get it work.
[12:25] <dktrkranz> !paste
[12:26] <Zhenech> shiki-, pbuilder creates a chroot and builds there, so you can build debian on ubuntu and ubuntu on debian etc
[12:26] <pzico> #!/usr/bin/env python
[12:26] <pzico> from distutils.core import setup
[12:26] <pzico> setup(name='surem',
[12:26] <pzico>       version='0.1.1',
[12:26] <pzico>       description='program',
[12:26] <pzico>       author='I am',
[12:26] <pzico><EMAIL_ADDRESS>[12:26] <pzico>       packages={'surem' : ['src/gui/board_ui.py']},
[12:26] <pzico>     )
[12:27] <pzico> that board_ui.py is the only thing the program needs
[12:27] <shiki-> Zhenech, still, I cant install it on arch linux :)
[12:28] <Zhenech> shiki-, oh, well, technically you could :)
[12:28] <Zhenech> but yes, this makes it more difficult
[12:28] <Zhenech> but a chroot is still better than a VM imho
[12:28] <shiki-> well.. it works in vmware
[12:28] <shiki-> hmm.. beats me
[12:28] <shiki-> its more comfortable to work in an Ubuntu completely
[12:29] <Zhenech> your point :)
[12:30] <pzico> here is also pastebin link: http://paste.ubuntu.com/261917/
[12:32] <sistpoty> hi folks
[12:32] <dktrkranz> pzico: look at the one from oggconvert, it's very simple and should match your case perfectly
[12:32] <dktrkranz> hey sistpoty
[12:32] <sistpoty> hi dktrkranz
[12:35] <pzico> oggconvert is based on setup.py running a script, like is terminator program used in python packaging example. They load the script from the install folder directly.
[12:36] <pzico> I don't know what to figure out of that, unless to try learn make such script system myself
[12:38] <pzico> I think the question is, if I have a file helloworld.py in folder foo/bar/
[12:38] <pzico> how to make setup.py?
[12:38] <dktrkranz> well, "scripts" are single files, "packages" are modules
[12:38] <pzico> but why are the scripts assumed to be in the same folder with install?
[12:39] <pzico> and if my program gets bigger in future, it's not one single file anymore
[12:39] <pzico> It's a bit frustrating to go over reorganising files/folders in version control
[12:39] <pzico> just for setup program assuming all single files scripts..
[12:40] <dktrkranz> IIRC, you can pass a third parameter specifying where to get scripts from
[12:41] <pzico> or should I make it module nevertheless and the just call the main function from script?
[12:41] <pzico> I guess that's how it's done in that oggconvert
[12:41] <dktrkranz> yes
[12:42] <pzico> ok, good to know.. is there some name or keyword for this method using script calling modules, in case I want to learn more about it
[12:42] <dktrkranz> also look at this one: http://bazaar.launchpad.net/%7Edktrkranz/debomatic/debomatic.dev/annotate/head%3A/setup.py
[12:43] <dktrkranz> it also calls data_files
[12:43] <pzico> interesting, I guess I'm starting to understand this
[12:45] <pzico> that is a good example. thanks!
[12:46] <dktrkranz> np :)
[12:59] <shiki-> I ..dont..get..it
[12:59] <shiki-> pbuilder build *.dsc builds the package completely fine
[12:59] <shiki-> upload to PPA, it dies
[12:59] <shiki-> :/
[13:01] <Zhenech> shiki-, with what sort of an error?
[13:01] <shiki-> same Makefile problem with before
[13:01] <shiki-> but..thats it.. I removed that part from Makefile, used pbuilder
[13:03] <Zhenech> mh
[13:24] <shiki-> oh lol.. I made a small mistake.. yet it was fatal
[13:39] <c_korn> how can I get all files which cause this warning ? W: stone-soup source: patch-system-but-direct-changes-in-diff source/rltiles/tile-dngn.html and 8 more
[13:39] <Zhenech> c_korn, diffstat on diff.gz?
[13:40] <c_korn> Zhenech: oh, thanks. I was looking for a lintian option
[13:41] <Zhenech> no idea if it will do so in verbose mode or so
[13:41] <Zhenech> I just use diffstat for such things
[13:47] <shiki-> how can I make pbuilder as strict as the buildbots?
[13:47] <shiki-> I mean..buildbot dies, pbuilder works
[13:49] <sistpoty> shiki-: you could install pkgbinarymangler... but a failed buildlog might give more clue
[13:50] <shiki-> well..it was a patch problem. But thats it... I simply overlooked it since pbuilder created the builds
[14:03] <bdrung> Zhenech: thx
[14:39] <aladin_> hello, i have a big problem.. someone can tell to me the equivalent to "dpkg --force all" in apt?
[14:43] <andv> aladin_, usually if you have some deps problems you should give an apt-get -f install
[14:43] <aladin_> it'snt equivalent
[14:43] <aladin_> :(
[14:43] <andv> aladin_, what are you trying to do?
[14:43] <aladin_> overwrite file issue
[14:43] <andv> why are you trying to force something?
[14:44] <aladin_> but if i run the installation via "dpkg -i --force all" work fine, and if i use apt-get -f install do not work
[14:44] <aladin_> :\
[14:44] <andv> apt-get -f install fix for you deps problems
[14:44] <andv> and install the package you were trying to install without success (cause deps missing(
[14:45] <aladin_> it'snt depends issue.
[14:45] <aladin_> it's file overwrite!
[14:45] <andv> can't get what you mean sorry
[14:45] <aladin_> dpkg: error processing /var/cache/apt/archives/linux-image-<IP_ADDRESS>_<IP_ADDRESS>-10.00.Custom_i386.deb (--unpack):  trying to overwrite `/lib/firmware/whiteheat.fw', which is also in package linux-image-<IP_ADDRESS> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[14:46] <aladin_> if i use dpkg -i --force all package.deb work all fine
[14:46] <aladin_> but if i use apt-get -f install package.deb do not work
[14:46] <aladin_> so my question is, where is the equivalent to dpkg -i --force all in apt?
[14:47] <andv> aladin_, giving a --force all option is not the right way to go
[14:47] <aladin_> yes it it in my case.
[14:47] <andv> so if it worked why are you asking the apt equivalent?
[14:47] <aladin_> andv: have you solution about my issue or not ?
[14:48] <aladin_> because i need to do it via apt.
[14:48] <aladin_> -.-
[14:48] <arvind_k> hi, there is a bug in the notify-osd of karmic, the notification comes in the centre in the of the screen, why isnt it being fixed?
[14:48] <aladin_> arvind_k: check launchpad
[14:50] <aladin_> adnv ?
[14:50] <andv> aladin_, I guess there is no equivalent
[14:50] <aladin_> ok
[14:50] <aladin_> i will wait mvo
[14:50] <andv> aladin_, apt-get --help
[14:50] <arvind_k> aladin_, i have checked it, what am asking is, why isnt changes being reflected in the upstream version?
[14:51] <ScottK> arvind_k: It's on purpose.
[14:51] <ScottK> It's by design and not a bug.
[14:51] <ScottK> arvind_k: #ayatana is their channel.
[14:53] <arvind_k> ScottK, thanks ... :)
[14:57] <jedc> do i have to use make with debian/rules or can just run a custom install script from it? would it be easier to just make a makefile?
[14:58] <maxb> jedc: Give a bit more context to your question
[14:59] <jedc> maxb, i am trying to package a compiler, and i have a script that builds it for me, i wasnt using makefiles. Do i need to use make from debian/rules or can i just have the rules file run the script?
[15:00] <maxb> debian/rules is itself a makefile, but nothing at all says you have to have it run make to build your program
[15:02] <jedc> maxb ok, thanks, i think most of my confusion stems from most of the examples being tailored for packaging c/c++ programs
[15:04] <maxb> It's true that because very many programs follow the ./configure make make install pattern that the examples often use that. Just remember that those are only examples.
[16:40] <c_korn> hm, I wrote a gconf schema and it gets installed in /schemas/apps... by the postinst script but why doesn't it get installed in /apps/... so I can change the values ?
[16:41] <RainCT> Heya
[18:04] <Dyllan> Is there a way to install pre-deps from a .deb i have created? I specify the pre.dep in the control file, but gdebi just fails to install and complains that the pre-dep is needed which makes perfect sense, but i would like for it to be installed automatically if possible?
[18:06] <joaopinto> my question was not about wether you wanted to use text tools, but to identify wether it's a gdebi limitation for which you will need to file a bug report :)
[18:06] <joaopinto> and btw, why do you need pre-depends instead of depends ?
[18:08] <joaopinto> Dyllan, are the pre-depend debs available when you try to install the package ?
[18:08] <joaopinto> Dyllan, gdebi works with single packages, using regular APT methods, it will not attempt to satisfy depedencies from other external .deb packages, if that was your question
[18:09] <Dyllan> joaopinto: I would think that it could be a gdebi limitation, however i am sure it is setup that way for good reason.
[18:10] <Dyllan> joaopinto: yes, that was basically mu question. GDebi complains that it cannot install because of a pre-dep, so that makes sense because i set the pre-deb, but you have answered my question, GDebi cannot handle dependencies so then it is a GDebi limitation unfortunately.
[18:11] <Dyllan> I guess what  I could do is add a check into my program that checks to see if they dependency is installed and if not it installs it.. .
[18:21] <joaopinto> Dyllan, gdebi is very limited, for mutli .debs your best option is to use  a repository/PPA
[18:21] <joaopinto> with an apt-url link for the install
[18:21] <Dyllan> alright, thanks for the help.
[18:24] <joaopinto> np :)
[18:53] <kees> ScottK: can I get a FFe for ubuntu-dev-tools?  It looks like the current bzr contains a mess of fixes, but it just never got uploaded (0.76).
[18:54] <ScottK> Shouldn't be a problem.
[18:54] <kees> okay, cool, thx.
[19:12] <RainCT> nhandler: uhm.. is pull-revu-source looking for the URL of the .dsc file searching in revu.ubuntuwire.com/p/<pkg>? (don't really understand that perl stuff)
[19:23] <ScottK> Dear everyone: Please work on NBS: http://people.canonical.com/~ubuntu-archive/NBS/
[19:23]  * geser awaits the bug reports for the recent ubuntu-dev-tools upload
[19:47] <ryanakca> Is there a way to make sbuild drop to a shell in the schroot if a build fails?
[20:19] <nhandler> RainCT: Yes. I merely ported apachelogger's script to Perl. I plan on cleaning up the script later this week
[20:22] <RainCT> nhandler: You know about http://revu.ubuntuwire.com/dsc.py?package=X?
[20:23] <RainCT> nhandler: err, http://revu.ubuntuwire.com/dsc.py?url&package=X
[20:23] <nhandler> RainCT: I probably did at one point (just forgot). I'll fix it now
[20:25] <apachelogger> RainCT: I suppose that should be documented some place?
[20:26] <RainCT> apachelogger: Well, it isn't that interesting other than for scripting. Maybe what I should implement is something like  revu.ubuntuwire.com/download/X.{dsc,diff.gz,orig.tar.gz} so that you can just dget
[20:27] <sebner> RainCT: there is now a pull-revu-source though
[20:27] <nhandler> sebner: That is why RainCT was making his comments ;)
[20:27] <sebner> heh ^^
[20:28] <apachelogger> RainCT: possibly, though, I think that ?dsc.py is enough
[20:29] <apachelogger> also, IMHO downloading files individually does not have much of a use case for revu as for released sources
[20:29] <apachelogger> where one might just want the tar.gz because the packaging is in a no-full-source branch and needs to be merged with the source by builddeb
[20:32] <RainCT> apachelogger: I'm not sure I understand.  dget ../dsc.py?package=X doesn't work (it will get the .dsc and fail for the other files)
[20:32] <nhandler> RainCT: The URL returned by dsc.py is the path to the .dsc from /srv on spooky. It is not a valid URL
[20:33] <apachelogger> RainCT: dget only requires the dsc file?
[20:33] <apachelogger> so why would one need the other files :)
[20:33] <RainCT> apachelogger: Why would you want only a .dsc file? It's useless
[20:33] <apachelogger> nah
[20:33] <RainCT> nhandler: if you use ?url
[20:34] <nhandler> RainCT: Yes. For example, I get: http://revu.ubuntuwire.com/var/revu/revu1-incoming/nucleo-0905052003/nucleo_0.7.3-0ubuntu1.dsc
[20:34] <RainCT> nhandler: yeah, so then you can dget that
[20:34] <apachelogger> dsc.py returns url of most recent upload of $package as would be available in the regular UI
[20:34] <nhandler> That should probably not have the /var/revu part on it
[20:34] <apachelogger> so you run dget $URL and get the dsc and the diff.gz and the orig.tar.gz
[20:34] <RainCT> nhandler: err right, I'm fixing that right now
[20:34] <apachelogger> which is pretty much why one woud use dget and not wget anyway ;-)
[20:34] <nhandler> Thanks RainCT
[20:35]  * nhandler is fixing pull-revu-source
[20:50] <RainCT> nhandler: ok it's working now
[20:52] <nhandler> RainCT: pull-revu-source has been updated
[20:52] <RainCT> nhandler: cool, thx
[20:53] <nhandler> Thank *you* RainCT ;)
[21:21] <RoAkSoAx> DktrKranz, ping?
[21:35] <DktrKranz> hey RoAkSoAx
[21:41] <RoAkSoAx> how's it going DktrKranz
[21:41] <DktrKranz> fine, and you?
[21:42] <RoAkSoAx> DktrKranz, pretty good but kinda bored xD
[21:43] <DktrKranz> package something NEW ;)
[21:43] <RoAkSoAx> DktrKranz, hey I wanted to ask you, why would this error was showed to him by lintian and not to us when reviewing the package: https://bugs.launchpad.net/ubuntu/+source/lekhonee/+bug/419759
[22:21] <ScottK> RoAkSoAx: What version of lintian were you using?
[22:22] <RoAkSoAx> ScottK, I did not report the bug, slangasek did :). That bug is invalid right?
[22:22]  * ScottK didn't read the bug yet.
[22:23] <ScottK> Looks possibly valid to me.
[22:23] <ScottK> Is python-support needed in the clean rule?
[22:24] <ScottK> BTW, RoAkSoAx: Did you undertsand why I changed your patch before I uploaded lekhonee?
[22:27] <ScottK> Although I don't get it with the current lintian.
[22:27] <ScottK> slangasek: Are you sure you filed 418759 against the right package?  I can't replicate that lintian complaint.
[22:28] <RoAkSoAx> ScottK, I'm guessing that the change on the patch is because  /usr/bin/env python will figure out the correct location of python?
[22:28] <RoAkSoAx> ScottK, and I cant replicate the lintian complaint that's why I was thinking this is an actual invalid bug
[22:28] <ScottK> RoAkSoAx: If you read the Python Policy you'll find that we don't like /usr/bin/env python because it's easy to have it point at the wrong Python.
[22:29] <ScottK> RoAkSoAx: You may be right.  I've pinged slangasek, so  we'll wait and see.
[22:31] <RoAkSoAx> ScottK, ahh I see, so we should always try to use /usr/bin/python to avoid pointing to the wrong python. gotcha! :) thanks for explaining that to me
[22:31] <ScottK> You're welcome.
[22:32] <ScottK> We keep Python pretty up to date, so that's sufficient.  I know a lot of people on RHEL that always use their own Python in /usr/local so the env trick is useful for them.
[22:32] <ScottK> We'd rather be more deterministic.
[22:34] <RoAkSoAx> I see.
[22:57] <DktrKranz> RoAkSoAx: I used latest lintian from unstable
[22:57] <DktrKranz> and python-support is not involved in clean target
[23:02] <RoAkSoAx> DktrKranz, ok so this bug should be invalid then. I wonder why slangasek got that lintian error
[23:03] <DktrKranz> Dunno either
[23:06] <RoAkSoAx> weird
[23:20]  * ScottK guesses he was reviewing a number of packages and filed it on the wrong one.
[23:36] <ScottK> Next time someone sees quadrispro, please whack him with a hammer and remind him we are post feature freeze.
[23:39] <mrooney> Anyone know a guide for grabbing the appropriate theme colors in gtk to use in an app (or a more appropriate channel)?
[23:51] <DktrKranz> ScottK: ?
[23:51] <DktrKranz> what did he do?
[23:51] <ScottK> DktrKranz: https://launchpad.net/ubuntu/karmic/+source/zbar/0.8+dfsg-3ubuntu1
[23:52] <DktrKranz> UGH!


[11:21] <yogeshrt> Hi, I would like to suggest change for name of "Startup Disk Creator" to "usb-creator-gtk" on page http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-ubuntu
[11:23] <yogeshrt> this is applicable on ubuntu 16.04, as there is no utility called as "Startup Disk Creator"


[02:40] <ScottK> Fixed kpat FTBFS.
[02:52]  * ScottK fixes harder.
[03:41] <ScottK> Riddell: debian/changelog for kubrik claims it's a PPA build (the revision number is right however).  Please fix for the next upload.
[03:44] <ScottK> s/kubrik/kubrick/
[03:44] <kubotu> ScottK meant: "Riddell: debian/changelog for kubrick claims it's a PPA build (the revision number is right however).  Please fix for the next upload."
[04:16] <ScottK> Riddell: ksquares copyright was missing one person.  I fixed and reuploaded.
[05:13] <ScottK> Riddell: For ksirk, ksirk/iris/src/libidn/nfkc.c is LGPL and there's no license file included nor is it mentioned in debian/copyright.  Additionally, there are other copyrights missing.  I'll have to reject it.
[05:22] <ScottK> Riddell: I fixed the killbots debian/copyright.
[05:28] <kubotu> ::workspace-bugs:: [1088772] Broken icons in plasma tray @ https://bugs.launchpad.net/bugs/1088772 (by xapienz)
[06:31] <ScottK> Riddell: granatier was missing stuff too.  In retrospect, don't they all need GFDL in debian/copyright?
[06:31]  * ScottK fixed that one up and is calling it a night.
[07:24] <jussi> Quintasan_: various, but ubuntu mostly. why?
[08:32] <Tm_T> so yeah, icons that comes outside of icon theme are not shown in systray
[08:53] <apachelogger> Tm_T: did you file a bug yet?
[08:54] <apachelogger> someone please send a test mail to<EMAIL_ADDRESS>[08:56] <shadeslayer> apachelogger: sent
[08:57] <apachelogger> \o/
[08:57] <apachelogger> my mail be workign again
[08:57] <apachelogger> tickets ftw ^^
[08:57] <shadeslayer> :D
[09:00]  * apachelogger would really like to blog about something
[09:01] <shadeslayer> blog about tickets?
[09:06] <apachelogger> shadeslayer: not useful :P
[09:06] <shadeslayer> apachelogger: blog about how we need business cards
[09:07] <apachelogger> we do?
[09:07] <shadeslayer> yes
[09:07] <apachelogger> I am sorry, I have not gotten much mail for 2 weeks :P
[09:07] <shadeslayer> with updated artwork and stuff
[09:08] <shadeslayer> apachelogger: see https://plus.google.com/107577785796696065138
[09:08] <shadeslayer> erm
[09:09] <apachelogger> I know
[09:09] <shadeslayer> okay
[09:09] <apachelogger> not sure me blogging is a good idea tho :P
[09:09] <shadeslayer> it's on G+
[09:10] <apachelogger> dragon3 still has no UI ;)
[09:10] <shadeslayer> heh
[09:10] <apachelogger> its only been >1.5 year since inception
[09:10] <shadeslayer> xD
[09:10] <shadeslayer> apachelogger: I haz kde-mm question
[09:10] <apachelogger> so do I, who do we ask?
[09:10] <shadeslayer> you
[09:10] <apachelogger> oh
[09:11] <shadeslayer> apachelogger: http://paste.kde.org/623426 < why does this not work?
[09:11] <shadeslayer> by not work I mean does not compile
[09:11] <apachelogger> well
[09:12] <apachelogger> supposedly path a is an interface that was changed for 1.0 hence why you need path b
[09:12] <shadeslayer> whut
[09:12] <shadeslayer> apachelogger: no no
[09:12] <shadeslayer> apachelogger: /home/shadeslayer/sauce/kde/phonon-gstreamer/gstreamer/audiodataoutput.cpp:128: error: ‘GST_BUFFER_CAPS’ was not declared in this scope
[09:12] <shadeslayer> GST_BUFFER_CAPS was removed, the caps are now applied on the pad that  the buffer is pushed onto
[09:13] <shadeslayer> so you get the caps from the pad now
[09:13] <apachelogger> that's what I said
[09:13] <shadeslayer> roger
[09:13] <shadeslayer> now
[09:13] <apachelogger> the two paths are compile time mutually exclusive
[09:13] <shadeslayer> ahaha
[09:13] <shadeslayer> okay
[09:13] <shadeslayer> right
[09:13] <apachelogger> you cannot do a runtime if-else
[09:13] <shadeslayer> I have to ifded
[09:13] <apachelogger> but you need a compiletime if-else
[09:13] <shadeslayer> *ifdef
[09:13] <shadeslayer> not if
[09:13] <apachelogger> shadeslayer: aye
[09:13] <apachelogger> shadeslayer: well
[09:14] <shadeslayer> ?
[09:14] <apachelogger> shadeslayer: technically it would be best if you did #if gstversion > expectedversion
[09:14] <shadeslayer> righto
[09:14] <apachelogger> we have lines like that somewhere
[09:14] <apachelogger> best grep for version
[09:14] <shadeslayer> grep for version?
[09:15] <apachelogger> gstreamer/pipeline.cpp:#if GST_VERSION >= GST_VERSION_CHECK(0,10,23,0)
[09:16] <shadeslayer> oic
[09:17] <shadeslayer> apachelogger: but gst provides all that already
[09:18] <shadeslayer> apachelogger: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstVersion.html#GST-CHECK-VERSION:CAPS
[09:18] <shadeslayer> so why define it in p-c-gst.h.cmake
[09:20] <apachelogger> shadeslayer: possibly it did not in the past
[09:20] <shadeslayer> mm
[09:30] <apachelogger> Commandline: apt-get install ubuntu-tweak
[09:30] <apachelogger> those are really the best logs
[09:33] <apachelogger> JontheEchidna: do you see the reason for bug 1062824
[09:33]  * apachelogger does not
[09:33]  * apachelogger also thinks that perhaps maintscripts should be more verbose on error
[09:34] <kubotu> ::workspace-bugs:: [1066237] log out button freezes kde @ https://bugs.launchpad.net/bugs/1066237 (by J. Sundermeyer)
[09:34] <kubotu> ::workspace-bugs:: [1075518] Plasma Workspace (plasma-desktop), signal: Aborted [Current thread is 1 (Thread 0xb31c5720... @ https://bugs.launchpad.net/bugs/1075518 (by Blair Chasteen)
[09:34] <kubotu> ::workspace-bugs:: [1077196] klipper does not save contents from closed windows @ https://bugs.launchpad.net/bugs/1077196 (by ill)
[09:53] <shadeslayer> ScottK: digikam uploaded to rebuild against hupnp
[11:12] <shadeslayer> apachelogger: do you think we could do with some autopilot tests in our packaging?
[11:13] <Riddell> http://news.slashdot.org/story/12/12/09/1828238/mark-shuttleworth-answers-your-questions
[11:14] <shadeslayer> "So I think the next frontier is to create a seamless experience from the embedded world to the cloud."
[11:14] <shadeslayer> that's what I want for KDE :P
[11:23] <apachelogger> shadeslayer: yes?
[11:23] <Quintasan_> jussi: Becasue I was not sure how does one run ubuntu on imx when it is so slow there
[11:23] <apachelogger> shadeslayer: depends on what you mean though
[11:23] <apachelogger> specifically
[11:23] <shadeslayer> well
[11:23] <shadeslayer> things like
[11:23] <shadeslayer> autopilot tests for rekonq
[11:23] <shadeslayer> and ktp
[11:24] <shadeslayer> ktp is going to be a bit hard to do
[11:24] <shadeslayer> and dolphin etc etc
[11:24] <Quintasan> \o
[11:24] <shadeslayer> oh this is going to be fun
[11:24] <shadeslayer> I get to build kdelibs twice
[11:24] <shadeslayer> like kde-workspace
[11:24] <Riddell> two times the fun
[11:24] <shadeslayer> indeed
[11:25]  * shadeslayer looks at how kde-workspace is built
[11:29] <shadeslayer> JontheEchidna: btw could you figure out how we can build nepomuk-core with ffmpeg and dlrestrictions? ( from what I've been told, you've done this before )
[11:42] <shadeslayer> uhh
[11:42] <shadeslayer> Quintasan: what's build-kwin-active
[11:42] <shadeslayer> I can't find it anywhere
[11:42] <Quintasan> try guessing
[11:42] <shadeslayer> dude, there's no debian/build-kwin-active
[11:43] <shadeslayer> how does this even compile 0.o
[11:43] <Quintasan> shadeslayer: That's how our workspace is broken xD
[11:43] <shadeslayer> xD
[11:43] <Quintasan> shadeslayer: Theoretically this is the build directory that should get created during build proccess
[11:43] <shadeslayer> oh
[11:44] <shadeslayer> does it?
[11:44] <shadeslayer> get created I mean
[11:44] <Quintasan> Dunno lol
[11:44] <Quintasan> It SHOULD
[11:44] <shadeslayer> okay
[11:45] <Quintasan> I have no idea how does this thing even work seeing patches got reverted when I was not looking
[11:45] <shadeslayer> yeah
[11:45] <shadeslayer> that's what I'm looking at myself
[11:45] <shadeslayer> xD
[11:45] <shadeslayer> seems like a big ol fuck all
[11:45] <Tm_T> oh my
[11:46] <shadeslayer> yeah, sorry about that, but this is *really* messed up
[11:46] <shadeslayer> Riddell: are you sure this is right? http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/nepomuk-widgets/revision/7
[11:48]  * shadeslayer scratches head
[11:48] <Riddell> shadeslayer: um, no
[11:48] <shadeslayer> Riddell: :P
[11:48] <Riddell> I think I'll change all our Section fields to "who cares" since it's a pointless label anyway
[11:49] <shadeslayer> xD
[11:49] <Quintasan> :D
[11:49] <Quintasan> +1
[11:49] <shadeslayer> Quintasan: okay, so, the patches should only be applied when doing the active build right?
[11:49] <shadeslayer> they shouldn't land in the normal build
[11:49] <Quintasan> shadeslayer: Yeah, that's right
[11:49] <shadeslayer> okay
[11:49] <shadeslayer> HOW THE HELL DID THIS WORK
[11:49] <Quintasan> That's why I put them into separate directory
[11:49] <Quintasan> now the directory is gone\
[11:49] <shadeslayer> yeah
[11:49] <shadeslayer> @_@
[11:50] <yofel> you can't apply 2 different patch sets with dh7 packaging - at least I don't know how to
[11:50] <yofel> that's why the last attempt at double-building wrapped the patch in ifdefs and used a flag
[11:52] <shadeslayer> can't you do a export the quilt patch dir and then do quilt push before the second cmake call?
[11:52] <Quintasan> what shadeslayer said
[11:52] <Quintasan> That's what I did
[11:52] <Quintasan> and it worked
[11:53] <shadeslayer> sounds like it should work
[11:53] <shadeslayer> without too much hassle
[11:54] <yofel> are configure and build batched together in dh7? As configuring twice and then building twice won't really work
[11:56] <shadeslayer> don't think so, but we're using a separate dir for the second build
[11:57] <yofel> sure, but you only have ONE source that you can patch
[11:57] <shadeslayer> so build 1 happens in obj-whatever
[11:57] <shadeslayer> I don't see how that's an issue?
[11:57] <yofel> does cmake copy the source into the build dir? afaik it doesn't
[11:57] <Quintasan> yofel: patch -> build -> do magic -> UNPATCH -> apply different patch set -> build INTO another directory
[11:57] <shadeslayer> ^
[11:57] <yofel> Quintasan: yeah, that work, but how do you do that with current packaging?
[11:58] <Quintasan> yofel: it did work with dh7 and unless they did some significant changes it should still work
[11:58] <Quintasan> yofel: override everything?
[11:58] <Quintasan> I overrode auto_patch auto_build and auto_install
[11:58] <yofel> as AFAIK dh_auto_configure and dh_auto_build are both only run once
[11:58] <shadeslayer> yofel: override_dh_auto_configure:
[11:58] <shadeslayer>         $(overridden_command) -- -DKDE4_KDM_PAM_SERVICE=kdm -DKDE4_COMMON_PAM_SERVICE=kdm
[11:58] <shadeslayer>         $(overridden_command) -Bdebian/build-kwin-active -- -DKDE4_KDM_PAM_SERVICE=kdm -DKDE4_COMMON_PAM_SERVICE=kdm -DKWIN_PLASMA_ACTIVE=true
[11:58] <shadeslayer> that's how :P
[11:58] <Quintasan> yofel: override it and call it twice?
[11:59] <yofel> whatever, show me the finished work. the current workspace build isn't set up like that
[11:59] <shadeslayer> it is! :P
[11:59] <Quintasan> yofel: That's the problem xD
[11:59] <yofel> shadeslayer: it's not!
[11:59] <shadeslayer> but it doesn't have patchery
[11:59] <shadeslayer> I just copy pasted from kde-workspace rules :p
[11:59] <Quintasan> It was working but $STUFF happened and it doesnt work as it is supposed to work right now
[11:59] <yofel> it applies the patch and uses a cmake flag to turn it on and off, that's not using 2 patchsets
[12:00] <shadeslayer> ah okay
[12:00] <shadeslayer> this should really be upstreamed :|
[12:00] <Quintasan> yofel: The flag does shit by itself when the patches are not there xD
[12:00] <Quintasan> once shadeslayer fixes the patching the rest should work
[12:00] <shadeslayer> righto
[12:00] <shadeslayer> the question is
[12:00] <yofel> the patch that was removed was upstreamed, and I'm not yet convinced that the missing part is really needed
[12:01] <Quintasan> IT WAS NOT UPSTREAMED T_T
[12:01] <Quintasan> shadeslayer: show him @_@
[12:01] <shadeslayer> err more patches : ftp://ftp.kde.org/pub/kde/stable/active/3.0/src/patches/
[12:01] <yofel> as for the PA3 patches: yes, I know they're not in
[12:01] <yofel> Quintasan: wait, I'm looking myself, I might be wrong too as I was last time ^^
[12:01] <shadeslayer> yofel: we applied the patches cleanly on git master at UDS R
[12:02]  * Quintasan goes to take a shower
[12:02] <Quintasan> I expect results
[12:02] <shadeslayer> or maybe they were, but were reverted or sth
[12:02] <shadeslayer> and we forgot
[12:02] <Quintasan> Riddell, ScottK: friendly reminder for maliit review
[12:03]  * shadeslayer looks at bzr log
[12:04] <yofel> shadeslayer: after resetting workspace KDE/4.9 hard, kwin/CMakeLists.txt respects KWIN_PLASMA_ACTIVE. The missing part of the patch were a few includes - I'm not convinced that they're missing
[12:04] <Riddell> apachelogger: apachelogger @ubuntu.com got unsubscribed from kubuntu-devel 10 days ago
[12:04] <yofel> er, needed
[12:04] <shadeslayer> I see
[12:04] <Riddell> Quintasan: keep reminding us
[12:04] <shadeslayer> yofel: we still need this patchset though : ftp://ftp.kde.org/pub/kde/stable/active/3.0/src/patches/
[12:05] <shadeslayer> I see some really fun commit entries : http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kde-workspace/revision/668
[12:06] <yofel> yeah, I know. I'm just wondering how to get dh7 to work with 2 patch sets. I don't know if that's possible as I remember the sequencing, but maybe Quintasan knows better.
[12:06] <shadeslayer> hmm .. I *think* you might be right
[12:07] <shadeslayer> after the first patchset gets applied, and you pop it, those patches are no longer applied
[12:07] <shadeslayer> and the first build loses that patchset
[12:07] <shadeslayer> so, keep first patchset, apply active's patchset ontop of our patchset for active build
[12:08] <apachelogger> Riddell: autounsub because the alias was broken I presume
[12:09] <yofel> shadeslayer: still leaves the issue of only one available source. We really would need to 'patch - build - unpatch - patch - build'. But not sure how to do that. [OR add ifdefs for the patches, not sure how much work that is]
[12:09] <apachelogger> Riddell: I think I am subbed again, thanks for pointing it out
[12:10] <yofel> anyway, back to work, let's hope that Quintasan has some magic idea
[12:10] <shadeslayer> hmm
[12:13] <yofel> shadeslayer: or maybe one could make a full source copy at the start and then point cmake to that for one build. I've never tried something like that though.
[12:13] <shadeslayer> heh
[12:13] <shadeslayer> that would be fun
[12:14] <shadeslayer> a 'cleaner' solution I guess would be to have different -active sources
[12:14] <shadeslayer> so kde4libs-active, kde-workspace-active
[12:24] <Riddell> how would that be cleaner?
[12:25] <Riddell> that just means they'll get out of sync
[12:30] <shadeslayer> hmm
[13:02] <ScottK> Quintasan: Look at the number of KDE games still in New and you'll understand why I didn't get to it yet.
[14:23] <shadeslayer> Quintasan: http://paste.kde.org/623696/
[14:23] <shadeslayer> still WIP
[14:24] <Quintasan> >built with active patches
[14:24] <Quintasan> means nothing to me
[14:25] <Quintasan> make it built with Plasma Active support
[14:25] <shadeslayer> heh
[14:26] <shadeslayer> still needs install files and the likes
[14:26] <yofel> I don't see kdelibs5-active-dev, if the -active stuff isn't installed during build dpkg-shlibdeps WILL do the wrong thing
[14:27] <shadeslayer> like I said, still WIP :)
[14:28] <shadeslayer> I thought that dh_auto_configure would create the debian/build-kdelibs-active dir, but it didn't
[14:31] <shadeslayer> and hmm ... debian/build-kdelibs-active-dir is empty right now
[14:31] <shadeslayer> I thought it would have the relevant CMake files
[14:31] <yofel> -Bdebian/build-kwin-active is an option for dh_auto_configure, not cmake, so put it before the --
[14:32] <shadeslayer> oh good point
[14:33] <yofel> see man debhelper BUILD SYSTEM OPTIONS
[14:33] <shadeslayer> yeah, that's where I picked it up, except I put it at the wrong line
[14:34] <shadeslayer> -- Build files have been written to: /tmp/buildd/kde4libs-4.9.90/debian/build-kwin-active
[14:34] <shadeslayer> wohoo
[14:34] <shadeslayer> erm
[14:34] <shadeslayer> wrong dir
[14:34] <yofel> why?
[14:35] <shadeslayer> build-*kwin*-active
[14:35] <shadeslayer> should be kdelibs
[14:35] <shadeslayer> :P
[14:35] <yofel> oops
[14:35] <yofel> ^^
[14:36] <yofel> ah, and don't forget to remove the dir in dh_clean
[14:36] <shadeslayer> better : -- Build files have been written to: /tmp/buildd/kde4libs-4.9.90/debian/build-kdelibs-active
[14:36] <shadeslayer> ofcourse
[14:36] <soee> guys what re the oxygen-fonts ?
[14:36] <shadeslayer> soee: experimental ppa
[14:36] <soee> shadeslayer, yeah i see topic but what do they chenge ? add some extra fonts ?
[14:37] <shadeslayer> they add the oxygen fonts? that's about it
[14:37] <soee> so its like ubuntu font ?
[14:38] <soee> ok googled it
[14:38] <shadeslayer> :)
[14:38] <shadeslayer> it's a font that upstream KDE is working on
[14:38] <yofel> 'y' still feels unbalanced. Looks nice otherwise
[14:39] <soee> will test later but i doubt any font will replace my Droid :)
[14:39] <yofel> then again, I can just use the mono version
[15:01] <shadeslayer> ermmmm
[15:01] <shadeslayer> yofel: http://paste.kde.org/623702/
[15:01] <shadeslayer> any ideas how I can apply active patches ontop of our patches
[15:02] <yofel> uh... I would usually go with quilt pop -a, choose a different series file and push -a
[15:02] <shadeslayer> uh
[15:02] <shadeslayer> hm
[15:02] <yofel> and drop setting QUILT_PATCHES at all
[15:03] <shadeslayer> right
[15:03] <yofel> shadeslayer: what doesn't work there though?
[15:03] <shadeslayer> the pushing
[15:05] <yofel> dunno, would need a test env for debuggin but I don't have the time for that now
[15:06] <shadeslayer> sure
[15:06] <shadeslayer> I just made a debian/patces/series.active and appended the PA patch there
[15:17] <shadeslayer> yofel: well that's odd
[15:18] <shadeslayer> doing :         export QUILT_SERIES=series.active  or         export QUILT_SERIES=debian/patches/series.active doesn't work as well
[15:22] <Riddell> I expect it's cached in .pc/
[15:23] <Riddell> I'd be inclined to just patch it manually if quilt is faffy
[15:23] <Riddell> patch -p1 < debian/patches/foo
[15:23] <Riddell> -patch -R -p1 < debian/patches/foo  in clean
[15:25] <shadeslayer> uglyness
[15:25] <shadeslayer> :(
[15:27] <Riddell> 77CABWYBP: got a new amateur radio call sign?
[15:27] <Riddell> Quintasan: where's that maliit?
[15:32] <shadeslayer> god
[15:32] <shadeslayer> rm -rf .pc/
[15:32] <shadeslayer> cp /tmp/buildd/kde4libs-4.9.90/debian/patches/series.active /tmp/buildd/kde4libs-4.9.90/debian/patches/series
[15:32] <shadeslayer> quilt push -a
[15:32] <shadeslayer> No series file found
[15:33] <highvoltage> quilt obviously hates you.
[15:34] <shadeslayer> clearly
[15:35] <shadeslayer> this is a fairly wtf build :P
[15:37] <shadeslayer> I'll go with Riddell's suggestion
[15:37] <shadeslayer> even though it leads to uglyness
[15:37] <yofel> that'll be a wtf build then
[15:37] <yofel> go ahead for now, I'll debug this if I have time in the evening
[15:37] <shadeslayer> heh
[15:37] <shadeslayer> okay
[15:38] <Quintasan> Riddell: dget -xu http://people.ubuntu.com/~quintasan/uploads/maliit-framework_0.93.0-0ubuntu1.dsc
[17:47] <shadeslayer> ugh
[17:48] <shadeslayer> does this look sane for kdelibs5-active-dev.install : http://paste.kde.org/623762
[18:16] <Riddell> buildslayer: isn't it just the same as the normal kdelibs5-dev.install ?
 I don't see kdelibs5-active-dev, if the -active stuff isn't installed during build dpkg-shlibdeps WILL do the wrong thing
[18:18] <buildslayer> uhh ... now that I think about it, I don't see how adding that will fix said issue :P
[18:20] <buildslayer> hmm .. this will most definitely cause issues if dpkg-shlibdeps takes into account out of source builds
[18:22] <buildslayer> anywho, something for tomorrow I guess
[18:22] <yofel> uhm, a) you need to have something that installs the lib*-active packages. b) they need to conflict with the regular set of packages. c) That'll probably break everything
[18:22] <yofel> so I'm currently thinking about how to solve this too...
[18:23] <buildslayer> right
[18:23] <buildslayer> :P
[18:24] <buildslayer> upstream sux
[18:24] <yofel> this is *so* set up for a one-config environment which we don't have -.-
[18:25] <buildslayer> yeah ...
[18:25] <buildslayer> maybe we should complain loudly
[18:25] <buildslayer> the fun part is that half of the kdelibs patch is in 4.10
[18:25] <buildslayer> so I had to redo it
[18:27] <Tm_T> yofel: huh?
[18:29] <buildslayer> ah yes, new kernel
[18:30] <buildslayer> with TCP Fast open
[18:45] <buildslayer> Riddell: btw decisions like Business card artwork would be taken by the Council right?
[18:54] <yofel> Tm_T: hm? kdelibs? I meant the one big kdelibs patch from active that changes god knows what and that I would rather not have on the normal desktop
[18:55] <Tm_T> yofel: are you saying that we (kubuntu) are going to have either plasma-desktop or plasma-active but not both on the system, against upstream?
[18:57] <yofel> Tm_T: I'm saying that it makes it hard to do it, not that it's impossible. And that's not really something they *need* to care about either.
[18:57] <Tm_T> hmmm
[19:00] <yofel> hm
[19:01] <yofel> actually...
[19:03] <kubotu> ::workspace-bugs:: [1088772] Broken icons in plasma tray @ https://bugs.launchpad.net/bugs/1088772 (by xapienz)
[19:03] <Tm_T> yofel: yes?
[19:03] <yofel> buildslayer: are the changes that replace functionality in 4.10? As the diff is otherwise mostly adding stuff, maybe we don't need to build twice
[19:03] <buildslayer> yofel: uhh sec
[19:04] <yofel> except for the replacements that just add fuse support
[19:04] <buildslayer> http://paste.kde.org/623792 is what quilt gave me after refreshing
[19:05] <buildslayer> yofel: can you see any difference in lines 55 and 57?
[19:05] <buildslayer> possibly useless diff
[19:08] <Riddell> buildslayer: well the money part at least will be
[19:08] <yofel> buildslayer: whitespace diff
[19:08] <buildslayer> Riddell: nah, I mean deciding which artwork will become 'official'
[19:08] <buildslayer> yofel: so it wasn't me being sleepy ... good to know
[19:10] <yofel> line 106-127: filling empty methods o.O?
[19:11] <buildslayer> ?
[19:11] <buildslayer> nope
[19:11] <Riddell> buildslayer: I'm less fussed about that
[19:11] <buildslayer> Riddell: heh
[19:12] <buildslayer> I've also pinged Eugene
[19:17] <yofel> http://paste.kde.org/623798 - wth..
[19:17]  * yofel will continue review after dinner
[19:17] <buildslayer> 0.o
[19:17] <buildslayer> I'm probably going to go to sleep in another 20 minutes
[19:26] <yofel> re
[19:29] <yofel> buildslayer: can you make a fresh full clone of kdelibs? I can't
[19:30] <yofel> pulling works, but clone not
[19:30] <buildslayer> sec
[19:31] <buildslayer> yofel: clone from anongit1
[19:32] <yofel> thanks
[19:32] <yofel> now lets see which one's broken
[19:34] <buildslayer> 3 I guess
[19:35] <buildslayer> erm, there's no 3 ...
[19:35] <yofel> 1 2 and 4 work, 3 doesn't resolve here
[19:36] <yofel> 5 is broken
[19:36]  * yofel pokes the admins
[19:37] <buildslayer> I think they know
[19:37] <yofel> I didn't see anythign in -sysadmin...
[19:38] <yofel> they should at least take it out of the rotation
 I suspect it may be a nasty combo of anongit syncing + projects updating db + all 6 thin servers trying to show git repos all simultaneously
[19:39] <buildslayer> potentially something went wrong with anongit syncing
[19:39] <buildslayer> but yeah, it'd be good to mention it to the,
[19:39] <buildslayer> *them
[19:39] <yofel> yeah, could've been load corruption
[19:41] <buildslayer> yofel: are you doing a patch review?
[19:41] <buildslayer> and whether or not the patch applies to kdelibs?
[19:42] <yofel> didn't you check the 2nd part?
[19:42] <buildslayer> 2nd part?
[19:42] <yofel> whether it appleis
[19:43] <yofel> I'll try to find out what the activity part is supposed to do, as the fuse part seem safe
[19:43] <yofel> *seems
[19:43] <buildslayer> http://paste.kde.org/623792/ applies cleanly to 4.9.90
[19:43] <buildslayer> I didn't check against master
[19:44] <buildslayer> it applies cleanly
[19:44] <yofel> with the low amount of changes in kdelibs we shouldn't have to worry much there
[19:44] <yofel> do you know where the active patches are kept? ivan/plasma-active-patches ?
[19:44] <buildslayer> dunno
[19:45] <buildslayer> I'm touching this for the first time
[19:45] <yofel> same here...
[19:45] <yofel> guess I'll look around a bit
[19:45] <buildslayer> potentially #active can advise
[19:47] <yofel> yeah, I'm in there, just never said a word :P
[19:49] <buildslayer> hehe
[19:49] <buildslayer> same here
[20:01] <buildslayer> nighters
[21:02] <soee> whats motivates to work... is shower :)
[21:45] <ronnoc_> hmmm KMix volume control no longer working in 12.10 / 4.9.9. Anyone else seeing this issue?
[21:47] <Riddell> works fine in raring 4.9.90
[21:47] <Riddell> are you sure it's got the right output?
[21:50] <soee> ronnoc, what exactly not working?
[21:50] <soee> volume level works fine for me
[21:50] <soee> 12.10
[21:51] <ronnoc> Moving the slider does nothing to the volume, nor can I mute it. I didn't change anything that I'm aware of.
[21:53] <soee> well by default the channel visible when i click volume icon do nothig for me either
[21:53] <ronnoc_> fixed by closing kmix and restarting. odd because rebooting didn't fix the issue. but all's well that ends well.
[21:54] <soee> bu if i click mixer i got access to the right one
[21:54] <soee> :)
[21:56] <ronnoc> well I used to be able to use mouse wheel to control volume on hover, but that no longer works. seems alsa is no longer the default (my USB headphones are) and I can not see a way to change that back.
[21:57] <soee> alsa? i thought pulseaudio
[22:19] <ronnoc> yea. it shows up as Built In Analog Stereo. And it's teh preferred device in System Settings, but somehow it's not the default anymore in KMix. No big deal :p
[22:22] <dantti_laptop> hi, I'm having a serious issue with 12.10... I can't let my pcs on for too many time that out of nothing it freezes...  with sysreq I see VFS file-max limit reached, does anyone knows what causes this?
[22:22] <dantti_laptop> luckly today I was able to still use the pc, so I can type commands that might help
[22:23] <dantti_laptop> there's no 100% process running, no process eating lots of fds...
[22:23] <dantti_laptop> so I'm really out of clue of what is happening..
[22:23] <dantti_laptop> am I the only one experiencing this?
[22:26] <dantti_laptop> funny trying to open kwin it says too many open files on the system.. but I list /proc/*/fds and no process has so many open files..
[22:26] <dantti_laptop> is there another way to find this?
[22:33] <rbelem> dantti_laptop, i'm having issues with 12.10 and icecc
[22:34] <dantti_laptop> what's icecc?
[22:34] <rbelem> dantti_laptop, http://en.opensuse.org/Icecream
[22:36] <dantti_laptop> rbelem: ok I don't use that...
[22:36] <rbelem> :-)
[22:36] <dantti_laptop> the issue is that something is eating fds on my machine.. :P
[22:37] <dantti_laptop> I won't reboot till I kill it :P
[22:37] <rbelem> :-/
[22:37] <rbelem> no idea
[22:37] <dantti_laptop> I used to have my machine up for 40 days now it can't stand 2
[22:38] <rbelem> we have to find out what changed
[22:42] <yofel> I remember having aptitude complain about too many open files here in 12.10, but now I'm on raring and it hasn't happened again.
[22:42] <ScottK> Riddell: Any thoughts on my comment on missing GFDL attribution in debian/coyright for ~all the games?
[22:43] <dantti_laptop> yofel: do you know is lsof -p is better than listing the number of files on /proc/fd?
[22:43]  * ScottK is waiting to get that resolved before reviewing more.
[22:43] <dantti_laptop> it seems to show more stuff
[22:43] <ScottK> yofel: Your first mistake is using aptitude.  Just use apt.
[22:44] <yofel> I usually do, but aptitude's dependency resolver is sometimes handy for debugging dep issues (if it doesn't totally mess up ofc.)
[22:45] <Riddell> ScottK: mm I missed that one, what missing attribution?
[22:45] <dantti_laptop> not to mention aptitude search is way easier to read than apt-cache's
[22:46] <ScottK> [01:31:10] <ScottK> Riddell: granatier was missing stuff too.  In retrospect, don't they all need GFDL in debian/copyright?
[22:46] <yofel> dantti_laptop: not really, but I do wonder what would open 4k files (that's what ulimit -n at least says as file open limit)
[22:46] <ScottK> Riddell: Take a look at what I did for grantier and see if you think that makes sense.
[22:47] <dantti_laptop> yofel: is vfs some app? cause it seems it was the one trying to get more...
[22:47] <yofel> actually aptitudes full resolver works pretty well again, just the safe one is still pretty broken
[22:48]  * yofel reads vfs as virtual file system so it should be some kernel thing
[22:48] <yofel> but would that open files by itself o.O?
[22:48] <Riddell> ScottK: mm yes
[22:49] <ScottK> OK.  We need to fix the ones I already accepted.  I can work on that.
[22:49] <ScottK> Can you redo the ones still in the queue?
[22:49] <ScottK> Also, did I do the copyright format stuff right?
[22:49] <ScottK> I'm not very experienced with it.
[22:50] <dantti_laptop> yofel: yes, tis odd indeed, probably something uses vfs to open files... and don't releases them
[22:53] <dantti_laptop> ok, it seems kvirc and chromiun are eating lots of them... using lsof...
[22:55] <Riddell> ScottK: where is your granatie change?
[22:55] <ScottK> In the archive.
[22:55] <ScottK> I fixed it and accepted it.
[22:56] <Riddell> ScottK: only 4:4.9.90-0ubuntu1  shown in https://launchpad.net/ubuntu/+source/granatier and that has no FDL in debian/copyright
[22:56] <ScottK> Hmmm.
[22:56]  * ScottK looks
[22:58] <yofel> dantti_laptop: what does 'sysctl fs.file-nr' say for you?
[22:58] <ScottK> Riddell: Yes.  The one in the archive has it.  I didn't change the version number/changelog. so download it again (either delete yours or to a different directory)
[23:01] <Riddell> mm yes it's got it this time
[23:01] <Riddell> ScottK: yeah that looks good
[23:01] <Riddell> I'll add it to kdegames packages tomorrow
[23:01] <ScottK> OK.  Thanks.
[23:06] <rbelem> yofel, maybe it kills dantti's system
[23:07] <yofel> rbelem: well, he says that it kill is, but it seems like it's still working to some extent
[23:07] <yofel> *kills it
[23:08] <dantti_laptop> yofel: hmm sorry too lat, I killed chormiun which somehow killed my konsole, but I'm guessing my issus is kvirc
[23:08] <dantti_laptop> since it's the one that is less maintained...
[23:08] <dantti_laptop> the two where the ones that lsof couldn't proccess it all
[23:09] <dantti_laptop> I'll use another irc client for now and see what happens...