[00:09] <theunixgeek> Would anyone like to do me a favor of going into Synaptic, checking off libgtk2.0-dev and libgtk2.0-doc for installation (just checking the check box, not installing unless you want to) and then go to File>Generate Package Download Script, please? as in this picture: http://2.bp.blogspot.com/_fs6jwQq0LQk/SLsbgxQZ7KI/AAAAAAAAAQw/FSqht56jDO8/s1600-h/Screenshot-Synaptic+Package+Manager+.png
[00:09] <theunixgeek> hardy heron 8.04.0 please :)
[00:09] <theunixgeek> and the script can just go on a pastebin somewhere
[00:16] <theunixgeek> http://ubuntuforums.org/showthread.php?p=5702397#post5702397 :0
[00:16] <theunixgeek> * :)
[00:19] <crimsun> \sh: is this post-upgrade of nspluginwrapper 1.1.0?  did you purge and reinstall flashplugin-nonfree afterward?
[00:23] <ion_> You mean dpkg-reconfigure flashplugin-nonfree?
[00:30] <theunixgeek> please someone? :(
[00:31] <theunixgeek> http://ubuntuforums.org/showthread.php?p=5702397#post5702397
[00:31] <theunixgeek> it only takes 5 seconds
[00:34] <cjwatson> theunixgeek: one moment, I need to remove those packages first
[00:35] <cjwatson> theunixgeek: err, will intrepid do?
[00:35] <lukehasnoname> http://mibbit.com/pb/cwQqez
[00:35] <lukehasnoname> theunixgeek:
[00:35] <lukehasnoname> there you go.
[00:35] <lukehasnoname> And thanks to hitting execute instead of display, I have flooded my home folder.
[00:35] <cjwatson> (I hope nobody's still running 8.04.0, BTW)
[00:36] <lukehasnoname> Nobody would be, unless auto updates are off, correct?
[00:36] <cjwatson> 00:09 <theunixgeek> hardy heron 8.04.0 please :)
[00:36] <mika_videodev> Q: what is the status of kubuntu 8.10? can bugs still be filed and will the fixes make it to the 8.10 when it is released ?
[00:37] <cjwatson> mika_videodev: feature freeze; yes, bugs can still be filed; depends on all the usual things (whether a developer is paying attention and has time, how complex and invasive the fix is, whether it's reasonably fixable, etc.) but there's no intrinsic reason why not
[00:38] <mika_videodev> a part of lspci command output: 01:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
[00:38] <lukehasnoname> theunixgeek_: http://mibbit.com/pb/34mLX0
[00:39] <cjwatson> mika_videodev: please report bugs at bugs.launchpad.net/ubuntu rather than here, though
[00:39] <theunixgeek_> lukehasnoname: thank you!!!! :D
[00:39] <theunixgeek_> thank you so much!!!!
[00:39] <theunixgeek_> thanks
[00:40] <mika_videodev> in kubuntu 7.10 there's a problem with that. if in kaffeine, one tries to activate live dbv-c viewing, kaffeine will lock up. work-around: first play any mpeg2 video file or DVD. While it is playing, do command it to live DVB-C viewing mode. Works about 80% of the time, but sometimes kaffeine  locks up anyway (need to use kill command or click the X and answer yes, when KDE asks whether to kill the app)
[00:40] <cjwatson> mika_videodev: please report bugs at bugs.launchpad.net/ubuntu rather than here
[00:40] <cjwatson> also, 7.10 != 8.10
[00:41] <cjwatson> was one of those a typo?
[00:41] <mika_videodev> I know that, but is there s liveCD snapshot of 8.10 somewhere to download and try if it still has the ame problem ?
[00:41] <mika_videodev> I am still using 7.10, no typo.
[00:42] <cjwatson> mika_videodev: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-August/000470.html
 which image do you recommend me to try? The normal 32-bit or the amd64-bit version? I am currently running 32-bit version, but I do have AMD-64-bit dualcore CPU 2300 MHz, and 4 Gigabytes RAM.
[00:46] <_MMA_> mika_videodev: Try what you like.
[00:54] <mika_videodev> is there any known problems using 64-bit versions of linux ? like in device driver support ?
[00:55] <RAOF> No
[01:11] <crimsun> ion_: sure, that will also work.  It's only important that nspluginwrapper is rerun.
[02:01]  * NCommander smacks his head on the desk a few hundred times per hour :-)
[03:44] <leleobhz> pacakge bug! The following packages have unmet dependencies: tzdata-java: Depende: tzdata (= 2008b-1ubuntu1) but 2008e-1ubuntu0.8.04 is installed.
[03:44] <leleobhz> s/Depende/Depends/g
[03:45] <leleobhz> all my repositories is updated and system upgraded
[03:50] <Hobbsee> leleobhz: and irc is now the new bug tracker?
[03:50] <leleobhz> no
[03:50] <leleobhz> i only want before i file a bug if its really a bug
[03:51] <leleobhz> or if someone got this too
[03:51] <Hobbsee> can you run 'apt-cache policy tzdata-java', and pastebin it please?
[03:52] <wgrant> I suspect that you don't have hardy-updates enabled for universe.
[03:52] <Hobbsee> sorry, 'apt-cache policy tzdata tzdata-java'
[03:52] <leleobhz> Hobbsee: http://paste.milk-it.net/919
[03:52] <StevenK> Yup. What wgrant said
[03:52] <StevenK> Enable hardy-updates universe, and apt-get update
[03:53] <leleobhz> lets see
[03:53] <Hobbsee> ah, eys
[03:53] <StevenK> wgrant: Nice catch
[03:53] <wgrant> StevenK: Not particularly, but thanks.
[03:54] <leleobhz> added and dist-upgrading
[03:54] <leleobhz> but tzdata is not included on update list..
[03:54] <wgrant> tzdata-java should be.
[03:54] <wgrant> tzdata should not.
[03:54] <leleobhz> hmm
[03:55] <leleobhz> now got no warning
[03:55] <leleobhz> well, thanks :]
[03:55] <wgrant> Excellent.
[03:55] <leleobhz> (and sorry by false allarm)
[03:56]  * wgrant disappears to another lecture.
[04:05] <JustinF_> hello everyone
[04:11] <ion_> Hi, doctor Nick!
[05:55]  * pitti hugs the channel, good morning
[05:55] <StevenK> pitti!
[05:56] <pitti> hey StevenK
[05:56] <StevenK> pitti: NBS hasn't been the same without you running your broom through it :-)
[05:56] <pitti> heh
[05:58] <Hobbsee> pitti!
[05:58]  * pitti throws a gummybear to Hobbsee
[05:59] <Hobbsee> \o/
[05:59]  * Hobbsee throws the gummybear to StevenK, and looks for some chocolate
[05:59] <Darklock> I pitti the fool!
[05:59]  * StevenK grins
[06:00]  * ScottK mentions that the MIR queue has been lonely in pitti's absence.
[06:06] <ajmitch> hello pitti
[06:10] <pitti> hey ajmitch
[06:10] <pitti> ScottK: that's part of the backlog I have to grind through now :)
[06:10] <ion_> Welcome back, pitti :-)
[06:11] <ScottK> Welcome back.
[06:11] <ion_> scottk: Thanks
[06:20] <dholbach> goooood morning!
[06:21] <ion_> Hi
[06:21] <dholbach> hi ion_
[06:22] <pitti> hey dholbach! *hug*
[06:22] <dholbach> hi pitti
[06:22]  * dholbach hugs pitti back
[06:25]  * nxvl HUGS pitti
[06:25] <nxvl> pitti: we miss you!
[06:28] <NCommander> hey jdong
[07:00] <NLE> hi guys i need help in my VLC command, I always got an error "stream_out_transcode private debug: drift is too high" can anybody help me with my problem thanks
[07:02] <\sh> crimsun: flashplugin works now, but again without doing any rtmp connections to an fms ... because of missing libs it seems
[07:03] <\sh> oh good morning pitti :)
[07:03] <pitti> hey \sh
[07:03] <\sh> pitti: hope you had a good holiday :)
[07:04] <pitti> \sh: yes, it was wonderful; lots of fresh air, food, exercise, and sleep, all the things I usually don't get :)
[07:04] <pitti> \sh: two weeks bicycling through southern Sweden
[07:04] <pitti> we made some 830 km
[07:05] <\sh> pitti: I'm jealous...:)
[07:05] <StevenK> pitti: Damn it! You undid all of the hard work keeping you in a darkened room at UDS!
[07:06] <StevenK> :-P
[07:06] <dholbach> pitti: you don't get food?
[07:07] <dholbach> everybody: please cough up and let's send pitti some food
[07:07]  * Mithrandir waves.
[07:07] <dholbach> the poor guy is starving!
[07:07] <pitti> I mean *lots* of food :)
[07:07] <NLE> hi guys i need help in my VLC command, I always got an error "stream_out_transcode private debug: drift is too high" can anybody help me with my problem thanks
[07:07] <pitti> due to being exposed to fresh air all the day, I ate twice as much as usual :)
[07:08] <RAOF> It's a little known fact, but fresh air makes food evaporate from the body.
[07:09] <Treenaks> RAOF: that would explain a lot!
[07:09] <\sh> ok..now everybody is back from the weekend and from holidays...I'll have a question regarding tslib being in universe, but also being a dep of directfb which is in main...this screws up my work on ia32-libs
[07:09] <crimsun> \sh: what does 'now' mean?  after nspluginwrapper is rerun?  (the ia32-libs bits are known, but someone has to fix the scalability problem.)
[07:10] <\sh> crimsun: after I reinstalled the whole flashplugin stuff , meaning: purging and reinstalling the base functionality is back..
[07:11] <\sh> crimsun: and yes, I'm dealing with ia32-libs right now...see the question above :)
[07:11] <crimsun> \sh: right, that was debugged/discussed in -mozillateam last week.
[07:14] <dholbach> pitti: do you know anything about the seahorse-agent situation?
[07:15] <pitti> dholbach: if you mean the gpg part, it still needs to be packaged
[07:15] <StevenK> pitti: stardict is in NBS, and will FTBFS if it's rebuilt. There are no Ubuntu changes, and the new Debian revision in unstable looks like it will solve it, do I need a FFe to get you to sync it?
[07:16] <pitti> StevenK: no, it's just a new debian revision; I can sync it right now
[07:16] <pitti> StevenK: is there a bug for it already? (if not, don't bother)
[07:16] <StevenK> pitti: There isn't, I'm pulling stuff from NBS.
[07:17] <dholbach> pitti: I see
[07:17] <dholbach> hiya thekorn
[07:17] <StevenK> pitti: Note "looks like it will solve it", I'm test building to see if it holds.
[07:17] <thekorn> good morning dholbach
[07:17] <pitti> StevenK: ok, I prepared the sync, tell me when/if to commit it
[07:18] <StevenK> pitti: Could you also add running a broom through NBS to your todo list if you haven't already? :-)
[07:27] <\sh> who is responsible for reviewing MIRs?
[07:27] <StevenK> The ubuntu-mir team
[07:27] <\sh> lol
[07:27] <\sh> doko and pitti...who else ,-)
[07:28] <\sh> I stop asking "who is reponsible for this and that"...the answer is always pitti somehow ;)
[07:29] <pitti> \sh: you could just look at the team member list :)
[07:29] <\sh> pitti: I just did
[07:30] <\sh> pitti: and if you are relaxed, just promote tslib to main (as written on https://wiki.ubuntu.com/MainInclusionReportTslib) so I can start refreshen the ia32-libs stuff and start support the new flashplugin stuff which is missing ;)
[07:31] <StevenK> \sh: MIRs are done as bugs now
[07:31] <\sh> StevenK: pitti: bug #255275
[07:32] <\sh> nevermind..
[07:32] <pitti> \sh: ia32-libs is in universe, so what does it have to do with MIRs?
[07:32] <\sh> pitti: directfb is pulled in, and it needs tslib...which is not promoted to main...so freshen fails
[07:33] <pitti> \sh: seems that ia32-libs needs to be fixed to pull from universe then, although I had expected that it does that already
[07:33] <\sh> pitti: it is
[07:33] <\sh> pitti: it pulls from universe...but directfb is manual dep wait because of tslib in universe;)
[07:33] <pitti> oh, I see
[07:33] <\sh> pitti: so source is new, but binaries are old
[07:34] <pitti> what do we need directfb for in main? sdl?
[07:34] <\sh> pitti: ask doko ;)
[07:35] <\sh> ScottK: do you agree with bug #261885 ? arj in main for clamav?
[07:36]  * \sh really wonders who is using arj these days? I mean we are totally out of the 80ties and 90ties where it was famous being used in mailboxes
[07:54] <cjwatson> StevenK: (I did at least the empty stuff from NBS on a couple of occasions while pitti was away, BTW; just to dispel the idea that nobody looked at it at all ...)
[07:55] <pitti> ScottK: argh, so we now need to support every possible unpacker format for clamav? they can't become suggests: or something?
[07:55] <pitti> even gzip has vulnerabilities these days, I don't want to imagine how many zoo, arj, etc. have...
[07:56] <StevenK> cjwatson: Ahhh, I thought I noticed it get cleaned up a few times.
[07:56]  * StevenK kicks stardict for failing with an obtuse error.
[09:00] <dholbach> hi blueyed
[09:00] <dholbach> hi seb128!
[09:00] <seb128> hello dholbach!
[09:03] <StevenK> pitti: Right, gucharmap is broken, I'll need to fix that first.
[09:04] <seb128> StevenK: what is broken? there is a new version to package btw ;-)
[09:05] <StevenK> seb128: There is no .pc file in the -dev, so things using pkg-config to check it fail
[09:06] <seb128> are you sure?
[09:06] <StevenK> Fairly sure
[09:06] <seb128> the .pc name changed this cycle
[09:06] <seb128> and it's correctly installed there
[09:07] <StevenK> Ah, nice. That would explain it. stardict is looking for gucharmap.pc
[09:08] <StevenK> Ah ha, gucharmap-2.pc
[09:21] <StevenK> pitti: That sync can't be processed, it needs an Ubuntu change. :-(
[09:35]  * StevenK kicks stardict
[09:59] <persia> james_w: To avoid further discussion in the mailing list irrelevant to the original subject, what's the best forum to discuss the use of bzr for distributed development and impacts for cases where packages are only touched once?
[09:59] <james_w> persia: I'm not sure. I assume you would like a mailing list?
[10:00] <azeem> (there's the vcs-pkg project/lists I think)
[10:00] <persia> james_w: Or just some of your time to help understand either what I'm doing wrong with regard to performance, or whether we can identify specific issues that might need attention.
[10:01] <james_w> azeem: yes, I'm on it thanks, I think this is not exactly its mandate, and Ubuntu-specific to boot
[10:01] <james_w> persia: for that then private email or IRC is fine for me
[10:01] <dholbach> can we get 1.6 into hardy-backports? :)
[10:02] <james_w> persia: I would like to have the other discussions though. Perhaps just breaking the thread on ubuntu-devel would let your topic breathe while allowing us to have a discussion
[10:02] <james_w> dholbach: there's a 1.6.1 this week, once that's in and tested a but I can request a backport
[10:02] <dholbach> cool :-)
[10:05] <stefanlsd> im looking forward to the bzr session in dev week.   (totally unfamilair with bzr.  i know some git)
[10:09]  * mpt cries
[10:09] <mpt> Ctrl Alt Backspace = stupidest keyboard combo ever
[10:10] <Robot101> :(
[10:10] <ion_> I don’t know what i do differently, but i never manage to hit it accidentally.
[10:11] <cjwatson> mpt: https://blueprints.launchpad.net/ubuntu/+spec/xorg-ctrl-alt-backspace; unfortunately deferred from intrepid due to apparent dissension
[10:11] <cjwatson> (read the wiki rather than the spec title; it's not just about disabling it any more, just making it harder to activate)
[10:15] <mpt> I doubt any of the "make it harder to trigger" techniques would have helped me
[10:15] <mpt> I was using Ctrl Backspace to delete words and hit Alt by mistake
[10:16] <ion_> Ah, that’s it. I always use ^W.
[10:17] <mpt> If it had done nothing, I would have just pressed it more/longer, assuming that Ubuntu was in one of its frequent snoozes
[10:18] <dholbach> mpt: I know your pain
[10:18] <ion_> How about an instant popup that says “Hit Ctrl-Alt-Backspace again to blahblah”?
[10:18] <cjwatson> ion_: see the discussion in the spec, please
[10:18] <ion_> cjwatson: That was an answer to “I doubt any of the techniques would have helped me”.
[10:18] <cjwatson> ion_: an answer explicitly addressed in the spec as "unimplementable"
[10:19] <cjwatson> and with other UI deficiencies noted there
[10:19] <ion_> Ok
[10:20] <cjwatson> (well, clearly it's possible to do anything in theory, but that would at least require turning an awful lot of stuff upside down for this one thing)
[10:20] <cjwatson> and furthermore a dialog would completely fail to address the cases where you *do* need ctrl-alt-backspace for real, e.g. when most of X has locked up
[10:22] <ogra_> if you are lucky hal didnt start up ... then ctrl-alt-backspace wont restart your session </sarcasm>
[10:22] <ion_> cjwatson: alt-sysrq-k ;-)
[10:23]  * ogra_ sat on a blocked gdm screen to often already since intrepid ... no input at all (!) without hal ... not even console switching ...
[10:24] <cjwatson> we should try to arrange for hal to start earlier; it's very late for what's now such a critical service
[10:24] <ion_> And as for the display chip possibly being in a broken state after killing X with sysrq, well, hopefully the move-graphics-drivers-to-kernel-and-make-X-use-common-framebuffer-with-virtual-consoles thing gets implemented soon. :-)
[10:25] <ogra_> cjwatson, no, X should have a fallback mechanism to have *something* if there is no hal
[10:25] <cjwatson> ogra_: that too
[10:25] <cjwatson> X is not the only thing that is coming to depend on hal, though
[10:25] <ogra_> or an automatism to switch you to tty1 or some such
[10:26] <cjwatson> bryce: perhaps bullet-proof-x should detect this situation
[10:26] <ion_> How about X simply refusing to start – at least by default – if there’s no HAL?
[10:26] <mpt> As Ubuntu becomes more popular, the proportion of users for whom Ctrl Alt Backspace is useful decreases, so the average benefit decreases, while the average harm remains constant
[10:26] <ogra_> cjwatson, doesnt that need an input mechanism as well ? (note that there is also no mouse without hal)
[10:27] <cjwatson> ogra_: bullet-proof-x is for when X crashes, and takes its input on the console at least to start with
[10:27] <ogra_> ah, i thought thats the part that you get to configure yur graphics card in vesa mode
[10:27] <ogra_> (which needs a mouse for me)
[10:28] <didrocks> pitti:
[10:29] <pitti> hi didrocks
[10:29] <persia> mpt: How does the proportion of users who wish to recover from crashed X decrease with wider penetration?
[10:29] <cjwatson> ogra_: in any case, the failsafe X configuration seems to manually configure input devices, so that should bypass input hotplug and not require hal, I think
[10:29] <ogra_> ah, i havet had that screen in intrepid at all yet ... if it does that then it's fine
[10:29] <mpt> persia, the proportion who *want* to recover from an error of that sort doesn't decrease, but the proportion who know that that's how to do it does.
[10:30] <cjwatson> ogra_: I think I'm misremembering and you're correct that it goes into X
[10:30] <didrocks> pitti: (Hi, sorry for the later hilight) for OpenWeekdev, huats and I will handle a session on patching a package. We were thinking about based the session on your previous work as it has been well understandable (adding quilt pach system, eventually)
[10:30] <persia> mpt: Surely that's a matter of education, rather than removing the capability, no?
[10:30] <ogra_> and i think currently X gnores all input stanzas in the config file (there was a patch though that enabled it again)
[10:30] <pitti> didrocks: NB that my original notes already cover quilt as well; just in some IRC sessions I didn't get to it
[10:30] <cjwatson> I disagree that education helps; arranging that the facility is harder to invoke by accident would be fine
[10:30] <pitti> didrocks: but it's also documented in the wiki
[10:31] <cjwatson> (the reason education doesn't help is that even educated users hit it by mistake sometimes)
[10:31] <didrocks> pitti: yes, we will try to have enough time to speak about it
[10:31] <huats> pitti: sure
[10:31] <huats> (hey btw :))
[10:31] <pitti> hey huats
[10:31] <persia> cjwatson: I meant education that it was possible to so recover, not that they shouldn't press that combination of keys
[10:31] <didrocks> pitti: it was just to ask you if we can base our speech on your previous session :)
[10:32] <mpt> persia, what cjwatson said. And also, where would you propose putting this education? On the CD sleeve? In the installer?
[10:32] <cjwatson> I don't agree that facilities should be removed simply because their use diminishes; repeatedly applying that principle is a good way to irritate a different 2% of your users each time
[10:32] <persia> The idea is that the facility *should* be useful for any affected users, and not get hit accidentally.
[10:32] <pitti> didrocks: of course, it's all "free software" :)
[10:32] <cjwatson> it doesn't take a very long time of applying that principle before you've irritated most of your users
[10:32] <didrocks> pitti: thanks a lot :) Will try to be as good as you as a teacher :)
[10:32] <huats> didrocks: there is no way we can be as good as pitti ;)
[10:33] <persia> mpt: Within the system: as long as it's sufficiently difficult to accidentally trigger, it's useful as part of the documentation.
[10:33] <pitti> didrocks: thank you for covering the session; I can lurk in it and be a fallback for questions, if you want
[10:33] <huats> pitti: that would be a great asset thanks martin
[10:33] <didrocks> pitti: with pleasure, if you can find the time :)
[10:33] <cjwatson> it is a fallacy to say that every feature not manifestly obvious to every single user is useless, I feel
[10:33] <pitti> but how is ctrl+alt+backspace easy enough to hit accidentally?
[10:33] <mpt> persia, as the user base increases the proportion who read anything labelled "documentation" also decreases.
[10:34] <mpt> cjwatson, is anyone suggesting that?
[10:34] <cjwatson> pitti: I do it often enough to be irritating
[10:34] <cjwatson> mpt: I find your argument distressingly close to that position ...
[10:34] <mpt> I'm saying that the benefit decreases as the harm remains constant
[10:34] <mpt> I'm not saying that the benefit is zero
[10:34]  * ogra thinks a cancel/ok dialog with proper naming would suffice
[10:34] <stefanlsd> pitti: i was hitting it pretty often in some application. cant remember which.
[10:34] <cjwatson> mpt: and I'm saying that the correct response is to reduce the harm, not to remove the benefit
[10:34] <persia> mpt: I don't agree that the benefit decreases, your low opinion of users notwithstanding.
[10:35] <cjwatson> ogra: for ctrl-alt-backspace? a dialog isn't feasible, as I said above
[10:35] <pitti> cjwatson: wow, your cat/dog/whatever must have a knack for hitting those three keys :)
[10:35] <cjwatson> pitti: what usually happens is that I was holding down ctrl+alt for something else, then wanted to delete some text and forgot to let go for ctrl+alt
[10:35] <mpt> persia, nice fallacy you got there. :-)
[10:35] <cjwatson> the accident is hitting one while the others are down, not hitting all three at once
[10:35] <persia> pitti: It can be trivially easy with some hardware configurations: the handykey being one.
[10:36] <pitti> ogra: in most cases when you actually want to kill X, popping up a dialog (or doing an action in it) is precisely what *doesn't* work any more...
[10:36] <ogra> hmm ... right
[10:36] <cjwatson> mpt: the reason I drew the conclusion you did was that your immediate response was to remove the benefit; that's a response that tends to arise from assuming that each 2% doesn't need to be cared for, I find
[10:37] <persia> mpt: OK.  To put in less contentious terms: I don't agree that the benefit isn't there just because someone doesn't know about it: I do agree that triggering it by accident is unfortunate, but not that this is worth the cost of removing the ability to do this, nor creating wide variance from historically available documentation.
[10:37] <cjwatson> I'd like to care for the 98% *and* the 2%, not just the 98%
[10:37] <mpt> cjwatson, my immediate response was to label the keyboard combo as stupid, not the function in general.
[10:38] <cjwatson> I agree that the keyboard combination is unfortunate
[10:38] <cjwatson> one reason for it is that it needs to be largely independent of keyboard maps, so a relatively small number of keys (all of which are in common use) are available
[10:38] <persia> mpt: One issue with changing the key combination is that there is vast amounts of documentation indicating that this specific key combination is the appropriate way to restart X when it locks.  Not support that may cause user confusion.
[10:39] <mpt> persia, sorry, I left out the word "average" once there. The average benefit is partly dependent on the proportion of people who know about it, which is a function of how long you've been using an X-based system.
[10:39] <cjwatson> the available keys are essentially the function keys, backspace, enter, escape, tab, cursors, and the insert/delete/etc. block
[10:39] <persia> mpt: I can accept that argument, although I think it's a function of both how long one has been using such a system, and how one tends to seek support when one has an issue.
[10:39] <cjwatson> I think it's important to remember that the people who know about it and would be annoyed by its absence are likely to be the most vocal users of Ubuntu right now, i.e. decision-formers
[10:40] <mpt> exactly
[10:40] <cjwatson> I've seen one too many bug recently where we made a well-intentioned attempt to improve matters for a big chunk of our userbase, and pissed off people who'd been using Ubuntu since Warty as a consequence
[10:42] <cjwatson> this is not an argument for never changing anything, of course, just for considering the people left behind
[10:44] <fta_> pitti, could you please have a look at https://code.edge.launchpad.net/~fta/apport/apport/+merge/758 ? I proposed a fix 2+ weeks ago
[10:45] <pitti> fta_: right, I saw the page this morning and kept it open for processing ASAP
[10:45] <mpt> persia, some people will not realize they have an "issue" at all, they'll just think that Ubuntu crashes occasionally when they're typing. :-)
[10:45] <pitti> fta_: I was away on holiday in the last two weeks, and I didn't get a mail about the request
[10:45] <fta_> pitti, i figured that out, no problem
[10:46] <persia> mpt: Indeed.  Making it harder to break the system would be good.  I'm just not sure that disabling a useful feature is the right way to do it.
[10:46] <seb128> hey fta_, any news about the libcairo update?
[10:46] <fta_> pitti, someone pushed a new apport in the meantime so there is probably a conflict in changelog
[10:46] <fta_> seb128, hi, glad you ask. i was about to ping you
[10:46] <persia> I have one system that regularly has X crashes: when I can invoke the keystroke fast enough, I don't need to reset the PCI bus a couple times to boot again.  Perhaps this system ought be recycled, but it's very useful to me.
[10:47] <pitti> fta_: that sounds trivial to fix
[10:49] <fta_> seb128, i've been using this new cairo for 2 weeks now, i see a small difference in the lcd filter but other people are complaining too so it may not be my cairo... see http://ubuntuforums.org/showthread.php?t=902556
[10:50] <fta_> seb128, for me, it's perfectly acceptable, not like in that screenshot at all
[10:51] <seb128> fta_: ok, seems good enough to upload the new cairo then, where is you package update? ;-)
[10:51] <fta_> seb128, i can update my debdiff (as i added 03_from_git_fix_lcd_filter_default.dpatch since the 1st one)
[10:51] <fta_> i need 2 secs.
[10:55] <fta_> seb128, http://www.sofaraway.org/ubuntu/debdiff/cairo_1.7.4-0ubuntu1.diff.gz http://www.sofaraway.org/ubuntu/debdiff/cairo_1.7.4-0ubuntu1.dsc
[10:55] <seb128> fta_: thanks
[10:59] <bigon> seb128, must I ask a UVFe for gnome pkg in universe (like empathy) or such pkg automatically get UVFe?
[11:00] <wgrant> bigon: Why would universe be different? We have our policies too.
[11:00] <seb128> bigon: GNOME has a standing exception so no need to ask one to update it
[11:00] <bigon> great
[11:00] <seb128> wgrant: GNOME has a standing freeze exception
[11:01] <NCommander> pitti, I think you need to check who submits give-back bugs, I"m not a core-dev :-)
[11:01] <seb128> NCommander: hey
[11:01] <wgrant> seb128: Ah, I see. Some people have historically ignored the fact that FF applies to universe as well.
[11:01] <NCommander> Ooh, seb128
[11:01] <pitti> NCommander: oh, I just saw dholbach's mail
[11:02] <NCommander> seb128, I haven't seen you online in awhile
[11:02] <NCommander> pitti, Don't worry, we still love you :-)
[11:02] <seb128> NCommander: I was on holidays
[11:02] <NCommander> seb128, wow, what is this holiday you speak of?
[11:02] <NCommander> seb128, you've missed my work since you went away :-P
[11:03] <seb128> ;-)
[11:03] <seb128> NCommander: did you get pangomm in shape? ;-) looking for other updateS?
[11:03] <seb128> updates
[11:03] <NCommander> er, well
[11:03] <NCommander> seb128, https://edge.launchpad.net/~sonicmctails - the Xubuntu guys stole me
[11:04] <NCommander> (although I did get a FTBFS fix for update-notification uploaded)
[11:05] <seb128> lol
[11:05] <seb128> NCommander: going to update libgsf, goffice and gnumeric then? ;-)
[11:06] <NCommander> seb128, well, as revenge for disappearing, I went and processed the entire outstanding hardy backports queue, so roughly 40-50ish bugs await the archive admins ;-)
[11:06] <NCommander> (my revenges are usually producive and usually result in someones mailbox getting flooded with bug fixes)
[11:07]  * NCommander looks on the status of pangomm
[11:07] <NCommander> Wooo, STILL in the NEW queue
[11:08] <seb128> NCommander: can you get fake sync for ubuntu? ;-)
[11:08] <NCommander> You don't ask much, do you :-P
[11:09] <NCommander> (knowing my luck, upstream has released a new pangomm)
[11:09] <seb128> NCommander: there is a new GNOME due today so they will probably
[11:09] <seb128> NCommander: if you want to do some updates you are welcome to do so btw
[11:09] <NCommander> Ok, hold on
[11:10] <NCommander> Rolling a fast sync for our lovable archive admin
[11:11] <NCommander> On its way to my PPA
[11:14] <NCommander> seb128, that was notification-daemon who's FTBFS I fixed
[11:14] <NCommander> and I made sure the changes made it into the packaging teams BZR :-)
[11:14] <seb128> cool
[11:14]  * NCommander tries his best
[11:14] <NCommander> you could add me to ubuntu-desktop so I could commit my work to your bazaar branch
[11:15] <NCommander> ;-)
[11:15] <NCommander> seb128, my PPA rejected pangomm -_-;
[11:15] <NCommander> Says I already uploaded it with the same version
[11:15] <seb128> which is probably true ;-)
[11:16] <NCommander> Uploading the source package somewhere you can get to it
[11:17] <NCommander> which is easier said than done since I can't think of a public server I have access to ATM
[11:17] <seb128> NCommander: attach the diff.gz and .dsc to a bug?
[11:17] <seb128> I can get the tarball upstream
[11:17] <NCommander> o
[11:17] <NCommander> *ok
[11:20] <NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+bug/254050
[11:20] <seb128> NCommander: thanks
[11:24] <NCommander> my list of uploads grows
[11:24] <NCommander> *strokes beard*
[11:24] <seb128> NCommander: wants some updates to do then? ;-) did you start on the gtkmm one?
[11:25]  * NCommander is away: This creature sleeps beyond the reaches of time itself
[11:25] <Hobbsee> !away | NCommander
[11:25] <NCommander> seb128, not at the moment, need some sleep
[11:25] <seb128> ok
[11:25] <NCommander> Lets try that again
[11:25] <seb128> NCommander: 'night
[11:25] <NCommander> good
[11:25] <NCommander> ... well
[11:25] <NCommander> Expect I'm unmarked away when I speak ;-)
[11:27] <azeem> NCommander: consider using screen_away.pl in case you use irssi
[11:28] <cjwatson> azeem: thanks, hadn't seen that before
[11:31]  * wgrant finds it excellent.
[11:32] <wgrant> persia: Wow, is http really faster than bzr+ssh for you?
[11:33] <persia> wgrant: considerably, although I have a high-bandwidth high-latency environment, which I think is rare.
[11:33] <wgrant> That's rather surprising.
[11:33] <seb128> NCommander: the GPL text should be in the tarball since there is some file under the GPL licence
[11:34] <persia> Could well be due to some QoS adjustments by my provider: there's a lot of focus on giving the appearance of fast speeds here, and there's only so much more improvement available to be done to the infrastructure.
[11:34] <wgrant> Ah.
[11:35] <persia> I also suspect caching, as repeated http runs against the same source got successively lower speeds, whereas pushing the pulled branch, and checking that out went back to the higher speeds.
[11:35] <cjwatson> successively *lower* speeds?
[11:35] <cjwatson> anti-caching?
[11:35] <persia> s/speeds/times/
[11:36] <cjwatson> aha :)
[11:36] <persia> Thanks for the correction :)
[11:50] <jpds> cjwatson: Thanks for the manpage corrections.
[11:53] <cjwatson> no problem
[12:22] <siretart> cjwatson: assuming that wpasupplicant would produce a working udeb at some point, in what seed would it need to be in in order to end up on the alternate cd?
[12:24] <cjwatson> udebs mostly go in the installer seed
[12:24] <cjwatson> (in platform.intrepid)
[12:25] <siretart> I see. thanks
[12:26] <cjwatson> is somebody working on adding wpa support to netcfg?
[12:26] <cjwatson> hmm, apparently so (stuff on debian-boot)
[12:32] <siretart> I believe so, but nobody has cared to contact the wpasupplicant maintainers in debian about this yet
[12:40] <siretart> ah, it seems kel has been notified. ok
[12:42] <ogra_> woah, scrollkeeper is noisy with current livefs builds
[12:42] <pitti> didn't we switch to rarian nowadays?
[12:42] <ogra_> no idea, scrollkeeper is still seeded
[12:43] <ogra_> and the postinst didnt change yet apparently ...
[12:43] <ogra_> seems there are issues with XInclude in /usr/share/gnome/help/libs/C/legalnotice.xml
[12:44] <ogra_> /usr/share/gnome/help/libs/C/legalnotice.xml:13: parser error : Extra content at the end of the document

[12:44] <ogra_> ^
[12:44] <ogra_> heh
[14:27] <pitti> zul: do you have any tester for bug 180493 or can verify yourself with the hardy-proposed .debs? and can you please upload the fix for bug 242325 to intrepid? after that is done, I can consider accepting the next samba SRU which is sitting in the queue
[14:35] <pitti> seb128: FYI, i386 retracer finished consolidation, python duping in progress (works fine)
[14:35]  * seb128 hugs pitti
[14:35] <seb128> pitti: thanks for the sru copies, I asked to slangasek before my holidays but apparently he did do those
[14:36] <pitti> seb128: feel free to do them yourself in such cases (verified, and forgotten to copy)
[14:37] <seb128> pitti: right, will do next time, I was a bit in a hurry and I though slangasek would look at those while we were in holidays
[14:39] <pitti> fta_: I don't understand your apport change, the regexp: ((firefox|seamonkey|flock)[^\s]*)
[14:39] <pitti> fta_: why the ^\s*?
[14:40] <pitti> fta_: shouldn't it match for "firefox %s", too?
[14:41] <pitti> fta_: oh, it would already, it's just a very confusing regex
[14:41] <Adri2000> pitti: zul: bug #222804 as well, it seems the fix wasn't even uploaded...
[14:43] <Adri2000> cjwatson: amsn still on your radar? :)
[14:54] <fta_> pitti: the idea is to match firefox, firefox-2, firefox-3.0, firefox-3.1, seamonkey, seamonkey-2.0, etc...
[14:55] <pitti> fta_: oh, I see what you mean now
[14:56] <fta_> pitti, someone requested opera too but i don't know wherever opera uses -new-window, or --new-window or something else.
[14:56] <fta_> should be trivial to add now
[15:00] <pitti> fta_: I'll fix the epiphany regex and merge
[15:00] <fta_> pitti, it is not correct ?? i tested it
[15:00] <pitti>                         browser = re.compile('(epiphany[^\s]*)', preferred_browser)
[15:01] <pitti> fta_: before you used "(epiphany)"
[15:01] <pitti> fta_: suppose you have a program epiphany-2.22
[15:01] <pitti> fta_: then the regex would only deliver "epiphany" and you'd call the wrong program
[15:01] <fta_> pitti, well, should not happen but ok, fine with me :)
[15:02] <pitti> fta_: just for the sake of consistency with the other re, and correctness :)
[15:02] <fta_> sure
[15:02] <pitti> fta_: thanks for the fix!
[15:03] <fta_> np, my default browser is firefox-3.1 so i needed this fix too ;)
[15:19] <dholbach> how is the X utility called again with which it's possible to run scripts that require X without having an xsession?
[15:19]  * dholbach routinely forgets its name
[15:20] <seb128> dholbach: xvfb-run?
[15:20] <dholbach> that's the one, thanks seb128!
[15:20] <seb128> you're welcome ;-)
[15:21] <dholbach> seb128: I know... it's my own fault - if I was still on the Desktop Team..... :-)
[15:21]  * dholbach hugs seb128
[15:21] <seb128> lol
[15:21]  * seb128 hugs dholbach
[15:22] <asac> james_w: http://paste.ubuntu.com/42414/
[15:22] <asac> james_w: why does bzr builddeb needs to be so picky and fail on that?
[15:23] <james_w> asac: that's fixed in my branch
[15:23] <james_w> asac: sorry for introducing the bug
[15:23] <asac> james_w: no problem
[15:23] <asac> james_w: will the "default result-dir" change also be reverted?
[15:23] <asac> (i had to put result-dir in builddeb.conf)
[15:23] <james_w> asac: I don't think so
[15:24] <dholbach> james_w: bzr bd --figure-out-what-my-problem-is-and-do-something-about-it isn't a default option yet? :-)))
[15:24] <james_w> asac: it just won't fall over if you specify the result-dir to be the same as where the packages end up
[15:24] <asac> james_w: ok. however, the fact that --result=DIR is the option while builddeb.conf needs result-dir=DIR isnt obvious ;)
[15:24] <james_w> dholbach: that's planned for version 24
[15:24] <dholbach> james_w: I asked for it ages ago ;-)
[15:24]  * dholbach hugs james_w
[15:25] <james_w> asac: ah, I hadn't noticed that. I should probably unify them somehow.
[15:25] <james_w> asac: thanks for the bug
[15:25] <asac> james_w: yes. maybe use --result-dir in command line and keep support for --result= ...
[15:25] <asac> at least -dir is in line with the rest
[15:25] <james_w> yeah
[15:26] <james_w> asac: bug 263643
[15:26] <asac> james_w: another good thing would be: --export-upstream-dir=... so
[15:26] <asac> i can actually place them into --tarballs-dir directly ;)
[15:27] <cjwatson> Adri2000: done now, sorry for the delay
[15:27] <asac> in that case bzr builddeb should bail out if there is a tarball with the same upstrewam version imo
[15:27] <james_w> asac: what would --export-upstream-dir do?
[15:27] <asac> james_w: it would export the orig.tar.gz produced in the given directory
[15:27] <asac> james_w: atm it gets into --build-dir=...
[15:28] <james_w> it goes to --tarball-dir I think
[15:28] <asac> james_w: no it doesnt ... at lesat if you use the default for --tarball-dir
[15:28] <asac> (unless it changed in 2.0)
[15:29] <asac> nope. i can confirm that it doesnt get placed inteo ../tarballs/ ... just in --build-dir=...
[15:29] <asac> i think that makes sense ... one probably doesnt want to wipe a good tarball in --tarball-dir= ... unless explicitly stated
[15:29] <james_w> asac: ah, yeah, I was thinking of the uscan downloading
[15:29] <Adri2000> cjwatson: thanks!
[15:30] <asac> james_w: so ... option a) use --export-upstream-dir=... and overwrite whatever exists there ... _or_ copy to --tarball-dir unless a tarball with the same name exists there
[15:30] <asac> that would be my ideas on this
[15:31] <Q-FUNK> howdy!   could someone look into bug #259036 ?
[15:34] <james_w> asac: there are two use cases here, and I think it was originally written for the wrong one
[15:34] <james_w> asac: but I'm not sure it's possible to do the right one in a way that is both useful and correct
[15:35] <Q-FUNK> oh, thanks! :)
[15:35] <cjwatson> Q-FUNK: synced on the basis of bryce's +1. I'm not going to look at the SRU until somebody offers up a candidate patch that meets the usual requirements though; perhaps the X team can help with that
[15:36] <Q-FUNK> cjwatson: understood and agreed. the Hardy SRU is more involved.
[15:36] <cjwatson> "fixing deficiencies of packaging" would not be a normal valid SRU target
[15:37] <cjwatson> fixing hardware that's just plain broken can be provided that the risk of regression elsewhere is very carefully handled and limited
[15:37] <cjwatson> anyway, I don't really want to get into that; a sync was quick :)
[15:39] <Q-FUNK> indeed :)
[16:08] <asac> james_w: --result-dir isnt honoured for source bits :(
[16:09] <james_w> asac: using -S or --source, or doing something like "--builder 'debuild -S'"?
[16:16]  * ogra curses
[16:17] <ogra> my laptop doesnt survive DPMS
[16:18] <ogra> tjaalton, bryce, is there anything known with intel ? it *seems* that i dont have any input after the screen switched to dark ...
[16:18] <tjaalton> ogra: with .27?
[16:18] <tjaalton> kernel
[16:18] <ogra> though killing X via ssh didnt bring anything back either
[16:18] <ogra> yeah
[16:18] <tjaalton> right
[16:18] <ogra> ah, known ?
[16:19] <tjaalton> seen that too, same with .26 but fine with .24
[16:19] <tjaalton> so I'd blame the kernel :)
[16:19] <ogra> i didnt have it with .26
[16:19] <ogra> i use to keep my lappie running over night and find a black screen since .27 in the morning
[16:20] <ogra> so seems to be a kernel issue
[16:20] <tjaalton> think I tried .26 when I first saw that
[16:20] <tjaalton> downgrading the driver at least didn't help
[16:21] <ogra> hmm, looking at #ubuntu my xchat stopped logging at 16:07 (i left the machine at 16:04 and got back around 17:00 (20 min ago))
[16:22] <ogra> so its triggering something else, though nothing seemed to hang when i looked via ssh
[16:22] <ogra> weird
[16:30] <ScottK> pitti: Not every possible packer format.  Those two are the ones that are currently recommends from Debian.  There are plenty of others that are not.
[16:31] <Don-S> I have written a program in Python and would like to make a package out of it, but I'm not really sure what to do...
[16:31] <Don-S> Can anyone help me on it?
[16:31] <ScottK> Don-S: #ubuntu-motu is a better place for that kind of question.
[16:31] <Don-S> Okay, thanks.
[16:34] <geser> are there any known issues with xvfb? I ask because I've seen some builds where the test suite failed because xvfb won't start
[16:37] <Ng> ogra: fwiw disabling compiz seems to "help" with that, fsvo help meaning "it doesn't crash, but it's slow and ugly instead"
[16:37] <ogra> aww
[17:02] <lool> Hey what do you people do to solve "X--tag=CC: command not found" kind of libtool build failures with Ubuntu's libtool?  I did libtoolize  :-/
[17:02] <lool> what I run in my autofoo patch is: libtoolize --force --copy && aclocal-1.10 -I m4 && automake-1.10 --add-missing --force --copy && autoconf && rm -rf autom4te.cache
[17:05] <cjwatson> lool: try autoreconf -i -f
[17:06] <cjwatson> lool: http://lists.gnu.org/archive/html/autoconf/2008-07/msg00047.html
[17:06] <lool> Hmm right, I could have used the official tool rather than being clever
[17:07] <Keybuk> it's worth noting as well that libtoolize --force doesn't do what you think
[17:07] <Keybuk> --force means "break my build"
[17:08] <cjwatson> Keybuk: interesting that autoreconf passes --force through to libtoolize
[17:08] <lool> cjwatson: (thanks for the pointer)
[17:08] <cjwatson> (should we not be using autoreconf -f either?)
[17:10] <cjwatson> also, libtoolize --install isn't documented in its man page
[17:12] <cjwatson> and the info docs appear not to be packaged
[17:12] <lool> So I should be running libtoolize --force --copy --install instead?
[17:12] <lool> cjwatson: libtool-doc has an info?
[17:12] <cjwatson> I think that's the idea, but I've just been converting stuff to autoreconf
[17:13] <cjwatson> oh, so it does. I wonder why 'info libtool' ignores it then
[17:13] <lool> I don't like autoreconf because it tends to run more stuff than needed and wont pick the upstream versions of the tools if possible
[17:13] <cjwatson> perhaps because libtool-1.gz is missing and libtool.gz only has references to it rather than any actual documentation
[17:13] <cjwatson> bug 254182
[17:14] <Keybuk> I can't think of any situation where --force is necessary
[17:14] <lool> Keybuk: I wonder whether symlinks are converted to real files if you don't run it
[17:14] <lool> If you don't pass --force that is
[17:15] <cjwatson> I think I was led to believe that the autotools wouldn't update existing files reliably if you didn't use --force
[17:15] <cjwatson> this may have been due to inadequately precise documentation
[17:15] <Keybuk> it's probably more likely to do with the strange state that Debian kept automake in for a while
[17:15] <Keybuk> it may not have behaved properly, that led everyone just to always use --force
[17:16] <Keybuk> --force is only intended for "this is broken, fix it!"
[17:16] <lool> I jsut ran libtoolize and it converted a real ltmain.sh into a symlink
[17:16] <Keybuk> and if used without --install means "remove the broken stuff, but don't put anything new back"
[17:16] <Keybuk> lool: --copy ;)
[17:16] <lool> Keybuk: And --copy wont fix it
[17:17] <lool> So I think --force is used in e.g. gnome-autogen and misc autogen script to make sure no symlinks are used
[17:17] <cjwatson> Keybuk: mind if I fix libtool's info docs?
[17:17] <Keybuk> cjwatson: please do, I saw the bug and couldn't work it out
[17:17] <Keybuk> info and me are not friends
[17:17] <cjwatson> it's a matter of appending one line to debian/libtool.info I think
[17:17] <Keybuk> lool: if you run libtoolize --copy it won't convert a real ltmain.sh into a symlink
[17:18] <Keybuk> if you do run it without, it may convert, and then won't convert it back
[17:18] <Keybuk> that's one of the cases for --force
[17:18] <Keybuk> but you only care if you do it wrong in the first place
[17:18] <lool> Keybuk: No, but if a maintainer ever ran libtoolize, it will convert to a symlink
[17:18] <Keybuk> in general
[17:18] <Keybuk> "autoreconf -i" when checking out of revision control
[17:18] <lool> And then you need --force to fix it
[17:18] <Keybuk> and whenever you want to update to newer tools
[17:18] <Keybuk> otherwise rely on automake's inbuilt maintainer script handling
[17:19] <lool> The point is, if you can run a single command which always fixes this situation, it's easier than having to distringuish between two use cases
[17:19] <lool> But I heard you that "libtoolize --force" might break stuff
[17:19] <lool> I'm just trying to explain the likely rationale with using --force in many autogen scripts
[17:20] <Keybuk> there's no rationale for autogen scripts in the first place ;)
[17:20] <cjwatson> I find autogen useful to keep sanity checks in, followed by running autoreconf
[17:20] <cjwatson> also, autoreconf doesn't call gnulib-tool yet
[17:21] <lool> gnome-autogen allows forcing this or that autofoo version you're using
[17:21] <cjwatson> ah, now, I definitely don't believe in forcing autotools versions
[17:21] <cjwatson> it's an excuse for not writing correct code
[17:21] <lool> Unfortunately, some GNOME modules rely on automake 1.7
[17:22] <Keybuk> lool: err, why not just use AM_INIT_AUTOMAKE([1.7]) ?
[17:22] <cjwatson> right, so they've just arranged to forget about the bug :)
[17:22] <lool> Keybuk: I don't know; they don't use it though :)
[17:23] <cjwatson> lool: do you mean "exactly 1.7" or "at least 1.7"?
[17:23] <cjwatson> AM_INIT_AUTOMAKE is the latter
[17:23] <lool> Exactly 1.7 as in newer would break stuff
[17:23] <Keybuk> newer shouldn't break things
[17:23] <Keybuk> those are called "regressions"
[17:23] <cjwatson> Keybuk: there aren't internal interfaces in 1.7 that automake broke?
[17:24] <Keybuk> cjwatson: shouldn't be
[17:24] <cjwatson> (but that people were using anyway)
[17:24] <Keybuk> oh, if they were doing crazy shit, suuure :p
[17:24] <cjwatson> that is surely the common case with the autotools ;-)
[17:24] <lool>         Autom4te::Channels::msg('ac_config_headers="$ac_config_headers config.h"\x{a}\x{a}\x{a}#\x{a}# For eac...', 'configure.in:154', 'warning: The macro `AM_DISABLE_STATIC\' is obsolete.\x{a}You shou...') called at /usr/bin/autom4te line 1020
[17:24] <Keybuk> in theory, the option allows compatibility too
[17:24] <lool> Is what autoreconf -i tells me after setting version to 1.7
[17:24] <Keybuk> so if you say 1.7, and 1.12 breaks something, it can see you wanted 1.7 and behave that way anyway
[17:24] <Keybuk> gettext does this
[17:25] <Keybuk> lool: that's a warning?
[17:25] <lool> aclocal: autom4te failed with exit status: 1
[17:25] <lool> is how it fails
[17:25] <Keybuk> that's a bug ;)
[17:25] <Keybuk> it's clearly trying to emit a warning ;)
[17:26] <lool> Right; I believe there are many requires changes to get gtk+ and other GNOME modules of comparable size to build with newer autofoo
[17:26] <lool> Upstream even said they would take patches :)
[17:26] <Keybuk> I tried that with GNOME
[17:26] <Keybuk> I got told they were porting to scons, or cmake, or some other thing
[17:27] <lool> Some modules now support two build systems   :-(
[17:27] <Keybuk> autostuff's main problem is that it's too easy to get at the innards
[17:27] <Keybuk> and too easy to get wrong
[17:27] <lool> Keybuk: But I don't think platform libs are in that camp; some module maintainers might like it, but most people have learnt autofoo anyway
[17:28] <cjwatson> should be msg $cat, $loc, "warning: $msg", (type => 'warning'); shouldn't it?
[17:28]  * lool finds it a pity to require people to write in so many various syntaxes to update autotools
[17:28] <cjwatson> (on autom4te:1020)
[17:28] <ScottK> cjwatson: Thanks for the pass over hardy-backports.  It's been wanting for some time.
[17:28] <cjwatson> and probably 1024 too
[17:28] <cjwatson> ScottK: only partial, I'm afraid, but got the list down a bit
[17:30] <cjwatson> hmm, actually, isn't the problem that ac_config_headers=blah is being passed as the message category? that's clearly rubbish
[17:30] <cjwatson> it's supposed to be something like 'syntax'
[17:31] <lool> Hmm I had a spurious patch in my tree, I wonder whether I typoed when I generated the one calling libtoolize
[17:31] <lool> Anyway, it works with libtoolize --force --copy --install
[17:33] <cjwatson> so can we get gnome-autogen.sh fixed at least in our gnome-common package?
[17:33] <cjwatson> to use --install
[17:33] <lool> Keybuk, cjwatson: Sorry folks, it works with simply calling libtoolize --force --copy
[17:33] <lool> I tried again and it works without --install
[17:33] <lool> It produces exactly the same changes
[17:33] <cjwatson> it'll work the *second* time if you've already run with --install ...
[17:33] <lool> I just mistyped my patch update
[17:33] <lool> cjwatson: I did not
[17:37] <lool> seb128: You file FFEs for GNOME stuff?
[17:37] <NCommander> ScottK, you available to chat?
[17:38] <ScottK> Breifly
[17:38] <ScottK> Urgh.  If spelled correctly, that's what I meant.
[17:41] <seb128> lool: no, GNOME has a standing exception
[17:43] <lool> seb128: I'll push what I did for pygobject; I pondered betweek a private lib in /usr/lib/pygobject/pythonX.Y and /usr/lib/libpyglib-pythonX.Y, did the former, and now upstream prefers the latter of course
[17:43] <lool> seb128: I'll push what I did for pygobject; I pondered betweek a private lib in /usr/lib/pygobject/pythonX.Y and /usr/lib/libpyglib-pythonX.Y, did the former, and now upstream prefers the latter of course
[17:44] <lool> seb128: So I'll push that now but it will likely change upstream to public libs, and we might have to add a new binary package or two
[17:44] <seb128> lool: ok, thanks a lot for working on that!
[17:45] <cjwatson> File: libtool.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
[17:45] <cjwatson> much better
[17:45] <lool> cjwatson, Keybuk: (sorry again for wasting your time on the non-issue)
[17:45] <cjwatson> --install isn't documented in the info docs either :P
[17:46] <lool> cjwatson: Ah thanks for fixing this
[17:46] <lool> vi on the info file wasn't too confortable
[17:47] <Keybuk> lool: errr
[17:48] <Keybuk> you certainly need --install if you use --force
[17:48] <lool> Keybuk: There's no difference between the two patches with --install and without
[17:49] <cjwatson> lool: it is possible to get lucky
[17:49] <lool> cjwatson: Sure, I understand that
[17:49] <Keybuk> lool: depends on the order you run automake and libtoolize
[17:50] <lool> I run libtoolize first
[17:50] <Keybuk> if you run libtoolize after automake without --install, it will cheerfully *remove* config.sub, config.guess and install-sh
[17:50] <lool> Now, I'm happy to learn what install does
[17:50] <Keybuk> if you run it before, automake --install will put them back
[17:50] <lool> And also to fix gnome-common upstream and in Debian/Ubuntu
[17:50] <Keybuk> fix => just use autoreconf, really
[17:51] <lool> I outlined briefly why I don't use autoreconf
[17:51] <Keybuk> I missed that?
[17:51] <lool> Goal being not to have megabytes of patches
[17:52] <NCommander> cjwatson, thanks for processing part of the backports queue :-)
[17:52] <lool> Well autoreconf will run the latest version of the tools, might not be the one upstream uses, and it might run tools which aren't really needed
[17:52] <lool> For instance it might run automake even if I only touched configure.ac
[17:52] <Keybuk> if you touched configure.ac, you might need to run automake ;)
[17:52] <lool> Not sure my example is good enough
[17:52] <lool> Right
[17:52] <Keybuk> you certainly need to run autoheader
[17:52] <Keybuk> bet you don't run that one <g>
[17:52] <lool> You might
[17:52] <lool> I run autoheader when I add defines
[17:53] <lool> But I don't run it systematically
[17:53] <Keybuk> it's worth pointing out that if you touch configure.ac, when you "make", automake will run itself anyway
[17:53] <lool> If you don't use AM_MAINTAINER_MODE certainly?
[17:53] <Keybuk> right
[17:53] <Keybuk> if you're using AM_MAINTAINER_MODE, I'll just make funny faces and laugh at you whenever you have an autostuff question <g>
[17:54] <lool> Keybuk: Consider cdbs' bug which removes patches before running distclean
[17:54] <NCommander> Can someone please giveback kdeutils, and kdeedu?
[17:54] <lool> This means that if you touch autofoo files, you get automake, autoconf etc. run when calling distclean
[17:54] <Keybuk> yes...
[17:55] <NCommander> Keybuk, recently autotools default MAINTAINER_MODE to on, with no way to disable
[17:55] <lool> I don't want my build to trigger auto* because of timestamp things
[17:55] <Keybuk> NCommander: you have misunderstood the meaning of the macro
[17:55] <lool> The .diff.gz and the cdbs patch system issues make this possible though :-/
[17:55] <Keybuk> lool: do you want your build to make .o files because of the timestamp of .c files? :)
[17:55] <Keybuk> or, for example, if you have a .y file - do you want your build to run bison if you change that?
[17:55] <lool> Keybuk: Yes; but the build-deps required to run auto* are not the same as those for building the package
[17:56] <Keybuk> the usual preferred way I've seen cdbs handled is to make your patches
[17:56] <Keybuk> and have a 99-autoreconf patch in which you run "autoreconf"
[17:56] <Keybuk> therefore the last thing that cdbs does when applying patches is the effect of an autoreconf
[17:56] <NCommander> Keybuk, the meaning of the macro is the cause autoconf rerun itself when one of its config files are touch. An annoying design when it comes to packaging
[17:56] <Keybuk> and therefore the first thing that it does when unapplying is reverse that
[17:56] <Keybuk> NCommander: false.
[17:56] <lool> Keybuk: Read above: I only consider the *unpatch* case
[17:57] <cjwatson> I think that's workable with cdbs, but not with .diff.gz, because the timestamp order may not be what you want
[17:57] <lool> cjwatson: Actually .diff.gz isn't too much of a problem
[17:57] <cjwatson> oh, actually, that dpkg-dev bug got fixed didn't it
[17:57] <lool> Because timestamp is reset after applying
[17:57] <Keybuk> NCommander: the meaning of the macro is, confusingly, the exact opposite of your statement
[17:57] <cjwatson> nowadays I think it sets them all to the same timestamp
[17:57] <lool> cjwatson: exactly
[17:57] <cjwatson> right, I filed the bug suggesting it should do that :)
[17:57] <Keybuk> adding AM_MAINTAINER_MODE will cause automake to *NOT* run autostuff when the source files are changed
[17:57] <lool> cjwatson: Now we would need to do that after applying quilt patches or simple-patchsys patches
[17:57] <lool> And after unapplying them
[17:58] <Keybuk> or, more exactly
[17:58] <lool> But it's not easy to know what to touch after un applying them
[17:58] <NCommander> Keybuk, maintainer-mode is what triggers the autobuilding of files!
[17:58] <Keybuk> NCommander: false.
[17:58] <Keybuk> or, more exactly
[17:58] <cjwatson> lool: right, the problem here is that multiple files in a cdbs patch (e.g.) might end up with different timestamps after application
[17:58] <Keybuk> adding the macro causes an --enable-maintainer-mode and --disable-maintainer-mode options to be added to configure
[17:58] <cjwatson> or at any rate that's one of the problems
[17:58] <Keybuk> with the default as "disable"
[17:58] <cjwatson> because patch might be unlucky and run across a second boundary
[17:58] <lool> cjwatson: That, and unpatching will also touch the timestamps
[17:58] <Keybuk> *without* the macro, there are no options, and the default is "enable"
[17:58] <cjwatson> you need to have quilt etc. do it, really
[17:59] <lool> cjwatson: Typically if you patch configure.in in patch 1 and configure in 99, unpatching will cause configure.in to have a newer timestamp
[17:59] <lool> cjwatson: Problem is: which files do you reset the timestamp of when unpatching?
[17:59] <lool> You would need to save all timestamps or a list of fiels to timestamp
[17:59] <lool> And it becomes unworkable for dpatch and simple patchsys; probably even so for quilt
[18:00]  * cjwatson <- glad he avoids patch systems, really :)
[18:00] <lool> haha
[18:00] <cjwatson> works fine if your whole tree's in bzr ;-)
[18:00] <Keybuk> cjwatson: I got berated for failing to add a patch system when patching an Ubuntu package ;)
[18:00] <lool> The most annoying bug is that cdbs bug which unpatches before distclean
[18:00] <lool> Because even if I add MAINTAINER_MODE, it will have no effect
[18:01] <lool> cjwatson: It also works fine if debian/patches is a quilt series and you use the format 3.0 (quilt) mode; we'll come to that I guess :)
[18:01] <lool> I really sound stupid when I go ask upstream to please add am_maintainer_mode because our antique patch based build system breaks when it's not in the upstream tarball
[18:01] <Keybuk> lool: why ask the upstream?
[18:02] <lool> I inevitably get told (correctly) that am_maintainer_mode isn't good, isn't recommended upstream etc.
[18:02] <lool> Keybuk: Because if it's not in the released tarball, I can't patch it in usefully
[18:02] <cjwatson> Keybuk: I either ignore such complaints or point out why they're wrong, depending on my mood. I believe that current MOTU mood is that this is wrong
[18:03] <cjwatson> (actually, though, I get hardly any such complaints)
[18:04] <lool> seb128: GNOME #550235 for the 62_install-pyglib-in-libdir-with-python-version stuff
[18:04] <Keybuk> the irony is
[18:04] <Keybuk> the way cdbs works gets this right
[18:05] <Keybuk> if you patch the source files only
[18:05] <Keybuk> you can entirely rely on automake to do the right thing
[18:05] <Keybuk> you just need it in the build-deps
[18:05] <Keybuk> yes, it'll run it on build and clean, but that's not a bad thing
[18:05] <lool> Keybuk: It's fragile to run auto* without looking
[18:05] <Keybuk> it isn't
[18:05] <lool> How many times have I seen missing macros silently dropped from aclocal.m4
[18:06] <Keybuk> if you read the automake run-things rules, you'll see they sanity check their own work
[18:06] <lool> Many upstreams don't ship proper m4 files, or don't set aclocal flags correctly
[18:06] <Chipzz> cjwatson: looking at debian-boot archives wrt wpa stuff; can't find anything. which thread?
[18:06] <cjwatson> Chipzz: I googled for "wpa netcfg"
[18:06] <cjwatson> first hit
[18:06] <lool> Keybuk: It might be correct in the tools, but too many upstream and packagers get this wrong
[18:07] <Chipzz> ah k, just not August :)
[18:45] <mathiaz> james_w: FYI, I've been using bzr looms to handle the openldap package.
[18:45] <mathiaz> james_w: https://code.launchpad.net/~mathiaz/openldap/pkg-ubuntu
[18:46] <mathiaz> james_w: I'm using sftp:// rather than lp: to push the code as the lp bzr server doesn't support loom apparently
[19:02] <tormod> slangasek: what happened with bug #192772, you promised to upload before FF?
[19:38] <saivann> I'd like to request developers to take a look at security bug 55159 . I spoke of this problem with siretart and I attached patches to revert the changes, but I believe that this would need discussion
[22:38] <saivann> I'd like to request developers to take a look at security bug 55159 . I spoke of this problem with siretart and I attached patches to revert the changes, but I believe that this would need discussion


[05:48] <pradiprwt> Hi everyone, I am facing issue with provider network it is not able to acceesseble from outside . and route gateway interface showing always down
[05:49] <pradiprwt> can any one please help me ho I can trouble shoot
[05:49] <pradiprwt> I have deployed openstack using autopilet
[07:53] <tjbiddle> Hi all. Could really use your help. I’m going on day 3 of banging my head on the wall without success here. Trying to setup a NAT server so that another server can have internet access. The NAT server has full Internet access, the client server has DNS working - but ping, curl, etc. will not work. All ports are wide open for internet and intranet from my hosting providers security group ACLs. Here’s some debug information on both machines -
[07:53] <tjbiddle> https://gist.github.com/thomasbiddle/ef9ad16d33df722f5061106042c2d2ae
[08:13] <jamespage> ddellav, coreycb: nova b3 underway
[08:16] <jamespage> ditto cinder
[09:00] <pradiprwt> Hi Everyone, Can anyone help me to understand openstack-neutron in autopilot deploymnet
[09:27] <jamespage> ddellav, coreycb: nova, cinder and networking-ovn all uploaded
[09:30] <jamespage> moving on to keystone
[09:43] <jamespage> as well as manila
[09:57] <jamespage> coreycb, ddellav: doing glance
[09:57] <jamespage> keystone uploaded
[10:06] <jamespage> coreycb, ddellav: manila uploaded
[10:06] <jamespage> glance needs cursive to work its way in - in the Ubuntu binary NEW queue atm
[10:44] <jamespage> ddellav, coreycb: picking ceilometer up
[10:44] <jamespage> branch builds make this high throughput - thankyou for helping to make that effective!
[10:46] <jamespage> and aodh
[10:52] <zioproto> hello all
[10:52] <zioproto> jamespage: are you here today ? :)
[10:52] <jamespage> I am
[10:53] <zioproto> I tried to rebuild the stable/liberty horizon package
[10:53] <zioproto> and did not build for trusty
[10:53] <zioproto> https://www.dropbox.com/s/faadi3sfkmfjgeb/horizon_8.0.1-0ubuntu1_amd64-20160902-0955.build?dl=0
[10:54] <zioproto> where is the proper place to fill a bug for this compile issues ?
[10:54] <jamespage> zioproto, ok so horizon is a little awkward to build, due to a packaging nuance - it uses two orig.tar.gz 's
[10:54] <jamespage> one for horizon, and then we bundle all of the xstatic dependencies in a second one
[10:55] <jamespage> zioproto, have a look at debian/README.source
[10:55] <jamespage> for details on how to generate that second tarball
[10:55] <zioproto> OK will try to build it after reading the README and I will give you feedbacl
[10:56] <zioproto> I noticed because I am upgrading the documentation I have not github
[11:05] <jamespage> coreycb, ddellav: aodh uploaded
[11:07] <ddellav> jamespage very productive this morning
[11:09] <ddellav> jamespage is there a list somewhere of what's left? Or is it just todays releases - what you've just done?
[11:09] <ddellav> s/-/minus
[11:13] <zioproto> jamespage: so running the command ./debian/rules refresh-xstatic will create the tarball
[11:13] <zioproto> it creates it in the wrong directory
[11:13] <zioproto> I moved it build-area
[11:13] <zioproto> sorry I mean the tarball horizon_8.0.1.orig-xstatic.tar.gz
[11:14] <ddellav> zioproto i found it's better to use debuild with horizon.
[11:14] <ddellav> i've not gotten gbp to work
[11:16] <zioproto> ddellav: what I have to exactly that will differ from here: https://wiki.ubuntu.com/OpenStack/CorePackages ?
[11:17] <ddellav> zioproto it's basically the same, except instead of using gbp buildpackage -S you use debuild -S
[11:17] <ddellav> obviously the xstatic-orig tarball needs to be in the same directory as the orig.
[11:18] <zioproto> so I should call before manually ./debian/rules refresh-xstatic and place the tarball in the right place
[11:18] <zioproto> I will try
[11:18] <ddellav> you call refresh-xstatic, that will put the extra orig tarball in ../
[11:18] <ddellav> then from inside the same directory you run debuild
[11:18] <ddellav> it's a drop-in replacement for gbp
[11:22] <zioproto> ddellav: when I run gbp buildpackage -S it will download in the folder ../build-area the tarballs. But when I use debuild -S -us -uc it complains there are no tarballs
[11:24] <ddellav> zioproto are you trying to update horizon or just build what's there in the repo already?
[11:24] <zioproto> just build what is in the repo already
[11:25] <zioproto> ddellav: started with debcheckout --git-track='*' horizon
[11:25] <ddellav> ah ok, well gbp will pull out the existing orig tar from the pristine-tar branch, hence it's name: git-buildpackage. I thought you were updating, so you would've had to pull an updated orig tar ball for that to work.
[11:25] <zioproto> then I checkout the stable/liberty branch
[11:25] <zioproto> I pasted the build log earlier
[11:26] <ddellav> ok, since you're not updating, you don't want to do refresh-xstatic. That's only if you're updating a non-stable release. What you want to do is pull the existing orig-xstatic tarball from the archive and use that
[11:29] <ddellav> zioproto i assume you're using the 8.0.1 release? Here is the existing xstatic tarball: https://launchpad.net/ubuntu/+archive/primary/+files/horizon_8.0.1.orig-xstatic.tar.gz
[11:30] <ddellav> you put that, plus this: https://launchpad.net/ubuntu/+archive/primary/+files/horizon_8.0.1.orig.tar.gz in the directory directly above the horizon repo directory, then from INSIDE horizon, run debuild -S -us -uc
[11:30] <ddellav> and that will get you the .dsc so you can run sbuild or do whatever it is you want to do
[11:43] <coreycb> ddellav, zioproto: updatd https://wiki.ubuntu.com/OpenStack/CorePackages for horizon
[11:44] <coreycb> ddellav, jamespage: we can follow here to see where we're at with b3: https://private-fileshare.canonical.com/~coreycb/ca_upstream_versions_newton.html
[11:44] <ddellav> coreycb ah right, good call
[11:44] <coreycb> ddellav, jamespage: I fixed it up to favor upper-constraints versions over what's in github.com/openstack/releases/deliverables/newton
[11:53] <zioproto> ddellav: I was able to build horizon using the debuild command
[11:53] <zioproto> But I really want to understand
[11:53] <zioproto> I did a diff of the dsc files
[11:53] <zioproto> file
[11:53] <zioproto> I mean the one created with debuild and the one created with gbp buildpackage
[11:53] <zioproto> http://pastebin.com/j8cXRWFQ
[11:54] <zioproto> so different horizon_8.0.1-0ubuntu1.debian.tar.xz are generated ?
[11:54] <ddellav> so im confused, you ran gbp and it completed and generated a dsc?
[11:55] <zioproto> yes
[11:55] <ddellav> ok then what was the issue?
[11:55] <zioproto> the fail is later, when I run sbuild-liberty against the dsc
[11:55] <ddellav> i mean if that worked you didn't need to use debuild
[11:55] <zioproto> exact, but the dsc generated by debuild is proper so that later I can build sucessfully with sbuild-liberty
[11:55] <ddellav> what is the issue with sbuild? is it saying it can't import xstatic?
[11:56] <zioproto> https://www.dropbox.com/s/faadi3sfkmfjgeb/horizon_8.0.1-0ubuntu1_amd64-20160902-0955.build?dl=0
[11:56] <zioproto> here the build log
[11:57] <ddellav> yea, no module named xstatic.main
[11:57] <ddellav> that's what always happened when i used gbp as well which is why i use debuild. For whatever reason gbp does not properly import the xstatic tarball
[11:58] <ddellav> though it's showing a weird patch problem as well which shouldn't be happening
[12:01] <zioproto> yes I am bit confused what is the real problem
[12:01] <zioproto> btw I found the workaound of using debuild
[12:13] <coreycb> jamespage, ddellav, I'm working on horizon
[12:13] <zioproto> coreycb: fyi I was on the stable/liberty branch
[12:14] <coreycb> zioproto, ok.  sorry I was talking about newton b3 there.
[12:14] <zioproto> no problem
[12:15] <ddellav> coreycb jamespage im working on neutron
[12:15] <ddellav> i mean neutron-*
[12:23] <zioproto> something not openstack specific. The Vagrant image ubuntu/xenial64 has this bug open since long: https://bugs.launchpad.net/cloud-images/+bug/1565985 Do you guys know who to ping about this ?
[12:24] <Odd_Bloke> zioproto: I believe the fix to that is sitting in -proposed at the moment. :)
[12:28] <zioproto> I guess a lot of Vagrant users will not move to xenial until the image is stable as the trusty one
[12:28] <zioproto> I updated my tool to build the UCA packages https://github.com/zioproto/ubuntu-cloud-archive-vagrant-vm
[12:28] <zioproto> now it is aligned to the official docs
[12:30] <ddellav> coreycb please review: lp:~ddellav/ubuntu/+source/neutron-fwaas
[12:31] <ddellav> jamespage coreycb working on murano
[12:32] <coreycb> ddellav, we sync murano from debian
[12:32] <coreycb> ddellav, looking at neutron-fwaas
[12:32] <ddellav> coreycb ok
[12:33] <ddellav> coreycb i'll take trove then
[12:33] <coreycb> ddellav, +1
[12:34] <ddellav> coreycb nvm, trove b3 is already pushed just not released
[12:35] <coreycb> ddellav, you  sure?
[12:35] <ddellav> coreycb oh i didn't see the dev release there, nvm
[12:36] <ddellav> coreycb ready for review: lp:~ddellav/ubuntu/+source/neutron-vpnaas
[12:37] <coreycb> ddellav, can you move psycopg2 and pymysql to BD-Indep?
[12:37] <ddellav> coreycb sure
[12:37] <coreycb> ddellav, nm I'll do it, quicker that way
[12:38] <ddellav> ok
[12:46] <jamespage> zioproto, gbp does not support multi-orig tar balls
[12:46] <jamespage> zioproto, so yes you have to use debuild to generate the source package
[12:46] <jamespage> its less than ideal - apologies
[12:47] <zioproto> ok great ! at least we have a specific reason for that !
[12:56] <coreycb> ddellav, neutorn-fwaas pushed/uploaded
[13:04] <jamespage> coreycb, ddellav: ok glance uploaded
[13:04] <jamespage> cursive published (was blocking)
[13:04] <jamespage> I'll raise the MIR for that now
[13:06] <coreycb> jamespage, awesome, moving right along!
[13:06] <coreycb> ddellav, neutron-vpnaas pushed/uploaded
[13:09] <coreycb> jamespage, ddellav: horizon's going to take a bit, I want to test it a bit since the xstatic imports/patch have changed quite a bit
[13:09] <coreycb> how many times can I say bit
[13:09] <jamespage> coreycb, ta - thanks for taking that one
[13:09]  * jamespage least favourite
[13:11] <ddellav> i think it's everyones least favorite
[13:12] <drfritznunkie> Anyone here from Ubuntu who maintains the community AWS AMIs? It looks like all instance store AMIs in us-east-1 are gone/invalid
[13:12]  * ddellav thinks horizon is a great candidate for snapping
[13:13] <jamespage> coreycb, could we add ubuntu-proposed to the version tracker?
[13:13] <jamespage> that might be useful for spotting blockages
[13:13] <coreycb> jamespage, I'll look into it, should be fairly simple
[13:14] <jamespage> coreycb, ddellav: oslo's look up-to-date now - do  we have some work todo on clients as well still?
[13:14] <jamespage> I think we do looking at the report
[13:15] <drfritznunkie> we're seeing errors when launching new instances like: Client.InvalidManifest: HTTP403 (Forbidden) for URL ubuntu-us-east-1/images/hvm-instance/ubuntu-trusty-14.04-amd64-server-20160620.manifest.xml
[13:15] <coreycb> jamespage, yeah, they could use some work.  they should be fairly small bumps.  I took a pass earlier this week but they've released new versions since.
[13:15] <ddellav> coreycb please review lp:~ddellav/ubuntu/+source/neutron-lbaas
[13:19] <jamespage> coreycb, I'll take a run through
[13:20] <coreycb> jamespage, ok thanks
[13:24] <coreycb> ddellav, neutron-lbaas pushed/uploaded, thanks
[13:24] <freenerd> I'm seeing the same problem as drfritznunkie in us-east-1 for instance store AMIs. All (even some over a year old) are gone.
[13:25] <freenerd> 14.04 LTS that is
[13:33] <jamespage> coreycb, ddellav: cinder and congress clients uploaded
[13:36] <coreycb> jamespage, ddellav: working on backporting some things to the uca in the background here
[13:49] <jamespage> ddellav, coreycb: python-ironic* uploaded
[13:49] <jamespage> fwiw I'm prepping them as uploads for experimental and pushing to git, then versioning for ubuntu and direct uploading
[13:49] <jamespage> I'm not pushing the ubuntu versions to git
[13:50] <coreycb> jamespage, ok that's what I've done as well
[13:51] <jamespage> coreycb, ok
[14:01] <coreycb> jamespage, ddellav: I'm working on os-brick
[14:03] <jamespage> coreycb, doing clients still
[14:03] <jamespage> coreycb, ddellav: python-keystone* done
[14:03] <jamespage> auth and middleware
[14:03] <jamespage> doing magnum now
[14:11] <zioproto> Odd_Bloke: I found as a workaround to install vagrant-vbguest plugin
[14:12] <coreycb> jamespage, ddellav: os-brick uploaded.  looking at oslo.db/messaging.
[14:12] <jamespage> coreycb, ddellav: magnumclient done
[14:14] <jamespage> manilaclient next
[14:15] <coreycb> jamespage, oh yay no more merging of oslo.messaging, thanks
[14:17] <jamespage> coreycb, \o/
[14:17] <jamespage> yeah that should help a bit
[14:23] <jamespage> coreycb, you might want to hold on oslo.db - .1 broke gnocchi
[14:23] <coreycb> jamespage, ah ok will do
[14:24] <coreycb> jamespage, I'll just push it
[14:28] <jamespage> coreycb, ddellav: manila and murano client libs done
[14:28]  * jamespage looks for next
[14:29] <jamespage> neutron and nova clients on my list next
[14:29] <dlloyd> anyone else seeing 403s with ubuntu amis from cloud-images.ubuntu.com in us-east-1?
[14:30] <Odd_Bloke> dlloyd: Yep, it's a known problem; we're working to fix it.
[14:30] <dlloyd> ok cool, thanks
[14:33] <Odd_Bloke> dlloyd: It should only affect instance-store AMIs, so you could switch to using EBS whilst we sort it out. :)
[14:33] <dlloyd> hah, fair
[14:33] <dlloyd> its also on the mile long todo list to vendor our own ;)
[14:34] <dlloyd> out of curiosity is this the best forum to see status about similar issues in the future?
[14:37] <ddellav> coreycb can you review liberty branch of lp:~ddellav/ubuntu/+source/neutron for sru?
[14:37] <drfritznunkie> the AMI outage in us-east-1 has been ongoing since 5AM EDT
[14:37] <drfritznunkie> where would the best place, as dlloyd mentions, for problems like this? here?
[14:39] <drfritznunkie> Odd_Bloke: any idea how soon the AMIs will be back up in us-east-1?
[14:41] <jamespage> ddellav, coreycb: nova and neutron clients uploaded
[14:41] <jamespage> that's the lot I think
[14:42] <coreycb> jamespage, \o/
[14:43] <jamespage> coreycb, ok
[14:44] <coreycb> jamespage, ddellav: oslo.messaging uploaded
[14:44] <ddellav> jamespage :D
[14:46] <jamespage> aodhclient got missed - doing that now
[15:21] <coreycb> ddellav, neutron 7.1.2 uploaded to liberty-staging
[15:21] <ddellav> coreycb thanks
[15:26] <Odd_Bloke> drfritznunkie: We're restoring now, it's just a matter of data transfer. :)
[15:33] <drfritznunkie> Odd_Bloke: the AMI ids are not going to change, correct?
[15:33] <Odd_Bloke> drfritznunkie: Correct.
[15:48] <Odd_Bloke> drfritznunkie: dlloyd: You should be seeing AMIs becoming usable again now; we're doing August, then 2016, then everything.
[16:01] <dlloyd> Odd_Bloke: awesome, thanks for the update
[16:06] <drfritznunkie> Looks like August and June are back up Odd_Bloke, thanks for the hard work!
[16:07] <drfritznunkie> Any idea what happened?
[16:08] <Odd_Bloke> drfritznunkie: Yep, a job accidentally "cleaned up" all the files in our us-east-1 S3 bucket. :)
[16:09] <drfritznunkie> ha BTDT, I feel your pain
[16:13] <drfritznunkie> Odd_Bloke: this is pushing up our backlog for vendoring our own images, do you all have your build scripts/process posted somewhere? I can find anything that is recent
[16:13] <drfritznunkie> ...can't find anything recent
[16:16] <Odd_Bloke> drfritznunkie: Unfortunately not, it's a lot of Jenkins and shell scripts.
[16:17] <Odd_Bloke> drfritznunkie: And our case is pretty specialised (i.e. publish the same image in _every_ region for every storage type and every virt type), so you probably wouldn't need a lot of the complexity that we have. :)
[16:21] <drfritznunkie> I figured as much, but our AMI rolling scripts are 3+ years old at this point, and didn't know if we've missed the state-of-the-art in AMI rolling ;)
[16:58] <coreycb> ddellav, jamespage: I uploaded a couple remaining client packages for designate,mistral,senlin,openstacksdk, and will be uploading zaqarclient, openstackclient shortly.
[17:02] <jamespage> coreycb, glance-store as well?
[17:02] <jamespage> tbh I'm done for today - I'll leave the rest in your's and ddellav's capable hands
[17:05] <coreycb> jamespage, I'll take a look, see ya
[17:25] <renatosilva> anyone had problems upgrading from 14.04 to 16.04?
[17:28] <RoyK> quite possibly ;)
[17:29] <RoyK> renatosilva: sometimes some libs get messed up, especially if you're using 3rd party repos
[17:29] <RoyK> but mostly it just works
[17:42] <ducasse> is it maybe time to remove the last section of the topic?
[17:47] <RoyK> ducasse: perhaps ;)
[19:26] <blizzow> Urgh, running my root partition on top of an mdadm raid1 device is destroying my life. Does anyone else here experience terribly slow performance with this?
[19:27] <blizzow> Running apt-get update just sends dpkg into a D state for minutes at a time.
[19:33] <blizzow> All the drives are returning good info via smartctl
[19:33] <blizzow> Nothing in the logs is saying anything bad.
[19:34] <blizzow> But a dist upgrade that hits the linux kernel/headers packages takes more than 15-30 minutes. :(
[19:37] <sarnold> ouch
[19:40] <genii> Maybe your /boot is getting small
[19:42] <sarnold> misaligned sectors comes to mind as a possibility but I have trouble seeing how even that could force twenty minute dist-upgrades
[19:55] <compdoc> raid1 shouldnt be slow
[19:55] <compdoc> you could test it by breaking the mirror and running on one disk
[20:16] <sbeattie> blizzow: check your syslogs for disk errors as well, smartctl sees most things, but not always.
[20:35] <JanC> if it's SATA controller / SATA communication errors, SMART might not see it, I guess
[20:40] <patdk-lap> smart log would show it
[20:40] <patdk-lap> atleast if the error made it to the cable
[20:41] <patdk-lap> blizzow, what drive are you using, and what is it's age?
[20:41] <patdk-lap> fill filesystem will make it slow
[20:41] <patdk-lap> bad sectors will make it slow, until they actually fail, and they can take 45min to fail
[20:42] <patdk-lap> using one of these new shingle drives and a non-cow filesystem will be painful
[20:42] <sarnold> oww
[20:43] <patdk-lap> cow isn't so important, as much as writting data as a log is
[20:44] <blizzow> sbeattie: I've looked in syslog.  The only weird thing I see is this:  dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device: Dev dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0/host8/port-8:7/end_device-8:7/target8:0:7/8:0:7:0/block/sdi/sdi1 and /sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0/host8/
[20:45] <blizzow> patdk-lap: brand new SAS 7200 RPM seagate 4TB drives.
[20:45] <sarnold> standard systemdism, those happen everywhere :(
[20:45] <patdk-lap> that looks fine
[20:45] <patdk-lap> ah, so scsi smart, that is completely different from sata smart
[20:46] <patdk-lap> better and worse at the same time, the drive has smarts in it, so it doesn't show you raw info
[20:47] <blizzow> Filesystems are super clean. 2.8GB of 15GB used for the root partition.  3.6MB of 511MB used for /boot/efi
[20:52] <blizzow> sarnold: I did an alignment check on all the drives, they're optimal.
[20:53] <sarnold> topped up on blinker fluid?
[20:53] <patdk-lap> :)
[20:53] <blizzow> The pokey bits are plugged into the recepticals and the electrical faeries are flowing as far as I can tell.
[20:55] <sarnold> hehe
[20:56]  * patdk-lap goes to change his headlight fluid
[21:10] <tarpman> make sure the switch is set to MORE MAGIC, etc