[00:21] <Tonio_> hi
[00:22] <Tonio_> knetworkmanager just broke for me... is that known issue ? should I investigate ?
[00:25] <Riddelll> there was a new version yesterday
[00:25] <Tonio_> Riddelll: I suspect this is the one I got today
[00:29] <Doc_exe> sudo NetworkManager got network working for me again
[00:29] <Doc_exe> has something to do with the new startup scripts i believe
[00:35] <Tonio_> Doc_exe: then network is the problem I guess
[00:36] <Tonio_> networkmanager, sorry, so knetworkmanager might not by the guilty :)
[00:37] <ScottK> Riddelll: It is related to the chroots being broken.  The stack of packages needs to be upgraded together, but as soon as the first one was published, the chroots died.
[00:38] <a|wen> Tonio_: how did it break? ... I restarted earlier today to use the new version of knetworkmanager; and that one has worked much better than the previous snapshot
[00:39] <Riddell> a|wen: according to the above it broke by upstart being broken
[00:41] <Tonio_> a|wen: it's not knetworkmanager in fact
[00:41] <Tonio_> a|wen: it's networkmanager that doesn't start
[00:42] <Tonio_> a|wen: and I'm really happy to see that knetworkmanager seems to do real progress right now :)
[00:42] <Tonio_> a|wen: I'll look into this networkmanager issue, but it should get fixed soon I guess
[00:44] <Tonio_> amarok + covers = broken :/
[00:44] <Tonio_> well finds 1% of my covers...
[00:45] <ScottK> Tonio_: How's kdebluetooth looking?
[00:45] <Tonio_> ScottK: like... crap
[00:45] <Tonio_> ScottK: there are some commits right now but it won't build...
[00:45] <ScottK> Any less crap than before?
[00:45] <ScottK> Oh.
[00:45] <Tonio_> ScottK: I'm testing on a regular basis
[00:46] <ScottK> Cool.
[00:46] <Tonio_> ScottK: as soon as there is some binary, I'll tell you
[00:46] <ScottK> OK.
[00:46]  * ScottK needs to go for dinner.
[00:46] <JontheEchidna> It has seen some love (from a new maintainer) in svn, so hopefully it'll get better
[00:46] <Tonio_> ScottK: hum svn: Target path does not exist
[00:47] <JontheEchidna> whoa, lag
[00:47] <Tonio_> ScottK: looks like it was moved over kde svn.... which means it's got an official maintainer, or was droped :)
[00:47] <a|wen> Tonio_: okay ... well not-our-fault is good enough for this stage
[00:47] <a|wen> Tonio_: yeah; it stopped crashing on resume ... and now works for WPA enterprise!
[00:48] <JontheEchidna> a|wen: oh cool, so enterprise is really fixed now?
[00:48] <JontheEchidna> Tonio_: folder was moved: http://websvn.kde.org/trunk/playground/network/kbluetooth/
[00:49] <JontheEchidna> dropped the redundant 4
[00:49] <a|wen> JontheEchidna: i was connected using WPA-enterprise TTLS/PAP at my university today :)
[00:49] <JontheEchidna> :)
[00:50] <a|wen> Tonio_: kdebluetooth crashes for me on every resume; so as soon as you have a new snapshot count me in for testing
[00:50] <JontheEchidna> I feel bad triaging KNM bugs without being able to test fixes, glad to hear it works now
[00:50] <JontheEchidna> Bugs aren't looking so bad, actually: https://bugs.launchpad.net/ubuntu/+source/plasma-widget-networkmanagement
[00:50] <JontheEchidna> Not too many serious ones left, and most of the others are upstreamed
[00:51] <a|wen> exactly ... it is looking pretty decent
[00:51] <JontheEchidna> Mobile broadband has never really worked well, so at least that's not a regression
[00:51] <a|wen> is VPN still completely broken; or is it time to start testing that if i get the chance?
[00:51] <JontheEchidna> there has been efforts to fix that, too
[00:52] <JontheEchidna> s/has/have
[00:52] <JontheEchidna> latest upload fixes vpnc connections, purportedly (can't test myself)
[00:53] <Tonio_> a|wen: yeah
[00:53] <JontheEchidna> and openvpn connections should be working since a few updates ago. The only thing that's not there is pptp vpns
[00:55] <a|wen> cool ... needs to find ways of testing some of that
[01:02] <Tonio_> a|wen: here is my issue with kdebluetooth
[01:02] <Tonio_> http://pastebin.ca/1567703
[01:03] <Tonio_> a|wen: seen that already ? we probably have a packaging issue since we have the package, but cmake stuff lacks in it
[01:04] <Tonio_> a|wen: right, it should be fixed... that's a packaging issue
[01:05] <a|wen> Tonio_: kdelibs-experimental contains the .so ... and probably also the uninstalled .cmake file
[01:06] <Tonio_> a|wen: it doesn't include the cmake file, we should add it to the -dev package
[01:07] <Tonio_> a|wen: I'm doing this right now
[01:07] <a|wen> :)
[01:08] <shtylman> I don't know anymore...
[01:08] <shtylman> I cannot for the life of me figure out this filepicker bug...
[01:09] <shtylman> there is voodoo magic that I just don't understand...
[01:12] <a|wen> shtylman: have you tried clearing the cache+tmp and re-login? just to be sure that it isn't that kind of magic happening
[01:13] <shtylman> a|wen: how do I clear? and you can try this yourself...open openoffice and open the filedialog ... with oxygen style there is no text near checkboxes or any right click menu...but with other styles there is!
[01:17] <shtylman> I am just at a loss for what could be causing this...also...there is no "new folder" in the right click context menu...
[01:17] <shtylman> also...no idea...
[01:18] <a|wen> shtylman: okay, i agree ... that looks amazingly odd
[01:18] <shtylman> yea...and I have NO IDEA why it happens...nor have the slightest clue where to really start digging...
[01:19] <shtylman> this is a high priority bug for me... and I have no idea :)
[01:20] <a|wen> looks to be the completely wrong menu showing
[01:22] <shtylman> that is one problem... and then  another is with the text when using oxygen...
[01:22] <shtylman> I just ... *sigh* ..
[01:22] <shtylman> many hours spent trying little things to no avail...
[01:25] <a|wen> pretty annoying when that happens
[01:27] <shtylman> yea...very
[01:33] <rgreening> ScottK: any idea if there will be a way to fix the brokenness? I.e. via live disk and chroot or do I need a re-install?
[01:33]  * a|wen goes to bed ... 'night ppl
[01:33] <ScottK> I think it's fixable, but I didn't follow the details.  Read the #ubuntu-devel logs for hints.
[01:33] <ScottK> Good night a|wen
[01:33] <rgreening> ty ScottK. I'll look
[01:36] <ScottK> Tonio_: I think that means it got a real maintainer.  IIRC from ML discussion he was going to look into the Solid stuff too.
[01:41] <Tonio_> ScottK: yup afaik, the main problem for the UI is that the solid backend is very light atm
[01:42] <ScottK> So progress at least.  How much, we'll see.
[01:43] <Tonio_> ScottK: should all uploads fix a bug right now ? even if it's just a list-missing issue in a package fixed ?
[01:43] <ScottK> Tonio_: For Main?
[01:44] <Tonio_> yep
[01:44] <ScottK> For Main, don't upload anything that doesn't fix a bug milestoned for Alpha 6 and even then ask first.
[01:44] <ScottK> I suspect that after today's chroot bustage they'll be grumpy about extra uploads.
[01:45] <ScottK> It's already after we usually have the first test ISOs and we're no where close.
[01:45] <Tonio_> ScottK: I wasn't expecting to upload anything right now :)
[01:45] <Tonio_> ScottK: just that cause the freeze policy seems very.... changing, I'm asking :)
[01:45] <rgreening> ScottK: what's the correct process to chroot in live env under ubuntu? I have the partitions mounted, and I thought 'chroot /mnt was all I needed, but I think I need something else. yes/no?
[01:45] <ScottK> OK.  After Alpha 6 is out, you can upload any bugfix that doesn't break the U/I freeze.
[01:46] <ScottK> rgreening: No idea.
[01:46] <rgreening> crap
[01:46] <Tonio_> ScottK: but I need to declare the bug, right ?
[01:46] <Tonio_> that's my concern :)
[01:46] <ScottK> Tonio_: It doesn't need to be an LP bug, it can just be an issue in the package.
[01:46] <Tonio_> s/declare/write
[01:46] <Tonio_> kk
[01:46] <ScottK> No.
[01:46] <ScottK> For a new bugfix release from upstream, that you need a LP bug for (for documentation)
[01:47] <Tonio_> 6 month ago we had too... well maybe it was just post beta, but I seem to remember it was straight after the feature freeze
[01:47]  * ScottK doesn't think so, but who knows.
[01:47] <Tonio_> ScottK: yeah that the standard ffe
[01:47] <Tonio_> let's say I'm tired
[01:47] <rgreening> hmm... apparantly that works... I just can't run ifconfig or route to verify network. haha
[01:47] <ScottK> No, bugfix release doesn't need an FFe, just the bug to document it.
[01:48] <ScottK> You write the bug, but it doesn't need approval.
[02:12] <rgreening> ScottK: I posted the chroot recovery on my blog (http://roderick-greening.blogspot.com)
[02:12] <rgreening> nixternal: ^
[02:13] <ScottK> Nice.
[02:13] <rgreening> so i DON'T EVER FORGET IT :)
[02:13] <rgreening> oops caps
[02:13] <rgreening> dam... still got borked system even after updating in chroot
[02:13] <rgreening> grrr
[02:22] <jjesse> evening
[02:27] <jjesse> does on screen notification work with the kde 4 version of konversation?
[02:37] <JontheEchidna> screen notification?
[02:38] <JontheEchidna> like, when somebody pings you it pops up in a KDE notification?
[02:38] <jjesse> the OSD that was broke earlier, looks like it now works
[02:40] <shtylman> apachelogger: anyone ok my new package?
[02:43] <rgreening> ok, recovered my system. lots of errors about udev stuff though..
[02:43] <rgreening> whew
[02:44] <shtylman> heh
[02:46] <shtylman> this openoffice bug might have to be resolved very late in the cycle...
[03:54] <jjesse> ping nixternal
[03:55] <jjesse> nixternal:  unable to find /kubuntu/advanced-topics on my netbook edition
[03:55] <jjesse> nixternal:  looks like in my branch advanced-topics is missing
[04:41] <yuriy> Riddell: a bit of reduncancy in the koffice announcement
[04:44] <yuriy> the one on the dot
[09:07] <apachelogger> shtylman: pardon?
[10:37] <Riddelll> waa, oversized CDs
[10:40] <neversfelde> and totally borked karmic updates :(
[12:34] <Riddelll> uh oversized DVDs
[12:35] <shtylman> apachelogger: you said someone had to review the new binaries...
[12:35] <shtylman> for kubuntu-installer-style
[12:43] <Riddelll> shtylman: there's nothing in the queue for review
[12:43] <Riddelll> has it been uploaded?
[12:44] <shtylman> Riddelll: how do I get it uploaded? does it have to be added to the trunk of the package first?
[12:53] <apachelogger> upgrade your android once a day and you shall be happy
[12:53] <apachelogger> :)
[12:53] <Riddelll> shtylman: well yes, surely you've seen it done lots
[12:54]  * apachelogger thinks a graphic of the whole process would sure be useful
[12:54] <Riddelll> shtylman: evan or whoever will merge into trunk, package it up and upload
[12:54] <apachelogger> will still take some days though, currently we are freezing for alpha6
[12:55] <apachelogger> uhhh
[12:55] <apachelogger> new android market
[12:55] <apachelogger> sweet
[12:55] <davmor2> apachelogger: hey there's gonna be a re-spin I can feel it in my water ;)
[12:56] <apachelogger> Oo
[12:56] <apachelogger> now that is sick
[12:57] <apachelogger> did I point out that the computer-janitor UI is quite uglish?
[12:57] <apachelogger> should we port it, it sure has to be way different from the GTK thingy
[12:57] <apachelogger> though I have no clue how exaclty it should look :)
[12:58] <davmor2> apachelogger: it does a dirty job do you really need it to be pretty too?
[12:58] <emonkey> lol
[12:58] <apachelogger> usable at the very least
[12:58] <apachelogger> first I saw the UI, I was like, uh, eh, what to do?
[12:58] <apachelogger> hm
[12:59] <apachelogger> anyone using kile?
[12:59] <apachelogger> bug 430666 shoudl be fix0red according to upstream changelog
[13:01] <emonkey> apachelogger: I used it for a while
[13:01] <shtylman> Riddelll: ok...I got that, evan wanted me to ask if it would get a freeze exception before merging though...thats what my inquiry is about...
[13:02] <apachelogger> oh
[13:02] <apachelogger> emonkey: was misparsing the bug anyway
[13:03]  * apachelogger patches xdg-open support in
[13:03] <emonkey> k :)
[13:03] <apachelogger> although
[13:03] <Riddelll> shtylman: yes I can grant that, you'd need to open a bug asking for it
[13:03] <apachelogger> then we would have to do that for all the View thingies
[13:03] <apachelogger> don't like that
[13:03]  * apachelogger wont fix that
[13:04] <davmor2> Riddelll: I was going to say if you hurry it might make the next round of re-spins
[13:05] <shtylman> gotcha
[13:07]  * apachelogger starts spinning alright
[13:07] <shtylman> Riddelll: you know any kde developer I can poke about this openoffice bug? I just don't understand the strange filepicker behavior...
[13:08] <apachelogger> uh
[13:09] <apachelogger> kile snapshot aint got no translations
[13:11] <Riddelll> shtylman: what bug?  filepicker probably is dfaure
[13:14] <Riddelll> shtylman: what bug?  filepicker probably is dfaure
[13:18] <freinhard> any ppa with intel 2.8.1 for jaunty round? 2.6.3 isn't useable and 2.7.1 still bugs me...
[13:40] <agateau> ScottK: ping
[13:41] <JontheEchidna> freinhard: This might be something: https://launchpad.net/~xorg-edgers/+archive/drivers-only
[13:46] <JontheEchidna> So, are things safe to reboot w/ the latest updates?
[14:00] <ScottK> agateau: Pong
[14:00] <agateau> ScottK: do you use a specific branch for packaging Quassel?
[14:01] <ScottK> agateau: It's the standard Kubuntu bzr branch on LP.
[14:01] <agateau> ScottK: I mean in the upstream git
[14:02] <ScottK> agateau: There is a libindicate branch, but your stuff was (accidentally) merged into git head, so you should work from that.
[14:02] <ScottK> apachelogger: I think a|wen uses kile.
[14:02] <agateau> ScottK: ok, that's what I started to do
[14:02] <agateau> ScottK: no kubuntu branch or something then
[14:02] <ScottK> Nope.
[14:03] <ScottK> The libindicate branch for you was the only time I've pulled from anything other than head.
[14:03] <agateau> ok
[14:03] <ScottK> Once they release 0.5, there will be a branch for that, but that's a bit off yet.
[14:22]  * apachelogger giggles
[14:22] <apachelogger> ReleaseScript::Release = mom; ReleaseScript::Application = dad
[14:22] <apachelogger> obviously mom does all the work :P
[14:36] <ghostcube> apachelogger: heh like in real live
[14:36] <ghostcube> lol
[14:37] <apachelogger> aight :D
[14:38] <apachelogger> hm
[14:38] <apachelogger> that is all getting ugly
[14:39] <apachelogger> ReleaseScript::L10n -> ReleaseScript::AbstractReleaseL10n -> ReleaseScript::AbstractRelease -> ReleaseScript::AbstractVcs
[14:52] <apachelogger> uhh
[14:53] <apachelogger> taglib 1.6
[14:53] <apachelogger> sweet
[14:53] <apachelogger> we should get a list with stuff to do for 10.04
[14:53] <apachelogger> taglib 1.6 would be one of them :D
[14:57] <apachelogger> http://www.youtube.com/watch?v=MBRFkLKRwFw
[14:59] <ScottK> IIRC it's being packaged in Debian, so we should get it for free.
[15:00] <Riddelll> I'd have thought so
[15:01] <apachelogger> ScottK: it replaces taglib-extras for the better part
[15:01] <apachelogger> so whether to ship that by default is to be evaluated
[15:10] <jgjones> Greetings
[15:11] <jgjones> I'm wondering if anyone else have a bug to do with Karmic not picking up on any USB/Firewire drives being plugged in?
[15:11] <jgjones> If not, how can I report this please?
[15:13] <ScottK> jgjones: Karmic?
[15:13] <jgjones> Yes
[15:14] <ScottK> That area is getting seriously re-engineered this week, so it's not suprising.
[15:14] <ScottK> I'd wait and see if it works after the Alpha 6 release and if it's not working then, then let us know.
[15:14] <jgjones> Ah OK then...so I'll hold off until after that and if still a problem, report it?
[15:14] <ScottK> Yes.
[15:14] <jgjones> No worries I'll do that, thanks for letting me know.
[15:32] <rgreening> jgjones: I have the same issue
[15:32] <rgreening> :)
[15:36] <nixternal> any idea on how to get shit working today? my netbook is working cuz it isn't using encrypted drives
[15:37] <jussi01> nixternal: hurry up and wait? :D
[15:38] <nixternal> if that is the answer, as you are the only one who has responded thus far today, then i will wait a week and come back...don't expect docs for karmic, updated kairmode, or anything else I was working on
[15:39] <nixternal> I am getting ready to go on a month long cycling trip, and stuff has to get done...I am tired of the Ubuntu guys saying "It is karmic, what did you expect"
[15:39] <jjesse> nixternal do you know what happened to advanced topics portion of help, can't find an advanced-topics.xml
[15:39] <davmor2> nixternal: it's been being worked on all morning by all accounts
[15:41] <nixternal> jjesse: I might have ripped it out becasue it was blank...i noticed i was working in 2 different spots as there are kubuntu-docs/karmic branches everywhere
[15:41] <nixternal> so I take it the next beta isn't going to be released on time?
[15:42] <jjesse> nixternal: ok
[15:47] <ScottK> nixternal: Ask Keybuk if he needs a test case for encrypted drive debugging on #ubuntu-devel is what I'd do if you're in a hurry.
[15:49] <nixternal> i would, but he is gone :/
[15:50] <ScottK> rgreening is the expert on recovery here, AFAIK.
[15:50] <nixternal> thus far I have tried just about everything
[15:50] <nixternal> init=/bin/bash, live usb
[15:56] <rgreening> haha
[15:56] <rgreening> nixternal: did you read my blog on planet :)
[15:57] <rgreening> nixternal: I believe in #ubuntu-devel there was some discussion on recovering encryped drive
[16:09] <agateau> Riddell: just released a new version of libindicate-qt as well as updated patches for Konversation, KMail, Kopete and Quassel
[16:10] <agateau> Actually for Quassel I am going to ping the upstream devs directly I think
[16:11] <ScottK> Yes.  Please.
[16:11] <yuriy> agateau: little bug i saw with the indicator yesterday -- on a default setup with no applications running, if i click the icon, i just get a funny little 10x5 pixel or so tab above it
[16:11] <Riddelll> agateau: ok, that'll have to wait until after tomorrow's alpha for upload
[16:12] <agateau> Riddell: oh ok
[16:12] <agateau> yuriy: This is fixed in bzr,
[16:12] <agateau> yuriy: reminds me I need to release a new version of the plasmoid as well :)
[16:23] <Tonio_> ScottK: new libknotification and kdebluetooth on my ppa
[16:24] <ScottK> Nice.
[16:24] <Tonio_> ScottK: I couldn't test the build cause I'm on a fresh new computer and deboostrap cannot install right now...
[16:24] <Tonio_> so no pbuilder
[16:24]  * Tonio_ finally managed to buy a thinkpad, which I wanted for 10 years :)
[16:25] <Tonio_> canada is cheap compared to france on that point, and so because of the conversation, it was very cheap :)
[16:25] <happyaron> anyone know where's the upstream link to gettext-kde package?
[16:26] <Tonio_> happyaron: should have been in the control file, but I don't see it.... lemme look
[16:27] <Tonio_> happyaron: ftp://ftp.kde.org/pub/kde/devel/gettext-kde/gettext-0.10.35-kde.tar.gz
[16:27] <Tonio_> happyaron: when you need this information, you can generally apt-get source for your package, and look in debian/copyright or debien/control
[16:27] <happyaron> Tonio_: do you know where can I find it's bug tracker, use bugs.kde.org?
[16:28] <Tonio_> happyaron: as this is officially kde, I'd say yes
[16:28] <happyaron> Tonio_: thanks
[16:29] <apachelogger> Tonio_: plz invite ubuntu-dev to the kdesudo hackers team
[16:29] <Tonio_> happyaron: yw :)
[16:29] <apachelogger> or add me
[16:29] <apachelogger> even better, both :D
[16:29] <Riddelll> happyaron: it's not used any more, that's for KDE 3 only
[16:29] <Tonio_> apachelogger: right, just seen your email
[16:29] <Tonio_> apachelogger: I'll probably add kubnutu-dev instead no ?
[16:30] <apachelogger> we dont have an kubuntu dev team on launchpad
[16:30] <happyaron> Riddelll: oh, thanks
[16:30] <Tonio_> apachelogger: I don't see the point is the 'ubuntu-dev" group :)
[16:30] <Tonio_> apachelogger: well kubuntu-members then :)
[16:30] <Tonio_> apachelogger: need to commit changes ?
[16:30] <apachelogger> Tonio_: the point being that I, as core dev, can crap out the package in ubuntu yet I cannot bzr push to the branch
[16:31] <apachelogger> which is IMHO a permission flux since however does the next version needs to merge the upload done to ubuntu thus increasing his work load
[16:31] <Tonio_> yup
[16:32] <Tonio_> apachelogger: right, let's add ubuntu-dev then
[16:32] <apachelogger> so since non-kubuntu devs can upload a new kdesudo to ubuntu it also makes sense that they can push their changes directly to the branch, thus ubuntu dev or at least coredev should be member of the kdesudo team :)
[16:32] <apachelogger> Tonio_: k :)
[16:32] <Tonio_> apachelogger: you're in
[16:33]  * apachelogger looks for his torchwood dvds
[16:33] <apachelogger> Tonio_: thx
[16:33] <apachelogger> Tonio_: btw, is it common to create a new upstream release when doing changes? especially such that only affect the debian dir
[16:33] <Tonio_> apachelogger: ubuntu-dev invited, have to wait for the team admin to approve
[16:33]  * apachelogger converted to update-alternatives
[16:34] <Tonio_> apachelogger: for debian, I tend not to
[16:34] <apachelogger> ok
[16:34] <Tonio_> apachelogger: just commit and next real upload will do the trick
[16:34] <apachelogger> *nod* makes sense :)
[16:34] <Tonio_> apachelogger: the thing is that kdesudo is commonly used on gentoo, debian, and a few other distros, so basically any code fix may require a new upstream release
[16:35] <Tonio_> apachelogger: in this case ping me, I'll do it, since I publish on kde-apps
[16:35] <apachelogger> ok
[16:54] <nixternal> rgreening: ya, and that discussion wasn't productive at all concerning encrypted drives
[16:54] <nixternal> it seems all I can do is debug
[17:01] <nixternal> w00t, I finally worked around these buggers
[18:01] <nixternal> ScottK: that architect with the SAMBA issue that Canonical forwarded to me...SSH FTW! 2 minutes and it was fixed :)
[18:02] <ScottK> nixternal: Good for you.
[18:07] <nixternal> ScottK: are we going to have to change /etc/init.d/kdm for upstart or no?
[18:08] <ScottK> No idea.  I'd ask Riddelll.
[18:08] <nixternal> I think you just did :)
[18:08] <ScottK> Yup.
[18:08] <Tonio_> apachelogger: as I anticipated :) Invitation to ubuntu-dev declined by pitti
[18:09] <apachelogger> lol
[18:09] <nixternal> Tonio_: what are you trying to do?
[18:09] <Tonio_> nixternal: bah nothing :)
[18:09] <nixternal> you are up to something... pitti just doesn't decline for the fun of it :p
[18:09] <Tonio_> just apachelogger suggested me to invite ubnutu-dev to kdesudo project.... which seemed strange to me ):
[18:09] <Tonio_> :)
[18:10] <Tonio_> looks like as wasn't that wrong
[18:10] <nixternal> ahh, haha
[18:14] <Riddelll> nixternal: not long ago keybuk said he'd do it if we reminded him
[18:15] <Tonio_> nixternal: I was looking at that yesterday
[18:15] <nixternal> Riddelll: I think you need to add one more 'l' to your nick :p
[18:15] <Tonio_> nixternal: ouy kdm init script is a little more complicated than the average init
[18:15] <nixternal> Tonio_: ya, I have been looking at it all morning
[18:15] <Tonio_> nixternal: can be done of course, but it's not that easy :)
[18:16] <Tonio_> so maybe we should do it for him cause I suspect keybuk will not figure out if something breaks
[18:16] <apachelogger> whats this about?
[18:16]  * apachelogger is wondering when our kdm init script became complicate though :P
[18:17] <nixternal> Tonio_: I can take a glance and see how much work it would be...supposedly they did gdm faily easily and their init script wasn't the easiest iirc
[18:20] <rgreening> Riddelll: any progress in cleaning up ksplashx patch....
[18:22] <Riddelll> rgreening: it no longer runs when using autologin
[18:22] <rgreening> Is something up with PyQt? ImportError: /usr/lib/pymodules/python2.6/PyQt4/QtGui.so
[18:22] <ScottK> New version uploaded yesterday.
[18:22] <rgreening> it's b0rked
[18:22] <rgreening> no working usb-creator-kde now :(
[18:22] <Tonio_> nixternal: the kdmrc options on the fly is the trick
[18:23] <Tonio_> also it looks like ubuntu uses xsplash with usplash for easy transition to gdm
[18:23] <Tonio_> should we do the same ?
[18:23] <nixternal> Tonio_: ya, I was just noticing that
[18:23] <ScottK> We already do.
[18:23] <rgreening> ScottK, Riddelll: PyQt4 is giving me undefined symbol: _Z29qt_set_sequence_auto_mnemonicb
[18:23] <Tonio_> usplash is broken atm so I can't test, I've installed xplash and will let you guys know :)
[18:23] <Tonio_> ScottK: hu ?
[18:23] <ScottK> Don't we already use xsplash-kde?
[18:24] <Tonio_> ScottK: I see no xsplash-kde
[18:24] <Tonio_> ScottK: and xsplash doesn't rdepends on kubuntu-desktop...
[18:24] <ScottK> rgreening: It may be the new version is binary incompatible.  Could you rebuild against the new python-qt4 and see if it helps?
[18:25] <ScottK> Tonio_: ksplashx?
[18:27] <Tonio_> ScottK: no such package afaics
[18:27] <ScottK> OK.  Ask Riddelll where it's hiding then.
[18:28] <Tonio_> ScottK:  apt-cache show kubuntu-desktop | grep --color splash
[18:28] <Tonio_> ScottK: nothing except the old loved usplash
[18:28] <Tonio_> Riddelll: any plans on that point or should I test xsplash
[18:34] <rgreening> ScottK: shouldn't reinstalling the .py from the deb generate new .pyc's
[18:34] <rgreening> Tonio_: ksplashx is part of kde
[18:34] <rgreening> builtin
[18:35] <rgreening> nm...
[18:35] <rgreening> I think I misread conversation
[18:35] <rgreening> lol
[18:37] <yuriy> Tonio_, ScottK the way i understood it, kubuntu's implementation of xsplash just uses ksplashx, which is part of kdebase(?) so it's just a patch to kdm, no extra package
[18:37] <rgreening> ScottK: woudln't that be python-qt4 vs qt4.6 issue...
[18:38] <Tonio_> yuriy: bah afaics it doesn't work as nicelly as xsplash
[18:39] <Tonio_> yuriy: I still get a fallback to TTY between usplash and kdm
[18:39] <ScottK> rgreening: No.  Due to SIP insanity, as I understand it, pretty much every new build of python-qt4 is BIC.
[18:39] <ScottK> Tonio_: I don't.
[18:39] <Tonio_> yuriy: isn't ksplashx only for kdm to desktop transition ?
[18:39] <Tonio_> ScottK: maybe you're just lucky :)
[18:39] <rgreening> ScottK: I don't understand
[18:40] <ScottK> rgreening: I don't know the details.  NCommander can probably explain.
[18:40] <Tonio_> ScottK, yuriy: in any case I don't see how can a kdm patch fix the usplash-kdm transition...
[18:40] <Tonio_> maybe we should use xsplash too
[18:40] <ScottK> Tonio_: I'm pretty sure Riddelll has a plan, just not recalling the details.
[18:40] <Tonio_> ScottK: yep, that's why I asked :)
[18:40] <Tonio_> ScottK: http://pastebin.ca/1568600
[18:41] <Tonio_> ScottK: changelog for kdebluetooth :)
[18:41] <rgreening> Riddelll: any suggestion on how I can make python-qt4 work again
[18:41] <Tonio_> the guy mostly refactors the code, but seems very active :)
[18:41] <Tonio_> ScottK: I'll look at solid backend changes too, as most of his work should be on the backend side atm
[18:41] <Tonio_> but that sounds good, especially with knetworkmanager now starting to work decently...
[18:42] <ScottK> Cool.  If that would work, I could dump blueman and a stack of Gnome stuff off my netbook.
[18:42] <Tonio_> looks like kde4.4 will eventually be what I consider a mature desktop, feature complete
[18:43] <Tonio_> hum looks like knetworkmanager doesn't like when networkmanager restarts :/
[18:45] <Tonio_> ScottK: also about web browsers.... waiting for arora to come out with adblock, I'm right now packaging opera for medibuntu
[18:45] <Tonio_> ScottK: not perfect, but lots of ubuntu users do use it so....
[18:45] <Tonio_> ScottK: cause I've seen that firefox installere we have... so damned bad not to be able to install it the standard way
[18:46] <Tonio_> most people won't notice the installer and will get 75% of gnome to use it...
[18:46] <Tonio_> that sucks... especially since that could be fixed in the packaging...
[18:46] <rgreening> Arora 0.9.1 or higher will have adblock. Icefox has a release almost ready.. so it will be in the next iso release :)
[18:47] <Tonio_> rgreening: oh ? that fast ? nice ;)
[18:47] <Tonio_> rgreening: what about passwords storage ?
[18:47] <Tonio_> rgreening: among all the features most users will want to use, this is the last missing
[18:47]  * ScottK remembers he is away (working) and stops looking at IRC.
[18:48] <rgreening> wallet support too. but not kwallet yet
[18:55] <rgreening> Riddelll: I think we need a rebuild of bindings for use with the new python-qt4 as they are BIC at the moment. This is what NCommander suggests may solve the current breakage. thoughts?
[18:55] <rgreening> ty NCommander :)
[18:58] <Tonio_> rgreening: basic wallet support is pretty sufficient
[18:58] <Tonio_> rgreening: I use opera and that's okay for me
[19:01] <nixternal> hrmm, getting kdm to start) shouldn't be difficult honestly with upstart
[19:03] <yuriy> pyqt really breaks binary compatibility every bugfix release? ouch.
[19:04] <nixternal> heh, I am in pyqt4 hell myself
[19:09] <yuriy> me too, sort of. i was trying to fix apport-kde on sunday. actually i had a question for you
[19:09] <nixternal> no questions for me!
[19:09] <yuriy> nixternal: you used sys.exit(0) for cancel in apport-kde, was that because of hanging or segfaulting?
[19:09] <nixternal> I have to start charging for questions
[19:09] <nixternal> segfaulting
[19:09] <yuriy> dang.
[19:09] <nixternal> should have been a # FIXME when shit works again
[19:10] <nixternal> that was only temporarily iirc
[19:11] <yuriy> unfortunately that bug is still not fixed. can't tell if it's pyqt's or qt's fault either
[19:12]  * rgreening hates bindings!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[19:12] <nixternal> yuriy: i thought it was fixed...though I need to see how I am doing it in kairmode...it might have been because of the sillyness with a KMessageBox or something....
[19:12] <nixternal> might need a do not close on last window added
[19:16] <e-jat> anyone know how to solve this bug 428365
[19:27] <yuriy> nixternal: it was sort of fixed. it's hanging instead, if it goes down a code path that doesn't cancel and sys.exit
[19:27] <nixternal> app.exit() doesn't work?
[19:27] <nixternal> oh, it has to return 0, and I think doing 'sys.exit(app.exec_())' didn't return 0, even when it should of
[19:28] <nixternal> though I swore I figured taht one out as well
[19:30] <yuriy> nixternal: well there is no main window, so there is no way for app.exec_() to exit the way i understand it
[19:30] <nixternal> oh right
[19:30] <nixternal> what is the main issue with apport-kde now?
[19:31] <yuriy> nixternal: so you were running all the app code from the constructor, exec()ing the dialogs individually, then exec()ing the app and hanging
[19:31] <nixternal> which is odd, as that is the way it has always been, even when it was a qt app and not a kde app
[19:31] <yuriy> nixternal: main issue is that it's hanging instead of exiting
[19:31] <nixternal> lovely
[19:32] <nixternal> you get anything when attaching gdm to the PID and continuing?
[19:32] <nixternal> does it shutdown or crash?
[19:32] <yuriy> more obvious issue is that it doesn't do anything because the complete report option is not visible and not checked by default (easy enough to fix), so it tries to cancel and just hangs (this is the hard part)
[19:33] <nixternal> right, i messed around with it hanging as well, then got it away from hanging and then into segphaulting
[19:33] <nixternal> it was fun times iirc
[19:33] <yuriy> nixternal: the qt version did not exec() the app i think, but it had the segfault problem
[19:33] <nixternal> nice
[19:33] <yuriy> with the latest pyqt in jaunty at least
[19:33] <yuriy> which is what i get when i try to fix the hanging in apport-kde
[19:34] <yuriy> nixternal: bug 405378, bug 403361
[19:35] <nixternal> hrmm
[19:42]  * rgreening is currently rebuilding kdebindings to see if it fixes the BIC b0rkage
[19:43] <nixternal> heh, I spent an hour working on some code for a project and was wondering why it wasn't working :)
[19:43] <nixternal> silly changes
[19:44] <rgreening> haha
[19:44] <rgreening> yeah, pyqt with pykde == foobar
[19:45] <nixternal> and the funny thing, is I kept doing it even after we discussed we have issues right now :p
[19:45] <rgreening> haha
[19:45] <rgreening> silly vistalover
[19:45] <nixternal> let me tell you, my experience with vista yesterday was painful at best
[19:45] <nixternal> i would hit 'F4' to move over a tab in screen, and freakin' Outlook would start up instead
[19:46] <rgreening> bwahaha
[19:46] <nixternal> glad you found that funny, I couldn't check my damn email without F4, I was stuck in irssi the whole time :p
[19:47] <rgreening> ha
[19:47] <rgreening> :P
[19:52]  * ScottK
[19:53] <ScottK> ... is back
[19:53] <ScottK> So I was chatting with my Dad on the phone last night and he asked me how to do something with his computer (still Windows - I'm working on that).
[19:54] <ScottK> The answer I had to give him was, "Dad, you're asking me about how to do something in an operating system I haven't used in almost 5 years.  I really don't know."
 in that situation:-(
[20:01]  * hunger really hates that.
[20:03] <ScottK> We were together last month and he was using my step-brother's Vista equipped laptop and it was so incredibly slow, he asked me what to do to fix it.  I let him use my Kubuntu laptop and suggested it had the wrong OS.  For the first time, he was seriously thinking about it.
[20:04] <ScottK> My prediction is the next time he gets a new computer, he sends it to me to put the correct OS on it.
[20:04] <ScottK> ;-)
[20:04]  * ScottK got some people in #quassel really fired up the other day when I referred to Windows as a "legacy OS".
[20:16] <nixternal> the day I get my old man to switch, is the day that I die :)
[20:19] <SeaJey> Hi guys!
[20:19] <SeaJey> Is it possible to report bugs from Help -> Report bug directly to kde bugzilla instead of launchpad?
[20:19] <SeaJey> It was possible in KDE 4.2
[20:20] <SeaJey> I am using some self-compiled software and it would be more useful to report upstream
[20:54] <Sput> ScottK: but Windows *is* a legacy OS :)
[20:54] <Sput> and it was only one guy being of a different opinion :>
[20:54] <rgreening> Riddell: Qt4.6 does not work properly with python/kde
[20:55] <Sput> also I sorta forced my parents to switch to Linux (already in 2002!) because I refused continuing to give Windows support, and they would've had to look for someone else
[20:55] <Sime_> rgreening: what doesn't work? PyQt or PyKDE?
[20:55] <rgreening> I downgraded qt to 4.5.2 and my python/qt/kde issues went away. There's something eith wrong with the build in experimental or it's simply binary incompatible. I suggest we not do anything with 4.6
[20:55] <Sput> oooh, there's Sime_
[20:56] <Sput> Sime_: anything that could be done to make pykde4 compile again? it's been broken for months :(
[20:56] <rgreening> Sime_: I had latest python-qt and kdebindings 4.3.1 and qt 4.6. Nothing worked wrt python Qt/KDE bindings
[20:57] <Sime_> rgreening: crashes?
[20:57] <davmor2> ScottK:  legacy OS  :) Sweet
[20:57] <rgreening> ImportError: /usr/lib/pymodules/python2.6/PyQt4/QtGui.so  undefined symbol: _Z29qt_set_sequence_auto_mnemonicb
[20:58] <nixternal> http://paste.ubuntu.com/272330/  <- Riddelll? ScottK? upstart file for KDM? at least a start maybe
[20:59] <nixternal> Tonio_: ^^ you too
[20:59] <Sput> Sime_: https://bugs.kde.org/show_bug.cgi?id=206473  <-- I got told in #kde-bindings that you'd be the right guy to talk with
[21:01] <Sime_> Sput: the real cause is probably a break in kdelib BC.
[21:02] <Sime_> Sput: I usually only update and fix bindings in trunk at the end of the dev cycle.
[21:02] <Sput> Sime_: hmmm ok... means that I'll have to do without the python stuff for another few months, I guess... a pity, it looked like an easy fix for a layman :)
[21:03] <Sime_> Sput: If you want to do PyKDE dev stuff, then it makes more sense to use the last stable really.
[21:04] <Tonio_> nixternal: really nice, testing
[21:04] <Tonio_> nixternal: should I just drop the links for /etc/init.d/kdm or ?
[21:04] <Tonio_> I'm not very much used to upstart
[21:04] <nixternal> me either :)
[21:04] <Tonio_> okay so let's... try :)
[21:04] <Sput> Sime_: I'm not working with it, but I'd like to have a full KDE trunk install on my box, and without pykde4, several components won't build :) though I could see and try if trunk still works with pykde-4.3
[21:04] <nixternal> I just pieced together stuff from other upstart files :p
[21:05] <Tonio_> yup yup
[21:05] <nixternal> it doesn't seem to difficult initially
[21:05] <Sime_> Sput: trunk bindings should be very close to 4.3's.
[21:05] <Sput> Sime_: can I build pykde-4.3 against kdelibs from trunk at all?
[21:06] <Sime_> Sput: you can try ;-)
[21:07] <Tonio_> nixternal: installed in kdm.conf with link /etc/init.d/kdm.... let's... try
[21:07] <nixternal> ya, how that part works is beyond me
[21:09] <nixternal> I take it, that it didn't work :)
[21:10]  * jussi01_ waves
[21:10] <jjesse> hello jussi01
[21:12] <jussi01_> :) hi jjesse
[21:12] <nixternal> I never tested to see if I fat fingered anything in that upstart file :p
[21:12] <nixternal> could be a letter off somewhere
[21:14] <yuriy> SeaJey: currently no, but that's an interesting point for self compiled software. the patch for that is in kdelibs, so if you're not compiling that yourself i'm not sure how we could detect that.
[21:14] <yuriy> why is qt 4.6 an issue? it's not even out yet?
[21:16] <nixternal> Tonio_: hehe, take it that it didn't work :)
[21:16] <Tonio_> nixternal: couldn't get it to work
[21:17] <nixternal> lol
[21:17] <Tonio_> upstart report "unknown job kdm"
[21:17] <nixternal> ya, I should probably play around with it a bit, now I understand where it goes
[21:17] <nixternal> the upstart file gets placed in /etc/init/ as kdm.conf
[21:17] <Tonio_> nixternal: looks like having a /etc/init/kdm.conf script and a link in /etc/init.d/ doesn't help
[21:17] <nixternal> and gets run that way...so there are some other tricks it seems for the file
[21:17] <SeaJey> yuriy: this is mosty amarok issue - I regulary compiling it from git. BTW after some experiments with apport and ubintu-bug configs Report bug... does not work at all. How can I repair it?
[21:17] <Tonio_> nixternal: did that
[21:17] <nixternal> right
[21:18] <nixternal> ok...so need to figure out the job thing then
[21:18] <nixternal> I will look through the stuff and play around with it some more tonight
[21:18] <Tonio_> nixternal: -rw-r--r--   1 root root  7161 2009-09-16 22:06 kdm.conf
[21:18] <nixternal> which looks right
[21:19] <Tonio_> and in init.d : lrwxrwxrwx   1 root root    21 2009-09-16 22:10 kdm -> /lib/init/upstart-job
[21:19] <Tonio_> which looks right too :)
[21:19] <Tonio_> nixternal: keybuck might know
[21:19] <Tonio_> nixternal: I suspect :)
[21:21] <nixternal> right...i will let him chill on the fixes he has been doing for the time being...I am sure I can figure it out just by reading backlogs, emails, and any wiki pages, as well as the upstart configs that are already there
[21:21] <Tonio_> yup
[21:22] <Tonio_> lemme know so that I can test.... I can't really help right now since I'm not really available
[21:22] <nixternal> I am a moron, because instead of looking in /etc/init/ I was grabbing package source that already had upstart scripts :/
[21:24] <yuriy> SeaJey: i'm working on fixing that. there's a patch attached to bug 405378 that should get you something working
[21:25] <SeaJey> yuriy: thx
[21:38] <Dario_Andres> Hi. Is the Update Notifier icon a kubuntu-specific addon or it is just a kpackagekit thing ? Thanks
[21:50] <yuriy> Dario_Andres: it's kubuntu-specific, but in Karmic the packagekit one is used for most things
[21:50] <Dario_Andres> yuriy: mh, ok, I just wanted to know where to reassign this report https://bugs.kde.org/show_bug.cgi?id=205939
[21:53] <JontheEchidna> Dario_Andres: that's a KPackageKit crash
[21:53] <Dario_Andres> JontheEchidna: thanks, I will reassign it.
[21:54] <Dario_Andres> thanks yuriy too :)
[21:54] <Dario_Andres> see you
[22:34] <Tonio_> nixternal: in case you need tests for upstart/kdm ping me :)
[22:34] <nixternal> roger that
[23:09] <Tonio_> hum stupid question but how to request a package deletion within the new ppa UI ?
[23:09] <Tonio_> I can't manage to find out the option...
[23:11] <ScottK> There's a place to click to the right side above the package list.
[23:13] <Tonio_> ScottK: I don't see it anymore...
[23:13]  * ScottK looks
[23:13] <Tonio_> ScottK: sure there was but...
[23:14] <Tonio_> ScottK: kdebluetooth should be able to test in about 30 minutes...
[23:15] <Tonio_> ScottK: hum you have to go in "view package details"
[23:15] <ScottK> Tonio_: Upper right.  Yep
[23:16] <Tonio_> what an horrible choice...
[23:16] <ScottK> Was just typing that
[23:16] <ScottK> Feel free to file bugs
[23:16] <Tonio_> the more clicks the worse, added to the fact it's hard to figure out...
[23:16] <Tonio_> ScottK: yup I'll probably do


[12:54] <silvery> Hi, Is there network console ("Ctrl+Shift+K" one) in "builtin" FF from ubuntu 10.10 live (booted from cd)?
[13:00] <silvery> what version of ubuntu has minefield as it's default web-browser?


[00:00] <darkxst> aeoril, you could build vivid vim and try run that in 14.10
[00:00] <darkxst> or test with gnome-terminal from gnome3-staging ppa
[00:00] <darkxst> against standard 14.10 vim
[00:00] <aeoril> darkxst vivid vim works, so that is exactly what I was thinking - just shortcut to the vivid vim and if it solves the problem
[00:01] <aeoril> If not, try gnome-terminal as you suggested
[00:01] <aeoril> darkxst how do I find the build source for the vivid vim?
[00:01] <aeoril> is it in launchpad?
[00:01] <aeoril> (bazaar)
[00:01] <darkxst> pull-lp-source vim vivid
[00:02] <aeoril> pull-lp-source is an actual command at the command line?
[00:02] <darkxst> yes
[00:02] <aeoril> cool - that makes it easy!
[00:02] <darkxst> in ubuntu-dev-tools package
[00:02] <aeoril> gotcha - still gotta install those, but there is a developer wiki for that
[00:03] <aeoril> (to set up my build environment)
[00:03] <aeoril> darkxst doesn't someone need to independently verify the bug also?
[00:03] <aeoril> (confirm?)
[00:05] <aeoril> darkst how do I pull and build gnome-terminal from the ppa?
[00:06] <aeoril> pull-lp-source vivid gnome-terminal?
[00:07] <darkxst> aeoril, you would need to install the whole ppa probably, it needs gtk3.14 and an update libvte compared to 3.14
[00:08] <aeoril> ok, how do I install a ppa?  I can google that if it is involved
[00:08] <aeoril> (maybe I need to go through the beginner developer tutorial and steps at this point ...) darkxst
[00:09] <sarnold> apt-add-repository lp:.... ought to take care of much of it for you
[00:09] <darkxst> aeoril, there are instuctions at the top of any ppa's web page
[00:09] <aeoril> darkxst cool, I think I can take it from here
[00:11] <aeoril> sarnold cool, thanks!
[00:14] <aeoril> sarnold darkxst will installing the gnome-terminal ppa package update gtk3.14 and libvte systemwide?  e.g., do I need to do it on a test virtual machine that I can throw away after figuring out this bug because it will not be plain vanilla 14.4.1 anymore?
[00:15] <sarnold> aeoril: whatever packages in the ppa have higher version numbers than ones on your system will replace the system ones with the next apt-get update -- unless you go to some efforts to pin package versions.
[00:15] <sarnold> aeoril: VM would be best -- I know that might make it harder to reproduce the problem, though, your issue feels like a racy thing that might be harder (or easier?) to reproduce in  VM
[00:15] <darkxst> aeoril, it will update most of GNOME to 3.14, maybe safer to do it in a VM
[00:15] <aeoril> sarnold ok, I'll make a new vm so I can screw around without any worries
[00:16] <aeoril> sarnold it happens equally and very reproducably on a vm in VMWare, Hyper-V and on my 14.04 regular Ubuntu install
[00:16] <sarnold> yay :)
[00:17] <aeoril> sarnold it happens *rarely* on 14.10, but it did happen twice - much less reproducable on 14.04.  It has never happened on my 15.04 vm after many tries
[00:17] <aeoril> sarnold no kidding!
[00:17] <aeoril> much less reproducable on *than* on 15.04* (misworded)
[00:18] <aeoril> whoops, screwed up the fix - "*than* on 14.04*" :(
[00:18] <sarnold> aha :) I'm glad it's easily reproducable in vms, that makes it far easier to deal with :)
[00:18] <aeoril> yes, this particular problem does not seem to care about vms
[00:19] <aeoril> what do you guys do if vms fail to reproduce problems on bare metal machines?  Dual boots, quad boots, etc?
[00:19] <aeoril> (not sure how many different versions of Ubuntu you can have as alternate boots)
[00:20] <aeoril> I have read about chroot ...
[00:20] <darkxst> aeoril, for GNOME bugs there is jhbuild which is handy
[00:20] <aeoril> sarnold I am also glad it has *never* happened (so far) on 15.04 - I probably need to try it out a bunch more times though to make sure because 14.10 is pretty rare ...
[00:21] <aeoril> darkxst ok, I am writing down all this as I get it here so I can remember
[00:23] <aeoril> sarnold darkxst if I find that vivid vim works on 14.04/14.10, can we just use vivid vim for the backport?
[00:23] <aeoril> vivid's vim version*
[00:23] <darkxst> aeoril, no, only bug-fix only releases can be bugported to a stable release
[00:24] <aeoril> ahhh, ok - so I would have to see if the latest bug-fix only release of vim in launchpad fixes the problem, and use it if it does?
[00:25] <aeoril> darkxst ^
[00:25] <darkxst> aeoril, vim doesnt really seem to do proper releases
[00:26] <aeoril> darkxst I was just thinking that - the guy on #vim said their release/bug versioning was a mess ... or really not existant ...
[00:26] <darkxst> in which case you would want to backport the one patch that fixes the problem
[00:27] <aeoril> darkxst hmmm ... sounds difficult and laborious to find the individual patch I guess ...
[00:27] <darkxst> sometimes, often its pretty easy though
[00:27] <aeoril> darkxst oh, ok - that is good to know
[00:28] <darkxst> but first determine if its gnome-terminal or vim
[00:28] <aeoril> darkxst I was just exploring while I had you available
[00:31] <aeoril> darkxst what about confirmation from someone else?  What if the bug is somehow in my personal hardware/software setup?  Probably not, since two different machines do it, one normal install the other vms under Win 8.1, very different hardware darkxst
[00:32] <darkxst> you don't necessaraily need confirmation from someone else, especially if you can reproduce in clean installs on different  hardware
[00:32] <darkxst> atleast not at this stage
[00:33] <aeoril> darkxst yes, clean installs on all vms, and on the regular machine as well
[00:33] <aeoril> darkxst well, gotta knock off for a while - I'll try to get back to it tonight.  Thanks!
[00:34] <aeoril> sarnold thank you as well!
[01:58] <aeoril> darkxst you still there?  I am back and firing up a new vm with 14.04.1 to test vim and/or gnome.  I'll let you know how it goes.  Thanks.
[01:59] <aeoril> sarnold ^
[01:59] <sarnold> hey aeoril :)
[02:00] <aeoril> sarnold hey - I am back and starting to work on the steps outlined by you and darkxst for the vim/gnome-terminal bug
[02:00] <sarnold> aeoril: nice, happy hunting :)
[02:00] <aeoril> sarnold This is fun!
[02:00] <aeoril> yah, this is totally cool ... :)
[02:01] <aeoril> sarnold I am just glad I can use vms!  SOOOO much easier, I hope!
[02:01] <aeoril> vms are just tooooo easy - almost makes you feel guilty or something!
[02:02] <aeoril> I am sure they can also be problematic for many scenarios, though ...
[02:05] <aeoril> sarnold something actually cool - I built my machine to run lots of vms for various scenarios, this one included, so I have 32GB memory, so can have lots of vms running with lots of memory and just switch easily
[02:05] <sarnold> aeoril: ooh yeah, 32 gigs is a lot of breathing room :)
[02:06] <sarnold> especially since VMs typically can get away with less ram themselves -- their backing block devices are cached by the host, too
[02:07] <aeoril> sarnold yah, the guys on #hardware thought I was an idiot to do it, but it has already proved its worth.  I have 12GB used right now with 4 vms running simulataneously, 19GB still free!
[02:08] <aeoril> It is very convenient and easy to switch to various running configurations ...
[02:10] <aeoril> sarnold vmware says it uses 768MB for the video card by default, more if you choose
[02:11] <sarnold> aeoril: hah, fancy. I always use kvm and it has the lowest of low-end video cards; most of the time I just ssh in. heh. that might not work so well for your problem though...
[02:12] <aeoril> sarnold the hardware was pretty cheap though really, and the software is all free, so ...
[02:13] <sarnold> aeoril: pretty amazing, right? my first PC had 4 megabytes RAM..
[02:14] <aeoril> sarnold my first pc had 4K!
[02:14] <aeoril> lol
[02:15] <sarnold> aeoril: PC? :)
[02:15] <aeoril> Apple II ...
[02:15] <sarnold> hehe
[02:15] <aeoril> My XT had 640K - and a hard drive!
[02:16] <aeoril> oh, maybe 1GB, but 640 usable, other stuff was reserved, I think
[02:18] <sarnold> "640k ought to be enough for anyone" :)
[02:20] <aeoril> sarnold yes, there was a guy at my old place of work that had that in his signature
[02:59] <aeoril> sarnold darkxst how do I install this?  I tried sudo apt-get install ncurses but it did not work (not found):  https://launchpad.net/ubuntu/+source/ncurses
[02:59] <aeoril> sarnold darkxst ./configure for vim needs it ...
[03:00] <sarnold> aeoril: it probably needs libncurses5-dev -- but a neat thing is apt-get build-dep -- it'll install all the packages needed to build a specific package
[03:01] <sarnold> aeoril: (of course, better is to use a tool like sbuild to make repeatable builds that don't require installing new packages in your 'main' system -- but I assume you're doing the development on the VM, where it doesn't matter)
[03:01] <aeoril> sarnold yes, vm
[03:02] <aeoril> sarnold not sure how to use apt-get build-dep ...
[03:02] <sarnold> aeoril: try: apt-get build-dep vim
[03:03] <aeoril> sarnold I downloaded the vivid version of the vim source from lp - will apt-get build-dep vim still be ok for that?  I am on a 14.04.1 trying to build the vivid version of vim to test it on a 14.04.1 system ...
[03:03] <sarnold> aeoril: it'll get close most of the time
[03:04] <aeoril> sarnold I did this: pull-lp-source vim vivid
[03:05] <aeoril> sarnold this seems gunky - maybe I should use sbuild?
[03:06] <sarnold> aeoril: I wouldn't bother yet, faster iteration is probably more important at this point
[03:06] <aeoril> yes, sbuild seems involved ...
[03:12] <aeoril> sarnold making, thanks ...
[03:12] <sarnold> woo
[03:20] <aeoril> sarnold sssswwwwweeeeeettt!  That appeared to fix it!  Ran vim out of the temp directory from build, no problems, reran vim from normal spot, crapped out as usual!
[03:21] <Unit193> Heh, what can I say?  I use pbuilder. :P
[03:21] <sarnold> aeoril: oh good, now you get to figure out what changed :)
[03:21] <aeoril> sarnold lol there lies the rub!
[03:22] <aeoril> sarnold should I do something to the bug report at this point?
[03:22] <sarnold> aeoril: probably not, not much to be done yet
[03:23] <aeoril> this is still pretty cool ...
[03:24] <aeoril> sarnold so now I have to put on my developer hat? lol
[03:24] <sarnold> aeoril: you may have success bisecting their revision control, if they've got public trees..
[03:25] <aeoril> sarnold they've got public trees, but the revision control apparently sucks ... they use mercurial and the guy on #vim said that the revision control is a mess
[03:25] <aeoril> sarnold I think it is safe to say we have at least narrowed it down to a vim problem ...
[03:26] <darkxst> aeoril, bisecting would still find the commit
[03:26] <darkxst> regardless of how messy it is
[03:27] <sarnold> I'm seeing lots of checkins per day; it might not be ideal, but it's liable to give small enough checkins that'd it be useful
[03:27] <sarnold> I was afraid it was going to be tarball imports or something else fairly .. ghetto
[03:32] <aeoril> darkxst sarnold can I do anything with the lp source code instead?
[03:33] <aeoril> bisect on Ubuntu lp source/patches or whatever?
[03:34] <sarnold> aeoril: no :(
[03:37] <aeoril> sarnold how did you see their source code history?  Do you have mercurial and fetched their source code and looked at the commits in your local repo you fetched?
[03:37] <sarnold> aeoril: https://code.google.com/p/vim/source/list
[03:37]  * sarnold <-- lazy
[03:41] <aeoril> sarnold looks like they have issues tracked though
[03:41] <sarnold> aeoril: yeah, if you can find an issue, so much the better :)
[03:41] <aeoril> sarnold lots of issues ...
[03:42] <sarnold> I'm not surprised, they support a lot of crazy platforms
[03:45] <aeoril> sarnold like Windows?
[03:46] <darkxst> aeoril, I think a bisect would be your best bet here
[03:46] <aeoril> darkxst yes, I think so
[03:46] <darkxst> probably quicker than trawling through undescriptive commit messages!
[03:47] <aeoril> darkxst quick search on issues found nothing, lots of commits
[03:50] <aeoril> sarnold darkxst so, I guess once I download the latest source repo, I just checkout commits bisecting from my local repo, bisecting dates, until I hit the right commit?
[03:51] <aeoril> s/right commit/commit that fixes the problem/
[03:51] <darkxst> vcs should provide a bisect command (never tried in mercurial though)
[03:51] <aeoril> darkxst ok, that would be better then (much)
[03:51] <darkxst> don't try and do it manually!
[03:52] <darkxst> atleast with git bisect, you provide the last know bad commit and then a known good commit
[03:52] <darkxst> git chooses the commits to checkout and you tell it if each one was good or broken
[03:53] <darkxst> it would be a similar concept for mercurial
[03:53] <aeoril> http://www.selenic.com/hg/help/bisect :)
[03:53] <sarnold> hg does have a bisect sub-command, but I have no idea how you tell it success / failure; if it works, it'll be awesome...
[03:53] <aeoril> sarnold ^
[03:54] <darkxst> or there is a git mirror of vim on github -> https://github.com/vim-jp/vim/commit/f69eb7659a7bf4a586c569ae63fc2cc6ad364710
[03:54] <sarnold> :)
[03:54] <aeoril> darkxst oh, that is good to know - which do you suggest I use?
[03:55] <darkxst> probably git, given I know it works!
[03:55] <aeoril> lol ok, I would rather use git!
[03:56] <aeoril> darkxst sarnold wow, this is really cool - I am learning a lot rapidly ...
[03:56] <aeoril> Your help is immensely cool and appreciated ...
[03:57] <aeoril> darkxst sarnold I think I have lucked out with my first bug being relatively easy, at least so far (I know, famous last words ...)
[03:57] <sarnold> hah, normally terminal bugs don't get called "easy" :)
[03:58] <aeoril> sarnold terminal bugs?
[03:58] <aeoril> you mean terminal as in gnome-terminal?
[03:58] <sarnold> aeoril: anything involving ncurses, terminfo, terminals...
[03:58] <darkxst> aeoril, and you haven't found the solution just yet
[03:58] <aeoril> sarnold well, i said "so far" ...
[03:59] <sarnold> you might fix gnome-terminal but break xterm, rxvt, urxvt, aterm, wterm, Eterm, konsole, or the virtual terminals...
[03:59] <aeoril> I am an optimist!
[03:59] <sarnold> :)
[04:00] <aeoril> ahhh, I see ... right, didn't even think about that ...
[04:00] <aeoril> I am just a babe in the woods!
[04:00] <aeoril> Ready for the wolves to start circling!
[04:00] <aeoril> lol
[04:01] <sarnold> it's a good start though, the best way to get involved is to fix a bug that annoys you :) once you've gotten started, future problems will seem that much easier..
[04:02] <aeoril> sarnold yes, I am learning a lot - the funny thing is, with this particular bug, I just realized using screen I don't need to mess with the problem behavior, but it is good to learn on I guess
[04:03] <aeoril> screen or tmux
[04:04] <sarnold> aeoril: hah :) but similarly, gnome-terminal --geom .... -c "screen -e vim ..." is a bit much just to get a working vim in terminal.
[04:05] <aeoril> sarnold well, I have them as scripts, so "pup vi .bashrc" means "pop up a new gnome terminal sized per the script and run vi in it on .bashrc"
[04:06] <aeoril> So, pup <something> becomes useful for a variety of things
[04:09] <aeoril> sarnold can you think of a better way?
[04:10] <aeoril> sarnold well, I think tmux or screen are the best ways
[04:10] <sarnold> aeoril: tmux / screen would do it fine, but you're already on this path, might as well keep going :)
[04:10] <aeoril> sarnold yes, I am going to try to complete this bug fix
[04:11] <sarnold> sweet
[04:11] <darkxst> aeoril, get bisecting then ;)
[04:11] <aeoril> darkxst not tonight - already late - tomorrow ... :)
[04:12] <sarnold> indeed, goodnight aeoril, darkxst :)
[04:13] <aeoril> sarnold night~
[04:13] <darkxst> aeoril, night
[04:13] <aeoril> night, darkxst ~
[06:42] <pitti> Good morning
[06:42] <pitti> bdmurray: yes, I'll do one today, I got darkxst' wayland hook
[06:54] <darkxst> hey pitti
[06:54] <darkxst> also bug 1418766
[06:56] <pitti> darkxst: do our GTK packages have native wayland support, or do we need to explicitly check for xwayland?
[06:56] <pitti> darkxst: because, under xwayland you ought to have $DISPLAY?
[06:56] <pitti> [ ! -z "$DISPLAY" -o -z "$WAYLAND_DISPLAY"]
[06:56] <pitti> ITYM -a there (will fix when merging)
[06:57] <pitti> oh, and why the ! ?
[07:00] <darkxst> pitti, initially when you launch you only have $WAYLAND_DISPLAY, I think you won't get into XWAYLAND until gtk is initialized
[07:01] <pitti> darkxst: I mean, will GTK work without xwayland too?
[07:01] <pitti> darkxst: i. e. does GTK have native wayland support in our packages?
[07:01] <pitti> darkxst: if not, we need to check [ -n $WAYLAND_DISPLAY ] && (xwayland installed)
[07:02] <darkxst> pitti, GTK does have native wayland support, however apport isnt completely safe yet due to the couple of GdkX11 calls
[07:04] <darkxst> only core stuff is running native wayland by default
[07:04] <darkxst> and Xwayland gets installed with the session, so it wouldnt be possible to have WAYLAND_DISPLAY set and xwayland not installed
[07:07] <darkxst> and right that expression isn't quite right
[07:10] <pitti> darkxst: ah, ok; so existance of $WAYLAND_DISPLAY implies xwayland is present?
[07:11] <darkxst> I guess [ -z "$DISPLAY" -a -z "$WAYLAND_DISPLAY"] is right
[07:11] <darkxst> pitti, atleast on GNOME
[07:12] <darkxst> maybe not for weston
[07:16] <darkxst> I guess it wouldnt hurt to check if installed
[07:19] <pitti> darkxst: http://paste.ubuntu.com/10087059/ ?
[07:20] <darkxst> pitti, yep looks good to me
[07:26] <darkxst> pitti, and its really only set_modal_for() that would break under native wayland, although I don't think there an equivalent of that implemented in wayland yet
[07:26] <pitti> darkxst: ah, perhaps we could more gracefully intercept that failure, and just not make it modal then?
[07:28] <dholbach> good morning
[07:29] <pitti> hey dholbach!
[07:30] <dholbach> hi pitti
[07:32] <darkxst> pitti, right, should be simple enough but for 3.14 normal GTK apps all default to Xwayland unless the user forces things with GDK_BACKEND
[07:32] <darkxst> no probably not too urgent
[07:33] <darkxst> s/no/so/
[07:39] <darkxst> pitti, and I actually don't know how to check for that in python/introspection, atleast in C its GDK_IS_X11_DISPLAY()
[07:43] <pitti> darkxst: do you have a way to quickly test apport-gtk under native wayland?
[07:43] <darkxst> pitti, yes
[07:45] <pitti> darkxst: ok, so ATM this crashes on the Gdk bits; do you have a backtrace?
[07:45] <pitti> darkxst: I need to know what/where to intercept, to skip the set_modal_for bits
[07:46] <pitti> darkxst: I suppose Wnck also wouldn't work under wayland
[07:48] <darkxst> pitti, actually it doesnt crash but it probably should
[07:48] <pitti> darkxst: ah, so what happens?
[07:48] <darkxst> am getting an "Error: no display specified" though
[07:49] <pitti> darkxst: something like http://paste.ubuntu.com/10087376/ should be enough, if the actual imports work
[07:54] <darkxst> pitti, yes seems so
[07:54] <pitti> darkxst: great, thanks for testing; committing that then
[07:57] <darkxst> gah, still
[07:57] <darkxst> getting no dispay specified errors after clicking send though
[07:57] <darkxst> even in Xwayland
[08:03] <darkxst> seems like the browser call fails since there is no DISPLAY set
[08:03] <pitti> darkxst: ah, that's from xdg-open?
[08:05] <darkxst> pitti, yes
[08:09] <darkxst> pitti, xdg-open really needs a $DISPLAY
[08:09] <pitti> darkxst: ah, so that one also needs to be fixed for wayland then
[08:11] <darkxst> pitti, yeh looks like it
[08:17] <darkxst> pitti, by why doesnt the try catch the failure and fall back to webbrowser?
[08:17] <darkxst> I suppose it considers the subprocess.call successful?
[08:17] <darkxst> but it shoudn't right?
[08:17] <darkxst> or xdg-open isnt returning proper exit codes?
[08:18] <pitti> darkxst: I suppose xdg-open erroneously returns 0?
[08:20] <darkxst> pitti, yep it does
[08:23] <darkxst> pitti, or its really coming from firefox ;(
[08:26] <pitti> darkxst: does ffox actually work under wayland?
[08:27] <pitti> it's still GTK 2
[08:28] <darkxst> pitti, seems it works under Xwayland, but only when $DISPLAY is set
[08:37] <alkisg> slangasek: good morning, could I ping you about putting an update-manager SRU in precise-proposed, if you happen to have some time today?  https://launchpad.net/ubuntu/precise/+queue?queue_state=1 and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[08:59] <slangasek> alkisg: several of the bugs fixed in this upload are still waiting for the information required by the SRU process
[09:00] <alkisg> slangasek:  ah sorry I didn't realize that, I thought mvo had only uploaded one particular bug I'd reported...
[09:00]  * alkisg as at a loss on how to help with that sru now
[09:00] <alkisg> Split my own bug in a different SRU? Help in the other bug reports that are in the same upload?
[09:10] <slangasek> alkisg: filling out the other SRU bugs with the required information would be a good idea
[09:11] <alkisg> slangasek: thanks, I hope I'll be able to find test cases for them... E.g. "install ubuntu 12.04.4" doesn't sound so quick...
[09:11]  * alkisg tries
[09:11] <pitti> bdmurray: uploaded now
[09:12] <slangasek> alkisg: test cases aren't required to be quick, but correct
[09:12] <alkisg> slangasek: I'll obviously need to do the verification-done step afterwards too though, for 3 bugs that didn't get enough attention from their reporters...
[09:12] <alkisg> It's a bit unfair for me, considering I reported another bug :)
[09:13] <alkisg> I'd prefer it if it was possible to upload an SRU with just my bug fix, but OK I understand the deal
[09:13] <alkisg> I'll try to give all the appropriate feedback for the other bug reports
[09:16] <slangasek> alkisg: then you can talk to the uploader (mvo?)
[09:16] <slangasek> alkisg: talk to him about a reupload without the other changes
[09:17] <alkisg> slangasek: yes, I understand, but of course it'll be more burden for mvo then. I'll see first if I can easily do the SRU steps for the other bug reports.
[09:20] <alkisg> Hmm I think I'll try pinging the reporters as a first step :)
[09:21] <mpt> Help, I’m trying to push an Ubuntu packaging bug fix but Launchpad won’t let me
[09:21] <mpt>  😌 09:19:58@libnotify> bzr push lp:~mpt/libnotify/533631-timeout-doc
[09:21] <mpt> bzr: ERROR: Permission denied: "~mpt/libnotify/533631-timeout-doc/": : Project 'libnotify' does not exist.
[09:21] <mpt>  😠 09:20:21@libnotify> bzr push lp:~mpt/ubuntu/libnotify/533631-timeout-doc
[09:21] <mpt> bzr: ERROR: Invalid url supplied to transport: "lp:~mpt/ubuntu/libnotify/533631-timeout-doc": No such distribution series libnotify.
[09:22] <mpt> I got the branch from lp:ubuntu/libnotify, so why can’t I push to lp:~mpt/ubuntu/libnotify?
[09:29] <mpt> Do I need to specify vivid/?
[09:30] <mvo> slangasek, alkisg: I look at this, in a call right now
[09:30] <Odd_Bloke> mpt: I think I have done so in the past.
[09:31] <seb128> slangasek, hey, what's the status of systemd by default? ;-)
[09:31] <ogra_> mpt, perhaps it gets confused by all the smileys :)
[09:32] <alkisg> 😁
[09:38] <cjwatson> mpt: The namespace for personal source package branches is lp:~OWNER/DISTRIBUTION/DISTROSERIES/SOURCE/BRANCHNAME
[09:38] <cjwatson> mpt: so yes, you must include vivid/
[10:01] <mpt> Ok, that works. Thanks Odd_Bloke, cjwatson
[10:02] <darkxst> pitti, changelog had me a little worried for a sec "Also check for $WAYLAND_SESSION"
[10:03] <darkxst> but the code is ok!
[10:03] <mpt> ogra_, I set that up as an easy way to tell whether the last command succeeded or failed :-) (Only bzr diff messes it up)
[10:13] <cjwatson> Plain "diff" does the same
[10:13] <cjwatson> Interestingly, "git diff" doesn't
[10:14] <cjwatson> Ah, you have to say --exit-code if you want diff-style exit codes
[10:14] <cjwatson> Shocking, I think that's actually a good UI design decision by git
[10:29] <mpt> Human sacrifice … cats and dogs living together … mass hysteria … and good UI decisions in Git
[10:54] <pitti> darkxst: ah, should I have described that differently?
[10:55] <darkxst> pitti, wayland session or  $WAYLAND_SESSIO
[10:55] <darkxst> $WAYLAND_DESKTOP
[10:55] <darkxst> cut and paste fail there
[10:55] <ogra_> $WAYLAND_WAY
[10:55] <darkxst> DISPLAY
[10:55] <ogra_> :)
[10:56] <pitti> darkxst: ah, you mean _DISPLAY instead of _SESSION; fixed in NEWS in bzr
[10:57] <darkxst> pitti, yes exactly
[10:57] <pitti> (and fixed on https://launchpad.net/apport/trunk/2.16)
[10:58] <darkxst> ta
[13:07] <pitti> jdstrand: I'd like to point out bug 1418928
[14:12] <jdstrand> pitti: thanks!
[14:13] <jdstrand> tyhicks: fyi ^
[14:13] <pitti> jdstrand: ah, should I ping tyhicks in the future about security updates?
[14:15] <jdstrand> pitti: either is fine, but typically, yes
[16:13] <zul> mterry:  ping can you have a look at the  libxml-xpath-perl MIR please
[16:13] <smoser> :)
[16:13] <zul> mterry:  its blocking libvirt
[16:43] <Bluefoxicy> sigh
[16:43] <Bluefoxicy> why does every Linux distro install a 200MB /boot?
[16:43] <Bluefoxicy> before you know it, you've got three kernel images installed somehow, and /boot is full
[17:22] <cyphermox> flexiondotorg_: how far how we for reviewing your packages? are you still looking for a second reviewer?
[22:29] <aeoril> darkxst I am looking at github.  I found two mirrors of google mercurial vim.  One is outdated, the other is vim-jp.  How do I know I can trust these mirrors?
[22:32] <aeoril> darkxst is there a way to do a checksum or something on a commit?
[22:33] <darkxst> aeoril, it would just be an autosync repo, should be fine
[22:34] <aeoril> darkxst I wonder why one of the mirror repos is not up to date though?  That is what got me thinking ...
[22:34] <darkxst> not sure you can checksum, both git and mercurial hash commits differently
[22:35] <aeoril> darkxst https://github.com/b4winckler/vim
[22:35] <aeoril> darkxst yes, I see - good point ...
[22:35] <darkxst> idk, autosync can break from time to time I guess
[22:36] <aeoril> darkxst oh well, I will start bisecting on the japanese github mirror repo ...
[22:42] <darkxst> aeoril, ok
[22:59] <aeoril> darkxst what is the best way to figure out the starting/ending commits in the github vim repo based on the lp versions that are in the ubuntu builds?
[22:59] <aeoril> for the bisection
[23:01] <sarnold> easiest is probably to just select one at random from two years ago and the most recent
[23:01] <sarnold> you'll cut off half of them with the third test right in the middle, so there isn't too much reason to optimize finding the first and last ones to work with :)
[23:04] <aeoril> sarnold I feel like I am asking too many dumb questions ... I don't see anyone else doing so ...
[23:04] <sarnold> aeoril: ask away :)
[23:07] <darkxst> aeoril, though don't go back to far, if this used to work pre trusty
[23:07] <darkxst> I would start with first 7.4 commit
[23:10] <aeoril> darkxst sarnold Viewing the trusty revision history, the last revision for release is 57 dated 2010-03-08: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/vim/trusty/changes/57
[23:11] <aeoril> darkxst sarnold wouldn't I just choose that date as a good approximation?  But that is almost 5 years ago ...
[23:12] <sarnold> aeoril: I have no idea what that ubuntu-branches thing is..
[23:12] <aeoril> then, choose the latest and go from there?
[23:12] <aeoril> sarnold really?
[23:12] <sarnold> aeoril: yeah :) I don't think I've seen it before. and 2010 was a looooong time ago. I assume it's a process that predates my involvement.
[23:13] <darkxst> sarnold that is the packaging revisions
[23:13] <darkxst> nothing to do with vim commits
[23:13] <sarnold> aeoril: from this thing you can see that trusty shipped with a 7.4.052-based package: https://launchpad.net/ubuntu/+source/vim
[23:13] <aeoril> sarnold darkxst I got to it from here:  https://code.launchpad.net/ubuntu/+source/vim
[23:13] <aeoril> sarnold lol ok - same link!
[23:14] <darkxst> aeoril, really just start at 'v7-4'
[23:15] <aeoril> darkxst I am just looking around, trying to learn ... sorry if I am asking too many questions ...
[23:16] <aeoril> darkxst where do you see the info that it was v7-4?  I am clicking around and do not see that
[23:17] <darkxst> its a tag
[23:18] <darkxst> aeoril, you should just be able to run git bisect v7-4
[23:18] <darkxst> ^insert bad though
[23:21] <aeoril> darkxst sarnold oh, I was under the code section on launchpad - I see the tag now
[23:21] <aeoril> (launchpad for vim)
[23:21] <darkxst> aeoril, go to your git tree! launchpad is just confusing you!
[23:22] <FOSS_drivers_FTW> Hello
[23:22] <FOSS_drivers_FTW> is there any reason why xserver-xorg-video-ati is still at 7.4.0 in vivid?
[23:22] <FOSS_drivers_FTW> see:
[23:22] <FOSS_drivers_FTW> http://packages.ubuntu.com/vivid/xserver-xorg-video-ati
[23:22] <FOSS_drivers_FTW> Debian already has 7.5.0, see:
[23:23] <FOSS_drivers_FTW> https://packages.debian.org/search?keywords=xserver-xorg-video-ati&searchon=names&suite=all&section=all
[23:23] <FOSS_drivers_FTW> 7.5.0 is the latest version, see:
[23:23] <FOSS_drivers_FTW> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
[23:23] <FOSS_drivers_FTW> so, is there any reason why vivid is still using an old version? why hasn't the latest version been imported from Debian?
[23:29] <aeoril> sarnold darkxst please bear with me - I am trying to understand.  I see on the launchpad site (https://launchpad.net/ubuntu/+source/vim) a line next below "The Trusty Tahr" that says "2:7.4.052-1ubuntu3" ... "release (main)" ... "2014-01-02" - what exactly do those three things mean there? (the version, release(main) and date)?
[23:29] <darkxst> aeoril, 7.4.052 was the upstream version
[23:29] <darkxst> -1ubuntu3 is the ubuntu version
[23:30] <darkxst> the rest doesnt matter
[23:30] <aeoril> what is the 2:?
[23:30] <darkxst> an epoch
[23:30] <darkxst> part of ubuntu version also
[23:30] <darkxst>  7.4.052 is the bit you wanted to know I suspect
[23:34] <darkxst> aeoril, go to your git tree
[23:35] <darkxst> git bisect start
[23:35] <darkxst> git bisect bad v7-4
[23:35] <darkxst> git bisect good
[23:35] <darkxst> then start building!
[23:36] <aeoril> darkxst ok, thanks - but still learning here - give a man a fish, feed him for a day, teach a man to fish, feed him his whole life ... :)
[23:37] <darkxst> aeoril, and 'man git bisect' will give you even better instructions
[23:37] <aeoril> ok, cool - thanks
[23:38] <sarnold> heh, every time I need git manpages I always think of http://git-man-page-generator.lokaltog.net/
[23:38] <darkxst> aeoril, most of the git man pages have nice simple examples
[23:39] <aeoril> darkxst so, to find out I needed to start "bad" at 7-4, you looked at the launchpad page at that 7-4-52 and figured "spitball at 7-4?"
[23:40] <aeoril> darkxst or, did you just go by the date of the trusty release as a rough estimate?
[23:40] <darkxst> first
[23:40] <aeoril> I noticed precise was 7.3 and switched to 7.4 in trusty looking at the launchpad page'
[23:40] <aeoril> darkxst ok, that is the piece of information I was searching for - thanks (I know you already answered it previously, but just checking)
[23:42] <aeoril> darkxst sarnold ok, I'll clone the github repo now and start bisecting - thanks for your patience
[23:42] <brainwash> FOSS_drivers_FTW: it's not automatically synced from debian, because the current ubuntu package has some ubuntu delta
[23:43] <FOSS_drivers_FTW> brainwash: thanks for the reply. so what can be done to make sure it will be synced before Debian Import Freeze?
[23:44] <brainwash> FOSS_drivers_FTW: you could file a report and request that the new version is synced
[23:45] <aeoril> darkxst sarnold do the debian/ubuntu versions always try to include the versioning scheme of the underlying package in their version names?  What if vim had some completely insane version names?
[23:46] <aeoril> here, it really helped us
[23:46] <darkxst> aeoril, versions are always [upstream]-[debian][ubuntuX]
[23:46] <sarnold> is "requestsync" the right tool for that job?
[23:47] <brainwash> FOSS_drivers_FTW: maybe also ask in #ubuntu-x
[23:47] <darkxst> if the ubuntu delta can be dropped it is
[23:47] <sarnold> aeoril: I haven't yet seen a case where the upstream version isn't included; sometimes when projects change their version scheme, the epoch is needed..
[23:48] <aeoril> darkxst upstream means vim here? (7-4-052, for instance)
[23:48] <darkxst> aeoril, yes
[23:48] <darkxst> "-1" is the debian version
[23:48] <darkxst> "ubuntu3" the ubuntu version
[23:49] <aeoril> just about to ask that darkxst
[23:49] <darkxst> sometimes the debian version is "-0" which means the package is not based of a debian revision
[23:49] <aeoril> so we had an epoch change here because of the 2: ?
[23:50] <darkxst> aeoril, the epochs, seem to have come from many years ago
[23:50] <darkxst> but yes at some point (twice) vim must have changed versioning schemes
[23:52] <darkxst> although there are occassions when the epoch's come from packaging changes (not upstream)
[23:55] <aeoril> darkxst ok, cool


 @mitya57 FYI since qtwebengine 5.15.2 internal pdf viewer switched to polymer v3, so v1 can be removed for now and v3 needs to be enabled
 I've been testing it by adding missing source to debian/ folder and it was working. Unfortunately missing-source is an unknown territory to me to provide a correct patch
 Thank you for reporting this! I have to exclude a lot of files because of DFSG, most of the time it is safe but not always, as you can see.
 Can I ask you to file a bug with steps to reproduce, to make it easier for me to fix it for Hirsute? (re @X: @mitya57 FYI since qtwebengine 5.15.2 internal pdf viewer switched to polymer v3, so v1 can be removed for now and v3 needs to be enabled)
 https://bugs.launchpad.net/ubuntu/+source/qtwebengine-opensource-src/+bug/1926089 (re @mitya57: Thank you for reporting this! I have to exclude a lot of files because of DFSG, most of the time it is safe but not always, as you can see.
 Can I ask you to file a bug with steps to reproduce, to make it easier for me to fix it for Hirsute?)
 Thanks a lot!
 No problem