[00:57] <Nafallo> .win 81
[01:30] <bddebian> Heya gang
[01:33] <xtknight> i should be able to publish an update of flashplugin-nonfree on my ppa, shouldn't I?
[01:33] <xtknight> or no?
[01:35] <TheMuso> xtknight: You should yes.
[01:36] <xtknight> TheMuso, thanks.  just fixing bug 214341
[01:36] <ubotu> Launchpad bug 214341 in flashplugin-nonfree "flash plugin md5sum outdated" [Undecided,New] https://launchpad.net/bugs/214341
[01:45] <proppy> oy
[04:11] <LaserJock> hmm, so do we get flashplugin-nonfree part II?
[04:12] <jdong> looks like it
[04:12] <jdong> how many things are incompatible this time?
[04:12] <vorian> :/
[04:12] <superm1> part 2?
[04:12] <superm1> what happened?
[04:12] <jdong> superm1: new flashplugin apparently
[04:13] <superm1> with plugin included in deb by chance?
[04:13] <superm1> or what is deal?
[04:14] <superm1> hm i dont see anything new according to https://edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/
[04:14] <jdong> bug 214341
[04:14] <ubotu> Launchpad bug 214341 in flashplugin-nonfree "flash plugin md5sum outdated" [Undecided,New] https://launchpad.net/bugs/214341
[04:15] <jdong> it's always the md5sum fun.
[04:15] <jdong> we could just not check MD5sums :D
[04:15] <jdong> </bad security joke>
[04:15] <LaserJock> why not?
[04:15] <emgent> argh
[04:15] <LaserJock> it's not like Flash has the best security history or anything ;-)
[04:16] <superm1> well i'd be for maybe presenting a warning
[04:16] <superm1> that they don't match
[04:16] <superm1> and explain what can cause that
[04:16] <jdong> right
[04:16] <superm1> so that people can still proceed
[04:16] <jdong> making dpkg fail in postinst is probably the least elegant solution
[04:16] <superm1> although i'd moreso be for Adobe to put it in the canonical partners repo
[04:16] <superm1> but that's too idealistic
[04:17] <jdong> superm1: yeah and the world would spin a lot better if getdeb packages were reviewed into universe...
[04:17] <jdong> you utopians ;-)
[04:18] <jdong> that should be triaged and set to high importance, no?
[04:18] <jdong> wait xtknight has a debdiff
[04:19] <xtknight> helloooo
[04:19] <xtknight> :0
[04:19] <xtknight> yeah it worked for me at laest
[04:19] <jdong> it looks reasonable
[04:19] <LaserJock> jdong: Fedora's pretty fast. I first noticed the flash thing because I had an update to install
[04:19] <xtknight> we dont need an SRU do we?
[04:19] <LaserJock> then I opened up my email and saw the SRU bug
[04:20] <jdong> xtknight: for gutsy and friends very likely
[04:20] <xtknight> if it's a new flash... flash would be completely broken for everyone, so it's sort of vital to update the md5sums for it unless you're going to change the download link
[04:20] <xtknight> oh that's right gutsy uses it too
[04:20] <jdong> LaserJock: we need a standing SRU, like a volatile setup
[04:21] <LaserJock> jdong: well, as long as Adobe doesn't cause problems it's a pretty straightfoward deal
[04:21] <LaserJock> but I think a standing SRU approval would be a good idea
[04:21] <LaserJock> it's not like we're gonna do a code review
[04:22] <mbt> Does anyone have any ideas on debugging a package that works properly under a debugger (gdb) but not outside of it?  I'm trying to fix a particularly troubling bug (bug 106583) and it works when under GDB, but not outside of it.
[04:22] <ubotu> Launchpad bug 106583 in alltray "No windows hiding with compiz" [Undecided,Confirmed] https://launchpad.net/bugs/106583
[04:22] <jdong> xtknight: I uploaded your debdiff
[04:22] <jdong> thanks for jumping on that one :)
[04:22] <xtknight> oh thanks
[04:22] <xtknight> i'm also wondering why even bother checking the md5sum
[04:22] <LaserJock> but yeah, we need to do something about bailing out of postinst
[04:22] <jdong> xtknight: MITM attack. This would be a root compromise
[04:23] <xtknight> well i mean people are already at risk by using closed source things *shrugs*
[04:23] <jdong> xtknight: that's not quite the same thing
[04:23] <mbt> xtknight, jdong: Wouldn't there be a way to do it in a manner that doesn't require the package being updated every time?  It is a bit annoying the frequency which the md5sum on flash changes.
[04:23] <jdong> xtknight: there still is some "trust" if you call it that in big-names
[04:23] <xtknight> we could download the latest md5sum from ubuntu
[04:23] <jdong> mbt: if adobe GPG signs their flash stuff or provides a SSL/HTTPS download method
[04:23] <LaserJock> mbt: we can't know the md5sums ahead of time
[04:23] <xtknight> or something
[04:24] <mbt> No, but what if the md5sums were checked from an https Ubuntu server with a list?
[04:24] <jdong> xtknight: if we download md5sums from somewhere, then we should just always keep the package updated.
[04:24] <mbt> Using curl or something?
[04:24] <jdong> mbt: ^^
[04:24] <xtknight> if adobe uploaded a .md5sum would that fix it?
[04:24] <jdong> there would be no difference in complexity.
[04:24] <jdong> xtknight: no
[04:24] <jdong> xtknight: what prevents me from spoofing that?
[04:24] <mbt> No, but it wouldn't require the package be rebuilt.
[04:24] <xtknight> hmm
[04:24] <xtknight> true
[04:24] <mbt> SSL signature
[04:24] <jdong> mbt: the package rebuild is probably the least of concerns
[04:24] <jdong> if Adobe would provide a SSL download URL I'd be happy to remove this check.
[04:25] <jdong> but that apparently is not the case
[04:25] <LaserJock> I would be concerned about people getting new software without us knowing about it
[04:25] <xtknight> yea
[04:25] <jdong> honestly adobe+canonical partner is the BEST solution
[04:25] <jdong> LaserJock: +1
[04:25] <crimsun> no
[04:25] <jdong> package fetchers IMO are a bad idea
[04:25] <mbt> jdong: There have been times where there has been considerable lag and many duplicate bugs...
[04:25] <crimsun> remove it completely from the archive
[04:25] <jdong> mbt: indeed, mostly because of the painful procedure currently to get that update in
[04:25] <jdong> mbt: but there's no reason why that cannot be reformed
[04:25] <xtknight> https://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz
[04:25] <xtknight> well this works
[04:25] <xtknight> do you call that secure?
[04:26] <jdong> xtknight: does that actually work? :)
[04:26] <jdong> cool
[04:26] <crimsun> no, it's not "secure"
[04:26] <xtknight> but i dont see why that's any better than http
[04:26] <xtknight> anyone at adobe could still upload a tainted package
[04:26] <crimsun> it's not much better
[04:26] <jdong> if anyone at adobe uploads a tainted package we're all screwed anyway
[04:26] <jdong> </chicken little>
[04:26] <xtknight> not in our current system though
[04:26] <mbt> True enough, but at least it's not MITM if you verify the SSL cert, which is probably the biggest problem downloading it via HTTP.
[04:26] <xtknight> ;)
[04:26] <LaserJock> the problem last time was that Adobe's package broke Konqueror
[04:27] <jdong> is there any attempt for canonical to work with Adobe on this?
[04:27] <LaserJock> it takes us all of a couple hours to get a new package with md5sums to the archives
[04:27] <jdong> I find it hard to believe we can't reach an agreement for flashplayer
[04:27] <crimsun> the real solution to this is to have the browser handle it via a plugin
[04:27] <LaserJock> jdong: well, we had to remove Acrobat Reader completly
[04:27] <xtknight> takes longer to file an SRU for gutsy tho
[04:27] <LaserJock> jdong: my guess is Adobe doesn't really care
[04:28] <LaserJock> xtknight: we can fix that
[04:28] <xtknight> hopefully
[04:28] <jdong> xtknight: that's why I proposed a standing SRU
[04:28] <xtknight> ok.  ive never even heard of that.  but i know what it is now
[04:28] <crimsun> as long as we have this inane package in the archive, it will remain an issue.
[04:28] <mbt> It'd be nice if Adobe were more friendly, to be sure; then it wouldn't be an issue at all, and known-good versions could be kept in the repos.  :-/
[04:29] <xtknight> cant FF download from adobe anyway
[04:29] <jdong> xtknight: on 32-bit
[04:29] <crimsun> we already do nasty things like assume EULA acceptance
[04:29] <xtknight> yea true
[04:29] <LaserJock> I agree with crimsun that Flash should be done via the browser
[04:29] <jdong> LaserJock: well that's the easiest solution for us but isn't htat just skirting the responsibility?
[04:29] <xtknight> FF should make an official plugin wrapper or get nspluginwrapper into the tree
[04:29] <xtknight> for 64bit
[04:30] <LaserJock> jdong: well, not necessarily
[04:30] <xtknight> then there's no use in having the package at all
[04:30] <LaserJock> jdong: I bet Adobe would be much more willing to work with Mozilla than Canonical
[04:30] <jdong> LaserJock: how is it not "this isn't our problem, it's the user's problem now"
[04:30] <mbt> What about canonical putting resources into the free flash players?  Is that happening?  Or are there patent issues there?
[04:30] <jdong> oh that's what you meant
[04:30] <jdong> mbt: haha. free flash player.
[04:30] <jdong> mbt: reimplementing flash from ground up is not a walk in the park
[04:30] <mbt> jdong: Well, it works for some things... just not everything.
[04:31] <crimsun> first, updating this package endlessly is /not/ the solution.
[04:31] <LaserJock> yeah, I'm saying the actual browser that needs flash should maybe handle getting it
[04:31] <jdong> mbt: complexity wise I don't think it's any less nontrivial than implementing java from ground up and look at how long that took
[04:31] <jdong> crimsun: agreed....
[04:31] <jdong> LaserJock: firefox already kinda does that
[04:31] <jdong> LaserJock: before we castrated that ability
[04:31] <Hobbsee> crimsun: throw it out instead?
[04:31] <crimsun> Hobbsee: absolutely.  Make the browser handle it.
[04:31] <LaserJock> yeah, but it wasn't good about plugins
[04:32] <Hobbsee> does it not already?
[04:32] <xtknight> FF is fine on 32bit we just need to fix the 64bit
[04:32] <crimsun> Hobbsee: for some arches and browsers
[04:32] <jdong> Hobbsee: ubufox disables that ability for flashplugin in particular
[04:32] <Hobbsee> oh, meh, 64 bit.
[04:32] <Hobbsee> jdong: tasty.
[04:32] <jdong> yeah :)
[04:32] <jdong> when is a feature not a feature? ;-)
[04:33] <LaserJock> well, can we get ubufox to handle it?
[04:34] <xtknight> what else uses flash? epiphany,etc, do they have methods of d/l'ing it?
[04:34] <LaserJock> no
[04:34] <jdong> I don't see how having ubufox handle it is any less evil than turning off the MD5sum check
[04:35] <xtknight> we dont have to bother w/ updating the package
[04:35] <xtknight> i guess
[04:35] <LaserJock> btw, has anybody got a new package ready to go?
[04:35] <LaserJock> :-)
[04:35] <LaserJock> or did we already do it?
[04:35] <crimsun> it was already uploaded.
[04:36] <LaserJock> yeah, I see it now
[04:36] <LaserJock> did anybody test it?
[04:36] <crimsun> yes
[04:36] <LaserJock> like for konqi problems
[04:36] <crimsun> it works on KDE4's konqueror
[04:36] <crimsun> didn't test KDE3
[04:36] <LaserJock> I guess I was asking if it's been uploaded to -proposed
[04:36] <LaserJock> for the gutsy horde
[04:37] <ajmitch> ah, flash, everyone's friend
[04:37] <LaserJock> ajmitch: oh man, in the edu world it can be particularly exciting
[04:37] <LaserJock> everybody likes doing all their learning content in Flash
[04:38] <LaserJock> then trying to have 30 kids run it over a LTSP server
[04:38] <mbt> heh, does the new version work with libflashsupport without crashing?  :-D
[04:38] <xtknight> well i dont think there's a free equiv to Flash itself
[04:38] <xtknight> some free flash decoders that are half broken, not much more than this
[04:38] <crimsun> mbt: not really.
[04:38] <crimsun> what do you expect?  It's Flash.
[04:38] <LaserJock> :-)
[04:38] <mbt> Yep.
[04:39] <LaserJock> I like it when flash works though
[04:39] <LaserJock> as that's how I got my wife to ditch Windows
[04:39] <mbt> I started using Totem for YouTube with all the ick that is flash
[04:45] <jdong> mbt: that's great for the simple case of a flash video player
[04:45] <mbt> Yeah, but that's about it...
[04:45] <jdong> mbt: too bad flash is a pretty complete JITting language runtime.
[04:47] <LaserJock> ugg, Need to get 210MB of archives.
[04:48] <LaserJock> I sure wish my school didn't decide to mess with their VPN
[04:48] <LaserJock> *hadn't decided
[04:49] <LaserJock> they had a decent setup I could use, now they've got three different access points and none of them work
[04:53] <LaserJock> anybody feeling like doing a gutsy package for flash?
[04:53] <LaserJock> I can ack an SRU for it
[04:54] <mbt> I don't have a gutsy build env right now, since I went and focused on Hardy... been working on Alltray lately
[04:54] <xtknight> i'll try
[04:56] <xtknight> !info flashplayer-nonfree gutsy
[04:56] <ubotu> Package flashplayer-nonfree does not exist in gutsy
[04:56] <xtknight> what's it called on gutsy?
[04:57] <LaserJock> it's the same
[04:58] <LaserJock> !info flashplugin-nonfree gutsy
[04:58] <ubotu> flashplugin-nonfree (source: flashplugin-nonfree): Adobe Flash Player plugin installer. In component multiverse, is optional. Version <IP_ADDRESS>.2+really0ubuntu12.2 (gutsy), package size 17 kB, installed size 156 kB (Only available for i386 amd64 lpia)
[04:58] <xtknight> o plugin
[04:58] <jdong> flashplugin-nonfree | <IP_ADDRESS>.2+really0ubuntu12.2 | gutsy-updates/multiverse | source, amd64, i386
[04:58] <jdong> that's the sucker.
[04:58] <jdong> would it really kill us to put the true version number?
[04:58] <xtknight> we do on hardy
[04:58] <xtknight> not sure why not on gutsy
[04:58] <jdong> right but the SRU policy by default would be bump 12.2 to 12.3
[04:59] <jdong> that's why it's 12.2 right now
[04:59] <jdong> that's actually <IP_ADDRESS>
[04:59] <xtknight> o
[04:59] <jdong> LaserJock: ^^ your opinion on this?
[04:59] <jdong> I personally would say put the real 9.0.124 version number in
[04:59] <jdong> but of course set it less than Hardy by a bit
[05:00] <emgent> launchpad down ?
[05:00] <LaserJock> awesome we have 3 different version conventions for flashplugin-nonfree in -updates
[05:01] <jdong> LaserJock: lol
[05:01] <jdong> <IP_ADDRESS>.0ubuntu11~dapper3
[05:01] <jdong> <IP_ADDRESS>.0ubuntu1~7.04.3
[05:01] <jdong> 7.0.68~ubuntu3
[05:01] <jdong> <IP_ADDRESS>ubuntu5
[05:01] <jdong> more than that.
[05:02] <LaserJock> for goodness sakes
[05:02]  * jdong looks at the feisty and dapper one
[05:02] <jdong> wait...
[05:03] <jdong> isn't dapper a higher version?
[05:03] <LaserJock> it should be
[05:03] <jdong> backports
[05:04] <LaserJock> why isn't it in -updates?
[05:04] <StevenK> The dapper one is higher, according to dpkg
[05:04] <jdong> LaserJock: probably because when it was done, it's not accepted in -updates
[05:04] <jdong> LaserJock: we used to have quite strict policy, remember?
[05:05] <LaserJock> would it kill us to just use the real version?
[05:05] <jdong> that's my sentiments
[05:05] <jdong> let's just use the real version
[05:06] <LaserJock> I think it's more confusing to users looking for the update to see that  <IP_ADDRESS>.2+really0ubuntu12.3 is really <IP_ADDRESS>ubuntu1
[05:08] <xtknight> gutsy-proposed debdiff up. Bug 214341
[05:08] <ubotu> Launchpad bug 214341 in flashplugin-nonfree "flash plugin md5sum outdated" [Undecided,New] https://launchpad.net/bugs/214341
[05:08] <xtknight> tested on i386/firefox only, works fine
[05:09] <xtknight> hold up my bad i uploaded the wrong gutsy one
[05:10] <xtknight> nevermind we're good :)
[05:11] <LaserJock> heh
[05:11] <LaserJock> seems like we should make that version lower than Hardy though for some reason
[05:12] <jdong> *looks*
[05:12] <LaserJock> yeah, we better make it lower
[05:12] <jdong> just put ~gutsy1 on it
[05:13] <jdong> IMO.
[05:13] <LaserJock> if we need to do any updating we'd hate to cause a downgrade when people upgrade
[05:13] <LaserJock> yeah, I agree
[05:13] <xtknight> <IP_ADDRESS>ubuntu1~gutsy1?
[05:15] <LaserJock> that's lower isn't it?
[05:15] <jdong> yeah
[05:15] <xtknight> yup
[05:15]  * LaserJock forgets the magic dpkg --compare-versions incantation
[05:15] <xtknight> well should i do anything or wait for someone else to look at it for final decision?
[05:15] <LaserJock> I would like somebody to check konqi if we can
[05:16] <LaserJock> since that was the problem last time
[05:16] <chapocero> which programming language is the majority of ubuntu development done in?
[05:16] <LaserJock> chapocero: depends on what you mean buy ubuntu development?
[05:16] <xtknight> kernel is C, lot of UI is python
[05:16] <LaserJock> I would say bash
[05:17] <LaserJock> bash/Makefile
[05:17] <LaserJock> :-)
[05:17] <mbt> there is a lot of everything in ubuntu... c, c++, shell, lisp, python, c#...
[05:17] <chapocero> ah, xtknight is the winner i think with the answer i was most looking for.. lol :P
[05:17] <chapocero> thanks all
[05:17] <xtknight> do i get a cookie?
[05:18] <chapocero> hmm... you know i made some... but they didnt turn out so well, so i dont think you really want one
[05:18] <saivann> I'm looking to see if latest flash works with konqueror
[05:18] <LaserJock> chapocero: what are you trying to get at?
[05:18] <xtknight> :p
[05:18] <jdong> chapocero: I like mbt's answer better though...
[05:18] <jdong> chapocero: it'd really help us to understand the purpose of the question
[05:18] <LaserJock> jdong: I liked mine, personally ;-)
[05:18] <jdong> are you interested in contributing to Ubuntu and would like to pick a language to learn?
[05:18] <jdong> or just curiousity?
[05:18] <chapocero> LaserJock, i used to get a little bit in to programming several years ago.. some vb and c++, but most of it was forgotten.. im just trying to get various references on ideas of where i want to pick back up from
[05:18] <LaserJock> saivann: awesome
[05:18] <jdong> technically LaserJock is correct.... in a cheap way.... :)
[05:19] <LaserJock> jdong: dude, "ubuntu development" I'm totally right on :-)
[05:19] <LaserJock> although dash/bash
[05:19] <LaserJock> but still
[05:19] <jdong> LaserJock: pfft I'd say that's debian/copyright :P
[05:19] <jdong> *ducks*
[05:19] <LaserJock> hah
[05:20] <LaserJock> chapocero: boy, sky's the limit
[05:20] <jdong> LaserJock: haha speaking of satire, you might get a kick out of my boredom earlier in the day: https://wiki.ubuntu.com/JohnDong/FFeRejectionForm
[05:20] <jdong> (the only problem is that it'll probably be used against me some day :D)
[05:20] <LaserJock> C/C++/Ruby/Python are probably some of the most common
[05:21] <saivann> LaserJock : ERROR: Your architecture, \'x86_64\', is not supported by the
[05:21] <saivann>        Adobe Flash Player installer.
[05:21] <LaserJock> jdong: I saw that in -devel earlier
[05:21] <saivann> LaserJock : I don't think that the old installer had this warning about 64 bit
[05:21] <LaserJock> saivann: did it die?
[05:21] <saivann> LaserJock : yes
[05:21] <xtknight> huh
[05:21] <LaserJock> those cheeky buggers
[05:21] <jdong> AAh! regression! lock the doors! Engage protocol C-A-1-6-0!
[05:22] <xtknight> lol
[05:22] <superm1> so really why not at least put a warning in to let users pass by the md5 failing?
[05:22] <saivann> LaserJock : --help does not give any outputs..
[05:22] <LaserJock> jdong: that's CHARLIE-ALPHA-ONE-SIX-ZERO
[05:22] <xtknight> saivann, yes the flash player has had the warning about 64
[05:22] <chapocero> well i hope to bone up on some of the things ive forgotten and/or missed out on as far as useful programming languages before i start resuming my college career... but once i get a bit better foundation i hope to do what i can to contribute... i think im going to look in to some C or python
[05:22] <superm1> it would lower the priority of these SRU sprints to get it updated across releases
[05:22] <xtknight> saivann, you must run with linux32 if you use install-flash-player.  however the debian package doesnt
[05:22] <LaserJock> chapocero: those would be excellent choices
[05:23] <LaserJock> they can get you around a heck of a lot of code
[05:23] <saivann> xtknight : Ok thanks, I will now try on a x86 hardy
[05:23] <xtknight> saivann, wait were you trying the flashplugin-nonfree package or flash off adobe.com?
[05:23] <saivann> xtknight : flash from adobe, of course
[05:23] <xtknight> saivann, i mean "linux32 ./install-flash-player"
[05:24] <xtknight> run linux32 on a 64bit machine but, you must use nspluginwrapper also
[05:24] <xtknight> i think they meant for you to try the package
[05:24] <jdong> yeah, the package is what we're concerned about at the moment
[05:24] <jdong> don't scare us like that!
[05:26] <saivann> xtknight : is /usr/lib/mozilla the good place for firefox 3.0 ?
[05:27] <LaserJock> xulrunner-addons I think
[05:27] <LaserJock> though it may not make a difference
[05:28] <xtknight> saivann, hey sorry for this misunderstanding.
[05:28] <xtknight> can you download the flashplugin-nonfree packages here https://launchpad.net/~xt-knight/+archive
[05:28] <xtknight> amd64: http://launchpadlibrarian.net/13268638/flashplugin-nonfree_<IP_ADDRESS>ubuntu1%7Eppa2_amd64.deb
[05:28] <jdong> LaserJock is right
[05:28] <saivann> xtknight : Why not :) thanks
[05:28] <jdong> though symlinks idiotproof it
[05:29] <saivann> xtknight : Sorry? np here :)
[05:29] <xtknight> saivann, oh yeah basically we just didn't want you using install flash because the pakcage is what we need tested.  and package makes it easier for you
[05:29] <LaserJock> xtknight: I'm going to make bug #214341 a dup of bug ##173890
[05:29] <ubotu> Launchpad bug 214341 in flashplugin-nonfree "flash plugin md5sum outdated" [Undecided,New] https://launchpad.net/bugs/214341
[05:30] <saivann> xtknight : I though the flash player installer was less "manual", I also think like you
[05:30] <LaserJock> bah, screwed that one
[05:30] <xtknight> Bug 214130 too
[05:30] <ubotu> Launchpad bug 214130 in flashplugin-nonfree "flashplugin-nonfree mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/214130
[05:32] <saivann> xtknight, LaserJock : Tested 4 sites with flash in Hardy with konqueror and latest flash plugin from xtknight PPA and it works flawlessly
[05:32] <xtknight> saivann, nice. thanks for taking the time
[05:33] <saivann> xtknight : Thanks for your instructions :)
[05:33] <LaserJock> saivann: is that KDE4 konqi?
[05:34] <saivann> LaserJock : no, I'll test KDE4 konqueror in 2 seconds
[05:34] <LaserJock> that's ok
[05:34] <LaserJock> crimsun tested it
[05:34] <saivann> LaserJock : A nice :)
[05:34] <saivann> Sounds like we'll not need to wait a very long time before updating flash-plugin this time!
[05:41] <saivann> LaserJock xtknight : Tested two times konqueror for KDE4, does not work. Konqueror freeze when I go on youtube.com. Flash is properly detected by nsplugin but does not seem to works when surfing on flash sites
[05:41] <saivann> Instead of flash content, I get grey areas
[05:41] <xtknight> hmmm
[05:42] <xtknight> yeah ive always gotten that a lot even with the old plugin :(
[05:42] <xtknight> but it happenedin FF for me
[05:43] <saivann> mmh, firefox and konqueror works flawlessly, but konqueror for KDE4 does not work yet.
[05:44] <xtknight> interesting
[05:44] <xtknight> saivann, do you know if KDE4 konqi works with the old flash?
[05:45] <saivann> xtknight : I don't know, sorry
[05:48] <xtknight> but it worked for crimsun i think
[05:49] <saivann> xtknight : Maybe that I have some missing depends.. I tested this in ubuntu but not kubuntu with whole kde4 installed
[05:57] <saivann> xtknight, LaserJock : Also successfully testing in Gutsy, konqueror with nsplugins works correctly with latest flash, and also firefox 2
[05:58] <xtknight> saivann, i'm thinking the kde4 problem is due to nspluginwrapper or something.  maybe konq uses a different plugin folder than FF?
[05:59] <xtknight> seems like that should be another bug to me, at least, if it is indeed a problem
[06:00] <saivann> xtknight : Actually, it looks like konqueror and konqueror for KDE4 looks in the same Firefox folders to find flash plugin
[06:02] <saivann> xtknight : It really looks like a nspluginwrapper issue to me, yes.. but I don't know where is the problem since nsplugins search in the same folders and find the same plugins
[06:03] <xtknight> saivann, maybe running kde4 konq in the terminal would reveal something
[06:03] <saivann> xtknight : That's a good idea
[06:03] <xtknight> saivann, ive had flash go gray in FF with multiple windows open and stuff
[06:03] <saivann> xtknight : old or new flash plugin?
[06:03] <xtknight> old
[06:04] <xtknight> probably new too
[06:04] <xtknight> seems to have happened forever
[06:04] <saivann> xtknight : Seriously? That's the first time that it happens to me yet
[06:04] <xtknight> saivann, yeah.  i reboot FF and it works again
[06:04] <xtknight> it happens when multiple instances of nsplugin start and somehow it gets all messed
[06:04] <xtknight> segfaults and grays out all the flash areas
[06:04] <LaserJock> ok, I'm gonna upload xtknight's package to gutsy-proposed
[06:04] <xtknight> does flashplugin-nonfree even call nspluginwrapper when it installs?
[06:05] <saivann> xtknight : In my case, rebooting konqueror does not help, also I got a grey windows with "nspluginwrapper" in the title
[06:05] <xtknight> ah
[06:05] <xtknight> ok i guess nsplugin is called.  so that should not be the problem.
[06:06] <xtknight> saivann, did you find anything from the terminal output?
[06:07] <saivann> xtknight : I'm still searching the good command to start konqueror, it's not konqueror-kde4..
[06:07] <xtknight> maybe /usr/bin/kde4/konqueror or similar i dunno
[06:07] <xtknight> possibly opt , lib..
[06:08] <saivann> hehe /usr/lib/kde4/bin/konqueror
[06:08] <xtknight>  /usr/lib/kde4/bin/konqueror
[06:08] <xtknight> yeah
[06:08] <xtknight> beat me
[06:08] <saivann> ;)
[06:09] <saivann> yes I get relevant outputs
[06:10] <saivann> http://paste.ubuntu-nl.org/62600/
[06:10] <LaserJock> and it's off!
[06:10] <LaserJock> xtknight: good work
[06:10] <xtknight> thx
[06:10] <saivann> The program 'npviewer.bin' received an X Window System error.
[06:10] <xtknight> saivann, run "sudo ldconfig"
[06:10] <xtknight> looks like you've got other lib errors but i dont know if those are normal
[06:11] <xtknight> saivann, interesting.  you might need to a file bug for konqueror-kde4<> nspluginwrapper
[06:11] <xtknight> doesnt seem like the new flash caused it though
[06:11] <LaserJock> Hobbsee: do you have powers to accept packages into -proposed?
[06:11] <xtknight> maybe crim had 32bit thats why
[06:11] <saivann> xtknight : Even after running "sudo ldconfig" and restarting konqueror, does not change anything yet
[06:12] <jdong> LaserJock: I believe she went off to uni
[06:12] <saivann> xtknight : That would make sense
[06:12] <LaserJock> pfft
[06:12] <LaserJock> school
[06:13] <LaserJock> speaking of that
[06:13] <LaserJock> I have a meeting with my advisor tomorrow and I'm nowhere near ready
[06:13] <LaserJock> so I best be off for tonight
[06:14] <saivann> xtknight : I'm installing this in hardy 32bit just to see
[06:14] <xtknight> saivann, you're one of the most determined/dedicated testers i've seen :p
[06:15] <saivann> xtknight : Haha, I take it as a compliment :)
[06:15] <xtknight> i am obsessive in my own ways
[06:15] <saivann> xtknight : ^^
[06:15] <xtknight> and i probably dont test things enough :p
[06:15] <xtknight> i often end up posting three times to my ppa
[06:16] <StevenK> Better than that than three times to the archive :-)
[06:16] <saivann> xtknight : I'm addicted to test and I love to find explanations :)
[06:16] <xtknight> hehe
[06:17] <saivann> :P
[06:18] <Hobbsee> LaserJock: don't thin so
[06:24] <saivann> xtknight : It works with 32bit!
[06:24] <xtknight> cool
[06:24] <saivann> xtknight : for which package should I post a bug about that, in your opinion?
[06:24] <xtknight> saivann, for now leave it unassigned to any particular patch
[06:24] <xtknight> i mean package
[06:24] <xtknight> just ubuntu
[06:25] <saivann> xtknight : Ok, thanks
[06:27] <xtknight> saivann, if you want to go a step further you can get some people to confirm it
[06:27] <xtknight> otherwise could just be something broken on your machine, i dunno
[06:27] <xtknight> unlikely though
[06:27] <saivann> xtknight : Maybe people from #ubuntu-testing?
[06:27] <xtknight> i didnt even know about that channel
[06:28] <saivann> xtknight.. Yes, well I think that it's not a good idea. Perhaps that I can open the bug and then ask people to reproduce?
[06:28] <xtknight> saivann, well yeah that sounds good to me
[06:28] <xtknight> doesnt matter who it is, can be anybody :)
[06:28] <TheMuso> Anybody got an idea of whats wrong with this? http://www.themuso.id.au/ubuntu/vlc_0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu3_20080409-1435
[06:28] <saivann> xtknight : Great
[06:32] <StevenK> TheMuso: Looking
[06:32] <xtknight> TheMuso, i dont know im assuming youve seen this? http://ramblings.narrabilis.com/wp/vlc-build-for-rhel5/
[06:32] <TheMuso> xtknight: No, looking.
[06:32] <xtknight> could be gcc versions
[06:33] <xtknight> one might define the function implicitly
[06:33] <Hobbsee> TheMuso: you clearly did something bad in a past life.
[06:33] <TheMuso> Hobbsee: Oh yeah. Just pulled a package down that built successfully last time, did a tweak within the debian dir, adding a dep to a binary package and changelog bits, and tried to rebuild.
[06:34] <Hobbsee> TheMuso: strange.
[06:34] <TheMuso> Hobbsee: Indeed.
[06:35] <RAOF> I'd be wondering two things: (1) why that's a size_t _reference_, and (2) why it's not getting implicitly upconverted to a long long int.
[06:36] <StevenK> It could be a size_t deref'd pointer.
[06:37] <StevenK> Why they wouldn't just pass a size_t is beyond me
[06:37] <TheMuso> StevenK: As I said above, no actual code changes since last upload and that previous one worked.
[06:37] <StevenK> TheMuso: Which means something in the toolchain it's using has changed
[06:38] <xtknight> prolly gcc
[06:38] <TheMuso> StevenK: My thought exactly.
[06:38] <TheMuso> Well its a .cpp file,.
[06:39] <TheMuso> xtknight: The link you posted has a solution, but it sounds hacky to me.
[06:39] <xtknight> i think the people upstream should just make it work with whatever gcc ubuntu has now.  more strict casting or w/e is needed
[06:39] <xtknight> g++
[06:40] <xtknight> rhel5 obviously doesnt work either
[06:56] <TheMuso> So... Should I do that hack? I'd rather not...
[07:00] <xtknight> no idea
[07:05] <RAOF> Yeah, that's a bit of a hack.  It's probably meant to be from <algorithms> or something.
[07:10] <RAOF> TheMuso: Man, I'm a C++ god.  It _is_ meant to come from <algorithm>.  I suppose that they're 'using std;' at some point?
[07:11] <dholbach> good morning
[07:11] <bluefoxicy> I'm bored.
[07:11] <RAOF> bluefoxicy: Kindly finish nv40 gallium, then.
[07:11] <bluefoxicy> dholbach:  Piss of keybuk again so I can watch him spend 15 minutes demonstrating how to effectively convey his feelings with a vocabulary composed 95% of swear words :)
[07:12] <TheMuso> RAOF: Haven't checked yet, am about to head into a meeting. Will check later.
[07:12] <RAOF> Heh.  'You often need to do some string processing in C++.  This indicates that you've chosen the wrong language'.
[07:12] <dholbach> bluefoxicy: what are you talking about? where did I piss off Keybuk?
[07:12] <bluefoxicy> ROFL!
[07:13] <bluefoxicy> dholbach:  oh, it was like a year and a half ago, something about openoffice.org build-deps.  I just felt like I should bring it up once in a while but never really got around to it.
[07:13] <TheMuso>   /c
[07:13] <bluefoxicy> anyway I'm going to sleep.  I'm even more disruptive when drowsy.
[07:13] <dholbach> bluefoxicy: I never uploaded anything related to bluefoxicy
[07:13] <dholbach> to openoffice
[07:13] <bluefoxicy> You seem drowsy too.
[07:14] <dholbach> I just got up
[07:14] <warp10> Good morning
[08:31]  * Hobbsee headdesks
[08:31] <Hobbsee> why do the non-computer savvy people realise they're giving out viruses, but the computer-savvy people don't?
[08:32] <_ruben> they're too smart to do so
[08:33] <StevenK> Hah
[09:05] <DarkMageZ> Hobbsee, "compter-savvy" people think they're awesome and that they'd never fall victim to it. while others will either be completely ignorant or show worry that it could be happening.
[09:07] <DarkMageZ> there was a kid in my class accidentally infecting every removable hard-drive with his usb stick. he somehow didn't manage to think that he was doing it.
[09:08] <Hobbsee> tasty.
[09:12] <DarkMageZ> he had a virus that would make the machine shutdown when you tried to do anything that could destory it... like run command prompt. this was on hard-drives for cisco class. so no ping :'(
[09:19] <\sh> ScottK, you got the fix for wine from yesterday?
[09:22] <slytherin> DarkMageZ: that is an old one. I have seen that virus at least 1 year ago.
[09:22] <DarkMageZ> slytherin, no anti-virus in this environment cause we should all be competent.
[09:23] <slytherin> :-D
[09:25] <slytherin> DarkMageZ: actually that virus specifically reboots the machine when you open command prompt. I don't remember the solution but see if running 'command' instead of 'cmd' makes a difference.
[09:25] <DarkMageZ> oh, this one has other triggers like regedit and other things
[09:26] <slytherin> DarkMageZ: may be it is a variant
[09:26] <DarkMageZ> meh, either way. not my problem. i boot into a ubuntu live cd anyways.
[11:06] <mok0> dholbach: ping
[11:07] <dholbach> mok0: pong
[11:08] <mok0> dholbach: hi, dholbach, I have a few troubles with 5-a-day
[11:08] <dholbach> mok0: fire away
[11:08] <mok0> dholbach: hang on, I need to find it first :-)
[11:09] <mok0> dholbach: in files.py, you need to import os
[11:09] <mok0> dholbach: otherwise it wont find os.syserr
[11:10] <mok0> dholbach: sorry, it's SYS
[11:10] <mok0> dholbach: sys.stderr
[11:10] <dholbach> mok0: I have the fix queued up, will upload in after I've checked some other things
[11:11] <dholbach> s/in/it
[11:11] <mok0> dholbach: second, when I tried to register bugs yesterday, it kept on telling me to use --add on the first few bugs
[11:11] <dholbach> erm.....
[11:11] <mok0> dholbach: but that was what I was doing...
[11:12] <dholbach> can you paste me what the command line output?
[11:13] <DktrKranz2> mh... z88dk should not be available for amd64 and ia64, but it keeps building. Any clue on how to exclude it for these ports?
[11:13] <mok0> dholbach: ok, 2 secs
[11:13] <dholbach> mok0: gracias
[11:13] <Hobbsee> RAOF: so, why is gnome-do terrified of openoffice?
[11:13] <mok0> dholbach: I haven't got a bug # from today yet
[11:13] <dholbach> mok0: just give it 123456 - I can remove that from bzr afterwards
[11:14] <mok0> 5-a-day --add 123456 gives
[11:14] <mok0> You need to use  5-a-day --add  first to add a few bug reports to your list.
[11:14] <mok0> :-)
[11:14] <dholbach> erm
[11:17] <mok0> dholbach: Ah, I see you have an LP project for 5-a-day, so I could've reported it there
[11:17] <dholbach> mok0: thanks for reporting it at all - I don't mind IRC :)
[11:27] <TheMuso> RAOF: re vlc and your comment earlier, they have using namespace std, so I don't know what you were referring to.
[11:51] <dholbach> mok0: did you ever successfully use 5-a-day?
[11:52] <dholbach> mok0: what does    cat ~/.5-a-day   say?
[12:09] <mok0> dholbach: @12:51: no
[12:09] <mok0> dholbach: @12:52: mok0
[12:23] <dholbach> mok0: OK, found it - fixing it
[12:23] <mok0> dholbach: hey  cool
[12:37] <stani> pochu: are you there?
[12:40] <dholbach> mok0: I updated it with the fix: can you check http://daniel.holba.ch/temp/five-a-day_0.26_all.deb (and http://daniel.holba.ch/temp/five-a-day-applet_0.26_all.deb if you use that) and see if that fixes the problem?
[12:40] <mok0> dholbach: sure, will do right away
[12:43] <stani> I've added a patch to Bug #214539 which fixes it. Can someone upload it (pochu, ScottK, POX_, ...)?
[12:43] <ubotu> Launchpad bug 214539 in phatch "Phatch is unusable for specific themes" [Critical,Fix committed] https://launchpad.net/bugs/214539
[12:44] <pochu> stani: yes
[12:45] <pochu> stani: I didn't know you used Launchpad for Phatch :)
[12:45] <stani> pochu: thanks
[12:45] <pochu> stani: you know, I know write phatch instead of patch sometimes ;)
[12:46] <stani> pochu: Well spe was started before Ubuntu was born. For Phatch I decided to go for what is most friendly to my main distro (launchpad+bzr).
[12:46] <stani> pochu: Haha, that is also what I like about the name: Phatch patches your photos.
[12:50] <mok0> dholbach: I get an exception
[12:50] <stani> pochu: BTW, the phatch repository is up and running in PPA ;-) Thanks a lot.
[12:51] <RainCT> Hi
[12:51] <mok0> dholbach: http://paste.ubuntu.com/6662/
[12:51] <mok0> dholbach: making the directory now
[12:51] <pochu> stani: cool :)
[12:52] <dholbach> mok0: the directory does not exist?
[12:52] <pochu> stani: uploading. POX_: I've based phatch in the Debian package, including a patch to fix themes
[12:52] <mok0> dholbach: no
[12:52] <dholbach> mok0: hang on then
[12:52] <mok0> dholbach: I created it, and got another exception
[12:52] <dholbach> yes
[12:52] <pochu> stani: if you want me, I can include this patch in Debian... it's trivial to do so
[12:53] <mok0> dholbach:  http://paste.ubuntu.com/6663/
[12:53] <stani> pochu: ok, you can do so. But after Hardy release, I will release Phatch 0.1.4 which includes this patch. Besides Debian and Ubuntu Phatch is also available on ArchLinux. So I want them to get it too.
[12:54] <stani> pochu: do you have some time to chat about the SPE PPA? (here on in #heya)
[12:56] <pochu> stani: yes, but I may be a bit slow to speak... let's join there
[12:57] <POX_> pochu, stani: I will be home in 4 or 5 hours
[12:57] <POX_> I will upload it then
[12:57] <stani> POX_: Thanks.
[12:58] <POX_> (if I upload it now, it will still have to wait for dinstall)
[12:58] <pochu> POX_: ok, I'm including the patch in svn
[13:02] <dholbach> mok0: I uploaded a new version. could you remove the directory you created and try with the new version again?
[13:03]  * dholbach hopes it works for real now, ugh
[13:03] <mok0> dholbach: on your ppa?
[13:03] <mok0> dholbach: ... or using the same URI's from before?
[13:03] <dholbach> mok0: no on http://daniel.holba.ch/temp/
[13:03] <mok0> dholbach: ok
[13:03] <dholbach> gracias mok0
[13:03] <mok0> dholbach: glad to be able to help!
[13:05] <dholbach> I refactored the code in the last version, seems like I optimised a few safety checks away :/
[13:06] <dholbach> test driven development...... one day
[13:06] <mok0> dholbach: I deleted the directory .5-a-day-data, and I still get an exception
[13:06] <mok0>  File "/usr/lib/python2.5/site-packages/fiveaday/files.py", line 107, in add
[13:06] <mok0>     f = open(log_file(), "a")
[13:07] <dholbach> erm... maybe I didn't upload the right .deb - hang on
[13:08] <mok0> dholbach: it was version 0.26
[13:08] <dholbach> yeah, I didn't bump the version, just rebuilt the package with new code - could be I uploaded the wrong one
[13:09] <dholbach> can you download the .deb again (this time it should be the right one)
[13:10] <mok0> dholbach: ok, hang on
[13:10] <dholbach> sorry
[13:11] <mok0> dholbach: still getting exception
[13:11] <dholbach> argh
[13:12] <mok0> dholbach: same as above, line 107
[13:13] <dholbach> this is my line 107:
[13:13] <dholbach>                        return 106 #106: bug has already been added today
[13:13] <mok0> dholbach: checking...
[13:13] <dholbach> I just downloaded the .deb - maybe it was proxied or something
[13:13] <mok0> dholbach: I used wget
[13:13] <dholbach> 591d29a5eeb9ae7b621f0026ed678631  five-a-day_0.26_all.deb
[13:13] <dholbach> this is the md5sum of the .deb I downloaded myself
[13:14] <mok0> dholbach: nope, that's not the one I have...
[13:14] <mok0> dholbach: now I have it
[13:14] <dholbach> ROCK
[13:15] <mok0> dholbach: it's doing something
[13:15] <dholbach> woohoo
[13:15]  * dholbach hugs mok0
[13:15] <mok0> {{{ dholbach }}}
[13:15] <dholbach> :-)
[13:16] <mok0> dholbach: ... how long is it supposed to work?
[13:16]  * mok0 hopes it's not just hanging...
[13:16] <dholbach> no
[13:16] <dholbach> 5-a-day stores all the submitted bugs in bzr, so it'll get the branch now, then add your submitted bugs to it
[13:17] <dholbach> if you run ps afxvw, you will notice that bzr is doing its thing
[13:17] <mok0> dholbach: yikes  is it copying the entire bug db?
[13:17] <mok0> :)
[13:17] <dholbach> no :-)
[13:18]  * dholbach uploads to PPA
[13:18] <dholbach> thanks again mok0
[13:18] <dholbach> you ROCK
[13:18] <mok0> dholbach: ah, committed now. Very advanced syststem
[13:18] <mok0> dholbach: you too
[13:18] <dholbach> mok0: we used the same in bughelper (for the bug clues), it worked quite well :)
[13:18] <mok0> dholbach: can I add yesterday's bugs?
[13:19] <dholbach> sure
[13:20]  * dholbach -> dogwalk
[13:27] <ScottK> \sh: No.  No one gave me a debdiff for wine, AFAIK.  I know it's a simple change but may available mental bandwidth is very limited right now.
[13:28] <\sh> ScottK, you need to change the build-dep of "libgif-dev|libungif-dev" to "libungif-dev" just for the gutsy backport
[13:28] <ScottK> OK.
[13:28] <\sh> ScottK, which means wine backport needs a small change sourceful upload
[13:29] <ScottK> I can do that.
[13:29] <ScottK> Do I want .58 again or try with .59?
[13:29] <\sh> ScottK, we had this problem before, you remember? it was because fontforge was clashing with libgif (for I don't know what reason)
[13:29] <ScottK> I do vaguely remember.
[13:29] <ScottK> I was hoping you and Scott had solved it somehow.
[13:30] <\sh> ScottK, i missed the wine .59 upload..so I would say go with what scott uploaded yesterday :)
[13:30] <ScottK> K
[13:31] <jdong> ScottK: let's look at .59 for wine
[13:31] <\sh> oh man...I have such a horrible setup for a server now....
[13:32] <jdong> ScottK: would it hurt anything to flip to the b-d in universe then backport?
[13:32] <ScottK> jdong: We want to prefer libgif for the future, so I think that would be wrong.
[13:32] <\sh> jdong, yes it will hurt
[13:32] <jdong> I see
[13:32] <\sh> jdong, libungif is gone since hardy
[13:33] <\sh> jdong, so we need to go with libgif
[13:33] <\sh> jdong, but for gutsy it's different
[13:33] <jdong> ok let's do a sourceful backport of .59 though
[13:33] <ScottK> jdong: Just give it a spin and make sure it works.  I'll do a sourceful backport.
[13:33] <ScottK> I'm leaving town tomorrow AM, so it needs to be today.
[13:33] <\sh> jdong, just wait until this evening...I have to reintroduce the lpia changes
[13:33] <jdong> cool! ScottK is telling me to play Starcraft.... IMMEDIATELY....
[13:33] <ScottK> Sounds like a useful stress test case.
[13:34] <ScottK> jdong: YokoZar said iTunes works on .59 too.
[13:34] <jdong> :)
[13:34] <\sh> anyways.../me goes back to 7TB serevr
[13:47] <zul> jdong: slacker..
[13:48] <jdong> zul: between studying for a number theory test and playing starcraft, which would YOU choose ;-)
[13:48] <jdong> too bad I have to study waiting for it to compile
[13:50] <zul> jdong: well being the geek that I am obviously the number theory ;)
[14:06] <mok0> when builds are done in the build queue, how long before they appear in the archive?
[14:07] <Hobbsee> depends on how far through the publisher it is, but between 30 mins and an hour, iirc.
[14:07]  * persia thinks it is between 42 and 99 minutes
[14:09]  * cody-somerville doesn't think persia is being facetious either.
[14:10] <persia> Nope.  The difference between my guess and Hobbsee's is that I think there is a delay cycle between the thing that copies from built to accepted before the publisher runs, although there could have been internal improvements since I last asked lots of questions (October).
[14:10] <persia> s/before/and/
[14:14] <Hobbsee> evening mdomsch
[14:14] <mdomsch> good day Hobbsee
[14:15] <Hobbsee> persia: there have been improvements, and i don't think it's just for ppa
[14:15] <mdomsch> see my blog this morning - I was hanging out with some ubuntu/canonical folks last night
[14:15] <Hobbsee> mdomsch: ready for hardy freeze?
[14:15] <mdomsch> Hobbsee, I trust superm1 has it under control :-)
[14:15]  * persia defers to Hobbsee, who pays more attention to these things, but suspects that 43 minutes is still a likely minimum
[14:15] <Hobbsee> ah yes, that's right.
[14:16] <Hobbsee> persia: i'm no soyuz expert.  It was too frustrating.
[14:17] <persia> heh
[14:17] <Hobbsee> persia: Fujitsu is the resident expert.
[14:17] <Hobbsee> mdomsch: where is your blog?
[14:17] <persia> mok0: There's your pointer :)
[14:18] <Hobbsee> oh, found it.
[14:18] <cpro1> guys, for PRIMARY archive, everything built by :03 will be in the archive by :55
[14:18]  * mdomsch ribs rtg for not having sent patches sooner, but hey
[14:18] <Hobbsee> cpro1: ahh, thanks.
[14:18] <persia> cpro1: 52 minutes?  Is there ever a case when it happens in less time?
[14:18] <mok0> persia: thanks :-)
[14:19] <cpro1> for PPAs everything built by :00, :20, :40 will be in the archive within 2 minutes.
[14:19]  * persia calculates that as 52 minutes to 111 minutes
[14:19] <Mez> \sh ping
[14:19] <\sh> Mez, yepp
[14:19] <Mez> \sh, you were the sponsor for php5-xdebug ?
[14:20] <\sh> Mez, yepp
[14:20] <\sh> Mez, if you hit by the "different path names for config" bug
[14:20] <\sh> Mez, please kick php uploader ,->
[14:20] <Mez> \sh .... ooh, havent spotted that bug yet... got a link?
[14:21]  * Mez is actually working on the debian package
[14:21] <cprov> persia, correct.
[14:21] <\sh> Mez, no...php5 on i386 has -lfs suffix for module dir, and amd64 not
[14:21] <persia> cprov: Any chance of the PPA speedup happening for the main archive in the June release, or is the volume just too high?
[14:22] <Mez> I was just reading through the ubuntu's package code and was wondering if the guy who wrote it supplied painkillers for the headache (and wondered why you didnt just suggest a lintian override for the config.guess and config.sub thing - as client isnt built!)
[14:22] <Mez> \sh, the code for php5-xdebug shouldnt hit that, as I beleive it uses the proper api placement from php-config5 ?
[14:22] <slytherin> persia: long time no see.
[14:22] <persia> slytherin: Just quiet :)
[14:23] <slytherin> :-)
[14:23] <\sh> Mez, yeah, php-config5 provides different dir names actually...so having the config file for php I had to do a terrible workaround ;)
[14:23] <cprov> persia: zero chance, primary archive publication is more complex than PPAs, sorry. We are struggling to keep it hourly 100 % of the time.
[14:23] <Mez> \sh, hehe... yeah, may be terrible, but it works
[14:23] <persia> cprov: Understood.  Thanks :)
[14:23] <cprov> post 2.0 (en of July), maybe ;)
[14:24] <Mez> \sh, I will however, point you to an issue with the package that WILL cause problems (as the maintainer of XDebug told me
[14:24] <Mez> \sh, CFLAGS = -02 will cause problems, it needs to be set to -00
[14:24] <Mez> \sh, can cause a segfaiult
[14:25] <Mez> From email: I checked this, and it seems -O2 is used in non-debug mode. Please do
[14:25] <Mez> not do that, as there's some optimization that mess up things and cause
[14:25] <Mez> a segfault.
[14:26] <\sh> Mez, not here.
[14:26] <Mez> \sh, actually I'll quickly fix that in the ubuntu package.
[14:26] <\sh> Mez, I have it running on amd64 and i386
[14:26] <Mez> \sh, that may be so. But you have to respect the person who created it when they say it can cause a segfault
[14:27] <\sh> Mez, sure...does he know how to create this situation?
[14:27] <Mez> one sec
 no, not anymore
 it could be a specific GCC issue
 I couldn't find *what* it was either
[14:28] <\sh> grmpf
[14:29] <Mez> yeah, I know
[14:29] <\sh> it would be good to know which gcc he was using (gcc 4.2 or 4.3) and actually he should fix it,-)
[14:29] <\sh> well, anyways, please do as you wish :) if -O0 is better then -O2 let's change it
[14:30] <persia> Might be a symbol-not-found issue if it compares code to stacktraces.  It might lose track if the line of code under consideration was optimised away (or at least that is one of the things that causes me to interrupt when manually chasing stacktraces).
[14:36] <ScottK> Hobbsee: I think this is the blog mdomsch was referring to http://direct2dell.com/members/Matt_5F00_Domsch.aspx
[14:37] <Hobbsee> ScottK: thanks.  i said i found it, though
[14:38] <ScottK> Ah.  Missed that.  Sorry.
[14:41] <Hobbsee> jp
[14:41] <Hobbsee> * np
[15:07]  * sebner is of the opinion that \sh should consider writing better changelog entries :P
[15:07] <\sh> hmm?
[15:08] <\sh> sebner, or better "hae?" :)
[15:09] <sebner> \sh: better changelog entries :)
[15:09] <\sh> sebner, example?
[15:09] <sebner> \sh: https://edge.launchpad.net/ubuntu/+source/athcool  <-- "- Added zlib1g-dev to build-deps
[15:09] <sebner> " But *why* ;)
[15:10] <\sh> sebner, it's written there
[15:10] <\sh>  * Patched Makefile to link against zlib (added -lz)
[15:10] <\sh> and for zlib you need what in b-d? :)
[15:10] <\sh> and it's damn old
[15:11] <mok0> I need a hard-core MOTU to take a look at bug 110613
[15:11] <sebner> \sh: möhh. Nevermind then ^^ but debianfixed the -lz issue without adding zlib
[15:11] <ubotu> Launchpad bug 110613 in svn-buildpackage "patch: empty files in files list, add missing "-p" to mkdir" [Undecided,Confirmed] https://launchpad.net/bugs/110613
[15:12] <\sh> sebner, no...they just uploaded a new upstream version
[15:13] <sebner> \sh: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450447
[15:13] <ubotu> Debian bug 450447 in athcool "athcool: FTBFS: undefined reference to `gzopen'" [Serious,Fixed]
[15:14] <\sh> sebner, yes...seriously...I compiled the package before and most probably it ftbfs because of the missing build-dep
[15:14] <\sh> these days...
[15:14] <sebner> \sh: I did a rebuild without problems (of the debian package)
[15:15] <\sh> sebner, the .11-1 version?
[15:15] <\sh> sebner,  in feisty? :)
[15:15] <sebner> \sh: ^^ hardy. I'll make a sync. new version is a 1bugfix-release
[15:16] <sebner> \sh: .12-2
[15:16] <sebner> äh
[15:16] <sebner> .12-1
[15:16] <\sh> sebner, yeah...the old version is sitting in ubuntu since feisty :)
[15:16] <\sh> sebner, and I uploaded it during feisty :)
[15:16] <sebner> \sh: I know as you can see ^^
[15:17] <sebner> \sh: do you remember on which platform it FTBFS? Otherwise I will make a sync request as it seems that the build-dep isn't necessary anymore
[15:19] <\sh> sebner, imho it was just libz missing in feisty for some reason...and no...it could be i386 or amd64...it's long time ago
[15:19] <\sh> sebner, if it works now...sync and done :)
[15:20] <sebner> \sh: hmm no. wired. Another problem ^^  Depend on pciutils-dev (>= 1:2.2.10) we have 2.2.4. What's the way in such a case?
[15:21] <\sh> sebner, check if 2.2.4 is enough for the new version.
[15:21] <\sh> sebner, well, buildwise and also running
[15:21] <sebner> kk. thx
[15:21] <sebner> \sh: btw. wine landed. wuhu :)
[15:22] <\sh> sebner, well, yes...but without the last cahnges in .58-0ubuntu3 ...:(
[15:22] <\sh> so I have to readd them tonight
[15:23] <sebner> \sh: did he forget it?
[15:23] <\sh> sebner, looks like...
[15:23] <sebner> damn it
[15:24] <\sh> sebner, just a few lpia adds
[15:31] <sebner> \sh: hmm we need the new dependency. So I suppose extracting the fix?
[15:32] <\sh> sebner, what fix then? it's new upstream...
[15:34] <sebner> \sh: argh. I already said that new upstream is a *1* bugfix release. "fix freeze problem on SiS741 series chipsets"
[15:34] <\sh> ah
[15:34] <\sh> then I wonder why they need a new pciutils...
[15:34] <\sh> and why it's not working with our version in main?
[15:36] <sebner> \sh: * Depend on pciutils-dev (>= 1:2.2.10) and pkg-config, and use
[15:36] <sebner>      "pkg-config --libs libpci" to build statically with the correct
[15:36] <sebner>      libraries.
[15:37] <sebner> \sh: http://pastebin.com/m6dbb6341
[15:38] <\sh> sebner, yes...:) but I wonder, what the fix in the source was, if not using new pciutils or something which relates more on pciutils
[15:38] <\sh> s/on/to/
[15:39] <sebner> \sh: maybe because of that. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445016
[15:39] <ubotu> Debian bug 445016 in athcool "athcool: Does not start due to missing libpci.so.2" [Grave,Fixed]
[15:42] <\sh> sebner, ok...can you extract the fix of upstream for this freeze problem?
[15:42] <sebner> \sh: I'll try it :)
[15:45] <sebner> \sh: diff -ruN should be enough? if yes I have to change 1 line. I love such things ^^
[15:45] <\sh> sebner, pastebin pls
[15:45] <sebner> \sh: http://pastebin.com/m75690d57
[15:47] <sebner> \sh: but ignore the changelog ^^ was just testing something
[15:49] <\sh> sebner, aehm...no the source change :)
[15:49] <\sh> not the package change
[15:49] <sebner> \sh: see athcool-0.3.12/chips.h
[15:49] <\sh> aj
[15:49] <sebner> ^^
[15:49]  * \sh 's blind
[15:50] <SpookyET> hi
[15:50] <SpookyET> I'm having trouble creating a deb package. dpkg-source: error: source package has two conflicting values - bcwipe-1.7 and bcwipe. I've checked. I see bcwipe-1.7 everywhere.
[15:51] <sebner> \sh: do I have green lights?
[15:51] <azeem> SpookyET: 16:47 < azeem> changelog has bcwipe and control has bcwipe-1.7
[15:51] <\sh> sebner, create a debdiff against the version in hardy (.11-1ubuntu1) and push it to LP and subscribe..I'll upload when I'm at home
[15:52] <sebner> \sh: fine :) just with the fix our don't we ignore the cosmetic fixes. e.g lintian warning ...
[15:53] <\sh> sebner, I'll tend to fix the make clean stuff more like this: [ ! -e Makefile ] || $(MAKE) clean something like this ;)
[15:53] <SpookyET> azeem. I removed from Source and Package. Now it builds into an error.
[15:54] <sebner> \sh: never saw that before ;) But yes. include all fixes?
[15:54] <bddebian> Heya gang
[15:54] <sebner> heya bddebian
[15:54] <\sh> sebner, it says: test if Makefile does not exists, but when it's there execute $(MAKE) clean :)
[15:54] <bddebian> Hello sebner, \sh
[15:54] <\sh> hey bddebian
[15:55] <sebner> \sh: I know. I'm just wondering why -e and not -f
[15:56] <\sh> -e is enough imho...need to test if -f fails when it's a symlink ;)
[15:57] <\sh> sebner, which should fail, if Makefile is a symlink to something else...because of the existence of -h ;)
[15:57] <sebner> \sh: well I hope you'll upload it though I'm using -f ^^
[15:58] <\sh> sebner, no..I don't care :)
[15:58] <\sh> sebner, if you want, just fix http://lintian.debian.org/reports/tags/debian-rules-ignores-make-clean-error.html :)
[15:59] <sebner> \sh: ehm. what do we were talking about in past xD
[16:00]  * \sh heads home now...
[16:00] <\sh> cu later
[16:09] <ScottK> dholbach: I see we are not going to agree on Envy.  I'm not going to ack it, but I also sent a comment to the bug just now saying I don't want to stop other motu-release people from approving it if they think it should go in.
[16:10] <dholbach> ScottK: thanks - I realised that others were abstaining from the discussion
[16:10] <dholbach> ScottK: how is the motu release team doing otherwise?
[16:10] <ScottK> Seems fine.
[16:10] <ScottK> I think we could use the extra 2 months that Dapper got for bug fixing.
[16:10] <ScottK> A lot of things seemed to come late.
[16:11] <dholbach> ScottK: I guess that makes sense - sounds like good feedback for the "release cycle" session at uds
[16:12] <ScottK> Personally the late arrival of python-central sucked a lot of my time away from what I wanted to be working on.
[16:13] <dholbach> with late arrival you mean the bugs that were fixed late?
[16:14] <ScottK> dholbach: Specifically Bug 204895
[16:14] <ubotu> Launchpad bug 204895 in harvestman "Packages failed archive rebuild test possibly due to python-central transition" [Medium,Fix released] https://launchpad.net/bugs/204895
[16:16] <dholbach> ScottK: right - there's also a bunch of "interesting" upgrade behaviour bugs - ask mvo
[16:16] <LaserJock> ScottK: gfortran was the one for me
[16:16] <LaserJock> little as I do, that took a lot of my available time
[16:17] <emgent> heya people
[16:17] <ScottK> dholbach: I've seen.
[16:18] <dholbach> to me it seems like we're in much better shape than we were 2 months before dapper release though
[16:20] <ScottK> I wasn't involved in development then, so I've no basis for comparison.
[16:21] <ScottK> Getting setools unforked was another time sump I hadn't planned on.
[16:21] <LaserJock> dholbach: perhaps, I have a bit more of an uneasy feeling, but yeah, there was a lot of "umm, this isn't gonna make it" with dapper
[16:22] <ScottK> kde3 seems rock solid this time around.
[16:22] <LaserJock> yeah?
[16:22]  * LaserJock confesses to running Fedora KDE3 at the moment
[16:23] <sebner> LaserJock: damn you :P
[16:23]  * ScottK has enougn trouble keeping one Linux distro straight in his head.
[16:23] <ScottK> Intrepid should get a little sporting since Debian has started to freeze up for Lenny.
[16:24] <SpookyET> Firefox is so slow in Ubuntu. It stinks. I have to make a package.
[16:25] <SpookyET> I don't get why it's split up into xulrunner and a few other things
[16:26] <LaserJock> because more than Firefox can use xulrunner
[16:26] <SpookyET> My firefox build for arch linux is 7 times faster
[16:27] <LaserJock> good for you
[16:27] <SpookyET> I want to do the same for Ubuntu
[16:27] <SpookyET> debs are proving difficult
[16:27] <LaserJock> SpookyET: then discuss it with the Mozilla Team
[16:28] <SpookyET> LaserJock: I'm not going to wait on somebody else
[16:28] <LaserJock> umm, but you're waiting on people in here?
[16:28] <SpookyET> no
[16:28] <LaserJock> I'm saying you can get firefox-specific help from the Mozilla Team
[16:29] <SpookyET> I'm learning how to make debs.
[16:29] <LaserJock> ok
[16:29] <SpookyET> I've been spoiled by pacman simplicity
[16:45] <SpookyET> Debian package management and creation is quite messy.
[17:13] <SpookyET> Is pbuilder like ABS/ports/portage?
[17:13] <LaserJock> no
[17:14] <LaserJock> pbuilder is a .deb builder that uses a clean chroot environment
[17:14] <LaserJock> i.e. you give it a source package and it spits out a .deb
[17:15] <\sh> sebner, can you give me the bug number for athcool?
[17:15] <SpookyET> pbuilder create seem to be retrieving a lot of packages.
[17:16] <LaserJock> SpookyET: yeah, it's creating a minimal Ubuntu chroot environment
[17:17] <freeflying> can I upload new package now? any exception need? thanks
[17:17] <LaserJock> freeflying: what kind of package?
[17:18] <LaserJock> i.e. what do you mean by "new"?
[17:18] <freeflying> LaserJock: a gui tool for PostgreSQL
[17:18] <sebner> \sh: I have to upload first. just wondering if I should make a new one or attach at *any* open athcool bug report
[17:18] <freeflying> LaserJock: never been in Debian/Ubuntu
[17:18] <LaserJock> freeflying: uh yeah, you need a Feature Freeze exception for that
[17:18] <ScottK> freeflying: No.  You need an exception and it's stunningly unlikely you'd get one.
[17:19] <freeflying> heh
[17:20] <\sh> sebner, create a new one...
[17:20] <\sh> sebner, I don't see one which mentions the problem
[17:20] <\sh> sebner, in LP that is
[17:20] <sebner> \sh: k.
[17:21] <sebner> \sh: bug #214670
[17:21] <ubotu> Launchpad bug 214670 in athcool "Fix a freeze on SiS741 series chipsets and various stuff" [Undecided,New] https://launchpad.net/bugs/214670
[17:21] <ScottK> freeflying: Wait a few weeks and be first in line for Intrepid
[17:22] <\sh> sebner, thx ...
[17:23] <\sh> sebner, test building and uploading...thx
[17:24] <sebner> \sh: np. I testbuilded and tested it. Running.  But I can't test the fix though
[17:25] <\sh> sebner, well, I added the bugno for LP to your changelog (without changing your tagline :))
[17:25] <sebner> ah ok. sry and thx ^^
[17:28] <\sh> bah...233 € more to pay for electricity...I have to stop fan in my bathroom
[17:29] <\sh> sebner, it was on i386 the ftbfs (amd64 is not in the arch list ;))
[17:30] <sebner> \sh: ah. ok then ^^
[17:33] <sebner> \sh: maybe also a candidate for a SRU?
[17:34] <\sh> sebner, then you need to do it down to feisty
[17:34] <\sh> sebner, please ask someone from the sru team...
[17:35] <\sh> sebner, did you get the accepted mail from athcool?
[17:36] <\sh> ah no...there it is
[17:36]  * ScottK gives YokoZar a smack for \sh
[17:36] <\sh> hmm?
[17:37] <ScottK> Your wine upload that added the lpia stuff back in he forgot.
[17:37] <\sh> ScottK, well, I'll give yokozar a bzr training ;)
[17:37] <ScottK> That'll teach him to forget something
[17:38] <sebner> \sh: well the good thing is that I can reuse my debdiff. I'm just curious if it's a candidate
[17:38] <\sh> sebner, well, you need to provide at least new version numbers...and you have to remove all debian/ dir changes :)
[17:39] <\sh> sebner, just the code fix is important for SRU ..
[17:39] <sebner> \sh: what debian/dir changes? the package is the same since feisty!?
[17:39] <SpookyET> Building debs is a bitch. You've got tools upon tools upon tools.
[17:39] <\sh> sebner, updating standards version, debian/rules etc. :)
[17:40] <\sh> SpookyET, you never used rpm and .spec files...
[17:40] <sebner> \sh: Sry I don't understand. just different versions numbers yes but the debdiff should be the same
[17:40] <DaveMorris> how do you add/remove new content to a config file when packages are installed, anyone got an example?
[17:40] <SpookyET> No, I have not. I've used pacman and one simple PKBUILD file.
[17:41] <Spec> \sh: have too.
[17:41] <\sh> sebner, no.. the change to debian/rules is not going into SRU, the improved copyright notice doesn't go in, and the standards version change doesn't go into an SRU :)
[17:42] <\sh> sebner, so only a new changelog entry and the source fix in chips.h is important :)
[17:42] <\sh> SpookyET, pacman? the suse packman?
[17:42] <SpookyET> no, Arch Linux
[17:43] <SpookyET> It's grandma easy. A simple PKGBUILD file and one command: makepkg
[17:43] <SpookyET> 99% of the time with no arguments.
[17:43] <\sh> damn...I can't use "cool" anymore and now I need to be careful to use .spec , too ;)
[17:43] <sebner> \sh: ahh now I understand. Ok thx :)
[17:44] <Spec> \sh: =P
[17:44] <\sh> sebner, and now for the fun of it, we have one version in 2 releases (feisty/gutsy) so you need to adjust the ubuntu rev to something else then just -1ubuntu2 ,-)
[17:45] <Spec> \sh: i don't log/read mentions of "spec" 'cause it's always "did you read the damned spec?!" or "check the spec sheet on it!"
[17:45] <ScottK> Some MOTU (or hopeful) that cares about nexiuz ought to have a look at https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/003575.html
[17:45] <jdong> Dear Firefox default URL handler:
[17:45] <jdong> burn in freaking hell.
[17:46] <\sh> SpookyET, well, ports makefiles are easy too...and gentoo ebuilds are also easy...but cobalt pkg files are complicated...it's a tar.gz file, with an rpm inside which you have to create and another installation makefile in the tar.gz...
[17:46] <\sh> oh no not again nexuiz
[17:46] <jdong> ScottK: that's a backports bug
[17:46] <ScottK> Ah.
[17:46] <jeromeg> ScottK: i think is wrong, everything is fine for me on both gutsy and hardy
[17:46] <jdong> ScottK: nexuiz 2.4 is sitting all in NEW
[17:46] <ScottK> OK.
[17:47] <\sh> why that?
[17:47] <jeromeg> ah ok :)
[17:47]  * ScottK didn't look into it, just wanted to make sure...
[17:47] <jdong> ScottK: and in my defense that's a soyuz bug.... old versions should NOT be expired this ridiculously quickly
[17:47] <ScottK>  .. someone did
[17:47] <jdong> ;-)
[17:47] <SpookyET> \sh: well yeah. I would say that pacman is the BEST package manager. Similar to apt, but cleaner
[17:47] <\sh> jdong, bah :)
[17:47] <ScottK> jdong: Did you file said bug?
[17:47] <jdong> ScottK: on my TODO list
[17:48] <ScottK> jdong: You may be using the wrong DE.  Konqueror handles different file types VERY well from my perspective.
[17:48] <\sh> jdong, it's released dude
[17:48] <\sh> 2008-03-23
[17:49] <\sh> jdong, and it's in the archives
[17:49] <jdong> ScottK: no it's a firefox transitioning bug in GNOME's url handler
[17:49] <jdong> \sh: https://edge.launchpad.net/ubuntu/gutsy/+source/nexuiz/2.4-1~gutsy1
[17:49] <james_w> DaveMorris: what are you trying to achieve?
[17:50] <ScottK> jdong: OK.  I think that reinforces my point.
[17:50] <\sh> jdong, the backport...this guy is writing to -motu ml..and this means: hardy ;)
[17:50] <jdong> \sh: I am not sure what he meant
[17:50] <jdong> he didn't explicitly say Hardy, did he?
[17:50]  * jdong looks again
[17:50] <jdong> \sh: but nonetheless it is a backport bug I saw this morning
[17:50] <jdong> /usr/lib/firefox-3.0b4/firefox "%s"
[17:50] <DaveMorris> In http://www.mythtv.org/wiki/index.php/MythStreams a couple of files need updating
[17:50] <jdong> ScottK: ^^ hardcoded 3.0b4
[17:50] <POX_> are backports for ubuntu generated automatically or someone has to build them and upload?
[17:50] <jdong> POX_: both
[17:51] <jdong> POX_: usually generated automatically
[17:51] <ScottK> Ah
[17:51] <POX_> someone backported griffith and it's broken
[17:51] <ScottK> POX_: To which release?
[17:51] <POX_> 0.9.6-2~gutsy1
[17:51] <ScottK> What needs to be done to fix it?
[17:52] <POX_> rebuild probaby
[17:52] <POX_> .deb doesn't contain all files
[17:52] <ScottK> Odd.  It was a no change backport from Hardy.
[17:53] <jdong> deb doesn't contain all files?
[17:53] <POX_> symlink in /usr/bin is not there, size doesn't match, ...
[17:53] <POX_> just try to install it
[17:53] <jdong> I amI am.
[17:54] <jeromeg> jdong: waht do you think of the pidgin 2.4.x backport ?
[17:54] <POX_> dpkg should complain and refuse to install it
[17:54] <jdong> jeromeg: is that a newer one than the last one I looked at?
[17:54] <sebner> \sh: ^^. we'll see ^^
[17:55] <james_w> DaveMorris: why can't you just ship the updated versions in the package?
[17:55] <jeromeg> jdong: yes, 2.3.x has been updated in gutsy
[17:55] <jeromeg> jdong: there is 2.4.x now
[17:55] <jdong> jeromeg: then I haven't had a chance to look yet
[17:55] <jdong> apt-get update
[17:55] <jdong> dammit
[17:55] <jeromeg> ok
[17:55] <\sh> sebner, don't we have another powersaving software in main?
[17:56] <sebner> \sh: hmm dunno. why?
[17:56] <sebner> \sh: you mean because this one is outdated?
[17:56] <\sh> sebner, right :)
[17:56] <DaveMorris> james_w: because I think they change depending on what other mythtv plugins are installed
[17:56] <sebner> \sh: I'll fire up synaptic :P
[17:56] <\sh> sebner, there are two bugs still open...one is about a wrapper script (whishlisted it now) and the other one is about "athcool is not working with suspend/resume)
[17:57] <jdong> root@jdong:/# which griffith
[17:57] <jdong> /usr/bin/griffith
[17:57] <jdong> POX_: the package installed perfectly fine
[17:57] <sebner> \sh: I see
[17:57] <james_w> DaveMorris: well, the package that uses these files is taking the wrong approach really, it should allow plugins to drop a file in a directory to register.
[17:57] <jdong>   Installed: 0.9.6-2~gutsy1
[17:57] <\sh> sebner, powersaved e.g.
[17:57] <\sh> but it's also universe
[17:57] <james_w> DaveMorris: you could insert the text if it is not already present, but that's pretty hairy.
[17:57] <DaveMorris> ok, I'll have a look when I get home since I need to leave now
[17:58] <DaveMorris> thanks for the advice
[17:58] <POX_> jdong: please paste `md5sum griffith_0.9.6-2~gutsy1_all.deb` output
[17:58] <jeromeg> POX_, jdong : griffith seems to work fine for me, a bunch of gtk errors in the terminal but nothing to worry about
[17:59] <sebner> \sh: hmm. same features as athcool?
[17:59] <jeromeg> POX_: 5b67d65a44c4c56be6107b3e70e23e26  griffith_0.9.6-2~gutsy1_all.deb
[17:59] <sebner> \sh: kpowersave xD
[18:00] <\sh> sebner, actually I don't need any power saving tool...mostly because I need all the cpu speed for compiz and compiling ;)
[18:00] <jdong> yeah it runs fine from a pbuilder
[18:00] <jdong> fetched from archive.ubuntu.com
[18:00] <POX_> ok, so it's mirror's problem (http://na.mirror.garr.it)
[18:01] <sebner> \sh: and for nexuiz :P
[18:01] <POX_> or users
[18:01] <\sh> sebner, follow #ubuntu-devel pls :)
[18:02] <jeromeg> jdong: i think the tracker backport should be acked
[18:02] <jeromeg> jdong: there does not seem to be problems for most people, and it really solves a lot of issues
[18:03] <jdong> jeromeg: agreed. pochu's e-mail came after my backport process day
[18:03] <jdong> jeromeg: I have it slated for Friday
[18:03] <jeromeg> jdong: great
[18:03] <sebner> \sh: don't even *think* about the possibility to remove it from the repo after my update!!! :P
[18:04] <\sh> sebner, *eg* :)
[18:05] <jeromeg> jdong: scribes should be fine too, i've been using the backported package since the 20 of january without any issues
[18:05] <jeromeg> i guess i never tested a backport that much :)
[18:05] <sebner> \sh: deal. we remove it for intrepid :P
[18:06] <\sh> sebner, yepp...we should get rid of old crap which doesn't work anymore on modern systems
[18:07] <jeromeg> diner time
[18:07] <jeromeg> bye all
[18:07] <SpookyET> I've made my first deb. That was freaking complicated compared to pacman packages.
[18:08] <ScottK> SpookyET: FYI, whining about how awful Debian packaging is does not encourage people to volunteer their time to help you.
[18:08] <ScottK> \sh: What's you definition of modern?
[18:08] <sebner> \sh: fine :)
[18:08] <ScottK> you/your
[18:11] <\sh> ScottK, well, I think everything which was invented 2007-02-02 ;)
[18:11] <\sh> insert "after"
[18:11] <ScottK> Yeah.  I've got a circu 2001 laptop that runs Hardy reasonably well.  Actually far better than Gutsy because acpi was broken for it in 2.6.22.
[18:12] <ScottK> circu/circa
[18:13] <\sh> ScottK, serious...when we have a working piece of software for a delicate area like powersaving, I would rely more on something in main, then a piece of software which last upstream version was released in 2005
[18:14] <ScottK> Well when that laptop was on Gutsy I was using gkrellem because it worked.
[18:14] <ScottK> The modern stuff didn't
[18:14] <ScottK> It's a balance thing.
[18:17] <\sh> ScottK, but compare the new upstream releases between your gkrellm and athcool e.g. I mean, we have to be careful about what software can do to our users hardware (I'll remember this damn discussion about laptop-mode of ubuntu grills laptop hd just because nobody understand the s.m.a.r.t. manufacture data ) :=
[18:17] <ScottK> Right. I agree about being careful, but one of the nice things about Linux is that you can, in fact, continue to use older hardware.  Let's not throw that away.
[18:20] <\sh> ScottK, no...but we should deal with software, which is rotten and stinks, and doesn't get cleaned up from debian archives in time for intrepid :)
[18:20] <ScottK> Agreed.
[18:21] <\sh> ScottK, which means, old kernel modules (via module-assistant or whatever), which are not updated for new kernel releases etc.pp.
[18:22] <ScottK> Right
[18:44] <JontheEchidna> Could the REVU admins re-sync the REVU uploaders keyring?
[19:13] <RainCT> JontheEchidna: sure, one moment :)
[19:14] <JontheEchidna> RainCT: Thanks :)
[19:15] <RainCT> JontheEchidna: what's your Launchpad ID? (knowing it I can sync your key first)
[19:15] <JontheEchidna> echidnaman
[19:17] <RainCT> JontheEchidna: ok, done
[19:17] <JontheEchidna> thanks
[19:18] <RainCT> no problem :)
[19:22] <JontheEchidna> So how do I upload a package to REVU?
[19:22] <RainCT> !revu
[19:22] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[19:22] <RainCT> isn't it explained there?
[19:22] <JontheEchidna> maybe I missed it...
[19:23] <JontheEchidna> Oh, the dput stuff
[19:23] <RainCT> yes
[19:52] <mok0> Why is hardy's devscripts package so far behind?
[19:56] <RainCT> mok0: because you haven't merged it :)
[19:58] <ScottK> mok0: You might look if linitian needs updating while you're at it.
[20:00] <RainCT> ScottK: there's a new version too
[20:01]  * ScottK has no time for anything but displayconfig hacking right now, so feel free to go for it.
[20:01] <RainCT> ScottK: it can probably be synced, but does it need a FFe?
[20:02] <ScottK> \sh, jdong, or YokoZar: I'll be unable to upload probably for a week after today, so if you want wine backported, please debdiff me.
[20:02] <ScottK> RainCT: It's in Main
[20:02] <RainCT> hm, true ^^
[20:03] <RainCT> btw, if a sync is requested today does it need a big-freeze-exception, or not, or does this depend on the archive guy who looks at it?
[20:04] <ScottK> Exception process is different in Main.
[20:04]  * ScottK would suggest ping slangasek (just did) and see how he feels about it.
[20:05] <RainCT> this last question was for universe
[20:05] <ScottK> What package?
[20:06] <slangasek> chumbawumba?
[20:06] <ScottK> Sorry.  Thought we were still talking lintian
[20:06] <ScottK> slangasek: The question was would it be desireable to update lintian at this point.
[20:07] <RainCT> ScottK: any package in general. as when someone looks the next time at some sync there's probably already big freeze
[20:08] <slangasek> ScottK: are there enough new goodies in 1.23.46 to justify it?
[20:08] <ScottK> Use your judgement as I can't tell you when someone looks next
[20:09] <ScottK> slangasek: I like it for "Warn if the .diff.gz contains changes while the package uses a patch system."
[20:09] <ScottK> It's a long list though.
[20:10] <slangasek> ScottK: then I'm amenable
[20:10] <ScottK> slangasek: Thanks.
[20:10] <geser> doesn't it also contain better checks for bashism?
[20:10] <ScottK> RainCT: Would you be up for checking if the new lintian builds/runs here?
[20:10] <ScottK> geser: It's a long list
[20:10] <ScottK> I think it does
[20:10] <geser> :)
[20:11] <ScottK> Someone please look into it.
[20:11]  * RainCT wonders why he has linda 0.3.26ubuntu2 when in debian there's 0.3.24 -.-
[20:11]  * ScottK goes back to comitting atrocities on kde-guidance.
[20:11] <RainCT> ScottK: sure, one moment
[20:11] <ScottK> RainCT: Linda's been removed IIRC
[20:12] <geser> yes, linda is gone
[20:12] <DktrKranz> stani, I tried drpython on Hardy and I can open files normally. Is there a specific procedure to trigger the issue^
[20:13] <geser> Debian bug #469039
[20:13] <ubotu> Debian bug 469039 in ftp.debian.org "RM: linda -- RoM; deprecated" [Serious,Open] http://bugs.debian.org/469039
[20:13] <RainCT> oh. it had some nix checks, though
[20:14] <ScottK> The theory is they're all in Lintian.  Practice is often different than theory.
[20:14] <RainCT> will, I'll file bugs in lintian then :P
[20:15] <LaserJock> james_w: so it looks to be a MOTU problem (in regard to the ubuntu-bugsquad thread)
[20:16] <LaserJock> or at least ubuntu-dev
[20:16] <LaserJock> not sure what other Core Devs do
[20:18] <RainCT> ScottK: new lintian builds fine, installing it now
[20:18] <james_w> LaserJock: sorry, what is the MOTU problem?
[20:18] <LaserJock> james_w: requiring debdiffs
[20:18] <LaserJock> james_w: you didn't find any triaging wiki page that said to ask for a debdiff?
[20:19] <james_w> LaserJock: yes, however there is some good reasoning behind it.
[20:19] <james_w> https://wiki.ubuntu.com/Bugs/Responses#head-bca0f1c95c38399375e738b3f5ddd894f44f1b4f
[20:20] <james_w> however, we don't really have anything better to answer with right now.
[20:20] <LaserJock> interesting
[20:20] <LaserJock> that at least isn't making it mandatory, just saying it's got better chances
[20:20] <LaserJock> although I think that's more or less how it goes
[20:21] <LaserJock> I don't think we've ever closed a bug because it didn't have a debdiff
[20:21] <ScottK> I think it's like asking for a new package review for something from a bzr branch.  You can do it, but the number of potential reviewers goes down.
[20:22] <james_w> there are a few problems that are combining to make this worse than it should be, so I'd like to get input from everyone to get and idea of what the process should look like, and then we can move towards it.
[20:22] <LaserJock> well, I think having people who don't know what there doing not touch bug reports would be a good idea
[20:22] <LaserJock> i.e. if you don't know just leave it alone
[20:23] <james_w> LaserJock: do you have an example?
[20:23] <LaserJock> the status flippers
[20:23] <LaserJock> or Importance flippers actually
[20:24] <james_w> well you need to be in bugcontrol to change Importance, so they have shown a certain level of understanding.
[20:24] <LaserJock> uhh... yeah
[20:24] <james_w> but yes, that should be the rule, I agree.
[20:24] <LaserJock> that would be the problem, IMO
[20:24] <LaserJock> bugcontrol is darn near meaningless
[20:24] <james_w> I don't think that's true.
[20:25] <LaserJock> k, I'd love to be wrong
[20:26] <LaserJock> I just see a lot of bugmails that indicate that the person doing the work doesn't know anything about the bug or the software
[20:27] <RainCT> bug 214752
[20:27] <ubotu> Launchpad bug 214752 in lintian "Please sync lintian 1.23.46 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/214752
[20:27] <james_w> you could say that a MOTU uploading a debdiff knows little about the bug or the software, and has more potential to damage Ubuntu as a whole.
[20:28] <LaserJock> I agree
[20:28] <james_w> However I am sure there are cases where people in bugcontrol overstep their mark.
[20:28] <LaserJock> wholeheartedly
[20:29] <LaserJock> I'd so a whole lot of bugcontrol is busy work
[20:29] <LaserJock> some of which is necessary
[20:29] <james_w> that's why I think it would be good to have more ways for people triaging reports to escalate them to people that may understand development better.
[20:29] <LaserJock> but I think we can maybe get everything more efficient
[20:30] <james_w> however there are obviously issues with that, for instance the lack of developer time, so we need to move there slowly.
[20:30] <james_w> LaserJock: I'd agree with that.
[20:31] <LaserJock> we need a cohesive strategy that includes both bug triaging and developers
[20:31] <james_w> agreed
[20:31] <LaserJock> my feeling is that the two have kinda "gone their separate ways"
[20:31] <james_w> I'm going to spend a few days soliciting feedback from that thread on the issue, and then see if we need to make any development process changes at the time.
[20:32] <LaserJock> we need to really have a look at our processes and policies
[20:32] <james_w> another thing that is a problem at the moment is that there is no good way to represent all of the states that a patch in launchpad can be in.
[20:32] <LaserJock> strip them down to what is needed
[20:32] <LaserJock> and get the documentation together
[20:32] <james_w> so the two communities need to decide on a structure, and then (with the help of launchpad) implement that and stick to it.
[20:32] <cbx33> LaserJock, !!!
[20:32] <LaserJock> as there's just too much for a lot of people to keep track of right now
[20:32] <cbx33> yo yo yo dude
[20:33] <LaserJock> hi Pete
[20:33] <james_w> LaserJock: yes, I agree.
[20:33] <LaserJock> fundamentally though, we gotta have MOTUs on the same page
[20:33] <LaserJock> which I believe is a real issue
[20:33] <james_w> LaserJock: apart from patches, is there any other area that you would like to see bugcontrol and -motu converge in?
[20:34] <LaserJock> we certainly need to agree on tags, statuses, and Importance
[20:34] <LaserJock> triagers need to know how to most effectively get things to developers
[20:34] <mok0> ScottK, RainCT, I will merge devscripts then
[20:34] <LaserJock> and developers need to help the triagers know what they want
[20:35] <mok0> ScottK, RainCT, and take a look at lintian afterwards
[20:36] <james_w> LaserJock: great, thanks, we can look at those at some point then.
[20:36] <LaserJock> perhaps what we need is this
[20:36] <LaserJock> a list of every develper process
[20:36] <LaserJock> that describes what the developer, a contributor, and a triager should be doing
[20:37] <james_w> that would be great.
[20:37] <LaserJock> then we can build good processes and policies to match
[20:37] <LaserJock> and make sure that we're on the same page
[20:37] <james_w> yeah, it definitely sounds like UDS material.
[20:37] <james_w> post-hardy at least :-)
[20:37] <james_w> are you going?
[20:38] <LaserJock> no, sadly I was hoping to defend my dissertation around that time
[20:38] <james_w> ah, good luck with that.
[20:38] <LaserJock> I would encourage though, that UDS discussion only be a part of the solution
[20:39] <james_w> It won't all be done at UDS anyway, so there will be plenty of opportunity for input.
[20:39] <LaserJock> we need buy-in and feedback from everybody, not just the people at UDS
[20:39] <james_w> LaserJock: I agree totally
[20:40] <james_w> it's just a great opportunity for discussion of this sort of thing.
[20:40] <LaserJock> sure
[20:40] <LaserJock> I've just had enough "Oh, but we decided that at UDS" experiences to be wary
[20:40] <james_w> sure
[20:41] <SpookyET> Where can I find the xulrunner deb generation files?
[20:41] <LaserJock> I'm also thinking we should maybe ditch as much Universe/Main diff as we can in our processes
[20:41] <james_w> I imagine in this case what would be discussed would not be the specifics, but the way in which each side wants to know what they should be doing, and the boundaries that they can expect.
[20:41] <james_w> LaserJock: that sounds sensible
[20:41] <LaserJock> we've done a pretty good job of that so far, but there's probably more to do
[20:42] <james_w> isn't the proposal to drop the distinction in the archive still hanging around?
[20:42] <LaserJock> yeah
[20:42] <LaserJock> and certianly it would be a good idea to have matching policies for if that ever happens
[20:44] <james_w> yes, the confusion would be endless if not.
[20:50] <SpookyET> Where can I find the firefox 3 deb creation files? are the "debian" folders shared anywhere?
[20:50] <LaserJock> SpookyET: did you get the source package?
[20:51] <SpookyET> I have the firefox source, but where can I find the "debian" folder that ubuntu created. I want to modify some things
[20:53] <LaserJock> if you got the Ubuntu source package the debian directory is in the unpacke source
[20:53] <LaserJock> *unpacked
[20:55] <LaserJock> SpookyET: you might want to look at https://wiki.ubuntu.com/MozillaTeam/Build/Apt or https://wiki.ubuntu.com/MozillaTeam/Build/Bzr
[20:56] <LaserJock> except those are kinda old
[21:01] <sebner> RainCT: around?
[21:10] <sebner> heya afflux :)
[21:10] <afflux> hi sebner ;)
[21:13] <RainCT> sebner: pong
[21:24] <stani> LaserJock: Thanks for your help yesterday. My PPA is running fine now.
[21:24] <LaserJock> stani: awesome
[21:31] <stani> Laserjock: I could go back to feisty. As you guessed installation did not work for all distroreleases the same way.
[21:32] <LaserJock> stani: yeah, that would've been my guess
[21:43] <sebner> RainCT: debian folks appreciate my boson .desktop fix patch and are very happy about it ;)
[21:43] <RainCT> sebner: great :)
[21:43] <sebner> RainCT: ^^
[21:55] <yosch> ogra_cmpc: ping
[22:06] <RAOF> Hobbsee: Terrified?  In what way?
[22:07] <RAOF> Hobbsee: If you don't remember the context, that was "why is gnome-do terrified of openoffice"?
[22:14] <SpookyET> I hate open office
[22:16] <mario_limonciell> why do we still have gnome-bluetooth's obex server available?
[22:16] <RainCT> good night
[22:16] <mario_limonciell> it seems counter productive to include it still
[22:16] <mario_limonciell> since the support is native to bluez now
[22:24] <mok0> ScottK: ping!
[22:24] <ScottK> Pong
[22:25] <mok0> ScottK: I have a suggestion to a fix to pykdeextensions
[22:25] <mok0> bug 138189
[22:25] <ubotu> Launchpad bug 138189 in pykdeextensions "application tries to dlopen /usr/lib/libpython2.5.so (only found in the -dev package) " [Medium,Confirmed] https://launchpad.net/bugs/138189
[22:25] <ScottK> mok0: That'd be cool.
[22:26] <mok0> ScottK: I will leave it to you, since you've dealt with it's impacts
[22:26] <ScottK> mok0: I think we've got it worked around for now (packages needing it depending on python-dev), so it needs to be fixed, but I think it can wait.
[22:27] <ScottK> mok0: Did you test that and see if it works?
[22:27] <mok0> ScottK: no, I haven't
[22:27] <ScottK> I'm not sure, but I think I tried that.
[22:27] <mok0> ScottK: I was hoping you would do it :-)
[22:27] <ScottK> Not for a while.  I'm leaving town in the AM for a week.
[22:28] <mok0> ScottK: ok, I'll try it tomorrow, then
[22:28] <mok0> ScottK: can you suggest a good way to test it?
[22:28] <ScottK> mok0: Debian needs the fix too, so if it works, push the fix there.
[22:29] <mok0> ScottK: ok
[22:29] <ScottK> mok0: Make your own version of kde-guidance that doens't have the python-dev dependency
[22:29] <ScottK> mok0: Install that and remove python-dev
[22:30] <ScottK> mok0: If you can run displayconfig then, you have a winner.
[22:30] <mok0> ScottK: got it
[22:59] <YokoZar> Approximately how many hours do I have to make an upload before freeze rejects it and I have to ask someone else to do it for me?  I'm debating doing some work now or later this evening.
[23:00] <Fujitsu> You can upload once the freeze is in place. It'll just get stuck in a queue.
[23:19] <yosch> hi guys, I got an update for ttf-ubuntu-title (the font to used for Ubuntu branding in the LoCos and other things) http://revu.tauware.de/details.py?package=ttf-ubuntu-title
[23:19] <yosch> seb128 told me you'd help me out
[23:23] <yosch> what the process to follow from here?
[23:33] <mok0> motu-release ppl, please check out bug 195772
[23:34] <ubotu> Launchpad bug 195772 in matplotlib "please upgrade python-matplotlib to version later than 0.90.1" [Undecided,Triaged] https://launchpad.net/bugs/195772


[07:24] <RAOF> Hm. Mesa doesn't seem to play nicely with debuginfod.ubuntu.com; I think the source map might not be quite right?
[07:24] <RAOF> gdb can't find any of the source files.
[09:04] <rbasak> RAOF: on which release? Source file indexing depends on a fairly recent patch AIUI.
[09:05] <rbasak> (and won't work on older releases)
[09:06] <RAOF> On mantic. Actually building the package, I *still* can't find the files it's referencing 🤷♀
[09:09] <RAOF> Like, gdb is looking for libegl.c; I can't find that file with that name in a built tree!
[13:23] <vinodwa> rbasak Hi, did you got your questions answered regarding LP#1996229 ? We need this reviewed and approved as soon as possible. Thanks
[13:24] -ubottu:#ubuntu-devel- Launchpad bug 1996229 in python-magnumclient (Ubuntu Focal) "[SRU] magnum ui can not delete the coe cluster" [High, Triaged] https://launchpad.net/bugs/1996229
[14:08] <rbasak> freyes: to check we're not waiting on each other: you're working on answering my questions in bug 1996229, right?
[14:08] -ubottu:#ubuntu-devel- Bug 1996229 in python-magnumclient (Ubuntu Focal) "[SRU] magnum ui can not delete the coe cluster" [High, Triaged] https://launchpad.net/bugs/1996229
[14:08] <freyes> rbasak, yes, I just posted the reply - https://bugs.launchpad.net/ubuntu/+source/magnum-ui/+bug/1996229/comments/5
[14:09] <rbasak> ack, reading
[14:13] <rbasak> freyes: so another class of "Where problems could occur" would be users directly using python3-magnumclient with their own code, right? Has this been considered?
[14:14] <freyes> rbasak, yes, when I was going through the git log I didn't find code removed (e.g. deprecated API removed)
[14:15] <rbasak> Great, thanks
[14:21] <freyes> updated the bug description to include the impacted packages and this aspect of users running custom code with magnumclient as a library
[14:24] <rbasak> freyes: will the CLI for ListCluster (not sure what the command is exactly) now output more columns by default?
[14:24] <rbasak> I'm thinking about https://github.com/openstack/python-magnumclient/commit/74c5f22c6ffb23154f2e0412ba43371f3c02f3b7#diff-f055b476bf7193ad89f9512f8f9d13dc2fe6d32644ea5d8755294d45c8a23ea7
[14:24] -ubottu:#ubuntu-devel- Commit 74c5f22 in openstack/python-magnumclient "Support health_status on client side"
[14:26] <freyes> rbasak, yes, it will
[14:27] <freyes> rbasak, this has been identified as a problem, not showing that column, since operators have no visibility on the cluster's state
[14:27] <freyes> rbasak, the general guideline has been to use the openstackclients snap
[14:28] <freyes> which ships newer versions of the clients (from upstream python tarballs)
[14:29] <freyes> although this change may break bash scripts :-/ I didn't think about it
[14:34] <rbasak> freyes: how configurable is the list CLI currently? Would it be feasible/trivial to make the default not output that column, for example, but make it possible with an option? Or would that be not useful anyway?
[14:35] <rbasak> If you want to deliberately change the output, then that wouldn't be unreasonable. We just need to be careful to think about the possible consequences.
[14:35] <rbasak> freyes: I'm also curious why you didn't only cherry-pick the necessary patches - looks like that would be feasible?
[14:38] <adrien>  /lastlog -clear
[14:38] <adrien> woops :)
[14:40] <sergiodj> jbicha: hey, I'm about to start my patch pilot shift and I couldn't find your entry in the handoff doc.  is there anything worth mentioning from yesterday's shift?
[14:40] <adrien> ginggs: you retried rust-globset on yesterday but I'm wondering if the triggers were right: more specifically I'm wondering if the needed ones are exactly rust-bstr/1.5.0-1 and rust-globset/0.4.10-1 , which would be that URI: https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=armhf&package=rust-globset&trigger=rust-bstr%2F1.5.0-1&trigger=rust-globset%2F0.4.10-1
[14:44] <ginggs> adrien: i think that combination was tried, but failed with 'websocket: bad handshake' -- let's try again...
[14:46] <freyes> rbasak, on the aspect of bash scripts, typically users run the openstack clients with flags (e.g. `openstack coe cluster list --format json | jq ...`), it's a very common practice by the complexity of the objects in OpenStack. Even users who don't want to deal with jq they do things like `openstack coe cluster list --format value -c ID` to filter the specific data they want to consume
[14:47] <freyes> rbasak, why not cherry-pick, this is because we went initially that route, and we kept finding incompatibility issues, so we were taking a path where the client would become more unstable than just bumping up the version with what was really tested upstream
[14:49] <adrien> ginggs: yup, that's why I think it's worth a new try; tbh I'm not certain that will be the solution but it seems plausible enough
[14:52] <freyes> rbasak, about patching the CLI to not display the health status, removing it from the list of default columns is a oneline change, I would need to check how large a change would be if to allow users to opt-in to the show the column, there is a "-c" flag that allows users to make the CLI print specific columns
[14:59] <sergiodj> @pilot in
[15:28] <adrien> I have a question about rust packages: for instance rust-jsonwebtoken; for 8.2.0, it says " crate directory not found: /usr/share/cargo/registry/jsonwebtoken-8.2.0" and that path comes from librust-jsonwebtoken-dev which is pulled at version 8.3.0-1
[15:29] <adrien> I think the solution is to re-trigger with rust-jsonwebtoken too; is that analysis correct?
[15:29] <schopin> Probably, yes.
[15:31] <adrien> there's a followup comment but I need to get some stats first
[15:33] <adrien> I only get three packages affected by this at the moment but is there something to improve to prevent these from occuring again?
[15:34] <adrien> I think I can get the triggers for the affected packages fairly easily but only if I manage to do it before the children hord of children arrives
[15:35] <adrien> first one
[15:35] <adrien> % ./retry-autopkgtest-regressions --blocked-by-tests rust-jsonwebtoken
[15:35] <adrien> https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=armhf&package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2
[15:39] <adrien> rust-syn seems to be a slightly different issue: it searches for the 2.0.16 directory while testing 2.0.18
[15:40] <adrien> the trigger is 2.0.18 and the -dev package is at version 2.0.18
[15:41] <adrien> the only mention of 2.0.16 in<EMAIL_ADDRESS>is basically the failure itself
[15:44] <adrien> the only place I find 2.0.16 is in debian experimental and I'm not even sure that version was synced
[15:44] <adrien> I'll leave for now but I'm very interested in any idea people could have about this
[15:57] <ginggs> adrien: package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2 retried, but i think that combination has been retried many times
[16:00]  * ginggs tries package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2&trigger=rust-jsonwebtoken/8.3.0-1
[16:18] <ginggs> adrien: re rust-syn -- yes you are correct, the only mention of 2.0.16 is in the test itself
[16:18] <ginggs> https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/syn/debian/tests/control
[16:18] <ginggs> looks like that is the problem!
[16:21] <adrien> this looks like a good way to have version issues; I think the author was focused on a transition and specifically 2.0.16
[16:22] <adrien> ginggs: oh, yes, I definitely wanted to have jsonwebtoken itself as part of the triggers; I think I completely misread the output of r-a-r and that's probably not the first time today; I think I was reading the package as part of the triggers
[16:23] <adrien> ah, right, almost 6 hours ago I pasted one URI which I had similarly misread (repeteadly)
[16:52] <rbasak> freyes: thanks. I think this is mostly on me now to finish my review, and then I might have some further discussion. I've been distracted by meetings and have a prior commitment this evening. I'm hoping to come back later though.
[16:56] <freyes> thanks, rbasak
[17:17] <jbicha> sergiodj: oh sorry I missed the doc. I didn't have anything to pass along
[17:17] <sergiodj> jbicha: ACK, np.  thanks
[18:01] <ogayot> Hi, may I ask somebody to trigger this autopkgtest for me please? https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=pyparted&ppa=ogayot%2Fmantic-proposed&trigger=pyparted%2F3.12.0-4ubuntu1~ppa2 Thanks!
[18:03] <sergiodj> ogayot: done
[18:03] <ogayot> sergiodj: thanks!
[18:03] <sergiodj> np
[18:44] <adrien> create an issue for rust-syn: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/46 (I'll link it to LP and upd*ate-excuse on tomorrow)
[18:44] -ubottu:#ubuntu-devel- Issue 46 in rust-team/debcargo-conf "syn: d/tests/control not synchronized with d/changelog" [Opened]
[18:48] <sergiodj> RAOF: hey, https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1995606 has been updated and is in the sponsorship queue but I don't have enough time/knowledge to review it properly.  it seems like you're driving the review whenever you have time, so I'll leave it to you
[18:48] -ubottu:#ubuntu-devel- Launchpad bug 1995606 in thermald (Ubuntu Jammy) "Upgrade thermald to 2.5.1 for Jammy (22.04)" [Undecided, Incomplete]
[19:09] <sergiodj> @pilot out
[20:13] <adrien> for rust-rustls-pemfile, I would like to run the rust-rustls tests on all arches again *but* with the additional rust-base64 trigger version 0.21.2-1 and I see no way to do that with retry-autopkgtest-regressions
[20:15] <adrien> for amd64 that would be https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=rust-rustls&trigger=rust-rustls-pemfile%2F1.0.2-1&trigger=rust-base64%2F0.21.2-1 (I guess dropping arch=amd64 runs it on all arches?)
[20:33] <bdmurray> adrien: the documentation for retry-autopkgtest-regressions talks about pipeing the output to vipe and you could add a trigger in there
[20:57] <adrien> bdmurray: ok, thanks; I remember vorlon was asking for invocations of r-a-r rather than links to click on but I guess an invocation and a comment about what to change would work too
[22:21] <mwhudson> @pilot in
[22:26] <vorlon> bdmurray, adrien: I've been known to pipe to sed :)
[22:27] <bdmurray> that's what he said
[22:28] <vorlon> Right Sed Fred
[22:28] <bdmurray> lol
[23:41] <sarnold> lol


[02:17] <theluffy> hi
[14:09] <oh2eko> Where would i find a sources.list for lubuntu 19.04?
[14:21] <apt-ghetto> oh2eko: The sources.list of Lubuntu is the same as the sources.list of Ubuntu 19.04
[14:22] <apt-ghetto> You can take the sources.list from https://help.ubuntu.com/lts/serverguide/configuration.html.en
[14:22] <apt-ghetto> and replace the word 'bionic' with 'eoan'
[14:22] <oh2eko> Thank you
[14:23] <apt-ghetto> The 'deb-src' entries are only needed if you need the source code of the packages
[14:32] <apt-ghetto> oh2eko: Sorry, you should use 'disco' (19.04) instead of 'eoan' (19.10). And I see now, that some repos are missing
[14:33] <apt-ghetto> You can find a sources.list for a desktop system (in german): https://wiki.ubuntuusers.de/sources.list/


[08:02] <mup> Bug #1908983 opened: Commissionig with 18.04 fails in smartctl script <MAAS:New> <https://launchpad.net/bugs/1908983>
[08:20] <mup> Bug #1908984 opened: Commissioning requires universe repo for lldpd <MAAS:New> <https://launchpad.net/bugs/1908984>
[08:26] <mup> Bug #1908984 changed: Commissioning requires universe repo for lldpd <MAAS:New> <https://launchpad.net/bugs/1908984>
[08:29] <mup> Bug #1908984 opened: Commissioning requires universe repo for lldpd <MAAS:New> <https://launchpad.net/bugs/1908984>
[17:09] <cyphermox> are there best practices for how one would use MaaS to commission machines, but only just for the initial install, I don't want MaaS or cloud-init to run at all after the machine has been installed once -- it gets moved to a different network where the maas server is not at all reachable
[17:10] <cyphermox> (so currently, I need to rm a bunch of things to break it out, otherwise machines may take >10 minutes to start, trying to reach a cloud-init network source)


[19:34] <Guest13194> Hi, i am installing xubuntu right now
[19:34] <Guest13194> for the first time
[19:34] <diogenes_> Guest13194, awesome!
[19:35] <Guest13194> until now - it seems to work
[19:35] <Guest13194> i will restart the computer ... and see, what it is. thank you!
[19:36] <Guest13194> \O/
[20:23] <Celso> Good afternoon!
[20:23] <Celso> Has anyone from the channel managed to install conky-manager on xubuntu?
[20:24] <Celso> I need a conky-manger installation tutorial on xubuntu.
[20:25] <Celso> I need a conky-manager installation tutorial on xubuntu.
[20:47] <Celso> I managed to install, thanks.
[21:03] <Celso> https://imgur.com/BwMzu1H.png


[13:53] <inquata> hey ux people – greetings especially to those at UDS, hope you’re having fun ;)
[15:43] <doctormo> ivanka: Also check out http://inkscapers.deviantart.com/
[15:44] <doctormo> http://zombiwoof.deviantart.com/art/Frog-149323068 Awesome
[15:52] <ivanka> thanks doctormo
[16:01] <doctormo> Let me know if your having trouble finding people, I vibrate in several communities.
[20:57] <liquidmeson> was checking out http://www.markshuttleworth.com/archives/383, perhaps I didn't read the full thing but can someone enlighten me as to what the diamond icon in the bottom left corner is?