[00:05] <superm1> mythbuntu-meta is finished publishing, can someone respin mythbuntu now?
[00:50] <slangasek> superm1: looking
[00:54] <slangasek> superm1: building
[01:24] <skaet> ScottK ok.   If the overnight builds don't pick up the right pieces, let me or NCommander know in the morning and we'll respin.
[01:24] <ScottK> OK.
[03:21] <ScottK> NCommander: Any ideas what causes http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/kubuntu/current/livecd-20110801.1-powerpc.out
[05:03] <GrueMaster> Looks like a last minute upload of unity has once again clobbered the ubuntu-armel desktop images right before release testing.  Will need a respin so I have something to test tomorrow.
[07:41] <mvo> good morning! how much of a problem is CD size at this point? I have a app-install-data upload, but it adds some new icons so it will be a bit bigger  (~1mb in the deb)
[07:53] <didrocks> mvo: we are not in a good shape AFAIK :/ +8 MB yesterday
[07:55] <mvo> didrocks: ok, thanks! I will wait then
[07:55] <mvo> and not upload new app-install-data for now
[07:56] <didrocks> mvo: are those new app desktop icons? just curious :)
[07:56] <mvo> yeah, app icons plus new desktop files
[07:56] <didrocks> I guess there is no real alternative then…
[07:57] <mvo> well, we can use the a2 data, not *that* much has changed
[07:57] <mvo> and I can upload right after a3
[07:57] <seb128> didrocks, what 8mb where?
[07:58] <didrocks> seb128: oneiric-desktop-amd64.iso  (712M for i386), but if we finally go for 703M, it's a little less
[07:59] <seb128> didrocks, oh, I though you were mentioning an increase of 8mb in use
[07:59] <seb128> yeah, that's nothing new
[07:59] <didrocks> oh no, don't get scared :-)
[07:59] <seb128> we will win 8mb once we got a chinese CD
[07:59] <seb128> get
[08:00] <didrocks> yeah, but still problematic for other language respin as they will still add some to the official image
[08:00] <didrocks> (and so, won't fit in a CD)
[08:00] <didrocks> but let's see pitti to come back :)
[08:00] <seb128> well I discussed it with pitti before his holidays
[08:01] <seb128> he said that the next option for him would be to consider to go back to rhythmbox and drop mono from the CD
[08:01] <seb128> but let's see
[08:02] <didrocks> that's an unfortunate time, but yeah, that would make sense
[08:02] <seb128> didrocks, well there are still potential wins
[08:02] <seb128> like dropping synaptic from the CD
[08:03] <mvo> …
[08:03] <mvo> indeed
[08:03] <mvo> what was missing again? software-properties?
[08:03] <didrocks> seb128: is it that big? I was thinking last time you discussed it it wasn't a huge win?
[08:03] <seb128> didrocks, 750k
[08:03] <seb128> which is not to ignore
[08:03] <didrocks> yeah, still worth it then
[08:04] <didrocks> right :)
[08:04] <seb128> mvo, need to check, but at least update-notifier
[08:04] <jibel> Good morning
[08:04] <jibel> edubuntu, kubuntu (excepted dvd), kubuntu mobile, mythbuntu, ubuntuu-server and ubuntu studio posted to the tracker
[08:04] <didrocks> hey jibel!
[08:04] <seb128> mvo, gnome-codec-install as well but you said that one might not be needed nowadays, it's on my "to test" list
[08:04] <seb128> hey jibel
[08:04] <jibel> Hello didrocks
[08:04] <jibel> Salut seb128
[08:04] <jibel> Guten morgen mvo
[08:04] <mvo> seb128: yeah, I think gnome-codec-install should be superseeded with the session installer
[08:04] <mvo> good morning jibel
[08:05] <seb128> mvo, I will try that today
[08:05] <mvo> thx
[08:05] <seb128> mvo, update-notifier depends on synaptic for the "update index" and some other things we don't use in ubuntu since we don't have a systray
[08:05] <seb128> mvo, not sure if we could drop synaptic to a suggest or something
[08:05] <jibel> didrocks, bug 817896
[08:06] <ubot4> Launchpad bug 817896 in unity-2d (Ubuntu Oneiric) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QDeclarativePropertyPrivate::initProperty() (affects: 17) (dups: 17) (heat: 150)" [High,Confirmed] https://launchpad.net/bugs/817896
[08:06] <mvo> seb128: indeed, we should simply make it call aptdaemon via dbus and make it a or-depends
[08:06] <jibel> on a fresh install, login to Unity-2d and click on the launcher in
[08:08] <didrocks> jibel: hum, I was using this version and never got this crash, can you try something?
[08:08] <didrocks> jibel: like apt-get update && apt-get upgrade
[08:08] <didrocks> as you will get latest unity-2d
[08:09] <didrocks> and then reloading it and try the same thing?
[08:09] <didrocks> (the code in the launcher/place connect changed there)
[08:11] <didrocks> jibel: can you come on #ayatana? I just pinged Kaleo about it
[09:08] <jibel> Ubuntu Desktop and Alternate posted to the tracker
[09:11] <jibel> netboot posted too
[09:29] <jibel> No ubuntu dvd ?
[11:02] <jibel> xubuntu desktop|alternate 20110802 posted
[11:52] <didrocks> jibel: so, I have a new unity-2d built and tested there
[11:52] <didrocks> fixing the 2 bugs
[11:52] <didrocks> should I push?
[12:03] <jibel> didrocks, bug 819727
[12:03] <ubot4> Launchpad bug 819727 in compiz (Ubuntu) "[Intel 945GME] Compiz crashes on startup (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/819727
[12:03] <jibel> I'll try to reproduce
[12:04] <didrocks> jibel: omer is just telling that he has some issue on intel on #ayatana
[12:04] <didrocks> jibel: maybe the same
[12:04] <didrocks> works well there on nvidia
[12:13] <didrocks> skaet: jibel: NCommander: so, new unity-2d release ready with the fix for two bugs: https://launchpad.net/unity-2d/+milestone/<IP_ADDRESS>, please tell me once I can upload it
[12:30] <jibel> bugbug 819739
[12:31] <jibel> bug 819739
[12:31] <ubot4> Launchpad bug 819739 in nux (Ubuntu Oneiric) (and 3 other projects) "compiz crashed with SIGSEGV in nux::IOpenGLVertexShader::IOpenGLVertexShader() (affects: 1) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/819739
[12:31] <jibel> (once is enough :))
[12:32] <seb128> jibel, do you get this bug?
[12:33] <jibel> seb128, yes
[12:34] <seb128> bug #819667 as well
[12:34] <ubot4> Launchpad bug 819667 in nux (Ubuntu) (and 2 other projects) "compiz crashed with SIGSEGV in nux::IOpenGLVertexShader::IOpenGLVertexShader() (affects: 1) (heat: 10)" [Critical,New] https://launchpad.net/bugs/819667
[12:36] <seb128> njpatel, ^
[12:36] <jibel> master is bug 819739
[12:36] <ubot4> Launchpad bug 819739 in nux (Ubuntu Oneiric) (and 3 other projects) "compiz crashed with SIGSEGV in nux::IOpenGLVertexShader::IOpenGLVertexShader() (affects: 2) (dups: 1) (heat: 20)" [Critical,Confirmed] https://launchpad.net/bugs/819739
[12:37] <seb128> didrocks, ^ just fyi in case you didn't read
[12:37] <jibel> seb128, we were talking about it on #ayatana
[12:37] <didrocks> seb128: we discussed about it on #ayatana
[12:37] <didrocks> damn, too slow!
[12:37] <didrocks> basically, jay's
[12:38] <seb128> didrocks, it's somewhat looking similar to the glew 1.6 issue
[12:38] <seb128> weird
[12:38] <jibel> there are many duplicates coming in.
[12:45] <seb128> yeah, you that broken on all intel I can see that
[12:48]  * didrocks gives a look at nux trunk
[12:49] <didrocks> I see some AsmShader change
[12:49] <didrocks> for "mem leak fixing"
[12:50] <seb128> didrocks, https://code.launchpad.net/~vanvugt/ubuntu/natty/nux/fix-785118/+merge/64275
[12:50] <seb128> you mean?
[12:51] <seb128> didrocks, well, let jay debug it, he replied on ayatana
[12:51] <didrocks> seb128: yeah, I was about it doing that :)
[12:51] <seb128> it's a bit weird that this commit would be driver specific
[12:52] <seb128> well I don't know enough about GL to say, I will let the pros work it out ;-)
[12:52] <didrocks> seb128: from my very limited understanding, there are two kind of shaders
[12:53] <didrocks> those used on intel/ATI, and those used on nvidia
[12:53] <didrocks> (and that's different files), so it can maybe affect only those
[12:53] <didrocks> but it's a rough guess, let's wait for ay :)
[12:53] <seb128> yeah, he seems to have a clue about the issue
[13:10] <ScottK> Did anyone here retry kdepim on armel?
[13:10] <ScottK> It restarted 4 hours ago and I'd like to find out why.
[13:16] <ScottK> Are we worrying about dvds this milestone?
[13:17] <stgraber> I always do (though that's limited to Edubuntu in my case ;))
[13:18] <ScottK> The last Kubuntu dvd livefs failed due to gcj installability.
[13:18] <ScottK> No idea if it's been fixed.
[13:19] <jibel> skaet, ^ ? I asked the same question for ubuntu this morning
[13:34] <utlemming> jamespage: are you around?
[13:34] <jamespage> utlemming: sure am
[13:35] <utlemming> so we have a fresh batch of AMI's that we built for Alpha3 using the new live-build stuff. It was suggested that we ask you to run a quick small scale test on them. Could we impose upon you to do so?
[13:46] <jamespage> utlemming - sure - do you have a specific build number to test?
[13:48] <utlemming> jamespage: :( we just found a bug that renders this build not so good -- so we have to rebuild first
[13:55] <skaet> Good morning all.
[13:57] <jamespage> utlemming: OK so I'll get things setup ready to go
[13:58] <utlemming> jamespage: thank you much
[14:03] <skaet> ScottK, jibel,  yes, we're trying for DVD unless there is some blocker on them.
[14:03] <ScottK> Someone ought to look into the gcj installability issue and see if it's fixed.
[14:07] <didrocks> hey skaet! did you see my ping about unity-2d?
[14:07] <skaet> didrocks,  yup,  go ahead and upload
[14:07]  * didrocks does
[14:07] <skaet> faster we get these bugs fixed the better.
[14:07] <didrocks> skaet: seems there is a big issue with intel driver on unity (not 2d) from nux. jay is looking at it
[14:08] <skaet> didrocks,  re: nux.  thanks - keep me up to date.   BTW - did you see GrueMaster's post?   do any of these fixes make the ARM images work?
[14:08] <skaet> or is that still pending?
[14:09] <didrocks> skaet: hum, no I didn't see that post, what is it?
  Looks like a last minute upload of unity has once again clobbered the ubuntu-armel desktop images right before release testing.  Will need a respin so I have something to test tomorrow.
[14:10] <skaet> didrocks,  do I just need to kick off the armel builds,  or is there a bug that needs to be fixed.   I can't tell from his message.
[14:10] <didrocks> skaet: it's just that the armel builder was screwed yesterday evening, so a give back had to be done this morning
[14:11] <didrocks> and nux finished to build
[14:11] <GrueMaster> Morning, skaet.  Still no armel images.
[14:11] <GrueMaster> I think jani was looking at it, let me check.
[14:11] <didrocks> skaet: the builder wasn't ok yesterday at midnight (my time) when I looked at them
[14:12] <didrocks> unity is now built, so just have to wait for the new unity-2d to be built
[14:12] <GrueMaster> great
[14:13] <skaet> didrocks,  re: nux if it tests out sane (and fixes the bug) please upload,  and I'll kick off a set of rebuilds as soon as they publish.
[14:13] <didrocks> however, with nux needed an upload once the intel issue fixed, this will still take time…
[14:13] <didrocks> skaet: sure, let me get more info, a fix was under work half an hour ago
[14:14] <skaet> didrocks, thanks!  let me know the ETA on starting off the rebuilds.
[14:14] <didrocks> skaet: trying to get some inffo…
[14:14] <didrocks> info*
[14:32] <skaet> ScottK,  kicked off a Kubuntu DVD build.   There were some 20110801 images that were built late in the day yesterday (UTC time)- was there a problem with those,  or they just didn't get published?
[14:32] <ScottK> Thanks.
[14:33] <ScottK> Dunno, the mail I got today said gcj was uninstallable on the dvds
[14:35] <micahg> skaet: someone uploaded gnumeric without goffice, this will break xubuntu and lubuntu if a respin happens, should I upload goffice now?
[14:36] <charlie-tca> skaet: ^ ^
[14:36] <skaet> micahg,  yes please
[14:36] <micahg> skaet: k, thanks
[14:36] <charlie-tca> Thank you, micahg and skaet
[14:37] <ScottK> micahg: Someone was angelabad.  You might want to have a conversation with him about freezes.
[14:37] <micahg> ScottK: I know, this is also why MOTU shouldn't be able to upload stuff in seeds :)
[14:38] <ScottK> No, this is why it needs to be obvious in the tools what's in seeds and MOTU need to pay attention to it.
[14:38] <micahg> k, fair enough
[14:38] <micahg> but I will send an e-mail
[14:44] <micahg> is there an archive admin that can sync goffice 0.8.17-1?  if not, I'll use syncpackage
[14:47] <superm1> charlie-tca, did you see 819617 on xubuntu too?  I expect you should have..
[14:48] <charlie-tca> broken icon, yes. But I do get an internet connection here
[14:48] <charlie-tca> I haven't tried with wireless yet
[14:48] <superm1> do you actually see items for the ethernet connection to turn on and off in that list though?
[14:49] <superm1> if i just plug in a cable it "works", but the U/I doesn't have anything in it regarding the connection
[14:50] <charlie-tca> no, I don't have items like eth0 in there, I have edit connections and connection info
[14:50] <superm1> okay so same situation there then
[14:50] <charlie-tca> Okay, I will add it to my tracker bugs
[14:50] <micahg> AA no longer needed by me, Riddell did the sync
[14:51] <charlie-tca> superm1: thanks for that one. I haven't been paying attention to it because my connection works
[14:55] <skaet> micahg, Riddell - thanks!
[15:01] <ScottK> My powerpc seed changes way overshot the mark and will have to be reverted.
[15:01] <ScottK> That'll require a respin for the new meta.
[15:03] <NCommander> didrocks: feel free to upload unity-2d;
[15:03] <didrocks> NCommander: done already :)
[15:03] <didrocks> and nux as well :)
[15:03] <NCommander> ah
[15:03] <NCommander> then I shall smack the manual rebuild button in a little bit
[15:08] <didrocks> NCommander: yeah, wait for nux, I would say, it will be the longest
[15:08] <skaet> NCommander,  good morning.  Thanks,  will turn the rebuild trigger over to you.
[15:15] <skaet> ScottK,  Kubuntu DVD's posted
[15:15] <ScottK> skaet: OK.  Getting CD size fixed for powerpc is my current priority.
[15:16] <ScottK> Just uploaded a new kubuntu-meta.  Once that's built/published I'll want a kubuntu live powerpc respin to see if it fits now.
[15:26] <ScottK> NCommander: kubuntu-meta on powerpc is built.  Could I have a kubuntu live (powerpc only) respin in ~80 minutes?
[15:57] <charlie-tca> superm1: got all the devices in an install of alpha3, but not on live session
[15:58] <superm1> charlie-tca, oh weird.
[16:01] <charlie-tca> Have to think it has something to do with lightdm not working for us yet
[16:01] <charlie-tca> We don't get a default session and we do not get the list of users anymore.
[16:02] <superm1> you need to install accountsservice for the list of users
[16:03] <NCommander> ScottK: not a problem, one respin, hgold the onions in 60 minutes from this point
[16:04] <ScottK> Even 45 would work.
[16:04] <ScottK> Thanks.
[17:05] <didrocks> NCommander: I think nux is published now (at least i386 and amd64)
[17:19] <micahg> seb128: was there anything specific in the gnome-games upload that was need?  it's seeded in xubuntu as well
[17:19] <micahg> (i.e. do we need a respin for something in it)
[17:19] <seb128> micahg, there was a depends missing which made a game on the CD not start
[17:19] <seb128> but it's only a game
[17:19] <seb128> i.e sudoku
[17:19] <micahg> yeah, we have that one..
[17:19] <seb128> gnome-sudoku
[17:19] <micahg> charlie-tca: ^^
[17:20] <seb128> but having a game not working in an alpha is not the end of the world
[17:20] <seb128> not sure it's worth a respin by itself
[17:20] <seb128> I uploaded so it's picked if there is a respin for another reason
[17:20] <micahg> seb128: there are other things as well that we've been considering
[17:20] <micahg> seb128: thanks
[17:20] <seb128> yw
[17:41] <charlie-tca> skaet: I am going to upload a new xubuntu-meta for alpha3 and ask for a respin. Is that okay?
[17:43] <skaet> charlie-tca,  yes,  go ahead.
[17:43] <skaet> NCommander,  what order are the rebuilds working in?
[17:44] <charlie-tca> Thank you, skaet
[17:48] <charlie-tca> NCommander: will need a respin of Xubuntu images in 1.5 hours
[17:56] <charlie-tca> NCommander: I am told to hold off on that until we get the changes done for sure.
[17:59]  * skaet appreciates "for sure" with careful testing ;)
[18:04] <skaet> didrocks, seb128 - NCommander must have stepped away and I'm not seeing activity on the image builder.   Are we good from your perspective now to respin the images,  or still waiting for something?
[18:45] <seb128> skaet, sorry I was away for dinner
[18:46] <seb128> skaet, yes, everything is ok from the desktop side
[18:46] <skaet> seb128,  no worries.
[18:46] <skaet> ok,  starting the respinning of ubuntu desktop now
[18:46] <seb128> thanks
[18:48] <skaet> NCommander,  FYI:   have kicked off:
[18:48] <skaet> echo building ubuntu daily; for-project ubuntu cron.daily;
[18:48] <skaet> echo building ubuntu daily-live; buildlive ubuntu daily-live && for-project ubuntu cron.daily-live;
[18:48] <skaet> echo building ubuntu server; for-project ubuntu-server cron.daily
[18:48] <skaet> echo building ubuntu daily-preinstalled (x86); buildlive ubuntu daily-preinstalled && for-project ubuntu cron.daily-preinstalled;
[18:48] <skaet> echo building ubuntu dvd; buildlive ubuntu-dvd dvd && for-project ubuntu cron.dvd;
[18:48] <skaet> echo building ubuntu core; buildlive ubuntu-core ubuntu-core; build-livecd-base ubuntu-core;
[18:51]  * NCommander isback from lunch
[19:08] <GrueMaster> skaet: I hear we are respinning armel server?  What changed?
[19:09] <SpamapS> Is it alright to upload minor stuff to universe right now?
[19:09] <micahg> SpamapS: you can upload stuff that isn't seeded
[19:09] <skaet> GrueMaster,  if server images posted right now are good, we won't repost them.   Basically just redoing the full set to pick up all the changes on desktop.
[19:10] <SpamapS> micahg: heh.. are we finally going to start using the proper terms now? :)
[19:10] <GrueMaster> Ok, that's what I thought.  No show stoppers on server that I have seen.
[19:10]  * SpamapS is almost done w/ RAID1 tests on amd64 server
[19:11] <GrueMaster> I understand the need for desktop respin (unity-2d, etc).
[19:11] <micahg> SpamapS: there are 4 derivatives seeded from universe, so I hope so :)
[19:12] <SpamapS> micahg: and how does one see, easily, whether something is seeded? (Though I'd be shocked if my current upload were seeded)
[19:12] <micahg> I check tasks on binaries, but that's not entirely foolproof
[19:13] <SpamapS> Need something like rmadison for that
[19:14] <charlie-tca> Can we respin all xubuntu images, please?
[19:15] <skaet> charlie-tca, will do.
[19:15] <skaet> stgraber,  I'm assuing edubuntu wants a respin too?
[19:16] <micahg> gilir, superm1: FYI, chromium was just uploaded
[19:16] <stgraber> skaet: yep. I haven't even tested the current build anyway :)
[19:17] <skaet> stgrber, charlie-tca - ok, both flavors marked for rebuild.
[19:17] <charlie-tca> Thank you
[19:17] <charlie-tca> Hopefully, got a couple of those bugs nailed this time
[19:21] <skaet> charlie-tca, :)  yup.  fingers crossed.   All the pieces uploaded & published or are we waiting for some last bits?
[19:21] <charlie-tca> micahg: all done, right?
[19:22] <micahg> yeah, it was published an hour ago
[19:25] <skaet> Ubuntu Alternate 20110802.1 now posted (i386, amd64, amd64+mac, powerpc)
[19:35] <ScottK> NCommander: I don't see any evidence the powerpc rebuild finished?
[19:37] <ScottK> slangasek: The binaries for smokekde all landed in Universe for armel and powerpc.  They are in component mismatches for demotion, but perlkde is now FTBFS on armel/powerpc waiting for them.
[19:37] <ScottK> Could you promote them for now and we'll sort it out once we're done building all the bindings?
[19:39] <ScottK> (or any other archive admin who happens to be around)
[19:50] <ScottK> Actually, I think demoting perlkde source is the better solution.
[19:50] <ScottK> I shouldn't have accepted it into Main.
[19:54] <jibel> skaet, alternate i386|amd64 are ok. nux fix tested and verified on real hardware.
[19:55] <skaet> jibel, \o/
[19:56] <skaet> ScottK,  do you just need powerpc rebuild, or do you want a fresh set of all Kubuntu images?
[19:56] <ScottK> skaet: Just powerpc for now.
[19:56] <ScottK> No point in doing them all until I get that one to fit.
[19:57] <jibel> \o_
[19:57]  * jibel will raise the other hand once desktop images are verified
[20:10] <skaet> jibel,  looks like desktop's off the builder,  posting now.
[20:20] <skaet> jibel,  ubuntu desktop 20110802.1 now published (i386, amd64,  amd64+mac, powerpc).
[20:40] <jibel> ack
[20:40] <jibel> bug 819609 is a regression
[20:40] <ubot4> Launchpad bug 819609 in lightdm (Ubuntu Oneiric) (and 3 other projects) "Oneiric live CD boots to login screen (affects: 5) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/819609
[20:53]  * SpamapS drums fingers as RAID1 volumes rebuild.. slowly...
[20:57] <jibel> skaet, I'll keep my hand low.
[20:57] <jibel> bug 819609
[20:57] <ubot4> Launchpad bug 819609 in lightdm (Ubuntu Oneiric) (and 3 other projects) "Oneiric live CD boots to login screen (affects: 6) (heat: 30)" [High,Triaged] https://launchpad.net/bugs/819609
[20:57] <jibel> not that one
[20:57] <jibel> bug 820036
[20:57] <ubot4> Launchpad bug 820036 in casper (Ubuntu Oneiric) (and 1 other project) "User can not start ubiquity from a live session (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820036
[20:58] <skaet> jibel,  ack.
[20:58] <skaet> slangasek, can you look at bug 820036?
[20:58] <ubot4> Launchpad bug 820036 in casper (Ubuntu Oneiric) (and 1 other project) "User can not start ubiquity from a live session (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820036
[20:59] <slangasek> ScottK: perlkde demoted, per your last comment
[20:59] <slangasek> skaet: ah, I'll have a look, not sure how much headway I'll make
[21:00] <slangasek> anyone in #ubuntu-installer right now?
[21:00] <slangasek> might be a desktop bug anyway, for that matter
[21:01] <skaet> stgraber, ^^ can you have a look at this and help us figure it out?
[21:03] <stgraber> skaet: yep, let me grab a desktop image. Should be able to start poking at it in the next 30min
[21:03] <skaet> stgraber,  thanks!
[21:04] <stgraber> skaet: not sure if someone aleady told you but the version numbers on iso.qa.u.c are wrong so the download links fail
[21:06] <skaet> stgraber, nope didn't know that.
[21:06]  * skaet looking
[21:07] <stgraber> there's an extra 0 in there
[21:07] <stgraber> I guess the easiest is to change the version number directly in the DB to avoid loosing results
[21:08] <jibel> stgraber, it could be a regression of what cjwatson fixed in bug 797669
[21:08] <ubot4> Launchpad bug 797669 in user-setup (Ubuntu Oneiric) (and 5 other projects) "No autologin on live session with lightdm (affects: 1) (heat: 70)" [High,Fix released] https://launchpad.net/bugs/797669
[21:08] <jibel> skaet, stgraber I'll fix the version number. no big deal
[21:09] <skaet> jibel,  thanks!
[21:09] <jibel> and both bugs 819609 and 820036 are probably linked
[21:09] <ubot4> Launchpad bug 819609 in lightdm (Ubuntu Oneiric) (and 3 other projects) "Oneiric live CD boots to login screen (affects: 7) (dups: 1) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/819609
[21:09] <ubot4> Launchpad bug 820036 in casper (Ubuntu Oneiric) (and 1 other project) "User can not start ubiquity from a live session (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820036
[21:10] <stgraber> yeah, sounds like some casper scripts not running or not doing what they should. Should have a desktop iso in the next 5 minutes if rsync continues at this rate
[21:11] <ScottK> slangasek: Thanks.
[21:17] <utlemming> ping slangasek or skaet
[21:18] <skaet> yup utlemming?
[21:18] <utlemming> so it looks like we have a good EC2 build of 20110802.2
[21:19] <utlemming> can we enable iso tracker for them?
[21:19] <skaet> utlemming,  yes please.
[21:21] <utlemming> skaet: actually according to smoser, I need to ask one of you to do that for me :)
[21:21] <utlemming> I don't know if I have rights to do it
[21:23] <stgraber> jibel: ubiquity starts fine here
[21:23] <skaet> utlemming.  fair enough.   We usually get a link from smoser to where the images are.
[21:23] <stgraber> jibel: with 20110802.1 amd64
[21:23] <utlemming> ah...one minute
[21:24] <stgraber> jibel: I got the lightdm prompt, logged in as "ubuntu" with no password. Clicked on Install ubuntu and got ubiquity
[21:25] <jibel> stgraber, oh, was I logged as guest maybe. let me try again.
[21:26] <stgraber> jibel: yeah, I don't think the guest user is part of the admin/sudo group so it won't be able to start ubiquity
[21:26] <stgraber> ubuntu/<no password> is the usual livecd user and the one that will be used whenever lightdm does autologin :)
[21:30] <stgraber> ok, so from what I quickly checked the problem is that we don't have a /etc/lightdm/lightdm.conf so Colin's casper script won't configure autologin
[21:30] <jibel> stgraber, phew, that's it. I must have clicked on guest. Thanks for double checking.
[21:30]  * skaet breaths a sigh of relief.....
[21:30] <skaet> Thanks stgraber. :)
[21:31] <slangasek> right, I was just about to ask why it wasn't auto-logging here :)
[21:31] <stgraber> skaet: no prob. Now trying to figure out where /etc/lightdm/lightdm.conf went...
[21:31] <stgraber> I have it on my system but don't on the livefs...
[21:32] <utlemming> skaet: here's the link http://uec-images.ubuntu.com/oneiric/20110802.2
[21:32] <skaet> thanks utlemming
[21:33] <utlemming> :) thank you
[21:37] <stgraber>   * debian/lightdm.conf:
[21:37] <stgraber>     - Removed, no longer needs configuration
[21:37] <stgraber> I guess that explains it...
[21:41] <skaet> ScottK, the kubuntu desktop powerpc image is posted now
[21:41] <stgraber> ok, I "think" I have a "fix".
[21:41] <ScottK> Thanks.
[21:42] <ScottK> Dropping OOo off powerpc saved over 70MB.
[21:42] <ScottK> skaet: If you could do i386 and amd64 now, I think we're good.
[21:43] <skaet> ScottK,  queued up for after Edubuntu and Xubuntu
[21:44] <stgraber> skaet: I'm guessing we want lightdm autologin fixed for alpha-3? (just to confirm before I upload a new casper)
[21:44] <skaet> stgraber, yes please
[21:44] <ScottK> Thanks.
[21:52] <stgraber> skaet: uploaded (tested as well as you can test a livefs casper script...)
[21:55] <jibel> slangasek, stgraber skaet NCommander : quick A3 testing status before going to meet morpheus
[21:55] <jibel> apart from 819609 other notable issues with A3
[21:56] <jibel> bug 819904
[21:56] <ubot4> Launchpad bug 819904 in casper (Ubuntu Oneiric) (and 1 other project) "Shutdown doesn't works in live session (affects: 5) (dups: 1) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/819904
[21:56] <jibel> bug 819616 (maybe regression ?)
[21:56] <ubot4> Launchpad bug 819616 in ubiquity (Ubuntu Oneiric) (and 1 other project) "automatic login was not enabled even though checked in the installation (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/819616
[21:56] <jibel> Other bugs reported are "known issues that should be fixed before FF" or cosmetic issues
[21:57] <jibel> good night everyone. Let me know if there are images to post tomorrow morning European time.
[22:02] <skaet> Thanks jibel
[22:03] <skaet> will leave a post in this and the testing channel if there are likely to be images waiting for you to come online.
[22:09] <skaet> Ubuntu DVD 20110802.1 (i386,amd64) posted
[22:10] <ScottK> skaet: We'll need Kubuntu DVD on i386, amd64 at some point too.
[22:17] <skaet> ScottK, ack
[22:34] <skaet> utlemming,  uec images posted now to the tracker.
[22:34] <utlemming> skaet: much thanks
[22:46] <GrueMaster> What's the scoop on Ubuntu-armel-desktop?
[22:46] <stgraber> disappearing for a while. Feel free to SMS/call me on my cell if I screwed up the casper upload (hopefully I didn't :))
[22:47] <slangasek> GrueMaster: at last look it was failing due to unity non-installability; has that been fixed?
[22:47] <skaet> thanks stgraber,  when you get a chance could you look at the others that jibel mentioned above?
[22:48] <GrueMaster> I don't know, but I will shortly.  I'm doing a netinstall with ubuntu-desktop selected.
[22:49] <GrueMaster> Grr.  Looks like I'm seeing a dependency issue on linux-headers-omap.
[22:49] <slangasek> blah, why is the subarch name still in the livefs logfile directory name
[22:49] <slangasek> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu-omap/20110802/livecd-20110802-armel.out - unity uninstallable
[22:49] <GrueMaster> sigh.
[22:50] <slangasek> but maybe it's built since then, checking
[22:50] <slangasek> NCommander: have you looked at this already, by chance?
[22:50] <GrueMaster> he's out apparently.
[22:51] <slangasek> last build attempt was before unity built
[22:51] <slangasek> will retry
[22:51] <GrueMaster> ok, thanks.
[22:51] <skaet> slangasek,  there may be some still building.
[22:51] <skaet> Ncommander started of a set before he left.
[22:51]  * skaet goes to look closer
[22:52] <slangasek> ah
[22:52] <slangasek> yep, there they are
[22:52] <superm1> stgraber, for the casper upload, it doesn't fix derivatives
[22:53] <superm1> only standard ubuntu
[22:53] <superm1> the situation won't be any worse for derivatives though at least
[22:53] <skaet> slangasek,  yeah but they haven't triggerer from what I can tell.
[22:58] <skaet> slangasek, NCommander,  have disabled the crontab,  so we don't have to deal with cross effects for now.
[23:02]  * slangasek nods
[23:36] <SpamapS> Hrm, why was server re-spun?
[23:37] <skaet> SpamapS, was respinning all of the Ubuntu images, and did that one as well.   Since testing on the existing one hadn't gotten too far,  Daviey and hggdh said they'd pick it up.
[23:38] <SpamapS> just wondering if the respin affects my almost done RAID1 test. :-P
[23:38] <SpamapS> I really don't want to do it again.. it takes 2 hours :-P
[23:39] <skaet> SpamapS,  don't think it should,  mostly it was to pick up desktop changes.
[23:40] <GrueMaster> SpamapS: Try doing a raid on a Panda with USB drives.  Especially given bug 709245.
[23:40] <ubot4> Launchpad bug 709245 in linux-ti-omap4 (Ubuntu Oneiric) (and 3 other projects) "panda: USB disk IO slow (affects: 7) (dups: 1) (heat: 46)" [High,Confirmed] https://launchpad.net/bugs/709245
[23:40] <skaet> skaet,  but probably prudent to double check the package lists, and confirm no package that was useful for the test was affected.
[23:41] <skaet> SpamapS, ^^ even
[23:41] <NCommander> skaet: we should probably have a cron-disable script :-/
[23:41] <SpamapS> skaet: talking to yourself.. and its only a3? We'll have to schedule a spa visit for you after b1 ;)
[23:41] <skaet> NCommander,  heh,  feel free to write one in your spare time... contributions welcome.
[23:42] <skaet> SpamapS, lol,  indeed.
[23:42]  * skaet is quite fond of spa visits :)
[23:43] <NCommander> SpamapS: its just the sign of a release manager becoming a veteran. Mental trama andall that
[23:44] <skaet> lol,  yeah its been an interesting sort of day.  :)
[23:44] <charlie-tca> Well, at least it's Tuesday this time
[23:44]  * skaet is very glad we froze yesterday.  :)
[23:45] <NCommander> Meh, wish we could sort the alpha 3 tagged bugs by priority
[23:45]  * NCommander is going through the list
[23:45] <micahg> NCommander: using advanced search you should be able to
[23:45] <skaet> Edubuntu DVD 20110802.1 is now posted
[23:46] <skaet> charlie-tca,  Xubuntu now building
[23:46] <NCommander> bah my build script failed
[23:46] <skaet> NCommander, what happened with those ARM builds from earlier?
[23:46] <skaet> heh
[23:46]  * NCommander had an unexpected linebreak
[23:46] <charlie-tca> Thanks!
[23:46] <NCommander> all the buildlive parts ran so it shouldn't take long to actually build everything
[23:47] <skaet> NCommander,  coolio.  Post here and #ubuntu-testing as they emerge and get added.
[23:48] <skaet> NCommander,  I've got Ubuntu preinstall building now.
[23:48] <NCommander> skaet: don't run the buildlive part, that completed successfully
[23:50] <skaet> NCommander, its been running for a couple of hours right now... so the buildlive may be from that.  Not sure.
[23:51] <SpamapS> skaet: how do I determine the packages that were changed between 20110802 and 20110802.1 ?
[23:53] <NCommander> SpamapS: grab the manifest from 802 and 802.1 and run diff
[23:54] <SpamapS> NCommander: danke
[23:56] <SpamapS> looks good.. nothing remotely related to the RAID test
[23:57] <hggdh> SpamapS: so you have RAID covered, correct?
[23:57] <SpamapS> hggdh: amd64 .. yes. :-P
[23:57]  * hggdh high-fives SpamapS
[23:57] <hggdh> oops
[23:58] <SpamapS> nearly done
[23:58] <SpamapS> This test is.. ridiculously long
[23:58]  * hggdh high-2.5s SpamapS
[23:58] <SpamapS> did find one bug
[23:58] <SpamapS> which I introduced myself.. :-P
[23:58] <hggdh> which one?
[23:58] <hggdh> LOL
[23:58] <SpamapS> bug 820111
[23:58] <ubot4> Launchpad bug 820111 in mdadm (Ubuntu) "boot degraded question is asked twice (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/820111
[23:59] <SpamapS> Probably need sto be fixed for b1
[23:59] <hggdh> SpamapS: good to know, when I run raid for the i386 (unless you are willing to? ;-)


[19:05] <Unit193> Where'd all my snow and cold go?  I'm sad now.
[20:22] <PCLine__> I can send you a little snow if that would help you.


[22:59] <Unit193> mapreri: You do ubuntu-dev-tools, no?  `backportpackage` doesn't send 'Host' does it?  I get errors, Error: Server presented certificate that does not match host incoming.debian.org: {'subjectAltName': (('DNS', 'www.debian.org')  which would indicate that it doesn't.


[11:47] <akhil54> why vm from `ssh boost` is different from `multipass sh boost` because it not showing the my files that i downloaded when i ssh into the vm ?


[00:00] <broder> slangasek: understand is a pretty strong word. i don't think i ever reached a point of understanding
[00:00] <broder> just possibly a point of being able to apply grep and sed thoroughly enough
[00:03] <TheMuso> @pilot in
[00:05] <slangasek> broder: so, I have a partial patch that gets root-system part of the way through a build w/ multiarch, but for some reason I can't discern, it fails to build the kerberos module
[00:08] <Ampelbein> TheMuso: hi, could you have a look at bug 725044 and if it looks good sponsor the upload?
[00:11] <TheMuso> Ampelbein: I am actually looking at that merge proposal now. :)
[00:12] <Ampelbein> TheMuso: ah, cool ;-)
[00:15] <slangasek> broder: bug #745850 if you care to save it; if not I think removal is the right thing to do
[00:18] <broder> slangasek: i have no interest in saving it, i just didn't want to see kerberos maligned for someone else's issues
[00:18] <slangasek> :-)
[00:44] <GunnarHj> ScottK: ping?
[00:51] <Ampelbein> hmm, when installing gcj-4.4-jre-headless (4.4.5-15ubuntu2) it segfaults on the configure stage in a clean pbuilder environment, but not on my worksystem.
[00:52] <Ampelbein> it is the same error in pbuilder as appears on the official builders. https://launchpadlibrarian.net/67807729/buildlog_ubuntu-natty-i386.checkstyle_4.4%2Bdfsg-5_FAILEDTOBUILD.txt.gz
[01:15] <lifeless> kees: FYI cve pages are fixed
[01:35] <kees> lifeless: cool, thanks
[01:36] <lifeless> properly even :) - that huge one is down to 2 seconds render time
[02:48] <ScottK> GunnarHj: Pong
[02:54] <GunnarHj> ScottK: Hi Scott! It's about a gdm security update in lucid and maverick leading to the backports binaries no longer being the latest versions. I wanted to ask if there is some shortcut available for dealing with the issue. What I'm about to do is making new backports branches that include the update.
[02:54] <GunnarHj> ScottK: After having thought about it, I assume that this is a general problem with backports. Is it so?
[02:55] <ScottK> GunnarHj: That's the right thing to do.  Normally backports have enough higher version this doesn't come up.
[02:57] <micahg> this is actually good in this case
[02:59] <GunnarHj> ScottK, micahg: But would it have been appropriate to set a higher version? I mean, in that case the backports users would not have been notified about the security update, right?
[02:59] <ScottK> GunnarHj: Backports are unsupported, so that's not unusual.  It's like using a Universe package.
[02:59] <micahg> GunnarHj: well, the version was appropriate for what was backported
[03:00] <micahg> GunnarHj: in this case, the users are better off secure, than with the backport, the solution is to rebase the backport, sometimes packages are backported and not updated for security fixes which can be problematic for backports users
[03:05] <GunnarHj> ScottK, micahg: Think I got it. As regards typical backports, even if they are official, they are unsupported, and users install them on their own risk with respect to possible updates afterwards.
[03:06] <ScottK> Yes.
[03:06] <ScottK> Generally though it's easy enough to backport an update that has the relevant security fix.
[03:08] <GunnarHj> ScottK: But not quite as easy in this case... Guess I have myself to blame. ;-)
[03:09] <micahg> GunnarHj: nah, gdm's just not the normal fare for backports, usually with leaf packages, you just backport the latest version assuming it'll build/run
[03:09] <ScottK> Fortunately you can diff the security update from the base package and it should be ~easy to figure out how to update your backport.
[03:09] <ScottK> micahg: No, we test that it builds/runs.  Not much more though.
[03:10]  * micahg wonders what he said wrong
[03:10] <ScottK> In fact builds/installs/runs is the exact test criteria.
[03:12] <sbeattie> GunnarHj: FYI, bug 746796 is about the gdm backports issue.
[03:13] <GunnarHj> ScottK: Yeah, not saying it's _that_ difficult. Btw, considering it's gdm, can you upload the new branches, or should I ask someone in ubuntu-desktop?
[03:13] <sbeattie> GunnarHj: also, the patch fixed in USN-1099-1 is self-contained; I would be highly surprised if it didn't apply cleanly.
[03:13] <ScottK> Please find someone else as I've got a $WORK project that's due today.
[03:13] <ScottK> GunnarHj: ^^^
[03:17] <GunnarHj> sbeattie: I know. Bug 746694 too. Yes, I don't anticipate any problems. Thanks!
[03:20] <GunnarHj> ScottK, micahg, sbeattie: Going off keyboard. Thanks all for helping.
[03:22] <sbeattie> GunnarHj: okay. I'm stepping away for a while, too. If you have any questions about the update patch, feel free to poke me about it.
[04:03] <TheMuso> @pilot out
[04:03] <TheMuso>
[06:41] <micahg> StevenK: would you be available to add some binary overrides?
[06:41] <micahg> s/add/adjust/
[06:41] <StevenK> micahg: It depends -- are we still frozen?
[06:41] <micahg> StevenK: I don't think so
[06:42] <micahg> StevenK: this is for stable releases
[06:42] <StevenK> micahg: Er?
[06:42] <micahg> StevenK: security update for qt4-x11
[06:43] <StevenK> micahg: Okay, what do you need?
[06:43]  * micahg is getting the list
[06:49] <Dread> heya
[06:49] <Dread> latest updates screwed up my internet on my main machine
[06:49] <StevenK> micahg: It doesn't bode well that it's taken over 7 minutes to get the list.
[06:50] <micahg> StevenK: sorry, the script is inherently slow
[06:50]  * micahg has only needed to do this once before and forgot how slow it is
[06:50] <StevenK> micahg: Oh, you want a bunch of stuff copied from security to updates?
[06:50] <micahg> StevenK: no, there's a script that does that, I just need the overrides applied in -security
[06:56] <micahg> StevenK: http://paste.ubuntu.com/588128/, I'm still working on hardy, thanks
[07:03] <StevenK> micahg: All done.
[07:03] <micahg> StevenK: thanks, I'm fighting with the script at the moment for hardy, I might just make it manually if I can't get this to spit it out
[07:08] <micahg> StevenK: can you demote qt4-dev-tools and qt4-qtconfig in hardy-security?
[07:09] <StevenK> micahg: And not libqt4-core? That's been in every other.
[07:09] <micahg> StevenK: nope, that's in main in hardy
[07:10] <didrocks> good morning
[07:10] <StevenK> micahg: DOne.
[07:10] <micahg> StevenK: thanks!
[07:12] <StevenK> micahg: Welcome.
[07:14] <DreadKnight> was there some alternative network manager for natty? called conman or something?
[07:15] <DreadKnight> because latest updates broke my network manager, which makes my main machine kinda useless now
[07:15] <holstein> how about wicd ?
[07:16] <DreadKnight> hmm
[07:17] <DreadKnight> holstein: does it have indicator support by any chance?
[07:18] <RAOF> Connman is in the archives, yes.
[07:18] <ohsix> what broke?
[07:18] <DreadKnight> RAOF: so that's how you spell it xD geez
[07:19] <holstein> DreadKnight: well, it did
[07:19] <ohsix> nm has its own logging, you should probably look & report the breakage, chances are it isn't nm
[07:19] <holstein> not sure about how things are now though
[07:19] <holstein> i havent had a chance to look at wicd+natty
[07:19] <RAOF> Last time I tried it it was not particularly functional; it'd do brain-dead things like update hostname to a string based on the connection and wouldn't update routes when a wired connection got plugged in.
[07:19] <DreadKnight> fail
[07:20] <holstein> :/
[07:20] <ohsix> big fail
[07:20] <RAOF> DreadKnight: In short, I'd suggest working out why network manager isn't working and fix it :)
[07:21] <DreadKnight> I can fix other stuff, but when it comes to internet and not being able to at least have a wired connection...
[07:21] <DreadKnight> might as well reinstall or look for another distro :
[07:22] <holstein> theres other distros ?
[07:22] <holstein> ;)
[07:22] <holstein> DreadKnight: try updating a different way
[07:22] <holstein> aptitude or apt
[07:23] <DreadKnight> indeed....
[07:23] <ohsix> DreadKnight: what do you mean by not working, is the applet there?
[07:24] <DreadKnight> ohsix: it's there, but it's saying something like "device not administrated" (it's in my native language, sry for bad translation)
[07:24] <pitti> Good morning
[07:24] <ohsix> DreadKnight: ok, so that's working, you just need to find out why its ignoring the device
[07:25] <DreadKnight> ohsix: even got my restricted driver I didn't really needed and installed it..
[07:25] <holstein> DreadKnight: if you had a kernel update
[07:25] <holstein> try booting into the older one
[07:26] <DreadKnight> holstein: good idea; trying it
[07:27] <micahg> GunnarHj: did you test build, install, run the new version?
[07:27] <ohsix> hm /etc/NetworkManager/NetworkManager.conf references /etc/default/NetworkManager but it's not there
[07:28] <DreadKnight> ohsix: bad prank for 1 april i guess
[07:28] <ohsix> DreadKnight: i know it says that when i blacklist a device as unmanaged, but i do that in NetworkManager.conf, there are other places that can probably do it, i'd rule those out
[07:28] <ohsix> like /etc/network/interfaces
[07:28] <GunnarHj> micahg: I have test builds in my ppa.   Will test. Logging out for now. See you.
[07:31] <holstein> DreadKnight: im suspicious of the proprietary driver install you were talking about
[07:31] <holstein> you might want to look at that a bit more
[07:32] <DreadKnight> holstein: did that for the modem software; but was just a try out at fixing the issue
[07:33] <DreadKnight> probably I don't have anything to do with modems anyway
[07:34] <holstein> DreadKnight: i would probably sleep on it
[07:34] <holstein> and see if an update comes along that sorts you out
[07:35] <ohsix> that is, if you don't want to figure out what it is
[07:35] <DreadKnight> holstein: I won't be able to update anyway, would have to get packages on another machine in the best case scenario and move them via an usb hdd... but that makes things kinda complicates as I won't know when or what...
[07:35] <DreadKnight> d*
[07:35] <DreadKnight> and not even if*
[07:36] <holstein> i usually find that with things like that
[07:36] <holstein> its my own fault
[07:36] <ohsix> DreadKnight: hook it up to ethernet, dhclient eth0
[07:36] <holstein> im not saying thats the case with you
[07:37] <DreadKnight> ohsix: oh didn't know about that; getting another cable around :D
[07:37] <micahg> this conversation should probably move to #ubuntu+1 unless it's discovered there's a bug
[07:37] <ohsix> you're right, i'm over there too
[07:49] <DreadKnight> dhclient eth0 gives me some "Permission denied" errors
[07:49] <DreadKnight> SIOCSIFADDR: Permission denied
[07:50] <DreadKnight> and twitce for FLAGS
[07:50] <DreadKnight> SIOCSIFFLAGS: Permission denied that is
[07:50] <DreadKnight> ohsix: poke :D
[07:50] <ohsix> #ubuntu+1
[07:51] <GunnarHj> micahg: Still there? They both install and run fine.
[07:52] <micahg> GunnarHj: ok, I can't ACK it, as I'm not officially a backporter, but change the statuses to new, give a link to your built packages if they're not there already, and add an install/run comment to the bug
[07:56] <micahg> GunnarHj: actually, you can mark "confirmed" as you said it "runs well"
[07:56] <micahg> GunnarHj: BTW, what did you mean by:  Stupid arguments, btw.
[07:58] <GunnarHj> micahg: Done. I was talking about my own attempt to justify that I hadn't tested.
[07:59] <micahg> GunnarHj: ah :)
[08:00] <micahg> broder: do you have time to review a backport?
[08:00] <GunnarHj> micahg: If I understand it correctly, that's as long as you can help with it.
[08:00] <micahg> GunnarHj: yep, aside from trying to ping someone to review it :)
[08:01] <GunnarHj> micahg: You are too fast to me! :)
[08:03] <GunnarHj> micahg: Think I'll ask Martin. People tend to be nervous about everything gdm, and he is well updated on the backported changes.
[08:03] <micahg> GunnarHj: he's not a backporter AFAIK
[08:09] <GunnarHj> micahg: No... I know that a backporter is supposed to confirm that it's appropriate for -backports, but since Scott did that a few weeks ago, and I haven't changed anything, it should still be appropriate for -backports...
[08:10] <micahg> GunnarHj: right, but every upload requires the review again, should be a fast one if nothing changed :)
[08:18] <GunnarHj> pitti: Hi martin, any chance that you can upload the gdm branches linked to bug 746694? micahg has helped me as far as he can. No backporters review yet, but nothing in the backported code has been changed, Scott is off making money, and it's a little urgent. ;-)
[08:19]  * micahg doesn't claim to have reviewed the actual package, just that pieces are ready for a backporter to review
[08:27] <pitti> GunnarHj: will do; as this is a bug fix to an existing backport, it should be okay
[08:27] <GunnarHj> pitti: Great, thanks!
[08:28] <GunnarHj> micahg: ^^^
[08:29] <GunnarHj> micahg: Btw, thanks for helping out with this urgent issue. As usual I learned a thing or two. ;-)
[08:29] <micahg> broder: nevermind :)
[08:47] <micahg> pitti: do you think bug 747025 is critical?
[08:52] <mvo> dpm: do we have someone from the cjk community who could look at #206018 ? there is some config change in there for language-selector fontconfig magic, but I have no clue if it helps or not
[08:55] <pitti> micahg: ugh, indeed; targetted to natty
[08:55] <pitti> micahg: assigned to tim for checking/uploading
[08:55] <micahg> pitti: cool, thanks
[08:56] <dpm> morning mvo, let me ping the Chinese translation team, but I'm not sure they'll be able to do much, as I see some of them on the bug comments already
[08:56] <dholbach> good morning
[08:58] <mvo> dpm: well, if there is consens what to do I'm happy to do it :) but I can't judge whether or not its a improvement so I need someone with that knowledge to help
[08:59] <mvo> dpm: if we shouldn't do anything about it, it would be good to close it as "opinion"
[09:01] <dpm> mvo, ack. I can't find anyone around right now, but I'll try later on
[09:02] <mvo> dpm: thanks a bunch, not urgent, I just don't want to let it drop on the floor without some opinion
[09:02] <dpm> no worries :)
[09:58] <tkamppeter> pitti, hi
[09:59] <pitti> hey tkamppeter
[09:59] <tkamppeter> pitti, can you upload CUPS? It has 2 fixes queued on the BZR.
[10:03] <pitti> tkamppeter: sure
[10:11] <doko_> janimo: do you get emails about the arm-rebuild build failures?
[10:11] <janimo> doko_, I don't think I do
[10:12] <janimo> doko_, I got various FTBFS emails these days but they were PPA related and not all armels
[10:12] <janimo> some for Canonical-ARM ppa
[10:15] <doko_> hmm, so it didn;t help to create the test rebuild https://launchpad.net/ubuntu/+archive/test-rebuild-20110329-arm
[11:05] <pitti> GunnarHj: just looking at your gdm branches -- did you re-do them from scratch?
[11:06] <pitti> GunnarHj: I had expected that you'd just merge lp:ubuntu/maverick-security/gdm into your original one, and then just have a changelog which says "update to latest security update (LP: #746694)
[11:06] <pitti> GunnarHj: want me to reorganize the changelog accordingly?
[11:07] <pitti> GunnarHj: otherwise it looks fine
[11:13] <pitti> both uploaded
[11:16] <GunnarHj> pitti: Doing so was my first thought, but I became in doubt. I simply used Bazaar Explorer and uncommitted my revision, pulled the news from -update and committed my revision again.
[11:17] <pitti> GunnarHj: ok, all sponsored and approved
[11:17] <pitti> thanks!
[11:57] <cdbs> pitti: As for bug #722521 I tested the maverick fix on a newly-started EC2 instance. Since the proposed upload I have installed it on my instanced whenever I start a new one (this has happened 5-6 times). No regression. Would this be a verification of the SRU?
[12:01] <pitti> cdbs: sounds good, thanks for testing!
[12:01] <pitti> cdbs: can you please followup on the bug saying so?
[12:01] <cdbs> pitti: okay
[12:01] <cdbs> pitti: if I had known I would have done that quite a long time ago. I often keep building stuff on newly-started instances
[12:06] <cdbs> pitti: But I verified only on maverick, so should I tag it verification-done?
[12:06] <pitti> cdbs: I'll deal with this
[12:07] <cdbs> pitti: commented, thanks!
[12:14] <doko_> Daviey: could the server team have looks at the postfix and openldap build failures?
[12:31] <Daviey> doko_, yes, thanks for raising them.
[12:39] <Daviey> doko, hah, postfix builds fine... on checking, it seems slangasek multiarched it this morning. \o/
[13:03] <mdz> didrocks, silbs' crash is https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/747205
[13:04] <mdz> didrocks, I filed that by manually running apport-gpu-intel-error.py
[13:04] <mdz> so it's not exactly at the point where the problem occurred, but should have all of the debug
[13:05] <didrocks> mdz: thanks, I wasn't able to find a dup in launchpad, I'll ping your Xorg guys on that, still googling if something can be of help
[13:05] <mdz> didrocks, the dupe check found bug 721086
[13:06] <cdbs> pitti: Sorry for the late response but bug #747025 has an attached debdiff by me - still it was assigned to tgardner
[13:08] <didrocks> mdz: ok, that's nice to know, bryceh already look at something similar
[13:11] <didrocks> mdz: info sent FYI
[13:33] <pitti> cdbs: I assigned it to him for review/upload, as he uploaded the original change
[13:33] <cdbs> pitti: okay, thanks!
[13:42] <tjaalton> mdz, didrocks: sent it upstream, and I'll ask ickle to have a look
[13:49] <mdz> didrocks, info sent where?
[13:49] <tjaalton> hmm, do we not mount debugfs by default anymore?
[13:49] <pitti> tjaalton: we do, /sys/kernel/debug/
[13:49] <tjaalton> pitti: ok, thanks
[13:51] <tjaalton> mdz: can you get /sys/kernel/debug/dri/0/i915_error_state from the hung state and attach it to the bug?
[13:51] <mdz> tjaalton, no, sorry, Jane has rebooted
[13:52] <mdz> tjaalton, does the apport hook not collect that?
[13:52] <didrocks> mdz: pang the xorg guys directly as it's more in their field of competence ;)
[13:52] <mdz> i915_error_state: no error state collected
[13:52] <mdz> didrocks, ah, ok
[13:52] <tjaalton> mdz: it did for the other bug you linked to, don't know why not this time
[13:53] <tjaalton> maybe it doesn't include it if it contains just that
[13:53] <mdz> tjaalton, it's there: "no error state collected"
[13:53] <mdz> tjaalton, that's the actual contents
[13:53] <mdz> I think
[13:55] <tjaalton> mdz: ok, thanks for confirming
[13:55] <mdz> tjaalton, it just does this:     attach_file_if_exists(report, '/sys/kernel/debug/dri/0/i915_error_state', 'i915_error_state')
[13:58] <mdz> tjaalton, i915_debugfs.c:396:		seq_printf(m, "no error state collected\n");
[13:59] <tjaalton> mdz: yep, figured as much
[13:59] <tjaalton> ickle said it wasn't a hung gpu, but related to the drm error, and will follow up on the upstream bug later
[14:00] <doko> tkamppeter, pitti: could we re-add the dependency of ghostscript in gs-common for the release? just too many build failures left
[14:02] <pitti> no problem from my side; I still see about 20 reverse build deps, do they all fail because they mean "ghostscript" when they say "gs-common"?
[14:04] <doko> yes, /bin/sh: ps2pdf: not found
[14:10] <tgardner> pitti, I'm coming to the conclusion that conf files are a bad idea. if you screw them up then the carnage lasts forever. wrt module-init-tools, should I perpetuate the carnage, or just delete the conf files from the package and leave it at that? this version missed B1 so it won't be on a CD.
[14:10] <pitti> tgardner: I think in this case we can just have a preinst snippet which bluntly rm -f's it
[14:11] <pitti> tgardner: it's only been in natty for a day or two as you say, so we don't need to be concerned about keeping user changes
[14:11] <pitti> tgardner: please do check the dpkg --compare-version "$2" ..., though :)
[14:12] <tgardner> pitti, why bother? there is no version where intel-3945-iwlagn-disable11n.conf is valid.
[14:13] <pitti> tgardner: it might come back at some point, though
[14:13] <pitti> tgardner: it doesn't cost much and is safer
[14:13] <pitti> tgardner: but I guess we can drop the preinst code after beta-2 anyway?
[14:14] <tgardner> pitti, yes
[14:27] <tgardner> pitti, can you give this a quick look? https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/747025/comments/5
[14:39] <hallyn> interesting.  xdg-open does not fare well when executed 3 times in a row very fast (i.e. 'for x in 1 2 3; do xdg-open http://bugs.launchpad.net/$x; done').  Wonder if this is an actual bug in firefox
[14:43] <pitti> tgardner: re (sorry, door bell)
[14:44] <tgardner> pitti, np. I'm actually testing it first.
[14:46] <tgardner> pitti, ok, it appears to work as expected.
[14:47] <pitti> tgardner: with le -> le-nl it looks perfect
[14:47] <pitti> le won't do much harm, though
[14:48] <tgardner> pitti, how can the version be empty?
[14:49] <pitti> tgardner: on fresh installation
[14:49] <tgardner> pitti, hmm, ok
[14:59] <dpm> hi cjwatson, the e-mail announcement I sent yesterday about Ubuntu AppDeveloperWeek didn't seem to make it to ubuntu-devel. Could you approve it when you've got a minute? thanks!
[15:01] <pitti> dpm: ah, I only approved it to u-devel-announce@, I thought that was what you meant
[15:03] <dpm> pitti, yeah, I got confused because I thought only Colin was admin on ubuntu-devel, I've just noticed that it didn't make it there - thanks for approving it on -announce, though :)
[15:09] <cjwatson> dpm: done
[15:10] <dpm> awesome, thanks cjwatson :)
[16:24] <ScottK> mvo: Thanks for 745396.  Awesome responsiveness, much appreciated.
[16:24] <ScottK> mvo: BTW, LP changes for backports-not-automatic will land next week.  So we can (if the FFe is approved) actually turn that on this cycle.
[16:24] <Laney> \o/
[16:29] <mvo> ScottK: nice!
[17:58] <doko> pitti, seb128: what's the recipy for /bin/sed: can't read /usr/lib/libgobject-2.0.la: No such file or directory
[17:58] <doko> libtool: link: `/usr/lib/libgobject-2.0.la' is not a valid libtool archive
[17:58] <doko> make[2]: *** [bsepcmdevice-alsa.la] Error 1
[17:58] <doko> ?
[17:59] <seb128> doko, grep libgobject-2.0.la /usr/lib/*.la on the system where you build to figure what .la is buggy and get that one rebuilt
[17:59] <seb128> or clean_la-ed
[17:59] <pitti> because it's /usr/lib/x86_64-linux-gnu/libgobject-2.0.la now?
[18:01] <doko> pitti: maybe, packages in universe are a mess now :-/
[18:02] <micahg> slangasek posted a list the other day
[18:03] <slangasek> yes, sources needing no-change rebuilds for .la moves: http://people.canonical.com/~vorlon/broken-srcs-universe.txt
[18:03] <slangasek> (some of these may have already been rebuilt since the list was generated, I'll refresh it a bit later today)
[18:04] <doko> maybe we should give these packages in the test rebuild
[18:04] <penguin42> anyone fix a link typo on http://www.ubuntu.com/testing/natty/beta; the link to 'Download the Ubuntu 11.04 beta' goes to #Download%20Beta  where I think it should be #Download%20Beta%201
[18:21] <broder> slangasek, kklimonda_: did either of you start on the universe rebuilds? if not i'll just start working my way down from the top
[18:22] <slangasek> broder: I haven't started yet; let me regen the list right now and we can see what's been fixed already
[18:27] <kklimonda_> broder: I didn't have time yet, I hope to get some work done tomorrow.
[18:27] <slangasek> two fell off the list on their own, it seems
[18:27] <broder> cool. i'll start working from the top, then
[18:29]  * micahg was going to try to get a few on sunday at the global jam if time permits
[18:34] <bdmurray> @pilot_in
[18:34] <udevbot> Error: "pilot_in" is not a valid command.
[18:35] <broder> bdmurray: 2 words
[18:35] <bdmurray> broder: thanks
[18:35] <bdmurray> @pilot in
[18:39] <YokoZar> mvo: poke
[18:40] <YokoZar> mvo: I put in a bzr branch of app-install-data for you that cleans up an old wine workaround, but never actually told you :p
[18:55] <broder> slangasek: and you wanted me to start cleaning the .la files when i rebuild as well?
[18:55] <hrw> kklimonda_: will you attend UDS-O?
[18:56] <slangasek> broder: use your best judgement - the highest priority is to get them all rebuilt, but if we have time to also fix some along the way to proof them against future changes, that's better in the long run
[18:57] <micahg> well, now that we have the list, we can always "fix" them later
[18:58] <slangasek> yeah, though that's kinda double work
[18:59] <broder> i don't think it's too much trouble to take care of them now - there are fairly standard snippets for most of the standard build systems
[19:06] <kklimonda_> hrw: well, that depends. :)
[19:07] <kklimonda_> (on whether I'll get a sponsorship, or not)
[19:10] <slangasek> jani_: hmmm, why is removing the symbol from the .symbols file the right fix for bug #747047?  Symbols files exist to guard against accidental ABI changes that can break reverse-dependencies, is this symbol not needed here?
[19:15] <jani_> slangasek, from what I understood, the diff suggested by dh_shlibdeps is what is needed to fix such errors
[19:16] <slangasek> jani_: it's what's needed to *avoid* the error, but it takes someone looking at why the symbol is gone away to decide if this is a "fix" :)
[19:17] <jani_> slangasek, I admit I do not fully understend symbol files :)
[19:17] <jani_> so such fixes based on what dh_shlibdeps say are not actually fixes?
[19:18] <slangasek> jani_: so a previous version of the library in the libclutter-1.0-0 package exported a 'clutter_clone_get_paint_volume' symbol.  The package is configured with dpkg-gensymbols -c4 specifically to treat it as a fatal error when a symbol goes missing, because other packages in the archive may be relying on that symbol being available at runtime
[19:18] <jani_> so the bug is why the library no longer exports that?
[19:19] <slangasek> the questions then are: is the symbol's disappearance deliberate, or is it an accident?  And if it is deliberate, is it safe wrt the reverse-dependencies?
[19:20] <jani_> slangasek, just checked upstream
[19:20] <jani_> commit fd89dee1b01c01619110cd77968062aaf2a98b79
[19:20] <jani_> Author: Neil Roberts<EMAIL_ADDRESS>[19:20] <jani_> Date:   Fri Mar 18 14:09:57 2011 +0000
[19:20] <jani_>     clutter-clone: Make clutter_clone_get_paint_volume static
[19:20] <jani_>
[19:20] <jani_>     clutter_clone_get_paint_volume was being exported from the shared
[19:20] <jani_>     library because the function wasn't declared static. This function
[19:20] <jani_>     shouldn't be exposed because it should be accessed through
[19:20] <jani_>     clutter_actor_get_paint_volume.
[19:20] <slangasek> ok
[19:20] <jani_> so it is deliberate, as for reverse deps I don't know
[19:21] <jani_> from the description it seems it was not part of a publicised API
[19:22] <slangasek> so in fact the symbol disappeared on all architectures, and it's just the armel symbols file that didn't get updated
[19:22] <slangasek> so your change is fine :)
[19:22] <jani_> not sure why the armel file did not get updated as the others
[19:22] <jani_> phew
[19:32] <slangasek> jani_: probably because "all the others" shared a single .symbols file which is the one that got updated :)
[19:32] <slangasek> and if it builds on x86, it's good to upload ;)
[19:49] <broder> ok, maybe knowing the topo sort for these rebuilds would be helpful. the first two on the list depend on other rebuilds. oh well
[20:14] <broder> slangasek: hmm...are libraries that link multiarch'd libs supposed to have rpaths?
[20:18] <bdmurray> @pilot out
[20:25] <slangasek> broder: not *supposed* to, but that seems to be a common side-effect... will work on sorting that out in the next iteration
[20:25] <broder> slangasek: i actually have two packages that both use libtool, and it's only happening on one, which seems weird
[20:26] <broder> slangasek: but i won't worry about it too much
[20:27] <slangasek> yes, the principal problem with rpath is that it makes directory transitions hard later; temporarily introducing them as /part/ of a transition is no big deal as long as we eventually fix it up
[20:54] <hallyn> zul: is there anything you want from me for the lxc dput?  (i.e. if you don't want to 'bzr bd -S' it for some reason)  if not, i'll mark it as 'done' in my list.
[21:00] <bdmurray> @pilot in
[21:51] <broder> doko: did the ftbfs page for your most recent rebuild stop getting updated? the list of universe failures looks way too short
[21:52] <broder> oh, i guess the package i was curious about just hasn't built yet
[21:53] <slangasek> I don't know how frequent the job is that updates the page, but I think it's "not frequent"
[21:55]  * micahg thought it was once an hour
[21:56] <micahg> The status pages are updated hourly
[21:57] <slangasek> ok
[21:58] <broder> i'm starting on the lib* packages in an attempt to wriggle out of the dependency hell, which the rebuild hasn't gotten to yet
[21:58]  * slangasek nods
[21:58] <slangasek> I started from the tail end; currently stabbing xmlrpc-epi, which has some sick and wrong hard-coding of libexpat.la
[22:42] <Keybuk> jono: jef!
[22:45] <slangasek> Keybuk: is that your safe word?
[22:45] <Keybuk> slangasek: "the safe word for tonight is 'Spatula'"
[22:45]  * slangasek nods
[22:46] <chrisccoulson> it's been quite an entertaining april 1st today ;)
[22:46] <jono> Keybuk, LOL!
[22:46] <chrisccoulson> hi jono!
[22:47] <jono> hey chrisccoulson :-)
[22:49] <jdong> sigh, I love you, eclipse
[22:49] <jdong> "The word 'strex' is not correctly spelled". Quick fix #1 is to correct to "straw"
[22:51] <bdmurray> @pilot out


[00:00] <asac> maybe you did that once
[00:00] <Jazzva> yeaah, sounds possible :)
[00:00] <asac> that would also explain why you dont see a warning with my patch ;)
[00:00] <asac> it uses the same pref
[00:03] <Jazzva> what is the name of the pref?
[00:03] <Jazzva> kept in about:config?
[00:05] <asac> Jazzva: not sure
[00:05] <asac> warnonclose
[00:05] <asac> or something
[00:05] <Jazzva> ok
[00:05] <asac> or *tabs*
[00:05] <Jazzva> thanks
[00:06] <Jazzva> browser.warnonrestart. that's the only that is modified
[00:07] <Jazzva> yep... here's the dialog :)
[00:42] <asac> ok. i am off. most likely not back for ~26h from now ;)
[02:26] <saivann> asac : Just a little note : my ethernet card on my laptop now works correctly with latest network-manager update in the PPA. The bug isn't here anymore.
[14:27] <Jazzva> Volans, you and gnomefreak have prepared meeting schedule for the next six months?
[14:28] <Jazzva> I'm updating the minutes from the last meeting... I would like to know if I can set it to "Done" :)
[14:28] <Volans> Hi Jazzva, yes
[14:28] <Jazzva> Volans, great :)
[14:28] <Volans> the only thing I don't know is if gnomefreak have reserved the meeting channel for all the dates
[14:28] <Volans> (if this is possible)
[14:29] <Volans> or will ask the fridge guys every month or two
[14:29] <Jazzva> ok, I'll take it as done :)
[14:29] <Jazzva> reserving shouldn't be a big problem :)
[14:30] <Volans> ok, also an automatic system of email alert in the mailing list is done
[14:30] <Jazzva> noticed :)
[14:30] <Volans> perhaps you have read the email today morning at 9
[14:30] <Jazzva> yep :)
[14:31] <Jazzva> If anyone care to review https://wiki.ubuntu.com/MozillaTeam/Extensions/Team (new page) and https://wiki.ubuntu.com/MozillaTeam/Extensions/Packaging (Update section), I'd be thankful... just to know if it's readable enough :)
[14:34] <Volans> the first one is clear and shor... +1 :) looks at the second one
[14:35] <Jazzva> yay :).
[14:36] <Volans> Jazzva: just a note... in the MozillaTeam page I don't see any reference to the Extensions page... how an interested people can find that page?
[14:37] <Jazzva> Through MozillaTeam/Extensions/ page, which I'm writing now
[14:37] <Jazzva> There'll be a pointer on MozillaTeam/ page to that one...
[14:37] <Volans> ok, perfect
[14:39] <Volans> a note on the Packaging page, on the requisites, maybe change at the second line: "packages:" -> "Ubuntu installation with those packages installed:" or similar and specify if the latest ubuntu is needed or also a previous version can be enough
[14:39] <Jazzva> right...
[14:39] <Jazzva> maybe Ubuntu's is expected if someone's reading that page ;)
[14:40] <Jazzva> then again, better be safe than sorry :)
[14:40] <Volans> of course but perhaps I can understand that I can build those extensions also in another distro, debian for example
[14:40] <Jazzva> right :)
[14:42] <Volans> the bzr branch of XPI.TEMPLATE is repeated in the prerequisited and in the packaging procedure
[14:43] <Jazzva> maybe someone skips the prerequisites :). I don't think it's really a problem if it's mentioned twice.
[14:44] <Volans> maybe can be useful to point in the " create an upstream branch in the firefox-extensions" paragraph to add a LICENSE file in the root dir of the upstream branch
[14:45] <Jazzva> license file should be there...
[14:45] <Jazzva> and added by upstream.
[14:45] <Volans> or just a reminder to check that... I see that is a common "bug" in the packaging process
[14:45] <Jazzva> in case it's not there, then we contact upstream to provide one, and stop packaging until then. the extension goes to "missing details" table :)
[14:46] <Jazzva> a reminder is good :)
[14:51] <Volans> very good page for me! Just to make it even better a note on the update procedure for extension packaged in previous Ubuntu releases (backports) can be added
[14:52] <Jazzva> hmm... well, to put a link to the usual backports page. I think it should be the same: get into current release, prepare a backport, file a bug :)
[14:52] <Volans> ok
[15:04] <Jazzva> Volans, I added your suggestions
[15:04] <Jazzva> also, this is finished https://wiki.ubuntu.com/MozillaTeam/Extensions
[15:04] <Jazzva> and now to add pointer on MozillaTeam
[15:05] <Volans> Jazzva: the pointer in the table SubPages is automatically added
[15:05] <Jazzva> huh?
[15:05] <Jazzva> oh, that one :)
[15:05] <Volans> https://wiki.ubuntu.com/MozillaTeam#head-ed7ac67f971a606328b0ec330cf62c6411913f2d
[15:06] <Volans> but adding a little paragraph explaining what is it is better
[15:06] <Jazzva> hmm... it might need some time to appear in SubPages
[15:06] <Jazzva> oh
[15:06] <Jazzva> it's there :)
[15:06] <Jazzva> I was looking for /MozillaTeam/Extensions :)
[15:08] <Volans> maybe I'm wrong but seems that in the MozillaTeam/Extensions there isn't a link to the MozillaTeam/Extensions/Team  page with title like "how to join us"
[15:09] <Jazzva> right :)
[15:09] <Jazzva> missed that one
[15:11] <Jazzva> done.
[15:12] <Volans> you can use the [[MailTo(ubuntu-mozillateam AT lists DOT ubuntu DOT com)]] to show the mailto: link to registered users that have made the login ;)
[15:12] <Jazzva> yeah :)...


[05:28] <alkisg> Hi, I'm developing an app called epoptes, where the epoptes-client part gets installed in clients, and on postinst it autodetects with avahi (or if not, it presends a debconf dialog) a public crypto key and the DNS name or IP of the server where the epoptes-server runs. It then saves that DNS name and uses it when the epoptes-client service starts on boot.
[05:28] <alkisg> My question is, where should the key+DNS name be saved? In /etc or in /var? And if I store it in /etc/default/epoptes, should that be a conffile, even if postinst will modify its contents?
[05:31] <RAOF> alkisg: I'd probably lean towards /etc, particularly since this seems like it's meant to be end-user-editable.  Which would mean it probably *should* be a conf-file, because you don't want it overwritten on updates.
[05:36] <alkisg> Thank you RAOF. My next question is, I'd like to minimize the cases where the debconf dialog is displayed. When the client service runs, it connects to the server and offers it a remote shell so that a sysadmin on the server can manage all the clients (execute commands etc) through a GUI. So it's somewhat security-sensitive.
[05:36] <alkisg> Would it be reasonable to assume that if only one such server is published on avahi at the time the client postinst runs, then this is the server from which the sysadmin will be controlling the clients, and not present a debconf confirmation/entry dialog in this case?
[05:37] <RAOF> I guess this depends on where you expect this to be deployed.
[05:38] <alkisg> School computer labs, mostly
[05:38] <alkisg> Where the teacher will be monitoring clients, executing commands on them tem
[05:38] <alkisg> *ec
[05:38] <alkisg> *etc, damn :)
[05:38] <RAOF> If this is intended to land in the main archive, then that seems insecure, as there are any number of systems that won't be on trusted networks.
[05:38] <alkisg> I'd like it to be included in universe, but no, not in main
[05:39] <RAOF> I don't think I'd automatically have it trust a machine it discovers via avahi.
[05:40] <alkisg> Ah, but I could use preseeding in order to automate installations, right?
[05:40] <alkisg> So if the sysadmin put the server name with preseeding, then I'd trust that avahi-published server with the same dns name...
[05:41] <alkisg> Does preseeding sound reasonable?
[05:47] <alkisg> Also, if the dns name goes in /etc and it's a conffile that was changed in postinst, that will prompt the user on upgrades. I think there's a configuration mechanism that somehow marks that file so that no prompt appears if the user didn't manually edit the file, how's that mechanism called? UCF?
[05:48] <RAOF> Yeah, preseeding would be reasonable.  And, now that I think of it, as long as your postinst respects any existing file, it doesn't need to be marked as a conffile.
[05:48] <alkisg> Thank you very much :)
[06:56] <Angelo> hello
[07:08] <dholbach> good morning
[07:09] <Angelo> dholbach: hi!
[07:09] <Angelo> :-)
[11:33] <handschuh> hi, what I am just wondering. is it allowed to include python "binary" code into source packages while java-bytecode is not allowed there?
[11:43] <Rhonda> Both is allowed along the same rules: If they get regenerated when producing the binary package and don't get installed directly into the binary package, they are accepted in the source package.
[11:45] <Rhonda> Under the assumption that those binaries are actually produced from the same set of source. But to assure that, the binary package is only allowed to contain binaries that are produced during the build process.
[11:46] <handschuh> What for example for binaries that are only needed for the build process and not for the actual package itself?
[11:47] <geser> handschuh: what you mean with "python binary code"?
[11:47] <handschuh> geser: for instance the waf "binary"
[11:47] <Rhonda> handschuh: binaries needed for the build process do require source-full rebuild too.
[11:47] <Rhonda> handschuh: Whether they end in the actual binary package or produce those binary packages isn't the difference here.
[11:48] <Rhonda> Included binaries in source packages are not allowed to be used in any sense, they need to be reproduced before from source.
[11:48] <handschuh> Rhonda: thats good to know, thank you. What if I find such a package in the universe repos?
[11:48] <Rhonda> The only exception here is obviously multiverse for which no source is required to be available. ;)
[11:49] <Rhonda> Then file a serious bugreport against them.
[11:49] <geser> handschuh: file a bug and let us know here
[11:49] <Rhonda> Because of policy violation.
[11:49] <handschuh> ok, I already did that with the bug report
[11:50] <tumbleweed> handschuh: can you tell us the bug number?
[11:50] <handschuh> 873003
[11:50] <Rhonda> bug #873003
[11:50] <tumbleweed> aah, waf
[11:50] <handschuh> yes waf
[11:50] <tumbleweed> waf is a special case of horribleness
[11:50] <handschuh> indeed!
[11:51] <handschuh> maybe the same holds for the midori package
[11:51] <handschuh> but I did NOT check that
[11:51] <Rhonda> It might be a horribleness, but that doesn't warrant an exception for main/universe
[11:52] <tumbleweed> well, waf can't be broken out into a separate package, it has to be bundled with every source package that needs it
[11:52] <handschuh> yes thats the tricky part
[11:52] <Rhonda> Then the sourcecode has to be bundled with the source package, too
[11:52] <tumbleweed> Rhonda: naturally :)
[11:52] <Rhonda> sourcecode of waf, that is
[11:52]  * tumbleweed thought waf was python, though
[11:52] <Rhonda> Or, would a waf-source "binary" package be able to work around for that?
[11:53] <tumbleweed> no, the problem is that waf doesn't provide a stable API to packages that use it
[11:53] <handschuh> it has been removed from lucid on
[11:53] <Rhonda> That bugreport should potentially be forwarded to Debian.
[11:54] <handschuh> I think there is no debian package of polster
[11:54] <Rhonda> Though: Maintainer: Devid Antonio Filoni<EMAIL_ADDRESS>[11:54] <Rhonda> handschuh: Well, there is.
[11:54] <Rhonda> You think wrong. :)  http://packages.debian.org/postler
[11:54] <handschuh> Rhonda: indeed, I missed that
[11:54] <Rhonda> and, the included waf isn't a binary file?
[11:54]  * Rhonda did a quick apt-get source postler
[11:55] <Rhonda> handschuh: which is the "binary" file there?
[11:55] <handschuh> "waf"
[11:55] <Rhonda> waf: a python script text executable
[11:55] <DktrKranz> oh, waf again? plese, no!
[11:55] <handschuh> look at the last lines
[11:55] <Rhonda> handschuh: Not a binary in the source package I look at over here?
[11:55] <Rhonda> oh
[11:55] <handschuh> yes, nasty
[11:56] <Rhonda> line 161 that is, right
[11:56] <Rhonda> wtf does it do that?
[11:56] <handschuh> thats the actual waf script
[11:56] <tumbleweed> bdrung: ubuntu-distro-info is currently broken in Debian testing
[11:56] <handschuh> IMHO
[11:56] <DktrKranz> there was a waf package (with me being one of the co-maintainers), upstream "kindly" asked us to refrain from package it, and let waf "binary" to be distributed with several programs
[11:56] <Rhonda> handschuh: I'm filing the bugreport now.
[11:57] <handschuh> Rhonda: thanks a lot!
[11:58] <Laney> DktrKranz even sponsored postler ;-)
[11:58] <DktrKranz> yeah
[11:58] <tumbleweed> bdrung: aah, no it's just confused by precise not being open yet
[12:00] <DktrKranz> FYI, here's a summary about waf: http://lists.debian.org/debian-devel/2010/02/msg00714.html
[12:00] <handschuh> Rhonda: same thing with midori (since the authors are partially the same)
[12:01] <handschuh> DktrKranz: yes, I read that and thats what caught my attention (also a python script that has 160 lines an 90kb of size)
[12:01] <Rhonda> handschuh: checking
[12:01] <Rhonda> Do you have an LP bug number? Or not filed?
[12:02] <handschuh> Rhonda: not filed since I checked that just now
[12:03] <Rhonda> hmm, that's a different maintainer
[12:05] <Laney> is there any place to search the contents of source packages?
[12:05] <Rhonda> DktrKranz: You didn't mention in that blaaaahhhhh
[12:05] <Rhonda> corsac!!
[12:06]  * Laney thinks a lintian error for waf would be worthwhile
[12:06] <handschuh> Laney: yes that would be very helpful to avoid waf
[12:06] <Rhonda> at least that was done post-squeeze.
[12:07] <Laney> yeah?
[12:07] <DktrKranz> well, to be honest, waf has source code
[12:07] <DktrKranz> there's an option to unpack it into wafadmin directory
[12:08] <Rhonda> not in midori anymore, not since 0.3.0-1.1
[12:08] <DktrKranz> obviously, it isn't the preferred form of modification
[12:09] <handschuh> Rhonda: it is in 0.4.0
[12:09] <DktrKranz> the win-win solution is to get rid of waf for good
[12:09] <DktrKranz> IIRC, there are ~10 packages using it, with midori being the more publicized one
[12:10] <Rhonda> handschuh: what is in 0.4.0?
[12:12] <handschuh> Rhonda: waf
[12:13] <Rhonda> I know.
[12:13] <Rhonda> But the source was removed in 0.3.0-1.1, that's what I meant.
[12:13] <handschuh> ah, ok I see
[12:14] <handschuh> it should not be to hard to get rid of waf in those two packages as I was able to compile them with a 10 line makefile
[12:15] <handschuh> s/them/postler
[12:21] <handschuh> Rhonda: thank you for the fast reaction on that issue!
[12:22] <Laney> doesn't look like the maintainer responds to bugs though
[12:22] <Rhonda> Doesn't matter as long as the release team removes the package. :)
[12:24] <Rhonda> huhm
[12:24] <Rhonda> handschuh: Just reading the mail from DktrKranz, the line 161 seems to be an embedded .tar.bz2 file.
[12:24] <DktrKranz> it is
[12:25] <DktrKranz> and gets unpcked in $PWD/.waf-*/wafadmin
[12:25] <Rhonda> hmm, so the bugreports might be invalid then?
[12:26] <bdrung> tumbleweed: what's the output of ubuntu-distro-info on testing?
[12:28] <handschuh> Rhonda: yes that is correct but in general, this could contain anything. One never knows until one extracts the file and unpacks it
[12:29] <DktrKranz> AFAIK, embedded waf sources are all DFSG-free (while waf source tarball distributed upstream isn't). Sources are in place when launching waf, the correct way to invoke them would be launching waf-light once unpacked, or write something that does just that
[12:29] <Rhonda> handschuh: Well, you don't know what's in a source package until you unpack it neither.
[12:30] <Rhonda> There are packages that contain multiple upstream tarballs in a single source package.
[12:30] <DktrKranz> but I guess is an overkill for a 10 package work...
[12:31] <Rhonda> hmm, how do I enter a \r in vim?  \n is ^M
[12:31] <handschuh> Rhonda: indeed. so it is invalid, or not?
[13:03] <Rhonda> handschuh: I fail to find the proper way to unpack and repack that included binary because it contains a substitution of \r for #% and \n for #*
[13:03] <Rhonda> And thus can't be directly saved. Missing the tools to un- and repack the included tarball this still is valid (to me)
[13:07] <handschuh> Rhonda: good. to me it is also still valid since accepting this would mean that one can pack the sources in a non standard-way (for instance base64 then some xor with a value that is in the unpack-script) which might be theoretically ok but it at least very ugly in my opinion.
[13:22] <murrayc> Do I need to do anything for a "dependency-wait" build status?
[13:25] <geser> check which dependency is missing and why
[13:26] <geser> if it's only because the other dep is still building then wait and recheck later
[13:26] <geser> the "dependency-wait" build gets retried automatically but you don't get a notify if is still in depwait for an other reason
[13:32] <murrayc> geser: It's just a regular oneirc package. https://launchpad.net/~openismus-team/+archive/ppa/+build/2840723
[13:37] <geser> murrayc: typo in your Build-Depends line: it's libgtksourceview-3.0-dev (note the - before the 3.0)
[13:38] <murrayc> geser: Ah. Thanks. I have looked at that so many times looking for a typo, but didn't see it.
[15:27] <tumbleweed> bdrung: it doesn't have precise yet, so http://paste.ubuntu.com/707395/
[15:28] <tumbleweed> we should have waited for it to migrate before doing more stuff
[15:29] <tumbleweed> bdrung: we also need a u-d-t upload soonish, to update the dependencies
[15:30] <bdrung> tumbleweed: we should wait for getting 0.3 migrated
[15:30] <bdrung> tumbleweed: the u-d-t upload does not hurry
[15:30] <tumbleweed> I'll ask for a speedy migration
[15:35] <tumbleweed> bdrung: we'll have to SRU it in natty too. Which means clearing the existing SRU
[15:38] <bdrung> tumbleweed: or we need to get the SRU migrated to updates in then get it in
[15:39] <tumbleweed> indeed, that is preferable. I was going to ask for volunteers in #ubuntu-testing (if they aren't all exhausted)
[15:42] <tumbleweed> bdrung: http://paste.debian.net/hidden/178c8b32/
[15:54] <bdrung> tumbleweed: feel free to propose something that a user can change
[19:43] <jtaylor> what do I do with this: https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/79330
[19:44] <jtaylor> I can only set the status ti WIP needs review or merged
[19:44] <jtaylor> no deny
[19:44] <jtaylor> set it to merged?
[19:44] <jtaylor> or delete it?
[19:53] <tumbleweed> jtaylor: members of ubuntu-branches can set other statuses, just ask (normally in -devel)
[19:53] <tumbleweed> a slight confuion there is that it'll actually be merged into -proposed