#ubuntu-devel 2005-08-29
<seb128> martinald: what kind of reply do you expect? version? if it's installable?
<martinald> is it going to be shipped with breezy?
<seb128> yep
<martinald> ah k
<rtcm> martinald: http://packages.ubuntu.com/changelogs/pool/main/o/openoffice.org2/openoffice.org2_1.9.121-1ubuntu11/changelog
<martinald> cool. will it be out of beta by the time breezy is released?
<seb128> that's probably a question for oo.o2 guys :)
<martinald> right, let's say it's not - will updated versions be backported for breezy
<ogra> martinald, we only backport security and dataloss fixes.... everything beyond that would be a question to the backports team guys
<martinald> hm
<ogra> like in debian
<martinald> is this policy going to change? I asked a while about it and iirc there was going to be some discussion about it
<seb128> we are 2 months before 5.10 and people already want to backport stuff ...
<ogra> a stable release is sable...
<ogra> stable even
<ogra> seb128, yes *sigh*
<seb128> martinald: backports are here for people who wants to update to new versions
<ogra> martinald, thats why there is a backports team now
<martinald> yes, for example let's say it doesn't ship and there is a few critical bugs that are neither security nor dataloss but provide serious pain for a good chunk of users
<seb128> we backport fixes
<martinald> does that mean users will have to actively go out and install backports?
<martinald> as opposed to just clicking on the ubuntu update applet
<seb128> no, fixes are backported for such bugs
<ogra> martinald, we have a official backports team, no need to "go out"
<jcole> how do i trick apt into thinking a dependency exists?
<seb128> you don't
<martinald> seb128: sure, but let's say there was a problem with the word importer that was neither dataloss nor security but failed on a quite a few documents
<ogra> jcole, dependencys are there for a reason
<martinald> would you backport the fix for that?
<pitti> martinald: not for a stable release
<martinald> don't you think that's a huge problem?
<pitti> martinald: since the patch for that is probably > 1000 lines
<jcole> ogra: ya, but apt doesn't see a virtual package that is installed... so i need to tell apt it is installed (cause it really is)
<seb128> martinald: new versions also give new bugs
<jcole> i thought it was something like... apt-get install synaptic -o APT::Get::Fake-Provides="libapt-pkg-libc6.3-5-3.9"
<martinald> seb: true. but say you ship openoffice 1.9.151 or something, but it has a bug that stops a lot of word documents opening, but it's fixed in openoffice 2.0. surely it would be a better idea to ship that update?
<ogra> jcole, rather reinstall the virtual package so that apt sees it
<pitti> martinald: if you would allow such updates, what would make a stable release stable?
<jcole> ogra: --reinstall ?
<ogra> martinald, how do you guarantee that the 90 language packs we ship for it still work, how do you make sure it doesnt break other things ? 
<seb128> martinald: this has been discuted again and again, you have to put limits. Everybody clames that the new version of his favorite software fixes some stuff ... but experience shows it brings also new issues
<martinald> good point. but surely suggesting users have to wait 6 months to get major bugs fixed is a problem
<ogra> martinald, a stable release has recieved months of bugfixing and testing work... why should we break that ?
<ogra> martinald, major bugs get fixes
<pitti> martinald: that's why we try to fix major bugs *before* the release
<martinald> i've just pointed out a bug that wouldn't probably get fixed...
<seb128> martinald: you are basically saying "the version from 2 weeks before 2.0 is total crap and they automagically changed that in 2 weeks because they changed the number to 2.0"
<martinald> no i'm not
<martinald> i'm saying there is likely to be bugfixes in the final release
<seb128> martinald: and new bug will not be grabbed
<seb128> martinald: you can say that for any new version of a sotfware, it's supposed to fix bugs ... 
<martinald> yes but generally new software fixes bugs surely
<ogra> martinald, you showed today that you dont like our theme, our color selection and our policy to handle stable releases, may i ask what you like on ubuntu ?
<seb128> martinald: you need to run a siftware some time to know it's stable
<martinald> that's uncalled for, i was simply debating ogra
<ogra> just out of interest ...
<rtcm> martinald: if a bug is really annoying to a lot of users it will be spotted and fixed before the release
<martinald> what do i like? many things. i love the hardware detection, installer, use of latest gnome etc etc
<ogra> martinald, thanks :)
<slomo> elmo: please sync bb from debian (aalib and slang2 transition, ftbfs fix for gcc 4.0)
<martinald> rtcm: we both know that sometimes bugs that are critical will be unspotted
<pitti> martinald: btw, if you do want new versions, breezy is for you :-) But today you told us that it is too unstable
<martinald> pitti: there is a bug in colony 3 which means i can't boot it
<ogra> martinald, critical bugs recieve fixes, even in stable releases
<martinald> that's why i'm trying the nightly cd
<pitti> martinald: that's exactly what would happen if we put new versions into stable releases
<martinald> surely a new openoffice bug wouldn't break booting?
<seb128> martinald: no but it could crash by example
<pitti> martinald: it pulls in new dependencies, and so on, so it might break your desktop, which is equally bad
<seb128> martinald: some new stable firefox broke extensions by example
<ogra> martinald, but who guarantees that it doesnt break all docs out there for example, because the fix breaks doc handling ...
<pitti> seb128: meh
<pitti> martinald: right, ffox is a nice example
<martinald> the problem is that on windows or mac you could get a binary and install it if you wanted it fixed, but you can't do that on linux
<pitti> martinald: we *did* put a new upstream version into stable, and it caused lots of trouble
<martinald> pitti: true
<ogra> martinald, you can, thats why we hae a backports team...
<martinald> ogra: ok, but does the backports team backport every new release of main software?
<pitti> martinald: epiphany broke, some extensions broke, some packages were rendered ftbfs, enigmail broke after tbird upgrade, etc.
<ogra> but that doesnt guarantee the stability we can guarantee after months of work
<pitti> martinald: once you start, you are in a mess
<seb128> martinald: if you want every new version don't use stable
<ogra> martinald, the team backports waht gets requested by users
<seb128> pitti: epiphany/warty is still b0rked (now than you speak about that)
<michele> martinald: well, you can grab binaries from OOo's website and install those
<pitti> seb128: yes, just thought about that
<ogra> martinald, but it cant track   sideeffects and doesnt test as intensive as we do it
<michele> martinald: so you can have the latest version, as you do on mac and win
<martinald> what i mean is that say i have a buisness customer is using xyz package which has a bug in hoary which is uncommon but for him means that ubuntu is unusable
<martinald> but the bug is not common enough for it to be backported
<martinald> what does he do?
<pitti> martinald: then a specific backport is what he needs
<seb128> martinald: if you sell service you can backport fixes for issues reported by users
<pitti> martinald: major software like gaim, ffox, etc. is usually backported
* dredg finally loses his temper with the whole 'trying to do things with the network at boot time when there is no network'
<martinald> seb: ok, ignore customer, replace it with 'friend'
<dredg> a small script running ethtool suits my purposes for now
<pitti> martinald: do a backport yourself or ask for one :-)
<martinald> i can't backport myself. and there isn't any demand from the community to do it (being a very uncommon bug)
<dredg> but between now and the kickoff for breezy+1 i think i'll be trying to come up with a single standard way of testing for a network link
<martinald> on mac/windows i could say 'ok, just go to www.project.net and install the latest version over the top'
<ogra> martinald, if you ask the backports team, it will do the backport fo you
<pitti> martinald: you can do the same with Ubuntu
<ogra> thats what its there for
<michele> or you can always hire somebody to do the backport...
<martinald> fine, say it's a charity then
<michele> well... is network-manager in universe or main?
<pitti> and what ogra said, that's what I meant with "<pitti> martinald: do a backport yourself or ask for one :-)"
<Mez> what you want backporteD
<seb128> martinald: what do you do on IE when outlook has a bug not fixed by MS ?
<pitti> Mez: TEH WORLD
<pitti> Mez: nevermind, just theory :-)
<martinald> seb: that's different.
<ogra> Mez, nothing yet, but martinald will ask you for openoffice as soon as breezy is released ;)
<pitti> martinald: but you see, the backport guys are listening :-)
<Mez> martinald, email me - martin@sourceguru.net or ubuntu-backports@lists.ubuntu.com regarding backports stuff
<Mez> ogra: lol
<seb128> martinald: how so?
<seb128> martinald: there is some case you have bugs and that's all
<martinald> because in my scenario there is a fix availiable but due to the OS i'm running it's not available. in that situation there is no fix available regardless of OS
<seb128> martinald: you can't fix every single minor bug happening for anyone
<ogra> martinald, but we just prove that it *is* available... Mez will backport what you ask for
<pitti> "ask your local backports dealer"
<pitti> hehe :-)
<ogra> martinald, the app just wont be as heavily tested as the one in the release
<seb128> martinald: use unstable so
<ogra> :)
<martinald> ogra: ok. but what happens if mez for whatever reason can't or won't backport
<seb128> martinald: so you have every new version, good way to learn that they don't only fix bugs
<rtcm> martinald: ask/pay another person to do it for you
<ogra> martinald, if he won't just poke him even more or send him some rowdys :)
<pitti> seb128: and that's GOOD
<seb128> ;)
<pitti> seb128: imagine what happened if, say, from warty on all upstreams only fixed bugs
<pitti> seb128: breezy would be bug free, boring, and we would be jobless
<seb128> yeah
<ogra> martinald, if he cant, he has the whole distro team to ask for help
<seb128> pitti: why do you think I break the panel? Want to keep my job :p
<ogra> hah, i *knew* its intended
<martinald> well maybe you have me convinced that backports is a good idea
<ogra> *g*
<martinald> and that i'm fretting over nothing :)
<martinald> i assume backports are not turned on by default?
<seb128> nop
<martinald> how hard is it to add backports?
<martinald> for the average user
<ogra> martinald, but for your customer, it will be you who has the risk for newly introduced bugs...
<seb128> add 1 lines to the sources
<seb128> 1 line
<seb128> and click on synaptic update
<martinald> ok that's too complex for most users
<seb128> (people are never happy)
<ogra> clicking two times ? is to hard for an admin in a company at your customer ?
<martinald> i'm not saying for me ogra, i'm saying for mrs joe smith who has a problem with openoffice and would like the fix that is waiting in backports
<martinald> mr*
<rtcm> martinald: is it easier to go after some random installer on the net and clicking through an installer wizard?
<martinald> rtcm, yes
<seb128> martinald: synaptic is not harded than a website
<seb128> I don't agree
<mvo> martinald: if it's too complex to add backports, then it's maybe too complex/worrying to actually install/use backports?
<mvo> I mean, backports do not have the same level of QA as the rest of the archive
<seb128> martinald: upgrading software to new versions on a stable system is not a good idea that's why it doesn't work out of the box
<martinald> well i was thinking there should be a checkbox in the update-manager saying 'Would you like Ubuntu to search for updates which don't impede security or dataloss'?
<martinald> or something
<mvo> IMHO you can't have dead-easy and cuting-edge
<seb128> martinald: you want to push people to unstability and new bug, feel free but don't expect the distro to do that for you
<martinald> well this is the problem
<seb128> use unstable if you want that
<martinald> if you don't solve this then there will be a large amount of users who don't understand computers very well but have broken software
<martinald> and they go to the software site and they are told there is an update available
<martinald> but they don't know how to get it
<seb128> they don't bring new bugs and keep the stable tested version
<seb128> that's good :)
<pitti> martinald: btw, you can enable backports in synaptic (or at least it would be easy to allow that)
<jdub> GOOD MORNING FREEDOM LOVERS!
<martinald> pitti: synaptic is still too complex for most regular users to use
<seb128> HEY HEY HEY jdub
<pitti> Hey jdub 
<ajmitch> mornign jdub 
<seb128> martinald: these users just use the stable version and the security updates
<pitti> martinald: ok, but for these users it is also too dangerous to confront them with backports in the first place
<pitti> seb128: right
<martinald> pitti but on windows/mac users do this all the time
<martinald> with very little trouble
<martinald> why should it be different on linux?
<seb128> and they complain all the time about stuff not working right
<pitti> martinald: no, they don't
<seb128> I don't agree with the very little trouble
* mvo thinks that might be the reason why those systems are so wonderfully stable
<seb128> they get bugs, they complain, etc
<martinald> i think you'll find they do
<pitti> martinald: in fact many of them don't ever install *any* software
<martinald> pitti: that isn't true either
<ogra_> martinald, most win users i know still run win98
<pitti> martinald: my mother, the folks in my father's company, etc. - they don't touch anything
<seb128> martinald: you are speaking about people going on the web to get new software, these people are able to click on 2 synaptic options
<martinald> ok fair enough but you are not looking at the bigger picture
<pitti> martinald: many people aren't version junkies - they use what they have and get used to bugs and itches
<ogra_> martinald, with the SW they had on it in the first place
<martinald> the fact is the majority of windows users use XP
<martinald> which is very stable
<dredg> it's true. for the majority of users who do X number of tasks, provided that nothing breaks they will never change the software
<ogra_> i doubt that
<pitti> no, in companies etc. many folks still use 2K or even 98
<martinald> pitti: look at the statistics
<martinald> well over 60% of windows machines are XP
<seb128> martinald: 40% is a good part
<martinald> and all new computers are sold with xp now, or 95%
<ogra_> martinald, in my last company XP was a no go, they still use 2k all over the place and that wnt change the next years
<pitti> martinald: and how many corporate XP users will ever touch the software?
<pitti> martinald: most of them can't even
<martinald> corporate is not the same
<pitti> also private ones
<pitti> my whole family never touches their boxes
<pitti> why should they?
<martinald> well 80m+ users have installed firefox
<pitti> martinald: my gf had used Debian in a pre-woody version for 3 years without touching anything
<martinald> fair enough pitti you can throw all this anecdoatal evidence at me but i am telling you the raw statistics
<seb128> martinald: your statistics
<ogra_> martinald, which statistics ? 
<Burgundavia> martinald, 80 downloads and anyway, they installed FF because the builtin browser is crap
<ogra_> have links ?
<pitti> martinald: most version and install junkies are young home users
<martinald> www.spreadfirefox.com
<pitti> martinald: which know a bit about computers
<ogra_> martinald, about 95% of users using XP
<pitti> martinald: whoever is able to download new windows software and find/install cracks for it certainly knows how to enable backports for Ubuntu
<martinald> i said 95% of new computers are sold with XP
<ogra_> not the firefox promotion page, and please no microsofty study
<pitti> right
<martinald> that's a guess
<rtcm> martinald: hear pitti, he's reaching the point now
<pitti> martinald: that's true, but doesn't change our claim
<ogra_> martinald, so why do you say its based on statistics ?
<ogra_> if its a guess
* pitti speaks about stable versions and uploads PostgreSQL 8.1 alpha to Debian experimental :-)
<ogra_> hihi
<martinald> do you honestly think that less than 95% of new computers sold with windows are not sold with XP?
<pitti> martinald: I don't doubt that
<ogra_> martinald, you said most users *use* XP
<martinald> and i will provide statistics
<martinald> http://www.w3schools.com/browsers/browsers_stats.asp
<ogra_> and that i doubt very much
<martinald> bit biased that one
<pitti> martinald: but most of its users won't fiddle with their configs, also not in XP
<ogra_> give me a real statistic, including all continents
<pitti> ogra_: even if they did, it doesn't change our target user for stable releases
<pitti> whether the stable version is called hoary, 2K or XP is irrelevant
<pitti> many people just stay with what they have
<seb128> martinald: by beeing a new version addict you get bugs for sure
<ogra_> pitti, nope, and its hilarious offtopic for this channel anyway, lets stop it *now*
<pitti> (apart from computer freaks, of course)
<pitti> ogra_: ok, rikght :-)
<ogra_> ;)
<martinald> http://wesnerm.blogs.com/net_undocumented/2005/07/windows_markets.html
<martinald> which says xp is at ~40%
<martinald> so i was slightly wrong
<martinald> but it shows that only 5% of users use 95 and 98
<martinald> perhaps someone can clear this up for me: what is the target audience of ubuntu?
<pitti> that means 60% of users use software > 5 years old
<martinald> use an OS > 5 years old
<pitti> right
<martinald> many will stick with windows 2000 precisely because it lets them run all their new software
<martinald> if software forced them to upgrade to XP they would
<pitti> but that will be similar for Office etc.
<martinald> well i don't know
<martinald> i shall see :)
<rtcm> martinald: sane people I believe :-)
<martinald> i can't find any stats on office marketshare
* mvo__ goes to bed now because his network hates him anyway
<ogra_> mvo__, and i thought my line was crappy today...
<pitti> good idea
<ogra_> night all
<pitti> good night everynody
<martinald> ok night guys
<mvo__> ogra_: usually it's not _that_ bad. but tonight ... oh well
<ogra_> mvo__, they changed the dslam two days ago here... i drop once an hour since...
<ogra_> mvo__, night :)
<jdub> it was just pointed out to me that our kernel is built with 3.4, but our default compiler is 4.0
<ogra_> jdub, yes
<jdub> we don't really have a nice way of getting, say, "kernel-build-essential" ;)
<jdub> that'll be a gotcha for some users
<ogra_> jdub, poke fabbione 
<mvo__> night ogra_ (and everyone)
<Burgundavia> jdub, should we put a seperator between the categories and g-a-i on the applications menu? It looks quite quished
<jdub> the separator was intended - if it's not there, please file a bug
<wasabi_> Hmm. So me and my boss (long time UI designer) just sat down in front of OS X and argued about UI design.
<wasabi_> It has occured to me that listing Home Directory in the Places menu is not helpful.
<wasabi_> OS X does it too. ;)
<Burgundavia> jdub, is that -menus or g-a-i?
<luis> wasabi: you have to have *some* way to get to home, so... where else are you going to put it? :/
<wasabi_> Why?
<wasabi_> What do you need to use your home directory for?
<wasabi_> Yeah this argument sucks.
<wasabi_> Okay, my reason for bringing this up is because my boss expressed confusion at there being two differnet ways to get to Documents
<wasabi_> And he wasn't sure what the difference between the folders were.
<wasabi_> Weither one was for everybody, or one was for just himself.
<HrdwrBoB> home directory should be desktop
<HrdwrBoB> that solves that problem
<HrdwrBoB> but makes a lot of people whinge
<spacey> my desktop would be too cluttered
<HrdwrBoB> spacey: that's not an inherent problem with it
<mdz_> wasabi_: I'm pretty sure this has been done to death upstream in gnome, and this was the only way for the desktop and unix to meet in the middle ;-)
<HrdwrBoB> that's a problem with how you manage files
<wasabi_> yeah
<wasabi_> heh
<spacey> HrdwrBoB, i know your right :D
<wasabi_> I just enjoy the UI paradigm arguments usually.
<mdz_> wasabi_: did you find any low-hanging fruit in OS X that we could borrow for ubuntu?
<mdz_> the last time I looked at it, it seemed like the major differences between it and gnome fell under the category of "bling"
<Burgundavia> mdz, pop-ups for fn keys
<HrdwrBoB> since I've changed home to be desktop, I use nautilus a lot more, since I can actually get to all my files in a sensible logical way from all access methods
<wasabi_> Well, one of the next complains was about what happens with unknown file systems. OS X fails this. You download a .sit file.
<wasabi_> And try to open it.
<wasabi_> And a new user is going to be confronted with a list of possible programs to open it with.
<mdz_> Burgundavia: how does that work?
<wasabi_> And most of them are going to be useless.
<HrdwrBoB> is the default for images now gthumb?
<Burgundavia> mdz, when you hit a fn key (brightness or sound), it pops something up showing the change
<wasabi_> And it will be set to open by default, by default.
<HrdwrBoB> because the default image viewer is completely useless
<Burgundavia> mdz, we already have a mute one
<mdz_> Burgundavia: we only recently got the keys working at all ;-)
<mdz_> on laptops anyway
<wasabi_> We don't allow unknown file types to be open at all on a double click.
<wasabi_> just noticed that
<Burgundavia> mdz_, hey, I shot for the moon. LEO is not far enough
<wasabi_> Our error message just sucks.
<Burgundavia> wasabi, the huge one?
<wasabi_> Can't Display Location \ Couldn't display "/home/jhaltom/ssl/ISIdatapro.key".
<wasabi_> No, that one sucks too, btw
<Burgundavia> mdz_, have you seen our mute key pop-up
<mdz_> no
<mdz_> I don't have a mute key
<Burgundavia> ah
<tseng> Burgundavia: i "designed" that mute key popup
<Burgundavia> tseng, it is quite nice, one minor bug
<tseng> Burgundavia: it sucked worse before, i filed a bug on several inconsistancies
<tseng> i think it was hadess fixed it up
<Burgundavia> tseng, https://bugzilla.ubuntu.com/show_bug.cgi?id=14062
<jdub> Burgundavia: panel
<tseng> why did you report it there, out of curiosity
<Burgundavia> jdub, I will change it then
<Burgundavia> tseng, I have never seen it, though it was something mjg59 did
<tseng> Burgundavia: no, that was part of the old bug
<Burgundavia> ok
<tseng> what would happen was, it set the volume to zero
<Burgundavia> tseng, got a bug # for me?
<tseng> as "mute"
<Burgundavia> ah
<tseng> now it really mutes it and saves the stat
<tseng> e
<HrdwrBoB> I have a better idea
<tseng> i guess you want to go one step further and *look* like mute = 0 volume
<HrdwrBoB> it should show you the level, but grey it out
<HrdwrBoB> becaute mute != 0 volume
<Nafallo> mdz: hi! is it a possibility that some apps could have built earlier on amd64 than i386 and then still have got libcairo1 depends (timer-applet for instance)?
<Burgundavia> HrdwrBoB, yes it does
<tseng> HrdwrBoB: right.
<Burgundavia> from a user perspective it is
<mdz_> Nafallo: it's fairly unlikely; the usual method is to wait for the package to be built on all 3 architectures and then do the transition
<HrdwrBoB> as a user, I also want to know what the volume is though
<mdz_> Nafallo: if there is a specific case you're referring to, please name it
<Nafallo> mdz: I did, timer-applet on amd64 depends on libcairo1 here.
<mdz_> there may still be packages in universe which haven't transitioned yet
<tseng> Burgundavia: http://bugzilla.gnome.org/show_bug.cgi?id=140937
<Nafallo> it was rebuilt as ubuntu2, but on amd64 that depends on libcairo1 it seems.
<wasabi_> Ok I have low hanging fruit, mdz.
<mdz_> Nafallo: that's because -0ubuntu2 hasn't built on amd64 yet
<wasabi_> OS X has the dock bar. One of the things that makes it way better than any window list is you know that when you put an icon on it, it stays where you left it. If you put it way to the left, it stays there. And it lets you quickly open your programs.
<Burgundavia> tseng, where both the bug reported and your bug fixed?
<wasabi_> It's annoying using a windows list where the order of the icons is based on the order you open the programs.
<Nafallo> mdz: aha. that was to easy to figure out for me I guess ;-)
<tseng> Burgundavia: yes
<Nafallo> mdz: thanx :-)
<Burgundavia> tseng, ok
<wasabi_> Possible solution: Let users drag window list buttons to different positions.
<wasabi_> And remember them. Somehow.
<Burgundavia> tseng, mine is actually about the visual state, not about what it actually does
<tseng> Burgundavia: it makes alot more sense to file your bug @ gnome than ubuntu to me
<mdz_> Nafallo: in fact it failed to build on amd64 and powerpc both
<mdz_> http://people.ubuntu.com/~lamont/buildLogs/t/timer-applet/1.1-0ubuntu2/
<Burgundavia> tseng, I would have, but I didn't realize that it was a non-ubuntu specific thing
<tseng> Burgundavia: ok.
<wasabi_> Probably just store something like "this app should be at position 4" and do a best effort to fulfill that.
<wasabi_> or maybe "this app should be to the left of this other app and to the right of this one".
<Burgundavia> tseng, so the control-center actually provides the pop-up?
<tseng> Burgundavia: yes
<mdz_> yay, amd64 livefs build is working again
<tseng> or it did however many releases ago i filed that bug
* Nafallo smells give-backs :-P
<tseng> Nafallo: i smell i told you it was ftbfs :P
<Nafallo> tseng: did you? :-)
<tseng> something like that, yes.
<tseng> but im starving, better go
<Nafallo> I'm not sure I would want to call that ftbfs :-P
<tseng> anyone notice metacity crashing all over the place?
* dredg shakes head
<dredg> anything in .xsession-errors?
<tseng> not about that
<dredg> i'm afraid that i've no idea
<jdub> mozilla-openoffice.org -> tell me this is not a plugin for viewing OOo documents in the web browser...
<jdub> the description hints at that, but doesn't really confirm the suspicion
<wasabi> Eh. That plugin sounds sucky.
<wasabi> I am really getting PISSED at the totem plugin.
<wasabi> Why does everything have to open in the damned browser?
<HrdwrBoB> win 26
<schweeb> fabbione: awake?
<HrdwrBoB> argh
<wasabi> If I click on a file, I just want that file to open, in all it's glory!
<schweeb> wasabi: rm it
<wasabi> I do. I just recently diverted it. ;0
<wasabi> But then I can't view REAL embedded media.
<wasabi> Stuff that is supposed to be embedded.
<jdub> i like the totem plugin used only when it's embedded
<wasabi> Yeah. That should definatly be the way it's done.
<jdub> i wonder if we can fix that
<wasabi> Hmm. I don't see why not. Surely the browser knows.
<jdub> it's going to be some whackass mime thing
<wasabi> Yeah.
<jdub> and a bad interaction with mozilla
<jdub> should bug seb about it
<jdub> yo Gman 
<mjg59> SUN SPY
<Gman> http://www.smh.com.au/news/world/horror-run-of-august-crashes/2005/08/24/1124562897210.html
<Gman> scarey!
<Gman> mjg59, i'm trying to steal your love.
<mjg59> Gman: Statistics in action
<mjg59> Oh man
<mjg59> If you steal my love, I'll have no love left for laptops!
<Gman> that's probably a good thing
<luis> mjg59: but plenty of hate and bile still, right?
* Gman would love some jds ubuntu love
<mjg59> luis: SO MUCH HATE
<mjg59> Gman: If people ask nicely enough, I'll stick all my patches somewhere useful. Despite them being gross hacks.
<T5-Steboyuk> hi guys
<T5-Steboyuk> do you know why i can't boot off a scsi disk in breezy?
<Gman> mjg59, patches for laptops?
<T5-Steboyuk> i asked in #ubuntu but no-one seems to know
* Gman hates the way linux is so much about vendor specific patches
<mjg59> Gman: Yeah
<Gman> that is, well, arse.
<ajmitch> afternoon
<mjg59> Gman: Of course, you can't steal them. That would be GPL infringement.
<wasabi> That's the goal of bazaar. ;)
<Gman> yeah, we've had the whole cddl/gpl thread on opensolaris-discuss with rms involved
<mjg59> Oh man
<ajmitch> that would have been fun
<mjg59> Gman: Your easiest solution is going to be to run Opensolaris under Xen with a Linux domain 0 kernel
<mjg59> That way shit will work
<mjg59> Still leaves you with problems when you want to ship gcc, though
<Gman> oh come now, 3rd party isvs will flock to opensolaris because they can develop proprietary binary drivers :)
<mjg59> Haha
<mjg59> Shame they'll need to buy a compiler
<mjg59> (I exagerate for comic effect)
<Gman> our compiler is free!
<mjg59> Though I /am/ curious as to how you're supposed to ship a compiler with OpenSolaris
<Gman> although you're right, there is somewhat unobvious agreements with the compiler stuff
* Gman suspects there will be pressure to open source the compiler at some stage
* Gman is just happy to promote opensolaris/solaris as a good developer environment for gnome
<Gman> sod the free-ness of it all :)
<mjg59> Or, indeed, bash
<mjg59> What with the C library not being GPL compatible, and all
<elmo> eh, system library exception surely?
<HrdwrBoB> 'open'solaris
<elmo> tho this is kind of off-topic
<jdub> everything is a system library :)
<mjg59> elmo: Debian doesn't seem to believe that's possible if stuff is coming from the same directory of the same ftp server...
<elmo> the C library slightly more than most :-P
<elmo> mjg59: Debian or debian-legal? ...
<mjg59> elmo: Heh. I was under the impression that that was why we didn't ship KDE?
<mjg59> Back in the old days, that is
<elmo> eh, wasn't that QPL vs GPL?
<elmo> if so, not sure how you get to QT as a system lib
<mjg59> Yeah, but we could have used the system library exemption
<mjg59> By prompting QT to base
<jdub> ha ha
<mjg59> (Which would have been stupid, but still)
<elmo> or we could not ship KDE and have Trolltech dual-license QT under the GPL :-P
<mjg59> Indeed
<mjg59> So Linux distributions should refuse to ship Opensolaris until Sun dual-licenses it under the GPL.
<mjg59> Uhm.
<Gman> :)
<mjg59> Well, it /does/ provide problems when it comes to something like Debian/OpenSolairs
<mjg59> Please pretend I can type. I'm /very/ drunk.
<elmo> shocking
<jdub> I AM SO SURPRISED!
<mjg59> You wouldn't believe how many hours of my life I've spent on laptop love in the past few days
<mjg59> I think I deserve a drink. Or two. Or twenty.
<jdub> mjg59: any ideas on that weird laptop-mode interaction bug?
<mjg59> Hard drives are fucked. Or something.
<mjg59> It's *never* happened to me. On anything.
<mjg59> So it's quite difficult to track down...
<mjg59> Wah. Today I will try to make g-p-m work, and will then tidy up autoconfig of tablet PCs
<mjg59> And then deal with the HUGE pile of bugs that have been assigned to me
<elmo> did bdale ever submit those damn patches for the TC1100?
<mjg59> Did bdale have any?
<elmo> and/or did you/someone get one as part of LAPTOP-MADNESS?
<elmo> he said he had three
<mjg59> I've just implemented half of his kernel patches as 5 lines of shell
<elmo> but had been scared by bugzilla as a small child and avoided it since
<elmo> ok
<mjg59> The other one is awkward
<mjg59> The third is upstream
<elmo> what's the last two?
<mjg59> 1) Random broken shit that's been fixed in Breezy
<mjg59> 2) Enable/disable wireless
<mjg59> (2) is surprisingly awkward
<elmo> oh?
<mjg59> I've got a TC1105, which is a cheaper TC1100
<mjg59> With the exception of wireless stuff, pretty much everything ought to work in Breezy
<elmo> (I discovered the lover of hardware wifi-cut off with this temporary i386 laptop.. how INTUITIVE)
<mjg59> Think yourself lucky that you don't have an amd64 laptop
<mjg59> With luck, we'll sort that stuff out before Breezy
<elmo> dude, znarl DOES have one and I'd kind of like him to have a working laptop :p
<mjg59> elmo: Seriously, half of the misery is HP BIOS bugs
<mjg59> I'm in touch with them, but haven't got far yet
<mjg59> The rest can be dealt with. Probably.
<elmo> are non-big-four laptop's BIOS likely to be better or worse?
<elmo> e.g. fujitsu or samsung
<mjg59> But the BIOS throttles the CPU to 13% of full speed when the temperature gets above 16 degrees
<mjg59> In general, worse
<mjg59> When it comes to amd64, christ knows. Everyone seems to see "amd64" and think "OH MY GOD HOW MUCH CRACK CAN WE SHOVE IN HERE"
<jdub> BIOS are bad
<mjg59> Anyway. Sleep now.
<mjg59> See you funsters in the morning
<elmo> heh, night mjg59
<jdub> sleep well, enebriated one
<lamont> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
<lamont> what was the fix to that again?
<elmo> point the file at a local copy
<elmo> of the DTD
* lamont decides that'll make more sense once he downloads/unpacks the br0ken version of the package
* lamont decides that his blood sugar is to the point that he should go home, eat, and sleep.
<daniels> mdz_: please also set DEBUG_XORG_DEBCONF=user around the dpkg-reconfigure xserver-xorg call in casper
<mdz_> I thought DEBUG_XORG_PACKAGE implied DEBUG_XORG_DEBCONF
<daniels> mdz_: nope
<daniels> mdz_: i think I'm just going to make them imply each other and be done with it
<mdz_> sounds fine to me
<infinity> mdz_ : Do I need to fill out a MainInclusionReport to get linux32 seeded?
<infinity> mdz_ : It's a bit of a necessity for foolproof package building on powerpc64/sparc64/hppa64 systems.  (The buildds are running in linux32 environments as of today, since elmo gave me shiny new ppc64 kernels)
<mdz_> infinity: is it completely trivial?
<fabbione> morning
<infinity> mdz_ : Very.  It just sets the kernel personality, which has very little effect except altering the output of uname -m
<mdz_> infinity: it's like one 2k binary or something, right?
<infinity> 4k, but yes.
<mdz_> I think we can sneak it in...but if it turns out to have some completely crackful packaging bug or something, we'll be coming after you
<jdub> with sticks
<infinity> Big ones?
<infinity> Yay.
<jdub> dipped in banana yoghurt!
<mdz_> pointed sticks
<daniels> just deprive him of hot dog sausages.  he won't be able to live.
<mdz_> and fresh fruit
<infinity> Let's see, it has zero bugs, and is so ridiculously flawless that is hasn't been update/uploaded since December 2004.
* jdub knows infinity hasn't had elderberry training yet
<infinity> I think it's safe. :)
<daniels> deprive him of fresh fruit, or other?
<daniels> because no-one wants scurvy.
<daniels> (incidentally, I sort-of-know two people who got it, but I digress.)
<jdub> yeah, uni students eating dogfood tend to get scuvy
<infinity> mdz_ : I'll seed it to supported right now, then.  Feel free to sharpen a stick in preparation.
<infinity> mdz_ : I just don't feel comfy about running anything (even something this trivial) on the buildds that we don't support.
<fabbione> infinity: sooooo... you like ppc64 on the buildd's.. don't you?
<infinity> fabbione : I'm liking it so far.
<wasabi> I need a little bit of basic C help. I'm working in pmount. I added a new function, do_setup_loop(char * device, char * loop_device). It runs if pmount is trying to mount a file, and creates a loop back device for it before continuing.
<daniels> jdub: in this case it was fish and chips for about six months on end, but yeah.
<fabbione> infinity: stock kernel or custom?
<infinity> fabbione : About to do a mass give-back to see which mysterious failures spontaneously go away.
<wasabi> Error: unable to create loopback device: Value too large for defined data type
<wasabi> perror( _("Error: unable to create loopback device") );
<wasabi> I'm guessing perror looks up the message from some global number?
<fabbione> infinity: ehehhe plenty..
<infinity> fabbione : Definitely a custom config, you'd have to ask elmo if it's from your stock sources.
<fabbione> infinity: yes i am sure it's from the stock source...
<fabbione> infinity: but custom config.. that's what we usually do/he usually does
<wasabi> oh well im going to bed will try again tomorrow
<infinity> fabbione : I think the plan is to run a truely stock kernel on at least one buildd of each arch, to stress test them.  But don't quote me on that.
<fabbione> infinity: yeah.. don't worry.. :) i am not going to crossburn you if we don't
<fabbione> mdz_: what's the situation with the CD's?
<fabbione> did they get fixed?
<mdz_> fabbione: they are built
<mdz_> but I cannot test them right now
<mdz_> I would very much appreciate if you guys would test them
<fabbione> mdz_: yup.. ok.. rsyncing now
<`anthony> wooo google talk goes live.
<luis__> that is so two hours ago. ;)
* luis__ finishes compressing a gnome livecd based on yesterday morning's ubuntu livecd
<`anthony> luis__: Yeah, but it's still cool. Pity they've gone live without documenting their xmpp based calling protocol :-(
<luis__> yeah, indeed.
<`anthony> can I be bothered right now to reverse engineer it, or do I wait for them to document it...
<\sh> morning
<ajmitch> morning \sh 
<\sh> guys...google uses jabber
<luis__> yah
<\sh> http://www.kron4.com/Global/story.asp?S=3757295
<\sh> http://tomservo.cc/blogs/english/archive/2005/08/23/48.aspx
<luis__> http://www.google.com/support/talk/bin/answer.py?answer=24073 <- instructions for gaim :)
<\sh> gajim works as well
<ajmitch> good to see jabber getting someone pushing it  :)
<\sh> they doesn't support the SVR dns records, so u have to setup the "connecting to host" stuff..so shr591@gmail.com is my jid at google...if anyone wants to try
<luis__> ajmitch: yeah; nice to see momentum behind open standards
<\sh> ajmitch: until now google only opened the service..when they're pushing new services in then jabber is ready to rule the propietary IM world
<`anthony> well, they've got an (undocumented) xmpp extension for doing voice calls, as well. yay! death to sip ;)
<`anthony> \sh: Yeah, we're playing with it at work talking to each other. seems to work fine.
<\sh> `anthony: what? The last time I talked to Peter he said, they're working on the JEP and Ulrich Staudinger never said a word...argl...I will kick them
<luis__> \sh: they say in their page that they will support sip 'soon'
<luis__> but in the meantime they have their own protocol that they will document
<`anthony> http://www.google.com/talk/developer.html#protocols
<`anthony> I don't mind, so long as they write it up soon, because otherwise I was going to look at writing the fucker myself.
<\sh> `anthony: hmm...that sounds really good...and regarding UDU Goals I'm quite excited about this...
<\sh> one client for everything...based on opensource standards
<`anthony> \sh: yep.
<ajmitch> \sh: you'll roll it into the shtoom goal?
<`anthony> doesn't even have to be one client. one network is what's important.
<\sh> ajmitch: that's one thing I wanted to do...signaling SIP calls via jabber
<`anthony> open protocols, open networks, open source.
<ajmitch> \sh: that would be great
<ryanthiessen> have any of you been able to connect the talk.google.com to an outside jabber server?
<`anthony> \sh: You're not the only one.
<\sh> ryanthiessen: no
<\sh> ryanthiessen: it's not configured..and SVR records doesn't work either
<`anthony> ryanthiessen: Nope, looks like the federation isn't set up yet.
<ryanthiessen> I do hope they support that eventually
<\sh> `anthony: seeing that you're the famous shtoom guy :) I would like to have u on board for this project...*run*
<ryanthiessen> \sh, you asked for bugreports for gajim, and I'm happy to say that it works fine with google :-)
<`anthony> \sh: it's on my list of goals for shtoom for the next few months.
<\sh> `anthony: so we can work together on this adventure?
<\sh> ryanthiessen: it works fine as well with other jabber servers :) 
<doko> good morning
<\sh> oh damn...I have to go back to the office
<\sh> only 3 hours of sleep is not enough
<ajmitch> \sh: coffee
<\sh> good morning doko :)
<ajmitch> morning doko 
<\sh> ajmitch: I went to office at 3:00 UTC, worked on a change request, and went back home one hour later..just went to bed again..and one hour later..I'm sitting here :)
<\sh> and have to go back..:(
<ajmitch> \sh: you're crazy
<ajmitch> no wonder you turn to ubuntu for comfort :)
<\sh> hahaha
<\sh> ok...preparing to head to office...laters :)
<fabbione> daniels: any news for the fixed mesa ?
<luis__> gnome-app-install has gotten quite nice- congrats, guys
<luis__> mdz: don't know if you care or not, but my livecd on top of your daily of yesterday seems to work pretty well
<pitti> Good morning, world
<fabbione> hey pitti
<infinity> Good morning, Mr Piiii-iiitt!
<ajmitch> hi pitti 
<daniels> fabbione: i've bene working on the serve,r but uploading now
<fabbione> daniels: great thanks
<jdub> so how much ugliness can we rip out of the pre-usplash boot process
<jdub> there's grub poo
<jdub> then the single audit blabber from the kernel
<jdub> which should probably be killed by 'quiet'
<Treenaks> I get a few "hda3: No such volume group"-like messages after that
<Treenaks> and then usplash comes up
<infinity> As do I.  I assume that's an initramfs bug/misfeature, though.
<lathiat> yeh ditto
<lathiat> one thing i noticed is that initrams seems to take alot of time to start booting
<bob2> more than an initrd?
<lathiat> yes
<lathiat> significantly
<lathiat> like 4-5 seconds
<bob2> yay for suspend-to-ram then ;)
<lathiat> heh
<bob2> is suspend-to-disk any faster in 2.6.12?
* lathiat mumbles something about suspend2
* lathiat hides from bob2
<infinity> Hard to qualify, since it never worked on my machine until just recently.
<bob2> you're right, it's all about frozen bubble splash screens ;)
<lathiat> bob2: what the hell else do you want!?
<infinity> So, I'm comparing an old Celeron 550 to a new Pentium-M 2GHz, and yeah, it's faster now.  <smirk>
<bob2> hah
<pitti> infinity: out of interest, do our buildd chroots update theirselves regularly? (build-essential and so on)
<siretart> morning
<siretart> bob2: ping :)
<infinity> pitti : Yes.  Once daily.
<pitti> infinity: cool, thanks
<pitti> Moin mvo
<mvo> hey pitti 
<fabbione> daniels: do you remembe what do i need to export in the enviroment to use X -dbg libraries?
<Mithrandir> fabbione: gdb should do that automatically, IIRC?
<fabbione> Mithrandir: i am not sure...
<fabbione> oh yeah
<fabbione> it does
<fabbione> daniels: i need your help.. there is a regression in either xterm or libxt
<fabbione> basically xterm from hoary was using XTerm-color as default and if the file was not there, it was switching back to XTerm
<fabbione> (/etc/X11....)
<daniels> that'd be a regression in xterm then, I guess
<fabbione> now it uses as default class XTerm
<fabbione> it searches from XTerm-color
<fabbione> but in the wrong place...
<daniels> fabbione: look at xterm then
<fabbione> daniels: i am not that sure...
<fabbione> because xterm invokes XtOpenApplictions to read these files
<fabbione> i can't see any code that takes care of that directly in xterm
<fabbione> and that happens inside main
<DrSpin> can I bug you guys about something for a sec?? I wanted to ask some questions before I filed a bug report...
<daniels> it was probably a change to xterm to read XTerm-color resources first.  somehow I doubt libXt has a special case for xterm ...
<fabbione> daniels: it still reads XTerm-color first, but in the wrong place
<daniels> fabbione: define 'wrong place'
<fabbione> it searches first in ~ but not in /etc/X11...
<fabbione> as soon as it can't fine XTerm-color in ~ it tries XTerm, first in ~ and then in /etc...
<fabbione> the latter succeed
<DrSpin> when I logout of my X session whether in XFCE or GNOME, I have trailing applications that don't close -- specifically dbus-daemon-1 and gam_server -- can't seem to get anyone to help me troubleshoot this but I had the same problem on this box before a reformat and again before another reformat -- this is with a clean home DIR and clean config files for the ENTIRE OS
<jdub> DrSpin: they time out after a while
<DrSpin> jdub: so having 15 instances running doesn't hurt anything?? 
<jdub> if you have 15 users who have just logged out, no
<jdub> if you have 15 instances running for a single user that never time out, yes
<DrSpin> jdub: I have 2 users on this system -- I like to leave my box on for days at a time -- I'll leave town for the weekend and come back and still have dbus-daemon-1 laying around -- 
<DrSpin> not sure about gam_server -- only noticed a parallel recently
<daniels> fabbione: no idea, sorry
<DrSpin> jdub: if I should just ignore this, is there any documentation on how long they stick around?? I'm somewhat anal and if a user is logged out anything associated with that session *should* in my head at least, no longer exist -- 
<DrSpin> unless it's a service or system app -- but as a regular user...
<fabbione> daniels: ok.. we will figure it out
* mvo waves to ogra 
<ogra> morning
<jsgotangco> hi ogra
<\sh> remoins
<ogra> remoins ? hehe
<DrSpin> jdub: if I should just ignore this, is there any documentation on how long they(dbus-daemon-1 && gam_server) stick around??
<\sh> ogra: 7:00 localtime I was sitting here ,-)
<ogra> meh
<\sh> morning sabdfl 
<pitti> Hi sabdfl 
<sabdfl> morning all
<pitti> seb128: okay for you if I package g-v-m 1.3.6?
<Mithrandir> mjg59: do you have your amd64-x86emu-crack-vbetool somewhere?
<pitti> seb128: there is also 1.5.0, but I think we should rather stay with 1.3 in Breezy
<seb128> hey pitti
<seb128> pitti: sure, I was not going to touch it anyway, g-v-m is yours :)
<seb128> I've enough to do with my toys :)
<pitti> ok
<pitti> seb128: one question: what's preferable, calling nautilus-cd-burner, or "nautilus --no-desktop burn:"
<pitti> ?
<jdub> the second
<pitti> ok
<jdub> saves letting n-c-b doing it for you ;)
<pitti> the latter is the new g-v-m default
<infinity> doko : Dude, you're about 2 weeks behind the times.
<pitti> so I don't need to change it
<seb128> pitti: what jdub said :)
<seb128> grrr
<seb128> 80 bugs mail since monday
<daniels> seb128: ?!?
<daniels> seb128: why don't you have my bug mail
<seb128> I've enough with these ones, thanks :p
<doko> infinity: ?
<infinity> doko : libgl1-xorg is dead.
<infinity> doko : I'm uploading OOo2 again to fix that. :)
<doko> infinity: doesn't it build at all?
<doko> it's fixed for the m125 uploads, so if it builds, no other upload is needed
<infinity> doko : libgl1-xorg?... It builds right now, but not with the next X upload.  Have yo unot noticed all the xorg -> mesa changes I've been making i nthe last week? :)
<siretart> infinity: libgl1-xorg dead? then I hope #14017 will be fixed soon, else no direct rendering ;)
<doko> infinity: as I said, fixed for m125 ...
<infinity> doko : Kay, so it suggest libgl1-mesa now?
<doko> yes
<infinity> doko : Fix the package description for s/xlibmesa-gl/libgl1-mesa/ too.
* infinity grumbles about having downloaded 200+ MB of source and deletes his tree.
<daniels> siretart: it's i810-specific
<doko> infinity: fixed as well
<siretart> daniels: oh. I thought it was a general problem with libgl. ok
<\sh> guys..problems with seahorse-agent 
<\sh> hmmm...
<daniels> siretart: if DRI was broken in general, I wouldn't have uploaded the new mesa
<madduck> is the date and location for the next ubuntuconf already set?
<jdub> madduck: see the ubuntu-announce archives
<jdub> it was announced today
<madduck> weird. i am subscribed there...
<madduck> well, i guess i'll just have to wait...
<madduck> jdub: thanks anyway.
<pitti> Hi madduck 
<jdub> it'll be on the web archives
<madduck> pitti: how are you?
<pitti> fine, thanks; and you?
<pitti> packaging a new g-v-m, it's really fun this time :-)
<madduck> lol
<madduck> i am ok. struggling to make a 180 degrees turn in my life without making too many enemies
<madduck> "OCT30 -> Ubuntu Love Day (Interesting to Everyone)" -- i bet. :)
<\sh> madduck: divorced? ;)
<madduck> \sh: nah, quite the contrary. i *did* have a great confrontation with my g/f this morning at 4am when she rose up from deep sleep and thought that there was nothing more important than to discuss the future of our relationship.
<madduck> but you didn't want to hear that.
<mvo> anyone here with a ppc desktop that runs breezy? I would like to know if you see update-notifier consuming 100% cpu after a recent upgrade
<mvo> (just got a bugreport from a ppc user and I can't reproduce it here)
<\sh> madduck: hehe :) I know this all :) I made my 180 Degree turn last year...and I'm not recovered completly from it :)
<madduck> sounds reconfirming.
<pef> hello
<\sh> madduck: at least starting a single life agian from scratch is an adventure 
<madduck> i sometimes wish... 
<madduck> damn. flight to montreal comes in at 700 EUR.
<ogra> madduck, you can try to get sponsoring... see the attendees subpage on the wiki
<madduck> ogra: i am not active enough, not am i from the Americas.
<madduck> but i can try.
<pef> ogra: hi
<ogra> madduck, trying is cheap ;)
<ogra> haha, after i made the uzpgrade of about 150 packages, now update-notifier says there are upgrades available...
<ogra> mvo, your app is a bit late ;)
<mvo> ogra: are there still upgrades available now? or does the arrow point into the void?
<ogra> mvo, nope... it closed itself after the notification... 
<pitti> mvo: btw, this morning I got two arrows...
<pef> a motu available to check my package ? (1 vote missing) http://siretart.tauware.de/revu/details.py?upid=413 thanks !
<ogra> pitti, i had this yesterday... (if you mean the popup bubbles)
<mvo> pitti: yes, I got a bug about it, I think it's actually two notification windows that are overlapping, but I haven't invetigated it enough yet 
<{Seb}> i've been looking around
<{Seb}> and there is still no wv-dev package in breezy
<ogra> pitti,  * Starting Hardware abstraction layer:
<ogra> run-parts: /etc/dbus-1/event.d/20hal exited with return code 1
<ogra>  * Starting Power management daemon:                                     [ ok ] 
<ogra> invoke-rc.d: initscript dbus, action "restart" failed.
<ogra> ^^^^ recent upgrade
<{Seb}> beagle uses wv for searching MS Word files and without wv-dev
<pitti> ogra: did you stop it before?
<{Seb}> i have to build wv-dev from scratch
<{Seb}> i've put it into malone
<ogra> pitti, nope, the upgrade script...
<pitti> ogra: p-m's upgrade script is not supposed to restart hal...
<ogra> pitti, i havent cleaned the pre/postinst of PowerManager yet
<{Seb}> is that the correct thing to do?
<ogra> pitti, yes, but hal is not supposed to fail on dbus restarts i guess
<pitti> right
<pitti> ogra: I'll look into it
<pitti> ogra: hald is *very* hard to kill
<ogra> and i'll clean the postinst :)
<pitti> I already did some extra measures
<pitti> ok
<{Seb}> what is the difference between the bugzilla, launchpad and malone?
<pitti> ogra: $ sudo /etc/init.d/dbus restart -> WFM
<ogra> hangs here
<ogra> on  * Starting Hardware abstraction layer:
<ogra> ah, now the same error
<ogra> run-parts: /etc/dbus-1/event.d/20hal exited with return code 2
<pitti> ogra: please check if there is still an old process
<pitti> ogra: sudo killall hald 
<pitti> ogra: and do it again
<ogra> ah, yes, there still is an old process
* ogra kills 
<ogra> ok, now it starts cleanly....
<ogra> lets try restart
<ogra> yup
<pitti> ok, so sometimes hald doesn't want to die...
<ogra> might have been the old version
<pitti> I'll apply some more force in /etc/dbus-1/event.d/20hal
<ogra> i didnt upgrade for some days...
<pitti> ogra: did the stop part fail?
<ogra> it didnt say so...
<ogra> but it obviously failed, since there was a process left
<pitti> ok
<jsgotangco> hey hno73 
<hno73> jsgotangco: hey
<Mithrandir> does anybody understand what the guy in 9799 is actually trying to say?
<jsgotangco> it seems to be a problem in enigmail rather than a thunderbird issue
<Treenaks> Mithrandir: Yikes, that doesn't even _look_ like English
<Mithrandir> Treenaks: it looks like english, but falls flat on its face when parsed.
<Treenaks> Mithrandir: ok, true
<Mithrandir> ogra: can you verify that 10290 works for you?
<ogra> Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-24 12:03 CEST
<ogra> Failed to determine the netmask of ! : No such device
<ogra> hmm
<ogra> i have a lo
<seb128> \sh: Debian has a gajim 0.8 package using CDBS, why do you remake it to use debhelper?
<ogra> Mithrandir, but it doesnt crash apparently...
<Mithrandir> ogra: can you do an apt-get --reinstall install nmap and see if you still see the problem?
<ogra> Mithrandir, same
<ogra> Mithrandir, but  according to comment #1 its not supposed to work and it doesnt crash
<ogra> so i would see it solved
<Mithrandir> ogra: does nmap 127.0.0.1 work for you?
<Mithrandir> -oO 127.0.0.1 SIGSEGVs for me now.
<pitti> ogra: fixed hal, uploaded now
<ogra> pitti, can i poke you to have a look at the python-pysqlite2 inclusion report soon...? it gets a bit awkward to spam the buildlogs with gcompris the whole day... its the last package that holds up edubuntu-desktop.... and i think this report a no brainer
<pitti> ogra: yep, just finished with my other stuff, I do some reviews now
<ogra> yay, thanks a lot :)
<pitti> sjoerd: ping
<pitti> doko: why is bsh in multiverse ATM?
<doko> pitti: ENOCLUE, better ask elmo ...
<Mithrandir> pitti: it needs javacc to build, iit
<Mithrandir> iirc
<pitti> elmo: why is bsh in multiverse?
<pitti> Mithrandir: yes, but javacc is in universe
<Mithrandir> pitti: it might be hysterical raisins, then.  javacc used to be very non-free
<pitti> ok
<pitti> doko: btw, what did change in OOO recently that it needs a whole new bunch of build-deps?
<doko> pitti: using the packages, and not the sources included in the OOo2 source
<pitti> ah, ok
<doko> besides mdbtools, for which I'm writing a report now ...
<doko> (for opening Access databases)
<pitti> doko: can you please create a separate page for mdbtools?
<pitti> FWIW, I just released the lock on OOO2deps
<infinity> ogra : Is that one MainInclusionReport the only thing standing between us and gcompris building?  It's the only thing in main that still has  alibcairo1 dependency.
<doko> pitti: ok
<doko> pitti: done, ready for review ;-)
<pitti> thanks
<pitti> ogra: https://wiki.ubuntu.com/MainInclusionReportMoodle
<ogra> pitti: i havent come around to fix the wwwconfig-common stuff yet
<ogra> i'll fox the recommends too then, thanks
<ogra> (and i cant do anything about the sce. history, sorry :) )
<ogra> sec. even
<Mithrandir> yay
<sjoerd> pitti: pong
<ogra_ltsp> pitti, what do i have to do for mediawiki ? moin is no option for edubuntu
<fabbione> ogra_ltsp: what's the installer option to get ltsp install
<fabbione> ?
<ogra_ltsp> fabbione, there is none
<ogra_ltsp> fabbione, install ltsp-server-standalone and run sudo ltsp-build-client....
<ogra_ltsp> fabbione, or even test edubuntu
<infinity> ogra_ltsp : What's wrong with moin?
<ogra_ltsp> fabbione, http://www.edubuntu.org/EdubuntuTesting
<fabbione> ogra_ltsp: ok.. i need to test the normal CD first
<ogra_ltsp> infinity, we committed to mediawiki, all our users (teachers denied moin for their schools...) wikipedia needs mediawiki
<ogra_ltsp> EWRONGBRACKETS
<ogra_ltsp> infinity, the most important usecase is wikipedia... i doubt they'll use it for something else, since we promised moodle
<infinity> Fair enough.
<ogra_ltsp> and we aim at schools with no online access, so they need to be able to pop in a wikipedia dvd and run it on the server
<ogra_ltsp> thats why it needs to be in the default install
<ogra_ltsp> it == mediawiki
<ogra_ltsp> pitti, is there really no way ? 
<pitti> ogra_ltsp: I just wrote down my feeling; if we have to support it, so be it
<pitti> ogra_ltsp: I just didn't know why moin is no option
<pitti> sjoerd: Hi!
<pitti> sjoerd: recently I uploaded a whole lot of new utopia crack
<ogra_ltsp> pitti, i have the same feeling, but we commited to mediawiki at the summit... 
<pitti> sjoerd: also, do you think the stuff should be uploaded to main soon? IMHO it should
<pitti> ogra_ltsp: if I have sabdf1 and you against me, then I have to bow :-)
<ogra_ltsp> pitti, so lets hear sabdfl
<sjoerd> pitti: to unstable you mean ?
<pitti> sjoerd: erm, yes
<pitti> sjoerd: the stuff just sits in experimental and nobody uses it
<pitti> sjoerd: at the same time it fixes so much stuff...
<sjoerd> pitti: i'm planning to update all the stuff in experimental this week(end)
<sjoerd> pitti: probably for debian it's best to switch when also switching to G2.12 in unstable.. that saves a lot of unneccessary G2.10 patching..
<pitti> sjoerd: ok, right
<pitti> sjoerd: btw, for Breezy I packaged g-v-m 1.3.6 instead of 1.5.0 to stay on the safe side
<pitti> sjoerd: but 1.5.0 is certainly more appropriate for Debian
<sjoerd> yup
<pitti> sjoerd: 1.3.6 was really fun - upstream accepted all of our fixes :-)
* pitti yays Jeffrey
<sjoerd> is breezy staying with the current dbus release or going to the new one that was just released ?
<sjoerd> pitti: that rocks ;)
<pitti> sjoerd: we really stay with 0.35 now, no more exceptions
<sjoerd> pitti: i'm also gonna switch to lsb init scripts, so that should make the debian <-> ubuntu diff smaller again :)
<pitti> sjoerd: cool
<pitti> sjoerd: Md uses it for udev, so it's already important anyway
<sjoerd> pitti: btw still haven't heard from the cryptsetup maintainer :(
* pitti neither
<sjoerd> pitti: bah :(
<daniels> gar!!!
<daniels> i think the discover1 merge dropped patches, again
<infinity> elmo : Can I get mesa's new binary package shoved through NEW?
<Diziet> Joy, now I get to debug some daft thing in apt.
<Diziet> I have a typescript of it downloading some .deb which it then complains doesn't exist.  (And then it goes and tries to use the fd -1 that it got out of open anyway, but that's a different problem.)
<seb128> elmo: please sync gtk+2.0 from debian incoming
<mvo> Diziet: can you send/show that script to me?
<mvo> Diziet: sounds like a bug in the new progress-reporting code
<Diziet> mvo: I've put it in chinstrap:~iwj/d/typescript
<Diziet> The progress reporting code can make it fail to find the file ?
<mvo> Diziet: no, that was about the fd that was -1
<Diziet> mvo: Oh, right.  That bit is easy to fix.
<Diziet> It's the way the file apparently vanishes that's strange.
<mvo> Diziet: is the problem reproducable?
<Diziet> I haven't tried yet.  I didn't want to perturb it.
<Diziet> The way it carries on blithely after all of those errors is rather worrying.
* ogra_ltsp hugs pitti for python-pysqlite2 approval :)
<pitti> no worries :-)
<ogra_ltsp> :)
<mdke> who maintains ddclient?
<mdke> ah its universe
<mvo> Diziet: a strange error! did it happen on a hoary->breezy upgrade
<Diziet> mvo: Yes.  I installed hoary from the i386 CD, edited the sources.list, and ran apt-get update; apt-get dist-upgrade.
<Diziet> AFAICT this code in apt-pkg/contrib/fileutl.{h,cc} is BAD.  There is no way for (eg) FileFd::Size to actually tell its caller that it didn't work.
<Diziet> The only correct way to implement that interface has it bomb out the entire program or throw a C++ exception.  Does apt use exceptions ?
<mvo> Diziet: no
<jtan325> hi i am having a slight problem when building my own debian package for a small program 
<Diziet> Alternatively ::Tell and ::Size could be changed to have a reference argument for returning the answer, changing all callers.
<jtan325> i've gotten it to build with debuild, 
<jtan325> i am just getting an annoying error with lintian
<jtan325> complaining about manpage-in-wrong-directory
<jtan325> i've read the man page for dh_installman
<jtan325> and have also googled
<jtan325> and my first impression was something was wrong with the man page i was provide
<jtan325> *providing
<jtan325> so i checked that, but i'm pretty sure the section number is right
<jtan325> so i tried, just to try, not even including "dh_installman" as one of the build rules
<jtan325> but i still get the same error
<Diziet> apt--
<Diziet> This program would appear to have a fundamentally incorrect algorithm.
<mvo> Diziet: what bit exactly
<Diziet> The bit where it replaces libc6 with a version whose dependencies aren't met by the current system and then refuses to start because libc6-dev has unmet dependencies.
<Diziet> (in between it had bombed out due to another error)
<Diziet> (err, the first libc6 in that sentence should read libc6-dev)
<doko> daniels: after reboot the mouse wheel stopped working, current breezy amd64, ZAxisMapping however is defined
<fabbione> mdz: daily install looks good here
<daniels> doko: i believe this is a kernel bug
<fabbione> doko: what if you unload/reload mousedev ?
<fabbione> doko: do you still have /dev/input/mice and /dev/psaux?
<fabbione> if so -> X
<fabbione> no recent kernel upgrades did touch the mouse
<daniels> fabbione: nothing in the mouse code has changed
<daniels> fabbione: (in X)
<daniels> or input handling
<fabbione> daniels: hotplug...
<daniels> doko: if you can narrow it down to which version of xserver-xorg broke it (or which version of the kerenl, even better), that would rock
<fabbione> i think we can blame hotplug or udev :)
<daniels> fabbione: hotplug is suppressing scroll wheel events but nothing else?
<fabbione> daniels: the effect i see here is that mousedev is loaded too early..
<daniels> ah, ok
<fabbione> so i don't get anymouse at boot
<daniels> keybuk's fault.  score.
<fabbione> rmmod modprobe fixes it
<HiddenWolf> fabbione, you might want to repeat that stuff for doko
<HiddenWolf> ^^
<doko> fabbione: yes, both devices are created
<fabbione> doko: ok thanks
<Saba_Z> hey all
<fabbione> doko: does the mouse start to work again if you rmmod mousedev and modprobe it again?
<fabbione> hi Saba_Z :)
<doko> fabbione: while X is running?
* fabbione takes 2 minutes break
<fabbione> doko: nope.. you can't inside X
<fabbione> you need to logout, kill gdm, rmmod/modprobe and restart gdm
<doko> I stopped X, rmmod/modprobe, started X again, same behaviour
<fabbione> the mouse needs to be fully reinitialized
<fabbione> ok
<fabbione> blame X :)
<fabbione> or check if there are data coming from the mouse moving only the scrollwheel
<doko> daniels: ^^^
<doko> xev?
* fabbione takes 2 minutes break for real
<daniels> doko: xev output would be nice, too
<doko> no, nothing from the wheel ...
<daniels> doko: stop X, cat /dev/input/mice, and generate scroll wheel events
<doko> wait ...
<Saba_Z> fabbione: i am trying to complete / test my deb package
<fabbione> Saba_Z: cool !
<fabbione> i am looking forward to test it
<doko> fabbione, daniels: no events on the console without X
<daniels> fabbione: YOU WIN! :)
<fabbione> doko: what kernel are you running?
<fabbione> daniels: don't be so sure...
<doko> 2.6.12-7-amd64-k8
<fabbione> becaue not all mouse events are mapped directly by the kernel
<daniels> well, something that is not X wins.
<fabbione> doko: do you have an older kernel in the 2.6.12 series around?
<doko> no, 2.6.10 only
<fabbione> doko: well you have an amd64 or there should be the morgue around...
<fabbione> if you can identify when the breakage did happen it would be slightly more useful
<Saba_Z> fabbione: is this going to be uploaded to breezy if i mail it now?
<fabbione> or look at the mouse source code/Docs in the kernel
<daniels> fabbione: the morgue has been broken for months
<fabbione> some of them have options that might need to be turned on
<fabbione> Saba_Z: i will need to check with mdz about that..
<fabbione> Saba_Z: in theory we can upload it to universe, but i am not sure it can make main
<fabbione> not at this point in time 
<fabbione> Saba_Z: but universe would still be a very good result
<fabbione> and it will speed up it's way to main for breezy+1
<Saba_Z> fabbione: i think more test is needed if you want to add it to main
<fabbione> ok.. than complete your deb and we will push it to universe
<fabbione> little careful steps are the best towards main
<doko> fabbione: hmm, can't find deb's on morgue. aficr ekmo did stop syncing debs to morgue due to space constraints
<mvo> Saba_Z: what package is that?
<Saba_Z> ok i will send you the package in 1 hour
<fabbione> doko: well ask elmo to grab one for you when he is around...
<fabbione> Saba_Z: no rush.. i am going offline now till tomorrow morning
<Saba_Z> mvo: it is smallbusiness server
<fabbione> mvo: Google SOC
<_SWAT_> I've had this problem a few times know. I think it happens when my PC is on for a week or so. Then suddenly, when I hold a "k"button down, it's only printed once (instead of lots of k's). Anyone any idea which process is responsible for this?
<fabbione> daniels: you win!
* mjg59 is, for the first time in ages, actually in the lab
<daniels> fabbione: hmm?
<doko> deb http://people.ubuntu.com/~doko/OOo2/ ./
<doko> deb http://people.ubuntu.com/~doko/OOo2-powerpc/ ./
<doko> ^^^ pitti, daniels, seb128: please could you have a look at these packages? i.e. the i386 build does have the cairo bits enabled. pitti, I currently don't have a powerpc around
<daniels> doko: ... what should I be looking at?
<doko> load a presentation with Impress, and watch it in full screen mode. That's the module that makes use of cairo
<daniels> do you have a presentation handy?
<doko> martink: do you still have the test presentations at hand?
<daniels> and, uhh ... as I said the other day, this is a really bad idea
<daniels> dri drivers just aren't stable enough
* fabbione heads offline
<pitti> doko: will do, but first I need to upgrade my laptop
<doko> pitti: thanks
<doko> daniels: yes, will be disabled in the final one
<doko> but it's running stable for me
<daniels> doko: uhm, ok.
<martink> doko, there was really nothing special about them, but last time (for the amd64 problems) I used these urls: http://marketing.openoffice.org/ooocon2004/ooocon2004template.sxi and http://www.gnome.org/~michael/ukuug-2005-ooo/ooo.odp
<mvo> anyone here running breezy with scim input method?
<mdke> is Kamion on holiday?
<crispin> yes, until the 30th I think
<mdke> ok thanks
<\sh> grmpf...how can I add a source package in malone?
<\sh> source package name?
<ogra_> elmo, whats the status for the blackdown packages ? 
<mvo> mjg59: the usplash in 2.6.12-7 is not yet supposed to do anything more than to display a ubuntu-screen+logo, right?
<ogra_> oh... that reminds me
<ogra_> mjg59, the picture is broken since -7
<ogra_> (for me on amd64 with widescreen display)
<Mitario> if I want to propose an new UI layout for gksu(do) would I have to submit the patch to Ubuntu, or to the upstream maintainers?
<mvo> Mitario: upstream is kov (gustavo) from debian and he's very friendly and reponsive
<Mitario> mvo, allright thanks :)
<mvo> Mitario: there are various enhancement bugs in the BTS already, you may want to check them out first (with some really nice ideas)
<mvo> Mitario: your welcome :)
<Mitario> ubuntu bts?
<ogra_> bugzilla.ubuntu.com
<bddebian> Howdy
<mjg59> mvo: Correct
<mjg59> ogra_: Uh. Odd.
<mjg59> ogra_: I can't /think/ of anything that's changed. In what way is it broken?
<Mitario> ogra, right, thanks
<Mitario> pff have two meetings this evening, hope I'll be on time for MOTU
<ogra_> mjg59, it still works but the image is mangled.... its rather black with blue stripes
<mjg59> ogra_: Hmm. Have you changed screen expansion options at all, by any chance?
<ogra_> mjg59, but i can still recognize the rectangle thats thought for scrolling text
<ogra_> mjg59, nope
<ogra_> mjg59, only upgraded to the -7 kernel
<ogra_> i can try to take a picture for you
<mjg59> ogra_: That's... deeply odd.
<mjg59> There were no changes to the vga16 code
<ogra_> mjg59, i'll take a digi pic as soon as i can afford to reboot
<rburton> i take it too late to push dbus 0.36 into breezy?
<mjg59> ogra_: Thanks
<ogra_> rburton, far to late
<rburton> ogra_: how about a 10 line patch for a crasher?
<ogra_> rburton, talk to mdz about it if he's around... i havent seen any crashers yet...
<elmo> doko: half these zope packages are still in incoming
<daniels> ogra_: not necessarily
<elmo> doko: unless it's urgent, I'm going to leave them till they're in the archive proper
<daniels> rburton: anything compelling over .35.1?  i just skimmed j5's post tbh
<rburton> http://cvs.freedesktop.org/dbus/dbus/dbus/dbus-errors.c?r1=1.27&r2=1.28 just hit me
<rburton> dbus frees then uses a string if there is an error sent over the bus
<elmo> doko: (and if it is urgent, I'm going to need a list of sync what from where, not just "all these, and please sort out the details yourself kthxbye")
<rburton> daniels: and the decent resursive type work would be useful
<mvo> ping ogra_
<elmo> seb128: done
<ogra_> mvo, pong
<daniels> rburton: ok, I'll try to ram it in
<rburton> sweet
<Diziet> Strange splash screen> I get that too.
<mjg59> Diziet: Hrmph.
<doko> elmo: well, it would be nice, if I could on them with the SoC student. only the -cps dependencies (the third mail) should be in incoming, all other in experimental. 
<mjg59> Right, I'll look into that later on
<doko> elmo: sorry, the lists are reasonable complete. Do you need them in another format?
<mjg59> Diziet: Oh, hang on. Is this on your laptop?
<elmo> > zope-atrbw_1.1-1_i386.changes
<elmo> ^-- that's in incoming for example
<elmo> doko: dude, it's very simple, I need a list of pkg_version and from what repo
<elmo> I'm not going to run around working what is where
<elmo> or you can wait till post cron.daily
<doko> ok, so <pkg> <version> <archive> ?
<elmo> sure
<doko> fine
<Mitario> mvo, do you know if gustavo is available on irc somewhere
<mvo> Mitario: kov in #debian-devel
<pitti> mvo: http://people.ubuntu.com/~pitti/shots/u-m.png
<Mitario> allright
<mvo> daniels: I got a conffile question for 'xinitrc' on hoary(fresh install)->breezy upgrade, should I report this?
<Treenaks> pitti: I see that too
<Mitario> pitti, ah, have the same thing here :)
<daniels> mvo: nah, known issue
<Treenaks> pitti: but I have a second arrow in there too :)
<Mitario> it's a bit freakier here though
<daniels> mvo: thakns though :)
<Mitario> Treenaks, me too
<pitti> Treenaks: I saw that this morning
<mvo> daniels: oki, thanks
<Mitario> mvo, btw, shouldn't you add another text option to start UM?
<Mitario> like 'Don't show this message again | List Updates' or st
<mvo> pitti: thanks, I have seen it too. can you reproduce it?
<pitti> mvo: logout/in?
<mvo> Mitario: hm, good point
<pitti> mvo: yes, relogin reproduces it
<pitti> mvo: I can't get rid of the notification by clicking on it; odd
<pitti> mvo: this works with other notifications...
<pitti> mvo: merely restarting it produces a correct result
* Mitario proposes a Close text/button :)
<mvo> pitti: thanks, I see it here as well. I'll do some debugging now
<pitti> mvo: sounds like a race condition between dbus, n-d, and u-n start...
<mvo> pitti: sounds like fun ...
<\sh> doko: wth is pype?
<mpt> mvo: "Click on the update item" ... I don't see an "update item" in that screenshot anywhere
<doko> \sh: apt-cache show pype
<\sh> doko: x-app or console?
<ogra_> mjg59, http://www.grawert.net/24-08-05_1640.jpg, sorry i have only my mobile to take photos currently
<doko> \sh: line editor ;-P
<\sh> doko: ha..I hoped it was an alternative to Eric/QT on Gnome
<doko> \sh: apt-get install pype
<\sh> wuaha
<mjg59> ogra_: Ok, my guess is that you may have somehow ended up with the wrong framebuffer
<mjg59> Either that, or vga16 has suddenly got *very* screwed
<\sh> gnome popups appear...and my desktop is jumping from 4 to 2 and 3 to 1 or the other way around
<shaya> mjg59: the hdaps seems to be coming along
<ogra_> mjg59, it works as before, only the image is broken
<mvo> mpt: the arrow is supposed to give the hint. So I should add a second button text "show-updates"?
<mjg59> ogra_: Yeah. Which makes me think that it's the wrong framebuffer driver.
<mpt> mvo: If you want people to click something to open a window listing the updates, why not just open a window listing the updates, without people having to click anything? (disclaimer: that's what OS X does)
<ogra_> ogra@honk:~ $ lsmod|grep vga
<ogra_> vga16fb                12864  1
<ogra_> cfbcopyarea             4352  2 vesafb,vga16fb
<ogra_> vgastate                9344  1 vga16fb
<ogra_> cfbimgblt               3264  2 vesafb,vga16fb
<ogra_> cfbfillrect             4864  2 vesafb,vga16fb
<ogra_> softcursor              2880  2 vesafb,vga16fb
<ogra_> mjg59, ^^^
<\sh> seb128: help ,-)
<ogra_> looks ok to me
<mpt> mvo: The balloon is pretty and everything, but it seems like it's wasting people's time a bit (not to mention being harder to implement than just opening the window)
<mjg59> ogra_: Can you lsmod | grep vesafb ?
<mvo> mpt: it feels wrong to just open a big window without asking politly
<ogra_> ogra@honk:~ $ lsmod|grep vesafb
<ogra_> vesafb                  9252  0
<ogra_> cfbcopyarea             4352  2 vesafb,vga16fb
<ogra_> cfbimgblt               3264  2 vesafb,vga16fb
<ogra_> cfbfillrect             4864  2 vesafb,vga16fb
<ogra_> softcursor              2880  2 vesafb,vga16fb
<ogra_> mjg59, voila
<mvo> mpt: (to me at least)
<ogra_> mjg59, should they both be loaded ? 
<dredg> mvo: what about providing a link in the balloon to open the window?
<mvo> dredg: yes, that sounds better to me
<mpt> mvo: As long as it doesn't grab focus, IMO that would be better than making people do an unnecessary click
<dredg> actually, a friend blogged this earlier today
<dredg> http://lbedford.org/diary/2005/08/ubuntu-breezy-colony-3.html
<HiddenWolf> dredg, nice blog, that
<mvo> mpt: the biggest blocker for that right now is probably that update-manager needs to run with gksudo
<mvo> dredg: thanks for the link
<mjg59> ogra_: Hmm. That's probably ok.
<mjg59> ogra_: Right, I'll look into it
<mpt> mvo: Well, why are you showing updates at all to someone who can't install them?
<mpt> oh, I see
<doko> \sh: you may want to have a look at spe
<mpt> they can install, they just need to enter the password
<mvo> mpt: I would like to change that, but there is no easy way to figure if a user is allowed to run sudo applications. there is a spec about it
<mpt> mvo: You don't need that
<mvo> mpt: yes, they can install, they need the password
<mvo> mpt: it would be nice to seperate that so that you don't need the password to show the updates, but that's not done yet
<mpt> mvo: You just need to ask for the password when they click the "Install Updates" button, instead of when they open the window
<Mitario> mvo, wouldn't there be a way to parse sudoers?
<pitti> doko: downloading ooo2 now
<mvo> Mitario: no, it's 600 for security reasons. we could cheat around the issue by checking for the admin group
<rburton> daniels: libgl1-mesa-dev_6.3.2-0ubuntu2_i386.deb:
<rburton>  trying to overwrite `/usr/include/GL/gl.h', which is also in package mesa-common-dev
<Mitario> mpt, problem with that, you'll also need sudo access to configure software sources and update options, which are available from update-manager
<daniels> rburton: wow.  i, er, suck.
<rburton> :)
<mvo> but that group was introducted only in hoary
<Mitario> mpt, anyways, why would you want to check for updates if you can't install them :)
<Mitario> mvo, ah, right
<mvo> Mitario: a google summer of code student was working on that (a way to tell what users have root access)
<daniels> rburton: new mesa thrown at the archive
<Mitario> mvo, ah that's cool
<pitti> mvo: a setuid wrapper would probably be the most reliable way
<mpt> Mitario: Exactly the same applies to putting up the balloon.
<mvo> Mitario: I was considering the "admin" group cheat, but I'm not sure if that works for everyone (i.e. people upgrading from warty to hoary to breezy)
<mvo> pitti: do you know if there is work underway on this applicaton?
<Mitario> mvo, people in the admin group don't nessesarily need to be sudoers
<Mitario> mpt, hmm, there are 2 sides on that, say an employee gets that message, he could warn his sysadmin, on the other hand, you're right that the balloon shouldn't popup to a user without admin rights, but we need a method for that then :)
<Mitario> anyhow, it is a bug yes
* Mitario wonders how windows XP/vista do it
<Mitario> or mac os x..
<\sh> Mitario: updates? every user get the message that there r updates..(xp like ,-))
<Mitario> ok, well /me thinks that's the best sollution
* mpt tests os x
<Mitario> say my mom gets that message, she can warn my dad that he should install the updates :)
<mpt> as a non-admin I can run Software Update
<pitti> mvo: no idea
* Mitario wonders why
<Mitario> true, it might be interesting for a user to see the updates, probably not though
<mpt> Presumably I'd get asked for an admin name and password when clicking "Install" (I can't test that because there are no updates available)
<Mitario> right
<Mitario> but since we don't have an adminstrator account in ubuntu
<mpt> There isn't an administrator account in OS X either
<Mitario> oh
<ogra_> Mitario, os X uses sudo ;)
<mpt> I said "an", not "the" :-)
<Mitario> ogra_ ah right :)
<mpt> Huh, that's interesting
<mpt> as a non-admin I can set my own Software Update prefs
<Mitario> anyways I think popping up at least the little red icon should be on by default
<pitti> doko: if you don't count 2 minutes startup time and slow response as a bug, writer works here (shallowly tested)
<pitti> doko: calc starts, too; anything I should test in particular?
<Mitario> mvo, oh right, IMO you should change that 'never show again' message to 'hide ballon' or something
<mpt> Mitario: Unfortunately a little red circle doesn't mean anything
<Mitario> mpt: true, so just display the balloon for everyone :)
<mvo> Mitario: it's meant as "never show again", if it is set, there will never be a ballon again
<mpt> This whole balloon thing is ... unfortunate
<Mitario> mvo, ok don't you think that's a little dangerous option to display on a balloon like this?
<mpt> Imagine if roadsigns were designed that way
<Mitario> i think the balloon thing rocks.. :)
<mjg59> mvo: The balloon doesn't align properly if you have a vertical panel
<Mitario> mvo, maybe just put an option 'Hide for now' or 'Warn me later' and put a 'never show balloons' option in g-s-p
<doko> pitti: no, how many RAM do you have?
<pitti> doko: 256 MB, G4 800 MHz
<doko> ok ...
<HiddenWolf> doko s/many/much
<mvo> mjg59: I suspected it, it's a bug in notification-daemon
<pitti> doko: the previous versions weren't faster, if you mean that
<mjg59> mvo: Ok. Should I file a bug?
<doko> pitti: but I assume it waits on something network related.
<fabbione> doko: 14092 -> Component linux <- Assignto: ben.collins@ubuntu.com . kthxbye
<doko> pitti: does the machine show some load?
<pitti> doko: no, just heavy I/O load
<pitti> doko: yep, mostly I/O, also much cpu
<mvo> mjg59: yes, please assign it to notification-daemon and to me and a screenshot would be cool as well.
<doko> swapping?
<pitti> doko: it's just normally loading all the stuff
<fabbione> doko: did you do the test i told you? or do we need to go trough them one by one?
<doko> pitti: I can only test with >= 1GB :-)
<pitti> doko: that slowliness was just bitching, never mind :-)
<mjg59> doko: You can boot with mem=256M
<doko> fabbione: what's up? we went throught the procedure
<doko> mjg59: psst ...
<fabbione> doko: i did ask you to try older kernels and to see the mouse options in the kernel doc, because the wheel works fine here
<doko> fabbione: I don't have an older kernel yet. It's on my list
<fabbione> doko: ok.
<fabbione> doko: anyway i am not the owner of kernel stuff anymore. Just assign the bugs to linux and the form will be automagically filled for you :)
<mvo> Mitario: ok, agreed
<mvo> mpt: so what can we do about the issue for breezy? 
<doko> fabbione: I just wanted to give you a chance bitching around :-) 
* fabbione larts doko with a userland bat
<mpt> mvo: Is the amisudoerornot.com code going to show up in time?
<ogra_> isnt that already in ?
<ogra_> its .org btw ;)
<mvo> mpt: probably not, we are in pretty deep freeze already, seb128 knows more. assuming it would, what would you suggest to do? hiding the icon complettly for non-sudoers?
<ogra_> as i understood him, its already in, but all sudoers .desktop files need a add on...
<ogra_> i'd really love to see it in edubuntu... 
<ogra_> and thus ubuntu first :)
<mpt> mvo: Ideally, (1) don't use an icon at all (if you need to point a balloon at an icon, the icon was the wrong design in the first place)
<lukas_> daniels, may I ping you about http://bugzilla.ubuntu.com/show_bug.cgi?id=12716 ? We two have this problem, and don't know how to help fixing that ...
<mpt> mvo: (2) open the Update Manager when updates are available, and not otherwise
<mvo> ogra_: it's in, but it just checks for the admin group right now
<ogra_> oh... i thought it checks for some magical line in the .desktop file too
<mpt> mvo: and (3) default to it opening daily/weekly for sudoers and not at all for others (though they can turn it on if they want)
<mpt> s/opening/checking/
<ogra_> mpt, opening once a week like hitting you right in the face without asking ? i'd prefer a icon...
<mpt> ogra_: oh, and (4) make it not take focus when it opens :-)
<ogra_> but still it hangs around on my desktop without being asked to do so... even if it doesnt takje focus, your windowlist entry will flash...
<mpt> Having a balloon pop up in front of my work, with a hyperlink (!) I might click by mistake to turn off update checking permanently, would be more annoying to me than a window opening in the background
<mvo> mpt: I'm still not happy with just opening a window that I have not asked for (even if it does not steal focus), I'll try to get at least (3) implemented (if technically possible) for breezy
<mvo> mpt: this is a misunderstanding, the icon will stay, just the ballon will not shown again 
<mvo> mpt: but I see that the wording of the the baloon is "unfortunate", it will change
<mpt> mvo: The problem you're trying to solve is that people don't install updates. Therefore the solution needs to be one where the easiest option is to click a button that installs the updates, not one where the easiest option is to click something that makes the notification go away.
* Diziet reads the diff between Debian's and Ubuntu's gs-esp.  And I've found at least one undefined-behaviour bugfix.
<mvo> mpt: I agree, the link will be changed to show the updates by default now 
<mvo> mpt: don't get me wrong, I'm grateful for your review
<Mitario> hmm, kov aggreed, going to send a patch soon :)
<mvo> Mitario: cool!
<Mitario> will go for breezy+1 of course, but ooh wel
<Mitario> at least it's in debian then :)
<mpt> mvo: Does that mean I'm still allowed to comment on the Language Selector? :-)
* mvo runs from mpt
<mvo> mpt: sure :)
<Mitario> haha :)
<ogra_> lol
<mpt> I haven't actually seen it yet, but I hear tell it refers to "inputs"
* mpt Really Must install Breezy tonight
<mvo> mpt: tomorrow is interface freeze ...
<mvo> mpt: I will do you a screenshot, give me a second
<doko> Mithrandir: did you notice, that on amd64 in the OOo2 menus the background is drawn in the wrong color when the menu is selected?
<daniels> lukas_: no huge ideas over at my side, no
<ryanthiessen> why not "tools" instead of "input" ?
<lukas_> hm, thanks anyway, daniels. I'll surely report if the state changes.
<mvo> mpt: http://people.ubuntu.com/~mvo/language-selector.png
<lukas_> and eagerly watching each new xorg-changelog-entry :)
<thoreauputic> can someone please kick spunk in #ubuntu?
<bddebian> spunk? :-)
<thoreauputic> his nick
<thoreauputic> :)
<mpt> mvo: "writting" should be "writing"
<mpt> mvo: When does this appear, exactly?
<ogra_> mjg59, the only thing i can get working from g-p-m's context menu is hibernate, did you implement shutdown/reboot as well ? should it work ? 
<Diziet> +    /* Some architectures have special alignment requirements for jmpbuf. */
<Diziet> Does anyone know if that's true for ppc ?
<mvo> mpt: thanks, you click on System/Administration/Language Selector
<Mithrandir> doko: no, I don't use ooo :-)
<mjg59> ogra_: Shutdown and reboot need to be implemented in pmi
<mjg59> Once they are, it should work
<ogra_> mjg59, oh, i thought it already does that
<ogra_> ok
<mjg59> ogra_: pmi just needs shutdown/reboot things. Though TBH, I think we probably don't want those on the GPM menu
<ogra_> nope
<ogra_> mjg59, g-p-m has a --no-actions option, we should start it with that... yu can manually hibernate through the logout dialog, thats enough
<mjg59> Ok
<mjg59> At the moment it's handy for testing
<ogra_> yup
<elmo> mjg59: we don't support .commands files, I'm afraid
<mpt> mvo: (1) I suggest changing the intro text to "Choose which languages should be available to people using this system."
<mpt> mvo: (2) Rename "Translation" to "Translations" and "Inputs" to "Spelling"
<mjg59> elmo: You don't? Ah, right.
<mjg59> An upload hung part-way though
<mvo> mpt: thanks, (1) fixed
<mjg59> s/though/through/
<mpt> mvo: (3) Move the explanatory text underneath the list, and have it say: "Translations include menus, dialogs, and help. Spelling includes dictionaries and grammar checkers. Some translations may not be available for some languages."
<mvo> mpt: (2) also contains stuff like input methods for chinese etc, so I guess that may be a bit misleading
<mpt> mvo: (2) oh, excellent. In that case it can be "Writing Aids".
* ogra_ hugs elmo very tight
<ogra_> elmo, ta :-D
<mvo> mpt: (2) "Input" -> "Writing Aids" in the caption?
<janimo> elmo, please sync wmaker from sid, thanks
<mpt> so (3) "... Writing Aids include spelling dictionaries, grammar checkers, and IMEs."
<elmo> mjg59: for now, just invoke me (or kamion/mdz as a fallback)
<ogra_> janimo, who approved that sync ? 
<janimo> it's universe
<ogra_> janimo, UVF still applies 
<janimo> mdz, said in principle universe is still ok, at least a week ago he said that
<siretart> janimo: you still need approval from ogra or an delegate ;)
<janimo> if particular packages are asked for, not en-masse
<ogra_> janimo, i'm fine with approiving it as long as it fixes a ftbfs or something
<janimo> ok, ogra then please approve :)
<ogra_> janimo, rationaly please
<xhaker> can someone help me about a gnome applet? i'm developing it and i can't manage to make it work in transparent panels
<ogra_> rationale even
<janimo> no ftbfs just a bugreport from a friend who uses 0.91
<janimo> and upstream 0.92 fixes it
<janimo> something to do with windows not maximized after reloggin into session
<siretart> janimo: which bugreport
<janimo> sorry for being vague
<janimo> unoffcial bugreport he just told me on IM  half an hour ago :)
<janimo> I'll ask him to file one if it's necessary
<janimo> oh well
<ogra_> janimo, crasher ? 
<janimo> no, annoyer
<ogra_> janimo, please do so
<mpt> mvo: Does setting a language as "System default" automatically install it if it wasn't installed?
<mvo> mpt: wording is fixed for (3). moving it down is easy enough, but it moves the text very close to the "System default" combo box. do you think that's ok? I will do another screenshot with the new version
<ogra_> janimo, i told you that you need approval already
<elmo> ogra: if you want me to apply UVF to universe pls let me know who can approve them
<mvo> mpt: no, it will only list already installed languages
<ogra_> janimo, ... about two weeks ago iirc
<ogra_> elmo, didnt mdz and Kamion tell you ? 
<xhaker> by the way.. GAIM is crashing when connecting to the googleTalk jabber server
<janimo> ogra_, I tought if a motu asks for a sync it means he'll take care of that package
<ogra_> elmo, they told me... with the addition that it can be handled more loosely but still needs approval
<janimo> that's implicit
<janimo> I am not just going around asking random syncs
<ogra_> janimo, its only a additional checkup ... 
<janimo> it's my time too
<elmo> ogra: no, no one's told me
<mpt> mvo: the gap between the explanation and the menu should be greater than that between the explanation and the listbox ... I'm sure the HIG has guidelines for that
<ogra_> elmo, thats odd, i'll talk to mdz then
<xhaker> i noticed the update for Gaim, but it still crashes.
<mpt> mvo: Would it be accurate to rename the menu to "Initial language for new accounts:"? What else does the system default do?
<elmo> ogra: ... ?  I just need to know who can approve them for universe
<ogra_> elmo, Kamion was very strict in his words
<ogra_> elmo, me and dholbach, \sh, siretart and ajmitch are delegates
<mvo> mpt: it's the default language in the login screen for example
<elmo> ogra: ok
<mpt> The login screen has a language?
<mpt> oh, right
<ogra_> elmo, but its still odd that nobody told you... 
<siretart> elmo: do you prefer sync requests by irc or mail?
<mvo> mpt: http://people.ubuntu.com/~mvo/l-s-2.png
<mjg59> elmo: Oh, I've got a workaround for the nx6125
<elmo> siretart: irc is fine, but I may well miss it - always fallback to mail, if I don't reply reasonably promptly
<mjg59> elmo: If it's booted with noapic nolapic as kernel options, it works much better
<elmo> mjg59: neato
<mpt> mvo: Excellent
<mpt> mvo: "Translations", not "Translation"
<elmo> mjg59: does yours do DMA on the hard drive?
<mvo> mpt: ups, fixed, thanks
<elmo> mjg59: and is laptop testing checking for that?
<mpt> mvo: The explanation would probably work better all as one paragraph
<mpt> mvo: Try "Default language:" instead of "System default:"
<mjg59> elmo: Does in Breezy, doesn't in Hoary
<mjg59> The driver doesn't support the hardware in Hoary
<mpt> mvo: And then have an explanation under that, aligned with the left edge of the menu, saying "Used for new accounts and the login screen."
<elmo> ok
<mvo> mpt: thanks, one paragraph and "Default language" now
<mpt> mvo: Finally, reduce the width of the window by about 30~40 percent ... It'll make lining up the checkboxes easier, and the menu look healthier
<mdz> fabbione: did you have a chance to test the live cds?  those are the ones which were bad before
<mdz> ogra_: what I said was that it was a MOTU decision and that you could apply UVF or not according to your needs
<mpt> mvo: I have an apology to make ... I stuffed up suggestion (1)
<mpt> mvo: I think just "Languages available to people using this system:" would be sufficient
<ogra_> mdz, yes, and we decided to go with Kamions decision that approval is needed, but handled loosely
<mpt> mvo: Then it would fit on a single line.
<mpt> I think I'm done now. :-)
<mdz> ogra_: Kamion's decision?
<ogra_> mdz, Kamion was very straigt telling me we should respect UVF
<ogra_> mdz, you then softened this a bit ...
<mvo> mpt: ok, thanks
<mvo> mpt: should be ready soon
<mjg59> Ok. In the worse case scenario, we can add a DMI quirk to fix-up the 6125.
<ogra_> mdz, but universe is in a very bad state, much worse then for hoary at this time... so approval makes sense if packages might break other packages
<mpt> mvo: btw, how did you achieve that button layout in metacity?
<mvo> mpt: the window has it's width because in the combo box is a entry like "English (United Kingdom of Great Britian and Nothern Ireland)" :/
<mvo> mpt: you need to use gconf-editor to get it, but I really strongly dislike the default where close is _so_ near to maximize
<mpt> mvo: Agreed, I was hoping that was a Breezy default I was seeing :-)
<mvo> mpt: let's blame seb128 for it ;)
<ogra_> mdz, have a minute for pm ? 
<mpt> iz metazity boog
* xhaker is away (Away, bnc logging)
<elmo> xhaker: please turn public away notification off
<mvo> mpt: http://people.ubuntu.com/~mvo/l-s-3.png
<mjg59> elmo: Of course, X is still broken unless you disable acceleration
<mpt> mvo: "menu" -> "menus"
<mvo> mpt: fixed, thanks
<mpt> mvo: "Writing Aids includes" -> "Writing Aids include"
<elmo> mjg59: or use the binary goop?
<mjg59> elmo: Possible
<mvo> mpt: fixed
<elmo> mjg59: ok
<daniels> mjg59: what?
<mjg59> daniels: On the nx6125. 
<mpt> mvo: Make the explanation just as wide as the listbox (e.g. in that screenshot "available" should have fit on the second line, not the third)
<daniels> mjg59: chipset?
<mjg59> X300
<mjg59> PCIE
<mpt> mvo: "Use" -> "Used"
<daniels> mjg59: gnnrgh
<mjg59> Graphical corruption on the login splash, freezes part way through login unless you switch to the console
<mpt> mvo: "Default language:" and "Languages available to people using this system:" should be the same font/weight
<mpt> mvo: Other than that, it's looking excellent now, well done.
<daniels> mjg59: i can't see why though ... it's not doing anything with the cp, obviously, just register banging.  it's a known quantity ... sigh.
<Treenaks> mjg59: Three cheers for for PCIE
* Treenaks pokes his FireGL V5000
<daniels> mjg59: i would _love_ to actually get one of those laptops.  i've been sitting around reading that they're broken for some time now (of course, adam's t42, which is a pcie x300, works), and no idea on what to do with any of it.
<mjg59> T43, surely?
<mpt> mvo: Is it not possible to have an option menu that is narrower than some of its options? (That's possible in Windows and Mac OS)
<mjg59> T42 is PCI
<daniels> mjg59: yeah, probably
<mjg59> And a 9600
<mvo> mpt: "Make the explanation just as wide as the listbox" looks very much like a gtk label layout problem to me, not sure how/easy hard it is to fix it
<daniels> mjg59: t4something
<mvo> mpt: checking that now
<daniels> mjg59: it's definitely x300 (well, m300), and definitely pcie.
<mjg59> Yeah, T43
<mjg59> It probably doesn't help that this is amd64
<daniels> mmm
<daniels> if we could localise this to a 32/64 bit thing, that would help a lot.
<mpt> mvo: It just looked to me like you hadn't made the explanation frame/box/gtkwhatsit as wide as the listbox, that's all
<daniels> the vt switch fixing things is curious.  i wonder if it just got more picky about the order things are done in.
<mjg59> daniels: Where's the list of individual acceleration bits, and I'll work out which bit is breaking it?
<mjg59> daniels: Once I switch back, I can crash it when doing simple operations
<mjg59> daniels: Oh, one obvious thing - when it draws rectangles, part of the bottom line is often missing
<mjg59> And the mouse carries on moving for about a second after the rendering stops, then the entire machine hangs
<daniels> http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/xaa/xaaInitAccel.c?rev=1.7&view=markup
<mjg59> daniels: They're in the driver section?
<daniels> mjg59: i'd be looking at noscanlineimagewriterect in particular
<daniels> mjg59: yesh
<daniels> mjg59: hm, if rectangles are broken -- nosolidfillrect
<mjg59> Ok
<daniels>     {XAAOPT_DASHED_BRESENHAM_LINE,	"XaaNoDashedBresenhamLine",
<daniels> 				OPTV_BOOLEAN,	{0}, FALSE },
<daniels> woo useful
<Treenaks> daniels: drivers _implement_ that?
<daniels> Treenaks: some, yeah
<Treenaks> daniels: I want them to hurry up with that new acceleration thing
<daniels> Treenaks: exa will be in for 7.0; we should have radeon, sis, and probably nv for breezy.  maybe i810, but that'll more likely be in an external repo (p.u.c/~daniels or so) since jbarnes is having fun with offscreen memory management still.
<highvoltage> hi. is there any documentation about ubuntu's build environment, and can I download it? or should I rather ask this in #ubuntu?
<ogra_> highvoltage, define  build environment
<ogra_> highvoltage, packages ? CDs ? 
<Treenaks> pbuilder?
<ogra_> greminate and seeds ? 
<ogra_> germinate even
<highvoltage> ogra_: i don't know really :) mdz said that ubuntu and debian has different "build environments", so i'd like to find out more about it.
<bur[n] er> anyone know if liferea can accept feed:// protocol?
<ogra_> highvoltage, hmm, i dont know what he means... i think we have different buildd setups and i doubt debian uses greminate and ssedlists
<ogra_> seedlists even
<Treenaks> ogra_: it doesn't
<ogra_> highvoltage, so that might be the difference he refers to 
<bur[n] er> it would be easy to integrate firefox with liferea feeds if it did... or for that matter, can we register feed:// somehow so that blam, straw, liferea, or whatever rss reader you use would work?
<Treenaks> bur[n] er: no, inventing new uri schemes is annoying
<Treenaks> bur[n] er: use MIME types instead
<Treenaks> bur[n] er: http://infomesh.net/2001/09/urischemes/
<mdz> highvoltage: if those are the words I used, there must have been more context ;-)
<highvoltage> debian doesn't use seedlists? i thought that was the native way of configuring things in d-i?
<bur[n] er> Treenaks: but rss feeds are sometimes html and firefox would try to render it instead of sending it to liferea
<rtcm> I already asked on -motu but got no answer: I need to build a debug symbols enabled package (no other modifications) is there a standard debian flag to do it?
<highvoltage> mdz: yes, I was asking you about the differences between ubuntu and debian. that's as much context as I can remember :)
<Treenaks> bur[n] er: then fix the webserver
<Treenaks> bur[n] er: to send out feeds with the proper mime type
<mjg59> daniels: Hmm. It also dislikes showing me any stipples until I move the mouse
<daniels> mjg59: er
* highvoltage goes and find more stuff to read about d-i and seedlists
<mjg59> Oh, no, maybe not
<mjg59> That might just be coincidence
<bur[n] er> Treenaks: it's not my webserver to fix ;)
<mdz> highvoltage: a "build environment" is all the stuff which influences the building of software or packages.  so it includes the compiler toolchain, library packages, etc.  these things differ between debian and ubuntu.
<Treenaks> bur[n] er: no, but you can complain :)
<bur[n] er> very true...
<mdz> highvoltage: another kind of "build environment", as ogra described, would be "the facilities and processes we use for building packages", which would be the buildd network.  that is also different between debian and ubuntu.
<highvoltage> mdz: ah, so that would refer to things like gcc, kernel version, etc?
<daniels> mjg59: i wonder if it's related to any updates at all
<bur[n] er> or i could just get in contact with teh livelines firefox extension and get them to support liferea ;)  or patch it myself
<bur[n] er> thanks for the feedback Treenaks 
<bur[n] er> :)
<mdz> highvoltage: not the kernel, but definitely gcc and its dependencies
<daniels> mjg59: i.e. if you kick some activity later, even drawing to an offscreen pixmap or something, if it shows
<daniels> mjg59: could just be missing an accel->Sync()
<highvoltage> mdz: ok. when you initially told me that, i interpreted it as "ubuntu has another process for building the distribution" (if that makes any sense)
<highvoltage> mdz: ok. i understand. thanks for clearing up.
<mjg59> daniels: Ok, got it
<Diziet>  gp_do_exit(int exit_status)
<Diziet>  {
<Diziet> +    exit(exit_status);
<Diziet>  }
<Diziet> Joy.
<daniels> mjg59: hm?
<mdz> highvoltage: we have a different process for building the distribution, too
<mjg59> daniels: XaaNoScreenToScreenCopy
<mjg59> If I do that, it seems stable.
<infinity> Diziet : Looks like a skeleton for "some day we may want some cleanup code in here" that never got filled in.
<infinity> Diziet : Not uncommon, IME.
<daniels> mjg59: boom.  thanks.
<mjg59> daniels: Hang on, still making sure of that
<mjg59> daniels: Ok. That fixes the hang, but there's still some graphical corruption. I'll figure out which one gets rid of that.
<highvoltage> mdz: does ubuntu use the same tools? is it just the actual process that's different, or the methods too?
<jdub> j^: ping
<mjg59> daniels: NoSolidFillRect seems to fix the graphical corruption
<daniels> mjg59: righty-ho.
<daniels> mjg59: amd64, you say?
<mdz> highvoltage: it depends on what part of the process you mean.  building a distribution is a large, abstract process
<highvoltage> ok, i think i understand what you mean anyway.
<mjg59> daniels: Yup
<highvoltage> mdz: i'll get the motu guys to educate me more, then I'll bug you for more info ;)
<daniels> mjg59: right, this'll take a little while to set up.  bear with me.
<ogra> my DSL sucks
<daniels> mjg59: http://amnesiac.heapspace.net/~daniels/radeon_driver.o -- i don't actually expect it to fix the problem, but it's worth a shot.
<mjg59> daniels: Ok, hang on a mo
<highvoltage> ogra_: less than my wireless, i'm sure :)
<lathiat> mjg59: what problem, ooc
<ogra> highvoltage, they changed the DSLAM unit in my headend last week, now it drops once an hour :(
<mjg59> lathiat: Crashing X300 based system
<ogra> highvoltage, ubuntu is built around its seeds, you can find the seedlists on http://people.ubuntu.com/~cjwatson/seeds/
<mjg59> daniels: 404
<ogra> s/around/from
<highvoltage> ogra: ah thanks, something to investigate! :)
<ogra> there is also a explanation how that works on https://wiki.ubuntu.com/SeedManagement
<highvoltage> what is tocd3?
<jsgotangco> the open cd?
<mjg59> daniels: radeon_drv.o
<daniels> mjg59: er yeah, that
<\sh> *grmpf*
<\sh> ping ogra
<ogra> \sh, pong
<mdz> daniels: so about the X server in breezy...
<\sh> ogra: how did u get the tftpd-hpa working again?
<ogra> \sh, install netkit-inetd before ;) its run by inetd
<\sh> actually I can't test anything anymore because the tftp is not working anymore
<daniels> mdz: been testing it in pbuilder, it's happy.  going to do upgrade tests, final polish on the xorg package, and then hopefully blast everything at the archive before I head to bed.
<highvoltage> interesting.
<mdz> daniels: you already checked it with debdiff?
<\sh> ogra: *grmpf*
<\sh> ogra: it is installed
<mdz> daniels: I asked for a copy of the packages; are they uploaded somewhere?
<mjg59> daniels: Looks much better
<\sh> let me try again..can be..that it was started by init.d
<\sh> bah
<ogra> \sh, is in.tftpd in /etc/inetd.conf
<\sh> ogra: yeah I know :) 
<\sh> brb
<daniels> mdz: not yet, because I'm still tweaking xorg; as discussed, there are filename changes (/usr/X11R6 -> /usr, *.o -> *.so)
<mjg59> daniels: Some strange stuttering in the login sound, but no freeze
<daniels> mjg59: it ... actually worked?
<mdz> daniels: we agreed not to do /usr/X11R6 -> /usr
<mjg59> daniels: Oh, no, hang on
<mjg59> System/Preferences has drawn a hollow rectangle and then frozen
<daniels> mjg59: \o/
<mjg59> But the corruption seemed to have gone
<seb128> mdz: freeze break request for gnome-screensaver. It's universe, the new version fixes some issues and luis would be happy to get if for the GNOME liveCD
<daniels> mdz: i thought we'd agreed to do /usr/X11R6 -> /usr and then have it capable of loading old modules from /usr/X11R6
<daniels> mjg59: wow-ee.
<ogra> seb128, do it :)
<mjg59> daniels: What was the difference?
<mdz> daniels: then we misunderstood each other
<Diziet> How would I go about getting a decision about what to do about gs-esp ?  The current version is completely nonfunctional on ppc.  I think the only practical solution is probably to update to espgs 8.15rc4 and then possibly even to track upstream's rc bugfixes.
<ogra> seb128, as long as you dont want it in main immediately MOTU can approve it too :)
<mdz> daniels: I thought you said that was an alternative to moving to /usr
<seb128> no, it was defered
<Diziet> I've had a go at debugging the problem, and tried reading diffs between 7.07.1 and 8.15rc4 but they're huge.
<ogra> seb128, so sync it then :) 
<mjg59> daniels: Ok, that driver fixes the corruption. NoScreenToScreenCopy fixes the crash.
<daniels> mjg59: right
<mvo> mpt: http://people.ubuntu.com/~mvo/l-s-4.png
<daniels> mjg59: uploading a new version
<daniels> mdz: no; it was moving to /usr, but with the ability to load old drivers
<mvo> mpt: if you are happy with it, I'll upload it 
<daniels> mjg59: the difference was that we wait until the engine idles after solid fills and screen-to-screen copies now, which isn't technically necessary, but ... yeah.  sort of papering over cracks.
<Diziet> https://wiki.ubuntu.com/UpstreamVersionFreeze doesn't say who to contact.
<seb128> Diziet: mdz
<seb128> or Kamion but he's away this week
<slomo> i'm currently doing slang2 transition... we have a package (python-slang) which only works with slang1 and is only needed by woody. woody and python-slang are the same upstream and upstream seems dead (2000 last release), in debian they have no maintainer... are these two candidates for morgue?
<ogra> Diziet, for main mdz, for universe #ubuntu-motu
<mjg59> daniels: Ok, let me know when to pull
<ogra> s/mdz/mdz and Kamion
<mdz> Diziet: is this about gs-esp?
<daniels> mjg59: go
<Diziet> mdz: Yes.
<Diziet> Kamion's still away on honeymoon, isn't he ?
<elmo> yes
<ogra> until monday
<Diziet> Nice to know I didn't fail to notice him arriving back :-).
<Diziet> Attempting a full frontal assault on the bug feels like a waste of time; it's quite possible that gs-esp 7.07.1 is riddled with problems on ppc.
<mjg59> daniels: No more stuttering sound, but still the freeze when I open the System/Preferences window
<mjg59> s/window/menu/
<Diziet> And it's known to work much better in the most recent version.  Shame it's an upstream release candidate of a new upstream-upstream.
<daniels> mjg59: yeah, sounds about right
<Diziet> mdz: ... ?
<daniels> mjg59: can you please run from a remote host with -verbose 999, and it should spit out which ScreenToScreen functions it's entering and exiting
<mjg59> daniels: Ok
<Diziet> I can do a more proper writeup in email if that would be helpful.
<mdz> Diziet: I'm in a meeting right now
<mdz> Diziet: so yes, that would be better
<Diziet> Ah, right.  Willdo.  I'll put it in my activity report and CC you for your attention.
<mjg59> daniels: (EE) RADEON(0): FIFO timed out, resetting engine... and then hang
<mjg59> Didn't get to the desktop
<mjg59> It didn't seem to say anything about which functions it was entering and exiting
<slomo> can somebody do a rebuild for mpeg2dec and libdv? this is needed for slang2 transition
<mxpxpod> who is the main guy that makes decisions for ppc for ubuntu?
<daniels> mjg59: agh
<mjg59> daniels: I got 4 of those, preceded by a (EE) RADEON(0): Idle timed out, resetting engine...
<daniels> mjg59: right.  so the engine is locked, hard.
<mjg59> Yeah
<janimo> daniels, what's the best way of working on breezy xorg code?Is there a baz archive?
<daniels> janimo: not at the moment, no
<rburton> daniels: awww, i was going to work on my ssh SI scheme
<rburton> oh i say, dirac plugin for gstreamer
<rburton> rock on
<doko> mdz: didn't you want to build a live CD for amd64? I just see, that OOo2 is broken for amd64, as long as the ooo2-amd64 package is not updated
<daniels> rburton: err, why don't you anyway?
<mdz> doko: I did build a live CD for amd64
<daniels> mjg59: /win 55
<daniels> er
<rburton> daniels: yeah i should have a go really
<mpt> mvo: Sorry, I was at lunch
<mjg59> daniels: Win!
<mpt> mvo: Still (1) "Writing Aids includes" should be "Writing Aids include", (2) "Use" should be "Used", and (3) the two control labels should use the same font weight. Other than that, it's great.
<mpt> mvo: Oh, and "Translation" should be "Translations"
<daniels> mjg59: new debugariffic version coming over that should tell you what it's doing at the time
<mvo> mpt: thanks, I was sure I fixed that, (me grumbles about glade)
<mjg59> daniels: Rock
<daniels> mjg59: go
<mpt> mvo: btw, what happens if you uncheck the "Translations" checkbox for the default language?
<mjg59> (**) RADEON(0): About to leave SubsequentSolidFill (synced)
<mjg59> (**) RADEON(0): WaitForIdle (entering): 64 entries, stat=0x00000140
<mjg59> (**) RADEON(0): WaitForIdle (entering): 64 entries, stat=0x8410c140
<mvo> mpt: nothing. I need to leave for dinner now, I'll bb in ~30min
<mjg59> Then a pile of "select returned 1" and "select returned 0"s, followed by "Idle timed out", and then "Fifo timed out" and crash
<mjg59> daniels: ^
<daniels> mjg59: yeah
<lathiat> seb128: could we get a separator between system tools and add/remove programs, it would look much nicer
<daniels> mjg59: i have a rough idea where it is that's going wrong now, but need to crash
<seb128> lathiat: no opinion on it, did the 2.10 version had one for the "run app" ?
<lathiat> seb128: yes
<Diziet> mdz: YHM
<seb128> lathiat: I've to go now, we will talk later about this
<lathiat> seb128: okie
<mdz> Diziet: I think that a new upstream gs-esp could greatly improve the current printing situation
<mdz> Diziet: however, I'm unimpressed by its bug list in 
<mdz> Debian
<mdz> the new release seems to have major regressions
<mdz> it hasn't even made it into testing yet
<Diziet> Yers.
<Diziet> Most of the bugs there are against 7.07.1 of one kind or another.
<sedak> when a bug has a UPSTREAM status in bugzilla and that there is a new version that fix the bug, what do we do to make the responsible for that package know ?
<sedak> the bug is assigned to seb128 now btw
<mdz> Diziet: I'm talking about the grave and serious bugs, which are all new
<ogra> mdz, so whats your word on mediawiki, pitti approved it in the end, but he wasnt happy to do it... we'll need it for wikipedia support in edubuntu...
<{Seb}> i am correct in saying NetworkManager is broken?
<mdz> ogra: pitti changed his mind?
<ogra> janew and i convinced him, he didnt know about its importance for us
<ogra> mdz, he still thinks its not good... thats why i want a last word from you about it
<ogra> mdz, since you were involved in the process that brought us here...
<mdz> ogra: in london we decided that mediawiki was what the community wanted
<mdz> ogra: but that's orthogonal to whether it's supportable
<ogra> mdz, exactly and we committed to have it if any possible
<mdz> I'd like to hear pitti's comments on it, especially if he changed his mind since we last talked
<mdz> ogra: I also think it's a bit late to add new complex applications to edubuntu; it's time to focus on stabilizing the preview release
<mdz> ogra: do the daily CDs work?
<ogra> mdz, it looks very  odd for me that we will ship completely different stuff from what we commited...
<ogra> mdz, nope...
<mdz> ogra: working CDs are top priority
<mdz> whether or not they contain mediawiki
<HiddenWolf> ogra, it's better to ship something that works partially, rather than something that's great and feature-complete, but buggy, right?
<ogra> i didnt test todays, the last one i tested still suffered from libcairo stuff (mondays)
<janimo> lamont ping
<ogra> HiddenWolf, its odd to have told your users you dont like their software selection but will support it, and in the end you ship what you suggested first...
<ogra> it feels like cheating the user i dont feel good about it
<doko> mdz: any word on the OOo2 update to milestone 125? just to know, if Mithrandir should build the amd64 package for m121, or the m125
<mdz> doko: I'm installing it right now
<HiddenWolf> ogra, agreed, but at least you'll ship something workable...
<ogra> i.e. we all said we want moin, all users said they want mediawiki, we committed to that, but in the end we ship moin
<doko> mdz: ok, I'm away for about two hours
<lamont> janimo: si?
<ogra> its not that mediawiki isnt workable
<janimo> lamont, eople.ubuntu.com/~lamont/buildLogs/x/xfce4-panel/4.2.2-1ubuntu2/
<ogra> its just hard to support security wise
<janimo> any idea why only powerpc got rebuilt today?
<mdz> doko: I am leaning toward including it if it feels good
<janimo> manualintervention?
<mdz> doko: how much testing have you been able to do?
<mdz> Mithrandir: an updated oo.o2-amd64 should target m125 since I think that is more likely
<elmo> ogra: maybe we should make such hasty commitments in the future?
<elmo> shouldn't too
<lamont> janimo: so there's build logs there for all 4 architectures, ppc being the only successful one, and you need someone to read the logs and tell you why they failed???
<ogra> elmo, it wasnt hasty ... there was a two day discussion
<janimo> lamont, no it seems only powerpc got rebuilt today
<mdz> it wasn't a commitment
<mdz> it was a survey
<mdz> if we ship something that we can't support properly, they lose AND we lose
<lamont> janimo: that'd be because either it hadn't been tried before, or happened to be given back as part of something else.
<mdz> if they really want it, they can always install it from universe
<mdz> but they'll know what they're getting into
<janimo> thanks
<ogra> mdz, it caused the the expectation at the users that they'll be able to install wikipedia on whyt we ship
<lamont> I'm betting it was infinity clearing up the buildds on ppc after some cleanup work there
<mdz> ogra: that won't happen unless mediawiki is supportable
<lamont> janimo: things with actual compile errors don't get automatically retried
<ogra> mdz, ok, so should i resort to moin then and drop the inclusion report ?
<mdz> ogra: have pitti mail me his thoughts about it
<ogra> ok
<mdz> ogra: and meanwhile concentrate on getting the CDs into shape
<ogra> mdz, yup
<janimo> lamont, looks like i386 and powerpc faild on the same thing (missing libpixmap)
<janimo> I wonder why only powerpc got retried today (and what triggered the rebuild)
<lamont> janimo: so what you really meant to ask from the start was 'please retry xfce4-panel on !ppc as well?'???
<janimo> lamont, not really
<Jhair> un
<janimo> as I wasn't the one who made the latest changes to these
<janimo> seb128 is did the cairo transitioning stuff
<lamont> well, to answer your original question, it was retried on ppc because one of us gave it back to the buildd's manually
<janimo> I just didn;t know what's happening and whether I should start fixing, wait on seb, the build system noticing etc
<janimo> the whole thing is very obscure to me :(
<janimo> but thanks you're always being helpful :)
<Jhair> Consider the following in hoary: ubuntu-base depends on jfsutils, but I don't use the JFS filesystem, AFAIK I can't remove jfsutils without breaking ubuntu-base. Is this a bug?
<martinald> hi guys
<martinald> could someone take a look at bugs 13521 + 11237
<martinald> and see if they are dupes?
<dredg> Jhair:  Installed-Size: 1108
<janimo> lamont I see the same with the other xfce4 cairo transed packages
<dredg> are you that stuck for space?
<janimo> do you know who did the manual giving back of these today, only on PPC?
* lamont bets on infinity
<lamont> and it was completely unrelated to xfce
<Jhair> the point is: I don't use the package and I don't need it
<jdub> mdz: we totally need to fix this unrequired shlibdeps mess for breezy+1
<lamont> Jhair: that's a question for #ubuntu, but note that ubuntu-base delvivers no files, just a bunch of dependencies...
<mdz> why is there a linux32_1-3_i386.deb?
<jdub> yo lamont 
<jdub> lamont: how's new gig?
<lamont> Jhair: that is, all you'll possibly break removing ubuntu-base is upgrades to the next release
<lamont> jdub: hectic as usual
<mdz> jdub: that is easily a 2+ release cycle kind of project
<jdub> mdz: suckage
<jdub> all this transition mess sucks up so much time :|
<lamont> jdub: otoh, starting to fix it in breezy+1 would be goodness
<lamont> jdub: have you seen http://www.arouse.net/despair-linux/ubuntu.jpg
* jdub fears MOTU uprising
<mdz> martinald: no, they are not
<elmo> jdub: eh, doko has it mostly scripted
<janimo> lamont I got a list of xfce packages that would need a manual kick on the rest of the arch 
<jdub> lamont: haha, yeah - i prefer the mandrake one though
<janimo> can I send it to you by mail?
<elmo> it's nothing like as painful in ubuntu as it is in e.g. debian
<lamont> sure
<janimo> lamont at ubuntu com?
<lamont> sure
<mdz> martinald: #11237 affects Hoary, while #13521 is an initramfs-tools issue (which only exists in breezy)
<martinald> ok
<jdub> elmo: doko's unruly use of perl does not count ;)
<elmo> jdub: seb used the same script for cairo-in-main ...
<elmo> and doko used it for C++.. so however distasteful you find it, it does work
<martinald> mdz: is this info in 11237 applicable to the other?
<dredg> what qualifies as 'unruly use of perl'?
<jdub> elmo: joke re: python policy
<mdz> martinald: your comment in 11237 is actually about 13521
<jdub> elmo: but the point is, it is mostly unnecessary in the first place
<martinald> right, thought so
<elmo> jdub: in a handwavy theoretical "wouldn't it be nice if the less people went to war" sort of way :-P
<ogra> jdub, MOTU rather lies down crying :/
<jdub> dredg: in this case, it's a joke about our policy of using python
<dredg> jdub: ah, gotcha
<\sh> ogra: what r we doing?
<jdub> elmo: it's not theoretical. if packages weren't unnecessarily depending on libcairo directly, we wouldn't have to transition so much
<martinald> mdz: is there any info i can provide you with about 13521 that would help?
<jdub> for many values of 'libcairo'
<martinald> it would be nice to have this so i could take screenshots of breezy for documentation ;)
<jdub> C++ ABI pukeshots are a different beast
<ogra> \sh <jdub> all this transition mess sucks up so much time :|
<ogra> \sh, * jdub fears MOTU uprising
<highvoltage> elmo: hi elmo.
<mdz> martinald: http://bugzilla.ubuntu.com/show_bug.cgi?id=13521#c1
<\sh> ogra: oh...I think slang2 we can remove from the list..slomo rocked today
<mdz> martinald: the person working on the bug already asked for more information
<ogra> \sh, <ogra> jdub, MOTU rather lies down crying :/
<jdub> ogra: large scale MOTU nervous breakdown would be preferable to an uprising, but still very depressing ;)
<highvoltage> elmo: did you get the gpg signed ssh public key?
<martinald> ok, sure
* dredg prepares to make a return as a somewhat absent motu
<dredg> just give me a month or so
<ogra> jdub, we are significantly more people for breezy, but the transitions sucked up all MOTU blood...
<ogra> jdub, i fear that breezy universe will be far worse then hoary
<jdub> yeah
<elmo> highvoltage: which address did you send it to?
<\sh> ogra: I told you the last time...breezy will be a off road release...
<highvoltage> elmo: i'll check...
<ogra> jdub, that means our ressources will be sucked up by fixing the remaining breakage for breezy+1 which is as worse as the transition this time
<ogra> and will draw as much time
<highvoltage> elmo: james@canonical.com, 06/08/2005
<highvoltage> elmo: 13:19 +2 GMT
<elmo> k, looking
<elmo> highvoltage: gpg --keyserver keyserver.ubuntu.com --send-key 0x6CBF29D6
<highvoltage> elmo: ok
<highvoltage> elmo: done
<Mithrandir> mdz: updating ooo2-amd64 isn't much work when the version to update to is in the archive, so just say when.
<hawk_78> hello, I'm a Summer of Code student...
<hawk_78> I've just finished the PythonModulePackaging:
<hawk_78> a tool to build deb packages out of standard python modules.
<hawk_78> I'm looking for someone to have a look at it.
<hawk_78> I also need help for publishing and licensing.
<siretart> hawk_78: out of interest, do you produce binary or source packages?
<slomo> does debian has some kind of archive were one can get older versions of packages?
<siretart> slomo: yepp. http://snapshot.debian.net
<siretart> sometimes I'd wish we had something similar for ubuntu..
<slomo> siretart: thanks :)
<elmo> morgue.ubuntu.com
<elmo> it's just run out of space, so out of date
<siretart> ah. that explains..
<ploum> Hello
<\sh> elmo: ping...why is libdv in main and the binaries in universe? do u know? :)
<ploum> Am I the only one for wich the epiphany icon disappeared in the "Internet" menu ?  Must I fill a bug ?
<elmo>  libdv-bin |    0.103-2 | breezy/universe | amd64, hppa, i386, ia64, powerpc, sparc
<elmo>     libdv4 |    0.103-2 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
<elmo> libdv4-dev |    0.103-2 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
<elmo>      libdv |    0.103-2 |        breezy | source
<\sh> ah only the bin files..
<elmo> \sh: libdv-bin isn't seeded  and nothing depends on it
<\sh> elmo: thx :)
<HeMan> Hi! How often does packages.ubuntu.com update?
<elmo> highvoltage: you seemed to flip/flip on the username; which is it to be?  jono or jonathan? :)
<HeMan> I installed a package (python2.4-opengl) but it doesn't contain the files packages.ubuntu.com suggests
<HeMan> (yes, breezy)
<highvoltage> elmo: jonathan will be fine, thanks :)
<teprrr> hmm, there's no apt-front (dev) packages in ubuntu at all?!
<mvo> teprrr: you will have to build it from svn
<teprrr> mvo, hmm. is there some reason why it isn't included?
<mvo> teprrr: it's under heavy development and the abi/api changes quite often (also I'm not sure if that is still the case, but it was some weeks ago)
<teprrr> mvo, ah. okay..
<highvoltage> elmo: /win 13
<teprrr> what happened to GL/glx.h and other glx dev files?
<highvoltage> sorry
<mvo> teprrr: building from svn should be straightforward
<teprrr> yeah, just wanted to test adept, but it's not that important.. just thought why there's no such thing
<mvo> teprrr: IIRC mournfall wanted to link libapt-front statically against ept
<teprrr> oh
<mvo> teprrr: at least at the beginning
<teprrr> mvo, okay.. now it's just how to compile kde without libtool and where's those missing gl(x) headers
<mvo> teprrr: the joy of the x-transition :) maybe you need libgl1-mesa-dev?
<teprrr> The following packages will be REMOVED:
<teprrr>   libgl1-xorg libgl1-xorg-dev libgl1-xorg-dri
<teprrr> :)
<HeMan> how could i look in a .deb-file without installing it?
<Mithrandir> dpkg -c and -I
<HeMan> Mithrandir: thanks
<teprrr> btw, should wajig search for packages from packages.ubuntu.com instead of packages.debian.org?
<doko> mdz: most of my OOo2 testing is limited to starting the applications, loading old documents, scrolling, editing a bit. These docs are M*word/excel/ppoint docs from old projects. I didn't see any obvious regressions. Spent about 1 1/2-2 hours testing. I didn't test powerpc, but pitti did basic tests and couldn't find obvious regressions
<doko> jdub: the zope* uploads are real work, done by kobold, one of our SoC students
<jdub> doko: hrm?
<doko> jdub: no perl work :-)
<jdub> doko: oh - nah, we were talking about general transition stuff
<jtan325> in cvs, how do you de-remove a file that's been scheduled to be removed?
<jtan325> (assuming you haven't actually committed yet)
<jdub> doko: hmm, what does OOo use portaudio for?
<Mithrandir> jdub: making noise during presentations, I presume.
* jdub bangs head against wall
<jdub> can it use anything else?
<doko> jdub: sound for presentations ...
<louie> ooo: pissing in the swamp since 1999
<louie> ;)
<jdub> so annoying!
<seb128> doko: do you need cairo/glitz?
<seb128> doko: the Debian maintainer has built cairo 1.0 without it: "* Removed glitz backend as currently experimental and unsupported"
<elmo> oh man
<doko> seb128: no, I will not enable that for the next OOo2 upload (pending mdz's ok)
<seb128> k
<mdz> doko: new ooo2 looks good to me
<mdz> doko: let's do it
<doko> mdz: fine :)
<doko> mdz, elmo: please reply to the OOo2 help topic I sent you via email. the bonus side would be having it for translations in rosetta as well, and hope it's buildable for breezy+1
<mdz> doko: I don't think that having oo.o2 help in multiverse only is worth the effort of creating that package
<mdz> doko: can we not pre-generate the help?  what is its license?
<doko> mdz: the license would allow that. but we would need the sun classes for generating that help. it would be less maintainance work to put that package in mutiverse, but I would prefer putting the help into main as well, if we can put the pregenerated help in a package in main.
<mdz> doko: if the license allows it, I prefer to have the pregenerated help in main
<doko> fine, preparing that one next week
<mdz> doko: perhaps the oo.o2 source package could have a build target which generates the help and wraps it in a source package?
<mdz> then it would be easy to keep up to date
<doko> mdz: exactly, same thing as we do with the -l10n package now
<mdz> oh, I haven't looked at the -10n stuff. :-)
<mdz> doko: mark says you expect to be able to have oo.o2 in rosetta for breezy
<doko> it's basically: rename the package, rebuild the control file, add the rosetta translations, rebuild
<jdub> boh, no seb
<doko> mdz: yes, we export the language data, it can be converted, I'm waiting for some tests with rosetta. I agreed now to reduce the number of po files from 36 to below 10
<jdub> mdz: permission to upgrade djvulibre by one micro version, required by evince?
<jdub> (otherwise, it could happily drop into universe if we remove the build-dep)
<mdz> jdub: if nothing other than evince uses it, yes
<elmo> nothing in the whole archive other than evince does
<elmo> (which is kind of amusing)
<jdub> and itself :)
<jdub> seb128: just asked mdz if i could upgrade djvu (micro+1) for evince
<jdub> seb128: also, mind if i turn on a few of the other evince backends?
<doko> jdub: no glitz :)
<seb128> jdub: that was on my list when I've read the changes for new djvulibre package this morning, thanks :)
<Keybuk> ah yes, the return of the dpi bugs
<seb128> jdub: is he ok ?
* Keybuk beats seb128 up
<seb128> Keybuk: GTK 2.8.2 coming within 2 hours, don't worry
<seb128> (upstream already here, but I've to sort cairo first and then package it)
<seb128> jdub: what other options do you want to turn?
#ubuntu-devel 2005-08-30
<doko> mdz: bugs which should be fixed for breezy, should have severity major?
<mdz> doko: severity reflects the bug's impact on Ubuntu and users, priority its relative importance compared to other bugs of the same severity, and target milestone which release it should be fixed in
<mdz> for the release we try to minimize the number of bugs >= major
<crispin> mdz: if that is the case, shouldn't bug 290 be at least major ? It stops my entire computer from booting
<doko> mdz: i.e. 14092, which seems to be minor for devlopers, but it's annoying for a user
<mdz> crispin: http://wiki.ubuntu.com/HelpingWithBugs explains the severities
<mdz> doko: ^^ also
<mdz> crispin: how exactly does that bug prevent your computer from booting?  is it a diskless terminal?
<doko> so does amd64 account for "a large portion of Ubuntu users" ?
<crispin> no, but my network card isn't raised, which means NIS and NFS home dirs don't come up, and then one of the later init scripts locks up
<crispin> I have had to manually add an extra init script to get the network card raised
<mdz> doko: by downloads I think it's about 5-10%
<crispin> bug 13832 was my original report
<elmo> mdz: eh, downloads of what?
<mdz> elmo: ISOs
<mdz> via bittorrent
<mdz> the last time I looked, which was admittedly a while ago
<mdz> why, has it changed?
<elmo> oh, I thought you meant apt
<mdz> elmo: do you have those numbers?  that'd be a much larger sample size
<elmo> i'm processing some now
<elmo> on a 15Gb logfile.  yay lack of logrotate *cough*
<mdz> yay for LFS support in apache
<jdub> seb128: oh, can we just sync djvu from sid?
<jdub> seb128: wanted to explicitly enable all of them (particularly pixbuf and tiff)
<seb128> jdub: probably, I've not tried to build it yet but that should be fine
<jdub> also looking  into t1
<seb128> jdub: I've enable tiff afaik
<seb128> jdub: did you ask mdz about djvulibre new version? it has a soname change but no rdepends out of evince 
<jdub> yeah
<jdub> elmo: please sync djvu from sid :-)
<elmo> ok to override ubuntu changes?
<jdub> seb?
<jdub> hrm, i think that's going to be caught up with C++ transition issues
<Nafallo> jdub: hi! do you have an ETA for the swedish mailinglist? :-)
<seb128> elmo: yeah, go ahead
<jdub> mailing lists is #1 on my list as soon as i start work ;)
<seb128> Debian has transitionned too
<jdub> (like, give me maybe 1/2 hour ;)
<Keybuk> have we moved the mailing lists off rince yet?
<Nafallo> jdub: hehe, oki nice :-)
<elmo> 24032435 i386
<elmo> 1249645 amd64
<elmo>  392432 powerpc
<elmo> Keybuk: no
<jdub> Keybuk: nup
<Keybuk> bwahaha, wasn't that supposed to happen ages ago?
* jdub is considering installing spamassassin on it
<jdub> also going to start a moderator team
<elmo> Keybuk: yes
<mdz> elmo: wow
<elmo> yeah
<mdz> that's quite different from my old numbers
<Keybuk> good showing from amd64
<mdz> amd64 is still about 5%
<elmo> keybuk: 5% is good?
<mdz> but powerpc is only about 1.5%
<Keybuk> reasonably
<jdub> there are so many OS X users to liberate though
<mdz> rather than 4% or so that I saw before
<mdz> maybe people are moving from ppc to i386
<mdz> or maybe powerpc users are nuts about bittorrent
<Keybuk> there's a limited market for amd64, those that have houses large enough to put them a long way away from the bedroom
<mdz> or maybe a lot of powerpc users are on dialup
<Keybuk> otherwise you roast in your bed, and can't sleep from the noise
<mdz> computers don't belong in bedrooms
<jdub> mdz: got any shipit arch stats?
<elmo> Keybuk: eh, they're not any noiser than P4's ?
<jdub> the only computer i'd consider putting in the bedroom is something for pia to plug her pda into
<Keybuk> yes, but our primary market still haven't moved out from home ;)
<elmo> and you can get amd64 laptops now
<elmo> trying on a less "SINCE THE BEGINNING OF TIME" log file
<mdz> jdub: no, I don't deal with shipit at all
* dredg wonders what the statistics are for ubuntu users, and what % of users are ex gentoo fanboys...
<Keybuk> seb128: nautilus is being very crashy today
<seb128> not the first to say that :/
<seb128> no issue here
<seb128> ARG, I hate .la files
<seb128> $ grep glitz /usr/lib/*.la | sed 's/:.*//' | uniq | wc -l
<seb128> 31
<Keybuk> seems to be when copying files about
<seb128> if we stop building cairo with glitz we have to rebuild a whole stack on stuff in the right order again :/
<Nafallo> mdz: okey to bring in kismet 2005.08.R1? fixes two CANs.
<elmo> Nafallo: ask a MOTMOTU
<mdz> Nafallo: doesn't matter to me; it's universe
<Nafallo> ah, oki.
<seb128> Keybuk, doko: mdz: we used to build cairo with glitz. Now a pile of stuff built with cairo have a .la mentionning glitz.la and we want to build cairo without glitz ... what would you do?
<seb128> keep the libcairo-dev Depends on libglitz-dev time to rebuild to avoid the FTBFSes is ugly?
<Keybuk> it's an interesting problem isn't it
<Keybuk> rebuild cairo and everything upwards :-/
<ajmitch> elmo: afaik it's ogra, dholbach & a couple of delegates for UVF exceptions, something we have to clear up
<seb128> yeah, that's going to be a mess
<Keybuk> hmm, and metacity just crashed too
* jdub wishes we had --as-needed functionality in shdlibdeps or something
<jdub> in libtool would make sense too
<jdub> maybe
<Keybuk> no such thing as "as-needed" for static libs
<seb128> jdub: do you have an opinion on cairo/glitz?
<Keybuk> which is why you have to list all the dep tree in the .la file
<Keybuk> if you wanted to link statically to a lib that links with cairo, you need to link in libglitz
<seb128> we should just drop .la files
<doko> seb128: grep the archive and re-upload all packages mentioning glitz
<Keybuk> no, we shouldn't
<Keybuk> it's there for a reason
<seb128> doko: they have to build the right order
<Keybuk> if you drop the .la files, drop the .a files too
<jdub> Keybuk: ugh, yucky
<seb128> that's going to break builds for a week again
<jdub> perhaps .la files should describe both situations :)
<doko> .la files are evil, they are even used for loading libs using dlopen ...
<jdub> seb128: i thought it was a runtime depend, so i'm a tad shocked by this problem :)
<seb128> mdz: around?
<mdz> seb128: yes
<seb128> mdz: did you read about the cairo/glitz issue?
<mdz> seb128: reading
<mdz> seb128: what is the reason for building without glitz?
<seb128> "   * Removed glitz backend as currently experimental and unsupported"
<seb128> the Debian maintainer did that
<mdz> how many packages affected?
<seb128> I've 31 .la files mentionning it on my box
<seb128> that's not a runtime issue for apps
<seb128> but that's going to break builds because of .la mentionning glitz and cairo not bringing it
<mdz> seb128: the best choice would seem to be to rebuild
<mdz> we have scripts for this
<seb128> the number of packages is not the issue
<seb128> I just wanted to make sure that you don't need to have everything installable from desktop today or something because it will take some hours to rebuild
<seb128> let's go for it 
<elmo> DO IT, POP THE TRUNK
<seb128> elmo: pango1.0 sync from incoming please
<elmo> seb128: done
<seb128> elmo: thanks
<mdz> new rule: no more exact versioned deps on arch: all by arch: any :-P
<mdz> that's the only reason this is inconvenient
<seb128> mdz: what should be used instead?
<mdz> seb128: now that is the question
<seb128> we already talked about that for libgnome etc with pkg-gnome guys
<seb128> the out of sync arch any/all is an issue for buildds every time
<mdz> maybe we should allow arch: all packages to be at different versions on different architectures
<elmo> it can be fixed in the archive
<mdz> so the old arch: all stays around until the new arch: any is built
<elmo> yeah, I worked out how to do that in katie a while ago
<mdz> I'll add it to my launchpad wishlist ;-)
<mdz> what did my departure message say?  I switched desktops and back and xchat was GONE
<carstenh> 01:41:49 -!- mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net]  has quit 
<carstenh>           [Remote closed the connection] 
<mdz> that's the second time it's done that
<mdz> seb128: have you seen any other xchat crash reports?
<seb128> just from people using a notify plugin for it
<seb128> is that your case?
<seb128> <-- mdz has quit (Remote closed the connection)
<seb128> it said
<mdz> I don't think I am using any notify plugins
<mdz> the only plugin I have is topicdiff.py
<seb128> so that's a new one ... run it under gdb so next time you get a bt :)
<mdz> I am
<mdz> no symbols, though
<ajmitch> elmo: sync python-imaging from sid, please
<ajmitch> elmo: ah, that's a main package..
<elmo> ajmitch: if you're not a main uploader, pls proxy through/get approval from  someone who is then
<ajmitch> elmo: I'll ask doko, it's his debian package
<Keybuk> topicdiff.py is mine
<Keybuk> so it is flawless
<Keybuk> obviously
<Keybuk> but, more to the point, nobody changed the topic before mdz crashed
<mjg59> Hrm. acpi-support has hit the archive, but hasn't been built
<mjg59> Where are the buildd logs?
<elmo> people.ubuntu.com/~lamont/ somewhere
<elmo> missing b-ds
<seb128> elmo: gtk+2.0 sync from incoming please
<mjg59> Oh, bugger. Yes.
<mjg59> Hngh.
<elmo> seb128: done
<seb128> thanks
<seb128> Keybuk: where is this topicdiff.py ? :)
<Keybuk> www.netsplit.com/software/topicdiff I think
<seb128> thanks
<mjg59> elmo: I've got a kernel workaround for the nx6125 clock running too fast, I'm in touch with HP over the temperature breakage and daniel's almost got the X crashes
<wohaah> mdz, dude
<wohaah> are you there?
<elmo> mjg59: sweet
<elmo> it'd rock if we could get it not completely sucking for breezy
<mjg59> elmo: If we can't get a new BIOS for it by Breezy, I'll stick in a DMI quirk to disable the APIC
<schweeb> mjg59: I noticed in the acpi-support or acpid updates the other day, you put in some sata stuff... anything useful for those of us w/ sata hard drives in our laptops?
<jdub> run_away_run_away()
<mjg59> schweeb: Useful in what way?
<schweeb> like spinning down the hdd w/ laptop mode or anything? (I seem to remember that not working)
<mjg59> Yes, that should work
<mjg59> Man. I can't remember whether I uploaded this package or not.
<elmo> that's encouraging...
<mdz> the only use for the otherwise obnoxious .upload file
<mjg59> Ah. It seems that I didn't.
<mjg59> How odd.
<mjg59> I must have copied it over to test, and never actually uploaded it
<schweeb> hrm, wonder why acpi-support .22 hasn't made it to the archive yet
<mjg59> schweeb: Because I suck
<mjg59> schweeb: .23 should do soon
<schweeb> k
<mjg59> Oh FFS
<schweeb> sorry about your suckage, hope that improves soon :p
<jdub> seb128: wow, i just rebuilt evince, and it very reliably crashes in libdbus-glib on startup :)
<mjg59> The headers for the XTest extension *don't depend on the library*
<carstenh> .23 of which package?
<schweeb> carstenh: acpi-support
<carstenh> ok, thanks. i have similar problems.
<mjg59> Right. 0.24, then.
<schweeb> rofl
<seb128> jdub: weird, the current package is supposed to fix this bug. From where do you build?
<mjg59> libxtst-dev *doesn't actually contain any headers*
<jdub> seb128: building on my machine, 0.3.4-0ubuntu3
* mjg59 kills daniels
<jdub> seb128: do i not have latest source?
<seb128> jdub: could be an autogenerated .h file shipped with the tarball, current version has this issue but the debian/rules do a rm of it
<jdub> ah, that's in this version
<jdub> bong :)
<seb128> jdub: that's the current version ... 
<seb128> grumpf
<seb128> I'll upload poppler now and then rebuild evince
<seb128> s/upload/update/
<jdub> hold on, probably a problem on my end
<jdub> yeah, file was there due to configuration i did previously
<seb128> why did you do to my nice package? :)
<jdub> ha ha
* jdub gives it the debian/rules clean loving
<seb128> that was the evil .h stricking back? :)
<jdub> yeah
<jdub> vicious
<seb128> right
* xhaker is away (Away, bnc logging)
<elmo> okay, who recommended beep?
<whiprush> i think that was me
<elmo> dude, this thing is teh suck
<crimsun> beep-media-player?
<elmo> it's got some insanely small window size and doesn't even support doubling
<whiprush> well, it /is/ based on xmms
<elmo> so on my 1600x1200 screen it's just not usable
<elmo> xmms has 'double size' mode to make it usable on post-1985 computers
<|QuaD-> daniels is in charge of xorg right?
<mjg59> |QuaD-: Yeah
<mjg59> But it's likely that he's asleep right now
<|QuaD-> yeah... just checking
<elmo> and fricking muine doesn't play any music
<elmo> what's up with THAT?
<|QuaD-> mjg59: does anyone else do xorg with daniels?
<bob2> cplay, duh
<crimsun> elmo: ctrl+d doesn't work?
<elmo> crimsun: nope
<crimsun> what the...
<bur[n] er_> elmo: quod libet ?
<daniels> of course, you could always try *asking* daniels if he's awake, rather than just assuming he is, before you go searching for others ...
<elmo> bur[n] er_: say what now?
<mjg59> daniels: Dude, you sleep less than me
<mjg59> It's worrying
<bur[n] er_> elmo: apt-cache show quod-libet
<|QuaD-> daniels: haha... :) i am sorry
<mjg59> Also, bloody hibernation
<bob2> he subsitutes more sleep for whiskey than you
<mjg59> For some reason it's unhappy with usplash
<bur[n] er_> elmo: apt-cache show quodlibet
<|QuaD-> daniels: are there any major problems with X currently that would make it crash when logging in wiht gdm?
<mjg59> bur[n] er_: You've already said that
<|QuaD-> i am using the nv drivers
<bur[n] er_> mjg59: i mistyped ;)
<mjg59> |QuaD-: When you say the nv drivers, you mean "nv" and not "nvidia", right?
<|QuaD-> mjg59: yeah
<mjg59> |QuaD-: In that case, it's probably best to file a bug
<|QuaD-> mjg59: hmm, alrighty, i think its in my config file, but i wanted to know if there are any known bugs before i continue picking at my xorg.config
<|QuaD-> should glx or glcore be enabled with nv drivers?
<HrdwrBoB> no
<|QuaD-> what about dri?
<daniels> bob2: no, I don't drink whiskey at all
<bob2> I meant 42 below
<HrdwrBoB> daniels: so just drunk on love?
<daniels> |QuaD-: i guess file a bug, yeah.  glx/glcore/dri won't make any difference, since nv doesn't use them.
<daniels> HrdwrBoB: no, vodka, mainly.
<|QuaD-> daniels: alright, if it doesn't work tonight, i will file a bug
<|QuaD-> other than busid, driver, and identifier, is anything needed in device?
<daniels> no
<bob2> don't forget to put the busid in xorg.conf
<bob2> it makes the driver work faster
<|QuaD-> bob2: in the device section i have it
<Keybuk> seb128: does evo use gnome-gpg?
<seb128> no that I know of
<seb128> why?
<jdub> Keybuk: i thought you could configure the gpg command?
<Keybuk> oh, just wondering
<elmo> 36251592 i386
<elmo> 1888596 amd64
<elmo>  563622 powerpc
<elmo> ^-- other half of archive.u.c
<elmo> i.e very similar
<|QuaD-> lets see if my config is working :)
<whiprush> > I will be in MI on Thursday (25Aug) thru Friday.  I am going to Brief
<whiprush> > the Australian Army guys on their tank buy.
<whiprush> >  bad paste, sorry
<bob2> I hope you're not leaking classifed info
<whiprush> heh, nah ...
<HrdwrBoB> everyone knows we're buying M1s
<bob2> btew
<bob2> fridge me up
<whiprush> bob2: ask Mr. Dub.
<|QuaD-> daniels: you still awake?
<bob2> there's a band here called Dubba Rukki
<bob2> jdub should hook up with them
<|QuaD-> Symbol __glXgetActiveScreen from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!
<whiprush> dude, so check this out. 10 days before release, we should do a "ten reasons to use Ubuntu" list.
<whiprush> 10 x 10.
<whiprush> 10 reasons every day
<|QuaD-> that cmoes out in in my xorg.0.log file
<bob2> is archive.ubuntu.com missing packages or something?
<jdub> whiprush: rock. write up some lists. :)
<whiprush> I'm on it.
<Keybuk> ouch, trying to spool dvd over USB 1.x is painful
<whiprush> jdub: hey is the official firefox icon in colony3 a mistake? or is that all worked out?
<|QuaD-> Skipping "/usr/X11R6/lib/modules/libfb.a:fbmmx.o":  No symbols found <-- is another error in my xorg.0.log
<jdub> whiprush: the trademark icon was incorrectly (and violationarily!!11) shipped in gnome-icon-theme ;-)
<whiprush> :-/
<ajmitch> jdub: oh that's a shame, I hoped it was there to stay
<whiprush> for a second there it seemed like everyone was on the same side.
<whiprush> but that's just crazy talk
<jdub> well, we may just get it sorted for breezy
<jdub> properly
<jdub> we'll see :)
<jdub> luckily it will be a tiny change in debian/rules if we are allowed to :)
<daniels> |QuaD-: the first error means that you never bothered uninstalling nvidia-glx, but it shouldn't cause problems
<daniels> |QuaD-: the second warning is utterly harmless
<|QuaD-> daniels: ok, i filed a bug
<|QuaD-> my first bug ever filed 
<|QuaD-> i hope i did it right
<|QuaD-> gtg for now
<|QuaD-> ttyl
<shaya> anyone seen mdz in a bit?
<mdz> I have
<shaya> :)
* fabbione finally gets to burn breezy live
<fabbione> morning guys
<ajmitch> morning fabbione 
<jsgotangco> hi all
<ajmitch> hi jsgotangco 
<lifeless> ./win 18
<fab_live> mdz: LIVE looks very very good :)
<fab_live> one problem only, given 2 nics in the box, it did attempt to init the wrong one...
<fab_live> other than that.. 100% success :)
<mdz> fabbione: which one is the wrong one?
<mdz> fabbione: it should try one, and if it works, use it, otherwise try the next
<fabbione> mdz: it did try to init eth1 and failed (no dhcp on that vlan)
<fabbione> and eth0 was unconfigured
<mdz> interesting
<fabbione> it didn't attempt to init it at all
<mdz>  /var/log/installer/syslog would be interesting
<fabbione> meh ok..
<fabbione> wait
<fabbione> i was rebooting already to install ltsp
<fabbione> but X res and all other stuff were perfect
<`anthony> So is there an easy way to downgrade my kernel to the version before last week's security update? It's completely screwed up unsuspend on this machine.
<`anthony> (logging a bug about it now)
<fabbione> mdz: do you mean /var/log/casper/syslog.gz ???
<fabbione> because there is no such installer/syslog...
<mdz> fabbione: yes
<mdz> fabbione: that is a saved copy of /var/log/installer/syslog from d-i
<elmo> `anthony: the hoary kernel will still be available in the pool
<elmo> as opposed to the version in hoary-security
<fabbione> mdz: ok..
<elmo> it will of course be at the very least local-rootable tho
<`anthony> elmo: Hm. So if I comment out the hoary-security from apt, and re-run apt-get update, it will offer the older one?
<`anthony> elmo: I can handle local-rootable over "have to reboot twice a day"
<elmo> apt won't offer to downgrade stuff without mucking around with pinning
<elmo> you might be best off just downloading the relevant deb by hand and installing it with dpkg
<elmo> (icky i know)
<fabbione> mdz: Aug 25 03:23:28 netcfg[12158] : INFO: eth0 is disconnected. (MII)  
<fabbione> mdz: we can't rely on MII info 
<fabbione> for 2 reasons:
<fabbione> a) not all cards are MII 100% compatible
<mdz> fabbione: dude, that has been the same since Warty
<elmo> `anthony: it seems very strange that a  hoary-security kernel update would make your box unstable
<fabbione> b) in my specific case the switch takes longer to negotiate
<fabbione> mdz: i didn't have this switch in warty
<fabbione> mdz: this is a GigaEth connected to a 10/100MB switch
<fabbione> it just takes longer to negotiate
<mdz> my laptop is gige and connected to a 10/100 switch, and the MII test works fine
<fabbione> mdz: is your switch a cisco 2924 ? and do you have a inter gigabit?
<mdz> no
<fabbione> intel even
<mdz> and yes
<mdz> it is an intel gige, but the switch is not a cisco
<fabbione> mdz: mii works here too after they negotiate
<mdz> that is a very expensive switch to use at home ;-)
<`anthony> elmo: bug 14124 has the details.
<fabbione> mdz: it depends .. i got a bunch for free...
<fabbione> mdz: some with fibers :)
<mdz> I would not mind a free cat 2924 if you have extra :-)
<mdz> I am out of ports on my netgear
<mdz> how many is "a bunch"?
<fabbione> mdz: i have one or two 2916 with 16 Fast + 2 expansions slots (and i have a few expansion with 2x100 FC each)
<fabbione> mdz: + two or 3 c19xx but they are only 24 Eth + 2 Fast
<fabbione> mdz: anyway how can i easily add a MII larger timeout?
<fabbione> mdz: like testing the mii for a few secs before giving up?
<carstenh> `anthony: you could use "apt-get install package=version" when you want to skip pinning
<elmo> oh, yeah good point
<`anthony> elmo: the version in pool appears to be the same as the version from the kernel upgrade
<carstenh> hmm, and set it to hold afterwards... 
<elmo> linux-image-2.6.10-5-686 |  2.6.10-34 |         hoary | i386
<elmo> linux-image-2.6.10-5-686 | 2.6.10-34.4 | hoary-security | i386
<elmo> `anthony: ^--
<mdz> fabbione: there is no timeout; I think it just checks once
<mdz> fabbione: you could have it check in a loop for 3 seconds or something
<fabbione> mdz: yeah the latter is what i meant..
<`anthony> elmo: ah. my reeding skillz gud. 
<Burgundavia> mdz, with UbuntuExpress not making, are the windows programs still going to be ont he livecd?
<mdz> Burgundavia: of course; we never planned to remove them
<mdz> even if ubuntuexpress had been ready
<Burgundavia> mdz, ok, just checking for the Quick Tour
<mdz> Burgundavia: is that published somewhere yet?
<Burgundavia> QuickTourDraft for a rough online and the writing
<Burgundavia> going into SVN sometime later this week
<elmo> `anthony: better?
<`anthony> dunno. going to try suspending now.
<`anthony> elmo: huzzah. downgrading to -34 makes it work again.
<elmo> well huzzah for you, sucks for us ;-P
<`anthony> Yes, yes it does. If someone wants to try building kernels to fix the problem, let me know and I'll try them out.
<Burgundavia> mdz, I though LP integration was supposed to have bug filing link as well?
<Burgundavia> mdz, and how mature in Get Help going to be? should it be promoted?
<mdz> Burgundavia: "get help" is going to include a path to report a bug if appropriate
<mdz> probably through a support system first
<Burgundavia> ala bug-buddy-style?
<Burgundavia> is LP integation in general mature enough to be promoted?
<mdz> Burgundavia: as much as Breezy is, yes ;-)
<mdz> the launchpad pages don't do much yet, but they will by the time we release 5.10
<Burgundavia> ok
<Burgundavia> I was talking about for the release
<mdz> ko
<mdz> ok
<Burgundavia> the Quicktour is designed so that with a few modification, you guys can take it to a show and use it there
<jsgotangco> yeah
* Burgundavia now needs to figure out how to replicate that layout is docbook...
<jsgotangco> Burgundavia, hard
<Burgundavia> hmm
<jsgotangco> it would be a PITA to make the tables alone
<jsgotangco> that's why i was asking you before
<jtan325> is there a way to dpkg-buildpackage without the -k option, i.e. it looks up your id in a file or env. variable?
<Keybuk> mdz: definitely looks like there's a "udev is dropping shit on the floor" problem, doesn't there
<Burgundavia> mdz, was evince removed from the menus intentionally?
<\sh> morning
<jdub> Burgundavia: why bother doing it in docbook at all?
<Burgundavia> seb128, UI freeze is tomorrow. https://bugzilla.ubuntu.com/show_bug.cgi?id=12145 is simple rename of the serpentine menu item to be more useful. Can it pushed in?
<Burgundavia> jdub, I am not going to
<jdub> yay
<Burgundavia> jdub, html and then from html to pdf
<Burgundavia> if needed
<jsgotangco> jdub, such a bother for an article
<Burgundavia> going to get my web-savvy brother to help me with kickass css
<Burgundavia> jdub, I was also thinking we could feed each piece into the fridge
<Burgundavia> jdub, one section/day
<mdz> Burgundavia: I don't know; that'd be a seb128 question
<Burgundavia> mdz, ok
<mjg59> mdz: Argh, the bugs!
<mdz> mjg59: you're telling me
<jdub> Burgundavia: chat to whiprush about his ten day lead up idea
<Burgundavia> jdub, can do
<jdub> Burgundavia: it'll fit in very nicely with that
<mdz> we were sort of asking for it by sending out laptops and telling people to file bugs, though
<Burgundavia> mdz, indeed
<jsgotangco> mjg59 said anything that doesn't work
<ajmitch> mdz: the laptops are appreciated though (when they arrive)
<Burgundavia> jdub, have you checked out the lastest stuff on QuickTourDraft?
<jsgotangco> (its pretty rad now)
<Burgundavia> jdub, read the rough work section at the very bottom
<mjg59> mdz: Well, yes
<mjg59> mdz: It's gradually getting under control, though I'm going to have to chase down some suspend issues
<jdub> Burgundavia: no, but i will - thanks
<Burgundavia> whiprush, ping
<jblack> Burgandavia: When you're done with whiprush, mind if we have a chat? 
<Burgundavia> jbailey, available now
<jblack> cool.
<jdub> Burgundavia: hmm, need to refocus on benefits, not features :)
<jblack> By any chance, are you familiar with the work that I do? 
<jdub> Burgundavia: give me a few minutes, will chat on -doc
<ajmitch> jblack: I thought you were mark, not jeff? :)
<Burgundavia> jblack, yes, to a certain extent
<jblack> ajmitch: Long story. :) 
<jblack> burgundavia: COol. Yeah. I work on bazar interests, which is a tool ubuntu works on and is about to push very hard. 
<Burgundavia> ya
<jblack> I heard a nasty rumor, though, that the ubuntu docs are in subversion? 
<Burgundavia> yes they are
<jsgotangco> jblack, true
<Burgundavia> shall we move to -doc?
<jblack> Sure. :) 
<mdz> mjg59: if you'd like me to sort/tag these differently, let me know
<\sh> good morning jblack :)
<Burgundavia> mjg59, mdz do we want to sort laptop and laptop-trivial
<Burgundavia> because some things really are
<Burgundavia> mdz, mjg59 never mind, it is late and I am an idiot
<\sh> whats up with debian bts
<\sh> grrrr...libdv ftbfs on amd64
<fabbione> mdz: the last LTSPHowTo is still https://wiki.ubuntu.com/LTSPHowTo? i recall something with thinclient in the name...
<mdz> fabbione: ThinClientHowto, oddly enough ;-)
<fabbione> ah here is.. the "C" in client.. that's it
<mdz> fabbione: please add a link from LTSPHowTo to ThinClientHowto, while you're there
<mdz> similar to the ThinClientHowto->LTSPHowTo link
<Keybuk> hmm, I have a nasty hunch about this udev problem
<mdz> down to 31 messages in ubuntu-bugs
<mdz> that is a new record since hoary I think
<fabbione> mdz: yup
<mdz> and a high note on which to go to bed
<mdz> tomorrow is carpet day
<mdz> night all
<Keybuk> nite dude
<Mithrandir> carpet day?
<mdz> the day when carpet is installed in my office and I can move back into it
<Mithrandir> ah, ok.
<fabbione> mdz: eheh congratulation :)
* Mithrandir goes to eat breakfast and then go head-to-head against the evilness of ddcprobe.
<fabbione> mdz: night.. (btw there is already a link to LTSPHowTo from ThinClient)
<\sh> Mithrandir: please install libpopt-dev on ravel, breezy chroot :) thx :)
<fabbione> the other is done
<Mithrandir> \sh: done
<\sh> Mithrandir: u rock :)
<robitaille> humm...when is the doc team meeting?  25th or 26th?  wiki + agenda has 26th.  topic in #u-meeting has 25th
<robitaille> [sorry wrong channel] 
<\sh> Mithrandir: after breakfast :) please install as well automake-1.9 into ravels breezy chroot :) thx :)
<Mithrandir> done (automake1.9)
<\sh> thx :)
<\sh> hmmmm..
<\sh> /usr/bin/ld: .libs/vlc_x86_64.o: relocation R_X86_64_PC32 against `dv_vlc_class_index_mask' can not be used when making a shared object; recompile with -fPIC
<\sh> and at least this object file isn't compiled with -fPIC..
<\sh> and I don't know where to enable this 
<\sh> in Makefile.am
<\sh> mdz: is it ok with you to break UVF if a new upstream version fixes FTBFS (for main) (source package libdv)
<Burgundavia> mjg59, your latest acpi update broken stuff, like rebooting
<fabbione> jamesh: you will need to backport only the fix required
<fabbione> ^ \sh
<mjg59> Burgundavia: Yeah, yeah
<mjg59> Burgundavia: More usefully - yeah, I think I know where the problem is
<mjg59> I'll dig into it now
<mjg59> (It's fixed rather more than it's broken, so)
<Burgundavia> mjg59, cheers!
<mjg59> Basically, there's a stack of device_suspend calls that shouldn't be there
<Burgundavia> ok
* Burgundavia was having flash-backs to the bad old days...
<mjg59> Hmm. Maybe not.
<mjg59> Oh argh goddamnit
* mjg59 cries
<mjg59> Burgundavia: Ok. Do you have a machine that no longer reboots?
<Burgundavia> mjg59, indeed
<Burgundavia> or not, hmm
<mjg59> Mm?
<Burgundavia> it just rebooted correctly
<mjg59> Ah
<Burgundavia> let me a test a few more times
<mjg59> Latest kernel?
<Burgundavia> absolutely latest as of 4 hours ago and you haven't updated anything since then
<mjg59> Indeed
<mjg59> 108 bugs found.
* mjg59 cries
* Burgundavia hasn't even starting filing his docking station bugs yet...
<\sh> fabbione: this will be a hard backport..
<\sh> fabbione: asm stuff 
<jsgotangco> you have a docking station? "$??$^"$^~~
<Burgundavia> the only that works through it is power currently
<Burgundavia> not even usb works
<Burgundavia> mjg59, ok, file that bug under Could Not Replicate
<mjg59> Burgundavia: Joy
<mjg59> The docking station on mine works fine...
<Burgundavia> testing some shutdowns now
<\sh> and grrr seb128
<\sh> any popup in gnome let my desktop switchjump to another desktop
<\sh> but 
<Burgundavia> mjg59, where do shutdown messages about pcmcia get logged?
<\sh> fabbione: regarding libdv...setting gcc-3.4 as build-dep on amd64 and everything is fine...is it ok as well for the apps depending on this to use this lib compiled against gcc-3.4?
<fabbione> \sh why not backporting only the fix?
<fabbione> hard != impossible
<\sh> fabbione: because it's more then a fix...and I can't test it actually on amd64...so for me it better to have a working "old lib" but tested then to backport asm crack
<fabbione> \sh make your choise.. is it a c++ lib? or only C? in the latter switching compiler is an okish compromise
<fabbione> if it's a c++ lib, no.. you need to backport the fix
<\sh> fabbione: libdv is plain c
<\sh> + asm of course
<\sh> and I was the stupid idiot who touched it, so I have to fix it somehow
<pitti> G'morning!
<\sh> moins pitti :)
<Burgundavia> pitti, I am truly sorry you have to support mediawiki. It is too bad that moin really sucks as a userinteface and mediawiki doesn;t
<mjg59> Burgundavia: Uhm. /var/log/daemon.log, IIRC
<mjg59> But I'm not sure of that
<Burgundavia> mjg59, that is the correct log
<\sh> I'll go for gcc-3.4 and check if I have the time to backport 0.104 asm crack
<fabbione_ltsp> not bad :)
<pitti> Burgundavia: :+/
<pitti> Hi fabbione_ltsp 
<fabbione_ltsp> hey pitti
<fabbione> jammcq: ping?
<siretart> morning
<\sh> hey siretart 
<\sh> mvo: moins
<siretart> woah, we have j2re1.4 now in universe?!
<siretart> wasn't the license just crack?
* mvo waves to \sh 
<siretart> huhu mvo
<mvo> good morning siretart 
* mvo yawns
<infinity> The license is crack, that's why it's in multiverse.
<\sh> mvo: come on dude..6:00 localtime == office time ,-) I already did my work for today ,-)
<siretart> I thought it is crack as in 'unredistributable'
<phlaegel> siretart: it's blackdown java, not sun
<infinity> I'd have to re-read it, but I'm pretty sure it's only unredistributable without permission.  And we may well have gotten said permission.
<siretart> in that case, can we also put libdvdcss in multiverse?
<infinity> And we very much don't guarantee that multiverse or restricted are redistributable by anyone other than Ubuntu/Canonical.
<mvo> \sh: my local time starts at 9 ;)
<\sh> mvo: u should work for your provider *eg*
<siretart> infinity: thats great news for our users!
* mjg59 assigns bugs to daniels
<mjg59> Bwahahahahaha
<\sh> siretart: I don't want to have libdvdcss...it would be much nicer to have it as a "legalized piece of software for linux dvd players"
<infinity> Indeed, the problem with CSS isn't the distributability of the code (copyright-wise), it's that people don't really want to get sued for doing so.
<infinity> (Or criminally prosecuted, in some jurisdictions)
<daniels> mjg59: (bastard)
<\sh> yes...the illegal status of dvdcss is the problem
<daniels> \sh: there is no 'legalized piece of software for linux dvd players', nor is there like ly to be until dvda does a complete backflip
<\sh> daniels: that's what I meant...
<Burgundavia> daniels, was there a discussion somewhere about scrolldown the side of touchpads?
<infinity> Or until we pay gods of money to the right people for every CD we press, and forbid redistribution of those compnents without licensing fees.
<pitti> launchpad-integration 0.0patch26+mvo7-0ubuntu3  - yay version numbers 
<infinity> YAY.
<infinity> s/gods/gobs/
<daniels> Burgundavia: not that I can remember
<jdub> daniels: there absolutely are legal dvd programs for linux
<Burgundavia> daniels, shall I raise it on the -devel list? (I happen to think that it is a sane default)
<jdub> daniels: there are just no FOSS ones
<\sh> infinity: what are the costs? I mean, a special ubuntu dvd player with legal decss code would be a "damn, those people did it again" PR gag...1 EUR/USD/currency fee to get the license payment back..
<infinity> \sh : Paying would set a precedent that no one wants.  It tells people that we think it's A-OK to strangle software freedom with patent licenses and crackpot anti-cirucumvention legislation in the name of profit.
<mjg59> Nnnngh.
<infinity> Also, this becomes wildly off-topic, methinks.
* mjg59 triages wildly
<\sh> infinity: yes...working on libqt3c102-mt unmet deps
<jdub> \sh: see section 7 of the GPL (sure, we could use software with another license, but keep it in mind)
<\sh> jdub: I wasn't thinking about the license right now..I was thinking: provide the linux users a "legally usable dvd player software for linux including decss" (completly different from ubuntu distribution)
<\sh> jdub: but this is really OT :) forget everything...I need coffee
<jdub> \sh: fluendo is working on proprietary dvd plugins for gstreamer
<jdub> they are going to support ubuntu
<\sh> jdub: include decryption?
<jdub> of course
<jdub> that's the whole point :)
<mjg59> *Half* of my open and non-needinfo bugs have been opened in the past week
<Burgundavia> they are only going to get worse
<mjg59> Yes
<mjg59> Yes, they are
<infinity> \sh : Argh, dude, don't upload new sources to force a retry of failed builds, just ask me to retry them.
<daniels> jdub: foss> that was kind of implied
<daniels> Burgundavia: i honestly don't think it's worth it -- we went through it before, and it's one of those things where you just have to pick some arbitrary default and accept that half of the people will love it and half of the people will think it's shit
<Burgundavia> daniels, indeed
<jsgotangco> daniels, but some models do have their touchpads with scroll indicators
<daniels> jsgotangco: we have no way to detect that
<jsgotangco> ahh
<daniels> jsgotangco: so we're going to have to pick one default that's sensible for both ones with a little ridge separationg the touchpad and the scroll area, and without
<jsgotangco> ok i won't file a bug then :)
<pef> hi
<mjg59> Oh man
<mjg59> I should really stop dealing with Bugzilla when I'm drunk
<mjg59> I write entirely sensible things that I have no recollection of writing
<Treenaks> mjg59: better than writing gibberish
<mjg59> 84 bugs dealt with
<fabbione> mjg59: i just reassinged one from acpi to linux with you in CC
<pitti> elmo: please sync postgresql-7.4 postgresql-8.0 postgresql-common from unstable; I'd also like to sync plr; it is a new upstream version, but universe, and the current plr package does not work at all with the new postgresql structure
<Mithrandir> daniels: is current breezy known not to autodetect modes (i386) correctly?  I got a question about it with today's daily.
<siretart> err, does anyone know where libxp6 did go?
<daniels> Mithrandir: *shrug*, usual disclaimer about xorg.conf, xorg.0.log, etc, applies
<daniels> siretart: it went to a better place.  we don't support xprint now.
<siretart> daniels: well, is there any possibility to get it backs for 'legacy' apps like java plugin?
<Mithrandir> daniels: I'm still in the middle of the install and this used to work on live, at least.  It only asked about modes, not about driver and stuff, so I guess ddcprobe had a bad day.
<daniels> Mithrandir: quite possibly
<siretart> daniels: javaplugin from blackdown makes firefox crashing instantly because of no libxp.so.6 available
<daniels> siretart: if so, it'll have to be an motu thing
<siretart> daniels: where are the sources?
<siretart> universe is ok
<Mithrandir> we kinda need the hooks support in dpkg, this install has been stalling for ten minutes regenerating font caches.
<mjg59> Bwahahahaha.
* mjg59 closes bugs that are due to binary drivers
<Keybuk> Mithrandir: I guess you missed the discussion about that at debconf?
<daniels> siretart: http://xorg.freedesktop.org, look at the modular developers' guide, you want proto/Print and lib/Xp
<Mithrandir> Keybuk: indeed I missed it.  Anything useful came out of it?
<mvo> daniels: do you happen to know if the r300_demo application (from r300.sf.net) should run on a current breezy kernel/Xorg?
<siretart> daniels: I assume there are no debian packages available yet and I have to look at them myself, right?
<mjg59> Ok, down to 58 bugs I'm supposed to be doing something about
<Keybuk> a couple of different ways of doing that kind of thing were discussed
<Keybuk> and I rather liked the one iwj/wiggy came up with in a taxi but never wrote down
<Keybuk> packages can ship a hook script (e.g. /var/lib/dpkg/info/fontconfig.hook) and specify when that hook gets run (files going into /usr/share/fonts)
<pitti> Hi seb128 
<mvo> good morning seb128 
<seb128> hey pitti mvo
<jdub> 5000+ people on ubuntu-announce these days :-)
* seb128 wants to sleep
<daniels> mvo: no, and it won't
<pitti> seb128: hm? you just got up, didn't you?
<mvo> daniels: is it a matter of updateing my dri radeon driver? 
<pitti> seb128: time for another funny day full of bug reports^W^Wfunny development
<seb128> pitti: yeah, but I went to bed at 5am, damn .la files
<jdub> bum, this machine has suse on it
<Burgundavia> jdub, where are you>
<jdub> sitting on my couch
<daniels> mvo: you'd need to update the drm in the kernel and the ddx in xorg.  the ddx stuff won't happen because xorg is now frozen.  no r300 for breezy, sorry.
<Burgundavia> daniels, shucks
<jdub> booting a fairly loud openpower 710 p series machine
<jdub> which is going to have an ubuntu enema very soon
<mjg59> daniels: Got a report of an identical X300 failure on an x86 HP
<seb128> pitti: after uploading cairo 1.0 at midnight I notice than the Debian maintainer turn the glitz backend of because it's experimental and upstream recommend it for stability reason ... the stuff is that ~30 .la file mention glitz.la and I wanted to rebuild pango/gtk and fix the gnome standard libs before going to bed ... oh joy
<mvo> daniels: ok, thanks. the stupid ati binary driver hangs for me when I try to use it and I was kind of hoping for free 3d :) breezy+1 then
<daniels> mjg59: sounds about right.  i think I know how to ward off the problem, being to idle the engine before we set up for solidfillrect calls.  nasty as hell though.
<pitti> seb128: sounds like fun
<mjg59> mvo: Of course, with the modular tree it's easy enough for someone to provide external packages
<daniels> mjg59: (and slow, but beats hung)
<seb128> pitti: yeah, now I really hate .la files :)
<daniels> mvo: indeed.  sorry.
<mjg59> daniels: Well, turning off Screen2Screen is *slow*
<daniels> mjg59: yes, but that's breezy+1
<pitti> seb128: they are for libtool, right? what do they do exactly?
<mjg59> daniels: Mm? We're not modular for Breezy?
<Mithrandir> pitti: I think they're there to annoy seb128, mostly.
<daniels> mjg59: right.  so idling the engine is cheaper than disabling it altogether, but not ideal.
<daniels> mjg59: no.
<mjg59> daniels: When in the past 12 hours did that change?
<pirroH> strange problem with breezy here, suddenly fs has become read only (simple ext3)
<daniels> mjg59: shortly before I went to bed last night
<seb128> pitti: dunno what they do exactly out of creating issues, other distro just trash them 
<mjg59> daniels: Right. Do we get the BIOS crack shit for i855?
<pitti> seb128: maybe we should change cdbs to not ship la files then?
<Mithrandir> pitti: eh, .la files are spawns of libtool, not cdbs
<seb128> or a dh_something :)
<daniels> mjg59: don't know, I've been told that xorg is now in polar freeze.  so I guess not, but I'll try like hell.
<seb128> Mithrandir: libtool is not used to make packages :p
<mjg59> daniels: Ok. Thanks.
<seb128> pitti: Debian policy is to ship them, but yeah
<infinity> policy says nothing about .la files.
<infinity> Unless you meant "common Debian practice".
<pitti> Mithrandir: I know, but cdbs would be a pretty convenient place to kill them off for a large number of packages
<infinity> And I say the best way to make that practice uncommon is to just stop shippin ghtme.
<daniels> dh_dielibtooldie
<daniels> i've stopped shipping them for everything in x
* seb128 gets coffee
<siretart> daniels: Xp was no problem in finding, but I fail to find proto/Print. Where is it? is it really necessary? a first build seemed to go fine
<Mithrandir> uhm, xresprobe wasn't installed.  that might be the reason
<lathiat> yes i had that problem
<lathiat> because its not in the seed
* pitti makes a mental note to keep his feet away from the power plug switch
<lathiat> ^ maybe
<lathiat> pitti: heh
<mvo> hehe
<Mithrandir> lathiat: yeah, it should probably be seeded
<lathiat> probably? :)
<Mithrandir> :-P
<Mithrandir> pitti: do you know the reason for xresprobe not being seeded?
<Mithrandir> that is, not in the desktop seed
<pitti> Mithrandir: no idea; nobody added it?
<fabbione> Mithrandir: it's an xorg-server Depends:
<fabbione> no need to seed it
<Mithrandir> fabbione: no, it's a recommends
<fabbione> it's pulled in automatically
<pitti>  xresprobe |   0.4.18-1 | http://archive.ubuntu.com breezy/main Packages
<pitti> Mithrandir: it's in main
<lathiat> its in the ubuntu-live seed
<lathiat> but not desktop
<Mithrandir> pitti: it's ship and live, but not desktop
<fabbione> Mithrandir: ah ship will push it to CD automatically... why does it need to be in desktop?
<Mithrandir> fabbione: because it's not installed at the moment, which means xserver-xorg's postinst won't have it -> question asked
<fabbione> Mithrandir: installed where? i just did a breezy install 
<Mithrandir> fabbione: by a default desktop install
<fabbione> i did that....
<fabbione> but it was via network...
<edd> seb128: ping?
<seb128> edd: pong
<edd> seb128: hey. my breezy font prefs are going mad right now. is this a known problem or shall i file bug with more data? the main issue is that it disrespects my hinting settings
<seb128> GTK 2.8.1 is bugged, 2.8.2 should fix it
<seb128> what version do you have ?
<fabbione> Mithrandir: are you sure xresprobe was not installed at all?
<edd> seb128: 2.8.1-1
<seb128> update
<seb128> :)
<Mithrandir> fabbione: yes.
<edd> seb128: thanks. btw, firefox still disrespects the hinting prefs before this was a problem, but i guess that's not your issue...
<fabbione> Mithrandir: is xresprobe on the cd?
<seb128> edd: nop, I use epiphany ... :)
<edd> seb128: yeah, i went back to ephy for this reason (wow, and it's way faster!)
<fabbione> Mithrandir: if so it could be base-config that lost the bits to install xresprobe
<Mithrandir> fabbione: nope, it's not there.
<carlos> pitti, hi, morning
<carlos> pitti, around?
<pitti> Hey carlos, sure :-)
<pitti> with the birds
<carlos> pitti, http://mawson.ubuntu.com/~carlos/
<Mithrandir> so, why is the package not on the cd even when it's seeded as ship?
<pitti> WOW
<carlos> pitti, new and fresh language packs, could you test them and tell me the error you find?
<pitti> Mithrandir: could be cd overflow
<pitti> Mithrandir: during the hoary release, we had a similar problem
<Mithrandir> pitti: checking for that already.
<pitti> Mithrandir: a few packages flowed to the 2nd cd and broke X
<Mithrandir> pitti: yeah, I think so; du -sh /media/cdrom gives me 641MB
<pitti> carlos: sure, doing that now. Thanks!
<carlos> pitti, thank you
<pitti> Mithrandir: hm, 650 MB for the whole image is the hard limit
<pitti> Mithrandir: can you rather look at the raw iso image?
<carlos> I think there are still some errors related with '\n', I'm debugging that already
<Mithrandir> -rw-rw-r--   1 tfheen  tfheen  645M 2005-08-24 09:35 breezy-install-i386.iso
<Mithrandir> pitti: does anybody notice this or should I nag somebody?  (FSOS)
<pitti> Mithrandir: Kamion can check for this, but I don't think the cronjob pushes a notification
<pitti> Mithrandir: that size should be fine, though
<\sh> seb128: I have some strange issues with switching desktops when popups are popping up 
<Mithrandir> pitti: well, Colin is on vacation.
<Keybuk> \sh: metacity crashes?
<fabbione> Mithrandir: mdz is the guy
<\sh> Keybuk: no..just switching from actual desktop to another one and back to actual one
<Keybuk> oh, I've had a few metacity crashes when doing things like switching desktops
<\sh> Keybuk: and only automatically when a popup is showing up
<Keybuk> WHAT IS THAT NOISE )!()"$(!$"
<Keybuk> I'm going to go on a campaign against any app that makes a beep or sound of any description without a visual clue alongside it
<\sh> infinity: *grmpf* sorry...I just had my head somewhere else :( 
<Mithrandir> Keybuk: your network connection jumping up and down?  Similar to the pcmcia insert/eject sound?
<Keybuk> it's a very quiet "bidong" kind of noise
<HiddenWolf> keybuk, start with ripping the system beeps out of email clients then.
<Keybuk> don't have one running
<Keybuk> Mithrandir: could you log in to jabber
<\sh> hmm...my jabber roster grew since the day before last
<Keybuk> FOUND IT
<Keybuk> Mithrandir: thanks!
<Mithrandir> Keybuk: np
<Keybuk> it's a beep to tell you someone's logged in to jabber
<Mithrandir> how annoying.
<Mithrandir> use guifications.
<Keybuk> gossip has guifications?
<Mithrandir> nah, gaim has guifications.
<Keybuk> but gaim sucks
<Mithrandir> gossip should be able to get them for breezy+1, if grim manages to finish guifications3
<HiddenWolf> Keybuk, don't all IM clients suck?
<Mithrandir> since that'll be a more generic notification framework.
<Keybuk> I like gossip, it's almost entirely bling free
<Keybuk> it gives you a window with a list of names in, and a window to type in
<Keybuk> which is about all I want
<lathiat> i like gajim
<lathiat> not really used gossip tho
<lathiat> but sucks less than gaim
<Keybuk> Robot101 and robtaylor__  need to finish their dbus rewrite
<lathiat> theyre writing one?
<lathiat> heh i was playing writin ga new dbus client library last night
<lathiat> thats like, thread safe and not stupid
<HiddenWolf> The only reason I stick to gaim is that it connects to just about any protocol. :)
<Keybuk> dbus rewrite of gaim
<lathiat> ah
<fabbione> elmo: something is badly wrong with archive...
<fabbione> elmo: hoary seems to be uninstallable via network..
<HiddenWolf> fabbione, hoary?
<\sh> Keybuk: try out gajim ,-)
<jdub> hrm
<Mithrandir> fabbione: elmo won't be around for six hours or so
<Keybuk> \sh: I saw screenshots, I didn't like
<jdub> anyone know how to do the equivalent of stop-a with openfirmware?
<\sh> Keybuk: it supports now real TLS handshakes, gpg-agents, and dns svr records 
<\sh> and it's python
<Keybuk> \sh: but it looks like bling
<\sh> wth is bling?
<fabbione> HiddenWolf: yes.. hoary.. i got a bunch of 404 and a set of security updates on hold...
<Keybuk> bling is bad
<fabbione> Mithrandir: i know, but he reads the backlog..
<lathiat> bling is good!
<\sh> Keybuk: actually...it's just like PSI for KDE ,-)
<Keybuk> no, bling is _really_ bad
<fabbione> now if only this damn FB didn't kill the scrollback, i could have paste more info
<lathiat> no bad bling is bad. :)
<Keybuk> bling is always bad
<lathiat> never
<Keybuk> bling is unnecessary
<\sh> translate bling ,-)
<seb128> \sh: why do you fork gajim to use debhelper when Debian has the same version using cdbs ?
<Keybuk> \sh: did you ever watch the A-Team?
<\sh> seb128: asterix didn't have cdbs for 0.7.1...and I was faster with 0.8...but I will merge back with his style..but offer more features then debian...it's all discussed in the background :)
<HiddenWolf> \sh, bling: lots of unneeded glitter/glamour -> bells and whistles
<HiddenWolf> \sh, IE, over the top.
<\sh> Keybuk: I only know mr. t and his gold chains ,-)
<\sh> Keybuk: and a lot of "bullets" in a-team
<Keybuk> \sh: the exact thing I was looking for -- Mr T is bling
<seb128> \sh: hum, k
<Keybuk> lots of gold chains, and "ya whuh fool"
<Keybuk> desktop bling is a UI with lots of gold chains, and rings and stuff
<\sh> seb128: asterix packages gajim for debian ( and he had a sponsor) and he is dev for this project
<seb128> \sh: k, and he used cdbs :)
<Keybuk> but did he inhale?
<\sh> seb128: this is build-dep from 0.7.1: Build-Depends: debmake, python2.4-dev, libgtk2.0-dev, python-gtk2-dev, libgtkspell-dev, gettext, libxss-dev
<\sh> i don't see any cdbs in there :)
<seb128> \sh: "   * use cdbs" that's 0.8.0
<seb128> :p
<\sh> seb128: 0.8.0 came too late...my package was already in our archives
<seb128> k
<fabbione> hmm 
<\sh> seb128: i saw it yesterday the first time in debian...and I mailed him directly
<fabbione> did we get a hoary-update for openoffice?
<fabbione> or a security update?
<fabbione> Package: myspell-en-gb
<fabbione> Version: 20030813-3ubuntu1
<fabbione> there is no such version ....
<fabbione> that's from the Packages.gz (hoary/main)
* fabbione rechecks...
<seb128> jdub: can we move Add/Remove Programs out of the application menu?
<jdub> seb128: we just moved it there :)
<seb128> jdub: it's just ugly with non-short locales ("Add" is short in english by example so you don't notice it, but with fr locales by example the menu twice larger)
<fabbione> yeps..
<fabbione> the file disappeared
<seb128> yeah, and that's ugly ugly
<jdub> seb128: not too concerned if you move it to the admin menu
<jdub> seb128: i'm not convinced the current incarnation is really ready for mass public exposure
<fabbione> elmo: myspell-en-gb_20030813-3ubuntu1_all.deb file disappeared from http://archive.ubuntu.com/ubuntu/pool/main/o/openoffice.org-dictionaries/
<fabbione> elmo: the Package file reports it correctly, but the file isn't there anymore.
<seb128> jdub: good. I'm not convinced too since the package discriptions are not translated ...
<seb128> descriptions
<jdub> yeah
<seb128> you have translated titles and english description which is ... weird ...
<seb128> mvo: please move it to admin :)
<mvo> seb128: System/Admin then?
<seb128> right
<seb128> like synaptic
<mvo> seb128: I'll just revert my gnome-menus change then
<niran> is there any work being done on getting debian package descriptions translated?
<sabdfl> niran: ask about that in #launchpad
<sabdfl> specifically, ask carlos
<niran> sabdfl, ok, thanks
<jsgotangco> hey sabdfl 
<sabdfl> hiya jsgotangco
<carlos> niran, https://launchpad.net/products/ddtp-ubuntu/
<niran> carlos, oh, that's pretty nifty
<jsgotangco> hi ogra 
<sabdfl> niran: check the templates on the left of the page
<ogra> hello wonderful world of isdn :(
<seb128> carlos: the template for main gives " Sorry, a system error occurred"
<Treenaks> ogra: you know "ISDN" means "It Still Does Nothing", right?
<fabbione> hey sabdfl 
<ogra> Treenaks, at least it works ... even if it eats my salary within one hour :/
<\sh> strike...\sh c++ fixing hour
<carlos> seb128, I see...
<carlos> hmmm
<seb128> carlos: morning BTW :)
<carlos> seb128, morning
<Keybuk> \sh: aptitude purge g++ ... fixed!
<jdub> anyone familiar with linux on ibm pseries machines?
<\sh> Keybuk: yes ;)
<fabbione> jdub: sivang
<jdub> ahr
<seb128> jdub: did you get this djvulibre sync?
<jdub> seb128: i requested it
<seb128> k
<jdub> fabbione: do you know if kamion has used one before?
<fabbione> no idea.. i don't think so
<fabbione> if you are talking about LPAR, then no
<siretart> daniels: I packaged now libxp6, I took the skeleton if libxrandr
<xerox> Hi.
<xerox> Is an uninstallable package worth filing a bug report?
<siretart> daniels: I am a bit confused about the part proto/Print you told me earlier. nevertheless, the java plugin works with my libxp6 package
<siretart> daniels: if you don't object, I'd upload it to universe now
<jdub> hmm
<jdub> so the machine doesn't seem to be recognising the OS on the CD
<hawk_78> Hi!
<fabbione> jdub: yes, it's some kind of issue with the bootloader.
<fabbione> jdub: but Kamion has no experience on it
<hawk_78> Anyone knows where doko is? I need to talk to him.
<jdub> fabbione: bum. red hat and suse work on it. gar! ;-)
* jdub doesn't have any ppc CDs for those tho
<jdub> and the suse install on here seems terribly b0rk
<fabbione> jdub: i think Kamion said that he was going to look at it, but they build the CD in a completely different way
<fabbione> i am not sure he managed to look at it before marriage
<jdub> ouch
<jdub> hmm, well i have access to one now
<fabbione> jdub: patches are always welcome :)
<jdub> 8)
<fabbione> jdub: you should check the differences between the CD's
<fabbione> that will be a good point to start from
<jdub> i'll have to find some RH or SuSE CDs
<fabbione> and see how yaboot is installed/configured
* hawk_78 is waiting
* hawk_78 is waiting for doko
<fabbione> mjg59: how can i disable usplash at boot? i don't need to kill it 100%, just disable it for one boot..
<fabbione> mjg59: it's a good idea if you can test a hoary perfectly clean install to breezy upgrade.. usplash has been spitting out a lot of errors that i can't even grab because they scroll behind and away as soon as X start...
<mjg59> fabbione: New upload should sort most of that
<fabbione> mjg59: ok
<mjg59> If you remove the splash parameter, it won't run
<mjg59> But 0.1-2 will sitll load vga16fb
<Mithrandir> mjg59: what's an easy way to trace wtf vbetool is doing?
<mjg59> Mithrandir: Hook into the interrupt execution handler and print out what it's doing
* mjg59 has to go and meet someone
<mjg59> BBL
<Mithrandir> ok, thx
<fabbione> mjg59: ok thanks...
<fabbione> now... there is an alsa problem upgrading from hoary to breezy that can be seen only once at the first boot into breezy...
* fabbione sighs
<Diziet> fab: Shame you can't strace init, really :-).
<\sh> g'day JaneW 
<JaneW> hi \sh
<Keybuk> Diziet: you can ;)
<Keybuk> replace /sbin/init with a shell-script
<Diziet> Yes, but then init won't have pid 1 and it will do something stupid.
<Keybuk> exec strace init
<Keybuk> well, yes, that doesn't quite work
<Keybuk> what you could do is fork in the script and wait for the parent to change to init,and then strace it
<Keybuk> with the parent doing exec init to keep init as pid=1
<Diziet> The kernel stops you ptraceing init.
<Keybuk> you could comment that code out ;)
<Diziet> :-).  You could do it with subterfugue perhaps.
<lathiat> pff comment
<lathiat> binary patch
<Keybuk> though quite a bit happens before init these days
* Keybuk is trying to work out exactly when initramfs happens
<Keybuk> Diziet: do you know much about it?
<Diziet> Not much.  AIUI it's very similar to initrd.
<Keybuk> hmm
<Keybuk> there's a bunch of recent bugs that devices just aren't appearing in /dev
<jdub> it's just a simpler initrd, basically
<Keybuk> they seem to co-incide exactly with the move to initramfs
<Diziet> What kind of devices not appearing in /dev ?  We're not using devfs so why wouldn't they always be there ?
<Keybuk> we use udev
<Diziet> Augh.
<Keybuk> things like input/mice, rtc, hdd, etc.
<Keybuk> those are all created by udevstart, which is being done in initramfs
<Diziet> What, before / is mounted ?
<Keybuk> I was wondering whether initramfs is started a bit earlier in the kernel ... so there's a chance it's not fully up
<Keybuk> yeah
<Keybuk> crazy, eh? :p
<Diziet> So how could it create the devices on / ?
<Keybuk> /dev is a ram disk
<Keybuk> the mount just gets moved over
<Keybuk> tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
<jdub> Keybuk: dunno about concretely earlier, but certainly faster
<Diziet> ramdisk> Cripes, so it is.
<Diziet> And yes, initramfs starts very early I think.  You should run the udev setup after most of the probey stuff.
<Diziet> It's all modularised now, so you should expect to have to load relevant modules.
<Keybuk> yeah, it's all a bit odd
<Diziet> I remember fighting with this stuff on liberator.  There's some tool whose name I've forgotten which looks through your lspci and looks them up to see what modules to load.
<Keybuk> hotplug does something like that
<Diziet> It might have been hotplug.
<Keybuk> though iterates /sys
<Keybuk> rather than just using lspci
<Diziet> /sys, lspci> all the same really.
<Keybuk> this is all changing anyway, the kernel's actually outputting a useful $MODALIAS variable now
<Keybuk> so "load relevant module" just turns into "modprobe $MODALIAS"
<Keybuk> rather than needing things like grepmap or the hotplug shell to work it out
<Diziet> Perhaps the modules haven't finished setting up by the time the udev setup runs.
<Diziet> I think that the forensics I'm doing here are too hard.  I'm going to redo my hoary -> breezy upgrade with the whole thing under strace.
<Keybuk> yeah, that's the kind of thing I'm thinking about
<Keybuk> I suspect we're racing the kernel :-/
<Keybuk> the fact there's some "sleep" in here worries me already
<Diziet> Except strace is too buggy.
<Mithrandir> mjg59: dude, bambam is broken on x86 with lrmi as well
<Mithrandir> mjg59: or actually, x86emu works, lrmi is b0rked
<dholbach> hi
<mbreit> hi dholbach
<dholbach> hi moritz
<dholbach> hi seb128 
<seb128> hey dholbach
<seb128> k, totem plugin crashed my box
<seb128> after waiting 5 min to get a ps I rebooted
<dholbach> ouch
<mbreit> btw: here has the clearlooks-olive theme gone to?
<dholbach> elmo: do you happen to know what happened about slomo's (sebastian droege's) account?
<mbreit> seb128: why are all the /usr/share/themes/Clearlooks-* files missing in latest gtk2-engines-clearlooks?
<seb128> $ ls /usr/share/themes/Clearlooks/
<seb128> gtk-2.0  index.theme  metacity-1
<seb128> they are not here
<j^> seb128 not Clearlooks/ but /Clearlooks-*
<mbreit> i mean /usr/share/themes/Clearlooks-Olive/* for example
<seb128> there is no Clearlooks-*
<mbreit> seb128: there was in gtk2-engines 2.6.5-0ubuntu1..
<seb128> upstream drop them when they moved the it to gnome-themes
<seb128> mbreit: no way, 2.6.5 is the gtk-engine version
<mbreit> seb128: dpkg -L gtk2-engines-clearlooks with gtk2-engines-clearlooks 2.6.5-0ubuntu1 installed shows me all the files
<seb128> that's the current version
<seb128> what is your issue if all the files are here with the current version?
<mbreit> lol... okay, i just saw it... but an amd64 (same version) they are missing
<seb128> /usr/share/themes/Clearlooks/gtk-2.0/gtkrc
<seb128> /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so
<seb128> that's what it's supposed to ship
<seb128> and that's all
<seb128> what 2.6.5 deb has other files?
<mbreit> on x86 it ships  /usr/share/themes/Clearlooks-Olive/gtk-2.0/gtkrc as well (as an example)
<seb128> no
<seb128> $ dpkg -c gtk2-engines-clearlooks_1%3a2.6.5-0ubuntu1_i386.deb | grep Olive
<seb128> $
<mbreit> ahh... okay, i have gtk2-engines-clearlooks 0.6.2-1 from the clearlooks-package installed on x86... my mistake
<seb128> yeah, that was the pre-GNOME version
<mbreit> but anyway... the update to 2.6.5 broke my gnome-desktop...
<seb128> they dropped the variant when they moved it to the new place
<sedak> seb128, are you in charge of anjuta for ubuntu ?
<seb128> sedak: no, it's an universe stuff, ask #ubuntu-motu
<sedak> i see that you've been assigned to one of its bug ...
<seb128> mbreit: upstream decision
<sedak> ok
<seb128> sedak: the one with pango?
<sedak> yes
<sedak> and there is a new upstream version that correct the problem
<mbreit> seb128: but this is a serious bug when upgrading... i found out that switching to another theme solved all my problems, but will the avarage user understand that as well?
<seb128> the bug is assigned to me because the guy bugged on pango
<sedak> ah ok
<seb128> mbreit: average users don't use unstable version
<seb128> mbreit: and the human theme has no issue
<sedak> actually, it seems it was anjuta the probleme because the new version work
<sedak> i'll ask the motus
<seb128> thanks
<mbreit> seb128: i know, but if a user select clearlooks-olive as a theme and then upgrade to breezy (when it's released)....?
<seb128> mbreit: does hoary ship this one?
<mbreit> clearlooks-olive as a theme? yes, i think so
<seb128> he's screwed
<seb128> nothing I can do about it
<seb128> upstream dropped it
<mbreit> hmm... not good... it really broke everything here...
<Diziet> Is someone already looking into the weird splash screen effect ?
<Diziet> (That was discussed here yesterday.)
<seb128> what sort of effect?
<mbreit> seb128: every second gtk-program segfaults..
<seb128> mbreit: changing your theme is not that a big deal
<mbreit> seb128: nautilus won't run..
<seb128> mbreit: what version of libgtk2.0 do you have?
<seb128> libgtk2.0-0
<Diziet> I'm not sure exactly what it's supposed to look like but I'm sure this is wrong.  I get a splash-screen like affair with a strange blank rectangle in part of the bottom half of the screen.
<mbreit> seb128: 2.8.2-1
<seb128> mbreit: get a backtrace for upstream, your issue is not known
<Diziet> Conversation yesterday suggests that it's supposed to be for scrolling console output.
<mbreit> seb128: as i said, changing the theme is not a big deal, but the user has to know that changing the theme helps..
<seb128> mbreit: you didn't say it crash
<seb128> mbreit: it's just supposed to change the look and that's what it does for other people
<mbreit> seb128: hmm... okay... hopefully it will do it even on amd64 after release ;)
<seb128> do you have a backtrace of these crash?
<mbreit> no, i have not... i will try to reproduce it somehow..
<HiddenWolf> gnagnagna: 'Mogelijk toch overname Antonveneta door ABN Amro'
<HiddenWolf> whoops
<HiddenWolf> sorry
<Treenaks> HiddenWolf: ELANGUAGE
<mbreit> seb128: sorry, i can't reproduce it... with another user on xnest it works... just uses the gtk-default-theme...
<HiddenWolf> Treenaks, shush
<mbreit> seb128: is there any chance that Clearlooks-Olive comes back? or should i prepare a new package for universe? (i would really like to have that theme in breezy...)
<Mithrandir> mjg59: hmm, what about the case where all available versions of vbetool breaks?
<Mithrandir> mjg59: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QL [Radeon 8500 LE]  is the card, arch is x86
<daniels> Mithrandir: then your BIOS sucks
<Mithrandir> daniels: as in motherboard bios?
<Mithrandir> or video bios?
<daniels> Mithrandir: video BIOS
<Mithrandir> I'll find some random other card, then
<seb128> mbreit: do a new package probably
<mbreit> seb128: if there are more people missing that theme... i don't want to break FF just for me ;)
<Mez> mdz: why did you change a bug assigned to me over to Riddell? 
<mvo> ping Mithrandir 
<Mithrandir> yes?
<mvo> Mithrandir: I just read your install report
<mvo> is the language-support-en package on the cd you used?
<pitti> mvo: it's in ship
<lathiat> hrm
<lathiat> somethings happene dto xine/totem-xine
<lathiat> when fullscreen you get lines adn stuff appearign through things
<Mithrandir> mvo: I'm not sure, since that machine is busy trying to boot the live cd atm
<mvo> Mithrandir: did you do anything after the intall with apt (i.e. apt-get update)? or is it still in the same state that it was when it hanged
<Mithrandir> mvo: I tried to do an apt-get update, which might have been what solved it.
<Mithrandir> mvo: I can retry the install, if you'd like.
<mvo> pitti: yes, it should be on the cd, but aptitude really shouldn't prompt for something untrusted because it's available from the trusted cd
<pitti> right
<mvo> Mithrandir: apt-get update probably fixed it. is there something "special" about your machine? two nice interfaces for example?
<mvo> Mithrandir: I have seen this problem before, it happend when there was no network in stage2 and base-config (or apt-setup) tried to do a apt-get update
<Mithrandir> mvo: no, single network interface on that machine.
<mvo> Mithrandir: and working network in stage2?
<Mithrandir> mvo: given that apt-get update worked, yes
<pitti> carlos: you have firewire, right?
<mvo> Mithrandir: right, thanks. I'll  do a testinstall now too to see if I can reproduce it
<carlos> pitti, yeah, I have a pending email about that from you...
<pitti> carlos: can you please /msg me "ls -l /sys/bus/"?
<carlos> I'm not using that computer atm
<carlos> will do it after lunch (I'm in a meeting atm)
<pitti> carlos: oh, ok
<pitti> carlos: nevermind, I got it already
<carlos> pitti, ok
<jordi> heh, according to the Cyborg Generator,..
<jordi> S.A.B.D.F.L.: Synthetic Artificial Battle and Dangerous Fighting Lifeform
<pitti> ouch
<fabbione> ehhehe hi jordi
<jordi> carlos: dude, when does the status page update?
<jordi> ffs
<jordi> I've been waiting for an update all morning
<jordi> (I mean GNOME's)
<ajmitch> hey jordi 
<carlos> jordi, three times/day
<jordi> hi andrew
<jordi> carlos: dude
<jordi> for catalan that should be 2 times every hour
<carlos> jordi, I'm working on near realtime updates...
<carlos> jordi, but still need days with 48hours :-)
<jordi> carlos: free time is overrated
<jordi> just DO IT
<Mithrandir> mjg59: when vbetool fails _the same way_ in 32 bit and 64 bit mode, (using the x86emu mode in the 64 bit case), is it then ok?
<pvanhoof> lynx-qt depends on libaiksaurus0c102
<pvanhoof> however
<pvanhoof> libaiksaurus0 replaces it
<pvanhoof> makes it impossible to sanely install lyx-qt (or any other lyx related package)
<pvanhoof> same for
<pvanhoof> libqt3c102-mt
<pvanhoof> and
<pvanhoof> libqt3-mt
<\sh> pvanhoof: this is universe..
<\sh> pvanhoof: and yes we know about it
<pvanhoof> ok. is there a workaround?
<\sh> pvanhoof: yes...fix it, provide a debdiff, and put it on wiki.ubuntu.com/UniverseUnmetDeps
<pvanhoof> :p
<\sh> (with your Name)
<\sh> pvanhoof: or wait until we fix it...
<siretart> elmo: around?
<\sh> (what we're doing in the meantime)
<pvanhoof> getting the source :)
<pvanhoof> how do I make a debdiff and in what file are the dependencies written?
<siretart> pvanhoof: there is no lynx-qt
<pvanhoof> lyx-qt
<siretart> pvanhoof: I already fixed it for me, but bob2 promised me to upload a fixed version to unstable
<pvanhoof> actually, I just wanted to install lyx
<siretart> pvanhoof: I'd rather sync his version
<siretart> pvanhoof: lyx is b0rken in breezy. we need 1.3.6
<pvanhoof> ok
<pvanhoof> then I'll just wait for you guys :)
<pvanhoof> ok then :). is there an alternative for \pagebreak in latex? I want a block of content to never split (when a page breaks) :)
<pvanhoof> (which is why I wanted to install lyx)
<pvanhoof> :p
<mjg59> Mithrandir: Probably, though we've managed to get it to behave differently in LRMI and x86emu modes
<pitti> pvanhoof: why not enclose it in a quote or figure block?
<Mithrandir> mjg59: well, it refuses to work on my radeon 7000, it crashes the same way on my 8500.
<pitti> pvanhoof: btw, that's #ubuntu
<pvanhoof> a quote block doesn't break?
<pvanhoof> pitti, yah yah :) but you guys broke lyx! :)
<pitti> pvanhoof: last time I had that problem that worked
<pitti> pvanhoof: we didn't -- lyx is universe
<\sh> pvanhoof: please join -motu if you have some problems with the universe repository...-devel is not the right channel
<lathiat> seb128: ping
<seb128> lathiat: pong
<doko> elmo, mdz: please promote mdbtools, bsh and javacc to main, reviewed by pitti. current OOo2 build fails
<lathiat> seb128: are you aware of this constant metacity crashing?
<pitti> lathiat: it doesn?
<seb128> no
<lathiat> hrm ok
<seb128> no bug, no crash here
<pitti> WMF too
<seb128> no bug, no fix
<slomo> lamont: please remove xawtv and bb from dep-wait
<lathiat> anyone using gajim?
<lathiat> it seems to trigger it most often
<lathiat> when it pops its dialogs ups
<pitti> lathiat: gaim, you mean? I use it
<lathiat> pitti: no, gajim
<lathiat> with a j
<lathiat> nm 
<lathiat> i'll file a bug when it happens next
<pitti> uh, so that wasn't a typo, sorry
<seb128> pitti: a new pygtk jabber stuff
<dholbach> pvanhoof: texdoctk might now
<dholbach> pvanhoof: texdoctk might know
<pitti> dholbach: Hi! btw, I gave him some hints in #ubuntu
<dholbach> pitti: hey martin :)
<mvo> hey Mitario 
<Mitario> hi mvo 
<sivang> seb128: I'm gonna give gnomemeeting last try today, but I have not yet succeded, do you like to try yourself?
<seb128> I can do it if you want
<sivang> seb128: I'd like to try another time , I will let you know around evening if I cannot ok?
<sivang> seb128: (I had problem with the menu structer not being of GTK_MENU, so I am going to try a cast)
<seb128> sivang: k
<sivang> seb128: I'm curious, have you finished with firefox already, if so was it alot of work?
<seb128> I'm working on it
<sivang> seb128: is it much trouble? (firefox's code always sounds scary :) )
<seb128> it doesn't work for the moment no
<Diziet> mjg59: Did you see my messages ^ up there about usplash ?
<Mithrandir> mjg59: so, just plain vbetool vbestate save > /tmp/vbestate ; vbetool post ; vbetool vbestate restore < /tmp/vbestate seems not to do the completely right thing even on my x40.  It's supposed to leave the display in the mode it was in before running the command?
<sivang> seb128: I see, well I'll not bug you and let you continue ...
<lathiat> ok,free tip of the day: don't run gdb on metacity inside the X session metacity is running on
<seb128> lathiat: sure, you lock your wm which is quite useful to use your desktop :p
<sivang> lathiat: lol, that's today's 50c :)
<Diziet> Woah, heavy hail here suddenly.
<sivang> lathiat: maybe you can run gdb from one of the text tty, and CTRL+ALT+F(n) to switch 
<lathiat> and even after killing gdb/metacity, it still wouldnt go :)
<lathiat> sivang: yeh thats what i'll try now ;p
<lathiat> ok so who here has jabber/google talk thats not on my list
<lathiat> i need to add someoen to trigger this popup box which crashes it reliably
<sivang> lathiat: I have jabber, just not google's
<lathiat> i said or
<lathiat> :)
<lathiat> i i said /
<lathiat> oops
<lathiat> either is fine im on both
<Diziet> And lightning too.
<sivang> lathiat: what's wrong with metacity that yu need to gdb it?
<lathiat> sivang: it crashes 
<lathiat> whenever gajim pops up one of its dialogs
<j^> the "battery at -1 minutes" dialog crashes it too
<lathiat> and of course
<lathiat> it didnt do it then
<mjg59> Mithrandir: Ideally, but once X has run that doesn't seem to necessarily be the case
<mjg59> And you may need to hit return
<mjg59> Diziet: Uhm. Sorry, no - I haven't got all of the scrollback. What was the issue?
<sivang> lathiat: ah, joy
<Mithrandir> mjg59: I get a prompt back and things seems to work, but my screen is full of green and blue vertical bars.  They go away if I C-l or reset or something like that.  Is that good, then?
<lathiat> 9
<Diziet> Well, basically, I don't know what it's supposed to look like but it definitely looks weird.  There's a sort of cream-coloured logo screen with a strange blank paler rectangle in the bottom half.
<mjg59> Mithrandir: Uh. Not something I've seen.
<mjg59> Diziet: What hardware is this?
<Diziet> The blank rectangle looks like it's supposed to have something in it.
<mjg59> Yes
<Mithrandir> mjg59: same thing on my x40 and this other gf5600 fx
<mjg59> The rectangle is for the text from the init scripts that will appear once /dev migration works
<mjg59> Mithrandir: Is this the vbetool in the archive or the bambam one?
<Mithrandir> mjg59: archive.
<mjg59> Oh. Ok.
<Mithrandir> I can try bambam if you think that works better.
<Diziet> Desktop with an Intel motherboard and onboard video.
<mjg59> Diziet: Ok. That sounds correct.
<mjg59> The picture will look more attractive soon, and the box will contain stuff soon.
<Diziet> Well, it doesn't _look_ correct.  It looks like something malfunctioned.
<Diziet> Oh, right, if you already know the box is empty and are going to fill it then that's fine :-).
<Diziet> I'll stop nagging.
<Diziet> But in the meantime we could put `this space will be filled RSN' in it :-).
<mjg59> I'm planning on chasing Jeff over it
<Diziet> OK.
<Mithrandir> mjg59: http://err.no/pictures/2005-08-25/medium/DSC01192.JPG is a picture.
<mjg59> Once that works, it's a trivial patch to lsb-init to make stuff start appearing
<mjg59> Mithrandir: Ooh, cool
<jbailey> mjg59: I have the migration stuff tested here.
<mjg59> Mithrandir: Very odd
<mjg59> jbailey: Ooh, rock
<mjg59> jbailey: When can you upload? :)
<Diziet> mith: Wow, it doesn't do that to me :-).
<jbailey> mjg59: Gimme an hour for another round of testing?
<mjg59> jbailey: Sure, no problem
<Mithrandir> mjg59: X has ran, yes.
<mjg59> Mithrandir: Ah. Try saving the state before X has run
<mjg59> And then always use that state file
<Mithrandir> mjg59: hmm, that's going to be hard, this is the live cd, but I'll try.
<mjg59> Mithrandir: Oh, right. Wurgh.
<Thunder000> hello. For some reason Breezy didn't detect my laptop DVDRW during installation.
<Thunder000> My laptop is Acer TravelMate 4152LMi
<mjg59> Thunder000: Please file a bug
<mjg59> If you can include lspci and dmesg output, that would be great
<Thunder000> the DVDRW is SlimType SOSW-833S
<hawk_78> Acer laptops are a nightmare!
<lathiat> mjg59: so, can vga16fb draw to an offscreen framebuffer
<lathiat> mjg59: and then switch to it
<lathiat> mjg59: so the splash screen appears instantly rather than seeign it draw down the screen? :)
<mjg59> lathiat: A good question. I have no idea. I'm pretty sure bogl doesn't support it.
<lathiat> that sucks
<Thunder000> mjg59: how do I include lspci and dmesg output ? when it is not installing ?
<lathiat> seb128: bah, debugging metacity is pain
<lathiat> seb128: now when it crashy, i couldnt switch to my console
<mjg59> Thunder000: Oh, right, it's that level of failure to detect? Please just file a bug against debian-installer, then
<seb128> lathiat: ctrl-alt-F2 should still work
<lathiat> seb128: as opposed to F1?
<Mithrandir> mjg59: the Acer has a SATA DVDRW, I think.
* mvo grumbles at notification-daemon
<lathiat> Mithrandir: oh thats gonna be nice
<Mithrandir> lathiat: as in "doesn't work", sure.
<lathiat> Mithrandir: yeh 'zactly
<seb128> lathiat: no, any F
<lathiat> seb128: hrm
<lathiat> se	weird
<lathiat> maybe it wasnt metacity that went bang then
<lathiat> blah
<lathiat> i'll attach gdb over ssh from another machien this time
<sivang> lathiat: mybe something in x itself
<lathiat> ok who else wants to add me to jabber
<lathiat> yay go ta backtrace
<Mithrandir> mjg59: hah, same thing with a pre-X-saved-vbestate.
<Mithrandir> mjg59: but the machine has had a framebuffer up, does that matter?
<mvo> seb128: it looks like #14006 is actually a gtk bug ... downgrading to 2.6.4 made the problem go away
<mjg59> Mithrandir: Oh, vga16fb?
<mjg59> Yeah, that might do it
<Mithrandir> mjg59: "live cd", whatever that gives me.
<mjg59> Uhm. Christ knows.
<mjg59> It's probably vga16fb, but could you check?
<seb128> mvo: not cool
<Mithrandir> mjg59: vgafb and vesafb are both loaded.
<Mithrandir> mjg59: I can retry with d-i/framebuffer=off though
<mjg59> Mithrandir: Which one has a usage count of 1?
<mvo> seb128: no, looks tricky :/
<Mithrandir> mjg59: vga16fb
<martink> doko, I have another idea for ooo-amd64 themes: (copy the 32bit engine to /usr/lib32/gtk-2.0/2.4.0/engines and) export GTK_PATH=/usr/lib32/gtk-2.0 before starting an ooo application
<mjg59> Mithrandir: Ok
<Thunder000> is there a way to insall ubuntu using a network installation ?
<AnnoyWolf> Thunder000, yes, possible, but ask in #ubuntu
<GNULinuxer> is there any status page for the ubuntu graphical installer?
<HiddenWolf> GNULinuxer, if it's not on the wiki, it's not there
<GNULinuxer> HiddenWolf: I want to beta test the installer
<dholbach> jdub: ping
<seb128> pitti: bugzilla is up again
<dholbach> does anybody know how to let mailman accept *@random.host.com on a moderated list?
<Mez> dholbach: it's not that hard
<Mez> one sec, lemme load up a mailing list
<dholbach> Mez: can you lead me to the option - subscribing *@bugs.launchpad.net didnt work
<Mez> privacy options -> sending filters -> Non-member Filters-> accept_these_non_members
<Mez> in there I have 
<Mez> ^(.*)ubuntu.com
<dholbach> Mez: super... thank you very much
<dholbach> universe-bugs@ is now operational!
<dholbach> thanks jdub too :)
<mdz> doko: done
<pitti> Morning mdz
<dholbach> hi mdz 
<mdz> Mithrandir,pitti: CD problem?
<mdz> morning
<pitti> mdz: I suspected CD overflow, just as we had in Hoary (this also killed xresprobe), but that doesn't seem to be the case
<mvo> hey mdz, good morning
<mdz> 281 new bug mails overnight, yay
<dholbach> mdz: universe-bugs@lists.ubuntu.com is now operational too, but i guess you read that in the backlog already :)
<Diziet> Is keybuk about ?
<_derek_>  /topic
<_derek_> blah
<_derek_> sorry
<HiddenWolf> mdz, good to see you're keeping busy. :)
<mdz> pitti: the CD did overflow
<pitti> mdz: hm, Tollef told me it was 645 MB?
<Mez> mdz: I'm wondering if I can get permission to break UVF for katapult (I'll need someone to sponsor it)
<Mez> We've fixed a couple of bugs that are pretty useful :D
<Diziet> I think I have an oddity in dpkg conffile processing so I'm reading the dpkg bugslist.  It's remarkably full of a lot of crap.
<Diziet> And real bugs too.  Lovely mixture.
<mdz> pitti: 
<mdz> + Trying to add mozilla-thunderbird...
<mdz>   @dep before checklist = mozilla-thunderbird
<mdz>   @dep after checklist = mozilla-thunderbird
<mdz> CD 1 filled with 647962888 bytes ... (limit was 653262848)
<mdz> Limit for CD 2 is 671088640.
<mdz> pitti: mozilla-thunderbird was larger than the space remaining on the CD
<pitti> mdz: ah, so this is from non-intelligent ordering
<pitti> ok
<pitti> mdz: how much more is required?
<mdz> debian-cd is not the sharpest tool in the shed
<pitti> mdz: I can trash some langpacks
<mdz> CD 2 will only be filled with 25983558 bytes ...
<mdz> !
<pitti> GASP
<pitti> how on earth could this grow by 20 MB in three days???
<pitti> that would mean to kill almost all langpacks
<mdz> hmm
<mdz> linux-kernel-headers appeared on the CD
<mdz> that wasn't there yesterday
<pitti> that's only required for development...
<mdz> maybe it overflowed yesterday too
<mdz> because it should have been there, as part of build-essential
<pitti> grumpf
<pitti> we already totally castrated the live cd, language-wise
<pitti> well, for the live CD we should probably rather kill the win software
<pitti> no sense to support this corner case and make it so much less useful to demonstrate Ubuntu IMHO
<pitti> but I'll mail u-d about that
<pitti> mdz: so shall I kill some langpacks for now? or maybe tbird?
<mdz> pitti: I'm looking at it to try to see what happened
<pitti> ok, thanks
<mdz> it has been overflowing for days
* pitti tests current live CD, brb
<mdz> this really should error out :-(
<Amaranth> woo, i got mIRC to install
<Amaranth> hi guys, long time no type
<tseng> Amaranth: um.
<HiddenWolf> Amaranth, mirc is windows, right?
<Amaranth> yes
<mdz> libgl1-mesa-dri is HUGE
<Amaranth> i'm at school
<HiddenWolf> de
<tseng> Amaranth: http://www.silverex.org/news/ < save yourself
<Amaranth> tseng: It can install into one random folder and run without any extra stuff?
<tseng> i believe so
<Amaranth> oh, and does it come in as a zip file?
<tseng> no
<mdz> we could drop emacs from the CD
<Amaranth> tseng: Then I'm stuck. :/
<mdz> seb128: do we need desktop-base?  it seems to only contain debian branding
<seb128> mdz: no
<seb128> we can trash it
<mdz> seb128: something depends on it
<mdz> we should use bzip2 for linux-headers
<mdz> fabbione: around?
<mdz> python-numeric's deps are huge too
<seb128> mdz: gnome-session Depends on it, but I can change that
<mdz> all that atlas/lapack stuff
<mdz> seb128: thanks
<comic> hello, I have a problem with amsn shows east error to me
<comic> /home/comic # amsn
<comic> Application initialization failed: this isn't a Tk applicationunknown color name "Black"
<comic> Error in startup script: can't invoke "wm" command:  application has been destroyed
<comic>     while executing
<comic> "wm state . withdraw"
<comic>     (file "amsn" line 43)
<Diziet> Should I expect to get correct information from   http://packages.ubuntu.com/breezy/python/python-imaging / Download python-imaging [list of files]    ?
<mdz> 5.7M linux-headers-2.6.12-7_2.6.12-7.11_i386.deb  4.7M linux-headers.deb
<mdz> there's 1M savings on the CD right there
<mdz> Diziet: no
<Diziet> I see.  OK.  It might be a good idea to remove it.
<Amaranth> that's better
<hawk_78> How do find which pid is using a kernel module, please?
<Amaranth> if i compress the firefox and xchat dirs then extract them to the local computer to run them, i have enough space on my network share
<hawk_78> I don't remenbere the command to use!
<pitti_live> Hi
<pitti_live> seb128: hmm, the trash applet crashed immediately at session start, known bug?
<Amaranth> hi
<pitti_live> seb128: (current live CD)
<seb128> pitti_live: no, backtrace?
<pitti_live> seb128: tricky at session start, but let me try it again
<seb128> pitti_live: no bug-buddy dialog?
<pitti_live> seb128: nope
<pitti_live> seb128: although b-b is installed
<Diziet> Who's in charge of python-imaging ?  It has a mistake in the python2.3 package that gets spat into universe (it has file overlaps with the _all.deb in main).
<dholbach> Diziet: we need to sync the debian version, ajmitch told me
<pitti_live> seb128: hmm, what's the binary name for the trash applet? I can't find it in the "Add to panel" dialog either
<Diziet> dholbash: I see.  Is someone on the case ?
<seb128> pitti_live: /usr/lib/gnome-applets/trashapplet
<hawk_78> Python modules can now be built using easy-deb from pypi.
<dholbach> Diziet: elmo can sync it, but he doesnt seem to be around
<dholbach> Diziet: i will double check and write him a mail
<hawk_78> easy-deb creates debs with a python egg inside.
<hawk_78> it can be used to allow multiple parallel versions of hte same module
<hawk_78> (I'm the author :-))
<Diziet> dh: Ta.
<jdthood> pitti_live: How is asoundconf coming?
<pitti_live> jdthood: I mailed you recently
<pitti_live> jdthood: first version is ready, but not for Breezy unfortunately
<jdthood> pitti_live: Oh?  I didn't get your mail!
<pitti_live> jdthood: not? odd...
<pitti_live> jdthood: I bounce it
<pitti_live> jdthood: can you please ping me again in ~half an hour? I'm currently debugging sth on the live cd
<mdz> infinity/lamont-away: can you confirm that oo.o2 is building
<mdz> pitti_live: what's happening?
<pitti_live> mdz: trash applet crashes immediately
<pitti_live> mdz: btw, I still get the resolution question on the live CD, but xresprobe is installed
<mdz> pitti_live: check /var/log/casper/post.log
<mdz> hawk_78: that's interesting
<mdz> hawk_78: see http://wiki.ubuntu.com/PythonModulePackaging
<hawk_78> That was my target!
<mdz> hawk_78: oh, what is your name?
<mdz> hawk_78: are you the student who has been working with doko through google?
<hawk_78> I'm the SoC student: Vincenzo
<mdz> ok
<mdz> welcome :-)
<hawk_78> Thank you!
<mdz> hawk_78: is there a web page where we can read about your implementation?
<hawk_78> Not yet, but I have uploade the project on pypi...
<hawk_78> there is a readme file inside the distribution...
<hawk_78> I'm waiting sf to approve my project
<hawk_78> The best resources to understand my job are from setuptools documentation: http://peak.telecommunity.com/DevCenter/setuptools
<hawk_78> easy-deb uses setuptools to create eggs...
<hawk_78> but this belongs to the project page, not to this channel, right?
<mdz> hawk_78: both are OK
<hawk_78> I have a little set of packages made using easy-deb... one of them is PIL
<mdz> hawk_78: I would like to read about how to use your tools
<mdz> i.e., documentation
<Diziet> Ahhh, I see what's happening with xinitrc now.
<Diziet> xbase-clients gets upgraded to the version without it and so dpkg forgets about the fact that xinitrc was ever a conffile owned by anyone.
<hawk_78> mdz: I can send you the readme and the --help output.
<mdz> hawk_78: send it to ubuntu-devel, please, for the benefit of others
<hawk_78> ok...
<jdthood> Diziet: Were you bitten by Debian bug #163657?
<hawk_78> done...
<hawk_78> I also updated the pypi page with the same info.
<hawk_78> http://www.python.org/pypi/easydeb
<mdz> hawk_78: thanks
<hawk_78> to test the project you can download from :
<hawk_78> deb http://hawk.linuxpratico.net/pypi ./
<hawk_78> deb-src http://hawk.linuxpratico.net/pypi ./
<mdz> hawk_78: this looks very nice!
<mdz> hawk_78: have you had fun with the project?
<hawk_78> I had a lot!
<hawk_78> The fun part was to make it autpackage itself!
<mdz> hehe
<mdz> hawk_78: I was going to ask how we would package easydeb itself ;-)
<mdz> pitti: did you get my bugzilla comment before leaving the live CD?
<mdz> pitti: you can get additional debug output from xresprobe
<pitti> mdz: no?
<hawk_78> I'm still waiting doko to say it is really ok. So if anyone wants to test/help/suggest... Please do it!
<mdz> XRESPROBE_DEBUG=yes xresprobe nv
<pitti> mdz: ok, same bug seems to occur in my installed system
<pitti> so I do it just here
<pitti> mdz: looks still boring...
<pitti> $ sudo ddcprobe
<pitti> VESA BIOS Extensions not detected.
<pitti> hmm, maybe something is more deeply broken here...
<mdz> pitti: it leaves the X logfile behind in /tmp
<mdz> check that
<pitti> mdz: ok, booting back to the live CD
<Treenaks> Mithrandir: ping
<siretart> wow. I'm impressed
<Mithrandir> Treenaks: pong
<Treenaks> Mithrandir: You had touchpad click = middleclick problems too?
<siretart> the wifi light of my madwifi card now blinks exactly then when there is traffic going over the air
<Treenaks> Mithrandir: (it seems my touchpad is doing that..)
<Mithrandir> Treenaks: given that I haven't had a touchpad for five years or so, no, I don't think so.
<Treenaks> Mithrandir: hm.. then who was it :)
<Diziet> jdthood: No, #108587.
<Mithrandir> Treenaks: I don't know, but I dislike touchpads, so.. :-)
<Diziet> #163657 looks annoying too.
<jdthood> Diziet: ah, yes, that was the one I was really looking for
<Treenaks> We need a "search" option for lists.ubuntu.com
<Treenaks> or get them google listed
<Diziet> Although: can someone coherently explain to me what these `transitional smoothing' packages are for ?
<HiddenWolf> Diziet, smoothing transitions, obviously!
<Diziet> They seem to have arisen a few years ago and been a very infectious meme.
<Mithrandir> Diziet: smoothing transitions?
<Diziet> Thanks everyone for your detailed description of the problem.
<HiddenWolf> Diziet, sorry, but that was asking for it. ;)
<dholbach> Diziet: it's for having proper upgrade paths (across releases)
<Mithrandir> Diziet: once in a while, packages go away and instead of just leaving the user with the old package, a transitional package will depend on the new package so no functionality is lost.
<Diziet> Is this a workaround for Replaces not having the right effect on package selection ?
<Mithrandir> I think so, yes.
<Diziet> Then we should fix Replaces, surely.  In dselect and I suppose apt too.
<Mithrandir> it's useful until that happens.
<Diziet> It's been around for years!
<Mithrandir> Replaces or transitional packages?
<Mithrandir> (both, I assume)
<Diziet> Because if we fix #108587 in the way described then it will produce two prompts when a locally-modified conffile is part of a package that `goes transitional' IYSWIM.
<Diziet> These transitional packages.  You would think that _someone_ would have fixed the root cause by now!
<Robot101> Diziet: no people wrote deborphan instead, to remove them when the transitional package doesn't need to be installed any more :P
<Mithrandir> Diziet: people are crap at removing crap, they just add more around it.
<dholbach> Robot101: if replaces should work and the automagic dependencies removal is in apt, we should all be happy :)
<Robot101> dholbach: automagic dependencies removal is in aptitude, because dpkg doesn't have a store for whether or not you explicitly requested a package or whether it was installed to satisfy dependencies
<pitti_live> hrmpf, live CD boot takes ages...
<Robot101> dholbach: which has the bad side-effect that if you don't use aptitude and try it, it wants to remove everything :P
<HiddenWolf> pitti_live, is that news?
<dholbach> Robot101: it should be in apt - it exists, but not in the archive yet
<jdthood> Transitional packages are sometimes needed in order to satisfy versioned Dependencies.
<jdthood> Diziet: Yes, ISWYM.
<pitti_live> HiddenWolf, worse than hoary in any case
<HiddenWolf> pitti_live, gasp, that's impossible, isn't it?
<pitti_live> oh, and I really like having *two* mixer applets :-)
<Robot101> Diziet: oh yeah, lack of versioned provides is the other problem :)
<Robot101> Diziet: how's your DNS server coming along? :)
<Diziet> No, the biggest problem is lack of Breaks.
<pitti_live> mdz: hm, so which file in /tmp is interesting for that? I don't see anything particularly interesting
<jdthood> It should be added to #108587 that dpkg should be smart enough to ask only one question when a modified conffile is abandoned and adopted in the same run.
<Diziet> If we had Breaks then everyone wouldn't be doing the TOTALLY INSANE Conflicts << thing.
<Diziet> jdt: In this case apt spoils that because it's not the same run.
<jdthood> Diziet: Ooo.  I haven't heard about Breaks before.
<Diziet> If you do it in the same run then it'll probably DTRT because it's all done during conffile resolution at the end, ie during configuration.
<Diziet> Breaks is a hypothetical field the specification of which is fairly obvious.  If A breaks B then B can't be configured if A is installed.
<Diziet> If A is not not-installed or config-files, that is.
<jdthood> Diziet: So the double question will appear only on an apt run?
<Diziet> I think so./
<Diziet> s,/,,
<Diziet> I haven't tested it.  I'll fix #108587 tomorrow and find out :-).
<Robot101> thanks apt. thapt.
<jdthood> Diziet: In that case perhaps dpkg could gain a "don't ask about abandoning conffiles" option which apt would use.
<jdthood> Hmm.  But how would it know that the option was needed in a particular case?
<Robot101> jdthood: no, that's "adding more crap"
<mdz> pitti_live: DEBUG_XRESPROBE=yes sudo xresprobe nv
<mdz> pitti_live: then it will tell you the path
<Robot101> jdthood: apt should just invoke dpkg properly :P
<jdthood> Robot101: What is properly?
<Robot101> no more than once unless it has a good reason to distrust dpkg's ordering of operations
<pitti_live> mdz: nope :/
<jdthood> Diziet: How is "Breaks" supposed to work?
<Diziet> jdt: apt, option needed> It couldn't.  It just can't be done right.
<Diziet> jdt: It causes dpkg to deconfigure (if you've got that turned on) when the breaking package is installed, or to prevent installation of the breaking package (if deconfiguration is forbidden).
<mdz> pitti_live: hmm, maybe that is only for LCDs
<pitti_live> mdz: I do have a TFT
<Diziet> Breaks would replace nearly every current use of Conflicts <<.
<mdz> pitti_live: see /usr/share/xresprobe/xprobe.sh
<Diziet> You'd say  Breaks: depender (<< ...)   rather than  Conflicts: depender (<< ...)
<Diziet> And it would never try to make it remove depender or impose installation ordering.
<pitti_live> mdz: I did a followup to #14151
<mdz> pitti_live: yes, the "not cleaning up after Xorg" means it did not run the server
<mdz> pitti_live: it used DDC instead
<pitti_live> mdz: and DDC does not seem to work
<mdz> pitti_live: did it work before?
<pitti_live> mdz: I use DVI now, may that be the reason?
<mdz> pitti_live: oh, you changed hardware
<mdz> pitti_live: well yes, that could be related ;-)
<pitti_live> mdz: I never really installed breezy on this box
<mdz> pitti_live: or booted breezy live?
<pitti_live> I tried several times, but it always failed
<lathiat> Anyone know about the glitz stuff? I'm fixing libgnomemm2.0 and while creating the libtool archive for gnomemm it whinges it cant find the glitz la
<pitti_live> mdz: I booted it a couple of times before, and always got asked, yes
<jdthood> Diziet: So depender would be deconfigured, not removed?
<lathiat> and i cant see any references to glitz so im not entirely sure whats up
<pitti_live> mdz: but it's a hardware specific bug and no regression, that's fine; I'll try with the hoary live
<Diziet> jdt: If necessary, yes.  It would be reconfigured later in the usual course of events.
<jdthood> Diziet: Ah, so it would be deconfigured but not marked 'deinstall'?
<pitti_live> brb
<Diziet> jdt: Indeed so.
<Diziet> It would be marked desired to be installed.
<jdthood> Diziet: I have seen this proposal before but this is the first time I understand it.
<jdthood> Diziet: Is there a wish for it in the Debian BTS?
<Diziet> jdt: I don't remember.  It's hardly the kind of thing that needs/wants a bug report.
<Diziet> But, no, there isn't.
<jAvier0> hi, is here anyone who works with the ubuntu trademark stuff?
<jdthood> Diziet: There are already requests for Previously:, Affects:, Suggests-Remove:, Recommends-Remove:, Successor-Of:, Pre-Super-Conflict:, ...
<Robot101> Smokes-Crack-With: ...
<dholbach> hahaha :)
<Diziet> Yes.  But I'm not on crack.  I've had this conversation with other actual dpkg maintainers and they agree with me :-).
<Diziet> Most of these additional ideas are barking and usually stem either from a lack of understanding of the existing features or in some cases from some missing stuff (like proper Replaces handling by dselect and apt).
<Robot101> aye
<Diziet> Lack of hooks or something like it is annoying too.
<Diziet> Breaks at least has a specification in some mailing list archive.
<Diziet> Unfortunately hooks doesn't - Wichert and I designed it on a cab ride back to an airport some years ago and forgot to write it down.
<infinity> mdz : Building on i386 and powerpc, failed on ia64 (as usual), and dep-wait on amd64 (will look into that right now)
<mdz> infinity: amd64 should simply fail (or not be tried at all)
<infinity> mdz : Well, the broken dep-wait did have that effect. :)
<infinity> mdz : If it really shouldn't be tried at all on amd64/ia64, we should change the architecture field so the buildds drop it on the floor.
<infinity> mdz : Or toss it in Packages-arch-specific.
<mdz> we hope that one day it will work on amd64, but it isn't expected to yet
<infinity> Yeah.  Fair enough.
<infinity> It fails on ia64 in the first 7 minutes, so it's hardly a bother to have it try there.
<infinity> Not sure how far into the build amd64 gets.  We'll see.
<phlaegel> jdub: ping
<infinity> Oh, wow, that dep-wait on amd64 was "correct"... In other words, there's a typo in debain/control.
<infinity> unixodbc-dev (>= 2.8.11) [amd64] 
<infinity> That probably should be (>= 2.2.11-8)
<infinity> But if it's expected to fail on amd64 later anyway, it's hardly the end of the world.
<infinity> doko : See above about openoffice.org2's broken build-dep ---^
<slomo> seb128: gnome-volume-properties has a bug: for scanners it has yast2 as default command
<seb128> slomo: you want to speak to pitti 
<seb128> he's the maintainer for it
<slomo> seb128: ok, i'll wait until he returned... thanks :)
<seb128> np
<elmo> infinity/lamont: I'm about to reboot the firewall that among other things is the choke for the buildds
<mdz> infinity: I think at this point it actually builds on amd64, but doesn't work
<elmo> shout now if that's crtically bad
<mdz> infinity: we should probably do something to ensure it doesn't upload broken binaries
<infinity> elmo : Doesn't bug me any.
<infinity> mdz : Well, a completely unsatisfiable build-dep does the trick there. :)
<mdz> infinity: it does seem likely that oo.o will start working on amd64 before unixodbc reaches 2.8.11...
<mdz> but it's hardly optimal ;-)
<infinity> slomo : Did you do the xawtv upload?
<slomo> infinity: dholbach uploaded it but i made the change
<infinity> slomo : Instead of guessing where the app-defaults file will go and then moving it (which you'll notice isn't really all that deterministic), you should just build-dep on imake, which configure uses to put the app-defaults file in the right place.
<infinity> slomo : At least, it looks that way to me, from reading a build log quickly.  You might want to actually read configure and see how it determines the path.
<slomo> infinity: thanks... good to know :)
<infinity> slomo : Note that the build failed on amd64 due to your patch.
<infinity> slomo : I'll be around for a bit, if you want to hack up a changed package and have me look it over and sponsor it.
<slomo> infinity: i'll do in a few minutes... thanks :) and this app-defaults file was the minor part of my previous change ;)
<infinity> slomo : Yes, obviously it was a minor part, it just happens to be the reason it now fails to build. :)
<slomo> infinity: you said a build-depend on imake would solve this... but it doesn't... the configure of xawtv looks whether /etc/X11/app-defaults exists and sets the dir to /usr/X11R6/lib/X11/app-defaults otherwise
<slomo> infinity: would it be ok to create the directory before calling configure or do you want a better fix?
<\sh> seb128: can u tell me what this is..i'm getting it when i start rhythmbox
<\sh> The error was 'BadIDChoice (invalid resource ID chosen for this connection)'. (Details: serial 23 error_code 14 request_code 1 minor_code 0)
<seb128> \sh: no clue, seems to be an xorg issue
<\sh> hmm..
<\sh> it's yesterdays daily
<\sh> with todays updates
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=14123 is a known GTK crasher, will be fixed with 2.8.3
<seb128> your error is not known
<phlaegel> seb128: is nautilus supposed to be sorting uppercase before lowercase now?
<\sh> hmm....what's the best way to debug it? gdb rhythmbox --sync?
<slomo> infinity: ok, ignore the last thing i've said... seems like i have to patch configure
<infinity> slomo : If you patch configure, make sure to also patch configure.in, so regenrating won't kill your changes.  And touch the files in the right order so they don't get regerated on build...
<infinity> slomo : In other words, that kinda a pain in the butt for a single fix. :)
<slomo> infinity: sure... i've patched configure now to use /etc/X11/app-defaults without checking anything... ok with you?
<Diablo-D3> is the breezy source apt sources on archive.u.c fubar?
<Diablo-D3> keeps having md5sum mismatch
<infinity> slomo : Have you patches configure.ac too?
<slomo> infinity: yes
<infinity> slomo : And have you ensured that the build won't try to regenerate configure if the timestamps are goofy?
<slomo> infinity: i'm currently trying that... i hope it works...
<infinity> slomo : See /usr/share/doc/autotools-dev/README.Debian (the section on "timestamp skews") for hints.
<seb128> phlaegel: depending of the locale I gues
<seb128> guess
<infinity> slomo : A simpler way to go, rather than patching configure (and all the hassles that come with that) sould just be to "sed -i -e 's,@resdir@,/etc/X11' Makefile.in"
<slomo> infinity: well the configure patch works ;)
<infinity> slomo : But it's much more intrusive to patch configure (and do it right, without introducing a build-dep on autotools)
<phlaegel> seb128: hm. en_CA? :-) it never used to, until maybe a few weeks ago.
<slomo> infinity: it works without regenerating anything and without autotools in build-depends... but you decide ;) i can also patch the Makefile.in
<seb128> phlaegel: the sort has been fixed during 2.11
<infinity> slomo : Make sure you have no autotools installed, the "touch configure.ac ; dpkg-buildpackage"
<elmo> mjg59: around?
<infinity> slomo : Then realise that timestamps can get messed up when unpacking sources, leading to that situation.
<mjg59> elmo: Hi
<slomo> infinity: the one with configure patch: http://yggdrasil.sytes.net/files/debdiff/xawtv_3.94-1ubuntu4.debdiff
<seb128> phlaegel: cd http://bugzilla.gnome.org/show_bug.cgi?id=172690
<elmo> mjg59: hey, have you tried latest breezy kernel with your nx6215?
<slomo> infinity: imho everything is working correctly there
<mjg59> elmo: Yeah
<elmo> we're getting /dev/hda1 does not exist on boot
<mjg59> Oh. Uh. Weird.
<mjg59> Oh, are you on the latest initramfstools?
<mjg59> If not, it won't load atiixp
<elmo> mjg59: yeah, crack of the cron.daily breezy
<mjg59> And explosion
<elmo> easy to hack around?
<mjg59> Hm. Actually, maybe I forced that myself
<mjg59> jbailey: Have you added atiixp to initramfs-tools yet?
<jbailey> mjg59: Yes, it's in the copy that you have.
<mjg59> elmo: Yeah, I added it to /etc/mkinitramfs/modules
<mjg59> Or wait for Jeff to upload the crack he's just been feeding me
<mjg59> jbailey: Ok, we win
<jbailey> Yay!
<elmo> mjg59: hmm, same erro for us
<mjg59> elmo: You regenerated the initramfs?
<elmo> well, err no ;)
<jbailey> =)
<phlaegel> seb128: I'm talking about the first letter of the filenames... like directory B coming before directory a.
<elmo> sorry I avoid init*
<elmo> how do I do that?
<mjg59> elmo: mkinitramfs -o /boot/initrd.img-`uname -r`
<jbailey> elmo: mkinitramfs -o /boot/initrd.img-$(uname -r)
<elmo> thanks
<jbailey> elmo: If you're doing it for not the running kernel, "mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r)" will tell it what version of modules to use.
<seb128> phlaegel: I've no opinion on the question. What does "ls -l" do?
<elmo> christ, I'm confused, how do I do this not from within that kernel, as I obviously can't boot the current initramds?
<mjg59> mkinitramfs -o /boot/initrd.img-2.6.12-7-amd64-whatever 2.6.12-7-amd64-whatever
<elmo> ok
<highvoltage> elmo: christ: no such nick or channel
<lathiat> he's forsaken us
<infinity> slomo : Okay, I just tested to make sure I'm not talking out of my ass.
<phlaegel> seb128: nautilus and ls do the same thing now... but nautilus used to be different, mixing upper and lowercase. I was just wondering if it was on purpose, since I liked it the old way :-)
<slomo> infinity: otherwise i also have a version with patched Makefile.in flying around... choose one ;)
<mjg59> jbailey: Ok, can you upload that initramfs-tools at some stage?
<jbailey> mjg59: Yup.  I'm just gluing in I think the last bit to make lilo users happy.
<infinity> slomo : "apt-get --purge remove autoconf autoconf2.13 ; apt-get swource xawtv ; cd xawtv-*; debian/rules work ; touch work/xawtv*/configure.ac ; debian/rules build" and watch it fail, cause it wants to regen configure.
<jbailey> Because I *love* string manipulation in shell.
<seb128> phlaegel: that's the bug I pointed. glib has a function for that now which makes the behaviour the same for everything and nautilus uses it
<jbailey> =)
<infinity> slomo : That's precisely what I was warning against.
<mjg59> jbailey: I've uploaded usplash that'll work with it
<infinity> slomo : I'll just upload with the patched Makefile.in, but I wanted to make you aware of the configure timestamp issue, cause it bites our buildds a fair amount, and MOTU in general seems to be blissfully unaware of it.
<slomo> infinity: ok... so at the same location the one which patches just the Makefile.in
<elmo> mjg59/jbailey: thanks, working now
<mjg59> elmo: Rock
<slomo> infinity: thanks... i thought i would be enough to look at the build and whether one can see something regenerating something else
<jbailey> elmo: Cool.
<phlaegel> seb128: ah, ok. so it is on purpose. thanks.
<mjg59> elmo: If you want X to work, add Option  "XaaNoScreenToScreenCopy" "True" to the device section of xorg.conf
<elmo> should an atheros madwifi thing get auto-hotplugged?
<elmo> it looks like link-on-boot worked, but it's not being loaded
<mjg59> Should do
<mjg59> But you'll need an ath0 entry in /etc/network/interfaces
<mjg59> Unless it's not being loaded at all, in which case - uhm.
<infinity> slomo : Uploaded.  I recommend reading README.Debian from autotools-dev and committing most of it to memory.  A lot of autotools weirdness can mess with builds in rather seemingly nondeterministic ways.
<mjg59> Usplash love!
<infinity> Usplash hate!
<mjg59> Bah
<elmo> mjg59: yeah,X seems to work now, thanks
<mjg59> Now all I need to do is figure out why it doesn't work on hibernate
<infinity> mjg59 : Does usplash repect "splash" in /proc/cmdline yet?
<slomo> infinity: thanks... will do later :) now i've to search for some food ;)
<elmo> does lspci use an internal or kernel database?
<mjg59> infinity: Yes
<mjg59> elmo: Internal
<elmo> 'cos even in breezy lspci doesn't recognise hardly anything on this machine
<infinity> Oh, so I can install ubuntu-desktop finally without it making me want to kill myself.  Yay.
<Diablo-D3> heh
<Diablo-D3> infinity: yeah it got fixed
<elmo> hmm, spoke too soon, X died already, meh
<Diablo-D3> rotfl
<mjg59> infinity: It also won't insmod vga16fb if you have vga= set
<infinity> mjg59 : And I do.
<infinity> mjg59 : So I guess I'm doubly insulated. :)
<mjg59> infinity: So, there you go
<mjg59> elmo: Possibly also Option          "XaaNoSolidFillRect" "True"
<infinity> Is there any hope of having it use a non-vga16fb framebuffer if one has been selected (ie: with vga=)?
<mjg59> infinity: Not trivially
<infinity> Yeah, I assumed as much.
<mjg59> Well, that's not strictly true
<infinity> Oh well, I'd rather have a pretty console than a splash screen, so I know what my choice currently is.
* mjg59 wonders how bterm deals with it
<mjg59> mdz: Ok, time to start integrating init scripts with usplash
<mdz> mjg59: I was just thinking about that as I was lying awake last night
<mjg59> Once Jeff uploads his new initramfs-tools
<dholbach> mjg59: i guess he's just looking up a witty quote of oscar wilde 
<jbailey> dholbach: *lol* Nah, it's already chosen. =)
<dholbach> jbailey: you rock! :)(
<jbailey> dholbach: Choosing the Oscar Wilde quote is what I do while I sit here and panic that I might have just caused hundreds of systems to fail to boot.
<jbailey> dholbach: It sucks being a non-smoker sometimes.
<mjg59> jbailey: Well, it's me who's left hacking on grub
<dholbach> jbailey: i read a nice quote of oscar wilde on cigarettes a couple of days ago
<infinity> mjg59  :Hacking on grub is a privilege.  If you tell yourself that over and over again, it still won't be true, but you may go numb.
<jbailey> mjg59: True. =)  I wonder if glibc + initramfs makes up for grub.
<jbailey> mjg59: Probably not, since at least if I screw up really badly, they can still boot into windows. =)
<elmo> I thought broadcom wireless cards were generally atheros
<elmo> am I on crack?
<\sh> no
<\sh> the broadcoms are not working with madwifi
<\sh> but ndiswrapper and windows crack works
<\sh> just tested it today 
<mjg59> elmo: No, Broadcom are evil stuff
<\sh> after this test..the nc6120 just burned away...memory burning error
<mjg59> No specs, binary driver for Linux-mips
<mjg59> \sh: ?
<\sh> because my colleague used the wonderfull invention of a portreplicator of hp...
<elmo> whine
<mjg59> elmo: And HP BIOS-lock their wifi cards
<\sh> i burned my nc6000 first, when i used this thingy...and then my boss...and now a new 6120 with different docking station but the same clip2burn system
<mjg59> \sh: Wow. I haven't managed to explode anything with the docking stations yet
<infinity> mdz : I have a girlfriend who's fluent in Japanese and spends a great deal of time using the Windows Japanese input methods.  Should I have her test drive the stuff mentioned in that -devel thread and see how hard it is to get any of it going?
<\sh> mjg59: the nc6000 i have, after this I got a new mainboard, new cpu, new memory...at least everything new but the hd
<\sh> mjg59: the hd broke 6 months later
<mjg59> Haha
<\sh> but the customer support service of hp is good...they came repaired..or shipped replacement
<mdz> infinity: absolutely
<\sh> mjg59: and now the same thing happend to my colleague..colony 3 installed on this and windows on the other part...when I felt the heat...I said directly: u used the docking station...made a memtest86 and boom memory errors en mass
<dholbach> bbl
<jbailey> Sweet!  lilo boots.
<mjg59> Nngh
* jbailey checks that grub still will too.
<michele> hello
<michele> wasn't breezy supposed to ship with gcc 3.4?
<crimsun> no, gcc 4
<jbailey> michele: Nope. https://wiki.ubuntu.com//ToolchainRoadmap
<michele> hm, ok... I probably misread it. I thought it was reverted
<jbailey> michele: The change from gcc-3.3 to gcc-4.0 was major enough that reverting it would almost be more work.
<michele> jbailey: I guess so. I wonder what I've been smoking when I read that...
* sivang is back
<martinhj> ubuntu did not boot from my LVM disks after the Colony CD 3 install.. File bug?
<martinhj> work around is to use initrd instead of initramfs
<ryanthiessen> anyone else notice that nvidia-glx is uninstallable at the moment?
<jbailey> mjg59: Uploaded.
<mjg59> jbailey: Rock
<mjg59> Now someone just needs to sort out the lsb stuff
<jbailey> mjg59: Do you just need that one line added?
<lathiat> jbailey: ping
<lathiat> jbailey: do you remembe that issue we had with __u64
<jbailey> lathiat: You  make it sound like I've only had one... =)
<jbailey> lathiat: What's up?
<lathiat> jbailey: haha well i was wondering if you could tell me if this is the same issue ->  http://bugs.archlinux.org/index.php?do=details&id=3106
<mjg59> jbailey: One line added to each of the printing functions
<jbailey> lathiat: Depending on which ANSI C you want, it could be.  C89 didn't have long long support, C99 does.
<lathiat> jbailey: well this was with -std=c99
<lathiat> jbailey: that it was failign so
<infinity> ryanthiessen : Should be installible if you upgrade to the latest mesa.
<jbailey> lathiat: Have you considered using the linux-libc-headers project for arch linux?  There's 2 or 3 distros now collaborating on it (We're one of them).
<lathiat> jbailey: oh im not asocaited with them
<mdz> pitti: did you make some changes to the seeds to try to free space on the install CD?
<jbailey> lathiat: It's silly for each us of to duplicate the work.
<lathiat> jbailey: i just reported the bgu because it broke avahi (my project)
<jbailey> lathiat: Ah. =)
<infinity> ryanthiessen : Oh, no it's not, cause that change got dropped.
<lathiat> jbailey: and was hopign to provide them with a little more info
<infinity> ryanthiessen : I'll upload a fix.
<ryanthiessen> infinity: thanks
<pitti_> mdz: not yet, since you said you wanted to look at it; shall I kick all langpacks?
<mdz> martinhj: you can add any additional information you have to the existing bug, and add yourself to the CC list
<mdz> pitti_: all? :-/
<mdz> pitti_: I have looked at it, but the only significant addition I see is hplip, which accounts for about 6MB
<pitti_> mdz: if we need 20 MB?
<jbailey> lathiat: Yeah.  Basically long long is allowed in C99, and that construct allows for it.
<lathiat> jbailey: and theirs doesnt?
<lathiat> jbailey: hence the || STDC_VERSION 1999
<jbailey> lathiat: Right, that's not in the upstream kernel.
<lathiat> jbailey: ah
<jbailey> I want to try and get some of those things in, but I suspect I'd need to go through the kernel janitors list.  I'm more hoping to convince other distros that linux-libc-headers is good enough to just use it.
<jbailey> Perhaps if we have all of us maintaining it together we can get usable ABI headers.
<martinhj> mdz: I havn't seen that bug?
<martinhj> which is it?
<jbailey> mjg59: Aww, this is pretty.
<mdz> martinhj: look through http://bugzilla.ubuntu.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=UPSTREAM&bug_status=PENDINGUPLOAD&field0-0-0=product&type0-0-0=substring&value0-0-0=initramfs-tools&field0-0-1=component&type0-0-1=substring&value0-0-1=initramfs-tools&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=initramfs-tools&field0-0-3=status_whiteboa
<mdz> rd&type0-0-3=substring&value0-0-3=initramfs-tools
<mdz> martinhj: I think I saw such a bug there
<mdz> martinhj: or ask jbaily
<mdz> jbailey, even
<jbailey> martinhj: 'sup?
<mjg59> jbailey: ?
<lathiat> jbailey: got a url / contact for that i can point them at?
<jbailey> mjg59: Seeing text in the white box.
<mdz> jbailey: martinhj ubuntu did not boot from my LVM disks after the Colony CD 3 install.. File bug?
<mjg59> jbailey: Ah, cool
<mdz> why does xchat no longer display <> around nicks?  that's annoying for cut and paste
<sivang> mvo: ping, hi
<jbailey> mdz, martinhj: Might be fixed by now.
<sivang> mvo: what's with the scheme thingy in lpint? (curious) lpi.def or something
<jbailey> martinhj: Got a moment to sit with me through testing it?  I cna usually tell quickly if it's a bug I've fixed already or not.
<mdz> martinhj: yes, try regenerating your initramfs with initramfs-tools 0.23 and see if that fixes it
<_derek_> did xen ever make it into breezy?
<martinhj> jbailey: sure
<jbailey> mdz: Do you have an old xchat conf file around?  If not, I can send you mine.
<martinhj> mdz: never used initramfs
<martinhj> will try
<lathiat> jbailey: ?
<jbailey> martinhj: Do you still have the colony CD handy?
<mvo> sivang: hi, I'm just having dinner
<mdz> jbailey: no, I don't.  but I don't think I changed it since it did that, either
<jbailey> lathiat: I'm googling at the same time, I've just run out of hands. =)
<lathiat> jbailey: haha sorry
<martinhj> jbailey: yes
<jbailey> lathiat: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
<lathiat> jbailey: just thought you missed it ;p
<mdz> jbailey: which config file should I be looking at?
<jbailey> lathiat: It's all good. =)  Entirely possible. =)
<jbailey> martinhj: If you can reboot, and at the prompt type 'rescue'
<jbailey> martinhj: It'll step you through setting up your hardware and drop you at a prompt after a little bit.
<martinhj> jbailey: only got one computer here, so you have to tell me first:-) (just moved from my parents house)
<jbailey> mdz: ~/.xchat2/{colors.conf,pevents.conf}
<martinhj> jbailey: or I can talk with you tomorrow and I can use a computer at campus
<pitti_> mdz: are there any other overflows?
<jbailey> mdz: Somewhere along the way xchat got rearranged to not have them and change all the colours.
<jbailey> mdz: I restored my old ones from a backup, I can post for you if you'd like.
<mdz> pitti_: amd64 and powerpc looked OK
<mdz> jbailey: sure, then I can diff them against mine
<sivang> mvo: ah ok, let me know if you can talk more today
<jbailey> martinhj: Mmm...  Is this a fresh install that you don't mind blowing away?  If you have easy access to good bandwidth and a cd burner, it might be worth just burning a nightly CD tomorrow.
<mvo> sivang: in a couple of minutes, sure
<pitti> pitti: ok, threw out most of the langpacks
<jbailey> mdz: http://people.ubuntu.com/~jbailey/colors.conf http://people.ubuntu.com/~jbailey/pevents.conf
<martinhj> jbailey: no problem, I got hoary, this breezy install I use now (where I use initrd instead of initramfs) and the fresh install
<martinhj> jbailey: where do I get the nightly CDs?
<Nafallo> madduck: cdimage.ubuntu.com :-)
<martinhj> and when tomorrow is the one I should use ready?
<jbailey> martinhj: http://cdimage.ubuntu.com/daily/current/
<jbailey> martinhj: It looks like 9 or 10 hours from now...
<jbailey> But I might have the timezone wrong. =)
<pitti> elmo: please sync postgresql-common postgresql-7.4 postgresql-8.0
<martinhj> yeah, I'm not sure either;-)
<jbailey> martinhj: What problem kept you over on initrd for your current breezy install?
<martinhj> the same, but I thought maybe it was fixed in colony 3(tried to talk about it once here, but probably the right people wasn't here then)
<jbailey> If you're willing we can do the test easily enough from the current breezy system.
<jbailey> martinhj: If you're using grub, we can easily switch it to use a temporary initramfs without affecting the known working one.
<martinhj> for all new kernel releases which uses initramfs I have had problems
<mdz> jbailey: 403
<martinhj> I need lilo to boot lvm
<jbailey> mdz: fixed.
<jbailey> martinhj: 0.23 should fix your problem then.
<martinhj>  /boot is in lvm to
<mdz> aha
<mdz>  event_name=Channel Message
<mdz> -event_text=%C18%B%B$4$1%O%C18%O$t$2
<mdz> +event_text=%C2<%O$1%C2>%O$t$2%O
<jbailey> Mm, I didn't test with /boot on lvm.
<martinhj> jbailey: ok, will try it..
<jbailey> martinhj: If you're comfortable.
<jbailey> martinhj: You can edit your lilo.conf to make a temporary setting that you can boot with.
<jbailey> martinhj: Are you willing to try this?
<mdz> jbailey: thanks
<martinhj> jbailey: I know lilo from before:-)
<jbailey> mdz: =)
<jbailey> martinhj: Cool.
<jbailey> martinhj: So if you do mkinitramfs -o /boot/myinitramfs
<jbailey> martinhj: ...  I skipped astep.
<jbailey> martinhj: apt-get upgrade and make sure you have the 0.23 of initramfs-tools
<martinhj> jbailey: 0.23 isn't in my repository.. (I could try US)
<infinity> Patience.  It was just uploaded.
<jbailey> infinity: MUST.. HAVE.. LATEST.. CRACK!
<jbailey> err
<jbailey> =)
<jbailey> martinhj: http://people.ubuntu.com/~jbailey/initramfs-tools_0.23_all.deb
<pitti> g'night
<slomo> pitti: gnome-volume-properties has a bug: as default action for scanners it calls yast2 which we don't have ;)
<slomo> pitti: oh sorry... gn8 then :)
<pitti> slomo: oh?
<pitti> slomo: indeed - what would be appropriate? calling yast sounds as if it would be intended to be a configuration program...
<slomo> pitti: no idea... do we have something that should be called when a scanner gets plugged in? just noticed this when looking at g-v-p... i don't even have a scanner ;)
<pitti> slomo: shall it just call xsane?
<pitti> slomo: me neither :-)
<pitti> slomo: well, just calling xsane scans for devices, so it should be a reasonable default
<slomo> pitti: ok :)
<pitti> slomo: fixed and uploaded; thanks for the hint
<slomo> pitti: np
<pef> bye !
<pitti> ok, good night, try 2
<siretart> elmo: around? could you please sync mozilla-tabextensions from debian?
<siretart> elmo: current firefox has problems with it. I just tested it with current firefox in breezy, works fine
<elmo> siretart: pls request syncs by source package name in future
<siretart> oh. its 'tabextensions'
<siretart> will do. thanks!
<elmo> done anyway
<lathiat> infinity: could you giveback libgnomemm2.0 and ultrapoint ?
<infinity> lathiat : Done.
<lathiat> infinity: thanks
<lathiat> infinity: ermm
<lathiat> infinity: for maxima, it has a given back for i386 but no fail or success log
<lathiat> infinity: whats that mean? (its from a few days ago, so i doubt its waiting?)
<infinity> lathiat : Note the "wanna-build failed with status 65280"
<infinity> lathiat : That means it tried to give it back, but failed miserably.
<lathiat> infinity: erm, what causes that? :)
<infinity> Lack of network connectivity?  General buggery?  Who knows.
<lathiat> oh, ouch
<infinity> Given back manually, though.
<lathiat> well it could do with being given back again if you can make it work :)
* infinity points up.
<infinity> The connectivity issue was obviously pretty short-lived, or nothing would be building right now at all. :)
<lathiat> right
<sivang> seb128: can you take a look at the menu data type of gnomemeeting, I keep getting GTK_IS_MENU assrtion failure, although I see it's a GtkWidget like lpi wants
<sivang> seb128: I'll implement it manually if they are not comaptible
<seb128> sivang: I'll have a look
<sivang> seb128: thanks
<sivang> seb128: (in my assertion faliure, I used _add_items)
#ubuntu-devel 2005-08-31
<sivang> seb128: I'm going to sleep, mail me with your results / msg me so I will pick up on my awaylog
<seb128> k
<sivang> seb128: thanks
<seb128> sivang: it works
<seb128> sivang: launchpad_integration_add_items (gtk_widget_get_parent (gtk_menu_get_widget (mw->main_menu, "about")), -1, TRUE, TRUE);
<seb128> that does the job
<shackan> are we getting dbus 0.36 in breezy ?
<seb128> no
<shackan> k
<seb128> shackan: they rolled it today?
<sivang> seb128:<educational question> whee thanks, how did you find out that you need to do it? </educationl question>
<sivang> seb128: also currently experimenting with clock applet, to see if the pkg tracking code works from there
<seb128> sivang: just try to get the menu from the widget used by the source code, no universal method ...
<sivang> seb128: that's an answer for the educational question?
<shackan> seb128, yesterday, apparently
<seb128> yep
<sivang> seb128: ah, so what is mw->main_menu ?
<sivang> seb128: (if not a GtkWidget)
<seb128> "mw->main_menu = gtk_menu_bar_new ();"
<sivang> seb128: AFAIK a menu bar is of class GtkWidget, no ?
<lifeless> hmm, boom, goodbye pubring.gpg again.
<lifeless> this is getting tiresome
<lifeless> bob2: did you file a bug on it ?
<seb128> sivang: right, why?
<seb128> every GTK widget is a GtkWidget ...
<lamont> mdz: you mean I have to highlight on 'infinity' now too?
<lamont> infinity: 65280 == 0xff00 --> exit -1
<sivang> seb128: so I get why the add_items wouldn't work , but I don't understand why it wasn't asserted like a GTK_MENU which is a GtkWidget
<seb128> what should be asserted and why?
<sivang> seb128: never mind. I'll ask you when we have more time, for the meanwhile I'll just get done with the patch
<seb128> want to do gimp tomorrow? 
<lathiat> lamont: i've got somethign that failed to build on i386 due to a missing libt1-dev but i've got it locally, any idea whats up?
<lamont> lathiat: which package
<lathiat> lamont: ultrapoint
<sivang> seb128: yes, I'll give it a quick try and ping you up on trouble
<mdz> seb128: how is firefox going?  do you know what needs to be done?
<sivang> mdz: already done lpi wise :) seb rocks
<sivang> seb128: I played already with the ffox items, works nice
<lamont> lathiat: is libt1-dev possibly in multiverse?
<lathiat> lamont: err
<seb128> mdz: I've uploaded firefox patched, but they are not translatable yet ...
<slomo> seb128: do we have some kind of glitz transition? i.e. is everything depending on glitz to be rebuild? or will you take care of this
<lathiat> lamont: main apparently
<mdz> oh, I must have missed it on -changes
<lamont>   vflib3-dev: Depends: vflib3 (= 3.6.13-3ubuntu1) but it is not going to be
<lamont> that's all the failures I see...
<lathiat> err
* lathiat looks again
<seb128> mdz: firefox files come from a DTD and some .js, we can't use lpi lib here, so I've made normal menu items 
<mdz> it doesn't seem to have built yet
<seb128> weird
<seb128> it was like 5 hours ago
<mdz> ah, there it is
<lamont> and vflib3 is missing a few X functions (ergo, libs) on at least one arch
* lamont must run home shortly
<mdz> it wasn't in my last apt-get update but it was in this one
<lathiat> lamont: i fixed vflib3 today
<lathiat> lamont: it was due to xmkmf 
<lamont> ah, ok
* lamont gives back ultrapoint
<lathiat> http://people.ubuntu.com/~lamont/buildLogs/u/ultrapoint/0.4-9.4/ultrapoint_0.4-9.4_20050825-2337-i386-failed.gz is what i was looking at
<mdz> doko_: thanks for seeing to oo.o2 launchpadiscation
<lathiat> have i got a cached list or somethin?
<seb128> mdz: launchpad seems to have reserved "mozilla-firefox" instead of "firefox" though ... 
<lamont> nah - I'm looking at my email, which tends to be a bit delayed.
<lathiat> lamont: oh right
<lathiat> lamont: i already had it given back a bit earlier
<mdz> seb128: should probably tell someone on #launchpad about this
<lathiat> lamont: and got the libt1-dev trhing
<seb128> mdz: yeah, I'll do now
<mdz> seb128: anyway thanks for getting it in
<lathiat> lamont: anyway talk to you later
<seb128> np
<lamont> lathiat: I'll look at it tonight when I finally get home..
<lathiat> lamont: thanks, cya
<mdz> mjg59: still here?
<seb128> slomo: it's already fixed. cairo used to build with glitz, the option is not supported for 1.0 so it has been turned but a pile of /usr/lib/*.la were mentionning it ... since cairo doesn't bring glitz by Depends it breaks the build
<seb128> slomo: I've rebuilt most of the stuff to fix that, should be ok now
<slomo> seb128: i count 68 sourcepackages here (including xfce stuff) which depends on libglitz1 or libglitz-glx1... so we should leave them alone when they don't fall under libcairo1 transition?
<seb128> slomo: that's not an issue, only libs break builds, most of these packages don't have .la files
<slomo> seb128: but as the other packages depend on glitz, glitz is installed for them although it isn't needed... well but that's nothing critical (and they just need a rebuild to fix)
<seb128> slomo: there is ~20 main packages and they will be almost all reupload for GNOME 2.12
<seb128> slomo: you can rebuild universe ones if you want
<sivang> seb128: http://muse.19inch.net/~sivan/lpint/gnomemeeting/ I hope it's ok..
<sivang> seb128: night
<seb128> sivang: I've already uploaded a patched package ...
<seb128> since I've made the patch I've uploaded it once done
<jdub> phlaegel: pong
<jdub> seb128: morning!
<seb128> hello jdub :)
* jdub looks at breezy-changes
<jdub> sebuild has been running hot!
<seb128> ;)
<jdub> jbailey: ooh, should i try rebooting with new initramfs? (nothing explicit in the changelog about the md stuff i hit)
<jbailey> jdub: Right, I didn't get that in.
<jdub> d'oh! ;)
* jdub refuses to reboot! ;-)
<jbailey> jdub: We'll entice you with usplash love in the next couple of days. =)
<sabdfl> jbailey: have you asked the art team for classy splashies?
<jdub> heh
<jdub> luckily my server does not care for usplashery ;)
<phlaegel> jdub: I had a howl question for you, but realized it doesn't matter :-)
<jdub> sabdfl: that's on cliff's list
<jdub> phlaegel: avahi uber alles! :)
<jbailey> sabdfl: mjg59 is doing all that magic.  I'm just providing infrastructure for him to work.
<sabdfl> jdub: might be nice to let the community have a free stab at it
<jdub> andy has also been doing some, not sure if he's mentioned it to the art team
<mjg59> mdz: Hi
<sabdfl> hiya mjg59
<phlaegel> jdub: mmmm... avahi
<jbailey> sabdfl: I did ask mjg59 if there would be a splash screen suitable for a cinema display though.  His response was to give me bugs to fix, so I'm not asking him anything anymore. ;)
<jdub> ha ha
<jdub> that's a hard problem ;)
<sabdfl> jbailey: in that case, we need surround sound startup sounds too :-p
<mjg59> Andy sent me some nice looking art, but I don't know if it fits in with the general branding
<jdub> i'd be happy to suggest a non-ratio-reliant usplash screen, but i think that would be a terribly suckful requirement (no text! no logo!)
<jbailey> Hmm.  That might be a nice excuse to use buying a surround sound setup as a tax-deductable expense...
<sabdfl> i like the apple approach - two colours on the splash screen, very classy and simple
<jdub> cliff is experimenting with nice plain ones with black background
<jdub> (black gets us around problems like widescreen and so on without looking ugly)
<jdub> we could go for a sandy colour, but it will look like a big block of out-of-place colour in many situations
<jdub> (this is why the windows one has an almost-black background too)
<sabdfl> ok
<sabdfl> i would say "surprise me" but breezy does that regularly anyhow ;-)
<jdub> http://people.ubuntu.com/~jdub/2005/usplash/
* jdub gathered a few windows ones for inspiration
<jdub> http://people.ubuntu.com/~jdub/2005/usplash/random-cute-longhorn-mod.jpg
<jdub> ^ i like this mod
<jdub> reflectioney and glowey
<jdub> (that one is non-MS artwork)
<seb128> jdub: FYI I've just built current djvulibre from Debian, build fine ... you can ask your sync again probably :)
<jdub> seb128: no C++ transition issues/
<jdub> ?
<seb128> jdub: what about cpp?
<seb128> jdub: it has been transition for Debian so it's probably good for Ubuntu too
<jdub> oh, good
<seb128> s/transition/transtionned/
<seb128> grumpf
<jdub> stupid english rules ;)
<seb128> yeah :p
<seb128> jdub: what build option has to change for next upload? They will probably roll 0.4.0 today or tomorrow
<lathiat> anyone know what libxp-dev's fate was?
* mjg59 should do a usplash upload with the XP splash
<jdub> seb128: i wanted to explicitly add --enable-pixbuf, but we could explicitly enable all of them (though t1 doesn't appear to detect correctly)
* lathiat grins at  mjg59 
<jdub> mjg59: did that image work for you?
<seb128> jdub: k, feel free to change that or I'll do that with next upload
<mjg59> jdub: Which one?
<jdub> mjg59: when i tried it, it looked like it had been dithered again
<jdub> the winxp image
<jdub> i sent you a modified one for testing the indices
<mjg59> Oh, right
<mjg59> Uh
<mjg59> I don't seem to get *any* of your mail
<lathiat> sending from a local smtp server or something? (rbl?)
<jdub> lists?
<jdub> um, sending from a static ip with sane reverse dns, but it is my adsl
<mjg59> I shouldn't be rejecting on that
<mjg59> I shouldn't be rejecting full stop
<jdub> ok, will try test email
<mjg59> mdz hates me :((((((((((
<diensthunds-_> don't worry mjg dpkg hates me
<lathiat> role reversal
<jdub> I have just put on pipy the first version of easy-deb: a tool to make source
<jdub> debs out of standard python modules.
<jdub> woo :)
* jdub hopes it's supersane
<mjg59> jdub: Ok, that worked
<diensthunds-_> ok who's awake and knows how to dev packages?
<diensthunds-_> crap I need somebody good with dpkg
<diensthunds-_> nobody, crap
<Decker|Laptop|Zz> anyone get ubuntu to work with a Dell Inspiron 600m? :D
<diensthunds-_> no but i have it on a compaq right now
<Decker|Laptop|Zz> does your wireless network card work? :D
<diensthunds-_> yes, and I use a pcmcia card too
<sivang> jdub: that's pretty cool, does it use cdbs ?
<jdub> sivang: haven't looked into it too much yet, might do the building itself
<jdub> sivang: meanwhile, do you have much experience with openpower 710s?
<sivang> jdub: basically, yes. I know the HMC and the architecture of operation of the managed system itself, do you have an HMC connected to it or is it a non managed system?
<sivang> jdub: besides experience, I also share a pervert love for those beasties..
<Decker|Laptop|Zz> mine is built in :S
<Decker|Laptop|Zz> centrino 
<jdub> sivang: i don't have an HMC, just serial (and supposedly web, but i haven't been able to connect to that yet)
<jdub> sivang: looks like it doesn't recognise the ubuntu install disk as having an OS on it - i have to figure out what magic RH and SuSE have done to make theirs work :-)
<sivang> jdub: me and colin already discussed that, he said we need to do cherry picking with stuff from the anaconda script
<jdub> aha
<sivang> jdub: IIRC, he also said he'd add -J (that they are using) to our mkisofs script just to try
<sivang> jdub: anyway, try setting the terminal to 19200, N81 and see if it works
<diensthunds-_> jdub did ya get the disk burnt right?
<jdub> sivang: yeah, have full serial access
<sivang> jdub: also, there's usually ONE exact connetor which corrosponds to the default console when no HMC is conencted
<jdub> sivang: the pages of IBM IBM IBM IBM are funny ;)
<sivang> jdub: true :)
<sivang> jdub:  I also don't know how they manage to hid their info from google so good :)
<jdub> diensthunds-_: it's a production CD, but that's not the issue (it's "interesting" hardware)
<jdub> sivang: the console stuff seemsnicely documented on the IBM site
<sivang> jdub: the docs are good , for some of the things - I just couldn't find them through google - I used ibm's search though
<jdub> yeah, dumb ungoogleable web page design
<sivang> jdub: anyway, how can I work with you (or others) about the Ubuntu for pSeries.
<sivang> jdub: am really interested in making it solid and workable
<jdub> well, i have one handy at the moment to test on
<jdub> so i imagine when kamion gets back, i can be he hands and eyes
<mjg59> jdub: Can we fix the installer on x86 laptops first kthxbie
<sivang> lol
<lathiat>  haha
<sivang> jdub: if you set up the console right, and you are connecte to the right connector at the back of the machine,
<sivang> jdub: make sure you press it's front button , if it stalled on booting the service processor
<sivang> jdub: this should bring up the serial console comm , and you will be able to configure boot order and devices, etc
<diensthunds-_> ah well I'm out of ideas
<jdub> mjg59: i don't know, can you? :)
<jdub> sivang: i've done all of that
<sivang> jdub: nothing helps?
<jdub> sivang: the SMS doesn't recognise the OS on the CD
<sivang> jdub: ah :)
<sivang> jdub: k , then it's Colin and his black magic :)
* sivang is tried so I jumped back in time
<sivang> jdub: was the machien purchased for the purpose of supporting that line of hardware?
<lathiat> heh ive been sleeping upside down all week so i need to stay up all day tonight (with no sleep last night) to throw it back aroudn for uni starting again next week :)
<jdub> sivang: no
<jdub> sivang: but i'm going to comandeer it for testing regardless :)
<sivang> jdub: hehe nice, I have a virtualization machien with an HMC, that was the machien where I first saw the SMS doesn't recognize the cd as bootable and with os on it
<sivang> jdub: it a bit more advanced then the openpower. do you have POWER5 + Hypervisor ?
<jdub> dunno
<jdub> does an openpower 710 have a hypervisor?
<toresbe>  v54t6yi\\
<sivang> jdub: seem it does! 
<toresbe> Which, interestingly, is the sound of me almost dropping my keyboard, but saving it, juuust in the nick of time.
<sivang> jdub: then you outta get an HMC
<toresbe> Thank you, you've been a wonderful audience.
<sivang> jdub: then you can have N os's running at the same time, given enough RAM and hd space
<sivang> jdub: and it's all controllable from a Java powered GUI device , which allows you to backup and restore installations into what they call, "
<sivang> jdub: "partitions"
<jdub> yeah, don't think i'm going to get my hands on an HMC
<jdub> i thought the web interface did some of this stuff too?
<sivang> jdub: not really
<jdub> can't talk to it with firefox tho, 'cos it uses some weird encryption protocol
<sivang> jdub: it will allow you to control the service processor,
<sivang> jdub: and view hardware events etc.
<sivang> jdub: well, if you get a machine like that near me , I'm willing to do full time testing on it :) (my work machine is not at my disposal on my free time ...)
<Decker|Laptop|Zz> going to try to run ubuntu again :D
<Decker|Laptop|Zz> on my laptop :D
<sivang> jdub: and install and configure ofcourse..
<jdub> sivang: long way from sydney to israel ;)
<sivang> jdub: true. although, practically speaking IBM Haifa research labs have a couple of machines like that they let ISVs borrow, humrous but maybe worhwhile checking :)
<jdub> sivang: who should i talk to so we can get one on your desk?
<sivang> jdub: well, for that I'd need to follow up tp you next week :)
<jdub> sivang: rock on, let me know
<sivang> jdub: sure thing. I will now go and test if lpi works from an applet, since the build finally succeded.
<sivang> jdub: cheers, laterz (alsoing hitting bed afterwards)
<eazel7> hi ppl
<eazel7> I have an obvious bug here, that seems that I will never solve by reinstalling another thousand times dbus or hal (packages.ubuntu.com says it's in devel/dbus, but I use the latest dbus packages
<eazel7> Failed to start message bus: Failed to open "/etc/dbus-1/system.conf": No such file or directory
<eazel7> I doesn't have that file, how can I get it? somebody had this problem or can help?
<eazel7> (this leads into errors starting hal)
<Keybuk> interesting
<Keybuk> on hoary, libesd-alsa0 doesn't appear to like dmix
<trulux> heya folks
* trulux is back from holidays
<Keybuk> aha!  that's better
<jdub> morning Keybuk 
<jdub> dude, you're on AEST or something
<Keybuk> heyhey mr 'dub
<Keybuk> yeah, on a definite strange timezone kick this week
<bob2> shock! horror!
<Keybuk> I think elmo is spinning my bodyclock off balance by being equally odd
<jdub>   * Add another missing build-depend DANIEL WHY DO YOU HATE ME SO
<jdub> ha ha
<lathiat> haha
<Keybuk> ah, mjg59
<Keybuk> which reminds me, is there an e-mail address that gets all new bug filings?
<elmo> yes
<elmo> oh, new
<elmo> no
<elmo> but there's a debian-bugs-dist equiv
<Keybuk> what were you thinking of?
<elmo> and you can procmail new ones, I think
<Keybuk> what's the traffic level on that?
<elmo> hmm, about the same as ubuntu-users in raw msgs, I think... totally off the top of my head
<elmo> List-Archive: <http://lists.ubuntu.com/archives/ubuntu-bugs>
<Keybuk> "Company Mail: 2 days"
<elmo> haha
<Keybuk> 40-odd a day?
<Keybuk> that's about -changes level
<Keybuk> oh, no, 200 a day
* Keybuk subscribes anyway, I guess the top one of each thread is the interesting one
<Keybuk> *chuckle*
<Keybuk> so today's new Sourcerer/HCT bug
<Keybuk> people who leave .bzr directories in their source packages
<Keybuk> mjg59, come on down!
<Keybuk> elmo: could you make jennifer squeal if sources contain .bzr, {arch}, .svn, CVS, etc. ? :p
<elmo> err, unpacked source?  no
<Keybuk> why not?
<elmo> I don't want people modifying .orig.tar.gz to remove them
<Keybuk> what about the .tar.gz and .diff.gz
<elmo> I could do that I suppose, but would a partial check like that be of any use?
<lathiat> elmo: can you please sync kaffe from unstable, okd by ajmitch
<elmo> lathiat: done
<lathiat> elmo: thanks
<ajmitch> thanks
<Keybuk> hmm, bouncy mdz
<mdz> trying to fix my xchat config
<mdz> it isn't listening
<Keybuk> what's it not doing?
<Keybuk> I've had problems before where x-chat doesn't actually seem to save shit
<Keybuk> usually the server list
<mdz> <%0Keybuk> usually the server list
<mdz> that's what it's doing at the moment
<mdz> trying to mangle my pevents.conf to get the <> back
<Keybuk> %C18%B%B$4$1%O%C18%O$t$2
<Keybuk> appears to be my value
<Keybuk> I'm not entirely sure what all that gibberish means :p
<Keybuk> though I don't have < or > around the nicks because I use the side-tray mode thing
<mdz> do you get angle brackets around people's nicks?  that's what I want
<mdz> side-tray mode thing?
<Keybuk> the default mode, the nicks are right-aligned against a bar
<Keybuk> so I see something like "    mdz|side-tray mode thing?"
<mdz> yeah, that's what I have too
<mdz> but I still want the <>
<mdz> so that I can cut and paste them and things make sense
<Keybuk> add < and > around the string above?
<mdz> working on it, %0Keybuk ;-)
<mdz> for some reason it's passing my %0 literally
<mdz> event_text=%C18%B%B$4%C2<%0$1%C2>%C18%O$t$2
<mdz> that's what I'm using
<Keybuk> do you mean %C0 ?
<mdz> I don't think so; all of the other strings say %0
<Keybuk> or %O ?
<Keybuk> 0 != O
<mdz> oh
<mdz> say something
<Keybuk> you know there's a dialog to edit that kind of stuff?
<mdz> perfect
<mdz> now to me?
<Keybuk> mdz: foo
<mdz> hmm, missing in that one
<Keybuk> that's Channel Msg Hilight
<Keybuk> Settings -> Advanced -> Text Events
<Keybuk> it lets you try them out too
<mdz> to me again?
<Keybuk> to you, to me
<mdz> mdz: hi
<mdz> doesn't work when I do it
<Keybuk> mdz: you sound like you're suddenly in the chuckle brothers
<Keybuk> Keybuk: hi
<Keybuk> heh, no, it appears to not do self-hilighting
<Keybuk> which is probably sensible
<mdz> there are just way too many strings here
<Keybuk> there's also the Private Message to Dialog
<mdz> oh, how clever
<Keybuk> and probably you want to change Your Message too
<mdz> they don't take effect when you click "save"
<mdz> or "ok"
<mdz> you have to press enter in the text bxo
<Keybuk> yeah, you have to press enter
<Keybuk> silly innit
<mdz> someone say my name
<milli> mdz: my name
<mdz> perfect
<mdz> thanks
* mdz backs up pevents.conf in the "this took WAY TOO MUCH WORK" config file backup repository
<Keybuk> Company X-Chat Text Formatting: 1 hour
<milli> lots of rope to play with in X-Chat
<fabbione> morning guys
<Keybuk> morning dude
<lamont> checking for life_signs in -lkenny... no
<lamont> oh my god! They killed kenny
<lamont> You bastards
<lamont> checking for main in -lz... yes
* lamont LOL
<Keybuk> oh, dear
<Keybuk> autoconf humour is so 1980s
<jdub> yeah
<jdub> but it makes a less depressing topic than libtool humour
<ajmitch> what, you're saying that libtool is a joke? 
<daniels> no, it's a fool
<fabbione> mdz: ping?
<mdz> fabbione: pong
<fabbione> mdz: see /msg
<fabbione> jbailey: ping?
<fabbione> jbailey: ping?
<fabbione> jammcq: ping?
<pitti> Morning
<mvo> monring pitti 
* pitti yawns, I should go to bed earlier
<tepsipakki> how do I report a bug for a package that is in universe and not found on malone, either?
<fabbione> hey pitti
<jammcq> fabbione: hey
<fabbione> hey jammcq !
<jammcq> what's going on?
<fabbione> jammcq: may i disturb you a few minutes?
<fabbione> if you have time..
<\sh> tepsipakki: file a bug against malone to include the package
<\sh> tepsipakki: or bug one of the launchpad guys in #launchpad
<jammcq> umm, it's almost 3am here, my mind isn't fully functioning, but go ahead :)
<\sh> morning gentlemen btw
<mvo> morning \sh 
<fabbione> jammcq: a friend of mine and I were searching 2/3 thinclients to buy to setup for our wifes (and one for me)..
<fabbione> jammcq: i was wondering if you can put me in the right direction on where and what to buy
<jammcq> ok
<fabbione> jammcq: and if you have any idea on how much they cost
<tepsipakki> sh: thanks, will do
<jammcq> fabbione: well, my opinions are biased, cuz we sell them.  But my favorite is the T-150, it goes for $279
<fabbione> jammcq: if you sell them it's even better :)
<jammcq> it's got room inside for a 2.5" hd, or a pci card, or compact flash
<fabbione> jammcq: do you have an URL where i can see it?
<jammcq> http://www.DisklessWorkstations.Com
* fabbione checks
<fabbione> jammcq: 150 or 105e ?
<fabbione> meh.. 150e
<jammcq> the 150 has PXE, the 150e has Etherboot
<jammcq> PXE is prolly all you need
<fabbione> yeah PXE is perfect
<jammcq> yeah, plus it's 15 bucks cheaper :)
<fabbione> it looks really neat
<jammcq> yeah, nice and flexible.  it's a 533Mhz via.  If you want 1ghz, that would be the T-170
<jammcq> basically the same box
<fabbione> jammcq: does it make sense to have 1Ghz to execute stuff on a server?
<jammcq> 1Ghz is a waste, if you want to just run the kernel and Xserver 
<jammcq> which is what 99% of the ltsp people do
<fabbione> that's what i tought
<fabbione> jammcq: that's all i wanted to know :))))
<jammcq> ok, with that.... I'm going to bed
<jammcq> see you later
<fabbione> jammcq: in case we decide to go, can i order them via you?
<fabbione> sure.. good night :)
<jammcq> order them on the site
<jammcq> we ship anywhere
<pef> hello
<fabbione> jammcq: ok perfect..
<jammcq> ciao
<fabbione> jammcq: i was more interested to get them at UBZ to save some shipping money ;)
<fabbione> ciao ciao
<jammcq> ah
<jammcq> yeah
<jammcq> we can figure out a way to get some of them to CA, and let you carry them home with you
<fabbione> jammcq: that'd be great, i will look and let you know :)
<fabbione> thanks again
<fabbione> and good night
<jammcq> okie dokey
<jammcq> see you later
<fabbione> later
<Keybuk> UBZ is probably too soon after release to get many CDs, if UDU was anything to go by
<Keybuk> we had a few boxes, but not enough for more than one or two per person
<Keybuk> gah, ww
<fabbione> hmmm
<pitti> Moin sabdfl 
<sabdfl> moin moin
<fabbione> morning sabdfl!
<sabdfl> fabbione: what rocks in breezy land today?
<Treenaks> sabdfl: normal rocks or crack rocks? ;)
<fabbione> sabdfl: good test results from breezy install tests, livecd tests, hoary -> breezy upgrades...
<fabbione> oh.. LTSP tests = teh r0ck!
<fabbione> starting clustering tests right now
<sabdfl> that's pretty rockful
<Treenaks> my old laptop works (100 - winmodem)% out of the box :)
<Treenaks> so that's at least 1
<doko> Mithrandir: time for an ooo2-amd64 update?
<fabbione> sabdfl: yeps.. looks pretty good
* jdub is making ltsp clients as a welcome home present for pia (only a weekend away, you see)
<Treenaks> jdub: are you wrapping them up and putting ribbons around them as well? :)
<fabbione> jdub: yeah.. it's pretty neat :)
<Keybuk> Treenaks: knowing jdub, probably
<jdub> yeah, have ribbon :)
<jsgotangco> hmm the daily build today is wonderful
<Treenaks> jsgotangco: *rsync*
<jsgotangco> Treenaks, yup
<Treenaks> I wonder where my utmp went though..
<jsgotangco> i just use a rewritable for maximum cost efficiency on testing
<jsgotangco> heh
<Treenaks> jsgotangco: yeah, so do I 
<Treenaks> they're a bit slow though
<jsgotangco> true
<jsgotangco> Treenaks, i still get #14007
<Treenaks> jsgotangco: that's probably because Kamion is on honeymoon :)
<Treenaks> jsgotangco: I added a few comments to the bug yesterday
<jsgotangco> oohh i just updated a few minutes ago and now we have OOo2 updates :)
<Treenaks> jsgotangco: could you test if the Gnome network tool thingy adds the "restricted" part in /etc/network/interfaces?
<jsgotangco> no it didnt i tried it
<Treenaks> (I'm at work atm, so I'm not near my laptop..)
<jsgotangco> i just tried that
<jsgotangco> (i tried doing it first in gnome)
<Treenaks> jsgotangco: could you file that bug? :)
<sabdfl> doko: great work on the new openoffice
<mdz> sabdfl: with launchpad integration, no less
<doko> sabdfl: thanks, help packages will come next week
<jsgotangco> err guys what is hpiod and hpssd for? it installed by default in the daily build
<mdz> jsgotangco: drivers for HP printers
<Keybuk> jsgotangco: HP printer things
<bob2> lathiat: put your mdns stuff in debian already
<mdz> jsgotangco: you tested the install CD or the live CD?
<jsgotangco> mdz, install
<jsgotangco> mdz, worked flawless except xresprobe
<mdz> that's from the CD overflowing
<mdz> I thought pitti dropped some more langpacks to make space, though...
<Keybuk> oops
<pitti> mdz: I did
<mdz> pitti: at what time of day?
<Keybuk> it's all those configurable x-chat strings
<pitti> mdz: however, there are not yet 20050826 images
<pitti> mdz: maybe 12 hours ago, when we talked about it
<mdz> heh
<mdz> the daily build is scheduled to run in 1 minute
<mdz> 20 seconds
<pitti> hehe
<mdz> so I will not bother kicking off a manual build
<pitti> mdz: I removed almost all langs but the "top 10", so please let me know if it still overflows
<mdz> sabdfl: the badger is somewhat heavyset
<Keybuk> what do badgers eat?
<mdz> software developers
<Treenaks> Keybuk: mushrooms?
<mdz> schnaaakes?
<mdz> that site is the #1 google hit for "badger"
<mdz> but we are #4 for "breezy" ;-)
<HrdwrBoB> badgers eat mushrooms, but run from snakes
<mdz> it all makes sense now
<Keybuk> http://www.whatbadgerseat.com/
<jdub> hrm, haven't seen the clint eastwood film though
<mdz> I fully expected that to NXDOMAIN
<mdz> but it didn't
<doko> mdz: on the German google site breezy is #1 and #3, badger is #4
<HrdwrBoB> yes, w t f
<Keybuk> no, that's quite bizarre
<jdub> ha ha
<Keybuk> it seems to be Simpsons related
<jdub> "Breezy is a teen-aged hippy with a big heart. After taking a a ride with a man who only wants her for sex, Breezy manages to escape."
<Keybuk> "breezy is a natural born show girl with lots of appeal and has outstanding coat
<Keybuk> "
<sabdfl> daniels: is it tricky to install the newer ati driver from source?
<daniels> sabdfl: shouldn't be, no, as long as you have the headers for your kernel installed
<jsgotangco> Breezy circa 1973?
<jdub> http://www.dapper.com/ <- looks more like a joke company from GTA than a real clothing store
<mdz> "breezy is now pregnant"
<mdz> that explains why the CD overflowed
<jsgotangco> haha
<jdub> mdz: we'll have to slip by nine months :)
<Treenaks> jdub: http://tinyurl.com/2emz3 (use babelfish if you don't understand)
<daniels> sabdfl: they have a spiffy point-and-drool driver install now that spits out Ubunturific packages
<sabdfl> daniels: seriously?
<daniels> sdbyeah
<daniels> er
<daniels> sabdfl: ^^
<sabdfl> hmm. cool.
<Keybuk> "breezy is a hopeless single mother trying to scam a free place to live"
<Keybuk> googlism is fun
<\sh> http://www.beejaysworld.de/archives/52-I-dont-care-how-cool-Ubuntu-is!.html
<\sh> this is a good one...I'm realy disappointed that it comes from a "known by me" gentoo dev
* jsgotangco reads with interest
<\sh> spreading FUD, he is frightend that ubuntu drains away gentoo devs ,-)
<mvo> \sh: kick him hard
<jsgotangco> dubious?
<\sh> please read the PS
<\sh> mvo: there is no need...many of the german gentoo devs are running ubuntu on their laptops *lol* or going to test it...
<jdub> daniels: page only mentions RH and SUSE - has that changed?
<\sh> but it has nothing to do with ubuntu as linux distribution
<mvo> \sh: it was always beyond me why someone would want to run gentoo on a laptop
<Keybuk> ask him to make the "Ubuntu" a link to www.ubuntu.com
<Keybuk> otherwise looks like a fairly common blog post in some quarters
<Keybuk> :)
<daniels> jdub: spits out packages for != supports
<\sh> mvo: I ran it for quite a while
<Treenaks> Keybuk: breezy is a very sensible girl
<Keybuk> there were a lot of Debian posts like that 6 months ago, thankfully Debian seems a little fluffier towards us recently
<HrdwrBoB> \sh: just because everyone tells me it's good, doesn't mean it's good, and even if it is, I don't like it waaaaah
<\sh> HrdwrBoB: there is no such thing like "good distribution" or "bad distribution"
<jdub> daniels: debs?
<\sh> HrdwrBoB: I'm old enough to judge only on this: "it works" or "it doesn't work" and I need my OS "just working" so..."insert cd and be happy"
<pitti> doko: here?
<HrdwrBoB> \sh: that's where it's at
<daniels> jdub: yes
<doko> pitti: 30minutes
<daniels> jdub: the installer wraps everything up -- including the kernel module it just built -- into a nice little deb
<mdz> Keybuk: that's because they've gotten a taste of true evil
<mvo> daniels: does it work well?
<Keybuk> mdz: you mean your singing? :)
<jdub> mdz: we should've had UBZ in vancouver
<daniels> mvo: don't know, I don't use binary drivers
<jdub> and nicknamed it UVP
<daniels> vp?
<jdub> vancouver prospectus :)
<HrdwrBoB> ubuntu versus predator?
<jsgotangco> hah
<daniels> jesus
<daniels> no thanks, we don't need any more cabalisms
<jdub> HrdwrBoB: no match, dude.
<Treenaks> daniels: I have to use the binary driver on my TestingTeam laptop
<jsgotangco> vancouver party?
<Treenaks> vancouver purge?
<Keybuk> Vancouver Proposal wasn't it?
<daniels> Treenaks: the ati one?  is it an x300?
<daniels> Treenaks: if so, I'm debugging that particular hilarity with mjg59
<Keybuk> though it's Vancouver II: Helsinki (this time, it's personal)
<daniels> Treenaks: but he's a student, so he's not awake yet
<daniels> daniels@ephemera:~/canonical/xorg/monolith/xorg-6.8.2/debian/patches/merge% wc -l * | tail -1
<Treenaks> daniels: No, it's a FireGL V5000 or something
<daniels>   570 total
<daniels> ^ code patches we have to xorg not merged upstream
<Treenaks> daniels: but it's PCIE too
<daniels> Treenaks: hm.  does XaaNoScreenToScreenCopy and XaaNoSolidFillRect (device section) fix it?
<Treenaks> daniels: it doesn't crash, it just looks like a sync problem
<Treenaks> (yes, on an LCD)
<Treenaks> daniels: I'll post a Xorg.0.log tonight, it does complain a bit
<daniels> Treenaks: ah, bong
<Treenaks> something about guessing dotclocks :)
<Mithrandir> doko: is m125 in yet?
<infinity> Mithrandir : yes.
<pitti> Hi carlos 
<carlos> pitti, hi
<doko> Mithrandir: yes, some more things ...
<doko> Mithrandir: new libs for ia32-libs: portaudio at least
* jdub growls at OOo
<doko> Mithrandir: OOo1 currently doesn't run, don't know, if you did drop some libs, but it would be good to have that again
<Mithrandir> doko: I didn't drop any libraries, no.
<doko> Mithrandir: strange, maybe just an OOo1 update should be enough
<doko> Mithrandir: martink did suggest adding the gtk2-engines to ia32-libs-openoffice for the font problem
<doko> see http://people.ubuntu.com/~doko/Screenshot.png
<Mithrandir> doko: for what font problem?
<Mithrandir> doko: ah, never seen that one.
<doko> it's amd64 only
<doko> Mithrandir: not sure, if it's related to the gtk updates, but recent libs shouldn't hurt
<mdz> pitti: CD 1 will only be filled with 619844588 bytes ...
<Mithrandir> mdz: yay
<Mithrandir> mdz: please tell me when it's ready for testing.
<pitti> mdz: ok, so I can add some more packs after UI/translation freeze, good :)
<mdz> Mithrandir: waiting for jigdo *snore*
<pitti> mdz: jigdo is essential... :-)
<mdz> jigdo is a waste of time
<Mithrandir> any reason we don't use Sledge's patches to make mkisofs spit out jigdo as it goes?
<mdz> it takes several minutes to run for each image
<mdz> x8 images = too long
<mdz> Mithrandir: I'm thinking of uploading a jigdo which quietly uses rsync instead
<Mithrandir> heh
<mdz> cdimage   7199 44.1  0.7  23048 16012 ?        R    08:51   2:29 jigdo-file
<mdz> that's been running for 7 minutes working on one iso
<mjg59> mdz: Hi
<mdz> more time is wasted during the CD builds than anyone saves on downloads :-P
<mdz> mjg59: good morning
<infinity> Spoken as a man who's never lived in Australia.
<infinity> WE HAVE NO BANDWIDTH, HAVE PITY ON US!
<daniels> yes.
<opi> hi guys
<pitti> mdz: it's the way that saves most bandwith, for us quota-impaired folks...
<Mithrandir> pitti: hmm, doesn't rsync work just as well?
<pitti> Mithrandir: nope
<mdz> I don't see how it saves bandwidth
<mdz> compared to rsync
<pitti> Mithrandir: jigdo can additionally scan /var/cache/apt/archives, dvd images, CDs from other arches
<pitti> mdz: ^ 
<mdz> you need to use bandwidth to keep your mirror up-to-date
<infinity> Right, but you don't have to use it twice, then, do you?
<mjg59> mdz: You were after me last night
<infinity> If you have a mess of packages that may be jigdo-useable, why re-download them to get a CD?
<mdz> mjg59: ah
<daniels> mdz: yes, which solves the problem of CDs and actual use of systems in a single swoop
<pitti> infinity: I tried apt-cacher, but it's broken
<mdz> mjg59: when you said it was time to finish usplash, did you mean "I am going to do it" or "I know that it needs to be done but someone else needs to do it"?
<infinity> Alos, you can jigdo from "quota-free zones" where people rnu Ubuntu package mirrors, but not CD mirrors.
<infinity> Lots of providers here have certain peering links that are quota-free, and it's nice to not leave that network if you don't have to.
<daniels> (given that we actually get metered on our bandwidth usage as well as getting shit-all in terms of speed.)
<mdz> unless you mirror only what's on the CD, you end up downloading a lot of extra stuff you don't need
<pitti> infinity: another thing is that rsync is much slower than http here (QoS on my provider's side)
<daniels> mdz: err, between an X maintainer and a buildd maintainer who also does a lot of transitions, I'm willing to bet the entire archive has been apt-get source'd and upgraded by now
<mdz> I will come and visit each of you, and feed out a spool of cat5 behind me as I go
<infinity> HTTP is QoSed higher than everything else?... I guess that makes sense when your core business is running an ISP for mom and dad surfing eBay...
<pitti> mdz: yay :)
<daniels> mdz: (not to mention, amd64 x2, i386 x2, powerpc x2, sparc x1.)
<mjg59> mdz: I'm not sure I especially want to upload critical lsb type stuff
<pitti> infinity: they slow down all high ports to keep P2P under control
<pitti> infinity: and apparently also rsync
<daniels> morning sebarino
<infinity> mjg59 : I'll attack LSB for me, just feed me pretty patches and I'll look them over and take the rap for breaking it. :)
<mdz> Diziet: ping
<infinity> pitti : Ahh, that makes sense.  rsync-over-unencrypted-ssh? :)
<mjg59> infinity: Basically, the log_* calls just need to call usplash_write with appropriate arguments
<pitti> infinity: some of this works, yes; but jigdo is so much faster and easier, so why bother? :-)
<daniels> infinity: either that, or just tunnel to chinstrap and rsync from there.
<daniels> although elmo may kill you
<infinity> mjg59 : Might be nice if I knew what those appropriate args were. ;)
<infinity> mjg59 : And what's our scientific method for determining if we're in a splash environment or not?  Or does usplash_write take care of echoing to the terminal if the splash is dead?
<daniels> infinity: whether or not 'splash' (or 'usplash') is passed on the kernel boot line
<infinity> daniels : Uhm, that's not helpful in the least.
<infinity> daniels : In the boot case, the splash could die, and I'd like output.  But more importantly, those same calls are made from init scripts at runtime when I do /etc/init.d/foo restart on the command line.
<mdz> infinity: usplash_write silently fails if usplash isn't running
<mdz> infinity: so you just need to be sure to keep going if usplash_write isn't around or fails in some weird way
<infinity> "silently"?... No return code I can check?
<infinity> How do I get output from an init script when I invoke it manually, then?
<mjg59> infinity: usplash_write will deal
<mjg59> Don't replace anything, just add a usplash_write
<mdz> infinity: you don't care if it fails; just keep going
<mjg59> (if it exists and it executable)
<infinity> Oh, right.  Wasn't on the same wavelength.
<infinity> I output to the console and usplash.  Check.
<infinity> I should start drinking coffee in the "mornings"...
* daniels coughs.
<opi> infinity: It's good for you. :-)
<mdz> infinity: if this bit goes well, there are apparently hooks for a progress bar as well
<daniels> opi: yes, and then kills you when you come off it
<mdz> mjg59: does the progress bar stuff work?
* opi takes a look at his Ubuntu mug with coffee
<infinity> mjg59 : Alright, will hack at lsb in a bit, remove vga= from my cmdline, and see what happens.
<infinity> mjg59 : Oh wait, does usplash_write actually work yet
<infinity> mjg59 : ?
<mdz> infinity: yes
<mdz> the message drawing stuff works; I tested it
<infinity> Alright, cool.  Will make changes and test, then.
<opi> infinity: life will kill you eventually ;>
<mdz> but I didn't mess with the progress stuff
<infinity> All in good time.  We have no progress bars now either, so no loss if they're not there in the first try.
<mjg59> infinity: Yes
<mjg59> infinity: README.usplash has the commands
<infinity> mjg59 : Rock.
<mjg59> Don't worry about making it look perfect yet, we can worry about that later
<infinity> Now I kiss my 1400x1050 vesafb goodbye for a few days while I polish this, I guess.
<opi> morning sabdfl
<Treenaks> mdz: is the CD build done yet?
<mdke> siretart, i've had no response from the debian maintainer about updating ddclient :(
<siretart> mdke: :(
<mdke> siretart, is there nothing that can be done?
<siretart> mdke: can you prepare a package for that?
<mdke> siretart, no :/
<mdke> i don't know how
<siretart> mdke: I'd suggest asking in #ubuntu-motu someone with enough time to do that. But updating stuff is not our priority right now
<infinity> mjg59 : I assume we need/want to QUIT usplash in an init script right before [gk] dm launch?
<mjg59> infinity: No, it catches the VT switch
<infinity> Ahh, so QUIT is mostly for testing?
<mdke> siretart, ok i will try!
<mjg59> infinity: Yeah
<infinity> mjg59 : Excellent.
<jsgotangco> hey AndyFitz 
<AndyFitz> g'day jsgotangco
<mdz> Treenaks: yes
<mdz> pitti: CD build is done
<mdz> Mithrandir: ^^
<jsgotangco> nice
* jsgotangco grabs
<Mithrandir> mdz: yay, I'll test it RSN, then.
<mdz> pitti: looks like powerpc overflowed
<mdz> CD 2 will only be filled with 4333104 bytes ...
* pitti kicks out some more...
<Mithrandir> mjg59: the x86emu version and the lrmi version are running different interrupts, but both seem to work in 32 bit mode at least.
<mjg59> Mithrandir: Right. They really shouldn't be running different interrupts.
<Mithrandir> mjg59: hmkay.
<mjg59> But I'm not sure how to track down why they are doing so
<mjg59> Other than disassembling your video BIOS...
<Mithrandir> heh
<Mithrandir> I'd like not to.
* infinity would really like to replace GAIM's tray icon with one that actually matches the style of everything else in his notification area.
* infinity stares at AndyFitz.
<sivang> morning all
<sivang> seb128: Bon Jour :)
<mae> Err I'm not sure if this will be very helpful to you guys, but I am testing out breezy colony-3 .. i have the latest up-to-the-minute packages installed.  So far I have noticed: Totem/Rhythmbox/Sound-Juicer _all_ crash right when you start them.. I was wondering If this is maybe a localized bug to my system or if others were experiencing the same thing
<seb128> sivang: hi
<mdke> mae, things are working here
<mae> hrmm
<mae> ok i'll try a settings wipe
<sivang> seb128: I got over that problem I was having, I was breaking the order of pathches to configure (there was more then one) so whem I fixed that, it worked.
<seb128> k
<jsgotangco> hmmm it seems the graphics for the update-manager notification is messed up?
<mvo> jsgotangco: yes, #14006
<seb128> how so?
<mvo> iz gtk bug :p
<seb128> oh, that
<jsgotangco> ahh
<seb128> hey mvo :)
<mvo> hey seb128!
* sivang needs a new keyboard :-/
<{Seb}> jbailey told me a command a while ago to create a *.img file with initramfs
<{Seb}> and i've forgotten it
<{Seb}> i'm on rescue mode and need to generate a new one
<jdub> mkinitramfs -o <file>
<{Seb}> that's the one jdub :-)
<{Seb}> thanls
<{Seb}> just the initramfs included with Colony 3 buggers up my laptop
<{Seb}> since it is missing the atiixp module which jbailey has fixed in the latest initramfs-tools
<sivang> is it too soon to plan BOFs for UBZ ?
<AndyFitz> infinity:  you're not the only one .   sadly the icon theme in gnome can't replace this...   I'll send the pixmap to you if you can make it happen
<AndyFitz> heh id like to see the day that ubuntu-artwork uses  replaces on gnome-panel  or gaim rather
<infinity> AndyFitz : I can make it happen for Ubuntu, so long as someone doesn't cosider it a "frozen feature"  (I assume it would be subject to the artwork deadline, though)
<infinity> The icon is probably compile dinto the GAIM binary, so won't be in -artwork.  That's just a guess, though.
<mae> Is the breezy usplash supposed to be "ugly" at this point?  All I get on startup is a really rough ubuntu logo with low color and a fuzzy white box at the bottom which is blank :)
<infinity> I'll look at it when I have a round tuit, if you want to mail me the pixmap.
<Mithrandir> mae: yes.
<infinity> mae : Deuglification is in the works as we speak.
<mae> Mithrandir, ahh ok good :) I wanted to make sure that wasn't a bug
<infinity> mae : But it's currently supposed to do pretty much nothing, yes.
<Mithrandir> mae: well, it's a bug, but we're working on it.  More of a "not implemented completely yet" thing, actually.
<infinity> AndyFitz : ---^
<AndyFitz> infinity. there are 4 states of that icon.  that would be really easy to make up considering I already have the 24x24 version of the gaim icon
<mae> Mithrandir, right, if it was a bug for maybe my hardware I wanted to report it, thats all :)
<infinity> AndyFitz : Mail me what you've got.  I'd like to see it suck less.  Well, it doesn't currently "suck", it just sticks out like a sore thumb next t oeveyrthint else up there.
<AndyFitz> jdub,  whatever happened to  16x16, 22x22 and 24x24 pixel versions of the ubuntu logo with alpha for the panel 
<AndyFitz> infinity, pm me your email
<infinity> adconrad@ubuntu.com
<infinity> It's not much of a secret. :)
<AndyFitz> lol
<sivang> jdub: re: CHRP ubuntu booting, I expect to be releasing something at work on monday, so I'll have more time on my hands, I may try the cherry-picking Colin suggested, between the flags we use and RH do in their mkisofs scripts... hopefully a booting image will come out.
<jdub> sivang: dude! was just about to ping you
<jdub> sivang: so opensuse just released a PPC build that works on pSeries
* jdub is sucking it down now
<bob2> you have a pSeries to test it on?
<jdub> yeah
<sivang> bob2: I do, but not at home.
<jdub> it is sitting on the coffee table
<infinity> jdub : Dude, want to send it to Melbourne for safe keeping?
<bob2> it IS the coffee table!
<sivang> jdub: well, that's interesting. They finally allowed the community to use the stuff they put in SLES9 :)
<jdub> naw, it's just a 2U, very light
<jdub> it has matrox!
<sivang> jdub: I'd say they have identified someone doing things in a specific direction, and try not to be left out :)
<jdub> :)
<sivang> hey guys, there a line.. I asked jdub first :)
<siretart> bob2: ping. Any news about lyx?
<Mithrandir> mjg59: so, after the first instruction, the state looks the same, except eflags differ (which I think is significant, but I'm unable to find a comprehensive guide on the different eflags' meanings) and the esp is different, but I assume that can be ignored?
<Mithrandir> mjg59: ah, iopl seems to be missing.  I'll see if I can hack around that.
<mjg59> Mithrandir: eflags can probably be ignored, but it implies that we may not be setting it equivilently
<mjg59> Oh. Uhm?
<mvo> I get a /etc/hotplug/net.rc conffile question on hoary->breezy upgrade. is this a known issue?
<seb128> grep: /usr/lib/libgtkhtml-3.8.la: No such file or directory
<seb128> /bin/sed: can't read /usr/lib/libgtkhtml-3.8.la: No such file or directory
<seb128> damn
<seb128> and "grep -i gtkhtml /usr/lib/*.la" or "grep -r -i gtkhtml *" on the source package returns nothing
<seb128> where does evolution-exchange picks that!
<seb128> /usr/lib/evolution/2.4/*.la ... grumpf!
<Mithrandir> mjg59: uhm on the stack pointer thing?
<{Seb}> when i run run mkinitramfs -o initrd.img-2.6.12-386 from the rescue shell
<{Seb}> nothing is generated
<sivang> jdub: check if that opensuse can be used as a VIOServer for that matter, if it does then you can save the costs of buying AIX VIOServer, and then when you'll have the HMC You could have 3 ubuntu version running in parallerl, + one for building.
<jordi> pitti: I have a mission for you.
<{Seb}> it says "cpio: ./initrad.img-2.6.12-6-386: mtime changed during copy-out"
<pitti> jordi: ?
<sivang> jdub: btw, it just hit me :) the hmc is built to be administrated from remote over a net.
<{Seb}> any ideas why?
<jordi> pitti: so the Asturian guys are going to translate Ubuntu, but they lack a locale definition.
<jordi> pitti: Carlos tells me that if Breezy has no langpack for ast, it won't be in the release at all.
<pitti> jordi: we can create a langpack for them 
<jordi> Can we create an empty one, until I write (or find) a locale data file for ast to get included later on the langpack?
<carlos> pitti, will you do that post release?
<jordi> pitti: it would be mostly empty at release time
<mjg59> Mithrandir: On the iopl thing
<pitti> carlos: probably not, no NEW packages in -updates
<carlos> pitti, that's what I thought
<jordi> pitti: ok, so if it could be added before the release, even if it has little or no content, we could work around that.
<jordi> pitti: also, they have no locale data, but I'm willing to write it for them.
<jordi> Would that fit (/usr/share/i18n/locale/ast_ES) in a langpack?
<Diziet> Morning, people.
<pitti> jordi: uh, there is not even an official locale for it? darn,
<pitti> I thought you meant an official langpack
<pitti> Hi Diziet 
<carlos> jordi, perhaps you should provide that language pack as an unofficial version and add it officially for breezy+1...
<jordi> pitti, carlos: if I can do something to make their breezy translations usable for breezy, I'd like to do it.
<jordi> pitti: I could try to write the file over the weekend, if it's not late to such patch in ubuntu's glibc.
<pitti> add a locale? that shouldn't bee too problematic
<pitti> however, it also requires installer changes
<seb128> jordi: you patch the libc now, scary :p
<lathiat> bob2: i cant put it in debian, because need of dbus 0.3x and python2.4-gtk2, i think 0.3x is in experiemntal but python2.4-gtk2 is not
<lathiat> bob2: will be i breezy shortly however
<jordi> seb128: evo was boring enough :)
<jordi> pitti: I could talk to Kamion about that.
<seb128> jordi: dunno if you noticed yesterday but people start pinging you about evo issues :)
<jordi> seb128: I saw them, and I decided to keep quiet because I don't know what they are talking about
<seb128> haha
<seb128> sucker :p
<jordi> seb128: GNOME crashes in Debian seem to be generalised though. Is it something about the C++ transition or what?
<seb128> you want to maintain evo, just assume now, BE A MAN
<jordi> pitti: but even if di has no ast support for breezy, having the langpack would be good. They can install in Spanish, use it in Asturian or wrhatever for now.
<seb128> jordi: what crash? There is no special activity on the alioth list ...
<jordi> They won't have time to translate the installer anyway.
<pitti> jordi: right
<jordi> seb128: there was a guy asking about random crashes here and there the other day, and I've seen others.
<pitti> jordi: so if you want to do the glibc change (send it to jbailey) to add the locale, I'll build langpacks
<jordi> maybe it's glibc
<jordi> nano is crashing now too.
<jordi> pitti: great. What's my deadline?
<sivang> pitti:<curious> what sort of libc changes adding the locale requires? </curious>
<seb128> pitti: have you planned a language-pack update? We have GNOME 2.11.92 complet, would be nice to give a translation update for translators
<jordi> sivang: adding a file with some data about the language.
<jordi> sivang: see /usr/share/i18n/locales/he_IL
<sivang> jordi: libc takes it's locale sepcific data from there? 
<sivang> seb128: patching one of gnome-panle, opens the gnome-panel page in launchpad - is this correct? (IMHO it is, since it's part of that package, and if it opens gnome-applets for it's applets, that's also fine)
<Mithrandir> mjg59: also, the VM and AC flags are set in LRMI mode, but appears not to be set in x86emu mode.
<sivang> (I just did the clock applet)
<jordi> sivang: that text file gets compiled with localedef, yes.
<mjg59> Mithrandir: I'd guess that the VM flag signifies that it's in cm86 mode. Not sure about the AC flag.
<Mithrandir> mjg59: AC : Alignment Check. Set if alignment checking in of memory references are done.  ; that can probably be ignored
<Mithrandir> mjg59: but shouldn't the vm flag be set the same in both occasions?
<mjg59> Mithrandir: Uhm. Well, in one case we're in vm86 mode, in the other we aren't
<mjg59> You could try setting it, I guess?
<seb128> sivang: what applet?
<{Seb}> with the latest g-v-m, the cd mounting is buggered up
<{Seb}> i can't eject CDs
<{Seb}> i can't mount CDs
<pitti> {Seb}: g-v-m doesn't eject
<pitti> eject is broken on i386 for some time already, pro'lly a kernel problem
<pitti> I will take a look at that soon
<{Seb}> but it physically won't do it
<pitti> {Seb}: however, mounting should work
<pitti> can you please file a but about the mounting?
<{Seb}> but the drives won't eject so i can't get a disk in ;-)
<{Seb}> yeh
<pitti> right
<pitti> there's already a bug
<{Seb}> oh bugger, i can't get my disk out :-(
<sivang> seb128: clock applet
<seb128> that's a gnome-panel applet, it's correct
<jdub> pitti: thought - the sound capplet device list doesn't include subdevices
<sivang> seb128: cool, then all left is to patch the remaning applets. I just hope that gnome-panel product in launchapd will include the aplets that come with it
<pitti> jdub: hm
<jdub> pitti: to get spdif output on my nforce device, i use a subdevice
<jdub> just a thought :)
<seb128> sivang: there is one .po for all the gnome-panel binaries 
<sivang> seb128: cool
<sivang> seb128: then we're set
<seb128> pitti: did you reply to my language-pack update question?
<Mithrandir> mjg59: hm, no, since x86emu only gives us 16 bit, it doesn't have eflags, just flags.  AIUI?
<seb128> jdub: do you know who the heck did change #commits on gnome IRC?
<jdub> seb128: no, don't know anything about it
<seb128> bah, thanks anyway
<jdub> seb128: oh
<jdub> does the change involve getting too many commit messages?
<sivang> for laptop testing team, does anyone has a good suggestion for a machine that would be useful for testing? (I'm planning to get myself a laptop of my own, finally)
<seb128> jdub: they changed it to CIA like the freenode #commits
<jdub> oh, no idea
<seb128> jdub: which sucks a lot, I would /j the freenode one if I wanted to know what gentoo partages are changed by example :p
<jdub> sivang: the problem with that question, is that the only kind of laptop worth suggesting for testing is one that doesn't work very well :)
<jsgotangco> hah
<jsgotangco> Toshiba with SATA
<sivang> jdub: hehe, well, if it allows me to use mutt , connect to network, and hack on code that's enough, plus those usually have really neaty feature usually :)
<sivang> jdub: I wish I pegasos would have released their ppc laptop already, that would be a good candidate
<sivang> s/I//
<sivang> jsgotangco: you have a link?
<Mithrandir> mjg59: hmm, is it on purpose that you don't call X86EMU_setupMemFuncs
<mjg59> Mithrandir: Not sure
<Mithrandir> mjg59: which means? :-)
<mjg59> Mithrandir: I can't remember :)
<pitti> seb128: which question again?
<seb128> pitti: <seb128> pitti: have you planned a language-pack update? We have GNOME 2.11.92 complet, would be nice to give a translation update for translators
<pitti> seb128: oh, I didn't even see that, sorry
<seb128> np
<pitti> seb128: yes, I can update them
<pitti> seb128: I will see how big updates will get, maybe I do new base packages
<seb128> cool, thanks
<carlos> pitti, after the first review of the diff you gave me, the only problem is the missing whitespace problem, the extra plural form header and the format change (the msgstr "foo" vs. msgstr ""\n"foo" ), the other changes are related to template updates
<carlos> pitti, also, could I get the list of missing .po files you told me ?
<mjg59> elmo: I keep getting mailed whenever dasher is uploaded (since I'm the Debian maintainer)
<carlos> if it's easy to get
<pitti> I already gave it to you, not?
<carlos> pitti, not by email
<carlos> and I don't remember an URL either
<pitti> carlos: oh, sorry, lemme find it
<lathiat> infinity: can you give back doodle for i386
<Diziet> Hrm, this conffile bug (#108587) is harder to fix than it looks.
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/rosetta-breezy-missing.txt
<carlos> pitti, thanks
<mvo> elmo: please sync scite from debian/incoming
<carlos> pitti, sabdfl thinks we should be able to add new languagepacks after release
<carlos> pitti, so new packages could appear after final release...
<pitti> well, if langpack-selector supports this... mvo, does it?
<pitti> mvo: do we need to update its list for new languages?
<mvo> pitti: uh, good question
<carlos> pitti, mvo perhaps with an update to langpack-selector....
<mvo> let me look at the code
<carlos> pitti, perhaps glibc or language packs should provide that list...
<pitti> carlos: locales does already, in some sense -> /usr/share/i18n/SUPPORTED
<pitti> mvo: do you use that list and just check whether a langpack for that language is actually available?
<mvo> pitti: I use the iso639 language list and check if a matching langpack can be found in the cache
<mvo> the language file has 187 entries
<pitti> mvo: ok, that should be fine
<pitti> thanks
<mvo> np
<pitti> carlos: yes, then it should be fine
<carlos> pitti, ok, thanks
<jordi> pitti: so if a new langpack has no entry in SUPPORTED, will it be usabel?
<jordi> usable
<pitti> jordi: well, the locale needs to be created as well, so it should be in SUPPORTED
<pitti> jordi: I don't know whether locale-gen will barf if it's not there
<jordi> pitti: can locales be added to breezy post release?
<pitti> no, please no libc 
<jordi> hehe
<jordi> another reason Debian and Ubuntu need to move to belocs
<pitti> jordi: I recently killed my server (ssh broke) with a libc upgrade - they are painful
<jordi> nod
<jordi> when/if we base stuff on belocs-locales and ignore glibc locales, adding/modifying locales will be a piece of cake
<jordi> and won't affect libc in any way
<carlos> jordi, is that the only change?
<carlos> jordi, or do we get other improvements?
<jordi> carlos: sure. belocs-locales is not managed by Drepper, which means speedy fixes/additions.
<carlos> jordi, X-)
<jordi> a correct Serbia and Montenegro locale, etc.
<jordi> you know, stuff that should have happened 4 years ago.
<carlos> so we have the same information and limitations but that is updated more often...
<jordi> pitti's "no libc please" limitation is gone. To update thel ocale data, you don't need to recompile or touch glibc in any way.
<jordi> That's a *major* win
<pitti> infinity: bah, I still get broken translation tarballs - do the 64 bit archs export langpacks again?
<Mithrandir> mjg59: I'm wondering if the memory mapping is totally off and if that's just the problem.
<mjg59> Mithrandir: It's possible
<Mithrandir> mjg59: since just now I get fun errors from gdb like: Cannot access memory at address 0xc000
<tseng> seb128: it looks like ill need to make some patches for the gtk-sharp gtkhtml3.8 mess
<tseng> seb128: update autoconf stuff
<seb128> tseng: what mess?
<tseng> seb128: gtkhtml wont build with gtkhtml3.8, it doesnt have proper autotools love.
<tseng> er, gtk-sharp
<seb128> it looks for 3.6?
<tseng> yes
<Mithrandir> mjg59: especially given that I don't think x86emu really cares about iopl.  So that is probably a wrong lead.
<seb128> that's just a matter to changing the configure.ac and running autoconf probably
<tseng> yes
<pitti> infinity: *headdesk* I know the reason for the broken tarballs - if you are still here, do you have a minute?
<pitti> carlos: did it occur to you that some stripped tarballs don't have mo files?
<pitti> carlos: I use them to determine domain names, do you use them at all?
<carlos> usually, if they don't have .mo files
<carlos> is because the .po files are not used by gettext directly
<carlos> I usually disable those ones so are not exported inside the language packs
<pitti> nope
<pitti> carlos: e. g. the latest control-center package
<carlos> pitti, like pkg-config .po files
<pitti> carlos: in some versions, the tarball has mo files, in some not
<carlos> pitti, dude, after the build we should have *always* .mo files
<pitti> carlos: and c-c uses gettext normally
<pitti> carlos: right, and I just found out why some of them haven't
<carlos> pitti, does it means the build is not generating those .mo files?
<pitti> carlos: IF a package exports mo files in an Arch: all package, AND any buildd is slower than the i386 one, THEN the tarball will be overwritten since !i386 does not build arch-all
<pitti> carlos: and the latest tarball always wins
<carlos> pitti, .mo files are not arch specific
<pitti> carlos: we already had a similar problem in the past, 64 bit machines claimed to have no locale support
<carlos> so all archs should have those, right?
<pitti> carlos: right
<carlos> oh
<pitti> carlos: that's why some packages ship them in arch:all
<carlos> I thought lamont did a fix for that...
<pitti> carlos: i. e. there is an arch: all capplets-data
<pitti> carlos: we circumvented the 64 bit issue
<pitti> carlos: the 64 bit archs just don't export their tarballs
<pitti> but that sucks
<carlos> anyway, I don't get your point, sorry
<pitti> carlos: eventually, we should either export per-arch tarballs (possible for Rosetta?) or let the biggest one win, instead of the latest one
<pitti> carlos: nevermind, I will fix that with infinity
<carlos> I still don't understand what's the problem with latest one...
<carlos> if the 64bit build is fixed...
<pitti> carlos: only i386 builds arch:all packages
<pitti> carlos: so if powerpc builds control-center later, then in that build there will not be *any* mo files
<pitti> because it doesn't build capplets-data
<carlos> then, the other archs will not overwrite it...
<carlos> oh!
<carlos> I understand it...
<pitti> carlos: but if i386 (which has mo) is earlier, then it will be overwritten
<pitti> carlos: tricky, right?
<carlos> pitti, anyway, It's not a big issue
<pitti> carlos: it is, it breaks my scripts
<carlos> once Rosetta's db stores the iformation 
<carlos> we don't need the .mo anymore
<carlos> oh, ok :-P
<pitti> carlos: mo files are the only reliable way of finding out the translation domains
<pitti> carlos: how do you do this? e. g. gnome-desktop recently *changed* its translation domain
<carlos> pitti, I'm creating that DB by hand + the info you give me with the .mo files
<pitti> carlos: ok, so you do need them as well?
<carlos> we need to fix that by hand then
<carlos> if I have them is helpful yes
<pitti> carlos: I will restore the lost tarballs now
<carlos> but not a big problem if they are missing
<pitti> but that needs to be fixed once and for all
<carlos> ok
<pitti> manually messing with this is cumbersome
<tseng> seb128: ok i got the patch worked out, testing.
<seb128> cool
<seb128> infinity, lamont-away: can you retry evolution-exchange on all the archs? thanks
<tseng> mdz: monodevelop is still in main, are we waiting on cron?
<seb128> pitti: what is "Fix Evolution backend of lbdb"? 
<pitti> what the name says - I made m_evolution work :-)
<pitti> seb128: I use lbdb for mutt
<pitti> seb128: and I recently started to use evolution for non-mail
<pitti> so I though it would be nice to have my evo contacts in mutt
<seb128> this backend is a part of evo?
* jdub loves lbdb :)
<pitti> seb128: nah, it just calls evolution-addressbook-export
<pitti> jdub: right, it rocks :-)
* Mithrandir needs to sit down and write clivolution.  Or something like that.
<seb128> pitti: oh k, I was just curious since I didn't notice any upload of the package for the fix :)
<pitti> seb128: no, I didn't fix evolution :-)
<Treenaks> jdub: is there also a way to _store_ new contacts in e-d-s using mutt? :)
<janimo> seb128,ping
<jdub> Treenaks: hmm. no.
<janimo> are gnome integration patches for firefox ubuntu specific?
<janimo> it seems debians mozilla-firefox package does not use gnomeui&co
<sabdfl> janimo: shouldn't be. also likely to come with source code, for porting joy
<janimo> I wonder if the two could coexist, the latter for xfce and ubuntu lite
<janimo> where we don't want gnome libs in the system
<seb128> janimo: pong
<janimo> seb128,^^^
<janimo> dreaded firefox questions :)
<seb128> janimo: dunno, I don't maintain firefox
<janimo> but you keep uploading it :)
<seb128> I usually fix issues having an impact on epiphany-browser
<seb128> and I've fixed cairo/pango issue because somebody needs to fix that
<seb128> but I don't really care about the package :)
<janimo> I see.Who's the closest to maintainer on ubuntu-devel?
<tseng> seb128: have you used the totem plugin lately?
<tseng> seb128: i think its broken, i can find more if you dont know it
<seb128> tseng: it crashed my box yesterday
<tseng> yep.
<seb128> it started slowing down everything, after 5min waiting for a prompt I've rebooted
<seb128> janimo: pitti maybe ... 
* seb128 runs
<tseng> mine just kills firefox
<pitti> nooooo 
<seb128> tseng: if you have a website were it happens please open a bugzilla.gnome.org bug and get hadess or BBB fixing it :)
<pitti> seb128: if I were to write a main inclusion report for it, I'd reject it outright :-)
<seb128> ;)
<seb128> janimo: what is wrong with the current package?
<janimo> seb128, it depends on too many gnome stuff
<seb128> you ask to a GNOME guy to drop GNOME? :)
<janimo> I'd like one package as  debian's mozilla-firefox (currently at 1.0.6) than works w/o gnome stuff
<seb128> that's a feature, not a bug
<janimo> but it can surely be built w/o ?
<seb128> yeah but it's probably nicer with it :)
<janimo> I need it for xubuntu and ubuntu-lite possibly so we don;'t have too many dependencies
<janimo> the most annoying being gaimn starting up at odd times
<janimo> gamin
<seb128> I've just looked on the configure option
<seb128> seems we have pango as difference
<janimo> I see there's a --disable-gnomeui
<janimo> option
<seb128> no
<seb128> $ ldd /usr/lib/mozilla-firefox/firefox-bin | grep gnome
<seb128> $
<seb128> it doesn't come from it
<janimo> hmm indeed interesting, but the package itself depdnds on many gnome libs
<seb128> $ ldd /usr/lib/mozilla-firefox/components/libimgicon.so | grep gnome
<seb128>         libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0xb7efd000)
<seb128>         libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0xb7d3f000)
<seb128> 
<seb128> does the Debian version ship that?
<seb128> (it lists also gnome-vfs, gnome-keyring, etc)
<seb128> if note try to figure why
<janimo> the debian version seems to suggest gnome-vfs
<janimo> that's part of the mozilla-gnome -support pkg or similar
<seb128> this file?
<janimo> gnome-vfs dependency I think
<janimo> also you know why the namechange happened (mozilla-firefox -> firefox)?
<janimo> debian still has the early name
<seb128> "debian/tmp/usr/lib/mozilla-firefox/components/*gnome* usr/lib/mozilla-firefox/components"
<seb128> is the gnome-pkg
<seb128> " firefox (1.0.2-0ubuntu6) breezy; urgency=low
<seb128>  .
<seb128>    * Rename to firefox per MoFo's trademark requirements"
<seb128> 
<seb128> that's for the rename
<lathiat> haha MoFo
<janimo> aha, I wonder why debian keeps it that way then
<Mithrandir> mjg59: do you have vbetool in some version control somewhere?
<mjg59> Mithrandir: Nope
<Mithrandir> evil person.  Mind if I import it into arch?
* mjg59 curses ACPI upstream
<mjg59> Mithrandir: No problem
<mjg59> Mithrandir: Getting anywhere?
<Mithrandir> mjg59: I think it's because of the missing memory setup functions, so I'm stealing that from the int10 handler in X and see if that helps.
<mjg59> Ok, cool
<lathiat> infinity: and can you also giveback libglademm2.0
<infinity> pitti : ?
<seb128> janimo: the difference between debian/ubuntu is the build-dep on libgnomeui
<seb128> janimo: not sure of what that change exactly to use it, but I'm not sure that a good idea to change it now
<janimo> seb128 I don't want to change that
<janimo> but see if we can get the debian version of firefox too
<janimo> as alternatives providing firefox
<janimo> call it firefox-vanilla or something
<seb128> pitti: want 2 firefox ? :)
<seb128> hihi
<janimo> the gnomeui change is so that the open dialog is gnomish at least
<janimo> but that brings in gamin :(
<seb128> how is that an issue ?
<janimo> I use xfce4 and do not want to start gamin at all
<pitti> janimo: I will kill you for that :-)
<janimo> so on first firefox file open it does
<janimo> and it takes 20 seconds of break
* mvo is away now for a bit
<seb128> pitti: I knew you would love that :)
<janimo> pitti, be gentle if you do :)
<ajmitch> pitti: twice the fun :)
<janimo> I am interested in this so I'd put in some work if you need and think it's doable
<pitti> janimo: ok, will clubbing you with 200 MB of ffox source code be regarded as gentle?
<janimo> it could be as simple as sync from sid into our universe
<pitti> janimo: can't we rather merge the debian and ffox features?
<janimo> and make the package conflict I hope
<seb128> janimo: then you have to update, sync, apply security fixes, etc
<janimo> I have the source already and looking at it :)
<janimo> well it's universe so the sec fixes can lag behind main a bit
<janimo> well I don;t know: could we build two binary packages from the same ubuntu ffox sources?
<seb128> janimo: still somebody should fix issues, want to do it?
<janimo> one with the other w/o gnoimeui?
<janimo> seb128 if we agree on this I would
<seb128> yeah, lot of work for almost nothing
<ajmitch> only if you made 2 compile passes, I'd guess
<janimo> I am committed to xfce4-ubuntu
<seb128> gamin can run on xfce
<janimo> ajmitch, sure two passes
<seb128> what is the big deal?
<janimo> seb128, but hardly on 64 megs of ram :)
<janimo> xfce ubuntu is for lowly machines
<janimo> almost any gnomity hurts :)
<seb128> don't use firefox on 64M :)
<janimo> it's an option only but the easiest :)
<janimo> the other would be kazehakase
<janimo> I'll look at the ffox sources and try out some stuff the let you know if I find something feasible
<pitti> carlos: would arch-specific translation tarballs be a problem for you?
<jbailey> jordi: Got a glibc change for me? =)
<jbailey> fabbione: pong
<pitti> jbailey: next upload is imminent?
<jbailey> pitti: No, I haven't started merging the patches yet.
<fabbione> jbailey: hey.. nothing extremely important.. i did open a bug on initramfs that i would like to see fixed :)
<jbailey> pitti: But if he had somethign initial that he wanted me to review, I have brainspace to do that.
<jbailey> fabbione: #?
<jbailey> Sure, cciss shouldn't be a problem.
<jbailey> (In fact, all my old servers used it)
<jbailey> fabbione: I'm curious if it's enabled for the auto scan at the beginning.  Do you have one handy that we can test with?
<fabbione> jbailey: i have 3 handy at the moment
<fabbione> i add cciss to /etc/mkinitramfs/modules
<fabbione> regenerated the initramfs and it works
<jbailey> Nice!
<jbailey> 'cause I remember that those devices  showed up in a /dev/cciss/
<pitti> Hi jdthood 
<jdthood> pitti: Hi ho.
<{Seb}> does anyone here know what has happened to backports?
<pitti> jdthood: ah, I wanted to bounce that mail to you, doing now
<jbailey> {Seb}: Did you get your initramfs question answered earlier?
<pitti> jdthood: I sent it to alsa-utils@packages.debian.org
<jdthood> OK
<pitti> jdthood: ... back then
<pitti> jdthood: shall I bounce it there again?
<{Seb}> jbailey: yeh - the problem was i was running mkinitramfs -o image instead of mkinitramfs -o /boot/image
<jdthood> pitti: I didn't get it, but that wouldn't be the first email I failed to get via that mailing list.
<pitti> jdthood: which mail addr shall I use?
<jbailey> {Seb}: Right.  I should fix it to allow relative paths. =)
<jdthood> pitti: Send directly to pkg-alsa-devel@lists.alioth.debian.org
<jdthood> Is your message at http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-August/thread.html ?
<pitti> jdthood: nope; I'm not subscribed to that list, though
<pitti> jdthood: bounced to p-a-d
<jdthood> Mail to alsa-utils@packages.debian.org should go to the mailtainer's email address which is pkg-alsa-devel@lists.alioth.debian.org.  However, I fail to receive some mail from the BTS that goes that route.  Messages sent directly to p-a-d do seem to get through.
<jdthood> pitti: "Would you be willing to keep this around
<jdthood> for a while?"  What do you mean?
<Mez> {Seb}, ping
<pitti> jdthood: the transition code
<Mez> well, actually, more of a ping
<Mez> pong *
<jdthood> pitti: Sure.  I want to support both Debian and Ubuntu.
<pitti> jdthood: it's unfortunate that breezy won't get it, but we have to live with that
<carlos> pitti, the only problem with that is that the filename will have a variable part
<carlos> i386, ppc, amd64, etc...
<pitti> carlos: we can put an intermediate script in between that sorts them if you want
<pitti> carlos: I need to do that anyway
<carlos> pitti, if you do it in a way that does not affect my current scripts, it's ok
<pitti> carlos: so I can sort them to ~pitti/translations/
<carlos> pitti, I think it's enough if it only affects translations.txt content
<pitti> carlos: so you only need to change that import URL
<pitti> carlos: ok, I think about it
<pitti> carlos: I could throw out the obsolete ones from translations.txt
<carlos> pitti, you don't need to, don't worry
<infinity> pitti : Hrm, do you want me to change the format of translations.txt at all?
<pitti> infinity: it should just list available tarballs, so the format shouldn't actually change, I guess
<infinity> pitti : Right, but there will be duplicates now.
<pitti> infinity: how so, with arch names?
<infinity> pitti : Well, not identical duplicates, but if anyone's relying on being able to say "this is the filename for Package mysql Version 4.1.22 in Component main (etc)", there will now be 4 filenames that match that criteria, not one.
<pitti> infinity: yep, that's fine
* sivang ---> be back later on in the evening
* infinity wonders idly if this fragile translation shuffling mojo will fall apart miserably when we do this.
<infinity> Oh well, nothing gets lost anyway, since it's all on the individual buildds too, so nothing to lose. :)
<pitti> infinity: I'm glad that they are still there, so I could recover them :)
<infinity> pitti : Have you made the changes to pkgstrip?
<infinity> pitti : If so, can you provide me with the new sources, so I can install it on exactly one buildd for testing? :)
<pitti> infinity: not yet, doing three things at once max'es out my male multitasking capabilities
<infinity> Good thing your girlfriend's not in the room too.
<pitti> yep, she'll arrive in ~ 1 hour :-)
<pitti> infinity: 4 things - phone rings
<pitti> infinity: shall I use dpkg --print-architecture?
<seb128> infinity: could you give a retry to evolution-exchange?
<Mez> evening bddebian 
<bddebian> Heya Mez, how are you?
<Mez> tired
<Mez> and... tried
<bddebian> Heh
<\sh> Mez: do u have a special backports channel?
<Mez> \sh: nope - I dont see the need for one yet
<Mez> \sh do you think we need one?
<infinity> pitti : --print-installation-architecture
<infinity> pitti : That's what sbuild uses.
<pitti> infinity: ok
<\sh> Mez: no...but i was curious :) u have couple of minutes time? 
<HiddenWolf> who is responsible for the order in which the init scripts run by the way?
<Mez> yeah, go for it , sup?
<\sh> Mez: check -motu
<Mez> \sh: kk
<seb128> pitti: http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg00038.html .. if you want to give a reply on the topic
<daniels> pitti: ping
<pitti> Hey daniels 
<pitti> seb128: will come to that soon
<seb128> pitti: you don't have too, but that would probably be cool :)
<seb128> thanks
<fabbione> jbailey: yes they do show up in /dev/cciss, but it just works..
<fabbione> anyway...
<fabbione> time to start the weekend!
* fabbione goes offline
<fabbione> cya guys
<seb128> enjoy fabbione :)
<pitti> enjoy the we, fabbione 
<pitti> infinity: can you poke me when your tests are finished and I shall upload?
<Mez> infinity, email sent :D
<infinity> pitti : You can't upload until I roll out the changes to all 12 buildds.
<infinity> pitti : So, I'll poke you much later. :)
<pitti> infinity: oh, ok
<pitti> infinity: I thought you need the new deb in the archive for that
<mdke> elmo, any news on a name for the docteam linode server?
<mdke> we've been waiting for weeks :(
<jsgotangco> months actually
<HiddenWolf> call it sleepy. :)
<mdke> elmo, if you think it will take a long time, we can set up a free temporary solution i suppose
<jsgotangco> mdke: let's just do dyndns :)
<jordi> jbailey: not yet, I'm waiting for Asturian info from the Asturian translators to write the locale.
<elmo> mdke: err, you guys chose to use docteam.ubuntu.com for the svn repo in the first place
<elmo> I warned you at the time it was a bad idea
<mdke> elmo, ok but it has been at least two weeks since henrik and jane decided on doc.ubuntu.com for the linode
<jsgotangco> elmo: what do you suggest?
<jsgotangco> the time i came it was already docteam
<jdub> elmo: planet update please :)
<mdke> elmo, your call, if you don't want to do doc.ubuntu.com, we'll get a dyndns name
<elmo> mdke: please stop putting words into my mouth
<mdke> elmo, i'm not, i said "if"
<mdke> just let us know
<siretart> elmo: any news about the revu linode vserver?
<mdke> elmo, i have no problem with a dyndns temporary solution if you don't have time to do it now. All we want to know if whether you can do it, and when. Not knowing is the only problem.
<pitti> seb128: ok, gnome packs get too big, I upload completely fresh gnome packs and update just main and kde
<elmo> sigh
<seb128> pitti: how do they get too big?
<jbailey> jordi: There's an alernate locales project being done by some Debian folks.  I was thinking that for breezy+1 that it might be worth looking more closely into that.  What do you think?
<pitti> seb128: too many updates
<seb128> elmo: have you sync djvulibre? jdub asked for it yesterday
<seb128> pitti: oh, blame jordi :p
<jordi> jbailey: I've been ranting about belocs-locales being the way to go all morning :)
<jbailey> jordi: Lovely.
<jbailey> jordi: I haven't read much about the project, but I would love to see an upstream that actually cared about the locales.
<jordi> belocs/denis is the man
<jordi> jbailey: I got my Catalan stuff in there in like... 1 day.
<ogra> jbailey, 
<ogra> Done.
<ogra> Begin: initializing /dev...
<jordi> jbailey: other goodies... locales know about Yugoslavia being no more! etc.
<elmo> seb128: no, I missed it, doing now
<jordi> jbailey: and updates to locales doesn't mean rebuilding libc6
<ogra> jbailey, ^^^ is that your domain ? it occurs directly after the kernel has booted
<ogra> jbailey, on ltsp
<pitti> elmo: can you please also sync plr? the current version does not work at all, so even it is a new upstream version, it can only improve...
<pitti> elmo: (it needed to be adapted to new postgresql architecture)
<pitti> Hi otavio 
<ogra> jbailey, oh, somehow xchat swallowed the error, thats the line afterwards: /init: 66: Syntax error 0x
<pitti> seb128: for the g-vfs mail, is there an mbox archive somehwere?
<elmo> siretart: there should be a (!linode) server available now, checking
<elmo> pitti: pitti done
<pitti> thanks
<pitti> I really feel done :-)
<pitti> Hi carstenh 
<carstenh> hi pitti 
<jbailey> ogra: 0x?
<jbailey> ogra: Nothing else?
<ogra> yup
<carstenh> hi jbailey 
<ogra> Done.
<ogra> Begin: initializing /dev...
<ogra>  /init: 66: Syntax error 0x
<pitti> seb128: nevermind, found it
<\sh> elmo: pls think about the situation...we want to build something like a automatic sbuild structure on this (v)server :)
<jbailey> ogra: Hmm.  It should have no-op'd the parse_numeric call for you.
<\sh> elmo: (regarding revu)
<jbailey> ogra: Does it die right after that?
<Thunder000> hello.. from where can i download the breezy kernel package ?
<jbailey> carstenh: Heya!
<ogra> jbailey, yup... kernel panic
<jbailey> ogra: Got time to try an experiment with me?
<ogra> jbailey, sure, but my laptop is the client, so i'll be offline for testing... :)
<Thunder000> I did an dist-upgrade to breezy.. and i need the newer kernel .. can anyone help me get it ?
<\sh> newer kernel?
<elmo> siretart, \sh: please talk to Henrik, (hno73 on irc or henrik@ubuntu.com), he should have a real server available to you
<siretart> elmo: you ROCK! thanks! :)
<\sh> elmo: u rock :) we really have to meet and have a nice time.... what do u need from germany?
<azeem> weisswurst
<siretart> :)
<\sh> germany != bayern ,-)
<\sh> koelsch...krombacher...pferde leberkaes
<hno73> Hi siretart, yeah just send me an email 
<pitti> seb128: I replied to the maiul
<Mitario> elmo, ping
<frans-th> hi there
<frans-th> anyone from cannonical or willing to help indonesia?
<frans-th> on belong of my goverment, 
<frans-th> we need help from all of you
<frans-th> to make ubuntu become official desktop for our country
<frans-th> but, the ubuntu brand must be renamed to lcoal brand
<frans-th> aloo
<\sh> why?
<frans-th> why?
<frans-th> this is political step,
<frans-th> because microsoft dont want to do this, and sun change his JDS brand become IGOS Desktop
<frans-th> but right now JDS is very strong here, 
<frans-th> so, goverment ask me about how to change ubuntu brand
<\sh> but why you have to change a name?
<frans-th> or make a theme :P
<frans-th> because the goverment want to use local brand for this project
<\sh> or do it like redflag linux in china..take redhat as base...and fork it ;)
<HiddenWolf> frans-th, there is a wiki page on BrandingforDeriviates
<frans-th> Sun change his JDS in Indoensia become IGOS brand.
<frans-th> and IGOS now, adopted by ASEAN, south east asia 
<Mitario> frans-th, why do they want a local branch? (Just interested) :)
<frans-th> i think ubuntu is better than JDS, can be more :)
<carlos> Mitario, I suppose that is a way to justify that it's a "local" development
<frans-th> why?
<frans-th> this is political step only
<frans-th> the govermetn want something local support 
<Mitario> ah, what are the political arguments?
<seb128> pitti: thanks !
<frans-th> to make the goverment can said to another country, that we have our own distro :)
<frans-th> i think, we dont ahve to change all the ubuntu brand
<frans-th> just the theme :)
<frans-th> or any input for this?
<frans-th>  i can guarrante our goverment will use ubuntu
<frans-th> right now Sun very agresif selling JDS here :( with IGOS brand
<Mitario> frans-th, maybe you whould e-mail some people :) I don't assume the canonical people will be here all the time :)
<frans-th> HiddenWolf: where is the url? i cannot find in ubuntulinux.org
<HiddenWolf> frans-th, as I said, there is work being done on making it easier to rebrand ubuntu: https://wiki.ubuntu.com/BrandingForDerivatives
<lathiat> oucht he enter bug page really does suck at dialup speeds
<frans-th> some people, can give me the name?
<lathiat> im shaped to 8K/s and its been like a minute so far
<frans-th> ok thx
<HiddenWolf> frans-th, so I'd say talk to kamion
<HiddenWolf> or jbailey
<Mitario> mako also does lots of marketing stuff right?
<frans-th> ok
<jbailey> HiddenWolf: Hmm?
<frans-th> thx, send email to me, frans@intercitra.com
<frans-th> that is my email
<frans-th> this is very urgent
<HiddenWolf> jbailey, you're second on BrandingForDerivates, aren't you?
<frans-th> i have a job here from goverment to support 800 PC with ubuntu :)
<jbailey> HiddenWolf: Yup.  What do you need?
<HiddenWolf> frans-th needs you jbailey. :)
<frans-th> so, i am preparing to create indonesian based ubuntu support services
<jbailey> frans-th: Cool!
<frans-th> if someone can help me to make the best linux support services in this country will be cool
<frans-th> i got in canonical, canonical support south africa go open source, now i am one of the team that help indonesia goes open source, i am managing igos.or.id
<mako> Mitario: i do less marketing stuff.. more community stuff. i guess it depends on who we are marketing to ;)
<frans-th> this web site will become our center of open source research
<frans-th> our office will move to goverment office
<Mitario> mako, heh ok :)
<sivang> seb128: did you see my talks with neo on #gimp ?
<frans-th> there is 3 minister support my action
<jsgotangco> hey mako
<mako> jsgotangco: hey dude :)
<frans-th> jbailey, who r u anyway :) sorry, i am new in this channel
<frans-th> all: am i in the wrong channel? can i chat this case here?
<jsgotangco> frans-th: this is a developer channel
<jbailey> frans-th: Do we have your company listed in the Marketplace yet?
<tseng> frans-th: you really want the ubuntu-sounder mailing list, i think
<frans-th> aloo...
<frans-th> what is markeetplace?
<jsgotangco> frans-th: i will PM you
<frans-th> ok
<Mitario> jbailey, i thought his company was the indonesian government :)
<jsgotangco> Mitario: please no making fun, the guy isn't that well-conversant in english
<jsgotangco> he is south east asian like me
<Mitario> i'm not making fun, just noting someone
<Mitario> sorry if it looked like that, but, he is from the government right?
<jsgotangco> im talking to him now
<Mitario> oki :)
* Mitario shuts up
<frans-th> Mitario: i am not goverment staff, but the goverment staff want this help, but this project must finish before sun know it
<Mitario> frans-th, ahh right, I was just curious/exited
<HiddenWolf> *chuckle* there are probably sun-related people here anyway.
<Mitario> frans-th, sounds really great
<azeem> good thing GMan does not lurk in here anymore
<frans-th> Mitario: my job is to make a ubuntu repository, where the server is from Sun :) see, the political step of Sun here.
<frans-th> I think apokrypt, paul, and philips vanhoff, know my idea
<frans-th> i visit this chat room every day, for asking this hel
<HiddenWolf> frans-th, if you have a plan, why not take it up with sabdfl?
<Mitario> frans-th, heh, I know pvanhoof :)
<frans-th> ask him, he know my problem well
<pvanhoof> aha
<frans-th> sabdfl? who is he?
<frans-th> i am new in this channel, event i am use ubuntu since warty :P
<frans-th> hi pvanhoof
<pvanhoof> about the bandwith?
<HiddenWolf> frans-th, the guy that funded canonical and ubuntu :)
<Mitario> frans-th, sabdfl is the project leader, mark shuttleworth
<frans-th> i have good news, the goverment now need something new, they want to make ubuntu become national wide formally, become indonesia official distro
<frans-th> the bandwidth will come soon, next week i will try to prepare :)
<frans-th> :)
<pvanhoof> frans-th, so the bandwith is no longer a problem?
<frans-th> and the govermetn staff want something radical :) to break sun movement here.
<pvanhoof> frans-th, because, for a serious mirror, you do need much more than 56k
<Mitario> pff, I wish the dutch government was like that :)
<HiddenWolf> frans-th, out of interest, what is sun doing  that you don't like?
<frans-th> because sun charge US$ 50 for his linux distro, and this shocked several of the goverment, they think Linux is free, but how can 
<jsgotangco> HiddenWolf: i believe he is concerend with rebranding Ubuntu
<frans-th> pvanhoff: i will prepare for the bandwidth, i will update next week
<\sh> linux is free as in free speech..but not as in free beer...
<frans-th> right now, i have another task, but must keep in silence, we must make a ubuntu version that with indonesian brand, 
<\sh> frans-th: is this a secret? 
<frans-th> right now, microsoft are very agresif in open source team :)
<frans-th> the unbuntu rebranding = not goverment official project yet.
<frans-th> after finish, they will launch, the process cannot be introducte to sun indonesian team :) they never chat here anyway, 
<ivoks> rebranding?
<\sh> well..right now all the world can read about your plans ;)
<jsgotangco> frans-th: this is possible, but cannot be done without planning
<frans-th> so, give me the best way
<frans-th> rebranding = change the ubuntu default theme :)
<frans-th> i think we still can adopt the installer with ubuntu name, 
<frans-th> i just now prepare for theme :)
<frans-th> background, :)
<ivoks> theme needs change, i agree :)
<frans-th> :P
<frans-th> about the duplication cD, my goverment open sourec team will do it.
<frans-th> so, no need canonical time :P
<seb128> sivang: no, is the log somewhere?
<frans-th> pvanhoff, r u there?
<jsgotangco> frans-th: got your email, thanks
<frans-th> ok
<jsgotangco> but why do you want it renamed to pigeon?
<frans-th> if all of you can help, send me an email frans@intercitra.com
<jsgotangco> (merpati)
<frans-th> this is a project name.. :)
<jsgotangco> don't you have something similar to "ubuntu"
<frans-th> ubuntu?
<frans-th> because right now our goverment promote about indonesan brand :)
<frans-th> so we must use something that look like indonesian brand, but not :P
<frans-th> i personally wanna becoem ubuntu resp in indonesia rather create my own brand
<\sh> frans-th: the word "ubuntu" has a meaning
<jsgotangco> yes, i mean the equivalent of ubuntu in bahasa
<ivoks> ah, indonesia
<ivoks> frans-th: leave our ships alone! :)
<\sh> frans-th: do u have a word with the meaning "humanity to others" 
<jsgotangco> frans-th: it seems IGOS is relatively new
<jsgotangco> (a few days ago)
<\sh> asianux
<\sh> was also new to me until a few minutes ago
<jsgotangco> oh asianux is relatively old
<jsgotangco> but its a consortium of 3 linux companies
<jsgotangco> red flag is actually crap imho
<HiddenWolf> jsgotangco, mind, mind. be human to others. ;)
<jsgotangco> Acer bundles them over here
<\sh> HiddenWolf: hehe
<\sh> HiddenWolf: red flag was a copy of redhat 
<frans-th> :)
<frans-th> because our country have lack of linux expert, but one of our linux team, now work in finland :)
<frans-th> IGOS is 2 years old, you can visit igos.web.id for goverment website :P
<\sh> frans-th: indonesia? in bali or jarkate there is the redhat linux emea support center...
<frans-th> jakarta
<\sh> yeah
<frans-th> yah redhat linux support center, :) i very close with all those companies :)
<frans-th> but they job is only sell redhat 
<\sh> build up by a redhat employee from germany :)
<frans-th> redflag is crap :) but this is good for goverment
<frans-th> the fedora have been rebrand here, named blankon, 
<frans-th> so, i think ubuntu time now :)
<jsgotangco> what does blankon mean?
<\sh> ok..have to go to a music festival..cu later gentlemen
<frans-th> blankon mean a hat, this is javanese traditional hat
<frans-th> and fedora here, also renamed become wareong IGOS, and this distro is very popular right now
<DrSpin> APT-get update will "IGN" both the planetmirror and mirrormax haroy-extras and hoary-backports -- any clue why or how I can fix it??
<jsgotangco> i thought Igos was an OS, it actually meant Indonesia go open source
<frans-th> right now, my positioni is become the ubuntu support :) event i am not expert in ubuntu :)
<frans-th> yah, igos :) is a goverment program, i am one of the team :) i am resp of java community leader, not linux :)
<frans-th> but got this job :( sad
<jsgotangco> interesting project
<jsgotangco> (looking at the english site)
<frans-th> :P
<frans-th> knopix also renamed become linux sehat , mean healthy linux
<frans-th> but honestly, no one will use the rebranding version :P
<frans-th> i am personally more trust the ubuntu team that me :)
<frans-th> so, any tips?
<jsgotangco> frans-th: make a comprehensive project plan/abstract and send an email to the sounder list you will definitely get a reply
<jsgotangco> http://lists.ubuntu.com/mailman/listinfo/sounder
<jdub> but keep in mind that it's a public list
<ivoks> elmo: ping
<jdub> frans-th: btw, your emails to info were received :)
<frans-th2> hi all, sorry disc
<frans-th2> so, any tips for me for this task?
<jdub> frans-th2: your mails to info were received
<jdub> frans-th2: those mails were a good start for your task
<jsgotangco> wow my first birthday greeting came from an ad bot
<ivoks> jsgotangco: hb!
<ivoks> jsgotangco: 26. or 27.?
<frans-th2> jdub? who r u :) can i know :)
<frans-th2> jsgotangco: 200 :P
<frans-th2> haha
<jsgotangco> ivoks: 28
<ivoks> jsgotangco: hehe mine is 27. :)
<frans-th2> jdub: i think this project will be started soon :)
<jsgotangco> !!
<jsgotangco> ivoks: hb!
<ivoks> jsgotangco: thanx :) you were first :)
<Diziet> keybuk: ping
<frans-th2> hb from me too :)
<jsgotangco> ivoks: at least you didn't get your first greeting from an ad mailbot
<ivoks> :))
<ivoks> jsgotangco: i'm waiting for my g/f's gift :)
<frans-th2> oh yah, any one have goverment credetian of ubuntu?
<frans-th2> ivoks: what kind of gift do you want?
<ivoks> frans-th2: leave our ships alone! :)
<ivoks> frans-th2: from my g/f? :)
<ivoks> we are offtopic with ships and birthdays
<frans-th2> ivoks: hot ship :) 
<frans-th2> ivoks: i am not a hijacker :P
<jsgotangco> jdub: thanks on the planet thing, it works...
<frans-th2> anyway
<frans-th2> all
<frans-th2> must go to go, 
<frans-th2> midnight here, tomorrow saturday, and still workding :)
<frans-th2> byeall
<ogra_ltsp> jbailey, the fix worked fine
<jdub> so the opensuse torrents
<jdub> ww
* Treenaks read "Opensuse terrorists"
<lathiat> Treenaks: haha
<DrSpin> On Hoary are there any CD burning tools that will burn a CD WITHOUT root privelages??? I've tried GnomeBaker, Graveman, and bout to try k3B but on my last Hoary install -- it needed root privelages
<Mitario> hmm where has libxp-dev gone too?
<jsgotangco> night all
<jordi> jbailey: I hve stuff for you.
<jbailey> jordi: Lovely!
<jbailey> jordi: Email or bugzilla is fine.
<jbailey> jordi: You know my usual paranoia - These are locale changes that stand a chance of being accepted upstream, right? =)
<jordi> that really doesn't matter, we're dealing with Drepper.
<jordi> I'm not exaggerating
<jordi> Drepper still doesn't acept, afaik, the Serbia and Montenegro locale, and Serbian users are still using a sr_YU locale
<jordi> when that country got blown up by bombs years ago
<jbailey> jordi: Well..  What about the other locales guy?
<jordi> But anyway, Asturian should be accepted. :)
<jbailey> I want to find out by which standards they're accepting things.
<jordi> The belocs maintainer?
<jbailey> That's the one.
<jordi> Denis will accept this locale after checking it doesn't have parse errors.
<jbailey> I can never remember the word.  I get "belrog" in my head, instead...
<jbailey> Oh, so he doesn't validate the locales changes at all? =(
<jordi> heh
<jordi> well, how can he validate if "Wednesday" is written this or tthat way in Elbonian?
<jordi> he checks if the file is sane, has no unnecessary bits, etc. But the actual data, in most cases he can't do much about except trust the source.
<Diziet> Is there anyone in particular whose attention I ought to draw if I propose to upload a new dpkg into Breezy ?
<Diziet> FVO `new' = with a patch to fix #108587.
<jbailey> jordi: Literal translations aren't usually my worry.  Date format changes, collation order, separator characters, etc. are.
<jbailey> jordi: Those things are usually tracable through newspapers, standards, etc.
<jbailey> bbiab, initramfs-tools testing
<Coyctecm> Hi.
<Coyctecm> ubuntu developers here?
<Coyctecm> First of all. Thanks for the great distribution.
<lewion> what's wrong with java?
<lewion> there is no java anymore in ubuntu repositories
<Coyctecm> I have used Linux since 1996 never used as clear distro as ubuntu is by default.
<Coyctecm> I have one wish...Is it possible to add englightenment or fluxbox to installation cd. That user can deside which one to use?
<Coyctecm> lewion: Why you just can't go to the sun microsystems site and grab java there?
<zul> Coyctecm: i think its due to a space issue
<Coyctecm> zul: oh yes..that could be true...just that fluxbox doesn't take much space..
<Coyctecm> or maybe better would be if fluxbox could be added to official ubuntu repositories...
<zul> not up to me :)
<Coyctecm> :)
<Mitario> anyone has e-mail addy of elmo?
<jdub> james@canonical.com
<Mitario> jdub, thanks
<jbailey> jdub!
<jbailey> jdub: Are you able to test an initramfs for me? =)
<mako> mdz: ok
<mako> mdz: you around
<mdz> mako: yep
<mako> mdz: re this last thread on scim-anthy and input methods and language support packs
<mako> mdz: i want to drain this swamp
<mdz> mako: I would love it if you would
<mdz> mako: but didn't we have this same conversation 6 months ago? ;-)
<mako> mdz: yes
<ogra> jbailey, did you get my message before ? the fix works fine for me 
<mako> mdz: i think we can do japanese now
<jbailey> ogra: I did, thank-you.
<ogra> ok :)
<ogra> jbailey, thank *you* ;)
<mako> mdz: i think the guys in this thread are right.. so far everyone has been advocating anthy.. whether it comes from UIM or SCIM doesn't make a huge difference except SCIM seems to offer more flexibility for other languages
<mako> i think the correct thing to create a procedure for the inclusion on an input method
<mako> it doesn't have to be heavy-weight
<mako> but that's the long-term solution
<mako> but i think the japanese guys are on track at this point
* mako will reply on list
* xhaker is away (Away, bnc logging)
<mvo> Diziet: if you implement your fix for #108587, could you please send something to the status_fd of dpkg (if there is one) so that frontends can deal with it in a gui way?
<Diziet> I'll just tie in the new question to the existing conffile prompt, so it'll just do the same (well, a similar) thing as all the existing questions.
<Diziet> I assume you mean to control interaction.
<mvo> yes, we do that with the normal conffile prompt now too (in synaptic)
<jdub> jbailey: i could be tempted :)
<jbailey> jdub: I uploaded it already. =)  Hope it works for you.
<mvo> Diziet: the current "protocol" for the conffile prompt that dpkg sends over the status fd is very limited, it may be a good idea to think of something better here
<Diziet> You may well be right, but I'm just fixing this bug for now :-).
<mvo> sure, the communication thing is the easiest bit to fix :)
<xhaker> mvo, you there?
<mvo> xhaker: yes
<xhaker> could you please rebuild Scite?
<xhaker> it is pretty messed up right now
<mvo> xhaker: it should already fixed in breezy, 1.64-2 should be fine
<xhaker> hmm, i don't get that version here
<xhaker> 1.64-1
<xhaker> still
<mvo> elmo: can you please sync scite from debian?
<mvo> xhaker: right, it's not yet synced into ubuntu, but the fix is only a couple of hours old :)
<xhaker> fix to the text jibberish that occurs?
<mvo> xhaker: yes, scite does not work with the new libpango out of the box
<mvo> a small patch is needed to fix that
<xhaker> then i'll wait for the sync
<mvo> xhaker: if you want to test it right now, you can just rebuild the debian package locally 
<xhaker> how?
<xhaker> get the src from what repositorie?
<mvo> xhaker: get the source (three files) from http://packages.debian.org/unstable/editors/scite
<mvo> or add a deb-src line to the debian unstable repository 
<mvo> or just wait for the sync :)
<mvo> (shouldn't take long)
<xhaker> looks like i have alot of options :)
<xhaker> hah, the source on that site is for -1
<mvo> xhaker: odd, I uploaded it a couple of hours ago 
<xhaker> mvo, i'm just reporting what i see :P
<mvo> xhaker: I see the same, it's not in the pool yet
<torkel> seb128: ping?
<seb128> torkel: pong
<torkel> seb128: seen http://bugzilla.gnome.org/show_bug.cgi?id=314530
<torkel> I'm hit by that bug too, but it usually crashes gnome-screensaver for me
<crimsun> hmm, getting a connection refused when trying to dput
<seb128> torkel: nop
<seb128> torkel: does the patch fix your issue?
<torkel> seb128: yes
<seb128> I'll fix it
<torkel> thanks!
<seb128> np
<infinity> crimsun : That machine is unhappy right now.  Wait a while, elmo's heading to the DC to give it some love.
<crimsun> infinity, thanks!
<ivoks> infinity: or old russian method? :)
<jbailey> infinity: Oy, Adam. =)
<jbailey> err.
<jbailey> "ping" =)
<infinity> jbailey : pong?
<elmo> (ftp-master is back)
<crimsun> rock
<crimsun> thanks, elmo 
<lamont> mdz: ping
<lamont> mdz: nm
<Mitario> elmo, great :) btw, can you give me MOTU upload access?
<mdz> lamont: pongnm
<zeedo> .mode zeedo
<jbailey> mdz: ogra and I were chatting earlier about ltsp.  He mentioned that it was sad that there was no way to PXE boot a laptop with wireless for ltsp.  I don't think it'd be that hard to do something like that where either we did something with a PXE loader and kexec, or just did an nfsroot bootup with local media.
<jbailey> mdz: The key part to each would be adding the ability to load firmware for the network card in the initramfs.  Is that something work trying for for Breezy, or should I add it to my list of things for earlyuserspace cleanup for breezy+1?
<mdz> jbailey: I don't know of any laptops which can PXE boot over wireless
<infinity> Yes, but it can be faked.
<mdz> I think it's the sort of feature we should wait to implement until there is demand
<jbailey> mdz: Right.  They would need a local CDROM or something like that to boot a Linux system and then fake it.
<mdz> jbailey: we'd also need to worry about l-r-m
<mdz> I think that it's easier to fake it using grub than messing with PXE and pxelinux
<jbailey> Hmm, I hadn't been thinking much beyond making it easy to get the firmware on to there.
<mdz> though, I don't suppose grub supports wireless NICs either
<jbailey> I doubt it.
<tseng> mdz: hi. it looks like monodevelop is still in main, is this intended?
<jbailey> Doing it all in Linux would probably be the most sane.
<infinity> Clearly, we should be pushing LinuxBIOS everywhere.
<mdz> tseng: it's been removed from the seeds and is either a) still pulled in by a dependency, or b) waiting to be physically moved out of main
<crimsun> jbailey, FWIW, the only way I could get Linux onto this ThinkPad X41 was via PXE over the wired eth, since this machine lacks a cd-rom drive.
<tseng> mdz: hm well nothing should depend on it.
<jbailey> crimsun: Joy.  I'm the one supposed to be hacking on the floppy install for 2.6 for d-i in Debian.
<mdz> elmo: is it intentional that I can't login to jackass?
<infinity> jbailey : That doens't help, no floppy on the X series either. :)
<crimsun> infinity, right. :)
<jbailey> No floppy, no cd?
<jbailey> That's..  impressive.
<crimsun> none.
<infinity> mdz : Already pinged him about that, he's still in transit.
<jbailey> Do they epoxy the case closed, too?
<crimsun> thankfully, no
<mdz> tseng: I can't check right now, but it's probably waiting for the next archive resysnc
<mdz> resync
<infinity> mdz : With any luck, HE can still login.  If not, maybe you should phone his mobile so he can turn around and go back to the DC...
<mdz> tseng: moving packages between components is a manual process
<tseng> mdz: alright.
<mdz> infinity: he's a professional, I'm sure he checked before he left
<infinity> mdz : Almost certainly, but this could be the exception proving the rule. :)
<mdz> tseng: first we change the seeds, then germinate thinks about what that means, and then we look at the diff between germinate and the archive and take action based on that
<mdz> infinity: besides, he doesn't live far away from the DC anymore
<infinity> jbailey : You can get USB cdrom or floppy drives for the X series, but pretty much no one does.  Windows users can restore from the system restore partition (unless they foolishly delete it), and Linux users can install via PXE, so it all works out.
<elmo> oh for christ's SAKE
<infinity> Speak of the devil.
<elmo> right.  change of plan.  new ftp-master machine
<infinity> One with 20% more bling?
<elmo> one with 1000% less RAID card death
<elmo> bbiab
<Mithrandir> crimsun: you could probably also have installed off an USB stick.
<infinity> jbailey : What's this all about?  "/init: 89: chmod: not found"
<infinity> jbailey : I get that right after the kernel audit message.
<tseng> infinity: isnt that usplash badness?
<infinity> Oh, couls be.  It's "earlyuserspace", so I just blame jbailey by default.
<infinity> s/couls/could/
<crimsun> Mithrandir, true, but then I would have chosen the less effort route of buying a usb cd-rom. Plus I needed to hone up on PXE.
<Mithrandir> crimsun: price of USB driver >> price of USB stick, but yeah.
<Mithrandir> crimsun: at least I tend to have USB sticks lying about.
<Mithrandir> (you need 8MB or bigger stick to do a netinst of Ubuntu)
<crimsun> hmm, I should just get a bunch of USB thumb drives
<torkel> does anyone have a .deb of linux-headers-2.6.12-6-686 available?
<crimsun> should be in the morgue
<infinity> The morgue that hasn't been updated since April?
<crimsun> ok, not in the morgue then :P
<torkel> nope :-(
<mdz> infinity: it's a harmless usplash error
<jbailey> infinity: forgot about that one when I was hacking today, sorry.  There's no chmod in initramfs' busybox, need to change that.
<JanC> crimsun : you can boot the debian-installer from a windows partition...
<jbailey> It's when I mount the old /dev onto /dev/.static, it should be chmod'd 700 so that nothing uses it.
<mdz> oh, I thought it was usplash
<Mithrandir> JanC: hmm?  I though loadlin was broken with 2.6 kernels?
<JanC> there is a grub-for-windows
<Mithrandir> ok
<JanC> https://wiki.ubuntu.com/Installation/FromWindows
#ubuntu-devel 2005-09-01
<elmo> eh, the hoary installer is trying to give me 12Gb of swap
<ogra> elmo, sure, hibernate needs 3x RAM :p
<infinity> elmo : Should I light up the buildds again, or is jackass going to be up and down all day?
<elmo> fire it up
<elmo> I know what's killing it, and I'll just not do that
<infinity> Heh.
<elmo> I'll not be migrating it to the weekend
<elmo> the buildds fail nicely when they can't ssh to jackass tho right?
<infinity> Yes.
<elmo> ok
<infinity> Assuming the hotname won't change when you migrate.
<infinity> hostname, even.
<elmo> ip/hostname/ssh will all remain the same
<infinity> (Well, they'd fail nicely either way, they'd just not stop failing if the hostname changes)
<mae> has anyone noticed slight performance hits in drawing operations since gnome 2.12(cairo)
<mdz> tseng: monodevelop moved
<tseng> mdz: thank you.
<tseng> mdz: the rest will follow?
<mdz> tseng: the rest?
<tseng> mdz: gtk-sharp2 was the goal
<mdz> tseng: most of it wants to go to universe, but not the source package
<mdz> http://people.ubuntu.com/~mdz/anastacia.txt
<mdz> tseng: monodoc-gtk2.0-manual is still in Supported
<tseng> im seeing that
<tseng> depended on by monodoc-manual
<mdz> oh?
<tseng> yes.
<mdz> I don't see any dependencies on it
<tseng> hm yes
<tseng> where did i just see this
<tseng> oh, -gtk2.0- depends on monodoc-manual
<tseng> not the other way
<tseng> i see no rdepends for monodoc-gtk2.0-manual
<mdz> tseng: I've removed it, cross-merged to kubuntu and edubuntu
<mdz> it should fall out in the next germinate run
<tseng> mdz: wonderful, ill watch this anastacia page.
<mdz> tseng: if you poke me when it disappears from people.ubuntu.com/~cjwatson/germinate-output/ then I'll push it through immediately after
<tseng> mdz: can do.
<infinito> where should gnome applets files been installed??
<elmo> Rejected: lsb-release-udeb_1.4-8ubuntu1_i386.udeb: architecture part of filename (i386) does not match package architecture in the udeb (all).
<elmo> ^-- whoever uploaded lsb-release last
<elmo> hmm, colin, a month ago
<salkin> Hi, this is not a support request. I am just having trouble getting a bugzilla login and I wanted to mention that emacs fails to even start on my breezy/x86 install. No messages when started from console. Strace didn't tell me anything useful with a quick read. I just wanted to make someone aware of that. Thanks.
<ajmitch> elmo: could you sync socketapi from debian? c++ lib rename was unnecessary
<xhaker> elmo: while you're at syncs check if Scite 1.64-2 is already at the debian pool and sync it
<ajmitch> elmo: also sync plucker, drop ubuntu changes 
* xhaker is away (Away, bnc logging)
<mdz> tseng: stuff moved
<Keybuk> mmm, baz is _so_ fast, oh yes
<Keybuk> two hours just to do glibc *sigh*
<jdub> GOOD MORNING FREEDOM LOVERS!
<whiprush> yay!
<ajmitch> morning jdub 
<glick> hi all
<glick> ok so i checked out the website on ubuntulinux about contributing but i dont see a concrete list of what has to be done or maintained
<glick> its all very fuzzy
<glick> id like to contribute, maintain a coupla packages but where to begin?
<jdub> glick: the motu team!
<ajmitch> most packages start off in universe, which is cared for by the masters of the universe
<ajmitch> in #ubuntu-motu
<jdub> glick: #ubuntu-motu or wiki.ubuntu.com/MOTU
<glick> hmmm
<Keybuk> Dear Shadow Maintainer ... a patch file for every translation change is NOT CLEVER! :p
<elmo> jesus, are you kidding?
* fabbione yawns
<fabbione> morning
<fabbione> Keybuk: ahahaha
<Keybuk> syndicate shadow-4.0.3% ls debian/patches
<Keybuk>   :
<Keybuk> 101_cs.dpatch
<Keybuk> 102_de.dpatch
<Keybuk>   :
<Keybuk> 112_da.dpatch
<Keybuk> 113_es.dpatch
<Keybuk>   :
<Keybuk> 126_tr.dpatch
<Keybuk> 127_zh_CN.dpatch
<Keybuk>   :
<Keybuk> 205_it-manpages.dpatch
<Keybuk> 206_ko-manpages.dpatch
<Keybuk> etc.
* fabbione sighs
<rob^> hey, I'm getting in breezy: The following packages have unmet dependencies:
<rob^>   scorched3d: Depends: libwxgtk2.4 (>= 2.4.2.6ubuntu1) which is a virtual package.
<rob^> any ideas?
<crimsun_> I haven't uploaded the fixed one yet
<crimsun_> wait about 3 hours
<rob^> thanks :)
<crimsun_> (michiel already fixed it)
<Keybuk> I want to know when we get the "either that wallpaper goes, or I do" release of initramfs-tools
<jdub> i enjoyed the mistake-to-learn-from in the latest release
<Keybuk> "Experience is simply the name we give out(sic.) mistakes." ?
<Keybuk> Lady Windermere's Fan, iirc
<Keybuk> it's a misquote, if it is <g>
<Keybuk> Act 3, Scene 1; Dumby: Experience is the name everyone gives to their mistakes.
<jdub> s/their/they're/ for good measure
<Keybuk> no, that would be wrong
<jdub> that would be experience!
<Keybuk> heh
* jdub burns suse ppc disk 1
<jdub> OF FIVE
<jdub> fascists.
<Keybuk> ya know, I never knew the "The difference between England and America is that when we hold a World Championship for a particular sport, we invite teams from other countries to play too" quote was John Cleese
<Keybuk> hmm
<Keybuk> what did I call the last release of dpkg?
* Keybuk forgets
<jdub> i don't think you called it gawn blotto
<Keybuk> no, I don't think I even understood that one
<Keybuk> it's fine for them to make no sense to other people, but I at least have to get the joke :p
<jdub> gawn is australian for gone
<jdub> blotto is australian for drunk
<Keybuk> I see...
<Keybuk> we had an australian one already
<jdub> fie.
<Keybuk> in fact, we've had two if you count On Like Donkey Kong
<jdub> how about 'aloha'?
<Keybuk> it's quite worrying that there's about 50 of them in my dpkg-release-names file now
<Keybuk> I really need to make some more releases
<Keybuk> Four fonts walk into a bar.  Barman says, "oi, get out!  we don't serve your type"
<jdub> ha ha ha
<jdub> ha ha
<Keybuk> Man walks into a bar with a roll of tarmac under his arm, says "pint please, and one for the road"
<jdub> that is not as good
<jdub> woohoo!
<Keybuk> hmm?
<Keybuk> SuSE downloaded a last, did it?
<jdub> booting opensuse beta3 install cd on this openpower machine
<jdub> Loading Installation System (67420 kB) -  10%
<jdub> ha ha
<Keybuk> I see, defecting are we?
<jdub> no
<jdub> learning their secrets
<jdub> so we too can boot on openpower
<Keybuk> do we not?
<jdub> nup
<Keybuk> cunning
<jdub> doesn't recognise the os on the cd
<jdub> some funky cd build or yaboot foo involved
* jdub keenly awaits kamion's return
<Keybuk> he's not coming back
<Keybuk> and when he does, he's not allowed more than 8 minutes of installer time a week
<Keybuk> he's married now
<Keybuk> it'll be different
<jdub> that's okay, we're in the same club ;)
<Keybuk> yes, but you're married to pia -- which makes you the woman in the family <g>
<jdub> wow, their curses installer has no respect for 19200 bps
<Keybuk> Gentoo's does
<Keybuk> you can install Gentoo over a 300 bps serial line
<Keybuk> "make" doesn't need much in the way of fancy graphics
<Keybuk> actually, someone told me the other week that Gentoo had a graphical installer now.  I asked whether it was XEmacs
<jdub> after configuring the language, timezone and time
<jdub> i have "desktop selection"
<jdub> describing both kde and gnome as "powerful and intuitive" and which mailer, browser and file manager they use
<jdub> comical
<Keybuk> you know the whole "innovation" argument
<jdub> they ask BEFORE PARTITIONING
<Keybuk> where those who claim they're innovating are usually the ones who do all the "ripping off"
<Keybuk> well, two of the gay clubs in Birmingham are opposite the road from each other
<Keybuk> The Nightingale and DV8
<Keybuk> the 'gale, after a refit, opened up during the afternoon and early evening as a bar and restaurant
<Keybuk> they called the bar "B5" ... not really sure why, but that's it's name
<Keybuk> a few months later, DV8 followed suit and opened up their bar outside of club ours
<Keybuk> they called it "innov8"
<Keybuk> I've been trying to explain the irony of this to various friends for a while now, but they don't get it
<Keybuk> (now I think about it, B5 is probably the postcode)
<jdub> why do we do -build versioning again?
<crimsun_> jdub: they signify only a rebuild
<jdub> yeah, what situations do we do a rebuild without changelog?
<Keybuk> libraries underneath them changed
<crimsun_> hmm? changelog should at least note rebuild or something to that effect; usually it's to use newer libs, like Keybuk mentioned
<jdub> man, this installer stinks over 19200
* jdub ignores suse recommendation for reiser
<Keybuk> changelog has to mention it, in fact
<Keybuk> I challenge your claim to have seen a build version without a changelog entry
<jdub> :-)
<Keybuk> BECAUSE, and this is the clever bit, the version number comes _from_ the changelog entry
<jdub> yes dear
<Keybuk> the only other kinds of rebuilds are when they fail on the buildd for some logical reason that just means you have to give them back
<Keybuk> that's the "laaaaamont" kind of rebuild
<jdub> gar.
<Keybuk> that's usually due to being uploaded before the shared library that changed
<jdub> after repartitioning, it suggests i won't be able to boot unless i do a particular thing with partitioning
<jdub> eeeediots
<jdub> and almost every character change requires a screen update
<Keybuk> sweet
<Keybuk> I must admit to having never tried debconf over a serial line
<Keybuk> does that not suck?
<jdub> it's not this bad at all
<Keybuk> hmm, I better get in the shower
<Keybuk> got to get to Uncle Steve's before we head off to the pub
<Keybuk> and it's a 4 hour train ride :-/
<jdub> say hello to the gang
<Keybuk> will do
<Keybuk> ciao
<Hieronymus> Treenaks: wakker?
<Hieronymus> aargh, er zijn weer random mensen die een pm-window met mij openen
<Hieronymus> net als gisteren
<Hieronymus> brr... eng
<Hieronymus> sorry!
<Hieronymus> Wrong channel!
<jdub> ;-)
<Hieronymus> it's because #ubuntu being weird
<ompaul> Seveas, where to now?
<mdz> Keybuk was going to Steve's and the pub at 0700?
<jdub> mdz: four hour train ride
<mdz> jdub: even so...;-)
<jdub> i think they have a bbq and stuff ;)
<pef> hi
<jdub> YAY, ubuntu livecd chroot on the 710 :)
<Treenaks> \\o o//
<jdub> hrm, no devices detected from the mga driver. hrm.
<sivang> jdub: ah, colin has retunred and you made a bootable image? 
<jdub> sivang: no, using livecd chroot on top of opensuse
<sivang> jdub: ah cool, that leaves for me at least some of the work for sunday/monday :)
<sivang> jdub: are you X on the matrox?
<jdub> can't get it running atm
<jdub> (II) MGA: driver for Matrox chipsets: mga2064w, mga1064sg, mga2164w, mga2164w AGP, mgag100, mgag100 PCI, mgag200, mgag200 PCI, mgag400, mgag550
<jdub> (EE) No devices detected.
<jdub> very yummy dual-cpu dual-core though :)
<sivang> jdub: hehe, I know ;) can you post a photo of your machine? (I'd like to see it)
<jdub> um
<jdub> no
<jdub> camera was nicked while i was in the states
<sivang> ah bummers
<sivang> jdub: how is oopensuse on that machine, btw?
<jdub> seems ok
<jdub> only done a minimal install
<jdub> have to get rc on here
<sivang> jdub: rc?
<jdub> red carpet
<sivang> eh :) 
* sivang --> logout, login 
<sivang> jdub: does the machines weighs alot?
<sivang> s/machines/machine/
<jdub> not really, it's surprisingly light
<jdub> 18-32kg says the box
<Treenaks> That's light?
<sivang> Treenaks: that's light :)
<sivang> jdub: mine is about ~50Kg
<sivang> jdub: it's a beast
<Treenaks> sivang: what is it then? :)
<sivang> Treenaks: pSeries POWER5 , hypervisor enabled virtualization platfrom by IBM
<Treenaks> sivang: ah ok :) then it _is_ light ;)
<sivang> Treenaks: I am running 6 operating systems on it, at the same time with no apparent latency.
<Treenaks> sivang: nice
<sivang> Treenaks: It's very interesting piece of hardware
<Treenaks> sivang: I still think virtualisation is being overhyped atm :)
<sivang> it supports virtualizaion at the hardware level, having a special component multiplexing the hardware in a way that each partition, is truely a machine of its own
<Treenaks> sivang: I know what a hypervisor is :)
<sivang> ah oops , sorry:)
<Treenaks> sivang: np :)
<Treenaks> sivang: and it's a really cool idea.. I just don't see the use, that's all :)
<Treenaks> ADJECTIVE ADJECTIVE {EXPLETIVE NOUN}!
<Treenaks> some "YahooSeeker-Testing/v3.9" is retrieving /log/Ubuntu/keyboard-crack.html every _6_ seconds
<sivang> Treenaks: where from? 
<Treenaks> sivang: 68.142.195.82
<sivang> Treenaks: that your ip?
<Treenaks> sivang: no, that's theirs
<sivang> Treenaks: what's that file got in it?
<Treenaks> sivang: a blog post
<Treenaks> sivang: http://foodfight.org/log/Ubuntu/keyboard-crack
<sivang> Treenaks: ah :)
<HiddenWolf> Is the lastest daily working?
* sivang needs a faster machine for gnome pkgs build
<sivang> this testing cycle takes too long..
<Treenaks> sivang: you said you had a POWER5 ;)
<sivang> Treenaks: nonon :) I don't have 15k$ for a computer machine :) it's at work....
<Treenaks> sivang: ssh compilefarm.work :P
<sivang> Treenaks: they bought the higher end of this line, since it's also used as a build server and runs both a couple of instances of AIX and linux simultaneously
<Treenaks> I _really_ like this ultra high resolution on this laptop
<Treenaks> makes the fonts so crisp & clean :)
<Treenaks> 1920x1200 @ 15.4"
<tseng> mm
<HiddenWolf> Treenaks, and you where calling me a showoff when I was happy with my 24" lcd!
* HiddenWolf laughs
<Treenaks> HiddenWolf: oh, you were talking about an LCD :P
<rubenv> j^: I just installed your network manager packages for breezy, they work like a charm, nicely done :-)
<sivang> Treenaks: notification area, is the panel area that displays applets icons? 
<Treenaks> sivang: it's the one which displays the red "You need to upgrade" icon, the Gaim icon, etc.
<hunger> Is there a fixed network-manager deb yet?
<rob^> heh
<hunger> Last monday somebody was working on that...
<rubenv> hunger: not officialy in the archives, but: http://bootlab.org/~j/NetworkManager-breezy/
<sivang> Treenaks: and what is wncklet used for?
<rubenv> sivang: window lists etc
<rubenv> it's a 3 in 1 applet
* hunger is updating 192MiB at the moment... all the stuff that changed since monday.
<hunger> You sure are keeping yourself busy!
<Treenaks> sivang: that's the desktop switcher
<hunger> Could somebody please update sl-modem-daemon to depend on the linux-restricted-modules instead of sl-modem-modules-new (which does not exist in ubuntu)? Better yet: suggest lrm only since sl-modem-daemon runs with alsa as well.
<frans-th> hi all
<frans-th> anyone can share with me the ubuntu development process and license?
<jsgotangco> hey
<frans-th> hi jsg
<frans-th> how r u
<jsgotangco> brb dinner
<Mez> frans-th, ???
<frans-th> wow, what time there? here 5 
<frans-th> hi Mez :) i am from indonesia
<Mez> "<frans-th> anyone can share with me the ubuntu development process and license?"
<frans-th> :P thx
<frans-th> right now, i have a job from goverment, i think jsgotangco, known it, we did a chat in this channel in several days
<frans-th> i have 2 question about ubuntu development.
<frans-th> this is not technical question, can share here? or pm better?
<Treenaks> frans-th: Language? :)
<jdub> frans-th: this is the best channel for it
<frans-th> cool
<frans-th> hi jdub, 
<frans-th> ok
<frans-th> right now, i have a donation from canada goverment, called SIDA for open source development
<frans-th> we will use webservices and java, 
<frans-th> and there is a small project, donation about sun server, for promoting open source, and i will make it become ubuntu repository
<frans-th> those are clear, i just wait the time
<frans-th> and there is a small project, to change ubuntu name become local brand. the project named by our goverment is merpati, mean piegon in indonesian language
<frans-th> but, i am personally better to promote ubuntu, in several way, but need information more about the ubuntu brand.
<jdub> go on
<frans-th> i believe ubuntu brand is more open thatn redhat, suse, and of course JDS :)
<frans-th> JDS here renamed become IGOS Desktop with nick name Garuda, mean eagle in english
<frans-th> i believe that make a new brand, is need more time, becuase the team must rename the ubuntu theme to our theme, 
<frans-th> and of course, change = make it must be tested first, and it is wasting time
<frans-th> i prefer to make the team become part of ubuntu development rather make thi
<frans-th> this project to make sure that we have a free and always free linux solution
<jdub> all of this is fine
<frans-th> any comment on this?
<jdub> we encourage rebranding
<frans-th> in our experience promoting linux in indonesia
<frans-th> there is 2 local brand, made by several of my friend, the software is not good as the original, both is a rebrand from fedora core 3
<frans-th> but, Sun make the JDS become "IGOS Desktop"
<frans-th> and because the promotor is Sun, several goverment love it, but Sun charge for US$ 50/PC
<frans-th> we know JDS is commercial product
<frans-th> i think, in this case, we need a local brand of ubuntu, but ubuntu name there
<frans-th> that is not possible, because there is no ubuntu indonesia here, and there is canonical branch in indonesia
<jdub> hold on
<frans-th> so, if we change to local brand, we cannot make the charisma llike ubuntu that happen here
<jdub> neither of those are restrictions to you creating an indonesian branded version of ubuntu
<frans-th> jdub: what is that mean?
<jdub> you can make your own version without canonical's permission
<frans-th> i think, this channel is cool, you are very helpfull :P
<jdub> also, you could start an indonesian LoCo team
<frans-th> jdub: i know, we can change the ubuntu, if we know how to make it, but the problem is, the trust of the new version must be less than ubuntu name
<jdub> frans-th: you could put "powered by ubuntu" on it :-)
<frans-th> i think, that is better to make ubuntu still :) so the ubuntu brand can become national distro
<frans-th> jdub: Waroeng IGOS and Blankon have that word, create based on Fedora Core 3, but i see after 3 month promotions, the popularity is getting down
<frans-th> jdub: i personally, love ubuntu more :P 
<jdub> why do you think they are less popular?
<frans-th> so, my question is, how open ubuntu brand
<frans-th> they are less popular, because several goverment wont use Waroeng IGOS and Blankon, they prefer IGOS Desktop from Sun, but of course with out paying
<frans-th> i think we need a global brand for this project, or like global support, 
<frans-th> honestly, there are no support from Sun, :) 
<frans-th> just marketing wording
<jdub> ok
<jdub> so canonical provides global support for ubuntu
<frans-th> what kind of global support?
<jdub> but there is also the ubuntu marketplace - a list of companies who are supporting ubuntu
<frans-th> i never got this information
<jdub> see the support section on www.ubuntu.com :)
<frans-th> my point is, i dont want to make a rebranding version :) and the goverment make an exception to make ubuntu become national standard distro, so my job reduced here, just to support ubuntu :P
<frans-th> jdub: can explain about the process of ubuntu development
<jdub> you could become a support partner
<frans-th> ? how open is it?
<jdub> totally open
<jdub> you can become a maintainer of the supported packages :)
<frans-th> that is :) because ubuntu is very very open, make a local brand is not good
<jdub> it's not like fedora/rhel
<frans-th> i will become a maintainer of support in the future, after the server arrived :) i am in the process to there.
<frans-th> that why, because you are more open than fedora, ubuntu brand is the cool brand :)
<jdub> frans-th: would it help you if someone from canonical visited to talk to your government agencies about ubuntu, and how they can use it?
<frans-th> `can..
<frans-th> if there is a canonical guy wanna help me, i can give the goverment contact to you
<frans-th> and he is the project manager of those of this kind of open source movement
<frans-th> and this job directly from the minister
<jdub> frans-th: ok, i would be happy to help
<jdub> jeff.waugh@canonical.com
<frans-th> ok
<frans-th> i will email you and cc to him,
<jdub> great!
<frans-th> you can ask to those guys, that rebranding is a good case for education, but your investment from canonical, is better the goverment join the ubuntu netwrok
<frans-th> what do you think?
<jdub> sounds good to me
<frans-th> ok
<jdub> i will have to find out what sounds good to them ;)
<frans-th> i will email you and cc to him
<frans-th> cool
<hunger> daniels: You maintain the linux-restricted-modules now in addition to X? You must be a busy guy.
<frans-th> because if we success, the 800 PC that is donated to the schools here, can become more popular :)
<jdub> :-)
<frans-th> because the openenst of ubuntu :)
<frans-th> wait ok :P
<jdub> j^: ping
<j^> jdub pong
<frans-th> :P
<jdub> j^: just trying out your n-m packages - NM is failing to start bind
<tseng> speaking of, can we upload those soon?
<rubenv> j^: any way to make it not ask my keyring password every time I boot up?
<j^> jdub did you make sure it is not running before starting NM?
<rubenv> now I have to login
<rubenv> wait for it to detect my wired is not cabled
<jdub> j^: yeah, i stopped it
<rubenv> enter my keyring pass
<j^> jdub whats the error in syslog?
<rubenv> and then I finally have networking
<jdub> aha
<jdub> Aug 27 21:00:35 ubuntu named[10522] : couldn't open pid file '/var/lib/NetworkManager/NetworkManager-pid-named': Permission denied
<jdub> Aug 27 21:00:35 ubuntu named[10522] : exiting (due to early fatal error)
<j^> rubenv i dont know a way, you might ask on networkmanager-list@gnome.org
<j^> jdub does /var/lib/NetworkManager/ exist?
<rubenv> j^: will do, thx
<jdub> yeah
<j^> hm
<jdub> i'm starting it as root, too ;)
<j^> /etc/dbus-1/event.d/25NetworkManager does:
<j^>   test -d /var/lib/NetworkManager || mkdir -p /var/lib/NetworkManager
<j^>         chown -R bind:bind /var/lib/NetworkManager
<j^>         chmod 755 /var/lib/NetworkManager
<frans-th> jdub: finished email to you :P
<jdub> oh
<jdub> aha
* jdub restarts dbus
<jdub> boh
<j^> would be cool if /etc/init.d/dbus restart would restart dbus :)
<{Seb}> oin #ubuntu
<frans-th> jdub: i will call the contact after this, and hopefully he will love it :)
<jdub> hj
<jdub> j^: ok, so that fixes it, but nm-applet could not start due to missing resources...
<j^> jdub missing resources?
<jdub> seriously ;)
<j^> thats the error message?
<jdub> The NetworkManager applet could not find some required resources.  It cannot continue.
<j^> never seen that
<j^> what does it say in the terminal?
<jdub> ** (nm-applet:10963): WARNING **: Icon nm-no-connection missing: Icon 'nm-no-connection' not present in theme
<jdub> though it's there
<jdub> and i've rebuilt the cache
<j^> nm-applet --sm-disable
<jdub> yeah, get the error, don't get nicon
<jdub> /usr/share/icons/hicolor/22x22/apps/nm-no-connection.png
<j^> is that installed?
<jdub> yep
<jdub> aha!
<jdub> i forced an icon cache rebuild for hicolor
<jdub> now it's happy
<j^> how can one do that? might be something for nms postint
<j^> *postinst
<jdub> gtk-update-icon-cache -f /usr/share/icons/hicolor/
<jdub> maybe don't need the -f, but it worked for me
<jdub> hrm, the nicon is annoyingly wide
<j^> there is some discussion on the list about it
<jdub> so how do you interop with /etc/network/interfaces ?
<j^> right now it read /e/n/i on startup,
<j^> if it finds iface .. static 
<j^> it uses that
<jdub> uses that as seed configuration?
<jdub> ah, right
<j^> nameservers are a problem right now
<j^> for static configuration
<j^> if nothing or dhcp is fond in /e/n/i NM handles all on its own
<j^> modem connections are also read from /e/n/i iface .. inet ppp
<j^> but that is all part of the debian backend and can be changed
<jdub> excellent :)
<jdub> i'll keep testing
<j^> enjoy
<j^> if you have a vpnc server you can also test that
<hunger> j^: When will it hit the ubuntu archives?
<j^> i dont, so i only packaged it
<hunger> j^: only post-breezy?
<j^> hunger thats up to infinity or the person maintaining nm in the end, it could/should go into universe now
<j^> since the version in universe does not work at all
<hunger> j^: Yeap, I fully agree with you on that:-)
<j^> and main inclusion was moved post-breezy if i understand right
<hunger> j^: Yes, that was my impression as well.
<j^> that would also need some work on things like network-amdin
<hunger> j^: And I still do not like nm too much... I hate having several places to configure things.
<j^> network-admin and NetworkManager do not like eachother 
<j^> hunger several places?
<hunger> j^: /e/n/i and wherever NM stores its stuff.
<jdub> NM is dynamic :-)
<hunger> jdub: It does store wlan keys, etc., dosen't it?
<j^> hunger you should not have to use static ips on a laptop in a dynamic workd
<j^> *world
<tseng> hunger: in gnome keyring
<hunger> j^: No, but I do have lots of WLAN ids, currently nicely configured in /e/n/i.
<j^> hunger move on and remove it
<j^> legacy
<j^> if you want to use NM forget about any systemwide wireless configuration
<hunger> j^: Yes... but since NM can not handle static IPs I still need those.
<j^> hunger you could make NMs static ip support better
<j^> or you could stop using static ips on wireless networks
<hunger> j^: NM can not handle systemwide WLAN configs? Now that is annoying!
<jdub> why are systemwide wlan configs important to you?
<j^> hunger complain on networkmanager-list@gnome.org
<hunger> j^: Because I do not want my users to set up there own...
<j^> hunger in which case NM is not for you
<hunger> j^: Only root should do that or they will use their laptops at home and stuff.
<j^> NM is for laptops and dynamic network environments
<hunger> j^: s/at home/in non-approved environments/ ;-)
<j^> not for "i dont want users on my laptop to change the wireless settings, but they are free to take out the battery"
<hunger> j^: They can take out the battery all they want... as long as they do not use unlicensed networks:-)
<j^> haha, how long does it take you to change the root pwd of you have the laptop on your lap?
<hunger> j^: It is not about how long it takes *me*, but how long it takes my users.
<j^> one boot with the livecd
<j^> security by obscurity?
<hunger> j^: Not possible...
<hunger> j^: Yes... to an extend.
<jdub> hunger: mandatory settings for n-m will turn up fairly soon, probably after it stablises bit
<j^> hunger i come back to the point, you can add that functionality to nm if you need it
<j^> or not use nm
<hunger> j^: I think not using NM is the easier option to take:-)
<j^> i for one do not understand what why you would limit wireless access 
<j^> like that
<hunger> j^: I never claimed I did... ask the management.
<j^> its wrong from the conseptual side
<j^> fix the management
<hunger> j^: I definitly prefer writing NM from scratch to that:-)
<j^> haha
<j^> i love people that are so confident of how much they can do
<j^> see you next year
* j^ starts writing TheManagement from scratch
* siretart thought network-manager was dropped for breezy. is that correct?
<tseng> the goal was dropped
<tseng> the package was not
<jdub> the goal was dropped
<jdub> heh
<tseng> we should add j^'s package
<tseng> because they arent spectacuarly broken
<jdub> totally
<siretart> good idea
<jdub> j^: are you a MOTU?
<j^> jdub no
<siretart> j^: do you have a package ready for upload?
<jdub> http://bootlab.org/~j/NetworkManager-breezy/
<jdub> :-)
<crispin> j^, yeah, thanks for your package, I was using an ancient version, but yours work wonderfully :-)
<jdub> oh, hey crispin 
<j^> jdub where do i have so sign to be a MOTU
<crispin> hi jdub 
<siretart> ok. who wants to upload his crack? ;)
<jdub> j^: all info on wiki.ubuntu.com/MOTU
<siretart> j^: /join #ubuntu-motu
<jdub> OH SUDDEN PAINS OF HUNGER
<tseng> haha
<Mithrandir> j^: why on earth do you think that freedesktop #4267 is critical?
<HiddenWolf> Who did secondstageinstallerprogress?
<jdub> kamion
<tseng> i thought mvo
<HiddenWolf> In any case, you've got a glaring bug there. It just stalls if it needs to install a dependency and the cdrom is not in the drive. I'll file a bug as soon as I've got a workable system.
<HiddenWolf> (discover1, libdiscover & others)
<j^> Mithrandir because that breaks using pkg-config on mingw32?
<HiddenWolf> daniels, around?
<Mithrandir> j^: if you use -uninstalled, yes.  Anyway, if you can find out why it does that, it would be appreciated; I don't have a mingw32 box.
<hunger> Any ideas why I get "Invalid module format" on insmods?
<j^> Mithrandir first i wanted to creat a bug, later i will check if i can find the problem
<Mithrandir> j^: ok, patches accepted.
<Lathiat> has gamin / nautilus upating etc stopped working for anyone else recently? it seems to pretty much never work 
<jdub> my desktop doesn't seem to list half the files on it sometimes
<Lathiat> but pressing control-r finds them?
<Lathiat> menu updating hardly works either
* Lathiat looks for a recent gamin upload
<infinity> Meh.  Has anyone else seen apt-listchanges segfaulting recently?
<Mithrandir> : tfheen@vawad ~ > file =apt-listchanges
<Mithrandir> /usr/bin/apt-listchanges: a /usr/bin/python script text executable
<infinity> Right, not apt-listchanges itself... An strace show the last thing before death is opening /usr/lib/python2.4/site-packages/gtk-2.0/atk.so
* infinity checks to see if he can reproduce it on another machine.
<infinity> Fun, it just hangs on another machine.  I guess I need mvo/mdz to give it some love.
<jdub> http://stream.fluendo.com:8850
<jdub> mark at akademy ^
<siretart> w00t!
<sivang> jdub: very nice :)
<sivang> jdub: talking about KDE in ubuntu?
<jdub> hasn't touched on that yet
<jdub> he's doing the usual keynote atm
<sivang> jdub: ah, is it live feed ?
<jdub> yes
<HiddenWolf> anyone here working on xorg?
<sivang> jdub: cool
<HiddenWolf> Guys, I have a sudoer user with "acces to cdromdrives" enabled in users-admin, but I cannot acces my cdroms... where do I file that bug?
<joefso> hello
<joefso> cdimage.ubuntulinux.org is down
<joefso> sometimes it's up for a view seconds
<Seveas> try releases.ubuntu.com
<Seveas> or se.releases.ubuntu.com
<slomo> does somebody know why ffmpeg is in main? it seems like it isn't needed by any main packages
<slomo> oh sorry, kino needs it and is in main...
<Treenaks> _needs_ it?
<siretart> it links against it
<slomo> yes... build-depends against libavcodec-dev
<azeem> kino does not use gstreamer, unfortunately
<azeem> or not yet, dunno
<siretart> ffmpeg is really a pita :/
<hub_> do we really have the choice ?
<hub_> what can replace ffmpeg ?
<azeem> well, kino should be replaced with that new, whiz-bang, gstreamer based video editing application
<siretart> that would probably be best
<azeem> at least mid-term
<slomo> hub_: nothing... but currently it's somewhat broken and imho it belongs in multiverse...
<hub_> I have heard people bitching about their lack of release process
<hub_> so I'm almost not surprised
<azeem> "their" == ffmpeg
<azeem> ?
<hub_> yep
<hub_> ffmep release process
<siretart> gnaarf
<hub_> what is the rule for universe vs mutliverse?
<infinity> azeem : What new whizbang video editor is this?
<siretart> ffmpeg seems to be a bigger PITA than thought
<infinity> azeem : I was under the impression kino was the best we had to offer currently.
<siretart> hub_: universe is free software as in dfsg
<Alex> mako: Can you give me a shout when you're around please?
<siretart> hub_: multiverse is all kind of software with funny licences. some of them are patent encumbered, some not
<hub_> ah ok
<hub_> so any GPL but patene encumbered go there
<siretart> yes
<infinity> hub_ : It's easier if you read main and restriced as "supported/free and supported/non-free", and universe and multiverse as "unsupported/free and unsupported/non-free", perhaps.
<slomo> hub_: yes... for example lame ;)
<hub_> looks like one of my packages on REVU will end up in multiverse
<siretart> or mplayer
<siretart> hub_: which?
<hub_> autopano-sift
<hub_> university of BC has a patent in the US
<hub_> BC = British Columbia, Canada
<infinity> Is it being actively enforced?
<azeem> infinity: http://www.pitivi.org/
<hub_> infinity: don't know
<azeem> http://www.linuxdevcenter.com/pub/a/linux/2005/08/18/linux_video.html
<infinity> azeem : Looks reasonably immature still, but promising.
<azeem> yeah, I qualified my assertion to 'mid-term' :)
<infinity> Is also seems to depend on gst-ffmpeg...
<infinity> Not sure how that solves anything. :)
<slomo> gst-ffmpeg seems to ship there own version of ffmpeg... at least it doesn't build-depend on libavcodec-dev
<infinity> And statically compiling fixes license issues, how? :)
<infinity> (or whatever people's concerns are with ffmpeg..)
<siretart> it fixes the problems that ffmpeg seems to change apis like other people changing underwear
<slomo> infinity: i don't know... but imho this ffmpeg stuff really belongs in multiverse ;)
<siretart> it at least in restricted..
<j^> pitivi does not depend on gst-ffmpeg
<j^> but it depends on gst-0.9
<infinity> j^ : The "what should you have installed" bit claims you should have gst-ffmpeg.
<j^> and gst-ffmpeg uses its own version of ffmpeg which you can see here http://cvs.freedesktop.org/gstreamer/mirror/ffmpeg/
<infinity> Though it also claims gstreamer 0.8.10, so perhaps it's just out of date.
<slomo> infinity: it helps to have it... but you can also use it without gst-ffmpeg... gst-ffmpeg only adds support for more formats
<infinity> slomo : Sure, but how many people, realistically, won't want support for those formats.  Handwaving with "well, you CAN use it without X, Y, Z" isn't helpful.
<j^> infinity are you refering to pitivi 0.1.1=
<j^> ?
<azeem> indeed, I think the main merit is that you don't need to link against some library, but just decide which gstreamer plugins are available at run-time
<infinity> j^ : I'm referring to the website.  <shrug>
<j^> Please do not use version 0.1.1 or earlier of PiTiVi. They are deprecated, unsupported and cause cancer. Use at your own risk ! Wait for the next release or try out the cvs version.
<j^> you can join working on it, but currently its moving from gst-0.8 to gst-0.9
<j^> it would not recomend spending much time packaging the old version
<slomo> infinity: noone ;) hm, are main packages allowed to have multiverse/universe ones in Suggests/Recommends?
<infinity> Yeah, I wouldn't touch it at asll right now anyway.
<infinity> Give it a bit more time ot mature, and I may be interested in supporting it in main for breezy+1... If it really is moving that quickly.
<infinity> slomo : In suggests, sure.
<siretart> can someone reproduce an instant rythmbox crasher?
<infinity> slomo : It's bad form to recommend something non-free, as most decent package frontends attempt to auto-install (or auto-select) Recommended packages.
<slomo> infinity: ok... good to know :)
<infinity> slomo : If/when all the frontends properly support "Enhances", suggesting anything non-free would also be bad form, as the non-free package should just declare "Enhances: <foo-in-main>"
<infinity> slomo : But that's mostly a matter of taste/style, as the end result for the user would be the same.
<jordi> elmo: ping
<infinity> Does Jani Monoses IRC?
<slomo> infinity: yes.. that's janimo... he was yesterday and the day before at least in -motu
<infinity> slomo : Ahh, doesn't seem to be around right now.
<infinity> slomo : If you see him around, can you smack him around a bit for "fixing" exo by adding libglitz to its build-deps?
<slomo> infinity: i've done already ;)
<infinity> slomo : seb128's been frantically trying to REMOVE libglitz dependencies (which is why exo was broken).
<slomo> infinity: iirc ajmitch wanted to upload a really fixed version soon
<infinity> slomo : Anyhow, I've uploaded a glitz-free libxfcegui4 and exo is following it, so that should fix it all up properly.
<siretart> those transitions like the libglitz desaster should really be announced on ubuntu-devel
<HiddenWolf> anyone here working on udev?
<infinity> slomo : I'm not sure really if we have proper procedure for this stuff, but if main changes in a way that breaks a mess of stuff in universe and you guys aren't sure why, it would be nice if you poked some distro guys for answers.
<jdub> siretart: yeah, they should
<infinity> siretart : Yeah, the glitz thing is/was thpethul.
<siretart> thpethul?
<infinity> Picture me slamming my limp wrist violently into my chest while I say it.
<jdub> siretart: saying 'special' with a strong... speech impediment
<slomo> infinity: sure... but it seems some know of it, some don't :(
<siretart> aah. thanks..
<infinity> slomo : Yes.  Ideally, seb should have posted to -devel (and probably -motu too, now that you have one)
<infinity> slomo : I'll try to be more proactive in pinging people about transition issues as I see them from my position (and I see them all, whether I want to or not)
<slomo> infinity: not -motu... universe-bugs afaik
<siretart> -devel should be fine
<jdub> jordi: catalan's primary locale id is CA, right?
<infinity> -devel shold be enough, yes.
<jordi> yes.
<jsgotangco> hey jdub
<jordi> which conflicts ubuntu-ca :)
<infinity> jordi : Yes, and it confuses every Canadian I know. :)
<jdub> jordi: hrm, this is going to get confusing with the canadian loco team
<jordi> yup.
<jordi> those lists should have been named ubuntu-loco-ca anyway.
<jdub> the standard we have is ubuntu-??-l10n
<jordi> If it's about territory.
<infinity> <shrug>... It's not isolated, though.  Lots of country codes conflict wiht language codes.
<jdub> weeeell...
<slomo> infinity: maybe we should create/extend a policy for that... "announce transitions to -devel" or something similar
<jordi> jdub: there's only one list with that scheme
<jordi> and it's brand new.
<jdub> there are two
<jordi> Maybe we are on time to fix the standard.
<jordi> two? hm.
<jdub> but seb hasn't made the fr one public
<jdub> i don't think the l10n standard is incorrect
<jordi> anyway, ubuntu-l10n-ca would match the lp scheme
<infinity> slomo : Not sure we need a written policy for it, but asking people politely to explain transition issues on -devel when they break things isn't a terribly bad idea. :)
<jdub> and ubuntu-?? covers TLDs and languages, in some cases
<jordi> I wonder how many en_CA translators will join.. :)
<infinity> slomo : I'll bring it up with seb when he comes back from his short vacation.
<jdub> jordi: i standardised on ubuntu-??-l10n for sort order reasons
<jdub> and relationship to loco team
<slomo> infinity: ok, fine :) or maybe some wikipage which lists all transitions with the current state
<jordi> then Catalan, Ukrainian and other langs are left out in the cold I guess. :)
<jdub> unfortunately, we had different demands for loco teams
<jdub> the french and chinese speakers really wanted language lists, not region lists
<jordi> jdub: is mailman-admin@ incorrect?
<jdub> i just replied to your email
<jordi> k
<jdub> it's just mailman@
<jordi> ok.
<jordi> I will kill carlos.
* jordi rushes to fix the wiki.
* jdub furrows brow.
<infinity> slomo : With the exception of really complex transitions (like the C++ transition), editing a massive wiki page to make small changes/progress is a lot more effort than just fixing all the packages and uploading them, at least I find so.
<jordi> jdub: for ordering reasons, ubuntu-l10n-* orders lists too
<infinity> slomo : I could fix the glitx issues (and am working on it) faster than explaining it to other people in a formal document (and keeping it updated)
<jordi> (and I guess all other projects out there do stuff like this
<jdub> jordi: not alongside the loco lists, however
<slomo> infinity: no i meant just a list of all transitions, not the packages which are involved ;)
<infinity> slomo : But I'm not against just sending a quick note to -devel and assuming that everone on distro/motu will read it.
<jdub> however, i'm *this* close to switching
<jordi> jdub: I guess the code clashes make this incompatible :(
<jdub> hrm, seb's not here
<slomo> infinity: something like "CXXTransition: done" or "libcairo1 transition: work in progress"
<jdub> nor koke+carlos
<infinity> slomo : You're welcome to make such a page and ping me for info on the current status (since I keep my finger on the pulse of most transitions in progress)
<slomo> infinity: ok, i'll add this to my todo list ;)
<infinity> slomo : I don't feel like adding "document transition status" to my list of duties, but I definitely don't mind someone else doing it and asking me for input.
<jordi> jdub: just DO IT :)
* siretart also thinkgs that an email with a list of packages which need to be rebuilt should really be sufficient
<Mitario> elmo, ping
<OculusAquilae> hi
<OculusAquilae> are there problems with #ubuntu . It always says, that I'm banned
<tseng> its locked to registered users only
<tseng> to keep out spambots
<OculusAquilae> tseng: how to register?
<tseng>  /msg nickserv help
<OculusAquilae> thanks
<LaschW> How is a registration done? Any HowTo about that?
<tseng>  /msg nickserv help
* ..[topic/#ubuntu-devel:tseng] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze! https://wiki.ubuntu.com//HelpingWithBugs | Colony 3 is released: http://cdimage.ubuntu.com/releases/breezy/colony-3/ | #ubuntu is temporarily open to registered users only to prevent spam bots. /msg nickserv help to register
<OculusAquilae> tseng: hm, me and another guy are registered and it doesn't work 
<tseng> works for me
<tseng> did you identify to nickserv?
<OculusAquilae> yes
<LaschW> tseng: It's me who is the other guy...
<LaschW> tseng: me too
<OculusAquilae> :-)
<tseng> if you are properly registered and identified, i dont see why you would have any problems getting in, sorry.
<azeem> 16:25 [OPN]  -!- 0 - #ubuntu: ban *!*@*.dip0.t-ipconnect.de 
<azeem> is that not applicable to registered users?
<LaschW> tseng: I would see it _very_ strange to be banned whithout _ever_ posting to the channel.
<Lathiat> LaschW: its more than your ISP is banned
<Lathiat> perhaps someone was being a git
<LaschW> tseng: Up to now I've only been listening
<tseng> its a ban on the entire block
<tseng> i dont run #ubuntu, sorry.
<LaschW> tseng: a block on an IP range???
<tseng> LaschW: yes???
<OculusAquilae> seems so, strange
<tseng> he just showed you the hostmask being blocked.
<LaschW> tseng: never heared that before, not for irc...
<tseng> but im sorry to say, I cannot help you.
<LaschW> tseng: who may be able to give a helping hand?
<tseng> Seveas is the only oper
<OculusAquilae> hm
<LaschW> Seveas: Did you follow the thread between tseng, OculusAquilae and me?
<Seveas> no, reading back now
<Seveas> yeah, that ban is part of spambot prevention
<Seveas> it failed anyway, I'll remove it
<OculusAquilae> thanks
<LaschW> Seveas: Hey seems you are quite close to me, location Friesland, maar het duitse Friesland
<Seveas> I'm not in Friesland :)
<LaschW> Seveas: Hhhm, but I would say that most dutch counties are much closer to Friesland than bavaria, eg. :-)
<Seveas> hehe
<Seveas> that's true
<LaschW> Seveas: Most people are not able to differentiate between Friesland / Netherland / Denmark. So at least most people who are more than 500km in distance
<Seveas> hahaha, how true :)
<LaschW> Seveas: differentiate / onderscheidmakentussen
<LaschW> Seveas: Pardon my pidgin english
<LaschW> Seveas: May I ask how this bann occured, technical? 
<Seveas> there are spam bots all over freenode
<LaschW> Seveas: Has it been a ban on IP level as tseng mentioned?
<Seveas> yup
<Seveas> *.dip0.t-ipconnect.de was banned
<LaschW> Seveas: Interesting, didn't know that this could be done up to now
<Seveas> One can just as much ban *!*@*
<Seveas> which means: everyone :)
<LaschW> Seveas: *.dip0.t-ipconnect.de is another ip range than my Provider uses...
<hunger> where did you ban me?
<LaschW> Seveas: And *.dip0.t-ipconnect.de will ban some million german Telecom customers. At least it's the biggest provider, afaik
<\sh> it is the biggest
<hunger> Seveas: Yeap... and it has lots of subcontractors as well... you basically locked out 95% of all german broadband users.
<Seveas> yeah, that's why I removed it
<hunger> Seveas: Thanks!
<Seveas> the spambots have way too big a net to ban effectively
<\sh> Seveas: whats the prob with t-online?
<Seveas> one of the nets abused by the spambot attack...
<Seveas> (which is still going on)
<\sh> hmmm...freenode can file a complaint against t-online users 
<\sh> abuse@t-online.de or so
<LaschW> Seveas: I've never noticed spam / spambots up to now. How do they occur, as normal users who behave as trolls?
<OculusAquilae> i had some spambots today
<Seveas> users that quickly enter+exit a channel and then spam all users on the channel in PM
<Seveas> has been going on for almost a day now
<hunger> \sh: t-offline does not really care in my experience.
<Seveas> #ubuntu is currently blocked for non-registered users, these are forwarded to a channel wher I'm announcing this periodically
<\sh> hunger: they're caring when the users are blocked on ip range
<LaschW> Seveas: PM means per E-Mail not per private chat?
<Seveas> PM = private message
<hunger> \sh: it is "only" IRC and only one network as well.
<OculusAquilae> fucking spammers :-(
<\sh> hunger: it's freenode..many opensource devs have dsl from telekom or their subcontractors...so the users will complain as well, and then t-online has to react
<LaschW> OculusAquilae: I would say you never have been in contact to t-online abuse team. :-))
<\sh> actually...at our company...we're caring about and we're closing the account temporalily during investigation of spam or other activites not allowed in our contracts
<LaschW> OculusAquilae: It's better called NOabuse-team or better ProAntiabuse-team.
<hunger> \sh: All I am saying that the company is *extremly* unresponsive.
<\sh> hunger: lemme ask for the contacts to t-online from my security it boss :)
<Mitario> could someone update gconf2? it still depends on libglitz
<hunger> \sh: It does not even care about people when they tell them that they are going to leave if they are ignored much longer.
<Seveas> grmbl
<Seveas> freenode is crap
<\sh> hunger: u will always come back to the telecom in this or that way...that's the thing...
<Seveas> it's the only network that i'm getting disconnects from
<Treenaks> Seveas: try darkernet, it's even more crap ;)
* LaschW thanks Seveas for fixing #ubuntu ban and leveas for supper
* OculusAquilae too
<\sh> me has supper right now..a nice dner
<infinity> Mitario : Working on it... It's a weekend, expect people to be a bit slack. :)
<Mitario> infinity, heh, np :) just discovered it was depending on libglitz when I was looking at rhythmbox :)
<infinity> Mitario : No big deal.  Everything that isn't horribly FTBFS will be rebuilt for cairo/glitz in the next day or two.
<Mitario> allright great :)
<Seveas> hmm, how many transitions were ther in the past months?!
<infinity> Seveas : Lots.
<Seveas> I certainly lost count
<infinity> gcc-4.0, c++ ABI bump, libcairo1 -> libcairo2 -> libcairo2 without gliz, GL/GLU from xorg to mesa, aalib -> libaa, slang1 -> slang2.... Uhm.
<infinity> A few.
<\sh> cxx, xorg, cairo, slang (ongoing), unmetdeps (ongoing), gl/glu, gl/glu-mesa
<\sh> too many
<infinity> <shrug>... I don't mind so much.  If we get all this sorted, we'll be in really good shape for a nearly transition-free devel/release cycle for breezy+1.
<infinity> Which is high on my list of Really Good Things.
<slomo> Seveas: https://wiki.ubuntu.com/Transitions  <--- that's the page i created a few minutes ago... because i also lost track ;)
<jdub> infinity: *cough*
<infinity> jdub : Swallow something?
<jdub> infinity: 'sif it's going to be transition free :)
<infinity> jdub : I did say "nearly".
<jdub> (of course, we could just specify that as a goal, and JFDI(
<\sh> infinity: well..regarding main, u r right, regaring universe...I think we will have a bumpy right when breezy is released...and for breezy+1 we have to polish everything
<infinity> jdub : In comparision, it will SEEM transition-free.
<jdub> haha
<Seveas> slomo, that's not complete
<infinity> \sh : I keep switching hats back and forth in an effort to try and help you guys keep universe buildable/installable.
<Seveas> it misses the mono and X transitions at least ;(
<Seveas> ;)
<infinity> \sh : I wouldn't be too doom and gloom about it, I think we'll be in good shape in universe.
<slomo> Seveas: maybe... so please add it :P
<Seveas> I don't know their state..
<slomo> Seveas: and mono transition is long over... so not really necessary
<slomo> Seveas: set it to unknown... i don't know the state for x transition either
<Seveas> and gcc4 of course
<\sh> infinity: for breezy+1 we need to "plan those transitions" much better for universe...I talked with ogra about it..and we're working on it :)
<infinity> \sh : Building reverse-build-dep and reverse-dep trees/maps can go a long way to making things easier.
<\sh> anyways...the week after next...I will hit again :) 
<infinity> \sh : If you can do a full transition (modulo FTBFS issues) in one well-ordered string of uploads, life is much easier.
<mako> Alex: around
<\sh> infinity: yepp but u know...it will be my first ubuntu release and the next will be much better :)
<\sh> infinity: so for breezy I didn't know anything at all...(work processes etc. in debian env.) but now..I learned, I'm trained...and lets rock on breezy+1 ,-)
<infinity> \sh : Heh.  Debian development in general is an interesting learning experience, and I can imagine that starting with Ubuntu (where our release cycle are short and furious) is even more interesting.
<Seveas> "Ubuntu -- where the release cycle are short and furious"
<Seveas> nice slogan
<\sh> infinity: I mean, I worked on debian packages long ago..but when u r not all day long involved in some working processes..it's really hard to accomplish some things..but now it was a real push of my knowledge and I learned a lot
<jdub> having very fast turnaround times for this stuff is a huge benefit
<\sh> Seveas: right it down, put a (c) 2005 by Adam Conrad to it..and make it a heading for "DeveloperResources" ,-)
<\sh> s/right/write/
<\sh> I found a nice logical bug today in launchpad
<\sh> bugs filed to products, are not mentioned in common malone buglist...and it's not possible to assign them != upstream maintainer
<infinity> jdub : Being able to do transitions rapidly is quite nice, but it can also be a lot more stressful than the Debian environment.
<infinity> \sh : I assume you're filing bugs on malone as you find them?... I know Brad loves quality feedback.
<HiddenWolf> Any kernel/alsa hackers here?
<tseng> jdub: its also an assload of work on people like \sh
<infinity> tseng : Bah.  \sh enjoys pain, that's obvious.
<\sh> infinity: hahahha
<\sh> infinity: I'm not in SM, actually not while I'm working on software ,-)
<jdub> infinity: ie. it's hours/days of people pinging you instead of drawing it out over weeks/months ;-)
<infinity> jdub : Yeah, but it means I can't ignore my emails for months.  <cough>
<infinity> :)
<infinity> (funny story: I fired up my Windows laptop the other day to rescue an old email from Outlook, and was informed by Outlook that I had a task that was 230 weeks overdue...)
<jdub> heh
<jdub> j^: do you not want to use dhcdbd?
<j^> jdub not at compile time
<j^> its just needed by configure at the moment to get its path
<j^> --with-dhcdbd=/sbin/dhcdbd should too too
<j^> *doo
<jdub> oh
<infinity> ls
<infinity> -EWIN
<\sh> hmmm...I'm in need of a linksys wrt54g router 
<\sh> and they sold it last time at saturn for less then 50 
<infinity> (base)adconrad@cthulhu:~/cairo$ apt-get source `cat brokenPackages`
<infinity> Reading package lists... Done
<infinity> Building dependency tree... Done
<infinity> Need to get 131MB of source archives.
* infinity sighs and waits.
<jdub> *snicker*
<Mithrandir> infinity: that's less than just ooo2-amd64 or ia32-libs.  Don't complain.
<xhaker> someone using wireless here that can send a file with the iwlist scan output?
<xhaker> can't find anything on the net
<sivang> does anybody experience problems with irssi? I get the screen all blue every once when a new msg appears
<Mithrandir> sivang: you're using screen and gnome-terminal?
<sivang> Mithrandir: yeah, what causes it?
<Mithrandir> and have switched to another tab after you connected to the screen?
<Mithrandir> it seems like it's a bug in gnome-terminal.  Annoying.
<sivang> very much, but I think I've opened a new tab, then closed it altogether.
<sivang> (and still getting this bug)
<Mithrandir> just disconnect and reconnect the screen.
<sivang> Mithrandir: ok, I'll do that, thanks
<sivang> Mithrandir: hrm, actually you mean to kill the server's screen session and then restart it?
<Mithrandir> no, just C-a d  and then screen -rd again
<jbailey> C-a c, C-a <spc> is usually enough for me.
<jbailey> Or I resize the window.
<infinity> I detach and reattach.
<infinity> And, for the record, it happens with BitchX too (someone was under the impression that it was only reproducible with irssi)
<Mithrandir> I just don't use gnome-terminal. :-)
<jbailey> infinity: Aren't you supposed to be asleep?
<infinity> Yup.  I'm doing a fantastic job of it, too.
<sivang> Mithrandir: what do you use instead?
<sivang> [OF]  does anybody know if H.G. Wells was British or American?
<infinity> http://en.wikipedia.org/wiki/H.G._Wells
<jbailey> sivang: http://en.wikipedia.org/wiki/H._G._Wells mentions a whole bunch of 'royal' this and 'royal' that.
<jbailey> So I'm guessing not American.
<infinity> He was British, yes.
<infinity> Also....
<infinity> jbailey : JINX.
<\sh> *grmpf*
<\sh> I think I have to buy some beer for tonight and have a look to boson-base with a dizzy brain
<\sh> I hope that I understand what they're trying to "develop" there...
<sivang> \sh: what's boson base?
<\sh> a 3d game enviroment...
<sivang> infinity: why JINX  ?
<\sh> hmm..it looks like it wants to have an older version of kde-games include headers
<Mithrandir> sivang: pterm
<\sh> no wonder that all *.ui files of this package were broken
<\sh> and new version of this, doesn't build as well...hellaluja
<[SemTeX] > I just upgraded my hoary to breezy on a laptop and found a problem with the x config
<[SemTeX] > it sets a mouse as corepointer, but there was no mouse on the laptop
<[SemTeX] > had to fix this manually and set the touchpad as corepointer
<\sh> normally it has 2 entries...
<\sh> the mouse as core and the touchpad (synaptics normally) as second pointer
<[SemTeX] > it had
<[SemTeX] > but didn't start with that config
<\sh> hmmm..
<[SemTeX] > so i commented out the mouse and set synaptics as corepointer
<\sh> strange..cause it starts here..
<[SemTeX] > weird
<[SemTeX] > i'll try to enable the mouse back and test some other things to be sure :)
* xhaker is away (Away, bnc logging)
* sivang listens to pink floyd war of the worlds audio transcript, remarkable. (much better then the movie, IHMO)
<\sh> sivang: u mean the new movie or the old one?
<Coyctecm> I can't disable touchpad via button in keyboard...
<sivang> \sh: ah, I've never seen the old one (frmo 1952?) but I can guess its better
<sivang> Mithrandir: I had bit quite with the terminal bug, but now it returned
<\sh> sivang: i think so...but i don't know the correct movie date...have to look...
<jordi> jdub: any update on thel ists stuff?
<jordi> I figure he must be sleeping.
<jordi> jdub: I'll be back tomorrow night or monday.
<jordi> laters.
<HiddenWolf> Who is the Alsa guy?
<Treenaks> HiddenWolf: you are ;)
<HiddenWolf> I'm the guy with an horrific confusing bug that I need to figure out how to fix. :P
<HiddenWolf> alsa maintainer field isn't set. :S
<crimsun> what type?
<HiddenWolf> maintainer is set to some debian email adres. Doesn't tell me who I need to bug to figure this stupid thing out.
<crimsun> HiddenWolf: this is probably better addressed in #ubuntu
<HiddenWolf> crimsun, I've tried #ubuntu, and -nl. seveas and treenaks don't know. Little hope for me among the general public.
<crimsun> I wasn't paying attention, recap
<HiddenWolf> I just want to get a clue about what's going wrong, so i can file a meaninful bug. :)
<Treenaks> HiddenWolf: bugzilla.ubuntu.com ; file a bug on "alsa"
<Treenaks> or something?
<HiddenWolf> Treenaks, I did, but the only thing I can tell is that I don't get sound on either soundcard on either an upgrade or a fresh install of Breezy daily.
<crimsun> I'm sorry, HiddenWolf, but I'm pressed for time currently. Can you recap in #ubuntu?
<HiddenWolf> Now that's not likely to get it fixed fast. :S
* sivang grumpfs. Why can't gnome panel and the applets use the same method for menu creation...
<pef> hi
<\sh> madduck: ping
<madduck> \sh: yes?
<madduck> \wii \sh
<madduck> argh. i have latexitis
<\sh> madduck: hehe...
<madduck> what's up?
<\sh> madduck: u wrote something on your wiki about bazaar and upstream source and debianization
<madduck> that's the pkg-zope wiki, but yes.
<\sh> on http://debian.madduck.net/pkg-zope/wiki/Arch/Package/Upstream
<\sh> yes
<madduck> it's all work in progress and there will be changes...
<madduck> and i will try to use bzr soon.
<\sh> what about patching upstream and creating unified diffs...we had a discussion with j^ about his changes without providing unified diffs
<madduck> huh?
<\sh> if you pull a source from somewhere and create a baz repos
<\sh> change something in the code...debianize the source and build the packages...
<\sh> the orig.tar.gz should be always the orig upstream package..so all changes go into diff.gz..which is sometimes not nice
<\sh> madduck: have a look to backlog of #u-motu ,-)
<madduck> yes.
<madduck> i am not logged into u-motu.
* madduck hides
<\sh> hehe
<madduck> i am on too many channels already... wanna send me logs?
<\sh> madduck: use the irclogs of fabbione ,-)
<madduck> thx
<\sh> madduck: thanks to you :) 
<madduck> i'll be with you in #u-motu in a bit, okay?
<\sh> madduck: u can stay forever :) 
<\sh> madduck: actually I don't understand him..or I'm too non-baz alike but I think the first point is more right then the latter
<sivang> anybody to sponser my pkg of gnome-panel ?
<sivang> (lpi patches)
<netdur> hey, I installed breezy, the kernel has some problems, it doesn't load speedtch model, so I can't get online... also usplash thing doesn't work fine (compaq computer) but everything else so far so good! I'm going to install old kernel so I can get online and do more tests
<hub_> speedtouch?
<hub_> you still use USB ADSL modems?
<netdur> yep
<netdur> yes
<hub_> ghawd
<HiddenWolf> crimsun?
<netdur> here in Morocco, there speedtouch and sagem usb adsl modem... nothing more
<crimsun> HiddenWolf: yes? I'm extremely lagged atm, so I may not respond timely
<hub_> speedtouch DO exist as Ethernet. In fact the first one was Ethernet
<hub_> I hate these stupid manufacturers
<hub_> cut down price to sell crap
<HiddenWolf> crimsun: you asked me to check if my audigy sound card worked under colony3. It does, out of box. However, daily does _not_ work.
<HiddenWolf> what do you want me to do?
<BenC> anyone give me a quick tutorial on installing grub by hand after an install (e.g. a debian system with lilo, upgraded to ubuntu)?
<BenC> by hand meaning, I have the package installed, but not grub as the bootloader
<HiddenWolf> BenC: grub-install && update-grub
<HiddenWolf> something along those lines
<crimsun> BenC: to install GRUB in the MBR?
<crimsun> HiddenWolf: sorry, my wifi connection sucks today
<HiddenWolf> Crimsun: I've attached my /proc/asound and the other things you needed to bug http://bugzilla.ubuntu.com/show_bug.cgi?id=14232
<crimsun> HiddenWolf: thanks, I'll take a look in a bit
<crimsun> (barring my wifi collapsing completely, grr)
<HiddenWolf> crimsun: also, my tvtuner sound chip doesn't show up anymore in alsa / mixers. Is this intentional?
<crimsun> HiddenWolf: bt87x?
<HiddenWolf> yup. It seems to be disabled completely.
<crimsun> HiddenWolf: is it loaded? (snd_bt87x)
<HiddenWolf> Doesn't seem to be, no.
<HiddenWolf> the kernel has lost it. :P
<HiddenWolf> crimsun: I'm slow too. battling with the wiring of my speaker set. ;)
<crimsun> snd-bt87x exists in 2.6.12-7-686
<HiddenWolf> Doesn't seem to get loaded here.
<crimsun> but it exists as /lib/modules/$(uname -r)/kernel/sound/pci/snd-bt87x.ko, correct?
<HiddenWolf> it seems to
<HiddenWolf> 2.6.12.11-k7
<crimsun> err
<crimsun> what is that from?
<HiddenWolf> that's the version synaptic gives me.
<crimsun> my linux-image-$(uname -r) is package version 2.6.12-7.11
<HiddenWolf> 2.6.12-6-386
<crimsun> you're an abi version behind
<crimsun> well, for that package
<HiddenWolf> hm
<HiddenWolf> I'll reboot to a newer kernel, brb
<HiddenWolf> crimsun: 2.6.12-7-k7
<crimsun> HiddenWolf: sound quality?
<HiddenWolf> crimsun, one sec, Rhythmbox won't run.
<HiddenWolf> I've got sound. Still only one channel it seems.
<crimsun> are you using an ~/.asoundrc ?
<HiddenWolf> Doesn't seem to be the case.
<crimsun> HiddenWolf: one channel being?
<HiddenWolf> crimsun, sound coming out of my line1, but not line2 or 3 (i'm quite a noob, but seem to need these for 5.1 sounds..) not a big issue one way or another.
<crimsun> HiddenWolf: ok
<HiddenWolf> the snd_bt87x module isn't loaded still. :(
<hunger> Anyone working on updating the linux-restricted-modules so that the new ATI drivers are installed?
<HiddenWolf> hunger, daniels isn't here.
* hunger is too stupid to install those drivers himself.
<hunger> I am feeling really stupid... but I can not get rid of that Mesa GL lib for some reason.
<HiddenWolf> crimsun, need I file a bug about that bt87etc module?
<crimsun> HiddenWolf: did you attach /proc/asound/cards before (colony 3) and after (daily)?
<HiddenWolf> crimsun, what I posted is colony3. Do you need daily too?
<hunger> There is no libGL.so* on my system anymore, but glxinfo still claims there is Mesa inderect rendering:-(
<crimsun> HiddenWolf: I need to be able to compare what happened after, so yes
<HiddenWolf> crimsun, ok, i'll upgrade to daily then. :P
<HiddenWolf> crimsun, suddenly getting weird "could not open resource for writing" errors
<slowtek> part #ubuntu-devel 
<HiddenWolf> and someone should fix that udev annoyance. :P
<HiddenWolf> crimsun, upgrading from colony3 to daily leaves me with sound.
<HiddenWolf> I can still give you the info, if you want.
<crimsun> so what was the issue?
<HiddenWolf> No idea
<HiddenWolf> If I do a clean daily install, no sound. Upgrade from hoary-> daily no sound, but colony3 and upgrading from it work fine.
<crimsun> hoary->colony3?
<HiddenWolf> Haven't tried.
<HiddenWolf> My route today was daily -> hoary -> daily -> colony -> daily
#ubuntu-devel 2005-09-02
<HiddenWolf> lol, ntpdate is broken.
<jtan325> hi. how do you do a cvs diff between the most recent previous version, and current version, without knowing the actual version numbers? is this even possible?
<HiddenWolf> crimsun, anything I can do for you short of reinstalling my system again?
<crimsun> hoary->colony3 would help
<HiddenWolf> I'll consider, but not now. It's past midnight.
* HiddenWolf notes down.
<crimsun> sure
<HiddenWolf> The audigy2 never worked under hoary anyway. There was that bug in 1.06 (I think)
<tseng> it worked for me
<tseng> or is that audigy1
<rob^> hey is dbus working at the moment?
<tseng> i have a few
<HiddenWolf> I had an audigy2 that didn't, and an audigy1 that did work.
<tseng> right now whatever i have in my desktop doesnt work in breezy
<tseng> after a clean reinstall
<tseng> did before
<crimsun> tseng: model # from lspci -v?
<tseng> crimsun: um
<tseng> crimsun: its 2 hours away presently
<crimsun> tseng: k, whenever you get to it
<rob^> I guess not?
<tseng> crimsun: k.
<crimsun> rob^: it seems to work her
<crimsun> e
<HiddenWolf> Breezy seems to be pretty broken :S
<tseng> not really
<rob^> crimsun, ok thanks
<crimsun> (just updated ~20 mins ago)
<tseng> you are too late for "pretty broken"
<HiddenWolf> rightmouse in nautilus and try to create a new file
<tseng> WFM
<HiddenWolf> error: "not on the same filesystem"'
<rob^> yeah mines broken to
<HiddenWolf> ntp has a failure in name resolution during boot, despite it being pingable.
<HiddenWolf> rhythmbox crashes as soon as it's launched. 
<HiddenWolf> evo has 2 different icons under internet and office. 
<HiddenWolf> and I could list a few more. ;)
<tseng> those are all pretty minor, comparatively
<tseng> you missed out on all the ROFFLECOPTER X IS TEH B0RK!!1
<HiddenWolf> tseng, second stage installer hanging without a warning on server install is one.
<tseng> or more recently most of gnome crashing at random
<HiddenWolf> (doesn't prompt for cdrom when it needs it)
<tseng> HiddenWolf: on laptop-mode or so?
<HiddenWolf> *chuckle*
<tseng> seen that
<HiddenWolf> tseng, yup, libdiscover and friends.
<tseng> is there a bug #?
<HiddenWolf> I filed one.
<tseng> cheers.
<tseng> i have 10 more boxes to build, that would get annoying
<HiddenWolf> It doesn't hang on a desktop-install.
<tseng> whats the bug # please
<HiddenWolf> #14225
<tseng> thanks.
<HiddenWolf> 14228 is also fun. :)
<slomo> HiddenWolf: well rhythmbox crashes for me too while starting ;)
<HiddenWolf> and tseng: I had to miss the fun. My harddrive just got back from RMA.
<tseng> hm great
* tseng kicks dbus api in the face
<restrex> are the X working on breezy right now? or.. don't upgrade! ?
<crimsun> X Window System works here
<restrex> ok crimsun thanks :)
<HiddenWolf> crimsun, should I file a bug about that snd_bt87x module not loading for me?
<crimsun> HiddenWolf: hotplug/udev aren't my area, but it may be a good idea
<HiddenWolf> crimsun, who deals with udev?
<crimsun> hmm, maybe pitti?
<HiddenWolf> hm, well. I should be to bed. :)
<HiddenWolf> hope you can figure out that bug crimson. :)
<restrex> heh, I was killed on a chilean irc for being unix user, that's cool
<restrex> 18:33 -!- You were killed by DeserT [~DeserT@netadmin.irc.cl]  [vaya a jugar con virus, no me importa su unix.]  [Path: VTR!IRCops!netadmin.irc.cl!DeserT] 
<rob^> irc.cl?
<restrex> go play with you virus, Unix doesn't matter to me
<HiddenWolf> how rude. :P
<restrex> I just was saying them that leave windows :)
<restrex> rob^: yes, chilean irc
<rob^> whats the server address?
<restrex> irc.cl
<restrex> I think they run unix, 'cause they have opened a ssh port
<rob^> hmm didn't work the first time
<restrex> 445/tcp  filtered microsoft-ds <- but they have these kind of m$ port opened too :/
<restrex> Apache/2.0.46 (Red Hat) Server at www.irc.cl Port 80
<restrex> heh
<rob^> oops I got booted from#chile
<restrex> rob^: heheh what?
<rob^> (y pa esa wea te pgan internet ?)
<rob^> whatever that means
<restrex> rob^ wuaha!
<rob^> care to translate? my spanish isn't so good..
<restrex> that means: ... for that shit you pay internet=
<restrex> that means: ... for that shit you pay internet?
<restrex> xD
<rob^> I thought it was something like that
<restrex> rob^: what did you say there?
<mpt> Are Chileans violently pro-Windows or something?
<rob^> something like that
<ryanthiessen> mpt: you planning to update your great ubuntu UI list for breezy?
<rob^> oops now they banned me..
<jdub> oh man
<jdub> dude turns up on ubuntu-devel knowing how to sort out the ppc64 iso foo
<jdub> that's brilliant
<tseng> yeah i liked that
<tseng> nice timing though
<mjg59> Cocking Dell.
<jdub> good morning cocking lovers!
<tseng> i was eating, even
<jdub> "The first Live-CD based on Debian GNU/kFreeBSD has appeared. Its name is Ging (for Ging Is Not Ging) and it includes a GNOME 2.10 desktop, Abiword, and a complete toolchain with gcc 4.0."
<jdub> cool
<Lathiat> jdub: yeh
<Lathiat>  It stands for "Ging Is Not Ging". It is, to my knowledge, the
<Lathiat>                  first recursive acronym with an implicit contradiction.
<mjg59> You'd think something as simple as "Not breaking when someone presses the lid switch" would be within Dell's capatbilities
<mjg59> But no!
<tseng> mjg59: works on my 600m
<tseng> mjg59: what kind of cockery are you speaking of?
* j^ looks out for the first palyndromic acronym
* luis_ presses mjg59's lid switch
<mjg59> Instead it generates two video eventsplus the lid open event, and DOESN'T SWITCH THE BACKLIGHT ON
<jdub> palindromic recursive acronym!
<mpt> ryanthiessen: yes.
<tseng> "hannah is a palindrom"
<mjg59> Thanks, Dell. Thdell.
<Lathiat> mjg59: what hardawre is this?
<mjg59> D610, but one with Intel graphics
<jdub> infinity: still there?
<jdub> In the stock Debian configuration,
<jdub> xrdb is called by gdm as part of the default session (three times), and
<jdub> then again by gnome-settings-daemon.
<jdub> ha ha
<tseng> jdub: its good to be sure
<luis_> cpp, baaaaabye
* jdub checks for -nocpp, given that we don't need it
<jdub> nup
<Mitario> is elmo the only one who can give MOTUs upload privileges?
<jdub> Mitario: yep, believe so
<Mitario> hmm, okay
<jdub> he controls the keyring
<Mitario> ok
<mjg59> And the vertical
<mjg59> And the horizontal
<jdub> ha ha
<jdub> ha ha ha
* jdub smiles
<jdub> mjg59: are you quoting uhf?
<tgall> jdub, hey ya
<jdub> whoa, dude
<jdub> howdy :-)
<jdub> tgall: your timing is impeccable
<tgall> jdub, perfect timing!
<jdub> i got the 710 a few days back
<jdub> it's sitting on my coffee table
<tgall> jdub, cool ...  how did you score one of those ?
<jdub> it needs some serious ubuntu anti-depressants
<tgall> heh ..  well no worries .. I know how to get it a rollin
<jdub> local solutions company got ibm to give them one for us
<tseng> tgall: hi
<tgall> jdub, great
<tgall> tseng, greetings
<jdub> ah, i see from tgall's channels list that you two have background ;)
<jdub> so is it in the cd build, or yaboot configuration?
<tseng> `fg`
<tgall> jdub, both!
<jdub> d'oh! :)
<tgall> jdub, and the console gets a little fun to setup
<tgall> depending if you're running in a partition or not
<jdub> oh right
<tgall> so first things first!
<jdub> i don't have an HMC to test
<jdub> can i set up partitions in the hmc web thingy?
<tgall> well no biggie ..  I've got access to hardware a plenty
<tgall> umm yes you should be able to ... tho I haven't don't it personally but I'm fairly certain you can
<tgall> s/don't/done/
<jdub> (not that firefox can talk to it - will have to plug in my windows box)
<tgall> hmm firefox should work
<tseng> ogra!
<jdub> it can't negotiate a cipher to use
<tgall> jdub, anyway .. so to get a IBM chrp / hpa box to boot off of cd we need to put a little magic on the cd
<tgall> in gentoo land we build isos so they can boot on pmac and ibm .. no reason why ubuntu can't either!
<jdub> bonus
<tgall> yeah ..  that's kinda my background .. I run the ppc64 port in gentoo land .. but don't hold it against me!  
<tseng> you are safe as long as you convert immediately
<jdub> haha
<jdub> tseng: you survived :)
<tseng> and sacrifice a virgin at the shrine of dpkg
<tgall> tseng, I'm sure there are DNA fixing technologies to allow such things
<jdub> tgall: actually, we found a method that doesn't involve in-place genetic modification
<tgall> tseng, well my 4 way 604e box still runs debian .. I never converted it to gentoo
<tseng> :)
<tgall> jdub, does it involve beer ?
<jdub> tgall: we're building a screensaver that downloads build logs and displays them, while pegging the CPU
<jdub> ;-)
<tgall> heh
<tgall> jdub, ok so boot on chrp
<tgall> (and this holds for both 32 and 64 bit ibm systems)
<jdub> handy
<tgall> this boxes all look for a file named ppc/bootinfo.txt
<tseng> jdub: there is an apt-emerge or something that does exactly that
<tgall> so assuming no one ever blasts their boot-device in open firmware it will look for that path on the cdrom
<tgall> bootinfo.txt is a bootscript of sorts and if you like i can just dcc you one
<tgall> waaaaay to much to dump here
<jdub> i'll check the one on the opensuse cd
<tgall> sure that works too
<tgall> o wait .. do they have ppc support in opensuse yet ?
<jdub> yeah
<tgall> I didn't think they had started that effort yet
<jdub> well, they've always had it internally
<jdub> they've just started pushing it public
<tgall> kudos to olaf and matze!
<tgall> yes so grab that
<tgall> inside the bootinfo.txt you'll see the following line
<tgall> <boot-script>boot &device;:1,\ppc\chrp\yaboot</boot-script>
<tgall> you can guess what that does :-)
<jdub> haha, just opened one here
<tgall> now .. one difference you might or might not have here is do you run addnote over your yaboot binary ?
<jdub> xml boot scripts! brilliant!
<jdub> hrm, dunno - addnote?
<tgall> you need that on ppc64 boxen
<jdub> ah, thus suse
<jdub> ah, thus suse's yaboot.ibm
<tseng> jdub: its extensible to a web service
<tgall> basically throws a small header on the front
<tgall> so I suspect you'll have two yaboots ..
<tgall> but they can both read the same /etc/yaboot.conf file
<jdub> yep
<jdub> yaboot and yaboot.ibm
<tgall> ok .. so the next bit of trivia is the various consoles
<jdub> oh, and it has image[64bit]  yada in it
<tgall> so like on a js20 powerblade, they use console=hvc0
<tgall> the as far as pseries goes,  you've got ttyS0  or hvc0  or hvsi0!
<tgall> that also covers new iseries as well
<jdub> hrm
<tgall> jdub, o and do you need the xserv magic as well ?
<jdub> so suse don't seem to pass console params in yaboot.cnf
<tgall> they might have something built into their kernel to figure it out
<tgall> kernel.org kernels don't have that
<tgall> :-/
<jdub> oh
<jdub> so, X magic?
* jdub couldn't get the X in his hoary chroot to run
<jdub> couldn't find the device, even though it was quite happy with the mga driver
<tgall> console=ttyS0,57600n1  <-- that's for xServ
<tgall> jdub, ah ..  so you have the matrox card at least
<jdub> yeah
<tgall> jdub, on ppc64 hardware there aren't much for graphics solutions and with no agp ... it's slim pickins
<jdub> oh, maybe i should try the breezy xorg
<tgall> xorg and mga does work tho
<tgall> least it does as a 64 bit binary .. but it should work 32 bit
<jdub> so the detection works fine
<tgall> you MIGHT need one kernel param tho depending on what level of kernel you have
<jdub> but trying to run it, the mga driver can't find a device
<jdub> oh
<jdub> heh
<tgall> yeah for a long long time the memory detection on the cards has been mega screwed up
<tgall> kernel just needs to be slapped
<tgall> I think ianr submitted the correct kernel code upstream .. if he didn't tho, I have the patch for that
<jdub> ok, so have to find suse patches for console detection and X memory foo :)
<tgall> umm let me fire up my power3 box .. half a mo
<tgall_foo> guess i'll chat from here for a sec
<tgall_foo> jdub, so any idea which matrox card you have?
<jdub> g400
<tseng> arent you fancy
<tgall_foo> jdub, I have a GXT130P   so yeah you're a 135P then
<tgall_foo> you might be ok .. 
<tgall_foo> for the 130 series you definitely need video=matroxfb:1280x1024@60,memtype:3
<tgall_foo> basically sets up the cards other 6 meg
<jdub> aha
<tgall_foo> if you don't do that, then xorg tries to run thinking it has 8 megs of memory in only 2
<jdub> i will try it in a minute (710 takes a while to boot...)
<tgall_foo> and you get a big screen of angry fruit salad
* tgall_foo heads back upstairs
<tgall> tseng, jdub : do either of you have pointers to the tools and such that you use to build isos ?  ...  (tseng : least assuming there's something similiar to catalyst)
<jdub> debian-cd
<jdub> but i think ours is pretty thoroughly hacked up
<tgall> ah ..
<tseng> tgall: ive not built an install cd
<tseng> tgall: we have some pretty decent community docs on livecd building
<luis_> he means 'most excellent'
<luis_> :)
<tgall> cool  just what I need .. as you might imagine I'm a bit interested walking down that road 
<tseng> it doesnt smoke crack like catalyst
<tseng> but its more manual
<tseng> the gist is you get an old iso, unpack it somewhere, edit, repackage
<tgall> heh ...  yeah catalyst requires the stroking of other people's ego so they will share the magic ...    
<tseng> meh
<tgall> aweful way to run a project
<tseng> i wrote a wrapper script
<luis_> we're all about the wiki love here
<tseng> to the supposed end all wrapper
<jdub> tseng: hrm, that's not how the cd builds themselves work
* tgall loves wiki love
<tseng> jdub: LiveCDCustomizationHowtoForLife(LessThenThreeLuisVilla4)
<jdub> but that's post-build
<tseng> indeed.
<tseng> is the real process documented outside the d-i cabal?
* tgall just hopes it documented
<jdub> debian-cd is around somewhere
<jdub> unfortunately kamion isn't here
<tgall> hmm so any suggestions as far jury rigging the installer from a chroot since obvious the install cd isn't feeling well yet ?
<jdub> he would be the most useful person to speak to about all of this
<Mitario> byebye everyone nite
<jdub> night Mitario 
<Mitario> that evil BBB slipped my sight!
* Mitario hopes elmo is awake tomorrow :)
<tgall> there ... on the motu candidate list now ....  
<jdub> tgall: rock!
<jdub> tgall: awesomely fast i/o subsystem on these things
<jsgotangco> what a sucky weekend
<tgall> jdub, yes very!  
<rob^> has anyone else had problems with the nvidia drivers in the breezy repos?
* jdub installs the breezy powerpc64 kernel
<jdub> rob^: such as?
<rob^> I have them installed and lsmod shows they are loaded
<rob^> but 3d is painfully slow still
<jdub> you're definitely using the nvidia driver?
<rob^> yes
<rob^> its in xorg.conf, the logo shows up on startup
<jdub> hmm
<jdub> daniels will know
<crimsun> what does glxinfo|grep ^direct say?
<rob^> direct rendering: Yes
<crimsun> cat /proc/driver/nvidia/agp/status  -> #flood
<rob^> done
<rob^> don't you have to remove Load "GLcore" from xorg.conf?
<crimsun> that should have been done by nvidia-glx-config
<rob^> hmm seems it wasnt
<rob^> brb I'll remove it and see what happens
<rob^> yep, thats all it was
<crimsun> k, b.u.c. time
<rob^> I removed Load "dri" and Load "GLcore"
<rob^> k thanks
* tgall jdub is successful
<tgall> s/jdub/hopes jdub
<jdub> oh sweet baby jebus
<jdub> how do i remove langpacks without regenerating locales?
* jdub is going to die
<tgall> well night ...  
<jdub> gute nacht!
<LaserLine> Is there a tool for checking BAD SECTORS on the hard drive ?
<jdub> LaserLine: badblocks
<pcmanlin> who can tell me whether unionfs will be used in breezy-livecd?
<pcmanlin> just be used in breezy-livecd, about install cd?
<fabbione> pcmanlin: no
<fabbione> unionfs is terribly unstable
<Burgundavia> ogra, you seen this? It is a Fedora SoC project: http://sourceforge.net/projects/pootypedia/
<Mithrandir> elmo: could you please sync mercurial?
<sivang> morning all
<HiddenWolf> morning
<frans-th> afternoon here :P
<Treenaks> hey sivang 
<sivang> hey Treenaks , hows the laptop testing going?
<Treenaks> sivang: very well
<sivang> main uploading people - anybody for reviwing my pkg and upload it?
<Treenaks> I love the 1920x1200 res :)
<sivang> Treenaks: you managed to get over that annoying kbd layout ? :)
<Treenaks> hard to live without it on my old laptop
<Treenaks> yeah.. still getting used to it, but I'll manage ;)
<frans-th> i use my NEC m540, wide screen, ubuntu know it well :) without any driver, except the sllink modem, 1280x800 :)
<hunger> My laptop (IBM T43p) seems somewhat more stable now... I switched to a homemade 2.6.13-rc7 kernel and the new ATI proprietary drivers.
<hunger> The latter seem to make a difference... but the first is said to have some SATA fixes which might improve stability for me as well.
<hunger> The box runs for about 6h straight now... with the ubuntu kernel it crashes after about 3 if I am lucky. Sometimes it crashes before it booted up properly.
<hunger> Now: Any ideas how to debug the "udev does not create /dev/input/mice" problem?
<Treenaks> hunger: change loglevel to "info" in /etc/udev/udev.conf
<mdke> hunger, i have a T43, haven't had any problems on standard breezy, perhaps it is a different model?
<Treenaks> the "usb mouse doesn't do scroll events" bug is known?
<hunger> mdke: Does it have PCIe and SATA?
<mdke> yes i think so
<mdke> i had an email from someone who had random crashes, he blamed it on the wifi chip iirc
<hunger> mdke: Mine is unusable in standard breezy.
<hunger> mdke: It is not the WLAN chip: I only installed the driver for that yesterday.
<mdke> hunger, surely the driver is in the breezy kernel
<hunger> mdke: My box crashes on graphics ops and whenever it has lots of HDD or ethernet activity.
<mdke> hunger, anyhow check out https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadT43 and see if you can find anything useful
<hunger> mdke: Nope... in linux-restricted-modules and that is broken.
<mdke> the guy who reported the crashes is the second one in the list on that wiki page
<hunger> mdke: Or maybe it was just my config of it that was... dunno. It did give warnings on modprobe though.
<mdke> anyway this is kinda off topic for this channel
<mdke> go to #ubuntu-laptop
<hunger> mdke: I just wanted to report my findings to the kernel people.
<mdke> hunger, they might not be awake, better use bugzilla or #ubuntu-kernel
<hunger> mdke: ubuntu has way too many channels here!
<robotgeek> hi, https://launchpad.net/malone/bugs/1138 is marked as fixed, but i still get the same error. i filed a new bug at https://launchpad.net/malone/bugs/1926 referencing the old one.
<siretart> robotgeek: this seems a universe package, please join #ubuntu-motu for that
<robotgeek> siretart: okay...sorry :) 
<sivang> jdub: ping , dude you there?
<tseng> hi sivang 
<jdub> sivang: yeah
<jdub> sivang: i have ubuntu booting on this sucker now
<jdub> sivang: got some help from tgall with the cd booting foo
<jdub> will be very helpful when kamion's back
<Treenaks> when will he be back btw?
<jdub> dunno
<sivang> jdub: wow cool
<mjg59> Should be this week
<mirak> hi
<sivang> jdub: I was about to try that now , then guess there's no need :) What did you have to do in order to make it boot?
<OculusAquilae> hi mirak
<mirak> is breezy a bit more stable, kind of like debian unstable or is it still as unstable as breezy just after hoary was final ?
<jdub> sivang: i unpacked the livecd onto a different disk, currently using suse's yaboot to boot it
<OculusAquilae> my breezy (kubuntu) is running very good mirak
<jdub> mirak: breezy has almost reach preview release
<OculusAquilae> s/is running/runs
<jdub> mirak: it is not like debian sid - we stabilise our development branch for release
<mirak> ok, in fact I was using hoary already before it was final, it was "ok", though when hoary was final, I tried breezy but it was really awfull lol
<jdub> we always make the biggest changes at the beginning of the development process, so that makes sense
<sivang> jdub: I see, nice, then I am still going to try find the right flags to be used in our image build scripts to make a bootable image, since you just workaround the problem for the meanwhile :)
<jdub> it is almost always dogfoodable though
<OculusAquilae> mirak: it was a new version then, with many changes at the beginning
<mirak> ok, so I will give it a shot
<jdub> sivang: http://www.google.com.au/url?sa=U&start=2&q=http://penguinppc.org/ppc64/power-bootable-iso/&e=42
<mirak> if it breaks everything it will be a good occasion to switch to ubuntu amd 64
<OculusAquilae> :-)
<mirak> I run ubuntu on two macs
<OculusAquilae> i don't like ubuntu on amd64
<mirak> G3 and G4
<OculusAquilae> ah
<sivang> jdub: anyway, can you review and sponser my new pkg of gnome-panel ? (launchpad integration included)
<mirak> OculusAquilae: what's wrong ?
<jdub> sivang: i'll leave that for seb
<sivang> ah ok, 
<sivang> np
<OculusAquilae> mirak: with media codecs etc
<mirak> OculusAquilae: yes that's what I have heard
<mirak> I should have created a second partition
<OculusAquilae> i think its possible to change it
<mirak> I mean a second system partition
<mirak> OculusAquilae: resize ?
<Mitario> elmo, ping
<OculusAquilae> mirak: no, the bad media-support in amd64
<OculusAquilae> but i don't know how it changed in breezy
<sivang> jdub: thx for the howto. /me reading it now
<mirak> OculusAquilae: I have read that gentoo have some workarounds for this
<mirak> mmm
<OculusAquilae> you could simply compile the media apps in 32-bit
<sivang> jdub: so how's breezy working on the hardware? have you found any userland issues yet?
<jdub> sivang: sorting through an X issue with daniels
<jdub> haven't fully upgraded to breezy yet
<jdub> but otherwise running ok
<Snark> jdub: fixed font issues?
<jdub> no
<jdub> pci domain on powerpc issues
<Snark> oh... powerpc...
<HiddenWolf> *grumble* nvidia driver is hosed for me.
<shackan> after last upgrade nautilus icons are gone (every file has the default 'file' icon) and it crashes quite often
<sivang> jdub: you're booting the live fs on another disk, from a the opensuse yaboot prompt?
<jdub> sivang: i added a section to it in suse's lilo.conf (which its lilo command turns into yaboot.conf)
<sivang> jdub: nice, so the fs system you're booting is already on one of the SCSI hard drives?
<jdub> yeah
<jdub> i just blatted the livecd fs on it
<sivang> jdub: then it seems that what we now need is only (1) a bootable install cd that's able to boot, and (2) through testing to get certified, seems like we can get a certified version in no time :)
<mirak> is ther gnome 2.12 or approaching in breezy ?
<jdub> fingers crossed
<jdub> mirak: our devel branches always icnlude the gnome devel branch
<mirak> nice
<mirak> and e17 ?
<mirak> I m kidding
<jdub> don't think anyone's got around to it yet
<jdub> ideally it would be in universe
<luis_> someone was talking about doing it.
<mirak> I want expos in gnome
<mirak> seems apple have patented it
<JanC> mirak: there is expocity ?  :)
<mirak> it sucks
<mirak> come on
<mirak> have you ever tried expos  ? ;)
<jdub> expocity is limited by the functionality available to us
<jdub> once we've got COMPOSITE running everywhere, expocity will fall into place (and fairly likely into metacity itself)
<sivang> jdub: that's what cairo will enable us, right? (and the rationale behind the transition)
<jdub> not really
<jdub> COMPOSITE and possibly Xgl
<mjg59> It's sort of orthogonal
<jdub> cairo could be used for transformations
<jdub> but it's not enormously related
<mjg59> Cairo buys us the primitives to use Composite at the toolkit level
<mjg59> Something like expose could be done as well at the raw composite level
<mjg59> Remember that not all your windows will necessarily be built with cairo-using toolkits
<luis_> blasphemer
<luis_> ;)
<sivang> mjg59: ah I see
* mjg59 starts hacking teh dell again
* sivang reads through CONF.sh in debian-cd , now where are the mkisofs flags ....?
<sivang> jdub: do you know if debian-cd build scripts putt stuff from the net, or require everything to be on disk?
<jdub> not sure
<siretart> err, is ftp://upload.ubuntu.com really down?
<HiddenWolf> I have a case of evince showing half a pdf. i guess that should go upstream?
<luis_> probably to poppler in fd.o
<HiddenWolf> luis_, where can I find this?
<luis_> bugzilla.freedesktop.org
* HiddenWolf doesn't have an account there
<luis_> getting an account is not hard :)
<HiddenWolf> no, but it's annoying.
<tgall> morning
<bur[n] er> i'm not sure if this is proper to talk about here, but seems like rhythmbox doesn't work on my desktop, but does on my laptop... both the latest breezy  I've dumped ~/.gnome2/rhythmbox to try to remedy, but I still get errors.  I've tried to run as root to no avail as well.  Anyone know something about this?  if not, i'll bug report the lil info i have
<bur[n] er> also... on running, I get "the program has quit unexpectedly"  restart, close, inform developers... but I get no terminal output whatsoever, so I'm not sure hte problem
<sivang> hey pitti , 'sup ?
<pitti> Hi sivang 
<Laur>  /msg nickserv help
<sivang> pitti: do you have a couple of minutes?
<pitti> sivang: just returned from a marriage party, quick mail check and then off to swimming :-)
<pitti> sivang: well, yes
<sivang> pitti: ah cool, then happy pool time :)
<sivang> pitti: never mind, I have something I wanted someone to review it, but it's probably better left for seb to do
<pitti> sjoerd: thanks for your hal work
<siretart> does anyone know whats going on with ftp://upload.ubuntu.com?
<bur[n] er> nope
<sivang> morning tgall :)
<HiddenWolf> crimsun, around?
<Coyctecm> toimaa =)
<Coyctecm> Sain takas on alkup. kursoriteeman. Se musta perinteinen, musta kaikista paras. =)
<tepsipakki> vr kanava?
<tepsipakki> ;)
<Coyctecm> sorry...wrong channel...
<opi> I hope you don't bad mouth us ;->
<Coyctecm> yes I was writing in #ubuntu.fi
<Coyctecm> :D
<HiddenWolf> Finnish?
<Coyctecm> yes
<tepsipakki> har har
<Coyctecm> :D
<mjg59> Argh GPL violating modem drivers
<mjr> fun fun fun
<j^> oh why is there not sane dvd/cd burn program for gnome in ubuntu
<Lathiat> j^: define sane
<Lathiat> j^: nautilus works good for me..
<j^> sane: burn on the fly, set title of disk
<sivang> ogra_ltsp: ping
<ogra_ltsp> sivang, pong ?
<j^> have 3 diffrent image layouts and burn them in random order several times, without creating iso images
<Lathiat> yuo can set the title
<Lathiat> as for burning on the fly
<Lathiat> it doesnt do that
<Lathiat> thats a nice feature of growisofs
<j^> burn on the fly is essential
<j^> i do not have an extra 10GB on my disk
<Lathiat> quite
<sivang> ogra_ltsp: do you know if debian-cd expects the whole archive to be on disk?
<sivang> ogra_ltsp: (that is, if you are using it to create edubutnu)
<ogra_ltsp> sivang, nope, i use the ubuntu infrastructure, i dont even know he backend
<sivang> ogra_ltsp: ah, whre is the ubuntu infrastrucute / where can I find the frontned?
<sivang> ogra_ltsp: I want to try pass different mkisofs options to the ubuntu image creation process for ppc64
<ogra_ltsp> i have a seedlist that gets automatically synced and the edubuntu metapackages, thats the only influence i can take without Kamion mdz can trigger the builds additionally
<sivang> ogra_ltsp: ah I see
<sivang> mdz: ping, you here?
<ogra_ltsp> sivang, but i guess there are some howtos out there for debian-cd
<sivang> ogra_ltsp: yes , there are, the problem is they are bit vaugh regarding the archive itself, I'll try rereading the README
<sivang> well, looks like I need to mirror the whole archive locally
<j^> Lathiat and it would be nice to be able to configure the default diskname
<tgall> greets
<mdz> sivang: yes?
<xhaker> elmo, scite?
<crimsun> HiddenWolf: yes?
<HiddenWolf> crimsun, never mind. Thought my soundcard screwed up again, but it was human error.
<crimsun> k
#ubuntu-devel 2005-09-03
<Keybuk>          _    _ ___ ___ _
<Keybuk>  ___ ___| |__/ |_  | _ ) |
<Keybuk> (_-</ -_) '_ \ |/ // _ \_|
<Keybuk> /__/\___|_.__/_/___\___(_)
<Keybuk> METACITY KEEPS CRASHING
<Lathiat> http://bugzilla.ubuntu.com/show_bug.cgi?id=14145
<Lathiat> also
<Lathiat> i doubt ghe has figlet on notify :)
<slomo> Keybuk: same here... but nothing to get crazy about :P
<Keybuk> no, but it makes me feel better
<crispin> yeah, I see that too, I don't understand why a rebuild fixes (mostly?) though
<lllmanulll> Keybuk, Hey, seb128 is on holiday for a few days :)
<Keybuk> I know
<gratuit> I'm using breezy, and I'm noticing sevral bugs, how should I go about reporting them?
<lllmanulll> Keybuk, should come back some time wednesday
<lllmanulll> Keybuk, oh, all right :)
<Keybuk> like I said, it just makes me feel better <g>
<Keybuk> I'm on holiday too
<lllmanulll> Keybuk, But never far away from keyboard :)
<lllmanulll> gratuit, use https://bugzilla.ubuntu.com/  but make sure that what you are going to report aren't know bugs
<JanC> gratuit: bugzilla for things in main/restricted, malon for things in universe/multiverse
<JanC> s/malon/malone/
<gratuit> lllmanulll: yeah I just found it, I'm looking at the bug I was going to report now
<lllmanulll> gratuit, Good, if you have anything else to add, you can post a comment
<lllmanulll> gratuit, Otherwise, just be patient and it will hopefully get fixed
<JanC> hm, how does a metacity crash look like ?  :)
<HiddenWolf> if seb128 is on a holiday for a few days, can someone else check out why the hell rhythmbox won't start?
<HiddenWolf> it crashes without error almost immediatly.
<gratuit> JanC: what is malone?
<JanC> https://launchpad.net/malone
<HiddenWolf> gratuit, bugzilla but better. under development and used for universe/multiverse bugs already.
<Keybuk> JanC: all your windows lose decoration, gain them again, and jump down and across slightly
<mpt_> I'm installing Colony 3 right now and noticing lots of places where the text could be better. Is this worth bothering with at this point of the development, or is Breezy+1 much more likely to have a graphical installer?
<jdub> mpt_: breezy+1 may have the livecd based installer
<jdub> mpt_: worth noting down improvements though, but not sure if they'll get in (translations to worry about)
<mpt_> yeah
<mpt_> ah, Breezy doesn't restart this laptop either
<mjg59> mpt_: It fails in both Breezy and Hoary?
<mpt_> yes
<mpt_> but then, this is only second-stage installation, is that too early to tell?
<mjg59> mpt_: What hardware is it?
<mpt_> mjg59: Toshiba Satellite, circa 2001 vintage
<mjg59> Ah, right
<mpt_> I'm sorry I never reported a bug earlier, no excuse really
<mpt_> The most aggravating problem, though, is that the installer asked for my WEP key when this wireless network uses WPA
<mjg59> We have no sensible WPA support yet
<mjg59> No...
<mjg59> Argh. Wrong window.
* mpt_ wonders what his roommates are using, then :-)
<mjg59> You can set it up manually in an awkward way
<mjg59> But driver support is poor and the userspace tools are miserable
<mpt_> UbzSpec!
<mpt_> thanks for the info mjg59
<jdub> mpt: NM may get wpa support in breezy+1 timeframe.
<jordi> jdub: J! D! U! B!
<jordi> any news? :)
<jdub> i kinda wanted to catch up with seb, carlos and koke
<jordi> how's NM for Debian/Ubuntu coming along? Is it usable?
<jdub> j^'s packages are pretty rad
<jdub> hopefully we'll get them into universe for breezy
<Lathiat> if im using network manager
<Lathiat> should i take the hotplug mapping out of interface
<jdub> dunno
<Maynoth> hey can you guys help a noob
<Maynoth> why is there no control panel applet to install/unistall programs?
<Maynoth> why is there no control panel applet to install new drivers
* xhaker is away (Away, bnc logging)
<HrdwrBoB> Maynoth: because any drivers that are easy to install are already installed
<HrdwrBoB> and that's not the way it works
<HrdwrBoB> to install/uninstall programs/etc use the synaptic package manager
<HrdwrBoB> under system->administration
<Maynoth> do you guys think it will ever have a nice gui applet to install/unistall drivers and software
<Maynoth> I really think more people would switch if that was an option
<HrdwrBoB> Maynoth: there is a nice app installer
<HrdwrBoB> and it's the default in breezy
<HrdwrBoB> drivers are an entirely different kettle of fish
<Maynoth> so the next version is going to have a better installer?
<Maynoth> will it have options to unistall programs too?
<HrdwrBoB> gnome-app-install
<HrdwrBoB> it's in hoary too
<HrdwrBoB> check it out
<HrdwrBoB> anyway, this is the wrong channel for that, it's still #ubuntu stuff
<Maynoth> they told me to get out
<Maynoth> :(
<Maynoth> what new features is breezy going to have?
<HrdwrBoB> Maynoth: have a look at the wiki, again, this is not talk for here
<mjg59> Ok, I've found the usplash problem
<jdub> there was a problem?
* sladen raises eyebrow
<mjg59> jdub: It breaks hibernate at the moment
<mjg59> For a really subtle reason
<mjg59> Of course, my current fix is a kernel patch...
<jdub> d'oh
<luis_> mjg59: man without fear.
<mjg59> I remove one line
<mjg59> I merely charge you $500 for knowing which one line to remove
<luis_> man.
<mjg59> Why must ftp.ubuntu.com be down? Why must Unix be so mean?
<luis_> consulting truly is the way to go.
<mjg59> luis_: Once I'm through this PhD, it's sorely tempting
<mpt> So, that's what Breezy looks like
<mpt> ... like Hoary
<mjg59> mpt: Pretty much
<mpt> What happened to those awesome new icons?
<mjg59> Artwork isn't finished yet
* mjg59 says, waiting for some Usplash pictographic love
* mpt restarts to see the usplash
<mpt> So gksudo alerts dim the rest of the screen now
<tseng> its a non-event
<mpt> that's a bit ... strange
<mjg59> mpt: Nobody has ever offered me money to draw stuff.
<mjg59> Usplash's current state represents that quite well :)
<mpt> hey, radio buttons are black now
<mpt> that's a change
<daniels> mpt: if you accept that gksudo's going to grab your keyboard, it seems a little unintuitive to show the rest of the screen as if you can nusefully interact with it
<mjg59> Oh, hmm.
* mjg59 watches his machine fall over on hibernate
<mjg59> Of course, this is running ndiswrapper and similar crack
<mpt> daniels: If anything, I'd expect that to make the controls in every other window look insensitive, or at least (as an approximation) reduce their contrast
<mpt> rather than making them darker
<daniels> mpt: so ... every window still looks like it's activatable, but even if you do activate them, everything will be insensitive
<mpt> Including the title bars, daniels :-)
<daniels> mpt: gksudo is, right now, display-modal
<mpt> Other major operating systems have display-modal dialogs, and (with the exception of the Shut Down dialog in Windows) they don't make the screen darker
<mjg59> mpt: It's consistent with, say, the typing break lock
<sladen> mjg59: are you using the Libretto at the moment with ndiswrapper?
<mjg59> sladen: Nope
<mjg59> sladen: I'm testing on an HP that has a keyboard big enough for me to type on
<mpt> ok, enough whining on my part, perhaps I can do something useful
<daniels> must ... resist ... joke ...
<mpt> mjg59: Is there a convenient wiki page or mailing list post describing the exact requirements for the usplash pictographic love?
<mjg59> mpt: jdub has a spec that he's supposed to have passed on
<jdub> mjg59: the bug described it
<jdub> mjg59: i just told cliff what to do
<mjg59> jdub: Rock
<mjg59> Incidentally, Breezy seems *much* better at suspend to disk
<bob2> and faster?
<mpt> jdub: Does that mean it's being done already?
<jdub> yeah
<mjg59> Faster, yup
<jdub> mjg59: actually, ready for an image to play with? :)
<jdub> mjg59: i just tested that image, it looks horrendous
<jdub> mjg59: i think there's something funny going on with the xpm conversion
<tgall> hey ya jdub
<daniels> holy shit suse are nuts
<daniels> they appear to have backported exa and pretty much the entirety of all the drivers
<bob2> haha
<tgall> heh
<daniels> why they don't package 6.8.99.x rather than patch 6.8.2 to buggery is beyond me
<lu|away> because they have a version freeze
<daniels> jdub: please grab http://people.ubuntu.com/~daniels/pc_pcibus.diff and apply, see if that helps
<lu|away> they have this bizarre notion of version freeze
<bob2> haha
<daniels> that's complete bullshit
<daniels> they've backported r300 DRI
<lu|away> where they can backport basically the whole damn thing of the next version, as long as the original tarball stays the same
<daniels> and i915 DRI
<bob2> "backport whatever, just don't BUMP THE VERSION"
<lu|away> bob2: yup
<daniels> if you're not going to respect version freeze, then don't respect version freeze
<daniels> hmm
<daniels> however, they still only have 225,000 lines of patches
<daniels> we were up to about 280 at one point
<tgall> well some people have weird ideas of "fun"
* lu|away blinks
<lu|away> 280_K_ lines of patches?
<daniels> hold on
<daniels> i swear the original tarball must have changed
<daniels> they're patching exaPriv.h, which was most certainly *not* in 6.8.2
<daniels> lu|away: yeah
* lu|away puts X on my list of 'seriously broken projects'
<daniels> oh, cute
<daniels> they have an arseton of new files
<daniels> in .tar.bz2
<daniels> ADDING ORIGINAL TARBALLS == NOT FROZEN
<bob2> maybe they have their own rpm dbs
<bob2> that'd rock
<caldwell_> any idea why i get this error when i build Xorg?  make[3] : *** No rule to make target `../../extras/rman/rman.c', needed by `rman.c'.  Stop.
<caldwell_> or how to fix it?
<daniels> caldwell_: ... try #xorg, maybe?
<wasabi_> Wow. This SATA DVD-drive I have simply doesn't appear in Ubuntu.
<Lathiat> yeh sata cdroms are rather uneventful
<wasabi_> Not sure how to make it show up.
<fabbione> morning
<pitti> Good morning
<daniels> morning pitti
<fabbione> hey pitti
<pitti> Hi Daniel, hi Fabio
<pitti> hehe, SuSE wants to use pmount :-)
<Lathiat> but submount is so cool
<pitti> I used it the other day, right, it's nice
<pitti> but needs to be configured for devices
<pitti> so I guess SuSE is doing automatic conf file rewriting
<Lathiat> eh i was joking anyway
<Lathiat> pitti: heh
<Lathiat> pitti: using their standard configuration & management system
<pitti> but they autotool'ized my pmount and want me to adopt it *sigh*
<Lathiat> no doubt :)
* pitti hates autotools
<jdub> pitti: hrm, so, can you check out avahi sometime when you have a moment?
<jdub> pitti: for security and sanity - let Lathiat know what you think? :)
<pitti> jdub: avahi?
<Lathiat> pitti: http://www.freedesktop.org/Software/Avahi
<pitti> oh, howl take 2?
<rob^> elmo, ping
<Lathiat> pitti: you could say that
<Lathiat> pitti: nothing to do with howl other than sharing the same spec, however
<pitti> jdub, Lathiat: but none of this is breezy stuff, I presume?
<Lathiat> not for main
<pitti> jdub: are you the right person for #13328?
<rob^> is dbus working in breezy today?
<Burgundavia> jdub, what is the saga with add/remove programs. Is it now not going to be a the root of Applciations?
<rob^> I mentioned it in the FAQ Guide for Breezy, but due to the fact it can't install a lot of things I used Synaptic when writing it
<sivang> morning all
<rob^> In Breezy I went to System -> Administration -> Networking, changed my hostname, rebooted, my window borders are all screwed up (they are all green). b.u.c?
<siretart> morning
<siretart> bob2: around?
<siretart> bob2: can you at least tell me the md5sum of the orig.tar.gz you will be using for lyx? I'd upload then a -0ubuntu1 version, which can be synced over by your package...
<rob^> grr
<dholbach> good morning
<pitti> Hi dholbach 
<dholbach> hey pitti :)
<pitti> argh, can someone please stop these /msg spam?
<Treenaks> pitti: /mode +E
<Treenaks> uh
<Treenaks>  /umode +E
<pitti> that means?
* pitti googles
<pitti> thanks
<dholbach> pitti: according to GermanTeam you seem to have new ubuntu fans in dresden :)
<Treenaks> pitti: usermode +E means only identified users can msg or something
<pitti> dholbach: some folks from LinuxInfoTag already asked me for coming
<dholbach> oh cool
<Treenaks> pitti: read lilo's cruft in the message window
<pitti> dholbach: unfortunately I will be at UBZ at that time
<pitti> Thanks Treenaks 
<dholbach> pitti: next time then :)
<dhonn> 2.6.13 is out.  will ubuntu 5.10 ship it?
<pitti> dhonn: no
<pitti> dhonn: the kernel will only receive stabilization and security fixes
<pvanhoof> On my breezy, /dev/hdc (cdrom/dvd) device isn't readable for the desktop users
<pvanhoof> how can I fix this? (workaround, a better one than doing chmod 777 /dev/hdc)
<dholbach> good morning mvo
<dhonn> 5.10 is going to ship gnome 2.12, is that even stable?
<dholbach> pvanhoof: add them to group "cdrom"?
<Treenaks> dhonn: yes
<pitti> dhonn: that's a particular exception we do; it will be stable at the time we ship preview
<doko_> good morning
<dholbach> doko: good morning!
<dholbach> doko: is your cold any better?
<mvo> hey dholbach, morning all
<doko> yep, the drugs did help lowering the temperature
<dholbach> super
<sivang> morning dholbach 
<pitti> daniels: do you plan to upload a new dbus shortly?
<dholbach> hi sivan :)
<Treenaks> sivang: are you coming to BelowZero?
<pitti> daniels: (for #14178)
<pitti> daniels: if you don't have pending changes, I can do it myself
<daniels> pitti: if it's not crucial to fix (i.e. you can wait about 18h), wait for me to upload 0.36.1
<daniels> pitti: i got uvf-exception approval from mdz
<pitti> daniels: oh, ok
<pitti> daniels: that's fine; I reassign the bug to you then?
<daniels> pitti: sure
<mvo> elmo: please sync scite from debian
<pitti> elmo: simpleproxy sync, please
<zyga> mvo: hello
<mvo> zyga: hi
<pitti> infinity: btw, ok to upload the new pkgstripgranslations?
<infinity> pitti : Oh, yes, the changes have been rolled out on the buildds for a while, let 'er rip.
<infinity> pitti L They should just magically switch over to using the new format when it shows up.
<infinity> pitti : In theory.
<infinity> pitti : We'll see. :)
<pitti> ok, thanks :-)
<pitti> infinity: btw, rather than taking the biggest one, the more scientific method would be to take the union of all
<pitti> infinity: so, in theory, if there are per-arch domains, we get them all
<pitti> (that would be incredibly crackful, though, and probably never happens anyway)
<infinity> Well, what we're doing right now is just taking all of them. :)
<infinity> Where to go from here is up to you guys.
<pitti> infinity: I mean for import into langpack-o-matic and Rosetta; so far I only took one random arch
<infinity> (In fact, you and the rosetta guys should probably look at the lamont's scripts and move those to a more service-centric location, doing what you want them to do)
<infinity> There's more than enough things running out of ~lamont on various machines that don't have to be. :)
<pitti> infinity: well, in fact we could move it to /srv/langpacks... on rosetta and the import could just download the tarballs from *.buildd directly
<pitti> infinity: then I could export the merged tarballs over http for rosetta import
<pitti> infinity: so you didn't change lamont's scripts? (i. e. you didn't need to?)
<infinity> pitti : AFAICT, I don't need to.  We'll see if I'm terribly wrong about that in a little while.
<infinity> (If I am, it's no big deal, since we don't lose any data, as the originals all sit on the buildds, not rookery)
<infinity> pitti : But yes, if you want to import directly from the buildds, I have no issues with that.  The middle-man appears to only exist for the sake of turning 4 langpakcs into 1, which we seem to no longer want (or, at least, we don't want it without first comparing them)
<pitti> infinity: right, so we could get rid of ~lamont and that superfluous copy step in one shot
<infinity> pitti : Adding some more smarts to the import process is The Right Direction to go anyway, since if we add uploading of langpacks to DAK, it's not going to do the sorting for you, it's going to need one per arch (as we have now)
<pitti> EPARSE
<pitti> well, more like, I didn't understand that
<infinity> We don't want to make katie do the 4->1 langpack thing.  We just want katie to accept the files and give them to you.
<pitti> infinity: ah, that one, right
<infinity> So you need the 4 unique filenames, and you need to have your own import intelligence to deal with them.
<pitti> yes, makes sense
<dholbach> hellas infinity
<infinity> dholbach : Yo.
<dholbach> :)
<infinity> dholbach : Do have any overwhelming urge to smack the Debian XFCE maintainers around for doing something really dumb?
<dholbach> infinity: jani and crimsun are our MOTUs taking care of xfce
<infinity> dholbach : xfce4-mcs-manager-dev depends on libxfce4mcs-dev (>= ${Source-Version}), but they're not built from the same source.  So, stuff breaks horribly if they aren't always uploaded together, even if you're only fixing a bug in one.
<dholbach> infinity: i'll write them a mail
<infinity> dholbach : Forward this to them, then. :)
<dholbach> will do
<infinity> dholbach : It's a simple hack to add something that detects "Upstream-Version" in debian/rules, then fills that in for .substvars, which is probably what the Debian guys wanted.
<infinity> dholbach : Cause having the exact debian revisions tightly bound like that is just... Wrong.
<infinity> </rant>
<siretart> infinity: same issue to moagg and moagg-date, btw
<pitti> Hi sjoerd 
<siretart> s/date/data/
<sjoerd> pitti: mornig
<infinity> siretart : Please fix it and file a bug with Debian with a patch.  Pretty please.  Having packages split like that when they all have to be updated together ANYWAY is so obviously pointless.
<infinity> siretart : dpkg-parsechangelog -> echo "Upstream-Version=<whatever>" foo.substvars -> use "Upstream-Version" in debian/control instead of Source-Version.
<infinity> siretart : Fairly simple to hack up correctly.
<daniels> infinity: errr
<daniels> infinity: just pass -VUpstream-Version=$(UPSTREAM_VERSION) to dh_gencontrol
<infinity> daniels : I skipped some steps, I assume siretart's smart enough to get there.
<infinity> daniels : <shrug>... Either one works.
<siretart> infinity: I'm currently at work, so I cannot doi it right now. Will put it on my list. 
<siretart> infinity: I'm honoured :)
<infinity> daniels : Same end effect.
<sjoerd> pitti: do you know why dbus-sessionbus-checkuid.patch was dropped from the ubuntu dbus package, couldn't find that in the changelog..
<pitti> sjoerd: no idea, please ask daniels
<sjoerd> daniels: ? :)
<daniels> sjoerd: hullo :)
<pitti> sjoerd: AFAIR that was backported from stable
<daniels> sjoerd: i guess you mean the gid-hecking stuff?
<daniels> sjoerd: if it was gid-checking, the entire codepath got dropped upstream
<sjoerd> it's the patch that prevents other users to connect to your session bus
<sjoerd> added in 0.34-1ubuntu4
<sjoerd> daniels: it still applies in 0.36.1 so, i doubt that codepath was dropped
<dholbach> infinity: there's even a motuxfce team in malone :)
<dholbach> infinity: but i wrote the mail alread
<mvo> ping jdub 
<infinity> dholbach : Fancy, thanks.
<infinity> dholbach : Just ran accross that while clearing up cairo/glitz issues and it irked me. :)
<daniels> sjoerd: oh.  the checkuid thing was fixed upstream already.  unless something's gone horribly wrong.
<dholbach> infinity: you ROCK! :)
<sjoerd> daniels: maybe it was fixed in some other way then.. because the patch still applied cleanly
* daniels stares at session.conf and frowns.
<daniels> sjoerd: thanks, good catch.  i'll check into it now.
<daniels> sjoerd: btw, I'm doing 0.36.1 packages.  time to move 0.3x to sid?
<sjoerd> daniels: haha, no way
<sjoerd> daniels: oh, did you see my 0.36.1 package for debian :)
<sjoerd> daniels: we're gonna move to 0.3x at the same time with gnome 2.12 probably..
<daniels> oh *dear*.
<daniels> oh dear, oh dear, oh dear.
<daniels> joey only applied the patch to 0.2x's branch.
<sjoerd> woops
<daniels> sjoerd: are your .36.1 packages in experimental?
<sjoerd> daniels: yes
<sjoerd> well incoming atm maybe
<sjoerd> got the mail that it came out of new this morning, so probably still incoming
<sjoerd> the debian dir is also in pkg-utopia svn btw
<infinity> Yupm there it is in ACCEPTED.
<pitti> Hi carlos 
<carlos> pitti, hi
<daniels> sjoerd: i've hit upstream about it, too.  thanks a lot for the catch.
<pitti> sjoerd: did you use lsb init scripts in experimental?
<sjoerd> pitti: yup
<pitti> daniels: ok, then it almost seems that we can just sync from experimental?
<sjoerd> gotta go, class in 15 min.. later 
<daniels> oh, okay
<daniels> pitti: i'll look at the interdiff, but it's tomorrow
<daniels> pitti: i need to have an xorg upload done today
<pitti> daniels: sure, no hurry; just a general question :-) thansk
<daniels> pitti: cool
<daniels> sjoerd: later on -- thanks
<dholbach> elmo: could you please sync gaim-irchelper and glademm from sid and remove glademm from the blacklist - seems upstream works on it again and users want it
<pitti> Hi jdthood 
<jdthood> hoi
<zyga> how do I correctly describe launchpad bug?
<zyga> the 'system error' page is quite lacking on details
<mdke> zyga, just tell them what you do and what happens, they can look in the logs
<zyga> mdke: ok, I did that
<mdke> zyga, you can also see if anyone is around to help in #launchpad
<zyga> good idea, thanks
<dholbach> see you all later again *wave*
<siretart> cu dholbach 
<spayne> i think there is an issue with hotplug/modprobe and ndiswrapper
<spayne> it looks as if it isn't loaded the ndiswrapper.ko module on boot
<spayne> so the startup locks upon "Loading Modules..."
<sivang> jdub: so, already knows how to crete the boot images , all lfet is just to put this into CONF.sh of our debian cd
<sivang> jdub: (tgall knows, that is)
<Treenaks> spayne: Please file a bug, instead of complaining here
<azeem> http://www.murrayc.com/blog/tech/2005-08-29-11-30
<daniels> argh
<daniels> when do we get an oo.o2-amd64 update?
<Treenaks> azeem: he's right
<daniels> ubuntu-desktop is uninstallable on amd64 atm
<spayne> Treenaks: i did two weeks ago and nothing has happened
<Treenaks> spayne: that doesn't mean nothing will happen eventually
<spayne> eventually?
<spayne> breezy is out in a month
<Treenaks> spayne: yes.. guess what we do just before release?
<spayne> Bug Day?
<Treenaks> spayne: more like a bug month:)
<pef> hi
<pvanhoof> Is making bugzilla.ubuntu.com slow a way to make sure we don't submit a lot bugs?
<pvanhoof> sometimes it's awfully slow
<Lathiat> pvanhoof: heh try viwing the page source for the enter bug page
<pvanhoof> ubuntu bugzilla devs: try making sure it loads fast. It's not that the enter bug page really has to be complicated or huge
<pvanhoof> omg. it loads ALL components in some EMBEDDED java script
<Lathiat> yuh
<pvanhoof> people get shot for that at my company
<pvanhoof> they just bypass any justice system here .. they get immediatly shot
<pvanhoof> in the head, and if not dead .. shot again
<Lathiat> what if theyre still not dead?
<pvanhoof> then .. they get the chance to correct it .. (with the brains they have left)
<pvanhoof> they could at least try to consider ajax if they really want to do it that way 
<pvanhoof> and if ajax is to hard .. put it in a .js file
<pvanhoof> that way it'll be cached between different pageviews
<pvanhoof> *sigh* .. so far for "intelligent" opensource developers at ubuntu's web services
<daniels> no work has gone into bugzilla for ages
<daniels> it's all about malone
<daniels> so judging launchpad based on how bz's been mangled is rather unfair
<pvanhoof> and they should remove the fact that the "Package" textbox is required. Not a single normal user "knows" how to use that
<pvanhoof> daniels, it's not about being unfair. For MOST people (with internet connections of today), it's simply unusable this way
<daniels> ah, that's where all my multiseat uploads have gone
* daniels tries bumping the distribution from hoary to breezy, for a novel change.
<daniels> pvanhoof: i know it's shit, dude
<daniels> pvanhoof: i spent months bitching about this while I was on dialup
<pvanhoof> :(
<daniels> pvanhoof: but saying 'ubuntu's web service team sucks, look at bugzilla' is really, really unfair.
<pvanhoof> I'm not saying they suck. I said they made a very unintelligent decision when they decided to put all components in an embedded javascript
<daniels> pvanhoof: that was not the launchpad team.
<j^> that should be ajax as used on http://www.google.com/webhp?complete=1&hl=en
<daniels> pvanhoof: entirely separately to launchpad, we used to have a bugzilla maintainer.  back then, he made the decision to do the javascript thing.  he was not ever a part of the launchpad team.  entirely unrelated.
<pvanhoof> ok
<pvanhoof> never said that "launchpad" did this
<daniels> j^: i'm sure patches would be welcome.  do it against the bugzilla codebase, submit it upstream, and everyone wins.
<daniels> pvanhoof: ubuntu has nothing else to do with a web services team.
<pvanhoof> daniels, for a user of the system, it doesn't matter "who" did it
<pvanhoof> or "how" the team is called
<pvanhoof> the fact is .. it doesn't work
<pvanhoof> it takes ages to submit a bug because of that component list .. which is a stupid feature anyway
<pvanhoof> not a single mortal normal user will submit bugs .. I thought ubuntu was about Humanity to others .. or.. creating a system that is usable for everybody. Including bug reporting
<pvanhoof> or is bug reporting only for the elite who have great internet connections?
<daniels> pvanhoof: i know it's crap, but you're not being at all helpful here.
<daniels> pvanhoof: malone is fine for reporting bugs, and bugzilla has been slated for imminent death for, oh, about a year now.
<j^> pvanhoof and do you think this is the biggest problem to fix in ubuntu right now, or is it a minor glich?
<daniels> pvanhoof: if you want to actually be productive, try using malone and report bugs on it.
<pvanhoof> maline.ubuntu.org ?
<pvanhoof> malone.ubuntu.org ..
<j^> https://launchpad.net/
<daniels> http://www.launchpad.net/malone/
<pvanhoof> j^, problems can be solved in parallel. It's not because this isn't the biggest problem .. that it's unimportant or to be queued 
<daniels> pvanhoof: try not having a bugzilla maintainer.  anyway, as I said, if you want to be useful rather than just randomly bitching on IRC, try either doing the AJAX stuff against upstream Bugzilla, or filing bugs against Malone.
<HiddenWolf>  /umode +CE
<j^> pvanhoof never said that, but you made it sound as if this was not fixed ubuntu would not be "a system that is usable for everybody"
<pvanhoof> j^, Well, if ubuntu wants to be usable for everybody, I think you guys should make that Malone thing the default for bugreporting
<pvanhoof> or fix that bugzilla flaw
<pvanhoof> because the default for bug reporting is not usable at this moment
<pvanhoof> I'd like to close the discussion
<j^> pvanhoof thats the plan, but it might take some more time
<daniels> pvanhoof: the plan is to move to Malone
<pvanhoof> that is good
<daniels> pvanhoof: closing the discussion is a good idea, since it hasn't achieved anything.
<hunger> Hi there.
<HiddenWolf> pitti: ping?
<HiddenWolf> daniels: nvidia drivers don't work for me, but I guess I'm not the only one? (6600GT, using nvidia driver sends my monitor to sleep mode)
<HrdwrBoB> HiddenWolf: do you have enough power?
<daniels> HiddenWolf: uhm, I dunno.  ask nvidia?
<HrdwrBoB> AGP 6600GT?
<HiddenWolf> HrdwrBoB, I'd say so. it's pci-express.
<HrdwrBoB> ah, that should be ok, I've just ahd a few issues with my agp 6600gt
<HiddenWolf> daniels, you mean they'd actually care about a bug report @ nvidia? ;)
<pitti> HiddenWolf: pong
<hunger> pitti: Did you look into my cryptodisk script yet?
<HiddenWolf> pitti: #14226, anything else you need?
<pitti> hunger: no, sorry, but we are in feature freeze for some weeks anyway
<pitti> HiddenWolf: just saw your bug reply
<daniels> HiddenWolf: i dunno
<pitti> HiddenWolf: so you installed from scratch? without any dist-upgrade?
<pitti> HiddenWolf: I'm currently installing the i386 daily, I will look at it
<pitti> HiddenWolf: might very well be that udev doesn't ship the file any more (we had a similar bug recently)
<HiddenWolf> I filed the bug installing a 28aug daily from scratch on a brand new harddisk even. Then I tried mounting an audio cd, and cdplayer told me I didn't have permissions to read the disk.
<HiddenWolf> I since reverted to colony3, and dist-upgraded from there, which fixed a load of crap for me.
<zyga> when are translations frozen?
<pitti> HiddenWolf: ok, then I guess some udev update just dropped the file
<HiddenWolf> zyga, sept1 is string freeze, translations will be updated throughout the release probably?
<zyga> HiddenWolf: they are? I never noticed any updated translations
<pitti> zyga: there have been several language pack updates recently
<HiddenWolf> *argh!*
<HiddenWolf> I spent an hour or so getting my tvtuner to work yesterday, and now after a reboot, I don't have sound again.
<zyga> pitti: are they in any special repo? 
<pitti> zyga: no, ubuntu main
<zyga> strange
<pitti> zyga: language-pack-[gnome-] -<lang>
<pitti> zyga: please use the language selector :-)
<zyga> pitti: language selector for hoary? :)
<pitti> zyga: ah, hoary - no there haven't been any updates
<zyga> BTW: it really rocks :)
<zyga> so after the release breezy's translations are frozen, right?
<pitti> zyga: well, the original strings are, not the translations
<HiddenWolf> zyga, language packs should be updated.
<pitti> zyga: there will be updates after release
* pitti kicks udev's braindead postinst really hard
<zyga> pitti: so if I translate a package in rosetta now it will be updated in hoary (language packs that is)
<pitti> zyga: yes, as soon as rosetta export actually works
<zyga> pitti: excelent!
<pitti> zyga: I made a few attempts, but so far export is still broken
<zyga> :-)
<zyga> anyway if that's WIP it will be operationan one day
<zyga> operational even
<pitti> zyga: yes, archive-wise hoary updates are prepared and ready to go
<doko> anybody knows where seb128 is?
<pitti> doko: yes, vac until tomorrow
<doko> ohh
<doko> pitti: do you know, if we already have translations for the two lpi items?
<pitti> doko: I guess not
<pitti> but maybe Rosetta knows them already`
<pitti> ?
<pitti> hey, my i386 install finished
<ogra> doko, feeling better ?
<doko> ogra: drugs are ok ...
<ogra> doko, did you recognize that the blackdown packages are compiled with XPrint support (so nothing mozilla related works, i.e. plugins)? anything we can do about that ? 
<doko> ogra: please file a bug report
<ogra> doko, dholbach will be soon around the corner... we'll send him to you to be helpful ;)
<ogra> (mix your drugs and such ;) )
<janimo> any MOTUs with some free time on their hand - does such a motu even exist ;) ? - want to revu xubuntu-meta? End of spam
<janimo> sorry wrong channel
<HiddenWolf> daniels, There is nothing you can do about nvidia drivers, so I have to bitch to nvidia?
<daniels> HiddenWolf: well, it's not like I can fix the problem ... same with fglrx
<pitti> HiddenWolf: hmm, clean install from today's iso: I do get the 020_permissions.rules symlink
<HiddenWolf> pitti, perhaps today's udev fixed it?
* netjoined: irc.freenode.net -> herbert.freenode.net
* mode/#ubuntu-devel [-s]  by ChanServ
* netjoined: irc.freenode.net -> brown.freenode.net
* netjoined: irc.freenode.net -> brown.freenode.net
* netjoined: irc.freenode.net -> brown.freenode.net
<pitti> HiddenWolf: nope, that fixed another bug; also, today's update is not yet on the CD
<HiddenWolf> Hm. Well, then I'd say check what differs between colony3 and today?
<HiddenWolf> pitti, Hm. Well, then I'd say check what differs between colony3 and today?
<pitti> HiddenWolf: but you said colony 3 worked for you?
<pitti> HiddenWolf: hm, it seems the installer downloaded new packages off the network, so I already do have udev 0.060-1ubuntu8
<pitti> HiddenWolf: which version do you have?
<HiddenWolf> pitti, Version: 0.060-1ubuntu9
<HiddenWolf> hidde@system:~$ /etc/udev/rules.d/020_permissions.rule
<HiddenWolf> bash: /etc/udev/rules.d/020_permissions.rule: No such file or directory
<HiddenWolf> haven't rebooted tho
<pitti> HiddenWolf: ok, I have ubuntu8
<pitti> HiddenWolf: the udev postinst is braindead, I will try to whack some sense into it, but that's nontrivial due to conffile migratio
<pitti> n
<HiddenWolf> pitti, anything i can do to to help you track it?
<pitti> HiddenWolf: beat up Marco d'Itri to do sensible packaging? :-) /me runs
<HiddenWolf> pitti, sorry, I'm a pacifist. ;)
<pitti> HiddenWolf: me too, that's the problem :-)
<pitti> anyway, I will look into it
<pitti> but first, lemme take a look at eject
<HiddenWolf> pitti, no rush.
<pitti> brb
* netjoined: irc.freenode.net -> brown.freenode.net
<pitti> HiddenWolf: hmm, the symlink is correct for me, but the group of the cdrom device is indeed wrong
<HiddenWolf> pitti, what does the symlink do really? (yes, I'm dumb. ;) )
<pitti> HiddenWolf: it just makes /etc/udev/permissions.rules actually evaluated
<pitti> ... being ...
<HiddenWolf> pitti, you're the language pack guy right?
<pitti> yes
<HiddenWolf> pitti, any reason why in my english-only install I get fonts from Arabic to Swahili?
<pitti> yes
<pitti> HiddenWolf: we want to display all content correctly
<pitti> HiddenWolf: "english install" means english desktop "translations" and english input support
<pitti> but we don't want to cripple content display
<HiddenWolf> Right, but would it be possible to get all those fonts out of my openoffice font lists then? It makes changing the font a pain, since half of them look like gibberish to me.
<pitti> hm, no idea
<HiddenWolf> s/openoffice/texteditor
<HiddenWolf> doko: any clue? ^^
<doko> HiddenWolf: no
<HiddenWolf> bummer
(HiddenWolf/#ubuntu-devel) doko, mind if I file a bug to that extent?
(mpt/#ubuntu-devel) eh, that's interesting
(siretart/#ubuntu-devel) ogra: around?
(mpt/#ubuntu-devel) Yesterday, I had X but not usplash. Today I have usplash but no X.
<doko> HiddenWolf: implement FontHandling, or how this breezy goal is named.
(ogra/#ubuntu-devel) siretart, hey, thanks...
(ogra/#ubuntu-devel) siretart, i thought lbxp was dead ...
(ogra/#ubuntu-devel) libxp even
(HiddenWolf/#ubuntu-devel) pitti: hidde@system:~$ /etc/udev/rules.d/020_permissions.rules
(HiddenWolf/#ubuntu-devel) bash: /etc/udev/rules.d/020_permissions.rules: Permission denied
(HiddenWolf/#ubuntu-devel) pitti: just the group then.
(siretart/#ubuntu-devel) ogra: it is dead, but still in xorg cvs
<pitti> HiddenWolf: ok, so we two have the same situation. I just wanted to assert that :-)
<siretart> ogra: daniels suggested to package it and have it around in universe for binary shit like this
<ogra> siretart, but the clean fix would be to fix the java package :)
<mpt> daniels: It says "Failed to start the X server", etc, and the text frame uses lots of s, s, and s, and becomes unresponsive
<ogra> at least its a start :)
<daniels> mpt: need an Xorg.0.log
<siretart> ogra: but still I wonder why no binaries are available: http://packages.ubuntu.com/breezy/source/libxp
<mpt> daniels: and that would be in /var/logs/ ?
<daniels> ogra: fixing java would be nice, certainly ...
<siretart> according to http://people.ubuntu.com/~lamont/buildLogs/libx/libxp/6.2.0-0ubuntu1/ it got built
<siretart> but there is no binary in the archive. huh?!
<daniels> siretart: possibly binary NEW
<daniels> mpt: /var/log/, yes
<ogra> daniels, yes, but i dont hav access to the source, we only have the blackdown binary packages currently...
<daniels> ogra: exactly
<fabbione> daniels: ehy dude
<daniels> fabbione: sup
<fabbione> -54.. did you fix the MANIFEST for sparc? ;)
<siretart> daniels: who could check this?
<daniels> fabbione: yes, I said that I fixed it a while ago, when you last asked me about it :P
<fabbione> daniels: given i had to do a vi on the fly while building -53 ;)
<daniels> siretart: probably elmo when he wakes up, but he was up until stupid o'clock fixing jackass
<fabbione> daniels: there was no track in the changelog.. sooooo....
<siretart> ok
<HiddenWolf> doko, ok, i'll live with it
<opi> Hi
<marcin_ant> hi all
<marcin_ant> I got a problem with wireless network interface on breezy
<marcin_ant> I need to configure this NIC as dhcp client and in ad-hoc mode
<opi> iface wlan0 dhcp won't work?
<opi> Oh, ad-hoc.. 
<marcin_ant> the problem is that wireless-mode ad-hoc in /etc/network/interfaces doesn't want to work
<opi> marcin_ant: man interfaces says nothing at all?
<opi> marcin_ant: TBH, I always created my own script for WiFi in /etc/init.d ;)
<marcin_ant> opi, it says to add wireless-mode ad-hoc
<marcin_ant> opi, but after boot my nic is in managed mode and doesn't want to connect
<marcin_ant> opi, when I iwconfig eth1 mode ad-hoc
<marcin_ant> and dhclient eth1 
<marcin_ant> then everything is ok
<opi> maybe there's an error in /etc/init.d/networking?
<marcin_ant> opi, hmm I need to take a look at this script
<opi> marcin_ant: if everything fails, you can try dirty hack, throw .sh script into if-pre-up
<j^> marcin_ant you have to set ssid before you can set ad-hoc. so it should be
<j^> wireless-essid Wireless
<j^> wireless-mode ad-hoc
<marcin_ant> j^, I got this like you said 
<marcin_ant> j^, and it worked on hoary
<marcin_ant> j^, but doesn't want on breezy
<opi> marcin_ant: maybe you should poke around Bugzilla
<opi> marcin_ant: maybe it's filled bug?
<marcin_ant> opi, I'll try
<marcin_ant> opi, but in fact I even don't know where is ubuntu bugzilla
<marcin_ant> opi, anyway I'll try to add iwconfig eth1 mode ad-hoc somewhere to run this script before ifup
<j^> pre-up iwconfig ...
<j^> could work
<j^> (in interfaces)
<marcin_ant> j^, /etc/init.d/networking fails always when I add something to interfaces....
<opi> marcin_ant: http://bugzilla.ubuntu.com
<pitti> HiddenWolf: ok, so you are sure that ubuntu6 worked?
<HiddenWolf> pitti, I haven't tried any breezy before Colony3.
<pitti> HiddenWolf: ok, thanks; 
<HiddenWolf> pitti, sorry for giving you that impression. I ment: On my colony3 install I could at least acces(automount) the disc without chowning them, which I couldn't under the 26aug daily.
<pitti> HiddenWolf: ok, so what I meant was that the device permissions were ok?
<HiddenWolf> pitti, I guess so, yes.
<pitti> darn
<pitti> does anybody still have a copy of the udev_0.060-1ubuntu6 source package?
<pitti> Keybuk: you maybe? since you touched it recently
<siretart> elmo: around? - do you happen to know what's up with libxp? it seems to be accepted (got that mail), it has been built, but there are no binary packages in the archive. did I do something stupid?
* ..[topic/#ubuntu-devel:irc.freenode.net] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze! https://wiki.ubuntu.com//HelpingWithBugs | Colony 3 is released: http://cdimage.ubuntu.com/releases/breezy/colony-3/ | #ubuntu is temporarily open to registered users only to prevent spam bots. /msg nickserv help to regi
<HiddenWolf> Gees, what a mess. :)
<opi> HiddenWolf: ;-)
<opi> HiddenWolf: we're all vitims of spam wars 
<pitti> HiddenWolf: can you please verify that the permissions are correct when restarting udev?
<pitti> brb
<HiddenWolf> opi, it's just sick that someone would spam freenode.
<pitti> HiddenWolf: can you please put your udev deb somewhere?
<sivang> tgall_foo: ping
<sivang> tgall_foo: when you created your IBM booting images, did you use an archive mirror, if so, was it local or on the web?
* mvo curses at notification-daemon
<sivang> tgall: ping again, did yu catch my last question ?
<tgall> morning sivang 
<tgall> sivang, as to how did those combo of flags come about ?
<Mitario> mvo, yay! cheers :)
<mvo> hey Mitario 
<mvo> how are you? 
<Mitario> mvo, hey :)
<Mitario> just noticed      - fix the "window is incorrectly drawn on first run" bug (#14006) :)
<Mitario> mvo, i'm very good, you?
<mvo> Mitario: I think I fixed that bloody bug in the notification daemon that caused the double drawn notification for update-notifier :)
<Mitario> yeah :)
<Mitario> great!
* Mitario has been very busy doing MOTU stuff the last few days
<mvo> Mitario: oh, nice! 
<sivang> tgall: haven't tested them alone yet, I've been trying to hack on debian-cd to have those flags in for building images, troulbe is that I think debian-cd expects me to have a complete mirror on the local disk to run
<tgall> sivang: ah ..  yeah I haven't started to hack on debian cd quite yet...    my experiences with livecd etc creation is all based on gentoo from which I hail,  just started to get into the swing of things to learn about debian packaging and building
<tgall> sivang, I know those mkisofs flags work tho ...    were you around when jdub and I were talking about the other bits you need to get an IBM chrp/rpa ppc64 box to boot off iso ?
<sivang> tgall: not quite. I recall he told me you two had success rolling them on, would you mind sharing with me the missing bits?
<tgall> sivang: np .. sounds like maybe I ought to throw it into the wiki!
<tgall> sivang: I personally haven't rolled a ubuntu cd yet ... but I'm burning to come up to speed to be able to do that
<sivang> tgall: how did you get your image made eventually? uncompressing the content of a livecd and preparing it with mkisofs like the way you described in your mail to -devel ?
<sivang> tgall: me too :)
<sivang> tgall: we can start the inofficial IBM CHRP Ubuntu team :)
<tgall> basically on IBM boxen (32 and 64 bit)  by convention they look for a script  ppc/bootinfo.txt
<tgall> sivang: I'm all for that
<tgall> the bootinfo.txt script is a bit too long to c/n/p in here tho
<sivang> tgall: I'll start a quick page  on the wiki, then send you the link so you can outline the instructions there
<tgall> and in that script basically you point at a yaboot that has had addnote run over it (addnote comes with yaboot)
<sivang> tgall: ah, I think I saw that bootinfo.txt file in the howto jdub pointed a link for me
<sivang> tgall: what'a addnote role?
<tgall> sivang: throws a little elf record at the front that the open firmware loader needs
<sivang> tgall: ah like the first bits the loader JUMPs to ?
<tgall> no doesn't contain code to execute
<tgall> more of a packaging issue which is rather silly
<tgall> IBM OF looks for it ... apple OF expects it not to be there
<sivang> tgall: I see. ok then, I guess I can read about it at penguinppc.org
<sivang> tgall: thanks for the explenations
<tgall> sure ting
<HiddenWolf> Who maintains pppoeconf?
<sivang> tgall: https://wiki.ubuntu.com/UbuntuOnThePseries?action=show now you're turn to outline how to create a boot iamge manually :)
<pitti> HiddenWolf: FYI, it is not an udev regression; I suspect something else, I need to grab jbailey for that
<HiddenWolf> pitti, right. Thanks for the positive action. :)
<pitti> HiddenWolf: this one makes me drive up the wall
<HiddenWolf> pitti, If I could code my way out of a wet paper bag, I'd help. Sorry. :$
<pitti> HiddenWolf: I suspect that initramfs-tools breaks it somehow, but I need to talk to Jeff to find out details
<HiddenWolf> pitti, you rock.
<hunger> pitti: Was this about /dev/input/mice not working?
<HiddenWolf> hunger, no, about /dev/cdrom being owned by root instead of cdrom.
<pitti> hunger: it was about "devices have the wrong permisssions" (#14226), not sure whether this also affects your problem
<pitti> HiddenWolf: it's not just cdrom, but all block devices
<HiddenWolf> pitti, ok, sorry.
<hunger> Oh. haven't noticed that yet:-)
<pitti> no need to excuse :-)
<hunger> But then I have not used my cdrom since I installed hoary:-)
<HiddenWolf> The first thing I did was pop in a cd, since rhythmbox isn't working at all at the moment.
<HiddenWolf> ubuntu then promptly told me I couldn't play my cd. :P
* hunger finds /dev/input/mice missing much more enraging anyway: X won't start without me doing an udevstart beforehand.
<pitti> hunger: could indeed be the same bug
<dilinger> $#@!$
<dilinger> --- Unregistered users cannot currently send private messages due to spambot problems. please register! ( http://freenode.net/faq.shtml#nicksetup )
<dilinger> i hate this network
<pitti> fabbione: do you happen to know about the guts of initramfs?
<HiddenWolf> bah, is daniels gone?
<dilinger> pitti: hiya.  are you familiar w/ CAN-2005-2655?
<pitti> Hi dilinger 
<zul> dilinger: maybe you should register then
<pitti> dilinger: never heard of
<dilinger> pitti: alright.  pitti@canonical.com, right?
<dilinger> or is it mpitt?
<pitti> dilinger: martin.pitt@u.c
<pitti> dilinger: pitti could also work
<pitti> brb
<dilinger> zul: because i have no desire to register my nick w/ an irc network and have unregistered people not able to msg me
<sivang> dilinger: just register ? :)
<sivang> dilinger: woops, terrible latency problem
<dilinger> it's yet another stupid password to remember
<sivang> true...I just got used to it by now..
<HiddenWolf> crimsun, around?
* dilinger heads over to oftc
<lamont-away> elmo: please sync ixbiff_0.03d (fixes ftbfs in breezy)
<lamont-away> elmo: dvi2dvi_2.0alpha-5.1 looks like a good candidate as well, although it contains a bit more code cleanup than just the bare minimum...
<infinity> elmo / mdz : xdriinfo needs to be pushed through NEW for xbase-clients to be installable again, pretty please.
<siretart> lamont-away: hi. is it possible that a package got build but it's binaries did not go into the archive yet because it is in Binary NEW? can you check that or is elmo the only person to do that?
<siretart> s/to do/who can do/
<infinity> siretart : Yes, it's possible.  Which package?
<lamont-away> siretart: anyone can verify that the package was uploaded (buildLogs/Lists/breezy.all.$ARCH, state==Uploaded)
* infinity sees that siretart's in good hands, and heads off to bed.
<lamont-away> from there, why it's not in the archive requires looking at the appropriate overrides file in archive.ubuntu.com/ubuntu/indices
<lamont-away> that is, to confirm that it truely is 'NEW' (missing from the overrides file)
<lamont-away> someone with shell access to the master archive (not infinity/me) can actually go look and see what queue it's in...
<lamont-away> there are other reasons that it might not be in the archive, but those are the usual ones...
<siretart> it is package libxp
<siretart> lamont: it has been built sucessfully on all archs, and I got a mail from katie that it got ACCEPTED
<siretart> lamont: but its binary packages are not yet in the archive
* siretart is a bit puzzled
<siretart> and there is no entry in the override file at all. does this mean it is in binary NEW?
<siretart> gn8 infinity 
<infinity> siretart : Yes.
<siretart> ah. ok
<siretart> I thought I did something stupid
<siretart> :)
<lamont> elmo: please sync evolver_2.23-1.1 (fixes ftbfs)
<lamont> siretart: your ACCEPTED mail says that the source was accepted into the archive
<lamont> if it's not in the overrides file, then it's NEW
<siretart> ok. learned another thing for today :)
<siretart> so I'll wait for another few days. no problem
<mdz_> infinity: done
<bddebian> Hello
<pitti> Hi mdz_ 
<lamont> elmo: please sync tint_0.03b (fixes ftbfs)
<_derek> daniels: ping
<mdz_> pitti: hi
<_derek> can anyone tell me if any work has been done on bug 14120
<tgall> sivang, ping 
<lamont> elmo: please sync nntp_1.5.12.1-19 (ftbfs)
<pitti> mdz_: is there anybody else apart from jbailey who knows about the guts of initramfs?
<lamont> elmo: ipchains_1.3.10-16 looks sync-able as well (a couple other minor-nit bugs fixed too)
<lamont> elmo: mmv_1.01b-12.2 fixes ftbfs
<mdz_> pitti: I do
<HiddenWolf> Who maintains ppp(oeconf)
<HiddenWolf> ?
<lamont> HiddenWolf: it says this for Debian:  Maintainer: Eduard Bloch <blade@debian.org>
<lamont> for ubuntu?  whoever fixes it, I expect
<HiddenWolf> lamont, so who do I talk to if I want it to start earlier during init?
<lamont> dunno
<lamont> if it needs to start earlier in general, I'd probably start a discussion with Eduard
<HiddenWolf> lamont, piont is that if one uses ppp, ntp will always time out, just because ntp gets run before ppp. That's silly.
<lamont> and a pretty good argument
<mdz> infinity: are xdriinfo binaries inbound?
<HiddenWolf> mdz, just showed up on -changes...
<mdz> HiddenWolf: that was the soruce
<mdz> source
<siretart> HiddenWolf: Eduard Bloch is Zomb on irc, btw
<HiddenWolf> siretart, we'll see. I might get flamed again for running Ubuntu tho. :)
<sivang> tgall: pong
<sivang> anyone to review and upload http://muse.19inch.net/~sivan/lpint/gnome-panel/my_lpint_gnome-panel-crack.diff for me?
<sivang> hmmm, guess I'll email pitti with the debdiff then
<mvo> ogra: ping
<tvo> mdz: ping
<mdz> tvo: pong
<tvo> mdz: is it possible to get a new version of kio-locate into main ?
<mvo> mdz: what do I do with automatically imported bugs from bugs.d.o against universe packages? just clossing with "universe" as tag?
<mdz> tvo: subject to release criteria, yes
<mdz> mvo: universe or NOTWARTY
<mdz> mvo: (notwarty suppresses all further mail)
<mvo> mdz: done, thanks
<BrightLight> Hello. Ubuntu installer is unable to find my Slimtype DVDRW (Laptop-Acer TravelMate 4152Lmi). Is there any other way to install Ubuntu ?
<tvo> mdz: where to find those?
<mdz> tvo: http://wiki.ubuntu.com/BreezyReleaseSchedule
<mdz> tvo: if the new version is exclusively a bugfix release, that would be a good candidate
<infinity> mdz : xriinfo binaries are all uploaded...
* mvo is away for a bit to play hockey
<infinity> xriinfo, too.
<infinity> Argh.  xDriinfo.
<tvo> mdz: it depends on what you'd call a bugfix. I'd say it could do, but who am I to say so..
<infinity> Note to self: If you're awake at3:30am because you can't chake a cough, that's not a good time ot be working or communicating.
<tvo> mdz: detailed changelog --> http://home.casema.nl/vollebregt/soc/changelog-kio-locate--tvo--0.2.html
<mdz> infinity: did you have any luck with usplash?
<infinity> usplash is a "This Morning" thing.
<tvo> mdz: to summarize: no new features, just changed behaviour and bugfixes
<infinity> (I took an actual weekend for once, then Monday was "jackass was down and stuff was goofy" day)
<infinity> So, Tuesday (which happens in a few hours, it looks like) is "make usplash and lsb love each other day"
<tgall> sivang, still out there ?
<mdz> infinity: oh, I thought you had been working on it already on Friday
<infinity> I tihnk it was Saturday already when I said I'd play with it, though my mental calendar may be off.
<infinity> (Well, my Saturday is your Friday, so that always confuses)
<mdz> tvo: looks OK except patch-3; how intrusive is that
<mdz> tvo: ?
<infinity> Anyhow, I see no reason why I shouldn't have something working and reasonably tested today.
<jbailey> infinity: The one line patch that mjg59 gave me for when we were doing the initramfs testing shows that it all seems to work in its basic form at least.
<infinity> jbailey : <nod>, it certainly appears to.
<tvo> mdz: I'd say not-intrusive, large part of the code it added already existed (and was tested). For enduser, it's just a change in UI (output only)
<sivang> tgall: now I am, but going out in about 10 minutes
<tgall> heh
<tgall> go figure!
<sivang> tgall: what? :)
<sivang> tgall: (I was out taking some dinner, and then I Have a couple of arrangements to do)
<tgall> I was going to ask you did you get that wiki page started ?
<sivang> tgall: already there :)
<tgall> great,  what's the name 
<tgall> ?
<ogra> mvo, late pong
<mjg59> jdub: We've got three more colours to play with, dude
<mdz> tvo: OK, sounds reasonable
<jbailey> mdz: ping?
<tvo> mdz: can you do a sponsored upload too or should I ask someone else?
<mdz> tvo: please ask someone else; don't you have a mentor assigned?
<mdz> jbailey: why is it that you often seem to ping me when I've already spoken in the channel a few seconds before 
<mdz> jbailey: :-)
<tvo> mdz: yes, he's pretty busy with aKademy, but I'll ask him anyways
<jbailey> mdz: Synchronicity? =)
<mdz> jbailey: well, there's no need to ping if I'm obviously here.  fire away :-)
<infinity> mdz : ping.
<jbailey> mdz: Do you have brainspace for questions on 14242 right now?  Or, I can reply in the bug.
<mdz> jbailey: happy to talk about it here, but please follow up to 14242 as well so that pitti gets copies
<mdz> oh, thinking of a different bug
<mdz> jbailey: I was thinking of #14226, which is much more important at the moment
<sivang> tgall: https://wiki.ubuntu.com/UbuntuOnThePseries
<mdz> jbailey: does my suggested solution in 14226 make sense to you?
<jbailey> mdz: The tmpfs has to move from the initramfs to keep the socket for usplash up.  I'll have to figure out why it's not firing on other systems.  On mine, when I  checked it was still calling the udevstart, and seemed to be fine.
<jbailey> mdz: So I don't tink stopping and starting is the right solution.
<mdz> jbailey: that was pitti's proposal.  mine is in comment #7
<sivang> tgall: I'm out talk to you when I'm home
<jbailey> mdz: Yes, that would work.
<HiddenWolf> Oh my, I found a critical bug. ;)
<jbailey> Funny that I had originally created the .initramfs-tools as a way for me to tell when people had actually updated to the new initramfs or not. =)
<mdz> mjg59: I think we need to increase the usplash timeout
<mdz> mjg59: the lrm init script seems to take longer than the timeout to complete
<mjg59> mdz: Ok, that's easy enough
<mdz> mjg59: I think it might help if that init script actually printed something; I've made it do so
<mjg59> mdz: Do we have usplash support in the lsb scripts now?
<mdz> still, it seems pretty feasible for it to take >15 seconds just for the meat on slow hardware, considering that it runs depmod
<mdz> lsb (3.0-1ubuntu4) breezy; urgency=low
<mdz>   * Basic usplash integration
<mdz>  -- Matt Zimmerman <mdz@ubuntu.com>  Mon, 29 Aug 2005 11:20:00 -0700
<mjg59> Sure. Want me to bump it, or should I add support for setting it via usplash_write?
<mdz> mjg59: care to take a look before I upload it?
<mjg59> Then it could be extended when it's expected to take longer, and shortened otherwise
<mjg59> mdz: Sure
<mdz> mailed
<mjg59> Thanks
<mdz> I haven't looked at anything but the success case yet
<mdz> so I'm not sure if the mapping makes sense in the other cases
<BenC> what package creates Xorg.conf?
<ivoks> xserver-xorg
<BenC> hmm, didn't seem to create it for me
<ivoks> dpkg-reconfigure xserver-xorg
<mjg59> mdz: The failure case should probably be FAILURE, not STATUS
<mdz> mjg59: won't that print the message at the right side?
<mdz> I think log_failure_msg is used for longer messages
<mdz> like "I'm fucked because my config file is broken"
<mjg59> Oh, right, I see
<BenC> dpkg-reconfigure worked
<mdz> BenC: fresh install or upgrade?
<mjg59> Yeah. Looks good in that case.
<mdz> mjg59: looking into sysv-rc integration now
<mdz> need a way to count the number of words in a string using only posix sh without /usr
<BenC> wow, that was bad...xserver-xorg picked the vmware module for my nvidia geforce4
<mdz> hmm, though I guess we did agree that usplash would just lose if /usr was != /
<mdz> mjg59: could we have usplash print something in the text box immediately after starting up?  there's quite a delay between usplash startup and the first init script
<mjg59> mdz: can do
<mdz> mjg59: how early does it get started?  could we actually have initramfs init display progress messages to usplash?
<mjg59> At the moment it's started towards the end of initramfs
<mdz> detecting hardware, etc.
<mdz> ah
<mjg59> Probably best to talk to Jeff about whether it could be done earlier
<mdz> jbailey: ^^^
<jbailey> Where does it need to be started?
<mdz> jbailey: it would be nice if it could be started early enough to display progress info for the rest of the initramfs process, see above
<BenC> mdz: fresh install
<mdz> BenC: daily?
<BenC> mdz: well, fresh install of hoary (server), and then a dist-upgrade to breezy, and then manual install of xserver-xorg
<hmrocha> hello, i don't know if this is the right channel
<BenC> I can go back and try a fresh install of breezy daily and see if it does the same, but I suspect the xserver-xorg scripts will do the same thing
<mdz> BenC: you probably forgot to preinstall xresprobe/mdetect
<hmrocha> the group "plugdev" is the group that allows a user to mount a removable usb disk ?
<BenC> it detected the nvidia card correctly
<BenC> the name and PCI slot atleast
<mdz> BenC: you said you didn't even have a xorg.conf
<BenC> yeah, those two packages weren't installed
<BenC> so I guess that's the reason
<jbailey> mdz, mjg59: If we do it sooner, hmm.
<mdz> BenC: the .config script should print a warning in that case
<jbailey> It could be put in init-top, but I'd need to mount the /dev tmpfs sooner.  So far you'd just lose /dev/console, but that can be made by hand.
<spayne> it is about this ndiswrapper problem because i think i might know the answer
<spayne> whoops!
<mdz> mjg59: so about the progress bar
<mdz> mjg59: it looks like sysvinit makes it rather difficult for us to get the overall number of steps in advance
<mdz> since we go first to runlevel S, then someplace else, and I don't think we know "someplace else" in advance without, say, parsing inittab and /proc/cmdline and duplicating its logic
<mdz> mjg59: I've got a nice progress bar for rcS though
<mdz> I suppose we could say that the first 50% is rcS and the other 50% for whatever runlevel we end up in
<mjg59> mdz: Yeah
<jbailey> /dev/console is always c5,1 right?  /me check lanana
<mjg59> mdz: What did you want me to do about the timeout - increase it statically, or give you a command to increase it on the fly?
<mdz> mjg59: I'm not sure what the best way would be to deal with it
<mdz> ideally we shouldn't have a timeout at all, of course
<mjg59> It's easy to remove the timeout
<mdz> mjg59: how about a "PING" which says "I'm alive, please reset the timeout"
<mjg59> The reason for having it was in case something dies in init
<mjg59> mdz: That'll work already
<mdz> but doesn't print anything
<mdz> oh, ko
<mdz> ok
<mjg59> The timeout is just implemented as a select loop - sending it a command it doesn't understand will reset it
<spayne> who mantains hotplug btw?
<jbailey> spayne: There's a few of us who've hacked on it.  What do you need?
<spayne> just my ndiswrapper problem - i have discovered it is the problem of hotplug not loading the module
<jbailey> spayne: Can hotplug detect the need to load ndiswrapper?  I've never used it.
<spayne> jbailey: gernally adding a line to /etc/modules tells it to and it works
<jbailey> Right.  And it's not loading it in /etc/modules?
<jbailey> s/in/from/
<spayne> jbailey: but for some reason, when i do that, it locks on "Starting Hotplug..."
<spayne> jbailey: it is not loaded by default
<jbailey> spayne: If you modprobe it by hand does it work?
<spayne> yes
<mdz> mjg59: I suppose we should start using the -novtswitch stuff too...
<spayne> jbailey: it works no problem when doing that
<mdz> though even if we do that, the progress bar is never going to reach the top in the default configuration
<jbailey> Hmm.  module-init-tools is what should be loading everything from there, not hotplug.
<spayne> jbailey: i assume it is hotplug because when i just install ndiswrapper and create the link, the system fails on "Loading Modules.."
<spayne> jbailey: but when I add the line to /etc/modules, it fails on "Starting hotplug..."
<martinhj> jbailey: you know, I can't use lilo when I boot with a initramfs image.. works fine with a initrd image
<martinhj> jbailey: have you noticed?
<mjg59> martinhj: If you haven't filed a bug, then the answer is probably "no"
<jbailey> martinhj: When was the last time you tried?  All the lilo issues that I know about were fixed near the end of last week.
<pitti> Hi jbailey 
<jbailey> Oh, look, a screen full of yellow. =)
<jbailey> pitti: Heya Martin. =)
<spayne> jbailey: any ideas why?
<spayne> jbailey: i also compiled the newer 1.3rc1 modules and it still failed
<spayne> jbailey: which means it isn't ndiswrapper
<pitti> jbailey: shall I fix that new initramfs/udev bug or do you want to?
<jbailey> spayne: Not without doing some further tracing.  I don't know ndiswrapper at all.  When you say that you install it and it fails with "Loading Modules", that's the ndiswrapper startup script?
<martinhj> jbailey: you know, it's because of the lvm stuff.. you told me to use initramfs-tools 0.23 and it worked
<jbailey> pitti: I've got another patch for udev, so I can just as easily.  I'm going to take mdz's idea and just special case it.
<mjg59> When you modprobe ndiswrapper, it does funky stuff involving filesystem access
<pitti> jbailey: right, thanks
<pitti> jbailey: that was a hard one...
<spayne> jbailey: it must be because when i remove the device, it says "ndiswrapper failed to load the windows driver"
<jbailey> pitti: Yeah, I had gone over that stuff, and for some reason had the impression that it should be calling udevstart correctly.  Sorry for the hassle.
<jbailey> spayne: This is despite it not loading?
<martinhj> now I have tried to use both 0.23 and 0.24 to create a initramfs image but I can't use the lilo command to update the mbr
<martinhj> boot works fine
<jbailey> spayne: Or did it load once succesfully?
<spayne> jbailey: it has never loaded succesfully on the 2.6.12 kernels
<spayne> jbailey: only on the old 2.6.10 hoary ones
<jbailey> martinhj: So when it was working before, it wasn't with lilo?
<spayne> jbailey: despite it not loading, the ndiswrapper rror appears
<martinhj> jbailey: yes, but I need to boot with a initrd-image to use the lilo user space program
<mdz> mjg59: usplash integration goodness uploaded
<martinhj> when I do that, I can use initramfs images to boot just fine
<jbailey> martinhj: Oh?  Okay, so the initramfs bit is working, it's lilo that's unhappy.  Got it. =)
<mjg59> mdz: Rocking
<mdz> jbailey: I encountered #14242 on my laptop as well
<jbailey> martinhj: Can you paste me the error message in a /msg?  We'll see if it's something obviousish.
<jbailey> mdz: Were they both upgraded from Warty?
<mdz> jbailey: yes
<martinhj> jbailey: yeah sorry, I was typing before thinking makeing everything a little bit unclear:-)
<mdz> who runs packages.ubuntu.com?
<pitti> slomo: here?
<jbailey> mdz: initramfs-tools populated the /etc/initramfs/modules from /etc/initrd/modules so help make sure the system is bootable.  Warty's install used to include ide-generic in there.
<slomo> pitti: yes
<jbailey> martinhj: It's okay, I'm threading quite heavily at the moment, too. =)
<pitti> slomo: I try to make pgadmin 3 work with the wxgtk 2.6
<pitti> slomo: so far it wanted 2.5
<spayne> jbailey: is there any way of getting more detail from the output?
<pitti> slomo: "configure: error: you need to install the stc package from wxWindows/contrib/src/stc"
<pitti> slomo: however, there is no -contrib for 2.6, only for 2.4
<spayne> jbailey: if you are busy, ping me when you have a free moment we can talk
<mdz> jbailey: we should explicitly exclude ide-generic, ide-disk, ext2 and ext3 from that migration
<jbailey> mdz: Will do/
<pitti> slomo: any idea about that?
<slomo> pitti: no idea... i don't really know anything about wx ;) i just fixed something to let it compile again
<pitti> slomo: ah, ok; I just looked in the changelog :-)
<pitti> doko: do you know about wxgtk?
<pitti> Hi carstenh 
<carstenh> hi pitti 
<CarlFK> before I start filing bug reports (not even sure on what yet...) should a user be able to start/stop a modem connection to the Internet without sudo?
<jbailey> martinhj: Can you please file that in bugzilla, and assign it to me?  I don't understand why lilo would give dev-mapper ioctl errors.  Might be something crazy with using /dev/root and lvm rather than some name it knows about.
<martinhj> I don't know.. it's strange since it works if I use initrd image
<martinhj> I can try to diff the loaded modules
<jbailey> spayne: I'm just trying to think of the best way of doing this.  If you can modprobe it by hand, then it seems like it might be trying to do something special, or locking something.
<martinhj> jbailey: what do I pick to assign it to you?
<jbailey> martinhj: There's a box to put an email address in the assigned to bit.  Please put jbailey@ubuntu.com in there.
<martinhj> ok, I will
<jbailey> Thanks
<spayne> jbailey: although, when modprobing by hand, i need to insert it, modprobe and remove it about three times to get it working
<martinhj> jbailey: what package should I assign it to? lvm, lilo, something to do with mkinitramfs?
<spayne> jbailey: but i have had to do this on other distros - not just ubuntu
<jbailey> martinhj: Erm.  You ask hard questions.
<jbailey> martinhj: Make it initramfs-tools for now so that it shows up on my quick searches.
<jbailey> spayne: Have you seen http://bugzilla.ubuntu.com/show_bug.cgi?id=9942 ?  Is there a different between on battery and not?
<martinhj> jbailey: but I can't set it assigned to you email address.. I'll put it in "cc"
<spayne> jbailey: none at all
<jbailey> martinhj: 'k, thanks.  That might be one of the new permissions things that got put in.
<jbailey> spayne: Part of what I'm looking for is to match it problems that others are reporting.  ndiswrapper is common enough that I'm worried that your problem might not be generic...
<jbailey> spayne: As in, it might be specific to your laptop / card / driver / zodiac sign.
<jbailey> spayne: Since we're dealing with binary drivers there, it could be quite difficult to troubleshoot.
<mjg59> jbailey: Well, we have the source to ndiswrapper, at least
<jbailey> mjg59: Oh, I'm not giving up yet.  I'm just surprised to not get any other hits with the same problem.
<spayne> jbailey: i can imagine
<jbailey> mjg59: Want an untested initramfs that mounts /dev earlier?  You can move your usplash file to init-top instead of init-premount then.
<mjg59> jbailey: Sure, give me a moment - I'm just about to do a usplash upload
<sladen> again?
<martinhj> jbailey: it's commited
<jbailey> martinhj: Thanks.  I'll chew on it a bit more later today.
<mjg59> jbailey: Oh, one thing I meant to ask. Which was the right hook for "install this module, but don't modprobe it"?
<jbailey> manual_add_modules
<mjg59> jbailey: Ok, that's what I thought. Cool.
<jbailey> mjg59: The other one is cleverly named force_load.  I will put a HACKING file together soonish for it.
* mjg59 uploads a more attractive usplash
<jbailey> mjg59: http://people.ubuntu.com/~jbailey/initramfs-tools_0.25_all.deb
<Treenaks> mjg59: more attractive? new image? :)
<mjg59> Treenaks: Indeed
<Treenaks> whoa
<zyga> pitti: ping
<mjg59> jbailey: Heh. It might be nice to have a /dev/null at that point:)
<pitti> Hi zyga 
<Simira> anyone, what's this ubotu-bot good for?
<zyga> pitti: there are some problems with polish translations
<zyga> pitti: I'm working on resolving them on #launchpad
<zyga> pitti: short story: incorrectly tagged .po files produce corrputed stuff in rosetta
<zyga> pitti: I've written a small script that converts all latin-2 .po files to utf8 
<jbailey> mjg59: Bah. =)
<jbailey> Actually, hmm.
<pitti> zyga: can we please discuss this tomorrow? I'm about to leave
<jbailey> I don't think you have /dev/null at that point now. =)
<zyga> pitti: as carlos suggested I've downloaded language-pack and -support source packages
<zyga> pitti: okay :>
<zyga> just a short question, ok?
<zyga> what's a .poe file? they seem to be in language-support files and are identical to .po
<mjg59> jbailey: I get an error about /dev/null not existing, which seems slightly odd since I don't reference it anywhere in my script file
<jbailey> mjg59: YezBoz.
<mjg59> Oh, I guess it might be from one of the functions
<jbailey> mjg59: New 0.25 version on people.
<mjg59> jbailey: Ok, will grab in a second
<mjg59> jbailey: Hmm. Interesting. No errors, but silent usplash failure to start.
<sivang> tgall: ping again, I'm back
<mdz> there's a new one: "Ubtuntu"
<louie> 'ubuntu, but with more T'?
<azeem> louie: that's ututoe, or whatever it's called
<azeem> more t's, not more Ubuntu
<sivang> what is Ubtuntu ?
<bddebian> You mean Utnubu ?
<tgall> sivang: pong!
<mpt> "More tea?" "Please."
<sivang> tgall: yeah, at least we sync up :)
<tgall> this is true!
<tgall> sivang: do you have any idea who does "official" isos or anything ?
<sivang> tgall: I bet this is Kamion (Colin Watson)
<sivang> tgall: but he is probably away for some holiday, I think I've heared he should return on wedensday or something
<tgall> great
<tgall> be nice to see if we can start to get the ppc64 ibm support into some builds
<sivang> tgall: we should then ping him up and let him have a round on the mkisofs flags, that should get us up and running with daily builds
<sivang> tgall: yeah
<tgall> sivang, yup that'd be perfect!
<sivang> tgall: my hacking attempts on debian-cd weren't that fruitful, mdz -- do you have an exact minute to spare?
<mdz> sivang: exact?
<mdz> sivang: Ubtuntu is a misspelling of "Ubuntu" that I had not seen before
<tgall> heh .. sounds like something my 2 year old would say
<sivang> mdz: eh :) well, I was more going to ask if you know if debian-cd must have a local mirror to use, or can it use other means to produce images from?
<mdz> sivang: it needs a local mirror
<mdz> at least, I have never seen it used any other way
<sivang> mdz: ok, so then I guess deb-partialmirror is my freind
<sivang> mdz: thx
<tgall> sivang, i haven't started tring to grok debiancd ...  that's on the menu for this evening
<tgall> sivang: I gather from your comments that one either has to build all the packages that will go onto the cd local on your box or pick them up off a mirror 
<tgall> ?
<sivang> tgall: well, from my understanding you need to prepare a local mirror to use, and hack CONF.sh (That's a file in the debian-cd tree) to include the neccessary mkisofs flags.
<sivang> tgall: there's a utility that mirros the archive where you tell it, sec
<mdz> jbailey,mjg59: we need to work out a way for usplash to cause the initramfs to be generetaed when it is installed/upgraded
<spayne> why have some of the clearlooks engines been removed?
<spayne> although the new Clearlooks engine is a nice blue (better than the previous one)
<jbailey> mdz: I've tried to think about this a couple times.  The problems is that there's no promises about the users kernel.  Can we make an assumption that they'r'e going to reboot into the current kernel and that it's a Standard Ubuntu Kernel?
* jbailey hates custom kernels.
<wasab1> It should be PACKAGED
<wasab1> I think that's a reasonable assumption!
<Mithrandir> mdz: I think it's spelt "hooks". :-)
<wasab1> Can you rebuild all initramfs for all installed kernel packages?
<infinity> Yes, you can, but it's also not a very smart idea.
<mdz> jbailey: no, the process needs to be coordinated with the kernel packages
<mdz> jbailey: e.g., the kernel drops a file someplace saying "I need to be kicked when initramfs changes"
<infinity> That means that upgrading initramfs-tools or usplash could potentially render the whole system unbooteable, because all your working initrds could go away.
<jbailey> wasab1: Sure, the formula of installed kernel package to initramfs name is easy.  But breaking standby rescue kernels could be... sad.
<wasab1> Hmm.
<jbailey> BenC: ping? ^^
<wasab1> usplash should be disabled for rescue kernels then?
<mdz> jbailey: by default, we provide the vmlinuz/initrd.img symlinks
* wasab1 shrugs.
<mdz> jbailey: we should only touch that kernel
<wasab1> I'm just the penut gallary.
<jbailey> wasab1: It's not just usplash.  It's any case where someone keeps a safe kernel around.
<mjg59> wasab1: It already is
<jbailey> Ugh, there's two places in the udev init script where it checks to see if /dev is a tmpfs.  I had only caught one of them before.
<jbailey> At least that's not evidence of my insanity.
<sivang> tgall: I am going to prepare a an archive copy using  debpartial-mirror, then play with debian-cd on it (I'm preparing it now)
<tgall> sivang, hope it all works well!   I figured I'd dive into this, this evening
<sivang> tgall: Cool :) I will be able to test that only tommorow, when I'm near the machine , I will just have the repo ready :)
<infinity> Hrm.  Is a postinst that fails because the user deleted a conffile "wrong", or has the user just shot himself in the foot and all bets are off?
<sivang> tgall: tommorow means about 9 to 10 hours from now for me
<tgall> sivang, ah .. you must be in europe!
<tgall> evening for me means in about 5 hours
<sivang> tgall: mail me / add to the wiki page if you have any progress
<tgall> sivang, shall do!
<hughsie>  anyone got an asus or ibm laptop that they use /proc/acpi to change the brightness for?
<hughsie> I've written a toshiba backend for hal, but i don;t have asus or ibm hardware
<Burgundavia> hughsie, LaptopTestingTeam for contact inof
<Makako> hughsie: I have an ASUS L3800C
<Burgundavia> hughsie, those sort of things can be tested with these people --> https://wiki.ubuntu.com/LaptopTestingTeam
<sivang> tgall: great, thx
<hughsie> Burgundavia: thank, checking now
<hughsie> Makako: how do you change your brightness on your asus?
<Makako> With the keyboard. :)
<Makako> cat /proc/acpi/video/VGAC/LCD/brightness sez: <not supported>
<hughsie> Makako, what about echo "4" > /proc/acpi/asus/brn?
<Makako> works
<infinity> mdz : Dude, you forgot to bump all the binary package revisions in debian/rules in your lrm uploads.
<hughsie> sweet.
<infinity> mdz : Binary uploads are being rejected.
<hughsie> Makako, i'm adding SetLCDBrightness() to HAL
<hughsie> so we can do platform neutral adjustments
<mdz> Mithrandir: ping?
<Burgundavia> hughsie, your laptop work rocks.
<mjg59> hughsie: There's support for some Sonys, too
<mdz> Mithrandir: what's happening with #13905?
<mdz> infinity: I fucking hate that thing
<hughsie> mjg59: what module?
<mjg59> hughsie: sony_acpi
<infinity> mdz : Me too.  Shall I fix it to not require voodoo on every upload?
<hughsie> Burgundavia: thanks!
<hughsie> mjg59: thanks.
<infinity> mjg59 : Have you noticed that usplash is FTBFS?
<mjg59> Can't remember if it's mainline
<mjg59> infinity: Oh, crap. Now what?
<hughsie> mjg59: do you own such a beauty?
<Makako> hughsie: How are you achieving platform neutral support?
<mjg59> hughsie: Nope
<mdz> infinity: YES
<mjg59> hughsie: Panasonic_acpi, too
<hughsie> Makako: thru hal, and clever method support
<mdz> infinity: or at the very least it should blow up if you try to build a different source version with identical _minor
<hughsie> like power management
<hughsie> mjg59: thanks
<infinity> mdz : Yeah, I'll just fix it up the same way I fixed up apache1.3 (which used a very similar scheme... I blame Fabio..)
<Makako> hughsie: Ah, so SetLCDBrightness() does the dirty work of platform specific parameters
<hughsie> Makako, exactly, and thats the bit I'm coding now :-)
<Makako> Very nice
<infinity> mdz : It'll be a day or two down the TODO though, so you may want to just upload with bumped minors for now. :)
<hughsie> Makako: you can help if you wish
<infinity> mjg59 : usplash.c:67: error: 'logfile' undeclared (first use in this function)
<Makako> hughsie: It would be a pleasure
<mjg59> infinity: Yeah, got it
<mdz> infinity: done
<Burgundavia> hughsie, when you have some packages to test or need some feedback of any kind, use the laptop testing mailing list or #ubuntu-laptop
<hughsie> Makako: could you find (google is your friend) how we can change the brightness for acpi_sony, acpi_panasonic, acpi_ibm like this link does for asus : http://www.taupro.com/wiki/ChemBook/LCDdisplayPowerConfiguration
<hughsie> Burgundavia: I tend to send all patches to hal-devel - i'm quite a regular there
<mjg59> hughsie: It's probably worth noting that these methods tend to be flaky
<mjg59> hughsie: They don't usually work on all machines
<hughsie> mjg59: but better than /proc/acpi/video
<mjg59> Oh, yes
<hughsie> mjg59: wrapping this in HAL-foo allows the backend to change tosysfs and not impact userspace at any time
<crispin_> hughsie: I can't see any way through acpi on my IBM x31
<hughsie> (when the acpi kernel guys feel like it that is)
<hughsie> crispin_: /proc/acpi/ibm?
<crispin_> nothing in there looks like the LCD brightness
<mjg59> hughsie: ibm-acpi only has brightness control if the experimental option is passed
<hughsie> mjg59: sounds good. more ppl will clamour for that feature
<mjg59> hughsie: Oh, we have g-p-m in an almost usable state in Breezy - however, it doesn't seem to get any button events
<hughsie> mjg59: yes, i see! Are you using a new 2.6.13?
<mjg59> No
<hughsie> sometime in 2.6.12rcX they changed to using the generic hotkey that broke hal pretty bad
<mjg59> Yeah, we disable that
<hughsie> and Andrew and Linus got mad at Larry, and he changed it back
<mjg59> That's not the problem
<hughsie> does hal get the event?
<HiddenWolf> Guys, that new xorg pulls in 52 packages on a dist-upgrade. Is that ok?
<mjg59> HiddenWolf: From Hoary? Yes.
<mjg59> hughsie: What's the easiest way to tell?
<HiddenWolf> mjg59, breezy upgrade
<infinity> HiddenWolf : Yes, it's normal.
<rtcm> HiddenWolf: it's the x-base clients
<infinity> HiddenWolf : It's all the "missing" binaries coming back to xbase-clients and xutils.
<mjg59> hughsie: Well, to be fair, hal-device-manager isn't listing any ACPI devices
<HiddenWolf> ah, ok.
<mjg59> So it's presumably a hal problem
<HiddenWolf> infinity, the last batch of things broken out, or the last things missing put back in?
<hughsie> mjg59: what hal version?
<mjg59> Give me a sec, just making sure I'm on the latest
<hughsie> mjg59: hal has had *loads* of new stuff in 0.5.4
<mjg59> hughsie: It's almost certainly not 0.5.4
<mjg59> But I thought this stuff was supposed to be working ages ago?
<hughsie> mjg59: 0.5.2 should have the acpi stuff
<mjg59> 0.5.3
<hughsie> could you do me a trace of hald --daemon=no verbose=yes please
<mdz> does anyone here know about pppoe/pppoeconf?
<mdz> I haven't had to use them in years
<mdz> and there seems to be at least one problem being reported frequently
<Nafallo> I've use them, I had to debug a problem with them this past weekend.
<jbailey> mdz: Failing everything else, I think bradb's provider might still do pppoe, I could try to sync up with him for troubleshooting.
<infinity> Aww, crap.
<mjg59> hughsie: Ah, hang on - it's probably because of the missing /proc/acpi/button crap
<Nafallo> what's the problem?
<mdz> Nafallo: http://bugzilla.ubuntu.com/show_bug.cgi?id=14102
<hughsie> mjg59: yes, that's the change that Andrew went mad about
<mjg59> Yeah, we've got that rectified as well
<infinity> mdz : A mess of xbase-clients' dependencies ended up in universe (which, I suppose, is where they probably do belong, but..) and xbase-clients is either directly or indirectly a build-dep of many things in main.
<mdz> Nafallo: http://bugzilla.ubuntu.com/show_bug.cgi?id=8568
<mjg59> I'm just not running the latest kernel on this machine
* mjg59 goes to find another one
<hughsie> mjg59: okay, thanks :-)
<infinity> mdz : Do we bring all those little apps back to main (so xbase-clients, which is in main, becomes installable again), or should I spend a mess of time hunting down every xbase-client dep and replacing it with something saner?
<infinity> mdz : I assume a germinate run will just insist on promoting a bunch of stuff to main, due to xbase-clients and xutils pulling them in, which is probably the path of least resistance.
<mdz> infinity: germinating
<mdz> mjg59: no main inclusion report for irda-utils; wasn't that one of yours?
<mjg59> mdz: Oh, yes, good point
<mjg59> mdz: Give me 5 minutes?
<mdz> mjg59: sure
<mdz> mjg59: otoh, toshset has one but it isn't seeded yet
<HiddenWolf> Guys, I just noticed that grub doesn't pick up on my windows install anymore. update-grub removes it from the menu.lst even.
<mjg59> mdz: toshset is depended on by the latest acpi-support, isn't it?
<mjg59> If not, I've screwed up
<sivang> mdz: how do I tell debpartial-mirror to use breezy instead of sarge that is currently uses?
<infinity> HiddenWolf : Was it listed before or after ### END DEBIAN AUTOMAGIC KERNELS LIST
<ivoks> it removes it if it was before
<HiddenWolf> infinity, before. usually, however (read hoary) grub picked up on my windows install and added it automaticly.
<infinity> HiddenWolf : GRUB doesn't do any autodetection of Windows partition, only the installer does.  If you later accidentally move around the Windows entry in menu.lst so it's in the autogenerated area, it will go away on update-grub.
<mdz> infinity: xbase-clients deps promoted to main
<ivoks> HiddenWolf: nope, he added it after
<mdz> infinity: should be much happier after cron.daily
<infinity> mdz : Danke.
<HiddenWolf> infinity, I added it with the boot tool in the menu, which added it before the end of the automagic list. This then got overwritten.
<mdz> mjg59: not by the current version in the archive, no
<HiddenWolf> I guess I need to file a bug on whatever that boot tool is named then?
<infinity> HiddenWolf : Then the boot tool is the buggy applicatoin for adding it in the wrong place.  Fire away in bugzilla. :)
<mdz> mjg59: (0.25)
<HiddenWolf> infinity, what's the package?
<mjg59> mdz: Grah. Crap.
<infinity> HiddenWolf : dpkg -S /usr/bin/boot-admin
<mjg59> hughsie: Ok, hal finds them, but g-p-m is still doing nothing
<Nafallo> mdz: I have no clue about #14102 (I use hoary for my router), but couldn't #8568 be two default routes?
<hughsie> mjg59: what event do you get with hal? can you do lshal --monitor plz
<hughsie> and then hammer a button :-)
<Nafallo> mdz: (not that i used kubuntu though ;-))
<mjg59> hughsie: Nothing
<mjg59> But it's getting ACPI battery events
* Nafallo almost falls asleep at the keyboard
<Nafallo> night guys
<hughsie> mjg59: odd. you using acpid or plain /proc/acpi ?
<mjg59>  /proc/acpi
<hughsie> mjg59: odder
<mjg59> I disabled acpid in order to stop it interfering
<hughsie> sure, good more
<hughsie> *move
<hughsie> could you do hald --verbose plz
<hughsie> and then hammer a button
<hughsie> sounds like a hal bug
<sivang> mdz: err, sorry, I found the conffile...never mind
<mjg59> hughsie: Nothing
<hughsie> mjg59: not cool.
<hughsie> did acpid button event work?
<mjg59> hughsie: Yup
<mjg59> Just grabbing the latest package to confirm
<hughsie> mjg59: you're right, hal's ignoring the events
<mjg59> Ok, certainly not happening
<Mitario> hello
<hughsie> mjg59: do you have hal-addon-acpi running?
<ajmitch> morning
<mpt> mdz: Should the event-notifier idea described by pitti and yourself in http://lists.ubuntu.com/archives/ubuntu-devel/2005-June/008392.html become a UBZ BoF?
<mjg59> hughsie: No, it doesn't seem to have started it
<mjg59> hughsie: In fact, it doesn't appear to be installed
<HiddenWolf> mvo, your reply to 14228, what is that? a novel? ;)
<HiddenWolf> mvo, cheers mate.
<mvo> HiddenWolf: heh :) it's a tricky problem
<mvo> HiddenWolf: what do you think about it? which one of the alternatives do sound good to you?
<HiddenWolf> mvo, heh, yeah. Left me puzzled. I was about to start downloading a hoary kernel for my breezy upgrade. ;)
<HiddenWolf> I'd say put it in a package, and get that package into warty/hoary as well, just to make sure. But I'm not the expert, just the guy that ran into it and knew where to file a report.
<infinity> No reason to bring the package back to older releases.
<infinity> If ubuntu-desktop depends on it, you're good to go.
<mvo> having a package does not feel right, but it would be a solution that works now(tm)
<infinity> mvo : Well, the other option is just to smack all the default sources.list lines for breezy on the bottom of the existing file, so they now have both hoary and breezy (and can disable hoary on their own)... Ick.
<infinity> Of course, you sitll need something to do that work.
<mvo> infinity: yes, if we do that too often mmap will complain loudly ;)
<infinity> :)
<infinity> The default limit now is pretty huge.
<infinity> I run with a sources.list that's unreasonably large at times.
<mvo> i can easily kill it with tranlated package descriptions
<HiddenWolf> Oh, and guys. I just got kicked out of usplash (albeit old version) when fsck decided it needed to check my /home. Nearly gave me a heart-attack. :P
<hughsie> mjg59: phone, sorry
<mvo> but yes, the limit is good otherwise :)
<infinity> HiddenWolf : usplash has a timeout where it drops to the console if it hasn't seen any input for a while.
<mjg59> HiddenWolf: Yeah, that could be improved
<HiddenWolf> I was just pionting out the heart-attack factor. 
<sivang> does anyone know if we have a baz version of debpartial-mirror that's used for Ubuntu somewhere?
<mjg59> mdz: Ok, added
<HiddenWolf> I'd say in this case, you should have usplash print a message "we're checking to see if the disc is ok, this might take a _long_ time"  - the checking filesystem message it displays now is rather unfriendly. :P
<sivang> (the installable package is configured to use sarge, and when modified just stops after fetching Packags.gz files)
<mvo> mdz: do you have a opinion on #14228 (I tossed around some ideas)? 
<infinity> sivang : Try debmirror, it sucks (a little) less.
<infinity> sivang : Or, if you just want to exclude some architectures, try this script, wiht appropriate values filled in:
<infinity> sivang : http://www.us.debian.org/mirrors/anonftpsync
<sivang> infinity: yes, I want to grab the main ppc64 archive
<infinity> sivang : powerpc, you mean.  There is no ppc64. :)
<sivang> infinity: ah right :)
<sivang> infinity: also to change fetching code to suit ubuntu, I use http://archive.ubuntu.com/dist/breezy ?
<infinity> You missed an ubuntu in that URL.
<sivang> infinity: sorry, that is http://archive.ubuntu.com/ubuntu/dists/breezy/
<infinity> Basically, if you're modifying debian mirror scripts, s/debian/ubuntu/ should be enough to get you where you want to be.
<sivang> infinity: that holds for debmirror *and* anonftpsync ?
<mjg59> mdz: And new acpi-support fixes the toshset depends
<sivang> infinity: thx so far :)
<infinity> Our archive layouts are identical ({ubuntu,debian}/{pool,dists}), we just have different compnent names (which most mirror scripts don't take into account unless you specifically specify components) and different dists (same argument)
<infinity> specifically specify?... Yay redundancy.
<sivang> infinity: lol, say, what does --root signifies?
<sivang> (Won't mirror without dists/breezy/main/binary-powerpc/Packages.gz signature in Release at /usr/bin/debmirror line 1174.)
<sivang> I guessed this error has something to do with that argument. probably wrong
<infinity> sivang : debmirror /path/to/mirror -h archive.ubuntu.com -r /ubuntu -d breezy -a powerpc
<infinity> (Add "-s main" to that if you don't want universe, which you probably don't, cause it's HUGE)
<mdz> mvo: I think the upgrade-via-CD system needs more discussion
<mdz> mvo: we need to decide exactly what it should mean to "upgrade"
<mdz> I feel like we need a higher level preference file
<mdz> sources.list is too random
<sivang> infinity: gee thanks, now I see that I invoked it completely differnt
<infinity> You could just dump everything in sources.list and prefer a dist with a pin.  <shudder>
<infinity> Not intuitive for users to diagnose when it goes horribly wrong.
<sivang> infinity: err, keep getting the previous error - am I missing a signed key for the archive?
<mvo> I get a bunch of conffile questions on my upgrade, about random files in /etc/X11/app-defaults. is this a known issue?
<infinity> mvo : Yes.
<mvo> infinity: thanks
<infinity> mvo : It's because the apps went away for a while and then came back.  Should be a nonissue for hoary->breezy upgrades, where the conffiles will just be migrating between packages.
<mvo> infinity: ah, it's that dpkg bug 
<JanC> WTF, Mandriva releases a security update of python because of a bug in _pcre_ ?
<sivang> infinity: anyway, I'm out (gotta get some sleep for today) I am awaying my client, so just msg me or something and I'll catch that in the morning
<JanC> python doesn't use pcre AFAIK ?
<infinity> mvo : Not a bug, really.
<infinity> mvo : Oh, well, I guess one part of it may be a bug.  <ponders>... Anyhow, it's worked around in the release->release upgrade case, and we'll double-check that.
#ubuntu-devel 2005-09-04
<hughsie> mjg59: sorry, off the phone now
<mjg59> hughsie: No problem
<mjg59> hughsie: I have an irritating feeling that hald-acpi-addon is just not being installed into the package
<hughsie> mjg59: maybe. Mine isn;t being run too, and that's with CVS
<mjg59> Well, the Debian hal binary package doesn't have it in
<mjg59> Whereas it's certainly built
<infinity> sivang : Add "-s main"... It's looking for debian-style components (non-free, contrib) otherwise.
<mjg59> Oh, no, I'm being stupid - it's built and installed
<mjg59> I just can't spell "addon"
<hughsie> mjg59: heh
<mjg59> hughsie: Ok, so hal bug
<hughsie> mjg59: yeh, just chasing
<hughsie> mjg59: it runs, but exits. not cool.
<mdz> mjg59: toshset is root-only, right?  no setuid madness or anything?
<mjg59> mdz: It just needs write access to the device node, so yeah
<mjg59> Usplash suddenly looks sexy
<mdz> mjg59: I'm not sure why the module-init-tools message is broken
<mjg59> mdz: Which one?
<mdz> mjg59: I get "Loading modules..." in green hanging off the right side of the text box
<mjg59> Oh, right
<mjg59> Because it's too long, and stuff over there never gets blanked
<mjg59> Possibly there should be some magic linebreaking support
<mdz> mjg59: no, I also see "TEXT" flash by
<mjg59> mdz: Ah - which version of usplash?
<mdz> mjg59: 0.1-4
<mjg59> mdz: Fixed that today
<mdz>             usplash_write "TEXT $@" || true
<mdz> ah
<mjg59> It was happening when multiple writes went by before usplash was scheduled
<mdz> oh, good, X doesn't start on my laptop anymore
<mjg59> Grab the new one and watch the enhanced prettiness
<mdz> doing it
<mdz> SEXY
<mjg59> Oh yes
<mdz> I get a colored band on the left side of the screen; is that intentional?
<mjg59> Uhm. Mm?
<mjg59> No, that shouldn't be happening
<mdz> it's about the color of the "ubuntu" text
<mdz> light brown
<mjg59> Weird
<mjg59> Uhm
<mdz> I don't think it was happening, before, but it would ahve been hard to tell with the old background
<mjg59> Yeah
<mjg59> Let me take a look here
<mjg59> No, I don't get that here
<mjg59> I'll add linebreak support to deal with the longer lines
<mdz> mjg59: would a photo help?
<mjg59> mdz: Sure, why not?
<mdz> oh, hmm, I think I see what it is
<mdz> I think it's a monitor adjustment problem
<mjg59> Then we just need it to be started earlier in initramfs
<mdz> we should definitely do that
<mdz> and modify initramfs to kill it if it drops to a shell
<mjg59> Yeah
<mdz> maybe jbailey can add a hook for that
<mdz> ok, after readjusting my monitor it looks sweet again
<mjg59> Just add it to the panic code
<mjg59> Is Mark still at akadamy?
<mdz> dunno
<mjg59> He seems to be missing out on the sexiness
<mdz> what are we going to do about usplash artwork for kubuntu?
<mdz> we should probably move the artwork out into ubuntu-artwork
<mjg59> Hrm. Good question.
<mjg59> jdub: We can still use another couple of colours in the artwork, if that'd help
<mdz> mjg59: can we get anti-aliased fonts?
<mjg59> mdz: Nngh.
<mjg59> mdz: Not easily. We can probably get a more attractive one, though
<mjg59> We can use any bdf font
<mjg59> Anti-aliasing would require someone to write support for it in bogl
<mjg59> (ie, not me)
<jbailey> mdz, mjg59: Dropping to a shell is already handled by a 'panic' function.
<jbailey> So that part is easy.
<jbailey> mjg59: Did you get usplash working in the init-top hook on that 0.25 I posted?
<mdz> mjg59: could we choose a font with anti-aliasing built into it?  are the fonts grayscale?
<mjg59> jbailey: Nope. Not sure what's up there.
<mjg59> mdz: They're bitmap fonts
<mjg59> I'm not sure if they're greyscale or not
<mdz> mjg59: bitmap fonts can have anti-aliasing if they're grayscale
<jbailey> mjg59: That's before any modules have been loaded at all.
<mdz> we need to make hotplug faster
<HiddenWolf> mdz s/hotplug/ubuntu
<mdz> mjg59: the "ok" isn't green anymore
<mdz> HiddenWolf: no, actually I meant what I wrote
<mdz> mjg59: also, ARGH TOSHSET BAD
<mdz> mjg59: it displays some blaring warning about how it's useless on ACPI-enabled kernels
<mdz> mjg59: which is sort of unfriendly considering that our default kernels are ACPI-enabled
<HiddenWolf> mdz, lol, I was just about to mention that.
<mjg59> mdThe green is removed, yeah. Jeff wasn't keen on it - it makes things visually noisier for no especially good reason
<mjg59> mdz: Oh, crap. I'll hack that out.
<mjg59> It's entirely wrong.
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<mjg59> mdz: BDF appears to be b&w
<mdz> mjg59: is there a baz repository for acpi-support, or is the source tarball it?
<mjg59> mdz: http://people.debian.org/~mjg59/acpi-support
<mjg59> It's bzr rather than baz
<mdz> mjg59: ok, I'll send you merge requests rather than uploading it in the future
<mjg59> mdz: No problem
<mjg59> mdz: There's a usplash one there as well
<mdz> mjg59: I just uploading acpi-support to fix its log_begin_msg
<mdz> s/ing/ed/
<mjg59> mdz: Cool, thanks
<mjg59> mdz: Could you possibly send me a diff?
<mdz> mjg59: done
<mdz> it's a one-liner
<mjg59> mdz: Ta
<CarlFK_> should a user be able to connect/disconnect a dialup ISP connection?  (sorry if this was answered, my connection is bouncing)
<mjg59> CarlFK_: Using gnome-modem-applet, yeah
<mjg59> Though it requires them to have sudo
<CarlFK_> mjg59 - ok - I was thinking the sudo thing was bug
<sebest_> is the icon next to update-notified notification a bulb?
<mjg59> sebest_: Yeah. It's to tell you that you have a message related to an update.
<sebest_> mjg59, thanx, but i mean the notification from notify-daemon
<CarlFK_> mjg59 - do you know of any "official" like docs besides: https://wiki.ubuntu.com/DialupModemHowto and https://wiki.ubuntu.com/DialUpSupport ?
<mjg59> CarlFK_: Nope
<sebest_> because i'm using the dbus api of notify-daemon on breezy and i can't set another icons other than the default bulb, so i wanted to know if update-notifier was able to do this
<CarlFK_> I am having trouble beliving noone is bothered by needing sudo to make a dialup connection
<mjg59> Oh, right, I see what you mean
<mjg59> No idea
<mjg59> CarlFK_: Either it needs sudo, or it means that any user can override the default routing
<infinity> CarlFK : Is it required even if you're in the dip group?
<mjg59> infinity: Yes
<infinity> Err, dialout.
<carstenh> CarlFK_: never used dialup with ubuntu, but in debian you have to be in the group dip to be allowed to start a dialup connection as ordinary user
<mjg59> infinity: It launches pppd directly, rather than using pon or poff
<infinity> mjg59 : Oh, yes, that would requite root.
<infinity> require, too.
<infinity> Oh, for the love of...
<CarlFK_> system, users and groups, user privs: "user can connect to the net using a modem" - shouldn't that remove the sudo requirement?
<infinity> mjg59 : Why are we promoting things to main that are unbuildable? (toshset)
<infinity> mjg59 : Doesn't build with g++4.0, the binary in the archive is still the one from hoary compiled with g++-3.3
<mjg59> infinity: Because it provides necessary functionality
<infinity> mjg59 : Could we fix it to build? :)
<infinity> mjg59 : It's unsupportable ATM, since it doesn't build with build-essential.
<mjg59> CarlFK_: The mechanism used for connecting to the net via dialup requires root
<mjg59> There's a good argument for providing a suid wrapper that's only executable by a subset of users
<mjg59> But someone would need to implement that
<infinity> mjg59 : Ahh, there's a patch in the Debian BTS to make it build.
<mjg59> infinity: Excellent
<whiprush> infinity: kudos dude, you're a machine.
<infinity> mjg59 : I'll upload a fix and stop bugging you.
<mjg59> infinity: Thanks! :)
<infinity> Actually, I'll cheat and fake a sync of 1.69-2
<infinity> No one look.
<mjg59> Haha
<CarlFK_> mjg59 - so what does that "user priv: can connect..." option govern?
<mjg59> CarlFK_: Sorry, I dropped off. Which bit are you referring to?
<CarlFK_> system, users and groups, user privs: "user can connect to the net using a modem" - shouldn't that remove the sudo requirement?
<CarlFK_> it is a checkbox in the user admin gui
<mjg59> That refers to the pon/poff mechanism, not the one used by gnome-modem-applet
<CarlFK_> ah, so if that is checked, they can use pon from a prompt? 
<mjg59> They ought to be able to
<infinity> On second though, we should just sync 1.70-1
<infinity> mdz : Still around?
<ajmitch> yay, more x breakage, using ls in /var/lib/dpkg/info sometimes isn't good
<infinity> whiprush : Which machinery are you referring to?... The cairo/glitz stuff?
<whiprush> infinity: yeah, you've been rebuilding stuff for what ... 7+ some days now?
<whiprush> including the weekends.
<infinity> whiprush : The only packages left to transition are oregano (needs to be updated for the new cairo API), fdclock (same), network-manager (out of sync with DBUS APIs), and gcc-snapshot (waiting on doko to roll a new CVS snap)... Everything else is fixed now.
<ajmitch> infinity: great, you're making the MOTUs redundant :)
<whiprush> I was just noting your inhuman stamina.
<infinity> ajmitch : No, you guys getr to hunt down every FTBFS I leave in my dust.  Thpt. :)
<infinity> ajmitch : oregano being a fine example.  I have no urge to fix it. :)
<ajmitch> infinity: that's the fun part
<ajmitch> it's on my fixit list
<infinity> ajmitch : Don't worry about fdclock, daniels will update it from freedesktop CVS.
<infinity> ajmitch : cworth has already committed the required fixes.
<slomo> infinity: i already have... i only need someone to upload ;)
<ajmitch> oregano will probably be a new upstream version to fix it
<infinity> slomo : Oh, you already pulled cworth's fixes?
<slomo> infinity: sure
<ajmitch> assuming I'm allowed 
<infinity> slono : Cool.  Then find someone to upload for you.  I don't think daniels is overly protective of his clock. :)
<slomo> infinity: ok, i'll try :) but when you want to take a look: http://revu.tauware.de/details.py?upid=509
<infinity> mjg59 : You should probbaly just request a sync of toshset 1.70-1 from Debian.  The only thing in the diff is the gcc-4.0 fixes, a manpage typo correction, and an added ID for another Toshiba laptop.
<infinity> mjg59 : I can't see anyone disallowing a UVF exception on that.
<mjg59> infinity: Ok
* infinity seriously considers a nap, now that his hacking cough that was keeping him up all night has subsided.
<mdz> infinity: yes
<infinity> mdz : See above.  Permission to break UVF for toshset for gcc-4.0 fixes, a manpage correction, and one added device ID?
<infinity> mdz : That's the entirety of the diff.
<mdz> infinity: yes
<infinity> mdz : Danke.
<infinity> elmo : Please sync toshset 1.70-1 from Debian, permission granted by mdz for UVF exception.
* infinity ponders this python-gtk segv...
<mdz> infinity: have you foregone your native timezone entirely?
<infinity> No, I'm still awake. :)
<infinity> The nap option is sounding good, but I may force myself to stay up.
<infinity> I got a cold over the weekend, and was up all night coughing.
<infinity> Figure I may as well work, since I couldn't sleep.
<mdz> mjg59: still around?
<mdz> elmo: my word, cron.daily is a lot faster now
<mjg59> mdz: Hi
<mdz> mjg59: wanted to talk about usplash and casper
<mdz> mjg59: can't remember if you answered this already or not
<mdz> do I need to mess with any kernel modules, or can i just start usplash with the framebuffer set up by d-i?
<mjg59> Assuming that d-i on the livecd loads vga16, that'll be fine
<mdz> it does
<mdz> I'm not sure it loads the other stuff that the initramfs usplash script does, though
<mjg59> If it modprobes it, it'll be fine
<mjg59> It insmods stuff by hand due to issues with modprobe at that point of initramfs
<mjg59> (haven't tracked that down yet)
<mdz> infinity: so long as you've given up on sleep, can you tell me why pppconfig didn't build?
<mdz> mjg59: ah, splendid
<jbailey> mjg59: I think most of the need for that  is probably gone now.  There've been a few bugs fixed where it was spuriously adding .ko, or where it was losing modules on the way.
<infinity> mdz : Uhh, cause it's not in wanna-build?
<infinity> mdz : Which usually means it's arch:all (probably is), and is currently installed.
<mdz> infinity: interesting; it's been a cron.daily since I uploaded it, and it's in Sources
<mdz> 2.3.11ubuntu2
<mdz> mjg59: so the only sticking point in usplash-for-casper is that udev will mount over /dev
<_derek> mdz: thanks for the comment/reassigning of bug 14120
<mdz> I suppose I could do what initramfs does, and move the mount over
<mdz> but that's more intrusive than I'd like
<mjg59> mdz: Hmm
<mjg59> mdz: Hrm.
<mdz> I could invoke /etc/init.d/udev early, I guess
<mjg59> There's not really a good way around that
<mjg59> Basically, we need a fifo that'll be there from the point usplash is started until you finish writing to it
<infinity> mdz : Hrm.  I don't see it in any logs on the i386 buildds... And it's not reigstered in w-b... Either it's waiting on another cron.daily to right itself, or something's very confused.
<mdz> I think running /etc/init.d/udev start before usplash would be ok
<mdz> infinity: we'll find out in a few minutes, then
<mdz> much usplash love landed in the last cron.daily
<infinity> Indeed.  How fast is daily now?
<mdz> infinity: it was finished at :11
<infinity> Not bad.
<mdz> s/at/before/
<mdz> I'm not really sure; I just loaded up my "wait-for-cron.daily" finger macros and discovered it wasn't running
<infinity> That's a sign that we need to run it every 15 minutes instead.
<mdz> I don't think elmo has fully recovered from the 24h->30m transition yet
<infinity> Hrm.
<infinity> mdz : I wonder if the jackass switchover may have goofed something with the hack used for arch:all building.
<infinity> mdz : Still not listed in wanna-build.  I'll kick it manually, but remind me to poke elmo about it.
<infinity> mdz : Uploaded.
<jdub> mjg59: yeah, have two spare on that image
<mdz> infinity: thanks, remember to poke elmo about it
<jdub> mjg59: but it looks terrible when i use it with usplash
<infinity> :)
<jdub> jbailey: ahr?
<jbailey> jdub: Are you a pirate now? 
<jdub> i am a pirate MAN
<bddebian> heh
<jdub> actually, i lie
<jdub> i am a pirate ANDROID
<jbailey> He is a pirate, horror!
* jbailey breaks into "modern major general"
<jdub> i am not a pirate horror
<jdub> though i can put on a horror face
<jdub> anyway
<jdub> you were in #grub
<jbailey> jdub: You'd better on Hallowe'en. =)
<bddebian> Uhm
<jbailey> jdub: stalker
<jdub> that means i'm going to ask you my hard question about grub
<zul> yarrgh
<jbailey> jdub: Alright.  But I'm best suited to answer questions about grub2 on powerpc. =)
<jbailey> jdub: And I occasionally help  the guy who's porting it to Sparc. 
<jdub> bum
<jdub> well, this is general
<jbailey> a'ight
<jdub> you know that "i am about to do the following..." spew after the item is selected in grub?
<jdub> it clears the screen, says, "Booting Pirate OS..."
<jbailey> Yup
<jdub> and then blah blah smeg irrelevant blather YELL YELL BIFF THWACK
<jbailey> Mhm
<jdub> can we get rid of that? :-)
<jdub> like, if quiet is in the boot line, never show it?
<jbailey> Umm,...  Parsing the kernel command line seems like the wrong way to determine that.
<jbailey> How about if the menu wasn't shown or somethign ilke that?
<jdub> well, it could be an option for each stanza
<jdub> even if the menu was shown, i'd far prefer to see
<jdub> grub menu -> pause -> usplash
<jdub> instead of
<jdub> grub menu ->
<jdub> booting your os now ->
<jdub> grub process spew ->
<jdub> uncompressing your os now ->
<jdub> audit 9823749823487 ->
<jdub> usplash
<jdub> :-)
<jbailey> I already asked benc and them about the audit line.
<jdub> the other distros that have evil bootsplash-in-kernel
<jdub> only show a flash of the yucky output
<jdub> but they are evil
<mjg59> jdub: Mm?
<mjg59> jdub: Have you tried the usplash I uploaded today?
<jdub> oh, no
<jdub> i tried putting it in myself and it looked like baby spew after fingerpainting class
<mjg59> Yeah
<mjg59> There was a tiny bit of code hacking needed
<jbailey> jdub: So you want basically another command in there "stfu" or something like that to silence everything from the menu name to "booting your kernel" right?
* jdub updates mirror
<mjg59> apt-get install usplash lsb-base and then regenerate your initrd
<jdub> jbailey: that'd be elite
<jdub> mjg59: woohoo :-)
<jbailey> jdub: If I do this, will I get beaten by the mdz feature freeze stick of doom?
<mjg59> jdub: Do it. POP THE TRUNK.
<jdub> jbailey: it's totally a bug fix man
<whiprush> trunk monkey!
<mjg59> We can hack grub to get rid of its output, and we can trivially fix the kernel to get rid of that fucking "initialising audit" crap
<jbailey> Mhm.  
<jbailey> jdub: Do I get a bug number that I can close so that we keep this fiction going? =)
<jdub> i think there is a bug in there somewhere about it, actually
<mjg59> jdub: How long until you get to test usplash?
<mjg59> I don't want to miss your reaction
<jdub> well
<jdub> there has been an OOo2 update
<jdub> ;-)
<mjg59> Oh man
<mjg59> And you're in bandwidth hell
<jdub> not so much these days
<jdub> 1.5MB down
* jbailey pats his bandwidth.
<mjg59> Hmm. Better than me at the moment.
<mjg59> That was bizarre.
* bddebian does too
<jdub> mjg59: well, that's 1.5MB within the country
<mjg59> Haha
<jdub> ;-)
<mjg59> The TV suddenly said "Just do it, DO IT"
<mdz> mjg59: usplashoriffic casper uploaded
<infinity> Hrm, casper is arch:all too.
<infinity> Guess we get to see if your ppconfig issue was an isolated incident.
<mdz> indeed
<mdz> at least, those of us who are still awake will
<mjg59> mdz: Indescribable rock
<mjg59> I need to sort the PPC usplash at some stage
<mjg59> There's very little that needs to be done
<mjg59> But someone needs to write a bogl_move routine for non-vga16 framebuffers
<infinity> I'm still awake, technically.
<mdz> infinity: but I hope not for much longer
* jdub growls at feenode irc spam
<infinity> I'm somewhere between "I should try to stay up all day, so I don't end up backawards" and "oh god, just let me die right now"
<mdz> mjg59: the casper stuff is somewhat academic at this point because we have like a minute of (partly interactive) d-i spew before we can start it up, but it will make silbs happy
<infinity> The latter's likely to win at any moment.
<mjg59> mdz: Yeah
<infinity> But not until I get casper for you.
<mjg59> mdz: There's no way to tie it into d-i?
<mdz> mjg59: for breezy+1 I think I am going to ditch d-i for the live CD
<mjg59> Ok
<mdz> and just have a simple initramfs
<jdub> mdz, mjg59: so how easy will it be to brand usplash on the livecd?
<jdub> mdz: ooh!
<mdz> jdub: same as branding it anywhere else
<jdub> mdz: 'cept it's totally pre-cloop pain
<mjg59> jdub: Is requiring a package rebuild ok?
<jdub> mjg59: that's not so bad
<jdub> but it will also mean putting a new initrd on the non-cloop bit
<mjg59> Hmm. Yes.
<mdz> jdub: all it needs to do is load enough kernel stuff to find the CD-ROM and mount the cloop; casper can do everything else from inside there
<jdub> mjg59: this is the bit that will make people scared a bit
<mjg59> jdub: If it's going to be started in the initramfs, there's no obvious way around having the picture in the initramfs
<jdub> mmm
<Lathiat> oh no
<Lathiat> the sptial mode discussion has errupted again
<HrdwrBoB> spatial mode, home as desktop is winner for me
<wasabi> I'd be for home as desktop if home didn't traditionally have other stuff.
<jdub> Lathiat: whereabouts?
<jdub> oh
<jdub> that's just murray
<mjg59> jdub: Well, he's got something of a point
<mjg59> In three releases, we've shipped three different defaults
<mjg59> And only one of them has matched upstream's
<Lathiat> the new tree thing brings up a new point
<wasabi> Oh geeze. Just as I get used to explaining to all my friends why spatial is better, and start to get some converts.
<Lathiat> persoanlly, i like browse mode, but thats just me
<wasabi> I just "got used" to spatial.
<jdub> mjg59: and this one is the right one, which we should've done last time (modulo browser improvements)
<jdub> mjg59: his point about spatial is irrelevant
<jdub> and wrong
<mjg59> jdub: I think this version is better than Hoary's. I'm pretty sure you argued in favour of spatial for Warty :)
<wasabi> It's funny to see everybody run to the other side of the room.
<jdub> mjg59: nup
<jdub> mjg59: i wasn't fully committed (because browse mode sucked back then), but i did push for browse
<infinity> I like whatever mode shuts the most people up, because my file browser is gnome-terminal, cd, and ls.
<mjg59> jdub: Ok, fair enough
<jdub> mjg59: i've always loved spatial as a feature, but it punches real users in the face
<wasabi> Define "real users".
<jdub> people who don't like technology for technology's sake, who use the computer to get their job done,  not for the sake of using their computer
<mjg59> To be honest, I'm happy with either (I grew up with an OS that used something similar to spatial). The fact that we *keep changing* sucks.
<mjg59> If there's a commitment to staying with browser mode in future, then fine
<jdub> mjg59: sabdfl welcomes your blame :)
<mdz> infinity: if you need to kick casper, make sure you get 1.9 (not 1.8)
<Lathiat> haha
<mjg59> It's not necessarily the mode I'll use, but I don't think it's a default people would be unhappy with
<wasabi> Odd. All "real users" i've given spatial too... those who weren't proficcient in any previous OS, got their work done fine.
<mjg59> wasabi: People will get their work done fine in either mode
<wasabi> Yeah.
<wasabi> I guess.
<jdub> "What are all these windows all over my screen?"
<jdub> that is why spatial is a cool feature for geeks, but is irrelevant for real users
<wasabi> Hey, I still have the opinion I had back when spatial was first introduced. I think it is BETTER for complete novices with no computer experience. Weither that is "real users" or not, i dunno.
<HrdwrBoB> my inlaws use spatial
<HrdwrBoB> they don't even notice
<wasabi> My MOM uses it.
<HrdwrBoB> all they said was the computer seems faster since I put ubuntu on it
<wasabi> Doesn't even know what the back button in a browser really does, though.
<mdz> infinity: cron.daily finished in <4 minutes
<mdz> this new box rocks
<mdz> infinity: oh, it's a dual opteron with a decent raid card now.  no wonder.
<Lathiat> haha
<jbailey> Just saw the new usplash.  Purty. =)
<Lathiat> ssh dont spoil it :)
<jdub> for what it's worth, i replied to the original mail
<infinity> mdz : Meh.  Same problem.  Needs a manual shove.  I'll be sure to deliver a WTF to elmo aboiut it when our timezones match again.
<tgall_foo> evening jdub 
<mdz> infinity: how about sending an email?
<mjg59> My AUNT TILLIE thinks that browser mode is worse than paedophiles
<infinity> mdz : Well, yes, that works too. :)  Give me a break, I'm dead on my feet. :)
<jdub> yo tgall_foo 
<mdz> infinity: you need to sleep more
<mdz> infinity: we'll need you in top shape for preview week
<mdz> ...which is next week
<jbailey> infinity: So go exercise.
<infinity> mdz : Mailed.
<infinity> mdz : casper uploaded, I'm off to nap.
<mjg59> Oh christ we're releasing preview next week?
<martinald> hi
<martinald> is there any movement on bugs 11237 and/or 13521
<jbailey> martinald: No.  I don't think there's anythign I can do under 11237 is done.
<jbailey> martinald: Well, I'm going to look at hwdetect
<jbailey> See if I can force load them, but in general the answer to your question is 'no'
<mdz> martinald: generally, when the status of a bug changes, it is updated in bugzilla.  so there's no need to ask about bugs here; just add yourself to the CC list in bugzilla.
<lifeless> mdz: so for me to upload stuff to ubuntu .. I've signed the Coc, and am a DD now.
<lifeless> mdz: what next ?
<mdz> lifeless: apply to become a maintainer
<lifeless> ok
<mdz> lifeless: http://www.ubuntulinux.org/community/participate#code
<lifeless> mdz: so, care to suggest a mentor, or do I grab one at random ? 
<mdz> lifeless: feel free to ask someone you know; you know enough ubuntu devlopers I expect ;-)
<lifeless> ;)
<mdz> lifeless: otherwise, #ubuntu-motu
<lifeless> I'll ask keybuk
<lifeless> what is meant by 'substantial' - its used a lot in the process documentation ...
<mdz> depends on context
<lifeless> other than being upstream for several packages, and being package maintainer for bicycle-repair, I'm not sure what stuff I can claim as being direct contributions to /Ubuntu/
<ajmitch> lifeless: help out the MOTUs, please :)
<lifeless> 'becoming a maintainer'
<lifeless> ^^ the context
<mdz> substantial in the case of contributions to ubuntu means actual, concrete, observable work done on the distribution
<mdz> of a significant magnitude
<jdub> mdz: he maintains our revision control system? :)
<mdz> jdub: the one that isn't used for ubuntu development yet? ;-P
<jdub> :-)
<jdub> details
<lifeless> I guess I'm concerned that I won't be able to deliver that level of work in my spare time - as I definately won't be doing it during work.
<jdub> i hear pitti uses it
<jdub> ;-)
<mdz> pitti uses bzr
<mdz> ;-)
<lifeless> mdz: which I am full time on ;0
<Lathiat> lifeless: ah you moved from baz?
<mdz> I'm not trying to be difficult, but we can't offer maintainership to anyone based solely on being upstream for a package in Ubuntu
<lifeless> baz is in maintenance mode
<Lathiat> i tried bzr out yesterday with ajmitch, and we synced our repos over ipv6 :) woot.
<lifeless> mdz: I know. I'm going down this path because you suggested someone in my team should do that so we can upload our own baz/etc packages.
<mdz> lifeless: do you maintain the debian/* for baz?
<lifeless> mdz: I maintain the master copy for it in baz itself, but bob2 has been the guy tweaking that for debian.
<mdz> since we use that verbatim, that'd be qualifying work
<jdub> Lathiat: OVER IPV6! THE FUTURE!
<lifeless> I maintain bicycle-repair's debian package, which you also use verbatim.
<Lathiat> jdub: YES!
<Lathiat> so we coudl sync to our laptops on remote networks directly :)
<jbailey> Lathiat: Ah, he hadn't said who that was with.
<Lathiat> and im advertising my repository over mDNS/DNS-SD nto that its much use to anyone ;p
<jdub> mdz: btw, j^ is going the motu route for n-m in universe
<Lathiat> jdub: rock
<whiprush> oh dudes, 3 laptops today with j^'s packages
<whiprush> nothing but nice.
<jdub> Lathiat: mpool would be keen to get dns-sd support into bzr :)
<jdub> whiprush: UNPLUG!
<jdub> *sha-wing!*
<jdub> REPLUG!
<jdub> *sha-wing!*
<whiprush> he's even got the vpnc thing going on
<whiprush> unfortunatly I can't test that
<Lathiat> yeh if only my unis network worked with vpnc :(
<jdub> whiprush: "stargazing: cool stuff in the ubuntu universe" as a pre-breezy article
<whiprush> jdub: just tell me what to do.
<Lathiat> i ethereald it, it seems to send th esame packet type, i'll have to figure out whats different
<lu|away> where are j^'s packages?
<whiprush> I can do that + my 10x10 idea
<jdub> ## j^'s NetworkManager
<jdub> deb http://bootlab.org/~j/NetworkManager-breezy/ ./
<whiprush> good?
* lu|away can't risk having the network go down right now, but maybe later
<lifeless> mdz: so - baz's packaging, bicycle-repair's packaging are two packages. 
<jdub> rock on :)
<jdub> whiprush: even just a list of cool stuff in universe would be a good start
<whiprush> give me a day or two.
<Lathiat> now i just need to find ross
<whiprush> lu|away: it has a startup script thing and everything
<whiprush> you just install, and go.
<lu|away> whiprush: well, so, typically with NM I install, and 3-5 minutes later my kernel hangs
<whiprush> it does the Right Thing inbetween suspends too
<lu|away> so until my fantasy football draft is complete I can't risk it. :)
<whiprush> what wifi card?
<jdub> lu|away: what network cards do you have?
<lu|away> atheros
<whiprush> same problem
<whiprush> until the other day
<jdub> oh.
<lu|away> whiprush: ?
<whiprush> the latest l-r-m has no problems for me
<whiprush> that used to happen to me
<whiprush> random lockups when scanning
<lu|away> nice.
<whiprush> or doing wifi-type stuff
<jdub> yeah, it'll be up and down, just due to the combination of prop driver and n-m support for its breakages
<wasab1> Hmm. jbailey, a week ago 2.5.12 was not putting evms support into the initramfs, did you ever hear about that?
<wasab1> 2.6.12.
<whiprush> latest updates should do the trick
<lu|away> well, right, though other network management tools don't hurt atheros quite so bad as to hurt my kernel
<whiprush> I feel your pain, I was close to buying a new card 
<lu|away> but yeah, I'm glad to hear things have gotten worked around or whatever
<lu|away> that is quite awesome
<jdub> quick guide:
<jdub> install n-m
<jdub> remove /etc/rc*.d/*bind*
<jdub> restart dbus
<wasab1> bah.
<jdub> start nm-applet
<whiprush> hmmm, I didn't have to mangle bind or dbus
<jdub> you can't run two binds at the same time :)
<jdub> and n-m really wants to be on the system dbus
<whiprush> well, I'm pretty sure most people won't have a bind running alreadt
* wasab1 raises hands.
<jbailey> wasab1: Yes, I know abaout that.
* lifeless thinks he chased mdz away :[
<jdub> whiprush: when you reboot, and the bind startup scripts run bind, then you do :)
<jbailey> wasab1: Do you do evms?  Will you be a guinea pig? =)
<wasab1> jbailey: yes and sured.
<jbailey> wasab1: Lovely!
<mdz> lifeless: I have a ton of work to do; was there a question in there?
<whiprush> jdub: saw your posts about that earlier, I've rebooted like 5 times, no difference, still just working
<jdub> jbailey: oh crap, i haven't rebooted for you
<whiprush> unless it's doing some something in the background it shouldn't be
<jbailey> jdub: It's all good.  I'm trying to remember off hand which bug was yours.. =)
<jbailey> DSDT handling?
<jdub> whiprush: sudo netstat -pan | grep $(pidof named)
<jdub> jbailey: that one's fixed
<jdub> jbailey: mdrun funniness on my server
<mdz> lifeless: the next tech board meeting is 2005-09-06, but because of the preview release, it might be pushed out a week or more
<jbailey> Oh right.  Where if the last device I touched wasn't raid then I assumed there was no raid in the system.
<jbailey> jdub: Ought to be fixed, I'd appreciate it when you have time.
<jdub> yeah
<jdub> i'll do it now
<jbailey> jdub: You just want to see the new usplash, admit it. =)
<wasab1> evms should totally be the default vol management system. ;)
<jdub> jbailey: no usplash on my server man
<lifeless> mdz: I'm not in a rush. Just moving the process along. The question was 'is maintaining the base debian dir for baz, and the bicycle-repair package' qualifying work ?
<jdub> i have to reboot my notebook too ;)
<mjg59> jdub: Mirror sync not finished yet?
<jdub> mjg59: finished, upgrading now
<jdub> will do notebook first
<jdub> sleepyhead ;)
<mjg59> jdub: I promise you a world of rock
<whiprush> ooh
<whiprush> this the new artwork?
<mdz> lifeless: if they go verbatim into ubuntu, I'd say definitely
<mjg59> whiprush: Yeah. Not finalised, but much better than what we had up to now
<mdz> lifeless: if there's someone in between who is taking your work and making it suitable for ubuntu, I'd say it's more subjective
<mjg59> whiprush: Also, lsb-base integration so text actually appears
<wasab1> I don't want boot text. =(
<jdub> wasab1: i'm working on mjg59 about that - wait for breezy+1 :)
<wasab1> I only want text if something fails badly. heh.
<wasab1> cool
<whiprush> mjg59: rock
<lifeless> bicycle-repair is used verbatim AFAIK. ditto bazaar, though bob2 does tweak it (as far as I know all he does is change the deb version to be not-an-upstream number.)
<mjg59> jdub: It's arguably a bug that any text appears, so we can probably remove that
<lifeless> mdz: thanks. I've got what I need to put stuff on the wiki page.
<mjg59> Oh dear. It's going to be too hot here tomorrow.
<jdub> mjg59: ... for breezy?! i thought we said--
<wasab1> I'd like it to boot exactly like OS X does really.
<mjg59> jdub: Did we? It's like a one line patch for the kernel, and a couple for grub
<jdub> wasab1: OS X has boot text. ;-)
<wasab1> Simple gray or otherwise colored screen until high res is avaiolable.
<wasab1> Sorta. It has a progress bar.
<mjg59> jdub: Oh, hang on, I see what you mean
<jdub> mjg59: oh, no, wasab1 and i are talking about the usplash scrolly bits
<mdz> wasab1: sure, all we need to do is develop a custom hardware platform for Ubuntu.  then we can get rid of all this conditional logic ;-)
<jdub> yeah
<wasab1> It doesn't have scrolling techy text.
<jdub> but the other stuff, totally agree
<jdub> and i asked jbailey about the grub spew
<mjg59> jdub: Yeah. I still hold with what we agreed for now
<wasab1> mdz: I recognize up to the bootloader we can do nothing. ;)
<jdub> yeah, conditional logic is for girls
<jbailey> jdub: I looked and wasn't able to find a bugzilla entry.... =)
<wasab1> but beyond that!
<jbailey> jdub: I *like* girls...
<mdz> wasab1: there are things we can't do beyond that, too
<lu|away> what do I need to install to get the usplash sexiness?
<mjg59> If someone rewrites a small amount of bogl, we can have anti-aliased text in usplash...
<wasab1> Oh? Such as?
<mdz> lu|away: ubuntu-desktop
<mdz> and 'linux'
<louie> hrm.
<jbailey> mjg59: Will that make it harder for me to port it to ppc?
<jdub> louie: install usplash, then re-mkinitramfs -o /boot/<your-initrd-file>
<mjg59> louie: More usefully, perhaps, usplash, lsb-base, initramfs-tools and dpkg-reconfigure your kernel
<wasab1> I really don't want to see graphics until we have high res though. They just look nasty
<louie> mjg59: thanks
<mjg59> wasab1: Depending on boot, that could then result in a very long black screen
<jdub> should have all that stuff already
<mdz> mjg59: I've now seen on three different displays; if the picture is not adjusted properly for whatever reason, the border area comes through as a light color
<mjg59> wasab1: The Windows world deals with 640x480 in 16 colours
<mjg59> mdz: Hrm
<mdz> mjg59: any idea how we can make that black instead?
<wasab1> THe windows world sucks. ;0
<mjg59> mdz: My only guess is that their might be a bit of overscan
<jbailey> mjg59: I see the outside square as white here on my laptop too.
<jdub> mdz, mjg59: hrm, perhaps we have to specify one index as the screen backgroudn too
<mjg59> mdz: Easiest way around that is to make colour 0 black
<mdz> mjg59: sounds fine to me
<louie> jdub: I removed ubuntu-desktop a long time ago because, well, I wanted to see how much misc. puffery I could remove from the livecd, mostly, and decided to leave it off my machine, which is often low on space
<jdub> louie: badness :)
<louie> <shrug>
<jdub> mjg59: turns out shifting colours between indices is hard
<mjg59> jdub: Dude, have you not rebooted yet?
<jdub> mjg59: it's just shutting down atm
<mjg59> jdub: I'll write a damn program to do it
<louie> jdub: ubuntu-desktop depends on a lot of stuff which is totally unrelated to any sane meaning of the word 'desktop'
<mjg59> The BBC news person has what looks like an X300 on the desk in front of him
<jdub> mjg59: supposedly some gif toolkits do it
<HrdwrBoB> louie: postfix isn't needed on a desktop?
<jdub> louie: agree.
<jdub> HrdwrBoB: no, and we don't depend on it anymore
<mjg59> louie: I think "desktop install" rather than "desktop environment"
<jdub> louie: i want to move the python stuff to ubuntu-python
<louie> mjg59: by either definition, it doesn't work
* jdub prepares for a ROCKS OFF experience
<louie> mjg59: all the misc. python stuff, for example?
<mjg59> louie: Yeah, well
<jdub> mjg59: ARGH!
<mjg59> Hrm. Ok, it's not an X300. Previous generation Dell, though
<jdub> mjg59: i have old poo artwork without scrolly bits!
<wasab1> I wonder if there is any feasible way for me to mod my bios to remove all text.
<mjg59> jdub: Dude, you have the wrong usplash and the wrong lsb-base, or you didn't mkinitramfs
<mjg59> 0.1-6 is the usplash you need
<jdub> i did all these things!
<mjg59> It works for everyone else
<jdub> fascist machine
<mjg59> WONTFIX, NOTABUG
<jdub> heh
<mdz> jdub: perhaps you poked at the wrong kernel
<mdz> dpkg-reconfigure linux-image-`uname -r` && reboot
<jdub> i did mkinitramfs
<mjg59> jdub: I mean, dude, mdz has got it to work
<mjg59> And everyone knows how he feels about graphics
<mdz> yeah, and I'm pretty slow when it comes to computers
<jdub> wow
<jdub> hey
<jdub> random
<jdub> so with cfq
<jdub> i get the gdm drumbeat before login:
<jdub> that's harsh
<whiprush> brrump bump
<mjg59> Hrm
<mjg59> That's because cfq eats babies
<jdub> cfq was meant to fix the baby eating problem
<mjg59> So, for reasons I don't understand, at 03:30 every morning, BBC news switches to PBS for half an hour
<louie> so you can know how good you have it?
<mjg59> Uh, not PBS. ABC.
<louie> sort of like taking the children of the rich to tour homeless shelters?
<mdz> could someone figure out why gdm doesn't switch the console properly on the live CD anymore?
<mdz> on shutdown?
<mdz> it used to
<jdub> uh oh
* jdub wonders which machine he's been upgrading.
<mjg59> mdz: We should add a shutdown and reboot init script for usplash, too
<louie> uh
<jbailey> wasab1: http://people.ubuntu.com/~jbailey/initramfs-tools_0.25_all.deb =)
<mdz> mjg59: yes, but it looks like not for breezy
<jbailey> wasab1: I've confirmed that it still boots my totally non-evms setup here, no idea beyond that.
<jbailey> wasab1: It does load all the pieces on, though.
<jdub> mjg59: toshset spews a debconf error about fully-enabled acpi machines
<mjg59> jdub: YES, I KNOW
<jdub> ha ha
<mjg59> (The baby Jesus weeps bitter tears)
<jdub> another gin and tonic
<mjg59> mdz: Oh, that's a point. Can we grab 1.70-1 from Debian for toshset to fix gcc-4.0 FTBFS?
<jdub> so apparently some major strains of malaria are resistant to quninine now
<mjg59> There's basically no code changes other than that
<jdub> quinine
<mdz> mjg59: infinity already asked, and I said yes
<louie> jdub: yeah, have been for at least a few years
<mjg59> jdub: Bah. I'm being forced to drink myself through the mountain of Stella that got left here after the housewarming
<mdz> mjg59: at least, I assume you were both talking about the same thing.  I don't remember which version he wanted
<mdz> stella is not a very good beer
<mjg59> mdz: Yeah. Ok, cool - I missed you acking it
<mjg59> mdz: I wholeheartedly agree
<louie> jdub: they don't give the peace corps kids in africa quinine anymore
<mjg59> But I only have one more can to get through, and then I have enough cupboard space to get something decent
<jdub> mjg59: you let housewarmers bearing stella in the house?
<mdz> mjg59: I have decided that talisker is worth having around, even if it isn't quite as good as cragganmore
<mjg59> jdub: It was Phil Hands
<jdub> so building a custom kernel for ubuntu is a bit of a challenge these days
<jdub> i imagine
<mjg59> jdub: Yes
* jdub still complies with his oath
<mjg59> Got usplash yet?
<mdz> yeah, what's taking so long?
<jdub> "Apple Computer is preparing a major announcement next week, dropping hints of something as critical to the company's future as the release of the original iPod in 2001."
<mjg59> Tablet?
<jdub> BABIES TO RECEIVE IPOD INTERFACE AT BRIS
<mjg59> BRIS?
<mjg59> That's crazy talk
<mjg59> Or dreadful typing
<louie> why wait that long?
<mjg59> Inter-uterine ipod
<jdub> mjg59: it wasn't a typo ;)
<mjg59> iuPod
<mdz> mjg59: that's what they call births in Australia
<mjg59> mdz: Damnit.
<jdub> supposedly it's music related
<jdub> http://www.zdnet.com.au/news/hardware/soa/Apple_hints_at_big_music_announcement/0,2000061702,39209327,00.htm?feed=rss
<louie> oh, right
<louie> this is when they announce all the major labels have told them to fuck off
<louie> :)
<jdub> http://blogs.sun.com/roller/page/swinger?entry=towards_humanity_oh_my
<jdub> ^ ha ha ha
<mjg59> jdub: Get usplash working, damnit
<whiprush> jdub: you just had to defend why we're not shipping spatial by default.
<mdz> jdub: stop changing the subject
<jdub> mjg59: now i'm upgrading my laptop!
<whiprush> we're indeed in the outer limits.
<jdub> mjg59: i must've been upgrading something else before
<mjg59> "KDE uses C++ so it's less error prone and allows developers to concentrate on real work instead of fighting with libraries (and dependencies)"
<mjg59> ?
<louie> well
<louie> to be fair
<mjg59> I must have missed all those C ABI transitions
<louie> if I had a nickel for every time we had some stupid pointer-based-bullshit crash in bugzilla
<mjg59> Except, no
<louie> I'd not be worried about going back to work, or school
<mjg59> That is, actually, a 4:0 ABI transition win for C++
<mdz> louie: yeah, good thing C++ doesn't use pointers
<HrdwrBoB> I am not very keen on Gnome, because I hate depending on lots of different libraries with different evolutionary speeds
<jdub> whiprush: i've always loved the feature myself (to a certain extent), but understood its impact on real users
<jdub> louie: ha ha C++ without pointers!@
<louie> right, so, not the example I was searching for
<whiprush> jdub: the one bummer with new browser, is that the sidebar isn't drag and dropabble.
<louie> it's late, I'm tired ;)
<whiprush> so it's like, so close.
<jdub> whiprush: yeah
<jdub> good bug :)
<mjg59> Oh dear. ABC seem to be saying that the US is going to be bankrupt now.
<mjg59> $67.20 a barrel? Ouch.
<louie> it was up to $74 this morning at one point.
* jdub enjoys sogrady's style
<jdub> http://feeds.feedburner.com/tecosystems?m=808
<jdub> mu ha ha
<jdub> mjg59: STATUS: mkinitramfs
<lifeless> mjg59: goes around, comes around.
<mjg59> louie: It's basically impossible for a third party to provide dynamically linked C++ binaries
<jdub> mjg59: STATUS: reboot
<mjg59> jdub: Hurrah
<louie> mjg59: I'm not saying C++ is good
<louie> mjg59: I'm just saying C really sucks
<mjg59> louie: Oh, hell, yeah
<mjg59> C really sucks
<jdub> HOLY CRAP
<mjg59> We win!
<jdub> MY PANTS ARE A MESS!
<jdub> mjg59: ok, so the funny look must be the scaling on my LCD
<mjg59> jdub: Only thing really left to fix is word wrapping
<louie> #ubuntu: our pants are a mess
<mjg59> Funny look?
<jdub> mjg59: console scaling, makes it look, uh, badly anti-aliased
<mjg59> Ah, yeah
<jdub> we can pass that off as a feature though
<mjg59> That's massively hardware dependent
<jdub> is it possible to turn off the scaling in userland?
<mjg59> Yes. If we know how to speak to your specific bios.
<jdub> save state, turn it off, resume state
<jdub> oh
<jdub> screw that, then
<mjg59> (So, uh, no)
<mjg59> ACPI was a wonderful opportunity to standardise all of this
<mjg59> But, damn.
<jdub> mdz: http://lwn.net/Articles/149564/
<jdub> ha ha h
<jdub> a
<mjg59> louie: I'm actually astonished at how bad ABC seems to be
<louie> mjg59: the only news radio worth listening to in the US is NPR
<louie> and even that is not nearly as good as BBC
<whiprush> it's all about science friday.
<EvanCarroll> I just found a pretty big bug in breezy, I was playing with debfoster, a utility that i never used before in ubuntu, when I asked it to purge the vlc package, in doing so all of the vlc dependenices not registered as dependencies elsewhere were removed, the result was quite odd, no sound using xine/alsa, like a problem with mpeg/mp3+avi/rm decoding in everything
<louie> which probably would not be as good as circa-1985 apple tts reading the economist
<EvanCarroll> Though i could see the motion picture, I coulden't hear the sound, and nothing spit out an error to stderr or though dialog, nothing in logs or anything
<louie> OK
<louie> wish me luck, usplash and n-m when I return
<louie> hopefully
<louie> either that or DEATH
<EvanCarroll> the only thing that produced sound was xmms with its alsa plugin, when i readded vlc for troubleshooting everything worked
<mjg59> jdub: So how many sexiness points do we get for that?
<mjg59> EvanCarroll: That's very odd.
<jdub> mjg59: well, i'm rebooting again
<jdub> if that's any indication
<mjg59> Haha
<mjg59> I did that several times today
<jdub> mjg59: the progress bar needs to be further down
<jdub> mjg59: in between bottom of logo and top of text area
<mjg59> Oh, the progress bar has been added?
<EvanCarroll> mjg59: It is reproducable though, I can output the log of the things that vlc pkg added to my system, I would say all of its dependenices should be listed with other programs that could use them though, such as gxine
<jdub> yeah
<mjg59> I hadn't seen it working with those graphics yet
<mjg59> Yeah, that's an easy fix
<EvanCarroll> or at the very least amarok, kaffeine, and nautoplay
<mjg59> Pls file bug kthxbi
<mjg59> (Severity: BLOCKER)
<jdub> mjg59: when would you expect it to dump you at normal output?
<jdub> with current version
<mjg59> jdub: If something goes wrong
<mdz> mjg59: hmm
<mjg59> Unless an init script is taking too long
<mjg59> I might want to extend the timeout
<mdz> mjg59: I think busybox init is killing usplash
<mjg59> mdz: Mm? Erk.
<mjg59> mdz: How so?
<mdz> mjg59: well, it does more or less kill(-1)
<mdz> mjg59: what I get is the usplash artwork, static and unchanging until X starts
* jdub reboots again
<mdz> fixing that is going to be a pain
<mjg59> mdz: Oh, nngh.
<mjg59> mdz: I haven't seen that. I get text here.
<mdz> mjg59: on the live cd?
<mjg59> Oh, no
<mjg59> Sorry, was missing context
<jdub> HDIO_SET_DMA failed: operation not permitted
<jdub> something in my hdparm settings, i guess
<mdz> mjg59: the live CD boots into d-i, which uses busybox init, then it tells busybox init to re-exec itself (along the way it kills everything but itself)
<mjg59> jdub: That sounds like initramfs somehow missing your driver
<mjg59> mdz: Hrm. Right.
<mdz> mjg59: so either I'll need to hack up busybox, or create an init script for usplash so that it gets started after init
<mjg59> mdz: Well. it /could/ just catch KILL...
<fabbione> morning
<mdz> mjg59: catch the uncatchable catch?
<mdz> dream the impossible dream?
<mjg59> Oh, damn, KILL is uncatchable?
<mdz> yes
<mjg59> I forget which ones are and aren't
<jbailey> jdub: Take ide-generic out of your /etc/mkinitramfs/modules
* jbailey wanders off for food.
<mdz> jdub: DELETE /etc/mkinitramfs/modules
<jdub> well, it even happens post-boot
<mdz> jdub: and then re-mkinitramfs
<mjg59> jdub: Once ide-generic has bound, nothing else can grab the controller
<jdub> oh
<jdub> badness
<wasab1> I don't suppose anybody knows hwo to make NFS not require reverse DNS?
<mjg59> wasab1: Check /etc/hosts.deny
* jdub lines ducks up for another reboot ;)
<wasab1> Check for what?
<mjg59> wasab1: man hosts.deny
<wasab1> Well, the file is empty.
<mjg59> Unsure, then
<wasab1> It seems to be part of NFS itself.
<mjg59> Not to the best of my knowledge
<mjg59> Though I haven't touched NFS since 2002, thankfully
<wasab1> Heh.
* mjg59 enjoys no longer being a sysadmin
<wasab1> I'm open to alternatives. =(
<mdz> lamont-away: around?
<jdub> mjg59: magical
<jdub> i'm reboooting again
<mjg59> jdub: ?
<jdub> i just got my first complete usplash run
<mjg59> Are you addicted?
<mjg59> Haha
<jdub> so i'm going to watch it again
<mjg59> Rock
<jdub> mjg59: mm, and that choice of red wasn't offensive
* jdub is pleased
<mjg59> jdub: I think this is a historic victory
<fabbione> mjg59: yo
<mjg59> fabbione: Hi
<fabbione> mjg59: i think i need a new laptop.. what brand would you suggest?
<fabbione> (amd64/TONS of RAM/no need of big hd/possibly nice big screen)
<mjg59> fabbione: If you've got enough, IBM
<mjg59> There are no good amd64 laptops yet
<fabbione> mjg59: i only have one.. i don't make laptop collection as you do...
<daniels> fabbione: he meant enough money
<mjg59> IBM are expensive, but the T series is *very* good
<mjg59> Toshiba are probably the best of the rest, if you go for their business machines
<fabbione> mjg59: how much are we talking about +/-?
<mjg59> fabbione: 1500 Euros or so 
<mjg59> At a guess?
<mjg59> I don't really know what they go for in the Eurozone
<fabbione> mjg59: eheh ok :) an estimate is more than fine
<mjg59> You could get the same CPU and RAM for much less, but it wouldn't be as well made
<jdub> mjg59: use your BBC words
<jdub> this is AN historic victory
<mjg59> I REFUSE.
<fabbione> mjg59: hmmm they have IBM R50 and T42..
<mjg59> fabbione: T42
<jdub> fabbione: the samsung-rebadged Dells are good (currently the Dell X1 / Samsung Q20)
<mjg59> The R series is cheap rubbish
<fabbione> mjg59: and they are almost the same prices as PowerBooks ....
<mjg59> Yeah
<mjg59> They're nicer than Powerbooks
<jdub> they're just like the IBMs without the bowel pain
<mjg59> No T43s?
<daniels> jdub: ps: when talking to an irishman, possibly refrain from mentioning 'your' BBC
<fabbione> mjg59: i am surrounded by i386 :)
<mjg59> fabbione: Haha
<mjg59> fabbione: Well, Powerbook means PCMCIA or USB wireless
<mjg59> The only AMD64 from a big name manufacturer yet is from HP, and it's not very nice
<fabbione> mjg59: if i need to spend that amount of money, i would go for a powerbook.. i hounestly expected to be cheaper
<fabbione> mjg59: i saw the ACER ferrari?
<jdub> powerbook
<jdub> sheesh
<fabbione> mjg59: yeah usb/pcmcia doesn't scare me
<mjg59> fabbione: If you buy an Acer, I will fly to your home and punch you in the face
<jdub> you are buying a cadaver :)
<fabbione> mjg59: gotcha :)
<mjg59> And will never reply to your bugs
<mjg59> fabbione: You remember how much crack acerhk was?
<fabbione> mjg59: yes yes..
<fabbione> wasn't a powerbook g4 2Ghz around?
<mjg59> fabbione: Now imagine a whole laptop of that much crack
<fabbione> or the top was 1.67?
<jdub> mjg59: congrats
<jdub> mjg59: usplash is aesthetically beautiful, and technically non-objectionable
<fabbione> mjg59: yes.. i gotcha from "the i will fly there and kill you of the slowest painfull death" ;)
<mjg59> jdub: It was a lovely spec to implement
<mjg59> fabbione: The Dutch government wants to stop foreigners buying drugs there
<fabbione> CRAP
<louie> I probably should not have tempted the fates.
<fabbione> mjg59: well we still have kernel source printed on thin cigarette paper.. just refill it with tobaccos.. that will do :)
<mjg59> jdub: Any more impossibilities you want implemented before release?
<jdub> no
<jdub> it is love
<daniels> mjg59: also, I want a pony
<wasabi> jbailey: no luck.
<jdub> we can worry about scrolly bits for breezy+1 ;)
<wasabi> Says no root device, can't find /dev/evms/root
<jbailey> Hmm
<jbailey> wasabi: Can you try rebooting, add the word 'break' to the kernel command line.  It should drop you to a shell.
<jbailey> wasabi: Take a look in /dev/evms, does it exist?  What's in there?
<wasabi> lemmie grab other comp
<jbailey> If nothing, trying running /sbin/evms_activate
<jbailey> wasabi: Cool.
<jdub> jbailey: ok, time to reboot my server :)
<jbailey> jdub: Cool.  Hopefully get you and wasabi happy and then I'll go to bed. =)
* fabbione starts to make bubbles on the powerbook
* jbailey blinks nervously.
<wasabi> No /dev/evms and no /sbin/evms_activate
<jbailey> Well, the second is the cause of the first..
<jbailey> Hmm
<wasabi> reverse that.
<wasabi> Heh
<wasabi> Err
<wasabi> Yeah, you're right.
<wasabi> Damn backwards logic!
<wasabi> Oh hey, my iBook apparently can sleep and can wake up now.
<wasabi> but it can't REALLY wake up. it wakes up and goes to console with kernel messages printed out
<wasabi> and I can't switch to X
<wasabi> I can plug/unplug a usb device though and see that it's responsive.
<jbailey> wasabi: Are you able to boot the system the rest of the way up?
<fabbione> wasabi: hand me 3000 Euros and i will happily test on my new shiny powerbook :)
<wasabi> jbailey, i can switch back to oter kernel.
<jbailey> wasabi: Please.  We need to figure out why evms_activate didn't get included.  It's in mine here.
<mdz> mjg59: ok, so I changed it to start usplash after udev instead, which is not so bad
<jbailey> Of course, I get "Error returned from evms_open_engine(): No such file or directory". but I'm hoping that just means that I don't have any evms volumes.
<mdz> mjg59: but on the live CD, X can take longer than the timeout to start
<wasabi> I get big errors like that.
<wasabi> On the old kernel.
<mdz> mjg59: and I seem to end up back at a text console rather than on the VC where X is running
<wasabi> Unable to create lock file, might be dupe instances, etc.
<wasabi> Always just ignored them.
<mjg59> mdz: Ok
<mdz> mjg59: usplash tries to switch back to VC#1 or VC#<previous> when it times out, right?
<mjg59> mdz: Hrm. If X hasn't changed VT, then usplash will exit back to its VT, and I guess that X might notice that the VT has changed again
<jbailey> jdub: And?
<jbailey> =)
<wasabi> jbailey, I'm up.
<mdz> mjg59: yeah, I think it's taking >=15 seconds just to read all of the X server garbage off of the CD, before it starts doing anything
<mjg59> Yeah. usplash -c opens a new VT. If it times out or gets a QUIT message, it switches back to the old one.
<jdub> jbailey: lovely :-)
<jbailey> wasabi: 'kay, can you make sure that you have a file /usr/share/initramfs-tools/hook/evms
<jbailey> jdub: Cool. =)
<jdub> jbailey: /init: 89: chmod: not found
<mdz> mjg59: should gdm tell usplash to quit?
<mjg59> mdz: Ok. We can either increase the timeout generically, or I can give you a command to alter the timeout on the fly
<jdub> jbailey: known?
<jbailey> jdub: Yup, I know about that one.
<wasabi> jbailey, I do not.
<mjg59> mdz: Hrm. That doesn't sound like the right answer.
<mdz> mjg59: I wouldn't know what to set the timeout to
<jdub> jbailey: tops - thanks! :)
<jbailey> wasabi: 'kay, so I apparently gave you the wrong initramfs-tools deb, gimme a sec. =)
<wasabi> hehe k
<jdub> jbailey: btw, should i need sata_sil/sd_mod in /etc/mkinitramfs/modules?
<jbailey> jdub: Nope.
<mdz> mjg59: apart from that, it works (or would work, if the latest casper would build without infinity)
<mjg59> mdz: Rock
<jbailey> jdub: Mind doing another reboot test with that gone?
<mjg59> mdz: Well, if it's got as far as gdm, then it's unlikely that anything is going to explode
* jdub furrows brow.
<jdub> ok :)
<jbailey> wasabi: New version posted.
<mdz> I guess usplash still isn't working for jdub, if he's complaining about that chmod error
<wasabi> same version?
<jbailey> mdz: It's his server, he probably isn't running usplash on it.
<mdz> oh, I see
<jbailey> I should upload the new busybox that fixes that.
<jbailey> wasabi: Yup.
<mjg59> usplash doesn't use chmod any more
<jbailey> mjg59: initramfs-tools does.
<mjg59> Yeah
<mjg59> But one of the chmod errors used to be from usplash
<fabbione> mdz: why xdm has been promoted to main?
<mdz> fabbione: I don't know; perhaps elmo processed it straight into main
<fabbione> mdz: ok.....
* ajmitch remembers to file a bug on xdm
<fabbione> mdz: if there is no good reason, it should land in universe, as it was for warty and hoary
<mdz> fabbione: I already moved it
<mdz> it was on anastacia's list
<fabbione> mdz: perfect. thanks
<mdz> fabbione: which you can always find at http://people.ubuntu.com/~mdz/anastacia.txt (updated every 15 minutes)
<fabbione> mdz: yes, i recall the URL.. but that won't give me an explanation if somebody asked for it to be specifically forced in main...
<jbailey> wasabi: How's it going?
<fabbione> mdz: probably rman can be demoted too. It was a Xfree/Xorg B-D
* fabbione checks
<mdz> fabbione: I already tried; it needs elmo love
<fabbione> yeah it can go..
<fabbione> hmm why elmo love?
<fabbione> ah i guess for the links, and move stuff around...
<wasabi> jbailey, it has it
<wasabi> jbailey, about to reboot
<jbailey> wasabi: lovely, thanks.
<louie> hrm.
<louie> so, X wasn't starting because my mouse device got renamed from /dev/input/mice to /dev/input/mouse0
<louie> known bug?
<louie> (or NOTABUG?)
<mjg59> louie: Erm. The two devices aren't the same thing.
<mjg59> /dev/input/mice should exist
<mjg59> It multiplexes the stream from every mouse input device
<mjg59> mouse0 is the input from a single mouse
<louie>  /dev/input/mice does not exist, and replacing one with the other in my xorg.conf got me a working system, so... 
<jbailey> louie: The udev upload I just did should have fixed that.
<louie> jbailey: the missing /dev/input/mice, you mean?
<jbailey> louie: right.
<louie> ah, thanks.
<jbailey> louie: #12915 for reference.
<mjg59> Jesus. Have we really gone though about 15,000 bugs in a year
<mjg59> ?
<mjg59> That's not too bad
<wasabi> synaptic should remember the size of the last Packages and Sources files that were downloaded.
<wasabi> And use that to prime the progress bar.
<jbailey> wasabi: Does that mean the reboot was succesful? =)
<wasabi> Having a progress bar that hits 100% and goes back to 50% over and over again is a bit annoying.
* jbailey is going to turn into a pumpkin shortly.
<wasabi> jbailey, naw, means I'm updating my laptop.
<wasabi> No work
<wasabi> ALERT!
<wasabi> Engine: Unable to open the control node for Device-Mapper
<wasabi> The Engine will run without Device-Mapper support.
<wasabi> Error returned from evms_open_engine(): No such file or directory
<wasabi> it's missing dmsomething. ;)
<jbailey> wasabi: can you check /proc/modules for dm_mod ?
<wasabi> Hmm. When runnign with break, it's not there, but it looks like break stops initrd launching
<jbailey> wasabi: Right.  Didn't it drop you to a shell when it couldn't mount root? =(
<wasabi> Nope. It said it was.
<wasabi> But it just left me at the error line
<jbailey> Hmm.
<louie> blah, nm is not happy to be running under jhbuild. looks for the system dbus somewhere in my jhbuilt root. anyone know how to fix that?
<jbailey> wasabi: Run scripts/local-top/lvm and then scripts/local-top/evms please?
<wasabi> in break?
<jbailey> Yup
<wasabi> same error on evms
<jbailey> The whole error, include the device-mapper bits?
<jbailey> Oh - of course.
<jbailey> lvm isn't causing dm-mod to be loaded for you.
<wasabi> The error from evms.
<jbailey> Can you modpribe dm_mod please
<jbailey> and then try /sbin/evms_activate
<wasabi> evms_activate gave me the no such file or directory error
<wasabi> but not the Engine! error
<windub> so that would be a big fat ugly NoBurger
<wasabi> And /dev/evms now exists, with only one file. /dev/evms/dm
<windub> jbailey: it spewed about changing roots and stuff
<jbailey> windub: Err.. What? =)
<jbailey> windub: Oh, removing the sata module?
<windub> jbailey: pulling sata_sil/sd_mod from modules resulted in very unhappy initramfs
<wasabi> On this other system, my SATA DVD drive doesn't appear at all.
<wasabi> Alas.
<jbailey> windub: I need to pass out soonish.  Are you able to take some time with me on this tomororw night?
<windub> sure
<jbailey> windub: It won't be a whole series of rebooting, mostly just walking sysfs to find out why it's not discovering this.
<windub> fwiw, this machine is piix on the mobo, sil pci card, boots from sil
<jbailey> Right, but it should load both of those.
<windub> heh, now it's reconstructing my one disk raid array ;)
<windub> hrm, and couldn't mount my other raid array
<windub> interesting
<jbailey> wasab1: Thanks.  Now that I see that I get the same message as you, I can trace it.
<wasab1> okay!
<jbailey> wasab1: Should be in either 0.25 or 0.26.  Depends if I need to push something for 0.25 sooner than evms is ready.
<jbailey> And with that, g'night all. =)
<wasab1> Night!
<bddebian> gnight Jeff
<lamont-away> mdz: just home
<lamont-away> and wandering back and forth for a bit
<whiprush> jdub: ping
<jdub> pong
<jdub> er, brb
<jdub> just to make things difficult ;)
<jdub> (phone)] 
<whiprush> tell me of large appliances that keep things cold.
<robitaille> ice boxes?
<whiprush> sort of.
<ajmitch> morning pitti 
<Mithrandir> mdz: (re 13905): I'm handling it today, I didn't make it yesterday, but it's top priority once I get into the office.
<pitti> Hi folks
<Mithrandir> hi pitti
<pitti> Hi Tollef
<fabbione> hey pitti
<xhaker> udev doesn't set my cd recorder permission right
<xhaker> any info on that?
<xhaker> i couldn't record a CD, before chmodding 777 /dev/hdc
<pitti> xhaker: known bzg
<pitti> xhaker: #14226, will be fixed soon
<sivang> anybody has id what debmirror wants? Won't mirror without dists/breezy/main/binary-powerpc/Packages.gz signature in Release at /usr/bin/debmirror line 1174.
<sivang> I use:debmirror /home/vmware/mirror -h archive.ubuntu.com -s main -r /ubuntu -d breezy -a powerpc
<xhaker> didn't thought of searching :s sorry and by the way, scite is not yet synced with debian
<sivang> pitti: morning
<sivang> pitti: d'ya get my email?
<pitti> Hi Sivan
<pitti> sivang: just started reading mail 30 seconds ago
<\sh> mjg59: for what do i need toshset_
<\sh> ?
<\sh> only 20 minutes left to leave for breakfast
<sivang> pitti: k :)
<jdub> pitti: do you maintain pmount TODO stuff in bugzilla, or on a wiki or in the tarball or something?
<pitti> xhaker: should be solved in udev (0.060-1ubuntu10)
<pitti> jdub: right in bzr: http://people.ubuntu.com/~pitti/bzr/pmount/TODO
<sivang> pitti: anyway I sent you a link to the debdiff, if you have time you can ping me in about 1.5 hours I'll be at work an able to respond to feedback
* sivang away out
* Keybuk has a half-finished zsh completion for bzr now
<ajmitch> Keybuk: know of any bash completion for it yet?
<pitti> jdub: the list doesn't contain the stuff from bug reports, btw
<Keybuk> ajmitch: *shrug* I've never used bash in earnest
<ajmitch> I've yet to play with zsh
<jdub> pitti: haven't got anything in there about smb/nfs :-)
<jdub> pitti: or images (iso/img)
<pitti> jdub: #11796
<jdub> aha
<pitti> jdub: why smb? smbclient works fine, doesn't it?
<jdub> pitti: mounting smb shares as seamlessly as media devices
<pitti> jdub: hm, ok
<pitti> jdub: back in warty, we explicitly removed the setuid bit from smbmount :-)
<pitti> but that was to get rid of suid bits, not particularly to disable smb mounts by users
<daniels> Keybuk: have you already got bored, thrown it away, and rewritten it, or does that come later?
<pitti> elmo: please sync phpldapadmin simpleproxy
<jdub> pitti: i should chat to you about this some time
<jdub> pitti: maybe we should meet in some place easy for both of us to get to in the next couple of months
<jdub> like montreal
<jdub> that seems simple
<jdub> i know
<pitti> right :-)
<jdub> maybe we should *all* go to montreal
<pitti> great idea!!!
<pitti> but it's friggin' cold there...
<pitti> and my laptop produces almost no heat
<pitti> ok, I could compile firefox in an endless loop...
<ajmitch> pitti: don't do that to your poor laptop
<Keybuk> daniels: bash?
<Keybuk> I've always just used zsh
<Keybuk> and ksh before that
<daniels> Keybuk: ... okay, but why are you telling that to me?
<Keybuk> <daniels> Keybuk: have you already got bored, thrown it away, and rewritten it, or does that come later?
<Keybuk> unless I mis-understood the sarcasm
<daniels> Keybuk: i was talking about your zsh completions
<Keybuk> oh, right
<Keybuk> I was going to give it to you, so you could split it into 100 different packages
<Keybuk> zsh-completion-bzr-add
<Keybuk> zsh-completion-bzr-remove
<Keybuk> zsh-completion-bzr-status
<Keybuk> zsh-completion-bzr-inventory
<Keybuk> etc.
<daniels> dude, don't look at me for the xorg app stuff
<daniels> it might be instructive to check the changed-by field on all those uploads
<Keybuk> http://people.ubuntu.com/~scott/software/_bzr
<Keybuk> is the current code, it does completion of command names and a few of the arguments now
<pitti> argh, dpkg conffile question for Xman
<daniels> pitti: dpkg bug, harass keybuk
<Keybuk> *shrug* dpkg bug you knew about before you broke X :)
<pitti> I also got questions for two other x clients
<pitti> well, as long as they don't appear in the hoary->breezy upgrade...
<daniels> Keybuk: and again, 'might be instructive to check the changed-by field on all those uploads'
<daniels> i've nothing to do with xman
<daniels> pitti: they won't from hoary->breezy, by a very curious quirk of dpkg
<jdub> pitti: hmm, i have two CDs listed in computer:///
<jdub> and only one cd drive
<jdub> they appear to be displaying the same thing
* jdub ejects
<pitti> jdub: hm, can you please mail me your "lshal" output?
<pitti> jdub: oh, btw...
<pitti> jdub: does eject work for you? also for usb sticks?
<pitti> jdub: it was broken for a while, but now it works fine for me again
<jdub> eject with the desktop icon context menu just worked then
<pitti> jdub: just want to confirm #5049
<pitti> jdub: ok, fine
<jdub> aha, and i still have two devices
<jdub> rad
* jdub gets lshal
<jdub> pitti: done
<Burgundavia> daniels, you actually post in the forums?
<daniels> Burgundavia: i troll for bugs around preview releases
<Burgundavia> daniels, ah, that explains it
<Treenaks> daniels: do you have any idea about the HP/Synaptics issue?
<bob2> someone should run a tutorial to teach people how to file bugs or something
<bob2> run it over msn, I mean
<Treenaks> bob2: oh, like Simon Tatham?
<Treenaks> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
<bob2> haha
<pitti> bob2: right; "only file bugs if you have a proper explanation in plain text and diff -u format" :-)
<bob2> haha
<Treenaks> pitti: +patch
<daniels> Treenaks: which one?
<Treenaks> daniels: the one about all taps being middleclicks
<Treenaks> daniels: which is teh suck
<daniels> Treenaks: yeah, I saw it, but -synaptics hasn't changed in *ages*
<daniels> Treenaks: so if it's recent breakage, I'd be looking at the kernel
<Treenaks> daniels: it's recent hardware
<Treenaks> (i.e. canonical-supplied)
<daniels> maybe synaptics 0.14.x fixes it
<Treenaks> daniels: also, it works fine on my _other_ laptop
<jdub> mjg59: are you asleep?
<pitti> jdub: odd, it seems that you get one icon for the storage device, and one for the volume on it
<jdub> rad!
<pitti> jdub: but you said this lshal was issued *after* you ejected the disc?
<jdub> no
<jdub> oh, well
<jdub> i ejected, then put it back in
<pitti> ah, ok
<jdub> just to see if i still had two disks
<pitti> then it's at least not completely broken :-)
<jdub> :-)
<jdub> yeah, that would be alarming
<pitti> jdub: can you mail me lshal without a cd inserted, for comparison?
<jdub> i believe so
<Treenaks> daniels: it might be fixed in 0.14.2+
<Treenaks> - Ignore the finger count from synaptics touchpads if the finger
<Treenaks>   pressure is below finger_high. Some touchpads (for example, the one
<Treenaks>   found on HP Pavilion 2028) report an unreliable finger count when
<Treenaks>   the finger pressure is very low.
<jdub> mmm, finger.
<daniels> Treenaks: 'kay, I'll look into it
<Treenaks> daniels: I'll attach this to the report
<daniels> Treenaks: thanks
<jdub> pitti: sent
<rob^> are there any problems with xorg in breezy at the moment?
<rob^> I just noticed there are a lot of updates
<daniels> there will continue to be lots and lots of updates right through to breezy
<rob^> yeah, nothing of note though?
<daniels> not yet
<Treenaks> daniels: how about http://bugzilla.ubuntu.com/show_bug.cgi?id=14159 ;)
<rob^> hmm 
<daniels> Treenaks: hotkey-setup is matt's baby, not mine
<daniels> Treenaks: (but yes, complete crack)
<Treenaks> daniels: yeah, but as they're not quite standard keys..
<daniels> 'quite'
<pitti> jdub: just to be clear, you get two icons even if the CD-ROM is ejected?
<jdub> pitti: no
<jdub> pitti: icons disappear properly
<jdub> pitti: but when mounted, i have two icons
<pitti> ok
* jdub tries another cd
<jdub> yeah, just to make sure
<jdub> same thing happens with non-ubuntu cd
<jsgotangco> is that for today's build?
<pitti> jdub: ok, I will eyeball the gnome-vfs2 code
* jsgotangco has strange icon behaviors in 0829
<Belutz> anyone work in canonical? :)
<pitti> Belutz: quite a few
<jsgotangco> i've seen some
<Belutz> pitti: what if i'm going to open official support for ubuntu in indonesia?
<Belutz> i'm sorry, but this is out of topic from the channel
<jsgotangco> Belutz, Ubuntu Marketplace in the Ubuntu website has details on how to do it
<Belutz> jsgotangco: ok, i'm goign to look at it
* sivang --> back
<jsgotangco> hi sivang 
<Keybuk> random debconf error during upgrade: "Your kernel has ACPI enabled.  Unfortunately toshset is not fully functional on ACPI-enabled kernels".
<Belutz> thx all
<jdub> Keybuk: mjg59 knows about it. loudly.
<sivang> jsgotangco: hey :)
<Treenaks> Keybuk: Toshiba?
<Treenaks> The Dutch version of that message is full of grammatical errors
<Keybuk> jdub: yes, he just got a critical bug about it too :p
* Keybuk sings the "On my new Toshiba" song from the 1980s advert
<Keybuk> (but I don't even own a Toshiba)
<daniels> mdz: btw, xkeyboard-config 0.6-1 fixes your dvorak ralt problem
<dholbach> hi
<sivang> hey dholbach 
<jsgotangco> dholbach!
<jdub> morning dholbach 
<dholbach> morning sivang, jsgotangco :)
<dholbach> jeff!
<jdub> dholbach: how did thesis stuff go?
<dholbach> jdub: i have presentation on friday
<jdub> ooer
<jsgotangco> ooohhh good luck!
<jdub> and when i say ooer
<jdub> i mean BOOYAKASHA
<dholbach> *jitter* *tremble*
<pitti> Hey dholbach 
<dholbach> elmo, infinity: do you happen to know what happened to my clamtk 2.06 upload?
<pitti> dholbach: good luck and rock'em :-)
<dholbach> hey martin
<dholbach> how are you all? :)
<pitti> dholbach: it was accepted according to the log
<pitti> clamtk_2.06-0ubuntu1_source.changes
<pitti> ACCEPT
<pitti> dholbach: ^ this version?
<dholbach> yes, i received the mails as well
<dholbach> yes, it seems to never have been built
<dholbach> at least there are no logs and no new version in the archive
<sivang> dholbach: I've had my first FTBFS this morning, but besides that, everything's coolo :)
<dholbach> sivang: there are a lot of "first times" :)
<sivang> dholbach: yeah, and for some, Nth times :)
<dholbach> "doesnt build at all", "builds only on arch X", "uploaded to wrong host", "upload not signed", ...
<dholbach> hi carstenh 
<carstenh> hi dholbach 
<dholbach> carstenh: i'm in trier now as well :)
<dholbach> carstenh: but will leave this afternoon
<sivang> dholbach: yeah...
<sivang> infinity is probably sleeping now, right?
<Keybuk> There's something delightfully retro about that usplash font
<pef> hi
<xhaker> Keybuk, isn't it nice? :P
<dholbach> hey mvo
<pitti> Hi mvo
<pitti> mvo: thanks for fixing u-n
<mvo> hi dholbach, pitti 
<mvo> pitti: yes, I'm pretty happy that it is fixed now, took me a bit to find the problem
<pitti> mvo: was it a startup race condition with dbus?
<mvo> pitti: it was a race between gtk and x that caused the shape extension not to work on the first run
<pitti> carstenh: ping
<carstenh> pitti: pong
<pitti> mvo: ouch
<jdub> daniels: is it sane for xorg.conf not to have a Module section?
<jdub> when it was built by dpkg-reconfigure?
<tepsipakki> what's the reason for running lrm-manager with --quick on boot?
<tepsipakki> I'd like my nvidia binary-driver to be available on boot
<jdub> it's built for you on boot
<dholbach> morning doko
<tepsipakki> jdub: no it isn't
<tepsipakki> lrm-manager: ld: not found (or something)
<jdub> tepsipakki: ls /lib/modules/2.6.12-7-686/volatile/
<jdub> ah
<jdub> something interesting is wrong, then
<tepsipakki> I filed a bug on that some time ago
<hunger> tepsipakki: Install binutils-static and replace ld with ld_static
<tepsipakki> i know how to fix it for me ;)
<tepsipakki> but would like to get the fix in ;)
<hunger> tepsipakki: There are two bugs open about this issue IIRC, ask daniels, he should know for sure;-)
* hunger does not understand what exactly the lrm-manager does anyway.
<lifeless> dholbach: why are you assigning baz bugs ?
<jdub> it builds the modules in l-r-m for you, at boot
<dholbach> lifeless: they were all in the unassigned view
<dholbach> lifeless: i thought it'd be better for them to be assigned to bazaar-developers
<lifeless> please don't
<lifeless> unassigned means noone has taken responsibility for them
<dholbach> lifeless: what should i do with them?
<lifeless> leave them unless you plan to work on them
<dholbach> hmhmhmhmhm
<lifeless> now all the ones you had edit _incorrectly_ show as being worked on by the baz team,.
<daniels> jdub: 'no'
<hunger> jdub: Why aren't the modules build at install time?
<dholbach> lifeless: isnt the "accepted" bit what you are talking about?
<lifeless> and I've got to get someone to go through and put them back to unassigned. 
<daniels> jdub: still with fiddy-foah?
<jdub> yes, -54 on my desktop - nvidia, x86, etc.
<dholbach> lifeless: i don't want a needless discussion, just to make sure i get it right
<jdub> it's rather bizarre running a server without SHAPE
<daniels> jdub: output of DEBUG_XORG_PACKAGE=developer DEBUG_XORG_DEBCONF=developer sudo dpkg-reconfigure -phigh xserver-xorg, pls
<daniels> jdub: but ISTR this being a Debconf bug
<lifeless> dholbach: actually, its different again, I just looked (I was alerted by email) - you are assign the work in the distro to the upstream team.
<dholbach> lifeless: these are the only ones i can assign :)
<lifeless> dholbach: So the right thing to do if you want upstream to work on it is to 'request a fix upstream'
<jdub> daniels: you want the output?
<lifeless> dholbach: 'accepted' means that the person assigned the bug has agreed. 'assignment' is asking a specific person to fix it in a specific context.
<jdub> o/~ when you call my name, it's like a little prayer o/~
<daniels> jdub: yeah
<dholbach> lifeless: i see - it's just that bugs that are unassigned tend to get lost, assigned bugs are bugs that a team or somebody is aware of, accepted bugs from my point of view are bugs that are "taken care of"
<lifeless> they cannot get lost - they are tied to bazaar, to the team, already.
<lifeless> unassigned -> lost is a bugzilla thing, not malone ;0
<dholbach> lifeless: i will leave the next bazaar bugs alon
<dholbach> e
<lifeless> dholbach: thanks. If you want a bazaar bug fixed, just do the 'request a fix in upstream', and/or get someone on the team to agree to tackle the bug, then they can assign it to themselves or ask you to assign it to them.
<dholbach> lifeless: i wanted to make sure that the team knows of the bugs, nothing else
<Mithrandir> dholbach: they probably know how to search for bugs in "bazaar". :-P
<lifeless> dholbach: to make sure we know of bugs in bazaar, all you need to do is ensure there is an 'Ubuntu upstream' entry in the 'needs fixing in' column.
<dholbach> Mithrandir: a mail in my inbox is a step closer to fixing the bug :)
<lifeless> dholbach: I get a mail on evey bug when its filed against bazaar upstream.
<Mithrandir> dholbach: that's not everyone's workflow.
<dholbach> Mithrandir: that's what i just learnt
<doko> >   * Add java-gcj-compat again as alternative for lib32gcj6 as per
<doko> >     Matthias' advice.
<dholbach> lifeless: i won't pester you guys again :)
<doko> Mithrandir: I said: add it, not replace it
<lifeless> dholbach: I'm very happy to have you helping with bug management.
<lifeless> dholbach: things that are useful are reviewing bugs from old versions to see if they are fixed,
<Mithrandir> doko: eh, yes?  I haven't replaced it, I've added it.
<lifeless> dholbach: and taking ownership of bugs (assigning them to you ;)) followed by a patch ;0
<Mithrandir> doko: if you want it done differently, you should either provide a diff, explain it properly or fix it yourself.
<lifeless> dholbach: take bug 1534 for example.
<lifeless> dholbach: its not listed as needing a fix in 'upstream bazaar'.
<lifeless> dholbach: requesting an upstream fix there would be a useful thing to do, as it would make it visible to us.
<dholbach> i see
<doko> Mithrandir: sorry, that's not the tone I would expect. the java stuff is called as an external process, and it's used by dlopening libgcj. So we need both, not an alternative. The changelog doesn't say so.
<fabbione> lifeless, dholbach: can you please stop playing ping pong with the bugs i did open in malone?
<fabbione> they are either assigned or not
<fabbione> lifeless: also.. why should they be unassigned?
<dholbach> fabbione: i wanted to assign them to the team, but lifeless didn't like that - he wants upstream bugs not ubuntu bugs
<fabbione> lifeless: they clearly are upstream bug dude.. did you at least read them?
<lifeless> fabbione: team assignments are useless.
<dholbach> fabbione: sorry for flooding your inbox - i thought it would help in the process
<fabbione> the fact that they arrived as ubuntu is becauseat the time there was no clear idea on how to use malone
<lifeless> fabbione: they mean nothing, we need individual assignment.
<lifeless> fabbione: thats fine, this is nothing to do with the bug content, its to do with the workflow for getting them fixed.
<lifeless> and assigning to team ensures they will be ignored violently.
<Mithrandir> doko: there's no way to express that in the packaging system.
<lifeless> because folk look for unassigned bugs, and bugs assigned to them individually. 
<Mithrandir> doko: you can't say "use ( lib32gcj6 and java-gcj-compat ) or j2sdk"
<lifeless> the Right Way to say 'upstream need to deal with this' is to request an upstream fix, and sure - they way they were entered may be improvable, but it doesn't change what we currently see.
<doko> Mithrandir: lib32gcj6 | j2sdk, java-gcj-compat | j2sdk  comes close.
* madduck eyes the MSN spaces logo...
<madduck> that's a pretty obvious plagiarism...
<madduck> canonical should sue their asses!
<Mithrandir> doko: why doesn't lib32gcj6 depend on java-gcj-compat if it's needed?
<doko> Mithrandir: it's not needed. It would be needed, if we had a 32bit gij-4.0 on amd64.
<Keybuk> madduck: *shrug* we don't actually know who invented their logo first
<Keybuk> it'd be fairly ironic to go blasting in with all guns blazing, to discover that they commissioned it four years ago and only just got around to using it
<Keybuk> and then have to change _our_ logo
<lifeless> msn spaces ?
<Mithrandir> lifeless: spaces.msn.com
<madduck> lifeless: spaces.msn.com
<lifeless> holy shite
<lifeless> thats uncanny
<Mithrandir> doko: first you're saying that's it's needed, then that it's not.
<Keybuk> lifeless: did you not see that last year when it got noticed?
<sivang> pitti: how can I see the new build log of gnome-panel ?
<pitti> sivang: http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/g/gnome-panel/2.11.92-0ubuntu5/gnome-panel_2.11.92-0ubuntu5_20050830-0838-i386-successful.gz
<pitti> daniels: ah, new dbus - sync was not possible?
<sivang> pitti: yay :)
<madduck> Keybuk: ah, so this has been known for a while?
<Keybuk> madduck: yeah, 6mnths to a year
<madduck> ic
<Keybuk> it could also be simply parallel evolution
<madduck> come on...
<sivang> pitti: btw, why does it have hwdb is as it's virtual host? :)
<Keybuk> it's not exactly a non-obvious logo
<madduck> either they copied from ubuntu, or the dude who did the ubuntu logo "got inspired" by them.
<madduck> Keybuk: it's the exact same concept, size, orientation.
<doko> Mithrandir: no, OOo2 uses java in two ways. One way is to dlopen the libgcj library. For that case we need the lib32gcj6 library. In the other case, it's calling gij (separate process), using the native 64bit libgcj6.
<pitti> sivang: it was just available for it :-) it's ogra's private nice hack
<madduck> Keybuk: but let's not waste our time over this.
<Keybuk> the orientation is actually not an accident
<madduck> Keybuk: rather, let me ask some hct questions...
<Keybuk> just about every other way up, it looks like one guy is on top, or one is the bottom in a threesome
<Keybuk> it's about the only way you can draw that without it looking silly :p
<madduck> Keybuk: :)
<madduck> Keybuk: mirrored along the vertical axis would work.
<Keybuk> then it'd look like the Canonical logo
<madduck> Keybuk: so hct... you read?
<madduck> ready
<Keybuk> sure
<madduck> Keybuk: aegis has this great concept of associating workflow states with changesets
<madduck> and someone said that hct does that too.
<Keybuk> how do you mean?
<madduck> you can flag a changeset (new, under inspection, testing, final, ...)
<Keybuk> there's support for that kind of thing in Launchpad
<madduck> and then you can e.g. get a snapshot of the tree with only final changeesets
<madduck> launchpad... for issues, yeah.
<Keybuk> but only at the branch level, iirc
<madduck> no, i mean in the SCM
<madduck> yeah, and at changeset level.
<madduck> so nothing in hct?
<Keybuk> nope, nothing like that in hct
<Keybuk> it'll probably support the lp branch label stuff, when we can come up with some use cases for it
<daniels> pitti: haven't looked at it yet, tbh
<madduck> lp?
<Keybuk> launchpad
<madduck> doh
<daniels> pitti: i have syncing with debian on my agenda for dbus and mesa though
<Keybuk> hct doesn't really work (despite its name) at the changeset level
<Keybuk> it does the exact opposite; it works with collections of inter-related branches
<Keybuk> an hct operation might be "take what's new in the equivalent RedHat source package and add it to my local one"
<Keybuk> though it's obviously moving changesets about underneath, it doesn't talk about them to you
<Keybuk> it talks about new patch branches, and stuff
<Keybuk> it says "Debian added 04-fix-something-silly.patch" rather than anything else
<carstenh> hmm, i remeber to have seen a filename like this in a debian source package
<madduck> Keybuk: and what is sourcerer?
<carstenh> a bit different, but debian floks seem to like the word silly: ./iptables-1.3.3/patches/s390/005-atomic_t_silly_hack.patch
<Keybuk> sourcerer is the source-package import tool
<daniels> jdub: so, uhm
<madduck> import to the supermirror?
<madduck> Keybuk: ?
<daniels> jdub: could you please edit /var/cache/debocnf/config.dat, and change the seen flag of xserver-xorg/config/modules to false?
<daniels> jdub: then reconfigure, and see if you get a proper modules section again
<Keybuk> madduck: import into baz archives
<Keybuk> as well as linking up the dots to previous imports, upstream tarballs, cvs, etc.
<madduck> ah, ok. with the hct-style branches?
<madduck> so sourcerer actually calls dpkg-source?
<Lathiat> sourcerer? heh
<dholbach> brb
<Keybuk> no, it has it's own implementation of it (la la la, See Keybuk NIH)
<madduck> Keybuk: will hct be any useful without the super mirror?
<daniels> Keybuk: you're even worse than KDE
<Keybuk> madduck: it's not useful without Launchpad or source packages imported with Sourcerer
<Keybuk> at some point it'll grow a "start a new source package" mode, but it doesn't have that yet
<madduck> Keybuk: and if it starts a new source package, how does it do it then? indpendently from launchpad?
<madduck> i am asking because while hct looks promising, it's very ubuntu-centric. i am investigating a way to do something similar for debian, but without the requirement for a centralised architecture...
<Keybuk> it's initially ubuntu-centric, yes
<Keybuk> though it's designed to be useful for everyone
<Keybuk> the requirement for a centralised architecture is necessary, because unless you co-operate on file-ids each system wouldn't be able to share patches
<Keybuk> if your Debian baz archives for pmount use different file-ids than Ubuntu's baz archives -- you can't swap patches
<hunger> Is launchpad down?
<lifeless> Keybuk: no I didn't
<Keybuk> lifeless: tsk, you need to spend more time reading e-mail, or something
<lifeless> !
<lifeless> is there a tool to complement dchroot that setups the config file and chroots ? Perhaps a wrapper around debootstrap ?
<fabbione> lifeless: i don't agree with the way you handled 223
<fabbione> lifeless: given that it is a bug
<fabbione> noise in BTS is normal
<lifeless> noise in BTS is harmful, and not normal.
<fabbione> or you prefer to hide problems to users and get duplicates?
<lifeless> I'm not deleting the bug description, or removing it from the db.
<lifeless> I'm marking it accurately.
<fabbione> REJECTing a bug means saying that's not a bug..
<lifeless> but if you want to reopen it again in ubuntu, sure, I won't turn this into a bts war
<fabbione> so either malone needs a more appropriate status
<fabbione> or it has to stay as NEW
<lifeless> its not new, its been triaged, and an action decided.
<fabbione> lifeless: the bug is not ubuntu specific..
<lifeless> if it was bugzilla, I'd say 'wontfix'
<lifeless> perhaps you could file a bug on malone if you feel strongly about this.
<dholbach> morning ogra
<ogra> wow, who made this new usplash graphics ? 
<sladen> andyf I think
<ogra> its really cool...
<ogra> sadly my widescreen display streches it 
<kronoss> where can be seen the new graphics?
<ogra> kronoss, dont you read ubuntu-devel ?  there isa step by step guide
<mvo> mjg59: should new usplash bugs be assigned to you?
<mvo> ogra: it's pretty cool the new usplash!
* ogra guesses mjg59 is still asleep.... i saw him around 4:30am before i wen to bed
<ogra> yeah
* pitti tests new usplash
<pitti> hmm, is that just me, or does usplash drop back to text mode *very* soon again?
<mvo> pitti: I have it until X is started here
<pitti> mvo: hm, that looks like a bug then; thnaks
<Lathiat> drops back into text mode fairly soon here too..
<Lathiat> or at least it used to
<Mithrandir> jbailey: I'll chuck 14239 in your direction; I think it's initramfs-related.
<mvo> fabbione: could you please test traceroute on your sparc and tell me if it faults with a bus error? a traceroute www.debian.org should be enough
<carlos> mvo, hi, around?
<mvo> carlos: yes
<sladen> pitti: there's a watchdog of about 10seconds
<carlos> mvo, I need that you change the synaptic's po directory layout
<sladen> pitti: eg. fdisk 
<pitti> sladen: hm, no init script takes so long for me
<mvo> carlos: in what way and why? isn't it a fairly standard layout?
<carlos> mvo, instead of having two .pot files there, please, create a po-manual or manual-po or something like that and move there that .pot file
<carlos> mvo Rosetta is not able to handle directories with multiple .pot files and that's preventing to have breezy's synaptic imported into Rosetta
<mvo> carlos: rosetta does not like two pot files in the same dir?
<carlos> mvo, we will add that support in the future, but I don't think we will have it before breezy
<mvo> carlos: ok, I'll have a look today. it's a bit of a pain this xmldoc stuff, I'll see what I can do
<carlos> mvo, thank you very much
<mvo> carlos: how did that work before btw? my layout didn't changed in quite a while
<carlos> mvo, that's new for breezy, right?
<carlos> mvo, we don't have any breezy version imported for synaptic I just detected it because an user asked me for synaptic
<mvo> carlos: oh, ok
<carlos> mvirkkil, thank you
<mvo> can I just close auto-imported bugs from debian that do not affect our release-architectures? (we have two major bugs open that seems to only affect sparc)
<ogra> pitti, are you sure you use the latest usplash (did you regenerate the initrd ?)
<koke> mvo: BTW https://oops.kerneljanitors.org/repos/synaptic fails :(
<koke> I guess spanish translation is outdated
<mvo> koke: yes, I send a mail to the administator of the machine
<JaneW> BREEZYGOALS - are there any new status updates to the BreezyGoals? Some are still listed as WIP, even though the Preview Freeze is in 2 days time....
<mvo> I want to have it in baz, but apparently the import keeps failing
<koke> mvo: are you the current maintainter of gnome-app-install in gnome-cvs?
<janimo> mdz, ping
<mvo> koke: yes, but the current development is happening in baz
<chmj> shackan: ping 
<koke> mvo: I know, but translation is happening in cvs
<mvo> koke: yes, that's pretty bad. I need to reimport the current code into cvs
<koke> ok, but it's string freeze now, isn't it?
<mvo> koke: yes
<sivang> JaneW: did you get an update about lpint ?
<LaschW> producer preinstalation framework? Are there any plans for a producer preinstallation framework for breezy which will be offererd to hardware vendors??
<JaneW> sivang: no...
<Diziet> mdz: ping
<mvo> Diziet: he's probably sleeping
<dholbach> ha... lunch :)
<mvo> hmmm, lunch
* pitti gets hungry from so many people talking about lunch
<Mithrandir> LaschW: yes.  OEMInstall
<LaschW> Mitario: Ahh, thats what I'm looking for. Is there a place where I may find more infos?
<LaschW> Mithrandir:  Ahh, thats what I'm looking for. Is there a place where I may find more infos?
<Mithrandir> LaschW: https://wiki.ubuntu.com/OEMInstaller is the spec
<LaschW> Mithrandir: Thanks! Seems to be in a very early state?
<Mithrandir> LaschW: it should be implemented, but I don't know if anybody has used it yet.
<elmo> doko: ?
<Mithrandir> LaschW: Colin Watson is the guy who've been working on it, he doesn't seem to be around now (I though he should be back today, but apparently not).  You might want to chat with him.
<LaschW> Mithrandir: I'm discussing this with a hardware vendor in the moment. Seems that they are interested in such a tool.
<Mithrandir> LaschW: excellent!  We're very much interested in getting into touch with vendors who want to preinstall Ubuntu.
<LaschW> Mithrandir: Me too. I'm looking for a job and that might be a chance to get a foot on deck...
<doko> elmo: pong
<elmo> doko: is calling this package  python-pylib really appropriate?  it seems to stomp all over the python namespace
<elmo> doko: and the README.Debian is kind of lame - I don't know if it ends up getting installed or not tho
<slomo> elmo: any news with Mitario's, ivok's and my upload rights?
<doko> elmo: the package is requested by salgado, I know, that whole package looks insane, no wonder that nobody did try to package it. it doesn't bloat the namespace however. each and every module is contained in the 'py' package, so you have to explicitely import 'py.*'
<elmo> doko: sorry I don't mean python namespace, I really mean debian packaging namespace
<elmo> slomo: I'll look at it when I'm caught up
<ivoks> elmo: thanks
<slomo> elmo: thanks :)
<ivoks> now we are intrusive :)
<doko> elmo: I don't know, how to name it else... the author writes about it as a bunch of useful stuff ... any other suggestions? (http://codespeak.net/py/current/doc/)
<ogra> elmo, any idea why libxp doesnt show up in the archive ? http://archive.ubuntu.com/ubuntu/pool/universe/libx/libxp/ according to the logs it has built ages ago http://people.ubuntu.com/~lamont/buildLogs/libx/libxp/6.2.0-0ubuntu1/
<ogra> Kamion, !!
<ogra> Kamion, congrats etc...
<Kamion> hi, thanks
<elmo> ogra: becuase siretart uploaded the source with a lower version than the current binaries
<mvo> hey Kamion, welcome back!
<Kamion> looks like I'll be spending the guts of today sorting through e-mail
<ogra> argh
<elmo>      libxp | 6.2.0-0ubuntu1 | breezy/universe | source
<elmo>     libxp6 |   6.8.2-10 |         hoary | amd64, i386, ia64, powerpc, sparc
<siretart> whops
<mvo> elmo: can you please sync scite from debian? 
<ogra> heh
<siretart> elmo: so I'll reupload with an epoch?
<ivoks> siretart: you stilly man :)
<elmo> siretart: a higher version number somehow; not sure if an epoch is appropriate or not
<ogra> siretart, only with a higher number
<elmo> epochs are for life, not just for christmas
<ogra> evil
<elmo> mvo: done
<siretart> ah. ok. will do. sorry for the mess
<mvo> elmo: thanks :)
<doko> Mithrandir: OOo2 amd64 loads, but I only see the non-gnome skin, although the OOo2-gnome package is installed
<Mithrandir> doko: what does ldd /usr/lib/openoffice2/program/libvclplug_gtk680li.so| grep -i found say?
<siretart> elmo: could you please sync java-package (for more jdk supported) and arch-buildpackage (for better baz support) from unstable?
<doko> Mithrandir: libcairo.so.2 => not found
<ogra> Kamion, we'll have a lot to sort for the edubuntu CDs this week (just a warnig :) )
<sivang> JaneW: besides two more packages, the spec is done - I updated the wiki page for it, you can look at it and see what's done. I mailed seb last week about the gimp, and I can take care of the other remaining package if this can expemt from FF
<fabbione> Hey Kamion !
<sivang> Kamion: YO! :)
<sivang> Kamion: did you enjoy your vacation?
<pvanhoof> Current rhythmbox is extremely unstable (in breezy)
<pvanhoof> as in .. unusable unstable
<Mithrandir> doko: weird; I wonder why it's trying to get libcairo2 for you; here it's libcairo1
<Mithrandir> doko: I'll see if I can reproduce it
<Kamion> ogra: sure
<ogra> Kamion, :)
<Kamion> sivang: definitely
<doko> Mithrandir: old references to libcairo1? that one cannot be built anymore in breezy
<Mithrandir> doko: so? :-)  It's still in ia32-libs, iirc
<dholbach> have a nice day
<sivang> Kamion: cool, btw - it seems we've figured the right flags to pass mkisofs for pSeries booting, I am going to test them when I get my local mirror complete. (currently downloading) the trouble is, I wasn't able where in CONF.sh I can add those..(talking about debian-cd)
<dholbach> *wave*
<ogra> hmm, damned, after dpkg-reconfigure linux-image-`uname -r` my ltsp server tries to netboot now.... something is very wrong here...
<Kamion> sivang: not CONF.sh; just edit tools/boot/breezy/boot-powerpc
<Mithrandir> doko: bingo, I see it too.  Thanks.
<sivang> Kamion: set_mkisofs_opts file is also of no relevance ?
<elmo> siretart: debian doesn't have a java-package newer than 0.24
<elmo> 0.25 sorry
<jbailey> Mithrandir: Cool, looks like missing driver.
<Mithrandir> elmo: could you please sync mercurial from Debian?  It seems to be missing in breezy.
<elmo> Mithrandir: done
<elmo> siretart: arch-buildpackage done
<Mithrandir> jbailey: yeah, I figured it'd be something like that, but you know the code way better, so easier for you.
<Mithrandir> elmo: excellent, thanks.
<siretart> elmo: sorry, it is still in incoming.debian.org/java-package_0.26.dsc
<siretart> I mixed up the debian dinstall run
<jbailey> Mithrandir: Yup.  In the next version of two, I'm going to add a HACKING file with clearer instructions as to what's where.
<elmo> siretart: done
<sivang> Kamion: in boot-powerpc you have $N.mkisofs_opts , do you just echo the flags there as it seems from the script?
<Mithrandir> doko: hmm, even with nothing missing, it doesn't look very good :-/
<JaneW> sivang: ok thanks - did seb respond?
<sivang> JaneW: not yet, he is on vacation IIRC
<sivang> JaneW: should be back tommorow, IIRC :)
<siretart> elmo: thank you very much. I owe you much more than a beer (or othere preferred beverage)!
<Mithrandir> doko: does http://err.no/tmp/ia32-libs-gtk_7_amd64.deb fix it for you?
<pitti> re
<pitti> Hi Kamion, welcome back!
<Diziet> Dammit, Debian's various gs 8's have crashy problems in ppc too.
<Diziet> And I'm forgetting to have lunch.
<Mithrandir> doko: if that fixes it for you, I'm going to upload that.
<doko> Mithrandir: that does work, but I still see the white text on a grey ground. did you add the gtk themes, as martink suggested?
<Mithrandir> doko: no, I didn't pay well enough attention; where was that?
<Mithrandir> s/well/good/
<doko> http://people.ubuntu.com/~doko/Screenshot.png
<Kamion> sivang: right
<doko> martink: what was your other suggestion with setting some environment variable?
<Mithrandir> doko: the suggestion from martink, not the bug. :-)
<doko> ahh, I think, adding the .so from the thinice(?) theme?, then he suggested setting a GTK_THEME_PATH variable (or something like that). I don't remember ...
<Mithrandir> was it here, or somewhere else?
<Mithrandir> here as in #ubuntu-devel
<doko> here
<Mithrandir> doko: yay, that fixed it.
<doko> Mithrandir: nice :)
<martink> clearlooks, not thinice ;)
<Mithrandir> doko: uploading ia32-libs-gtk_7 now, please test and give feedback.
<Mithrandir> martink: yeah, I picked clearlooks.
<JaneW> BREEZYGOALS - are there any new status updates to the BreezyGoals? Some are still listed as WIP, even though the Preview Freeze is in 2 days time....
* pitti has made his peace with his goals
<sivang> Kamion: k, thx
<JaneW> pitti:  yeah yours are looking GOOD. :)
<JaneW> pitti: in fact would you like some more? *run*
<pitti> JaneW: I already have enough bugs, thanks :-)
<mpt> pittti: Should the event-notifier idea described in http://lists.ubuntu.com/archives/ubuntu-devel/2005-June/008392.html become a UBZ BoF? or is it already implemented/obsolete?
<pitti> mpt: I would love to get a BoF for it
<Mithrandir> guifications3  should be able to be a all-singing, all-dancing notification thingy.
<Robot101> watch out for guifications, it might be on complete crack
<JaneW> pitti: darn, ok
<Mithrandir> Robot101: nah, grim is fairly sane and a good programmer.
<Robot101> Mithrandir: it looks very overengineered for a "show foo to the user" system :P
<Robot101> Mithrandir: I prefer the look of the libnotify/notification-daemon stuff
<Mithrandir> Robot101: slightly, possibly.  But it's really cool, too.
<Robot101> although I don't know what the fashion of the minute is in GNOME
<Robot101> they're flaming about it I think
<mpt> mmm, guifications looks nice (at least on the screenshot level)
* mvo reboots to test new usplash on his notebook
<mpt> more effective than trying to stuff notifications into a tiny panel, at least
<Mithrandir> mpt: I wonder if notifications can be (ab)used for general system monitoring stuff as well; "your ~ is nearly full" and so on.
<ogra> Mithrandir, YES !!!
<mpt> Mithrandir: Definitely
<ogra> but you can already do this with zenity ....
<Mithrandir> mpt: but those should be visible for different users, and be some kind of sticky.
<mpt> I've just been suffering that in OS X, which is throwing up alerts telling me my HD is nearly full when I'm in the middle of something mouse-intensive
<ogra> it has notification opportunitys since ages
<mpt> It's good that it's telling me, not so good that it's in an alert
<sivang> Mithrandir: are you working on imelementing that ?
<sivang> Mithrandir: sounds cool
<mpt> Mac OS 8~9 used little yellow floating windows for things like that
<Mithrandir> sivang: I'm just packaging guifications, I'm not a developer on it.
<ogra> sivang, there are several frontends... whats missing is a backend
<sivang> ogra: ah I see, and guifications is frontend to ?
<ogra> zenity, guifications, notification-daemon, event-notifier....
<lu|sleep> so, does n-m bounce the network like a cheap whore for anyone else?
<ogra> all there waiting for your input :)
<sivang> ogra: sure and they are all frontends to inotify?
* ogra gave up on MN
<ogra> NM
<Mithrandir> sivang: guification is a framework for doing it.
<ogra> sivang, what has inotify to do with that ? 
<sivang> Mithrandir: k
<sivang> ogra: you said those were all frontends, who's the backend?
<ogra> sivang, inotify is a kernel interface...
<ogra> [14:47]  <ogra> sivang, there are several frontends... whats missing is a backend
<sivang> ogra: i know, I though those were used as frontends to that kenrel interface at thge backend
<sivang> ogra: DoH ! :_
<ogra> write one :) 
<sivang> ogra: gotta learn to read between the lines...
<sivang> ogra: gotta spec it first :)
<ogra> something for UBZ then :)
<sivang> ogra: so currently, what do they use as their current backends? (I mean, we do have some of them on our desktop)
<ogra> sivang, whatever wants to send a notification to the user....
<ogra> we dont have much yet on our desktop... 
<ogra> the update-manager/notifier stuff, gnome-power uses it... i'm not aware of anything else currently
<sivang> ogra: I see, so we need a unified backend that exposes the same API and request events, instead of waiting to recieve them?
<ogra> they all have these backends
<ogra> there is just not much what uses them
<ogra> s/backends/APIs
<ogra> sivang, we only need apps that feed them... 
<mvo> ogra: pitts detection of additional usb audio hardware uses it too afaik
<ogra> i.e. a diskwatcher app that monitors your disk via inotify and sends a warning to notification-daemon
<ogra> at a certain amount of disk usage...
<sivang> ogra:so  apps = backends?
<ogra> mvo, oh, yes... i seldom change audio devices over here....
<mvo> heh, same here
<ogra> sivang, you got it :)
<ogra> sivang, notification-daemon and friends are just tools waiting for input... but there is not much that feeds them...
<ogra> and the final decision what wil enter upstream is still going on afaik
<sivang> ogra: I'm dum, but when explained slowly I get things :)
<lu|sleep> j^: have you had reports of network-manager taking the wireless connection down every few minutes? Just for a few seconds each time, but long enough to be spectacularly irritating
<doko> mvo: apt-listchanges does segfault on amd64
<mvo> doko: every time? or only in a minimal chroot?
<infinity> doko : Same thing on i386, but he can't reproduce it.  It's also not apt-listchanges, but python2.4-gtk, afaict.
<infinity> doko : I can segv with just "python ; import gtk"
<j^> lu|sleep i read about that on the network-manager list, it might be a problem with some wifi cards, do you have an a/b/g card?
<sivang> ogra:<simpletone mode> so we need a list of stuff most wanted by people that want to know about their systems, and seek implementation. </simpletone mode>
<infinity> mvo : It's in my base system where it segfaults, in the minimal chroot, it hangs but doesn't die.
<lu|sleep> j^: atheros, which I'm pretty sure has no g
<lu|sleep> but I might be wrong on that
<mvo> infinity: it does segfault on your normal install?
<infinity> mvo : Yes.
<j^> lu|sleep if you right click the applet and switch off scanning it should stop disconnecting
<luis_> hrm
<j^> right there are issues with atheros
<mjg59> atheros can't scan while associated
<infinity> mvo : Also, the core from that "import gtk" is just a few thousand lines of obviously very smashed stack, so not very helpful. :/
<mjg59> So presumably it's decided that dropping the interface to scan is sensible
<mjg59> Rather than, say, cracked in the head
<luis_> I don't have the applet running, since it fails to find the system dbus (looks for it in my jhbuild root for some reason)
<mvo> infinity: hrm, I can't reprdocue it on my two systems here (up-to-date breezy, upgraded today) :/
<infinity> mvo : Want an ccount on a machine where it's happening?
<j^> luis_ well you have to install dbus service files for NM
<j^> in ubuntu that is in /etc/dbus-1/system.d/
<j^> NetworkManager.conf and nm-applet.conf
<mvo> infinity: maybe, probably
<luis_> j^: they are installed; I assume you mean I can edit them to point at the proper system bus?
<j^> luis_ right, if nm-applet can not talk to NM via dbus, your dbus instance might not have picked it up
<j^> or you are not in the plugdev group
<jdub> untz untz untz
<jdub> hey hey j^
<j^> hey jdub 
<sivang> yo jdub 
<j^> jdub http://revu.tauware.de/details.py?upid=514
* mjg59 uploads sexy irda-utils autoconfig goodness
<mjg59> If people could test that when it hits the archive, I would love them forever
<jdub> mjg59: woo
<jdub> mjg59: usplash looks a bit funny on my desktop
<jdub> mjg59: non-black border (easy fix), also looks a bit uncentred
<jdub> the border only appears at top and left
<mjg59> jdub: Ok. I think we'll need to shift black to colour 0.
<mvo> mjg59: it seems to be not working on my X30 (but it may be me)
<mjg59> mvo: usplash?
<mvo> mjg59: yes
<sivang> jdub: I'm preparing a local mirror, when gonna try plunge tgall's flags into debian-cd and see waht comes out :)
<jdub> mjg59: black or bg?
<Mithrandir> jordi: is it on purpose that movemail isn't sgid mail?
<mjg59> jdub: Background
<jdub> sivang: cool
<mvo> mjg59: I used to boot with vga=771, but I removed the vga line and I botted with 785 as welll without getting a splash
<mjg59> mvo: You've installed usplash and regenerated your initramfs?
<Mithrandir> pitti: would you be ok with movemail (in mailutils) installed sgid mail?  it's fairly useless without that bit.
<j^> it works on my x30, but its only a 640x480 image on a 1024x768 screen
<mjg59> j^: Yes, that's correct
<j^> mjg59 its also small
<pitti> Mithrandir: right; there was a recent vuln in that, but I asked for sync
<mvo> mjg59: yes, usplash is 0.1-6 (as on my other machine where it works fine). I'm regenerating my initramfs again 
<jdub> mjg59: also, i'm getting an error on the 'generating console font' thigny
<ogra> j^, it uses vga16fb ....
<Mithrandir> pitti: it's universe, though.
<Mithrandir> pitti: and I haven't audited it, just asking first.
<pitti> Mithrandir: right, but I don't care about universe :-)
<pitti> well, at least not at the level I care for main
<mjg59> j^: We either have small usplash or we have non-working suspend
<Mithrandir> pitti: mpe.  :-)  I was more interested if you were going to run screaming away or if it was on the level of "sure, whatever". :-)
<mjg59> jdub: Yes, I need to look into that
<mvo> jdub: that error is reported as #14350
* j^ goes in the sun and dreams of bootscreens like http://www.neystadt.org/john/album/London2003/DSCN1246-London-Eye-Wheel.JPG
<pitti> Mithrandir: the latter :)
<ogra> j^, fix the heardware vendors ;)
<ogra> hardware even
<j^> mjg59 i am more interested in suspend(though i still use apm) than i am in a bootsplash
<mvo> j^: acpi s3 works pretty well on the x30 these days
<j^> thanks the the former i do not see the second that often
<jdub> mvo: aha!
<j^> mvo better than apm?
<mvo> j^: I think so, yes. 2.6.12 comes back very quickly from sleep. you need to pass acpi_sleep=s3_bios on the kernel commandline though
<mvo> mjg59: should #14350 be assinged to you?
<j^> mvo no problems with broken X after resume?
<j^> no hang every 10th suspend?
<mvo> j^: no, I used it daily, travel with it etc. works really well in my experience
<j^> i think its suspend with ethernet cable, resume without. bang!
* j^ tries
<zul> what kind of network cable?
<zul> grrrr...network card
<mjg59> mvo: It's a duplicate
<j^> zul e100
<jordi> Mithrandir: could be an oversight from the move to cddbs
<j^> but it works right now with apm
<jordi> can you fil a bug?
<Mithrandir> jordi: it appears that it can call out to dotlock, but doesn't.
<Mithrandir> jordi: (which is sgid mail)
<jordi> is this 0.6.90?
<Mithrandir> yes.
<Mithrandir> (or, 1:0.6.90-1)
<jordi> hmm, -2 should have important fixes for imap4d
<jordi> just for the record :)
<Mithrandir> jordi: ok; so we want to sync that?
<jordi> let me check something.
<jordi> is MU in breezy, or universe?
<pitti> jordi: both :-)
<Mithrandir> jordi: universe
<jordi> i meant main :)
<jordi> Mithrandir: -2 should be good
<jordi> I seem to have -3 unreleased with a related fix for the testsuite, but it's not important
<Mithrandir> hm, should we wait for that?
<jordi> I could upload right away.
<jordi> +  * debian/patches/05_imap4d_bad_uid.patch: fix the imap4d testsuite to
<jordi> +    match the uid behaviour.
<jordi> it's just this
<Mithrandir> ok, goodie.  And then please get it synced. :-)
<jordi> I'll say here
<jordi> Mithrandir: why do you say movemail should be sgid?
<Mithrandir> jordi: how is it going to dotlock else?
<jdub> I HATE THE LINUX AUDIO STACK
<jdub> LET US BURN IT INTO THE GROUND
<lu|away> get thee to a real desktop OS
<jdub> AND LET A BEAUTIFUL PHOENIX RISE
<ogra> jdub, complain at pitti ;)
* pitti protects his ears and agrees to jdub
<jdub> no, it's not his fault
<jordi> oh dude
<jdub> too many people shitting in the swamp for just one man
<jordi> I'm out of here
<jdub> (even if that man is the inimitable pitti)
<ogra> jdub, sure, he didnt rewrite it :)
<jordi> Mithrandir: yeah
<Treenaks> Wasn't ALSA supposed to be this phoenix?
<pitti> jdub: THEN GIVE US SOMETHING SANE, DUDE
<pitti> Treenaks: in a century, maybe
<Treenaks> pitti: urgh
<jordi> Treenaks: let's say it's taking some time to rise :)
<pitti> Treenaks: in fact it works quite well on the cards where it works at all
<pitti> Treenaks: unfortunately there are too many cards it doesn't work on...
<j^> mvo my x30 does not sleep if i press Fn-F4
<j^> and with acpi the disk is checkted even without power
<Treenaks> pitti: nice
<j^> mjg59 is it a known problem that uspalsh goes away at the time / is mounted?
<pitti> j^: see ubuntu-devel, happens to several people
<lu|away> gah.
<bddebian> Hello
<mjg59> j^: Make sure you have the latest lsb-base
<mvo> j^: hm, workf here (Fn-F4)
<j^> sudo /etc/acpi/sleep.sh also does nothing
<mvo> j^: oh, please have a look at /etc/defaults/acpi-support 
<j^> mjg59 lsb-base is 3.0-1ubuntu4
<mvo> there should be a ACPI_SLEEP=true in it
<jdub> j^: eh, rock! next stop, motu land! :)
<j^> mvo that helps indeed :)
<mvo> j^: :)
<pitti> Hi jbailey 
<jbailey> Heya Martin
<pitti> jbailey: "testhaus"?
<jbailey> pitti: my ia64 box is hosted at a university in Toronto, and that's the DNS name the sysadmin gave it.
<lamont-away> wb Kamion 
<pitti> jbailey: sounds German :-)
<pitti> Hi lamont-away 
<jbailey> pitti: I IRC from there when I might be rebooting a bunch so that I can run it in screen.
<jbailey> pitti: He might be.  Generally Russ and I speak French. =)
<Diziet> Is there anyone here who knows about alignment constraints on ppc ?
<jbailey> Diziet: To what level of detail?
<Diziet> The compiler aligns a jmp_buf to 16 bytes.  Is that necessary ?  An optimisation ?
<jbailey> Diziet: I think 16 byte alignment is required for altivec things.
<jbailey> So it's convenient to just do it all the time to save handling it if you're going through an altivec routine.
<Diziet> The gs source code (all versions AFAICT) makes (according to a comment) the assumption that sizeof(a struct containing a couple of shorts and a pointer has) % alignof(jmp_buf) == 0.
<jbailey> Err..  Have to ask doko to be sure - I didn't think there was a promise ever on struct size, just starting pointer...
<Diziet> The sizeof that struct is 8.
<Diziet> (according to gcc and gdb on davis's breezy chroot).  The alignof jmp_buf is 16.  So gs's assumption is false and the algorithm breaks.
<Diziet> I haven't looked at the gs code in enough detail (yet) to see if it really makes the assumption claimed in the comment.  It's quite complex.  But, there are at least two separate comments saying the same thing.
<jbailey> Diziet: Are they intentionally padding the struct somehow, or just hoping that nothing ever needs more than 8 byte alignment?
<Diziet> Hoping, AFAICT.
<Diziet> The 8-byte struct has a big union in it but none of the things in the union is a jmp_buf.
<Diziet> I can't see anything resembling a coherent justification for this assumption.
<Kamion> sivang: jdub referred me to the specification for /ppc/bootinfo.txt, so I'm adding that file to the CD images now
<Kamion> sivang: and the -chrp-boot mkisofs option, too. Do you have anything else I need to add?
<Diziet> The alignof jmp_buf is only relevant because jmp_buf is one of the things which can appear in some other giant union.  I think the assumption was probably reasonable before jmp_buf was added to that other union.
<jbailey> Diziet: What are they doing that requires them to know about the struct's alignment?
<jbailey> Seems like a strange requirement.
<jbailey> Or is just for feeding stuff into the union across multiple structs or something?
<Diziet> It has some very fancy memory management.  Justifiable in a PostScript interpreter, I think - I just wish they'd got it right.
<jdub> Kamion: ok, so you have the yaboot.chrp (addnoted)?
<Diziet> There's something odd going on here, actually.  I can't remember the exact rules but I thought the alignment constraints were supposed to be identical for all structs.
<jdub> Kamion: do we have both 32 and 64 bit kernels on the install disk?
<jdub> i guess that'd be pretty huge, with modules and all
<Kamion> jdub: yes, we have both, and yaboot is always 32-bit
<jdub> don't want to boot the appropriate one?
<Kamion> the addnote thing is a bit difficult at the moment since there's no addnote binary available on i386; would require some weird hacking
<Kamion> the appropriate what?
<jdub> 32 or 64 bit kernel
<jdub> maybe this is a suse hack
<Kamion> we don't attempt that on any architecture at the moment
<jdub> their yaboot will happily choose
<Kamion> sounds like a SuSE hack, ytes
<Kamion> yes
<jdub> image[64bit] =inst64
<jdub>   label=install
<jdub> etc
<Kamion> no support for that in our yaboot to my knowledge
<Diziet> No, in fact I'm wrong about structs.
<jdub> suse have so much crack
<jdub> tgall said they have some kind of console detection patch in their kernel too
<Kamion> that would be a useful thing to grab for our yaboot, probably
<Kamion> but not critical, so I think probably post-breezy
<jdub> yeah
<mjg59> Kamion: Hey 
<Kamion> sivang: -chrp-boot and /ppc/bootinfo.txt stuff committed to my debian-cd arch repository
<mjg59> Kamion: You've seen the bug report about the weird Toshiba that has Intel SATA RAID by default?
<hunger> Any chance of getting kernel 2.6.13 into breezy?
<pitti> hunger: nope
<mjg59> hunger: No
<mjg59> hunger: What's in 2.6.13 that you want?
<hunger> Too bad... then I have to stick with custom kernels for a while longer.
<Kamion> mjg59: #13506?
<fabbione> hunger: what do you need from .13?
<hunger> Longest Uptime I got with 2.6.12 is about 3h...
<fabbione> you didn't answer the question..
<Kamion> mjg59: I kind of failed to understand the bug, possibly because I have 900 other mails ;)
<hunger> fabbione: And that is with your breezy kernel which is *way* more stable than the vanila 2.6.12 for me.
<fabbione> hunger: and did you file a bug?
<mjg59> jkamYeah
<fabbione> do you get OOPS'es?
<Kamion> sivang: next CD images will have that, too
<fabbione> hunger: are you using binary modules?
<hunger> fabbione: I guess TG3 and SATA fixes.
<zul> hunger: hell no
<mjg59> Kamion: Oops. Yeah.
<fabbione> hunger: i use TG3 and SATA here...
<hunger> fabbione: I am doing so with my 2.6.13 kernel, but not with the breezy one.
<zul> hunger: same here
<fabbione> hunger:  16:23:32 up 9 days,  8:58,  9 users,  load average: 2.91, 3.88, 4.00
<fabbione> hunger: and no problem at all
<hunger> fabbione: I do not know what makes 2.6.13 work better!
<mjg59> Kamion: It's got an Intel BIOS that (by default) does SATA RAIDing
<mjg59> Kamion: So presumably the disk has some magic header 
<doko> Mithrandir: what about adding a dependency on lib32gcj6 in ia32-libs-openoffice.org ?
<mjg59> Kamion: It seems that we're not dealing with that. I guess it's something that device-mapper should be recognising
<j^> Diziet at http://revu.tauware.de/details.py?upid=514 / http://bootlab.org/~j/NetworkManager-breezy/ i have new NM packages
<hunger> fabbione: If I'd know what was wrong I'd have tried to fix it... or at least filed bugreports.
<mjg59> Kamion: As a result the partitioner isn't useful
<j^> there is some confusion about if and what the right way would be to get them into universe
<Kamion> mjg59: that or parted, I suppose
<Diziet> So you know we've given up on n-m for Breezy main ?  We're still planning to have it in Breezy+1.
<ogra> j^, no confusion... i just dont want to break stuff in advance :)
<mjg59> Kamion: Well, the partitions inside the RAID ought to look pretty normal
<Diziet> And I don't think that one will want BIND9.  It'll probably use some combination of resolvconf, dnsmasq and dbus.
<j^> ogra the last 4 days i was told to go the motu route. what you bring up now is at best confusion
<ogra> j^, to make sure that doesnt happen you and Diziet should coordinate your work :)
<j^> Diziet what is your current plan for NM?
<ogra> j^, sorry i had network probs the last week, i wasnt always around... who told you that ?
<Diziet> My current plan is to ignore it while we're in the middle of the Breezy crunch, but that's not what you meant :-).
<Lathiat> ogra: oh you got your dsl fixed? ;p
<j^> ogra jdub, slomo and others
<ogra> Lathiat, its still not suitable to upload iso images :)
<Lathiat> ogra: heh
<jbailey> ~[6~[6~[6~/win 7
<jbailey> Feh
<Lathiat> jbailey: dont you hate that
<Lathiat> jbailey: damn paste detection
<ogra> jdub, ?
<jdub> ogra: yeah
<jdub> ogra: what's the confusion here?
<Lathiat> so.. i have a 5 page document from customs all of them telling me i owe them money... yet not anywhere can i see where to actually send said money
<pitti> ah, seb128 seems to be back :-)
<ogra> jdub, j^  works on a vanilla NM package he wants to get into universe... i know that the package we'll have in main in breezy+1 will have quite intrusive changes... i try to get both worlds together now
<ogra> jdub, Diziet is working on it for main
<jdub> ogra: i can't see why we'd have intrusive changes, personally
<jdub> but regardless,
<jdub> j^ has done extremely awesome work
<jdub> it should be in universe
<Diziet> So re n-m, the idea /I/ have is that in Breezy+1 we'll be using n-m and dnsmasq.  resolv.conf will mention only the local dnsmasq and n-m will drive dnsmasq somehow (either resolvconf or dbus).
<infinity> Diziet : How do you propose to get bind9's network views (for VPNs and such) without using bind9?
<ogra> jdub, might be... but can you guarantee that a breezy+1 version Diziet reworked for us wont break all network setups out there ? 
<jdub> Diziet: i don't think dnsmasq buys us anything
<Diziet> It buys us not having BIND9.
<jdub> ogra: no, but that doesn't matter
<Lathiat> Diziet: but you add dnsmasq
<j^> bind9 is in main
<jdub> Diziet: that is not useful
<Diziet> dnsmasq has some simple support for sending different queries to different places, AFAIAA.
<Diziet> Not having BIND9 isn't useful ?
<ogra> jdub, its still scheduled for breezy+1 so i'm carefull about such stuff
<infinity> Diziet : What do you fear from bind9?
<jdub> ogra: there's no need - it's in universe
<Diziet> I've seen the source.  300kloc !
<j^> if dnsmasq it would have to be the dbus enabled version which is currently worked on
<ogra> jdub, exactly... ;)
<j^> resolvconf is out again
<Lathiat> ogra: why shouldnt we have working network-manager packages now for unvierse, just because we have plans for breezy+1...
<j^> i do not see any place for resolvconf
<jdub> ogra: we ought to get it in now, get people who care to test it in preparation
<Diziet> I don't have an opinion about resolvconf vs dbus atm.  resolvconf did seem slightly less edificial.
<ogra> Lathiat, i dont say we shouldnt have them, i say plaese coordinate the work between universe and main
<siretart> Diziet: do you have any and if yes, what objections do you have about j^'s package for universe?
<Lathiat> j^: so that your 127.0.0.1 isnt broken by some other package updating it
<ogra> jdub, i'm not opposed to that... i'm just missing communication
<Diziet> Do I have any what ?
<Lathiat> since afaict pretty myuch everything usefull in debian suppots resolvconf
<ogra> Diziet, objections
<Diziet> OIC.
<Diziet> The standard way that resolvconf is supposed to work is totally broken.  You can't update resolv.conf on the fly like that and expect it to work.  All of that stuff about going and poking various applications is never going to get all of them and the result will just be flakey.
<Diziet> But that doesn't mean we can't use it as an interface to drive dnsmasq.
<jdub> Diziet: upstream have chosen to use bind for very good, thoroughly well discussed reasons
<jdub> tossing bind (which will be the maximally tested configuration) for religious reasons is not all that sensible
<Diziet> I haven't looked at j^'s package for universe.  Are you asking me to review it ?  The real question is how badly things will break if and when we do something different in Breezy+1.
<jdub> (i trust bind9 more than i trust other dns servers)
<Diziet> jdub: I don't have time to get into BIND9 vs. XYZ right now.
<jdub> if we need to do something different in breezy+1 (and i guarantee you n-m will be changing in the mean time anyway), we can say:
<jdub> a) n-m was in universe so we don't have to support upgrade issues
<jdub> b) it's unlikely we're going to change anything that would effect the user-side configuration anyway
<jdub> so stonewalling on putting it in *universe* for breezy seems like pointless wheel-spinning
<siretart> Diziet: if you are intersted, j^ package can be seen here: http://revu.tauware.de/details.py?upid=514 
<Diziet> I'm new here; the reason I'm hesitating giving my blessing is because I don't know really what the policy is.  Bear with me a moment while I get a handle on things, please ?
<siretart> I think we should either remove n-m from breezy/universe now or take j^ updated package
<ogra> siretart++
<Diziet> n-m in breezy/universe atm is pretty damn broken, certainly.
<siretart> Diziet: sorry. I didn't want to do any preassure on you. take as much time you need to review and consider all opinions
<eruin> will gtk 2.8.3 make it into breezy?
<elmo> hmm, someone upgrading from hoary is going to download oo1 from universe; I wonder if that's desirable and/or fixable
<Kamion> it's true that it's officially Not A Problem (i.e. not release-critical) if upgrades from stuff formerly in universe fail; OTOH I'd still consider it a bug for that to happen, and I think it would depend on the severity of the upgrade breakage
<elmo> eruin: if it's part of gnome 2.12, it will, yes
<jdub> underneath all of this is the continuing in-development nature of n-m - things *will* change
<Kamion> i.e. if it's breakage that tells you that the upgrade isn't supported and you need to do stuff by hand, fine; if it silently breaks and clobbers lots of stuff, not so fine
<Diziet> k: Would we prefer the current pretty broken situation to it at least sort of working in universe how even if that means breaking it later ?
<eruin> elmo, okay, I was wondering because of bug #14251, which is solved in 2.8.3
<Diziet> k: Oh, right.  Well we can probably turn any hideous breaking into a dialogue :-).
<jdub> Diziet: there is no solid indication that it will break for breezy+1
<Kamion> Diziet: to a large extent it's up to the universe maintainers, but I think they're quite entitled to say that they want either something that works or nothing rather than a broken thing
<Kamion> I have no opinion on whether we should have something that works or nothing other than to note that the latter will probably generate more whinemail :-)
<Kamion> s/works/sort of works/g
<Diziet> jdub: Indeed so, but I don't want to be spending lots of effort in breezy+1 working out a smooth transition.
* ogra expects breakage with NM to be quite serious... for networking
<Diziet> k: :-).
<jdub> Diziet: you're assuming breakage
<Diziet> I've been working on software for some years.  Yes, I do assume breakage :-).
* hunger just hopes NM does not break too much of his /e/n/i setup if it gets automagically installed.
<jdub> hunger: it uses it to seed configuration
<j^> hunger thats breezy+1 so..
<jdub> Diziet: you're assuming it in an unproductive way
<hunger> jdub: Yeap... but not too well so far.
<jdub> j^ has done an excellent job creating these packages
<jdub> they work really nicely
<jdub> getting them tested during breezy lifecycle will be a huge benefit
<Diziet> But, I think the discussion has produced a clear answer in my mind, anyway: I don't have an objection to the MOTU's putting j^'s package in breezy universe.
<Kamion> I don't think we (i.e. Canonical staff) should be spending lots of time now reviewing stuff for universe that we know isn't going to make it into main for breezy
<Diziet> k: Quite so.
<jdub> anything we change below the user-side configuration is probably not going to have an enormous effect anyway, assuming we don't do insane things
<Kamion> if the general approach seems to be tenable, letting the MOTUs get on with it is much better than spending time on code review
<hunger> jdub: My dozend WLAN keys in /e/n/i is confusing NM a tiny little bit;-)
<Kamion> maybe with the odd check that whatever approach is being taken isn't digging us into an enormous pit we can't get out of somehow later
<jdub> hunger: i was under the impression they would be ignored
<Diziet> k: Right.
<j^> hunger editing /e/n/i by hand to get your keys in was never supported by ubuntu anyway
<jdub> Kamion: (j^'s work is fully inline with what upstream are doing)
<Diziet> jdub/ogra/j^/etc.> Is that all you want from me now ?  I'd like to get back to cursing GhostScript.
<hunger> j^: Yeap... Basically WLAN was never supported.
<Kamion> jdub: I hadn't checked so didn't want to assume any particular approach; I was trying to stick to generalities rather than getting into the detail of n-m
<hunger> jdub: Yeap... but "mappings" does confuse NM.
<jdub> ahr
<jdub> yeah
<siretart> ogra: ?
<ogra> Kamion, jdub, Diziet, all i was requesting before even thinking about including j^'s package was that at least the main maintainer and the universe maintaine have talked with each other, i didnt want a review or anything... MOTU can handle that themselves ;)
<hunger> jdub: Expecially when the mapping is using a iwlist scan result;-)
<ogra> i just hate duplicate work... 
<ogra> ...through missing communication...
<jdub> ogra: unfortunately, we duplicated j^'s work for a while there too :-) so now we're pretty much sorted, i hope
<ogra> yup
<Diziet> ogra: Right, that's sensible.  And thanks for bringing it up.
<ogra> ha ha 
<jdub> Migrating old dbus init symlinks to runlevel 12 ...
<jdub> update-rc.d: /etc/init.d/dbus exists during rc.d purge (continuing)
<jdub> uh oh
<jdub> may we live in interesting times
<ogra> err, EWRONGWIN
<pitti> elmo: can I please have the gnumeric build deps in concordia's breezy?
<sivang> do we have a community council meeting today?
<Lathiat> sivang: yes in about 5 hours
<Lathiat> Tue Aug 30 14:53:17 UTC 2005
<Lathiat> err, 7 ?
<Lathiat> no, 5
<jbailey> Lathiat: Pick a timezone, any timezone. =)
<Lathiat> mine, 4am :(
<sivang> Lathiat: k, thanks
<elmo> pitti: done
<pitti> elmo: thanks
<mdz> janimo: yes?
<mdz> Diziet: yes?
<fabbione> mdz: /j #ubuntu-kernel please
<mdz> morning
<fabbione> morning :)
<janimo> mdz, sent mail to u-d, regarding /usr/bin/which in usplash integration in lsb-scripts
<janimo> mdz, it's not in the path but called as which so it generates errors on the screen
<Diziet> mdz: Hello.  Just wanted to talk to you about gs; things have moved on a bit.
<mdz> janimo: works fine here
<Diziet> I've found what I think is the problem afflicting all ppc gs's.
<mdz> janimo: with which init script are you having problems?
<Diziet> Seeing that even Debian's gs-gpl 8 crashed showed that the diffs were a red herring.  Presumably our gs-esp 8 only works by chance.
<janimo> hmm, I am not sure the errors were pointing to /lib/lsb/init-functions or something
<janimo> lines looking like if which usplash >/dev/null .....fi
<mdz> Kamion: welcome back
<janimo> and which not being found
<janimo> I updated usplash and lsb-init and initramfs as mjg59 asked
<janimo> I am not fully dist-upgraded so maybe some scripts are not uptodate then if you say it works for you
<mjg59> mdz: Oh, this'll presumably be stuff that gets run before /usr is mounted?
<mjg59> janimo: You have /usr on a separate partition?
<pitti> Hi mdz 
<mjg59> pitti: hal doesn't send acpi events
<pitti> mjg59: do you use a python client?
<mjg59> pitti: In fact, none of the addons ever seem to run properly
<janimo> mhg59, nope
<mjg59> janimo: What shell is /bin/sh ?
<janimo> bash
<mjg59> Uhm. Which is a bash builtin.
<janimo> hmm
<janimo> I thought it would call which form debianutils
<mjg59> pitti: Uh. This is running hald in verbose mode and lshal monitoring
<janimo> then I am not sure why this happens.
<mjg59> pitti: If you stop acpid, restart hal and then press the power button, you should get a hal event
<pitti> mjg59: ok, because python clients are broken atm
<mdz> mjg59: yes, it should probably handle it more gracefully
<janimo> If it reoccurs I'll try debugging it I won;t be on this machine for about a week
<mdz> mjg59: I'm not particularly interested in doing a dance to try to make it work on systems with a separate /usr
<mdz> pitti: morning
<pitti> mjg59: you mean, you monitor with dbus-monitor, not lshal? or you compare lshal before and after?
<janimo> mjg59, when I say which in bash it calls /usr/bin/which
<mdz> mjg59: I didn't think which was a bash builtin
<mjg59> janimo: Oh, ups. Sorry, I'm running zsh.
<Kamion> mdz: hiya
<janimo> mdz,mjg59 it's not a separate partition
<mdz> janimo: <mdz> janimo: with which init script are you having problems?
<Kamion> mjg59: which is definitely not a bash builtin; look at /usr/bin/which to see how to do it in portable sh ...
<mdz> janimo: I'm asking which init scripts are producing the errors
<janimo> but in the lsb-functions scripts I see other binaries in /usr/bin are called from there explicitely only which isn't
<mdz> janimo: many init scripts mangle the PATH
<Kamion> mjg59: often, 'type' is good enough, and you don't need anything more complex
<mdz> janimo: those hardcoded paths in there are bugs
<Kamion> mjg59: (type is portable as long as you avoid weirder options)
<mdz> I'm just not fixing them until after the release
<mjg59> pitti: Well, dbus-monitor shows nothing either
<janimo> mdz, I don't know which initscripts called lsb-functions I didn;t look
<janimo> as I said they may not be uptodate if it works for you
<mjg59> pitti: If I run hald in verbose mode, I get output whenever the battery status changes. I don't get output when I push a button
<mdz> janimo: they all do.  I'm asking which ones printed errors.
<Kamion> mjg59: (I usually do 'if type foo >/dev/null 2>&1; then ...; fi'
<Kamion> )
<mdz> janimo: I haven't made any changes which would cause a change in that
<janimo> I mean I don;t know which printed the errors ;)
<mjg59> Kamion: Heh. This is mdz's code :)
<mdz> janimo: could you find out, please?
<pitti> mjg59: hm, has that ever worked, i. e. is a recent regression?
<janimo> Ok I'll reboot and try to look
<mjg59> pitti: It's supposed to work
<janimo> back in 10 minutes
<mdz> janimo: thanks
<mjg59> pitti: Otherwise gnome-power-manager can't work
<pitti> mjg59: for testing, how can I stop the power button from shutting down my machine?
<mjg59> pitti: Stop acpid
<pitti> ah, ok
<mjg59> pitti: You'll then need to restart hal, because it will have bound to the acpid socket rather than /proc/acpi/event
<ogra> pitti, cant you just press your lid button ?
<pitti> ogra: I mean on my desktop; my laptop will sleep on power button/lid, but of course I can stop pbbuttonsd there and test it on powerpc as well
<mjg59> I've no idea whether hal is supposed to deal with button press events on PPC
<pitti> guys, I need some minutes to finish the gnumeric security update, I will test that later
<mdz> Diziet: so you're saying we don't actually want the new gs-esp now?
<JaneW> BREEZYGOALS - Please update the status on any BreezyGoals which have made progress in the past week. Some are still listed as WIP, even though the Preview Freeze is in 2 days time.... 
<Diziet> mdz: I think that's right.  I'm doing some tests on my new build and will let you know later.
<janimo> mdz, I couldn't reproduce :(. Usplash bails out after battery checking but no sign of which errors as last time
<janimo> I get instead if it's any use /init: line 89 chmod not found on one of the last lines
<mdz> janimo: I don't know what the problem is, then
<mdz> but it isn't your PATH
<ogra> i get the same here... i think jbailey said something about the chmod stuff yesterday
<janimo> I probably need a full dist-upgrade
<ivoks> no one has problems with ACPI since update today?
<fabbione> elmo: pcre3_4.5-1.1ubuntu0.5.04_sparc.changes UNACCEPT <-
<fabbione> elmo: sorry but i am not sure i can do anything for it
<elmo> I've just killed it anyway
<fabbione> elmo: thanks
<fabbione> is there anything else i need to do?
<fabbione> i am not even sure why i get it...
<pitti> fabbione: this was very odd - it arrived quite late, and then I couldn't release it
<elmo> no, nothing you need to do
<fabbione> elmo: ok thanks
<elmo> fabbione: you get it because that part of dak sucks
<mdz> elmo: did you find out what was happening with arch: all builds?
<elmo> and having it spam the maintainer forces us to fix it ;)
<elmo> mdz: yes, it got broke by the change in architecture; I've fixed it
<mdz> elmo: thanks
<fabbione> elmo: ahahah
<elmo> tho, with a 30min cron.daily the spam goes from mildly irritating to rude and unpleasant
<fabbione> elmo: i didn't get that mail so often....
<fabbione> only 4/5 times probably...
<elmo> oh, that's because you were only getting it when pitti tried to amber it
<fabbione> and i recall it from a couple of days ago...
<fabbione> ahh
<pitti> fabbione: oh, sorry :-/
<elmo> but non-security uploads UNACCEPTS _will_ happen every 30 mins
<fabbione> so it has been ambered or did you just kill it?
<elmo> so they make lamont cry
<fabbione> pitti: don't worry dude...
<elmo> I killed it, it's obsoleted by a newer source security upload
<fabbione> elmo: perfect.. thanks
<pitti> fabbione: interesting ways to send you mail :-)
<fabbione> pitti: via amber? ;)
<pitti> yes
<fabbione> pitti: it was enough the crack :
<fabbione> )
<pitti> fabbione: do you always get mail when I release sparc updates?
<fabbione> pitti: yes.. i get the ACCPTED message that usually i don't care to read
<mjg59> ivoks: What sort of problem?
<mdz> Kamion: /srv/cdimage.no-name-yet.com/scratch/ubuntu/debootstrap/breezy-amd64: line 3: finddebs_style: command not found
<mdz> Kamion: is that important?
<ivoks> mjg59: hal-addon-acpi lock /proc/acpi/event
<ivoks> mjg59: and acpid can't start cause of that
<pitti> mjg59: doesn't work in hoary either
<mjg59> ivoks: Interesting.
<ivoks> mjg59: s/lock/locks/
<mjg59> pitti: No, that doesn't surprise me
<pitti> mjg59: well, hal 0.5.4 has tons of bug fixes and also ACPI updates
<mjg59> pitti: But it's *supposed* to
<pitti> mjg59: I will try it
<mjg59> ivoks: Now, that's interesting.
<mjg59> ivoks: Do you still have hal-addon-acpi running?
<ivoks> mjg59: yes... locking event :)
<mjg59> ivoks: And what version of hal?
<mjg59> ivoks: We're currently discussing the problem that this doesn't seem to work for anyone else
<ogra> pitti, there was no functional code in hoary for acpi/hal stuff
<ivoks> mjg59: (0.5.3-0ubuntu10)
<mjg59> ivoks: Ok, thanks
<ivoks> mjg59: just did reinstall of hal and acpid... no changes
<mjg59> ivoks: No, I wouldn't expect there to be
<ogra> pitti, but 0.5.3 is supposed to work...
<mdz> Kamion,mjg59: switched from 'which' to 'type' in init-functions, rc and rcS
<mdz> since it's a built-in and should be faster
<pitti> ogra: hmm, no idea then
<mdz> though which *is* in fact in /bin
<ivoks> mjg59: me too, but i messed a lot with acpi, so i wanted to get clean configs...
<mjg59> pitti: Ok. hald-addon-acpi should be running. It isn't.
<pitti> mjg59: right, neither it does for me
<mjg59> pitti: That's a bug
<pitti> mjg59: I only have hald-addon-storage
<Kamion> mdz: annoying but unimportant
<mjg59> pitti: I don't even have that, but still
<Kamion> mdz: it makes the are-all-debootstrapped-packages-there? check not work, but that check doesn't matter much any more now we have automagic debootstrap
<ogra> mjg59, i have it and it runs.
<ogra> mjg59, but i still dont get acpi events
<mjg59> ogra: It's running? In the background?
<ogra> ogra@honk:~/edubuntu-artwork-0.1.0 $ ps ax|grep acpi
<ogra>     7 ?        S<     0:00 [kacpid] 
<ogra>  4409 ?        Ss     0:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket
<ogra>  4645 ?        S      0:00 hald-addon-acpi
<mjg59> ogra: Can you strace it and see if it's getting events?
<mjg59> ogra: My suspicion is that it may not be sensible enough to have bound to the acpid socket
<ogra> hmm, is it supposed to talk to acpid ? i thought it reads from proc ? 
<mdz> has anyone tested a daily install CD recently?
<mjg59> ogra: It can't read from proc if acpid has already bound to the event file
<ogra> mdz, my last edubuntu was on sunday...
<mdz> ogra: we need tests with the new xorg
<ogra> mdz, on edubuntu desktop-base seems gone, any idea why ? 
<ogra> mjg59, ah, ok
<mdz> Kamion: hmm
<mdz> Kamion: [1] -  5685 Stopped (tty input)     cron.daily-live
<mdz> Kamion: I usually run it in the background without issue
<ivoks> ogra: mjg59 if acpid is started before dbus, then it's ok
<mjg59> ivoks: Yes, that's what I'd expect
<mjg59> ivoks: But right now I'm trying to track down why this doesn't actually seem to work at all for most people
<mdz> Kamion: happened at this point: Running tools/boot/breezy/boot-powerpc 1 /srv/cdimage.no-name-yet.com/scratch/ubuntu/tmp/breezy-powerpc/CD1
<ivoks> cause dbus is S12 and acpid S20? :)
<mvo> mdz: I downloaded one today but haven't managed to test it yet. should I do that now?
<mjg59> ivoks: No
<ivoks> ogra: when was last time you reboot your breezy?
<mjg59> ivoks: Because hal is broken
<ivoks> ok
<mjg59> ivoks: I'll fix your bug once I've worked out what's wrong with hal
<ogra> ivoks, ~ 2h ago for usplash testing
<ivoks> ogra: ok...
<mdz> Kamion: maybe your yaboot changes?
<mdz> mvo: please
<Kamion> mdz: could be, let me have a look
<Kamion> mdz: did the change to cdimage user happen without incident?
<pitti> mjg59: 
<pitti> 29379: 17:52:37.803: addon-acpi.c:115: Cannot open /proc/acpi/event: Permission denied - trying /var/run/acpid.socket
<pitti> 29379: 17:52:37.803: addon-acpi.c:127: Cannot open /var/run/acpid.socket - bailing out
<mdz> Kamion: the cron jobs seem to have been working, yes
<mjg59> pitti: Ok. Now, why is that failing?
<mdz> Kamion: I've still been running ad-hoc builds as mdz
* mjg59 looks
<pitti> odd, since it is 666
<pitti> mjg59: just to be clear, it is supposed to take the socket, not the proc file, right?
<Diziet> How strange.  Now I can't get gs-esp to build from source on i386.  I'm sure it worked yesterday.  (But perhaps that was on sarge not breezy.)
<mjg59> pitti: If acpid is running, it should take the socket
<pitti> mjg59: oops, yes
<mjg59> If acpid is not running, it should open /proc/acpi/event
<pitti> mjg59: I stopped it
<mjg59> Right. What user does hald run as?
<pitti> mjg59: hal
<Kamion> mdz: could you ctrl-c your build so I can try it out?
<mjg59> Ok. It's not going to be able to open /proc/acpi/event
<pitti> mjg59: I stopped acpid to not shutdown my box when I press the power button
<pitti> mjg59: right
<ivoks> pitti: 666? here is 400...
<mdz> Kamion: done
<pitti> srw-rw-rw-  1 root root 0 2005-08-30 12:09 /var/run/acpid.socket
<ivoks> ah, socket...
<ivoks> sorry
<pitti> ivoks: yes, /proc/acpi/event
<mjg59> pitti: Ok. hal needs to be started after acpid
<ivoks> right
<mjg59> Otherwise it does stupid stuff
<pitti> mjg59: ok, any chance I can run acpid without shutting down my box?
<mjg59> pitti: Yes, just move /etc/acpi/powerbtn.sh
<ogra> mjg59, note that it will slow down the boot for about 4secs, i did tests for hwdb in hoary...
<mjg59> ogra: What will?
<ogra> (running acpid before hal)
<mjg59> ogra: We either run acpid before hal or hal doesn't work as it's supposed to
<mvo> nautilus-cd-burner hates me today and refues to burn on my cdrw 
<ogra> acpid is run after gdm currently 
<mjg59> ogra: We have a choice between correct or slow.
<pitti> mjg59: right, now it works
<mjg59> pitti: No, it doesn;t
<mjg59> pitti: acpi events aren't sent
* mvo goes back to cdrecord
<pitti> mjg59: the connection, I meant
<mjg59> pitti: Ah :)
<mjg59> pitti: Sorry, yes.
<ogra> mjg59, i just wanted to point that out, since my patches were rejected by thom in hoary because of this..
<mjg59> Seems to work for me, too
<pitti> mjg59: also events
<pitti> signal sender=:1.7 -> dest=(null destination) interface=org.freedesktop.Hal.Device; member=Condition
<pitti>  string "ButtonPressed"
<pitti> string ""
<pitti> mjg59: ^thats what hal sends for the power button
<mjg59> Hurray!
* mjg59 watches g-p-m work
<ogra> geez
<Lathiat> mjg59: like, work work?
<mjg59> Lathiat: Like, work work
<Lathiat> as in all the options?
<pitti> mjg59: humm, so we need hald running before gdm, otherwise we could see races at session start
<mjg59> I pressed the power button and g-p-m gave me a notification
<pitti> mjg59: so we don't have much of a choicee
<Lathiat> cool
<mjg59> pitti: Yeah
<mdz> Kamion: looks like this could happen if none of the cases in the if/elif at line 94 trigger
<mjg59> I'll upload a fixed acpid
<mjg59> Oh. Hrm.
<mdz> Kamion: of course, I'd think that CDIMAGE_LIVE would be true...
<mjg59> What's the right way of changing startup priority?
<pitti> mjg59: it takes maybe 0.3 seconds here to start up, not much of a regression...
<ivoks> ok, then that's fixed...
<pitti> mjg59: dbus recently did it
<pitti> mjg59: maybe steal from daniel's postinst :-)
<mjg59> pitti: Presumably postinst has to deal with the case?
<pitti> I guess
<mjg59> Hm. dbus doesn't seem to have anything to handle it in its postinst
<Kamion> mdz: reproduced, thanks for the hint - looks plausible
<ogra> mjg59, dh_installinit ??
<Kamion> mdz: judging from ps that's not it, though
<mjg59> ogra: That's fine for new installs
<pitti> ogra: you have to preserve local symlink configurations
<mjg59> ogra: I don't think it can handle the case of something changing
<ogra> hmm, how does dbus do it then ? 
<mjg59> Dunno
<pitti> mjg59: I /msged you the postinst code of dbus
<mjg59> Ah!
<mjg59> My dbus must predate that
<mjg59> Yes
<Kamion> mdz: fixed now, I think; testing
<doko> ogra: do you need schooltool and schoolbell in main for edubuntu?
<ogra> yup
<pitti> still, the hal 0.5.4 changes look tempting...
<slomo> elmo: the ppc buildds are broken... no space left... see this for example: http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/h/hasciicam/0.9.1-1.1ubuntu1/hasciicam_0.9.1-1.1ubuntu1_20050830-1646-powerpc-failed.gz
* jordi giggles at his quotes file.
<jordi> too bad seb isn't here.
<jordi> 15:55 <@seb128> I'm pretty sure that's not a gtk bug
<jordi> he really said it
<dholbach> haha
<Nafallo> lol
<Diziet> No, this new ppc binary is fundamentally hosed.  Less so than it was, but still fundamentally hosed.
<Kamion> oh ye hideous screaming gods, 1120 new messages in breezy-changes
<Kamion> you lot have been busy
<Nafallo> Kamion: lol, that's a nice way to put it ;-)
<sivang> gos?
<sivang> err, gods?
<sivang> :)
<Nafallo> Kamion: welcome back btw :-)
<Kamion> mdz: ok, fixed, try again
<pitti> Nafallo: btw, I noticed some recent security uploads from you to breezy; please always prefer a package sync over an -ubuntu upload
<Nafallo> pitti: talking about kismet?
<pitti> Nafallo: yes, that was it
<Nafallo> pitti: I've tried to find insolated patches, but I haven't had any luck :-/
<pitti> Nafallo: I meant, you used the Debian version and uploaded it as ubuntu1, right?
<infinity> slomo : Fixed.
<sivang> infinity: I got over that issues I had with debmirror, apparently ftp was blocked here so I used --method=ftp
<pitti> Nafallo: no, for breezy (i. e. unstable), syncing from Debian is preferred over patching
<slomo> infinity: thanks :) can you start a rebuild for hasciicam / aatv / mono? they failed because of that
<Nafallo> pitti: yepp, took the debian version and merged our changes.
<Kamion> Keybuk: I guess making binfmt-support depend on lsb-base was too hard? ;-)
<infinity> slomo : Are those the only ones?
<pitti> Nafallo: according to the changelog there aren't any Ubunut changes
<ivoks> bye
<Nafallo> ehm
<slomo> infinity: wait
<Nafallo> pitti: let me check :-)
<Keybuk> Kamion: mm
<Keybuk> oops :)
<slomo> infinity: uh... much more
<slomo> infinity: everything from kvpnc to mmv
<slomo> infinity: mmv is 13:08 GMT
<gans10> can someone help me in #ubuntuppc
<slomo> infinity: but there were some successull ppc builds in that time... hmm
<infinity> slomo : Obviously, there are three ppc buildds, only one was out of space.
<gans10> i have a problem booting liveppc cd
<elmo> wow, my terminal is entirely SNAFU after a breezy upgrade
<slomo> infinity: shall i make a list of all failed packages or is this easier for you?
<infinity> slomo : I like lists.
<Nafallo> pitti: wow! I seemed to have dropped them :-(. I guess I should fix that.
<gans10> can someone help me in #ubuntuppc
<gans10> i have a problem booting liveppc cd
* Nafallo hugs REVU
<pitti> Nafallo: dropped the changes, or just the changelog?
<elmo> only within the running screen session tho
<elmo> ho hum
<Nafallo> pitti: the changelog, I knew what changes we did by heart already :-)
<infinity> elmo : How much do I have to bribe you to get more disk space in royal? :)
<infinity> elmo : Alternately, I should make sure *-desktop is uninstallable most of the time, so the livecd builds fail and don't fill the fs.
<Kamion> gans10: don't see why it needs a separate channel
<Kamion> gans10: are you using a G5?
<gans10> G4
<gans10> something withxorg
<gans10> it flashes several times
<Kamion> ah, probably not something I know about then unfortunately
<gans10> oh
<gans10> ok
<gans10> thanks
<mvo> mdz: installing now (stage2), got a debconf message from toshset that it will not work :)
<infinity> mvo : mjg59's already been larted for that.
<mvo> infinity: heh, ok
<Diziet> OK, so what will go wrong if my jmp_buf's are not 16-byte aligned on ppc ?
<elmo> infinity: it has a 3rd drive
<Kamion> Keybuk: also your change has Nathaniel-esque set -e breakage :-P I'm incorporating it into Debian at the moment, and will fix it
<elmo> infinity: problem is, I need to wipe + reinstall to add it
<elmo> mjg59: is the plan for that text in usplash to always be there?
<mjg59> elmo: Always be there in what way?
<elmo> mjg59: (that text == the Starting service ..., stuff)
<infinity> elmo : I could just mount it to ~buildd/public_html, for livcd+translation export.
<infinity> elmo : For now, anyway.
<mjg59> elmo: It may be dropped after Breezy, but we'll probably keep it for now
<Keybuk> Kamion: meh, I cargo-culted that stuff mostly from another one
<elmo> well, hum, sure
<elmo> ^-- infinity: sorry
<elmo> mjg59: hum, ok, silbs is concerned that makes usplash kind of like normal boot except with a progress bar ;)
<elmo> oh, well, as I can HEAR from her NOISY client, silbs is here, so I'm sure she can speak for herself ;)
<silbs> elmo: quit talking about me and the noise won't bother you
<Diziet> Can I compile a specific program without altivec support ?
<mjg59> elmo: Heh. If there's consensus that the text shouldn't be there, we can probably remove it
<Diziet> Because this 16-byte-aligned jmp_buf violates too many assumptions in gs.
<infinity> elmo : Do you trust me to abuse root for that, or will you do it when you find a round tuit?
<Kamion> Diziet: -mno-altivec
<Kamion> give that after any -mcpu
<elmo> infinity: I'm on it
<silbs> mjg59: it was just my first reaction to see usplash for the first time.  Gut reaction more than a thoughtful consensus. 
<infinity> elmo : rock.
<mjg59> silbs: At the moment we don't really have any infrastructure for passing on failures to the user
<Diziet> k: And this is allowed ?  I mean, I can do that in Breezy ?
<mjg59> I can think of a couple of ways to hack around it, but nothing terribly breezyable
<elmo> wow
<Kamion> Diziet: oh, yes, that's fine
<elmo> cfdisk on the Xserves is amusingly SNAFU
<elmo> it reckons / is all free space
<mjg59> Oh argh why does PowerManager not create a pidfile?
<Kamion> elmo: mac-fdisk?
<Kamion> cfdisk probably expects PC-style partition tables or something
<elmo> Kamion: yeah, I guess - I wish cfdisk would be less unhelpful tho
<Diziet> k: Excellent.
<Kamion> there are two partition table types in common use on powerpc, which is painful
* mvo watches breezy installing with progress bar in the downloading languges mode ... sweet
<elmo> boggle, this "blank" hard drive from Apple has a non-empty HFS partition
<silbs> mjg59: breezyable is the name of the game these days. If it's not in that category,then no need to talk about it now :)
<infinity> elmo : fdisk is the only way to go on PPC.. I don't know why we even ship cfdisk.
<infinity> elmo : fdisk appears to be smart enough to figure out apple and PC style tables.
<Diziet> Hrm.  -mno-altivec doesn't seem to change the compiler's idea of the alignment for jmp_buf.
<mjg59> Oh, FFS.
<Kamion> Diziet: -mabi=no-altivec maybe?
<elmo> infinity: cfdisk is useful for e.g. usb sticks
<Kamion> if not that, it must be something other than AltiVec
<Diziet> k: google seems to suggest that produces an incompatible abi which will therefore break.
<mvo> ping jamesh 
<infinity> elmo : If cfdisk was rewritten to just be a shell frontend to libparted, I'd probably like it better, cause it would stop doing silly things like claiming a disk is empty. :)
<Diziet> Oh, no, the stupid gs build system doesn't pass my flags to genarch.
<Diziet> To gcc when building genarch, I mean.
<infinity> Anyhoo.  Off to bed in an attempt to get back in my own timezone.
<infinity> elmo : Thanks in advance for making royal happy.
<infinity> (Or, happier, anyway)
<Diziet> But anyway, -mabi=no-altivec doesn't change the alignment of a jmp_buf either.
* infinity looks at his laptop on his lap, his lack of power cord, and the battery applet that claims "no battery present / running on AC power"
<infinity> Uh huh.
<elmo> infinity: partition's ready, /dev/sdc2
<ogra_ltsp> mdz, for my fresh installed ltsp client X autodetection didnt work it seems...
<elmo> infinity: do you want me to mv public_html's contents there?
<mvo> Kamion: the install is hanging with apt/aptitude asking for a cdrom. it looks like mozilla-firefox-locale-en was not copied onto the hd (but is available on the cd)
<mdz> ogra_ltsp: I haven't changed anything
<mdz> ogra_ltsp: did it ever work on this client?
<ogra_ltsp> mdz, what about x packages ? 
<infinity> elmo : If you wouldn't mind, that would be cool.  I should go find a bed.
<mdz> ogra_ltsp: I didn't change the X packages either
<infinity> elmo : And if you do it, I can blame you if things go missing. :)
<ogra_ltsp> mdz, sure until yesterday
<ogra_ltsp> mdz, the client has versioned deps ? 
<ogra_ltsp> there was an X upload recently... 
<mdz> ogra_ltsp: yes...
<mvo> Kamion: I pass a "need cdrom" question on the status-fd in apt easily if you need that
<mdz> ogra_ltsp: if it isn't working for you, then you should file a bug
<dholbach> slomo: did you write that transitions page?
<ogra_ltsp> hmm, strange then...
<mdz> ogra_ltsp: you know how to debug it, right?
<slomo> dholbach: yes
<dholbach> slomo: thank you for that - i linked it on MOTUTodo
<Kamion> mvo: yes, that would very much help
<ogra_ltsp> mdz, the X startup ? 
<ogra_ltsp> sure
<mdz> ogra_ltsp: https://wiki.ubuntu.com/DebuggingXAutoconfiguration
<ogra_ltsp> yup
<mdz> ogra_ltsp: then file a bug against xserver-xorg
<mdz> ogra_ltsp: it will automatically be assigned to daniels
<ogra_ltsp> oki
<Kamion> mvo: it's possible that language-* copying isn't working right; just before I left, I noticed that it didn't follow dependencies
<slomo> dholbach: can you check whether i got the status of the transitions in main right?
<ogra_ltsp> Kamion, mdz, can anybody tell me why desktop-base is gone from edubuntu iso's since saturday ? or tell me where to look for the reason ? 
<mdz> ogra_ltsp: /usr/share/gnome-session/changelog.Debian.gz
<mdz> ogra_ltsp: why?
<Diziet> Aha!  Found the problem in the gs bugzilla.  http://bugs.ghostscript.com/show_bug.cgi?id=687643
<ogra_ltsp> gnome-session breaks on it...
<dholbach> slomo: seems ok to me, but will doublecheck next week
<slomo> dholbach: thanks :)
<mdz> ogra_ltsp: gnome-session is working fine here
<mdz> ogra_ltsp: perhaps you could do some analysis and file a bug?
<ogra_ltsp> mdz, it requires some files in place that arent there... i need to do a new install to get the error... last time i was on it, i was dragged away by initramfs-tools probs
<mdz> ogra_ltsp: perhaps your gnome-session is old
<mdz> ogra_ltsp: you need 2.11.91-0ubuntu3
<mdz> ogra_ltsp: <mdz> ogra_ltsp: /usr/share/gnome-session/changelog.Debian.gz
<mvo> mdz, Kamion: modulo the missing "language-*" stuff the install worked finetest-install was sucessfull here 
<mdz> mvo: thanks
* mvo should learn to type properly
* xhaker is away (Away, bnc logging)
<elmo> mdz: pls don't trigger any powerpc livecd builds
<dholbach> infinity: with whom would i arrange a test-rebuild of the archive? with you? or does lamont still that kind of thing?
* mjg59 has almost wonderfully working g-p-m
<pitti> mjg59: cool
<mjg59> Only issue is that it doesn't seem to be responding to sleep key events
<mjg59> Oh, hang on, I know
<mjg59> That'll be ibm-acpi
<mvo> elmo: can I please get python-apt in the breezy chroot on concordia?
* mjg59 pokes
<elmo> mvo: installing
<mvo> elmo: thanks
<sivang> dholbach: test rebuild of the *whole* archive ? :)
<dholbach> sivang: that's what lamont did for hoary
<sivang> dholbach: wow, that oughtta to take some time
<Amaranth> couple days
<mjg59> pitti: Hal probably needs support to recognise various vendor hotkeys as sleep buttons
<mdz> mjg59: so I'm not entirely sure what's happening with usplash vs. X on the live CD
<mjg59> mdz: Hm
<mjg59> mdz: What sort of symptoms?
<mdz> mjg59: so usplash goes along fine until gdm starts
<mdz> mjg59: the CD churns away as X is being read in parallel with all the readahead stuff
<mjg59> Ok...
<ogra_ltsp> mdz, ok, xorg checked, it detects vmware instead of nv here... reproducable...
<mdz> mjg59: the usplash timeout presumably expires, and I end up at a text-mode login
<mjg59> mdz: Right
<mdz> mjg59: then X gets around to starting up, but doesn't switch consoles
<mjg59> mdz: Ok
<mdz> mjg59: does X have some sort of paranoia check where it could notice a console switch before it has even switched itself?
<mdz> mjg59: clearly usplash is switching first, so I'd expect X to go ahead and switch after that, and win
<mjg59> mdz: Unsure
<mjg59> mdz: Can you try adding a usplash_write "QUIT" to the start of the gdm script and ensure that that's working ok?
<mdz> mjg59: can do
<mdz> I should check the X log also
<mjg59> pitti: Actually, Hal needs quite a bit of loving in this respect
<mjg59> Argh
<mdz> mjg59: yes, an explicit usplash_write QUIT lets things end up in the right place
<mdz> trying again without it to see if X says anything useful
<elmo> btw, are we going to usplash shutdown?
<mdz> elmo: sure, after breezy ;-)
<mdz> we've pushed our luck far enough, I'd say
<Nafallo> :-)
* Nafallo loves usplash :-)
<elmo> and/or ever turn most of the init.d stop scripts into no-ops?
<mdz> mjg59: ok, very weird
<elmo> mdz: heh, ok
<mdz> mjg59: X log halts midstep with "(++) using VT number 7"
<mdz> mjg59: and doesn't seem to proceed until I switch over to VT 7
<mdz> mjg59: it's blocked in ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE
<mdz> mjg59: FD 3 being /dev/tty7
<mjg59> mdz: Hmm.
<mjg59> mdz: That's with usplash?
<mdz> mjg59: yes
<mdz> that's after removing the workaround
<elmo> hum, is it known the xscreensaver dialog has regressed?
<mjg59> mdz: Right. I'm guessing some sort of race condition, but I'm not sure what.
<elmo> I can't see in bugzilla but maybe I'm being stoopid
<mdz> mjg59: I can understand X wanting to do a VT_WAITACTIVE, but surely it's doing a VT_ACTIVATE immediately before that, and I don't see any reason why that shouldn't work
<Kamion> elmo: is shutdown slow enough to merit that? it seems a bit risky to just power off under the feet of a lot of daemons
<elmo> Kamion: I don't have working suspend/resume, so yeah, I find shutdown annoyingly slow
<elmo> but then I'm hyperactively impatient
<mdz> mjg59: I guess it's possible that we're ending up with 1. X does VT_ACTIVATE 2. usplash does VT_ACTIVATE, 3. X does VT_WAITACTIVE [blocks] 
<mjg59> mdz: Yeah
<mdz> mjg59: what was the plan with -novtswitch?  do we have some reasonable way to determine which vt X is using, so we can switch there ourselves?
<elmo> hey, this is breezy
<elmo> maybe I do have working suspend/resume
<mdz> elmo: yes, it is known, ogra and I talked about it and I thought he was going to upload it last week sometime
<elmo> hmm, nope
<sivang> elmo: can I get whitelisted or whatever neede to receive mails from your beloved katie?
<elmo> ogra_ltsp: ?
<elmo> sivang: email address?
<ogra_ltsp> elmo, ?
<elmo> ogra_ltsp: ^-- see mdz's comment?  shuold I file a bug?
<sivang> elmo: sivan AT piware DOT de
<mjg59> elmo: Hm. On PPC?
<mjg59> mdz: I'm afraid I'm not sure what's going on there
<elmo> mjg59: no, i386, my powerbook is dead
<elmo> mjg59: HP Pavilion zt3000
<ogra_ltsp> elmo, i have the lockscreen patch waiting on my disk... its blocked by a prerequisite mdz had for it i'm just figuring out
<mjg59> elmo: What failure?
<elmo> mjg59: i.e. the office cast off
<oceandead> just wondering - will breezy have built in support for rtl8180 
<elmo> mjg59: just doesn't suspend
<mjg59> elmo: Have you edited /etc/default/acpi-support ?
<ogra_ltsp> elmo, no need ofr a bug... it would be a duplicate anyway :)
<elmo> ogra_ltsp: ok, as long as it doesn't get forgotten ;)
<ogra_ltsp> s/ofr/for
<elmo> mjg59: no - should I have?
<mjg59> elmo: Yes
<mdz> ogra_ltsp: I think I asked you to upload the LTSP change at the same time
<mdz> mjg59: the strange thing is that I only see one VT switch, not two
<ogra_ltsp> mdz, you asked me to upload a ltsp change ? 
<ogra_ltsp> mdz, ah, sorry, slow today
<mdz> ogra_ltsp: for xscreensaver, yes
<ogra_ltsp> mdz, exactly... but thats not ready 
<mdz> ogra_ltsp: is it not trivial?  if (getenv("LTSP_CLIENT")) { force blanking mode }
<ogra_ltsp> so the lockscreen is waiting... i think i got it done tomorrow... its scheduled for my nightshift today :)
<elmo> mjg59: to enable SLEEP?  if so, after an /etc/init.d/acpid reload, still no love
<ogra_ltsp> the "force blanking mode" isnt :)
<mjg59> elmo: It shouldn't need a reload. What happens when you press the slepe key?
<ogra_ltsp> i know how to do get a environment var :)
<mjg59> If the answer is "absolutely nothing", can you try sudo /etc/acpi/sleep.sh ?
<elmo>                                 ~.
<mjg59> Helpful.
<elmo> heh, woops :)
<elmo> mjg59: hotkey does nothing
<mjg59> elmo: Ok
<elmo> mjg59: running the script by hand worked
<mjg59> elmo: Are you on very latest breezy?
<elmo> mjg59: updated like 30 mins ago
<mjg59> elmo: Oh, I know. You'll need to restart gdm.
<mjg59> (sorry)
<elmo> shouldn't it suspend on laptop lid close, or am I AWTY-ing?
<mjg59> elmo: Give me half an hour?
<elmo> heh, sure, no problem sorry
<mjg59> Argh, my acpi-support upload has stalled.
<Diziet> Wahey!  A working-ish gs on ppc!
<mjg59> Let's try that again
<mjg59> There we go
<Diziet> I did have to do this:
<Diziet> #define setjmp(x)      (gsfix_orig_setjmp(find_jmp_buf((x))))
<Diziet> et al.
<jbailey> Diziet: Eww...
<Diziet> It works, though.  gs never memcpy's a jmp_buf, so you can make a set of macros that work just like normal setjmp etc. but whose jmp_buf is (a) bigger but (b) has alignment 1.
<mjg59> elmo: Ok. Once they've got through the buildds, grab acpid, acpi-support, powermanagement-interface and gnome-power-manager
<elmo> mjg59: ok, cool, will do
<elmo> ssh is exiting with exit code of 1 for me since I upgraded; anyone else seeing that?
<elmo> seems only to be when using the nc proxycommand trick tho
<mjg59> ogra_ltsp: Ok, g-p-m seems to be working sensibly now
<mjg59> Though the sleep button stuff isn't terribly useful right now
<mjg59> lid, power and hibernate look good
<spayne> well done - the latest udev sorted out the mounting problems
<spayne> now i can use the CD drive :-)
<sivang> elmo: thanks :)
<sivang> elmo: she just mailed me, I feel so special :-)
<jbailey> spayne: Thanks.
<jbailey> Seems to be fixed for some cases, just not all.
* mvo is away for dinner
<spayne> jbailey: but not ndiswrapper :-) 
<ogra_ltsp> mjg59, wow, cool
<spayne> jbailey: i'm on #ndiswrapper to see if they can tell me what the error message means
<mjg59> ogra_ltsp: You should have a play later on
<mjg59> ogra_ltsp: (needs a pile of stuff I uploaded just now)
<ogra_ltsp> mjg59, i will...
<ogra_ltsp> :)
* mjg59 goes to get a shower before heading out
<ogra_ltsp> hmm, seems daniels changed the handling of discover for dpkg-reconfigure xserver-xorg, that seems to make my card recognized wrong... but i dont get why it thinks it is vmware
<ogra_ltsp> s/recognized/being recognized
<elmo> mjg59: I've got lots of ACPI error spam in my dmesg; do you care?
<mjg59> elmo: What sort?
<mjg59> elmo: If it's about owner_ids, it'll be fixed in the next upload
<doko> Riddell: in the latest OOo2 upload, there's a patch, which allows using addresses for i.e. form letters, which are taken from kaddressbook. I didn't check, if that actually works. Maybe you care ... ;)
<lamont-away>  dholbach full rebuild requires that the test-archive be flushed and it's wanna-build db repopulated... both of those are archive-management tasks...
<lamont-away> and a full rebuild was just done last week, iirc
<elmo> oh, and yay
<elmo> I can't cleanly shutdown after suspend/resume
<dholbach> lamont-away: oh... i see, thanks for that - are the buildlogs in /Test/ as usual?
<elmo> [4294932.334000]      ACPI-0423: *** Error: Handler for [EmbeddedControl]  returned AE_TIME
<elmo> [4294932.334000]      ACPI-0509: *** Error: Method execution failed [\_SB_.C046.C059.C0EA.C132]  (Node cffb73a0), AE_TIME
<elmo> mjg59: that kind of thing
<dholbach> lamont-away: thanks, i will generate a todo list from that data
<ivoks> that reminds me... sometimes after resume, some keys on keyboard don't work...
<ivoks> and that's when i use hr or hr_US layout
<Riddell> doko: cool, I'll give it a try
<mjg59> elmo: Hrm. that's interesting
<elmo> mjg59: http://people.ubuntu.com/~james/tmp/kern.log has more
<fabbione> elmo: can we sync tailor from Debian -> universe? it looks an interesting piece of python code...
<elmo> fabbione: done
<fabbione> elmo: thanks
<slomo> mdz: did you read my mail regarding ffmpeg?
<mdz> slomo: yes
<ogra> grmpf... why doesnt pcmcia-cs notify me anymore before it shuts down my network on upgrade...
<ivoks> :)
<Treenaks> ogra: use cardbus! :P
<ogra> Treenaks, pcmcia-cs used to ask before it shuts down the interfaces...
<Treenaks> ogra: true..
<Treenaks> ogra: but still, it's ancient :)
<ogra> its what the default install choose here... i didnt touch it
<Treenaks> no I mean hardware-wise
<mdz> does anyone know a convenient shell idiom for capturing the exit status of the first command in a pipeline?
<Kamion> I don't know any *convenient* ones; would you like an inconvenient one instead? :)
<Kamion> CODE="$(((foo; echo $? >&3) | bar) 3>&1)"
<Kamion> at least IIRC
<Kamion> might need a few >/dev/null redirects and such
<mdz> Kamion: I ended up moving the branch into a subshell
<mdz> in this case I was lucky and it didn't matter that the conditional logic was executed in a subshell
<mdz> bah, I just clobbered my /tmp testing mountall.sh
<mdz> obviously "mountall" is a secret code for "mount the remaining filesystems AND THEN DELETE LOTS OF STUFF"
<Lathiat> heh
<mdz> jbailey: did you and mjg59 work out a way to get usplash activated upon install?
<mdz> jbailey: that's necessary for preview
<Kamion> mdz: I saw the mail about that; what's wrong with just sticking it in the minimal seed?
<jbailey> mdz: No, I was chatting with Fabio about it a bit ago, though.
<jbailey> To see if there was any reasonable way of doing it that way.
<jbailey> mdz: It's not ideal, since it involves the kernel packaging at times other than reinstall, but it's hard to come up with a better solution.
<Kamion> anyone here speak Chinese?
<fabbione> Kamion: when i am drunk enough :P
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/man-gb2312.gif
<Mitario> hmm, the elipses are wrong in liblaunchpad
<Kamion> wondering if that looks kinda right (from the point of view of line-wrapping, etc.)
<Mitario> ellipses*
<mdz> Kamion: usplash in the minimal seed seems a bit evil, don't you think?
<Kamion> I suppose
<Kamion> failing that it's easy to have a bit of code to apt-install it with a debconf question to let certain CD builds turn it back off, though
<mdz> minimal isn't terribly minimal at the moment, but usplash seems out of place there
<Kamion> though I don't know offhand where it might go; could just hack it into base-installer I guess
<mdz> I'm not sure whether it's more or less evil than having usplash regenerate the initrd on install
<sedak> fabbione, do you have some time to check if a module package is fine ?
<fabbione> sedak: not today.. it's sort of late evening and i am going offline soon
<sedak> ok
<sedak> then another day :-)
<fabbione> sedak: remind me in a day or two...
<fabbione> please..
<sedak> ok, no problem, i'll do that ^^
<fabbione> thanks
* fabbione goes offline
<ogra> hrm, now X thinks i have a cirrus_laguna card :/
<HiddenWolf> ogra, get a screwdriver, and check, perhaps you'll be suprized. :)
<ogra> HiddenWolf, i know that my laptop has a nvidia card ;)
<ogra> xorg autodetection stopped working for me with -54 it seems... 
<ogra> the weird stuff is, that the card gets detectd as vmware if i run the laptop as ltsp client, but as cirrus_laguna if i run dpkg-recionfigure locally...
<wasabi> Is X going to be modularized into actually different development modules? So a single X change doesn't result in 60 packages being downloaded. ;)
<ivoks> :)
<ogra> wasabi, hasnt that already happened ? 
<HiddenWolf> ogra, to an extent. :)
<ogra> heh
<dieman> grmbl
<dieman> does breezy have ahci support?
<eruin> How can I get involved in laptoptesting?
<eruin> I've got a few spanking new laptops around here I'd like to contribute with
<HiddenWolf> eruin, check on wiki.u.c/LaptopTestingTeam or the like of it.
<eruin> cheers
<HiddenWolf> np. :)
<eruin> wikis really scare me
<eruin> ;C
<HiddenWolf> eruin, they're addictive. :)
<eruin> heh, the lads at ECS say battery life of my current laptop is more than 3hrs
<HiddenWolf> eruin, sure, if you leave it on the desktop, and only look at it. :)
<eruin> btw, did the network-manager discussion in here earlier today lead to any conclusions affecting breezy?
<eruin> HiddenWolf, thats when I get 2 1/2 tops
<eruin> :P
<HiddenWolf> eruin, but you've used it, they're using a brand new battery. :)
<Burgundavia> eruin, what was the gist of the discussing?
<dholbach> eruin: the package in debian built and works for me (not that i did a hardcore stress test)
<dholbach> eruin: the package on REVU
<dholbach> eruin: sorry
<eruin> well, J^ has made some great packages at http://bootlab.org/~j/NetworkManager-breezy/ (using these myself atm) and wanted to get them in to replace the broken stuff in universe
<eruin> but the guy responsible for getting it into breezy+1 main atleast initially didn't like the idea
<Burgundavia> eruin, dholbach who was that? mdz?
<zanaga> i would be really happy if just bug #13070 was fixed.. 
<zanaga> that would mean that we had an actual working network-manager
<eruin> mainly because the packages he's working on don't use bind9 afaik, and he's afraid users having used the universe packages would face upgrade hell (or that he'd have to spend days to avoid that)
<Burgundavia> ah
<ogra> eruin, nope, i didnt like the idea, when i was asked to approve the universe package
<mdz> eruin: that would have been Diziet
<eruin> Diziet is the main lad
<ogra> eruin, since main and universe devs didnt even know about each other
<eruin> that's an interesting situation indeed
<mdz> eruin: however, further discussion has moved back toward using bind9, but splitting up the bind9 package to avoid the current problems
<mdz> eruin: not much will be done with it until after breezy
<ogra> eruin, so i opposed to approve an upload before there wasnt some communication going on...
<eruin> thanks for clearing this up - I lost my buffer...
<j^> ogra to not further repeat this myth, i was in mail contact with ian before
<j^> also with thom and adam
<ogra> j^, you told me you didnt commiunicate with the amin devs and had n-m ready since warty
<ogra> s/amin/main
<j^> ogra i said he was not responsive and not intested in nm before b+1
<eruin> eek, keyboard stopped responding when testing volume hotkeys
<Lathiat> eruin: haha
<eruin> volume down set the volume to 0 with that fancy gnome graphic on-screen, volume up set the volume to max (eek) and then the keyboard was dead ;-)
<sabdfl> so guys, would today be a fun day to go hoary -> breezy on my laptop?
<sabdfl> or would the fun be all twisted?
<eruin> it'd be fun
<dholbach> sabdfl: you'd get USPLASH! :)
<eruin> though a fresh daily install would probably be more fun
<eruin> does anyone in here know how to properly test suspend/hibernate/sleep features?
<eruin> I'm completely at loss
<sladen> eruin: System->Logout->Hibernate.  Wait.  Press power-switch.  Wait.  Does it look the same as 3minutes earlier ;-)
<Burgundavia> sabdfl, do you have one of the machines that the TestingTeam has?
<eruin> sladen, well, my screen goes blankand things get quiet
<eruin> but then xscreensaver seems to kick in before things really die
<eruin> I know I saw my hibernation led glow a week or so back
<Burgundavia> eruin, hibernate takes a second and the screen blanks right away
<sladen> eruin: ah, okay.  You probably need to pop along to #ubuntu-laptop with details of your machine
<ivoks> eruin: same thing on my lap too
<eruin> I
<sabdfl> Burgundavia: X40
<sabdfl> so, yes, probably
<eruin> sladen, they don't seem very talkative in there today. I'll try again tomorrow ;)
<Burgundavia> sabdfl, don't see an X40 on this list
<sladen> ivoks: not coming out of hibernate?  Or never going to hibernate.  (Hibernate == machine fully switched off)
<ivoks> not going to
<ivoks> everything stops, but then wakes up before it ends
<eruin> yeh, same story here
<sladen> Burgundavia: mjg59 has an X40 so things should just work
<Burgundavia> sladen, right
<Burgundavia> sabdfl, in general, it seems safe to jump right now
<sabdfl> mdz: any comments on the migrate-to-breezy-today plan?
<ivoks> another thing is broken nvidia driver, but we can't do much here... and that's too bad
<mdz> sabdfl: migrate what/whom to breezy today?
<mdz> sabdfl: oh, you
<mdz> sabdfl: do it
<mdz> sabdfl: have you seen usplash yet? ;-)
<dholbach> sabdfl: i have it on an x40 too - i upgraded my brothers computer (a k7) yesterday and they both run nicely
<Nafallo> :-)
<elmo> sabdfl: I upgraded this throw-away laptop today, it was relatively painless
<sabdfl> ok. DOIT
<Nafallo> sabdfl: w8 till after the meeting ;-)
<sabdfl> Nafallo: oh ye of little faith
<Robot101> mjg59: did you fix the bluetooth? :)
<eruin> is usplash supposed to drop off long before gdm comes up?
<Nafallo> :-)
<Burgundavia> eruin, known bug
<eruin> kk
<_derek__> my X hasn't booted in 2 months :)
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<shackan> talking about hibernate, in the last days, after hibernating it reboots rather than power off
<mdz> _derek__: which bug#?
<_derek__> mdz: 14120
<_derek__> i just filed it this w/e
<_derek__> its not a big deal
<_derek__> i have other boxes that aren't using gdm
<mdz> _derek__: not being able to login for 2 months sounds like a big deal...
<mdz> in that bug, it looks like X is starting fine
<mdz> and that the problem is with GNOME
<_derek__> mdz: hehe, well if it were my only computer it would be a problem, but i am using my other for the time being (till it gets ironed out)
<_derek__> mdz: yeah, it is with gdm/gnome (not sure which)
<mdz> _derek__: make sure the loopback interface (lo) is configured properly
<mdz> it looks like you're running netapplet or something? you could try removing all the non-main packages you have installed
<mdz> GNOME is working for others
<_derek__> mdz: hmm, i am not home now, but when i get home i will, lemme see if my router will let me ssh in
<_derek__> mdz: how do i know if my lo is configed properly?
<lifeless> who is 'xavier poinsard' ?
<mdz> _derek__: "ifconfig"
<ogra> lifeless, you go for MOTU i heard ? 
<sladen> shackan: there's various issues to do with power-off;  the method was power-off method was changed
<lifeless> ogra: working through the process.
<_derek__> mdz: my router isn't letting me to ssh to it, but if i have an lo on there, then it is all setup?
<mdz> _derek__: no, it needs to have IP address 127.0.0.1, be set to "up", etc.
<ogra> lifeless, so you just miss the first meeting that you need for approval
<_derek__> mdz: ok, when I go home I will try that, then I will try removing all non-main packages (thats going to be fun :) )
<lifeless> ogra: I know, I'm not rushing through.
<ogra> ah, ok :)
<sladen> Kamion: can d-i be made to worry if you don't have a swap device ...hibernate don't work otherwise
<lifeless> ogra: I didn't have up the wiki page describing my exploits yet, for instance.
<_derek__> does anyone here know "Sean D. Quinn", the other person who had the same problem, him and I can discuss it (if he uses irc)
<ogra> ah, ok
<_derek__> mdz: also, is there a gnome log for when it starts up?
<Burgundavia> _derek__, he does. He sometimes hanges out in -doc, afaicr
<mdz> _derek__: ~/.xsession-errors; I think you already sent it in
<_derek__> Burgundavia: whats his nick?
<Burgundavia> _derek__, he just joined
<squinn> me?
<_derek__> squinn: can I pm you?
<squinn> sure
<_derek__> mdz: thanks for your help, i will let you know what i find
<Kamion> sladen: just needs a partman-basicfilesystems sync; it's on my to-do list
<Kamion> need to give it a quick test first
<_derek__> squinn: you have a pm
<slomo> can someone tell me why mplayer failed on the buildds and works in pbuilder? it seems the buildds don't get the build-depends right...
<ivoks> slomo: even LP doesn't like my GPG :))
<slomo> ivoks: lol... but i had your problems too... i tried until it worked ;)
<Nafallo> slomo: thank me for that ;-)
<Nafallo> slomo: you have an  in your name, the bug and trying came from me ;-)
<slomo> Nafallo: ?
<slomo> Nafallo: ah... because of launchpad ;)
<Nafallo> slomo: yea :-)
<sladen> Kamion: okay, thanks
<CarlFK> I pluged in a Logitec web cam, ran $ lsusb: it didnt report anything or return me to a prompt - is this a bug?
<sladen> CarlFK: if the webcam is known to work, yes it is a bug
<CarlFK> sladen - I was trying to see if it was on the list: https://wiki.ubuntu.com/HardwareSupportComponentsMultimediaWebCameras
<CarlFK> so I can't tell if it is known or not
<CarlFK> but I am sruprised that lsusb would "hang"
<CarlFK> unpluging it didn't seem to help.  
<dholbach> need to go... have a nice evening
<sladen> CarlFK: is it spca5xx ?  I have feeling the driver maybe buggy;  it hung the machine when I yanked out a webcam using that module
<CarlFK> box says "quick cam chat"
<CarlFK> I don't see any model #
<sladen> CarlFK: google for the FCC ID
<CarlFK> where do I fidn the fcc id?
<CarlFK> found the fcc compliance statement....
<CarlFK> http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2204,CONTENTID=10034
<CarlFK> that is the device
#ubuntu-devel 2006-08-28
<Keybuk> Kamion: how was your trip home?
<desrt> Kamion; nobody really uses openoffice, ...
<Kamion> Keybuk: uneventful
<LaserJock> or that firefox thing ;-)
<Kamion> (just how I like it)
<desrt> apt-get install epiphany-browser, baby
<Keybuk> Kamion: those foomatic ppds people claim aren't used?
<Kamion> people suggesting things that won't happen, please don't bother - I'm serious here
<Kamion> foomatic> hmm, would like opinion from printing gurus before doing that
<desrt> anything you remove will step on at least one or two toes
<Keybuk> Kamion: we ship several different gnome icon themes
<Kamion> desrt: not if I remove the stuff that was only just added
<Kamion> and honestly, I'm not that bothered about toes, but removing openoffice and firefox would step on sabdfl's toes and I like my job
<desrt> Kamion; then you step on recently placed toes.  those hurt a lot.
<Kamion> desrt: *shrug*
<desrt> :)
<Kamion> changes introducing breakage can and should be reverted
<sivang> Kamion: hehe
<Kamion> but I'd like to know if the people who committed those changes have any suggestions
<Kamion> fonts are a distant possibility, but that's a tricky one too
<desrt> right.  so y'all ship dejavu these days, right?
<desrt> doesn't that, in theory, mean that you shouldn't be shipping all of the various codeset-specific fonts....
* desrt blogged about the pain caused by this the other day
<crimsun> Kamion: perhaps a few ttf- packages? For instance, I see ttf-bitstream-vera and ttf-dejavu for ubuntu-desktop.
<crimsun> arg, too late.
<sivang> speaking of fonts, I wonder if that caused emacs21 to have such ugly fonts be default...
<desrt> crimsun; dejavu should stay
<Kamion> it's stuff like ttf-kochi-* that's the real hugeness, but removing those would regress Japanese support
<Kamion> ttf-bitstream-vera is 354028 bytes. who cares?
<desrt> Kamion; kochi looks nice but is incomplete
<Riddell> Kamion: could we look at having language packs Recommend on fonts (along with install recommends by default)
<desrt> Kamion; if you use kochi you end up getting one character in kochi and the next one (which isn't in kochi) rendered in a different font -- looks awful
<Kamion> desrt: honestly, I want an opinion from native Japanese people before nuking it
<sivang> Riddell: FYI I'm trying to co-operate with KleanSweep's author to see how we can produce a unified system cleaning tool :-)
<Kamion> Riddell: doesn't particularly help - there's no size gain unless we remove them from the CD and that is politically difficult
<Riddell> Kamion: of course
<Kamion> Riddell: if you want to run that particular gauntlet with sabdfl, silbs, and mdz, you're welcome :)
<desrt> Kamion; a good call.  the girl who complained to me about the problem was chinese.  they are not to be trusted on issues about the japanese :)
<Riddell> sivang: I don't even know what KleanSweep does :)
<Kamion> I would expect Chinese to use characters not in kochi
<desrt> Kamion; kanji is kanji
<desrt> same codepoints in unicode regardless of the language you're in
<sivang> Riddell: very perliminiary go at a tool for cleaning duplicates , borken binaries and stuff
<Kamion> my understanding has always been that that is a huge oversimplification
<desrt> Kamion; different languages hint the characters to be displayed slightly differently
<Kamion> look, I'm not listening until you get a Japanese person to say that they don't need kochi. :)
<desrt> Kamion; point is -- you're probably right about the japanese thing
<desrt> i'm just explaining why it was a problem for her
<sivang> Riddell: but already ahead of me, with a KDE GUI (plans are to have QT independent one) and a perl script as a backend. It's currently targetted for the experienced user (as many of KDE's stuff are) but hopefully together with the author who seems keen for getting involved in Kubuntu/Ubuntu we'll make it nice and easy.
<Riddell> I wouldn't say kde is targeted at experienced users...
<desrt> is ekiga on the cd?
<sivang> Riddell: (e.g. it requires that you know which duplicates can be removed, and which files that do not belong to any package need to stay)
<desrt> because seriously... nobody uses ekiga
<Kamion> desrt: a bunch of Canonical employees would disagree with you there
<desrt> it's at least several orders of magnatude between the users of fspot and ekiga
<Keybuk> Kamion: example-content would buy us 20MB ... could strip something out of that
<desrt> Kamion; canonical employees are not "human beings"
<Kamion> thanks much
<desrt> Keybuk; touchy
<Keybuk> the dapper ogg alone would be 11MB
<crimsun> also, how about using ogg vorbis in ubuntu-sounds?
<Kamion> Keybuk: gnome icon themes> what are the sizes?
<gnomefreak> can you drop bluetooth apps off install? to free up room?
<Keybuk> desrt: though Mark is now telling everybody edgy will definitely come with mono
<Keybuk> so taking that out would be equally touchy
<sivang> hmmm..Mono...
<Kamion> Keybuk: desrt isn't suggesting taking out mono
<desrt> Keybuk; i was going to suggest example content earlier but i understand it has a special place in some important hearts...
<Kamion> -rw-r--r-- 1 root root 11137689 2006-05-24 15:37 Experience ubuntu.ogg
<Kamion> crimsun: that's kind of the big one already ...
<Keybuk> gnomefreak: they're not that big
<Keybuk> clearly, we need bigger CDs
<desrt> or different compression
<Kamion> gnomefreak: see sizes in http://people.ubuntu.com/~cjwatson/germinate-output/edgy/desktop before making suggestions
<gnomefreak> lol bigger cd's = dvds
<LaserJock> or shorter .oggs
<Keybuk> tbh, I really can't find anything to remove
* desrt wonders how big ekiga is, even
<Riddell> the example content video does seem like a likely candidate
<Kamion> 3.6MB. Useful, but not sufficient in itself
<tseng> 3650936
<tseng> (1.2mb installed)
<desrt> it has a lot of exotic deps
<tseng> no thats not right
* desrt wonders what libpt is
<Kamion> I wouldn't be too opposed to taking out ekiga - would need to talk with sabdfl though
<desrt> oh.  i have a good one.  nice and controversial
<desrt> humans don't read /usr/share/doc
<Kamion> not happening
<desrt> yet every single package ships a few k of junk there
<slomo> what about gthumb? does almost the same as f-spot... but that's only ~1,1 mb
* sivang recalls the rpath guys don't ship it and have infras. to take it out
<Burgundavia> Kamion: what about dropping hwdb-client? I see kubuntu already has
<desrt> slomo; you need gthumb for picture import to work
<Kamion> Burgundavia: 2.1MB, not sufficient
<desrt> slomo; unless fspot also does a camera-import sort of thing
<Kamion> Burgundavia: and anyway, kubuntu never had it
<Burgundavia> combine it with a few other removals
<Kamion> check facts first
<Burgundavia> thats boring ;)
<slomo> desrt: afaik it does, i don't know that much about f-spot... better ask ajmitch ;)
<Riddell> Burgundavia: no, kubuntu added hwdb-client
<Burgundavia> Riddell: right
<tseng> what about it?
<tseng> desrt: yes of course f-spot does imports
<tseng> desrt: thats the main use case
<desrt> then gthumb is a good candidate for the chopping block
<tseng> it is
<Burgundavia> we could do eog as well
<tseng> but you should read the lengthy thread of tears on -devel
<desrt> take away eog and i'll remove your hands
<Burgundavia> desrt: I use those!
<slomo> Burgundavia: not eog... it has different use cases than f-spot
<tseng> about "my favorite gthumb feature i will kick and scream about if you replace it"
<desrt> and i use eog.
<tseng> some of them were eog features
<Kamion> desrt: you don't get to use "you guys aren't human beings" without also considering yourself not a human being, incidentally :P
<Burgundavia> slomo: currently yes. f-spot just needs a "simple browse mode"
<desrt> Kamion; it's fair... but jpegs and pngs open automatically in eog
<desrt> Kamion; i know human beings use it en masse if only by that property alone
<crimsun> xscreensaver-gl, perhaps? I'm thinking trimming multiple packages.
<desrt> ya.. you could split out the screensavers into -core and -extras
<desrt> but then you have a whole new microdebate
<crimsun> they're split to some extent already according to the xscreensaver- descriptions, but my rationale is that the package doesn't actually provide any added functionality.
<desrt> a friend just called.  i told him about the discussion we're having.  his first question: "wtf is ekiga?"
<desrt> he's been an ubuntu user for almost 2 years :)
<gnomefreak> gnome-meeting ;)
* sivang wonders why the name changed at all, it's still same software isn't it?
<Keybuk> sivang: because it's a VoIP soft phone now, not a netmeeting client
<Burgundavia> indeed
<Kamion> crimsun: xscreensaver-gl is also a sabdfl item, I'm afraid - he took a personal interest in that
<crimsun> ah
<Keybuk> Kamion: is there anything left in desktop that sabdfl _hasn't_ taken a personal interest in?
<Kamion> Keybuk: there are probably a few niche items :P
<Kamion> is pitti around next week?
<Riddell> I think he's canoeing
<Keybuk> Kamion: computer says No
<Kamion> bugger, was hoping to get weigh-in on the foomatic-filters-ppds suggestion
<Keybuk> mdz is away, sabdfl is away
<Kamion> oh, sabdfl is away too? meep
<Riddell> so they won't be able to complain...
<Burgundavia> Kamion: knot2 is targetted for later this week, no? (just want to know when I need to finally finish that bloody Knot2 page)
<Keybuk> fabbione is away
<sivang> Keybuk: ah
<Kamion> Burgundavia: yes, assuming I can resolve this issue
<Burgundavia> right
<Keybuk> iwj is away
<Keybuk> err
<Keybuk> IS ANYONE AT WORK THIS WEEK ?!
<Kamion> I am, though not Monday
<Kamion> (bank holiday)
<Keybuk> indeed
<Keybuk> I'll be still on the way back from Cambridge tomorrow
<Riddell> still at the BBQ?  must have been a good party
<Keybuk> yeah
<Kamion> anyone have comments on the suggested removal of foomatic-db-gutenprint?
<nictuku> wouldn't a subversion extension for nautilus be useful? me and kov are writing one
<Burgundavia> Kamion: removing it now is fairly painless, because we have another knot to readd it back in
<Kamion> indeed
<tseng> Kamion: the fact that I know nothing about that package could be a sign
<Kamion> it's not
<Riddell> printer drivers sound important to me
<Kamion> no offence, but lots of people don't know about printer driver
<Kamion> s
<Kamion> Riddell: cupsys-driver-gutenprint apparently does everything necessary
<Kamion> the claim is that foomatic-db-gutenprint is only needed for lpr and lprng spoolers, not cupsys
<Burgundavia> Riddell: printer drivers are a general mess
<Riddell> could test out if pitti has phone signal in his tent
<Kamion> I've removed foomatic-db-gutenprint for now
<Burgundavia> Riddell: part of the issue, afaict, there is no "central clearing house" for all printer drivers, that does a timely release. Gutenprint does some and linuxprinting.org has others
<slomo> Kamion: is that enough free space? otherwise i would suggest gthumb additionally
<Burgundavia> we should probably only ship with gthumb OR f-spot, we might want to remove gthumb to get additional testing on f-spots weakness'
<Kamion> slomo: see http://cdimage.ubuntu.com/daily/current/
<Kamion> we need getting on for 30MB
<Kamion> I think I might well unilaterally drop "Experience Ubuntu.ogg" and apologise to sabdfl later
<Burgundavia> Kamion: example content can be trimmed. It is only really important for the final release anyway
<Kamion> gthumb seems a reasonable suggestion (if controversial), but it's only 1MB
<Burgundavia> 95% of the users of edgy have already seen that video
<Kamion> Burgundavia: if something is going to come back in for the final release, then we need to reserve space for it early
<Burgundavia> yep
<Kamion> but granted on the second point
<Burgundavia> yes
* LaserJock runs to go watch it before it's gone :-)
<Spads> mdke: ping
<geser> hello
<geser> what is the correct syntax to mark a bug as fixed through the changelog?
<Kamion> oho, there are in fact a lot of language packs I can trim
<Kamion> that helps :)
<Kamion> though maybe doesn't help Edubuntu
<LaserJock> heh, poor Edubuntu, always so fat ;-)
<Keybuk> yeah, get rid of the lebowskistan locales
<Burgundavia> languagesupport-whiterussian?
<Riddell> Kamion: presumably edubuntu doesn't have mono?
<Kamion> f-spot seems less good for just quickly browsing through a directory of images (on a throwaway basis) than gthumb is
<Burgundavia> Kamion: that is what eog is for
<Kamion> Riddell: nope
<Keybuk> Kamion: right, but that's what nautilus and/or eog are for
<tseng> eog can do what gthumb can in terms of browsing
<tseng> (and f-spot could with a few hours of hacking)
<Burgundavia> tseng: it would be glorious of f-spot could have a simple/fast browse mode
<tseng> Burgundavia: its "faster" than eog according to larry
<Kamion> hmm, true, eog is ok
<tseng> Burgundavia: it just doesnt switch through the directory easily
<Keybuk> f-spot is impressively fast, I must admit
<Keybuk> it's one of the first things that struck me about it
* jdub hopes lewing has time to tidy up the f-spot viewer mode
<tseng> Keybuk: it handles large libraries significantly better than iphoto
<Burgundavia> tseng: yes
<tseng> Keybuk: which is something we can pimp the hell out of if someone does a scientific write up
<tseng> miguel has only done wallclock
<tseng> if someone has some fancy european beer larry is into or something...
<tseng> bribe away
<tseng> eog is also part of "gnome", i am not sure how much that will anger upstream if we remove it
<tseng> jdub: ?
<jdub> tseng: nowt i suspect, it's not really an integration target
<jdub> more of a user acceptance issue, i think
<tseng> well the biggest complaint is the browsing
<tseng> probably by a vocal minority
<bddebian> Heya tseng
<tseng> I imagine there is another group of users that don't know or care what eog is
<tseng> and that it can browse directories like that
<tseng> hello, Burgundavia 
<tseng> and bddebian ...
* tseng masters tab
<bddebian> heh
<Burgundavia> users need a fast way of browsing pictures
<Burgundavia> how they do that is totally immaterial to 95%
<Kamion> jdub: same question (angering upstream) for ekiga
<Burgundavia> I disagree with removing eog because fspot viewer mode isn't up to snuff yet
<bddebian> Wow everybody's here :-)
<Burgundavia> Kamion: one of the key reason I would support keeping ekiga in the desktop is to make people aware of the alternatives to skype
<Burgundavia> reasons, rather
<tseng> Burgundavia: MS NetChat or whatever it is
<Burgundavia> that too
<tseng> I never saw anyone use it.
<jdub> Kamion: want to remove it for space reasons, or...?
<Kamion> jdub: space, maybe
<Kamion> there are other candidates of course, there always are, but it's one of the ones that's been suggested on a less-widely-used basis
<Kamion> although I see it was one of the top new features listed for GNOME 2.14
<Kamion> which is of course interesting since we've been shipping gnomemeeting/ekiga since warty ;)
<Burgundavia> Kamion: what came in 2.14 was SIP support
<jdub> Kamion: maybe wait to remove ekiga until the telepathy stack is ready to rock
<jdub> Kamion: it is a useful feature to be able to talk about
<Kamion> Burgundavia: oh, good point, I misread
<Kamion> will telepathy be any smaller? :)
<jdub> Kamion: i don't think "angering upstream" is going to be much of a factor though
<tseng> jdub: google talk would be alot more wideless useful than an arbitrary sip server
<tseng> jdub: (i think)
<tseng> wideley
<Kamion> agreed on useful headline feature - although I do think that folks shouldn't limit themselves to talking about what's installed by default
<tseng> widely
<jdub> Kamion: yeah, probably (though it brings in a bunch of libs)
<jdub> Kamion: yeah, same FirstAgainstTheWall problem with GIMP
<Kamion> mm, that's not one I'm keen to do either
<Keybuk> we could increase to 800MB CDs?
<Kamion> I wish we had a better option for fonts, but desupporting non-ISO-8859-* speakers without network connections doesn't make me a happy bunny
<Kamion> Keybuk: ... or not
<Keybuk> Kamion: any particular reason why not?
<Kamion> Keybuk: you can field ALL the support requests
<Keybuk> it's edgy, half the crap won't run without modern hardware, so you're likely to have a CD writer made in the last decade
<Kamion> because, unlike the last time we increased the CD size we demanded, there is not a clear majority of media out there capable of 800MB
<jdub> Kamion: perhaps we could think about removing non-ttf 100dpi/75dpi fonts...
<tseng> Keybuk: people have spools of 750mb cds sitting around
<Keybuk> meh, that's trye I guess
<Kamion> come on, most media one buys in the shop isn't 800MB
<tseng> that they expect to use
<Keybuk> 750MB is the more prevalent media
<Keybuk> forgot about that
<Kamion> and I'll get all the complaints. I already got complaints about the dapper.0 powerpc CD being too big to burn with some software/media, and that was 703MB or something
<Kamion> jdub: hmm, doesn't sound popular with the older-Unix crowd, and they'd blog about it
<jdub> Kamion: how much of our software realistically requires it these days?
<Kamion> as far as fonts go, ttf-* are the heavyweight ones
<Keybuk> this is a non-win discussion
<jdub> hrm, i guess there's a bunch of tcl/tk things, and old school X stuff
<Keybuk> we're at the point where we can't justify removing much at all
<Kamion> jdub: if you dislike gnome-terminal and like fast terminals :-), you want old X fonts
<jdub> Kamion: not scalable old X fonts
<jdub> you can totally remove gimp
<Kamion> jdub: ttf-scalable is 344KB
<Kamion> er, I mean xfonts-scalable
<desrt> i guess example content was (literally) a no-go?
<jdub> g-a-i is at a point where removing things like gimp is viable
<Kamion> desrt: I've sent mail about it
<Kamion> gimp also sounds like a negative blog publicity attractor
<Kamion> removing it, that is
<desrt> btw guys: for what it's worth i hear a lot of people talk about how awesome it is that ubuntu still fits on one CD
<jdub> Kamion: not sure you should be ruled by negative blog publicity
<Kamion> jdub: not ruled by it, but PR is worth considering
<Keybuk> desrt: it doesn't fit :)  the CD is a very difficultly laced corset :p
<Kamion> desrt: that's certainly not something we plan to change in the near future
<jdub> with usefully published rationale people can point to, i think removing gimp is entirely understandable
<bddebian> Keybuk: :-)
<Kamion> jdub: you always wanted to get rid of it, though :)
<Kamion> there are others more attached to it
<jdub> (clearly stating the rationale and fact that it can be installed very easily from supported set)
<Kamion> I'm not saying no, just saying I put it further away from the wall than you do
<jdub> Kamion: well, no, i always had it on my list of things that could be removed at some point in the future because they were inessential
<Burgundavia> fwiw: fspot now doing redeye and cropping removes 90% of the raison-de-etre of gimp installed by defeault
<jdub> if we had "gimp elements" that should totally go on the cd :-)
<Kamion> I'm a little concerned that we've been letting printing stuff grow without end because too few developers understand it
<Kamion> gimp elements?
<jdub> Kamion: riffing on "photoshop elements" (the cut down easy version of it)
<Burgundavia> Kamion: photoshop elements is a cutedown version of photoshop that has been flying off the shelves
<Kamion> ah
<desrt> jdub; removing gimp is likely to go over better, too, than removing, say, abiword
<mjg59> Burgundavia: Yes
<jdub> desrt: abiword isn't on the CD (or are you making a hub joke?)
<Burgundavia> I can the blog post now "Ubuntu sabatoges the GIMP"
<desrt> jdub; not a hub joke.  abiword developer persecution complex joke.
<Burgundavia> mjg59: thanks
<mjg59> Burgundavia: Let me know if it causes any problems - I believe it to be safe now
<desrt> jdub; abiword got removed from some fedora cd a while back and planet was ablaze
<jdub> desrt: you could replace all of those big words with "hub" and still be utterly accurate :)
<desrt> jdub; it's not just hub :)
<jdub> wow, x-lite just got vastly less sucky
* desrt still thinks that /usr/share/doc could go
<desrt> it might not be the debian way... but seriously... no real human uses that directory
<bddebian> How about a DSU? (Damn Small Ubuntu) to fit on a USB Stick :-)
<maswan> bddebian: just get a 1-gig USB stick. ;)
<bddebian> maswan: Have you seen DSL?
<maswan> bddebian: I think I've heard of it
<maswan> bddebian: no personal experience with DSL though
<bddebian> It's actually quite cool
<Kamion> desrt: they do when they're pointed at it
<Kamion> I'm not interested in removing documentation. seriously.
<desrt> /usr/share/doc isn't documentation
<Kamion> I'm especially not interested in removing documentation when it would take hundreds of uploads to implement
<Kamion> rubbish
* jdub turns up the channel air conditioning
<desrt> the hundreds of uploads thing is a good argument
<Kamion> and we're not removing changelogs. no way. too useful for us
<desrt> the internet is a one-to-one function that maps version numbers to changelogs
<Kamion> hundreds of uploads> that's just for the CD
<bddebian> jdub: :-)
<Kamion> it must be nice for you to have internet everywhere you go, even when you're travelling
<desrt> Kamion; only costs $50/mo too
<Kamion> perhaps you could share your technology
<Kamion> or your money
<bddebian> heh
* ..[topic/#ubuntu-devel:irc.freenode.net] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released
<bddebian> Sheesh
<desrt> welcome, everyone, to freenode
<desrt> the OFFICIAL network of the ubuntu project
<desrt> enjoy your stay
<desrt> (it may be short)
<Burgundavia> desrt: be nice
<Keybuk> Kamion: not to mention licence zealots
<desrt> oh right.  the GPL has some sort of a clause about that
<Keybuk> oh good
<Keybuk> "a replacement ircd server tree"
<Keybuk> how nih
<desrt> Keybuk; hm?
<lifeless> Keybuk: I would have thought you would support that :)
<Keybuk> lilospam
<desrt> oh.  i finally ignored lilo!*@*
* desrt got sick of freenode's prefered hostname format changing on a weekly basis and causing lilo to evade his previous bans
<exobuzz> the internet was fine in 1995
<exobuzz> it all worked
<Keybuk> August 95 ?
<Burgundavia> exobuzz: for about 20k people
<exobuzz> well around that time and before.
<exobuzz> :-)
<exobuzz> and i dont ever remember getting a popup, or even adverts ont he www
<desrt> if y'all think this is bad you should have been on efnet in the late 90s
<exobuzz> just real information
<desrt> now _that_ was a party
<exobuzz> aah the irc war period ?
<desrt> oh yes
<exobuzz> check my clone bots. etc etc
<lifeless> man, undernet
<desrt> lilo is merely incompetent.  back then you had people actively trying to take down irc servers
<bddebian> Heya lifeless
<tseng> desrt: that was awful
<maswan> desrt: we moved our local channel from ircnet to gimpnet back then
<exobuzz> gimpnet.. thats a wonderful name ..
<desrt> and efnet had like 50x the population of (then) openprojects
<maswan> ah, freenode is starting to get a resonably high user count these days though
<exobuzz> you know, the gimp is very nice piece of software, but it probably should rename if it wants to be taken serously in the business world.. or maybe it doesnt
<desrt> even now it's 10x... efnet is very peaceful by comparison :)
<Keybuk> exobuzz: it is being renamed
<exobuzz> it is ? what to ?
<Keybuk> it'll now be the sadomasochistic submissive personality with a distinct rubber fetish
<Keybuk> (prizes to anyone who can backronym *that*)
<maswan> you want a backronym to the entire thing, or just to tsspwadrf?
<desrt> sounds a bit like sabdfl
* Keybuk activates an emergency mind-wipe
<maswan> desrt: btw, ircnet is nice and quiet these days too
<desrt> SAdo suB with Distinct Fetish....
<welshbyte> sudo apt-get install sadsubpwidruft
<desrt> maswan; i think they learned a lot of leasons from the irc wars about how to make a network withstand anything
<maswan> desrt: yup
<desrt> maswan; washed-up efnet server admins are probably really good people to have on staff :)
<maswan> desrt: still, the kiddies that wield 10+ GBit/s packeting still can make an impact
<Keybuk> desrt: they're too washed up
<desrt> maswan; you can only do so much....
<exobuzz> well. if it wasnt for all the bloody remote controlled pc's
<desrt> "bill gates made efnet suck!"
<exobuzz> and that's partly microsofts fault for not addressing security earlier on
<desrt> hah.  yup.
<maswan> desrt: I remember back when the current generation of our nren was new, they made a point of "hey, we took 1.5Gbit/s of DDoS and we delivered the packets. poor server, but the network didn't go down."
<exobuzz> its also partly the fault of people like "my mum" who open up emails with attachments which advertise "pretty screensaver"
<desrt> "poor server" is a funny concept :)
<maswan> exobuzz: again reminding us why it would have been useful to separate "display" and "execute". :/
<desrt> i mean... if you really think about it you'll find it quite amusing :)
<exobuzz> maswan: yeh
<Keybuk> so, as well as upstart, I'm going to write a daemon that you install to make your machine run faster
<desrt> jdub; welcome back.
<Keybuk> it'll shave 5s or so off the boot process, make all apps start faster and use less memory
<Keybuk> I shall call it "placebo"
* maswan double-clicks on Keybuk's irc statement in the hope of making stuff go fast
<desrt> Keybuk; can't we just have people install gentoo for that?
<desrt> Keybuk; i hear it feels a lot faster
<maswan> oh, call it "placeboo"
<exobuzz> of course it feels faster when you have been waiting 4 days for something to compile!
<exobuzz> :)
<HrdwrBoB> placebo -funroll-loops
<desrt> at that point it's practically your baby.  it's only natural to feel proud :)
<exobuzz> and with gentoo you have the added benefit of a source package installing everything + teh kitchen sink onto your system, so you must upgrade to newer faster hd's all the time
<Keybuk> I just realised why upstart "Boots Faster"
<desrt> woh.  easy there.
<Keybuk> it doesn't start usplash
<sladen> Keybuk: so what speed we up to at the moment?
<desrt> there was something on planet a few days ago about how having a usplash running in non-splash mode slows down the boot
<tseng> desrt: actually, when warty came out, the entire gentoo fanboydom wet itself
<tseng> desrt: over LDFLAGS
<tseng> linker optimization
<Keybuk> sladen: 44s
<Keybuk> .4
<jdub> and that's why we have tseng!
<desrt> tseng; i'm afraid i don't understand
<jdub> interesting, Amazon EC2 uses Xen
<jdub> they're planning to have ubuntu images fairly soon, too
<lifeless> EC2?
<jsgotangco> EC2?
<lifeless> jdub: are you going to the redhat thing tomorrow ?
<jdub> lifeless: massive virtualised 'on demand' computing cluster
<jdub> lifeless: wasn't planning to (they didn't get back to me about speaking)
<jdub> http://www.amazon.com/b/ref=sc_fe_l_2/103-8136015-6811048?ie=UTF8&node=201590011&no=3435361&me=A36L942TSJ2AJA
<desrt> crap
<desrt> dad needs to go to hospital.  amulence is here
<desrt> bbl.
<jdub> "amazon elastic compute cloud"
<lifeless> rocking
<jdub> desrt: ! good luck
<jsgotangco> nice name
<lifeless> desrt: goodluck!
<jdub> Pay only for what you use. 
<jdub> $0.10 per instance-hour consumed (or part of an hour consumed). 
<jdub> $0.20 per GB of data transferred outside of Amazon (i.e., Internet traffic). 
<jdub> $0.15 per GB-Month of Amazon S3 storage used for your images (charged by Amazon S3).
<jdub> 
<lifeless> jdub: ok, wondering if its worth dropping in to see what their message is
<jdub> you use S3 for storage (transfer internally is free)
<jdub> lifeless: want to go?
<lifeless> jdub: kinda :). I think someone should keep an eye on them ;)
<jdub> my edgy server upgrade was pretty boring, btw
<jdub> i babied the upgrade a bit
<jdub> but there were no spectacular breakages or anything
<jdub> though i did get to swap in my new SATA card
<zul_> hmmm...debian has ported update-grub to grun2
<zul_> grub2 even
<jdub> zul: now *that's* edgy!
<zul> i guess it is :)
<Burgundavia> how complete is grub2?
<zul> its still got a way to go ihmo
<zul> heh...maybe i should go to bed
<zul> its usable though
<Burgundavia> zul: hasn't it been in development for years?
<zul> apparently
<robertj> there seems to be a phenomena in which items at either tail of the development time bell-curve are very unstable
<Kaleo> does anybody know if the existence of the file /var/lock/acpisleep is checked at any point in the acpi scripts ?
<bluefoxicy> I am so frigging lazy.
<bddebian> That's nice
<bluefoxicy> seriously, I have a one-file C project I'm messing with
<bluefoxicy> I wrote the C file such that ./malloc.c compiles it.
<zul> thats nice
<exobuzz> you will find that a malloc funciton has already been written
<bddebian> heh
<exobuzz> so you cant be that lazy
<exobuzz> writing your own
<exobuzz> :)
<exobuzz> aaah my new code. finally finished. its a masterpiece.... 4 days hard work.. ./printf.c .. no. wait dont't tell me. aaargh!!
<exobuzz> what about alias @="make" or something
<exobuzz> :)
<lastnode> imbrandon_, you around, mate?
<bddebian> haha
<elkjaer> I do not know who to direct this to.. The daily build iso that can be downloaded from the ubuntu website is too big to fit on a 700 MB cd-rom. The latest is 724 MB.
<infinity> elkjaer: Yeah, dailies go oversized sometimes.  Obviously, we'll fix that before we do another test release.
<elkjaer> cool.. thanx
* Hobbsee waves to infinity 
* infinity hides.
* Hobbsee searches out infinity.  why are you hiding?
<infinity> Instinct. :)
<infinity> When people greet me on IRC, I run.  I'm sure it seems more rational in my head.
<Hobbsee> infinity: ahhh....i wasnt going to request *that* many things off you :P
<Hobbsee> in fact, i dotn think i was going to request anything at all
<bddebian> HI infinity! :-)
<infinity> In that case, you're my new best friend. :)
<Hobbsee> infinity: hehe, right...
<Hobbsee> infinity: now it's my turn to hide?
<infinity> Hobbsee: Oh, don't worry, I'm not clingy. :)
<infinity> Much...
<Hobbsee> infinity: hehe, right
<Hobbsee> much
<Hobbsee> infinity: did you want to give back wine?  seems that it broke due to udev
<Hobbsee> infinity: which seems fixed
<lastnode> infinity, might i bug you a little now
<desrt> arf
<desrt> destroy vs. dispose vs. finalize
<desrt> how perplexing!
<grexk> -fno-stack-protector on xen-source-2.6.16 fails to compile...
<dholbach> good morning
<tepsipakki> keybuk: upstart boots fine here :)
<doko> ajmitch: ping
<slomo> Kamion: ping?
<Kamion> slomo: hi (but not working today)
<Kamion> I'm just doing a bit of Debian work, then I'll be off again
<slomo> Kamion: np :) i only had a small question... regarding the dbus uvf exception as mdz is away this week afaik. do you have an oppinion on this? :)
<Kamion> is it OK if I read over it tomorrow?
<slomo> sure, thanks :)
<carlos> Kamion: Is there a new version of .po and .pot files for Debian Installer that should be imported into Rosetta? (either dapper or edgy?)
<carlos> Riddell: hi, around?
<lucas> are there plans to enable KPROBE in the edgy default kernel ? fedora core enables it
<sivang> morning
<imbrandon> moins sivang
<Kamion> carlos: I've set my build system to edgy, so I'll have new versions for that in a couple of hours
<carlos> Kamion: ok
<carlos> Kamion: do you want to do a new upload for Dapper?
<Kamion> carlos: not particularly
<carlos> ok
<carlos> Kamion: could you send us (rosetta@launchpad.net) the list of packages that we should block for Edgy ?
<carlos> or is it the same list as Dapper?
<Kamion> I might suck in new translations from Rosetta at the next point release, but there's no need for new strings
<Kamion> carlos: at the moment it appears to be the same
<carlos> ok
<carlos> I will prepare a wiki page with such list so we can double check that we didn't miss anything and we can update it later when needed.
<carlos> Kamion: btw, if we do an upload after you do 'suck' translations from Rosetta for a new debian installer release, the statistics are updated so people would know that their translations are being used. It's just an informative UI change.
<Kamion> carlos: so do you want me to generate files for dapper+dapper-updates first?
<Kamion> carlos: ok, look, I'm off work today, so I'll generate dapper+dapper-updates tomorrow and ping you
<Kamion> I've disabled the cron job so it won't build for edgy today
<carlos> Kamion: that would be good
<carlos> thanks
<Kamion> np
<AndrewLee> sladen: Hi, I updated bug 57081, but it seems no progress still.
<Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57081
<Riddell> carlos: hi
<Spads> http://xkcd.com/c149.html <-- ha ha sudo
<carlos> Riddell: hi, about KDE's .desktop translations
<carlos> Riddell: just to remind me how it works, I guess we should import the specific .pot files with exactly the same filename you gave them as the translation domain and include them as part of the language packs, right?
<Riddell> carlos: yes please
<carlos> ok
<ogra> Kamion, did anything else apart from the sysv-rc dependency change in openssh with your last upload ? seems the -S option doesnt create a socket anymore for me in ltsp
<Spads> oolite is kind of confusing, because the police are purple and I always thought purple meant pirates
<Spads> er, mcm
<AndrewLee> sladen: How to change the im-switch config file of scim-chewing package is still in question, who do you recommend to answer that?
<ogra> Kamion,  ssh localhost -S /tmp/olis-ssh-socket -vvv gains me a 
<ogra> debug1: Control socket "/tmp/olis-ssh-socket" does not exist
<Kamion> ogra: no
<Kamion> ogra: the message you quote is not a fatal error, and will happen if there isn't an existing master ssh client
<Kamion> on that socket
<dholbach> please let poor Kamion go back to his free day :)
<ogra> Kamion, hmm, it worked until the recent update
<Kamion> ogra: you need to use -M to make ssh be a master
<ogra> oh, damned, i missed he had a free day ...
<Kamion> ogra: ssh hasn't changed in that respect, I can assure you
<ogra> Kamion, sorry, go back relaxing and enjoy ... !
<Kamion> ogra: I suggest you use -o 'ControlMaster auto'
<ogra> ok
<Kamion> then it'll automatically create a socket if there isn't one already
<Kamion> dholbach: just before I go back to house-cleaning (joy), do you know much about printing? If so, could you have a look at the suggestion on ubuntu-devel@ to get rid of foomatic-filters-ppds from desktop and replace it with a symlink?
<Kamion> the suggestion was to put the symlink in cupsys, although I think perhaps it belongs in foomatic-db-engine instead - not sure
<dholbach> Kamion: atm I don't have a printer here to test at all. doko and pitti always looked into printing.
<Kamion> ah, ok
<Kamion> doko: if you're around this week ... ^--
<ogra> argh ... /tmp wasnt wiretable in my ltsp client ... it wasnt ssh's faut at all ... silly me ...
<ogra> *fault
<ogra> (i called it with -M in ldm btw)
<ogra> (missed that while testing with localhost)
<Kamion> if nobody's looked at it when I come back tomorrow, I'll probably Just Do It; the 11MB saving would be well worth it
<doko> Kamion, dholbach: in the past, gnome-cups-manager did use that kind of information. I'm pretty sure that it's still needed; g-c-m cannot use the xml database AFAIK
<Kamion> XML database? the change as I understand it is to generate the PPDs on the fly using foomatic-db-engine rather than having them statically on the filesystem
<LarstiQ> ogra: why not ~/.ssh/host-port-user ?
<ogra> LarstiQ, because ter is no ~/ on ltsp clients ;)
<LarstiQ> ogra: valid reason I guess ;)
<ogra> *there
<ogra> yep :)
<gnomefreak> the gnome-panel having to be refreshed before newly installed apps show up is a feature right?
<seb128> gnomefreak: what do you mean? how do you refresh the panel?
<gnomefreak> seb128: log out and back in or killall gnome-panel
<seb128> no
<seb128> that would be a bug
<seb128> if you speak about the menu
<gnomefreak> since breezy
<seb128> works fine for me and lot of other users too
<seb128> I think there is some bug for .desktop not installed to the standard location
<gnomefreak> you install an app than you have to refresh gnome panel or menu before it shows up
<seb128> but monitor should just work
<seb128> no
<gnomefreak> hmmm
<seb128> that would be a monitor bug on your box
<seb128> monitoring bug
<seb128> what package is that?
* mvo remebers that under certain conditions there was a race condition
<ogra> hmm, why has still nobody added a gconf key for the fading to gnome-session ...
<gnomefreak> any package
* ogra goes digging ...
<gnomefreak> seb128: give me a sec and i will give you a bug number
<seb128> mvo: there was the "TryExec=" being an issue if .desktop is installed before the binary
<mvo> seb128: yes
<seb128> mvo: didn't you workaround that one?
<seb128> gnomefreak: please don't open a new bug, we already have some for that
<mvo> seb128: I can't remember TBH, the problem was tricky to solve, I talked with vuntz about possible strategies
<gnomefreak> i didnt
<gnomefreak> im commenting on one someone else opened
<gnomefreak> https://launchpad.net/distros/ubuntu/+bug/57956
<Ubugtu> Malone bug 57956 in Ubuntu "Software package installed, but menu not updated until next X session" [Untriaged,Unconfirmed]  
<gnomefreak> i retrack last statment i have seen it since hoary so i figured it was normal 
<seb128> mvo: right, I think you workarounded the package by dropping the TryExec in fact
<seb128> gnomefreak: ok, will comment later
<gnomefreak> ty
<seb128> np
<mvo> :)
<ogra> seb128, gnome-sessions logout.c has a function:
<ogra> 488   if (!a11y_enabled)
<ogra> 489     {
<ogra> 490       XGrabServer (GDK_DISPLAY ());
<ogra> 491       gsm_foreach_screen (fadeout_screen);
<ogra> 492     }
<seb128> yep
<ogra> does that mean i have a key i could set for the fading not to happen ? 
<seb128> yeah, activate a11y
<seb128> but we can patch it to have a "or LTSP set" case
<ogra> ok ... so i can add a && getenv(LTSP_CLIENT) there :)
<ogra> thanks 
<seb128> I've to go for lunch, bbl
<seb128> yeah, sure
<seb128> feel free to do the change :)
<ogra> i will, thanks for the help, bon appetite :)
<seb128> ogra: you probably want use "||" and not "&&" for that
<ogra> yep
<ogra> indeed
<ogra> Keybuk, morning 
<ogra> Keybuk, does upstart come with an opportunity to blacklist services ? i just remembered i forgot to ask you about that ...
<Keybuk> "blacklist services" ?
<ogra> yes
<Keybuk> define.
<ogra> as i do in ltsp for the services that got run by the ltsp-client initscript
<ogra> if i create the chroot i remove a whole lot of stuff from rc2.d 
<ogra> (save memory make sure stuff i dont need isnt run at all etc)
<Keybuk> right
<Keybuk> so you can do that two ways with upstart
<Keybuk> 1) rm /etc/event.d/....
<Keybuk> 2) vi /etc/event.d/... and take out "on startup"
<ogra> ok, but if i rm it might cause trouble with other services that depend on that one i guess ...
<Keybuk> upstart doesn't do dependencies, remember
<ogra> i.e. i never use the networking startup script ... because i set up the interfaces statically from the client initscript
<ogra> so if a script has on defaultroute, it will work ... but not if it depends on "networking" to have finished
<ogra> well, you kind of have dependencys if you want, no ? 
<Keybuk> no, just events
<ogra> even though it might be a event thats the dependency :)
<ogra> *an
<ogra> "on avahi running" is a dependency ...
<Keybuk> you can always change them
<ogra> well, i wouldnt like to change a ton of initscripts ...
<Keybuk> I haven't yet fully figured it out
<Keybuk> suggestions welcome
<ogra> i will try with rm and see how it breaks :) assuming we'll get upstart as default in edgy
<ogra> s/how/how and if/ :)
<Keybuk> I was thinking of slipping it in before knot freeze;)
<ogra> knot2 ?
<Keybuk> just need to write shutdown now
<ogra> hmm ... k ...
<Lure> Keybuk: is UUID in /etc/fstab not supported for LVM volumes yet or should I report a bug?
<_ion> lure: Well, i don't think UUIDs are really necessary with LVM.
<_ion> lure: The device names will be static no matter in which bus the physical disk is.
<Lure> _ion: true, but not sure what is the plan for edgy
<Keybuk> Lure: we don't convert LVM volume names to UUIDs
<Keybuk> doesn't seem to be any point
<Lure> Keybuk: ok, I just started to use my LV home in Edgy dual boot and just wanted to know what is the-right-thing
<Keybuk> "don't use LVM in the first place"
<Keybuk> <G>
<HrdwrBoB> what happens if you have two LVs with the same name (f.e. you put another ubuntu installs disk in a pc with ubuntu already on it
<HrdwrBoB> (I haven't yet needed to do that, and it may well be out of scope)
<Keybuk> HrdwrBoB: you discover that using LVM was a mistake
* Keybuk is not a fan of fabbione file
<Keybuk> systems
<HrdwrBoB> haha
<Hobbsee> heh
<Hobbsee> "a mistake"
<Zdra> does someone knows why libnotify in edgy doesn't shows images from pixbuf and stock but works from URI ?!? On dapper all methods worked. http://bugzilla.gnome.org/show_bug.cgi?id=350416
<sivang> hmm, so when I boot now I see that tty mode is all wrong, flickering like hell and rolling accross the screen being displayed in the half of the screen
<sivang> and also, grub display flickers
<seb128> Zdra: no
<sivang> have my laptop gone bad already, or could the troulbes in the usplash affect grub screen as well?
<sivang> (I also noticed instead of 60hz in the resolution preferences, I get only 50 now, I think it was 60 once)
<Hobbsee> sivang: i've been getting weird tty's at times, just after the usplash ends
* Hobbsee figured it was a pebkac problem or something
<Zdra> seb128: can you reproduce the bug too ? or I'm alone ?
<seb128> Zdra: how do I try?
<Zdra> seb128: run the unit test in libnotify/tests/test-image :-)
<Zdra> or activate notification in xchat-gnome
<seb128> xchat-gnome works fine
<seb128> getting libnotify source
<Zdra> seb128: you have image ?
<seb128> what image?
<seb128> let me build libnotify
<Zdra> the x-g's icon in notify bubbles
<seb128> dunno
<zyga> hi
<seb128> Hi zyga
<zyga> Keybuk: ping
<seb128> Zdra: what I look is the text to those bubbles, I would have to pay attention for the icon next time I have one :p
<seb128> Zdra: nop, no icon
<Zdra> seb128: in libnotify's code I see it needs dbus >= 0.60
<Zdra> but it should be ok for edgy
<seb128> Zdra: configure should force that then
<seb128> Zdra: edgy had 0.62
<seb128> has 0.62
<Zdra> #if CHECK_DBUS_VERSION(0, 60)
* Zdra make some tests :)
<seb128> rodarvus: around? is there anything special to get aiglx used? is it supposed to work with a radeon card using the standard ati driver for xorg?
<rodarvus> if your ati board supports DRI yes, this is the case
<rodarvus> seb128, "glxinfo | grep rendering" shoult tell you
<seb128> $ glxinfo | grep rendering
<seb128> libGL warning: 3D driver claims to not support visual 0x4b
<seb128> direct rendering: Yes
<seb128> when running compiz I get a "compiz.real: GLX_EXT_texture_from_pixmap is missing"
<rodarvus> mjg59 uploaded a xorg-server with compositing enabled by defult this weekend, so if your board supports it, it should be working now
<seb128> my edgy is uptodate and I've no fglrx installed
<rodarvus> hmm, I'm getting the same error here. seems to be a recent bug
<seb128> BTW fglrx needs to be updated for xorg 7.1
<rodarvus> I'll have to trigger it
<seb128> ok
<Keybuk> zyga: hello
<rodarvus> seb128, infinity will do the update of fglrx (he's the only one that knows where the .tar.gz for fglrx comes from :) )
<seb128> rodarvus: ok, cool. You commented on a bug some weeks ago saying that fglrx should be updated really soon so I was wondering about it
<seb128> rodarvus: let me know if you figure something about the "GLX_EXT_texture_from_pixmap is missing"
<rodarvus> indeed, this update is due for a few weeks already, need to ping him again to check if he'll be able to do it
<rodarvus> seb128, sure, I'll take a look at it later today
<seb128> thank you
<rodarvus> no, thank YOU :)
<exobuzz> seb128: thats nto supported in the ati driver!
<seb128> exobuzz: fglrx or ati?
<exobuzz> fglrx
<seb128> exobuzz: I'm using ati
<exobuzz> ddint think the ati ones had 3d at all ?
<exobuzz> only 2d
<rodarvus> seb128: now whats really interesting is that this hook *is* supported by current Mesa
<rodarvus> ("glxinfo | grep GLX_EXT_texture_from_pixmap" to check)
<rodarvus> I wonder why compiz believes it is not.
<seb128> $ glxinfo | grep GLX_EXT_texture_from_pixmap
<seb128> libGL warning: 3D driver claims to not support visual 0x4b
<seb128>     GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, 
<seb128>     GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
<zyga> mvo: ping
<LarstiQ> exobuzz: ati has 3d fine for a couple of chips
<exobuzz> OH
<mvo> hello zyga
<mjr> ati actually calls the radeon driver for radeon chips, but yeah, the free dri driver does do 3d pretty fine for <=9250 (experimentally for <=x850)
<exobuzz> the ati driver doesnt turn the backlight on on my laptop without forcing it to think there is an external monitor..
<exobuzz> :/
<zyga> mvo: hi, I've fixed a minor crash in cnf and I'd like to know how this (and other improvements later) can get synced again
<tseng> exobuzz: file a bug?
<exobuzz> tseng: there was one filed years ago about it
<exobuzz> well. last year anyway
<tseng> well then you know what to do
<exobuzz> what ?
<tseng> start commenting on the bug adding any missing info
<mvo> zyga: if it is in your branch, I merge it and upload it. does that sound ok?
<zyga> what is the last branch have you used?
<zyga> s/have you/you have/
<mvo> zyga: http://people.ubuntu.com/~mvo/bzr/cmd-not-found--mvo/
<mvo> zyga: just write me where to merge from (and add a changelog entry) and I will sponsor the upload
<zyga> mvo: I branched the source available in edgy and pushed the original branch and the fix to http://suxx.pl/~zyga/command-not-found
<zyga> I'll clean the code up today  and try to have just one, working branch that incoporates your fixes (regarding data extraction)
<mvo> zyga: the edgy code should be identical to the branch above
<zyga> I don't thing you can just merge with that (that is a fresh branch without any ancestry)
<zyga> yes, that's cnf-0.0.2.tar.gz + the fix - stuff bzr chose to ignore according to .bzrignore
<mvo> zyga: ok, thanks. if you branch is up-to-date, I don't really mind creating a new one. I will do this now
<zyga> mvo: I don't have one branch ATM, I need to get my code cleaned up
<mvo> ok
<zyga> mvo: you can use your original branch and just apply the one-line-diff
<ogra> wow, network manager gets freaky if you run a local dhcp server on the same machine :)
<mvo> zyga: let me know when I can merge again
<zyga> mvo: thanks, I will
<ogra> even if that server isnt bound to the interface 
<Zdra> seb128: for the image on notify bubbles, I read libnotify and notification-daemon's code. it seems good. the daemon print a warning because it doesn't receive what is expected, seems a dbus bug
<Zdra> in changelog I see there were a dbus bug for images in libdbus <= 0.60 and I think the bug is back on 0.62
<seb128> Zdra: ah, might be
<Zdra> seb128: is it planned to switch to 0.90 ?
<seb128> Zdra: slomo has it ready I think but is waiting on an UVF exception
<seb128> Zdra: mdz is on VAC and UK is a bank holiday today though
<Hobbsee> what, another one?
<Zdra> slomo: have you libdbus packages for 0.9x ? would be great like that I can check if it fixes my notify bug :-)
* Hobbsee suspects you get bank holidays every couple of weeks or something!
* tseng sees Hobbsee and raises an ANZAC day
* Hobbsee raises tseng a queens birthday holiday
<Hobbsee> tseng: that only happens once a year though.  i've seen at least 2 bank holidays in the past couple of months.
<tseng> Labor Day is coming up in the US
<tseng> we seem to have a few in the summer
* tseng shrugs
<Hobbsee> ah right
<Hobbsee> hi mvo_ 
<Hobbsee> tseng: and 4th of july, of course
* mvo_ waves to Hobbsee
<mjg59> seb128: compiz --indirect-rendering
<Zdra> seb128: I installed dapper's packages for dbus and it works now
<ogra> mjg59, my console gets freaky with the recent usplash update ...
<mjg59> ogra: What hardware?
<ogra> mjg59, it starts glowing white on the edges ... ati card
<mjg59> ogra: What hardware?
<ogra> 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)
<Zdra> seb128: so dbus 0.62 is buggy and can't send GValueArray
<mjg59> ogra: Yes, but what hardware?
<mjg59> The chipset is uninteresting
<seb128> Zdra: good, now we know where the bug is, next step: the patch ;)
<ogra> hp pavillon ze2000, amd turion, run in i386 mode
<mjg59> Ok
<mjg59> I'll see if I can duplicate it on the one I have here
<mjg59> (Well, similar machine)
<LarstiQ> ogra: hey, I have that too
<ogra> same HW ?
<LarstiQ> almost
<LarstiQ> hp nx6125, amd sempron, x86
<LarstiQ> ogra: fglrx reports a different card then lspci tho
<ogra> i disabled fglrx sice it was broken for some time during the xorg 7.1 transition ...
<ogra> so i'm running the ati driver
<slomo> Zdra: i hope to get new dbus in shortly after knot2 (or with some luck even before)
<seb128> mjg59: thank you for the option, it doesn't complain with it but it still acts like if I had no window manager, and I managed to crash xorg then
<seb128> there is something else to do than running gnome-window-decorator and compiz?
<rodarvus> seb128: sorry, I was offline, what option did mjg59 passed you to enable aiglx?
<seb128> rodarvus: --indirect-rendering to compiz
<seb128> rodarvus: that's not to enable aiglx
<seb128> just to run compiz
<seb128> but it doesn't work better that way
<ogra> it should have a generic check if DRI is available and autoamtically fall back to that option :)
<mjg59> seb128: You want --strict-binding as well for aiglx
<seb128> mjg59: is there a place where I can read about that instead of bothering people on IRC? :)
<ogra> the source ? :)
<Zdra> btw, xcompmgr without any option and the free nv driver works pretty well... and that's by far faster to not redraw all windows when moving a window :-)
<ogra> hmm
<Zdra> but if I have a transparent window or shadow it becomes damn slow without nvidia driver
* ogra wonders why he didnt got a notification mail from the main inclusion queue page ... Kamion apparenly promoted ltspfsd and even changed the wiki ... 
<seb128> ah, better with compiz-plugins installed
<HiddenWolf> seb128: will we ever see a metacity with those effects? 
<seb128> mjg59: thank you, with that package installed it works fine now
<seb128> HiddenWolf: now that I have aiglx working I can have a look on that :p
<mjg59> seb128: Don't the dependencies require compiz-plugins?
<mjg59> Zdra: Yes, doing any composition effects will be slow at the moment
<jdub> mjg59: so i didn't catch much about radeon vs. fglrx in the latest changelogs - what's the best option there?
<jdub> are we still waiting for an fglrx with the new GLX apis?
<mjg59> jdub: Still on the XPress 200 thing?
<mjg59> If so, you don't have a great deal of choice
<jdub> yeah, quebecistani craptop
<jdub> i'm mulling getting a macbook (would love a laptop with dvi)
<mjg59> radeon won't drive the 3D on it
<seb128> hum, k
<seb128> so it sort of worked smoothly once
<seb128> and since as soon as I start compiz Xorg goes to 99% of CPU usage and moving a window takes like 5 seconds, restart the box makes no difference
<seb128> mjg59: no, compiz-gnome "Replaces: compiz (<< 0.0.2-4ubuntu2)
<seb128> Depends: libgnome-window-settings1 | capplets-data (<< 1:2.15.0), libgconf2-4, libgtk2.0-0, libwnck18, compiz-core (= 0.0.13.38-0ubuntu2)"
<seb128> and compiz-core package:
<seb128> "Depends: libcairo2, libpng12-0, libxdamage1, libxcomposite1, libxfixes3, libxrandr2, libice6, libsm6, libstartup-notification0, libgl1-mesa, librsvg2-2
<seb128> "
<Anndy> any idea about mobile phone application development under linux
<bddebian> Morning folks
<seb128> mjg59: ah, that's because I installed compiz-gnome instead of compiz
<mjg59> seb128: Ah
<seb128> mjg59: what the standard options to use? running compiz without plugins gives no window decorations and nothing
<seb128> I copied "gconf decoration wobbly fade minimize cube rotate zoom scale move resize place switcher trailfocus water bs neg" from the wiki which gives all sort of effects
<bddebian> seb128: Hi.  So that new pygobject upload fixes my codegen problem? ;-P
<seb128> but shouldn't the decoration by example be a "standard" one?
<mjg59> seb128: gconf really ought to be the default, I think
<mjg59> And then the others should be in the default gconf schema
<seb128> mjg59: right, makes sense
<mjg59> Except this will irritate KDE users
<seb128> bah
* Hobbsee looks in
<seb128> having compiz doing nothing by default irritate everybody I would say
<Hobbsee> true that
<mjg59> seb128: FWIW, I believe RH are shipping compiz in preference to the composited metacity
<mjg59> Also, composition currently degrades 3D performance and breaks Xv on most hardware
<seb128> mjg59: I don't think we want to do that by default for edgy
<mjg59> seb128: Indeed
<mjg59> But I think it's worth a main inclusion report
<mjg59> Since it all works now
<seb128> mjg59: but xorg with aiglx and metacity built with it (that's a runtime option then) should be fine
<mjg59> seb128: Sure
<seb128> though I would not say "it all works now"
<seb128> I managed to crash xorg like 5 times in 10 min by trying to run compiz
<rodarvus> it "works" on my machine
<rodarvus> just slow as hell
<seb128> and it's not-usable slow now when it runs (though it was fast one)
<seb128> I don't get why it was fast on the first try though
<rodarvus> mjg59, btw, we were discussing enabling Composite extension by default last Thursday, and just a few hours later you uploaded xor-server with Composition enabled - talk about good timing :)
<rodarvus> btw, there are at least two patches for xorg-server (and one for mesa) that might make sense to be applied, but I won't have much time for them, this/next week
<rodarvus> here -> http://people.freedesktop.org/~krh/compiz-on-aiglx/
<seb128> rodarvus: what are the patches for?
<rodarvus> I haven't tested them, so I can't say if they work. but in theory, one fixes the 'GL_ARB_fragment_program is missing' issue, other two are supposed to just make aiglx work "better" out of the box.
<seb128> better like faster? :)
<mjg59> rodarvus: We've got the include inferiors one, the others ought to be good as well
<rodarvus> there is one for copySubBuffer which sounds promissing, but I wonder if it will break 'nvidia' and 'fglrx'
<seb128> "$ glxgears 
<seb128> libGL warning: 3D driver claims to not support visual 0x4b
<seb128> *********************************WARN_ONCE*********************************
<seb128> File radeon_mm.c function radeon_mm_alloc line 216
<seb128> Ran out of GART memory!
<seb128> Please consider adjusting GARTSize option.
<seb128> ***************************************************************************
<seb128> Error: Could not get dma buffer... exiting"
<seb128> hum
<seb128> rodarvus: is that known? :)
<mjg59> seb128: Is that with the compositor running?
<seb128> no
<mjg59> Ah, ok
<seb128> I've metacity --replaced it
<seb128> it's unusably slow
<seb128> now I'm trying to figure why it's slow, since it can be fast (it was on the first try)
<mjg59> seb128: Yeah, removing blur makes it much, *much* faster
<mvo_> I tried to test it today too, but I don't have working agpgart on my amd64/nforce3-250/r200 system :/
* mvo_ also just got a error from the wiki, very strange
<zyg1> bye, I'm going home
<seb128> mjg59: right, without blur it works great
<seb128> mjg59: so gconf by default and blur not listed would be nice ;)
<pygi> siretart, poke?
<pygi> sivang, poke?
<seb128> mjg59: thank you for the help to get that working
<mjg59> seb128: No problem
<seb128> mjg59: do you know if there is a place with wnck patches by example to get compiz integration better?
<mjg59> seb128: Not that I know of
<mjg59> It does seem a touch broken
<seb128> mjg59: things like the desktop switcher applet and the shortcuts seem to not be happy with compiz
<mvo_> keybuk made it into the news: http://www.golem.de/0608/47429.html
<slomo> mvo_: he was already everywhere :)
<zul> but now in germany..:)
<LarstiQ> is there really a markt for German news?
<mjr> probably in Germany?
<pygi> ivoks, meeting today?
<ivoks> pygi: yes
<LarstiQ> mjr: hmm, I shudder at Dutch it news, it's really bad
* pygi will try to attend
<LarstiQ> mjr: perhaps .de has more competent reporters
<_ion> Which are the sites with news about upstart? I only know about OSnews.
<Hobbsee> _ion: planet.ubuntu.com
<HiddenWolf> _ion: uh, I'm sure it'll get publicity when it's actually debugged, working and in main. :)
<Simira> in which repository can I find wine?
<gnomefreak> Simira: universe 
<Simira> thanks
<seb128> Simira: apt-cache policy package
<seb128> Simira: or "apt-cache madison package"
<seb128> or apt-cache show package and look the Filename ;)
<janimo> Kamion: hi, is it you who can get an a11y menu entry on the xubuntu desktop CD? should I file a bug on ubuntu-cdimage?
<jdong_> mvo: ping?
<MagnusR> xlyskom
<mattn> hi
<mattn> can anybody help me with a valgrind problem?
<mattn> i always get the message: valgrind: mmap(0x80C8000, 303087616) failed in UME.
<mattn> when trying to use the valgrind deb that comes with ubuntu
<mattn> i'm calling via: valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./ufo run +set vid_fullscreen 0 +set vid_grabmouse 0 +set developer 1
<ogra> Mithrandir, around ? 
<Zdra> I read somewhere that gnome-terminal has real transparency when compositor is present... I'm running edgy with xcompmgr and I don't get real trans... it that normal ?
<desrt> Zdra; you can transset the entire window
<desrt> Zdra; but in order to get proper "real" transparency you'd need to have g-t paint its background with an rgba colour... which afaik it currently doesn't support doing
<Zdra> desrt: http://bugzilla.gnome.org/show_bug.cgi?id=345378
<Ubug2> Gnome bug 345378 in general "real transparency" [Enhancement,Resolved: fixed]  
<Zdra> found the bug with the patch commited to g-t
<desrt> +gboolean terminal_window_uses_argb_visual (TerminalWindow *window);
<desrt> i see :)
<desrt> well
<desrt> this was only committed last month
<desrt> so unless you're running CVS HEAD or edgy or something you won't have this functionality
<ogra> mjg59, i have a weird problem with usplash and ltsp
<ogra> seems the login manager doesnt get the keyboard input 
<ogra> i have to switch to tty1 and back to make it work
<Zdra> desrt: I'm running edgy and I don't get the functionality :(
<desrt> odd?
<Tonio_> hello
<Mithrandir> ogra: around for a little bit now, yes.
<jdong_> who should I talk to about getting XFS whipped up to shape for Edgy?
<jdong_> our edgy kernel suffers from the directory corruption bug, and the userspace tools are all out of date
<LarstiQ> jdong_: partly kernel team then?
<jdong_> LarstiQ: what's a good way of reaching them... launchpad is apparently pretty ignored :-/
<crimsun> #-kernel.
<LarstiQ> or https://lists.ubuntu.com/mailman/listinfo/kernel-team
<bddebian> LarstiQ!!  Did you look at diacanvas2 yet? :-)
<LarstiQ> bddebian: yup!
<LarstiQ> feh, it's clean target also fails
<bddebian> LarstiQ: Really?  Any luck? :-)
<LarstiQ> bddebian: not yet, other than confirming it also fails for me :)
<bddebian> Heh
<bddebian> LarstiQ: Blame seb128, it's easier ;-P
<tseng> ez gtk boog
<bddebian> ez pygobject b00g
<imbrandon> jdong_: i was just stopin the flood , come on back 
<jdong_> imbrandon: I will, give me a sec
<bluefoxicy> someone is requesting a security notice RSS feed
<tseng> http://rss.gmane.org/gmane.linux.ubuntu.security.announce
<bddebian> What, someone was requesting a ball gag for bluefoxicy? ;-P
<bluefoxicy> tseng:  very nice.
<bluefoxicy> bddebian:  .... ball gag.  o.o
<Seveas> bluefoxicy, media.ubuntu-nl.org/rss
<Seveas> hmm -- the scurity feeds are still on ubuntu-nl.org/files/
<bddebian> bluefoxicy: :-)
<kiko> hey there
<kiko> how's the UK bank holiday going?
<bluefoxicy> Hi kiko
<rodarvus> crimsun, ping
<LaserJock> what's a bank holiday?
<Burgwork> LaserJock, stat
<bluefoxicy> it's when banks stop operating for a day I think
<kiko> so here's a silly question
<kiko> I have install linux-image-686 and linux-image-386
<kiko> however the 686's version is behind the 386 version.
<kiko> is that reasonable?
<jdong> no...
<jdong> you should have linux-686 installed
<desrt> maybe you installed the 386 version at a time the -686 one was waiting to build
<jdong> and it should pull in the latest linux-image-2.6.15-whatever-686
<crimsun> rodarvus: pong
<rodarvus> crimsun, I'll ask in privmsg
<kiko> hmmm
<kiko> let me pull in updated index files
<pygi> siretart, poke?
<jcole> what is the debian installer irc room?
<jcole> nm wrong server!
<bluefoxicy> <kiko> however the 686's version is behind the 386 version.
<bluefoxicy> mdz was talking about eliminating everything but 686 (386 is really a 486 kernel) and renaming 386 to 'generic'
<bluefoxicy> but I think the plan was to move 'generic' up from 486 to 586 if that route was taken; and I don't think there'd be some half-ass transition w/ 386 going and then getting renamed etc etc.  Actually I'm wondering where that's going
<bluefoxicy> anyone know what conclusion they reached for that?
<jdong> idn, but the generic kernel better support SMP :)
<bluefoxicy> it will; smp has zero overhead.
<HiddenWolf> bluefoxicy: it already does in dapper, afaik
<bluefoxicy> HiddenWolf:  I didn't see that; that sounds kind of invasive to backport to dapper
<bluefoxicy> it's a major infrastructure change
<HiddenWolf> bluefoxicy: there are no -smp kernels in dapper, never have been
<HiddenWolf> at least, don't think so
<bluefoxicy> the method in which kernels are built and distributed goes from having 486, 686, k7, and p4 to just generic (586)
<jdong> HiddenWolf: but 386 is not smp
<LaserJock> I thought the idea was to just to go to 1 generic kernel for x86
<LaserJock> and I thought they were smp in Dapper too, :/
<bluefoxicy> HiddenWolf:  -SMP was gotten rid of a while back, since it has no overhead it's just built into all kernels
<jdong> bluefoxicy: except -386
<bluefoxicy> HiddenWolf:  I was talking about what LaserJock is saying.
<bluefoxicy> jdong:  yeah
<jcole> like knoppix... uses an smp kernel
<jcole> why doesn't -386 have smp?
<bluefoxicy> a few drivers break when built for 486 or something.
<Chipzz> bluefoxicy: yes, and some drivers dont work at all with -smp :P
<bluefoxicy> Chipzz:  I thought the smp kernel for 586 and 686 would have smp and those drivers would work
<Chipzz> bluefoxicy: some companies just don't care about "border cases" like smp
<bluefoxicy> Chipzz:  nods.  Well, in the future when we have 16 core chips they will.
<jdong> if that "we" implies that I'll have it, then I'm in :)
<bluefoxicy> AMD Athlon 64 X16 1.2GHz, runs at 10C, 16.8GHz total raw power, $150 in 2015, "Back in my day we had a 686... it only had one core... and we still built Ubuntu for 486..."
<Chipzz> so I wonder how smp as a default is a good thing :P
<jdong> well, having a non-smp kernel or a way to turn off SMP is a necessity
<jdong> *cough* damn ralink drivers *cough*
<jdong> actually, at the moment ipw3945 isn't spectacular with SMP
<bluefoxicy> jdong:  I'm looking at newegg, it's $150 for an Athlon 64 X2 2GHz and around $50-$80 for a microATX board that has SATA2 and 4 DDR400 slots and PCI-e 16 lane and nforce 410
<bluefoxicy> as long as you live a decade or so longer I'm sure you'll get one ;)
<jdong> bluefoxicy: yeah, x2's are really cheap now that intel pwned them :)
<bluefoxicy> hah
<jdong> my neighbor has a socket 939, and he's just eyeing the price slashes
* jdong has a core duo, which keeps him happy :)
<LaserJock> well, considering my pbuilder machine is a 1.3Ghz P4 with 256MB of ram, I'd be happy with just about anything
<jdong> :)
<bluefoxicy> jdong:  I need to upgrade my brain to something dual core, the workload is getting too heavy ;P
<LaserJock> more RAM!
<bluefoxicy> LaserJock:  actually that's what I'm up to now
<LaserJock> my problem is the brain IO is really slow
<bluefoxicy> LaserJock: http://bluefox.kicks-ass.org/mediawiki-1.5.5/index.php/Project_Steel:Design  re, my silly personal projects
<tseng> LaserJock: i loose things moving stuff across the system bus to cache
<jdong> bluefoxicy: SMP-enabled brain.... sounds like bipolar if you ask me :)
<tseng> LaserJock: never gets through to the cpu
* bluefoxicy has not notated down the use of high-end xcanaries on there
<LaserJock> tseng: mhm, I fell you there
<jdong> on a more non-OT note, how long does it typically take ubuntu-archive to respond?
<LaserJock> bluefoxicy: I have no idea what that is, but it's got lots of stuff
<jdong> I've got 25 or so backports in launchpad with their name stamped on em :)
<LaserJock> jdong: depends on if ubuntu-archive is on vacation
<bluefoxicy> LaserJock:  it's me pushing the "glibc is a pile of crap" mentality because I hate their allocator.
<LaserJock> or busy putting out a knot cd
<LaserJock> etc.
<jcole> btw, how does one get the arch? 686 386 k7 etc.?
<jdong> LaserJock: at the moment?
<jdong> jcole: I'd look at /proc/cpuinfo for that information
<jdong> jcole: uname -m can get you 386 vs 586/686, but not k7
* jcole looks for that string
<jcole> i don't see 686
<jcole> the debian installer selects the right kernel
<jcole> how?
<jdong> LaserJock: does poking ubuntu-archive people help speed up the process, or just irritate them?
<LaserJock> jdong: perhaps a bit of both
<LaserJock> I think they have a pretty good handle on what they need to do
<LaserJock> they just need to find time
<LaserJock> but I think many people have been on vacation
<LaserJock> which is what I suspect is the issue in your case
<trappist> There are hundreds if not thousands of bugs filed against old releases where the most recent activity is something like "is it still a problem on dapper", unanswered for several months.  It it useful or correct to close these with appropriate comments?
<LaserJock> I try to either confirm them or not myself before doing that
<trappist> LaserJock: yeah me too if possible, but I'm mostly seeing stuff that one guy reported once against breezy or hoary or warty and we haven't heard about the bug again since, in situations nobody else could reproduce.
<Burgwork> trappist, ask dholbach
<LaserJock> trappist: sound like a good candidate for a closing with a nice note ;-)
<Burgwork> trappist, there is a time, but my brain is not remembering the specific time
<trappist> LaserJock: I'm asking because there are like bajillions of these things
<trappist> Burgwork: last time I asked a similar question, I was told a month.  I'm asking again now because of the sheer volume of these bugs that I'd like to clear out.
<Burgwork> yep
<Burgwork> do a few and then ask seb128 or dholbach for a check
<Burgwork> then go to town
<LaserJock> trappist: honestly I'd ask dholbach or sfllaw before you go on a big bug closing campaign
<trappist> LaserJock: sounds like a plan.  I don't know either of those people.  wait for em to show up here, or what?
<sfllaw> trappist: Hi.
<sfllaw> :)
<trappist> hey!
<trappist> sfllaw: did you see the original question?
<LaserJock> trappist: #ubuntu-bugs is also good ;-)
<sfllaw> Yeah.
<trappist> I'm in there.  didn't think to ask there.
<sfllaw> The general policy is that if someone asks for information and there's no response in a month, then we reject the bug.
<sfllaw> But for things like this...
<sfllaw> It's probably not a good idea to close them unless you're pretty sure it's no longer an issue.
<sfllaw> Or if the bug is so vague that you'd never be able to reproduce it without help from the original submitter.
<sfllaw> If in doubt, leave it open.
<trappist> sfllaw: I could probably kill many hundreds of bugs with a 3-month threshold, and on most of them there's no way to be sure it's no longer an issue, unless assuming that no activity for so long means it's no longer an issue counts
<trappist> sfllaw: ok that's pretty much been my approach.  thanks!
<Burgwork> sfllaw, is it worth having a bug open for more than 3 months?
<Burgwork> a needinfo one, tbc
<sfllaw> Burgwork: If there's no info at all and it's still in Needs Info, then we close in one month.
<sfllaw> trappist: You can use some judgement.
<sfllaw> trappist: For instance, if someone says something is broken, and then doesn't reply for three months, it probably unbroke.
<sfllaw> trappist: If it's something minor, then you might leave it as a record.
<sfllaw> trappist: You can also ask people in #ubuntu-bugs to look at edge cases.
<sfllaw> trappist: That's the channel the BugSquad uses for bug triage and stuff.
<trappist> sfllaw: excellent.  and for the ones that pretty obviously ought to be closed, the correct status is rejected, rather than assuming fix released?
<sfllaw> trappist: Rejected.  You should subscribe and leave a nice note saying "We closed this bug because there was no response.  But just reply to reopen."
<trappist> replying will reopen?  that's good, I didn't know that.
<sfllaw> trappist: Well, no.
<QuestionMarkCoun> Hi *
<sfllaw> trappist: You'll have to set it to something sensible.
<trappist> ah.
<QuestionMarkCoun> Kamion, sorry for annyoing you again with a cdimage question... 
<QuestionMarkCoun> I have modified some udebs, apt-setup e. g., and putted them in a separate section of my archive (not main or restricted)
<QuestionMarkCoun> how do I get deb
<QuestionMarkCoun> debian-installer, to use my own udebs from the other section?
<z\> hello some italian developer herE ?
<z\> *here*
<shackan> z\,  you might have better luck if you ask in #ubuntu-it
#ubuntu-devel 2006-08-29
<z\> tnx .
<jdong> boy is archive.ubuntu.com slow today :-/
<Kamion> jdong: we've been having a weekend + UK bank holiday after getting back from the sprint - cut us a *little* slack please :)
<Kamion> jdong: it's Keybuk's archive day tomorrow, so I'm sure he'll catch up for you
<jdong> Kamion: sorry, I wasn't trying to be rude/impatient.... this is really the first time I've worked with ubuntu-archive... just curious
<Kamion> typically archive processing does not happen on weekends
<jdong> I'm patient
<Kamion> unless it's world-shattering urgent
<jdong> but... it's a new version of k3b... it's gotta be world-shattering urgent :)
<Kamion> we caught up on most things except syncs and some of the promotion/demotion details on Friday
* jdong passes time by converting laptop to XFS :)
<lucas> infinity: ping
<lucas> infinity: the status of ruby on powerpc hasn't changed. it has been broken for months now.
<lucas> I can't do anything about it since it requires buildd access to investigate (the same packages work fine in debian)
<z\> fabbione PING
<bddebian> Howdy
<shackan> z\, he's in vacation for two weeks, what are you looking for?
<z\> shackan i have to talk with fabio about a possible bug.
<z\> and i should to talk with fabio about my possible employment.
<shackan> at canonical?
<z\> at home 
<z\> http://www.ubuntu.com/employment#head-ee181be4e2f101318f548b6e62a74711085e9224
<z\> :D
<shackan> oh
<shackan> so you're a.. security expert?
<z\> i work in this sector.
<shackan> I see
<z\> where ?
<treitter> is there a "best practice" for a package that only _partially_ conflicts with another? (ie, overwriting one of its config files)?
<grexk> hello everyone
<treitter> I want to create a package that installs some config files in /etc, but I don't want to have to patch a million different packages, just to overwrite their default config files
<z\> shackan sorry.. 
<z\> but why u talk about me in english if u r italian ?
<Burgwork> z\, because this is a mostly english channel?
<treitter> I'll second Burgwork
<z\> ok.
<treitter> z
<treitter> z\: I hope that doesn't sound like we're against people speaking their own language
<crimsun> treitter: it's not allowed to just prance upon another's conffile.
<z\> uhm, ok.
<treitter> crimsun: of course. But is there any easier way?
<LaserJock> crimsun: "prance"? I was thinking "clober" but you were more eloquent as usual
<treitter> z\: but the downside of people speaking in another language is that other people who might want to participate might not be able to
<crimsun> treitter: call a helper method to adjust the conffile owned by the package you're prancing upon
<treitter> crimsun: in postinst?
<crimsun> treitter: does the package [whose conffile is affected]  offer a means of adjusting its conffile?
<treitter> crimsun: not sure. Where/how would it offer this means?
<crimsun> treitter: section 10.7.4, Policy
<treitter> crimsun: thanks! I'll check it out
<desrt> someone ought to poke this bug: https://launchpad.net/distros/ubuntu/+source/openssl/+bug/57736
<Ubugtu> Malone bug 57736 in openssl "HW engines are missing" [Untriaged,Unconfirmed]  
* desrt will confirm it at least -- but someone who knows ought to pay it some attention
<desrt> keybuk might be one such person
<tseng> possibly.
<desrt> Keybuk; i've found that you muck around with openssh from time to time.  are you also an openssl type?
<Keybuk> err
<Keybuk> I know how to connect the two bits together
<desrt> that's a very strong no.
<desrt> i think i'm confusing Keybuk with Kamion again
<desrt> sorry.
<Keybuk> yes
<Keybuk> Kamion is the openssh maintainer
<jdub> desrt: dude, you have met them in real life!
<desrt> i have this problem when i talk to people on irc i often don't think about who they actually are
<Keybuk> now, was desrt the short, fat, loud one?
<Keybuk> or the tall, cute one with the long hair?
<desrt> tall and with long hair, certainly
<desrt> perhaps also loud
<Burgwork> whiprush, you need to educate the Edubuntu people all about profiles, etc. As they are looking for stuff sabayon doesn't offer, but don't have a clear roadmap
<desrt> Burgundavia was the cute one
<whiprush> Burgwork: I can talk to ogra at the ltsp hackathon in a few weeks
<Burgwork> desrt, not hard. Keybuk is the crazy one. Kamion is the sane and stable one
<Burgwork> whiprush, excellent, but ogra isn't doing the work. LaserJock and cbx33 are
<Keybuk> gee, thanks
<whiprush> Burgwork: ok, you have a link to a spec or something?
<Burgwork> edubuntu-dynamic-menus
<whiprush> ta
<LaserJock> whiprush: but I've had to totally redo the implementation
<LaserJock> as sabayon hasn't worked out for what we'd like to do
<tseng> Burgwork: you mean between releases Kamion is sane and stable
<whiprush> the idea looks neat LaserJock 
<tseng> Burgwork: i wouldnt anger him after his 15th cd build
<Keybuk> Kamion is certainly more conservative than I
<Keybuk> I wouldn't say he was either sane nor stable :p
<Keybuk> unless he's a special kind of sane that's the opposite of insanity, rather than simply its abscence
<LaserJock> and seems to play a mean Mao
<jcole> i get this installing kubuntu -> /usr/share/debconf/confmodule: line 42: 3: Bad file descriptor
<Burgwork> tseng, ineed
<jcole> ctrl-alt-f2 and killing dpkg lets it continue
* Keybuk giggles at the "when will upstart be in Fedora" mail
<whiprush> upstart works for me on the X40 if you're looking for feedback
<desrt> jdub; what kind of cash does the foundation have kicking around?
<jcole> his is the offending line --> echo "$@" >&3
<jdub> desrt: USD
<desrt> er.  i meant more like the order of magnatude than the variety
<Keybuk> whiprush: yeah, it has worked for everyone.  I'm quite shocked actually
<desrt> *magnitude
<Keybuk> the only thing I don't understand is why upstart is so much quicker at shutting down the machine than sysvinit
<whiprush> heh
<Keybuk> I worked out why it was faster at booting
<jdub> desrt: do you really expect a real answer to that?
<desrt> jdub; ya.  i do.
<jdub> desrt: ok, your expectations are not in line with reality. :-)
<desrt> the answer should be a solid "none" or otherwise an approximate amount
<Keybuk> desrt: that number was public at the time of announcement
<desrt> but in any case it should be public knowledge
<Keybuk> google://ubuntu+foundation+dollars appears to give you the same answer multiple times
<Keybuk> $10 M
<desrt> oh crap.  not that foundation
<desrt> the gnome on
<gnomefreak> iirc it was 10 mil to ubuntu 10 mil to foundation at start
<jdub> desrt: it is reported publically, but not generally discussed on random irc channels
<desrt> same story for gnome too, i guess?
<Keybuk> whiprush: is it faster at shutting down for you too?
<jdub> desrt: i'm answering for gnome
<desrt> gotcha.
<desrt> so how do i find out?
<jdub> desrt: i don't believe anyone here can answer for TUF
<jdub> desrt: mail board-list
<jdub> desrt: though you'll obviously get questions as to why
<gnomefreak> gnome isnt really a non-profit org. so as to release that as public info is not a have to
<sladen> Keybuk: did you do the upload so that upstart is now default as /sbin/init ?
<whiprush> Keybuk: I can't tell either way, though I have not measured it.
<Keybuk> sladen: not yet, still fiddling with the shutdown tool
<Keybuk> deciding which of shutdown, halt, reboot, poweroff will be the "canonical" one and which are ubuntu-compat-sysv fodder
<Keybuk> I vaguely feel that since reboot is the syscall, that one should be, but meh
<sladen> Keybuk: make a new one called sys_reboot and overload that
<Keybuk> eh?
<LaserJock> whiprush: get my pm?
<sladen> Keybuk: sys_reboot is the name of the syscall
<whiprush> LaserJock: I responded, I think it's me not registering with freenode again
<sladen> Keybuk: or "yes", I agree that reboot should be the canonical binary
<LaserJock> whiprush: ah, well maybe #edubuntu real quick?
<whiprush> sure
<sladen> Keybuk: I think you should provide redhat style 'service' compatibility
<tseng> sladen: /usr/bin/service ?
<tseng> or sbin rather
<sladen> tseng: yup.  the red hat jockeys love it;  it's also marginally more nice (as in "making it simpler for the user") than either type 'initctl' or 'etc/init.d/foo'
<tseng> maybe we could make a vfs too
* jdub spanks tseng 
<tseng> so they can cd to /etc/sysconfig/wtf/network/network-scripts/network-interfaces/maybe-stuff-here
* tseng kids, 'service' is nice :)
<jdub> /roflcopter/
<Keybuk> sladen: how do you mean?
<Keybuk> I'd vaguely figured on having /usr/sbin/start and /usr/sbin/stop
<Keybuk> start apache
<Keybuk> stop smoking
<Keybuk> initctl is just a temporary thing
<sladen> keybuk: start and stop are quite major pieces of namespace, especially when you add restart and reload
<Keybuk> sladen: true, but then so is init
<Keybuk> and I think once you have init, you get to be arrogant about your namespace
<sladen> Keybuk: and especially if (as was talked about) 'start', 'stop', 'wankbadger' become an arbitary first parameter
<Keybuk> "wankbadger" ?
<sladen> Keybuk: the one I'd really like is MacOSX 'open'
<bddebian> haha
<Keybuk> open?
<sladen> Keybuk: 'foobar' 'moo' 'crack' 'speeeeefial'
<Keybuk> eh?
<Keybuk> I'm clearly not following you here
<sladen> Keybuk: Mac OSX (a modern Unix-based OS made by a company called Apple), has a command called 'open' that is performs what ever the equivalent of a double-click (eg. actually a mime-match) would be.  'open foldername' brings up the equivalent of nautilus, 'open foobar.mp3' brings up itunes, 'open moo.pdf' brings up the doc viewer
<Keybuk> alias open=gnome-open
<sladen> Keybuk: rocking.
<Keybuk> I didn't follow the foobar, moo, crack, bit
<sladen> Keybuk: $x
<Keybuk> what's $x ?
<sladen> Keybuk: defininate indefinate
<sladen> Keybuk: "foobar"
<Keybuk> whuh?
* sladen rewinds
<Keybuk> what has all this got to do with upstart?
<gnomefreak> Keybuk: who is a good person to ping about FF in edgy?
<Keybuk> gnomefreak: iwj
<sladen> Keybuk: 'start' and 'stop' are major pieces of namespace, check?
<tseng> gnomefreak: iwj
<gnomefreak> figured as much ty guys
<Keybuk> sladen: right, no package has ever dared use them as binary names
<Keybuk> I think init has the right to :p
<sladen> Keybuk: 'reload' and 'restart' are also names that make sense, check?
<Keybuk> no
<Keybuk> neither of those are in the upstart job life cycle
<Keybuk> start and stop are very special
<sladen> Keybuk: s/job life cycle/default state machine/
<Keybuk> s/default//
<sladen> Keybuk: 'start' and 'stop' are signals to the state machine
<Keybuk> right, start and stop are the only two external changes permitted
<Keybuk> reload, restart, kickupthebum, etc. don't need to be represented in the state machine, because they don't form part of the life cycle -- they're just separate actions (and we're off the spec here, as I deliberately omitted them from it <g>)
<sladen> Keybuk: what's your proposed suggestion (whether it's in the spec or not) for sending arbitrary signals?
<sladen> oooh, 'signal' is not taken either
<Keybuk> for reload to make sense in the state machine, it would mean that it would have to be a goal
<Keybuk> so you'd have "start", "stop" and "reload"
<sladen> maybe 'kill' should correctly be called 'signal'
<Keybuk> the reload goal change would need to kill the running process to force a state change, and move the job into the reloading state, which would then be able to have a "reload script" that did some magic to ... oh, oops, we killed the process
<Keybuk> so it doesn't really make sense for them to be considered first class properties of a job
<Keybuk> if you take a gui, there would be pretty toolbar buttons for start and stop
<Keybuk> but things like "graceful restart" would be on a right-click menu for that job only
<sladen> Keybuk: 'reload' is an arbitary signal (eg. apache may implement it with   kill -HUP `cat $pidfile` )
<Keybuk> and then you get into messy things like having to be able to ask init for a list of actions on the job, provide translatable descriptions for them, etc.
<sladen> Keybuk: 'restart' is a goal in the state machine (I think).  or is it   send(apache,stop), spin(apache,stop), send(apache,start)
<Keybuk> restart doesn't need to be a goal
<sladen> Keybuk: eg. the latter
<Keybuk> just kill the process, but don't change the goal
<Keybuk> if it's a daemon, it'll go through respawning
<Keybuk> if it's a task, it'll go stopping/starting
<sladen> Keybuk: I think that if it /can/ be implemented as a layer on top, then it shouldn't be in the core spec (which is a faily good API design rule)
<Keybuk> (which you probably don't want)
<Keybuk> yeah
<Keybuk> another way of looking at is that you could have /etc/event.d/reload-apache
<Keybuk> which has
<Keybuk> on reload-apache
<Keybuk> script
<Keybuk>     kill -HUP $(pidof --job apache)
<Keybuk> end script
<Keybuk> -- 
<sladen> Keybuk: I think for sanity, it should be  /etc/upstart.d/apache.reload
<Keybuk> we settled on event.d :)
<Keybuk> I'm vaguely avoiding using the word upstart anywhere except in the tarball name
<Keybuk> the daemon is "init"
<sladen> Keybuk: it would be nice if the signals for a particular task sorted alphabetically next to each other
<Keybuk> I'm pretty happy that we can implement signals/actions/etc. on top of the current model
<Keybuk> like I was able to implement dependencies
<sladen> Keybuk: apache, apache.start, apache.stop, apache.reload
<Keybuk> which, to me, suggests the model is simple and flexible enough
<sladen> Keybuk: yup
<Keybuk> though I'm not yet happy with the event naming/value
<Keybuk> the main unhappy is that I want
<Keybuk> "on apache" to mean "the apache job is running" but "on checkroot" to mean "the checkroot job is stopping" ("has finished")
<Keybuk> and at the moment, there's no "null" values
<Keybuk> so you can't do "while default-route is down"
<Keybuk> because it's not down until it's been up at least once :p
<Keybuk> and then there's "on default-route" ... does that mean when it's up, or when it changes, etc.?
<Keybuk> I suspect the world would have been simpler if I just started off with "string only" events
<Keybuk> but then I'd've still wanted to generate them for jobs
<sladen> Keybuk: I just went to the toilet and I was thinking of  http://en.wikipedia.org/wiki/Subject_Verb_Object
<Keybuk> hmm?
<sbalneav> Keybuk: saw the upstart stuff, very nice.  Will be a HUGE help with diskless, where large chunks of your devices aren't there.
<lgespee> Keybuk, upstart really looks nice, will it be stable enough to go into Main before Edgy? Or isn't that clear at all at the moment?
<Keybuk> lgespee: I don't see why not; it seems very stable
<lifeless> plus, its edgy.
<lifeless> if its not bleeding, its not ready for edgy
<bddebian> heh
<zul> edgy makes me want to gouge out my eyes its so bleeding
<lgespee> Keybuk: wow, really great, looks very promising
<zul> or something like that
<lgespee> zul, it's like living on the edge ;)
<sladen> Keybuk: SVO -> Subject, Verb, Object.   Lingustics, Sentence construction.  It may help with both the command line tools and the config file format
<lgespee> Keybuk, as a Ubuntu-NL teammember I heard soem rumours from teh Ubuntu-NL leader, but didn't actually believe it :D
<lgespee> well great to know, I won't bother you all any further, keep up the great work, bye
<sladen> Keybuk: if you are converting "on apache" -> "the apache job is running" -> "apache is running"
<Keybuk> I'm starting to wonder whether we shouldn't split the events
<Keybuk> so reserve "on" for system events, "at" for time events, etc.
<Keybuk> but that bloats the config
<sladen> Keybuk: if the format needs explanation then perhaps it's wrong :)
<Keybuk> right
<Keybuk> right now, I need to explain how it works, so it's wrong
<Keybuk> and I really don't like that people can do "initctl trigger shutdown"
<Keybuk> because that doesn't do the right thing
<mjg59> Keybuk: So can we tie upstart in with gcc?
<Keybuk> mjg59: umm?
<mjg59> So your system gets rebuilt on every boot?
<Keybuk> heh
<bddebian> w00t
<sladen> that would get the gentoo guys on board
<Keybuk> start script
<Lathiat> sure fire way of getting the gentoo guys to use it ;)
<Lathiat> haha
<Keybuk>   cd /src
<Keybuk>   make
<Keybuk> end script
<Keybuk> exec /sbin/binary
<Lathiat> -Olatest_hardware_from_this_boot
<sladen> Keybuk: start shell script    start python script?
<Keybuk> sladen: shell
<sladen> Keybuk: why not make it really easy, take it out of the config file and do the dpkg thing of  have  thing.start
<Keybuk> sladen: what happens when you need to have multiple thing.start ?
<Keybuk> people would confuse thing.start with "run this when thing starts"
<Keybuk> so you'd have someone not thing shipping thing.start
<sladen> Keybuk: "would confuse" ?
<Keybuk> right
<Keybuk> so right now, it's obvious that the "start script" bit in /etc/event.d/udev is something for the udev author to use
<sladen> action start, action stop
<Keybuk> if it were a separate file, e.g. /etc/event.d/udev.start you could end up with some other package trying to ship a udev.start script so that it's run before udev starts
<Keybuk> when it should be a separate job entirely that happens to be run when udev is starting
<sladen> Keybuk: in which case that would break the policy
<sladen> Keybuk: technical solutions to policy issues and policy solutions to technical issues generally don't work
<Keybuk> true but policy issues are often caused by bad technical solutions
<sladen> Keybuk: the only thing that would 'prevent' another package shipping their own '/etc/event.d/udev' would be dpkg complaining that the same file is owned by two packages
<Keybuk> I'm reasonably sure that upstart needs to be very simple
<Keybuk> and not allow arbitrary expansion in any number of directions
<Keybuk> but instead just allow lots of building blocks
<Keybuk> the more complex levels of interactions one tries to layer on top, the more of a headache one gets figuring out where the deadlocks can lie
<sladen> start == pre-start, stop == post-start, kill == pre-stop ?
<Keybuk> err?
<Keybuk> start = pre-running, stop = post-running
<Keybuk> there is no kill
<Keybuk> could rename them pre and post ;)
<sladen> Keybuk: (thinking of dpkg-style naming of start/stop scripts), there is {pre,post}{inst,rm}.  check?
<sladen> renaming does seem like it might be more accurate
<Keybuk> I'm thinking that the dpkg-style scripts are not a good design to follow
<Keybuk> given everyone has to read the manual every time they try and use them
<sladen> and people are might be less like to try to run  'pre-start' directly, and especially unlikely to run 'post-start' directly :)
<sladen> s/like/likely/
<Keybuk> you can't run them directly ;)
<Keybuk> they're in the config file
<sladen> having them separate would make 'script' and 'exec' redundant
<Keybuk> no it wouldn't
<Keybuk> you can exec /path/to/script already if you want
<sladen> Keybuk: anything that can be done inside  script ... endscript  or  exec "path/filename"  could be done with just having  "path/filename"  exist
<Keybuk> then how do you specify path/filename ?
<sladen>  $base = "/etc/event.d/"; $who = "apache";  $action = "pre-start";  $filename = strcat($base,$who,$action);
<Keybuk> that only replaces "start script" ... it doesn't replace "script" or "exec"
<Keybuk> how do you specify the name of the daemon binary to run
<sladen> Keybuk: man 2 symlink
<Keybuk> err, I really don't think we should be symlinking daemons into /etc
<Keybuk> that's a bad idea
<sladen> Keybuk: why is that different to specifying the name of an executable in a configuration file, in etc?
<Keybuk> one can be modified trivially in a text editor
<Keybuk> one requires heavy filesystem lifting
<Keybuk> "one file per config option" sounds a bit djbish
<Robot101> says the qmail advocate :)
<sladen> Keybuk: why duplicate existing functionality?
<Keybuk> sladen: what existing functionality?
<sladen> Keybuk: databases and filesystems
<Keybuk> Robot101: I use qmail because I know it
<Keybuk> I know how it delivers mail, how it works, how to fix it, etc.
<Keybuk> and I have no pressing desire or need to learn anything else
<Keybuk> sladen: eh?
<Keybuk> how have you strayed here?
<Robot101> Keybuk: I was just pulling your leg; I use postfix for the same reasons. I'll shut up now. :)
<Keybuk> I really don't see how "always execs an executable at a fixed path on the filesystem, which means you must place one there or arrange a symlink to the right place" is better than "a line in the config file says what to exec, and provides arguments"
<Keybuk> e.g. right now you can "exec /sbin/udev --daemon"
<Keybuk> to do that with your proposal, I'd have to write an /etc/event.d/udev.exec script that had in it
<Keybuk> #!/bin/sh -e
<Keybuk> exec /sbin/udev --daemon
<sladen> Keybuk: if a symlink would do the job in a transparent fashion (in the less common case) and a shell script would do the job (in the more common case)---both of which are already core kernel functionality;  which duplicate (obfuscate) those with 'exec' and 'script...endscript' options in a configuration file?
<sladen> s/which/why/
<sladen> Keybuk: I'm now coming around to the idea of   to "pre-start" exec "/usr/bin/apache" "--daemon" "xyzzy"   (or similar) in the config file
<sladen> Keybuk: maybe I'm just untouched by the 'script' business and the idea of having two (very similar) methods in the config file, both of which can do each other
<Keybuk> the difference between exec and script is pretty obvious
<Keybuk> exec runs sh -c exec ...
<sladen> oh. OH
<Keybuk> script runs sh /dev/fd/%d and puts the lines up to end script in that
<sladen> Keybuk: I had assumed 'exec' called 'execve()'
<sladen> Keybuk: if you're still calling through the shell even for an exec then there isn't even a speed difference in its favour
<Keybuk> it calls exec() directly if there's no interesting characters in the string
<Keybuk> so "exec /sbin/udev --daemon" would just do exec({ "/sbin/udev", "--daemon" }), yes
<sladen> Keybuk: and native exec() would be better as it functions even in the light of no shell
<sladen> Keybuk: two codepaths for one command?
<Keybuk> whereas exec /sbin/udev $FOO would call exec({ "/bin/sh", "-c", "/sbin/udev $FOO" })
<Keybuk> *shrug*
<Keybuk> it seemed to be a copy semantic
<sladen> Keybuk: just use 'script...endscript' for the secondone!
<Keybuk> (sysvinit, cron and atd all do the same thing)
<Keybuk> the config file offers lots of short cuts
<Keybuk> mostly because I'm lazy and like to put them in :p
<Keybuk> e.g. "while FOO is BAR" is identical to "start when FOO is bar\nstop on FOO"
<shackan_> FOO and BAR being event identifiers ?
<Keybuk> FOO being an event name, BAR being an event value
<sladen> Keybuk: "while FOO is BAR";  do what?
<shackan_> real world example for doc-reading impaired ? :)
<Keybuk> ok
<Keybuk> so events have values
<Keybuk> when you change the value of an event, the event is triggered with that value
<Keybuk> the event is also triggered with no value
<sladen> while FOO.state == 'stopped'
<sladen> while FOO.state == 'stopped' do yeild
<Keybuk> so if I set FOO to BAR, any jobs which have "on FOO" and "when FOO is BAR" will be started
<Keybuk> uhh, pseudocode won't help me understand it?
<sladen> Keybuk: but it helps *me* understand it
<Keybuk> eh
<Keybuk> FOO doesn't have state
<Keybuk> it's an event, not a job
<sladen> Keybuk: then that's an edge, not a level and you should be using 'if' not 'while'
<Keybuk> "startup" is an event, "default-route is up" is an event
<Keybuk> on startup
<sladen> Keybuk: an event does not exist for a length of time, it happens in an instant
<Keybuk> when default-route is up
<Keybuk> would be those two equivalents
<Keybuk> it happens that "while EVENT is VALUE" means your job is started WHEN EVENT is VALUE and stopped ON EVENT (ie whenever it changes to something else)
<Keybuk> this has already noted to be confusing
<sladen> Keybuk: a state does exist for a length of time, it is something that is achieved, or reached
<Keybuk> which was the beginning of this conversation
<shackan_> but the *event name* "default-route is up" does have some *state* information (that is, that the route is up :)
<Keybuk> right
<Keybuk> but "startup" doesn't
<Keybuk> and then there's tricky ones
<sladen> the event in this case is   default-route.up
<Keybuk> is "writable-filesystems" a one-shot event
<Keybuk> or should there be a filesystems are writable state ?
<sladen> so you can simply have   on default-route.up
<Keybuk> stop inventing syntax :p
<Keybuk> ok ...
<Keybuk> so what happens if one does "on default-route" instead ?
<sladen> preferably  on default-route.up do something
<sladen> on default-route.up do start
<Keybuk> the "do something" is always either "set the goal to start" or "set the goal to stop"
<sladen> on default-route.down do stop
<Keybuk> ok ...
<Keybuk> now reverse that
<Keybuk> on default-route.down do start
<Keybuk> on default-route.up do stop
<Keybuk> when will that get started?
<sladen> the goal called 'start' will be set when an event goes past called 'default-route.down'
<shackan_> so people should call their events like 'mysql-running', 'mysql-updating' etc..,      or just use 'mysql' for the event name and then read its state ?
<Keybuk> right, so it won't get started until the network has come up and gone back down again
<Keybuk> you'd need on startup do start
<Keybuk> which may not be a bad thing, as it makes the world more clear
<Keybuk> you could then have
<Keybuk> on mysql.starting do start
<Keybuk> on mysql.running do start
<sladen> Keybuk: so that is an event, that that is what is currently broken in sysvinit (and worked around by having K??* scripts)
<Keybuk> the latter could be just "on mysql", which is a different event, but triggered at the same time as running (for services) or stopping (for tasks)
<shackan_> so the syntax is <event name>.<event state> ?
<grexk> I always fail to compile xen-source from edgy to dapper. http://pastebin.com/778461?
<Keybuk> shackan_: event state is confusing, apparently
<sladen> Keybuk: on mysql.isrunning() == true: do ...
<sladen> Keybuk: (ignore the fact that it is puesudo code)
<sladen> Keybuk: bah, state/event; level/edge;  bah
<Keybuk> ?
<sladen> Keybuk: yes, "event state is confusing, apparently"
<sladen> events *happen* on the transition of states
<Keybuk> job events feel like they want to have state
<shackan_> "feel like they want to" ? omg :D
<sladen> Keybuk: what is a "job event"
<Keybuk> sladen: the events that occur every time a job changes state
<Keybuk> maybe that's what I confused
<shackan_> let's hope upstart will never feel like willing to format my disks
<Keybuk> the events should be single-fire things, the state should be in the job machine
<shackan_> I totally second the 'events happen on the transition of states'
<Keybuk> the mysql *job* has state, and fires events when the state changes, which get forgotten once they're processed
<sladen> shackan_: upstart's job is to get /other/ things to format your disks on its behalf :)
<Keybuk> on idle
<Keybuk> mke2fs /dev/root
<shackan_> sladen, I tought its job was to take over the world? :)
<sladen> shackan_: no, that's ubuntu's job.  upstart is merely a means to an end
<Keybuk> sladen: yeah, I really think events shouldn't have values and grab
<sladen> Keybuk: seems that, for things to have state, they must have a way of querying if that state is true
<Keybuk> crap
<Keybuk> they should just be arbitrary strings
<Keybuk> which may follow a naming pattern
<sladen> yes
<sladen> yes
<sladen> on each transition, the previous state is left and the next on is entered
<sladen> stopped -> started
<shackan_> o rly? (errrrr, sorry)
<sladen> stop.left, start.entered.  state == started
<Keybuk> stopping -> starting  </pedant> :p
<shackan_> sladen, your pseudocode does actually confuse :p
<sladen> maybe we should  s/ing$//;s/ed$//g
<Keybuk> sladen: that would be incorrect for the state machine
<Keybuk> the job state has to be an "ing" because it is a present perfect(?)
<Keybuk> ie. it's what the job is actually doing right now
<Keybuk> the events could have different names, of course
<sladen> shackan_: perhaps you could provide psuedocode that does /not/ confuse.  I sometimes find your random comments confusing.
<Keybuk> waiting -> starting
<Keybuk> starting -> running
<Keybuk> running-> stopping
<Keybuk> stopping -> waiting
<Keybuk> are the primary transitions
<sladen> post-stop, pre-start, post-start, pre-stop
<sladen> yup
<shackan_> event are fired during transitions or when states are reached ?
<shackan_> +s
<Keybuk> during transitions
<Keybuk> waiting => "nothing is happening"
<Keybuk> starting => "the job's start script (if any) is running"
<Keybuk> running => "the job's primary process is running"
<Keybuk> stopping => "the job's stop script (if any) is running"
<shackan_> so, if we go A -> B, when the 'on B' trigger will be fired, the current state will still be A ?
<Keybuk> no, the state will be B, obviously, you went from A -> B :p
<shackan_> but you fired the event during the transition, before the state switched to B :)
<Keybuk> isn't the definition of a transition that the state is switching?
* sladen ponders.  (mental exercise, rather than suggestion)  What if the daemon periodically fired off events stating the current status of each 'job'
<Keybuk> does it need to?
<lifeless> eww. polling.
<Keybuk> shackan_: upstart's states are gated
<shackan_> ouch, maybe 'transition from A to B' should be a 'transition state' itself? (let's call it C)
<shackan_> ok, </crack>
<Keybuk> you can only move from starting to running if the start script has terminated
<lifeless> btw, this is very similar to the mswindows service management api in terms of the state stuff
<sladen> and, on boot, fired off 'is_stopped' events for each of the daemons it knows about 
<Keybuk> which, given the thing that moves the state is the child reaper for the start script, is not surprising :p
<Keybuk> lifeless: *hides the book under his desk*
<sladen> Keybuk: so, how do you moved from  waiting->starting  if the previous transition was not achieved
<lifeless> Keybuk: :)
<Keybuk> sladen: you can't be in waiting if the previous transition wasn't achieved?
<Keybuk> you'd still be in stopping
<Keybuk> lifeless: it's similar to the design of any sensible service management api
<Keybuk> by gating the states, we don't need messy interim states
<sladen> cron has  @reboot
<sladen> I like that syntax
<Keybuk> at reboot
<Keybuk> though upstart uses reboot to mean "after jobs have been stopped, and you want to reboot the machine" :p
<Keybuk> ie. run rc6 currently
<sladen> so @reboot is actually  at boot
<Keybuk> right
<sladen> @start /usr/bin/asdf
<sladen> @stop kill `pidof asdf`
<Keybuk> that's what current init does
<Keybuk> and not what upstart does
<sladen> @bedtime irssi /away night night
<sladen> Keybuk: I'll think on it over night.  Something about the non-heriarchy, multiline config-file without qualifiers is getting my brain
<sladen> Keybuk: you don't need endscript, there is the    \   syntax at the end of the line
<sladen> Keybuk: or the  <<<EOF  syntax
<sladen> both of which cope with escaping
* rouzic se ha ido
<Kamion> sladen: macosx open> isn't that see(1)?
<Burgundavia> sladen: I need UWN 11 on the fridge, stat ;)
<jdub> Kamion: pretty much, but using all of osx's happy mime foo (gnome-open would be a more appropriate analogue)
<Kamion> oh, I always forget that the desktops reinvented the existing mime handling
<Kamion> I tend to ignore them :)
<grexk> Anyone want to check this out http://pastebin.com/778609
<jdub> Kamion: i hammered pretty hard to have mailcap compat (or direct use) in gnome - didn't happen.
<Kamion> grexk: it's polite to tell people what it is rather than expecting them to follow the URL to find out
<grexk> sorry
<dholbach> good morning
<Kagou> hi
<grexk> I can't perfectly compile xen-source-2.6.16 lately, checking launchpad seems it works well with i386?
<grexk> or should I just use deb binary from edgy to dapper.
<HiddenWolf> grexk: edgy uses a newer libc, it's not a good idea to replace that lib. :)
<HiddenWolf> grexk: what you can do is get the source, build-deps and build it yourself on dapper.
<grexk> Been doing that but I can't compile it perfectly with make-kpkg:(
<HiddenWolf> I'm no expert, but I've managed both rhythmbox and gossip with dpkg-buildpackage
<grexk> no success either:(
<HiddenWolf> grexk: perhaps you can find help in #ubuntu-kernel? 
<grexk> thanks
<sivang> morning all
<Hobbsee> hey sivang 
<grexk> morning
<sivang> hey Hobbsee , how are things?
<Hobbsee> sivang: okay.  i keep sleeping thru uni classes, which is kinda bad though.
<zyga> hello everyone
<sivang> Hobbsee: don't. Uni is important , trust me
<Hobbsee> sivang: yes, exactly.  
* Hobbsee notes that being sick is bad - you miss an incredible amount of work
<sivang> Hobbsee: yes, I recall that from my pre-uni studies. It's like missing a day is roughly as loosing the introduction and the fin abut how for instnace, electromagnetism works...
<Hobbsee> sivang: yeah, true
<sivang> Hobbsee: and trust me, when you can't present too many credentials for something you want to do, at least having completed a university degree can be considered as one big and demanding project you've done successfuly ;-)
<Hobbsee> sivang: true that.  i dont usually have this problem - just the last couple of weeks.
* TheMuso only fell asleep in lectures when we were in rooms that had no natural light, or fresh air.
<sivang> TheMuso: known :-)
<dholbach> keybuk, Kamion: could one of you please liberate libtelepathy from binary new (soname change)?
<\sh> moins
<rouzic_ausente> alegrate, /me ha vuelto
<seb128> doko: is your mail against closing old "Needs Info" bugs too?
<doko> seb128: maybe, but I agree with Dennis' reply
<seb128> doko: ok, because usually people close old Needs Info without a reply for some timez
<Hobbsee> doko: in kde-based bugs, often that doesnt make sense - because kde upstream fixes a lot more with each version than they tend to put in their changelogs
<Hobbsee> they put the major bugfixes in, but they dont put in every little single change, usually
<Hobbsee> although people should try to reproduce before closing
* Hobbsee suspects she's stopped making sense.  marketing lecture on behind me.
<doko> marketing what, bugs? ;-P
<seb128> Hobbsee: so you close random bugs because they might be fixed by a new version?
<Hobbsee> seb128: no, of course not
<seb128> Hobbsee: usually the way it works it that you verify that the bug is fixed before closing
<Hobbsee> doko: i'm not sure, i'm trying to ignore it :P
<Hobbsee> seb128: true that
<seb128> Hobbsee: and KDE people doing a poor job documenting what they do doesn't change that :p
<Hobbsee> sorry - the thought was there, the execution was shocking.
<Hobbsee> seb128: hehe, true that
<pygi> sivang, poke?
<joumetal> linux-libertine package (font) is in Debian testing. It seems to work with dapper without any changes. Could it be added to edgy?
<Riddell> Hobbsee: KDE changelogs are very detailed, and include full SVN logs for maximum details
<Hobbsee> Riddell: hmmm okay.  i was thinking of a lot of the universe packages, etc
* Hobbsee goes back to her corner
* Hobbsee wonders who stole her brain
<sivang> pygi: hi
<HiddenWolf> Hobbsee: we all want a part of you. ;)
<Hobbsee> ....
<Kamion> dholbach: done
<dholbach> Kamion: thanks muchly.
<Hobbsee> HiddenWolf: did someone steal your brain too?
<HiddenWolf> Hobbsee: I never had any. :)
<Hobbsee> ah
<Mithrandir> ogra: how's it going wrt getting your CDs down to a reasonable size?
<ogra> Mithrandir, just merging seeds ... lets see
<zyga> hi, is install-info a known issue?
<ogra> mjg59, ping
* ogra hugs dholbach 
<ogra> one g-p-m patch less :D
<dholbach> yeah :)
<zyga> guys what's wrong with install-info?
<sivang> anybody has an idea why google has vanished from our firefox's search bar?
<sivang> (and for some reason can not be add
<sivang> ed)
<mjg59> ogra: Hi
<ogra> mjg59, i have a weird behavior of usplash on thin clients
<ogra> the keyboard in the login manager doesnt work unless i switch to tty1 and back
<ogra> well, it kinda works after a loong delay and only prints '''' chars  
<ogra> if i switch off usplash for the boot all is fine ... 
<StevenK> mjg59: I have the same problems with Debian that you do, if that's news.
<mjg59> ogra: Erm.
<mjg59> I can't think of any reason why it should behave differently for thin clients
<ogra> it changed with my recent update ... (i havent updated for 3 weeks before)
<ogra> because we dont use GDM =
<ogra> ?
<mjg59> Well, there's been a lot of code changes
<mjg59> What do you use?
<ogra> and i kill it in the wrong place in ldm or miss something that needs to be added ? :)=
<mjg59> You shouldn't kill it
<mjg59> The VT switch will let it clean up
<ogra> so
<ogra> if pidof usplash > /dev/null; then
<ogra>                         /etc/init.d/usplash stop
<ogra>                 fi
<ogra> is not appropriate anymore ? 
<ogra> (got that at the top of the initscrit, before i start the X session)
* ogra tries that
<mjg59> Uhm
<ogra> i had to add it because usplash dropped my to tty1 else
<mjg59> /etc/init.d/usplash stop will not do what you think it does
<mjg59> Look at how gdm does it
<ogra> i think thats what it did for dapper
<ogra> i didnt look in edgy yet
<infinity> ogra: You probably want "start", not "stop", which is what gdm uses.  Yes, confusion, I know.
<ogra> hehe
<infinity> usplash's init script is the silliest thing I've ever accidentally contributed to.
<infinity> But I blame mvo, just 'cause I can.
<ogra> how about rewriting it at some point to be sane :)
<infinity> Yeah, yeah. :)
<infinity> Or obsoleting it entirely somehow.
<ogra> upstart might help here :)
<thom> can't you blame scott? i'm sure it must be his fault
<infinity> thom: Scott didn't really touch usplash until edgy, so the brain-damage in breezy and dapper is something I get to share responsibility for with mjg59 and mvo, mostly.
<infinity> thom: I'll happily blame him from here on in, though!
* mvo refuses any blame and reads to scrollback now to find out what it was actually about
<ogra> mvo calling "start" to stop usplash :)
<zyga> guys does anyone know what's install-info mess is all about?
* Hobbsee blames ogra 
<mvo> ogra: that is called "newspeak" ;)
<ogra> lol
* ogra looks with a totally innocent look at Hobbsee 
* Hobbsee laughs at ogra's innocent look
<ogra> :)
<Hobbsee> ogra: it doesnt work :P
<ogra> Hobbsee, well, was worth a try :)
<Hobbsee> heh
<ogra> mjg59, thanks, the keyboard works as expected now :)
<jono> he
<Treenaks> eh?
<Hobbsee> hey jono 
* rouzic se ha ido
<Gloubiboulga> Kamion, hi, is it possible to run a new xubuntu isos build?
<Mithrandir> Gloubiboulga: just new ISOs or new livefs too?
<Gloubiboulga> Mithrandir, new livefs is needed too I think
<tepsipakki> netboot-installer has old components, so d-i should be rebuilt
<Mithrandir> Gloubiboulga: xubuntu livefs running now
<Gloubiboulga> Mithrandir, thanks
<Kamion> tepsipakki: yes, I'm going to do that after all my no-more-devfs stuff is through
<tepsipakki> kamion: ok, thanks
<Kamion> plus the kbd-chooser change I'm working on now
<Kamion> I didn't get a chance to do it at the sprint last week
<tepsipakki> devfs is going to go? does that affect the disk-device-id that the d-i uses?
<Mithrandir> tepsipakki: we haven't used devfs as such for ages.
<Kamion> devfs disappeared long ago - the change is to get rid of devfs *paths*
<Kamion> so yes, d-i will start using /dev/hda1 instead of /dev/discs/disc0/part1, etc.
<Kamion> it already sort of does, but only patchily
<tepsipakki> right, good to know
<Mithrandir> ogra: well, getting anywhere?
<ogra> Mithrandir, yes, to lunch ... i'll trigger a new iso afterwards ... :)
<janimo> Gloubiboulga: hi
<Mithrandir> ogra: so you've managed to shrink it a bit, then?
<Gloubiboulga> hi janimo 
<janimo> Gloubiboulga: I added pyxfce to desktop seed as well, it will need a MIR
<Gloubiboulga> janimo, I'm not sure that it's a good idea
<janimo> Gloubiboulga: made progress on xkb?
<janimo> Gloubiboulga: why?
<Gloubiboulga> pyxfce seems unmaintained
<Gloubiboulga> I haven't seen an svn since months
<janimo> Gloubiboulga: there's at least one plugin upstream which uses it upstream no?
<Gloubiboulga> janimo, yes
<Mithrandir> Gloubiboulga: ISOs building
<Gloubiboulga> Mithrandir, thanks again :)
<Mithrandir> Gloubiboulga: .. and built.
<Gloubiboulga> lets see who much Mo we'll have to remove this time...
<ogra> Mithrandir, lets see, i found out that tomboy was still in the seeds and the foomatic stuff should gain a bit as well 
<rodarvus> heh, and I remember ogra quite happy just a few weeks ago, because we had gained ~20mb from python deps :)
* rouzic_ausente ha vuelto
<ogra> rodarvus, :P
<ogra> we'll get it in shape ... we'll just drop X, gnome and openoffice :P
<Mithrandir> nobody uses OOo anyway.  LaTeX ftw. ;-P
<Mithrandir> also, I'm using "ftw" far too much those days.
<rodarvus> yay LaTeX!
<sivang> I prefer genuine rubber..
<rodarvus> I think two things will likely have to happen in the medium-to-near future: split language packs per country
<rodarvus> and drop OOo helps from the cd :)
<rodarvus> . o O ( who needs help files anyway ) :D
* Hobbsee wonders if they're actually being installed now
<ogra> right, its even a lot more education you gain through LaTeX !
<rodarvus> openoffice.org-help-en-us is on the livecd
<rodarvus> ~11mb compressed, 22mb decompressed
<HiddenWolf> rodarvus: everyone needs help with the beast that is Oo. :)
<rodarvus> heh :)
<rodarvus> it would help if the OOo help was actually useful
<Gloubiboulga> Mithrandir, did you run the build for alternate isos too?
<rodarvus> (but anyhow)
<ogra> rodarvus, its totally useful (on 3GHz machines with 4Gig of ram at least) 
<janimo> mvo hi, re the gtkhtml2 use in g-a-i. It looks like it is used to render 3rd party commercial EULAS only?
<Mithrandir> Gloubiboulga: nope, you want those?
<rodarvus> yes, this is another problem. given it uses gcj runtime to run, OOo help is dog slow, and uses an incredibly high amount of RAM
<Gloubiboulga> Mithrandir, yes please :)
<Mithrandir> Gloubiboulga: running
<Gloubiboulga> thanks
<ogra> edgy-install-i386.iso          29-Aug-2006 14:18  722M 
<ogra> :((((((
<ogra> where do i get 22 meg ...
<rodarvus> ouch.
<ogra> hrm ..
<ogra> and its only i386
<rodarvus> !!
<ogra> the others are both at 716 only
<ogra> i wonder where the 6 meg come from
<rodarvus> I expected i386 to be smaller than amd64 at least
<ogra> well, the seeds are tweaked already to compensate that 
<ogra> (amd64 and ppc dont ahve all apps i386 has)
<Nafallo> ogra: oo-help :-)
<rodarvus> ogra, doko made a very good suggestion, btw
<rodarvus> (on ubuntu-devel@)
<ogra> funny ... http://cdimage.ubuntu.com/edubuntu/daily/20060829.1/report.html doesnt show and amd64 uninstallables
<ogra> hmm
<ogra> why not drop vim completely in edubuntu ...
<ogra> i wonder who would complain
<rodarvus> vim-tiny is tiny
<ogra> (apart from myself)
<rodarvus> but if you have at least nano, I think thats ok
* ogra cries ... debian constantly merged from the wrong ltsp tree ...
<rodarvus> FWIW, most other linux distributions install vim-tiny (or elvis) on their default installs
<ogra> ok, seed changed
<ogra> other suggestions ?
<Kamion> ogra: er ... where did you make that change?
<dholbach> ogra: what is ttf-dustin and xaos for?
<ogra> dholbach, xaos is a fractal generator
<ogra> the dustin font is required by kalzium iirc
<ogra> Kamion, minimal in the edubuntu seed
<Kamion> ogra: I'm sorry, but you can't do that
<Kamion> ogra: it will have no effect
<ogra> oops
<Kamion> please revert that
<ogra> ok
<ogra> doing so
<Kamion> the minimal and standard seeds in derivatives basically don't do anything
<Kamion> so, I was also thinking of moving from vim to vim-tiny in Ubuntu minimal
<ogra> that'd be great
<Kamion> in some ways it would be better, because vim-tiny is configured to act like vi if you run it as vi, and like vim if you run it as vim
<Kamion> (the compatible flag)
<Kamion> I was thinking that it wouldn't help much because you'd also want vim on the CD - vim-tiny is missing too many features
<_ion> Moving to vim-tiny is okay, but only having nano and no vi derivative would suck.
<slomo> Kamion: hi :) did you already have time to look at my two dbus mails?
<Kamion> but maybe you'd want to leave vim off the Edubuntu CD?
<Kamion> _ion: no intention of dropping vi
<Kamion> I'd hurt people if that happened
<Kamion> slomo: oh, not yet, will do shortly
<Mithrandir> Gloubiboulga: and done
<ogra> Kamion, well, -minimal pulls it in currently ... there is no other occurence of vim in the edubuntu seeds
<ogra> or do you mean completely ? 
<slomo> Kamion: thanks :) btw, when will the main freeze for knot2 start?
<Kamion> ogra: indeed, but I'd probably add it to Ubuntu ship - or maybe even desktop
<ogra> ah
<ogra> right
<ogra> no, i wouldnt merge that
<Kamion> vim-tiny is missing e.g. syntax highlighting
<ogra> i think edubuntu could even go without vi 
<seb128> do we need vim on desktop CD? I mean vim users are probably able to install it ...
<Kamion> seb128: yeah, not sure about that, I think it should be on the CD though
<Gloubiboulga> thanks Mithrandir 
<zul> i would want vim on a desktop cd alot users use vim
<Kamion> and a lot of vim users, while competent, won't necessarily be familiar with Debian/Ubuntu - they'll just start vi and notice that it sucks
<Riddell> Kamion: could you build a kubuntu livefs
<seb128> don't ship any vi at all then?
<Kamion> ogra: I'm not going to drop vi altogether from minimal
<Kamion> seb128: no
<seb128> nano is enough
<seb128> ok
<Kamion> no it's not
<ogra> seb128++
<seb128> just my opinion, but I don't use vi
<ogra> i use vi daily
<azeem> it would be alright to have a big warning/notice on the first invocation of vi as vi that this is vim in compat mode
<Treenaks> Kamion: whatever works, as long as 'vi' doesn't start nano... as I've seen on some BSD systems here.. *shudder*
<azeem> maybe
<Kamion> we drop vi over my dead body :)
<ogra> but i dont have a prob to install it 
<Kamion> it belongs in a base Unix system
<seb128> Kamion: we are lucky that you are not an emacs user then :p
<_ion> treenaks: Augh!
<ogra> haha
<Kamion> seb128: yes, we are :)
<doko> Kamion++, seb128----
<Treenaks> _ion: my words exactly
<Kamion> Riddell: sure, building
<Kamion> anyway, vim-tiny is half a megabyte
<Kamion> I think it's well worth it just for not pissing off server admins
<Kamion> vim I acknowledge as more debatable
<Kamion> the big chunk of space is vim-runtime - unfortunately that's also the bit that's really nice to have
<azeem> put vim-tiny into -minimal, and vim into -server?
<LarstiQ> didn't this get resolved in Debian?
<Kamion> LarstiQ: it is not possible for Ubuntu task choices to get resolved in Debian, so no
<LarstiQ> Kamion: right, task choices.
<azeem> and try to get desktop users to notice they should install vim for the real deal
<LarstiQ> Kamion: but the discussion was much the same
<Kamion> yes, that's why vim-tiny was created
<Kamion> but that doesn't necessarily help with the question of whether providing vim on the CD is a good idea
<infinity> Kamion: The full vim does seem excessive for -minimal
<bddebian> Good morning
<Kamion> hmm, I wonder whether /usr/share/vim/vim70/lang can be stripped and put into langpacks
<LarstiQ> Kamion: good luck with that :)
* Nafallo runs vim-tiny on his server. should be enough for -minimal indeed.
<ogra> seb128, what will break if i drop gnome2-user-guide from edubuntu ? are there any hardcoded referecnes to it anywhere ?
<seb128> ogra: the help from a bunch of gnome apps
<ogra> hrm ...
<seb128> ogra: I think some capplets, etc point to documens from the user-guide
<seb128> ogra: so you will get a yelp complaining about some reference not found
<ogra> ok, so i have to keep that
<dholbach> drop blender and xaos
<seb128> why do we have blender to main?
<ogra> dholbach, i cant drop xaos (and its only 500k or so)
<bddebian> For Margaritas?
<ogra> seb128, its in edubutu-desktop
<seb128> ogra: ah, k
<seb128> ogra: I was wondering yesterday because some user asked me if we had planned to update to the current Debian version for edgy
<ogra> would be something we could drop (it would be sane for the pacage to be in universe) 
<ogra> seb128, lfittl i guess ;)
<seb128> ogra: no, kagou
<ogra> heh, ok
<ogra> thats why i had a pm open this morning from him :)
<seb128> hehe
<seb128> maybe we should look at tackle that cdbs bug pointed by doko
<LarstiQ> upgrading to 2.42 would be nice, if possible
<ogra> well, blender has a big prob now it totally depends on ffmpeg, i considered dropping it already, but that wil get me many user complaints
<seb128> the one which make every binary from a same source package ship the ChangeLog, etc
<seb128> that could spare some megas
<doko> which reminds me at ajmitch's missing cdbs upload ...
<ogra> doko, that was the fix for the new python policy stuff, right ? if so, we have that anyway, i fixed it weeks ago
<Kamion> looks like vim currently requires /usr/share/vim/vim70/lang to stay where it is
<doko> ogra: no, new sync is required, and according to pitti, ajmitch has one prepared, but not submitted
<ogra> ah, k
<janimo> seb128: I have asked before, but any new opinions on splitting at least some libs out of gnome-python{-extras} to separate binary packages?
<ogra> ok, i'll let blender go bac to universe
<ogra> *back
<seb128> janimo: I don't want to
<janimo> g-a-i only needs gtkhtml2 but installs a lot besides that because of the bindsings
<seb128> janimo: or get them splitted from Debian
<janimo> seb128: but are you not mainatining them in debian anymore?
<seb128> janimo: they are team maintained and I'm pretty busy atm so other people are likely to give you a better reply
<janimo> seb128: in #debian-devel or is there a more appropriate channel?
<dholbach> #gnome-debian on irc.gimp.net
<janimo> and which of thos euploadrs is more likely to be involved with this package?
<seb128> janimo: bug report or #gnome-debian on GIMPNet
<janimo> dholbach: ok thanks
<janimo> seb128: thanks
<seb128> janimo: you probably want to mention you speak about python
<janimo> seb128: good idea ;)
* Mithrandir starts building new ubuntu livefs-es
* Hobbsee tickles Mithrandir 
<herzi_x41> mjg59: can you take a quick look at https://launchpad.net/distros/ubuntu/+source/spiftacity/+bug/57843
<Ubugtu> Malone bug 57843 in spiftacity "rebuild or merge with metacity" [Untriaged,Unconfirmed]  
<herzi_x41> thanks
<Mithrandir> hiya Hobbsee
<Hobbsee> hey Mithrandir, how are you doing?  :)
<seb128> herzi_x41: I had a look at that yesterday, but activating composite with metacity make it unusable (sort of blue,purple background with a sort of reduced ressource mode, I had to reboot to rescue mode and downgrade to the edgy version to be able to use my desktop again)
<Hobbsee> woo!  i got my name in another debian changelog :)
<seb128> Hobbsee: forwarding .desktops now? :)
<Hobbsee> seb128: i did for one package, i think.
<seb128> herzi_x41: and I'm reluctant making metacity linking to a lib with no ABI stability
<Hobbsee> seb128: no, i kept harrassing allee to fix his package in debian so i could sync it.
* Hobbsee is good at that :)
<bddebian> *cough*desktops*cough*
<seb128> Hobbsee: I've read your name to a package that included the .desktop you forwarded I think
<Hobbsee> seb128: yeah, quite likely. 
<Hobbsee> bddebian: no, it was +    Thx Hobbsee for reminding me (again and again :).
<Hobbsee> about kdelibs-bin dependancy that needed to be axed.
<seb128> Hobbsee: 
<seb128> " epiphany (0.5.1-4) unstable; urgency=low
<seb128>  .
<seb128>    * Add desktop file used by Ubuntu from the original patch sent
<seb128>      by Sarah Hobbs <hobbsee@kubuntu.org>"
<Hobbsee> seb128: ah yes, i got an email from him today
<Hobbsee> > +++ 0.5.1-3ubuntu1/debian/dirs	2006-07-10 11:18:27.000000000
<Hobbsee>   This file (dirs) doesn't exist in debian 0.5.1-3 version, arch
<Hobbsee> independent data has been splitted in a separate package, so same
<Hobbsee> happened to dirs file. You may want to update the ubuntu version to
<Hobbsee> reflect it.
<ogra> wohoo, Hobbsee on her way to become DD 
<Hobbsee> ogra: hah.   no way
<ogra> well, you partially entered the gnome team in debian with that change :P
<Hobbsee> ogra: presumably i should go for core (again) before that?
<Hobbsee> ogra: argh.  i dont even use gnome.
<ogra> hehe, i know :)
<ogra> we'll get you there ;)
<Hobbsee> hah
<Hobbsee> dream on
<ogra> *g*
<bddebian> Hobbsee: Why not?  Might be your "fast path" to core-dev.. ;-P
<Hobbsee> bddebian: my fast path?  heh
* Hobbsee is not going to reapply for core in a while. if ever.
<Mithrandir> Hobbsee: much better today than yesterday, but waiting for stuff to build is annoying.
<Hobbsee> Mithrandir: true that
<bddebian> Heya pygi
<pygi> heya bddebian 
<jcole> any xgl package maintainers or developers in this room?
<seb128> jcole: don't ask to ask, just ask
<seb128> jcole: I'm not technically maintaining it but I might be able to reply to a question
<seb128> same for other people too
<jcole> i've got a custom kernel and rebuild the dri module package from beerorkid ... i've installed them and it doesn't seem to work right
<jcole> apt-get build-dep linux-dri-modules-common; apt-get source linux-dri-modules-common; cd linux-dri-modules-2.6.15-26-20060726; dpkg-buildpackage -rfakeroot
<jcole> that builds all the linux-dri-modules-2.6.15-26-* packages and such
<jcole> is there something i'm missing? i dist-upgraded beforehand
<seb128> what "doesn't work right"?
<pygi> siretart, poke? :)
<Kamion> Mithrandir: do you know if there's a way to disable just the apt upgrade part of update-notifier, but not stuff like apport?
<Kamion> Mithrandir: 'cos I'd like to have update-notifier running on the live CD so that apport works
<dholbach> have a nice evening
<bddebian> Later dholbach
<jcole_nodri> seb128: can't get dri... it works with stock ubuntu kernel and binary modules from beerorkid
<jcole_nodri> (EE) I810(0): [drm]  drmAddMap(front_handle) failed. Disabling DRI
<seb128> jcole_nodri: I don't know, but doesn't looks like an Ubuntu bug if it works with the ubuntu kernel
<jcole_nodri> seb128: is that the only package i need to rebuild? do i need to rebuild the xorg/mesa drivers and such too?
<seb128> jcole_nodri: no idea, I'm not really a kernel nor xorg guy, maybe rodarvus knows about that
<rodarvus> jcole_nodri, where do you got your kernel source from?
<jcole_nodri> this is my /var/log/Xorg.0.log --> http://pastebin.ca/153243
<rodarvus> our kernel packages have updated agpgart & drm, needed for proper DRI
<jcole_nodri> rodarvus: from the ubuntu mirrors
<rodarvus> "I've got a custom kernel and rebuild the dri module package from beerorkid"
<jcole_nodri> rodarvus: apt-get source linux-source-2.6.15
<rodarvus> what is beerorkid?
<rodarvus> (and why did you need to download/built dri stuff from this external repository)
<jcole_nodri> rodarvus: the dri source actually comes from http://ubuntu.compiz.net/
<rodarvus> oh, right
<rodarvus> I suppose they already have working DRI for dapper, isn't this true? (though, as I don't use their repos, I can't confirm this)
<jcole_nodri> rodarvus: the dri in dapper is almost 3 years old for my intel card
<jcole_nodri> rodarvus: many glx extensions have been added in the last few years (including the ones xgl/compiz needs)
<rodarvus> indeed, intel dri on dapper is seriously lacking
<rodarvus> (but unfortunately, its nothing we can officially deal with right now, since dapper is released, and this is not something that could go into dapper-updates too)
* sladen grins at rodarvus 
<Hobbsee> hehe
<ogra> heh
<rodarvus> people, you are evil.
<rodarvus> :)
* Hobbsee hugs rodarvus 
<Hobbsee> us, evil?
<janimo> rodarvus: is X version frozen for edgy?
<janimo> as is no 7.2 for sure
<rodarvus> janimo, since a few weeks, yes
<rodarvus> no 7.2 for Edgy :)
<herzi_x41> janimo: 7.2 gets out after edgy, doesn't it?
<rodarvus> 7.2 will be released in two months, (maybe more)
<rodarvus> so, about 20 days before edgy is released
<rodarvus> surely not in time for inclusion into edgy
<janimo> ok I though they planned sep but anyway
<rodarvus> janimo, ~ october 15-20, afaik
<rodarvus> surely in time for Edgy+1
<janimo> rodarvus: do X packages come via debian now or is x-swat handling them?
<rodarvus> there's plenty of cool stuff which can be done for X.Org on Edgy+1
<jcole_nodri> rodarvus: like dri
<janimo> rodarvus: re the amd OLPC driver are you planning to package it or waiting on debian?
<rodarvus> janimo, I wish they could mostly be handled by debian, but unfortunately we (x-swat) had to mostly drive them for edgy
<rodarvus> janimo, I'll package it
<janimo> ok
<rodarvus> later this week
<rodarvus> sorry for not answering your email on the subject, btw :)
<janimo> np
<rodarvus> jcole_nodri, we package dri
<rodarvus> theres plenty of coolness coming for X.Org on edgy and edgy+1 (more if we find the right person to hire)
<Hobbsee> rodarvus: you're not volunteering?  :P
<jcole_nodri> rodarvus: who packages the linux-dri-modules-* packages?
<rodarvus> X.Org is not the reason I was hired. The only reason I'm doing it is because we don't have another hacker working full time on it
<jcole_nodri> whoa "who packages the packages"
<rodarvus> jcole_nodri, there is no linux-dri-modules-* package on (official) dapper
<infinity> Kamion: Nice CD health check mails.
<Hobbsee> rodarvus: i realise that :)  i was joking
<Hobbsee> hi infinity 
<infinity> Kamion: Also, FWIW, I've already pinged doko about fixing python-tk brokenness.
<rodarvus> these modules are inside the regular kernel package, and are done by the ubuntu-kernel team
<Kamion> infinity: good good. I hadn't got there yet ...
<HiddenWolf> rodarvus: so, are there any takers for it? You blogged about the employment ad. ;)
<jcole_nodri> rodarvus: does edgy have newer dri than dapper?
<Kamion> infinity: I'll add stuff like livefs build status to those mails later; I just got bored before doing so
<Kamion> infinity: does the reformatting I did of britney output suit you?
<rodarvus> HiddenWolf, I'm not interviewing people for this position, so, I have no idea, really
<infinity> Kamion: It doesn't make me want to poke my eyes out or anything.
<Kamion> I compacted multiple architectures down onto a single line, per mdz's suggestion
<infinity> Kamion: Yeah, works well enough for me.
<jcole_nodri> rodarvus: if so, i'll yank and rebuild the edgy kernel sources instead
<janimo> Kamion: nice mail indeed, could you add Gloubiboulga to the Cc as well for xubuntu?
<Kamion> janimo: sure, done - I was going to ask you about it beforehand but never seemed to catch you on IRC
<janimo> Kamion: yes, I was mostly offline these past weeks
<janimo> thanks
<Kamion> janimo: you ok with those being sent daily?
<Kamion> as I said to infinity, I'll flesh them out a bit later
<janimo> Kamion: re a11y boot entry, one will be needed for the xubuntu desktop CD as well, I assume you are doing them for the ubuntu CD?
<janimo> Kamion: daily is fine
<Kamion> janimo: easy to do - is the code in casper yet?
<janimo> Kamion: no idea about what code should that be sorry. It's ok to have that once the Ubuntu CD is accesbile just wanted to make sure it;'s you I'll come to
<janimo> I think it's not yet in casper as I gathered from what henrik blogged today
<Kamion> oh, you just use gtk so I guess it's not hard
<Kamion> do you have gconftool?
<janimo> Kamion: yes
<Kamion> if so, it should just be a matter of adding the necessary applications
<janimo> and added two metapackes to ship which dep on orca & co
<Kamion> janimo: hmm - you should have the a11y entry already
<Kamion> janimo: it's not really a boot menu entry, it's a full menu down at the bottom right of the gfxboot screen
<janimo> Kamion: I admit I have not tried an edgy live as they were oversized until recently
<Kamion> janimo: and it's added unconditionally for all derivatives - has been since dapper
<Kamion> which was actually a bug for kubuntu, but never mind since they're making it work now
<janimo> ah, I though it was supposed to be a main entry. ok then
<janimo> so then i tmeans it has to have some extra packages associated or a way to tell it to start and then install some gnome apps besides the xubuntu ones
<Kamion> it doesn't cause anything extra to be installed, only stuff to be enabled
<janimo> it is different from ubuntu as it does not install orca and gnome-mag by default
<Kamion> see scripts/casper-bottom/*accessibility in casper
<Kamion> that's the code that actually implements those menu items
<Kamion> if you need certain menu items disabled for xubuntu, let me know
<janimo> the a11y apps are not in the default xubuntu-desktoip so soemthing extra may be needed for the xubnunt CD then?
<Kamion> yeah, if you want
<Kamion> if they're not usable for xubuntu, we can disable those a11y options for you
<janimo> Kamion: I think they should be usable but are not put in the default desktop since they are relatively large gnome deps
<Kamion> nod
<janimo> so rigth now that option in ubuntu causes casper to call gconftool and tweak the desktop on start
<Kamion> right
<janimo> whereas in xubuntu it woulkd need that + install a few extra packages besides xubuntu-desktop for that to make sense
<janimo> packages starting xubuntu-at which are in the ship seed now
* ogra twiddles thumbs waiting for edubuntu-meta ...
* Hobbsee drops icecubes down ogra's back, to keep him from getting bored.
<Hobbsee> hey Arbiter 
<Arbiter> heya Hobbsee 
<ogra> AAAAAAAAAAHHHHHHHHH
<Hobbsee> hehe
<ogra> Hobbsee, THATS COLD !!
<Arbiter> o.O?
<Hobbsee> ogra: yes, and?
<Hobbsee> Arbiter: [01:14]  * Hobbsee drops icecubes down ogra's back, to keep him from getting bored.
<ogra> not again !
<Arbiter> 
<Hobbsee> ogra: what's the problem?  you're in the northern hemisphere, anyway.
<ogra> its cold, windy and raining here today
<ogra> 14C
<Hobbsee> ogra: hah.
<ogra> not the weather for icecubes running down your back ... :)
<Hobbsee> ogra: sure sure...
<ogra> i'm happy one of the cats warms my feet atm
* Hobbsee demands that firefox NOT CRASH!
<thom> Hobbsee: good luck with that one
<Hobbsee> hehe
<Kamion> janimo: mm, that's not really feasible though
<Kamion> janimo: especially not on the live CD, where this would have to be happening at boot
<Kamion> janimo: on the install CD I guess it would be theoretically doable but we have no infrastructure for it at present
<janimo> Kamion, so on the liveCD we should install all the accessibility stuff if we want it from start
<janimo> is there a way of not installing it on the disk if it was not enabled then?
<janimo> so the gnome deps only show up in the live session
<Zdra> seb128: for the icon problem in notification bubble, I found this patch from gentoo: ftp://ftp.belnet.be/linux/gentoo-portage/x11-misc/notification-daemon/files/notification-daemon-0.3.5-icon-data.patch
<slomo> Zdra: which problem? :)
<Zdra> images doesn't appear in notify bubbles
<Zdra> that's a strange bug, with dbus 0.60 from dapper it works
<slomo> Zdra: ok, i noticed this lately too... it's still the case with dbus 0.92 on edgy
<Zdra> and with this gentoo patch it seems to work too, at least that's what an user told me
<slomo> Zdra: could you file a bug on notification-daemon with this patch and assign it to me? i'll take a look later
<Zdra> slomo: ok thanks
<robtaylor> :q
<Kamion> janimo: that could be arranged with the aid of live-cd-stacked-filesystems, I think
<Kamion> janimo: probably best to include only the ones that don't need gnome for now
<Zdra> slomo: https://launchpad.net/distros/ubuntu/+source/notification-daemon/+bug/58114
<Ubugtu> Malone bug 58114 in notification-daemon "image doesn't appear in bubbles" [Untriaged,Unconfirmed]  
<slomo> Zdra: the patch is from upstream svn... and explicitely says that it makes icons work again on dbus >= 0.61... nice catch :)
<janimo> Kamion: all a11y stuff needs gnome so we'll have to wait for the stacked fs stuff if that solves it
<janimo> or we could just add it now to test a11y and hope we'll fid a way to remove it from the install later in the cycle
<janimo> that may be even better to get them tested in xfce
<janimo> I did not do that so far since I somehow thought that addtional packages can be installed based on boot selection
<janimo> it worked for the alternate CD and forgot they are quite different
<janimo> is anyone else experiencing firefox not handling https urls?
<janimo> the wiki and LP among them
<Riddell> hmm, these CDs really have got larger
<ogra> yep
<ogra> all of them ....
<ogra> *bigsigh*
<wasabi_> Hmm. My xkb has been acting up for the last week or so. Any body aware of changes which could have effected it? gnome-settings-d is unable to set it up. setxkbmap says it can't interpret _XKB_RULES_NAMES.  Latest packages haven't fixed it.
<wasabi_> Also, if anybody can explain to me htf XKB operates I'd be in debt, so I could find the problem myself. ;)
<Kamion> janimo: did it really work for the alternate CD? I don't recall ever adding code to d-i that installed packages based on access=
<Mithrandir> wasabi_: what does setxkbmap -print output?  (pastebin or query, please)
<Kamion> or in fact that did pretty much anything at all based on access=
<janimo> Kamion: maybe not via d-i ut I thought the LTSP extra packages were added in that way
<Kamion> ltsp has a special udeb that does the work
<Kamion> it would be possible to do so for access too, although nobody has yet
<slomo> Zdra: yep, fixes it for me... do you want to test it too?
<slomo> Zdra: (i took the patch from upstream svn instead of the gentoo one)
<Zdra> slomo: I'm a bit busy atm I'll try to test it later today if possible and if you didn't commit before ;-)
<Zdra> but if it works for you, for gentoo users and for upstream I guess it will work for me too ;-)
<slomo> Zdra: ok... i tested it on my two machines here and it works fine... i uploaded it, if you still have any issues please tell me :)
<Zdra> slomo: ok
<Zdra> thanks !
<slomo> np :)
<seb128> Zdra, slomo: thank you for working on that n-d bug ;)
<slomo> seb128: i also included a patch for fixing the assertion failure that mvo worked around last week, do you remember?
<seb128> slomo: nop, I just though mvo make the code no stop on assertions to workaround it
<seb128> slomo: but I've had mails issues during the sprint so didn't notice all the changes from previous week
<slomo> seb128: yes... now the assertion (well, the only assertion i ever got... not sure if it's really the same) is gone
<seb128> slomo: good job ;)
<ogra> hmm
<Burgwork> ogra, ?
* ogra wonders what went wrong with the current edubuntu iso ... it didnt pick up any chage in the metapackages or seeds
<Kamion> ogra: perhaps you were just a bit too quick on the trigger?
<ogra> heh, well
<ogra> likely
<ogra> new edubuntu meta was on a.u.c though
<ogra> (binaries)
<Kamion> ogra: what should have been added?
<ogra> removed ...
<Kamion> or removed
<ogra> i merged the ppd drop from ubuntu and dropped blende
<ogra> r
<ogra> should have gained at least 17MB
<Kamion> ogra: what version of edubuntu-meta?
<ogra> 1.7
<Kamion> ok, that was used
<ogra> hmm
<ogra> then its weird 
* Kamion investigates
<ogra> + Trying to add foomatic-filters-ppds...
<ogra> from the log ...
<Kamion> something is wrong with my seed checkouts on rookery
<Kamion> cjwatson@rookery:~/public_html/seeds/edubuntu-edgy$ bzr pull
<Kamion> Using saved location: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.edgy/
<Kamion> 0 revision(s) pulled.
<Kamion> cjwatson@rookery:~/public_html/seeds/edubuntu-edgy$ bzr revno
<Kamion> 511
<Kamion> but the current revno should be 515
<ogra> right
<ogra> wich the metapackage update script apprently got ...
<Kamion> oh, it looks like the http supermirror is broken
<ogra> so the seeds are fine
<Kamion> remember that the metapackage update script uses sftp
<ogra> and cdimage ? wget ? 
<Kamion> er, a complicated chain of stuff, but ultimately bzr pull from http
<ogra> the logs look like you are making a local copy
<ogra> ah
<Kamion> don't get distracted :) that's not relevant
<Kamion> ogra: would you mind chasing this up with #launchpad? the problem is that the http mirror of /~ubuntu-core-dev/ubuntu-seeds/edubuntu.edgy is out of date
<ogra> oki
<Kamion> thanks
<jcole> -26? http://packages.ubuntu.com/edgy/misc/vmware-player-kernel-modules-2.6.15-23
<jcole> err.. http://packages.ubuntu.com/edgy/misc/vmware-player-kernel-modules
<jcole> maybe those should be merged with restricted modules...
<Trae> https://launchpad.net/distros/ubuntu/+bug/22336  Anyone know when this is going to get addressed?  This is a fairly nasty bug that seems to affect all laptops.
<Ubugtu> Malone bug 22336 in Ubuntu "laptop overheats when performing CPU intensive tasks." [High,Needs info]  
<Trae> Having all Ubuntu laptops shut off when they do any real CPU work doesn't seem like it would be a good thing.
<tseng> "If the fan is running at full speed and yet the CPU is overheating, I don't see
<tseng> how this can be the fault of the operating system"
<tseng> you don't need to comment on bugs here btw, the bug is clearly the best place
<Trae> tseng, It's been open for almost a year.
<Trae> at what point does someone need to make a comment on it?
<Trae> and where?
<Keybuk> Trae: dude, "affect all laptops" is somewhat of an exaggeration
<Trae> Keybuk, do you have a laptop?
<slomo> Trae: at least my laptop is not affected by this
<tseng> (I was not going to feed the troll on that one)
<Keybuk> Trae: yes, several
<tseng> 80C is really freaking hot if you didn't know
<Treenaks> 
<Treenaks> ~/.
<tseng> my pentium 4, legendary for heat output, runs at 45
<Treenaks> uhr, oops, sorry
<Keybuk> there's an old kernel bug that nobody's figured out that means your laptop wildly over-estimates how hot it is
<Keybuk> so it isn't over-heating, but is just the kernel getting the math wrong
<Trae> Keybuk, would would other Distro's not have this problem?  That's the odd thing
<Trae> err s/would/why/
<Trae> heh
<Keybuk> Trae: we tend to pull the latest acpi patches, could be in there
<Keybuk> there's some chatter on the bug that suggests it also could be powernowd buggering up -- if you try disabling that, does it still power down?
<Trae> Keybuk, k, I would just hope this would be fixed for Edgy
<Trae> Keybuk, nod.. I did try that.. and *boom*
<Trae> hmmm
<Trae> wait
<Trae> maybe I tried turning off acpi
<Trae> Keybuk, how do you disable powernowd ?
<Keybuk> Trae: /etc/init.d/powernowd stop
<Trae> nod
<Trae> hehe, just tried that
<Trae> ok... let me fire up something and see if this sucker dies
<Trae> If I go poof, that means no ;)  {it didn't work}
<Trae> finally found a long enough video...
* Trae waits
<jcole> Trae: tail -f /var/log/messages | grep -i acpi
<Trae> k
<Trae> jcole, hmm nothing is showing up.
<Trae> that a good or bad thing?
<Trae> heh
<jcole> Trae: tail -f /var/log/acpid
<Trae> ok
<Trae> [Mon Aug 28 01:01:47 2006]  completed event "battery BAT0 00000081 00000001"
<Trae> Keybuk, hmmm
<Trae> Keybuk, stillll going!
<Trae> normally this sucker would have shut off by now
<lfittl> elmo: ping
<elmo> lfittl: ?
<lfittl> elmo: did you get my mail about gnupg and the smartcard reader udev rules? (sry for asking again here, it's just that FF comes closer and closer ;))
<elmo> lfittl: I'm not a maintainer of packages in ubuntu - whatever happens to gnupg in ubuntu isn't my problem/concern
<Trae> it seems like powernowd is the culprit
<jdong> Keybuk: thanks for pushing through all the backports. I really appreciate it
<Trae> I'll post something to the bug letting people know how they can fix things...
<Trae> Keybuk, this is working so far and no shutdown, thanks tons.
<lfittl> elmo: sure, but as you maintain it in debian I thought you might want to take a look at my solution, as I am interested in getting it into Debian sometime
<lfittl> elmo: and also, I was not sure if gnupg is the right package for it, or if there should be a dedicated package "gnupg-udev"
<elmo> a new package sounds like overkill, I'm not sure gnupg is the right p ackage thought
<elmo> s/t$$/
<lfittl> any idea which package would be better?
<Trae_> Keybuk ooops.  Spoke too soon.
<Trae_> Keybuk about 6mins into the second video it shut off.... which is way longer than it normally would work.  (2 or 3 mins before and it'd shut off)
<Trae_> this was after playing a YouTube video for around 12mins it powered off.
<Keybuk> Trae: hmm, interesting
<Keybuk> ok, what happens if you disable powernowd and then also
<Trae> what was that tail command from before?  (no longer have history :(
<tseng> 13:56 < jcole> Trae: tail -f /var/log/messages | grep -i acpi
<Trae> tseng danke
<Keybuk> sudo sh -c 'echo -n demand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor'
<Trae> Keybuk yessir... you were saying?
<Trae> ahh 
* Mithrandir sighs at the xprop 1.0.1 to 1.0.2 diff.  Two added lines of C, 4686 other lines inserted, 3850 lines deleted.  Go auto*
<Trae> Keybuk I don't have scaling_govenor
<Trae> oh wait
<Trae> sorry
<Trae> typo
<Trae> keep typing something wrong I think.. let me get on irc again and paste it to myself as a msg
<Trae> hmm
<Trae> I get this Keybuk:
<Trae> line: 0 echo write error invalid argument
<Keybuk> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
<Trae2> k
<Trae2> I have:
<Trae2> userspace powersave ondemand conservative performance
<Keybuk> oh, sorry
<Keybuk> echo -n ondemand :)
<Keybuk> thinko
<Trae> okies... heh, got this here so I could cut and paste
<Trae> ;)
<Trae> ok
<Trae> that took
<Trae> power off powernowd and try again?
<Keybuk> power off powernowd first
<Trae> http://www.shorttext.com/ab7ny
<Robot101> does powernowd predate ondemand?
<Trae> fwiw
<Trae> ok, I did that... did powernowd stop && the other comamnd you gave me with ondemand
<Trae> and that seemed to take
* Trae fires up a video
<Trae> Keybuk, anything else ?
<Keybuk> no, try that
<Trae> okies
<Trae2> ok.. here we go
<Trae2> Keybuk anything I should be tailing?
<Keybuk> Trae: /var/log/dmesg may be interesting
<Trae2> k
<Trae2> is there a way I can monitor temp?
<Keybuk> watch "acpi -V"
<Trae2> k
<Trae2> 63
<Trae2> Keybuk mind if I /q you these tmps?
<Keybuk> sure
<Mithrandir> janimo: are you aware that we're getting close to a new knot release?  You might want to make sure that xubuntu is in good shape over the next couple of days.
* Trae2 reads
<janimo> Mithrandir: yes aware that it is planned for Thu
<janimo> will test it tomorrow
<janimo> Gloubiboulga: started testing otday as well
<Mithrandir> janimo: goodie; just wanted to make sure you were aware of it.
<crimsun> the daily seems fine here fwiw, though I only tested clean and not a dist-upgrade.
<lucas> is the switch from powernowd to the ondemand cpufreq governor considered for edgy, for systems which support ondemand ?
<lucas> I was reading the paper from OLS about ondemand, and it really looks impressive
<jdong> lucas: I'm not sure
<jdong> but ondemand is what I use :)
<jdong> it's much more responsive than powernowd
<lucas> what's the clean way to switch from powernowd to ondemand ?
<jdong> but that's gonna require some rewiring at the acpi-support level
<jdong> remove powernowd
<Keybuk> I meant to chat to mjg59 about that at the weekend
<jdong> I currently just hacked /etc/acpi/power.sh
<lucas> ok
<jdong> make sure your cpufreq modules are probed in
<jdong> either via /etc/modules or do it in power.sh, too
<lucas> I was more wondering about edgy than about my own laptop
<jdong> right
<jdong> I hope to see edgy switch away from powernowd
<jdong> for yourself, you can actually just use ac.d and battery.d in /etc/acpi
<jdong> no need to butcher power.sh
<jdong> but Keybuk, pretty please follow up on ondemand for edgy :)
<jdong> or at least make powernowd poll more frequently
<lucas> the problem is that ondemand requires many more switches than powernowd
<lucas> so it's inefficient with processors without fast freq switching
<jdong> speedsteps need to be blacklisted
<jdong> most modern CPU's switch pretty fast
<jdong> enough that you don't notice
<jdong> but I can see needing branching code and cpu detection :-/
<jdong> which leads me to believe it won't be ready for edgy
<jdong> for sure any pentium M / core duo can be whitelisted
<jdong> and I'm pretty sure most turion / athlon64 are fine
<jdong> but celeron M's are not for sure
<jdong> the ones that scale from 300MHz up to 1.xGHz
<jdong> they lag horribly on ondemand
<zyg1> hey
<clee> is there a channel for the hwdb?
<sladen> clee: /query ogra
<clee> sladen: ah, that was the nick! thanks.
<Trae> Keybuk, thank you again for your time on this matter.  You have been most helpful, courteous and attentative. :)
<Trae> Keybuk, quick question... any way I can make these changes "stick" between reboots?  Like, how can I safely disable powernowd "The Ubuntu Way" so I don't break things?
<Trae> and will that ondemand echo thingy you had me do hold after a reboot, or will it require some special attention too?
<Keybuk> Trae: for now, I'd just edit the top of /etc/init.d/powernowd; add the echo and exit 0 :p
<Keybuk> or
<Keybuk> rm /etc/rc2.d/S??powernowd
<Keybuk> and add the echo to /etc/rc.local
<Keybuk> actually, yeah, do the latter
<Keybuk> there's module loading in the powernowd.early script you need
<Trae> Keybuk, do those bugs close?  Meaning, once they are marked fixed are they gone, or are they kept in an archive for historic purposes on launchpad?
<Keybuk> kept for historical purposes, but marked as closed
<Trae> k
<Trae> I could just add the two commands to /etc/rc.local at boot right?
<Trae> I've not used it in eons
<Keybuk> right
<Trae> after the esac thingy 
<Keybuk> esac ?
<Trae> fwiw, I do Graphics with Linux... I don't code, soo... if I sound uninformed, that's the reason why :)
<Trae> it's at the end of the /etc/init.d/rc.local 
<Keybuk> Trae: I know, we've actually met
<Trae> Keybuk, we have?
<Trae> Keybuk, uh oh
<Trae> :)
<Keybuk> Trae: ahh, /etc/rc.local not /etc/init.d/rc.local (the latter runs the former)
<Keybuk> Trae: LWE 1999, iirc
<Trae> Keybuk, sweet.... that was a great show
<Trae> all the linux.com banners all over San Jose
<Trae> hehe
<Keybuk> I used to run segfault.org :p
<Trae> what was your nick then?
<Keybuk> still Keybuk
<Trae> omg
<Trae> Scott!!
<Trae> hahaha
<Trae> You should have said it was you. :P
<Trae> I never know you by Keybuk
<Keybuk> hehe
<Trae> but immediately recognized SJR ;)
<Trae> from the whois
<Trae> hmm, didn't I bug  you via email recently?  *chuckle*
<Keybuk> umm, it's possible
<Trae> at any rate, /me hunts for /etc/rc.local
<ogra_> lfittl, hey ... blender moves to universe ....
<ogra_> so have fun with it :)
<lfittl> ogra_: very nice, how come?
<ogra_> space probs on th edubuntu CD
<ogra_> edubuntu was what kept it in main ...
<ogra_> it should move to universe during this week ....
<lfittl> will get 2.42a synced/merged after it is back to universe :)
<jdong> Keybuk: ping
<Keybuk> jdong: hey
<jdong> Keybuk: the latest k3b backport was "rejected" from the archive
<jdong> k3b: Version newer than that in BACKPORTS. 0.12.17-1ubuntu2~dapper1 >= 0.12.16-1ubuntu3~dapper1
<jdong> :-/
<Keybuk> right ... ?
<jdong> I meant to have the new 0.12.17 backport replace the 0.12.16 backport that did not build
<jdong> does the current backports system not work that way?
<Keybuk> you'll have to be a bit more verbose, sorry
<Keybuk> I did a backport of k3b for you
<Keybuk> and that has been rejected because there was already a backport in the archive?
<jdong> right
<Keybuk> was the backport-in-the-archive version higher or lower than the one I did?
<jdong> the one in the archive was lower 
<Keybuk> ok
<Keybuk> and it rejected?
<jdong> right
<Keybuk> soyuz bug then
<jdong> k :)
<Keybuk> please file a bug in launchpad
<jdong> where in launchpad?
<Kamion> /products/soyuz
<jdong> k
<HiddenWolf> +filebug
<HiddenWolf> ;)
<Kamion> ew
<Kamion> it's got a hardcoded check for *everything* that it's not newer than whatever's in the corresponding backports pocket
<Kamion> nobody thought to exclude backports from that check apparently :)
<Kamion> I'm not convinced the check is a good idea anyway - if we want to supersede the backport, then tough, we want to supersede it
<Kamion> please subscribe me to the bug you file and I'll try to explain that
<jdong> Kamion: you are subscribed to bug 58144
<Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58144
<Kamion> thanks
<jdong> and oh yeah, NEW is ok right? (for packages that are new to Edgy and backported to Dapper)
<jdong> i.e. someone will eventually allow it through, right?
<Kamion> well, that happened in the first round of backports and it got processed ...
<mvo> Keybuk: did someone told you already that upstart made it onto heise.de? (I guess so, given that the news item is a couple of hours old). still nice to see
<Keybuk> what's heise.de?
<thom> german tech news site
<ogra> *the* german IT news site
<mvo> Keybuk: its the most popular german tech news site
<schnabel> hello
<ogra> Keybuk, http://www.heise.de/newsticker/meldung/77421
<ogra> happy bablefishing :)
<Keybuk> heh
<Lure> wow, and 300 comments on the story...
<ogra> heh, they praise the dependencies you can add through events :P
<jordi> is edgy at upstream freeze now?
<crimsun> for main, yes.
<jordi> ick
<Kamion> has been for ages
<jordi> I guess :)
<Kamion> we're nearly at feature freeze
<Kamion> to my abject terror
<jordi> oh well. nano 2.0 about to hit the streets, it'd had been nice to have the round version number
<Keybuk> Kamion: GET CODING!
<_ion> Talking of which, /me hasn't seen new stuff in the upstart repository for a while. ;-)
<infinity> jordi: I doubt anyone other than the nano maintainer (pats you on the head) would much care what version it is. :)
<jordi> infinity: heh, even I don't care too much.
<jordi> more when I know the changes are basically translation and veeery minor nitpicks
<jordi> (since 1.3.12)
<infinity> jordi: Frankly, I'm shocked to discover that anything so featureless even gets upstream development, except for the occasional bitrot fixing.
<jordi> there's plenty of stuff nano needs to get still
<infinity> "removed from the archive"?
<jordi> well, give vim to your average ubuntu newbie
<infinity> "replaced by ae, we were right in 1999, damnit"?
<_ion> jordi: A good idea. :-)
<infinity> Yeah, vi's a poor choice for anyone who's not an old-skool UNIX hacker.  Modal editors are confusing.
* _ion guesses the average newbie uses gedit.
<jordi> give them gedit when xorg gets fucked up :)
<infinity> I remember backgrounding and killing vi out of sheer frustration the first time I used it on a university machine in ~1995.
<bddebian> hehe
<jordi> infinity: hehe
<infinity> And the fact that I knew how to background and kill tasks, but not exit my editor, says something.
<thom> infinity: at least you knew how to back..
<thom> yeah
<ogra> grmbl ... next tim i check if a lp bug is fixed before i waste resources ... now i got three identical iso builds ...
<HiddenWolf> ogra: one for the public, one for the archive, and one to put on the wall. ;)
<ogra> neither will be usable :)
<HiddenWolf> sentimental value? a reminder? ;)
<Keybuk> mjg59: just gonna take a quick break, then can I borrow you for five minutes
<mjg59> Keybuk: Sure
<Keybuk> mjg59: see comment at bottom of bug #22336
<Ubugtu> Malone bug 22336 in Ubuntu "laptop overheats when performing CPU intensive tasks." [High,Needs info]  http://launchpad.net/bugs/22336
<mjg59> Hadn't we already decided that ondemand made more sense where possible?
<mjg59> I've already discussed this with mdz
<mjg59> Hang on. Let me find a Celeron and test this...
<Keybuk> yeah I thought we had
<Keybuk> how were you planning to decide which?
<mjg59> Let me check the source again
<mjg59> But I /believe/ that ondemand will fail if it won't work
<mjg59> That is, attempting to switch the governer to ondemand will fail
<mjg59>                 if (policy->cpuinfo.transition_latency >
<mjg59>                                 (TRANSITION_LATENCY_LIMIT * 1000)) {
<mjg59>                         printk(KERN_WARNING "ondemand governor failed to load "
<mjg59>                                "due to too long transition latency\n");
<mjg59> Right
<mjg59>                         return -EINVAL;
<mjg59> So try to set /sys/devices/system/cpu/*/cpufreq/scaling_governor to ondemand
<mjg59> If that fails with EINVAL, set it to userspace and run powernowd
<lucas> failed to load. does it mean it still shows up in scaling_available_governors ?
<Keybuk> ok
<mjg59> No, the failure is when it's started
<mjg59> I think it'll still appear in the available governors
<mjg59> Though I'm not certain of that
<lucas> it would be easier to just grep for in in available_governors if it doesn't show up
<mjg59> No, by the looks of it it'll still be in available_governors
<jdong_> does preload actually make things load faster, or is it a scam like readahead most of the times :)
<Keybuk> jdong: scam
<Keybuk> well, it does make things a bit faster, at the cost of other things
<bddebian> heh
<bddebian> Keybuk: OK, wtf does ROM mean? :-)
<Keybuk> Request-Of-Maintainer
<bddebian> Ah..
<Keybuk> http://ftp-master.debian.org/removals.txt
<Keybuk> ^ cf. top of there
* bddebian always has to feel stupid :-(
<Keybuk> heh, you weren't to know
<Keybuk> I had to ask once
<Burgwork> bddebian, don't feel bad. I had to ask several times what FTBFS meant about 18 months ago
<infinity> Burgwork: What does FTBFS mean?
<mdz> infinity: You're fired.
<bddebian> Heh
<infinity> Hard to resist.
* Burgwork grumbles at FC4 and desktop-multiplier
<Burgwork> anybody say thing?
* mvo giggles
<tseng> Burgwork: nope.
<tseng> Burgwork: but infinity was fired
<bddebian> Burgwork: :)
<bddebian> hah
<Burgwork> damn. going to miss infinity 
<infinity> Lies.
<Burgwork> even if he is a traitor to his own country ;)
<bddebian> FTBFS == Forgot To Bring Fricking Shot-glass?
<infinity> FTBFS, loosely translated, is "That Which Keeps infinity Employed"
<infinity> The reason the letters don't seem to match up is because it's translated from the original Latin.
<bddebian> haha
<azeem> what's infinity in latin?
<LaserJock> Burgwork: you're actually using that stuff? ;-)
<jdong|coreduo> lol
<infinity> azeem: infinitum, but let's not split hairs.
<jdong|coreduo> mvo: do you have anything to do with opera in dapper-commercial?
<Burgwork> LaserJock, we dog food quite extensively. Mostly it is good, but occasionally we get all sorts of pain
<bddebian> Hah
<LaserJock> Burgwork: is DM more stable on FC than on dapper?
<slomo> hm, what happened to the 2nd powerpc buildd?
<mvo> jdong|coreduo: Mithrandir uploaded opera into dapper-commercial. why?
<LaserJock> Apple pushed the self-destruct button?
<Burgwork> LaserJock, it is mostly stable. We have a set hardware formula though.
<Burgwork> radeon 7000
<Burgwork> LaserJock, on my i915 box, it simply power cycles constantly
<jdong|coreduo> mvo: users are requesting the 9.01 update
<infinity> slomo: Weird grid failure in the DC, being investigated, current ETA unknown.
<slomo> infinity: thanks... so i really have to wait for gcj to finish ;)
<infinity> slomo: Yes. :P
<jdong|coreduo> crimsun: is there any chance for azureus 2.5.0.0 from sid -> edgy?
<jdong|coreduo> our ubuntu version is pretty unusable
<bddebian> jdong|coreduo: It's on the merges list
<jdong|coreduo> ok, cool
<jdong|coreduo> nvm then
* jdong|coreduo goes back to the backports list
<bddebian> I think I tried it once but it didn't build or something strange
* mvo goes to bed
<jdong|coreduo> I wouldn't be surprised
<slomo> bddebian: but nobody will probably touch it... it's not the easiest merge and the tarballs differ and doko did fairly large changes
<bddebian> slomo: I tried :)
<bddebian> Later folks
<slomo> bddebian: me too but i gave up :P maybe doko cares for it at some point
* jdong|coreduo joins ktorrent camp in the meantime :)
<geser> infinity: could you please giveback mail-notification and link-monitor-applet on sparc and powerpc?
<infinity> geser: Done.
<geser> thanks
#ubuntu-devel 2006-08-30
* Keybuk glances at licio's quit message
<Keybuk> I knew there was something I was supposed to do today
<LarstiQ> replace shutdown by upstart?
<Keybuk> right
* jdong|coreduo wonders what would happen if he installed upstart on his dapper box
<Keybuk> jdong|coreduo: you'll need a libc update
<Keybuk> it only builds on edgy
<jdong|coreduo> aww :(
<jdong|coreduo> Keybuk: you're ruining all my fun :)
<jdong|coreduo> excuse my complete lack of knowledge about upstart, but will all existing sysv init scripts need to be rewritten?
<Burgwork> jdong, no
<Burgwork> jdong, before you ask any further questions, I suggest you read Keybuk's rather extensive blog post
<Burgwork> this weeks UWN covers it
<Keybuk> "need", no
* jdong|coreduo must've skimmed the post too fast :-/
<jdong|coreduo> would upstart result in any kind of bootup/shutdown speed improvement?
<Keybuk> jdong|coreduo: eventually, yes
<Keybuk> though that isn't its goal
<jdong|coreduo> k, gotcha
<Burgwork> Keybuk, would it be fair to say that the archiecture makes such improvements easier to implement?
<Keybuk> Burgwork: yes
<ogra> Keybuk, i have a weird problem with my ltsp here ... apparently the NIC always starts in half duplex mode ... do you know how evil it would be to run  mii-tool -F 100base-Tx-FD in my initscript of the client ? would NICs that dont have 100base-Tx-FD support break on that or just gracefully fall back to something sane 
<Burgwork> right. I am going to writing something about upstart as part of the Knot2 release thingy
<ogra> i.e. how forcefully is the force switch ? :)
<Keybuk> ogra: they'd break
<ogra> gah
<Keybuk> in particular, you'd break any NIC plugged into a hub
<ogra> right 
<ogra> oh
<Keybuk> as you'd force it into 100base-Tx-FD overriding whatever it had auto-sensed
<ogra> RIGHT
<Keybuk> (hubs are almost never FD :p)
<ogra> i'm plugged into a hub
<ogra> <- heavy headdesking
<Keybuk> are you sure that it really should be at FD ?
<Keybuk> if you're plugged into a hub, it would not surprise me that HD is the best you can get
<Keybuk> if you set it to FD, do you get lots of errors?
<ogra> well, if i force it to FD i can import my 10Gig of music from the usb disk on the thin client to rhythmbox and my session doesnt die ...
<ogra> in HD that doesnt work
<Keybuk> why doesn't it work?
<ogra> the network gets saturated and the ssh session dies (locks up)
<Keybuk> hmm
<ogra> usually after 10-20 mins
<ogra> i switched to FD more than 1h ago and the music still plays fine ... desktop is responsive etc
<Keybuk> what's the error count in ifconfig?
<ogra> RX: 1597
<ogra> the rest 0
<ogra> hmm
<ogra> rising
<ogra> 1601 now
<Keybuk> then something isn't doing FD properly ;)
<Keybuk> errors should always be 0 on a wired interface
<mjr> well, close to it anyway
<ogra> right
<ogra> yay, finally ... 6M to go on i386 ....
* ogra dances ...
<zul> hey ogra 
<ogra> hey zul 
<profoX`> hey guys -- i wanted to apologise for not coming to the TB meeting yesterday -- i made a point on the agenda, but it slipped my mind (just wanted to say that)
<Kr4t05> Hey, guys.
<Burgwork> hey k4
<Kr4t05> I have a question about Edgy+1. Are there any plans to merge InitNG into Ubuntu?
<Kr4t05> Or, is that in line for Edgy?
<tseng> no.
<Burgwork> no
<Kr4t05> Mkay.
<Kr4t05> Just thought I would ask. :)
<Burgwork> Kr4t05, got a link for you, just a sec
<Kr4t05> Allright.
<Burgwork> Kr4t05, http://www.netsplit.com/blog/work/canonical/upstart.html
<Burgwork> read that
<Burgwork> it was answer all your initng questions
<Kr4t05> Ah, even from the intro, it sounds awesome. :)
<Kr4t05> Ok, thanks. :)
<Kr4t05> So, is this upstart going to be seen any time soon? 
<Kr4t05> Oh, oops.
* Kr4t05 reads further.
<Kr4t05> Oh, neat. :)
<Kr4t05> Thanks.
<Burgwork> when you are done reading, then ask questions
<Burgwork> or not
<HrdwrBoB> I think he's done :)
<Burgwork> which is good
<sladen> ogra: forcing full duplex assumes that the other end is directly connected to a wire-speed non-blocking device;  a modern switch or direct PC<->PC connection
<Burgwork> think I should add the upstart link to the topic?
<sladen> Burgwork: as long as if that is done, the answer isn't RTFM
<Burgwork> yep
<Burgwork> sladen, have you installed the LAMP option? 
<Burgwork> https://launchpad.net/products/ubuntu-website/+bug/58161
<Ubugtu> Malone bug 58161 in ubuntu-website "http://www.ubuntu.com/server incorrectly only mentions PHP for LAMP" [Untriaged,Unconfirmed]  
<infinity> Burgwork: The bug is invalid.  We don't install mod_python or mod_perl, only mod_php, so the website is correct.
<Burgwork> infinity, that is what I thought
<infinity> And, 3rd party definitions don't much matter in this case. :)
<Burgwork> yep. Rejected with extreme prejudice
<infinity> LAMP used to stand for Linux/Apache/MySQL/PHP originally.  Now it may be Linux, Apache and Many Possible database and scripting options.
<infinity> But that's not what we install. :)
<sladen> Burgwork: I haven't installed the LAMP option.  Haven't got a clue how to---it never seemed to actually get mentioned.  I presume it's a meta-package
<infinity> sladen: It's (currently) a book option on the server CD.  Will be a task in edgy.
<infinity> s/book/boot/
<lifeless> infinity: I thought LAMP meant perl ;)
* Burgwork smacks lifeless ;)
<HrdwrBoB> lifeless: it used to
<HrdwrBoB> many years ago
<infinity> lifeless: I'd be cool with that, mod_perl is great to use.  But it's not what the average user who'd pick a "LAMP install" blindly is likely looking for either. :)
<infinity> Anyhow, wikipedia claims the term was coined in a c't article in 1998, and that article claims it was PHP, so I win. :P
<Burgwork> infinity, and wikipedia also claims elephant numbers are increasing...
<infinity> Clearly visible by visiting a goth club.
<Burgwork> or any fast food joint
<sladen> it was probably mSQL instead of MySQL aswell...
<infinity> sladen: Not according to the article in question, anyway.
<JanC> trappist: seems like I missed your last message on bug 58002 before posting my comments; my second one might be a more general solution provided it causes no other problems...?
<Ubugtu> Malone bug 58002 in vim "vim should populate skel/.viminfo so ownership is not affected by initial sudo" [Wishlist,Confirmed]  http://launchpad.net/bugs/58002
<sladen> JanC: simple question.  what command would you run to edit /etc/apt/sources.list ?
<JanC> 'sudo -e /etc/apt/sources.list' ?
<Burgwork> why do we even ship vim and emacs?
<Burgwork> aside from the screaming if we didn't?
<HrdwrBoB> because people use them all the time?
<HrdwrBoB> emacs you could potentially lose
<HrdwrBoB> since it's massive
<Burgwork> "people" use irc all the time and we dropped that
<sladen> JanC: okay, most people (including me) would do  sudo emacs ...  and we have to cope with that (even if  export EDITOR=... and sudo -e  would be better)
<JanC> vim is massive too  ;)
<HrdwrBoB> and people who use it are all insane
<Burgwork> in fact, I would say that more people used xchat than vim or emacs
<Burgwork> infinity, what is your gut feeling? should I suggest we not ship them?
<HrdwrBoB> I know less than a handful of people who use emacs
<sladen> Burgwork: vim: so that people can edit files.  Emacs is not installed by default, but it is a programmers editor and normally the first thing I install
<JanC> sladen: but my second message was about the 'always_set_home' flag in sudoers
<HrdwrBoB> I know MANY people that use vim
<HrdwrBoB> people that use emacs are *ALL* "hardcore"
<Burgwork> sladen, umm, nano?
<HrdwrBoB> not all people that use vim are
<Burgwork> vim is awful to use
<Burgwork> if you *just* need to edit a text file to get up and running again, you can use nano
<infinity> Burgwork: We'r enot going to stop shipping some vi variant in -minimal.
<sladen> Burgwork: Ubuntu is "awful" to use if you've used DOS all your life.  People are comfortable using what they are familiar with...
<infinity> Burgwork: It belongs there.
<Burgwork> ok
<Burgwork> then at least lets ship the smallest bloody vim we can
<infinity> We've talked about vim-tiny, but it's still undecided.
<infinity> I'd be happy with nvi, personally, but whatever.
<HrdwrBoB> yeah
<HrdwrBoB> tbh as long as it came with 'viu'
<JanC> I use 'nano' to add universe so I can install 'joe'  :)
<HrdwrBoB> 'vi'
<HrdwrBoB> most people wouldn't care that vim had to be installed
<sladen> Burgwork: that's a proposal/spec worth making.  If I'm not getting my 'emacs' by default I want to ensure that the 'vi' nutters are penalised aswell
<Burgwork> aside from infinity's "it belongs there" arguement. Why do we need it? I am not trolling. I am asking a serious question from a non0technical users standpoint
<HrdwrBoB> 'vim' not 'vi'
<HrdwrBoB> vi is a core unix util which has a reasonable expectation of being their
<HrdwrBoB> vim is not
<sladen> HrdwrBoB: this is a valid point, can you write a spec?
<Burgwork> are things going to break if it is not included? it is easily apt-getable?
<Burgwork> I can see if somebody writes vim/vi into a script and thus it would silently fail, but I just don't see someone doing that
<lifeless> they'd use ed to do that
<infinity> Burgwork: Nothing breaks, except the brains of thousand of old UNIX hacks.  A small vi is not a size hit, and people who don't know what vi is will never rnu it, so there's no harm in having it there to satisfy old farts like me.
<HrdwrBoB> sladen: I can do that, can you point me in the right direction
<Burgwork> infinity, ok. Installed size is 1.5mb
<infinity> Burgwork: For vim?  Bigger than that, you're missing vim-runtime and other scariness.
<Burgwork> yes, I just saw vim-common at 21mb
<sladen> HrdwrBoB: https://features.launchpad.net/distros/ubuntu/+addspec is a good place, it'll guide you through the specificaiton registration and give you the templated wiki page to fill in
<Burgwork> at 21mb, that is insane
<HrdwrBoB> sladen: cheers
<sladen> that is BIGGER.  THAN.  EMACS
<Burgwork> HrdwrBoB, point me at the spec wiki page and I will add some commentary
<Burgwork> anyway, got to go home
<infinity> Burgwork: vim-tiny is small, though, and nvi is even smaller.
<HrdwrBoB> infinity: what does vim-tiny offer someone that they wouldn't install vim anyway
<bddebian> Howdy folks
<infinity> HrdwrBoB: A useable 'vi'?
<tseng> HrdwrBoB: it offers vi in significantly less space?
<HrdwrBoB> tseng: um
<HrdwrBoB> what I mean is if you install vim-tiny instead of nvi
<HrdwrBoB> would people actually care
<tseng> that isnt what you said
<HrdwrBoB> or are all 'vim people' going to isntall vim anyway
<tseng> I am
<HrdwrBoB> in which case, vim-tiny is not useful
<tseng> but if i have no vi at all, I will be pissed
<infinity> HrdwrBoB: vim-tiny sucks a bit less than nvi.  Fewer irritating misfeatures (like resetting the editor mode when you hit the beginning of a line) and such.
<tseng> this applies to 1000s of people
<HrdwrBoB> absolutely
<HrdwrBoB> which is why you would have nvi
<HrdwrBoB> you can't not have vi
<bddebian> nano-tiny!! :-)
<crimsun> Keybuk: ping
<sladen> dpkg -L vim vim-common vim-runtime | xargs -I'{}' find '{}' -type f -maxdepth 0 | xargs du -sch   23MB ...
<JanC> bddebian: you mean we have to replace nano with nano-tiny to save some 100 KiB of disk space ?   ;-)
<infinity> sladen: Yes, this isn't news.
<jdong> are dependency waits automatic or require intervention?
<infinity> jdong: automatic
<jdong> i.e. amarok backport needs libtunepimp3 backport
<jdong> will amarok try again once libtunepimp3 is ready?
<infinity> jdong: Assuming the build-deps are correctly versioned.
<sladen> infinity: yeah, I doubled-checked it as I couldn't believe  ^Installed-Size: 
<infinity> jdong: Yeah, looks like it did it right.  Should work fine.
<jdong> k, cool
<infinity> jdong: I'll push all the libtunepimp stuff through dapper's NEW queue once powerpc has caught up.
<bddebian> JanC: Yep ;-P
<jdong> cool, thanks for everything, infinity :)
<bddebian> Or you could alway just remove emacs from the archive and save even more space
* bddebian ducks
<HrdwrBoB> hahaha
<Lathiat> haha
<jdong> bddebian: lol, you duck quite a bit :)
<sladen> bddebian: we don't installed emacs by default "because it's too big"
<JanC> bddebian: we could remove all editors except 'ed'  ;-)
<bddebian> I know, I was being sarcastic sorry :-)
<jdong> world bandwidth conservation day... :)
<infinity> JanC: Why use ed, when you can just use dd?
<bddebian> JanC: I like it :-)
<infinity> JanC: Seek for characters in a reference file and construct the target.
<infinity> JanC: Alternately, there's always shipping tiny magnets and magnifying glasses alongside the shipit CDs.
<infinity> And perhaps a screwdriver.
<JanC> hm, at least that magnifying glass & screwdriver sound useful  :-)
<Keybuk> crimsun: 'sup?
<crimsun> Keybuk: hi, do you mind if I merge alsa-driver? I'd like to close bug 46996 and its dupes.
<Ubugtu> Malone bug 46996 in alsa-driver "Hotplugged sound devices get sound card index of 0 instead of PCI card" [Wishlist,In progress]  http://launchpad.net/bugs/46996
<Keybuk> crimsun: will you need a UVF?
<crimsun> Keybuk: for 1.0.11-3ubuntu1 -> 1.0.11-5ubuntu1 ? No, unless I misunderstand the exception process utterly.
<zul> hey Hobbsee 
<Keybuk> no, you don't then
<Hobbsee> hey all
<Keybuk> go for it
<crimsun> Keybuk: thanks.
<Hobbsee> woo!  syncs got done again :)
<jdong> Hobbsee: yeah :)
<Hobbsee> jdong: backports too?
<jdong> yeah
<jdong> keybuk's been busy today :)
<Hobbsee> indeed :)
<HrdwrBoB> https://features.launchpad.net/distros/ubuntu/+spec/large-text-editor-removal
<HrdwrBoB> it's not complete, but it's a start
<Hobbsee> remove nano :P
<bddebian> Nooooo
<Hobbsee> as long as we keep vi..
* jdong looks through edgy-changes for things worth backporting :)
<HrdwrBoB> hangon let me get this straight
<HrdwrBoB> vim/emacs is in a default install? or just on the CD
<bddebian> I'm too stupid for a "real" editor, I need my nano ;-P
<zul> Hobbsee: i totally agree
<Hobbsee> HrdwrBoB: vi at least is in the default install
<bddebian> jdong: You can do the fix on firestarter for me
<HrdwrBoB> Hobbsee: not vi, vim
<bddebian> It's a security issue
<jdong> bddebian: we really shouldn't be using dapper-backports for security issues :-/
<Hobbsee> HrdwrBoB: true that.
<jdong> but it sounds like it needs source changes anyway :)
<jdong> bddebian: is it the version in edgy?
<bddebian> jdong: It is now
<bddebian> jdong: Should be same as dapper + some changes
<jdong> !info firestarter edgy
* jdong mumbles
<jdong> firestarter (1.0.3-1.2ubuntu2) edgy; urgency=low
<jdong> that one?
<bddebian> Yessir
* jdong downloads sources
<Hobbsee> hey Burgundavia 
<bddebian> Heya Burgundavia
<jdong> I'd like to take this moment to complain a bit about why archive.ubuntu.com is so slow?
<jdong> 5-20kb/s
<Burgundavia> hey Hobbsee, bddebian
<Burgundavia> jdong: the DC in london is having issue, afaik
<jdong> ah, fascinating
<Burgundavia> HrdwrBoB: this yours: https://wiki.ubuntu.com/TextEditorCDRemoval
<HrdwrBoB> Burgundavia: yes
<Burgundavia> cool
<Burgundavia> ping me when you are done with it
<HrdwrBoB> I'm done with it for the moment
<HrdwrBoB> I have some actual work to do :)
<Burgundavia> right, will dig away
<HrdwrBoB> cool, cheers
<jdong> bddebian: merry christmas, bug 58164
<Ubugtu> Malone bug 58164 in dapper-backports "firestarter backport" [High,Confirmed]  http://launchpad.net/bugs/58164
<bddebian> jdong: Thx!
<bddebian> Wow, all those syncs brought down the merge list a little :-)
* jdong marvels at how fast his core duo cranked out a firestarter deb :)
* jdong grumbles at how slow XFS is at installing it since 2.6.17's write barriers
<lifeless> write barriers? 
<jdong> lifeless: yeah, flushing that annoying write cache to make sure nothing gets lost in abrupt shutdown
<jdong> without it, even journaling FS'es can corrupt during bad shutdowns
<jdong> XFS's aggressiveness makes it exceptionally vulnerable to this
<lifeless> ah
<jdong> so, safety at the cost of performance :-/
<lifeless> when does it flush now ?
<lifeless> not every write ?
<HrdwrBoB> it works ok for me :)
<jdong> right now the hd is responsible for flushing its own cache
<HrdwrBoB> (though I have XFS setup with an external journal and my disks have a large write cache)
<jdong> HrdwrBoB: extern journal turns off barriers on XFS
<HrdwrBoB> yeah
<jdong> in 2.6.17, XFS team turned on write barriers by default
<jdong> so the filesystem keeps track of what's currently in the hd's cache
<lifeless> ah, I see
<jdong> from what I've heard, ext3 has been doing this for some time now
<jdong> the goal was to address the xfs_repair-after-shutdown issues people have been complaining about
<lifeless> yeah, writing over whats in cache in the hd would be failure prone
<HrdwrBoB> writing over?
<jdong> until now, the XFS team has been just blaming it on cheap PC hardware :P
<jdong> lifeless: it's not writing over as much as it is losing...
<HrdwrBoB> not really, the cache is gone after no power
<HrdwrBoB> jdong: which realistically is fair, since XFS was designed to run on real hardware
<HrdwrBoB> with persistant write buffers
<jdong> HrdwrBoB: right, but I own cheap hardware but still want to run XFS :)
<jdub> HrdwrBoB: it was also designed to run with a real operating system... ;-)
<jdong> torrenting really blows on ext3/reiserfs
<HrdwrBoB> they also suck a lot for large filesystems
<HrdwrBoB> however, xfs delete times are awful.
<jdong> I agree
<HrdwrBoB> so you can't win
<jdong> a large journaling area + logbufs=8 helps a bit
<jdong> but that's just a band-aid
<HrdwrBoB> I'm talking about a few hundred thousand files
<jdong> I know, I feel the pain of cleaning out pbuilders every few hours
<jdong> for what I gain from XFS, it's a trade-off I am willing to make
<jdong> ext3 just simply does not work out for me
<HrdwrBoB> I use rsync+hardlinks to do backups
<HrdwrBoB> so I end up with LOTS of files
<jdong> and after trying to repair two different reiserfs corruptions, I've learned that fsck.reiserfs might as well be symlinked to mkfs.reiserfs :)
<jdong> lifeless: btw, bzr is just rocking recently.... handling my kernels superbly
<lifeless> thats fantastic nes
<lifeless> *news*
<HrdwrBoB> jdong: though I screwed XFS by trying to use it on an amd64 kernel
<HrdwrBoB> when it was made/used by a 32bit kernel
<jdong> HrdwrBoB: ouch... yeah, that's a tough lesson to learn
<jdong> HrdwrBoB: did you dodge the 2.6.17.6/7 directory corruption thing?
<jdong> that sucked for XFS's reputation :-/
<HrdwrBoB> yeah I managed to get around that, fortunately
<jdong> :)
<jdong> the other good thing about xfs, it provides me with xfs_fsr to entertain me when I'm bored
<jdong> I can fit in with Windows users and say that I defrag my filesystem :P
<HrdwrBoB> heh
<jdub> HrdwrBoB: xfs doesn't work with 64 bit kernels, or is it a filesystem portabiity issue?
<jdong> jdub: a xfs volume made in a 32-bit arch can't be used on a 64-bit arch
<jdong> if you mount it, you'll corrupt it
<jdub> that is so much bong
<jdong> no kidding :-/
<jdub> is that a linux port issue, or an xfs-in-general issue? i can't imagine why xfs would have portability problems... crazy!
<HrdwrBoB> jdub: portability
<HrdwrBoB> yeah
<HrdwrBoB> linux port issue afaik
<maswan> jdong: that's interesting, considering that I'm fairly sure I run that
<maswan> (or did I run a 64-bit kernel all the time on that host perhaps?)
<jdong> maswan: I've mounted one of my 32-bit xfs partitions under amd64 before, and it didn't seem to mess up 
<jdong> but so many people have reported problems and the XFS team has said not to do it... so.... yeah
<jdub> "doctor, it hurts if i hold my hand above my head!"
<jdub> "well, don't do that"
<jdub> *bzzt*
<jdong> jdub: i saw my doctor about something like that a week back
<jdong> he sent me home with a bottle of vicodin
<jdub> heh
<HrdwrBoB> the problem is, it's not obvious
<HrdwrBoB> and the documentation on it is sparse
<maswan> no mention of it in the faq either
<HrdwrBoB> I didn't realise that was the problem until I found an xfs mailing list post saying "my data is toast!"
<jdong> there's mention in XFS's wikipedia article
<HrdwrBoB> #
<HrdwrBoB> # On the Linux XFS implementations, compatibility issues between 64-bit and 32-bit environments exist.
<HrdwrBoB> that's a far cry from "you will frag all your data if you change to 64 bit"
<jdong> I know, very vague and not the red bold warning it deserves
<jdub> that's why wikipedia is a wiki tho :)
<maswan> ah, reading some ml stuff, there are mentions of things like patches to fix log replay when changing bitness and so
<HrdwrBoB> maswan: yeah very recently iirc
<maswan> so it might only be a "frag all data if you have change to 64 bit while having a dirty log"?
<HrdwrBoB> could be
<jdong> any firestarter "experts" in here?
<maswan> I like starting fires, but that's probably not what you're asking about.
<bddebian> heh
<jdong> nvm, pseudo-answered my own question
<jdong> when you open a port, it opens both tcp/udp
<jdong> I was wondering why it didn't ask me which
<jdong> good old iptables -L
<jdong> but either way, the backport looks good, bddebian
* jdong grumbles that he had to install a firewall on his laptop :P
<bddebian> jdong: Well I might duck a lot but you grumble alot ;-P
<jdong> :)
* jdong grumbles that azureus 2.5.0.0 isn't merged yet :P
* jdong specifically grumbles at bddebian :)
<bddebian> jdong: I'm going to try to look tomorrow but it may be over my head and I don't want doko kicking my ass :-)
<jdong> lol
<jdong> but think of it this way: it can't be any less usable than the current azureus package that he made
* jdong ducks, too :)
<bddebian> Well that's what everyone always says until I upload something ;-)
<jdong> lol
<jdong> well, I'm calling it a night. take care, everyone :)
<Hobbsee> jdong: feel free to fix it :)
<bddebian> Gnight jdong, thanks again
<slomo> infinity: ping? :) could you please accept dbus from binary NEW for all archs?
<jdub> mako: ping (planet debian)
<mako> jdub: yes
<jdub> mako: howdy - you should upgrade planet debian to planet 2.0 when you have a minute. it is much nicer, and handles some weird feeds better.
<robertj> jdub: does planet 2 fix the phenomena by which broken feeds get almost every post reposted sequentially?
<jdub> robertj: that was fixed much earlier than 2.0
<robertj> I just seem to recall seeing it alot on p.g.o. 
<jdub> robertj: not for aaaaaaages
<wubrgamer> which user owns the apache daemon by default ? on ubuntu ?
<dcstimm_> hey guys, what is the difference between the 6.06.1 livecd and the 6.06 livecd for ppc? does it fix any of the imac issues?
<LaserJock> dcstimm_: imac issues?
<dcstimm_> yeah the isight imac g5 boots to black video
<dcstimm_> the imac pre ALS goes crazy when you boot it up and the fans go on high and the console is broken
<dcstimm_> imac g4s do not boot and have graphic issues with usplash
<dcstimm_> so I was wondering the change log for 6.06.1 to see if anything was fixed
<dcstimm_> anyone know?
<LaserJock> well, do you have a fully upgraded Dapper
<LaserJock> i.e. are you using the dapper-security and dapper-updates repositories?
<dcstimm_> im talking about the livecd
<LaserJock> hmm, well you could check for bug reports on Launchpad and see if they say anything
<LaserJock> I just don't know of that specific problem
<dcstimm_> LaserJock, i am just looking for a changelog
<dcstimm_> there must be a change log between 6.06 and 6.06.1
<dcstimm_> isnt there?1
<LaserJock> hmm, not sure
<dcstimm_> standard documentation shouldnt be this hard to find
<LaserJock> dcstimm_: the release announcement is at https://lists.ubuntu.com/archives/ubuntu-announce/2006-August/000088.html
<LaserJock> I don't see anything about imacs but again, a bug report might be more useful
<LaserJock> I see a few bug reports about g5 imacs having boot problems
<Mithrandir> Seveas: why do you think that aiglx in 58015 comes from an unsupported repo?
* rouzic se ha ido
<Gloubiboulga> hello
<Hocko> Hi
<Hocko> I have found a major bug in ubuntu that renders it useless.
<mdke> Hocko: please report it at http://bugs.ubuntu.com
<infinity> Hocko: That might be a bit dramatic.  It's certainly not useless to everyone.
<Hocko> Well the bug is when my wife hogs the computer I cant use it!!!!!!!! and she wont get off.
<mdke> definitely a major one
<HrdwrBoB> Hocko: get another PC
<Hocko> come on that is some funny shit
<Hocko> lol
<HrdwrBoB> alternateively, use multi-seat ubuntu.
<HrdwrBoB> *alternatively.
<HrdwrBoB> but first, please take this discussion to #ubuntu-offtopic
<Burgundavia> mdke: remove vim from the default install: queue flamewar
<mdke> sounds like a plan to me, although that one wasn't my suggestion
<Burgundavia> somebody else just suggested on the cd thread
<mdke> yeah, I read it
<mdke> is a good idea, I think. People who like vim can install it, nano/gedit/kate are provided by default.
<HrdwrBoB> exactly
<mdke> but doesn't sabdfl use vim?
<HrdwrBoB> sabdfl can't use apt-get?
<HrdwrBoB> I use gvim, that's not installed by default either
<Burgundavia> regardless of specific people: do the majority of ubuntu users (or even a very large minority) use vim
<jdub> sysadmins the world over will hurt you
<Burgundavia> I doubt the answer to that is yes
<mdke> maybe a significant majority
<mdke> whoops, *minority
<mdke> jdub: they can install it too
<Burgundavia> jdub: then vim can survive on a -server seed
<Burgundavia> personally, I am not afraid of sysadmins
<mdke> heh
<Burgundavia> us desktop users outnumber them
<jdub> the package sizes are not that huge anyway
<Burgundavia> vim is almost 20 mb installed
<HrdwrBoB> sysadmins needs to stop whinging so damn much and get on with their lives
<jdub> installed vs. packages
<Burgundavia> jdub: installed is what counts on the cd
<HrdwrBoB> (I say that as a sysadmin)
<jsgotangco> Burgundavia: we sysads can just make the whole internet stop and make you desktop users cry
<jsgotangco> :D
<jdub> jsgotangco: score.
<jsgotangco> bye bye MMORPG
<Burgundavia> nah, I will just recruit the emacs users to keep it running
<jsgotangco> lol
<Burgundavia> as they will be pleased we stopped shipping vim
<jdub> vim-tiny -> desktop; vim -> server
<infinity> jdub: s/desktop/minimal/
<jdub> infinity: yeah
<infinity> jdub: But, yes, Colin and I were discussing that yestersay.
<infinity> yesterday, too.
<HrdwrBoB> jdub: why vim tiny?
<HrdwrBoB> and not nvi
<jdub> at least that solves the problem without punching too many people in the face
<jdub> HrdwrBoB: vim is at least vim, not vi
<infinity> nvi has some annoying misfeatures that driveme batty.
<infinity> Otherwise, I couldn't care less which one we choose.
<HrdwrBoB> I contended earlier that people who want vim will insteal real-vim
<infinity> nvi isn't THTA much smaller, though.
<jdub> infinity: misfeatures like... being vi? ;)
<infinity> jdub: Like dropping out of insert mode when you hit the beginning of a line, stuff like that.
<Seveas> Mithrandir, because quinn storms recent updates og the -i810 driver and aiglx have caused problems for more people
* netjoined: irc.freenode.net -> brown.freenode.net
<bluefoxicy> It is 4am
<bluefoxicy> I leave you with this thought, because I do not have time or really care
<bluefoxicy> Someone in #svn brought up that if you compress an input with gzip, then bzip2, you get significant gains
<bluefoxicy> this is also said to work with bzip2 and then gzip
<bluefoxicy> I'm not sure why; my best hypothesis is that compression leaves characteristics of the input stream in the output stream (after all, input is simply redundancy-eliminated and character encoded; patterns not affected by the algorithm will carry), and so rolling a different compression methodology past it allows the second pass to freely operate on those properties.
<bluefoxicy> This is only conjecture; but for similar concept, look into electronic codebook encoding with block ciphers.  Here is an encrypted picture of Tux:  http://en.wikipedia.org/wiki/Image:Tux_ecb.jpg
<thom> bluefoxicy: is this going to become relevant any time soon?
<bluefoxicy> And with that I leave you for the night.  (lzma debs vs gzip/bz2 vs gzip/bz2/lzma?)
<bluefoxicy> thom:  no clue; but at least the thought is circulating.
<thom> there's a reason that whilst we _can_ do bzip2 debs very, very few are. the relatively small gain is not worth the overhead
<bluefoxicy> thom:  personally I don't care.  I have a memory allocator to write in an attempt to solve a flaw in heap based management and reduce memory usage massively.
<bluefoxicy> thom:  no, I mean input -> gzip -> bzip2
<bluefoxicy> someone brought up that, strangely, the fact that it's gzipped already doesn't stop bzip2 from also causing a 20% reduction if it would have caused a 20% reduction on the input stream, or some such nonsense
<bluefoxicy> thom:  I have no answer for A) if it really works that way; B) if so, why it works that way; or C) If it's significant enough that anyone cares.  Regardless, such things are interesting; if everyone kept their ideas to themselves where would we be?
<thom> on topic?
<bluefoxicy> normally I'd prove it and give a stronger argument but I'm tired, it's 4am, and I have class tomorrow,
<dholbach> good morning
<Hobbsee> hey dholbach 
<dholbach> hey Hobbsee
<Chipzz> hrrrrm
<Chipzz> anyone knows if something broke in ssh (the client) recently?
<Tonio_> hello
<Kamion> HrdwrBoB: nvi has crappy undo, vim-tiny doesn't. that alone is enough to recommend vim-tiny
<Kamion> and honestly, I'll revert any seed change that removes vim altogether
<Kamion> sorry, that removes vi altogether
<Kamion> I'd merely protest very loudly about replacing it with nvi
<seb128> Kamion: hi. Did you get the UVF mail about gimp?
<HrdwrBoB> removing vi is stupid and not an option :)_
<HrdwrBoB> I 100% agree
<Kamion> HrdwrBoB: right, but Burgundavia doesn't
<Kamion> seb128: I think so, will check later
<Kamion> Chipzz: perhaps you could give some detail?
<seb128> Kamion: ok, no hurry ;)
<Chipzz> Kamion: ssh dsa keys take forever to login
<Chipzz> rsa keys work
<Kamion> Chipzz: nothing in the client has changed in that regard
<Chipzz> Kamion: could just as well be the server though
<Kamion> use -vvv (or -ddd on the server) to diagnose exactly where the slowness is
<sivang> morning
<Chipzz> Kamion: it accepts my first 2 (non-dsa) keys, whihc are not authorized, but it never gets around to accepting the third key
<Lathiat> i've noticed that
<Lathiat> it'd just sit there on a key forever
<Lathiat> never figured out why had to SSG_AGENT=""
<Kamion> happy to try to diagnose further given a bug with a -vvv trace
<Lathiat> yeh if im able to reproduce it again i'll let you know
<Lathiat> iirc it sat on the trying private key bit
<Lathiat> but yeh i'll get a -vvv next stime i see it
<Lathiat> else maybe Chipzz can get one :)
<Kamion> revno: 785
<Kamion> message:
<Kamion>   replace vim with vim-tiny in minimal; move vim to ship
<Mithrandir> Kamion: do you know how I mark edgy as frozen?
<sivang> Mithrandir: is there a knot planned ?
<Mithrandir> sivang: yes, don't you read u-d-a?
<sivang> Mithrandir: been out of date lately...should come to terms with my exploding mbox soon.
<Kamion> Mithrandir: hmm, you might need to be in ubuntu-drivers - let me have a look
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | Main frozen for knot-2 - ask Mithrandir for freeze exceptions
<Kamion> hmm, I *used* to be able to make that change - I know I made it for dapper
<Kamion> Mithrandir: ask Keybuk, see if a member of the tech board can do it
<Kamion> failing that, ask #launchpad
<Kamion> Mithrandir: so, it would be nice to figure out why gparted is popping up dialogs behind ubiquity
<sivang> Mithrandir: uploads wil be resumed afterwards right?
<Tonio_> is the knot 2 freeze ended, or should I wait a bit to upoad ?
<Mithrandir> Kamion: uh, when did it start doing that?
<Kamion> Tonio_: it only just started
<Kamion> Mithrandir: after the initial merge from Debian in edgy
<Mithrandir> Tonio_: it started just now, so if you want to upload to main, you'll need to hold off.
<Tonio_> kamnion, let's wait a bit then :)
<Kamion> I've never been able to figure out why
<Tonio_> s/kamnion/Kamion
<Kamion> I meant to get a couple of gtk hackers to investigate at the sprint, but forgot
<Mithrandir> sivang: yes, we'll be in UVF, getting close to FF afterwards.
<Mithrandir> Kamion: he doesn't seem to be around, though.  I'll drop him a mail.
<sivang> Mithrandir: k, thanks.
<Kamion> Mithrandir: I have two more pieces of no-more-devfs to upload (just merges). Can I do that?
<Kamion> specifically nobootloader and partman-target
<Mithrandir> Kamion: you're confident in them?  If so, upload away.
<Kamion> Mithrandir: as confident as I am in the other bits of no-more-devfs that are already in the archive
<Kamion> which is a slightly weasel answer :)
<Mithrandir> Kamion: go ahead, then. :-)
<Kamion> I'd rather fix the whole thing than just most of it
<Mithrandir> yeah
<Chipzz> Kamion: just checked, logging in with the same key from another host worked
<Tonio_> Hobbsee: http://wiki.thekatapult.org.uk/Download
<Tonio_> latest source tarball is more recent than our version ;)
<Tonio_> I'm trying to upgrade
<Hobbsee> Tonio_: wish you'd seen that about an hour ago.
<Hobbsee> oh, wait, we'd need a UVF for it anyway.  damn
<Tonio_> Hobbsee: yes, but if it closes 2 bugs that'll be okay ;)
<Hobbsee> true that
* Hobbsee wonders if reporting a bug to LP via email actually works.
* Hobbsee decides to use a script, and just add to it.  safer.
<Kamion> it does work
<Kamion> you have to sign it and provide an 'affects' line
<Hobbsee> ah, right
<Hobbsee> i'll remember that :)
<Tonio_> Kamion: thanks for the tip, that'll help :)
<Kamion> there's documentation on the web somewhere for affects lines
<Hobbsee> true that
<Hobbsee> i just couldnt remember what it actually says
* Hobbsee is exhausted, and it's only 7pm!
<infinity> Is it sad that I can identify source packages base on only seeing their Build-Depends lines?
<infinity> I suspect this may be a sign that I've descended into complete insanity.
<infinity> s/base/based/
* dholbach hugs infinity
<Hobbsee> infinity: you mean you werent insane before?
<infinity> Mithrandir: I can mark edgy as frozen.
<infinity> Hobbsee: I was, but perhaps only partially.
<Hobbsee> infinity: ahhh...right
<Mithrandir> infinity: please do so.
<Mithrandir> infinity: I wonder why you can and I can't, though.
<infinity> Mithrandir: Because I have a rubber duckie next to my name.. *cough*
<infinity> Mithrandir: Done.  You're frozen.
* Mithrandir feels the ice closing in.
<Mithrandir> infinity: thanks.
<infinity> I suspect that's something we might want the -release team to be able to do.
<Mithrandir> yeah, it'd be kinda useful.
<infinity> Anyhow, until they take away my duck again, I can do it for now.
* infinity is pretty happy about getting that last LRM in under the wire.
<mjg59> Does that make it Ben's problem now?
<dholbach> infinity: they took your duck away?
<infinity> mjg59: In theory, LRM has been Ben's problem since edgy opened.  I just have a hard time keeping from meddling.
<infinity> dholbach: They took it away, then gave it back when it was determined that I couldn't yet do my job without it.
<dholbach> infinity: I hope you'll be able to keep it this time
<infinity> dholbach: I don't really want it.  Being an LP admin means getting mail from all sorts of odd people with strange questions.  Doubly-so, because I'm the first name in the team list, due to being alphabetically challenged. :)
<infinity> dholbach: But it's nice to be able to poke a few buttons that we, as a team, should be able to poke, but can't yet.
<Hobbsee> infinity: hah.  i've found that with being a team leader on LP too.  emailed about everything, and poked into actually doing something.
<dholbach> Urg... ok, I understand :-)
<Hobbsee> infinity: try changing your name to Zaphod or something.
<seb128> at what time is the meeting tomorrow? did we shifted or skipped the 7am meeting?
<Seveas> @schedule paris
<Seveas> hmm, not on in here
<Seveas> @config channel plugins.webcal.url http://fridge.ubuntu.com/event/ical
<dholbach> "31 Aug 17:00: Ubuntu Development Team"
<Seveas> @config channel plugins.webcal.filter #ubuntu-meeting
<seb128> dholbach: the fridge is not really a reference to me :p
<Seveas> @config channel plugins.webcal.dotopic
<Ubugtu> False
<seb128> dholbach: and I would prefer 9am better ;)
<dholbach> seb128: then ask sfllaw
<seb128> dholbach: that's why I ask on that chan ...
<seb128> dholbach: not to be pointed to the fridge :p
<dholbach> there's not other "official" information atm and I can't remember a discussion about it
<seb128> ok
<Seveas> dholbach, according to the fridge it's hug day today
<dholbach> sfllaw: ^^ did you announce it to the fridge, but didn't send an announce mail?
<seb128> I think every wednesday is a hug day according to the fridge
<Mithrandir> ogra: are you working on fixing edubuntu's size problem?
<ogra> yes
<Mithrandir> Gloubiboulga: xubuntu alternate CDs are oversized, you're aware of that?
<ogra> i was hoping for Kamion to probably make the vim switch :)
<Gloubiboulga> Mithrandir, yep
<Mithrandir> he already did.
<ogra> apart from 6M on i386 i'm fine
<ogra> oh
<ogra> then i need to check size again :)
<Kamion> it's not active yet
<ogra> ah
<Kamion> Mithrandir: can I upload ubuntu-meta to change that?
<Mithrandir> Kamion: please do.
<Kamion> needs a priority change on the archive as well
* ogra merges seeds for consistency
<Kamion> ogra: you'll probably want to drop vim from your ship
<ogra> right
<Gloubiboulga> Mithrandir, Jani has modified the seeds, could you rebuild the alternate isos?
<Mithrandir> Gloubiboulga: the new seeds have been uploaded too?
<mvo> doko: around?
<Kamion> can you wait for the ubuntu-minimal change?
<doko> mvo: yes
<Gloubiboulga> Mithrandir, yes
<Mithrandir> Kamion: if that "you" was me, sure.
<Kamion> mostly to Gloubiboulga
<Gloubiboulga> Kamion, I can wait :)
<Mithrandir> *sigh*; alternate ppc is still oversized.
<Kamion> oh, hmm, it will take a little while
<Mithrandir> I'll need to rebuild ubuntu alternate too.
<Kamion> need to wait for the override change I just applied to vim-tiny to appear in a publisher run
<Kamion> so go ahead and rebuild xubuntu if there are other things to be tested
<Kamion> hmm, what to do about powerpc I wonder
<Mithrandir> Kamion: old image, it looks like.  It includes *-ppds still
<Mithrandir> I'll do it after xubuntu alternate
<Kamion> oh, what happened to this morning's build?
<Mithrandir> I disabled it. :-P
<Mithrandir> (so much for checklists, sorry)
<Kamion> oh
<Kamion> ok :)
<mvo> Mithrandir: permission to upload a fix to hplip? it fixes a upgrade issue and is only a two-line change in the rules file
<Kamion> you needed to rebuild alternate for partman-target anyway
<Mithrandir> Kamion: oh, sure.
<Kamion> which is on its way shortly
<Mithrandir> mvo: what kind of upgrade issue?  As in, is it useful for knot?
<infinity> Mithrandir: BTW, don't bother building ia64/sparc images for knot-2. Not worth the pain, they won't be functional anyway (at least, not live images)
<mvo> Mithrandir: people upgrading from dapper->edgy will be bitten by it, its a postinst failure. I can put up a debdiff if you want
<Mithrandir> mvo: yes, please.
<mvo> Mithrandir: http://people.ubuntu.com/~mvo/hplip_0.9.11-2ubuntu5.debdiff (a similar change is in the latst debian package)
<Kamion> ok, I'm going to grossly fudge ubuntu-meta to speed things up
<Kamion> partman-target uploaded
<Mithrandir> Kamion: thanks.
<Mithrandir> mvo: ok, upload away.
<mvo> Mithrandir: thanks
<Gloubiboulga> hum, xubuntu alternate isos still have the same size
<seb128> Mithrandir: is that ok to upload a nautilus with a Conflicts version updated to fix bug #56985 ?
<Ubugtu> Malone bug 56985 in nautilus "nautilus-data missing Replaces: nautilus" [High,Confirmed]  http://launchpad.net/bugs/56985
<Mithrandir> seb128: no other changes?  Go ahead.
<seb128> nop, no other change
<seb128> ok, thank you
<janimo> Gloubiboulga: hi
<Kamion> seb128: argh, why conflicts?
<Kamion> seb128: if a file moves, you should use Replaces
<janimo> Gloubiboulga: I wonder what grew so much since dapper in the alternates
<Kamion> Conflicts makes upgrades unnecessarily hard for the package management tools
<janimo> Gloubiboulga: I'd prefer keeping full vim if we can though
<seb128> Kamion: I do use some Replaces, some Debian guys use Conflicts, in that case the change come from Debian I just updated the version
<Kamion> can you get that changed in Debian please?
<seb128> Kamion: ok, will do
<Kamion> thanks
<seb128> np
<seb128> Mithrandir: ok to update Replaces version for gnome-menus (bug #56984)
<Ubugtu> Malone bug 56984 in gnome-menus "python-gmenu package missing "Replaces: gnome-menus"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/56984
<Mithrandir> seb128: ok.  Do you have many more similar replaces/conflicts bugs?
<seb128> Mithrandir: no, that was only nautilus and gnome-menus
<Mithrandir> seb128: I'm fine with a few of them, but I'd really like us not to end up with having to rebuild half of gnome.
<Mithrandir> seb128: ok, that's fine then. :-)
<seb128> yeah, sure
<seb128> thank you ;)
<seb128> rebuild of GNOME is for next week :p
<seb128> (GNOME 2.16.0 tarballs on monday)
<Gloubiboulga> janimo, ok for vim, I guess that we can remove a bunch of language packs
<Kamion> janimo: moving from vim to vim-tiny in minimal was a change that affected all derivatives, btw
<Mithrandir> seb128: that's fine since we'll be a bit away from a knot at that time.
<seb128> right
<Kamion> janimo: if you want to keep vim in your default installation, that would need to be done by adding it to your desktop
<seb128> anyway lunch time for now, bbl
<Mithrandir> Gloubiboulga: oh, xubuntu built a bit of time ago.
<janimo> Kamion: ok thanks
<Gloubiboulga> Mithrandir, yep I've seen this, thanks
<Mithrandir> I'll do a ubuntu build now to make sure ppc is fine, size-wise.
<Gloubiboulga> Mithrandir, I'll certainly poke you later for an other build (size issues again)
<Mithrandir> Gloubiboulga: sure.
<janimo> Kamion: is this correct syntax in seeds * language-support-${Languages} [i386] 
<janimo> I am trying to move all but English language supports only to i386 for now
<Kamion> janimo: yes, that's right
<janimo> Kamion: so what's in ship goes to the alternate CD and live seed to the desktop. These are the two places where Languages appear. This is what I assumed so far but want to make sure
<Kamion> janimo: right
<Kamion> I should write up a README at some point
<janimo> ok, thanks I wasn't sure if the relatively recent ship-live changed what I knew in dapper
<Kamion> packages in ship-live end up on the desktop CD as .debs, rather than being installed in the live filesystem
<Kamion> so you get /casper/filesystem.squashfs containing boot+minimal+standard+desktop+live, and /dists/ and /pool/ containing ship-live
<Seveas> Kamion, 'added vim-tiny to...' -- vim conflicts with vim-tiny, so installing vim whill remove ubuntu-minimal, right?
<Kamion> Seveas: vim Conflicts: vim-tiny (<< 1:6.4-001+3)
<Kamion> Seveas: current vim-tiny is 1:7.0-035+1ubuntu2
<Seveas> ah
<janimo> Kamion: I wonder if  debs on the liveCD copuld be used to install xubuntu-at- packages we talked about yesterday?
<janimo> what is that ship-live repo used for now?
<Kamion> janimo: it's possible, but would require a certain amount of head-scratching in ubiquity. :-)
<Kamion> janimo: basically to make stuff like build-essential available
<janimo> Kamion: to make sure they don't get installed on the disk you mean?
<Kamion> and various network access packages
<Kamion> janimo: no, just to do the installation at all
<Kamion> it's all just glue, nothing massively complicated, but would need to be done ...
<janimo> I'll have to take a look I guess if there is no other solution which lets gnome AT tools be installed on the CD but only optional on the final install
<Kamion> the other solution is live-cd-stacked-filesystems, as I said yesterday
<Kamion> having the accessibility packages be a layer stacked just above the desktop
<Kamion> so ubiquity could choose to copy just the desktop bit or desktop+accessibility
<Kamion> yet another alternative is just teaching ubiquity to manually remove the AT packages
<janimo> right. Is that done already? Is it to be used by ubiquity for something else?
<janimo> right I was thinking of the manual removal as it happens with languages
<Kamion> it's to be used by ubiquity in place of its current remove-lots-of-packages hacks; I think it's mostly done
<janimo> ok
<elmo> Kamion: ehm, dude
<elmo> Kamion: cdimage is up to 479GB
<elmo> pls to be reigning it in
<janimo> Gloubiboulga: committed modified seeds with only En on amd64 and ppc
<Kamion> elmo: ok, I'll have a look. you mean the bit that's mirrored?
<janimo> but I'd like to wait a bit until I upload x-system-tools before a respin ok?
<elmo> Kamion: yes
<Kamion> I'll just nuke the point-release dapper builds
<Gloubiboulga> janimo, ok
<janimo> Gloubiboulga: did you ./update from xubutu-meta for the upload?
<infinity> Kamion: Not sure we can do that, since it gives us some undefined behaviour.
<Kamion> infinity: ?
<janimo> I wonder why my subsequent upload of today deleted the two xfce plugins for HPPA, and they were ok when you uploaded
<infinity> Kamion: live-cd-stacked-filsystem assumes a linear 1+2+3 growth in filesystem stacking.
<Kamion> infinity: I'm not sure what that means
<infinity> Kamion: So, if we're doing base+desktop+live+live-dvd, where does live-at fit?
<Kamion> infinity: base+desktop+live-at+live+live-dvd
<infinity> Kamion: (We're overlaying a new dpkg status file each time, so we can't really do anything nonlinear)
<Kamion> right, seems pretty linear to me though
<Gloubiboulga> janimo, I didn't 
<infinity> Kamion: Okay, so live-at will always be there, check.  Then that's fine.
<janimo> Gloubiboulga: you wrote the changelog by hand?
<infinity> Kamion: I wasn't really following the above well enough to catch that, I guess.
<Kamion> elmo: down to 376GB - is there anywhere else I can put stuff like the archival copy of dapper.0?
<Gloubiboulga> janimo, yes, I need to use the tools wa have next times ;)
<janimo> Gloubiboulga: ok :). So after you commit to the seeds, just run ./update from the most recent xubuntu-meta, and it will generate the new version with automated changelog
<elmo> Kamion: public or for backup/storage?
<Kamion> elmo: dapper.0 probably still ought to be public
<Kamion> elmo: you could backup old-releases/{warty,.pool/warty*} non-publicly now, though
<Kamion> that's only 2.3GB though
<Kamion> you know, I'm just going to stop keeping two DVD builds
<elmo> Kamion: we could put them on hutte I guess - got any suggestions for a hostname?
<Kamion> elmo: old-releases.ubuntu.com?
<elmo> ok
<elmo> I'll setup an RT ticket - where should we copy the stuff from?
<Kamion> for warty or dapper?
<Kamion> elmo: /srv/cdimage.ubuntu.com/www/full/{,ports/,kubuntu/,edubuntu/,xubuntu/}dapper/release/
<elmo> blink
<elmo> that's old releases?
<Kamion> that's dapper.0
<Kamion> except make that /srv/cdimage.ubuntu.com/www/full/{,ports/,kubuntu/,edubuntu/,xubuntu/}releases/dapper/release/
<elmo> hmm, ok
<Kamion> the archival copies of warty and hoary are in /srv/cdimage.ubuntu.com/www/full/old-releases/
<Kamion> I guess all of that can be moved
<lifeless> infinity: - has evms changed in the dapper at all ?
<lifeless> infinity: I have a sick home server, I powered it off by mistake, but its claiming 
<lifeless> device-mapper: unknown target type
<Mithrandir> lifeless: with a stock kernel?
<infinity> lifeless: Not that I know of...
<lifeless> Mithrandir: yes, I'm booting off a 6.06lts livecd right now, and evmsn sees the volumes, bu refuses to activate with that error
<lifeless> doing evms_activate in busybox - when it fails to boot off hard disk - gives the same spew
<lifeless> I'm trying to find the bug I filed in launchpad that was related to this - 
<lifeless> when evms was broken during the dapper development cycle
<lifeless> ahem, faq-like question from moi:
<lifeless> http://evms.sourceforge.net/faq.html
<lifeless> the 'volume activation' entry there matches my symptoms. 
<lifeless>  - do we have that patch installed ? (yes, I know I should look myself, but my network access is rather curtailed with my main machine down)
<Mithrandir> yes, we have always have had that applied
<lifeless> thanks
<Riddell> Kamion: ubiquity fails on today's kubuntu CD https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/58199
<Ubugtu> Malone bug 58199 in ubiquity "Fails at apt-setup on kubuntu 20060830" [Untriaged,Unconfirmed]  
<Kamion> thanks, I'll check; I think that's a dupe
<mvo> Kamion: I will need some files on a ubuntu-alternative CD for the cdrom-dist-upgrades spec. what is the best way to learn more aobut the CD building and how I can integrate my stuff?
<Kamion> mvo: grab http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/, or just file a bug on /products/ubuntu-cdimage
<Kamion> mvo: how much space are we talking about here?
<mvo> Kamion: about 1,6mb (1,4 of this are mo files)
<Simira> Riddell: do you know if anything is done with kmail/kontact? they're setting new records of number of crashes at work today
<mvo> Kamion: so if we only do the supported languages it should be no more than ~400k
<Kamion> ok
<Riddell> Simira: I'm not sure what you're asking
<Kamion> Riddell: found the problem, fixing
<elmo> Kamion: any chance you could move everything you want on old-releases to a new subdir of www/ ?
<elmo> Kamion: we could do it if you like, of course, but it seems safer/saner if you guys do
<lifeless> Mithrandir: are you running evms ?
<lifeless> Mithrandir: can you do 'dmsetup targets' and show me the output ?
<Kamion> elmo: sure, I'll do so once I've finished with this ubiquity bugfix
<Simira> Riddell: do you know anything about kmail/kontact bugs and how fast they are being fixed? kmail seems to crash a lot
<sfllaw> dholbach: The ones on fridge are pre-scheduled.  Last week's fell in between two of them.
<Riddell> Simira: I don't know, I'd guess developmen will be focusing on kde 4
<mvo> Kamion: can we use "CDROM_ROOT/upgrade/" as the place for the dist-upgrader? or is that not-so-good because it was used in older debian releases to put packages in that needed upgrading before the install?
<elmo> Kamion: thanks
<Kamion> mvo: wouldn't it be better to put it in the same relative place as it is in the archive? so /dists/$DIST/main/upgrader-$ARCH/ or whatever it is
<lifeless> infinity: if you are still up, diagnosis is that dmsetup is missing some targets
<Kamion> dist-upgrader-$ARCH
<lifeless> http://rafb.net/paste/results/hm6hdZ52.html shows what it should look like for me, and the #evms folk are saying 'kernel patches affect this'
<infinity> lifeless: Fun.  Of course, I know pretty much nothing about evms.  The fact that I've uploaded it a few times means nothing. :)
<doko> Kamion: I'd like to upload OOo 2.0.4rc1, it shouldn't affect the knot-cd unless somebody processes the new binaries in NEW (and if all builds succeed, then it could be a candidate for knot-2 as well)
<infinity> lifeless: I can confirm the lack of targets on edgy, though.
<lifeless> CONFIG_BLK_DEV_DM_BBR
<Kamion> doko: -> Mithrandir, but I'm pretty sure the answer will be "please hold off until after knot-2"
<lifeless> thats apparently not on in our kernel config anymore
<lifeless> and thats what I need
<infinity> doko: I'd rather not have the buildds stuffed up while we're trying to do the release, especially since we only have one powerpc buildd.
<Mithrandir> doko: please hold it off until we're post-knot-2.
<infinity> lifeless: Perhaps best to take it up with BenC then, either on IC< or in a bug report.
<Mithrandir> lifeless: 
<Mithrandir> : tfheen@thosu ~ > sudo dmsetup targets
<Mithrandir> striped          v1.0.2
<Mithrandir> linear           v1.0.1
<Mithrandir> error            v1.0.1
<lifeless> infinity: well, I have no mail etc until I unfuck this
<lifeless> infinity: but I appreciate its really in his court
<doko> Kamion, Mithrandir: yeah, and then I have to hold off for feature freeze ... you know that -base and the wizards are currently broken?
<infinity> doko: Blocking the powerpc buildd for the next 12 hours just isn't an option right now. :/
<infinity> doko: If you upload right after knot-2, we'll all be much happier.
<Kamion> there is a week between knot-2 and feature freeze
<Kamion> so no, you won't have to hold off
<Mithrandir> doko: unless something goes wrong, you should be able to upload late tomorrow or Friday.  That leaves you a fair bit of time.
<doko> ok
<jsgotangco> doko: the SoC evaluations should be in already right? i was away for a few days....
<doko> jsgotangco: yes
<jsgotangco> ok sorry just catching up now...and google's app gives me server errors
<jsgotangco> argghh these server errors suck
<iGama> Hy!
<iGama> i have 1 question
<Simira> iGama: ask on #ubuntu
<iGama> what do i have do to , so submit a packet proposol?
<iGama> Simira its not that kind of help :p
<iGama> package pros.
<WaterSevenUb> iGama, you are talking about the OO-PT thing? 
<iGama> also that
<WaterSevenUb> Simira, the thing is that currently there is available openoffice-pt_PT and dictionaries for it, as well as many updates on aspell-pt and ispell-pt.... 
<iGama> but in generall ways, what do i have do to, to submit a package?
<WaterSevenUb> Simiria, that we would like to see in Edgy.
<Simira> WaterSevenUb: uh... wrong nickname?
<iGama> Simira so, in witch channel can we find the answer?
<Simira> iGama: #ubuntu-motu, maybe?
<pygi> jdub, poke?
<dholbach> sfllaw: what does that mean?
<sfllaw> It means that I forgot about this one.
<sfllaw> :)
<sfllaw> It thought it was next week.
<lifeless> anyone know what TZ benc is operating on ?
<StevenK> lifeless: -4
<StevenK> lifeless: As the changelog for the kernel would have told you.
<lifeless> thats where he *lives*, not what hes operating on.
<StevenK> Bah, semantics. :-P
<lifeless> and given that the kernel changelog also fails to mention 'fuck evm by removing BBR support', its not really a useful hint to give me
<neuralis> infinity: poke me when you're around
<infinity> neuralis: I'm vaguely aroundish.
<lifeless> is there a dead chicken to build just -one- of our brazjillion kernel targets ?
<Mithrandir> lifeless: debian/rules binary flavours=amd64-k8, I think
<zul>  binary-debs
<sivang> hmm, something is changed in when apt updates the cache.. it adds something like "GB-Translation" to the lines.. Is that part of a new specification that got implemented ?
<mvo_> sivang: that are the translated package descriptions
<jdong> infinity: buildd's not finding packages that exist :(
<jdong> https://launchpad.net/+builds/+build/240508
<jdong> it was just under dependency wait for libifp-dev, which is definitely in dapper universe
<infinity> jdong: Err, what?
<infinity> jdong: That's needs-build.
<jdong> it was depwait a second ago
<jdong> I swear
<infinity> jdong: How many seconds? :)
<jdong> 3 seconds ago, I swear :)
<infinity> jdong: Anyhow, I assume that means that libifp-dev was recently published or something.
<azeem> jdong: always make screenshots before you tell infinity
<infinity> Or, wait.  You said that libifp-dev is in universe?
<infinity> jdong: Let me guess, amarok is in main?
<jdong> perhaps
<infinity> That would do it, then.
<infinity> main doesn't build against universe.
<jdong> yes, it is :(
<jdong> darn
<slomo> janimo: evince-gtk FTBFS... could you take a look at it? or is it not used anymore by xfce?
<janimo> slomo: I'll take a look thanks. I was planning to update it to newer evince anyway
<slomo> janimo: thanks :)
<janimo> slomo: thanks for moving it to dbus-90 :)
<slomo> janimo: only a rebuild ;) unfortunately i tested only the real evince... looks like evince-gtk may need some patches for a newer djvu or something
<janimo> slomo: ok, I'll check it out.
<sivang> mvo_: cool
<janimo> Mithrandir: all uploads frozen or onlyu those that go to the ubuntu cd?
<ogra> janimo, usually main 
<Mithrandir> janimo: main is frozen.  Getting exceptions for stuff which doesn't go on the CD is obviously easier than for stuff which goes on the CD.
<janimo> Mithrandir: I mean main and not ubuntu CD (but xubuntu)
<janimo> it was usually less frozen than the main CD while that built
<Mithrandir> janimo: if you ask for xubuntu-specific exceptions, I can't see me not granting them, no, but you might want to have your changes eyeballed for sanity anyway?
<janimo> Mithrandir: ok, thanks.I'll point to the log when I am done.
<imbrandon> siretart: ping
<imbrandon> infinity: the libifp is in main in edgy, we cant promote it in a published distro for the backport huh ? we'll need a source change i'm guessing
<jdong> infinity: or allow backports to build against all sections? :P
<infinity> imbrandon: Changing components in a published distro is definitely a no-no.
<imbrandon> right
<imbrandon> well see thats the problem, what about allowing the -backports to build against all sections
<imbrandon> [08:40]  <Riddell> jdong: it seems like a bug in the backports implementation to me, this sort of thing can not be too uncommon
<infinity> Allowing backports to break component expectations may be acceptable, if we're also making it clear that we don't support backport in any way, shape, or form.
<infinity> Since, then, sections don't matter for backports.
<infinity> (Except for the non-free/free distinction)
<imbrandon> infinity: yea i think thats clear since its not enabled by default either
<imbrandon> its a choice to use it
<jdong> right
<infinity> I'll have to bring it up with the rest of the archive team.  It's not a policy decisoin I'll make in a vacuum.
<infinity> But since we don't provide any commercial support for backports, I suspect the main/universe distinction is pointless anyway.
<jdong> it's pretty clearly stated already that backports is not a supported repo
<imbrandon> not a problem, just curious an eta ? as in will it be a meeting agenda or you just gonna poke them ?
<Kamion> I'm not sure there's actually anything wrong with changing components in backports
<infinity> imbrandon: I'll just bring it up with my team when we're not busy trying to do a Knot release.
<Kamion> policy-wise
<Kamion> but I don't know whether Soyuz deals with that gracefully
<imbrandon> infinity: definately ;)
<infinity> Kamion: No, but there's something wrong with chanigng components of an already-published non-backport library to allow a backport to build. :)
<Kamion> oh, non-backport? right
<imbrandon> infinity: yea i was just sigesting that as a no-no ;)
<imbrandon> sugesting*
<imbrandon> jez
<imbrandon> e/g we COULDENT do that soo what COULD we do kinda thing
<infinity> Kamion: Hence why I figure it might make more sense to just view backports itself as universe/multiverse free-for-all, and drop the main/resitrcted distinction entirely, since backports aren't supported, hence de-facto not "main".
<jdong> if we backported libifp-dev to dapper, would it magically turn buildable?
* jdong smacks himself for such a reckless idea
<imbrandon> jdong: no
<infinity> jdong: Only if we popped it in main.  But don't do that.
<imbrandon> t dosent cahnge the component 
<jdong> k
<imbrandon> right
<infinity> jdong: Not much point in backporting anything if we backport all the libraries too.  Then you just have.. Edgy.
<imbrandon> exactly ;)
<jdong> well, I'm gonna grab breakfast, you guys enjoy hashing this out :)
<imbrandon> infinity: so ping you in ~36+ hours and ask again ( hince after knot publish )
<elmo> I'd pay someone $$$ to "fix" ubuntu-server so nano isn't even installed
<infinity> Kamion: Anyhow, I don't know if soyuz does per-pocket overrides, but I doubt it's worth the effort.  I can just mangle the ogre setup on the -backports chroots to always build against main+universe (for free sources) and main+universe+multiverse+restricted (for non-free sources), and just hand-wave the problem away.
<imbrandon> elmo: nooooo
<imbrandon> heh
<infinity> elmo: Paypal adconrad@0c3.net.
<Hobbsee> elmo: sounds good :)  who uses nano anyway :)
* Hobbsee runs sudo update-alternatives --config editor on imbrandon's machine again
<imbrandon> Hobbsee: i'll sooo disable ssh 
<imbrandon> ;)
<jdong> EVERYONE USES NANO :)
<infinity> They do?
<infinity> I despise it.
<jdong> what newbie editor would you suggest then?
<infinity> You don't want to know.
<jdong> I'm not teaching someone how to use vi over the phone :(
<imbrandon> hahaha
<infinity> Well, you might want o know, but if I tell you, elmo will hit me.
<Hobbsee> haha
<imbrandon> kwrite ;)
<Hobbsee> infinity: well tell elmo to cover his ears
<jdong> the last time I did that, swear words came out
<infinity> elmo: Don't look.
* Hobbsee watches elmo look
<infinity> jdong: I use "ae" as a lightweight newbie editor.
<Hobbsee> imbrandon: pretty hard for me to do anything that way
<infinity> (And, no, it's not in the archive, it's not been in Debian since potato)
<jdong> interesting
<imbrandon> Hobbsee: not realy you can tunnel X over ssh , i just havent told you how yet ;)
<Hobbsee> imbrandon: i've seen it before.  in fact, i've done it before.  it's too damned slow though.
<Hobbsee> imbrandon: i had ajmitch and StevenK over here, remember?
<imbrandon> hehe *couch*nx*cough*
* Hobbsee discovered lots of evil stuff from that
<imbrandon> nx over ssh can go fast on a 56k ;) but thats beside the point when you only have console 
<imbrandon> and considering nx isnt in the archives either
<Mithrandir> nx is stuffed with crack
<janimo> dholbach: hi, is g-s-t 2.15 supposed to be less buggy than 2.14 was?
<janimo> I get weird errors and want to make sure it's not my system that is broken
<dholbach> janimo: it uses new infrastructure
<janimo> that's an elusive answer ;)
<dholbach> janimo: make sure you file a bug or ask garnacho on #gst on irc.gimp.net
<dholbach> that's an answer that indicates that it might be due to new infrastructure :)
<janimo> I was just generally asking fro you rexperience is it working?
<seb128> janimo: new infrastructure is likely to bring new bugs too
<janimo> since all tools fail but differently
<seb128> janimo: not that good but ganarcho is working on it this week
<janimo> good part is he reduced a few gnome dependencies in the code, my gtk-only patch is a lot smaller
<janimo> I'll talk to him about this on #gst.
<janimo> Mithrandir: the upload exception I asked for was for xubuntu-system-tools. It's not a simple diff, but a new orig.tar.gz as well. I resynced with gnome-system-tools
<Mithrandir> janimo: if you think it's good to have it in xubuntu knot-2, feel free to upload it.
<janimo> with the current version it won't start at all, with the new upload it starts and works as correcly as g-s-t
<Mithrandir> sounds like progress to me. :-)
<janimo> Mithrandir: thanks
<janimo> yes, it closes one PL bug, possibly opens the gate a few new ones :)
<janimo> s/PL/LP/
* janimo notices that the gst channel on gimp.net is mostly garnacho + the ubuntu desktop team :)
<dholbach> janimo: they don't bite... often
<ivoks> does anyone knows what's the size of whole archive?
<infinity> Yes.
<ivoks> i'm buying new disks, so i'm thinking about mirroring it
<infinity> lp_archive@drescher:/srv/launchpad.net/ubuntu-archive/ubuntu$ du --max-depth 0   
<infinity> 206368248       .
<infinity> That big.
<infinity> And growing.
<ivoks> thanks
<jdong_> where's the emacs joke when you need it :(
<infinity> I'd suggest 4x300GB drives in a 900GB RAID-5 would be the way to go.
* jdong_ notes bddebian isn't here
<infinity> Or, if you're pressed to options, 2x500 in a RAID-1 should give room for a while.
<elmo> infinity: that's including non release architectures
<infinity> s/to options/for options/
<elmo> it's about 160GB without
<infinity> elmo: Fair point, but we all love those arches, don't we? :)
<ivoks> i was thinking about 320GB in RAID1
<infinity> ivoks: Should be room for a while, as long as you're not mirroring a mess of other stuff too.
<infinity> ivoks: I just always overpurchase, cause disk space goes really.. Fast.
<ivoks> infinity: i'll leave it at this for a while
<ivoks> infinity: later i'll buy new disks and new controler :/
<infinity> And overpurchasing on disk is cheap these days anyway.
<ivoks> it is
<infinity> elmo: When slomo uploads 50 packages at once, I miss ross.  Can we either get it back, or remove slomo from the keyring?  I'm open to either option.
<infinity> (Yes, I realise I can do the latter myself)
<tseng> if you remove slomo I'll have to actually upload things
<ivoks> :)
<tseng> I'm against this
<slomo> infinity: hm? you said it would be ok to upload now
<infinity> slomo: Yes, I did, and it is.  I'm just being whiney. :)
<elmo> infinity: znarl's moving powerpcs around now to get you ross back
<Hobbsee> infinity: haha.
<infinity> elmo: Oh, wow.  Many fluttering hearts for Znarl.
* slomo hugs infinity 
<Hobbsee> infinity: if it's not him uploading things, it's me requesting syncs.  you cant win.
<infinity> man, is there anything that ISN'T linked against dbus anymore?
<infinity> *spit*
<tseng> infinity: gnucash!
<infinity> I'm just failing to understand why half this stuff cares about IPC in the first place.
<tseng> years stuck at gtk+ 1.2, now its linked to dbus
<slomo> infinity: in a few years dbus will be integrated in glibc ;)
<tseng> infinity: alot of people use it simply to check for existing instances on startup
<Riddell> Mithrandir, Kamion: kubuntu alternate CD i386 installs fine, although my apostrophy key seems to have become a forward tick/acute accent key
<tseng> infinity: which is nice, but questionable if its worth the pain of current dbus
<infinity> tseng: That's vile.
<tseng> dbus is *almost* stable anyway
<tseng> hopefully edgy+1 will not suffer such pains
<slomo> infinity, tseng: apart from that libdbus is now guarantueed to be API/ABI stable for 1.0 (unfortunately not the bindings)
<tseng> the bindings arent that widely used
<infinity> tseng: I suspect that very few free software developers have done enough win32 development to learn from mistakes there, because it seems people used DDE as the same hammer for the same sort of nails on windows, and almost always with poor results in the end.
<infinity> tseng: Oh well.  I'll get over it, I suppose.
<Kamion> Riddell: I think there might be something wrong with kbd-choos4r
<mvo_> Kamion: dists/edgy/dist-upgrader/binary-all/ is fine as  a path on the cdrom for me as well, whatever you prefer
<Kamion> kbd-chooser
<tseng> infinity: "to dbus people, everything seems like a dbus problem" -- Keybuk 
<ogra> Kamion, did i understand you right yesterday, there is no metapackage update needed for the minimal change ?
<Kamion> ogra: not for you, no
<ogra> s/minimal/-minimal/
<ogra> good
<Kamion> ubuntu-minimal needs to change, but there is no edubuntu-minimal
<ogra> right, thats how i understood it
<tseng> infinity: its the underpinnings of great leaps forward like hal, so I can't cry about it at night
<ogra> its just that the update script still makes the change which is a bit irritating :)
<Kamion> ogra: try setting 'output_seeds: desktop live' in update.cfg
<ogra> ok
<Kamion> and then rm minimal* standard*
<ogra> oki
* infinity goes to make grilled chese sandwiches while adare churns away at slomo's uploads.
<ogra> hmm
<Keybuk> tseng: that wasn't a --Keybuk
* ogra tries to get a minimal dapper install going on a p133 with 64M
<tseng> Keybuk: pretty sure of it
<tseng> Keybuk: unless you've borrowed it
<Keybuk> tseng: I quote it, but the quote is Erik Troan
<tseng> oh, rpath
<Keybuk> when discussing upstart, he asked whether it was built using dbus
<Keybuk> I had to admit that I had no plans to do that
<Keybuk> which he considered a good thing
<ogra> how would that work ? 
<tseng> ogra: dbus-activation
<ogra> incorporating dbus code into init ? 
<Keybuk> ogra: init=/sbin/dbus
<ogra> *shudder*
<Keybuk> make it register everything as a service
<Keybuk> to start/stop something, you'd send it a message
<ogra> i thought you need to reboot if you change dbus services :P
<tseng> only upgrading dbus
<Keybuk> for this, and other nightmare scenarious, read Seth's/Fedora's "SystemServices" proposal
<thom> Keybuk: ye gods fedora are actually talking about that?
<infinity> thom: I't my experience (and I'm very grateful for it) that what Fedora contemplates and what they implement rarely relate.
<Keybuk> thom: no, I think they've stopped
<neuralis> Keybuk: who in the fedora camp has been discussing upstart with you?
<Hobbsee> Keybuk: https://launchpad.net/bugs/57478 is done now, FYI.  i thought i'd approved that a while ago.  feel free to do it with the next round of syncs.
<Ubugtu> Malone bug 57478 in lyx "Please sync xdg-utils and lyx-common from Debian" [Untriaged,Confirmed]  
<cbx33> hi guys
<cbx33> got a scenario to run past you.  working on something in edubuntu that requires me to run a an app as a nother user, who is not root, this is a graphical app that needs to run in my current session, I can be root if necessary...gksudo doesn't work
<cbx33> as the user doesn't have access to my xsession
<cbx33> and I want to keep it that way
<thom> Keybuk: that's pretty scary
<cbx33> I tried sux.....which worked great....just not in an LTSP environment
<cbx33> anyone got any better suggestions?
<cbx33> the only one we came up with was sshkeys
<cbx33> so i plant my public key in the users authoirsed keys
<cbx33> and that way I can run
<cbx33> ssh -X to the user@localhost
<cbx33> can anyone see a better solution?
<Mithrandir> Riddell: ok.  I guess you need new livefs-es and such and want to wait a little bit for the live one, though.
<infinity> Mithrandir: The dbus qorld rebuild is still ongoing, and affect kubuntu as well.
<Keybuk> neuralis: we haven't quite reached discussion yet
<Mithrandir> cbx33: xhost +SI:localuser:$username ?
<Riddell> Mithrandir: live was working too except for the issue I reported to kamion
<Mithrandir> Riddell: and the dbus rebuild, I presume.
<cbx33> Mithrandir, lemme try
<Keybuk> neuralis: Bill Nottingham, Jeremy Katz, Jesse Keating, "Rahul" and "Harald" are in the Cc list
<Riddell> Mithrandir: yes
<cbx33> Mithrandir, it would be preferable for the user not to have access to my X session
<Riddell> Kamion: how do I spot if the apt-setup fix is in?
<cbx33> do you think that is the only way to go....?
<Mithrandir> cbx33: well, you're really allowing the user access to your X session when you run an X based program as that user anyway.
<cbx33> well true
<infinity> cbx33: ssh -X is still allowing a user access to your session.
<cbx33> so are you suggesting add it run the app, then when the app closes take it away again?
<cbx33> infinity, again true
<cbx33> is vuntz around?
<Mithrandir> cbx33: yeah, that'd be useful.
<infinity> cbx33: You'd need to sandbox the app completely (say, in a VNC session, or other such insanity) to prevent that.
<cbx33> infinity, which is too much for this particular implementation
<cbx33> it's pessulus you see
<Mithrandir> cbx33: I guess one could implement a one-shot-cookie access control, but it wouldn't really help you much.
<Mithrandir> infinity: Xnest (or at least Xephyr) would work by itself.
<Mithrandir> (I'm less sure about Xnest than Xephyr, tbh)
<infinity> Mithrandir: I think xnest is safe, yeah.  Not positive.
<cbx33> basically it's for the Student Control Panel software
<cbx33> i need to run pessulus as the user themself....
<infinity> Mithrandir: I actually had "vnc or xnest" in my initial response, and backspaced over it cause I wasn't 100% sure. :)
<cbx33> because that way it will edit their own settings 
<cbx33> if you get my meaning
* Keybuk tries to work out why SIOCGIFCONF doesn't do what he expects
<Kamion> Riddell: look for the relevant versions of apt-setup or ubiquity in .list (alternate) or .manifest (desktop)
<vuntz> cbx33: pong
<cbx33> hi vuntz 
<cbx33> I'm currently implementing the Student Control Panel spec
<cbx33> and pygi mentioned you wrote pessulus?
<cbx33> which is on the list of things to implement :p
<vuntz> yes
<cbx33> well. if you are able to scroll up ^^
<cbx33> I need to run pessulus as a specific user
<cbx33> I wondered if you knew a way to do that
<cbx33> I've been using sux to achieve it...but for edubuntu that doesn't work on LTSP
<cbx33> any ideas?
<ogra> well, actually you want to run pessulus and apply the lockdown of gconf keys to a specific user ;)
<cbx33> well true
<vuntz> cbx33: does the specific user have specific gconf sources?
<ogra> there is probably a way where you dont need to run it as this user
<ogra> vuntz, yes
<vuntz> oh
<cbx33> ogra, true....I was just saying what I had tried thus far
<ogra> its a gnome multiuser setup
<vuntz> ogra: didn't we already have this discussion?
* vuntz has some memories of such as discussion :-)
<ogra> dunno, did we ? 
<ogra> i know jdub discussed it in person with me in paris
<cbx33> vuntz, did yo have a solution?
<ogra> and he said there is an opportunity to do it
<vuntz> iirc, I proposed to add a command line argument to pessulus to specify the gconf sources to use
<cbx33> vuntz, how much work is that :p
<vuntz> cbx33: shouldn't be too hard
<vuntz> assuming you only want to change the mandatory source, it should be about 10 lines of python
<cbx33> vuntz, possible before FF?
<jdong_> so will edgy cd's start working soon?
<cbx33> basically in SCP i have a context menu, so an admin can right clik on a username and hit lockdown
<vuntz> cbx33: when is the freeze?
<cbx33> which brings up pessulus for that user
<cbx33> sep 9???
<cbx33> am i right or wrong here?
<ogra> 7
<cbx33> 7th
<vuntz> lots of time to do it, then :-)
<cbx33> heheh
<cbx33> is it something yo uhave time to do
<cbx33> or do you want me to....try ?!
<cbx33> and send you a patch?
<vuntz> cbx33: you should really do it :-)
<cbx33> oh joy
<vuntz> look for GCONF_MANDATORY_SOURCE in pessulus
<cbx33> vuntz, ok
<vuntz> cbx33: replace it by a variable where it makes sense
<vuntz> and adds some command line parsing magic in main.py
<cbx33> ok
<cbx33> what are you envisaging for the command line parameter?
<vuntz> (if you could use GOption for the command line parsing, there's a bonus)
<cbx33> the actual path of the source
<cbx33> or the username ?
<vuntz> cbx33: the path
<cbx33> ok
<cbx33> vuntz, bearing in mind I'm still a python n00b !
<vuntz> cbx33: pessulus is good to learn :-)
<cbx33> heheh
<vuntz> (it was my first python project)
<cbx33> hehe
<cbx33> gISOMount was mine
<cbx33> it's in edgy
<cbx33> :D
<vuntz> cbx33: feel free to ping me if you need some help
<cbx33> thank you
<cbx33> I'll take a look now
<cbx33> I have about 2 hours
<cbx33> do you have a devel branch somewhere?
<cbx33> on LP?
<vuntz> cbx33: GNOME cvs
<cbx33> ah ok
* rouzic_ausente ha vuelto
<ogra> wow, i managed to get edubuntu to 700MB on the spot ...
* mvo cheers to ogra
<ogra> but installing dapper on a P133 with 64M is really no fun ...
<dholbach> edgy will be better ;)
<infinity> It will be?
<infinity> Are we shipping edgy with extra RAM in the CD sleeve?
<ogra> i managed to manually bootstrap it from the recue mode (instaler just dies if it needs to validate packages ) but now i cant install the kernel 
<dholbach> I'm trying to lift the morale :)
<infinity> It's never been my experience that new versions of operating systems consumer fewew resources. :)
<infinity> s/fewew/fewer/
<Kamion> dapper can install in less RAM than breezy, actually
<Kamion> but that's mostly just because I tweaked the lowmem limits. :)
<infinity> (Well, not entirely true.  I found Linux 2.4->2.6 to actually increase in speed on older hardware, with similar configurations... But when you toss an upgraded desktop environment around that, you lost the benefit)
<mvo> ogra: it would certainly help you would not run the install in a gnome-terminal ;)
<Kamion> and of course that's only for the alternate CD
<infinity> Yeah.
<ogra> mvo, ah, right, you mean i shouldnt use the desktop CD ?
<Kamion> ! don't use the desktop CD to install in 64M
<bddebian> Howdy folks
<mvo> ogra: exactly :P
<ogra> Kamion, haha
<janimo> ogra: this reminds me: what happened with the xfce edubuntu spec? No space on CD?
<infinity> Kamion: Is smarenka still working on lowmem stuff in d-i during the etch cycle, or did he give up the fight after sarge released?
<Kamion> the alternate CD should be able to handle down to 32M
<ogra> Kamion, as if that woud even boot :)
<ogra> *would
<Kamion> infinity: don't know - I think he's done the odd bit, not sure
<Keybuk> janimo: yeah, edubuntu *really* needs a third desktop environment on its CDs :p
<ogra> janimo, i'm happy i just got them down to exactly 700M
<ogra> Keybuk, well, there is a huge user demand for xfce in low end ltsp setups
<infinity> ogra: Exactly, to the last byte?
<janimo> Keybuk: it doesn't but deployment may really need on DE that allows them to server twice as many thin clients from the same server
<infinity> ogra: Cause that'll surely explode on you after this publisher run, then.  No one can be that lucky. :)
<ogra> i didnt look at the last byte yet ... cdimage shows 700
<Keybuk> ogra: it strikes me that at some point, the effort of converting the existing KDE apps to be GTK+ apps may be worthwhile
<ogra> Keybuk, thats in the works ;)
<ogra> there is a team of edubuntu users rewriting kalzium ... which is the only reason to have kdeedu
<janimo> ogra: you don't have kgeography or other kdeedu apps?
<Kamion> you still have lots of other kde applications in the seeds
<ogra> janimo, we have abut 5-10 kdeedu apps ... 
<ogra> but all of them would have gnome pendants or are easy to rewrite 
<ogra> apart from kalzium
<Kamion> $ wget -q -O - http://people.ubuntu.com/~cjwatson/germinate-output/edubuntu-edgy/desktop | grep -c 'kdeedu.*desktop seed'
<Kamion> 14
<Chipzz> ogra: why rewrite them?
<ogra> ok, let it be 14 ... still ...
<ogra> Chipzz, do you have a better opportunity ? 
<Kamion> Chipzz: having to have the KDE libraries on the CD takes up a lot of space
<Chipzz> ogra: given what I think of kde I have nothing against it
<Chipzz> just seems like a lot of work?
<ogra> Chipzz, gaiing 50-100M on the iso is worth it 
<ogra> *ganing
<ogra> grmbl
<Chipzz> yea I know what you meant ;)
<ogra> heh :)
<Chipzz> with the typo I mean ;)
<Chipzz> what are they going to be rewritten in? pygtk?
<ogra> my problem is that ubuntu fils up its own CDs to the limit ... i have to put stuff on top but dont want to cripple the desktop to much ... 
<Chipzz> Kamion: btw, my ssh issue from earlier disappeared when my uplink got less congested
<ogra> the kalzium thingie is pygtk/cairo
<janimo> dholbach: you know if bug-buddy is still active or apport replaces it completely?
<Chipzz> ogra: finally having a decent gnome-office and not having to put up with openoffice would be a big improvement too I guess
<ogra> Chipzz, oo.o would be the last thing i'd drop in a school environment
<Chipzz> abiword and gnumeric are fine replacements IMHO
<ogra> then i'd rather ask iwj for his desktop setup configs and go with fvwm
<Chipzz> but that's a matter of taste I guess
<ogra> its not about replacements or shiny apps ...
<Chipzz> but I'm getting off-topic and keeping you from doing your job ;)
<ogra> in schools we need to cope with free windows ...
<ogra> well, my job is rather waiting for LP today ...
<Chipzz> but getting into a pointless discussion with me is a waste of time too I guess ;)
<slomo> infinity: stuff likes to FTBFS on !i386 now because of broken build-deps :(
<infinity> slomo: I know.  Just bear with me.
<infinity> slomo: I'll resolve it all in time.
<sivang> spoken like a true god :p
<slomo> infinity: thanks, you rock :)
<ogra> what the heck does ndiswrapper do in powerpc ? 
<sivang> hi slomo 
<ogra> s/in/on/
<infinity> ogra: Not much.
<jdong> ha
<ogra> well, it braks my ppc iso :)
<slomo> Riddell: and kdegames FTBFS now because of "/usr/include/kde/kconfigbackend.h:256: error: 'KLocale' has not been declared". any idea what could've broken this lately?
<ogra> *breaks
<bluefoxicy> oh well time to reclaim memory.  Killing the most memory-intensive process running:    796 root      15   0  367m 156m 137m S  0.0 16.5   1:38.67 synaptic
<mvo> bluefoxicy: *ick* 
<mvo> bluefoxicy: for how long is this runing? 
<bluefoxicy> mvo: 3 or 4 days
<bluefoxicy> synaptic bloated more than Firefox, amusingly.
<infinity> You had synaptic running for 4 days?
<mvo> bluefoxicy: I blame memleaks in libapt 
<Riddell> slomo: hmm, my desktop-locale stuff could have but I doubt it
<glatzor> slomo: hi. you have killed my music player: #58225
<infinity> That's an odd use case.
<bluefoxicy> 30147 bluefox   15   0  215m 117m  18m S  0.0 12.4  29:37.26 mozilla-thunder  <-- 5 days
<Riddell> slomo: let me try a compile
<mvo> bluefoxicy: but yeah, its pretty ugly and needs fixing
<slomo> glatzor: cool... i'll take a look at it but it works fine here
<bluefoxicy> infinity: I tend to leave it open and reload every so often when there's an obvious bug or when I'm waiting for an update.
<bluefoxicy> in this case, I was waiting for pax-utils, which has finally hit universe.
<glatzor> slomo: perhaps another powerpc only issue.
* bluefoxicy wonders about pax-utils
<bluefoxicy> solar hasn't released another version; he's got some new features but he doesn't want to release them because they let the end user destroy shit badly
<bluefoxicy> mvo:  how many apport's you got running?
<bluefoxicy> or did you not install that?
<ogra> oh, wow, dapper boots with 2.4.17
<infinity> ONly on i386.
<jdong> ogra: huh? udev?
<ogra> right
<infinity> On all other arches, glibc won't work with << 2.6
<mvo> bluefoxicy: it is installed, but I doN't have one runing
<ogra> jdong, i havent wiped the mbr yet ... :)
<infinity> (Which will be true for i386 on edgy as well)
<jdong> interesting
<ogra> and was to slow to plug in the sbm floppie
<Riddell> slomo: confirmed, it is my fault, Ill upload a new kdelibs to fix
<Riddell> and Ill reupload kdegames
<Riddell> Mithrandir ^^
<slomo> Riddell: ok, thanks :)
<slomo> hi sivang :)
<bluefoxicy> mvo:  okay; I have 14 running.
<geser> can someone explain me what the amd64 debs for cantlr and libantlr-dev are doing in http://archive.ubuntu.com/ubuntu/pool/universe/p/python-smbpasswd/ ?
<geser> libantlr-dev for amd64 is also in http://archive.ubuntu.com/ubuntu/pool/main/p/python-smbpasswd/
<mvo> bluefoxicy: pitti (when he is back) may be interessted to hear this
<infinity> geser: Just hanging' out, I guess.
<geser> the other packages from antlr are in the right directory
<infinity> geser: (curious)
<geser> these dirs are also in the packages file for amd64/egdy: Filename: pool/universe/p/python-smbpasswd/cantlr_2.7.6-6ubuntu1_amd64.deb
<slomo> Mithrandir: libdbus-glib-1-dev is missing a replaces which breaks upgrades... are you fine with uploading?
<infinity> geser: Yeah, the packages file just reports on the on-disk structure, so that makes sense.
<dholbach> janimo: there are plans, but atm apport will do one part, bug-buddy the other
<dholbach> janimo: s/atm/for edgy
<janimo> dholbach: ok. I was wondering whether gnome_program_init is less useful but if b-b is still used then no
<dholbach> I'm currently not quite sure about all the implications
<infinity> geser: Team Soyuz is on it.  Thanks for the heads-up.
<Simira> ogra: power manager messes up my system
<Sp4rKy> hi
* jdong_ finds it amusing that RHEL4 update 4 adds gcc 4.1, but not python 2.4 :(
<slomo> Mithrandir: libdbus-glib-1-dev is missing a replaces which breaks upgrades... are you fine with uploading?
<infinity> Mithrandir: A kernel upload right now would make you very upset, right?
<Keybuk> hmm, wow
* BenC lives to make Mith's work harder
<Keybuk> whatever I'm doing is _really_ upsetting X
<Simira> Mithrandir's out, back in two hours or so
<Simira> Keybuk: couldn't be related to my desktop freezing and a lot of disc/swap activity?
<Keybuk> Simira: not unless you're running upstart
<Simira> not that I know of
<jdub> in edgy boot process, upstart runs you!
<Keybuk> it seems that I'm doing something to /dev/console that's making the running X server crash
<Keybuk> which is quite clever
<_ion> Hehe.
<Keybuk> the trouble is, all I think I'm doing is "echo foo > /dev/console"
<infinity> Simira: Care to phone or SMS him and ask if he'd kill BenC for uploading a new kernel? :)
<bddebian> doko: ping?
<BenC> infinity: this is sort of tricky...I mean it wouldn't be the end of the world if I don't upload
<doko> bddebian: pong
<Kamion> what are the changes?
<BenC> Kamion: huge
<Kamion> that doesn't sound immediately appealing
<Keybuk> "That's the second-biggest Kernel Upload I've ever seen!"
<BenC> the 686/k7 -> generic name changes
<Kamion> eek
<Kamion> that needs installer changes
<bddebian> doko: Do you have any suggestions for azureus? It looks like you made some fairly significant changes.
<BenC> my problem is that the kernel in Knot-1 isn't much different than what's in the archive right now
<Kamion> and livefs build script changes I guess
<BenC> so most ppl's problems wont be fixed from the last one
<Kamion> is it possible to back out the intrusive packaging changes temporarily?
<doko> bddebian: don't take the Debian package, please look at the fedora one. debian's is in contrib, so we cannot put it in main
* jdong_ hugs bddebian for remembering azureus :)
<BenC> Kamion: not really
<infinity> Kamion: The livefs change is simple enough.
<BenC> I have lrm, linux-meta and kernel source with this name change ready to upload
<Kamion> all the consequent changes are simple enough, there are just quite a few of them and I'm not convinced I can remember them all
<Kamion> and we'll have to basically rebuild everything from the ground up
<BenC> well, lrm is almost ready, I have to remerge from infinity's uploads :)
<bddebian> doko: Its not in main now
<infinity> Kamion: We're still rebuilding the world for the dbus crap anyway.  My only concern here is the delay required to build the kernels.
<BenC> when is knot-2 supposed to be released again?
<doko> bddebian: sorry, universe; but contrib would be multiverse
<Simira> infinity: sure
<Keybuk> BenC: tomorrow
<Kamion> yeah, but the world there wasn't supposed to include say debian-installer
<bddebian> doko: Aye.  Hmm
<BenC> ick, it would delay it to probably Friday night at best
<infinity> BenC: Best to skip the kernel uploads, then?
<Kamion> doko: we have discretion on that if the Debian package is contrib for reasons that don't apply to us
<Kamion> e.g. dependencies that we've moved to main/universe
<infinity> BenC: If you upload right after knot-2, that gives you a couple of weeks to iron out wrinkles and pray for a really solid kernel on knot-3. :)
<Simira> infinity: he says go
<BenC> probably best
<infinity> Simira: Heh, and we seem to have just said "no". :)
<Simira> just don't break anything
<Simira> ;)
<BenC> I'd hate to make this upload, and then something be broken that I didn't forsee, and end up delaying knot-2 for 3-4 days or something
<Simira> BenC: if you can wait till after knot release, I am sure he'll appreciate
<BenC> Simira: as usual, I can't guarantee non-breakage :)
<Simira> BenC: what is it with you guys and breaking things...?
<BenC> infinity: I don't suppose there's a way to have the kernel uploaded and staged somewhere is there?
<jdub> Simira: EDGY!!!111
<BenC> otherwise for the next two days I am going to feel the need to break^Wwork on it more
<Kamion> BenC: dump it on chinstrap?
<Kamion> then it can be uploaded right afterwards
<BenC> Simira: the kernel's job is to find hardware bugs, which may, on occasion require us to implement non-standard code into the cpu/hardware in order to flush out these bugs
<doko> Kamion: but it doesn't build using main/universe tools. and doesn't run using main/universe tools as provided in unstable
<Kamion> doko: ok, then it's not so much that the Debian package is contrib, but that when built on Ubuntu that package has to be multiverse :-)
<infinity> BenC: Yeah, just upload it to chinstrap (signed, even), and any one of us can plonk it on drescher when the release is out.
<Kamion> doko: I thought you were saying that any package synced from Debian contrib had to stay in multiverse.
<BenC> infinity: Ok, I'll have linux-source+lrm+linux-meta on there by the end of the day, and email you
<BenC> thanks
<infinity> BenC: Cool.
<doko> Kamion: no, not the latter
<doko> bddebian: if you do want to give it a try, let me know. the fedora patches are online as well.
<bddebian> doko: Up to you.  I'm happy to try
<jdub> (yay, fglrx works again)
<Seveas> mjg59, you around?
<Surak> BenC: ping
<mjg59> Seveas: Hi
<doko> bddebian: I'll send you some URL's tonight
<Seveas> mjg59, will usplash on ppc do $something_better_than_640x400x16 for edgy
<bddebian> doko: OK, thx
<doko> away for the next hour
<Seveas> I've ripped out run-length encoding and made pngtobogl do 256 color images, which works fine on 386 but ppc still uses bogl
<mjg59> Seveas: If someone writes the code, sure
<Seveas> mjg59, I would if I could but have no ppc to test 
<mjg59> Seveas: It ought to be trivial to make bogl write a 256 colour value to the framebuffer
<Seveas> mjg59, but it'd still be 640x400, right?
<mjg59> Seveas: That's just a matter of adding a modesetting call
<mjg59> ppc has proper framebuffers
<Seveas> right...
* Seveas goes ppc hunting
<Seveas> anyway, I'll upload my branch to launchpad later today so you can merge at least this part
<Seveas> (or the parts of it you like)
<Kamion> you probably want to just use the mode the framebuffer starts up in
<Kamion> I think that's generally reasonable
<Kamion> at present the powerpc code in usplash deliberately centres the image on the screen
<Kamion> (at least it did when I last wrote any of it)
<Kamion> all you need to do is just use a bigger image instead
<Seveas> sounds reasonable, but I don't want to touch the code with a 10-foot pole if I can't test it
<Kamion> usplash is doing bogl_init() failed for me at present, so ...
<Kamion> I assumed somebody broke it but haven't got round to figuring out why
<Kamion> today IIRC it complained about /dev/fb0 not being there; could just be a module loading issue
<Seveas> Kamion, you can test it while running (at least on x86) by running sudo usplash -c -- /dev/fb0 should be there post-boot
<Kamion> true, but not while I'm in the middle of taking gparted apart. :)
<Seveas> fair enough ;)
<nanday> Sorry for barging in. I'm a Newsforge writer, researching a story. Would anyone be willing to comment publicly on the civility on Ubuntu's forums and Ubuntu's sense of direction compared to Debian's?
<LaserJock> heh
<Burgwork> LaserJock, hmm, nice can of worms
<LaserJock> yep
<mjg59> Seveas: We don't autoload framebuffer drivers now
<mjg59> Oh, on ppc
<mjg59> Right, sorry
<dholbach> nanday: you can always try info@ubuntu.com
<sbalneav> LaserJock: I installed the 25edubuntu-menus thing you pasted yesterday.  Worked like a charm.
<Burgwork> dholbach, you want this to go to somebody official or should I cover it?
<Burgwork> dholbach, also, nanday is in the same timezone as myself
<LaserJock> sbalneav: excellent
<dholbach> Burgwork: he wants somebody to comment s
<nanday> Burgwork, the occasion is Matthew Garrett's resignation from Debian: 
<dholbach> Burgwork: he wants somebody to comment publicly, so I thought that somebody of the management would better do it
<nanday> http://mjg59.livejournal.com/66647.html
<Burgwork> dholbach, indeed. Light touch needed
<Surak> hum. Bug #20943 and bug #55104 looks the same. And I confirmed the latter on every 2.6-based linux version I put my hands on
<Ubugtu> Malone bug 20943 in linux-source-2.6.15 "module insertion hangs in apic/irq setup" [Medium,Confirmed]  http://launchpad.net/bugs/20943
<Ubugtu> Malone bug 55104 in linux-source-2.6.15 "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  http://launchpad.net/bugs/55104
<nanday> if anyone does care to respond publicly, I can stress that it's not the official opinion of Ubuntu.
<infinity> nanday: You may note that it's rather entertaining to discuss mjg59 in the third person when he's not only in this channel, but was actively participating 15 lines above.
<nanday> infinity, yep.
<Burgwork> nanday, basically, it boils down to I don't feel comfortable making any statements about those topics because I don't work for canonical. So you need to grab Mark/Jane/somebody else in Canonical's london office.
<nanday> Burgwork, fair enough. I can hope, but I won't pry.
<desrt> Burgwork; so have you thought any more?
<Burgwork> desrt, sorry?
<desrt> mentorship
<tseng> nanday: I would like someone else to back this up, but I also don't believe that the "civility of the forums" is directly linked to ubuntu or canonical
<desrt> tseng; word.
<Burgwork> what sort of mentorship?
<tseng> desrt: yo
<desrt> Burgwork; the thing i blogged about
<desrt> Burgwork; you said that you were the sort of person who could get the ball rolling on something :)
<Burgwork> right, not had a chance to think about it
<nanday> tseng, can you expand a little?
<Burgwork> let me do that lunch today
<desrt> just a friendly nudge :)
<tseng> nanday: I think canonical might provide hosting, but it isnt run by Canonical
<tseng> nanday: some forum leadership happens to be ubuntu members, not all
<LaserJock> the forums have their own admins and moderators
<tseng> nanday: its somewhat disconnected
<tseng> nanday: (And definately has 0 connection to mjg59 leaving Debian)
<LaserJock> but I think they still try to abide by the CoC
<jdong_> LaserJock: the CoC is strictly enforced at the forums
<Kamion> I think it depends whether you mean forums as in ubuntuforums.org or in the more general sense of places for Ubuntu discussion
<Kamion> (including IRC and mailing lists)
<LaserJock> ah, true
<LaserJock> I would say though that the CoC is still the common denominator with pretty much all communication in Ubuntu
<Kamion> most people answering seem to have assumed the former, but that's basically jargon
<jdong_> is the forum to blame for the mjg59 situation or something?
<tseng> its jargon with a specific meaning to most linux people
<Kamion> jdong_: it's got nothing to do with it
<jdong_> k, whew
<Burgwork> jdong_, I don't know how the two questions are connected. nanday ?
* jdong_ is still pretty swamped/backlogged with forums<->canonical dealings :-/
<Burgwork> nanday, generally I have found the forums to be very civil
<jdong_> we try very hard to keep the forums civil
<tseng> Burgwork: something to do with more civility in the forums having something to do with a departure from Debian
<nanday> so, it's more or less a reaction to Debian?
<Burgwork> tseng, ah, ubuntu is a more civil place in general? hmm, no idea
<tseng> nanday: a personal decision by one person based on events in debian, clearly spelled out
<dholbach> nanday: what do you mean?
<tseng> nanday: the references to ubuntu was tangential
<nanday> tseng, yes.
<nanday> but he's not the only one to make a similar comparison.
<tseng> nanday: it seems like jdong_ can point you to some ubuntuforums.org people if you did indeed mean 'those forums' and want to continue making such a connection
<jdong_> I'm an admin at the forums, and I'd be glad to clarify any questions regarding the forums
<jdong_> or put you in contact with someone who can
<tseng> I personally don't see any news here.
<nanday> jdong, I'd be interested in hearing if you take any particular steps to keep civililty. But maybe we should take this off the channel?
<jdong_> nanday: what do you mean by keep civility?
<jdong_> we have a large staff of moderators making sure users abide by the CoC
<tseng> (Code of Conduct)
<tseng> http://www.ubuntu.com/community/conduct
<nanday> jdong, maybe the moderators and CoC explain it.
<nanday> tseng, thanks.
<tseng> officially regognized members are required to 'sign' this
<jdong_> we do step in and take action when conversations start becoming rude or disrespectful
<tseng> everyone else is expected to comply in good faith
<tseng> and it mostly works, so far
<jdong_> for the most part, people are very courteous even without our intervention
<jdong_> but there are a handful that need us to remind them to be nice :)
<nanday> ok, that helps to give me some perspective.
<nanday> thanks for taking the time to talk.
<jdong_> no problem
<jdong_> stop by the forums or e-mail me at jdong@ubuntu.com if you have any further questions
<tseng> nanday: of most importance besides good faith "be nice"
<tseng> nanday: note that technical matters are taken to the Tech Board for a discussion and ruling, as opposed to people duking it out on the mailing lists
<tseng> (which still happens, sometimes)
<Kamion> *ahem* zeroconf
<nanday> tseng, good point. 
<tseng> community council is an escalation point for non-tech issues
<Kamion> it takes a while to get to the techboard sometimes ;)
<tseng> crucial points.
<Kamion> but, shrug, you don't want to go to a committee straight away, it gets too bureaucratic
<tseng> of course not, most things can be worked out civily
<tseng> just not $shiny_apple_protocol
<Mithrandir> Kamion: to be fair, the zeroconf disucssion, while lively and big was for the biggest part on-topic, civil and somewhat useful.  At least I think it didn't evolve into a flamewar.
<tseng> Mithrandir: alot of repeition ad naseum, but it was certainly civil
<tseng> same with mono / "zomg i only have 256mb ram"
<Mithrandir> tseng: yeah, hence my "for the biggest part".
<jdong_> Mithrandir: is there any plans to update opera in dapper-commercial?
<jdong_> I was told you were the go-to guy on that
<Mithrandir> jdong_: I uploaded the previous package.  I could always poke my contacts in opera and ask for an update.
<nanday> thanks, everyone. Much appreciated. I'm off.
<jdong_> Mithrandir: that'd be wonderful
<jdong_> people have been bugging me about 9.01
<jdong_> of course, I'm the one who gets bugged whenever something is out of date :(
<Mithrandir> heh
<jdong_> but this one is out of my domain :)
<Mithrandir> jdong_: please drop me a mail about it so I don't forget.
<jdong_> will do
* rouzic se ha ido
* rouzic_ausente ha vuelto, alegrate
<sbalneav> Mithrandir: Are you one of the people on the X.Org swat team?
<Mithrandir> sbalneav: depends. :-P
<Mithrandir> sbalneav: any particular issue which is biting you?
<sbalneav> There's a new series of thin client hardware coming out, that requires some patches to x.org.  What would the cutoff be to have them considered for inclusion?
<zyga> did anyone notice the corrupted virtual console on ati hardware with current edgy kernel?
<tseng> zyga: yes
<zyga> tseng: oh, k
<tseng> old nvidia too
<tseng> 2/3 of my systems have it
<zyga> cool effect, while irritating
<zyga> ;-)
<Mithrandir> sbalneav: hmm,  The earlier the better, naturally.
<jammcq_laptop> Mithrandir: is there a hard cutoff ?
<Mithrandir> sbalneav: new drivers or just patches to old ones?
<Mithrandir> jammcq_laptop: "release" is fairly hard. :-P
<tseng> jammcq_laptop: the hard cut off has come and gone
* jammcq_laptop thinks it's just a patch to the existing via driver, but i'm still trying to confirm that
<tseng> jammcq_laptop: there are always exceptions, with increasing difficulty
<jdub> hey duderinos
<tseng> hello jdub 
<Mithrandir> sbalneav: it should be quite doable to get it in if you have it by betafreeze.
<sbalneav> That's by second week of Sepember?
<sbalneav> err September?
<Mithrandir> betafreeze is Sep 21st.
<sbalneav> Perfect!  
<sbalneav> You, sir, deserve a beer.
<Mithrandir> sbalneav: though, you probably rather want to talk to rodarvus, he's the X driver guy.  I generally rather touch libs and apps and other crazy !server stuff.
* sbalneav slides one to Mithrandir
<Mithrandir> mm, beer.
<sbalneav> Ah, rodarvus! Perfect!
<sbalneav> Thanks muchly
<jammcq_laptop> Mithrandir: is the 'Unichrome' driver part of edgy's Xorg ?
<jammcq_laptop> or maybe it's a Unichrome patch to the 'via' driver
<Mithrandir> jammcq_laptop: UTSL; I'm not familiar with the via driver at all.
<jammcq_laptop> k
<rodarvus> sbalneav, hi :)
<jammcq_laptop> we'll bug rodarvus about it
<jammcq_laptop> tanks for your help
<rodarvus> sure, just hand me the patch(es) and I'll take a look at it(them)
<sbalneav> hey rodarvus!
<sbalneav> Yep, you'll be hearing from us! :)
<rodarvus> good! :)
<jammcq_laptop> rodarvus: it'll prolly take me a week or 2 to get it all figured out, to send something to you
<rodarvus> jammcq_laptop, sure, no problem.
<rodarvus> jammcq_laptop, afaik, the unichrome stuff is part of the via driver, yes
<jammcq_laptop> rodarvus: it is entirely possible that the version of Xorg in edgy already works with this thin client.  I'll dig into that soon
<rodarvus> (but I might be wrong)
<rodarvus> just for reference, I don't think the via driver has changed *so much* since dapper (even upstream -> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-via.git;a=summary)
<rodarvus> we have version 0.2.1, without any extra patches
<bluefoxicy> Is anyone interested in compressed memory?
<bluefoxicy> i.e. memory pressure compresses stuff, then extra memory pressure sends it to swap, possibly avoiding some I/O (the CPU-bound problem is shorter than the I/O-bound problem)
<jdong_> bluefoxicy: how on earth do you compress RAM
<bluefoxicy> Nitan's 2.6 patch is almost ready but he thinks it's too much work to get it into mainline; I've recommended he get it working and do some performance measurements and then try to convince a major distribution to use it as backing to convince mainline to take it
<mjg59> bluefoxicy: It's being looked at for OLPC
<jdong_> that would be a cool concept
<bluefoxicy> jdong_: when memory pressure is heavy normally pages are sent to swap.  This involves a few bits of disk access, seeking back and forth, writing data; then later some seeking and reading again to get it back.
<jdong_> right
<bluefoxicy> the compressed memory project takes the pages going to swap and compresses them
<mjg59> bluefoxicy: Of course, while it avoids writes to swap, it also reduces the size of available RAM
<bluefoxicy> when memory pressure gets tighter, it pushes those pages out to swap
<jdong_> oh, I see
<mjg59> So you end up compressing more stuff than you would otherwise have pushed out to disk
<bluefoxicy> mjg59:  of course, there is an effective limit and also memory access patterns affect it.
<mjg59> I can imagine it being a win under some workloads and a loss under others
<mjg59> But I would certainly be interested in the effect it would have on swapless systems
<bluefoxicy> mjg59: you compress least recently used memory; in many cases this memory goes to disk and stays there for a long time.  If you have a gig of ram, you may push 400 megs to swap, have 300 megs of disk cache.
<mjg59> Where it would be preferable to push some running code out to compressed storage in order to keep more cache
<mjg59> bluefoxicy: LRU memory or LRU working set?
<mjg59> bluefoxicy: IE, does it discard caches before compressing anything?
<bluefoxicy> You may find that over the course of days, you have 700 megs of working set in RAM and 400 megs on swap, and the 400 megs for the most part stays there.
<bluefoxicy> mjg59:  I'm not sure.  There is a lot of research behind it, Nitan is at least the third person in line
<bluefoxicy> Rodrigo was the second (it was his master's dissertation); and he got the idea from Wilson and Kaplan, who also did it for their Ph.D. dissertaitions IIRC
<mjg59> I can certainly see "discarding" some running apps in favour of cache as being advantageous for the live cd, for instance
<bluefoxicy> mjg59:  yes, it'd be great for the livecd
<zyga> re
<mjg59> bluefoxicy: It's going to be too late for edgy, but do encourage him to bring it up on -devel
<zyga> I don't think it's safe to turn it on by default without lots of testing
<zyga> hello lucas
<lucas> hello zyga 
<zyga> mvo_: do you agree?
<mjg59> Playing with it early in the edgy+1 cycle (perhaps at one of the developer conferences) would be good
<bluefoxicy> mjg59:  it's going to be late for edgy definitely; but I don't want to see the work die again.
<mjg59> We can easily produce two CD images, one with this and one without
<bluefoxicy> Rodrigo did it in 2.4.19 and it never went in, even though it worked rather well.
<mjg59> And then see how they perform on different machines
<bluefoxicy> two CDs are not needed.
<bluefoxicy> Nitan took a different route from Castro; he's made a kernel module.
<mvo_> zyga: we could try to raise more interesst in it, my latest bash upload should make it a matter of "apt-get install command-not-found" to activate it
<bluefoxicy> "Compression structure (as desc. later in this page) has been implemented as separate kernel module (and also merged with main compressed caching code)."
<zyga> mvo_: it's on by default after installing?
<mvo_> zyga: maybe someone could blog about it? this seems to be the best way to raise interesst these days
<mvo_> zyga: yes
<zyga> mvo_: maybe someone on planet.ubuntu?
<zyga> how about you? :)
<bluefoxicy> mjg59:  you can use a boot time option to load/not load the module when it comes to it :)
<zyga> I lost my blog a few days ago after forgetting to backup /var/lib before format :/
<mvo_> zyga: yes
<mvo_> zyga: eh ...
<mvo_> zyga: I don't habe a blog
<mvo_> zyga: maybe dholbach
<slomo> infinity: some give-backs for you :) gnome-applets (ppc) and evolution-exchange (!i386) for now
<thom> mvo_: searching Contents files for apt autocompletion?
<mjg59> bluefoxicy: Ok, makes life even easier
<zyga> dholbach: would you? do you think it's a good idea?
<bluefoxicy> http://linuxcompressed.sourceforge.net/linux24-cc/statistics/index.html  Here's the old stats on the 2.4 patch
<mvo_> thom: if a command in bash is not found, it will do a db search for binaries that might be available but are not installed. but it will not install anything automatically :)
<bluefoxicy> Rodrigo let Nitan have http://linuxcompressed.sourceforge.net/ too
<dholbach> zyga: i can't update planet, just a sec
<dholbach> zyga: https://wiki.ubuntu.com/PlanetUbuntu
<zyga> dholbach: oh, you can just be a member these days!
<zyga> cool
<zyga> I'll look into it, thanks
<thom> mvo_: ah. auto-apt, the revenge?
<zyga> thom, interesting - was auto apt fast?
<bluefoxicy> mjg59:  eyeballing some of the stats, looking at http://linuxcompressed.sourceforge.net/linux24-cc/statistics/0.24pre6_kernel/ and http://linuxcompressed.sourceforge.net/linux24-cc/statistics/0.24pre6_mummer/
* mvo__ kicks his wlan card and grumbles that his other one (zd1211) is not working with 2.6.17
<bluefoxicy> mjg59:  I know kernel compilation takes very little memory (as in a few tens, not 500 megs); it looks like as memory gets tighter the benefits are more and more substantial, while when memory is ample the cost/benefit ratio is almost 1:1 (you don't gain, but you don't lose either)
<thom> zyga: i can't honestly say i ever got auto-apt to play ball
* zyga knows how mvo_ feels now 
<thom> i didn't try very hard, mind :-)
<zyga> thom: try cnf from time to time, it's handy IMO
<thom> zyga: i'd have to use bash then ;-)
<bluefoxicy> as they do more parallel builds (-j2 and -j4) memory requirements go up and the cost/benefit stays higher for higher amounts of memory.  The second one (MUMmer scientific application) needs a LOT of memory and has a high benefit even with hundreds of megs of memory.
<thom> might see if i can find the spare time to hook up zsh
<zyga> thom: true, what do you use?
<zyga> that was my other question
<zyga> can zsh be hooked up easily?
<thom> i'd imagine so
<bluefoxicy> mjg59:  I'll send something to -devel later tonight with conjecture of impact based on the old benchmarks.
<mvo__> thom: I would be happy to have patches for zsh :)
<thom> we'll see :-)
<zyga> dholbach: hmm, my pubkey was denied any ideas? I have my key in launchpad so I don't have any
<dholbach> zyga: no idea at all
<Simira> dholbach: I have reserved a Danish-Swedish farm-dog (? it's called something like that), born August 19th.
<dholbach> wow!
<dholbach> when do you get it?
<thom> mvo__: on the random hacking states https for apt is rather higher on the priority list :-)
<Simira> dholbach: the one with light brown on the lowest middle pic is the mother: http://www.rdsg.no/Bilde14.htm
<Simira> dholbach: about Oct 13th
<mvo__> thom: agreed
<dholbach> Simira: nice :-)
* dholbach hugs Simira
<thom> should this kernel happen to work i can actually spend some time on that
<Simira> dholbach: not it. Him. The mother's name is Lilo, Tollef wants to call him Grub :p
<dholbach> haha
<Mithrandir> og silo og isolinux or maybe pxe?
<Simira> s/og/or
<Mithrandir> I can't type, you know that.
<Simira> I'm not convinced
<Simira> about the names
<thom> just use pwgen and stick with tradition :P
<Simira> no way
<Mithrandir> thom: I think she'd kill me if I did that.
<Mithrandir> or throw me out or something.
<thom> the _dog_ won't know :-)
<Simira> thom: I will know
<dholbach> have a nice evening
<Mithrandir> thom: well, I have to live with Karianne, so I better stick with something she can live with.  And it'll be her dog, not mine.  Especially on the days when it's hailing, etc.
<Simira> good night, dholbach 
<dholbach> bye Simira
<thom> *g*
<thom> night daniel!
<Mithrandir> good night, dholbach 
<OddAbe19> is the "gnome-panel using 100 cpu" bug fixed yet?
<dholbach> bye Thom, bye Tollef
<OddAbe19> is the "gnome-panel using 100 cpu" bug fixed yet?
<thom> please don't repeat questions
<ogra> Keybuk, what was the driver you used for the PCI wlan card we bought ? 
<ogra> (i dont even see it in lspci here)
<lifeless> BenC: ping
<BenC> lifeless: pong
<lifeless> hi
<lifeless> I'm going to skip my little tale of trauma from last night, and just ask - can we please get dm-bbr support put back into the dapper kernels ?
<lifeless> I dont know when it went away, but its lack is rather unfortunate - for me at least
<jdong|coreduo> lifeless: +1
* jdong|coreduo has asked for it before but didn't make dapper
<lifeless> in other news, building a custom tweaked kernel was hugely painless [except for my laptop being too puny] , so thanks heaps for everything done there
<sharms> mako: ping
<lifeless> jdong|coreduo: well it was in before dapper
<Burgwork> sharms, *laugh*. Good luck. Probably easier to mail him
<BenC> lifeless: dm-bbr?
<jdong|coreduo> lifeless: right; it disappeared at dapper....
<lifeless> jdong|coreduo: so it had to come out at some point. I know it was in because I setup my evms config *with* dm-bbr during the beta period
<jdong|coreduo> BenC: device-mapper's bad block relocator
<lifeless> BenC: do an apt-get source evms
<BenC> was that an external patch?
<jdong|coreduo> BenC: it's a part of evms
<lifeless> BenC: look in kernel/2.6/
<jdong|coreduo> at least upstream evms :-/
<lifeless> jdong|coreduo: its in the dapper evms package
<lifeless> BenC: yes, its an external patch.
<jdong|coreduo> BenC: it's pretty important since nowadays filesystem devs aren't thinking bad blocks are their problem anymore
<lifeless> in fact, as a module, evms could supply the thing
<jdong|coreduo> lifeless: I don't think the kernel module system ubuntu uses works that way
<jdong|coreduo> but then again, BenC is the expert on that
<BenC> lifeless: it would have to have one for each kernel flavour
<lifeless> BenC: well, what ever is easiest for you. For me - I have a disk partition config here that needs it, which I built using dapper's betas.
<jdong|coreduo> BenC: I got some bad hard drives I'd like to use again :)
<lifeless> so, if we can get it into dapper updates, it will save me a world of pain
<lifeless> and it sounds like jdong|coreduo wishes for it too
<jdong|coreduo> :)
<BenC> patch applied cleanly
<BenC> I guess I can add it in with dapper since it doesn't touch any other code
<jdong|coreduo> wow, today's a REALLY good day
<jdong|coreduo> and it's not just the vicodin that makes me say that
<lifeless> BenC: I built a kernel image with it myself last night, as a module, and it let me boot without error [well, it wasn't in the initramfs, but that I know how to fix] 
<lifeless> BenC: thank you !very! much
<jdong|coreduo> grr, gedit-dev...... gedit_-dev_? what the hell is gedit-dev....
<LaserJock> what's the default python version in Edgy? still 2.4?
<Chipzz> LaserJock: "still"?
<Chipzz> hrrrm
<Chipzz> wait
<jdong|coreduo> LaserJock: umm, isn't 2.4 still the latest version?
<Chipzz> nm
<lifeless> BenC: while you are there, can you see if the other evms patch is applied ?
<LaserJock> 2.5beta is in edgy
<lifeless> BenC: I ask because Mithrandir thought we definately have it, but its strange to have only have the patches from a package
<sivang> how dangerous will it be to install upstart and replace my init system?
<jdong|coreduo> sivang: it slots, so it should be safe :)
<jdong|coreduo> sivang: you need an init= kernel argument to invoke it
<jdong|coreduo> sivang: README.Debian time? :)
<sivang> jdong|coreduo: probably, but I wanted to know before installing the package from univers , fearing it will just replace stuff :-)
<jdong|coreduo> installing it appears quite harmless
<sivang> jdong|coreduo: what do you mean it "slots" ? (please excuse my non en nativeness)
<zyga> does anyone know how to make a nice hackergothi?
<jdong|coreduo> it installs things alongside what's in your system already
<jdong|coreduo> as opposed to replacing
<jdong|coreduo> sivang: i.e. python2.4 "slots" python2.3; gaim 2.0beta in Edgy "replaces" gaim 1.5.x in Dapper
<jdong|coreduo> sivang: it's more of a gentoo term than an english slang thing :)
<zyga> sivang: I'll give upstart a try too
<sivang> jdong|coreduo: you can never know what terms you will learn on ubuntu-devel ;-)
<jdong|coreduo> :)
<sivang> zyga: cool
* mvo decides its bedtime
<zyga> sivang: I'll reboot now
<zyga> mvo: night!
<lifeless> is modules still the right way to ensure a device is loaded into the initramfs ?
<zyga> well I'm still alive ;-)
<zyga> Keybuk: do you write upstart?
<zyga> upstart runs quite nice
#ubuntu-devel 2006-08-31
<sivang> does anyone recall by heat the keystroke in VIM to make lines aling with the same ident as the line upper ?
<sivang> heart, even
<LarstiQ> sivang: I'm not aware of that
<slomo> Riddell: you might want to ship the qt4 dbus bindings with qt4-x11-kdecopy as you already ship the debug build of it
<Burgwork> fabbione, ubuntulog appears to have vanished from #ubuntu-meeting
<Chipzz> sivang: you may be referring to =, which just correctly indents everything; it has however, nothing to do with the previous line, but is mostly used in visual mode or on a block of lines
<tseng> Chipzz: whoa!
<tseng> Chipzz: i had no idea
<Chipzz> tseng: > increases indent, < decreases
<tseng> knew that
<tseng> but = is pretty rad
<Chipzz> it can also screw you pretty badly
<tseng> (in visual mode)
<tseng> well
<Chipzz> fortunately, there's undo
<tseng> there is undo
<Chipzz> yes
<Chipzz> if you like long lines, it also wraps lines
<Chipzz> or is that the indent command?
* Chipzz hesitates
* LaserJock wonders how tiny is vim-tiny?
<desrt> Size: 418662
* desrt tells LaserJock about apt-cache show
<LaserJock> well, more feature wise, I guess
<LaserJock> me is looking forward to emacs-nano on the default install ;-)
<tseng> hah
<LaserJock> s/me/I/ stupid IRC grammar is ruining me
<gnomefreak> scribus-doc is not installible
<tseng> I is not liking emacs
<LaserJock> no?
<LaserJock> I keep switching back and forth
<LaserJock> but planner-el is keeping me with emacs presently
<gnomefreak> lol
<LaserJock> if I found a way to do it without emacs I'd probably go back to vim
<LaserJock> as emacs is so huge
<gnomefreak> gvim looks to have lost the .desktop file :(
<HrdwrBoB> you need a .desktop to launch gvim?
<gnomefreak> no dont need but it used to have one 
<Hobbsee> hey all
<sladen> hey Hobbsee, must be getting towards spring-time down there
<Hobbsee> sladen: almost, yeah :D
* Keybuk giggles
<Keybuk> that was fun
<Keybuk> I changed the ttys from "when rc2 is stopping" to "on startup"
<niKsternal> Kamion: ping?
<Keybuk> I think I'm going to leave them like that
<jdub> Keybuk: ping
<Keybuk> jdub: heyhy
<jdub> yo!
<jdub> http://lists.slug.org.au/archives/slug/2006/08/msg00318.html
<jdub> ^ bug or solveable?
<Keybuk> jdub: he needs to "mkdir /var/run /var/lock" without his /var mounted
<Keybuk> or $(mount --bind / /mnt && mkdir /mnt/var/run /mnt/var/lock && umount /mnt)
<jdub> Keybuk: right, so it's a matter of the underlying directories not existing?
<Keybuk> right
<Keybuk> and there's nothing we can do about that at boot, because the whole point of those directories is that they're for when we don't have a writable filesystem
<Burgundavia> https://wiki.ubuntu.com/EdgyEft/Knot2 <-- missing anything major? (any major mistakes)?
<Keybuk> no writable filesystem = no mkdir
<Burgundavia> not done, for the record
<jdub> Keybuk: so those tmpfs mounts will still appear, even if /var is mounted after they are mounted?
<ohoel> Burgundavia: hightlighting AIGLX with nothing that utilises it by default seems a bit weird
<ohoel> highlighting*
<Burgundavia> ohoel: it is installed by deafult, however
<Burgundavia> just not turned on
<ohoel> is compositor support in metacity still a pain?
<ohoel> I haven't heard anyone sing praise for libcm :)
<Keybuk> jdub: they will
<Burgundavia> no idea
<Keybuk> ohoel: if you have edgy, run compiz --replace for shiny bling
<jdub> Keybuk: thanks
<ohoel> Keybuk: yeah, and I know I'm being a nitpicking jerk, but compiz is in universe, while I thought the release notes were supposed to highlight default features
<Keybuk> ohoel: for milestones, it's probably enough to just talk about everything
<Hobbsee> Keybuk: when can you upload some major breakage to edgy?  :P  we're getting users wanting to upgrade for new features, and complaining as it breaks, again
<Keybuk> Hobbsee: when it's not frozen
<Hobbsee> Keybuk: well, yeah. i more meant "how soon after it's stopped being frozen"
<Keybuk> immediately
<Hobbsee> woo :)
<Keybuk> in fact, I can upload anyway given upstart is still in universe :p
<Hobbsee> Keybuk: woot!  that could be fun
* Hobbsee could upload to it too, come to think of it.
* Hobbsee considers being evil...or something...
<LaserJock> Hobbsee: now that's not the way to become a core-dev ;-)
<Hobbsee> LaserJock: true.  if i go for it again.
<Keybuk> syndicate scott# initctl jobs &
<Keybuk> [1]  7180
<Keybuk> syndicate scott# runlevel
<Keybuk> N 2
<Keybuk> syndicate scott# telinit 3
<Keybuk> syndicate scott# rc3 (start) starting, process 7185 active
<Keybuk> rc3 (start) running, process 7187 active
<Keybuk> rc3 (stop) stopping, process none
<Keybuk> rc3 (stop) waiting
<Keybuk> syndicate scott# runlevel
<Keybuk> 2 3
<Keybuk> -- 
<Keybuk> how can something so evil be so *right* ?! :p
<Keybuk> that's doing things "properly" too, storing the runlevel in utmp/wtmp
<Keybuk> it's just all done with event handlers, and not a single piece of "runlevel" knowledge hard-coded into upstart \o/
<Keybuk> grr
<Keybuk> init: rc6 process (7096) killed by signal 15
<Keybuk> WHY?!
* desrt smiles at Keybuk 
<Burgundavia> crimsun: could alacarte edit the system menu in dapper?
<crimsun> can't say (never tried, no fast access to a dapper system to test atm)
<Burgundavia> yep
<StevenK> Burgundavia: It can.
<Burgundavia> right
<dottedmag> Where is the authoritative source of information about writing ubuntu-compliant initscripts? Debian policy (even up-to-date) does not seem to be relevant, due to lsb-thingy.
<sivang> morning
<Burgundavia> morning sivang
<sivang> Burgundavia: hey corey
<Burgundavia> can you take a look at https://wiki.ubuntu.com/EdgyEft/Knot2
<Burgundavia> morning dholbach
<dholbach> good morning
<dholbach> hey burg
<dholbach> hey Burgundavia
* Mithrandir kicks git in the nuts.
<Mithrandir> good morning, Daniel
<Mithrandir> Riddell: do you want new livefs builds for kubuntu?
<Burgundavia> Mithrandir: what is my timing on the Knot2 page? Should I move it to the website before I go to sleep?
<dholbach> hey Tollef - having fun early in the morning already?
<Mithrandir> dholbach: if your idea of fun includes "building RC knot CDs", then yes.
* dholbach hugs Mithrandir
<Mithrandir> Burgundavia: Wiki or website -- both are fine with me.  Can the docteam still edit it if it's on the website?
<Burgundavia> no, but myself and Matthew East can
<Mithrandir> Burgundavia: ok, I guess that's good enough, then.  Thanks a lot for your work on the page -- it's absolutely appreciated.
<Burgundavia> no worries
<Burgundavia> can you give a quick glance over the page to see if I missed anything big?
<Mithrandir> sure, give me a minute to do it.
<moberg_> vuntz: hi
<Mithrandir> Burgundavia: looks good to me.
<dholbach> f-spot and gthumb are both in the desktop seed?
<Burgundavia> that would be a check
<dholbach> Burgundavia: a check?
<Burgundavia> dholbach: an affirmative to the fspot and gthumb
<dholbach> ah ok
<Kamion> nixternal: yes?
<nixternal> hey Kamion, you are the one posting the knot 2 announcement correct?
<Kamion> nixternal: that would be Mithrandir, I expect
<nixternal> roger that ;)  thanks
<nixternal> Mithrandir: if you are posting the knot 2 announcement, here is the link to the Kubuntu release info  https://wiki.ubuntu.com/EdgyEft/Knot2/Kubuntu
<Mithrandir> nixternal: cheers.
<nixternal> kool..thank you ;)
<Mithrandir> the CSS on that page is _seriously_ funky.  The content box on the right hand side starts out in the right position and then "walks" upwards for a bit as the page loads.
<Mithrandir> might just be Opera doing something weird.
<nixternal> i know it renders ok with ff1, ff2, and konqi
<nixternal> it could be the amount of images as well causing the issue
<nixternal> i tried to shrink them down as much as possible, and still be presentable
<Burgundavia> Mithrandir: http://www.ubuntu.com/testing/knot1
<Mithrandir> the system settings menu is _so_ a ripoff of the apple control panel. :-)
<Mithrandir> s/menu//
<Burgundavia> and?
<Kamion> Mithrandir: can I start alternate builds? I'd like to test my no-more-devfs changes
<nixternal> heh
<Mithrandir> Kamion: go ahead.
<Burgundavia> oh, wait. I am an idiot
<Burgundavia> it is knot2
<nixternal> lol
<Burgundavia> it is midnight here
<Kamion> ok, running
<Burgundavia> nixternal: tell me, where are the Europeans to help out the marketing people, anyway?
<nixternal> i have no clue
<nixternal> they aren't in Chicago..i know that for a fact ;)
<Burgundavia> Mithrandir: make that http://www.ubuntu.com/testing/knot2
<Mithrandir> Burgundavia: thanks.
<Burgundavia> one final check before I crash?'
<Mithrandir> Burgundavia: I'm happy with it.
<Burgundavia> then so am I
<Burgundavia> if you need anything changed, you will need to ping Nuzum, henrik or mdke
<Kamion> Burgundavia: "the menu editor, Alacarte and gnome-power-manager"
<Kamion> Burgundavia: that looks like a list of three items
<Kamion> perhaps "the menu editor (Alacarte) and gnome-power-manager"
<Burgundavia> or another comma
<Kamion> no
<Kamion> that would be a list of three items using the Oxford-comma convention
<Burgundavia> did you idea
<Kamion> which is common in British English
<Kamion> foo, bar, and baz
<Burgundavia> I trust your judgement, given it is morning there and night here
<Kamion> the text rendering in the Firefox screenshot is nasty, but probably not much to be done about that
<Burgundavia> that is utter default
<Kamion> "the always biting Matthew Garrett"? :-)
<Burgundavia> isn't it fun?
<Burgundavia> that text should be gone
<Burgundavia> look again
<Kamion> it is, but is in the Firefox screenshot ;-)
<Burgundavia> ah, yes
<Mithrandir> heh
<Burgundavia> it was early attempt at humour that did not survive the night
<Burgundavia> truly: any last thoughts?
<doko> Riddell: is gstreamer installed in a KDE desktop setup?
<zyga> hi
<zyga> did anyone notice that after dapper->edgy upgrade it takes several times longer to open a tab in gnome-terminal than to open a new window in it?
<nixternal> anyone else have a broken vmware-server after recent edgy updates?
<zyga> also all tabs other than the first one seem extereemly sluggish
<zyga> any gnome hacker want to have a look at gaim deadlock?
<zyga> I've got a backtrace
<dholbach> zyga: best to file a bug with a debug backtrace (gaim upstream guys read the gaim bugs in malone as well)
<Kamion> Mithrandir: all alternates built
<Mithrandir> Kamion: let's get started with the testing, then. :-)
<zyga> dholbach: it's not just gaim
<Kamion> Mithrandir: I've noticed a bug though - partman isn't writing out swap entries with a UUID
<zyga> gnome-terminal is affected too
<Kamion> rather, the swap partition has a UUID, but it's not in /etc/fstab
<zyga> Id' bet that any gnome app using tabs has this
<Mithrandir> I'll start off with alternate amd64.
<dholbach> zyga: accessibility enabled?
<Kamion> this is problematic because that will not now be changed on upgrade
<Mithrandir> Kamion: grr.. I'd like not to hold off because of it, can you think of a workaround?
<zyga> dholbach: yes
<ogra> Mithrandir, i just discovered an odd ltsp bug in the autoinstaller (will only affect edubuntu and xubuntus ltsp mode) ...
<ogra> :/
<dholbach> zyga: bug 58068
<Ubug2> Malone bug 58068 in gnome-terminal "can't open new tabs (with a11y turned on)" [Unknown,Needs info]  http://launchpad.net/bugs/58068
<zyga> oh :)
<Mithrandir> ogra: can you elaborate, please?
<dholbach> zyga: upstream would love you if you'd investigate it
<Kamion> Mithrandir: well, we could do the fstab conversion again in volumeid later, but that's very non-ideal because some people may already be trying to avoid it
<dholbach> zyga: or could follow up with some more information
<Kamion> I'm just trying to figure out now why it's happening
<Kamion> worth checking whether it affects the desktop CD too
<ogra> Mithrandir, it doesnt finish the ltsp chroot (which breaks edubuntus install) due to a plugin i merged from debians branch being called to early ...
<zyga> dholbach: I'll add info that gaim is affected too
<zyga> and try poking at that backtrace
<zyga> thanks for the easy start
<ogra> Mithrandir, i just need to move a file to a different dir ... would you oppose an upload ? (wont affect ubuntu /kubuntu)
<dholbach> zyga: way to go
<Mithrandir> janimo: do you have any feelings about the ltsp bug mentioned above? ^^
<ogra> additionally it seems there were 4M added to my i386 iso over night, damned
<Mithrandir> ogra: uh, the cronjobs are turned off, so I really doubt anything was changed without you touching it
<ogra> i didnt build the 20060831 iso
<Kamion> urgh, I think busybox mkswap must still be broken
<Hobbsee> ogra: blame the gremlins?  :P
<ogra> seems the dbus stuff made it grow on i386 and shrink on the other arches
<Kamion> I built Edubuntu alternate along with all the others
<ogra> Kamion, right ...
<Mithrandir> I need to pop out for a little bit, bbiab.
<ogra> Mithrandir, any word on ltsp before ? 
<Kamion> oh, for pity's sake, how many implementations of mkswap do we need
<Kamion> Mithrandir: if I can fix parted to create UUIDs on swap partitions, can I upload it?
<Kamion> doesn't need a debian-installer rebuild
<ogra> why the heck did only i386 grow .... grmbl
<zyga> did keybuk write upstart?
<fujitsu> zyga, yep.
<zyga> k
<janimo> Mithrandir: that ltsp bug should not hold up xubuntu alternate as far as I am concerned, I have just learned about it now that ogra mentioned it
<janimo> but if it's easily fixable it may be worth respinning after it's uploaded
<Riddell> doko: no, we dont have gstreamer in kubuntu
<Riddell> Mithrandir: yes, new livefs builds would be good
<kagou> animimotus: j'ai a aussi, plus 2 gamins (3 ans et 10 mois) qui me cherchent :) Ce soir  18H UTC - 1 ils seront couchs. Non mais ...
<mvo_> zyga: anything yet to merge from for c-m-f :) ?
<kagou> sorry
<zyga> mvo_: not yet :/
<zyga> mvo_: I don't have a solution for alternatives yet
<zyga> mvo_: I was thinking about splitting the data per source repo so that user will get notified that 'foo' is in universe
<mvo_> zyga: that is a interessting idea! I could extend the current extration script to look for update-alteratives in postinst. then we can work out how many packages are affected. IIRC we have only quite old information about this, right?
<zyga> mvo_: AFAIR about ~100 packages are affected, about 10 or so are top priority and can be processed manually
<zyga> mvo_: how do I run your data extraction script?
<mvo_> zyga: that sounds good then
<mvo_> zyga: unfortunately it needs a compelete mirror on the machine where it runs
<zyga> mvo_: we can use the suggestion system for manually processed packages
<zyga> mvo_: any rsync magic I can run to get that?
<zyga> I'm sitting on one fat pipe here
<mvo_> zyga: yes, that sounds good, I will add this feature 
<mvo_> zyga: I will have a look
<mvo_> zyga: about the rsync
<zyga> mvo_: I'll hack on extracting the repo part but just tell me how to get that repo here :)
<zyga> thanks
<mvo_> zyga: I think debmirror should do what you need
<zyga> checking that out now
<mvo_> zyga: when you have a mirror simply run the script in DataExtractor.mvo with "-d /path/to/the/mirror"
<mvo_> zyga: for full coverage we may need it on a mirror with all arches to get packages that are e.g. only available on ppc
<Mithrandir> Kamion: ok, if you can get it fixed RSN, then it's ok.  If it needs a bit of time, I say we don't care about it.
<zyga> mvo_: yes I did notice we are i386 only ATM
<Mithrandir> ogra: as it's ok with Xubuntu, feel free to upload
<ogra> yay
<mvo_> zyga: the extraction code will (or rather should :) go over all three supported arches
<Kamion> Mithrandir: I'm testing the fix now
<ogra> Mithrandir, edubuntu-meta fine with you as well ?
<zyga> mvo_: I need to fix debmirror to look at ubuntu, not debian ;)
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/tmp/parted-swap-uuid.dpatch
<mvo_> zyga: heh :)
<Mithrandir> ogra: edubuntu-meta is fine with me -- worst case you end up having to fix it yourself. :-)
<ogra> :)
<ogra> thanks
<Kamion> the annoying bit is that volumeid.postinst actually generates a uuid for the new swap partition, but only after /target/etc/fstab has been written
<ogra> Mithrandir, i was assuming that, but youre the frozen master ;)
* Mithrandir casts a cone of cold on ogra
<Mithrandir> muhahaha :-)
<ogra> hihi
<Kamion> <cjwatson@cairhien-wired ~>$ sudo parted -s /dev/hda mkfs 4 linux-swap
<Kamion> <cjwatson@cairhien-wired ~>$ sudo vol_id -u /dev/hda4
<Kamion> 58a7b66f-ea30-4303-af4c-1493a0525324
<Kamion> excellent
<Mithrandir> Kamion: ok, go ahead.
<infinity> Bah, I should have turned off cron.daily 3 minutes ago.
<infinity> Oh well.
* ogra knows mdz will be unhappy about the next -meta upload ... but it was so tempting ...
<infinity> ogra: ...?
<Kamion> infinity: I was just thinking that :(
<ogra> infinity, i dropped gcc and headers for a quick size reduction
<ogra> i dont know where else i should free up 4M right now
<Mithrandir> infinity: can you force an immediate publisher run when this one finishes?
<infinity> Mithrandir: Of course, and was planning on it.
<Mithrandir> thanks.
<zyga> mvo_: cool I got it working
<mvo_> zyga: rock!
<Kamion> parted uploaded
<cbx33> Hi all in an effort to reduce CD size....
<cbx33> I believe I can shave 2Mb+
<cbx33> by making the gnome system or whatever is responsible play oggs for system sounds
<cbx33> we are currently using well over 2Mb
<cbx33> the new sounds I have made are around 300-400Kb
<cbx33> just wondered if anyone knew if thiswas a possiblilty as ogg is supported OOTB
<Kamion> cbx33: sounds reasonable; can you talk to Frank Schoep about that?
<cbx33> ok sure
<cbx33> I'm in close contact with him anyway
<zyga> mvo_: pull from suxx.pl/~zyga/command-not-found to get mirror script
<Kamion> cbx33: great
<mvo_> zyga: pulling
<zyga> mvo_: i386 alone is 14GB of data
<zyga> it will take almost a day
<mvo_> zyga: I can run it on a ubuntu machine, you could just mirror a tiny bit (e.g. pool/main/a) to test the stuff and then we just run the full extraction on a different machine
<zyga> mvo_: I'm pulling the whole bit anyway, I won't have time to work on this till I get home
<zyga> I'm at work ATM
<mvo_> zyga: ok :)
<zyga> extracting section is easy, we'll just make a number of databases (edgy-main.db and so on)
<zyga> checking which is enabled might be more tricky
<zyga> (or does apt already know)
<seaLne> sould alternate be able to install onto lvm just now?
<mvo_> zyga: we have a "aptsources" module in update-manager should should be able to give us this information
<mvo_> zyga: initialy ist may just be enough to display the section (if not main) and check if the package is installable/available and display a message if not to enable the componenet
<mvo_> zyga: we will probably need to add architecture information to the db as well
<zyga> mvo_: right
<zyga> mvo_: how about: $DIST-$ARCH-$REPO
<zyga> and just pick the set currently used (multiarch might benefit)
<zyga> so we get lots of files
<zyga> cnf-data will probably grow a bit
<mvo_> sounds good
<slomo> doko: erm why was a python-gst0.10 b-d needed for gstreamer0.10?
<zyga> mvo_: this way we won't waste space on storing i386 a bazillion of times
<Riddell> Mithrandir: did you start a kubuntu livefs  build?
<Kamion> hmm, I apparently forgot about cdrom-detect in no-more-devfs
<slomo> doko: i don't think it's a good idea to have gstreamer0.10 b-d on itself :/
<infinity> Riddell: They all failed -- kubuntu-live is uninstallable.
<infinity>   qtparted: Depends: libparted1.6-13 (>= 1.6.24) but it is not installable
<infinity> Riddell: qtparted needs a rebuild with the new libparted, looks like.
<infinity> Riddell: Can you do a test build, make sure it works, and upload for that?
<Riddell> infinity: doing
<seaLne> should d-i be able to install to multiple lvm partitions? neither knot-1 or todays daily do
<Mithrandir> Riddell: yeah, but my ssh session timed out, for some reason. :-/
<Mithrandir> Riddell: they seem to have finished, but I'll check that they're all complete.
<infinity> Mithrandir: See a few lines up.
<Mithrandir> infinity: gah.
<infinity> Mithrandir: You do check that your builds actually work, right?  ubuntu-amd64 seemed broken too.
<Mithrandir> infinity: yes, I tend to do that.
<Kamion> the health checks will kick off shortly anyway ...
<infinity> Gah, and that's why amd64 failed.
* infinity kicks some builds.
<Kamion> seaLne: sorry, maybe I haven't had enough coffee yet, but could you elaborate?
<seaLne> Kamion: i was trying to install with todays alternate to multiple lvm partitions (root usr var tmp) aswell as a normal boot and swap partition, the install fails during install base
<Kamion> seaLne: ok, I'll give that a try in a moment
<seaLne> Kamion: the fact that it also fails on knot-1 makes me think its not just a problem with todays daily
<seaLne> Kamion: kubuntu, but i don't think that will make any difference for this
<Kamion> no, it wouldn't
<Kamion> I haven't tested LVM since the big merge from Debian in Edgy, so it could well be broken
<seaLne> sda1 = boot, sda2 = swap, sda3 = lvm (root usr var tmp)
<Kamion> created from scratch in d-i, or pre-existing?
<Kamion> (the lvm vg)
<seaLne> currently pre existing, i think i could have done them with d-i? but i didn't see that when i first tried earlier today, let me know if their is anything i can test as its a new machine with nothing on it
<Kamion> extracting the log files and putting them somewhere might speed up the fix; use 'save debug logs' from d-i's main menu
<seaLne> i tried that but it tried again to do base install
<Kamion> did you get back to the main menu at all?
<seaLne> i think it is creating devices it is failing on but it dosen't quite show enough
<seaLne> yes, to get to save logs
<Kamion> weird, save-logs doesn't depend on base-installer
<Kamion> well, 'anna-install openssh-client-udeb' from tty2 and you'll be able to copy off the logs
<Kamion> with scp
<seaLne> ah strange changed dir to /tmp and it saved them fine
<seaLne> "unknown user 0" for scping
<Kamion> knot-1 or current?
<Kamion> works for me with the current daily, was known breakage in knot-1
<seaLne> ah i think i might have knot-1 in just now sorry
<seaLne> "dmsetup: not found" is the error before it fails
<seaLne> could not find package lvm2 :)
<seaLne> sorry give me a few minutes to reburn daily used the same cdrw
<Kamion> oh, did we move lvm2 to supported instead of ship?
<Kamion> silly mdz
<doko> slomo: see #385439
<Kamion> seaLne: ok, should be fixed for the next or possibly the next-but-one build, depending on exactly how long my seed change takes to propagate
<Kamion> seaLne: thanks for the report
<Kamion> seaLne: (problem was that lvm2 et al had been removed from standard without making them available for the installer to use)
<Kamion> seaLne: oh, hmm, I may have spoken too soon, the error is a little weirder than that
<Kamion> seaLne: no, should be fine. indecisive, moi? :)
<Kamion> I think the dmsetup error is spurious
<nags> seb128, Hi
<seb128> hi nags
<seb128> lunch timme, bll
<infinity> Riddell: Err, were those kde-i18n uploads required for Kont-2?
<nags> seb128, sure, meet you later
<infinity> Riddell: If so, I'll push them through.
<seb128> nags: feel free to ask your question if you have one ;)
<seb128> I'll reply when I'm back
<nags> seb128, nothing special, its been long days, since I said hi, so ;)
<nags> seb128, In Mozilla accessibility hackfest LDTP is one of the important agenda - FYI - http://wiki.mozilla.org/Accessibility_Hackfest_2006
<gnomefreak> is it true that irssi is being removed from install?
<tseng> gnomefreak: sounds feasible, and yes things are being removed
<Kamion> already has been
<Kamion> supported: * irssi
<Kamion> timestamp: Mon 2006-06-19 09:48:28 -0700
<Kamion> message:
<Kamion>   Move irssi from desktop to supported; it isn't a desktop application
<gnomefreak> tseng: now gnome doesnt ship with an irc client other than gaim.
<tseng> gnomefreak: what does irssi have to do with gnome
<tseng> irssi is completely opaque to a new user, if they can even find it
<gnomefreak> tseng: the xserver-xorg-video-all is not being installed on upgrade (not sure about clean install) but that leaves 80% of users without X adn now without a way to get help
<tseng> gnomefreak: on edgy?
<Kamion> we can/should fix that before edgy; users who can't fix that sort of thing themselves shouldn't be running edgy
<gnomefreak> yes
<tseng> well, its edgy
<tseng> if it breaks, you get to keep both pieces
<Kamion> we have been entirely consistent about this message since the hoary development cycle
<gnomefreak> Kamion: that i understand and i tell people its not stable cant fix it dont use it (but they are stubborn)
<Kamion> well, then it's a learning experiece
<Kamion> experience
<tseng> anyway, back to my point
<tseng> if you can't figure out how to fix your edgy box
<gnomefreak> dont use it
<Kamion> and perhaps they will learn how to fix things in the process
<tseng> there is a good possibility you don't know what irssi is
<tseng> and its unhelpful interface
<Riddell> infinity: they arent required but they dont currelynt install otherwise
<gnomefreak> well i was thinking if its size issue to remove gaim instead of irssi 
<tseng> hah-hah
<Kamion> no, we're not going to leave the system without a graphical interface in favour of a textual one
<tseng> gaim is largely more useful to most people
<tseng> if you can get to a shell you can apt-get install irssi if you know how to use it, anyway
<seaLne> Kamion: thanks, sorry got called away to fix something
<tseng> if you don't know what it is or how to use it, I don't see how it helps you being preinstalled
<tseng> irssi being the liferaft of Joe User is a huge strech
<gnomefreak> understood
<slomo> doko: weird... why does it still build on the buildds? let me retry...
<ogra> seb128, did you add the patch for g-p-m actions to gnome-session yet ? i dont see any buttons
<ogra> oh
<ogra> hmm
* ogra would have expected to be up to date after the last dist-upgrade ... but that seems not to be the case 
* ogra pulls another 90 updates .... :/
<doko> seb128: (soffice.bin:2103): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (1000)
<doko> $ getent passwd 1000
<doko> doko:x:1000:1000:Matthias Klose,,,:/home/doko:/bin/bash
<doko> ?
<seb128> doko: weird
<seb128> doko: what do you do to get that?
<doko> start a new OOo build in a chroot on amd64. I currently cannot install that natively. do you want to give it a try?
<seb128> not really
<seb128> getpwuid_r() is not a glib function though, the message is weird
<doko> sure, that's glibc, but called by glib
<seb128> do you have a simple testcase?
<doko> not yet
<seb128> ok, let me know if you have one
<seb128> usually you can use --g-fatal-warnings to break on a warning and get a bt
<seb128> but that's when running something, dunno what your build is doing
<seb128> like if there is somewhere you can plug the argument for it
<slomo> doko: it still builds without python-gst0.10 here
<doko> slomo: yes, see the reply from the debian maintainer ... confused ...
<seb128> I'm away for some time, bbl
<cbx33> ping vuntz 
<zyga> mvo: I've got 4.5GB already, about 10GB to go
<ogra> hmm, update-initramfs and my p133 seem not to like each other ... lots of segfaults ...
<zul> ok i have a question on the nvidia driver for xen should it be ok to include it as a patch with the xen-3.0 or should i create a sepereate deb for it, ie call it xen-nvidia or osmething like that
<zul> i guess i am looking for opinnon/advice
<bddebian> Morning
<Kamion> zul: I'd go for xen-restricted-modules-2.6.16 myself
<Mithrandir> Riddell: are all the pieces you need for the livefs-es built and published yet?
<zyga> Kamion: xen restricted? what is restricted about xen?
<zul> Kamion: and an xen-meta as well?
<Mithrandir> zyga: the restricted modules, built for xen.
<Mithrandir> zyga: such as nvidia.
<zyga> ah, right
<Riddell> Mithrandir: yes, please do new livefs
<Mithrandir> Riddell: building
<Kamion> zul: not so crucial as for the mainline kernels, I'd say, but up to you
<zul> okie dokie
<prudhvi> Hi, i would like to add IN_te support to Ubiquity. how can i do that ?
<Mithrandir> Riddell: I'll build you new alternate ISOs, if you'd like?
<Mithrandir> (livefs-es are still not finished)
<Kamion> prudhvi: you mean te_IN?
<prudhvi> Kamion, yes
<Kamion> prudhvi: you need to start out by getting support for your language into d-i, and getting it translated to a reasonable level
<Riddell> Mithrandir: please
<Mithrandir> Riddell: running.
<Kamion> prudhvi: that's best done in Debian - we *can* add languages to the installer in Ubuntu, but it's a lot of work for me
<Mithrandir> ogra: same for you once kubuntu is ready?
<prudhvi> Kamion, hmm, so i need to Add te_IN support to d-i initially ?
<doko> Mithrandir: should alternate CD's be tested as well?
<Kamion> prudhvi: yeah
<bddebian> doko: You didn't send me any azureus URLs ;-)
<Kamion> prudhvi: ubiquity is based fairly heavily on d-i
<Mithrandir> doko: yes, please.
<Mithrandir> janimo: do you want rebuilds of the Xubuntu CDs?  There was some installer problems which are fixed now which you might want to pick up.
<doko> bddebian: oops, wait ...
<janimo> Mithrandir: sure, thanks
<prudhvi> Kamion, most of the Gnome Translations have already been done nearly 85% is done 
<Kamion> prudhvi: if you've already been working on translating the debian-installer package in Rosetta, you can use that file to seriously jump-start your translation of d-i upstream; most of the strings are common
<janimo> Mithrandir: and I have made uploads yesterday after the last cdimage
<Mithrandir> janimo: xubuntu alternate running
<Mithrandir> Riddell: kubuntu alternate done, livefs-es still building.
* Riddell rsyncs
<seaLne> does kubuntu 20060831.1 have lvm2 in it?
<seaLne> ah looking at the .list file it seems to
<jdong|coreduo> ooh, is the alternate cd failing for someone other than me on lvm2? :)
<jdong|coreduo> or is 831.1 actually gonna work?
<seaLne> lvm2 wasn't in it :)
<jdong|coreduo> seaLne: yeah... for a few weeks now :)
<jdong|coreduo> that's what I've been crying and whining about :)
<seaLne> obviously not to the right person, kamino fixed it when we worked out what it was
<ogra> Mithrandir, thanks
<Mithrandir> ogra: was that a "yes"? :-)
<ogra> err, yes
<Mithrandir> ogra: willdo.
<ogra> sorry, i'm a bit confused here ... 
<jdong|coreduo> seaLne: it's more fun to cry and whine to imbrandon :)
<jdong|coreduo> morning, Keybuk 
<Keybuk> heya
<jdong|coreduo> holy mother of god how did amarok build??
* jdong|coreduo must've slept through something
<Hobbsee> dholbach: hah.
<Hobbsee> oops
<Hobbsee> jdong|coreduo: hah.
<Hobbsee> jdong|coreduo: something crazy's happened to kopete too, btw
<Kamion> jdong|coreduo: imbrandon isn't in core-dev and couldn't possibly have fixed the bug
<Kamion> (it required a seed change, which is access-controlled to core-dev)
<jdong|coreduo> Kamion: I know, but it's still fun nontheless to tease him about it :)
<jdong|coreduo> either way, thanks for making the cd's work now :)
<Kamion> shame I didn't hear about it until today - it would have been easy to fix weeks ago as well
<jdong|coreduo> Kamion: next time I'll complain a bit louder to core-dev :)
<jdong|coreduo> Hobbsee: what's up with kopete?
<Mithrandir> ogra: I presume you want livefs-es too?
<Mithrandir> janimo: ^^ same goes for you?
<Hobbsee> jdong|coreduo: according to LP it's built, and in the archives, yet dapper users cant actually find it there.
<Mithrandir> ogra: also, alternate cds building.
<Mithrandir> janimo: alternate cds done.
<jdong|coreduo> Hobbsee: yeah, I can see that... I wonder if NEW packages have to have something done
<ogra> Mithrandir, livefses wont do no harm i guess ...
<doko> bddebian: http://cvs.fedora.redhat.com/core.shtml (or http://cvs.fedora.redhat.com/extras.shtml ?). but the site seems to be currently down
<jdong|coreduo> doko: fedora went down yesterday for upgrades
<jdong|coreduo> I'm not sure if they're backup
<Hobbsee> jdong|coreduo: that's the weird thing.  it's hit dapper-changes, and has built (!sparc).  p.u.c hasnt seen it yet, and it doesnt seem in the archives though
<StevenK> It takes a day?!
<StevenK> Do they run Gentoo or something?
<jdong|coreduo> StevenK: hardware upgrades :P
<Hobbsee> StevenK: they cant peddle fast enough :P
<jdong|coreduo> changing colos or something
<StevenK> Bwaha
<jdong|coreduo> and fedora does get a TON of updates :P
<jdong|coreduo> I think it's up to nearly 1GB in downloads from FC5's DVD to fedora-updates
<StevenK> Right, changing colos I can believe, since BGP4 propagation is a bitch.
<bddebian> doko: OK, thx
<jdong|coreduo> Hobbsee: yeah, it's strange
<jdong|coreduo> Hobbsee: could it be some kind of soyuz bug with new source packages?
<Hobbsee> jdong|coreduo: ask someone who manages soyuz stuff.
* Hobbsee just whines when it seems to break.
<doko> bddebian: I just did remove the bcprov stuff from the package (except the one changed class), then applied the FC patches; there are one or two new patches to use some gtk defaults from libgtk-java
<Mithrandir> ogra: edubuntu alternate is finished
<ogra> thaks !
<ogra> +n
<jdong|coreduo> would ya look at that... gentoo 2006.1 is out :)
<janimo> Mithrandir: lives too, thanks
<Mithrandir> janimo: will do once edubuntu livefs-es are done
<ogra> RAAAHHH
<ogra> why the heck did i gan only one meg with dropping the kernel headers and gcc
<ogra> *gain
<Mithrandir> ogra: still oversized?
<ogra> that cant be
<ogra> yes
<Kamion> check .list files first
<ogra> doing
<ogra> (was looking at the logs already)
<ogra> gah
<ogra> i guess the seed mirroring is still delayed ... both are in there (gcc and linux-headers)
<ogra> hmm, no the launchpad branch is up to date 
<ogra> and edubuntu-meta 1.9 is on the iso ...
<ogra> thats weird
<mejde> Any work being done on getting the broadcom 43xx firmware included? I.e. is it even possible, what's the license, know of any talks going on between Canonical and Broadcom... etc... (sorry if this is off-topic)
<ogra> mejde, no, its not possible, else we'd have shipped it in dapper already
<ogra> Kamion, any idea ... i cant find a reason why the headers should end up on the CD ... all seems fine 
<ogra> both seeds are up to date ... the metapackage is as well
<mejde> ogra: I guess it's because of the license? How realistic do you think it is for Canonical/Ubuntu to persuade Broadcom to change the license?
<zul> heh..
<ogra> it was already asked and denied afaik 
<jdong|coreduo> mejde: broadcom is not exactly happy about the bcm43xx driver
<jdong|coreduo> it's just lucky there's no legal action arising from it yet ;)
<ogra> ARGH
<ogra> right, i suck ... or bzr does 
<mejde> I don't get it... are they selling drivers or hardware... bah!
<Hobbsee> ogra: of course bzr doesnt suck :P
<ogra> Hobbsee, likely ...
<Keybuk> WTF does S31umountnfs.sh call halt?!
<ogra> looks like a human error
<Hobbsee> ogra: must be a local problem.
<Hobbsee> ogra: :P
<thom> Keybuk: *boggle*
<Keybuk> ah, to "write a wtmp record"
<Keybuk> eww
<jdong|coreduo> mejde: they sell pure evil
<jdong|coreduo> mejde: and their hardware is pretty crappy too :P
<Hobbsee> jdong|coreduo: surely they havent started selling cups!
<otavio> Is Jonathan Riddell here?
<Hobbsee> otavio: yeah, Riddell is around.  why?
<Keybuk> as if anything has ever used the shutdown wtmp records
<otavio> Hobbsee: which is his nickname?
<Mithrandir> otavio: Riddell 
<otavio> Mithrandir: thanks
<Mithrandir> ogra: does that mean you need another livefs/alternate build?
<ogra> it was an oversight from mdz  ... they stayed in ship but were moved from ship-live to desktop
<ogra> Mithrandir, yes
<Hobbsee> otavio: if it's kubuntu specific, ask in #kubuntu-devel
<Hobbsee> if you like
<seaLne> Kamion: 20060831.1 d-i still fails, did you change anything or will it not be till later?
<Mithrandir> ogra: oh well, tell me when you need it, then
<mejde> I wonder how Broadcom would feel about the installer automatically looking for the driver on a windows partition and extracting it from there
<Mithrandir> Riddell: also, your live ISOs are served.
<ogra> Mithrandir, i'll need you only for the livefs
<z\> uhm hello
<ogra> can do the alternate builds myself ...
<Mithrandir> ogra: well, tell me anyway, and I hold the big cdimage lock for now, so it's easier if I build the ISOs too.
<jdong|coreduo> mejde: I'm not sure using the broadcom firmware with bcm43xx is legal _in the first place_
<Hobbsee> fabbione: are your logs working?  seem that we dont have the last few  days of #ubuntu-meeting logged
<Mithrandir> now I need to go home for dinner and the distro meeting.
<Hobbsee> fabbione: well, they seem blank
<ogra> Mithrandir, oki
<z\> someone have ubuntu in dualboot with some system (fulesystem FAT32) ?
<z\> i found a big bug.
<jdong|coreduo> a big bug.... oh boy
<StevenK> z\: Dapper, yes
<mejde> jdong|coreduo: too bad... for most users, without it working out of the box, it's like the driver didn't exist at all :(
<z\> with it i can root all nox...
<z\> uhm
<Hobbsee> er, ubuntulog isnt in #ubuntu-meeting, thats' why.  who can fix that before the next meeting?
<z\> so i talk in launchpad
<jdong|coreduo> z\: I have ubuntu dual-booting with quite some different OS'es... what's wrong?
<z\> now i go to work
<z\> it's late
<ogra> whats the bug ? 
<jdong|coreduo> mejde: I know, it is too bad... but what can we do about it :-/
<jdong|coreduo> <z\> with it i can root all nox...
<jdong|coreduo> I think that? ^^
<jdong|coreduo> is he talking about init=/bin/bash?
<ogra> jdong|coreduo, thats the symptom
<ogra> not the bug :)
<jdong|coreduo> lol
<jdong|coreduo> aah, lost my terminal
<jdong|coreduo> where is it?
* Hobbsee ate it.
* Hobbsee has it as ransom for ubuntulog.
<jdong|coreduo> note to self: don't set compiz tranparency to 0 for a window
<jdong|coreduo> ha, there it is
<mejde> jdong|coreduo: reverse engineer the firmware =)
<jdong|coreduo> mejde: how about buy a better card than the bcm?
<jdong|coreduo> lol
* Hobbsee notes that mjg59 said he'd troubleshoot her wifi card, and make it work OOTB.  and hasnt yet.
<jdong|coreduo> Hobbsee: what kind of wifi card is it?
<Hobbsee> jdong|coreduo: marvell 8335 card - it's supposed to be recognised OOTB - i was using ndiswrapper back when i was using it.
<jdong|coreduo> Hobbsee: well, then you can rightfully blame it on him :P
<Hobbsee> jdong|coreduo: hehe
* Hobbsee doesnt want to miss the meeting.
<jdong|coreduo> breakfast and medication time....
<jdong|coreduo> I expect knot2 cd's posted and announced on distrowatch before I finish :)
<Hobbsee> yay.  i need to fix an uninstallable package, once main freeze is lifted.
<zul> and beg someone to upload it for you :)
<Hobbsee> zul: long pointy sticks are useful.
<Hobbsee> zul: true that, though.  
<Hobbsee> zul: thanks for volunteering :)
<zul> meh..
<Hobbsee> zul: you know you want to :)
<zul> yeah now..:)
<Kamion> ogra: did you check http://people.ubuntu.com/~cjwatson/seeds/edubuntu-edgy/?
<Kamion> seaLne: oh, the seed change probably hasn't been merged to kubuntu yet
* Hobbsee wonders if kubuntu needs to ship wlassistant.
<Kamion> ogra: from the looks of things, the ship seed only got updated on http://people.ubuntu.com/~cjwatson/seeds/edubuntu-edgy/ 9 minutes ago
<Riddell> Hobbsee: how else to scan for wireless networks?
<Hobbsee> Riddell: knetworkmanager
<Hobbsee> Riddell: unless it borks, of course.   *shrugs*
<Riddell> Hobbsee: that is not installed by default
<Hobbsee> Riddell: why not?
<Riddell> dunno, ask Keybuk :)
<tseng> because it doesnt work reliably
<Hobbsee> Riddell: same argument for knemo, too.
<tseng> esp madwifi
<Hobbsee> tseng: nothing does.
<Hobbsee> tseng: madwifi seems to work okay here
<tseng> Hobbsee: ok, it doesnt work reliably enough to meet our seal of approval
<Hobbsee> tseng: but i see your point
<Hobbsee> tseng: right :P
<tseng> it does wonky things even on my intel card
<tseng> as much as the novell guys will deny
* Hobbsee wishes wlassistant did WPA.  WPA users are stuck in the dark without knm.
<Hobbsee> true.  it's got work to be done.
<Zic_> sorry, I'm french, have you an idea of when the Knot 2 was on the mirrors ?
<Hobbsee> Zic_: its' not yet?
<Zic_> I don't know, but I can found it
<Zic_> :s
<tseng> when it is published it will be announced in the usual places
<Riddell> seaLne, Kamion: kubuntu seeds merged to add lvm2, I guess we will need new alternate CDs for that
<Kamion> Riddell: I wouldn't be inclined to rebuild just for that, but it can be in the next build if one's needed, maybe?
<Zic_> the publication is supposed being planned for today, then I wait 
<Zic_> I remain here, if you have information which arrives. I could make it go up with the French channel.
<Kamion> Zic_: subscribe to ubuntu-devel-announce@lists.ubuntu.com and you'll get the announcement
<Zic_> thx
<Zic_> a mail empty I suppose ?
<dholbach> Zic_: http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
<Zic_> thx ;)
<dholbach> zul: still editing the wiki page?
<zul> uh...no..
<dholbach> ok cool
<zul> i think i might have ghosted or someting
<dholbach> the wiki said so, yeah
<ogra> Kamion, right, i missed that it was in desktop *and* ship ... mdz only moved it from ship-live to desktop and left ship alone
<seaLne> bah i'd quite like an alternate with lvm2 so i can install my machine :(
<Kamion> BenC, fschoep, heno, kwwii, seb128: #ubuntu-meeting
<Kamion> hmm, no fschoep or kwwii, I hope they'll remember
<heno> Kamion: thanks, just writing my entry :)
<dholbach> sfllaw too
<Keybuk> I AM A GOD!
<dholbach> you're exaggerating
<Keybuk> and man, why is debugging so much easier after a full night's sleep?
* mvo_ bows before Keybuk
* jdong prays for his two backports to be synced ;)
<thom> Keybuk: what has claused you to claim deity status?
<Keybuk> thom: working shutdown process :p
<thom> getting to a state that everyone else is in already raises you to normality, not godhood :P
<tseng> thom: but he does it with flare
<HiddenWolf> flair or flare? ;)
<thom> flares
<thom> corduroy ones
<seb128> ogra: to reply to your question of before (you were not on IRC when I went back from lunch): yep, gnome-session sleep,hibernate should be fixed
<ogra> seb128, i have a funny effect here, i use gartoon icons and if i alt-tab through my windows, evo shows the default icos until i release the alt key, then it switches back to gartoon :)
* Starting logfile irclogs/ubuntu-devel.log
(ogra/#ubuntu-devel) HiddenWolf, hughsie in #hal
(ogra/#ubuntu-devel) and on the gnome-power.manager mailinglist
<ogra> *gnome-power-manager
<HiddenWolf> ogra: cheers
<BenC> Keybuk: ping
<Keybuk> BenC: heyho
<BenC> Keybuk: hey, can you check and see why my upload of kexec-tools is not even sending me a reject/accept email?
<BenC> I've tried twice
<Keybuk> usually bad signature
<ogra> or bad distro
<BenC> $ file kexec-tools_1.101-2ubuntu1_source.changes
<BenC> kexec-tools_1.101-2ubuntu1_source.changes: PGP armored data signed message
<BenC> weird
<BenC> distro is unstable
<BenC> ok, that explains it
<Keybuk> oh, well, that'd do it
<Keybuk> LP isn't very good at reporting failures that escape the main loop
<Keybuk> (ie. those that generate exceptions, rather than fail checks)
<ogra> i remember it sent "bad distro" mails once in the beginning
<ogra> but that might have stopped
<ogra> or it sends them to the DD :P
<Keybuk> it used to send them, as a python exception :p
<ogra> heh
<ogra> i once got a proper one ... but thats long ago ...
<seb128> mvo_: maybe putting compiz to ship? ;)
<seb128> mvo_: I think fedora is going with something like that for FC6, have a "enable graphical effects" sort of option which does "compiz --replace gconf"
<mvo_> seb128: I'm only interessted in the transparency :)
<seb128> mvo_: composite by default looks like edgy+1 material to me
<ogra> eek ... by default ? 
<mvo_> we already enable it in the X config
<seb128> mvo_: composite manager by default I mean
* ogra wonders if we could force the users to use gigE adapters on thin clients
<mvo_> right
<mvo_> I think for this we should have a easy option to turn it on. and maybe remove the worst plugins :)
<mvo_> or a GUI that makes it easy to turn them on 
<mvo_> something like this
<mvo_> maybe in universe, but just to have something to show off with
<mvo_> and transparent notifications :P
<ogra> haha
<ogra> the *important* stuff :P
<shining> I'm alone to find compiz sucks?
<seb128> mvo_: if you have a talk on composite, xorg; etc tomorrow please ping me, I'm interested too
<mvo_> ogra: we could make hwbd-clients transparency more smooth then (who needs i18n anyway) :P
<mvo_> seb128: and we could do the logout/gksu fadding proper
* mvo_ gets excited
<ogra> lets make it 99% transparent with 99% transparent fonts ...
<mvo_> shining: but its so *shinny*
<ogra> so people only see a ghost of hwdb ... and dont complain bout typos
* seb128 hugs mvo_
<shining> mvo_: don't you get bored after 5 min ?
<ogra> mvo_, didnt you say youre an ion3 fan ? how bout having drop shadowns there :P
<ogra> *shadows
<mvo_> ogra!
<ogra> :)
* mvo_ runs of to implement more transparency
<mvo_> ogra: more BLINK!
<ogra> hehe
* mvo_ wonders if he had to much tea today
<rodarvus> :)
<rodarvus> mvo_, depends on what this tea is made of ;)
<ogra> what about transparent usplash ?? you could see the console messages scrolling :)
* HiddenWolf shivers
<HiddenWolf> ogra: guess my mother would like that. ;)
<ogra> heh
<mvo_> ogra: we just needs to add a X server to grub
<ogra> Mithrandir, btw, you could trigger new edubuntu builds if you like
<Mithrandir> ogra: will do.
<ogra> if the live iso is oversized i dont care if edubuntu releases install-only for knot2
<ogra> (as long as i get these in shape)
<Mithrandir> ogra: you need full rebuilds of livefs+live image + alternate, right?
<ogra> yep
<ogra> but i doubt the live iso will be below 700
<Kamion> mvo_: I've given feedback on bug 58207
<Ubugtu> Malone bug 58207 in ubuntu-cdimage "Please add the dist-upgrader on the CD" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58207
<Mithrandir> ogra: ok, doing both now.
<Kamion> mvo_: ... and updated said feedback, whoops
<wasabi_> Anybody have an info about where the current multiarch approach stands?
<ogra> Mithrandir, ok ... i'm afk for 30-45min (shopping some food)
<wasabi_> I remember, back in the day, reading about an approach that introduced /lib/linux-686/libs.so, type paths. And liking it.
<Mithrandir> ogra: if I'm not around when you get back and the livefs is done, feel free to start the liveiso build; I need to go help my mum with gimp. :-P
<slomo> doko: i guess i'll drop this with the next upload then, ok?
<doko> slomo: sure
<mvo_> Kamion: thanks
<slomo> doko: it tried to rebuild the docs because you have some changes in the docs directory btw
<doko> slomo: hmm, which changes? I didn't change anything with intent
<slomo> doko: looks like only changes in the generated docs... no idea how you got them but i'll clean the diff next upload :)
<robertj> is knot 2 going to make a showing today?
<Simira> probably (k)not
<robertj> is there (k)nothing that will speed that up?
<Burgwork> robertj, being quiet ;)
<Simira> rumor says that less last-minute updates would
<Burgwork> Simira, you live the man building it, so you should have a pretty good idea of what is happening
<Mez> mdz / keybuk / kamion ping
<Simira> Burgwork: as I said, less last minute updates. I think it's on the doorstep, though.
<doko> Kamion: is it safe for /usr/sbin/elilo to use /bin/bash instead of /bin/sh ?
<Keybuk> zyga: yes
<zyga> Keybuk: hi, it's good to see you
<Keybuk> zyga: delayed answer to your question last night, there :p
<zyga> Keybuk: I still need to read the source but seeing this as an opportunity to improve i18n I wanted to ask you about upstart and possible i18n?
<Keybuk> zyga: yup
<zyga> BTW: libnih is a really cool thing
<Keybuk> *shrug* it's just a cut-price equivalent of glib, etc.
<_ion> Indeed.
<Keybuk> on i18n, in theory upstart is fully i18nised
<zyga> do you think that upstart can be fully i18n?
<zyga> Keybuk: (IMO it's cleaner than glib, but YMMV)
<Keybuk> the principal problem is just deciding where the translations should go
<Keybuk> I thought about putting them in /lib/locale or something
<zyga> Keybuk: right, since it's an init system I was thinking about some special place
<Keybuk> also making sure that the right LANG, etc. is picked up
<zyga> Keybuk: the LANG is sys global, right?
<Keybuk> it's supposed to be, yes
<Keybuk> however it's currently stored in a file only read by PAM, which is only used for login processes
<zyga> I was a bit worried about unbound memory problems that could go with gettext
<Keybuk> how do you mean?
<zyga> well gettext doesn't really free memory and upstart really needs to run forever
<zyga> that and fragmentation can turn to trouble
<Keybuk> really? that's kinda sucky
<zyga> Keybuk: well gettext doesn't really know when you are done using the translated string
<_ion> Do you mean LC_MESSAGES instead of LANG?
<zyga> once it's loaded it's always loaded
<Keybuk> if you use the same string again, does it allocate a new copy, or just use the existing one?
<zyga> _ion: I don't really understand?
<zyga> Keybuk: oh, no it gives you the same string
<zyga> it's just never-free == keep the page forever kind of approach
* _ion probably missed something because he didn't read the whole discussion. :-)
<Keybuk> zyga: that's not that bad, it's just a string overhead
<zyga> Keybuk: but since upstart will always use one language
<zyga> right
<Keybuk> unless you tell it to re-exec itself, which solves the problem anyway
<zyga> Keybuk: that brings me to a separate issue, of translating init.d/* scripts, that's not really easy to do, right?
<Keybuk> zyga: no, translating init.d/* scripts is hard
<zyga> Keybuk: hmm, do you re-exec?
<Keybuk> zyga: you can tell upstart to re-exec
<Riddell> Mithrandir: current kubuntu desktop and alternate CDs are good for release
* zyga is amazed by this interesting approach to limit resource usage/leak
<zyga> really cool stuff to remember :)
<Keybuk> how do you mean?
<Keybuk> it can re-exec itself because you upgrade it
<zyga> Keybuk: I never thought of re-execing the a daemon like that :)
<zyga> it's a good thing
<Keybuk> you obviously want the daemon to stay running, just become the newer version
<Keybuk> so it execs itself, and passes all of its state to the new process with an agreed protocol
<zyga> Keybuk: I'll look at some RH-based distros, especially some localized ones - they somehow translate init.d messages but I doubt thats anything generic :/
<Keybuk> zyga: they probably call gettext in their LSB equivalents
<rodarvus> Keybuk, yes, this is what they do
<zyga> but what if /usr is not available when that stuff gets called?
<zyga> (I obviously know what happens, it's a rethorical question)
* trappist backspaces
<rodarvus> zyga, gettext lies in /bin (or used to) on RH and Conectiva
<Keybuk> rodarvus: where do they put the .mo files though?
<Keybuk> and how do they seed LANG?
<rodarvus> if memory doesn't fails me, it was a rather huge hack
<rodarvus> I think adding the translation to the init.d script itself
<zyga> rodarvus: hmm, that sounds familiar
<rodarvus> Keybuk, don't remember how LANG was seeded, though
<cbx33> ping seb128 
<shining> what's happening with apt/dpkg ? I see a new thing: "Reading state information"
<shining> is this related to the auto-remove feature?
<shining> why are some operations in aptitude or synaptic painfully slow?
<slomo> Keybuk: oh? will we get upstart already for knot2? :)
<robertj> upstart would be a (k)noteworthy adition
<jdong> wow, have the knot2 puns spread to #ubuntu-devel?
* jdong did knot indent for that 2 happen
<jdong> intend*
<Nafallo> hmm, is it a bug in the udev source that it makes two binaries that calls update-initramfs? :-)
<Burgwork> robertj, and a fairly major chnage. Lets get knot2 out the door and then start breaking things
<robertj> Burgwork: I was actually just trolling for a pun :)
<jdong> well, I guess #ubuntu-devel is knot2 quick on catching puns....
<jdong> robertj: come to #kubuntu-devel.... I've already annoyed the living daylights out of everyone with knot2 puns
<Burgwork> oh god
<robertj> jdong: well you already have a collection k-related puns already I'm sure
<jdong> :)
<robertj> it's amateur hour here :)
<zyga> rodarvus: but the message catalogs do not
<slomo> Burgwork: scott's latest uploads are somewhat suggesting that it might happen ;)
<Burgwork> slomo, *grumble*. Means I need to add a section to the Knot2 page
<Keybuk> slomo: no, the plan isn't to have it for knot 2, but for knot 3
<slomo> Keybuk: ok :)
<seaLne> Kamion: just to let you know that kubuntu alternate 20060831.2 seems to be installing fine on lvm
<seaLne> jdong: ^
<jdong> excellent
<jdong> thanks seaLne
<sladen> Keybuk: I do think that before upstart gets too much out the door, it should have the magic "#!/bin/echo this file format is going to change"  or similar
<Keybuk> sladen: why would that help?
<Keybuk> that implies the job files would be executable
<Keybuk> which they absolutely would notbe
<sladen> Keybuk: remove the '!' then.  As discussed in Wiesbaden, the point would be to make people realise that the format is not finalised and not to implement custom job files using it, yet
<ogra> argh
<seb128> cbx33: pong
<cbx33> seb128, I believe you are the person to talk to if I wanted to make a change to the /etc/gconf/2/path file shipped with ubuntu
<cbx33> I'm working on a patch for pessulus with vuntz
<seb128> cbx33: right
<cbx33> so that it has the capability to edit another users key
<seb128> cbx33: we already changed it for sabayon, can't you use the same hierarchie?
<cbx33> current users don't have mandatory keys themself
<cbx33> well, according to vuntz, I'm no gconf expert, it is setup for profiles
<cbx33> where as we want actual user mandatory keys
<cbx33> he was suggesting something like
<cbx33> hang....
* cbx33 goes to find it
<cbx33> xml:readonly:/var/lib/gconf/$(USER)/gconf.xml.mandatory
<cbx33> so we can lockdown each user individually
<seb128> does "$(USER)" work?
<cbx33> i don't know ;)
<cbx33> vuntz, suggested it
<seb128> vuntz: ping?
<cbx33> I can try it in my hacking up pessulus
<seb128> cbx33: I don't think I like the idea
<cbx33> ok
<seb128> cbx33: too much directories to that list
<cbx33> I'll try and do it the sabayon way
<seb128> cbx33: and I don't think an user should be modifying mandatority for somebody else out of the admin user
<cbx33> i was asking as vuntz suggested I ask you
<cbx33> seb128, it would be an admin modifying them
<cbx33> it's for edubuntu
<cbx33> the Student Control Panel
<seb128> ah, admin modifying it for some user or group of user?
<cbx33> yes
<cbx33> seb128, you didn't think I meant just willy nilly editing of other users stuff did you?
<seb128> I did
<seb128> your description was not clear
<cbx33> sorry seaLne 
<cbx33> sorry seb128 
<seb128> " so that it has the capability to edit another users key"
<vuntz> seb128: $(USER) should work
<seb128> vuntz: should or does? ;)
<vuntz> seb128: does, according to the gconf webpage :-)
<seb128> ok
<cbx33> hehe
<seb128> cbx33: that's only one extra path to the list, I'm fine with it
<vuntz> seb128: you didn't expect me to try, did you? ;-)
<seb128> vuntz: not really, no :p
<vuntz> seb128: could be /var/lib/gconf/users/$(USER)/gconf.xml.mandatory to not make /var/lib/gconf/ too filled
<seb128> yeah, I like that option better
<cbx33> seb128, so I can add that to my file for now and we can get it added in the repos later?
<seb128> cbx33: yeah, please open a bug on gconf2 for it
<cbx33> will do
<seb128> bug on launchpad I mean
<seb128> not upstream ;)
<cbx33> yeh
<cbx33> no no
<jdong> what's the status on knot2?
<Simira> when it's ready!!!
<zul> holy crap you asked like 2 hours ago
<jdong> sorry sorry
<jdong> and I wasn't the one who asked
<LaserJock> anybody know current policy for rebuilds?
<bddebian> Has it changed?
<slomo> LaserJock: policy for rebuilds?
<LaserJock> like, are we supposed to do ubuntuXbuild1?
<LaserJock> or just ubuntu(X+1)
<slomo> i still do -Xbuild1 or -Xubuntu(Y+1)
<slomo> depending on whether there are ubuntu changes already or not
<LaserJock> ah
<bddebian> AYe, me too
<dholbach> Mithrandir: I'm a moron - I just uploaded bzr and bzrtools on jbailey's request (without thinking). They're not pulled in by the seeds, but are in main. -- Shouldn't mess up the Knot-2 plans, should it?
<LaserJock> tsk tsk ;-)
<slomo> dholbach: oh, new bzr :)
* bddebian starts singing "How bzr".. ;-P
<dholbach> bzr will build-depend on python-paramiko (source is in main already), it'd be nice if that'd get promoted
<Keybuk> dholbach: err, isn't launchpad frozen to prevent that?
<dholbach> ah, even better, then
<Keybuk> I hope so :)
<Keybuk> because I uploaded a few main things earlier
<Keybuk> like, err, sysvinit
<zyga> how large is the *entire* edgy at archive.ubuntu.com?
<dholbach> they were accepted
<dholbach> and showed up on edgy-changes
<zyga> (with *all* less popular arches?)
<Keybuk> I assumed that if they went through, the knot freeze was over
<Keybuk> since Tollef hasn't actually announced it anywhere
<Kamion> er
<Kamion> we tried to set the distro to frozen
<Nafallo> he said something about his mum and gimp and left :-)
<Kamion> but soyuz broke
<Kamion> please don't upload until Tollef actually announces
<Keybuk> oh
<Keybuk> bit late now :p
<Kamion> announced> see /topic
<Keybuk> Kamion: topic != announce
<bddebian> heh
<Nafallo> hmm updates for sysvinit and friends landed on my PC :-)
<Kamion> Keybuk: yes, but it's thre
<Kamion> there
<LaserJock> mhm, I just updated my pbuilder and saw it go by
<Keybuk> Kamion: something to fix in the policy for next time then ... teach Tollef how to use his e-mail client
<Kamion> let's hope we don't need to update debian-installer for knot-2
<Kamion> because the udev change means I'll have to upload cdrom-detect and iso-scan
<Keybuk> heh
<Kamion> I was expecting you not to do that until tomorrow :)
<Keybuk> oh, why?
<Keybuk> I tend to do things as soon I get bugs about them :p
<Kamion> because I said "after knot-2 is announced"
<Keybuk> and at that point, I'd completely forgotten about the freez
<Keybuk> Kamion: actually, you didn't say that at all
<Nafallo> we all now Keybuk is eager to break boxes, might aswell be knot-2 as knot-3 ;-)
<Kamion> Keybuk: didn't I?
<Keybuk> Nafallo: aye, trying to get everything in place before I go on holiday
<Keybuk> Kamion: no
<Kamion> Keybuk: oh. I thought it :P
<Kamion> Keybuk: you don't have telepathy installed
* Nafallo breaks out in laughter
<Keybuk> Kamion: I do, actually
<LaserJock> yep, apparently we need esp.launchpad.net
<Kamion> or else I have no brain and am therefore not susceptible to telepathy
<Keybuk> anyway yes, I completely forgot about the freeze, and uploaded stuff to main
* Kamion goes to the pub in order to further reduce brain mass
* jdub spies init related upgrades...
<slomo> Kamion: have fun :)
<Keybuk> and then I read an e-mail from tollef saying he'd got infinity to set it to frozen anyway, so I thought "phew, I can do the complicated uploads I had planned today and just have them go through once it's un-frozen"
<Keybuk> so double-bad-me
<jdub> ahr, but no upstart yet
<Nafallo> Keybuk: atleast you where not the only one forgetting about the freeze ;-)
<Nafallo> jdub: universe :-)
<Nafallo> Keybuk: you might fix that shutdown-bug you where so happy about hours ago with an upload? :-)
<Keybuk> Nafallo: as jdub's very astutely guessing, the series of uploads so far have been to make it possible for a future upstart upload to be installed *instead of* sysvinit
<Nafallo> Keybuk: yea, I know. I'm happy for that change anytime now :-)
<Keybuk> Nafallo: assuming this debootstrap works, and installs sysvutils, it'll be in about 3-5 hours
* Nafallo loves broken boxes ;-)
<Nafallo> nice :-)
<HiddenWolf> Keybuk: break the world, then go on holiday? ;)
<Keybuk> HiddenWolf: it'll still be in universe
<Keybuk> I'll file the MIR so that it can get promoted while I'm away
<Nafallo> hehe
<dholbach> Mithrandir: uploaded another bzrtools which fixes a broken build-depends
<Keybuk> I'm only away mon/tues, and not away out of reach of a computer, just celebrating other-half's birthday
<dholbach> Mithrandir: I hope you don't hate me too much for it.
<Nafallo> Keybuk: someone should have your phonenumber is something goes berserk ;-)
<LaserJock> HiddenWolf: heh, I find that humorous, breaking the Universe is much better than breaking the world
<Keybuk> Nafallo: most people do
<Keybuk> SIP/scott@netsplit.com
<Keybuk> :p
<Nafallo> :-)
<HiddenWolf> LaserJock: :D
<Nafallo> LaserJock: ROTFL!
<zyga_> dholbach: I've got a gaim backtrace for you
<Keybuk> not for the first time it occurs that it would be far more efficient to do milestone releases from a copy of the archive, instead of freezing the real one
<dholbach> zyga_: gonna attach it on the bug?
<dholbach> zyga_: did you have a look at the upstream bug it points to?
<zyga_> yes, just a sec
<zyga_> no, I didn't
<zyga_> I'll do in a sec
<zyga_> dholbach: backtrace attached
<dholbach> super, thanks
<zyga_> I also explained how to reproduce it
<shining> hey, right, freezing doesn't make much sense for a test release, does it?
<zyga_> it's really 100% reproducible
* dholbach whines over a11y crashes/etc
<LaserJock> shining: sure it does, we want the test release to be installable, right?
* zyga_ pats dholbach on the back
<zyga_> a11y is really important 
<shining> well, I guess so
<Keybuk> . o O { now, I wonder what happens if I make sysvinit no longer Essential ... }
<LaserJock> mwuahahaha
* LaserJock goes back to the lab, cackling 
<Keybuk> we'll find out in 7 minutes
<jdub> so what's with this python-gdbm / python-2.5 stuff?
<Mithrandir> Riddell: yay, thanks.
<Mithrandir> ogra: how are you, release-wise?
<doko> Mithrandir: alternate amd64 CD is ok, although the ati driver isn't capable of doing 1920x1200
<Mithrandir> doko: thanks.
<doko> infinity: fglrx still sucks. X cannot be shutdown without freezing the kernel
<doko> (amd64)
<doko> hmm, is hdparm supposed to work on amd64?
<doko> $ sudo hdparm -B 128 /dev/sda
<doko> /dev/sda:
<doko>  setting Advanced Power Management level to 0x80 (128)
<doko>  HDIO_DRIVE_CMD failed: Input/output error
<Mithrandir> yes, it should
<Keybuk> doko: err
<Keybuk> HDparm
<Keybuk> SDa
* Keybuk leaves you to figure it out
<Keybuk> :p
<jdub> hdparm is supposed to work with libata now though, innit?
<Mithrandir> Keybuk: yes, and?
<Keybuk> jdong_: no?
<Keybuk> jdub: no?
<Keybuk> sdparm does
<jdub> doko: python-gdbm / python-2.5
<jdub> doko: are we moving to python-2.5? :)
<Keybuk> Mithrandir: sdparm works with sd*, hdparm works with hd*
<dholbach> jdub: not for edgy
<Keybuk> hdparm on a sd* won't do much
<doko> jdub: yes, but not as the default. python-gdbm is a bug
<jdub> doko: ahr, okay - thanks
<doko> Keybuk: so we should seed sdparm, and not hdparm?
<Nafallo> sdparm is still in universe :-P
<Keybuk> there's not much call for sdparm ... chances are if your drive is showing up that way, the controller got the settings right
<doko> Keybuk: any hint how to get/set the acoustic management?
<Keybuk> doko: no idea, I'm afraid; including if you even can
<HiddenWolf> doko: virgin, goat, sharp knife, full moon?
<HiddenWolf> If you ever figure it out, please put it on the wiki. :)
<bddebian> heh
<jdong_> doko: some drives don't support acoustic management
<jdong_> and that's the kind of error you get back when you try to use it
<jdong_> and hdparm appears to work just fine on my SATA laptop hd... :-/
<Keybuk> jdong_: yeah, it works on some of the drivers
<jdong_> (intel centrino duo chipset, ich8 i believe)
<Keybuk> depends whether they implemented the legacy ioctls
<jdub> Mithrandir: did you do the latest vmware-player update?
<jdong_> Keybuk: ah, I see
<bddebian> Shit, doko, I'm sorry, do you still have that URL for azureus handy?
<doko> bddebian: cvs.fedora.redhat.com
<bddebian> doko: thx.
<slomo> doko: installing python2.3 breaks atm because of python-central... known problem?
<jdub> lca2007.linux.org.au/cfp
<jdub> ^ haven't seen much from you slackers
<Mithrandir> jdub: no, should I?
<Keybuk> jdub: it's expensive to get there
<Keybuk> throw in the flights and hotel, and I'll come :p
<jdub> Keybuk: what do you think the "i need travel assistance" checkbox is for?
<Keybuk> jdub: last time I was offered 25% of the flight because I was "too far away to be considered"
<Nafallo> get a wheelchair and a jdub to drive you? :-)
<jdub> Keybuk: can't sponsor flights from uranus
<bddebian> hahah
<Keybuk> if my anus could pay for the flight, I'd come :p
<jdub> Nafallo: insurance doesn't cover me at the wheel
<Treenaks> hm... Dave Airlie just committed a potential fix for a _long_standing Ati bug.. does anyone have an idea how I could test it?
<jdub> Keybuk: can be arranged. accom in kings cross.
<Treenaks> (as I'm suffering from the bug..)
<zyga> Treenaks: what is that bug?
<Treenaks> zyga: the 'no output, fixed by MonitorLayout' one
<zyga> hmm, if I can help you with testing that feel free to ask
<Treenaks> zyga: https://bugs.freedesktop.org/show_bug.cgi?id=5473 + http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=caaed927a07ffbac68b08246185ef93c1e7bb98c
<Ubugtu> Freedesktop bug 5473 in Driver/Radeon "Blank screen with Radeon Mobility X700 (Acer Ferrari 4005)" [Normal,Reopened]  
<Treenaks> patch is 5 minutes old ;
<Treenaks> )
<zyga> that's one fresh patch :D
<Keybuk> jdub: ok, proposal submitted :p
<Treenaks> zyga: I was just checking freedesktop gitweb, to see if anything had been committed recently :)
<jdub> Keybuk: as a personal prompt, i'd imagine a talk about upstart would be worthwhile in that timeframe
<zyga> Treenaks: boy, radeon code sure looks ugly
<Keybuk> jdub: oddly enough, that's exactly what I just proposed :p
<Nafallo> haha
<Treenaks> and if I understand it correctly, it might ALSO fix my 'wobbly image' bug
<jdub> Keybuk: cool
<Nafallo> Keybuk has telepathy :-)
<Treenaks> nah, the Gnome people can talk about Telepathy :P
<jdub> Keybuk: besides, you can tell canonical it's important for you to go
<Nafallo> ...because jdub said so :-)
<Keybuk> jdub: that only gives me the paid leave
<Keybuk> we still have to pay our own way to get and stay there, remember
<Treenaks> Keybuk: 'a temporary raise', you mean? :P
<jdub> Keybuk: not if it's important for you to go
* Nafallo thinks jdub tries to say: not if it's important for Canonical's code to spread :-)
<sistpoty> hi
<sistpoty> can any core-dev give me an ack for bug 58046 please?
<Ubugtu> Malone bug 58046 in sdl-image1.2 "please sync sdl-image1.2 [main]  (1.2.5-2) from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58046
<dholbach> good night everybody!
<madduck> Keybuk: lftp rocks :) thanks!
<sistpoty> gn8 dholbach
<dholbach> night sistpoty, night seb128
<seb128> 'night dholbach
* jdub hugs dholbach, seb128 
* seb128 hugs jdub dholbach
* dholbach hugs jdub back
* robtaylor hugs dholbach 
* Keybuk hugs everyone
<dholbach> hey robtaylor! :-)
<bddebian> Oh man it's a -devel love-in.. :)
<sfllaw> Woah.  I walked in at an awkward time.
* sfllaw turns around.
* Keybuk hugs sfllaw 
<sfllaw> Aw what the hell.
* sfllaw hugs Keybuk back.
<Keybuk> upstart so needs a logo
<jdub> Keybuk: freckly, rosy-cheeked kid with a tushy face
<HiddenWolf> +1
<Treenaks> jdub: http://msig.info/web2v2/(reflect)Upstart%202.0%20BETA.png
<sfllaw> Treenaks: That's very flickr-esque.
<jdub> heh
<jdub> Treenaks: i hate that site.
<Treenaks> sfllaw: it's also dynamically generated   the URL :)
<theCore> Keybuk, oh hello, I was just going to fill a bug in upstart
<Treenaks> +from
<jdub> Treenaks: i've had four separate logo suggestions for four separate projects from it. ;)
<Treenaks> jdub: then it MUST be cool!  :P
<theCore> Keybuk, I'm not sure if it's related to upstart directly 
<gnomefreak> LaserJock: ping
#ubuntu-devel 2006-09-01
<Keybuk> theCore: oh aye, what was the problem?
<theCore> Keybuk, bug 58396
<Ubugtu> Malone bug 58396 in upstart "System doesn't showdown via ACPI" [Untriaged,Fix committed]  http://launchpad.net/bugs/58396
<Keybuk> ah yes, just replied to that one
<Keybuk> it is, as you suspected, that there is no upstart-esque shutdown command in the package in universe
<theCore> ah, nice
<theCore> Keybuk, btw, I'm trying to make a logo upstart, maybe you will like it
<theCore> for upstart*
<theCore> it's arrows shaped in a sort of infinity sign 
<LaserJock> gnomefreak: pong
<gnomefreak> did you ever get python-tk issue worked out?
<LaserJock> oh, it worked itself out
<gnomefreak> ok cool
<LaserJock> or somebody did it
<Keybuk> theCore: sounds intriguing
<gnomefreak> do we take gnome-menu from gnome or do we use our own?
<jdub> does anyone 'own' printer stuff atm?
<tseng> jdub: pitti has always owned it afaik
<robertj> jdub: what do you think about nixing SOC from the planet now?
<visik7> hi
<visik7> will linux-phc patch be integrated into ubuntu kernel ?
<jdub> robertj: hrm?
<robertj> p.g.o
<jdub> robertj: i think you are in the wrong channel :)
<sladen> visik7: what's the patch do?  You'll need to make a case for it, you could ask in the #ubuntu-kernel channel or propose a specification by starting one at  https://launchpad.net/distros/ubuntu/+specs
<volvoguy> hey folks, sorry to ask this here. i was about to try out kubuntu knot-1 on my canonical laptop and realized knot-2 is scheduled for today. is it still scheduled for today? :)
<nictuku> is there any package with debconf scripts for creating SSL certificates?
<nictuku> I would like to use one as my template
<theCore> Keybuk, I think I got something: http://peadrop.com/files/upstart.png
<theCore> and for the source http://peadrop.com/files/upstart.svg
<Keybuk> theCore: I like the bottom one of the two arrows ... that works on its own, no?
<theCore> Keybuk, yea
<theCore> Keybuk, it's just two duplicated arrows
<Keybuk> needs some colour :p
<theCore> yeah :)
<theCore> blues?
<Keybuk> nah, something ! blue
<theCore> red?
<Keybuk> uh, not blue
<Burgwork> orange fading to red?
<theCore> uh, lets try that
<Burgwork> and I would try only one arrow
<theCore> yeah, I like that idea
<mbiebl> Keybuk: Is upstart also intended to replace all these scripts in /etc/ppp/*.d/, /etc/network/*.d, /etc/dbus/even.d/ etc. ?
<Keybuk> mbiebl: eventually, yes
<mbiebl> etch+1?
<mbiebl> That would be great!
<bluefoxicy> ubuntu etch?  what?
<mbiebl> s/etch/edgy/
<mbiebl> (can happen)
<bluefoxicy> I need a white board, my brain needs swap space for this, damn.
<mbiebl> One thing I was wondering is how a user can disable a service from being started
<Keybuk> mbiebl: how would you like them to be able to disable them?
<mbiebl> Say, ssh install /etc/even.d/ssh, which should be started as soon as the "network_available" event is triggered.
<mbiebl> There could be users, who don't want ssh to be started.
<Keybuk> "users" ?  or "system adminstrators" ?
<mbiebl> ok, system administrators then.
<Keybuk> right, so there's a whole bunch of ideas
<Keybuk> a) it's a conffile, the "start on ..." bits can be removed
<Keybuk> b) _ion has suggested adding a "disabled" entry to the config file
<Keybuk> c) it can be removed
<Keybuk> (a) has the advantage that it can still be manually started
<Keybuk> where (b)/(c) have the advantage that it cannot be
<mbiebl> Ah, ok. This ideas should be added to the wiki then
<Keybuk> yeah, should get a wiki together really
<Keybuk> and a website
<Keybuk> and stuff
<theCore> Keybuk, with colors, http://peadrop.com/files/upstart.png
<robtaylor> theCore: nice :)
<Keybuk> theCore: could you make the "underneath" obviously lighter ?
<Keybuk> ie. grey or some other colour?
<theCore> yeah
<Keybuk> I liked the tail effect it had last time
<theCore> like that? http://peadrop.com/files/upstart.png
<robtaylor> theCore: the top line overhanging on the left looks like a rendering error rather than a deliberate choice
<Keybuk> still too dark, lighter! :p
<Keybuk> maybe grey to white, rather than black
<theCore> robtaylor, I know that, I need to adjust it 
<robtaylor> theCore: ah, cool :)
<ohoel> upstart works like a real charm
<jdong|coreduo> does it shut down now?
<jdub> Keybuk: should i test upstart on my laptop or server?
<jdub> Keybuk: which use cases are you missing atm?
<Keybuk> jdub: laptop, until the upload that has shutdown etc. is in
<jdub> Keybuk: did that md/uuid stuff get a look in?
<theCore> Keybuk, now?
<Keybuk> jdub: fabbione is supposed to be looking at that
<Keybuk> theCore: url?
<theCore> oups, forgot scp 
<theCore> same url again
<theCore> robtaylor, fixed
<Keybuk> theCore: that looks cool
<Keybuk> the colours make it look a *bit* too much like the firefox logo though, no? :p
<jdub> heh, yeah
<theCore> that's what I thought too
<theCore> a small variant http://peadrop.com/files/upstart-rounded.png
<Keybuk> also the arrow is lop-sided, not sure whether that's deliberate or not?
<Keybuk> oh, definitely prefer the sharper one
<theCore> any other colour idea?
<theCore> what about yellow/black?
<theCore> like a banana
<Keybuk> try a few ideas
<Keybuk> green suggests "start" usually?
<theCore> I will try that (black/yellow looks like vomit in gradient)
<ohoel> there's a small glitch in that image
<jdub> how about
<jdub> a green arrow
<jdub> pointing up
<ohoel> about where the red tip points toward the gray, the black border is two straight lines meeting eachother instead of a curve
<jdub> it could even be the tango up arrow
<jdub> and then, in bold letters, probably half-logo-height
<jdub> "DO IT"
<ohoel> how about a flying herring?
<Burgwork> words in logos are general frowned upon, for i18n reasons
<jdub> i knew some anal retentive freak would mention that
<jdub> and thoroughly miss the point!
<robtaylor> theCore: sweeet :)
<ohoel> something that alludes to evolution perhaps.. ala http://www.mnpublius.com/evolution.jpg
<theCore> http://peadrop.com/files/upstart-green.png
<ohoel> the start of all things :p
<ohoel> too complex for a logo, probably
<Keybuk> jdub: what was the point?
<Keybuk> theCore: the black doesn't work there, does it?
<Burgwork> ohoel, make it just the outline and it becomes simpler and more interesting
<theCore> Keybuk,  hmm, good point
<ohoel> this'll be an excellent time to install inkscape
<theCore> now a radioactive version: http://peadrop.com/files/upstart-green.png
<ohoel> I think the green should be more in the tangerine/human/tango style
<ohoel> though talking about green and human in the same sentence is a bit.. off
<theCore> did my last message got through? my connection choked for a sec
<theCore> in case not, here a radioactive version: http://peadrop.com/files/upstart-green.png
<Keybuk> theCore: yeah, a bit ... bright
<Keybuk> maybe just make the green two different greens
<Keybuk> perhaps a darker tangoish one?
<Keybuk> even if the tango up arrow looks like a monopoly house
<theCore> ok, 
<ohoel> http://appelsinjuice.org/strekmenn.png <- evolution in a stroke!
<Keybuk> ohoel: why is Jesus at the front?
<Burgwork> Keybuk, be nice
<Burgwork> ohoel, drop the cross
<ohoel> Yes, my thought too
<ohoel> I just traced the image I showed you earlier
<Keybuk> Burgwork: I didn't mean it not-nicely
<theCore> should I drop the black for a tango-look?
<jdub> yeah, some arrows *dream* of being monopoly houses
<ohoel> It's okay, my opposition to any religious symbols in a linux distro is strong
<Keybuk> theCore: no, I like black outlines :)
<theCore> noted
<ohoel> theCore: I think the outline is perhaps a bit too heavy
<ohoel> softening it or adding a brighter outer copy of the arrow would make the arrow alot more friendly
<theCore> http://peadrop.com/files/upstart-green.png green/green not tangoish
<Keybuk> theCore: still rather yellow
<ohoel> are you using a radial gradient?
<theCore> oups
<theCore> ohoel, yes
<theCore> ok, uploaded now
<ohoel> that's probably best :) looks like it could use a smoother transition, though
<ohoel> I see all the steps between yellow and the pastel-green
<Keybuk> theCore: that looks better;  it might be nice if there was a less subtle transition -- like the "glassy"(?) effect they do sometimes where it's just two colours and a pretty shape?
<theCore> Keybuk, it could be done
<Keybuk> it's _almost_ right, but just lacking something
<Keybuk> dunno waht
<theCore> http://peadrop.com/files/upstart3.png
<Keybuk> hmm, the shape isn't right, and it doesn't want the blur, but I quite like that
<theCore> it doesn't want the blur?
<Keybuk> no, I don't think it does
<ohoel> http://appelsinjuice.org/strekmenn.png no cross :] 
<ohoel> this somehow reminds me of the GNU logo
<theCore> Keybuk, like that? http://peadrop.com/files/upstart3.png
<Keybuk> theCore: looks cool
<Keybuk> maybe bring the darker bit up a bit?
<theCore> both greens?
<theCore> sorry
<theCore> now? http://peadrop.com/files/upstart3.png
<Keybuk> hmm, that looks ok
<Keybuk> there's not quite enough of the dark bit though
<gnomefreak> where are the knot-2 images?
<gnomefreak> nvm looks like they were not released yet
<ohoel> is simon law here?
<gnomefreak> hes here somewhere maybe sleeping
<ohoel> I wonder what led him to set sourcepackage powernowd on bug 22336 ;] 
<Ubugtu> Malone bug 22336 in powernowd "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  http://launchpad.net/bugs/22336
<theCore> Keybuk, http://peadrop.com/files/upstart3.png
<Keybuk> theCore: *there we go!*
<Keybuk> the only error there is that the right hand side of the arrow is cut off
<theCore> oh, yeah I didn't saw it
<theCore> it looks like an export error
<theCore> Keybuk, it is fixed
<Keybuk> kewl
<theCore> Keybuk, here the Inkscape SVG: http://peadrop.com/files/upstart-logo.svg
<sfllaw> ohoel: You're right.  That's an ACPI fan thing, isn't it?
<sfllaw> ohoel: Well, it's sort of sketchy.  I think the laptop overheats while the fan is going, so maybe powernowd should be scaling back the CPU?
<theCore> Keybuk, and the final PNG: http://peadrop.com/files/upstart-logo.png
<theCore> I hope you like it
<Keybuk> theCore: yup, many thanks :p
<sfllaw> theCore: Nice.
<theCore> sfllaw, thank you
<de_wizze> what are the future planet for the multimedia platforms in Unbuntu, along the lines of "What are the prospectives for things lick NMM and PolyAudio or the like ( Im not sure how Gstreamer relates to PA)
<ohoel> sfllaw: the bug report is a bit overflowed with different setups, but in my case, atleast, it seems the fan just doesn't spin up fast enough... I'm not even sure whether that's just a hardware "feature" or a bug, but I didn't notice any problems back when I used XP on this machine
<ohoel> right now the cpu throttles up to 1.6Ghz, while the fan start spinning up slowly several seconds later, so if the CPU was hot enough before, it'll lead to the bug
<sfllaw> ohoel: Bleh.
<sfllaw> ohoel: It does sound like either the fan isn't spinning up soon enough, so the temperature threshold is too high.
<sfllaw> Or the fan is spinning, but the computer is poorly designed, so the CPU needs to be throtled back.
<sfllaw> In short, hardware is terrible.  :(
<mjg59> I still don't understand
<mjg59> Thermal shutdown shouldn't occur until you've got past the passive cooling trippoint
<mjg59> At which point the CPU should be throttled back down
<mjg59> It's got nothing to do with the speed at which the fan changes
<mjg59> And you'd expect the fan to lag behind the frequency change - it won't speed up until the temperature crosses a threshold
<Trae> sfllaw, boo
<sfllaw> mjg59: What if it's software controlled?
<Trae> sfllaw, ;)  I see you are working on the Overheat bug... 
<sfllaw> mjg59: There are some BIOSes that delegate this behaviour to the OS.
<ohoel> mjg59: in linux, at least, it doesn't seem like my fan is triggered by temperature changes
<Trae> sfllaw, if there is anything I can do for you to help let me know.  I can't code but I can be a guinie pig
<mjg59> sfllaw: That's the usual case
<mjg59> ohoel: Do you have anything in /proc/acpi/fan ?
<Trae> sfllaw, as long as you promise not to nuke my laptop *chuckle*
<sfllaw> mjg59: The fan kicking in won't instantly have effect.
<mjg59> sfllaw: The ACPI spec only lets you do this based on temperatue changes
<ohoel> mjg59: no, it's a void
<mjg59> sfllaw: I don't see why that's relevant
<mjg59> sfllaw: The idea isn't to keep the CPU at a constant temperature
<mjg59> ohoel: Then the fan isn't under Linux's control, and will behave identically under Windows
<mjg59> So that's unimportant
<mjg59> sfllaw: The aim is to keep the temperature below the critical level
<mjg59> sfllaw: There's two mechanisms for doing that - increasing the fan speed and decreasing the cpu speed
<ohoel> mjg59: are you sure it *shouldn't* be under linux's control, though?
<mjg59> sfllaw: The issue in this bug would, if anything, appear to be that the second of these isn't working
<sfllaw> mjg59: Right.  If your fan doesn't cool the CPU fast enough, it will keep heating up.  Thermal changes aren't instantaneous.
<mjg59> ohoel: Can you attach dmesg?
<mjg59> sfllaw: That's fine, and that's within spec
<mjg59> sfllaw: But that's got nothing to do with how long it takes before the fan turns on
<mjg59> As long as you ignore the pathological case of the fan not turning on until after the machine has turned off, of course
<sfllaw> mjg59: Didn't ohoel claim that the fan didn't turn on when his laptop was already too hot?
<mjg59> sfllaw: If the fan isn't in /proc/acpi/fan, that's not under our control
<Burgundavia> mjg59: quick question: I have been having occurances where my laptop turns on full at bootup and never turns off. However, it is totally intermittant. What can I do to usefully debug the issue?
<sfllaw> mjg59: Fair enough.
<mjg59> But that's besides the point - we /still/ shouldn't hit the critical shutoff because the passive cooling should kick in
<mjg59> Burgundavia: What machine?
<ohoel> mjg59: done
<Burgundavia> mjg59: Toshiba Tecra A5
<Trae> Burgundavia, I've seen that too.
<Burgundavia> Trae: only on some bootups but not others?
<Trae> Burgundavia, yup
<Trae> hpDV4150us
<mjg59> HPs have entirely different problems
<mjg59> I'm keeping an eye on that
<Trae> Burgundavia, if I suspend, the fan goes to "normal" operating mode
<Trae> Burgundavia, give that a try
<mjg59> sfllaw: So the issue before was with machines that don't have ACPI throttling, just voltage scaling
<Burgundavia> Trae: that doesn't work for me. I think we are seeing different issues, even though they have the same symptoms
<Trae> like my fan now is on full bore since I powered up the lappie.... but when I suspendk it'll throttle down and act nicely
<Hobbsee> morning all
<mjg59> Which requires the use of the ondemand governor rather than the performance one, otherwise the kernel can't slow down the CPU
<Trae> Burgundavia, ahh okies sorry
<Burgundavia> no worries
<mjg59> We need to fix that, but it doesn't seem that it fixes ohoel's problem
<mjg59> (And what's the bug number for this again? Launchpad has decided to stop mailing me)
<Trae> Burgundavia, back... just suspended, and then resumed... fan is off now :)
<Burgundavia> mjg59: for my bug?
<Trae> crazy
<ohoel> probably irrelevant, but every time I get the critical shutdown the fan suddenly starts going crazy before poweroff
<ohoel> mjg59:  bug 22336
<Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  http://launchpad.net/bugs/22336
<Trae> ohoel, yah me too
<mjg59> Trae: HPs are a different problem
<Trae> mjg59, why are the symptoms the same?
<mjg59> Trae: Because both problems involve the machine getting too hot and switching off
<Trae> mjg59, ahh hehe
<mjg59> There are many ways of getting to that situation
<mjg59> ohoel: Ok, the fact that there's nothing in /proc/acpi/fan is correct
<mjg59> Your fan is under BIOS control
<Trae> ok, I'll shush... but please, let me know if I an help you guys in any way
<mjg59> It's absolutely not a problem that it only starts spinning faster a short while after you increase the system load
<mjg59> It's tied to temperature, not CPU speed
<Burgundavia> Keybuk: your blog is already #2 in google searchs for upstart
<ohoel> mjg59: if I leave the machine idle for hours, it's flaming hot when I return, which leads me to believe it's load-activated rather than temperature activated
<mjg59> ohoel: Well, it is an elitegroup
<ohoel> yea :(
<mjg59> So I guess it's /possible/ that they're that stupid
<dcode> is there a way to get more detailed information from debian-installer?  like why a particular step is failing?
<mjg59> dcode: alt+F3 or alt+F4 should give you more information
<dcode> ah....got it....thnx.....  /target is still ro....that would explain why base system would fail
<dcode> :)
<Keybuk> meh
<Keybuk> for my next project, I will pick something I can fucking attach gdb/strace to
<Burgundavia> Keybuk: in other news, upstart already has wikipedia article, has apparently pissed off people from debian and general excited the blogosphere. Congrats on your new found fame ;)
<Keybuk> "pissed off people from debian" ?
<Keybuk> that bit I hadn't noticed
<wasabi> upstart? is that the new init thingy?
<grexk> Keybuk: Me either, I was amazed with your upstart...
<jdub> Keybuk: "that scott guy, he's just a f@#$king little..."
<jdub> UPSTART
<ohoel> mjg59: I'm not sure what to think. In windows the fan would sometimes spin up while the machine was idle, so the exterior of the laptop never got really hot like I'm experiencing now
<dcode> I read about upstart today on UP....sounded cool
<wasabi> Yup. Nice.
<mjg59> Keybuk: So, what should we do about powernowd?
<wasabi> Nice name. I heard the convo in here, and instantly associated it with init.
<Keybuk> mjg59: ondemand works nicely for me
<ohoel> I wish I could figure out whether there's a temperor sensor at all here, 
<mjg59> Keybuk: Right
<mjg59> Keybuk: So we need the init script to deal with that
* wasabi installs upstart.
<ohoel> I'll try contacting ECS+the retailer and ask a bit about the cooling system used, then add it to the bug when/if they reply
<Trae> Keybuk, heh
<Keybuk> so, who wants to fuck their computer over? :)
<Hobbsee> hah
* Hobbsee hides
<Keybuk> http://people.ubuntu.com/~scott/packages/
<wasabi> Heh. I just did a dist-upgrade, and my initrd.img regenerated no less than 6 times.
<wasabi> Total time wasted: 15 minutes
<Keybuk> install both upstart and upstart-compat-sysv  (up-to-date edgy only)
<wasabi> Keybuk: I'm about to do so.
<wasabi> Bringing system up to date first.
<Keybuk> mjg59: interestingly, I can't help but wonder whether the "laptop shuts down" problem is related to the fact I can't boot half the time
<Keybuk> the laptop shuts itself down if you don't get to userspace fast enough
<mjg59> ?
<mjg59> Oh
<mjg59> Because fan isn't loaded until then?
<wasabi> So upstart scripts in upstart.d are parsed files?
<mjg59> Possibly we should link it in
<wasabi> Parsed at upstart boot or ?
<Keybuk> wasabi: /etc/event.d ... parsed at boot
<wasabi> event.d
<Keybuk> or whenever they're changed
<Trae> Keybuk, heh, what kind of evil have you created?
<Trae> oh upstart
<Trae> yeah I'll pass on that one
<Trae> :)
<Keybuk> mjg59: dunno, it usually comes up with some lie like "Critical temperature 102 C reached"
<mjg59> Right
<Keybuk> which is a bit odd
<mjg59> We should probably load the modules earlier
<mjg59> Or have them linked in
<Keybuk> why do they lie about the temp though?
<wasabi> heh. nice.
<wasabi> "removing sysvinit in favour of upstart"
<mjg59> No clue
<Keybuk> wasabi: you'll discover, in a moment, the one "upgrade procedure" bit I haven't worked out yet
<wasabi> it still named /sbin/init?
<Keybuk> try rebooting ;)
<wasabi> seems to be.
<wasabi> heh. k
<wasabi> brb, maybe. ;)
<wasabi> haha shutdown broke. ;) yay
<poningru> mako: awesome pic http://defectivebydesign.org/sites/nodrm.civicactions.net/files/images/ff_boston1.jpg
<Keybuk> heh
<Keybuk> of course, the shutdown you installed was for upstart ;P
<Keybuk> reboot -f would have worked
<Burgundavia> Keybuk: any idea what mvo obsoleted https://features.launchpad.net/distros/ubuntu/+spec/network-wide-updates
<Burgundavia> Keybuk: especially given there is an implemementation in the works
<wasabi> Amazing. WOrked.
<wasabi> Nice early console too.
<Keybuk> Burgundavia: no idea, he doesn't say
<Keybuk> wasabi: heh, I put it there because I couldn't think of anywhere better
<Burgundavia> no, he doesn't
<wasabi> Something ate Xgl.
<wasabi> Probably unrelated though.
<wasabi> Well, looks like it works then.
<Burgundavia> my mind, of course, wanders into thought of that mysterious landscape-client
<wasabi> How is getty handled?
<Keybuk> Burgundavia: the what now?
<wasabi> inittab style or ?
<Keybuk> wasabi: less /etc/event.d/tty[123456] 
<wasabi> nice. awesome.
<wasabi> these files are fucking CLEAN.
<wasabi> what a blessing. ;)
<bluefoxicy> ouch
<bluefoxicy> wtf.
<Keybuk> wasabi: yeah, I'll get around to adding lots of ':' to them later :p
<bluefoxicy> I just tried to open an image in GIMP and that kernel bug popped up again >:|
<wasabi> It started up Very quick, by the way.
<bluefoxicy> [17793612.096000]  BUG: unable to handle kernel NULL pointer dereference at virtual address 00000074
<wasabi> Obviously moving rc scripts to this will increase it massively.
<bluefoxicy>  23:49:11 up 7 days,  2:35,  9 users,  load average: 1.79, 1.17, 0.82
<Burgundavia> Keybuk: this thing http://packages.ubuntu.com/dapper/admin/landscape-client
<Keybuk> wasabi: no, you just think it did :p
<Keybuk> Burgundavia: what's that? :)
<wasabi> Yeah. =)
<mjg59> bluefoxicy: Either one of your drivers is scribbling over memory, or your hardware is fucked
<wasabi> The console made it felt so.
<Burgundavia> Keybuk: I wish I knew
<Keybuk> wasabi: *nods* compare bootcharts
<Keybuk> wasabi: btw, do you like how I did runlevels? :p
<Keybuk> Burgundavia: I wish I could tell you
<jdub> Keybuk: you want to shift all main scripts to upstart for edgy?
<Keybuk> jdub: no, not for edgy
<wasabi> Yeah. As event.d scripts.
<wasabi> I'm trying to parse the rc* stuff in here.
<Keybuk> wasabi: you can even still run "runlevel" :p
<jsgotangco> after the metro memes we can now expect an airlines meme real soon now
<wasabi> Looks like this is just running 'rc'
<Keybuk> wasabi: yup
<wasabi> I need to comprehend the start on rc1/start stuff.
<wasabi> Those are just named events?
<Keybuk> along with a sick bit of script around it to stick something in utmp (runlevel --set) and make sure the environment is right
<Keybuk> yes
<Keybuk> rc1/start occurs when the rc1 job is started
<Keybuk> it means if you're in the middle of going through rc2, and you "telinit 3", the rc2 process is killed
<Keybuk> uh "telinit 1" :p
<Keybuk> (telinit is a verrrry trivial program ... it does "start rc$argv1") :p
<wasabi> Alright. So basically we just have named events. Each file in event.d has a "start on" line, which lists another named event.
<wasabi> and some stop ons.
<wasabi> That means stop Me when that event occurs.
<Keybuk> yup
<wasabi> And start Me when that other event occurs.
<Keybuk> http://www.netsplit.com/blog/work/canonical/upstart.html
<wasabi> "startup" is an event generated by ?
<Keybuk> upstart itself
<wasabi> Makes sense. Some predefined events.
<Keybuk> pre-defined are "startup" and "shutdown"
<Keybuk> semi-defined are "halt", "reboot", "poweroff" and "maintenance"
<wasabi> What about these events rc1/start?
<wasabi> What triggers that?
<Keybuk> upstart will generate events for jobs as they change state
<wasabi> Ahh, jobname/$predefinedname
<Keybuk> so jobs can start/stop other jobs
<Keybuk> yes
<Keybuk> the event stuff isn't *quite* right yet, but it's close enough
<Keybuk> (for edgy, at least)
<wasabi> I like.
<wasabi> The model is much more appropiate than a flat thing, or even launchd.
<Keybuk> jobs must have either "exec foo bar baz" or "script ... end script"
<Keybuk> which is the thing that's actually run
<wasabi> or "respawn"
<Keybuk> (respawn foo bar baz is just a short cut)
<Keybuk> exec foo baz baz
<Keybuk> respawn
<Keybuk> -- and --
<Keybuk> respawn foo baz baz
<Keybuk> are the same :p
<wasabi> Ahh.
<Keybuk> respawn defines a service instead of a task
<Keybuk> eg. the gettys are services, whereas the rcs are tasks
<wasabi> rcS is defined as starting on startup. Does that happen in parallel with other things which "startup"
<Keybuk> you can also have scripts run before the job is started, after it's stopped, or between respawns
<Keybuk> yes
<Keybuk> all jobs are started simultaneously
<wasabi> Think it might be better for sysv compat to run after upstart native tasks?
<Keybuk> wasabi: maybe, we'll see
<wasabi> As things get migrated from sysv to upstart, you would expect them to go in dependency order.
<Keybuk> initially we want it the other way round :p
<wasabi> Yeah. Heh.
<wasabi> It'll have to be built in order.
<Keybuk> http://people.ubuntu.com/~scott/example
<Keybuk> if you stick that in your /etc/event.d directory and run "start ping" you'll note
<Keybuk> 1) you have a /var/run/PINGING with STARTED in it
<Keybuk> 2) ping 127.0.0.1 is running
<wasabi> gotta get to X.
<Keybuk> 3) if you kill the process, it'll come back, and /var/run/PINGING will get a KILLED appended to it
<wasabi> Have to fix X. =(
<Keybuk> 4) when you "stop ping", the process and file go away
<wasabi> hmm. gdm locked up.
<Keybuk> heh
<Keybuk> just wget :p
<wasabi> that's a first.
<jdub> Keybuk: will event scripts be hashbang files (maybe with upstart as the binary)?
<Keybuk> jdub: NO
<wasabi> Haha.
<wasabi> event scripts are super simple... two lines:
<jdub> Keybuk: so you must use something like service to operate events?
<wasabi> start on startup
<wasabi> exec command
<Keybuk> jdub: yes
<jdub> Keybuk: makes policy clear ;)
<Keybuk> right, it makes it much more damned obvious what you're trying to do
<jdub> Keybuk: taking bets on how long it will be until someone makes a dbus activation frontend? :)
<Keybuk> jdub: hoping someone will do something dbusy
<wasabi> The management utilities are "start"
<wasabi> and apparently, "stop"
<Keybuk> and "status"
<jdub> Keybuk: so you fully intend for events to be useful to the whole stack (server to desktop, etc)?
<wasabi> What about custom events?
<Keybuk> wasabi: initctl trigger wibble
<wasabi> ahh.
<jdub> Keybuk: to the point that upstart could replace swathes of nm?
<Keybuk> jdub: don't see why not, though I'd say that upstart isn't a session manager
<wasabi> So, simple predefined commands, another initctl one for whatever.
<Keybuk> right
<jdub> Keybuk: will you define a standards process for events?
<wasabi> Hmm. That is interesting.
<Keybuk> jdub: it may be wise
<wasabi> THe idea of just using upstart to launch gnome.
<wasabi> A per-user copy.
<Keybuk> they may end up being namespaced ... e.g. ~jdub/cron/foo
<jdub> Keybuk: x-rhgb
<jdub> Keybuk: maybe go through lanana?
<Keybuk> I'm trying to avoid inventing things before we need them ... which is hard when everyone asks questions :p
<jdub> heh
<wasabi__> Keybuk: link to sample ping thing again?
<Keybuk> http://people.ubuntu.com/~scott/example
<jdub> PINGTHING
<wasabi__> So, just saved the file.
<Keybuk> right, copy it into /etc/event.d
<wasabi__> ahh. cool.
<wasabi__> worked.
<wasabi__> That's about the coolest thing ever. Already migrated one of my init scripts over.
<Keybuk> heh, careful cause the config format ain't fixed yet
<wasabi__> Hmm. sysvcompat stuff should advertise each script that it runs as an event.
<Keybuk> "advertise" ?
<wasabi__> trigger.
<wasabi__> So that I can have an upstart event that depends on a particular rc script being run.
<Keybuk> that's a good idea
<wasabi__> Would ease migration.
<wasabi__> Hmm. Lets see. I want to make gdm run... in rc5, ... S13.
<wasabi__> But it really depends on S12dbus.
<wasabi__> Maybe.
<wasabi__> Actually gdm probably doesn't.
<wasabi__> Or maybe simply have it trigger sysvcompat_gdm/start
* wasabi__ shrugs.
<wasabi__> I dunno.
<bluefoxicy> when you kill -9 something should it die
<Keybuk> if you're determined that it stops, you could just do "stop foo"
<Keybuk> :p
<jdub> Keybuk: start-stop-daemon - required?
<Keybuk> jdub: useless
<specialKevin> does anybody know how ubuntu does the vga out automatically, because with gentoo or foresight I have to have the projector plugged in on boot but with ubuntu I can plug it in any time after boot
<leoncamel_> hi, folks. how can I install gcc-3.2 into Ubuntu 5.10 ?
<azeem> leoncamel_: please ask in #ubuntu
<Keybuk> /usr/include/sys/types.h:46: error: conflicting types for 'loff_t'
<Keybuk> /usr/include/linux/types.h:30: error: previous declaration of 'loff_t' was here
<Keybuk> ...errr...?
<Keybuk> did someone break the kernel?
<Phoul> Hello, I was wondering where i may make a request for a deb to be updated?
<grexk> Phould: backports in the forum.
<Phoul> umm...
<desrt> Phoul; generally speaking,  updated versions of packages are not uploaded to the distribution.  only security and bug fixes
<Phoul> I ment to the repo but okay
<Phoul> Dang
<desrt> Phoul; right.  not to the repo either.
<desrt> Phoul; you have to wait for the next release to come out (in 6 months) or use backports
<Phoul> backports - ?
<desrt> somewhat unsupported -- updated versions of packages as requested by users
<desrt> but installing them can break the upgradability of your machine to future official ubuntu releases
<Phoul> ...
<desrt> you should generally avoid backports unless you know what you're doing
<Phoul> Thats lovely lol
<Phoul> Uhh
<Phoul> I just wanna update libmpd & mpd too 0.12 to work with emphasis
<Burgundavia> mgalvin: long time no see!
<desrt> Phoul; this sounds like something unlikely to be in backports anyway
<Phoul> :(
<desrt> Phoul; an alternative is to install edgy
<Phoul> Hmmm, I guess i will just go source then, thanks for the help
<desrt> Phoul; it has new versions of stuff... but it's beta
<mgalvin> Burgundavia: hey! yea been pretty busy
<desrt> Phoul; use at your own risk but in practise it works fairly well
<Phoul> desrt, edgy is most likely very unstable lol
<Burgundavia> mgalvin: why not in #ubuntu-docs or marketing?
<desrt> Phoul; using it right now.  it doesn't give me any trouble.
<Phoul> uhh well wouldnt it be safer to just update the one package with svn then to update the whole system to something beta?
<mgalvin> Burgundavia: just did a clean install on a macbook pro, still setting it all up :)
<desrt> Phoul; you're probably right
<bluefoxicy> so guys.
<bluefoxicy> I'm doing heap measurement.
<bluefoxicy> thunderbird currently has 14577269 bytes malloc()'d, and the sbrk() + mmap() growth related to malloc() is 23207936 bytes
<bluefoxicy> (I have seen up to 60% waste)
<ohoel> bit by the overheating "bug" again
<ohoel> mjg59 / sfllaw; is the fan driver loaded at "loading essential drivers" ?
<ohoel> my fan never seems to start until that message has been displayed
<zyga> hello
<AnAnt> what does "bashism" mean ?
<dholbach> good morning
<Burgundavia> hmm, should I munge the CommunityEdgyIdeas into IdeaPool?
<dholbach> that'd probably make the ideapool pages even more overfull :)
<Burgundavia> right. I need to do a cleaning on IdeaPool as well
<Kagou> hi
<zyga> mvo: hi
<mvo> hi zyga
<zyga> mvo: I've got some good news :)
<mvo> zyga: ohhh?
<zyga> first off I'm nearly finished mirroring the entire repo
<Burgundavia> mvo: quick question: why did you obsolete the nwu spec?
<zyga> second, we only have to look at alternatives with $ in the target name which is far easier (not so many)
<zyga> and I'll merge your data extractor into one extract-all-stuff program that simply runs over the mirror
<zyga> should be ready by midnight
<mvo> zyga: great! \o/
<cwillu> I was in #ubuntu, and was pointed here:  is there any way to downgrade to an older xorg package (in the range of a week to a couple months)?  I'm experiencing some breakage, but I'd rather not post a bug until I know if it's a new hardware fault or not.
<seb128> Mithrandir: hey. How is going knot work?
<Mithrandir> seb128: I don't have enough install reports yet, unfortunately, so help with that'd be appreciated.
<Mithrandir> particularly, I don't have anything about PPCs.
<ogra> ppc edubuntu is fine
<ogra> :)
<seb128> Mithrandir: I don't have ppc but I can give a try to i386 or amd64 if that's useful
<ogra> i'm waition for the live iso to finish rsyncing ...
<Mithrandir> seb128: it is, yes.  -desktop ones, please?
<seb128> ok
<mvo> Mithrandir: I don't have a ppc neither, but I could do i386/amd64 if needed too
<Mithrandir> mvo: if you could do -desktop of what seb doesn't that'd be nice, yes.
<seb128> mvo: I'm downloading i386 atm, feel free to start with amd64
<mempf> what is the current status of the knot 2 release?
<mvo> seb128, Mithrandir: ok, it will be -desktop on amd64 then
<infinity> mempf: Read the 10 or so lines since you joined.
<mempf> im not sure what it all means
<mempf> lol
<infinity> mempf: It means exactly what it says.  We need more people to test the the ISO images before we release.
<infinity> mempf: If you have a powerpc machine, that would be great if you helped.
<mempf> i don't :(
<mempf> i got i386 and amd64
* dholbach will do amd64 desktop testing
<mempf> il gladly do any testing thats required
<dholbach> Mithrandir: did we spin dvd images as well?
<Mithrandir> dholbach: no, haven't done that.
<dholbach> Mithrandir: if so, i could test some of those
<dholbach> ok
<Mithrandir> mempf: testing on i386/amd64 would be nice too, so just grab an image and test.
<mempf> from here?
<mempf> http://cdimage.ubuntu.com/daily-live/
<Mithrandir> yup
<mempf> ok
<Mithrandir> ogra: is edubuntu ready?
<Mithrandir> janimo: how's the Xubuntu images looking?
<Mithrandir> s/s/re/
<ogra> Mithrandir, not yet ... still testing
<ogra> but it looks good ...
<Mithrandir> Kamion: have you had a chance to test ppc?
<jdub> GOOD MORNING FREEDOM LOVERS!
<seb128> hey hey jdub
<ogra> GOOD MORNING JDUB !
<dholbach> why does my Cd writer hate me
<ogra> hate it back
<dholbach> ogra: you don't seem to be relaxed :-)
<ogra> i am ... totally
<ogra> :)
<Mithrandir> Kamion: my /proc/cmdline says root=/dev/sda1 ...
<Kagou> is that http://cdimage.ubuntu.com/daily-live/current/ the iso to test for knot2 ? If it's not too late i can test it too
<Mithrandir> Kagou: yes, it's the correct one.
<Mithrandir> Kamion: (i386 alternate)
<Kagou> thanks Mithrandir. I burn it and try it
<dholbach> does anybody else have sudden problems with burning on RW media?
<ogra> no
<Mithrandir> dholbach: my dvd-rw is a bit pesky, but I think that's just old media.  I've been using the same disc for about a year.
<ogra> at leat not on DVDRW
<ogra> *least
<dholbach> Mithrandir: me too, but it's suddenly complaining about all media now and for dapper release testing it was still fine :)
<Zdra> dholbach: it works here
<dholbach> hrm
<Zdra> cd-rw on edgy, it blank it and burn without problem
<Mithrandir> my firefox fonts look really, really bad.
<ogra> my terminal fonts on ppc do as well
<ogra> but ff is fine here
<Kagou> dholbach: burn ok here
<Mithrandir> ogra: www.ubuntu.com has good fonts?  (That's my test site in this case)
<ogra> Mithrandir, oh, right the fonts are crappy 
<ogra> i havent looked at content :)
<dholbach> ... just at pictures :-p
<Mithrandir> ...
<ogra> :P
<ogra> dholbach, what changed in the vendor logo handling ? i have an ubuntu logo in my menu ...
<ogra> seems it doesnt pick up the edubuntu one
<dholbach> ogra: what is supposed to show up? which icon is that, where is it installed?
<ogra> in /usr/share/icons/gartoon/48x48/apps/distributor-logo.png 
<dholbach> maybe you need it in a different size now?
<ogra> ah, it gets picked up in the TangoBrown theme  
<dholbach> 32x32 icons were added to half of the world
<ogra> where i have a 24x24 one
<dholbach> TangoBrown theme?
<ogra> yes
<ogra> the icontheme we ship for th eplain edubuntu flavor for older students
<dholbach> ah
* mvo notices that a lot is untranslated in knot2, even stuff that should really be available like the "applications" menu
<ogra> its fine here
<ogra> at least on the installs ... havent tried the liveCDs yet
<mvo> I'm on the livecd right now
<ogra> heh, ian mrdock praises windows+vmware because debians network manager and suspend are broken ... http://ianmurdock.com/?p=350
<Mithrandir> mvo: gnome-app-install is broken on my installed system.
<Mithrandir> "ImportError: No module named gdbm"
<mvo> Mithrandir: oh crap, the missing gdbm?
<ogra> mvo, right, i just booted the first liveCd, all english here, but thats cased by the missing langpacks i guess
<dholbach> must be a version where it's build-depends instead of depends - i thought it got fixed in the meantime :/
<Mithrandir> I need to grab a bit of food, hopefully Colin will be back when I am.
<ogra> hrm
<mvo> Mithrandir: can/should I upload a fixed g-a-i?
<ogra> and the flickering panel menu is still existent on ppc here
<ogra> didnt we drop the broken link in menu-xdg ?
<janimo> Mithrandir: there seem to be no new livecds, I was waiting to test those
<janimo> as the imegas from aug 29 were tested and ok'd by Gloubiboulga and crimsun IIRC
<janimo> the new one should have the two uploads I made yesterday
<mvo> is the live-cd more memory hungry?!? my testsystem with 256 mb ram (that used to work ok for -desktop) is now hardly usable because of slowness
* mvo is away for a bit to add more RAM
<Mithrandir> janimo: livecd builds running
<janimo> Mithrandir: thanks
<Mithrandir> mvo: no, I don't think I want a new g-a-i since Scott uploaded a lot of stuff last night which would probably cause more pain.
<Mithrandir> mvo: I'll rather say "known problem"
<mvo> ok
<mvo> I will do a new upload then immediately when we are unfrozen
<Mithrandir> thanks
<Mithrandir> janimo: livecds done
<mvo> what about the RAM requirements? known problem as well?
<Mithrandir> mvo: what about which ram requirements?
<mvo> Mithrandir: it seems that the live-cd requires more ram nowdays. my very unscientific test is that it is very very slow on my 256 mb testmachine
<mvo> that used to be better I think in the dapper days
<mvo> but if noone else noticed anything it may just be me ..
<Mithrandir> mvo: if so, I'm inclined to blame gnome or something else using all your memory.
<seb128> don't blame GNOME!
* dholbach throws heavy things 
<Mithrandir> seb128: does edgy's gnome use more, less or the same amount of memory as dapper's?
<seb128> I would say the same amount
<Mithrandir> mvo: might be the change of scheduler.. try booting with elevator=anticipatory ?
<mvo> Mithrandir: interessting, I will try that (once this install here is finished)
* zyga sighs about inability to file bugs on slocate in launchpad
<Mithrandir> mvo: also, my update-notifier's "software sources" dialog shows 4.10 as still supported?
<mvo> Mithrandir: that is just the description text, but it is misleading, I will change it
<Kagou> knot2 test. 2 cd recorded, and the 2 don't work on notebook but work on PC. Boot stop on "mounting root system". Am I alone with that problem ?
<Mithrandir> Kagou: after you
<Mithrandir>  have installed?
<Kagou> Mithrandir: no. Boot on live cd. Choosing French language. Normal Boot. and usplash screen, cd stay on "mounting root filesystem" ... May be it's a cd-recorder problem. I'm trying on a cd-rw
<Kagou> if i'm alone, it's certainly a hardware problem.
<sladen> Kagou: what speed were they burnt at?  Does the 'md5sum test' succeed?
<Kagou> first at 24X and second at 8x
<Mithrandir> Kagou: can you remove "quiet" from the kernel command line and see if you get any kind of useful feedback?
<Kagou> yes after burn finished i will do this
<janimo> Kagou: maybe the check CD option in the boot menu helps too
<Kagou> janimo: the check CD, freeze at the same point that the normal boot
<janimo> ah
<Kagou> i'll be back
<mvo> Mithrandir: another thing. the new desktop cd contains some package too, but apparently the CD is not added via apt-cdrom or apt_pkg.GetCDRom.Add() during install. is that known too?
<Mithrandir> mvo: sounds like an espresso problem; bug Colin. :-)
<mvo> Mithrandir: I will :)
<mvo> Mithrandir: other than this, the install looks pretty good!
<Mithrandir> mvo: good, thanks.
<ogra-live> mvo, did you check if dma is enabled for your CDROM ?
<mvo> has anyone tested the live-cd in 256mb? its painful :/
* mvo reboots with the scheduler change 
<mvo> ogra-live: no, when a xterm comes up I will test. this may take a while though ;)
<mvo> ogra-live: yes, dma is on for me
<ogra-live> well, was worth a look 
<Mithrandir> hmm, so, do we have anybody doing ppc tests?
<mempf> i have a problem with the latest daily-live build
<mempf> after usplash it ends up at a blank screen
<Mithrandir> mempf: X never starts for you?
<mempf> dont think so
<mempf> the alternate isntall works
<mempf> but the daily-live wont load X
<Mithrandir> does the "safe video" option work on the desktop cd work for you?
<ogra-live> urgh
<mempf> il try
<Mithrandir> also, X works after the alternate install?
<ogra-live> Kamion, something is wrong with the edubuntu preseed file, edubuntu-server doesnt get installed
<mempf> yes
<mempf> safe video mode does teh same
<mvo> Mithrandir: booting with the alternative scheduler did not help, it is still pretty much unusable in 256mb
<zyga> mvo: what takes most memory?
<mvo> zyga: no idea yet, I'm still waiting for a xterm to come up
<mvo> :)
<zyga> argh
<mempf> I removed splash from the boot settings and it loaded X and GDM
<Mithrandir> mempf: ok, please file a bug on usplash giving all the information you can.
<mempf> i found a thread on the forums with the same issue as me but on a installtion not the live cd
<mempf> http://ubuntuforums.org/showthread.php?t=245468
<Mithrandir> ok, please make sure a bug is filed
<mempf> im doing that right now
<Sp4rKy> hey
<mempf> there we go
<mempf> filed
<mempf> https://launchpad.net/distros/ubuntu/+source/usplash/+bug/58455
<Ubugtu> Malone bug 58455 in usplash "Can't Boot with splash boot option." [Untriaged,Unconfirmed]  
<sladen> dholbach: I've added something to bug #47602, do you might if I re-open it---I'm not sure "Reject" is the best status when it's been reported and confirmed by multiple people
<Ubugtu> Malone bug 47602 in gnome-panel "gnome panels are empty (show nothing) after login" [Medium,Rejected]  http://launchpad.net/bugs/47602
<dholbach> hum, it was just John Florian on the bug
<dholbach> seb128, you and I asked questions, nobody confirmed
<dholbach> can you add information of which bug it's supposed to be a duplicate?
<Mithrandir> ogra-live: any chance you could test the ubuntu ppc cds too?  Apparently, none of our regular PPC folks are about..
<ogra-live> Mithrandir, yes, but it takes a while, i haventr rsynced the isos since some weeks
<sladen> dholbach: is gnome-panel responsible for starting one of the applets;  could it be one of the applets (eg. weather/keyboard/clock) that would be blocking?
<ogra-live> wow, X on th ei386 live took about 10 mins to start here (on  a turion machine)
<dholbach> sladen: possibly
<ogra-live> oh
<Mithrandir> ogra-live: well, if we have to wait, we have to wait.
<ogra-live> and now i hear the repeated login sound
<ogra-live> seems stuck 
<ogra-live> killing esd solved it, but it seems my alsa driver is broken or something ...
<seb128> Mithrandir: i386 desktop liveCD works fine for me
<Mithrandir> seb128: great, thanks.  Installation worked fine too?
<seb128> Mithrandir: I've no spare partition on that box but I'll try on my laptop now
<Mithrandir> seb128: thanks a lot.
<Mithrandir> seb128: you don't happen to have a ppc, do you?
<sladen> dholbach: any idea how I'd debug it?
<seb128> Mithrandir: nop
<Kamion> mvo: lack of apt-cdrom fixed in my local tree now
<Kamion> ogra-live: can I have log files of edubuntu-server not being installed?
<dholbach> sladen: apart from using strace, gdb no, sorry
<ogra-live> Kamion, yes, next install, i'm just installing amd64 over it
<Kamion> Mithrandir: sorry I'm late. I'm downloading edgy-desktop-powerpc now but it'll take a while.
<Kamion> ogra-live: argh, sigh
<Kamion> ogra-live: you need to save log files when there's a problem
<Kamion> ogra-live: which boot option did you select?
<ogra-live> well, i want to finish the testing ... 
<ogra-live> the default one ...
<Mithrandir> Kamion: ok, sure.
<mvo> Kamion: cool, thanks
<ogra-live> its not like we need to fix that now 
<ogra-live> it installs fine ... telling people to install edubuntu-server manually in known issues is appropriate (and i fear Keybuks changes in a rebuild ;) )
<Kamion> ogra-live: that depends on the other consequences of that bug
<Kamion> it might not be an isolated bug
<ogra-live> right, but i wont do a rebuild anyways ...# 
<seb128> dholbach: debug what?
<ogra-live> since i dont want upstart right now, where *buntu uses sysvinit
<ogra-live> s/where/while/
<dholbach> seb128: bug 47602
<Ubugtu> Malone bug 47602 in gnome-panel "gnome panels are empty (show nothing) after login" [Medium,Rejected]  http://launchpad.net/bugs/47602
<ogra-live> Kamion, or are Keybuks uploads from yesterday locked in the queue ?
<Mithrandir> ogra-live: I'd recommend not doing rebuilds now unless you absolutely have to.
<ogra-live> exactly
<seb128> dholbach: that would be a good question for vuntz ;)
<Kamion> ogra-live: no, we were technically unable to freeze the distribution, unfortunately
<seb128> Mithrandir: doesn't work on my laptop, after the "configure x" on usplash I get a blank screen with just a cursor on the top-left corner
<mempf> seb128: Same here but no cursor
<Mithrandir> seb128: uh-hu.  Can you try without splash on the command line?
<seb128> Mithrandir: trying now
<Kamion> ogra-live: although upstart 0.2.0-1 binaries aren't there
<ogra-live> but the sysvinit deps are all gone as i understood the changelogs
<Kamion> ah yes, upstart is stuck in NEW on i386, and FTBFS elsewhere
<Kamion> ogra-live: but they were unnecessary
<ogra-live> who knows what consequences that has :)
<Kamion> sysvinit was Essential: yes
<ogra-live> ah
<Kamion> absolutely bugger-all
<Mithrandir> sysvinit is still priority: required
<seb128> Mithrandir: hum, it must have been waiting on some input, I pressed some keys and it continued booting in text mode then
<Kamion> and upstart is still in universe
<seb128> Mithrandir: will trying without splash next
<Mithrandir> seb128: uh, that's crack.
<Mithrandir> seb128: thanks.
<seb128> Mithrandir: I've the issue on my box too
<seb128> Mithrandir: when it needs to check disks I got a blank screen
<seb128> I know it's checking disk because disk is working
<seb128> but first time it happened I restarted the box to figure it was on disk checking
<seb128> s/got/get
<shining> ahah, I love the "unconfirmed" status of gnome bug 323064
<mempf> I fixed my usplash issue as well
<Ubugtu> Gnome bug 323064 in general "the panel applications menu is displayed empty with gamin 0.1.7/inotify" [Normal,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=323064
<mempf> pressing ctrl+alt+F3 makes the cd finish booting
<mempf> jsut like seb128
<zyga> anyone seen keybuk?
<Hobbsee> zyga: he was around earlier
<StevenK> He's probably staring at the upstart code wondering how to make it more evil.
<zyga> upstart crashes my session often
<zyga> or rather: it works the *second* time I login
<zyga> the first one simply dies a moment after logging in
<ogra-live> meh
<ogra-live> why is the livecd user udi 999
<Kamion> ogra-live: so that user-setup works smoothly
<Kamion> (in ubiquity)
<ogra-live> ah
<ogra-live> its a bit odd for my ext2 usbdisk :) 
<ogra-live> all files are owned by 1000.1000
<Kamion> that would only work by coincidence anyway
<ogra-live> right ... i never had that issue, so i never thought about it :)
<ogra-live> Kamion, http://people.ubuntu.com/~ogra/syslog
<ogra-live> do you need any other logs ? 
<seb128> Mithrandir: i386 ubiquity install from the desktop CD worked fine on my laptop
<seb128> (i386)
<Mithrandir> seb128: yay, thanks.
<seb128> np
<Mithrandir> then we're just lacking positive powerpc reports and acks from xubuntu and edubuntu.
<ogra-live> Mithrandir, apart from amd64 live i tested everything .... all fine 
<ogra-live> amd64 running ...
<Mithrandir> ogra-live: ok, cool.
<ogra-live> ok, amd64 done ...
<ogra-live> Mithrandir, edubuntu is all fine, apart from the fact the edubuntu-server needs to be installed manually ...
<Kagou> Mithrandir: my problems was on booting was hardware. (bad cd, or bad burning). Now i'm finishing the installation on my notebook. First impression for knot2 at home is okay.
* Hobbsee tickles Mithrandir 
<ogra-live> ubuntu desktop ppc rsync tells me its done in about 20min
<Mithrandir> ogra-live: I'll document that in the release notes, then.
<Mithrandir> ogra-live: cool.
<ogra-live> thanks
* Mithrandir tickles the Hobbsee back
<Hobbsee> hey!
<Hobbsee> Mithrandir: when does the freeze stop?  i've got two fixes.
<Mithrandir> Hobbsee: soon.  I need to get successful ppc installation reports first.
<Hobbsee> oh right
<ogra-live> Mithrandir, suspend still isnt supposed to work on the liveCD, right ? 
<ogra-live> or hibernate ...
<Mithrandir> ogra-live: correct.
<ogra-live> then we should hide the options in the logout menu :)
<ogra-live> i'll have to look at that for ltsp as well ... so i'll see if i can add a patch for the live session too ...
<Mithrandir> casper-reconfigure /root gnome-power-manager chroot /root su $USERNAME -- gconftool-2 -s -t bool /apps/gnome-power-manager/can_hibernate false
<Mithrandir> uh
<Mithrandir> it does turn off hibernate and tells gpm to reconfigure itself.
<Mithrandir> if that's wrong, please file a bug with a patch
<ogra-live> well, gnome-session doesnt seem to care about gdm for the suspend hibernate options at all ... unlike for shutdown and reboot
<ogra-live> so i guess thats the bug
<seb128> ogra-live: gnome-power-manager is used for sleep and hibernate
<seb128> ogra-live: gdm is used for reboot and shutdown
<seb128> I think I'll change that to use g-p-m for those too
<ogra-live> seb128, ok
<seb128> we reverted that for dapper because we had not splash on shutdown or reboot from g-p-m
<ogra-live> but then i still need a fix for the items being shown in a ssh session (ltsp)
<seb128> if g-p-m is used you can change the gconf keys
<seb128> like can_suspend
<seb128> and can_hibernate
<seb128> set them to wrong
<ogra-live> the gdm part chedcks if i'm logged in locally ...gpm doesnt
<seb128> false rather
<seb128> then write a patch for g-p-m? :)
<ogra-live> so i dont see shutdown/reboot on logout ... but hibernate/suspend
<ogra-live> (on a thin client)
<seb128> the way to go is to use g-p-m
<ogra-live> hrm
<seb128> people should not forced to use gdm as login manager to have those feature, etc
<ogra-live> gnome-session is easier to patch :P
<Kamion> ogra-live: I'd like to see /var/cache/debconf/config.dat too, if you could
<seb128> so let's fix g-p-m
<ogra-live> Kamion, uploaded
<Kamion> Name: tasksel/first
<Kamion> Value: edubuntu-desktop, edubuntu-server
<Kamion> hmm, looks ok ...
<Kamion> oh, hmm, I wonder
<Kamion> yeah, ok, it's a tasksel/seeds bug and only affects edubuntu
<Kamion> note how edubuntu-server isn't in /usr/share/tasksel/ubuntu-tasks.desc
<ogra> oh lucky me :)
<Kamion> I'll get it fixed
<ogra> thanks !
<ogra> nicely the bug showed my a wrong dependency of edubuntu-server i else would never have recognized :)
<ogra> s/my/me/
<Kamion> oh, for crying out loud, I fixed this but apparently never uploaded it
<ogra> heh
<Hobbsee> i believe ogra did similar with rss-glx
<ogra> well, finding the other bug was worth it ;)
<Kamion> uploaded
<Kamion> thanks for that
<ogra> thaks as well :)
<ogra> *thanks
<ogra> Hobbsee, the big screensaver bugfixing party starts after feature freeze :)
<Hobbsee> ogra: true that.
<HiddenWolf> ogra, heh, start with art-team looking at and tossing out the wacky screensavers. ;)
<ogra> electricsheep needs some fixes as well ...
<Treenaks> HiddenWolf: let's keep all the mathematical drawing thingies!!!!
<ogra> HiddenWolf, why ? dont you like sabdfls selection ? 
<HiddenWolf> ogra, some of them are great, if they ran at half speed for instance. :)
* sladen tips a hat at rodarvus 
<_ion> Electricsheep needs bittorrent support. :-)
<ogra> haha
<_ion> The Windows version has it already, but i don't know if it's even being developed for the Linux port. :-(
<ogra> HiddenWolf, get a slower machine :P
<tepsipakki> kamion: howdy. is there a (easy) way to disable the console during install somehow?
<HiddenWolf> ogra, I've had quite a few "what the heck, is it saturday-night" kinda moments. Looked like a disco. :)
* ogra never heard complaints the the screensavers are to fast ... thats really a new one
<Kamion> tepsipakki: don't understand?
<ogra> s/the the/that the/
<rodarvus> sladen, hi!
<tepsipakki> Kamion: I'm thinking of security, since if I have a machine installing itself on a public place, anyone can open the console..
<rodarvus> what did I do this time? :)
<Kamion> tepsipakki: that really is "don't do that then"
<tepsipakki> nooo ;)
<Kamion> tepsipakki: you could console=ttyS0 and fail to attach a serial console, I suppose
<Kamion> no idea if that would actually work :)
<zul> rodarvus: death and destruction
<tepsipakki> I'll need to experiment that
<tepsipakki> we have now ~220 dappers here ;)
<Kamion> tepsipakki: or if you have it entirely preseeded, delete the second vc from /etc/inittab and SIGUSR1 init (or whatever the signal is to make it restart)
<sladen> rodarvus: sorted out Nvidia crappness
<rodarvus> haha
<rodarvus> zul, thats the usual ;)
<tepsipakki> Kamion: hmm, that sounds good. although, the console is useful for debugging, so if a password protection could be possible, then.. :)
* Riddell wonder if we're nearly there yet
<Kagou> testing knot2, the only problem i'v found for the moment is the uggly fonts under firefox
<Kagou> installation is ok, and hardware support too
<Mithrandir> Riddell: I'm writing the release announcement, so we're almost there, yes.
<Mithrandir> seb128: which version of gnome do we have now?
<seb128> Mithrandir: 2.15.92 (2.16.0 beta 2)
<seb128> ups
<Mithrandir> thanks
<seb128> Mithrandir: nop
<seb128> Mithrandir: "GNOME 2.16.0 Release Candidate 1 (2.15.92"
<seb128> Mithrandir: "GNOME 2.16.0 Release Candidate 1 (2.15.92)"
<seb128> 2.15.91 was beta 2, that one is Candidate 1 ;)
<Mithrandir> ok, thanks
<seb128> np
<vuntz> dholbach, seb128: question? for me?
<seb128> vuntz: bug 47602
<Ubugtu> Malone bug 47602 in gnome-panel "gnome panels are empty (show nothing) after login" [Medium,Confirmed]  http://launchpad.net/bugs/47602
<seb128> vuntz: what sort of debug informations are useful for a such bug out of a bt and maybe valgrind log?
<Mithrandir> http://err.no/tmp/knot-2.txt ; corrections welcome
<Mithrandir> Riddell: if you have updated the KDE version, I can put that in too?
<vuntz> nice bug
<Kamion> Mithrandir: missing xubuntu from the cdimage.u.c URLs
<vuntz> sladen: do you have some time to play with this nel bug?
<Riddell> Mithrandir: "KDE has been updated to 3.5.4"
<Mithrandir> Kamion: oops, fixed.
<sladen> vuntz: which one?
<vuntz> sladen: bug 47602
<Ubugtu> Malone bug 47602 in gnome-panel "gnome panels are empty (show nothing) after login" [Medium,Confirmed]  http://launchpad.net/bugs/47602
<Mithrandir> Riddell: looks good?
<janimo> Mithrandir: xubuntu live looks good to me
<janimo> on 386 at least
<seb128> Mithrandir: s/Gnome/GNOME
<Mithrandir> janimo: cheers
<Riddell> Mithrandir: wiki.kubuntu.com -> wiki.kubuntu.org
<Mithrandir> seb128: fixed
<Mithrandir> Riddell: fixed
<seb128> Mithrandir: "The new version of usplash seems to cause the desktop CD to fail to boot" ... maybe adding "for some people", it doesn't happen to everybody, right?
<seb128> hum
<Mithrandir> seb128: point.  Fixed.
<seb128> thanks ;)
<seb128> looks good to me
<Riddell> Mithrandir: good for me too
<Mithrandir> ok, goodie.
<tseng> Mithrandir: knot 2 is the first in a series...
<tseng> Mithrandir: its the second
<Mithrandir> tseng: fixed
<Mithrandir> (thanks)
<Mithrandir> I'm publishing the images now, ubuntu and kubuntu done, will do edubuntu and xubuntu once lithium has breathing space, then sync-mirrors, then prod mirrors to actually get it into the right place, then send announce
* tseng hugs Mithrandir 
<cbx33> cool Mithrandir 
<zul> yay!
<Kamion> first/second> I always get that wrong
<ogra> Mithrandir, The edubuntu-server package is not automatically installed when you do an edubuntu default install
<StevenK> "Here is the sec^Wfirst upload of ubiquity...."
<Kamion> zul: ha, good timing; what's the status of quieten-grub?
<Mithrandir> ogra: but it should have been, or?
<cbx33> Mithrandir: is knot 2 based on 31.2 ?
<ogra> yes
<ogra> the edubuntu-server install is the default ...
<ogra> but there is no "server" option in the menu ... 
<Mithrandir> cbx33: that question makes no sense without you specifying ubuntu/kubuntu/edubuntu/xubuntu
<cbx33> edu
<ogra> cbx33, its based on /current 
<Mithrandir> yeah, it'll be 20060831.2
<cbx33> ok excellent
<ogra> (which links to .2)
<Mithrandir> ogra: no, it's not.  I specify the exact release.
<ogra> oh, ok
<cbx33> ogra: I have a question
<Mithrandir> ogra: anyway, I rephrased it now; looks better?
<ogra> yep, perfect, thanks :)
<cbx33> the pathch I'm working on for pessulus, relies on something that is in python in edgy only
<ogra> hmm, the partitioner doesnt start on ubuntu ppc ubiquity if i select manual partitioning
<cbx33> goption to be exact, it was a request from vuntz as gnome are phasing other methods out and that is the preferred option
<cbx33> you expressed an interest to getit backported to dapper
<ogra> well ...
<ogra> if it cant it cant :)
<cbx33> do you want me to come up with some alternative code for option handling for dapper
<cbx33> it's not problem...
<cbx33> I mean it won;t be immediate anyway
<ogra> if people want the shiny SCP they shall use edgy ... if its backportable right away we can do that else we dont ... 
<cbx33> ogra: drop pessulus support and it will be
<cbx33> we can use that as a carrot !
<cbx33> "move to edgy....we have pessulus support"
<ogra> exactly
<cbx33> ok, agreed
<ogra> move to edgy we have a shiny SCP
<cbx33> well not really agreed, heh, it's your decision
<cbx33> :p
<ogra> while the dapper one only kills sessions :)
<tseng> scp?
<Kamion> Mithrandir: s/implemention/implementation/
<cbx33> kills and executes
<ogra> tseng, SCP
<cbx33> and logs out
<cbx33> Student Control Panel
<tseng> oh.
<ogra> capitalization ;)
<Kamion> Mithrandir: actually "implementations" would be slightly better since you're saying "changes ... have been"
<cbx33> and has plugin support
<Mithrandir> Kamion: better now?
<Kamion> Mithrandir: yep, ta
<ogra> tseng, dont worry, we dont add plugins and sessions to secure copy ;)
<tseng> ogra: ok :)
<Kamion> Mithrandir: I'd say "splash" or 'splash' rather than splash - the guillemot quotes aren't entirely common in English
<cbx33> are you drafting the knkot 2 release announcement?
<tseng> yes.
<cbx33> and any one view it?
<cbx33> s/can/and/
<tseng> 08:45 < Mithrandir> http://err.no/tmp/knot-2.txt ; corrections welcome
<Mithrandir> Kamion: fixed.
<_ion> splash
<Mithrandir> (my email client does  automatically)
<ogra> Mithrandir, there seems no way for me to convince the partitioner to load for manual partitioning in ubiquity on ppc
<cbx33> Mithrandir: *not* encouraged for, would *not* advised
<Kamion> _ion: ASCII's better in announcements where possible
<Znarl> Mithrandir : nl.releases is having a diskspace shortage and shouldn't be included in the announcement.  nl.releases points to releases.ubuntu.com presently.
<cbx33> be a better wording
<Kamion> cbx33: not IMO
<cbx33> Kamion: np
<Mithrandir> Znarl: ok, nl.archive removed.
<Znarl> Thanks.
<Kamion> I think encouraged is marginally better, although there isn't much in it
<Mithrandir> cbx33: eparse.
<ogra> Mithrandir, and i cant delete the whole disk, there is some valuable data on it ... so i cant really test ubiqity here 
<Mithrandir> ogra: ok; Kamion, got any ideas?
<Mithrandir> ogra: I'm tempted to just say "heck, it works", but that's slightly dangerous too.
<ogra> right
<Kamion> Mithrandir: I don't think we should care for knot-2. I'd say release-note it and we can work it out later.
<ogra> at least it boots the live session fine
<Kamion> actually, before you do that
<cbx33> Mithrandir: "don't need to bother" - seems a little colloquial for an announcement to me?
<Kamion> ogra: can you get me /var/log/installer/syslog and /var/log/syslog please?
<Mithrandir> cbx33: I blame Colin for that. :-)
<cbx33> "there is no need to" ?
<ogra> sure ... 
<Kamion> cbx33's change would be fine by me
<Mithrandir> cbx33: ok, changed.
<cbx33> Mithrandir: in following changes as - in following the changes as
<ogra> Kamion, http://people.ubuntu.com/~ogra/ubuntu-ppc-ubiquity-installer-syslog and http://people.ubuntu.com/~ogra/ubuntu-ppc-ubiquity-syslog
<Mithrandir> cbx33: done
<cbx33> Mithrandir: ubuntu-devel-announce list - ubuntu-devel-announce mailing list     ?
<Mithrandir> personally, I think I'd rather write "If you are interested in following Ubuntu development, we would suggest you subscribe to the u-d-a mailing list"
<Mithrandir> but I have no idea if that's more correct or not.
<cbx33> hmmm
<cbx33> for people who are not in the know the full expansion may be better
<cbx33> one final change from me to suggest
<cbx33> to try to catch bugs far enough before the final release that they can be fixed - to try to catch bugs as soon as possible so the can be fixed before the final release
<giftnudel> Mithrandir: it certainly is not wrong
<cbx33> sorry....mistake in that
<cbx33> so they can be fixed ;P
<Mithrandir> cbx33: good now?
<Mithrandir> giftnudel: the question here is more better/worse than right/wrong.
<giftnudel> Mithrandir: I like the one here better (its easier)
<cbx33> Mithrandir: maybe just needs one more comma
<cbx33> just before - to try to cath
<cbx33> releases, to try to
<giftnudel> Mithrandir: also, there are 2 spaces after "frequent breakage." ;)
<giftnudel> Mithrandir: oh, and there are more :)
<cbx33> there should be two after every full stop
<Kamion> giftnudel: many people adopt that style intentionally - it's not wrong
<Mithrandir> Kamion: it should be consistent, though
<cbx33> there is a single space in the second paragraph
<giftnudel> ok, then it's not konsistent
<cbx33> that should be a doulbe
<giftnudel> there are a lot more though
<cbx33> there is still application menu breakage on knot 2
<Mithrandir> ok, consistently two now.
<Mithrandir> cbx33: give me a blurb and I'll add it.
<Mithrandir> cbx33: comma added
<cbx33> it needs a symlink removing
<cbx33> to a debian folder
<cbx33> I can't remember where though
<Kamion> ogra: (a) ubuntu-ppc-ubiquity-syslog isn't world-readable, (b) the other log is from a ubiquity run where you never tried to start advanced partitioning, so is no use in tracking down that bug
<Kamion> or at least it appears thus
<ogra> well its should be from the current run thats still sitting on the desktop
<ogra> manual partitioning is selected and i clicked forward ... 
<cbx33> can you confirm the application menu breakage ogra ?
<ogra> flickering ? 
<cbx33> yes
<giftnudel> * The application menu may be broken, if you find that error, you need to remove the symlink "whereever"
<Kamion> ogra: the log has no indication of this. perhaps you could try 'sudo env UBIQUITY_DEBUG=1 ubiquity'? make sure to use an unimportant password, as it'll show up in the debug log
<cbx33> ok it';s here
<cbx33> hang on
<ogra> remove /etc/xdg/menu/debian*
<ogra> there is a broken symlink
<Kamion> debug mode should show us what partman is doing
<cbx33>  /etc/xdg/menus/debian-menu.menu
<ogra> Kamion, world readable now
<giftnudel> Mithrandir: * The application menu may be broken, if you find that error, you need to remove /etc/xdg/menu/debian-menu.menu
<giftnudel> or if you experience this error
<cbx33> broken seems a little....
<giftnudel> well then
<giftnudel> * The application menu may be flickering, if you experience this error, you need to remove /etc/xdg/menu/debian-menu.menu
<cbx33> flickering 
<cbx33> giftnudel: sounds good
<giftnudel> Mithrandir: blurb above (don't forget a . at the end)
<ogra> Kamion, ok, i'm at the same point now ... 
<ogra> same logs ? 
<Mithrandir> giftnudel: I think it should be described a bit better than "broken", and does this happen in new installations?  If not, it's not that relevant..
<giftnudel> cbx33: does it happen on installations?
<ogra> the funny thing is that it doesnt always happen
<cbx33> giftnudel: it happened here on an edubuntu install
<cbx33> default install
<giftnudel> Mithrandir: then it should be added
<ogra> if i do an amd64 install on my lappie, it works fine amd64 live is flickering ... i386 install is broken, install is fine ...
<cbx33> you may want to mention about existing partitions sometimes have two icons present on the desktop
<giftnudel> Mithrandir: what about the second blurb with flickering
<ogra> its unpredictable where or when it happens, but removing the dangling link always helps
<Kamion> ogra: just /var/log/installer/syslog should be fine
<ogra> ok
<giftnudel> cbx33: I don't thinkt that is important ;)
<cbx33> as i said, may want to mention :p
<Kamion> cbx33: I don't think we need to list all the known bugs; my rule of thumb is generally to list the ones that'll get in people's way during installation
<cbx33> I'm just glad I have a running system - so I can continue my development
<cbx33> Kamion: that's cool
<cbx33> i just mentioned it as it was prominent and visible from installation
<cbx33> but it leave it all up to you guys
<Mithrandir> giftnudel: ok, added.
<Mithrandir> (added)
<giftnudel> hehe
<giftnudel> better
<cbx33> Mithrandir: looking gggoooooooD !
<seb128> cbx33: the menu bug? It's no present on new installation
<ogra> Kamion, http://people.ubuntu.com/~ogra/syslog
<Mithrandir> ok, knot-2 is now pushed to the mirrors.
<cbx33> seb128: hmm...I just burned and install 31.2 edubuntu
<cbx33> and it was there
<Mithrandir> Znarl: can you ask heanet to do their thing?
<Mithrandir> Znarl: and acc, please.
<seb128> cbx33: is /etc/xdg/menus/debian-menu.menu a broken symlink on default edubuntu?
<Mithrandir> maswan: ^^
<ogra> seb128, yes
<cbx33> yes
<seb128> why?
<ogra> no idea ?
<ogra> :)
<rodarvus> :)
<cbx33> what provides it?
<seb128> you guys install menu-xdg?
<ogra> i didnt touch xdg
<ogra> ogra@edubuntu:~/seeds/edubuntu.edgy$ grep xdg *
<ogra> development: * python-xdg                   # SebastienBacher
<seb128> development
<ogra> doe spython-xdg pull it in ?
<seb128> no
<ogra> right, then we dont
<seb128> kdelibs-bin does it
<Kamion> development's not installed by default anyway
<ogra> aaah
<seb128> is KDE bog :p
<rodarvus> ogra, did you chose de_BE.UTF-8 on purpose for this installation?
<ogra> evil KDE
<ogra> rodarvus, nope
<seb128> ogra: if you install menu-xdg you should install menu too
<ogra> i choose "Deutsch" from the gui 
<ogra> seb128, eek ... then i'll get the debian menu, right ? 
<Kamion> you'll get BE if you select a city not in a country with a de_* locale
<Kamion> just because it's the first in the list
<seb128> ogra: yeah, why would you install menu-xdg other way?
<ogra> oh, damned might be i didnt change to Berlin
<ogra> seb128, dunno ... i wouldnt want menu-xdg at all ...
<ogra> i'll look into kdelibs then 
<seb128> ogra: fix kdelibs-bin to only Recommends it then
<ogra> yep
<ogra> lets break kubuntu :P
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | knot 2 released
<rodarvus> \o/
<ogra> yay
<Kamion> ogra: hmm, interesting
<Mithrandir> I'm still waiting for mirrors to pick up the images before sending out the announcement
<Kamion> ogra: so what happens is that ubiquity drives partman forward to the resize question, so that it can figure out what range to use for the resize slider
<Hobbsee> seb128: ogra you shouldnt be using kdelibs-bin at all
<Hobbsee> !
<ogra> right, i noticed a popup 
<Kamion> ogra: however, for some reason partman then says it can't resize the partition
<Kamion> this is probably confusing the ubiquity partman component
<ogra> Hobbsee, i'D love to drop it ... do you write gnome replacements for kdeedu ?
<Hobbsee> ogra: it's incorporated into kdelibs4c2a.  you dont need it
<Kamion> ogra: could you please file a bug on ubiquity, attaching /var/log/installer/syslog and /var/log/partman? please also quote the relevant parts of this conversation so that I have a record of it
* Hobbsee doestn write gnome-anything.
<ogra> Kamion, will do 
<Kamion> thanks
<ogra> but first ... breakfast :)
<Kamion> Mithrandir: the above isn't a powerpc-specific issue
<Kamion> in case you haven't sent the announcement yet
<Kamion> and I doubt it will affect all powerpcs
<Kamion> it's just not one I've seen before
<seb128> Hobbsee: I agree, everybody should be using GNOME ;)
<ogra> Hobbsee, ogra@edubuntu:~/seeds/edubuntu.edgy$ grep kdelibs *
<ogra> ogra@edubuntu:~/seeds/edubuntu.edgy$
<Hobbsee> hah
<Mithrandir> Kamion: uh-hu.  What's the issue, really?
<Mithrandir> Kamion: as in, what's the blurb I should put in?
<seb128> Mithrandir: main unfrozen then? ;)
<ogra> apparently something depends on kdelibs-bin
<Mithrandir> seb128: upload away.
<ogra> i dont pull it in directly
<seb128> Mithrandir: rock on
<Hobbsee> ogra: my point is, nothing should depend on kdelibs-bin.  i got rid of all the stuff in the arhcives that did.
<Hobbsee> or so i thought
<ogra> doesnt look like ... 
<ogra> :)
<jdub> Hobbsee: need some thinking music?
<jdub> o/` o/` o/` o/` o/` o/`
<seb128> ogra:  kdelibs4c2a apparently
<jdub>  o/` o/` o/` o/` o/` o/`
<ogra> seb128, right 
<seb128> Hobbsee: kdelibs4c2a depends on kdelibs-bin
<Kamion> Mithrandir: "The desktop CD installer may be unable to start the advanced partitioner in some situations when there are errors on filesystems on the hard disk."
<Kamion> or something like that
<Mithrandir> Kamion: ok, added it to the head of the list of issues.
* ogra now really goes to eat something ...
<Hobbsee> seb128: no it doesnt.
<ogra> ogra@edubuntu:~/seeds/edubuntu.edgy$ apt-cache rdepends kdelibs-bin
<ogra> kdelibs-bin
<ogra> Reverse Depends:
<ogra>   kdelibs4c2a
<Hobbsee> seb128: it provides, replaces, and conflicts it, but it does *nto* depend on it.
<seb128> Hobbsee: "Depends: kdelibs4c2a (>= 4:3.5.2), libart-2.0-2 (>= 2.3.16), libaudio2, libbz2-1.0, libc6 (>= 2.3.4-1), libcupsys2 (>= 1.1.99.b1.r4748-1), libfontconfig1 (>= 2.3.0), libfreetype6 (>= 2.1.5-1), libgcc1 (>= 1:4.0.2), libgnutls12 (>= 1.2.5), libice6, libidn11 (>= 0.5.18), libjpeg62, libpng12-0 (>= 1.2.8rel), libqt3-mt (>= 3:3.3.6), libsm6, libstdc++6 (>= 4.0.2-4), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxft2 (>> 2.1.1), libxi6, l
<seb128> ibxinerama1, libxml2 (>= 2.6.23), libxrandr2, libxrender1, libxslt1.1 (>= 1.1.15), libxt6, zlib1g (>= 1:1.2.1), menu-xdg, perl, python
<seb128> "
<Hobbsee> seb128: your'e talking edgy?
<Hobbsee> seb128: that's dapper
<seb128> Hobbsee: 
<seb128>      4:3.5.4-0ubuntu9 0
<seb128>         500 http://archive.ubuntu.com edgy/main Packages
<maswan> Mithrandir: since Znarl hasn't told me to do my thing, I'm doing it from your poke instead. :)
<Mithrandir> maswan: thanks a lot.
<Hobbsee> no way....
<seb128> Hobbsee: if you are sure of you, good
<Kamion> seb128: kdelibs-bin has been removed from edgy
<Kamion> but kdelibs4c2a does Depends: menu-xdg in edgy
<Hobbsee> Kamion: i requested it :)
<seb128> Kamion: I've an old version "Status: deinstall ok config-files" apparently ;)
<Hobbsee> seb128: something's really weird with that.
<seb128> Kamion: right
<seb128> Hobbsee: KDE trigs menu-xdg by some way
<Hobbsee> seb128: sorry, what's your depends line from?
<seb128> Hobbsee: no sure now, don't bother about it anyway, what Kamion said
<seb128> "kdelibs4c2a does Depends: menu-xdg in edgy"
<seb128> I think it should be "Recommends" for iut
<seb128> it
<Hobbsee> seb128: ah okay.  i'm not sure what menu-xdg does at this point.  besides, i'm not in core.
<Hobbsee> so i cant do anything about it anyway :P
<seb128> Hobbsee: menu-xdg provides the xdg debian menu 
<Hobbsee> ah
<cbx33> orca is interesting
<cbx33> running the menu item......doesn't actually allow you to set it up yet does it?
<cbx33> hehehe button sounds like muffin
<cbx33> Shutdown muffin
<Mempf> is knot 2 out?
<tseng> Mempf: thats what the topic says.
<Mempf> i dont see it on the cdimage.ubuntu.com site
<tseng> it's getting there
<Mempf> oh ok
<Kamion> even datacentre-internal mirroring of these things takes a while
* Mempf is confused
<Mempf> lol
<Kamion> the short version is "wait"
<jdong> Mempf: it's already on cdimage.ubuntu.com for me
<Mempf> wow
<Mempf> jdong
<jdong> http://cdimages.ubuntu.com/releases/edgy/knot-2/
<Mempf> long time no talk
<jdong> yes, long time :)
<Mempf> The requested URL /releases/edgy/knot-2/ was not found on this server.
<Mempf> not for me
<jdong> :-/
<Mempf> oh well
<jdong> strange :)
<Mempf> i got all day
<Mempf> lol
<jdong> lol
<jdong> I'm torrenting it
<jdong> it's slow as hell, but I'm in no hurry
<Mempf> maybe we are linked to different mirrors
<jdong> I'm already dist-upgraded to edgy on my systems
<Mempf> that always fails for me
<Mempf> lol
<rikai> Hm, talking about the edgy download?
<Mempf> yeah
<Mempf> or in my case, the lack of
<rikai> Yeah, cdimage is doing some sort of dns rotation thing, but not all the mirror servers are populated yet.
<Mempf> ah i see
<rikai> Pop on over to http://82.211.81.191/releases/edgy/knot-2/ if you're in a rush. ;)
<Kamion> mvo: cdromupgrade seems to assume $CD/upgrade/
<elmo> rikai: no, don't
<elmo> people don't give out IPs for our mirrors, it's not big and it's not clever
<rikai> elmo: err, apologies then.
<Mempf> even the ip wont load for me
<Mempf> lol
<giftnudel> besides, who knows if this is not rikai's server and there are some compromised images on it
* sladen grins at elmo taking the IP down
<elmo> sladen: I didn't
<rikai> giftnudel: True.
<elmo> but I happen to know someone is working on the machines and that it was entirely possible those IPs would become invalid at any time
<giftnudel> well the server rejects the connection
<mvo> Kamion: that is fixed in my local branch, will upload very soon
<pygi> sivang, poke?
<Mempf> so are most of you guys devolpers then?
<Hobbsee> Mempf: yes. this is a dev channel :P
<Mempf> well im here
* HiddenWolf figures that this is -devel, right?
<Mempf> and im not
<Mempf> lol
<pygi> Hobbsee, :P
<Mempf> im looking into it though
<Hobbsee> Mempf: devs, lurkers, and other people :)
<rikai> Mempf: beauty of irc. Anyone can participate. :)
<Mempf> rikai: beauty of ubuntu. Anyone can participate. :)
<Mempf> lol
<Hobbsee> that too
<rikai> Mempf: indeed.
<rikai> On a small unrelated sidenote, anyone happen to know what version of ubiquity made it into knot-2?
<Kamion> rikai: 1.1.11
<rikai> Kamion: Thanks. :)
<Mempf> i want my glx_texture_from_pixmap ati/nvidia!
<rikai> That fixes the installer error i've been getting. Now i've just got to wait for the dvd release. Anywho, i'll quiet myself now and elt everyone get back to their.... developing?
<Kamion> I doubt there'll be a DVD release of knot-2
<Kamion> we don't usually do DVD milestones
<Mempf> yay I can see knot-2!
<rikai> Kamion: oh? You do dvd dailies but not dvd milestones?
<Kamion> twice-weekly, not daily
<rikai> Ahh.
<Kamion> and yes, they generally aren't released as milestones because they don't usually get enough testing for that
<tseng> beta usually has a dvd
<rikai> Alright. Thanks for the info. Guess i'll jsut grab the cd then.
<Mempf> anyone knot how soon till we start to see some new artwork?
<Mempf> knot*
<Mempf> sigh
<Mempf> know**
<Mithrandir> there won't be a knot-2 dvd, no.  If I get volunteers to test a knot-3 dvd, I could release it, sure.
<Mempf> i love my 10Mbit internet
<_ion> /summon keybuk
<ogra> Kamion, ...
<ogra> ogra@edubuntu:~/seeds/edubuntu.edgy$ apt-cache show edubuntu-server|grep Depends
<ogra> Depends: ldm, ltsp-server-standalone, openssh-server, samba, schooltool
<ogra> ogra@edubuntu:~/seeds/edubuntu.edgy$ grep ldm *
<ogra> ship: * ldm                                # seeded because its not a hard dep
<ogra> any idea how ldm ends up in edubuntu-server even its not seeded there ?
<ogra> hmm, and the fun is that ltspfs *is* seeded but doesnt show up
<Kamion> ogra: because you don't have server in the seeds: line in edubuntu-meta's update.cfg so it isn't getting updated
<Kamion> that could have been my fault while implementing ubuntu-meta-in-bzr
<Kamion> want me to fix it now?
<ogra> nah, i can do that ... thatnks for the hint
<ogra> *thanks
<Kamion> -seeds: minimal standard desktop live
<Kamion> +seeds: minimal standard desktop server live
<ogra> well, i'll drop minimal and standard anyway :)
* rikai checks around to see if the "put home to a seperate partition from /" idea made it into edgy.
<Hobbsee> rikai: i doubt it
<Hobbsee> would be sensible though
<Kamion> ogra: only from output_seeds please
<rikai> Indeed. It'd make for nice quick and painless reinstalls in the event something goes wrong in /.
<Kamion> ogra: I'm fairly sure dropping those from seeds will do bad things to germinate's head
<Kamion> you want:
<Kamion> seeds: minimal standard desktop server live
<Kamion> output_seeds: desktop server live
* Mempf is booting the knot 2 disk now
<Kamion> rikai: unfortunately it also makes autopartitioning quite a lot harder because the PC partition table format is so dreadful
<Kamion> and it requires asking for relative sizes
<Kamion> which people will of course get wrong :)
<ogra> Kamion, confirmed ... germinate-update-metapackage is very unhappy :)
<rikai> Kamion: ahh, true.
<Kamion> we do just-/-and-swap not because it produces a technically better system, but because it's much simpler
<Mempf> and knot-2 still freezes after usplash....
<maswan> What would rock is having a good enough lvm implementation to be able to do everything-on-lvm
<maswan> I hear there are some issues with that though
<rikai> Wow, this mirror of knot2 is suprisingly fast.
<Mempf> yeah i got it at 1.1MB/s
<maswan> can't be mine, I'm only up to alternate and desktop-amd64. :)
<ogra> Kamion, is output_seeds supposed to be in update.cfg ? 
<ogra> i dont have it ...
<Kamion> ogra: no, add it
<rikai> Ehh, mine is only going at 321KB/s
<ogra> ok
<sladen> Mempf: after usplash, or after gfxboot?
<rikai> But thats near the top of my connection speed anyway, so i cant complain.
<Kamion> just put it right after seeds
<Mempf> i think usplash
<ogra> done ...
<Mempf> not sure what gfxboot is
<Mempf> i knot the fix
<neuralis> Kamion: have you looked in detail how fedora implements installation to lvm? i've been meaning to, but never got around to it; they seem to install to lvm by default, though.
<Mempf> i can get passed it if i press ctrl+alt+F3
<rikai> gfxboot == modified grub, ne?
<Mempf> i filed a bug on it
<maswan> 16:48:05 (79.90 MB/s) - `edgy-desktop-i386.iso' saved [698845184/698845184] 
<Mithrandir> maswan: decent bandwidth you have
<maswan> Mithrandir: I'm happy with the current mirror setup so far.
<maswan> Mithrandir: And I'm looking forward to the next release too, it should be fun to see now that we've gotten most of the bugs out of the system
<shining> 80MB ? :o my disk are 4x slower than that
<Kamion> rikai: no, modified syslinux
<Kamion> neuralis: no
<Kamion> neuralis: it wasn't the installation that we were concerned about, in the end
<rikai> Kamion: ah. 
<Kamion> neuralis: it was the usability of the userspace tools after that
<maswan> shining: Well, it took a couple of tries before I found a filesystem where I had enough cache so that it didn't need to flush the data to disk before the transfer was done :)
<Kamion> rikai: actually, gfxboot can be hooked into several bootloaders, including grub, but we only use it for syslinux at present
<thom> maswan: hah
<zul> Kamion: i take it its too late for the gfxboot for grub
<rikai> Kamion: ahh i see. I just remember isntalling something called gfxboot a while back to make my grub look pretty. ;)
<Kamion> zul: mm, probably too late now yes
<Kamion> rikai: on a different distribution, I assume
<Kamion> zul: no harm in getting it set up and even maybe enabled optionally, of course
<rikai> Kamion: Ubuntu Dapper, actually.
<Kamion> rikai: well, I can tell you that dapper's grub doesn't support gfxboot
<zul> Kamion: yeah might just want to steel the patch from suse
<Kamion> zul: nod
<rikai> Kamion: As seen in pm, it wasn't default grub. ;)
<maswan> Mithrandir: ubuntu done, doing the other flavours now
<Kamion> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-September/000185.html
<Kamion> not all those mirrors will be there yeet
<Kamion> yet
<jdub> elmo: you at the office?
<elmo> jdub: yes
<jdub> elmo: can you let me know if a fax comes through
<jdub> oh wait
<jdub> the girls have replied now
<Kamion> imbrandon: could you fix kmformat's documentation directories, please? it installs stuff into /usr/share/doc/KMFormat/ as well as /usr/share/doc/kmformat/
<Kamion> imbrandon: I tried to file a bug about it but there seems to be some bug in Malone that means I couldn't
<imbrandon> Kamion: sure thing, will do that in a few moments
<Kamion> imbrandon: actually, I managed to get the bug filed in the end; bug 58478
<Ubugtu> Malone bug 58478 in kmformat "documentation directories are screwy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58478
<imbrandon> kk
* StevenK sighs at himself and requestsync.
<Mempf> didn't i read somewhere that universe and multiverse were going to be enabled in knot-2 by default?
<Mempf> i think it was on the knot 2 wiki page
<ogra> heh, surely not
<HiddenWolf> Mempf: there is a spec about it
<Mempf> also i noticed that after the install when the cd ejected itself the screen was blank
<Mempf> had to restart manully
<Kamion> Mempf: specifications and other plans don't automatically translate into implementation, I'm afraid ...
<Kamion> our lives would all be a lot easier if they did ;-)
<Mempf> im sure i read it on the wiki page at some point
<Kamion> it's possible, but I'm afraid it was wrong
<Mempf> yeah wahtever
<Mempf> its only two check boxes away
<Kamion> if it's there now, let us know so that it can be removed
<Mempf> thanks to the re-made software sources
* HiddenWolf downloads an iso to seed
<dholbach> congratulations everybody on getting knot-2 out
* dholbach hugs Mithrandir
<Mempf> ok thats odd
<Mempf> gnome-app-install wont launch
<slomo> Mempf: apt-get install python-gdbm probably solves this
<dholbach> Mempf: it needs python-gdbm ...
<Mempf> why isent that installed by deafult?
<dholbach> it's going to be
<dholbach> it's a bug
<imbrandon> Kamion: is today your archive day ?
<Mempf> ah ok
<imbrandon> or tuesday ?
<imbrandon> heh
<Kamion> imbrandon: today
<imbrandon> Kamion: cool can you poke bugs 58479 58480 through the archive when you get a moment 
<Ubugtu> Malone bug 58479 in dapper-backports "konversation 1.0 backport ( edgy --> dapper )" [Low,In progress]  http://launchpad.net/bugs/58479
* imbrandon fixes kmformat 
<Kamion> imbrandon: I will go through the list in order, yes
<Kamion> assuming ubuntu-archive is subscribed to it
<imbrandon> ok cool , just dident know how late in the day it was for you
<Kamion> I'm about half-way through
<imbrandon> ;) yea archive is subscribed
<imbrandon> ok back to work for me
<Mempf> card reader still not working
<Mempf> sigh
<mvo> Kamion: thanks a million for your prompt integration of #58207 \o/
<Mempf> also i was reading this: Edgy will ship with the 2.6.17 kernel, including all the various changes: NDISwrapper 1.22, madwifi-ng by default
<Mempf> what does that mean about the ndiswrapper part
<Kamion> mvo: no problem
<Kamion> mvo: hope it works :) I didn't test it either, I'm just going to let the cron job do that
<mvo> Kamion: when will that be (just curious)?
<maswan> ftp.acc.umu.se fully synced now, fyi
* HiddenWolf is uploading 850kb/s from home, hope it helps. :)
<Kamion> mvo: tomorrow morning
<Kamion> around 8am London time
<Kamion> Mithrandir: I've re-enabled the cdimage cron jobs, BTW; hope that's OK
<Hobbsee> Mempf: where did they read that?  ndiswrapper 1.18 is currently in ubuntu, according to MoM
<Hobbsee> !info ndiswrapper-utils edgy
<Mempf> its on this page
<Mempf> http://www.ubuntu.com/testing/knot2
<jdub> Kamion: your call on knot-2? rockingly awesome?
<Mempf> under New 2.6.17 kernel
<Kamion> jdub: don't ask silly questions :P
<Kamion> seb128: you seem to have undone the python transition in pyorbit; could you please fix that?
<Kamion> Hobbsee: that'd be the userspace side; I think it needs to be updated
<StevenK> Oh damn, does that mean Kamion has passed my first sync request.
<Kamion> no
<seb128> Kamion: ups, I uploaded the dapper-updates version which was newer and I didn't think somebody might have been updating the outdated version ... sure, will fix that :)
<Kamion> seb128: thanks
<seb128> np
<Hobbsee> Kamion: yes, by someone feeling brave.  i believe Mithrandir was offering
<seb128> BTW do we have a way to list packages newer to dapper-updates than edgy?
<dholbach> seb128: lucas might be able to alter his script for that
<dholbach> seb128: he compares package versions all the time
<seb128> dholbach: I would be happier to have a launchpad or official way for that ;)
<Kamion> nothing in launchpad to my knowledge
<seb128> ok
<Mempf> where is alacarte?
<seb128> will ask lucas when he's around then ;)
<seb128> Mempf: alacarte package
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/bzr/suite-diff/mainline/ should be able to do it
<Mempf> i see its install ed still
<Mempf> but not in the menus?
<seb128> Mempf: right click on the menu label, menu editor
<Mempf> kinda defeates the purpose
<seb128> or "edit menu"
<Mempf> oh i see
<Mempf> cool
<seb128> system, preferences, menu layout 
<seb128> too
<seb128> Kamion: will have a look at that, thank you
<jdong> guys, maybe laptop-mode shouldn't default to a hd spindown time of 5 seconds??
<jdong> that might be slightly bad to the hard drive
<wasabi> upstart kick ass.
<ogra> wasabi, sing it ? 
<ogra> *using
<wasabi> heh
<wasabi> Yeah.
<wasabi> At work and home now.
<ogra> and it didnt wipe your disks yet ? 
<ogra> nice :)
<wasabi> Nope. 
<wasabi> It's pretty simple.
<_ion> Yeah, upstart rules.
<theCore> can I know why it rules?
<Hobbsee> because Keybuk wrote it
<_ion> http://www.netsplit.com/blog/work/canonical/upstart.html https://wiki.ubuntu.com/ReplacementInit
<_ion> thecore: 
<ogra> theCore, it looks sexy in lingerie
<theCore> haha, but isn't still using the old /etc/init.d/ files?
<_ion> It has sysvinit compatibility.
<ogra> it *can* ... but doesnt need to ...
<Hobbsee> ogra: you've tried? 
<theCore> I think it will rules when all the sysvinit conf will be converted to /etc/event.d
<ogra> not yet ...
<ogra> i'm to anxious
<Kamion> you shouldn't try yourself - the config file format will change
<Kamion> so if you do, your system will break in edgy+1 :)
<Hobbsee> ooh yay!
<ogra> Hobbsee, but be sure i have to dive deep in ... ltsp will heavily suffer from it i fear ...
<Hobbsee> it can break over *2* releases!
<Hobbsee> ogra: heh.  do make sure you enjoy that
<ogra> well, not really looking forward to it 
<ogra> i have enough on my plate 
<doko> Kamion: please could you approve openoffice.org for dapper-proposed?
<jordi> Kamion: I'm about to send an announcement about edgy translations to ubuntu-translators and rosetta-users
<jordi> should I send to some other list?
<Kamion> doko: done
<jdong> Burgwork: I couldn't help but notice the knot2 release notes claim ATI/NVIDIA support for AIGLX?
<Kamion> jordi: if Ubuntu maintainers should know about it too, then ubuntu-devel-announce would be appropriate
<jdong> ;)
<jordi> Kamion: ok; I don't think it's specially interesting for them
<Kamion> jordi: ok, sounds reasonable then
<zyga> re
<Kamion> crimsun: was your comment in bug 58039 a confirmation?
<Ubugtu> Malone bug 58039 in sylpheed "[Edgy]  Please sync version 2.2.7-1 from Debian/unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58039
<Kamion> Pascal isn't in ubuntu-dev
<ogra> ok, this starts to get annoying ... thats the third < 200Mhz/64M machine i installed and it still doesnt see the ralink wlan card ... grr
<ogra> what am i supposed to do with a card that works only with pci busses of mainboards from this month
<zyga> main is frozen right?
<zyga> does universe still get continous builds?
<tseng> no.
<tseng> its all manual
<zyga> oh, good
<zyga> I wonder when will debmirror actually finish :P
<Mempf> uhh
<Mempf> im getting a problem with ndiswrapper
<LaserJock> heh, it would be nice to have freshened it up a bit before Universe Freeze, but oh well
<Kamion> zyga: you mean binary builds from source?
<zyga> Kamion: yes
<Mempf> i installed it with synaptic and when i go to run it from a terminal i get the error: Error: no versions of ndiswrapper found!
<Nafallo> ogra: s/month/decenium/ ;-)
<Kamion> zyga: yes, it does, and so does main
<zyga> Kamion: I could just stop debmirror now as it has iterated over _everything_ three times but I still hope it will end soon
<Kamion> we won't stop building binaries until about five minutes before release
<zyga> oh..
<LaserJock> zyga: yeah, I thought you meant syncs
<zyga> right
<zyga> okay time to get that stuff working and ignore the ongoing mirroring
<Burgwork> jdong, yep?
<jdong> Burgwork: are you sure that's an accurate statement?
<jdong> I thought 9000-series nvidia was supposed to add AIGLX support
<tseng> no it isnt
<jdong> fglrx 8.28 for sure doesn't support aiglx
<tseng> it is supposed to not die on aiglx server
<jdong> composite on = 3d off
<tseng> abi change
<tseng> no support.
<Burgwork> tseng, right. I will correct
<Burgwork> I misunderstood
<jdong> thanks, Burgwork
<tseng> Burgwork: thanks.
<tseng> Burgwork: yay f-spot
<jdong> did edgy go through some sort of hal abi change recently?
<tseng> dbus change?
<LarstiQ> dbus it did
<jdong> something-that-broke-vmware change?
<LarstiQ> or well, change at least
<wasabi> jdub: Yeah. I'm wondeirng about this too.
<jdong> :)
<wasabi> Err, jdong
<wasabi> Looks like vmware is segfaulting involving hal
<zyga> hmm, does python2.5 --libs seem broken?
<tseng> vmware-player doesnt even depend on hal
<tseng> this is why binary only distribution is bad, kids
<jdong> it's definitely vmware's fault at this point.. .we're gonna have to wait for new binaries from them
<wasabi> crud.
<wasabi> I'm getting vmware server set up to launch my VM
<tseng> jdong: ..how'd you come to that conclusion?
<tseng> after idly wondering about 30 seconds ago
<wasabi> then i'll just use a forwarded vmware-server-console from another box or some shit to access it
<zyga> do we have any console utils in dapper/edgy-commercial?
<jdong> tseng: on a less smartass-y note, do you think there's any chance to coax monodevelop to backport to dapper?
<jdong> it didn't look trivial at first glance
<tseng> it isnt trivial, mono packaging was significantly changed
<tseng> you would have to backport starting at step 0
* jdong makes another no-shit-sherlock statement
<jdong> ok then
<jdong> not worth the effort
<jdong> edgy's out soon :P
<tseng> right.
<tseng> thats the tradeoff for backports, and why we didnt even look at it initially.. next release is always not that far away
<desrt> wow.  october is so far away.
<Nafallo> far far away
<jdong> desrt: you'd be surprised at how impatient people can be
<Nafallo> are we there yet?
* mode/#ubuntu-devel [+o tseng]  by ChanServ
<desrt> "give me something for free right NOW damnit, and mail it to me on a CD for free while you're at it!"
* ..[topic/#ubuntu-devel:tseng] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | knot 2 released | ARE WE THERE YET?
* mode/#ubuntu-devel [-o tseng]  by tseng
<tseng> in the tradition of Daniel Stone
<desrt> i miss daniel stone
<jdong> I have to deal with them on a daily basis
<tseng> indeed.
* desrt sheds tears into his nokia 770
<zyga> guys did anyone notice: (...) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/include/python2.5/pyconfig.h (No such file or directory)
<Nafallo> lol tseng :-)
<LarstiQ> zyga: missing -dev?
<Burgwork> tseng, so do either Nvidia or ATI do the AIGLX composting stuff?
<zyga> LarstiQ: seems so, pythn2.5-config should be in -dev then, right?
<zyga> should I file a bug?
<jdong> lol, Burgwork, composting :)
<tseng> Burgwork: I don't know about fglrx
<LarstiQ> zyga: that's where it has been for as long as I remember
<jdong> no composite for fglrx
<tseng> Burgwork: then neither
<tseng> but open source ati might be usuable
<jdong> open source ati is usable
<Burgwork> what about nvidia?
<jdong> so is open source intel
<wasabi> The propriatary stuff is easier to use with Xgl.
<jdong> no nvidia
<zyga> LarstiQ: python-config is in python2.5, not python2.5-dev
<jdong> proprietary cards will use xgl
<jdong> which is in edgy/universe
<LarstiQ> zyga: ah :)
<Burgwork> "Edgy will ship with X.org 7.1, which includes AIGLX. With the release of the new Nvidia and ATI drivers that now working with Xorg 7.1 (but sadly still don't do compositing)"
<Burgwork> that correct?
<tseng> yes.
<jdong> yes
<jdong> mention Xgl's presence in universe, though
<Burgwork> will do
<tseng> I am not sure you are on the ball with the compiz stuff either
<tseng> oh duh
<tseng> this is an nvidia
<tseng> I'll test compiz on aiglx radeon later
<tseng> and intel
<Burgwork> All of this great AIGLX work means that there is much less need for XGL, for which the X Swat Team is going to be very happy, because AIGLX will produce about 1/1000th the bugs XGL does. XGL is still available in universe for those who need it.
<Mempf> i can confirm compiz works perfectly on intel cards
<Burgwork> that correct?
<tseng> Burgwork: erm
<tseng> that is slightly incendiary
<wasabi> Isn't Xgl the prefered way to make all this work In The Future?
<Burgwork> tseng, yes, yes it is
<tseng> no, its not
<wasabi> when Xgl doesn't need to piggyback, anyways.
<jdong> no, aiglx is the future :)
<tseng> but we don't want to be a dick about it
<Burgwork> XGL is a an ugly hack
<wasabi> How so?
<wasabi> A pure GL X server seems fine to me.
<jdong> x server inside an x server
<Burgwork> it is a complete new X server
<wasabi> XGl doesn't mandate that.
<wasabi> It just does Right Now.
<jdong> ^^^
<Burgwork> AIGLX is an iteration of the existing one
<tseng> aiglx and the other bit
<tseng> + compiz
<tseng> Burgwork: what was that thing you just told me about
<sladen> XGL would be even better if it didn't require extra extensions to all of the existing X servers to make it work
<jdub> wasabi: have a read of all the nvidia, ati and x hackers commentary on xgl vs. aiglx
<Burgwork> tseng, sorry?
<sladen> AIGLX would be better if it wasn't just stretching the existing driver model that little bit further
<Burgwork> wasabi, the XGL stuff has been hacked into something called glucose by Trolltech
<wasabi> Thgouth I had. Thought the prefered future path were to introduce GL drivers that didn't need GLX, then run a pure GL rendering X server on top of em.
<tseng> Burgwork: nevermind, but it would be nice if you could mention we have aiglx as our "go forward" without completly slamming XGL
<Burgwork> right
<sladen> tseng: the thing to promote is that they are both abstracted by compiz :)
<Burgwork> yep
<Burgwork> because what users care about is compiz, not aiglx/xgl
<tseng> except Xgl is the buzzword
<Burgwork> yep
<Burgwork> because Novell got out the door faster than RH
<tseng> Novell is pimping it senselessly, RH is doing nothing
<Burgwork> because RH realizes it is mostly useless tech (at least what it does right now)
<wasabi> Oh well. I thought the end goal was to decouple the hardware from X anyways.
<sladen> tseng: Novell are specifically not using 'XGL' any more, they've switched to "Desktop Effects" as the pimp word
<tseng> sladen: too late, monster is out the door
<tseng> :)
<sladen> yeah, they're having to try quite hard.  But it's similar to 'sudo' vs. 'root'.  The battle is winable, even if the legacy Unix vendors got there first
<Burgwork> right. page corrected
<Burgwork> I removed the inflamatory XGL remark, even though I thought it was quite justified
<tseng> Burgwork: you could justify a line stating that the RSS of tomboy is a few mb bigger than sticky notes and you are outraged
<tseng> and now 256mb laptops have just suddenly been "left behind" by ubuntu
<sladen> Burgwork: URL?
<Burgwork> but tomboy is clearly better tech
<Burgwork> www.ubuntu.com/testing/knot2
<Burgwork> should replicate in a few seconds
<tseng> just saying, I could justify alot of crazy things :)
<sladen> Burgwork: can we switch to the phrase "Desktop Effects" and leave only the compiz/GLX/AIGLX as a lesser footnote
<tseng> who are "Top Men"
<tseng> this is the 2nd time I did a double take on that
<jdong> tseng: how's mono in terms of memory usage nowadays?
<tseng> jdong: mono itself isnt bad, depends on the app
<tseng> beagle has improved greatly
<Burgwork> tseng, ajmitch (for XGL), mjg59 and quinn for compiz. I deliberately didn't mention any names in the Knot2 page
<Burgwork> sladen, sure, will do
<tseng> Burgwork: 'developers'?
<tseng> Burgwork: quinn isnt even a man
<jdong> I see
<jdong> does beagle still go crazy? :)
<tseng> Top Men is silly
<tseng> jdong: no.
<Burgwork> tseng, grumble. I am not changing it!
<tseng> suit yourself
<jdong> tseng: that's good to hear
<Burgwork> Top Men is a joke
<zyga> mvo: hi
<jdong> Burgwork: if we get any sexist debates at the forums, I'll blame it on you then ;-)
<Burgwork> right
* Burgwork actually goes to work
<LaserJock> you work?
* LaserJock runs
<Burgwork> you peanut gallery people have taken up almost 30 minutes of my precious time at work! ;)
<tseng> you are the one that asked for a review
<LaserJock> tseng: that'll teach him, or not
<Burgwork> actcually, I believe you pinged me
<Burgwork> oh, jdong did
<tseng> ah
<jsgotangco> oh just admit you couldn't resist picking their brains
<jsgotangco> ;)
<tseng> wouldve been really classy if you managed to turn that one back on me
<Burgwork> tseng, I always try
<sladen> Burgwork: is there an ACL on that page for me to edit it?
<Burgwork> sladen, do you have edit rights to the website?
<sladen> Burgwork: nope
<Burgwork> then you are screwed. need a password first, as editing is done another site
<jsgotangco> we are not 1337 enuff
<Burgwork> jsgotangco, no, I bugged henrik long enough
* sladen bugs newz2000
<Burgwork> grumble. FC4
<seb128> Kamion: do I need an UVF exception for a new ubuntulooks version fixing a crasher and a rendering issue (and no other change)?
<Kamion> seb128: yes, but you have the exception
<seb128> Kamion: thank you
<jdub> mjg59: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=204948
<thom> hrm, Keybuk's blog mentions upstart-compat-sysv; is that waiting in NEW or doesn't that exist?
<mvo> zyga: hello, sorry, had dinner
<mjg59> jdub: Yay
<sladen> CPU++
<sladen> perhaps more commerical is that they still ship sendmail
<zul> icky..
<jdub> postfix by default
<bddebian> Hey folks
<jdub> and they imported the debian alternatives system and abused it immensely to do postfix/sendmail switching
<Burgwork> tell me why hplip even exists in the first place? why is that not subsumed into cups and sane?
<LarstiQ> maintained by hp?
<zul> Kamion: for the grub splash stuff should i write out a spec like we did for the quiet grub spec?
<Kamion> thom: was in NEW until I liberated it recently
<Kamion> zul: grub splash stuff?
<zul> yep..
<zul> the gfxboot for grub
<Kamion> zul: oh, don't mind, if it's a simple patch and doesn't affect default behaviour then we can just do it
<zul> ok sweet..
<zyga> mvo: brb
<mvo> Kamion: I would like to ask for a UVF exception for hplib? its a rather long changelog, but it adds new hardware and is in debian/unstable since a bit
<Kamion> mvo: can I have mail about it?
<mvo> Kamion: sure, I will send it and CC doko (he was the most active ubuntu person on it)
<zyga> mvo: I've got a universal extractor that gets all the stuff we want
<zyga> I didn't run it on the entire mirror yet but I'm about to
<Kamion> mvo: ok, sounds good
<robertj> bwaha, I just realized I've had an open copy of program manager running on my desktop for the last month
<LaserJock> jdong: is the xchat backport stuck somewhere? it seems to have built on LP on the 29th but it isn't in the archives
<jdong> LaserJock: I've been wondering the same thing
<jdong> oh infinity...... :)
<jdong> help :)
<Kamion> mvo: so, I was just looking over https://wiki.ubuntu.com/AlwaysEnableUniverseMultiverse
<Kamion> mvo: I notice that the gnome-app-install changes have been pretty much done
<Kamion> mvo: (I also notice that the spec never got reviewed/approved ...)
<Kamion> mvo: the synaptic, software-properties, and installer changes are still pending, though
<Kamion> mvo: has any work been done on synaptic for this? that seems like the bit that would take longest
<Kamion> I'm only looking at this because it blocks stuff that's actually targeted at edgy, and will presumably now need to be deferred, but the more we do in advance, the better
<zyga> mvo: scanning entire main for non-obvious alternatives
* zyga is off for an hour
<neuralis> jdub: there?
<jdub> neuralis: pong
<neuralis> jdub: so, you misunderstood the python waking up every 100ms thing
<jdub> neuralis: yeah, modifying it slightly atm
<neuralis> jdub: it's not actually python; it's pygobject that does the waking up, when set to be thread aware. your demo (stracing a python interpreter) is crack; of course the *interpreter* is calling select
<azeem> dholbach: ping
<dholbach> azeem: pong
<zyg1> re
<zyg1> mvo: I'm running a full scan of main, but it looks like about handful of packages require manual checks to get alternatives right, right now vim, emacs, automake and java are biggest offenders
<mvo> zyg1: cool, those can be easily dealt with! great work :)
<doko_> sfllaw: ping
<Mehercle> hello!!
<Mehercle> sudo apt-get -qq install <package>
<Mehercle> returs DESTROY created new reference to dead object ' Qt::VBoxLayout', <> line 1 during global destruction.
<Chipzz> Mehercle: that's worthless
<Chipzz> heh
<Chipzz> whatever :P
<sfllaw> kozz: Pong.
<sfllaw> doko_: Pong.
<doko_> sfllaw: about the "on closing bug reports" ... could you publish the results of this discussion somewhere?
<doko_> (Rocco Stanziane)
<hunger> The new upstart breaks ubuntu-minimal... Could somebody please make those two compatible? aptitude wants to delete half my system without the -minimal package:-)
<pygi> hunger, Scott said in mail that it removes u-m :P
<hunger> pygi: Yeap, I notice that as well:-)
<sfllaw> doko_: Sure.
<Chipzz> just some stupid idea; but how much trouble would maintaining a config.site file be?
<Chipzz> one would say the idea is pure crack, but openbsd appears to be doing it?
<sfllaw> Wiki... painfully... slow...
<doko_> have a nice weekend
<welshbyte> sfllaw: yeah i've noticed that this past few days :/
<welshbyte> data centre having bandwidth trouble?
<HWolf> welshbyte, wiki is slow, but speeds of the cdimage server have been good for me.
<welshbyte> hm curiouser and curiouser
<jdub> mvo: did you notice that hplip is quite old compared to upstream?
<HWolf> welshbyte, could be that they're being hammered due to the knot release, but I doubt that should affect things greatly
<welshbyte> HWolf: yeah considering the wiki has been slow for a few days and Knot2 was only recently released I doubt that's the problem
<welshbyte> do we have an estimated time of arrival for upstart for AMD64? seems that it only built successfully on i386
<_ion> I think 0.2.1-1 is in the queue, and it contains some compilation fixes for non-x86 platforms.
<_ion> The source package is already in the archive.
<welshbyte> _ion: great, thanks
<_ion> welshbyte: Now https://launchpad.net/distros/ubuntu/+source/upstart/0.2.1-1 says "successfully built" for amd64.
* welshbyte cheers
<crimsun> Kamion: (sorry about the delay) at that time it wasn't, but since he has modified the Description, I've acked #58039
<mvo> jdub: yes, I have a local update that I will ask for UVF exception (1.6.something), but I need to fix the upgrade problem anyway because it blocks me testing dist-upgrade support
<jdub> mvo: cool! :)
<jdub> mvo: only noticed 'cos i got an HP MFP thingy ;-)
<mvo> jdub: heh :) I hope that it will be in early next week (if I get a ok for the UVF-e)
<Mithrandir> maswan: thanks a lot for your help.  Next release will be exciting, yes.
<Mithrandir> Kamion: cdimage cron jobs> sure, I was planning on leaving them disabled until we trigger livefs-es from cdimage, but there's no harm.
#ubuntu-devel 2006-09-02
<bddebian> Howdy
<jdong> is gnome-panel cpu hogging for anyone else?
<jdong> it chews a constant 70%-ish for me
<jdong> (edgy)
<shining> see bugs
<shining> I don't know what's the status how it though, I've read some stuff on ubuntu, debian and gnome bugzilla
<jdong> btw, when'd /bin/sh turn into dash?
<theCore> jdong: it did on my system once, I had to `killall gnome-panel' to fix it
<jdong> theCore: it happens every login every time on my system right now :-/
<jdong> doing a dist-upgrade right now, but don't see anything that should affect the panel
<crimsun> is it reproducible for a brand new user?
<shining> erm, I'm looking at the bugs again, some of them are a few month old, and are marked as fixed
<jdong> crimsun: happens in my freshly upgraded edgy
<jdong> when I get a chance, I'll try a livecd
<shining> I just removed a broken symlink
<jdong> but it's got me running kubuntu for now ;)
<shining> or kill gamin
<jdong> hmm, kill gamin.... that sounds like an idea
<shining> hehe, me too :)
<shining> it's the second bug on gnome-panel
<shining> https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bugs
<shining> high and confirmed
<shining> there are at least three workarounds
<shining> killing gamin, removing the broken link, fixing the link (by installing menu or something)
<jdong> shining: thanks, will do workarounds, but that still doesn't address the issue :-/
<shining> no
* jdong subscribes to bug
<shining> since it's a problem with gamin, either that needs to be fixed or something else used instead
<shining> also, fixing the menu packages to not provide a broken symlink wouldn't hurt, I think
<jdong> BenC: just want to tell you edgy kernel is a charm on my core duo
<jdong> kudos
* jdong nudges BenC about dm-bbr while he's at it :)
<shining> maybe also check these:
<shining> https://launchpad.net/distros/ubuntu/+source/gamin/+bug/36581
<Ubugtu> Malone bug 36581 in gamin "gam_server consumes lots of cpu time" [High,Needs info]  
<shining> http://bugzilla.gnome.org/show_bug.cgi?id=323064
<Ubugtu> Gnome bug 323064 in general "the panel applications menu is displayed empty with gamin 0.1.7/inotify" [Normal,Unconfirmed]  
<jdong> whoa, is edgy gcc stack protector'ed?
<tseng> yes.
<jdong> cool
<jdong> is there any work towards other forms of security?
<jdong> like exec-shield/selinux/whatever-else-redhat-is-advertising?
<tseng> no.
<jdong> k. I like the brief answers
<jdong> will I get rich today?
<tseng> nope.
<jdong> will you ever be more optimistic?
<bddebian> heh
<tseng> no.
<jdong> where's my firefox 2.0b2 packages?
<tseng> iwj is on vacation.
* bddebian wonders about azureus
<jdong> magic 8 ball, will applying 2.0b1 diff.gz to 2.0b2 sources work?
<tseng> nope.
<jdong> tseng: is that for real, or are you just trying to be funny now?
<tseng> ok, "extremely unlikely"
<jdong> lol, I don't doubt it
<tseng> it usually takes days to work it out
<shining> really?
* jdong quietly ssh'es onto friend's conroe extreme
<shining> I wouldn't have thought so
<shining> what does generally raise problems?
<jdong> I'll have an answer in 45 seconds
<jdong> we do have a bunch of patches
<jdong> which will likely reject like hell
<tseng> shining: a large set of patches against a large code base
<tseng> with a large delta of its own
<shining> ah ok
<jdong> 10 seconds...
<jdong> wow, I love these perpendicular recording hard drives
<jdong> alright, all unpacked
<jdong> now, for the moment of truth......
<shining> I'm not sure if I need all these patch though
<bddebian> Hmm, is the cvs stuff on cvs.fedora.redhat.com just their patches?
<jdong> failed hunks
<jdong> tseng is right :)
* jdong feeling lazy
<jdong> LOL, my friend just im'ed me asking what all that disk grinding was :P
<shining> oh, so that was for real :d
<jdong> what, you think I was kidding?
<rshakin> hello guys 
<shining> yep 
<jdong> I built that conroe extreme in return for free ssh access :)
<jdong> I can't believe the guy actually agreed :P
<shining> :d
<rshakin> sorry to bother you ppl but i need some help 
<rshakin> seems to me that the folks in #ubuntu are ether ignorinng me or something...
* shining looks at topic
<jdong> rshakin: shoot. it better be good or we'll ignore you too ;)
<jdong> if you don't ask quickly, someone will hurry you off to #ubuntu again :)
<shining> well, it has been off topic for a few hours, so I guess it doesnt matter
<rshakin> ok, i am getting a shitload of erors when i try to update my system...  http://madwifi.org/paste/161
<rshakin> thats what i get when i try to update using apt-get update 
<jdong> you spelled archive wrong :)
<jdong> that's your first problem
<shining> lol, so lame
<jdong> and it looks like you've got some connection problems to us.archive.ubuntu.com, too
<jdong> since I'm using that mirror right now to download 400MB of updates, I'd say your network connection is wacky
<rshakin> hmm weird 
<rshakin> i am on it right now :) 
<jdong> either way, fix that typo first :)
<rshakin> hehe... will do that 
<bddebian> doko: You aren't around by any chance are you?
<jdong> bddebian: wow, still working hard on azureus?
<rshakin> btw this is a clean install from a cd... nothing on it except what came with 
<rshakin> this is just weird it's like my isp is  blocking that site 
<bddebian> jdong: Just now getting to it
<jdong> rshakin: well, I don't believe that archive was spelled wrong on the cd.... but your isp might have connection issues to the mirror
<jdong> bddebian: k, cool... fedora's azureus runs really well with gcj, so let's hope we're that lucky too
<rshakin> well the archive was my fault... i was trying to edit to another mirror... so yeah thats more of my fault 
<jdong> :)
<rshakin> but as far as mirror, you are right there is no traffic going through to it for some off reason... 
<bddebian> jdong: Well I don't see the actual source.  Pulling from redhats repo all I seem to get are the patches
<jdong> bddebian: look for fedora extras' src.rpm's then?
<rshakin> is there another mirror that i can use  besides us.archive 
<pygi> rshakin, yes
<bddebian> rshakin: Just make it archive.ubuntu.com
<jdong> tseng: oh mono god, is there any way to get gtk# docs in monodevelop's help panel?
* jdong tries monodoc-gtk2.0-manual
<rshakin> hmm, this is just plain weird root@rshakin-laptop:/home/rshakin# apt-get update
<rshakin> Err http://archive.ubuntu.com dapper Release.gpg
<rshakin>   Connection failed [IP: 195.248.90.23 80] 
<jdong> rshakin: are you behind a proxy or anything like that?
<jdong> rshakin: did you install a firewall, etc?
<tseng> jdong: right, you got it
<rshakin> jdong: router wrt51G going to reset it in a min to see if it helps 
<jdong> tseng: wow, mono really rocks
* jdong used to be a c# fanatic when he used windows
<pygi> jdong, :)
<tseng> yeah, nice language
<hikenboot> hello all--I asked in #ubuntu but will ask here ...is there a list somewhere of packages that are installed in ubuntu live cd 6.06.1 that are not necessary for the basic function of the cd ..I am trying to make a custom live cd and want to make room for my own packages by removing all workstation related packages except gnome itself
<tseng> gtk# for the win
<pygi> hikenboot, you have several "modify livecd" apps
<jdong> tseng: do you know how well mono would work on arm?
<tseng> jdong: it works on arm...
<tseng> arm-l support is new
<tseng> i cant get it going on 770 on first try
<tseng> someone apperantly has, havent had much time for it
<jdong> tseng: there's the JIT compiler on arm, right?
<jdong> does mono's jit compiler generally make the code execute faster than python?
<tseng> generally faster than python...
<bddebian> Egads, how do I extract a clean gcj to make a patch?
<tseng> thats pretty hard to answer
<jdong> k
<Burgwork> hikenboot, check the seeds
<jdong> tseng: grr, monodevelop doesn't let me cut and paste from the documentation browser? :)
<hikenboot> pygi, besides livedistro what others got a link to a list somewhere?
<tseng> jdong: why wouldnt it?
<hikenboot> check the seeds? what do you mean?
<tseng> jdong: i just did
<jdong> tseng: almost everything under edit is greyed out while the documentation tab is active?
<pygi> hikenboot, I'll give you a script that you'll run
<tseng> i went back to the file tab
<pygi> hikenboot, sec pls
<tseng> and pasted
<Burgwork> hikenboot, ubuntu is built from seeds. see people.ubuntu.com/~cjwatson/seeds/
<pygi> hikenboot, COLUMNS=200 dpkg -l | awk ' { if ($1 == "ii") print $2; }' > /tmp/pkglist.txt
<jdong> tseng: middle-click pasting works, but the menu options are all disabled... can you confirm that?
<pygi> hikenboot, my command should also help :P
<tseng> i dont use anything but "middle click pasting"
<tseng> what menu do you mean, exactly
<jdong> tseng: edit->copy
<jdong> it's greyed out in the documentation tab
<tseng> ok, yes
<jdong> :-/ I'd call that a missing feature :)
<hikenboot> hey pygi, thats great...its a much shorter list than i generated with other commands i have used..I assume these are the root packages that install the others?
* jdong too lazy to do anything about it
<tseng> I personalyl would have never noticed
<tseng> the documentation tab is embedding monodoc
<jdong> hmm
<jdong> does stuff written on edgy in mono typically work in dapper?
<jdong> i.e. how's mono's binary compatiblity?
<pygi> hikenboot, those are all packages you have
<tseng> it should be good
<tseng> back a few versions
<tseng> except for say, sharpzlib
<tseng> that was a nice abi break 
<hikenboot> ah instead of package i guess i was showing deb's or somthing
<hikenboot> thanks a bunch guys
<jdong> tseng: how's running these exe's under windows?
<tseng> jdong: not good
<tseng> libraries
<jdong> ah, need gtk#?
<tseng> you can get gtk#
<tseng> if you use gnome stuff, it gets tough
<jdong> does gtk# run under ms's .net?
<tseng> yes
<bddebian> Scary :-)
<jdong> k, so just need to get people to find gtk# :-/
<jdong> how's windows.forms under linux?
<tseng> pretty good
<jdong> is there any gui SWF designers for linux?
<tseng> i dont think so
<jdong> well, that ruins that idea :-/
<jdong> well, that concludes my mono interrogation session for today
<jdong> thanks for your time, tseng
<tseng> that was easy
<robertj> is Trash a place in edgy now?
<tseng> no
<msw> jdub: dude, you're jumping to conclusions
<nixternal> OOo broke?
<bluefoxicy> OOo shiny
<nixternal> heh
<nixternal> OOo dead on one machine, slow on the other
<nixternal> splash screen pops up, and then disappears right away =/
<RedRose> toshiba: not a supported Toshiba laptop It recommend I rebuilt My kernel, should I, and how?
<Mempf> a lot of my fonts in firefox or err bon echo are ugly
<hunger> What is the recommendation on upstart use? I read it should be tested side by side with sysvinit, but now those two conflict.
<giftnudel> hunger: just uninstall sysvinit ;)
<hunger> giftnudel: That will breaks ubuntu-minimal.
<giftnudel> hunger: really?
<giftnudel> hunger: for me it didnt
<_ion> It doesn't "break" it, it just removes it. :-)
<hunger> _ion: Well, OK, I should have explained that better;-)
<_ion> No harm done. Install ubuntu-minimal later again, when it allows upstart.
<giftnudel> hunger: are you sure it breaks it? It only uninstalled ubuntu-minimal for me
<hunger> giftnudel: s/breaks/uninstalls/
<giftnudel> ehm, it only uninstalled sysvinit for me
<giftnudel> hunger: forget the statement before the last
<giftnudel> that was wrong
<hunger> Sorry, I should have said the right thing instead of claiming breakage.
<giftnudel> hunger: so correctly: I did not need to uninstall ubuntu-minmal
<hunger> Hmmm... aptitude is not happy with my current setup anyway, wanting to uninstall ubuntu-desktop due to broken dependencies all the time.
<giftnudel> I just did apt-get install upstart and it only removed sysvinit
<hunger> Uninstalling ubuntu-minimal should not make matters worse:-)
<giftnudel> hehe
<zyga> hunger: upstart works okay
* hunger is a bit worried that upstart is supposed to contain the functionality of inetd.
<zyga> just make sure you got upstart-sysvinit-compat 
<hunger> zyga: Yeap, so it does for me.
<zyga> without that you're hosed :)
<zyga> hmm
<zyga> can data.tar.bz2 be used in debian packages?
<zyga> anyone?
<hunger> It would have been nice if somebody had warned me that updating upstart causes kernel panics:-|
<_ion> hunger: It shouldn't  or maybe it does if you upgrade from < 0.2...
<hunger> _ion: I assumed that it should not;-) What should cause kernel panics after all?
<_ion> hunger: init (pid 1) dying.
<hunger> I still find it pretty scary that upstart is supposed to replace inetd.
* _ion finds it great.
<hunger> _ion: You find it great that process 1 listens on the network?
<_ion> It doesn't have to be process 1.
<hunger> Oh, then it is closer to being OK...
<_ion> For all i know, it could be a helper process that communicates with init.
<Hobbsee> Kamion: drat.  so i cant use requestsync script on it's own then :(
<giftnudel> _ion: well, where did you get upstart-sysvinit-compat from?
<hunger> giftnudel: apt-get install?
<giftnudel> in edgy?
<hunger> giftnudel: worked for me(TM)
<hunger> giftnudel: Yeap.
<giftnudel> what?
<_ion> Yes.
<giftnudel> maybe I should check my sources.list
<ajmitch> upstart-compat-sysv
<giftnudel> but I don't have it ...
<ajmitch> not upstart-sysvinit-compat
<giftnudel> ah, that may have been the cause ;)
<giftnudel> now i find it ;)
<giftnudel> thanks ajmitch
<lasindi> Hi everyone, I'm trying to create my own custom Ubuntu live CD, and I'm following this tutorial: http://www.atworkonline.it/~bibe/ubuntu/custom-livecd.htm I've written a script that I'd like to create a shortcut on the desktop to (like the "Install" shortcut to the installer). Since this shortcut must be copied to /home/ubuntu/Desktop at boot, is there a script in the CD that creates the ubuntu user that I can modify?
<zyga> _ion: install upstart-sysv-compat
<zyga> or similar..
<zyga> and make sure to REMOVE the alternative upstart section from menu.lst
<pygi> zyga, upstart-sysv-compat package isn't there
<pygi> ah :P
<hunger> pygi: Try upstart-compat-sysv (apt-cache search upstart will list it).
<pygi> hunger, I am running upstart already, no worries :)
<hunger> pygi: Good. Did you get a kernel panic upgrading it?
<pygi> hunger, nop, all worked
<hunger> pygi: Just asking, because I got one:-(
<_ion> Haha, pipermail ftw. http://lists.netsplit.com/pipermail/upstart-devel/2006-September/000006.html
<pygi> hey ho siretart 
<zyga> sigh
<zyga> python's tarfile module is broken
<_ion> Could fi.archive.ubuntu.com be changed to point to 193.166.3.2 (the address of ftp.funet.fi)? It's a very fast mirror for Finnish users.
<Lathiat> _ion: i beleive one of the funet admins would need to approac the ubuntu-mirrors team?
<Lathiat> i could be wrong someone else may know better
* _ion thought it would be the other way around. :-)
<Lathiat> well i guess the ubuntu guys could be pursuaded ot harass the funet admins :)
<_ion> (The mirror is already there in the correct path, http://ftp.funet.fi/ubuntu/)
<_ion> elmo: Any comments?
<Seveas> _ion, #ubuntu-mirrors
<_ion> seveas: Thanks.
<lisi> mjg59, hello, ping, here ?
<sladen> 650MB for Firefox(!)
<pygi> sladen, tabs? :P
<sladen> pygi: "only a few" :)
<sladen> ...dozen.
<zyga> re
<pygi> sladen, :P
<JanC> weird, synaptic (in dapper) acts differently (and very strange) when I manually mark the new OOo packages from dapper-proposed for upgrade (a.o. it wants to install kdelibs on my GNOME system???), compared to what happens when I mark them with "mark all upgradeable packages for upgrade" (does what I expect it to do)
<JanC> is that a bug or somehow a feature  ;-)
<Hobbsee> JanC: to install kde stuff on your machine?  of course it's a feature!
<Hobbsee> JanC: one of the early steps for the plan of world domination, by KDE.
<Hobbsee> JanC: next step will be installing kubuntu-desktop at the same time.
<zyga> lol
<JanC> fortunately I always check what gets installed beforehand  :-P
<zyga> I wonder what triggered the existence of mac forge
<Lathiat> everyone needs their own forge
<zyga> it's pretty useless ATM: they push bonjour, we have avahi, they push launchd, wh've just got upstart
<Lathiat> probably an apple-promotin-community-dev thing i would suspect
<Lathiat> zyga: sure, but theyre still open to do that
<zyga> Lathiat: it doesn't look like community, just official apple stuff
<sladen> JanC: if its replicatable, time to file a bug
<sladen> JanC: what happens from 'apt-get' or 'aptitude'
<LarstiQ> zyga: to be fair, launchd exists quite a while
<zyga> LarstiQ: yes I know
<zyga> and it had a license change along the way
<Lathiat> bonjour is still usefull on windows too
<zyga> what I'm trying to say: it's not about creating a community with their own projects - you canont do that on mac forge
<Lathiat> avahi doesnt cover that yet unfortunately
<_ion> When the launchd license change happened, upstart was already better more suitable for Ubuntu.
<JanC> apt-get does the right thing, as well as synaptics "mark all upgradeable" button (both in normal & smart mode) 
<Lathiat> im pondering goign to the dark side to port avahi to windows
<Lathiat> could be an interesting experience
<_ion> s/better //
<Lathiat> bbl
<zyga> _ion: yeap, upstart is far from being finished but it's already more like what we need
<giftnudel> anyone here how can rebuild python-mysqldb on edgy, compare bug 55047, it has been open for nearly a month now (or are there any other problems with this package?)
<Ubugtu> Malone bug 55047 in python-mysqldb "python-mysqldb doesn't actually install any python" [High,Confirmed]  http://launchpad.net/bugs/55047
<jdong> how do I get the uuid of a disk?
<jdong> is that something that changes if I mkfs?
<_ion> jdong: vol_id(8) or ls -l /dev/disk/by-uuid, and yes.
<_ion> Actually, the UUIDs are for partitions, not HDDs.
<darius_> Can I upgrade to Edgy or does it have to be a fresh install?
<_ion> Naturally you can.
<jdong> _ion: so, if I just mkfs'ed my /dev/sda1 and rsynced a backup back onto it, do I have to change anything?
<jdong> would the uuid have changed and I need to check my fstab/menu.lst?
<_ion> jdong: Better to check fstab and menu.lst.
<darius_> The 5.04 to 6.06 upgrade path presented me with a single dialogue to upgrade my distribution.  When I changed /etc/apt/sources.list to edgy it gives me 174 packages.  Not sure what I should expect
<jdong> _ion: yep, it did change
<rod> do the latest nvidia drivers support xorg7.1?
<shining> they say so
<geser> giftnudel: I've a rebuild version of python-mysqldb. could you test it?
<rod> so when using nvidia, a simple apt-get install compiz will be sufficient to test aixgl and compiz?
<shining> preparing to crash my laptop by trying to hibernate
<shining> rod: there is no such thing as aixgl
<rod> you got me confused
<giftnudel> geser: sure
<geser> do you have an amd64 or i386?
<giftnudel> i386
<giftnudel> geser: i rebuild one according to the bug (I added a comment)
<giftnudel> this one worked
<geser> I took the latest debian revision which also closes an other bug
<giftnudel> geser: do you need my email or will you give me a link?
<geser> I rebuild it now for i386 and then attach both debs to the bug report
<giftnudel> ok
<shining> crash succesful
<tseng> Mithrandir: openbox 3.3. yay!
<jdong_> did networkmanager break?
<jdong_> ** (nm-applet:5672): WARNING **: <WARNING>       nma_dbus_init (): nma_dbus_init() could not acquire its service.  dbus_bus_acquire_service() says: 'Connection ":1.9" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file'
<geser> giftnudel: I've attach deb for i386 and amd64 to bug 55047
<Ubugtu> Malone bug 55047 in python-mysqldb "python-mysqldb doesn't actually install any python" [High,Confirmed]  http://launchpad.net/bugs/55047
<giftnudel> geser: well, my program still works, but it doesn't use much of the module ;)
<geser> thanks for testing
<trappist> if a very minor bug is known to exist upstream, is it best to submit the fix upstream and wait for it to come back down the pike?  if so, what to do with the launchpad bug?
<tseng> you can link the bug to upstreams bug tracker if its a common one
<bddebian> Morning
<tseng> if you cant you can mention the ustpream bug in a comment
<tseng> don't crosspost, please
<trappist> tseng: yes, sorry.
<pixelmonkey> I just tried downloading the source for gnome-power-manager using apt-get source and then I tried building it using dpkg-buildpackage, but it claims unment dependencies.  When I try to apt-get the dependencies, it can't satisfy them... for example, libgnomeui-dev needs libgnomeui-0 of a version that won't be installed.  Shouldn't a clean dapper install, like mine, be able to build source packages?
<Mithrandir> tseng: yeah, but it requires somebody to ask for a sync ; would you want to?
<giftnudel> pixelmonkey: with apt-get build-dep gnome-power-manager, did you do that?
<pixelmonkey> yea, it claims it can't satisfy them
<tseng> Mithrandir: sure.
<giftnudel> pixelmonkey: I think it's ok to open a bug o gnome-power-manager about that issue
<_ion> Hi Keybuk
<trappist> or on libgnomeui-dev if it's what has the unsatisfiable dep
<_ion> keybuk: I'll write some tests for the patch.
<pixelmonkey> giftnudel, see, the problem is that the dependencies are a little strange.  libgnomeui-dev expects 2.14.1-0ubuntu2, and indeed that is my version, but it also provides ubuntu3, which is what seems to mess up the install
<Keybuk> _ion: cool :)
<pixelmonkey> because apt-get says that 2.14.1-0ubuntu3 is to be installed, yet libgnomeui-0 provides both those versions
<Keybuk> _ion: the test style should be pretty easy to copy
<giftnudel> pixelmonkey: uh, well ... I don't know anything about that
<Chipzz> pixelmonkey: are you sure you have a sane sources.list?
<Mithrandir> pixelmonkey: you're aware that versioned provides are not implemented?
<Chipzz> pixelmonkey: like, only entries for dapper-* and not for edgy?
<zyga> Keybuk: did you notice upstart-initialized boot sequence to kill X soon after login and restart gdm normally afterwards?
<Chipzz> pixelmonkey: also, apt-cache policy libgnomeui-0 might explain some stuff
<giftnudel> Keybuk: do you know about problems with upstart and e2fsk after a crash?
<pixelmonkey> Chipzz: http://paste.ubuntu-nl.org/22338 <-- not exactly sure what that means
<Keybuk> zyga: no, I've not noticed this
<Keybuk> giftnudel: no?
<Chipzz> pixelmonkey: what it means is:
<Chipzz>      2.14.1-0ubuntu2 0
<Chipzz>         500 http://archive.ubuntu.com dapper/main Packages
<tseng> Mithrandir: sync request filed
<Chipzz> libgnomeui-0, if installed by apt, would be version 2.14.1-0ubuntu2, and it would be installed from that archive
<Chipzz>  *** 2.14.1-0ubuntu3 0
<Chipzz>         100 /var/lib/dpkg/status
<Chipzz> this means
<zyga> Keybuk: it has happened regularly before upstart completly replaced init, I did't notice any problems since
<Chipzz> libgnomeui-0 is version 2.14.1-0ubuntu3, and it is only mentioned in that file (which is dpkg' status file)
<giftnudel> Keybuk: I had xorg crash on me and after a reboot, I didn't have X there and logged into the console, I found out that e2fsk was running and apparently corrected some errors, and the system rebooted without a warning
<Chipzz> it also means that the origin of the package is unknown
<Keybuk> giftnudel: that's kinda kooky
<pixelmonkey> Chipzz, hmm, I knew I shouldn't have run EasyUbuntu... I bet they grabbed it for some reason
<Chipzz> pixelmonkey: ergo, you installed it manually from somewhere, or it got installed from an entry in sources.list which you have since erased
<Keybuk> zyga: umm, so you're saying upstart fixed the problem?!
<Chipzz> pixelmonkey: ah there you are
<Chipzz> pixelmonkey: so, no bug
<pixelmonkey> Chippz, right, I didn't think it was a bug
<Chipzz> it's as simple as that
<Chipzz> pixelmonkey: there is also nothing wrong with gnome-power-manager build-deps
<pixelmonkey> Chipzz, what's a good approach I can take for reverting to the official package... I haven't dealt with apt hell fo awhile
<Chipzz> since you are the one having unsupported packages installed
<Keybuk> giftnudel: the console appears very early at the moment -- far earlier than it should, in fact
<giftnudel> Keybuk: well at least at the next login, everything was working normally
<Keybuk> it may be that you logged in while rcS was still running, which was why you didn't see X
<Keybuk> don't know why it would reboot though
<giftnudel> Keybuk: well, I had 3 getty's running (or that is as much as I tested)
<Chipzz> pixelmonkey: I think apt-get install libgnomeui-0=2.14.1-0ubuntu2
<Chipzz> or something like that
<pixelmonkey> Chippz, cool thanks
<giftnudel> Keybuk: the think is, it wanted to correct errors on the filesystem but apparently didn't wait for e2fsk
<giftnudel> *thing
<Chipzz> pixelmonkey: you may also have to downgrade other packages
<Chipzz> pixelmonkey: but
<Chipzz> pixelmonkey: do the following in a terminal
<Keybuk> giftnudel: it could be that the checkfs script didn't manage to run sulogin properly?
<Keybuk> but I thought then it'd just carry on with the boot sequence
<Chipzz> pixelmonkey: zless /usr/share/doc/libgnomeui-0/changelog.Debian.gz
<giftnudel> Keybuk: well, i was at terminal 7 and saw something similar to "something killed at vt2, restarting", then I switched to other consoles and logged in to see what wsa wrong
<Chipzz> the entry at the top should tell you the changes and who uploaded it, and to where
<pixelmonkey> "dapper-updates", by Sebastien Bacher
<Chipzz> pixelmonkey: and do you still have dapper-updates in sources.list?
<Chipzz> or did you remove that?
<pixelmonkey> Chipzz, don't think so, never added it personally
<pixelmonkey> Chipzz, though I have a feeling EasyUbuntu did :)
<Chipzz> may very well be the case
<zyga> Keybuk: no, I'm saying that upstart+compat-stuff finally stopped
<zyga> it started right after installing upstart initially
<pixelmonkey> Chipzz, ahhh.. I see... dapper-updates for some reason had its deb-src entry in my sources.list, but not the actual entry
<pixelmonkey> Chipzz, looking at my sources.list file, it looks like it's been "script modified" a few too many times.  Last time I take that risk.
<giftnudel> pixelmonkey: that explains the problem
<pixelmonkey> I've been out of the loop awhile -- is dapper-updates a bleeding edge repository, or?
<Chipzz> no no not at all
<pixelmonkey> so it should actually be in my sources.list then?
<giftnudel> not really, dapper-backports is more bleeding edgy, updates is for bugfixes and so on
<pixelmonkey> ah, I see.
<giftnudel> "bleeding edgy" ... ;)
<pixelmonkey> I stop using computers for 8 months, get home and everything's different.  What a surprise :-/
<Chipzz> not at all?
<sladen> pixelmonkey: been locked up?
<pixelmonkey> sladen, no no, I was traveling
<pixelmonkey> Chipzz, the occasional internet cafe
<pixelmonkey> Chipzz none of my own, anyway
<Keybuk> zyga: err, could you elaborate what went wrong when, and what fixed it?
<Keybuk> giftnudel: I'm going to go out on a limb and say it's something to do with not having sulogin atm
<giftnudel> Keybuk: well it should be easy to reproduce, I will see if I can find something
<Keybuk> cool
<Keybuk> giftnudel: if you can reproduce it, I've something for you to try to see whether it fixes it
<giftnudel> Keybuk: can I have the instructions now, then I will try it immediately
<Keybuk> giftnudel: grab a copy of the sysvinit deb, extract the sulogin binary from it
<Keybuk> and put that on the disk instead of my "exec /bin/sh" shell script that's hack-o-rama :p
<pixelmonkey> dpkg-buildpackage is working great now, thanks for helping me through that one, guys.
<zyga> Keybuk: after initial upstart from universe (the one needing a boot option) gdm/x crashed/were killed as soon as one logged in
<zyga> then after a second gdm was running again and everything was okay
<zyga> I tested this a couple of times without upgrading x or anything else
<pixelmonkey> Oh, and good news.  My patch for gnome-power-manager works! :)
<zyga> it was happening only with usptart as init
<zyga> now, after upgrades (and amongs them the compat package) this issue is no longer present
<giftnudel> Keybuk: ok, will tell you what happened
<Keybuk> zyga: ahh!
<Keybuk> zyga: yes, I know what that problem was ... X doesn't take kindly to flushing the console device under it
<Keybuk> it was fixed in 0.2.0
<zyga> ah :)
<Keybuk> it was some code I found in sysvinit that I didn't really understand
<zyga> good, it's a known and fixed issue then :)
<zyga> heh :>
<Keybuk> oddly enough, the same block exists in initng with /* what does this do? */ above it
<zyga> :D
<zyga> hehe
<Keybuk> then I realised that sysvinit never calls it, at least not in any mode anyone's used since the 70s
<Keybuk> so I took it out again
<zyga> should be labeled /* magic */
<zyga> I hope it's well commented now
<Keybuk> nah, it's deleted now :p
<zyga> hmm?
<Keybuk> I could put it in a make_x_crash () function
<Keybuk> but I don't see the need <g>
<Amaranth> zyga: the code from sysvinit was crashing X
<zyga> Amaranth: ahhhhhh
<Amaranth> zyga: he removed it, X doesn't die
<zyga> I thought that not keeping the code made x crash
<zyga> OTOH it's nice to see such process
<zyga> finding queer code that has been lurking for ages
<zyga> that somehow controls remote stuff in unobvious manner
<Keybuk> nah, was the code that "sets up and resets" a console device
<pygi> Keybuk, congrats, nice work on upstart
<ivoks_> right
<ivoks_> great job Keybuk 
<Keybuk> pygi, ivoks_: I'm reasonably pleased that it seems to be working well for most people that are trying it
<giftnudel> Keybuk: Ok, the problem is different: As you pointed out, the console comes far too early. When fsck.ext3 is run, the problem is, that the console is there, when the check is run, and you don't see any progress of the check, the usplash just disappears and if you change to a different console, you can login while the check runs
<pygi> ivoks_, I made silverspace try it yesterday :P
<Keybuk> giftnudel: right, why did it reboot though?
<giftnudel> Keybuk: putting sulogin in /sbin/ didn't change anything
<giftnudel> Keybuk: what do you mean?
<Keybuk> <giftnudel> Keybuk: I had xorg crash on me and after a reboot, I didn't have X there and logged into the console, I found out that e2fsk was running and apparently corrected some errors, and the system rebooted without a warning
<Keybuk> "system rebooted without a warning"
<giftnudel> I suspect fsck.ext3 rebooted 
<pygi> Keybuk, will we have it as default already in edgy?
<giftnudel> but since I didn't see anything, I don't know
<Keybuk> pygi: I hope so
<sladen> Keybuk: I've had crashed-X cause a reboot
<Keybuk> giftnudel: it didn't reboot this time?
<sladen> Keybuk: not with upstart mind
<giftnudel> Keybuk: it did it again
<ivoks_> uf, Keybuk i just saw i sent email to you, instead to the list; sorry
<Keybuk> ivoks_: heh, nm, just send it to the list :)
<giftnudel> Keybuk: It's surely the thing when it says "fsck corrected errors, system will reboot in 5 seconds", you just don't see it anywhere
<Keybuk> giftnudel: oh, it does that?
<giftnudel> yes
<Keybuk> oh yes
<Keybuk> heh
<Keybuk> can you file a bug? :p
<giftnudel> i will
<Keybuk> thanks
<giftnudel> Keybuk: bug 58609
<Ubugtu> Malone bug 58609 in upstart "upstart doesn't display checkrootfs.sh messages" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58609
<Keybuk> thanks
<zyg1> ah, why is mvo never here on weekends :/
<Keybuk> he has
<Keybuk> a) an active social life
<Keybuk> b) a lot of sports to play
<Keybuk> c) a wife
<Keybuk> :p
<_ion> *shiver*
<tseng> he doesn't even look old enough to be married
<tseng> those germans
<tseng> daniel and mvo look my age but are 5 years older
<giftnudel> tseng: I still suspect that there are countries im which you marry earlier, in Germany, you need to be at least 18 ;)
<zyg1> Keybuk: yeah I really understand
<Keybuk> iirc mvo is older than me
<tseng> goodness
<zyg1> Keybuk: and I am married too you know :)
<zyg1> I was rather saying that for people like me who can usually spend a small fraction of their time to cooperate the weekends are the only real time we have
* imbrandon is married too but is still on on the weekends
<imbrandon> Keybuk: do you know if Celso has had time to fix the dapper-backports thing , reason i ask is there is a pretty critical bug in the current amarok backport ( making it un-runable ) and it needs to be superceded
<imbrandon> with the new one
<Keybuk> I don't know either way, I'm afraid
<Keybuk> I would assume not
<imbrandon> k i figured not as it awas the weekend but i'm getting baraged with amarok people ;)
<Seveas> Keybuk, can I pm you for a sec?
<broonie> Is there anywhere I should be looking for Unbuntu-related init development work more generally than upstart? (Keybuk?)
<Burgundavia> broonie: sorry, I don't folllow
<Keybuk> broonie: in what kind of sense?
<broonie> Issues to do with the boot process, especially things like ordering init scripts.
<broonie> The sort of things that upstart is designed to facilitate.
<Keybuk> upstart takes away those issues
<broonie> It should end up pushing some changes into the rest of the world, shouldn't it?
<broonie> Dependency information, for example.
<Keybuk> upstart isn't dependency-based
<Keybuk> let's start from the beginning
<Keybuk> what is it that you're interested in, and what question are you trying to answer?
<broonie> I'm trying to find out about any changes you guys are making to the init process.
<broonie> My most practical interest comes from the NIS package.
<Keybuk> previous changes in dapper (the re-ordering of the boot process) or future changes in edgy+1 (conversion to using upstart)?
<broonie> Future ones.
<Keybuk> upstart-devel is probably the best place for that, then
<Keybuk> any specifications will be at least announced there
<broonie> Right, OK. I'm already looking there so that's good.
<Keybuk> there aren't any solid plans yet
<broonie> "We've got some cool stuff, let's build on it." ATM?
<Keybuk> yup
<Keybuk> actually, we're "We've just finishing off the cool stuff, we'll build on it later" :)
<broonie> If you don't build on it how will you get testing?
<broonie> :P
<Keybuk> for edgy I suspect we'll have the basic things like checkroot/mountroot/checkfs/mountfs/mountnfs/etc. converted to upstart jobs
<Keybuk> as that's where our most annoying races are at the moment
<love>  russian were are you
<Keybuk> bear in mind that upstart jobs aren't init scripts
<Keybuk> nor do they look like them
<Keybuk> so we'll be happily contributing them to upstreams to include, if they wish
<Keybuk> dunno whether they'll accept them or not, most don't ship init scripts because those are so wildly differently incompatible
<zyg1> Keybuk: is there any list of packages that require upstart scripts and need love?
* Seveas recently had the 'fun' of converting a very red-hat specific initscript to ubuntu...
<love>  
<zyg1> love: not you, sorry :)
<zyg1> I mean Ubuntu Love :D
<Keybuk> zyg1: hmm, define "need" ?
<zyg1> Keybuk: no one looks at providing upstart scripts for them
<Seveas> upsart has jobs, not scripts 
<zyg1> doh, right
<zyg1> anyway..
<zyg1> well they are scripts written using upstart job syntax :P
<Keybuk> zyg1: still not sure I'm following you
<zyg1> Keybuk: I was wondering if there is a list of packages that ship init.d script that could be modified to run from upstart but no one is looking at those packages because of low priority
<broonie> Right. My most practical interest is in seeing if anyone manages to come up with a way of resolving the mess with things like NFS, NIS and autofs playing together. 
<Keybuk> zyg1: well, for edgy, all packages are such
<Keybuk> we're not going to start the mass-modification until edgy+1
<Keybuk> broonie: this should, in theory, be easy with upstart
<zyg1> so init stays by default? ok
<broonie> Hence my interest in what you guys are up to.
<Keybuk> zyg1: upstart will be /sbin/init by default
<Keybuk> but upstart runs /etc/init.d/rc
<Keybuk> so sysv-rc will be default
<zyg1> Keybuk: I meant the 'old' init
<zyg1> right
<Seveas> zyg1, keybuk posted an implementation plan to -devel (or -devel-announce) recently
<Keybuk> zyg1: /etc/init.d has absolutely nothing to do with sysvinit's init binary
<Keybuk> it just happens that the configuration (/etc/inittab) causes it to be run
<Keybuk> upstart can obviously be shipped with the same semantic configuration
<Keybuk> the primary difference is that sysvinit will only start or stop processes (usually /etc/init.d/rc and getty) at a change of runlevel
<Keybuk> where upstart will do it at any event
<sladen> zyg1: fresh upstart pimpage at http://fridge.ubuntu.com/
<zyg1> sladen: interesting, thanks
<imbrandon> wow Keybuk nice^Wwell said blog post
* sladen tempted to add a "Resign from Debian Day" the calendar
<zyg1> what's with all that debian bye bye stuff?
<imbrandon> well its not nessesarly that that i was speaking of, more of the "why does debian single out ubuntu" when there is knappix,xandros,linspire and TONS of other dirivtives, i mean ubuntu clearly has a diffrent direction
<imbrandon> not so much the "bye bye debian"
<sladen> imbrandon: Ubuntu puts nitro in the gas tank
<imbrandon> ;)
<imbrandon> hahah that just gave me an idea to put a ubuntu/NOS mixture logo on my website ;)
<zyg1> how about throwing tar files out the window and redesign internal deb format a little bit?
<zyg1> (and dropping ar as well)
<imbrandon> wow zyg1 were'd that come from
<zyg1> imbrandon: my frustration with writing stuff that manages them :/
<imbrandon> ;)
<zyg1> apparently python's implementation of tar (tarfile module) has an annoying bug that makes it impossible to extract a single file from memory when the tar file is compressed 
<zyg1> it has been wrongly labeled as win-specific and left ignored; it can be easily avoided by simply extracting a file to fs and reading it but the sheer crappines and complexity/legacy of tar is annoying IMO
<sladen> zyg1: interesting, I haven't tried that.  only compressed from disk and uncompressed form memory
<zyg1> sladen: w87
<sladen> zyg1: perhaps you can feed the file through a stringio object
<zyg1> wait
<imbrandon> well honestly it does surprise me , i guesss since i came froma  non-debian background to ubuntu, but imho i do "the right thing" in that any "new" packages i get into debian first ( or try to ) and submit my patches upstream against their source etc etcetc , anyhow this isnt the channel for this so i'll shush now
<zyg1> tarfile.open(mode="r|gz", fileobj=file("control.tar.gz")).extractfile("control").read()
<zyg1> that's your crasher /
<zyg1> do not take my suggestions seriously
<zyg1> but I think that refreshing the design of debian packages is a valid goal
<zyg1> a few key issues: random access, improved compression, simple access to metadata, dropping ancient tech
<sladen> zyg1: we can actually get most of those using brain rather than redesign;  and we're working on it for delta-updates
<zyg1> sladen: how can I use my brain to get random access in bz2 compressed archive?
<zyg1> sladen: I just noticed your comment above stringio
<zyg1> I already do at another level (after reading them from ar archive)
<zyg1> I'll try doing that on control.tar.gz but that really equals with extracting the whole stuff into memory which is bad
<Seveas> zyg1, why not use python_apt?
<sladen> zyg1: scan the bz2 stream and note down a pointer to the corresponding start of each 900kB compressed block.  The you have ram-access with a sector size of 900kB
<sladen> s/The/Then/
<sladen> s/ram-access/random-access/
<zyg1> Seveas: actually I'm trying to make it faster, I have a working version with apt_pkg and apt_inst
<Seveas> aha
<zyg1> but it is pretty slow (I guess it extracts everything in a way)
<zyg1> sladen: I don't know the details of bz2 compression, do I need to read the entire stream to start decoding?
<zyg1> (what I really want is to read and decompress just a header of some sort and the portions that actually contain the file I'm interested in)
<sivang> zyg1: what are you developing?
<zyg1> sivang: a package scanner for cnf
<zyg1> sivang: I already got it working but it's quite slow
<sivang> zyg1: nice, cnf being Linspire's installation from web mechanism ?
<zyg1> ?
<zyg1> no no
<sladen> zyg1: no.  each 900kB in a bz2 stream is compressed completely independently.  You do need to know that the block for 3.5MB corresponds to offset 423,877 in the compressed stream though
<zyg1> cnf => command not found, cnr is linspire tech called click and run
<darius_> How can I see bugs only related to Edgy?
<sladen> darius_: bugs that haven't been marked fixed are presumed to be present in edgy
<zyg1> sladen: but that's really encoded in tar, right? I'd need to parse the tar header (I don't know if there is full map of stored stuff at the beginning) and the seek in bz2 to the place I want and start decoding there
<darius_> sladen: thanks
<zyg1> sladen: and since tar allows stuff to be appended I don't really think that's possible without reading the whole thing anyway
<zyg1> I might be wrong but that's my gut feeling
<sladen> zyg1: basically you need to have scanned the file once, and generated that "full map".  We intend to do this as standard for delta updates
<zyg1> sladen: nice
<zyg1> sladen: delta updates for stuff inside the archive with file granularity?
<zyg1> or with block granularity without file correspondence?
<zyg1> (or however that is spelled)
<sladen> zyg1: so in this case we scan the file when it is generated on the build-daemon;  store it with the .deb and then partial HTTP gets you the random access to each compressed block
<sladen> zyg1: no, sub-file granularity.  eg. to ~4kB
<zyg1> sladen: I was thinking about something simple and backwards compatible
<sladen> zyg1: this is backwards compatible
<zyg1> ah, I was not thinking about delta updates
<zyg1> about fast access
<zyg1> deb is just an ar right?
<sladen> zyg1: deb = ar -> gz -> tar 
<zyg1> there are 3 files inside, debian-binary, control.tar.gz and data.tar.gz or bz2
<zyg1> right
<sladen> zyg1: so ignore the tar and ar parts.   the data you want is a gzip stream starting at an offset from the start of the .deb
<sladen> zyg1: and then and a offset within that gzip stream
<sladen> an
<zyg1> sladen: parsing ar is easy, I already did that
<zyg1> parsing tars and gzips is also easy - we have libs
<zyg1> my only grief is that I need to fix one of them (tarfile) and do some stuff I don't want :)
<zyg1> the thought of implementing tar again in python so that my use case is fast is not a nice thought though :/
<Mithrandir> zyg1: just fix the tarfile module, then?
<zyg1> right
<zyg1> I'm doing that
<sladen> zyg1: oh, and the python fuse module can't create device nodes.  That needs fixing too.  Upstream didn't so maybe I'll fix it straight in the Ubuntu package
<sladen> ...it needs the API extending by one parameter (which are least is possible in pythong)
<sladen> zyg1: so what are you working on;  it sounds like the core requirement might be very similar to the stuff that's already done
<zyg1> sladen: yeah I know about mknod issue I used to play with fuse some time ago
<zyg1> sladen: hmm?
<zyg1> I only want to scan all debs I have and get symlinks, alternatives and executable files
<sladen> zyg1: don't tell me you're writing debfs too :)
<zyg1> no
<sladen> zyg1: do tell! do tell!
<zyg1> would be the perfect waste of my time IMHO :D
<zyg1> since I already wasted my time on trying to get fuse to guess alternatives
<zyg1> sladen: that's way too complex for my needs 
<zyg1> in the end I need to tell someone that vim is available in the yada-yada set of packages...
<sladen> ah, I see.  I think.  
<zyg1> sladen: that's dead easy when you ignore alternatives
<zyg1> (which unfortunatly cover the most interesting packages)
<sladen> zyg1: mmmm
<sladen> zyg1: it would be a wonderful problem to solve though
<zyg1> I even parse the postinst scripts to get the alternatives but some !@#!% maintainers use $i for the target for some reason (like when they want vim.foo and vim.bar processed in a loop)
<zyg1> after a dumb scan of main (and noticing that .tar.bz2 is valid as data source too) I got about 1.4K packages with $i or $var as alternative
<zyg1> I don't want to scan universe without getting a better scanner which I'm trying to make now
<zyg1> that's why I wanted to use fuse some time ago, so that I could chroot into fuse-based virtual fs and then exec the postinst script
<zyg1> but that would take ages and would not solve the problem really :/
<sladen> zyg1: you could do normal chmod and just wrap  update-alternatives
<sladen> zyg1: normal chroot
<zyg1> yeah but postinst stuff tend to do weird things
<sladen> zyg1: but it would be better if they didn't need executing at all
<zyg1> right
<zyg1> (I'd really like update-alternatives in a declarative form)
<sladen> zyg1: perhaps an option would be to add that meta-data to the packages that you can't parse
<zyg1> so that 99% of packages don't use installers after unpacking data
<zyg1> sladen: the important packages will get an eye review
<sladen> zyg1: 1.4k as in 1,400 packages in main using  for $i in ... ; do update-alternatives...
<zyg1> sladen: yes, 1.4k
<zyg1> wait
<sladen> zyg1: given that that about how many packages there /are/ in main
<zyg1> no sorry 
<zyg1> my mistake: first off that's for all arches
<zyg1> and second that's counting packages the scanner couldn't understand
<zyg1> 729 packages in main use alternatives with $variable
<zyg1> that's the state from yesterday
<zyg1> scanning main took about 7 hours
<zyg1> scanning universe will take about a day since it's quite larger
<zyg1> I don't event want to look at all packages in universe that require manual checks
* HiddenWolf wonders at the knot2 torrent. Still uploading my theoretical maximum after 27 hours....
<HiddenWolf> Does anyone have any figures on how much these things get downloaded?
<zyg1> HiddenWolf: there is a stat somewhere
<zyg1> this popped up when breezy got noticed heavily
<zyg1> I cannot remember the address though
<HiddenWolf> zyg1: ah, shame
<zyg1> http://torrent.ubuntu.com:6969/
<zyg1> ah :)
<zyg1> 185Gigs for i386 nice
<HiddenWolf> zyg1: that _can't_ be the total traffic
<HiddenWolf> I've uploaded 57gig myself alone.
<zyg1> totals are at the bottom
<zyg1> 1.1TB
<zyg1> HiddenWolf: what link do you have!?
<HiddenWolf> zyg1: just the one you gave me. :)
<zyg1> no, your internet link :)
<sladen> HiddenWolf: I suppose that torrent.ubuntu.com could just be spending most of its time seeding
<sladen> HiddenWolf: you only get 1.5 CDs / GB
<HiddenWolf> zyga: knot2 desktop i386
<HiddenWolf> sladen: true that
<zyg1> HiddenWolf: what kind of n
<zyg1> internet link do you have, that's quite a speed :)
<HiddenWolf> zyg1: 10/10
<zyg1> at home?
<HiddenWolf> zyg1: I live in a student building, converted office building. ISP is in the same building. ;)
<HiddenWolf> zyg1: yes, at home. :)
<zyg1> ah :D
<HiddenWolf> pulling 1100kb/s now.
<HiddenWolf> up
<shining> wow
<jdong> wow, is upstart fast at spawning a getty at startup :)
<zyga> jdong: yeah, upstart is quite faster at getting the whole thing to boot :)
<jdong> it's impressive
<zyga> I think it's a bug/misfeature about the getty though
<zyga> It's spawned from event.d 
<imbrandon> so with the current state of upstart in edgy i can just install it and reboot and all should work ?
<zyga> as soon as the system manages to run upstart
<zyga> not after stuff happens (mounting, networking)
<zyga> imbrandon: yeah
<jdong> imbrandon: yeah, as long as you can reboot :P
<aigarius> is knot2 really, really out? there is no link to its page from http://www.ubuntu.com/testing/
<jdong> imbrandon: you're gonna have to take a hard reset :)
<zyga> imbrandon: right, reboot doesn't work
<zyga> use shutdown -r or something, read readme.Debian
<jdong> reboot -f
<jdong> or alt+sysrq+b
<imbrandon> reboot -f
<jdong> come on, alt+sysrq+b is more dramatic
<imbrandon> hrm ok i got to run to my son's bday party but i'll try it when i get home
<jdong> sync once or twice or three or 20 times first :P
<imbrandon> bbiab
<Mithrandir> jdong: and umount first.
<Mithrandir> alt-gr+[sub] 
<sladen> ?
<jdong> Mithrandir: oh yeah, sysrq can remount-ro
<jdong> forgot about that
<jdong> meh, my reiser takes beatings from me quite well :-/
<sladen> mmm reiserfs.  mmm no.
<jdong> lol
<jdong> it's not terrible nowadays
<jdong> just don't expect reiserfsck to do much when hardware failures cause corruption
<Mithrandir> hope you have backups, then.
<jdong> Mithrandir: I am a paranoid backup freak
<jdong> Mithrandir: I have at least 3 rsync'ed copies of my partitions lying around
<sladen> even better;  keep those backups as reiserfs images *inside* a reiserfs partition
<jdong> sladen: uhh, that's... not gonna make the reiserfsck game any more fun :)
<jdong> so, now with upstart, how should I use sysv init scripts?
<zyga> jdong: as you did before apparently
<jdong> zyga: really?
<zyga> yeah
<jdong> I thought there was some initctl thing I should use instaed?
<sladen> jdong: as normal for the moment
<jdong> cool
<sladen> jdong: at the moment, upstart is just starting /etc/init.d/rc
<jdong> grr, squid and apt really don't play nice
<jdong> mono-xsp* are uninstallable under edgy :-/
<cbx33> hey pygi 
<cbx33> know much about gconf?
<pygi> cbx33, I know nothing ^_^
<cbx33> hehe
<cbx33> ok
<zyga> cbx33: what do you want to know?
<cbx33> um...about specifying sources
<cbx33> xml:merged:path
<cbx33> type things
<zyga> hmm, sorry I don't know much about that
<jelmer> infinity: ping
#ubuntu-devel 2006-09-03
<cbx33> the normal user can't read it
* desrt wonders what the last [whatever]  release is
<desrt> knot
<tseng> knot2
<desrt> oh.  yesterday.  that's convenient.
<bluefoxicy> can your computer take the knot?
<desrt> pfft.
<bluefoxicy> So after Edgy, what are we going to have?  We've seen a pig, some kind of spiky bush, a badger, a duck, and now a lizard.
<psusi> any kernel gurus around?  I'm trying to figure out if one driver ( pktcdvd ) can hook another device ( /dev/hda ) and filter requests to it, rather than create its own new device ( /dev/pktcdvd/0 )
<bluefoxicy> I vote for a mink!  http://youtube.com/watch?v=Lc_xNywG2KI
<tseng> bluefoxicy: please take it to -ot
<psusi> possibly by replacing the lower layer device's device_operations?
<bluefoxicy> tseng:  I appear to still be pseudobanned
<tseng> this isnt the refugee channel for -ot, in any case
<_ion> I'd vote for a giraffe, or perhaps a squirrel. :-)
<bluefoxicy> tseng:  I thought it was semi-ontopic but eh :P
<bluefoxicy> only by the longest stretch possible
<bluefoxicy> Seveas:  I vote that you cannae inslut me in channels I'm incapable of responding in!
<bluefoxicy> tseng:  btw pax-utils is in universe if you want it
<tseng> i saw, nice work
<bluefoxicy> hmm.  I don't see a TEXTREL/PIC patch for sdl 1.2.11 in Gentoo, did that stuff go upstream?
<bluefoxicy> (we have 1.2.10)
* bluefoxicy grabs 1.2.11 from upstream and checks for a few of the changes in the gentoo patches
<bluefoxicy> whoa, upstream just commented it out and said "FIXME"
<TMM> question: does anyone know of an ide that doesn't get in your way, but does support cool features such as code-completion and code-folding? I currently use gnome-terminal with multiple tabs and vim, anything I've tried so far annoys the hell out of me :)
<bluefoxicy> well, looks like they got their attention, I'll e-mail them and point them at portage CVS.  o.o
<tseng> TMM: the problem with every ide is: not vim
<psusi> TMM, emacs ;)
<TMM> tseng: I sure hope that that is not the problem, then I'm pretty much stuck :)
<bddebian> TMM: Apparently a new one just came in called geany or something like that that someone said was decent
<tseng> TMM: beats me, I personally can't use anything else
<tseng> vim has code folding
<TMM> it does?
<tseng> it does.
<tseng> google vim folding
<TMM> does it have code-completion as well? I'd love that :) I saw a vb monkey use it in microsoft develop... stuff thingy, it looked pretty nifty
<tseng> it does, but i heard it is less the fantastic
<jdong> I've not seen any good C/C++ code completion under linux
<jdong> monodevelop does a good job with C#
<jdong> but that's as close as I think we get
<Frederick> folks insnt openssl dev present in multiverse?
<psusi> it looks nifty, but if you know what you are doing it isn't helpful
<psusi> and can touch type decently
<jdong> psusi: that's the thing... I don't always know what I'm doing in a new language / library
<jdong> psusi: it's an appreciable feature
<TMM> well, I didn't do a lot of glib coding, and I am using it pretty heavily now, but I don't know the api very well, I think it might be faster than going to firefox and look at the api docs all the time
<jdong> not a must, but definitely a great bonus
<tseng> Frederick: how about libssl-dev
<psusi> I usually just rely on etags
<jdong> again, not a must, but a great bonus
<psusi> if I forget a parameter or something, M-. and look it up
<Frederick> tseng, thanks a lot
<jdong> and I do respect visual studio's code completion abilities
<tseng> TMM: 'gtkdoc' ?
<jdong> quite dynamic/intelligent, and not cpu hogging
<psusi> then i usually end up reading the implementation anyhow and learnign something not documented about it ;)
<TMM> tseng: I've got it locally, but still... is gtkdoc something else?
<tseng> TMM: sorry, devhelp
<tseng> TMM: (is the reader)
<_ion> tmm: Vim7 has omnicompletion.
<TMM> ow, shiney, I've got vim7
<TMM> I am pretty sure vim6 didn't have all that kind of stuff
<TMM> perhaps I should invest some time looking into vim some more, probably the way of the least resistance in this case
<_ion> tmm: It's similar to "IntelliSense" in MSVC (the thing you mentioned you saw someone using).
<TMM> 'intellisense' well, that sounds like something microsoft would call code completion :)
<jdong> _ion: is it as good as intellisense?
<jdong> intellisense is godly
<jdong> microsoft has full rights to that name, IMO :)
<Keybuk> wasn't that the silly thing where if you pressed Enter twice, it'd think you wanted a title?
<jdong> Keybuk: that's autoformat
<Keybuk> which was Intellidense?
<jdong> yeah
<TMM> Keybuk: I think the vb monkeys using it
* jdong glad visual studio has not adopted clippy
<jdong> TMM: have you tried monodevelop?
<_ion> jdong: I have no experience with IntelliSense. Can you describe what you mean?
<jdong> TMM: its code completion is a clone of intellisense
<TMM> jdong: for C code?
<jdong> TMM: no, not for C :-/
<jdong> C#
<jdong> _ion: it's for C/C++, autocomplete
<jdong> _ion: very similar to monodevelop caliber
<TMM> no, I haven't I don't know all that much C#, I prefer python :)
<sladen> Seveas: madness!  but sweet
<jdong> it autocompletes both from API's, included headers, your project files, anywhere
<jdong> it's very dynamic... will only suggest things that are valid... I've seen kdevelop/anjuta give erroneous suggestions
<jdong> and it's robust... a syntax error won't pollute/confuse intellisense
<jdong> I'm not sure how it indexes code so dynamically... it runs smoothly even on old computers
<jdong> but it reacts instantly to changes in the code
<jdong> basically, it's magic
<TMM> it is also closed source horse-shit :)
<TMM> and, unuseable for my purposes ;)
<jdong> I know. we need something as good as it but open source
<Keybuk> jdong: oh, QuickBasic had something like that
<Keybuk> and if you stopped the program, and selected a variable, its debugger could tell you what the value was
<Keybuk> not to mention where in your program it was used, etc.
<jdong> Keybuk: yep, intellisense does that too in debugging mode
<jdong> and when you start writing a function call, it provides a tooltip with the prototype
<jdong> bolding the current part you're working on
<jdong> and for overloaded functions, it's smart enough to guess which overload you're trying to use
<Keybuk> am still surprised no open source editor does that kind of thing
<TMM> tseng: devhelp isn't a whole lot more useful than firefox, in fact, a bit less useful as it doesn't have tabs :)
<jdong> the open source clones of it are pretty lame right now
<jdong> especially for C/C++
<Keybuk> anjuta annoys the hell out of me
<jdong> monodevelop does a good job for C#
<TMM> so, basically, I am stuck? :)
<jdong> TMM: sorry :(
<jdong> TMM: it's on all of our wishlists
<jdong> :)
<tseng> most of us are perfectly content with vi/emacs, I think
<tseng> thrilled, even
<tseng> you windows weenies should be so lucky
<jdong> yes, but that's if you know what you're doing
<tseng> :)
<jdong> it's definitely not "RAD-friendly"
<psusi> hehe
<jdong> (another MS term I am crazy over)
<jdong> that's about all I really envy from MS products
<tseng> I am pretty rapid in vi
<jdong> and for something you pay 10000 for, it better be damn good :)
<TMM> tseng: I'm not a 'windows weeny' 
<Keybuk> tseng: nah, I'm definitely not content with emacs
<jdong> tseng: you know what you're doing though
<tseng> jdong: (we hope)
<jdong> you better!
<jdong> lol
<TMM> that geany doesn't even look half bad
<jdong> I like to be able to open up a random OSS project and start changing it :)
<jdong> and for that, I need an intellisense and a fancy GUI designer
* jdong hopes that explains to tseng why I was so excited over monodevelop last night
<Keybuk> jdong: for GNOME stuff, I keep a fully-TAGS'd copy of the GNOME platform and desktop source around
<Keybuk> then I can lookup the code of what I'm trying to do
<jdong> I need to play around a bit more with this TAGS stuff
<jdong> haven't really found the time yet
<psusi> tags rules
<jdong> I'm sure I can find these tools satifying my intellisense crave
<jdong> but it sure requires a bit more effort than having a free copy of VS.NET mailed to me :)
<jdong> tseng: does mono/C# support generics?
* jdong is not too up to date on C# news
<tseng> jdong: yes of course
<tseng> but you need to use gmcs
<jdong> gmcs?
<tseng> and 2.0 assemblies
<tseng> mcs + generics
<jdong> oh
<jdong> and mono in edgy supports .net 2.0?
<tseng> yes
<jdong> cool
<jdong> dapper?
<tseng> yes
<jdong> cool
<Keybuk> jdong: MSDN?
<jdong> Keybuk: nope, employer
<jdong> Keybuk: we have this stupid embedded toolchain that requires the fanciest edition of VS.NET 
<jdong> tseng: did you hear me whining earlier about xsp being uninstallable in edgy?
<tseng> yes, I did
<tseng> I would rather never see that package again
<tseng> patches accepted, bugs at least
<jdong> tseng: is edgy gonna support xsp/asp.net then?
<tseng> that sounds like a loaded question
<jdong> loaded question?
* jdong just wants to see what asp.net is like with mono
<_ion> jdong: http://vissale.neang.free.fr/Vim/OmniCppComplete/ScreenShots/screenshots.htm
<jdong> from what I understand, that's xsp's job?
<tseng>   mono-xsp-base: Depends: mono-classlib-1.0 (< 1.1.14) but 1.1.16.1-0ubuntu3 is to be installed
<tseng> ^ some jerk in debian adding a hard depend
<jdong> tseng: if we take it out it'll be good? :)
<tseng> I don't know
<tseng> the least you could do is file a bug
<jdong> _ion: looks very nice... just have to learn how it works
<jdong> tseng: sorry, I'll file a bug...
<tseng> instead of hoping I happen to see whining on irc
<TMM> doesn't wining on irc get code written then? :)
<tseng> not by me
<jdong> tseng: bug 55433
<Ubugtu> Malone bug 55433 in xsp "Please port to Mono 1.1.16" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55433
<jdong> already filed a month back
<tseng> thanks.
<tseng> I'll rename it to soemthing actually usefull
<jdong> k, awesome
<jdong> thanks, tseng
<Keybuk> the thing I always miss from old editors is the Borland "block copy" function
<Keybuk> where you copied/pasted a square block rather than a number of lines
<Keybuk> so you can cut a block of code, and paste it at a different indention level
<_ion> Vim has it. :-)
<Keybuk> vim annoys me in myriad other ways
<Keybuk> mostly it just lacks the most basic developer features
<jdong> oh btw, Keybuk, I'm quite surprised at how well upstart replaced sysvinit
<jdong> and is the console supposed to be ready to log in 2 seconds into bootup?
<_ion> keybuk: Worksforme. :-)
<Keybuk> jdong: "surprised"? :p
<jdong> Keybuk: I've had bad luck with init replacements in the past ;)
<jdong> very bad luck ;)
<Keybuk> :)
<jdong> and don't give me this magic of ubuntu crap :)
<jdong> if you do, I'll give you a hoary CD and the job of setting up a md RAID
* jdong ducks
<TMM> yeah, ubuntu sucks! it doesn't have emerge!
<TMM> o wait, this isn't #gentoo-dev, now is it?
<jdong> TMM: my hoary used to
<Keybuk> jdong: md RAID probably won't work on edgy either
<jdong> :)
<jdong> heh, what's broken this time around?
<TMM> jdong: emerge? for hoary? there's a ports ... ehh... port to debian?
<jdong> TMM: I had some free time
<jdong> TMM: transplanted portage from a stage3 tarball
<TMM> jdong: you are a sick, sick man, someone ever told you that? :)
<jdong> :)
<jdong> hoary is when I migrated back from gentoo
<jdong> so it was hard to part from emerge....
<jdong> universe was pretty stale back in hoary's days, too
<TMM> jdong: otoh I'm writing a freely configurable lexer/parser, I've heard that that is considered quite insane as well :)
<jdong> TMM: I haven't told you about the time I tried to stress reiser4 by placing an entire system under bzr version control, right?
<TMM> jdong: you win, I'm a sane person, you need to be institutionalised
<jdong> :)
<TMM> jdong: also, how did it go? :)
<jdong> TMM: surprisingly well, actually
<jdong> reiser4 rocked at it
<TMM> as in 'no crash, all good'? 
<jdong> bzr's ram usage was not impressive at the time
<jdong> but it's improved since then
<jdong> I would've kept reiser4 around had I the time to maintain my own kernel
<TMM> I though when I was upgrading to edgy 'might as well go to reiser4 as well' but, I didn't dare to
<jdong> but edgy's kernel is just too good for me to turn down
<TMM> edgy's got reiser4, doesn't it?
<jdong> no
<jdong> reiser4 patches don't play well with other patches
<TMM> meh
<jdong> you gotta have a pretty vanilla kernel
<jdong> else you run into strange corruption issues
<TMM> lazy kernel team
<TMM> :)
<jdong> lol
<jdong> I don't blame anyone for not wanting to deal with reiser4 patches
<TMM> I merged xen patches with the ubuntu breezy patchset in under 4 days
<jdong> that's xen
<jdong> it was meant to be merged with a kernel :)
<TMM> trust me, not all the ubuntu patches enjoy the xen patchset :)
<jdong> TMM: they'll enjoy it much more than reiser4
<TMM> lol
<TMM> I believe you :)
<jdong> where nowadays it patches cleanly but just doesn't work well :)
<jdong> that hurts
<TMM> reiser4? or xen?
<jdong> reiser4
<TMM> is mister hans reiser doing anything about it?
<jdong> not really
<TMM> so, we might not actually get any of the reiser4 goodness, ever?
<jdong> TMM: the whole reiser4 in mainline thing looks depressing to me
<jdong> which is just too bad :-/
<jdong> reiser4 is good technology
<TMM> yeah, I've read some of the conversations between linus and hans
<jdong> and, except when you patch it wrong, reiser4 is rock solid
<jdong> it's currently the only atomic fs in linux
<TMM> probably two of the most talented programmers in the world, duking it out on the interweb, pretty interesting, also, both, pretty damn subborn
<TMM> I wish linus would just get over himself and bloody well rip out the linux vfs subsystem and replace it with reiser4 :)
<tseng> does switching vts cause rainbow patterns for anyone else?
<Keybuk> TMM: Please. God. No.
<TMM> Keybuk: I'm kind of fond of the idea of a vfs subsystem-with-plugins-in actually
* Fujitsu concurs with Keybuk on this issue, but not on the Vim one :P
<tseng> TMM: its actually alot more funny when bluefoxicy dukes it out with linus
<jdong> tseng: yes, usplash has broken my consoles too
<Keybuk> one's filesystem should behave predictably
<Keybuk> otherwise a poor application author can't even guarantee that when they close() it's on the damned disk
<jdong> tseng: take off splash, and it should be happier
<TMM> Keybuk: you don't HAVE to use a reiser4 on-disk format with reiser4 as a vgs
<TMM> Keybuk: vfs
<TMM> tseng: what is his real name?
<Keybuk> John Richard Moser
<Fujitsu> Ah!
* desrt gets the impression that edgy has a lot of good work that you only see if you do a fresh reinstall
<tseng> you can tell the fun threads because they end with a post from me saying "John, Please put down your bong"
<Keybuk> tseng: but he's soooo cuuuuute
<TMM> tseng: reading :)
<TMM> tseng: a weapon of mass distraction :)
<jdong> does beagle use up a considerable amount of space indexing?
<Fujitsu> jdong, yes.
<jdong> I got a ~src directory with like 3GB of random source code...
<Fujitsu> I hope you mean ~/src
<jdong> yeah
<Fujitsu> Ah.
<jdong> I blame the keyboard
<Fujitsu> I was hoping I wasn't going to have to indict you for a breach of the FHS :P
<Keybuk> why is that a breach?
<TMM> ~/src is not a part of the FHS... now is it? :)
<Keybuk> the FHS doesn't specify what you put in /etc/passwd
<TMM> or are we all supposed to go and do a ~/.local/src or something? :)
<Fujitsu> No, but aren't you meant to only have user home directories in /home?
<Keybuk> Fujitsu: no
<Fujitsu> Hm...
<Fujitsu> Oops.
<TMM> Fujitsu: you can just have an 'src' user
<Fujitsu> TMM, you could, but not in that context.
* Fujitsu runs away.
<Keybuk> TMM: I _really_ do not get ~/.local
<Keybuk> ~/. implies "user config" to me, already
<TMM> Fujitsu: err... create a user, become root, and type 'cd ~<my new username>'
<TMM> Keybuk: well, I can see why that is useful, I'd like to see something to the effect of ~/.local/etc actually.... all those .config files/dirs in a homedir are pretty sucky imho
<Keybuk> why are they sucky?
<TMM> Keybuk: I don't like having a ~/bin dir either, I use ~/.local/bin
<Fujitsu> TMM: Yes, but it would be silly to have a src user for that sort of thing.
<TMM> Keybuk: because there are so many of them
<Keybuk> TMM: moving them into another directory won't change that?
<TMM> Fujitsu: perhaps some anal security thing? :)
<Keybuk> ls -d .* | wc -l
<Keybuk> 831
<Keybuk> ls ~/.local/etc | wc -l
<Keybuk> 831
<Keybuk> *shrug*
<TMM> Keybuk: no, because they won't be  right in ~/
<Keybuk> why aren't they right?
<Keybuk> they've been there for 40 years
<TMM> Keybuk: it would be a bit cleaner imho, also, ~/.local/etc they won't all have to start with a dot :)
<Keybuk> why does that matter?
<Fujitsu> Now, that's not an entirely good attitude, Keybuk.
<Fujitsu> Just because they are there, doesn't mean it's right.
<TMM> Keybuk: which would make discovery of the settings for average users a bit easyer
<Keybuk> Fujitsu: right, but nobody's managed to tell me why they're wrong either
<Fujitsu> Although in this case the 40-year-old standard is right.
<TMM> Keybuk: I was working on that
<Keybuk> TMM: by hiding them even further inside the filesystem?
<Keybuk> how is ~/.local/etc more discoverable than just ~/.* ?
<TMM> Keybuk: there would be only one place to point your nautilus 
<Keybuk> there's only one place now
<Fujitsu> There is already, TMM.
<Fujitsu> !
<Fujitsu> *!
<Fujitsu> **~
<TMM> then they are mixed with 'ordinary' files
* Fujitsu hits the keyboard.
<_ion> I think there's a freedesktop.org spec about using ~/.config/programname/ (not ~/.local/etc).
<TMM> I'd prefer a ~/.local structure
<Keybuk> why not just ~/etc ?
<TMM> so, software installed in the homedir of a user gets to go in ~/.local/bin and the configs in ~/.local/etc 
<TMM> Keybuk: that would be fine as well, but, I think ~/.local would be less pollution :)
<_ion> http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
<Keybuk> in fact, we could probably expand the names to be more obvious too
<Keybuk> /Documents and Settings/Scott James Remnant/Application Data/...
<Keybuk> maybe
<TMM> that isn't even that bad
<TMM> but, 'documents AND settings' are confusing
<TMM> ~/Documents and ~/Settings would be quite good
<Keybuk> ah
<Keybuk> so maybe I need a /home/scott and a /etc/scott ? :)
<Keybuk> my stuff in one, config stuff in the other?
<TMM> no, I fully agree with the /home stuff :)
<Keybuk> you just disagreed with it :p
<TMM> note the '~' at the beginning of my suggestion
<Keybuk> /home = /Documents and Settings
<Keybuk> it's used for both currently
<TMM> no, /home/<username> is the 'root' of the user's system
<Keybuk> you proposed splitting those
<desrt> /home/.everything really is evil.
<bluefoxicy> tseng:  yes but when I duke it out with Linus it's on topics he admits he has no understanding of
<_ion> Let's just migrate all software to elektra. ;-)
<Keybuk> desrt: why is it evil?
<desrt> apple's /home/you/Library/ setup is a lot nicer
<desrt> Keybuk; i hate having a million .*'s in my ~
<TMM> yes, but, ~/ should be the root of the users system :)
<bluefoxicy> when Taenbaum does it Linus swears he knows more about it
<desrt> it's seriously a pain in the ass
<Keybuk> desrt: why?
<desrt> Keybuk; because i can't see then and they don't glob when i say *
<desrt> they're these files that aren't really files
<Keybuk> TMM: maybe a user's ~ shouldn't be writable by them?  but include common sub-directories like Desktop, Documents, Settings, etc?
<desrt> like just now, in preparation to install edgy i did
<Keybuk> desrt: *shrug* that's a fault of your shell's globbing, no?
<desrt> ~$ mkdir old
<desrt> ~$ mv * old
<desrt> which of course failed to work
<Keybuk> if you moved them to ~/.local they'd still be a hidden directory, so still be evil by your definition
<TMM> Keybuk: no, I do not thing that a user should be forced into anything, but, I think a structure that makes more sense would be good
<desrt> Keybuk; well, what about Library/?
<TMM> Keybuk: I agreed on your ~/Settings idea!!
<Keybuk> desrt: Library implies .so files to me
<desrt> ya.  it's a bad name
<desrt> good approximate idea, though
<TMM> desrt: I have to agree with Keybuk here
<Keybuk> ~/Settings would be nice
<desrt> ya.  Settings is just fine by me
<_ion> Either small letters or a case-insensitive filesystem, please. :-)
<desrt> just a rose by another name, imo :p
<desrt> _ion; how do you feel about ~/Desktop and ~/Documents?
<Keybuk> ~/etc ? :p
<TMM> perhaps ~/Programs as well, but I think I'd prefer that to be hidden, to make it less likely that people will poke at it
<Keybuk> my vague problem with /Useful Name/On/The Filesystem is that it's not translatable
<_ion> desrt: "documents" is fine, but desktop should .desktop (i.e. hidden).
<desrt> the website needs a note on "alternate install CD" and says "use this if you are unsure"
<TMM> Keybuk: well, with a reiser4 based vfs, we could have a plugin that does the translation at the kernel level ;)
<desrt> _ion; i definitely disagree with that
<Keybuk> TMM: even to the poor applications?
<desrt> oh WTF
<Keybuk> how would they know what directory name to use?
<desrt> knot2 won't fit on a CD anymore?
<TMM> Keybuk: well ~/Documents would work as well as ~/Documenten
<Keybuk> TMM: what if you wanted both?
<desrt> Please replace the disc in the drive with a supported disc with at least 670 MB free.  The following disc types are supported:
<desrt> CD-R, CD-RW, DVD-RW, DVD+R, DVD+R DL, DVD+RW
<desrt> ^^ burning knot2 to a blank CD
<Keybuk> desrt: ubuntu hasn't fitted on a 640MB CD for a long time!
<Fujitsu> desrt, sure it's a 700MB CD?
<desrt> ugggh
<desrt> this is mad
<webben> Why is Ubuntu's emacspeak package so ancient?
<Fujitsu> ?
<_ion> keybuk: I've heard MacOSX translates them on-the-fly. The directory tree is always in English, but the user sees them based on the locale settings.
* desrt overburns and hopes to get lucky
<TMM> Keybuk: simple hashtable with the different names assosciated with a dir, and default the names to C, translate at the vfs level :) bluefoxicy it is your job to get that idea pas linus! :P
<webben> It's stuck at version 17.0 from 2002. contrast: http://emacspeak.sourceforge.net/
<TMM> probably best to mark the dentries immutable though :)
<bluefoxicy> TMM:  hah, he hates me :)
<bluefoxicy> later
<bluefoxicy> TMM:  you want to talk to me about something random, try file systems.  :P
* bluefoxicy heads off
<TMM> bluefoxicy: he does?
<TMM> bluefoxicy: bye!
<TMM> bluefoxicy: ow, I've had this idea about a scattered filesystem! :)
<desrt> well
<TMM> bluefoxicy: basically, dump writes to the nearest emty place on the platter where the head happens to be, organise later
<desrt> it appears to have worked
* desrt wonders if it'll actually work
<TMM> desrt: you say it 'appears' to be working :)
<desrt> well
<desrt> it burned without error
<desrt> doesn't mean it'll install properly :)
<TMM> overburned an ubuntu disk?
<desrt> ya
<TMM> well, if it burned correctly, and you are real careful with the disk, it'll probably work once or twice :)
<TMM> dump it back to disk with dd to be sure :)
<desrt> i'll just install it :p
<TMM> I hope you've got another box :)
* desrt has a few dozen
<TMM> generally, it should work, if the cdr wasn't dirt cheap
<desrt> it's decent brandname.  i think it'll work.
<TMM> good luck
<TMM> btw, I've upgraded this install from dapper to edgy, and I don't think I'm missing any features
* desrt just likes that "clean install" feel :p
<TMM> desrt: gets old fast, when I discover that package I apt-get installed half a year back, I actually use a bit more often than I thought :)
<desrt> eh.  this isn't gentoo
<desrt> installing a package takes 12 seconds
<desrt> unless you're unfortunate enough to be on the go at the time you realise it's gone missing :)
<TMM> desrt: not without interweb it doesn't
* TMM wants a REALLY big disk, and mirror universe
<TMM> and main
<TMM> how large is universe and main combined these days anyway? :)
* desrt wonders how much of main is installed as per default
<desrt> like 50%?
<desrt> (ie: the union of ubuntu/kubuntu/xubuntu/edubuntu desktops)
<TMM> 'a config file can contain lines, and sections, a section can contain sections, lines and comments, a line can contain a comment and/or a key'
<TMM> 'a key can contain a value, a list of values or nothing'
<TMM> does that sound about right, describing, well, all config files? :)
<TMM> I'm missing something, I just can't quite put my finger on it
<tseng> desrt: there is alot more in main than -desktop
<tseng> LAMP is a good one
<TMM> anyone care to thing about my question please? :) pretty please? with sugar on top? :)
<TMM> I'm kind of all thought out on the subject, and, I've looked at one or two too many config files I think :)
<sladen> TMM: if you want an answer you a question, you have to actually ask it
<TMM> it WAS a question, just not on one line
<TMM> well, I thought it was a question anyway
<sladen> TMM: you may need to simply/repeat it.  Would was the quesition we missed?
<TMM> ok, I'll try again
<omnid> hi
<TMM> Does "a config file can contain lines of text and sections of lines of text." "A section of lines of text can contain : Sections of lines of text and lines of text", "A line of text can contain a comment and/or a key"  "a key can contain a value or a bunch of values" sum up how the vast majority of configuration files can be described, structure wise
<TMM> ?
<TMM> note the question mark :) 
<sladen> TMM: I see no question mark in that sentence.
<TMM> it was appended :P
<sladen> TMM: :)
<omnid> A configuration file that contains sections of text lines for setting up.
<TMM> omnid: 'for setting up' ?
<omnid> Is text of line setup key sections of lines.
<omnid> Words.
<sladen> TMM: it's a reasonable description
<TMM> sladen: I'm not looking for 'reasonable' I'm looking for watertight :)
<_ion> Well, a configuration file can be even a script, as is the case with the ion window manager. :-)
<TMM> _ion: in that case: no libnofconf loving for the ion window manager ;)
<TMM> _ion: also, wtf is 'the ion window manager'? I have a hunch that you might now :P
<_ion> apt-cache show ion3
<sladen> TMM: "A non-executable configuration file contains declarations that can be parsed by a computer program to perform setting of variables during initialisation.  Sections of the configuration file may exist that do not get processed, such as comments, header information, or declarations not relating to the particular program under scrutiny.  An example of a declaration could be 'x=10' by may be interpreted by a hypothetical as setting the value of a 
<TMM> _ion: I just found your website :) I dont think it'll be very funny to use the gimp with ion :)
<xt> sladen: not exactly right
<_ion> sladen: Seems like your IRC client doesn't split long lines.
<xt> amavisd-new's configuration file is perl code
<TMM> sladen: where did you paste that from? ;)
<xt> which means, it can be executed
<sladen> TMM: my keyboard.
<TMM> sladen: I was just teasing you ;)
<_ion> tmm: It's no problem at all. One just needs to create a "float" (as in not tiled) workspace for running gimp.
<sladen> TMM: perhaps you can combine that, your own and the improvements that xt would like to make into something more suitable
<TMM> sladen: I only got it up to "hypothetical as setting the value of a"
<sladen> TMM: An example of a declaration could be 'x=10' which may be interpreted by a hypothetical program as setting the value of a variable named 'x' to be the value decimal ten.
<TMM> sladen: thank you for that
<TMM> sladen: although, I wasn't looking for a scientificially correct definition of 'config file' but, more a technical description that would fit a generic parser tree for most config files :)
<TMM> _ion: I must say, I really like your website's layout
<_ion> I didn't know it has one. :-)
<TMM> _ion: it has the bare minimum :) and, still manages to pull off a 'designed' look, I love it
<TMM> _ion: http://www.modeemi.fi/~tuomov/ion/intro.html <--- that page is just sheer brilliance imho, it could use one rounded corner for the rightmost block, but, other than that, brilliance! :)
<_ion> That's not my website.
<TMM> _ion: it isn't? 
<tseng> TMM: ion is a window manager..
<tseng> for years
<TMM> I thought _ion did it... 
<TMM> because of the name, and all
<TMM> well, in that case, allow me to stfu and try and make myself look like less of a dumbass
<_ion> Well, i chose my nick years before the ion wm existed. :-)
<tseng> ion is a series of three leters
<TMM> tseng: _ion brought it up... so, well, I assumed...
<TMM> that is probably why 'assume' starts with 'ass'
* tseng shrugs, hunts for dinner
<TMM> sladen: do you have any suggestions if you look at my question in that light?
<madduck> 03 01:08 < Keybuk> jdong: md RAID probably won't work on edgy either
<madduck> i won't let this stand, Scott. :)
<madduck> but now is sleep time.
<bddebian> doko_: Are you actually around by any chance?
<madduck> dude, it's almost 3am here...
<bddebian> Yeah, and you're here aren't you? ;-P
<TMM> 2:38 am actually :)
<madduck> TMM: pedant. :)
<madduck> bddebian: i am not.
<TMM> madduck: ha! you should see my CFLAGS ;)
<madduck> mine beat that anytime, TMM :)
<TMM> madduck: well, if you put it like that, I am inclined to belive you :P
<madduck> oh, come on!
<madduck> i just had a caipirinha too many, that's all. :)
<TMM> I'm just tired and getting nowhere :)
<madduck> try reducing your CFLAGS and work upwards from there? :)
<TMM> madduck: the problem isn't the code, but the concept :)
<lexual> hi, I need to file a bug report for edgy knot 2 installer, I just need to know what package to file it for.
<lexual> The bug is when the installer gets to gparted.
<Fujitsu> Ah.
<Fujitsu> ubiquity.
<sladen> TMM: not sure, sorry.  Perhaps yours is a better start if that's what you need
<sladen> TMM: there's going to be parts of the file that need processing and parts which need ignoring (for whatever reasons)
<desrt> TMM; fwiw, all sorts of stuff that didn't use to work now works
<o_cee> is it just me, or is libcurl3-openssl-dev broken? can't install it..
<crimsun> (FWIW, installs fine in edgy)
<o_cee> mine complains about libkrb5-dev..
<crimsun> are you on dapper or edgy?
<o_cee> edgy
<o_cee> libkrb5-dev: Depends: libkrb53 (= 1.4.3-5) but 1.4.3-5ubuntu0.1 will be installed (translated from swedish..)
<crimsun> apt-cache policy libkrb53
<o_cee> http://pastebin.ca/159411
<crimsun> o_cee: remove the local package of libkrb53 you have.
<o_cee> crimsun: hrm, that would remove a lot of other packages.. 
<crimsun> dpkg -P --force-depends libkrb53
<crimsun> then, apt-get install libcurl3-openssl-dev
<crimsun> your local libkrb53 is preventing libkrb5-dev from being installed
<o_cee> thanks, give me a minute. no idea where a local version would be coming from though
<o_cee> thanks again, worked :)  any way to check for more of those?
<crimsun> look at your sources.list
<o_cee> anyone who knows what's happening to vmware-player that was supposed to get new modules?
<o_cee> crimsun: looks like it should, only edgy repos
<pradeep> uptime[5h 53m 2s] 
<pradeep> ^^ sorry
<robertj> Most people use passwords. Some people use passphrases. Bruce Schneier uses an epic passpoem, detailing the life and works of seven mythical Norse heroes.
<jono> robertj, :P
<mjg59> robertj: You're so a fortnight ago
<robertj> mjg59: your not gonna ruin my evening. No-sir-ree. I've just got done adding another exciting feature to my time-sink hobby project!
<mjg59> Haha
<robertj> People have been writing graphical user interfaces to text-based programs, but I'm one of the few & proud to provide a text-based interface to a first-person shooter!
<mjg59> robertj: Somebody did an IF Doom in 1998
<robertj> mjg59: this is line-level compatible with a shooter people still play though!
<robertj> hda to cheat a bit there. It wraps the network protocol stuff w/ SWIG, but the rest is in python :}
<mjg59> Nifty
<robertj> but after a month of python, I'm sold on it
<PenguinOfDoom> Will Edgy blow up in my face if I try to use it?
<robertj> PenguinOfDoom: perhaps, might want to ask in #ubuntu+1 as well
<hikenboot> hello all...I am remastering the ubuntu live cd...interesting enough when I boot the new live cd it gives me the choice to install it onto the hard drive or install a lamp server but not boot from the live cd...any ideas why this might be happening?
<welshbyte> hikenboot: sounds like you're using the alternate install CD instead of the live CD
<hikenboot> you got to be kidding ..what a moron I am all that work ...d*mn
<hikenboot> welshbyte, are most of the packages the same in both versions of the disk?
<welshbyte> hikenboot: i'm afraid i'll have to defer that question to someone who knows more about it than i do :)
<Fujitsu> hikenboot, the same versions.
<Fujitsu> Sounds like you have the server CD, though, so it'll be missing most of the stuff the alternate and desktop CDs have.
<hikenboot> not good it took me about 6 hours to pull all the "unncessessary" packages off the cd 
<hikenboot> so I could add my own
<sivang> morning
<Fujitsu> Evening!
<Burgundavia> morning sivang
<Burgundavia> ajmitch: ping
<Burgundavia> morning mvo
<mvo> good morning Burgundavia!
<Fujitsu> Good evening, mvo.
<Hobbsee> hey sivang, Fujitsu, mvo, Burgundavia 
<Burgundavia> hey Hobbsee
* mvo waves to Fujitsu and Hobbsee
<Burgundavia> Hobbsee: tell me about new and funky Kubuntu stuff last week
<Hobbsee> Burgundavia: no :P
<Burgundavia> Hobbsee: hmm, no UWN love for you then
<Hobbsee> Burgundavia: um.  i dont know of much myself, actually
<Burgundavia> right
* Hobbsee didnt commit much last week
<Hobbsee> that i remember about, anyway
* Fujitsu growls.
* Fujitsu kicks the wiki.
<Fujitsu> It is down really really frequently these past 3 or 4 weeks.
<Burgundavia> hmm, who did upstarts logo again?
<Fujitsu> It has a logo?
<Burgundavia> every Saturday night since LWE
<Burgundavia> most frustrating, as Sat. night is when we write and release UWN
<Fujitsu> LWE?
<Burgundavia> Linux World Expo
<Fujitsu> Ah.
<Fujitsu> It's not exactly acceptable... It is the ultimate resource, and any new people are going to get a bad impression when the primary help resource is down for several hours quite regularly.
<Burgundavia> yep
* Fujitsu wonders who designed the new Software Sources dialog.
<Fujitsu> The checkboxes are around the wrong way.
<Burgundavia> I understand there have been some systematic issues in the DC
<Burgundavia> Fujitsu: glatzor did most of the UI, but some bits are mvo
<Fujitsu> Shouldn't it go main, restricted, universe, muiltiverse, not universe, main, multiverse, restricted?
<Fujitsu> Otherwise it's a really great piece of work :D
<HiddenWolf> Fujitsu: I guess you just found a bug. :)
<Fujitsu> Is archive.ubuntu.com down as well!?
<Fujitsu> Hm.
<Fujitsu> Just being very very laggy.
* hunger gave up on upstart: Having to uninstall ubuntu-minimal, 3 kernel panics on upgrades so far (incl. with the newest deb) and no ttys coming up are enough for now:-)
<Burgundavia> hunger: ouch
<Fujitsu> It'd be nice if somebody added upstart as an alternative to sysvinit in ubuntu-minimal...
* hunger agrees.
<Burgundavia> get keybuk todo it
<HiddenWolf> That needs a main inclusion first, and a code review or two
<HiddenWolf> so that might take a bit
<Fujitsu> Or can't it Replace sysvinit, without main inclusion?
<madduck> w3m: Can't load https://wiki.ubuntu.com/.
<madduck> is this a known problem?
<Fujitsu> Yes.
<madduck> ok. thanks.
<Fujitsu> The wiki is down.
<Fujitsu> As is normal for this time weekly, it would appear.
<lifeless> any europeans around ?
<madduck> does .ch count? :)
<lifeless> someone needs to rng a sysadmin
<madduck> rng?
<lifeless> and international is not as cheap as irc:)
<lifeless> ring
<lifeless> phone 
<lifeless> page
<lifeless> alert
<giftnudel> if you do anything bad, I won't tell you that i'm european
<madduck> well, gimme phone number...
<lifeless> mmm, i dont know the privacy status of their numbers, sorry
<madduck> whom to call? elmo?
<madduck> and is this really an exceptional state?
<lifeless> help.ubuntu.com is down
<lifeless> and wiki.ubuntu.com
<Hobbsee> it's not usually a good idea to give out other people's numbers
<lifeless> Hobbsee: well duh ;)
<Hobbsee> you could call someone like Riddell, but i doubt he could help
<mdke> I've reported it
<lifeless> mdke: IRC is not a report
<madduck> i have elmo's number
<Hobbsee> his numbers/address/etc seem to be in his email signature :P
<mdke> lifeless: why do you say IRC?
<mdke> I filed an RT report
<lifeless> mdke: ok, cool. 
<lifeless> mdke: but we still have an escalation procedure
<madduck> then they'll know. better not call...
<mdke> ah good. I thought that someone would be scheduled to work on sunday
* lifeless seriously doubts any of them will be caring for non-urgent on sunday
<mdke> last week when the same thing happened Spads dealt with it quickly
* Hobbsee wonders what RT means
<madduck> request tracker
<Hobbsee> ah
<StevenK> Hobbsee: http://en.wikipedia.org/wiki/Request_Tracker
* StevenK buggers off again
<Hobbsee> StevenK: do my physics assignment, as you're clearly smart.  kthnksbye!
<Seveas> sladen, ? 
<Riddell> infinity: need a european?
<finalbeta> Does ubuntu have an alsa dev channel?
<sivang> crimsun: ping
<sivang> crimsun: if you did the patch against the ubntu devel lp team branch, please know that I'm working on a next major version branch linked from the wiki specification page
<sivang> crimsun: thanks for the fix though :-)
<mempf-edgy> why has there been little no no updates the past couple on days?
<Hobbsee> mempf-edgy: because it's a weekend
<mempf-edgy> lol
<mempf-edgy> im looking forward to next kernel update
<mempf-edgy> as according to launchpad my card readers should start working again
<kmon_> Hobbsee: I've opened a bug report on the kernel on knot cd1. Ben collins said the fix was on the next kernel update, but after trying knot cd 2 the issue remains. Should I change the status of the bug (it's fixed released right now) or wait to see what ben says? I'm afraid that since the bug is marked as fixed maybe the new comments aren't noticed
<phanatic> kmon_: you don't need to be afraid imho
<Hobbsee> kmon_: they are noticed.  probably reply back that the fix didnt work, and set it back to confirmed, or whatever it was
<kmon_> ok, Hobbsee thanks
* kmon_ leaves
<zyga> re
<Burgundavia> Riddell: ping
<Burgundavia> ajmitch: ping
<zul> heylo
<Burgundavia> hey zul
<Burgundavia> any news on the Xen front this week?
<zul> im working on the nvidia stuff and adding drivers to the xen tree
<zul> other than that no :)
<zul> it doesnt help that my laptop also died
<Burgundavia> that sucks. So nothing released this week?
<zul> bug fix was uploaded on friday
<zyga> zul: what's happened to the laptop?
<zul> hard drive died
<zyga> zul: the mechanical stuff or the electrical?
* zyga wants those flash disks to dominate the laptop word....
<zul> mechanical i think
<Burgundavia> doko: ping
<doko> what's up?
<ne78> I see that edgy has mesa cvs 20060817, does the edgy xserver-xorg includes the AIGLX compositing patches to make compiz works ?
<Burgundavia> ne78: yes
<Burgundavia> edgy includes upstream xorg 7.1, which includes aiglx
<ne78> Burgundavia: those patch are taken from the rpm and not yet it the git xorg tree, am i right ?
<Burgundavia> afaik, not being an X developer, aiglx is fully merged
<mjg59> compiz works fine with the code in edgy
<mjr> I also have the impression that aiglx is merged in the main xorg tree
<ne78> mjr: yes but it miss some redhat specific patches to add aiglx Composite fix
<mjr> ah
<mjg59> Not really, no
<ne78> mjg59: why doesn't xserver-xorg from debian (now 7.1) works with compiz
<mjg59> Without knowing how it fails, I have no idea
<mjg59> But there's no further code /needed/
<ne78> mjg59: i'm refering to http://lists.debian.org/debian-x/2006/08/msg01558.html, it says lus some additional patches by Kristian Hgsberg (patches taken directly from the Fedora source RPM).
<ne78> mjg59: i would be happy to learn that those are unnecessary
<ne78> ok i found the in the http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg-server/xorg-server_1.1.1-0ubuntu9/changelog
<ne78> nice, was compiz a target of etch ?
<mjg59> We carry a couple of patches from Fedora, but they're not required
<mjg59> They fix a crash on vt switching and add support for automatically disabling offscreen pixmaps when necessary
#ubuntu-devel 2007-08-27
<zerwas> What do you think about having the option to install the package ubuntu-restricted-extras? nearly every user will want to have the programs in it
<zerwas> i mean, having the option at the installation of Ubuntu
<sbalneav> Any core devs around who're willing to sponsor a debdiff for me, related to bug #134572
<ubotu> Launchpad bug 134572 in nbd "Segfault" [Undecided,Fix committed]  https://launchpad.net/bugs/134572
<xtknight> sbalneav, what debdiff do you mean?  this would be job of MOTUs/helpers but i dont see patch here?
<fabbione> morning
<sbalneav> Morning fabbione
<siretart> moin
<Hobbsee>  hiya siretart
<siretart> asac: okay, I've now built an wpasupplicant 0.5.8 package (latest stable release), and it is working for me okay
<siretart> asac: i.e. I see no regressions over 0.6.0, whereas I've uploaded a regression fix for that to unstable
<siretart> huhu Hobbsee
<kkkklee> hi,all
<saispo> hi
<saispo> BenC: ping ?
<asac> siretart: ok wanna push to ppa?
<asac> siretart: or let me know where i can fetch it ... so i can ask forum users to test if there are improvements/regressions over 0.6
<siretart> asac: however you prefer
<asac> siretart: you can decide ;)
<seb128> siretart: hi, is somebody working actively on emacs22?
<siretart> asac: http://siretart.tauware.de/upload-queue/
<siretart> seb128: mwolson and me as backup/reviewer/sponsor. or do you mean at upstream?
<seb128> siretart: ubuntu, I was wondering if bug #134308 is a packaging issue and if somebody is working on it
<ubotu> Launchpad bug 134308 in emacs22 "python-mode does not work" [Undecided,New]  https://launchpad.net/bugs/134308
<siretart> seb128: hmm. works for me
<seb128> siretart: "call-interactively: Cannot open load file: python-mode"
<siretart> seb128: do you have the package 'python-mode' installed?
<seb128> siretart: no, it wants to install emacs21
<seb128> "Depends: emacs21 | xemacs21-bin | emacs-snapshot, pymacs (>= 0.22-6)
<seb128> "
<siretart> ah, then it seems that python-mode needs to be adapted for emacs22
<siretart> strange why it works for me, though.. hmm
<seb128> siretart: do you have a local update you didn't upload? ;)
<coNP> I guess emacs22 finds and installs it. Maybe you have emacs21 | emacs-snapshot installed as well
<siretart> seb128: no, it seems that emacs22 hat its own python-mode builtin now. see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424973
<ubotu> Debian bug 424973 in python-mode "python-mode: please support emacs22" [Normal,Open] 
<siretart> and this sb-info error is something I've already had on my emacs21 installation at university. it is a bug somewhere else
<siretart> it seems to me that it doesn't make sense to port the python-mode package to emacs22 if it has its own version of 'python-mode.el' builtin
<seb128> ok
<seb128> I had python-mode still configured
<seb128> which means /etc/emacs/site-start.d/50python-mode.el installed
<siretart> I wonder why you get then the error message 'call-interactively: Cannot open load file: python-mode'
<seb128> without it the emacs22 version works
<siretart> oh yummi. It doesn't check if it has been removed but not purged. *sigh*
<siretart> seb128: do you actively use emacs for development? I thought you're rather a vim guy
<seb128> urg, no I don't use vim, I use nano and emacs
<seb128> and sometimes gedit ;)
<siretart> ah :)
* coNP would be seriously disappointed if Master Sebastien would use vi :)
<seb128> coNP: heh ;)
<seb128> siretart: confirmed, if you remove python-mode and let it configured it breaks emacs22
<siretart> seb128: ah, what I've expected. do you want to handle that or shall I do it later this week?
<seb128> siretart: would be nice if you do
<seb128> thanks
<siretart> okay, I'm updating the bug
<siretart> asac: as I mentioned before, there is a nasty regression in our 0.6.0-1 package, which has been fixed in 0.6.0-3. It is very likely to cause some of the problems we currently have in lp
<asac> siretart: which ones?
<siretart> asac: I'd suggest that we sync wpasupplicant_0.6.3-3 in any case, and can still decide if we want to downgrade to 0.5.8
<asac> siretart: sure ... but what regressions?
<siretart> asac: the regression is if you have zero lenght essid in your wpasupplicant config. this is usually used in roaming situations (like nm does)
<asac> due to our patches? ... or does -3 contain prepatches?
<siretart> wpasupplicant won't associate to any AP if you don't explicitly say which ESSID it should connect to. this is a clear regression to the 0.5 branch
<siretart> asac: yes, as I said before, this regression has been fixed in 0.6.0-3, which I've uploaded to unstable yesterday
<siretart> we currently don't have any patches in the ubuntu wpasupplicant. I'd prefer to keep it that way if possible
<asac> is that only a problem for config file scenario?
<siretart> it is a problem if you use zero length ssids for roaming
<asac> siretart: you mean we don't have a patchsystem ... or do you mean we don't have more patches than debian has?
<siretart> I'm not exactly sure if nm uses wpasupplicant this way
<siretart> asac: I'm talking about this patch: http://svn.debian.org/wsvn/pkg-wpa/wpasupplicant/trunk/debian/patches/10_fix_non_wpa_zero_len_ssid.dpatch?op=file&rev=0&sc=0
<asac> siretart: nm uses wpasupplicant through socket ... interface ... e.g. without configuration file
<siretart> (included only in -3)
<siretart> asac: again. depending on if nm is using this zero length essid roaming feature of wpasupplicant (which I think is likely), it might (or might not) explain some of the bugs we have
<asac> siretart: whatelse is in upstream svn that we might want to cherry-pick?
<asac> (or upstream git .. or whatever) :)
<siretart> upstream has changed to git for the 0.6.x series
<siretart> TBH, no idea. I didn't follow the commit mails lately.
<asac> siretart: it definitly doesn't use zeor length ssid if you click on the network in applet ... but it might use it if you manually configure your network ... i would have to check that.
<siretart> you can nowadays 'manually configure wpa'?!
<asac> i think so
<siretart> since when? I thought that button just disabled NM and brings gnome-system-tools back to live (which doesn't support wpa at all)
<seb128> siretart: it should in gutsy
<asac> siretart: just tested ... manual configuration allows to select wpa ...
<siretart> ah. great news!
<asac> siretart: probably not nm itself as you said
<siretart> again, I'd suggest that we sync -3 in any case now, and continue deciding about downgrading to 0.5.8
<asac> siretart: however for normal nm mode it doesn't use roaming without explicit ssid, unless you have never been connected maybe.
<asac> siretart: sure ... you have upload rights?
<siretart> err, yes. but this goes anyway via the archive admins, since it is a sync
<siretart> read, via seb128 :)
<asac> seb128: can you please sync?
* asac still doesn't understand why to put load on archive admins ... in these cases
<siretart> asac: because there is still no gui in launchpad for syncs
<asac> siretart: ... well but why not just upload :)
<seb128> asac: what cases?
<soren> siretart: No, but we could do it manually.
<asac> seb128: wpasupplicant ... in case the auto-sync is disabled
<asac> seb128: like now ... where is the difference from just me uploading the debian version ?
<soren> siretart: Grab the version from Debian, generate a changes file with the proper distribution set, and upload. voila.
<seb128> right, auto-sync are disabled during the freeze
<siretart> soren: we could, but were will be beaten with a large stick by Mithrandir if we would do that
<seb128> asac: you can't, the distro target is unstable and it'll not be accepted in gutsy
<asac> seb128: oh right.
<soren> siretart: Yes, because that's what the policy says now. I agree with asac that it's a bit silly.
<siretart> seb128: you can change the target distribution using changestool(1) (found in the reprepro package)
<seb128> starting messing by hand with .changes is a good way to screw something
<soren> seb128: It's not really all that difficult to change. "dpkg-genchanges -Ddistribution=gutsy [...] "
<asac> seb128: yeah ... can you push the button for wpasupplicant? or do you want a bug?
<seb128> asac: will do the sync now
<asac> seb128: thanks a lot :)
<soren> seb128: We could even wrap it up in a nice script that does the right thing.
<soren> seb128: Isn't that what the sync script does anyway?
<soren> seb128: The one you (the archive admins) use?
<siretart> soren: there is a nice script for that, but only available for the archive admins. I think there is little point to argue about this issue, since there spec for that is nowadays called 'NativeSourceSync'
<seb128> soren: well, I would not like having everybody starting to modify .changes
<soren> seb128: Right, hence the script. :)
<siretart> the spec was there since the beginning of launchpad, and has changed name several times so far, AFAIK
<seb128> with script or not
<soren> siretart: link?
<asac> seb128: well ... its you who gets the load ... even if its neglectable it still causes an interrupt in your current workflow :)
<siretart> soren: https://blueprints.launchpad.net/soyuz/+spec/native-source-syncing
<seb128> soren: the correct way would be to have a "sync this package" button on launchpad than anybody in the correct team could use
<asac> seb128: if you say you like it then there is really no point to argue ;)
<asac> seb128: well, but why not trust the people in the correct team to be able to use a script?
<seb128> asac: you can't restrict the script usage to a team
* siretart agrees to asac. you need to sign the upload with your gpg key anyway
<asac> seb128: yes, but the upload would die in the upload queue if some motu uploads to main for example
<siretart> this effectively limits the script usage to the correct persons
<asac> seb128: or do you want more fine grained access-control?
<seb128> no, people with upload rights would be ok I think
<siretart> asac: nah, you could just put it to the devscripts package and let people use their own gpg keys for restricting uploads
<seb128> well, nobody stop you to hack the .changes nowadays
<asac> seb128: then all should be fine ... give use the script ;)
<seb128> I've no strong opinion about it
<asac> seb128: right ... but it appears that today it would be kind of technical high-jacking ;)
<seb128> asac: I can't, the archive admin script needs connects to soyuz
<asac> seb128: anyway :) ... as long as archive-admins can cope with sync requests its fine for me.
<seb128> it does verification to know if there is Ubuntu changes, on the version, etc
<asac> seb128: ok i see ... so it gives you a warning and asks you to confirm that you want to drop ubuntu changes when pressing sync button?
<seb128> yes
<seb128> asac: anyway, wpasupplicant synced
* asac hugs seb128 
* seb128 hugs asac
* siretart joins the hug party :)
<siretart> asac: how do you want to proceed with testing the 0.5.8 package? - use ppas? - call for testing on u-d@l.u.c?
<Amaranth> if you go the PPA route wait until tomorrow so you can use the real one
<asac> siretart: yes i want to ask people in forums as well ... there is already a thread about network-manager
<asac> Amaranth: is it for sure that tomorrow things get for real?
<Amaranth> no
<Amaranth> it's a hope
<asac> hehe
<siretart> asac: cprov mentioned on the launchpad-users mailing list that he works on it to move it today
<asac> siretart: ok cool ... maybe i will bug him later to confirm. better wait for real ppa if at all possible imo.
<siretart> asac: in which team do we want to publish the package?
<asac> siretart: in the meantime we can ping people with roaming issues in malone to see if things improved for them with new wpa
<asac> siretart: no idea ... i thought about private archive ... either yours or mine
<asac> siretart: unless we want to start a network-managerandfriends team :)
<siretart> I haven't activated my ppa yet, and wanted to delay that as long as possible. I've noticed that I'm hitting my quota very fast otherwise
<siretart> I thought about using the desktop-teams ppa (but I'm not an admin nor a member there)
<siretart> or the ubuntu-core-dev's teams ppa
<Tonio_> seb128: ping ?
<Tonio_> hi there ;)
<seb128> Tonio_: hi
<Tonio_> seb128: hey, little question...
<seb128> Tonio_: ping with context = better ;)
<seb128> sure
<Tonio_> seb128: how to you perform a "buildprep" equivalent when not using cdbs on a gnome package ?
<Tonio_> seb128: and having a patch that touches makefile.am files
<seb128> what do you call "buildprep"?
<Tonio_> seb128: we use that with kde to apply patches, generate makefiles.in and unapply patches
<Tonio_> instead of regenerating them during the build
<seb128> hum?
<Tonio_> seb128: do you have an equivalent for gnome or not ?
<seb128> I'm not sure to understand what you want to do
<Tonio_> seb128: I have a gnome app and a patch that touches a makfile.am file, and I'd like the makefile.in file to be generated according to the patched makefile.am
<Tonio_> seb128: I wondered what is the good way to do that with gnome in your (for example) packages
<Tonio_> seb128: we have a cdbs "buildprep" rule to do that for kde apps, which patches, regenerate files and unapply patches
<Amaranth> you run automake and diff the two
<seb128> as I replied in query we usually do an autotools patch
<Tonio_> oki thanks ;)
<sheskar> Why does the restricted-manager install firmware to /lib/firmware/$KERNELVERSION by default? I have a Broadcom 4311 wireless and after a kernel upgrade the connetion was always gone. bcm43xx-fwcutter installs the firmware to /lib/firmware and it always works with upgrades (now I don't use restriced-manager anymore).
<sheskar> Wouldn't it be better if the restricted-manager just installed the firmware to /lib/firmware and leave it there for all kernels?
<ion_> sheskar: ubuntu-bug -p restricted-manager
<herzi> seb128: https://bugs.launchpad.net/ubuntu/+source/vte/+bug/89660
<ubotu> Launchpad bug 89660 in vte "control-cursor-key regression in vim" [Low,Confirmed] 
<soren> mathiaz: You already discussed https://bugs.launchpad.net/ubuntu/+source/samba/+bug/128548 a bit, right?
<ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Wishlist,In progress] 
<soren> mathiaz: What was the conclusion?
<mathiaz> soren: we discussed that with seb128 and infinity a couple of days ago
<mathiaz> soren: the first step was to enable it in samba
<soren> Sure.
<soren> And in user-setup, probably.
<mathiaz> soren: and the second step was to add a new permission/role to the user and group management application
<soren> mathiaz: Which would map to a group membership, surely?
<mathiaz> soren: yes
<soren> I'm not too hot on the smbshare group idea, actually.
<mathiaz> soren: why ?
<soren> Well, I think the nicest thing to do would be to provide this option to users without any furhter configuration.
<soren> This requires adding a group to base-config (and user-setup).
<soren> ...but it's not very nice to have a package specific group in there (smbshare is Samba-specific)
<soren> ...so I'd rather have a "fileshare" group or something like that.
<soren> I also think it's likely that the set of users you'd allow to use samba to share files is the same set of users you'd allow to share files with other protocols (webdav, http, whatever).
<mathiaz> soren: I think we discussed that, and cjwatson_ said that adding more groups to base-config is not such a good idea
<mathiaz> soren: ok. So you'd just change the name of the group.
<soren> mathiaz: And I agree with that. That's why I want to avoid having to do it next time a new appliaction comes along that allows pretty much the same thing only with a different protocol or something.
<soren> mathiaz: Naming it generically helps avoid that.
<soren> We could go even further and add the missing "users" groups.
<mathiaz> soren: we could. I think this should be discussed on ubuntu-devel.
<soren> There's a bunch of different things we want to provide to all *actual* users, but not to all system users (not www-data, for instance).
<soren> mathiaz: Agreed. I just wanted to know what the status of the discussion was.
<mathiaz> soren: well IIRC, it was not a good idea to add more system groups
<mathiaz> soren: as we're running out of space for them
<mathiaz> soren: cjwatson was not too keen on adding another group.
<soren> mathiaz: Ah, yes.
<mathiaz> soren: that was the argument against adding a group to base-config.
<soren> mathiaz: Debian has already added it.. Hm..
<mathiaz> soren: are you talking about the users group or smbshare/fileshare group ?
<soren> Hmm.... We *have* the users group. We just don't add users to it.
<soren> Hm... That makes it a lot easier.
<soren> mathiaz: Well, both, actually.
<soren> mathiaz: I was contemplating allowing this to all users (human users, that is).
<soren> mathiaz: ...so using the "users" group for the net usershare stuff.
<mathiaz> soren: hum... users may be too general
<soren> mathiaz: Possibly.
<mathiaz> soren: if we follow your users idea, why not add all the privileges/roles from the user and group management applet to the users group ?
<mathiaz> soren: we're adding the users to a couple of groups anyway by default
<soren> Indeed.
<soren> Well, in most cases, the only distinction you really need is "admin user"/"regular user"/"system user".
<realist> root/wheel/luser - you mean?
<soren> No.
<soren> We don't use the root user for anything.
<soren> ...and don't have a wheel group.
<realist> Was an example
<mathiaz> soren: well - there is no real difference between an admin user and regular user
<soren> "user with sudo privileges (i.e. member of admin)"/"regular users"/"system users like nntp, bin, www-data, etc."
<mathiaz> soren: an admin user is just an regular user that has a entry in the sudoers file.
<realist> mathiaz: one's in sudoers - one isn't?
<mjg59> No
<soren> mathiaz: Sure there is. My girlfriend^Wwife has an account on my laptop, but she sure has heck can't sudo on it.
<mathiaz> soren: from a user/group point of view I mean
<mjg59> We don't add users to the sudoers file
<mjg59> We add the admin group
<xtknight> what's the status of this bug?  Bug 42321
<ubotu> Launchpad bug 42321 in xrandr "xrandr reports invalid refresh rates for MergedFB setup" [Medium,Confirmed]  https://launchpad.net/bugs/42321
<realist> mjg59: equivalent to wheel elsewhere
<soren> Most of the groups we have are there to either limit what system daemons can fiddle with or to limit which sort of hardware you can fiddle with.
<mjg59> realist: If there's weird some part of the world that puts the wheel group in sudoers, yes
<realist> mjg59: plenty of people do
<mjg59> But it's not the traditional meaning of wheel
<realist> mjg59: which is?
<mathiaz> soren: well. That's what I meant - which is that an admin user is just a regular user that is part of the admin group
<mjg59> su was only executable by people in the wheel group
<mathiaz> soren: it's just another role - the same way as a user would be allowed to share files or not.
<soren> mathiaz: Well, yes. My point was more that (in this context) there are three kinds of users on the system: "users who should be able to break it"/"the other human users"/"the system users".
<mathiaz> soren: ok. So what would you suggest ?
<mathiaz> soren: we add a new group, fileshare ?
<realist> mjg59: also root files had wheel gid
<mathiaz> soren: how would this work for nfs sharing for example ?
<soren> mathiaz: With regard to this particular samba issue, yes.
<soren> mathiaz: It doesn't right now.
<soren> mathiaz: A few months ago, it didn't work with Samba either :)
<mathiaz> soren: could we use this group to implement the same kind of access control for nfs sharing ?
<soren> mathiaz: At some point, someone might create a method for certain users to share stuff via nfs. At that point, we already have a group for that purpose.
<mathiaz> soren: If we want to add a new group to the base-config, we'd better come up with some scenario about it.
<mathiaz> soren: for nfs, which groups owns /etc/exports ?
<soren> mathiaz: root, probably.
<mathiaz> soren: so we could change the group of /etc/exports to fileshare ?
<mathiaz> soren: and make it group-writable also
<mathiaz> soren: can I standard user call exportfs to reload the shares ?
<soren> mathiaz: Don't think so.
<soren> mathiaz: I also don't like changing the group of /etc/exports.
<mathiaz> soren: so how could the fileshare group be used to implement an access control to nfs sharing ?
<soren> mathiaz: I don't know. NFS sharing was just an example.
<soren> mathiaz: My point is this:
<soren> mathiaz: Rather than adding a group that "is allowed to share files with samba by way of calling net usershare", I'd rather have a group that "is allowed to share files over the network in various ways".
<soren> mathiaz: The point is: If there was a mechanism for nfs similar to "net usershare" for samba, I can't imagine you'd provide said option to a different set of users.
<realist> Is a unix group really necessary for this though?
<mathiaz> soren: ok. And you'd like to add this group to base-config ?
<soren> realist: Yes.
<soren> :)
<mathiaz> realist: for samba - yes.
<mathiaz> realist: that's how it's implemented in samba.
<soren> mathiaz: Possibly, yes.
<realist> It is? Since which version?
<soren> mathiaz: I dislike forcing the user to mess about with group memberships directly.
<soren> mathiaz: A possible solution is to have the first user added to this group by default. To do that, it needs to be added to base-passwd.
<mathiaz> soren: yeah. That's why there is the 'user privilege' tab in the user and group management application.
<soren> mathiaz: Another solution is to make use of the "users" group, since that actually is the most common level of granularity needed.
<soren> mathiaz: Yes, I'd also like to avoid that. :) I just want this to work out of the box.
<mathiaz> soren: seb128 said there is way to automatically do that. But I don't know how.
<soren> mathiaz: Do what?
<mathiaz> soren: add new users to groups
<mathiaz> soren: or when a new user is created, he has a set of default privileges.
<soren> Hmm...
<soren> Dunno.
<soren> adduser doesn't do it.
<realist> I always get adduser and useradd confused, but one of them should have a -g switch
<realist> Not sure about the default group settings though
<soren> mathiaz: Will you write something clever to discuss this on the mailing list?
<mathiaz> soren: I could. The other issue is that we're passed FF.
<mathiaz> soren: So I'm not sure we could get it included anyway.
<soren> mathiaz: Possibly not, but that gives us a lot of time to discuss it. :)
<mathiaz> soren: we could register a spec for UDS and discuss it there.
<soren> mathiaz: Sounds sensible.
<tkamppeter> doko, Riddell, I have packaged a new s-c-p, see your mail.
<doko> tkamppeter: will upload it today
<tkamppeter> doko, thanks
<phoenix7> i'm customizing ubuntu-usplash-theme package, is it neccessary to change usplash-theme-ubuntu.c especially Palette indexes section in the code?
<phoenix7> ubuntu usplash theme is mix of nearly red,yellow,green colors and kubuntu is blue but i have lots of light green.
<phoenix7> sorry, ubuntu-> red,yellow,orange
<phoenix7> now my logo and text disappear well but progress baar is very ugly
<saispo> BenC: ping ?
<phoenix7> i have a light green usplash theme, how can i calculate values of section palette indexes in the usplash-theme-ubuntu-c file?
<BenC> saispo: pong
<saispo> BenC: can you say how can i fix the rate on my wifi card ?
<saispo> i use bcm43xxxx but under gutsy it's 24mbits and not 54 mbits
<pygi> goedson, goedson :)
<goedson> Hi, pygi.
<pygi> goedson, we need to talk :D
<asac> siretart: what do you mean by nm doesn't detect you iwl driven interface?
<asac> siretart: can you see/use it with iwconfig and friends?
<saispo> no sound on gutsy tribe 5 :/
<saispo> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/131368
<ubotu> Launchpad bug 131368 in linux-ubuntu-modules-2.6.22 "Dell 1420n audio not supported under Gutsy" [High,Triaged] 
<saispo> will be fixed ?
<siretart> asac: after I sent my post, I noticed that the device was named 'wlan0_renamed'..
<asac> ouch
<asac> hmmm ... but would it matter?
<siretart> hm. iwlist says my 'wlan0_rename  No scan results
<asac> i guess you run iwlist as root?
<siretart> aah, as root I see networks
<asac> yeah
<asac> iwlist not as root doesn't scan ... just dumps the cache
<siretart> this is strange, because with ipw3945, I didn't need priviledges
<asac> well ... thats a driver issue then... afaik its official that it only actively scans when run as root
<siretart> aha?
<asac> siretart: though it might be that your running wpa/nm scans in background
<siretart> thats... interesting
<asac> so your cache is filled
<siretart> no, no wpasupplicant running
<siretart> and nm doesn't detect the card anyway
<asac> siretart: look at man iwlist
<siretart> anyway, need to leave now, will continue to investigate tomorrow
<asac> its there :"Triggering scanning is a privileged operation (root only) and  normal  users  can  only  read left-over  scan  results ..."
<infinity> siretart: He means that on ipw3945, your cache may have been filled, hence why you didn't think you needed root to scan.
<siretart> infinity: this doesn't explain why iwlist as user doesn't show the cache contents with iwl, whereas ipw did
<asac> siretart: i would like to fix that nm detects the card ... maybe it will just work ;) ... compared to ipw3945 which causes so much pain
<infinity> siretart: because you have no cache contents, because nothing's been doing background scanning.
<siretart> asac: kelmo also said that they closed a lot of bugs by switching to iwl
<infinity> siretart: Which could be because NM doesn't detect your card, for instance.
<asac> siretart: yeah ... all my hope is now on iwl ;)
<asac> siretart: if you get wpasupplicant going chances are high that nm can do it too :)
<siretart> hm. will continue research tomorrow. Cu tomorrow, guys!
<asac> siretart: cu
<mantiena-baltix> hi developers :)
<mantiena-baltix> who is responsible for linux-restricted-modules ? there is very big memory usage because of mountiing restricted modules into RAM (tmpfs)
<ogra> mantiena-baltix, you are not forced to install them :)
<ion_> I dont like it either, but due to license reasons, i hear thats the only way to go. They do get swapped out when the memory is needed, though, so its not as if theyre there eating your RAM all the time.
<ogra> (we dont install them by default in ltsp for example to save the 15M the volatile fs eats)
<ogra> ion_, they eati it on boot
<ogra> *eat
<ion_> ogra: Yes.
<mantiena-baltix> ogra, ion_ : lots of users can't boot from feisty LiveCD, because volatile modules eats about 34 MB RAM
<mantiena-baltix> why we can't do mount --bind instead of mounting into tmpfs ?
<mjg59> mantiena-baltix: --bind from where?
<mjg59> You realise the volatile stuff is built on bootup, right?
<mantiena-baltix> mjg59, yes, --bind can be used with symlinks too
<mjg59> mantiena-baltix: I'm sorry, I don't understand. What do you want to be bind mounted?
<mjg59> mantiena-baltix: The files in volatile simply don't exist before the system has booted
<danimo> BenC_: hi! any idea what changes in 22-9 or 22-10 totally changed (and rendered useless) the alsa driver for my Intel HDA card (82801FB/FBM/FR/FW/FRW (ICH6 Family))?
<BenC_> danimo: yes, and it should be fixed in lum today
<mjg59> danimo: Known issue. Will be fixed in the next upload.
<zul> maybe it should be added to the /topic not that anyone reads that anyways ;)
<danimo> ok, cool :)
<mantiena-baltix> mjg59, yea, it seems or you really don't understand me, or vice versa...  volatile modules are installed into /lib/linux-restricted-modules/2.6.xxx/ , right ?
<bhale> zul: /topic should support <blink>
<mjg59> mantiena-baltix: No, they're *built* in there
<mjg59> Before they're built, they don't exist
<zul> bhale: that would be annoying
<ion_> You could make chanserv send a notice about reading the topic to people on join.
<mantiena-baltix> mjg59, could you explain me  what means *built* in ?
<mantiena-baltix> look at http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=linux-restricted-modules-2.6.22-10-386&version=gutsy&arch=i386&page=3&number=50
<mjg59> mantiena-baltix: The files that end in .ko do not exist on the CD.
<mantiena-baltix> AFAIK restricted modules are *installed* into /lib/linux-restricted-modules/2.6.xxx/
<mjg59> mantiena-baltix: The .o files that are provided on the CD are passed to gcc and turned into a .ko
<mantiena-baltix> oh
<mjg59> The .ko is saved in the volatile directory
<mantiena-baltix> ohhh
<mantiena-baltix> and this is done during bootup, right ?
<mantiena-baltix> I thought, that .ko are simply renamed .o files :)
<mjg59> This is done during bootup, yes
<mantiena-baltix> mjg59, so, why linux-restricted-modules-2.6.xxx packages can't provide .ko files ?
<mjg59> Licensing issues
<mantiena-baltix> fuck
<mjg59> We tend not to do stupid things without having a reason to do so :)
<mantiena-baltix> hehe
<mantiena-baltix> I think we can always find better solution - as I see gutsy restricted modules eats more than 40 megabytes RAM and this cause not working LiveCD on systems with 256 RAM :(
<ScottK> Gutsy live cd works fine for me a 256mb system that does not need lrm except for wireless and modem (i.e. not for video).
<mjg59> Well, we could (a) not provide restricted-modules, (b) get the source code to them released, (c) relicense Linux to something that isn't under the GPL
<mjg59> Actually, that's not entirely fair. We could (in most cases) only build the drivers if the hardware is present
<mjg59> Which would break hotplugging, but that's only an issue for a minority of the modules
<ion_> It wouldnt break hotplugging, if done right.
<ion_> Something like this might work: read modalias lists from the .o files, write them to /etc/modprobe.d/aliases.lrm, add a hack that links the .ko file on demand when modprobing given module.
<ion_> install nvidia /sbin/lrm-foobar build nvidia && /sbin/modprobe --ignore-install nvidia
<ion_> Or something like that
<mjg59> ion_: Sweet. You get to implement it :)
<ion_> The fact that it takes like two hours to build l-r-m on this box somewhat discourages me from doing stuff with it. :-\
<gicmo> ok, something is totally broken regarding tex on my system
<gicmo> ;-(
<mantiena-baltix> ScottK, maybe you are using  Gutsy on system, which has non-integrated video ?
<mantiena-baltix> mjg59, I also think, that best solution is to build only these restricted .ko modules, which are really needed for real computer
<ScottK> It's an old laptop with an old ati video module that's well supported with free drivers.
<mathiaz> kylem: what's the status of the unison patch for apparmor ?
<ScottK> mantiena-baltix: It's a Dell Latitude L400.
<mantiena-baltix> hehe, try LiveCD on system with intel integrated video
<superm1> Riddell, you here?
<ScottK> mantiena-baltix: I've done that on a Intel 865 series motherboard and it worked fine.  Of course it had way more than 256mb ram.
<ScottK> Gotta run.  Good luck.
<gicmo> ok, is this gutsy's fault or what the heck do I do wrong when an example (moderncv) doesn't compile on a very much clean gutsy install ;-/
<Riddell> superm1: yes
<superm1> Riddell, the SRU procedures for motu were a bit vague, but i believe i followed them as expected from the wiki page earlier this past weekend.  I was hoping to get an archive admin to ack the SRUs sooner than later though because there is a time deadline upon the ones I uploaded
<superm1> bugs 134726 and 134801
<ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134726
<ubotu> Launchpad bug 134801 in mythplugins "Mythplugins 0.20.2 SRU " [High,New]  https://launchpad.net/bugs/134801
<Riddell> superm1: can you not backport the fix?
<superm1> Riddell, unfortunately not.  There is an ABI change
<superm1> involved with it
<Riddell> superm1: why does there need to be an ABI change?
<superm1> Riddell, the data is stored differently in the database
<superm1> at least the guide data is.
<Riddell> superm1: but a database change shouldn't cause an ABI change?
<superm1> Riddell, other machines (frontend or backend) need to all be at that same ABI when reading from the database is my understanding.
<Riddell> superm1: I'm not convinced it passes the SRU rules for minimal necessary changes, however it's ubuntu-sru you need to convince
<superm1> Riddell, i already mailed the TB about that.  Let me grab a link to that post
<superm1> Oh technical-board isn't a public mailing list is it.  Well i'll pastebin his email back to me then at least
<superm1> http://paste.ubuntu-nl.org/35286/
<Riddell> superm1: ok, but that's not an approval
<saispo> can you say how can i fix the rate on my wifi card ?
<superm1> Riddell, right.  So at this point, what should I do then?
<Riddell> superm1: e-mail back tech board and ask for an approval of those bugs
<Riddell> or pitti
<superm1> Riddell, okay will do
<wasabi> Hmm. What's the status of our amd64 32-bit compatibility stuff? What's it take to get something added to that? Would there be many complaints if I made the 64 bit version of Winbind include 32 bit pam libraries?
<wasabi> Hmm. Interesting. I had thought we had some of pam 32 anyways... seems I was wrong.
<keescook> Riddell: doesn't it need to pass motu-sru, not ubuntu-sru?
<keescook> superm1: and the tech board request is for future exception, isn't it?
<Riddell> keescook: right, yes
<superm1> motu-sru isn't discussed anywhere on that wiki page though.
<superm1> https://wiki.ubuntu.com/MOTU/SRU
<keescook> Riddell: sounds like you just need to verify the SRU bug information and version details (since it's motu)
<wasabi> So why do we use a tmpfs for restricted kernel modules?
<ion_> wasabi: Distributing proprietary modules linked with Linux is a violation of the GPL. Thus, the .ko files cant be distributed. Apparently even having a postinst script build them and save them to a non-volatile media could be considered to be distribution. Or something like that.
<wasabi> I'd find it amazing if a common Joe (Judge Joe) would find that to be in different in any fashion
<wasabi> .
<LaserJock> so the modules get linked when you boot? I don't quite get what actually happens
<wasabi> Seems so.
<davmor2> Dear devs I have noticed something strange with firefox.  I have installed firstly gnash but now flash, on my 64bit machine but firefox is still reporting that there is a plugin missing.  Flash is the missing plugin.  I have restarted the machine thinking it may of been a glitch but no.  still the same.  What info do you need or is this a known bug?
<mneptok> davmor2: this is not a support channel. try "/join #ubuntu"
<davmor2> mneptok: This is an issue with gutsy.  I was after info to make the bug I write as informative as possible.  But is now sorted thanks to pygi and galternatives.
<agoliveira> davmor2: When you joined this channel there was a message like this: "Development of Ubuntu (not support, even with gutsy...)" So, it does not matter if it's related to gusty, this is for development only, sorry.
<davmor2> understood.  But wasn't actually after support,  Just what info you needed in a bug report on the issue.
<davmor2> I don't like to just put this doesn't work.
<highvoltage> if jsgotangco pops up, remember to wish him happy birthday
<highvoltage> (goodnigh)
#ubuntu-devel 2007-08-28
<Kopfgeldjaeger> Good night and bye
<wasabi> Anybody around to discuss the initramfs lvm/md logic? I'm writing down how it "should" work, and would like input from somebody invested.
<wasabi> This recent conversion to use udev... is interesting... but I wonder if it's self-defeating, and adds nothing of value.
<ion_> I havent really read the code, either the earlier implementation or the udev implementation.
<ion_> But using udev sounds right to me. :-)
<wasabi> Sure, except udev is inherently disconnected from the actual init scripts that require wait conditions.
<wasabi> Which makes it awkward to do what's expected. Wait 30 seconds for non-degraded vols, then start assembly degraded vols.
<ion_> Well, yeah, we should migrate to Upstart. :-P
<wasabi> I'm not sure if upstart makes this much better... and certainly not easier.
<wasabi> The initramfs is by it's very nature sequential. You have to WAIT for the root device before moving on.
<wasabi> Makes me wonder though if the process wouldn't be more robust if it was more straightforward... like root=md/md_device_uuid:lvm-vg/lvm_vg_uuid:lvm-lv/lvm_lv_uuid:fs/filesystem_uuid
<wasabi> And just a simple dispatch to a set of scripts that are in charge of waiting for each component until a set timeout, and then mounting said component degraded.
<wasabi> Hmm. maybe udev would be fine, as long as it never actually activated degraded volumes of any sort... but something else did after the timeout.
* Starting logfile irclogs/ubuntu-devel.log
<wolfe> :)
<wolfe> nice, tracker is in C, unlike Beagle which is based on crap slow and buggy mono
<Amaranth> wolfe: *cough*
<wolfe> Amaranth: cover your mouth when you cough ;)
<Amaranth> wolfe: mono is just fine
<Amaranth> probably not appropriate for a long running daemon but...
<wolfe> I haven't tried it in a year. I tried it 2 years ago, 1.5 years ago, and 1 year ago. The overall experience was terrible. Many APIs marked "completed" were incomplete(threw "Not Implemented," or were terible implemntations)
<ion_> I dont find mono especially slow or buggy either. The language of choice probably isnt the most significant one of the things that make tracker better than beagle. :-)
<wolfe> I didn't say language of choice, I said mono
<wolfe> mono is just the VM
<wolfe> now, oh boy, if you want to discuss all the flws in Mono's crapp C# implementation
<ion_> There isnt much choice of the VM if your language of choice is C# and you want it to run on Linux.
<wolfe> ion_: right, but for those of us who are cross platform programmers, Mono and Mono/C# is a hunk o junk
<wolfe> which is why I use Python + wxWidgets
<wolfe> ion_: Mono's purpose is to run windows apps on linux, pulling developers more towards linux. That isn't happening, the original purpose of mono is non existant
<wolfe> they've complete .NET 1.1 support(supposedly, though it is probably non conforming like always), they're working on 2.0 support.. while WinFX(3.0) has been out for a really long time
<wolfe> ion_: long as tracker is nice a fast.. and doesn't use 100+MB of memory running idle, I'm happy.
<ion_> I dont even notice tracker, and this box isnt exactly high-end. (P3 500MHz, 384 MiB RAM)
<wolfe> ion_: what about when it runs ;)
<wolfe> people are complaining about when tracker does its thing, it is noticable.
<wolfe> though when it is idle again, everything is fine.
<ion_> Well, its extracting metadata from a video just now and i wouldnt have known it without taking a look at the process list.
<wolfe> guess the people who complain have 500GB in porn ;)
<ion_> (I do have indexing speed: 20 (slower) and minimize memory usage (slower indexing) set in Tracker preferences.)
<wolfe> o
<wolfe> well that would do it I guess :)
<wolfe> ion_: say..
<wolfe> ion_: do you notice any tools to join Ubuntu to a windows network?
<wolfe> there was supposed to be a tool someone is working on.
<wolfe> ubuntu specific, can't remember who it was.
<ion_> This discussion is very offtopic, it probably should be continued on another channel. Its been years since i used samba.
<wolfe> this discussion is devel related ;)
<wolfe> the person said it was going to be included /maybe/ in this coming release.
<Tonio_> hi
<saispo> BenC: ping ? :)
<saispo> hi seb128
<seb128> lu saispo
<seb128> ogra: new gnome-screensaver available
<Hobbsee> good morning seb128
<ogra> *yawn*
<ogra> morning
<ogra> seb128, thanks
<seb128> hey Hobbsee
<Hobbsee> hi ogra
<tepsipakki> does someone know what's up with ubuntu.com-services (lp.net et al)?
<elmo> tepsipakki: works for me - what's the problem you're seeing?
<ogra> LP works fine here
<tepsipakki> elmo: either they fail to open completely or partially
<tepsipakki> connecting from hut.fi
<tepsipakki> could be something here, too..
<tepsipakki> rest of the world seems to work though :)
<elmo> tepsipakki: try mtr-ing to launchpad.net and lithium.canonical.com, if you can still reproduce it
<elmo> tepsipakki: if there's anything interesting in the first, pastebin both of them
<tepsipakki> traceroute to l.c.c gets stuck after byrd.canonical.com
<elmo> tepsipakki: k, that doesn't really matter
<tepsipakki> now lp.net works again
<tepsipakki> mtr/traceroute always got through
<tepsipakki> maybe some db backend is busy?
<maswan> elmo: we're getting errors to security.u.c (connection timed out)
<Nicke> tepsipakki: I get connection timeouts now and then to LP too, fwiw
<maswan> elmo: never mind, back again
<elmo> seems like it might be telia
<elmo> or telia vs. l3 anyway
<maswan> elmo: telia might have had a power glitch in some parts, some machines we have in a telia hosting facility in denmark rebooted spontaneously. I guess if they have some routers/foo in there too, it might cause issues.
<maswan> (wild guessing)
<Nicke> (my traceroutes to lp seems to have problems with level 3 and Adapt Services.. not going through Telia at all)
<maswan> well, we get transit from telia, so we'd be hit by that anyway. :)
<Nicke> ah, true
<maswan> elmo: hm. I'm getting issues to s.u.c/82.211.81.138 again now
<soren> How does it make sense to have a package listed as both Replaces and Recommends?
<Hobbsee> uh....
<elmo> soren: assuming the replaces is unversioned, it doesn't
<elmo> maswan: yeah, I still can't see anything concrete unfortunately
<soren> elmo: It is.
<soren> elmo: Alright, just as I thought, then. Thanks.
<elmo> err, well, that's not actually strictly true
<elmo> soren: sorry, it's actually fine, I can replace *some* files in 'foo' (requires Replaces),  and still Recommend it
<elmo> (s/strictly//, s/$/ at all/)
<StevenK> s/strictly\( true\)$/\1 at all/ :-P
<Kmos> bz-gtk 0.90 is out at debian =)
<Kmos> ubuntu gutsy has 0.18.0
<Kmos> lol
<StevenK> And we are in UVF.
<seb128> Kmos: what is funny?
<Kmos> *bzr-gtk
<Kmos> seb128: nothing.. just UVF is ending, i've some requests there and nothing was done yet, so I won't file another sync request for it
<Hobbsee> uvf *isnt* ending for gutsy.  it will never end.  i told you this before, and you said you understood that.
<Hobbsee> and your sync requests lately have been contradicting themselves, so in the interest of getting things done, they've been getting ignored.
<Kmos> Hobbsee: but I won't file bug reports
<Kmos> :)
<Hobbsee> good.
<Hobbsee> then i wont have to work out WTF to say.
<Kmos> Hobbsee: only ddclient, and i've already explained.. and the others? =)
<Hobbsee> you explained once, then contradicted yourself again.
<Hobbsee> i gave up, at that point.
<Kmos> ok, the problem is for ubuntu, isn't mine.. i published it at getdeb.net and people are downloading =)
<Kmos> I'm credible for one things, but not for others
<Kmos> that's the point.
* Hobbsee ponders the quality of getdeb.net, then.
<Kmos> Hobbsee: that's your point of view =) I respect.
* Hobbsee decides it's better not to find out
<Hobbsee> i would have expected any repository maintainer to know what they were doing with their packages, before uploading them.
<Hobbsee> if they prove that they dont, then clearly the quality of their packages is debatable.
<seb128> Kmos: shipping non official packages is usually not a good idea
<Hobbsee> seb128: ship?  who said anything about shipping?
<RAOF> How exactly can you ship non-official packages anyway :)
<Kmos> seb128: it's the only way I found to publish my ddclient package, that's i'm part of uptream
<Hobbsee> seb128: this is about a sync/merge request of ddclient, whihc kmos contradicted himself in twice, so he turned to getdeb because it didnt get accepted.
<Kmos> Hobbsee: I know the owner of getdeb, it's also from Portugal :)
<Hobbsee> Kmos: if you're part of upstream, you should know WTF you're doing, including w.r.t syncs and merges, and not contradict yourself in bug reports about the package.
<Kmos> Hobbsee: i've done an typo "is" - "isn't"
<Hobbsee> yet you never corrected that in the bug report - or at least not when we read it.
<Kmos> Hobbsee: I don't know what i'm doing.. you know =)
<Hobbsee> which was a few days ago
<Kmos> Hobbsee: check it again
<seb128> Hobbsee: I probably didn't understand what getdeb.net is
<Hobbsee> Kmos: i have better things to do with my time than read a sync or merge request which probably now contradicts itself a third time.
<seb128> Hobbsee: I though somebody uploaded packages there
<Hobbsee> seb128: ahhh
<Kmos> bug 132694
<ubotu> Launchpad bug 132694 in ddclient "Please merge ddclient (3.7.3-2) from Debian unstable" [Undecided,Incomplete]  https://launchpad.net/bugs/132694
<Kmos> Hobbsee: i like to change comments and do typos and I can't :(
<Kmos> *when
<Kmos> I like to change comments when I do typos and I can't :(
<seb128> Kmos: you should spend some time writting your bugs to include required informations
<seb128> Kmos: that merge bug goes on pages and you still didn't describe what are the Ubuntu changes and why you think they can be dropped
<Hobbsee> Kmos: what really worries me here is that you've had 2 blocks of contradictions in that bug report already, and you dont quickly change them to be right
<seb128> "upstream don't apply it" is not a reason
<Hobbsee> therefore, i've got absolutly NO confidence that the rest of your changes are right, as you clearly either a) dont have a clue WTF you're doing with the package or b) dont care enough to actually file a decent report with the required information, which you've been told about before.
<Kmos> seb128: i've explained it.. upstream didn't apply it, because dyndns.com as talked to upstream to change it. only mention dyndns.com when we talk about the service, not about the core functions. like members.dyndns.org is the valid to update IP, and not dyndns.com
<Kmos> this talk happen after my last ddclient package releases
<Kmos> and before i enter to upstream as a member
<Hobbsee> so, i cant, nor any in the MOTU-UVF team, in good conscience, approve that bug, because we know that it's likely wrong, and that we dont trust the filer to have gotten it right.
<seb128> Kmos: well, your bug still doesn't list the changes with the rational, what you just explained is not clear
<Kmos> so debian hadn't updated their package for long time
<Hobbsee> it's as simple as that.
* Hobbsee --> dinner
<Kmos> Hobbsee: and you trust my other syncs? my last ddclient packages i've done
<Kmos> that's contradiction
<Kmos> lol
<Kmos> so that's why I won't file bug syncs again
<seb128> Kmos: what about "checked_ssl_load"?
<Kmos> seb128: that's applied upstream
<Kmos> and it's on v3.7.3
<Kmos> everything is correct with the package, the only thing I need someone to check is the changelog, because that's merged
<Kmos> I've also sent a lot of fixes to debian maintainer
<Kmos> in hope he updates the package, that don't happened these weeks
<seb128> Kmos: you should try to make a clear description directlu
<seb128> directly
<seb128> the issue with this bug is that the comments go on pages
<Kmos> seb128: check last comment
<Kmos> i took my debian/changelog
<seb128> Kmos: so the package should be synced on debian or merged?
<Kmos> merged from debian
<Kmos> i've changed the title of the bug
<Kmos> I think the debian maintainer has applied all of my changes, but not :(
<Kmos> that's why I made it wrong first time
<Kmos> but after changed to merge
<Kmos> http://changelogs.ubuntu.com/changelogs/pool/universe/d/ddclient/ddclient_3.7.1-0ubuntu3/changelog
<Kmos> as you can see here, I've done two packages of it
<Kmos> * Added a patch to change dyndns.org to dyndns.com (LP: #106753)
<Kmos> this was refused from dyndns.com service, we talked to them
<Kmos>   * Re-add debian/patches/checked_ssl_load.diff which got dropped accidently in
<Kmos>     last upload.
<Kmos> this one is applied upstream
<Kmos> like most of them
<seb128> hum
<seb128> merged = ubuntu changes need to applied
<seb128> synced = use the debian version
<Kmos> exactly
<seb128> are we sure it needs to be merged?
<seb128> which means you take the debian package
<seb128> and what needs to be changed then?
<Kmos> and applied the ubuntu changes
<Kmos> * debian/rules: call dh_installinit with -u multiuser (Teardown spec)
<Kmos> this one
<Kmos> for example
<Kmos> and ubuntu maintainer hadn't changed dyndns.com when talking about the service, inside debian/
<Kmos> i've already mailed with, but with no answer until today
<seb128> you should attach the debdiff of the merge to the bug then
<Kmos> so I do the debdiff from debian unstable and my changed one
<seb128> yes
<Kmos> i'll do it now
<Kmos> thanks
<Kmos> seb128: it's attached to the bug
<tuxcrafte1> how can i disable the new aiglx in gusty its causing errors on my system
<thom> tuxcrafte1: #ubuntu for help
<tuxcrafte1> thom: also for testing of gusty?
<thom> #ubuntu+1 alternatively
<Hobbsee> Kmos: lets put it this way - i gave you the benefit of the doubt in most cases, because i didnt know you were this bad at sync requests.  and i also checked the changes, to check that the ubuntu changes really were all gone.  however, now we're later in the cycle, and i've got other stuff i want to do.
<Hobbsee> Kmos: so it either needs to be right, or not happen.
<Hobbsee> seb128: if you could deal with that bug, that'd be appreciated.  i'd not want to put it up for the sponsorship review queue / motu-uvf queue again - we've already tried to figure it multiple times, adn given up.
<seb128> Hobbsee: will do
<Hobbsee> seb128: thanks
<Kmos> Hobbsee: benefit of the doubt.. lol.. Ok
<Hobbsee> Kmos: as in, trusting that the changes you listed that were also listed in debian were actually correct, that there werent any silently dropped, that werent in the original changelogs.
<Kmos> Hobbsee: and the powertop sync I've request, you acked it.. it's the benefit of doubt
<Kmos> and the others
<Kmos> ok
<Hobbsee> Kmos: yeah, but i have a clue about powertop.
<Kmos> so what's wrong with it ?
<Hobbsee> Kmos: but for stuff that i dont know a lot about, it's a different story, it's confusing, and i dont have the motivation, time, or possibly skill to go thru every fine-toothed change.
<Hobbsee> also, i dont recall powertop having any ubuntu changes
<Kmos> Hobbsee: exactly, so you can't say "i didnt know you were this bad at sync requests"
<Hobbsee> sure i can.  i knew that some of them were right, but i didnt know that some of them were that badly, and that confusingly wrong.
<Kmos> ok
<Kmos> that's your opinion, but a lot of them are synced and working fine
<Kmos> sabdfl: hi =)
<Hobbsee> previously, i'd known that some of yours were right, and some were wrong - but i didnt know they were that badly wrong.
<Hobbsee> greetings, sabdfl
<sabdfl> hey Kmos
<sabdfl> Hobbsee: :-)
<Kmos> Hobbsee: so, you're good, i'm not.. lol
<Kmos> that's ok =)
<Hobbsee> Kmos: i never said quite that.
<Kmos> Hobbsee: i need to work, conversation won't take us to any side.
<Hobbsee> ok
<Hobbsee> enjoy
<cromo> hi. I have some problems with qc-usb-messenger kernel module compilation. For some reason it segfaults (gcc: Internal error: Segmentation fault (program cc1)). Using feisty here and I am wonderign what's wrong. I tried compiling this module on other machine (archlinux, gcc 4.2.1) and it worked just fine.
<cromo> so I wonder if something is broken in feisty's gcc?
<cromo> basically, it's enough to download http://home.mag.cx/messenger/source/qc-usb-messenger-1.6.tar.gz package, untar it and exec a typical 'make all' in the directory
<cromo> anyone can please confirm that he gets the error?
<_StefanS_> infinity: hey, can you please re-upload kdesdk for lpia ? It compiles without changes now.
<Riddell> _StefanS_: it's called "give back" since nothing needs to be uploaded
<_StefanS_> right gotcha.
<asac> our fontconfig adds FC_ANY_METRICS to fontconfig.h (while debian doesn't) ... who might know about this patch?
<asac> doko_: ^^^
<doko_> asac: iwj did write that. we have to make sure that we don't use DejaVu as a substitute font for missing fonts for documents becuase it is not metrics compatible
<asac> doko_: so debian never had it?
<doko_> asac: no
<asac> thats interesting because the patch for firefox i have has a debian bug ... let me see
<Mirv> mjg59: do you happen to have any chance to put any input to bug #86666 ? in March, you said that "I'll see if I can determine a test case for this that will give us some more feedback", and there's now both manufacturer-supplied and copied from /sys/ BIOS ROM you asked for.
<ubotu> Launchpad bug 86666 in usplash "Feisty crashes after grub, before boot process, if usplash is enabled (amd64)" [High,Triaged]  https://launchpad.net/bugs/86666
<Mirv> not that I'd need the fix (vga=792 works just fine), but it seems to affect quite a lot Radeon X800 users (with an occasional mention about possible similar problems with some NVIDIAs)
<mjg59> Mirv: I've added an update
<\sh> jono, ping...very important matters arised
<\sh> jono, please in private or jabber (jid: sh@linux-server.org)
<bddebian> Heya
<tkamppeter> Hi, I need some help
<tkamppeter> I am packaging CUPS with an alternative USB backend, trying to surround kernel (or hardware) bugs
<tkamppeter> The alternative backend includes /opt/lsb-buildenv-ia32/usr/include/linux/usb_ch9.h
<tkamppeter> Sorry, i cannot grab other than the wrong thing, let me search
<tkamppeter> It needs /usr/src/linux-headers-2.6.17-10/include/linux/usb_ch9.h
<mjg59> That's weird. Where have my font and desktop effect preferences gone?
<tkamppeter> On my Gutsy linux-headers-2.6.17-10 is installed, and simply requiring linux-headers pulls linux-headers-2.6.22-10 which does not contain mentioned file. What do I have to do?
<mjg59> tkamppeter: If it needs to include anything from /usr/src, it's broken
<mjg59> Try /usr/include/linux/usb/ch9.h
<tkamppeter> In reality it only includes linux/usb_ch9.h, but on my system I have found this file only in /usr/src.
<mjg59> Oh. Change it to linux/usb/ch_9.h
<tkamppeter> Thank you, will try it.
<mjg59> seb128: Any idea why gnome-control-center doesn't seem to be building the font preferences?
<tkamppeter> File is in linux-libc-dev
<mjg59> tkamppeter: Yes
<seb128> mjg59: what do you mean? it's a tab in the appearance capplet now
<mjg59> seb128: Ah!
<mjg59> seb128: That's not especially obvious :)
<seb128> right ;)
<mjg59> seb128: It also seems to have lost the DPI setting
<seb128> no, details
<mjg59> Ah, yes, I'm blind
<mjg59> Hm. We really need to fix X's DPI handling.
<iwj> doko_: Would you be able to help me with some pointers in the glibc build system ?  I'm trying to wrap ldconfig with a script but my rules fragment isn't being executed.
<lamont> seb128: please don't do like shared-mime-info 0.22-2 did and break ia64, mk?
<iwj> doko_: I was hoping you would be able to tell me where it should go - since it takes about 4h to run the build system even with a fully primed ccache.
* lamont gets to figure that out today
<tkamppeter> jg59, thank you very much. Now I succeeded also to build it under pbuilder. The contributor of the code is probably not much experienced with packaging for distros.
<iwj> Scary.  I've just taught autopkgtest how to file bugs in LP and turned it on.
<mjg59> jamiemcc: Any joy with the tracker issue?
<mjg59> I've just pulled a kernel source tree into an otherwise entirely empty home directory, and tracker is eating all my disk i/o
<jamiemcc> mjg: yeah we are working on tuning it
<calc> who processes MIRs right now?
<calc> iwj: iirc i hear you were doing them?
<mjg59> jamiemcc: It's really not in a releasable state right now :(
<jamiemcc> mjg59: we will do index merging as updating a massive index is very painful
<mjg59> jamiemcc: Ok, sounds promising
<jamiemcc> mjg59: should be fixed for tribe 6
<mjg59> Cool
<jamiemcc> there may be corner cases but hopefully that will crop up in testing
<jamiemcc> mjg59: we recommend setting source dirs to be crawled instead of watched
<jamiemcc> that way it wont slow down check outs or compiling
<mjg59> jamiemcc: Hm.
<mjg59> jamiemcc: That's a pretty negative user experience.
<jamiemcc> yeah but only for devs
<jamiemcc> its why we adding the crawl directory setting to tracker
<mjg59> Who are a major part of our userbase
<jamiemcc> yeah I know
<iwj> calc: Yep.
<jamiemcc> mjg59: the best we can do is make it less slow in devs
<jamiemcc> we cant make it as fast as
<mjg59> jamiemcc: The alternative is to heuristically mark directories as source directories
<iwj> calc: If you have packages you'd particularly like approved do feel free to mention them.
<mjg59> Rather than asking people to do it manually
<calc> iwj: have you had a chance to look at libvigraimpex and libsvg
<iwj> I mean, to mention them now.
<calc> iwj: ok
<jamiemcc> mjg59: we will be using idle disk priority which will help a lot too
<iwj> calc: They don't seem to be mentioned on https://wiki.ubuntu.com/UbuntuMainInclusionQueue
<jamiemcc> idle mode waits for a grace period of no disk access before allowing tracker to use disk
<iwj> calc: Ought they be ?  I can review them and add them if you like.
<iwj> I see MainInclusionReportLibsvg and presumably a similar page for the other.
<calc> iwj: doh, i forgot to add them there i guess :\ yea please do
<jamiemcc> mjg59: you can set idle to trackerd using ionice to see if it makes a difference in your case?
<iwj> calc: NP.
<iwj> calc: When would you like a response by ?
<calc> end of the week if possible, i want to do the next ooo build with them which i expect to probably do around that time
<mjg59> jamiemcc: I'll give it a go next time I trigger it
<calc> iwj: between approval and promotion doesn't take long does it?
<mjg59> (I just killed it for the moment - I only have a few minutes to get this patch finished)
<jamiemcc> mjg59: ok next version will try and set idle automatically
<calc> iwj: assuming the packages are ok to be included i would like them to be in main (if possible) by the end of the week
<iwj> calc: Not hugely but it depends on someone having an archive day.
<calc> iwj: oh ok
<iwj> OK.  I should look at them soon then./
<iwj> Thanks.
<calc> thank you 8)
<alex-weej> asac: you got time for some VPN lovin'?
<calc> iwj: did you put them under approved or did i somehow put them there by mistake? (on the wiki)
<calc> iwj: i thought i added them to the area to be reviewed but it showed up under approved section, lol
* calc tries fixing it one more time before deciding he can't edit a wiki ;)
<zyga> anyone on gutsy around?
<iwj> I haven't touched them yet ...
<calc> iwj: ok i screwed up where i stuck it then, i just fixed it
<zyga> could someone confirm that /usr/share/command-not-found/programs.d still exists?
<zyga> (with up-to-date command-not-found and command-not-found-data packages)
<infinity> calc, iwj: If any promotions are time sensitive, don't be afraid to ping me to have an "archive moment", rather than waiting for someone to take an archive day.
<iwj> infinity: Noted.
<asac> alex-weej: nope
<alex-weej> asac: ok. can you consider making the bugs critical for gutsy release?
<asac> alex-weej: yes give me bug id
<alex-weej> asac: https://bugs.launchpad.net/bugs/134547
<ubotu> Launchpad bug 134547 in network-manager-pptp "NetworkManager PPTP VPN does not work; bad pptp plugin" [Undecided,New] 
<alex-weej> asac: and, to a lesser extent, the bad DNS = crash one: https://bugs.launchpad.net/bugs/134544
<ubotu> Launchpad bug 134544 in network-manager "NetworkManager aborts when attempting to connect to PPTP VPN server with bogus host name" [Undecided,New] 
<asac> alex-weej: bug 134544 must be a duplicate
<alex-weej> asac: how so?
<asac> ah sorry :)
<asac> lost the context
<alex-weej> (i split the old bug up into two new ones, the vpnc problem seemed to disappear)
<asac> right
<iwj> calc: Why does oo.o want a computer vision library ?
<iwj> calc: Hmm.  Looks like it's just using it for image processing.
<iwj> calc: Both approved.
<calc> iwj: thanks :)
<iwj> calc: NP.  Goodnight :-).
<geser> Riddell: Hi, are you responsible for UVF exceptions for packages in main?
<Riddell> geser: yes
<geser> what's your opinion on bug #134684? the link list of fixed upstream problems looks interesting but on the other side boost has some rdepends which would need rebuilding.
<ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,New]  https://launchpad.net/bugs/134684
<Riddell> geser: seems like a good idea if someone wants to test all the rdepends
<geser> Riddell: ok, will test in my PPA if upgrading boost is possible
<Riddell> geser: that's a good idea
<soren> MikeDK: /win 10
<soren> Whoops
<Riddell> infinity: do you have any opinion on having opensync 0.30 packaged?
<infinity> Riddell: None whatsoever...
<Riddell> oh jings, why do I always mix you two up on irc
<Riddell> lifeless: do you have any opinion on having opensync 0.30 packaged?
<moquist> Any postgresql-savvy folks in here? I'm working on the Moodle package and could use some advice about best practices.
<mathiaz> moquist: pitti is the man to talk to. But he's on vacation for two weeks.
<lifeless> Riddell: yes
<lifeless> Riddell: I think its a great idea; its on my todo list as upstream have apparently unbroken the soname issue.
<lifeless> Riddell: if someone wants to throw a patch my way I'd be extremely happy.
<Riddell> lifeless: what was the soname issue?
<azeem> using scons
<azeem> lifeless: though note that upstream discourages any use and packaging of opensync before 0.40 apparently
<lifeless> IIRC - its a year back now - they broke the ABI comprehensively; didn't bump the soname, and plugins were hardcoded back. Or something. azeem was dealing directly with it.
<azeem> it's really messed up there
<lifeless> azeem: more and more I get the impression they don't want users.
<azeem> apparently opensuse 10.3 (or whatever is next) won't ship it
<azeem> or well, will ship 0.2x or something
<azeem> but OTOH, maybe 0.32 is already heaps better than what is in the ubuntu/debian archive now
<moquist> mathiaz: thx
<bddebian> scons... Ugh
<azeem> they switched to scons and had no clue that a library should have a soname - neither had scons
<lifeless> I'm hearing that 0.3x is significantly better that 0.19
<azeem> lifeless: I'm not sure they guarentee not breaking the file/archive format till 0.40 though
<azeem> Riddell/lifeless: is this for gutsy, or just in general?
<lifeless> gutsy IVF is tomorrow I think
<lifeless> s/I/U/
<lifeless> IVF would be rather different ;) ;)
<Riddell> azeem: for gutsy
<azeem> ok
<lifeless> azeem: this is nuts; bzr has migrated file format several times, lossless upgrades. It's a solved problem.
<Riddell> azeem: fancy packaging it?
* bddebian thought UVF was last week
<Riddell> bddebian: it was
<lifeless> bddebian: perhaps I'm thinking universe ?
<bddebian> Us too
<Riddell> new package deadline is thursday
<bddebian> Aye
<azeem> well, there's exceptions
<azeem> no?
<bddebian> Yes
<lifeless> Riddell: meep; time for the UVF exception to roll out then -bzr 0.90 releases today
<azeem> lifeless: alternatively, we could roll it out in debian experimental, get minimal testing, and then ask for UVFe sync
<Riddell> lifeless: whoever is packaging it need to get me the changelog and convince me it's stable
<Riddell> or more stable than what went before
<azeem> 22:36 < azeem> lifeless: though note that upstream discourages any use and packaging of opensync before 0.40 apparently
<azeem> Riddell: heh
<lifeless> Riddell: of bzr, or of opensync ?
<lifeless> Riddell: cause bzr is one of the most stable things I've ever seen.
<Riddell> lifeless: both I guess.  bzr is a work of genius so I don't expect any problems
<azeem> maybe we should check on the plugin state, last I checked about only the file-sync plugin was ported to 0.3x
<azeem> s/state/status/
<lifeless> http://svn.opensync.org/tags/plugins-0.32/
<lifeless> looks promising; assuming its realistic
<Riddell> danimo: any information on that?
<danimo> Riddell: yes, it seems the enterprise branch guys changed the API without bumping the interface version
<danimo> Riddell: till will look into it asap
<azeem> lifeless: well, better than http://svn.opensync.org/tags/plugins-0.31/
<danimo> Riddell: so it seems another repackaging (and relinking of all dependant packages) is due in one or two days
<danimo> Riddell: sorry
<Riddell> danimo: I was asking about opensync plugins
<danimo> Riddell: oh, no, all I know is that 0.30 is not s/c
<danimo> Riddell: tokoe knows mor
<danimo> e
<danimo> Riddell: suse already has new packages via OSBS
<azeem> lifeless: 22:50 < abtronic> azeem: I don't think all of those are working yet
<lifeless> I guess its a case of suck it up and see
<azeem> btw, is there any indication how many users current opensync has on ubuntu?
<lifeless> popcon
<lifeless> http://popcon.ubuntu.com/
<azeem> I have the feeling we're going annoy quite some of them if we'd ship 0.32 in gutsy
<lifeless> http://popcon.ubuntu.com/by_vote
<lifeless> meh sorry
<lifeless> 270
<lifeless> 75811 would seem to be the number of popcon users, or thereabouts
* azeem blinks at "Ryan M. Golbeck"
<azeem> ok
<lifeless> so we know there are millions of users
<lifeless> millions / 100000 ~= some multiple of 10's expansion
<lifeless> so say a few thousand opensync users.
<lifeless> hows that for rough and ready stats
<ion_> Im going to use opensync as soon as i get around to purchasing a data cable for my phone. :-)
<lifeless> not if they never release a version with the plugins working again
<azeem> get this: Apparently Sun put one of their engineers on the task of writing yet another gtk opensync frontend
<lifeless> oh yay
<ion_> iwj: Removing linux-ubuntu-modules-2.6.22-9-generic ..., update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic, Purging configuration files for linux-ubuntu-modules-2.6.22-9-generic ..., update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic
<ion_> iwj: Could triggers be used to prevent this, too?
<ion_> iwj: Perhaps make each linux-image-$REL package provide the trigger for initrd.img-$REL or something like that...
<superm1_> Riddell, after the update cleared the buildds in -proposed yesterday, I received some info regarding a few reports of issues with the migration, and cherry picked a few patches from svn that take care of them.  Could you release the two updates (edgy and feisty -proposed) again?
<superm1_> or infinity cjwatson mdz Keybuk ^
#ubuntu-devel 2007-08-29
<Kopfgeldjaeger> Gute Nacht (verdammt, schon so spt?)
<Riddell> doko_: do you have an opinion on bug 134994?
<ubotu> Launchpad bug 134994 in python-central "UVF Exception for python-central" [Undecided,New]  https://launchpad.net/bugs/134994
<alex-weej> does Ubuntu have an application naming policy (e.g. for Desktop Entry files)?
<Utnubu> hi all
<cjwatson> alex-weej: delegated to desktop environments which generally do
<cjwatson> the GNOME HIG at least does, I believe
<alex-weej> cjwatson: ok, but they're not exactly compatible with other upstreams
<cjwatson> that's as may be, but no policy would be
<alex-weej> cjwatson: i'm thinking we should have one, and patch our packages to be consistent
<Utnubu> Since compiz is enabled per default in Gutsy or at least everything is ready for it why compizconfig-settings-manager isn't installed per default?
<cjwatson> alex-weej: so a different incompatible policy? I'm sure that would be excellent and really justify the work ;-)
<alex-weej> it seems that some applications are just "Name" ("Qalculate!"), others are "Generic Name" ("Text Editor")
<alex-weej> and in many cases they're not even the right name
<alex-weej> for example we're calling Impress "OpenOffice.org Presentation"
<alex-weej> when it starts up, it's called OpenOffice.org Impress everywhere
<alex-weej> same with Text Editor and gedit
<alex-weej> (that's one upstream not even eating their own dog food)
<Riddell> alex-weej: I think the gnome packagers edit some names to make them more generic
<Riddell> which is the wrong way to do it in my opinion, it should just use GenericName if that's what they want
<alex-weej> cjwatson: it would confuse users less. I don't know why we had to rename OpenOffice components.
<alex-weej> Riddell: (agreed, fwiw)
<cjwatson> OpenOffice.org Presentation seems more consistent with http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#menu-item-names to me
<cjwatson> likewise Text Editor
<alex-weej> cjwatson: but that's not what it's called... it's called Impress - i'd say changing the name of upstream programs isn't doing anyone any favours
<cjwatson> you asked if there was a policy; I answered you ...
<alex-weej> cjwatson: i'm justifying the need for our own
<alex-weej> as we are the ones who have to mix everything together and call it a product
<mjg59> The policy is, where possible, to provide applications with a menu entry along the lines of (specific name) (generic name)
<cjwatson> not to disagree with the fact that we're integrators, but I think where desktop entries are concerned the desktop environment upstreams also have some experience as integrators
<mjg59> So you get OpenOffice Presentation or Epiphany Web Browser
<cjwatson> I think Impress is a particularly poor choice of application to try to make a point about here
<alex-weej> the problem is that it's "OpenOffice.org Impress Presentation Editor"
<mjg59> Not in any real sense, no
<cjwatson> OpenOffice.org is a perfectly sufficient brand on its own and Presentation is a lot clearer in the menu entry than Impress
<alex-weej> cjwatson: so we need to change a OOo strings to read "OpenOffice.org Presentation"
<alex-weej> and that raises confusion for ex-Windows users
<alex-weej> who are used to using Impress for creating "powerpoints"(!)
<cjwatson> that sounds like a lot more work for much less benefit
<alex-weej> at least it's consistent with itself
<cjwatson> the menu entry is the first point of entry
<cjwatson> anyway, bed
<mjg59> alex-weej: No. The idea that the menu entry is the real name of the program is incorrect.
<alex-weej> Name=OpenOffice.org Impress;GenericName=Presentation Editor
<Amaranth> gnome-menus doesn't support GenericName :)
<alex-weej> mjg59: desktop entry files aren't menu entries
<mjg59> alex-weej: THe menu entry provides enough information for you to know what the program is, and also what specific instance of that class of programs it is
<alex-weej> mjg59: desktop entry files describe applications
<cjwatson> http://standards.freedesktop.org/desktop-entry-spec/latest/ "how it appears in menus, etc."
<SwellJoe> Anyone have a pointer to an example of running "apt-ftparchive release" that doesn't lead to a zero-sized "Release" entry in the Release file (and an error when using the resulting repo)?
<Amaranth> alex-weej: desktop entry files tell you what the application is and what it does
<mjg59> alex-weej: Providing the full title of the application provides no benefit to our users. Nor does changing the name of a program to be the same as its menu entry.
<Amaranth> alex-weej: so OpenOffice.org Presentation fits fine
<Amaranth> so does Text Editor
<alex-weej> but when I install Foo Text Editor
<Amaranth> no matter what the application says it is
<alex-weej> and i have the choice of Text Editor and Foo Text Editor, it just looks stupid
<mjg59> That's an argument for names which are entirely generic to include a specifier
<Amaranth> alex-weej: well it would be GNOME Text Editor but since that would end up with you seeing GNOME everywhere it's stripped off
<mjg59> Not an argument for changing OpenOffice Presentation to OpenOffice Impress
<alex-weej> Amaranth: no, it's Name=GEdit;GenericName=Text Editor
<alex-weej> mjg59: right, it's two separate arguments about cleaning up the same messy
<alex-weej> *mess
<Amaranth> alex-weej: No it's not
<Amaranth> it's Name=Text Editor
<alex-weej> Amaranth: i was speaking hypothetically
<Amaranth> alex-weej: gnome-menus does not support GenericName
<alex-weej> then that's too bad
<Amaranth> and it's a bit of a compatibility break if you change it now
<Amaranth> because lots of apps would have to be changed
<alex-weej> what are we going to break compatibility with? the current mess?
<Amaranth> Yes
<mjg59> Sigh.
<Amaranth> Although I wouldn't call it a mess
<mjg59> This conversation is not aiding Ubuntu development.
<Amaranth> It is not
<mjg59> If you have a concrete proposal, write it up.
<Amaranth> alex-weej: #gnome-hackers :)
<alex-weej> Epiphany has a name, "Epiphany". Totem has a name "Totem", Impress has a name "Impress"
<mjg59> But you're not going to convince the development team by having an argument on IRC at a time when most of them are in bed
<halcyonCorsair> hi, can anyone tell me how limits are dealt with in ubuntu/debian? (ie. limits.conf?)
<ion_> stevenk, doko: Since you have rebuilt openoffice.org-voikko previously to regenerate dependencies, id like to bring bug #135426 to your attention. Thanks.
<ubotu> Launchpad bug 135426 in openoffice.org-voikko "Needs a rebuild" [Undecided,New]  https://launchpad.net/bugs/135426
<qid> anyone know where I can get the wireless tools packages for gutsy 7.10? I'm attempting to follow the suggested workaround here: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214/comments/48
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [Undecided,Confirmed] 
<StevenK> ion_: Another rebuild? Oh, duh, OO.o 2.3
<StevenK> ion_: I shall do that in the next little while.
<ion_> openoffice.org-voikko depends on openoffice.org-core (>= 2.3.0~src680m224) and openoffice.org-core is being upgraded from 2.3.0~src680m224-1ubuntu2 to 1:2.3.0~oog680m1-1ubuntu3
<ion_> Thanks
<StevenK> ion_: openoffice.org-voikko 2.0.1-1build3 uploaded
<ion_> Yay
<ctkroeker> does the new screen gui support setting up dual monitors set up on dual video cards? i.e. an onboard SIS and a cheapo nvidia...
<moquist> Can I get away with using bash for the postinst in a package intended for main?
<moquist> (instead of sh)
<sbalneav> moquist: Don't think so, but, if yo need help converting bashisms to dashisms, I'm your man :)
<mneptok> moquist: dash was chosen for sh for a reason. the clock moves in one direction. :)
<moquist> sbalneav: if [ $(wc -l <<<"$o") != 1 ] ; then
<moquist> sbalneav: But I may just change several things, so that line may just go away.
<sbalneav> if [ $(echo "$o" | wc -l) != 1 ] ; then...
<moquist> sbalneav: I'm making things way too hard on myself. :)
<kirkland> mneptok: I'm curious of the reason...  is dash statically linked or something?  simpler?  faster?
<RAOF> Simpler & faster.
<sbalneav> Posix Compliant.
<Hobbsee> bah.  i thought i was almost going to get lucky
<Hobbsee> it looked like the open network was going to connect with the mangler, and ipw394
<Hobbsee> 5
<sbalneav> Anyone got a feisty box handy?
<sbalneav> check this out:
<sbalneav> start up dash
<sbalneav> echo foo bar baz | if read I J K; then echo i: $I; echo j: $J; echo k: $K; fi
<sbalneav> segfault!
<nixternal> sbalneav: works for me
<nixternal> but then again, that is with bash :)
* nixternal switches to dash
<nixternal> works in dash for me as well
<StevenK> Neat!
<StevenK> k: baz
<StevenK> zsh: segmentation fault (core dumped)  dash
<sbalneav> gutsy or feisty?
<nixternal> gutsy
<sbalneav> It works for me in gutsy, but not feisty.
<sbalneav> Hence, the reason why I asked if anyone had a handy feisty :)
<stdin> works on my feisty box
<sbalneav> In bash, or dash?
<stdin> bash
<stdin> and dash
<sbalneav> We've got 3 people who that segfaults with in dash on feisty.
<nixternal> oh, what is feisty :p
<nixternal> I haven't used Feisty since umm, it released :)
<sbalneav> What's out there right now.
<StevenK> Does it segfault in Gutsy?
<sbalneav> No.
<sbalneav> Not for me at least.
<StevenK> Does for me.
<StevenK> Maybe it's an AMD64 ism
<sbalneav> It's something.
<sbalneav> It's weeeeiiiird is what it is :)
<StevenK> Doesn't segfault in 32 bit.
<sbalneav> moquist bumped into it.
* moquist is running 32 bit and it segfaults for him
<moquist> I wonder if it's something in my environment.
<sbalneav> Well, even if it is, segfaulting wouldn't be the preferred way to handle it :)
<StevenK> doko__: Ping, what are your thoughts about bug 134994?
<ubotu> Launchpad bug 134994 in python-central "UVF Exception for python-central" [Undecided,New]  https://launchpad.net/bugs/134994
<lucas> a lot of packages (21) fail to build in universe because libxext-dev was dropped from the depends of libx11-dev
<lucas> the change hasn't hit debian unstable yet, so there's no fix to pick in debian
<fabbione> lucas: it probably means that you need to fix those 21 packages to Build-Dep on libxext-dev if they need that library
<lucas> we could fix those 21 packages, and then sync them during the gutsy+1 cycle, or we could re-add that dep for gutsy, and wait until debian fixes its packages (which will happen during the gutsy+1 cycle)
<lucas> re-adding the dep seems harmless. it was dropped because of #366676
<lucas> (I talked with julien cristau, and he plans to push that change to unstable, not revert it)
<fabbione> lucas: well there is a fix in there by breaking a loop in the build dep
<fabbione> lucas: not that it really matters were we are now
<fabbione> but either fix the 21 packages or revert that change is kind of harmless
<fabbione> i would personally prefer to fix the packages.. clean and proper solution
<lucas> ok
<seb128> Riddell: could we update bluez-gnome (bug #134462)?
<ubotu> Launchpad bug 134462 in bluez-gnome "[UVFe]  Please review merge of bluez-gnome (0.13-1) from Debian unstable (main) (was: Can you upgrade bluez-gnome to 0.13 version in gutsy because of the lot of bugfixes and better translations)" [Wishlist,Incomplete]  https://launchpad.net/bugs/134462
<atlas95> hello
<atlas95> i want little help in C, how to define a char in C please?
<atlas95> for exemple: long myVar="blabla"
<atlas95> don't work
<atlas95> and char="blabla" don't work too
<atlas95> i'm newbie
<seb128> atlas95: that's not the right channel to learn C
<atlas95> yes sorry :)
<atlas95> what is the goood?
<atlas95> Cnewbie is empty
<seb128> no idea
<coNP> atlas95: ##c maybe
<seb128> but you can find C tutorials on google easily
<atlas95> only 440 users on ##c
<atlas95> :p
<atlas95> thanks ;)
* mvo thinks that is going to be fun
* coNP sees that it *is* fun :)
<Riddell> seb128: which of the changes are you wanting to get from the new version?
<seb128> Riddell: lot of bug fixes
<Riddell> seb128: http://launchpadlibrarian.net/8999403/diffstat.txt only lists three, is there a more complete changelog?
<seb128> Riddell: I'll ask the people who wanted the update to add details
<seb128> http://launchpadlibrarian.net/8999404/changelog.diff
<seb128> that's the upstream changelog
<Riddell> seb128: do you have people testing it?
<seb128> no
<seb128> I was expected getting an approval easily
<seb128> I'll ask them if they tested it, etc
<Riddell> seb128: I'm happy to approve it but only if there's people to test it :)
<seb128> we need a proper UVF exception procedure for main
<Riddell> seb128: well, this is it (properly you should subscribe ubuntu-archive, but I'm fine with IRC too if I'm not busy)
<Kmos> or subscribe ubuntu-release
<Kmos> for others (simple users)
<Riddell> err, aye, that's what I ment
<Riddell> too many hats
<seb128> Riddell: the new gnome-bluez is in Debian for almost a month if you consider that as some testing ;)
<Riddell> seems like a fair criteria
<Riddell> seb128: go ahead
<seb128> Riddell: thanks
<Kmos> Riddell: bug 132405
<ubotu> Launchpad bug 132405 in xterm "Please sync xterm (229-1) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/132405
<Kmos> Riddell: i've answered you
<tepsipakki> who is holding the archive hat today?
<tepsipakki> um, archive _admin_ hat ..
<tepsipakki> but 133793
<tepsipakki> f***, bug 133793
<ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Incomplete]  https://launchpad.net/bugs/133793
<Riddell> tepsipakki: seb128
<tepsipakki> Riddell: thanks
<tepsipakki> seb128: ^^
<seb128> tepsipakki: "Incomplete", doesn't look good for you
* seb128 clicks on it
<Riddell> Kmos: is xterm.log.html a changelog?
<tepsipakki> seb128: right, I can change that :)
<Riddell> Kmos: yes, it seems to be, please include the latest changes entry in the bug
<seb128> tepsipakki: I'll do the sync
<Riddell> bryce: do you have an opinion on bug 132405?
<ubotu> Launchpad bug 132405 in xterm "Please sync xterm (229-1) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/132405
<tepsipakki> seb128: excellent, thanks
<Kmos> Riddell: the xterm doesn't have any changelog
<Riddell> Kmos: so what is xterm.log.html?
<Kmos> Riddell: i found another bug on LP about xterm that will fix with 229-1, i've commented there
<Kmos> Riddell: hmm.. let's check that
<Riddell> Kmos: err, it removes the .desktop file?  how is someone ment to run it then?
<tepsipakki> those were added upstream not too long ago
<tepsipakki> +by
<seb128> xterm .desktop?
<tepsipakki> uyes
<seb128> those need to use a NoDisplay=true
<tepsipakki> damnit, I can't type today..
<Riddell> seb128: why?
<seb128> because they are not nice creating a system tools category on the default desktop
<tepsipakki> seb128: they were removed by debian
<seb128> Riddell: because we install xterm for whatever reason and it's not nice to have 3 terminal emulator in the default installation
<Riddell> seb128: if it's a problem having it in the default desktop, why not remove it from the seed?
<seb128> Riddell: I except we have it by default because it's part of the basic debug tools
<seb128> like the debug login is running Xorg with an xterm
<Kmos> Riddell: done
<\sh> Riddell, you don't want to remove xterm from the seeds..xterm is default and should be installed by default
<seb128> s/except/expect
<Riddell> \sh: is default for what?
<cjwatson> xterm is used by the failsafe session
<cjwatson> oh, seb said that
<cjwatson> I think moving it to Accessories would be better than removing it, though
<\sh> Riddell, default for every X installation I know, and it shouldn't be removed from the default install of Ubuntu...and the facts from seb and cjwatson, which are important too
<cjwatson> gnome-terminal lives there (as does pterm, though that's incidental :-))
<seb128> cjwatson: we would have gnome-terminal, xterm, uxterm there
<cjwatson> seb128: yes
<seb128> cjwatson: that start being a bit much terminal emulators wise to my taste
<iwj> ion_: Hmm.  In theory, yes, triggers could improve that.  But the structure of the way the initramfs's are added and removed would have to be changed and I think we may be a bit late in the release cycle for that change.
<Kmos> anyone wants to sync bzr-gtk ? v0.90.0 from debian is out
<Kmos> gutsy has 0.18.0
<Kmos> :)
<cjwatson> not until bzr 0.90 is also in gutsy
<cjwatson> and I think we should possibly wait for a non-release-candidate there
<Riddell> "adapt xterm.menu to the new menu structure" do we use the new menu structure?
<Kmos> Riddell: nop
<Riddell> so that should probably be changed for any sync?
<Kmos> Riddell: but it still works in gutsy.. even with new menu structure
<Kmos> in the new package
<Riddell> ok, magic
<geser> Riddell: doesn't this only affect the Debian menu which Ubuntu doesn't use?
<tepsipakki> I bet there are other packages in gutsy already which have made that change
<cjwatson> Kmos: you say "fixes many bugs" but the changelog lists two changes. What is your definition of "many"?
<Kmos> tepsipakki: yep, a lot of them
<Kmos> cjwatson: you check the changelog from xterm ?
<cjwatson> Kmos: yes
<Kmos> cjwatson: i'm refering to them also
<cjwatson> the upstream changelog is what I'm talking about
<cjwatson> * override locale in minstall.sh; change in patch #226 does not work in UTF-8 locale (report by Zdenek Sekera).
<cjwatson> * undo an incorrect fix for a memory leak in (Debian #435858).
<cjwatson> that's not "many bugs"
<ubotu> Debian bug 435858 in xterm "xterm: crashes on non-existent wide bold font" [Normal,Fixed]  http://bugs.debian.org/435858
<Kmos> cjwatson: open http://invisible-island.net/xterm/xterm.log.html
<Kmos> and click on patch #226 and #209
<cjwatson> stop telling me to do that. I already did.
<Kmos> :)
<tepsipakki> Kmos: those are only links to previous releases
<cjwatson> why are the contents of patches #226 and #209 relevant? we already have those
<cjwatson> the changelog is indicating that it fixes problems in those patches
<cjwatson> we already have everything up to patch #228
<Kmos> cjwatson: and two LP bugs..
<cjwatson> this is still not "many". you were exaggerating the importance and I'm calling you on it.
<Kmos> cjwatson: i understand.. but english in not my primary language :) many.. a few ones =)
<Kmos> two =)
<cjwatson> ah, that defence
<cjwatson> I assume you will know in future and not exaggerate two-change upstream releases using the word "many" then?
<cjwatson> the default behaviour after UVF is not to accept new upstream releases
<Kmos> cjwatson: yes i know.. I just won't ask for any =) I've already told hobbsee
<Kmos> that's better for ubuntu, lol
<cjwatson> but you just did ask
<cjwatson> though admittedly that bug dates from before UVF
<Kmos> yeah, it's 2007-08-14
<Kmos> but I've done all procedures like UVFe
<Kmos> like i've done for rdiff-backup that's approved yesterday
<Kmos> bug 129572
<ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129572
<Kmos> this one stopped after first ack from hobbsee
<Kmos> days agoo
<Kmos> seb128: thx for the sync
<seb128> Kmos: you're welcome
<soren> cjwatson: Is the installation-guide kept in svn or bzr or something somewhere?
<soren> cjwatson: Or do you just use the debian svn and apply a patch each time?
<cjwatson> soren: the latter
<soren> cjwatson: Alright. Thanks.
<cjwatson> it's just a source package at the moment. if I ever manage to get a bzr import of it then I'll move to that
<cjwatson> oh, hey, what do you know
<soren> cjwatson: https://code.launchpad.net/~vcs-imports/installation-guide/trunk
<cjwatson> yeah, I just found that too :)
<soren> :)
<cjwatson> I'll migrate to that at some point then, but please let me do it as I have all the history
<soren> Sure, sure.
<soren> cjwatson: You wouldn't happen to know if there's a PDF version of it somewhere, would you?
<doko> Riddell: looks ok to me
<Riddell> doko: thanks
<ogra> iwj, would you mind to take a look at the libxml++2.6 MIR to unblock gobby (was added as new dep in the latest release)
<iwj> ogra: Sure.
<ogra> thanks :)
<cjwatson> soren: yes, in installation-guide-$ARCH.deb
<soren> cjwatson: Oh, so it is!
<soren> I thought it needed not-quite-free stuff to build the pdf's.
* ogra is irritated ...
<StevenK> doko: Ping, what are your thoughts about bug 134994?
<ubotu> Launchpad bug 134994 in python-central "UVF Exception for python-central" [Undecided,Confirmed]  https://launchpad.net/bugs/134994
<soren> https://wiki.ubuntu.com/DocumentationTeam/BuildingDocumentation/PDF suggests this is the case..
<MinuteElectron> Hi may I make a suggestion?
<somerville32> MinuteElectron: Sure.
<MinuteElectron> On the installer can you make it so when you press up on the top option of the main menu it goes to the bottom. It seams trivial but I install often and it gets rather tedious and I nearly always make the mistake.
<cjwatson> could you file a bug on https://blueprints.launchpad.net/ubuntu/+source/cdebconf/+filebug for that, please?
<cjwatson> sounds reasonable to me
<MinuteElectron> ok
<MinuteElectron> thanks
<cjwatson> though it would mean that you couldn't just hold down up-arrow for a while to get to the top
<MinuteElectron> done
<MinuteElectron> #135543
<MinuteElectron> thank you
<cjwatson> soren: we clearly manage it ;-)
<iwj> We're conducting a campaign against .la files, right ?
<Kopfgeldjaeger> hi
<ogra> thats what they all say ...
<Chipzz> Kmos: hobbsee already told you quite extensively why she didn't reply on your powertop sync request any more yesterday; why do you bring it up again then?
<Kmos> Chipzz: because if she doesn't want, maybe someone else want to.
<Chipzz> Kmos: also, sync requests are NOT about finding as many packages as possible that have a new version in debian or upstream, and requesting a sync request for all of them just for the sake of it
<Chipzz> and you have also been told that
<Kmos> Chipzz: yeah.. but as you can see isn't about to find many packages possible. it's about credibility
<Chipzz> almost sounds like you don't get what a sync request is
<Kmos> Chipzz: but for that, I won't ask for any syncs anymore
<Kmos> just want the ones i've waiting done for gutsy
<Kmos> like the powertop that still an RC in gutsy
<Chipzz> Kmos: maybe your credibility is related to the number and quality of the sync requests you file?
<Kmos> 1.8 is the final
<Kmos> Chipzz: don't think so.. you can check all of them =)
<Kmos> it's about the number
<Kmos> quantity :)
<Chipzz> a sync request is about synchronizing it because it actually has a concrete use; ie it fixes one (or more) bugs we care about
<Chipzz> and care about means "not just some random bug"
<Kmos> yeah, I know
<Chipzz> the idea is to actually get packages stable in preparation for a release; that means, no new features, and be carefull about what bugs they fix
<Chipzz> because every change can introduce a new bug
<Chipzz> so the bugfix for a minor bug may very well introduce one or more more severe bugs
<Fujitsu> This is what cherrypicking is for.
<Kmos> Chipzz: yep, I know that.. I'm also a developer :)
<Chipzz> Kmos: then *why* do you show so little intelligence and common sense?
<Chipzz> for example in filing these sync requests?
<Chipzz> I'm guessing that's why people get mad at you
<Kmos> Chipzz: have you checked the sync requests i asked for ?
<Kmos> Chipzz: maybe it's that, and that's because I won't file sync requests
<Kmos> anymore
<Chipzz> Kmos: quite frankly I don't need to if I see Hobbsee's comments
<Kmos> Chipzz: if you think that, that's your problem
<Kmos> *like that
<Chipzz> Kmos: my guess is people get mad at you because despite the fact that they've explained several things to you several times, you just don't seem to get the general idea and spirit behind it
<Chipzz> Kmos: I'm not calling you dumb, I'm just saying that you should try to understand why what you're doing is wrong, and learn from that
<Chipzz> but the last part (learning from that) is what's missing apparently, and that's why people get mad at you
<Kmos> I always be criticized from whatever I do, so I choose not to contribute directly to ubuntu, even file sync requests
<Kmos> i don't want hobbsee to be mad, and motu people.. they're the best, so do their job.. i'll participe from now on getdeb.net
<Chipzz> Kmos: no you won't; but have you understood what I'm trying to say?
<infinity> Kmos: The -release team works as a team, we back each other up.  If one of us turns down a UVF exception, please don't make an end-run around them and ask another.
<Kmos> with my packages and with people really needs
<Kmos> Chipzz: yes.
<infinity> Kmos: We're not divorced parents you can play off each other to satisfy your whims.  Hobbsee's decision is just as final as anyone else's on the team.
<Kmos> I think another one has sent an e-mail to devel mailing list about me..
<Chipzz> Kmos: what you seem to lack is not intelligence, just an understanding about what things like a release process are
<Kmos> infinity: so what's hobbsee decision ?
<infinity> Kmos: In my scrollback, I saw mention of her turning down one of your requests, and you asking someone else instead "in case they might want it".  Don't do that.
<infinity> Kmos: It just wastes our time to have multiple team members going over the same requests over and over again until you get your desired result.
<Kmos> infinity: she told me she won't process my requests. so I need someone else to do it
<Chipzz> infinity: 13:37 < Chipzz> Kmos: hobbsee already told you quite extensively why she didn't reply on your powertop sync request any more yesterday; why do you bring it up again then?
<Chipzz> infinity: ;)
<Chipzz> oh
<Kmos> these are my final requests, i won't ask for more anymore
<Chipzz> at leet-o-clock even :)
<mantiena-baltix_> who is responsible for kernel bugs ? there is big problem because 7.04 (feisty) CD doesn't  start on lots of new laptops. based on Intel santarosa platform
<mantiena-baltix_> look at bug #126653 for example
<ubotu> Launchpad bug 126653 in linux-source-2.6.20 "Feisty kernel cannot detect CD/DVD (SCSI based)" [Undecided,New]  https://launchpad.net/bugs/126653
<StevenK> Why do I have this feeling it's SATA based, as opposed to SCSI?
<cjwatson> mantiena-baltix_: the kernel team. #ubuntu-kernel
<mantiena-baltix_> it's interesting, that older and newer Ubuntu versions, also. it seems, feisty kernels (from Ubuntu 7.04 beta) detects cdrom fine
<mantiena-baltix_> cjwatson, thanks, should I repeat my post there ?
<mantiena-baltix_> StevenK, I also think, that it's SATA :)
<cjwatson> mantiena-baltix_: it'd be more useful than here, at any rate
* Hobbsee waves
* Hobbsee acts like a heron
* thom puts a net over his fish pond
<Hobbsee> oops, sabdfl flooded due to the waves.
* Hobbsee eats the fish through the fishnet
<xxxxx1> hey sabdfl
<Hobbsee> sabdfl: when waves are made, please dont flood, or drown.  it's really quite inconvenient.
<somerville32> 8.04 seems like such a "mature" number, <g>
<highvoltage> somerville32: it's almost 9.0! we can compete with old red hat versions!
* somerville32 cheers.
* Hobbsee wonders how people come up with such names, and whether they check things like the urban dictionary first.
<somerville32> I was hoping for Hungry Hippo myself
<\sh> as jdub wrote...it's pr0n ,-)
<StevenK> The urban dictionary is ... not exactly authoritative.
<Hobbsee> StevenK: that was a example
<ogra> somerville32, seems everybody was
* ogra reads that a lot over the channels ...
<StevenK> Hobbsee: Point.
<\sh> ogra: what's the best german translation for Hardy Heron, abgehrteter Reiher oder Khner Reiher?
<somerville32> The Urban Dictionary tells me that Heron is slang for a number of things
<ogra> \sh, robuster reihern
<ogra> err
<ogra> -n indeed :)
<Hobbsee> the first thing i think of is the hardy heroin users that develop the release.
<somerville32> Is Ubuntu 8.04 "a girl that club hops every thursday , friday and saturday night to see how many numbers she can get or how many guys she can make out with or how many free drinks she can get per night"?
<ogra> Hobbsee, no, its handy heroin we provide to our ubuntu addicts ;)
<\sh> ogra, we should file a bug at dict.leo.org ,-) robust is not known...but zhlebig :)
<Hobbsee> ogra: ah right.
<somerville32> haha
<Hobbsee> somerville32: maliciously so, so goes and trashes any windows installs at the same time.
<Hobbsee> ogra: there's the potential for so many drug jokes to be made here.  what fun.
<cjwatson> somerville32: and once upon a time 5.10 seemed so unimaginably far away ...
<somerville32> lol
<mjg59> cjwatson: Once upon a time 4.10 seemed implausible
<Hobbsee> cjwatson: yes, we know you're old :)
* Hobbsee ducks
<cjwatson> Hobbsee: heh
* StevenK tries to bend dch to his will.
<StevenK> It might just be easier to prepend a heredoc, sigh
<Hobbsee> cjwatson: oh wait.  i shouldnt say that kind of thing around you, because you could bash me up.
* Hobbsee blames mjg59 of being old instead
<cjwatson> er. could but won't
<Hobbsee> cjwatson: oh good.  so i'm safe!
<mjg59> Hobbsee: Colin's got a good 6 months of Ubuntu time over me
<cjwatson> mjg59 is a sprightly youngster
<cjwatson> mjg59: is that actually true? you were around in Oxford
* Hobbsee can accuse cjwatson of being old then :P
<mjg59> "So this guy who's been to space just rang me up and offered me a job"
<StevenK> What does that make me then, having joined during Dapper?
<mjg59> cjwatson: Oh, hm. 4 months? When did you join?
<cjwatson> mjg59: spoke to Mark in Feb, actually joined in May
<\sh> StevenK, a young padavan ,-)
<mjg59> cjwatson: Ah, that would explain it. 3 months or so, then.
<thom> you're both sprightly youngsters, really ;-)
<cjwatson> maybe March, not sure
<StevenK> \sh: You need to learn to spell. Or something.
* Hobbsee pinches thom's walking stick, and eats his fish.
<thom> get orf my laaaand!
<Hobbsee> bah.  crazy old man :P
<\sh> StevenK, padavan -> a young jedi knight
<Hobbsee> thom: just dont tell me all your money is in the freezer.
<\sh> StevenK, oh sorry...s/v/w/
<StevenK> \sh: It's a padawan, surely?
<StevenK> thom: I used to be sprightlier. :-(
* Hobbsee ponders what to cook for dinner.
* Hobbsee cooks \sh for dinner.
<Hobbsee> that'll do.
<\sh> Hobbsee, no taste...believe me :)
<Hobbsee> drat
<StevenK> Hum.
<StevenK> Hurray for sponge!
* lamont grumbles at the ubuntu-users ml
<Hobbsee> lamont: why?
<Hobbsee> hiya mdz_
<seb128> lamont: what were you saying about shared-mime-info?
<lamont> it looks like I'm not subscribed as 'lamont.jones@u.c', so my first message evah to the ml was blocked for moderation
<mdz_> morning
<lamont> seb128: that libxml2 sucks
<seb128> lamont: in what way? ;)
<lamont> seb128: root cause came down to zlib1g diverting to 64-bit, pointer-returning functions but not defining them --> segv in libxml2 --> update-mime-info SEGV during install of shared-mime-info
<seb128> lamont: oh, not good
<lamont> of course, it'd be nice if libgnomevfs2-common was _removable_ in that situation, instead of barfing in postrm
<lamont> seb128: yeah - I'm going to hack over sbuild on the ia64 buildd to ftbfs the package in those cases.
<lamont> Hobbsee: does that mean that you're a moderator for u-users?
<lamont> morning mdz_
<Hobbsee> lamont: i am not.  i am for a few other lists, but not that one.
<iwj> I have a MIR which I want to approve except that the -dev .deb contains a .la file.  Is that an approval-critical bug ?
<Hobbsee> (kubuntu-devel, kubuntu-users, ubuntu-universe-sponsors, ubuntu-devel)
<iwj> (I don't know what a .la is but I remember some people whose identities I've forgotten telling me they were EBW somehow and we were trying to get rid of them.)
<Riddell> iwj: we have loads of libraries with .la files
<iwj> Riddell: So we don't mind a new one ?
<seb128> iwj: .la are fine, they are used for static builds (though not required on linux nowadays)
<Riddell> iwj: can't imagine so
<iwj> OK, I must have misunderstood.
<siretart> iwj: speaking of MIRs, do you have news on the cryptsetup MIR?
<seb128> iwj: we try to get ride of them since they often bring issues (like when you drop a depends from a lib you need to rebuild all the packages shipping a .la to reflect that)
<lamont> iwj: .la files are how you wind up with horribly long build-depends lists that don't need to be that way other than for .la files.
<iwj> seb128: Right.
<iwj> Hmm.
<lamont> nothing in the gnome universe should have them.
<iwj> But is it an approval-critical bug if it does ?
<lamont> and seb128 said it better
<seb128> iwj: no, shipping them is not a bug
<seb128> we just try to get ride of them to make things easier
<iwj> siretart: No, I don't have any news but let me see the status.  (In general, feel free to chase me for MIRs.)
<iwj> seb128: OK
<StevenK> Damn it, find, *why* does -ctime have to be * 24 hours
<lamont> well, if the package changes at a later date to not use a lib that it does today, and delivered a .la file, then that droppage will require a rebuild of everything that build-depends that package and delivers a .la file.   recursively
<cjwatson> StevenK: does -cmin help?
<StevenK> *blink* Didn't know that one.
<cjwatson> still a stupid granularity but might be better
<iwj> siretart: It's under `reviewed packages that need work' in the queue.  Looking at the review now.
<StevenK> cjwatson: Indeed, thanks muchly
<iwj> siretart: Seems nothing much has changed since my last review.
<seb128> bah, apt sucks at describing why a package is not installable
<siretart> ogra: I think you have been filing the mir. are you still working on it?
<seb128> iwj: bug #135519, do you think those bugs could have an apt debug log or something like that?
<ubotu> Launchpad bug 135519 in compiz "autopkgtest gutsy compiz amd64: erroneous package!" [High,New]  https://launchpad.net/bugs/135519
<seb128> iwj: the bug has been opened on compiz but the issue is libcompizconfig0 not being installable and there is no detail (I think that's a transitional issue, mvo uploaded a new stack with Breaks use today)
<iwj> seb128: I could probably organise that.  How would I acquire one ?
<seb128> iwj: probably by setting Debug::pkgProblemResolver to true in the apt configuration
<iwj> seb128: Right, if it's just a transitional problem feel free to close the bug with `this is fixed now we think'.
<seb128> iwj: is there a way to determine that the bug is a "package not installable" and do a new try with this one set in this case?
<iwj> The tester can't really tell if uninstallability is just transient or not.
<iwj> I think it would be better just to turn on the debugging in general.
<seb128> mvo: ^ what do you think?
<iwj> Or to capture it and suck it out.
<iwj> I mean, suck it out if the installation fails.
<seb128> right, that would be nice
<mvo> iwj: you could use some sort of greylisting, if the install fails, record that and then try again in ~4h (or some other value). if it fails then still, file a bug
<seb128> mvo: would it be possible to make apt smarter about displaying errors?
<seb128> it display package is not installable because <list of depends not installable>
<seb128> but doesn't mention where is the issue in the list of depends
<seb128> and what prevents it to be installed
<mvo> seb128: probably
<soren> I need a bit of assistance with some licensing stuff. There's a bug about enabling some additional modules in the php5 build. The two modules in question are readline and gmp. readline is GPL, while gmp is LGPL.
<seb128> you usually have to apt-get install each of them to figure the bug
<mvo> at least for simple cases
<mvo> sometimes apt does not that itself ;)
<soren> IIRC the php license is considered gpl-incompatible, so php5-readline would require an exception from the libreadline copyright holder, correct?
<iwj> I've c&p the first bit of this irc conversation as bug 135581.
<ubotu> Launchpad bug 135581 in autopkgtest "autopkgtest should provide apt debug log" [Undecided,New]  https://launchpad.net/bugs/135581
<soren> What about gmp?
<seb128> iwj: thanks
<llllllllllllllll> bryce it's me lucky_lucas, I have to add something to the ati / compiz freezing problem
<iwj> mvo: If you have some idea how I should improve this I'm all ears.
<llllllllllllllll> I tried compiz on antoher pc with nvidia and it hangs too
<iwj> mvo: Failing that I'll just make something up ...
<superm1_> one of the archive admins got a sec?  I needed someone to release an update to an SRU that was release to -proposed a few days ago from the manual queue?
<llllllllllllllll> seems to be a trouble in  X aiglx or compiz
<seb128> superm1_: what do you mean?
<superm1_> seb128, i got a mail from ubuntu-installer saying the distro release manager has to release them
<mvo> iwj: the only idea I have is this greylisting, the disadvantage is that you have to carry around the state somewhere
<superm1_> seb128, it was to feisty-proposed and edgy-proposed
<iwj> mvo: No, I mean for getting more debug output.
<seb128> superm1_: your description is not clear. They have been accepted to proposed yet or are you asking for that?
<mvo> llllllllllllllll: what bugnumber is that?
<iwj> mvo: Greylisting is an answer to transient problems, surely ?
<mvo> iwj: yes, that is what I mean
<seb128> mvo: there is 2 things, transient bugs and real bugs not having enough details
<iwj> The question seb128 was asking was how to get more detail about the problem.
<superm1_> seb128, sorry, the SRU was accepted to proposed a few days ago, but there were a few problems encountered with it, so I have a follow up for proposed in the queue right now
<llllllllllllllll> mvo 134578
<seb128> superm1_: use launchpad, subscribe ubuntu-sru, wait for approval, etc as described on the wiki
<mvo> iwj: debug output> pkgProblemResolver=true and  Debug::pkgDepCache::AutoInstall=true
<llllllllllllllll> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/134578
<superm1_> seb128, its a universe sru
<ubotu> Launchpad bug 134578 in xserver-xorg-video-ati "Open source ati driver freeze with compiz" [Undecided,New] 
<mvo> bug  134578
<mvo> bug # 134578
<mvo> bug #134578
<seb128> superm1_: so ask on #ubuntu-motu was the procedure is
<iwj> mvo: And that'll go where ?  Can I get it to go a separate file ?
<mvo> seb128: yes, missed that
<superm1_> seb128, as previously, the point in the procedure is that the archive admin needs to release it at this point, per the wiki
<mvo> iwj: stderr, I could look into a redirect thing if you want
<seb128> superm1_: so open a bug on launchpad and subscribe the ubuntu-archive team and wait for a team member to process it
<superm1_> okay seb128 .  Thanks
<seb128> you're welcome
<iwj> If it could be sent into a file and there was a way to tell whether to dump the file into the log, that would be very nice.
<seb128> superm1_: I looked at ubuntu-archive bugs this morning and there was nothing about that
<iwj> I mean, the exit status or something would have to say whether it was a dependency problem.
<superm1_> seb128, previously Riddell had just acked it without looking for a bug about it, so it wasn't apparent that i needed to file a bug to make it happen.
<mvo> iwj: I made a note about this, I check it out
<seb128> superm1_: well, pings on IRC don't scale
<seb128> superm1_: that's not a replacement for a bug ;)
* superm1_ nods
<iwj> mvo: Thanks.
<iwj> mvo: (I tried  apt-get -o pkgProblemResolver=true install some stuff  and it didn't seem to produce any output.  Obviously I'm doing it wrong.)
<iwj> Ah, -o Debug::pkgProblemResolver=true
<ogra> siretart, well, i was pondering encrypted swap by default for ltsp, but there has beeen no further work on it due to time constraints
<mvo> iwj: apt-get install 4g8 -o Debug::pkgDepCache::AutoInstall=true -o pkgProblemResolver=true
<lamont> mvo: 4g8 has install issues, or it's just a conveniently short package name?
<Riddell> seb128, superm1: subscribe motu-sru
<iwj> That seems very good actually.
<seb128> iwj: Debug::pkgProblemResolver=true
<iwj> I'll just add that option to all of my apt settings.
<\sh> hmm...I made a bug fix today for 4g8
<iwj> Debug::pkgProblemResolver=true I mean.
<mvo> lamont: its a) short b) top in the synaptic list where I usually look for good examples. I also like "2vcard" and "3ddesktop" :)
<lamont> ok
<iwj> ogra: libxml++2.6 approved BTW
<lamont> mvo: it's also what my management would consider malware.
<iwj> mvo: Thanks, I think I don't need anything more from you about this.
<lamont> and yes, I packaged it
<ogra> iwj, yay, pkern will love you :)
<ogra> (and edubuntu too :))
<mvo> lamont: I never actually looked what it is, I noticed that you maintain it :)
<mvo> iwj: cool, even better. thanks
<lamont> mvo: you feed it a pair of IPs and MACs.  it inserts you in the middle
<StevenK> lamont: That's *EVIL*
<mvo> lamont: that is useful!
<lamont> network problem diagnosis made simpler
<lamont> arp cache poisoning for the win
<ion_> That program would probably be illegal in Germany. :-)
<StevenK> It's a MITM attack, used for diagnosis. Ouch.
<lamont> OTOH, I haven't actually made it _work_ yet...
<cjwatson> as usual, there's sometimes a fine line between malware and useful sysadmin tools
<\sh> ion_, whaaaa
<lamont> cjwatson: exactly
<lamont> mind you, telnet and gcc both meet the definition of 'malware' as written in the company policy here...
<\sh> ion_, I have it on my laptop
<StevenK> lamont: Ouch.
<StevenK> lamont: Even cat? :-P
<lamont> "any software that could be used to evaluate vulnerabilities in another computer"
<StevenK> netcat!
<lamont> so I guess a web browser would count too
<lamont> StevenK: certainly
<ion_> sh: Youre a criminal. ;-)
<StevenK> nmap, most definitely
<ion_> sh: Dont tell me you also have nmap!
* lamont maintains nmap
* StevenK high fives ion_ 
<\sh> ion_, I need nmap for our datacenter security ,-)
<StevenK> lamont: Oh, so you do. :-)
<lamont> StevenK: when I pointed out the stupidity of the policy, they granted me an exception from it.
<StevenK> Heh
<lamont> they much prefer possession rules to intent-based rules
<StevenK> "I can't do my work, since any web browswer is against company policy."
<lamont> to which their response is of course, that they'll determine on a case-by-case basis what is and is not malware.
<lamont> which just means that if they want to fire someone, that's one more excuse they can use...
* lamont stops venting about stupid rules, gets back to work
* StevenK keeps watching builds
<ion_> sh: Judging from your initial response, you werent familiar with the law. If thats true, please take a look at http://www.google.com/search?q=germany+law+nmap
<siretart> ogra: too bad. we were discussing installation on crypted filesystems in sevilla, and that time we expected cryptsetup to be in main for gutsy so that we can have partman-crypto tested in the installer :/
<\sh> ion_, I know everything about this law :)
<ion_> sh: Alright, sorry then.
<\sh> ion_, I'm one of those stupids who have to live with those stupid politicians ;)
<ogra> siretart, feel free to fix it ... i'm way to busy with other stuff
<ogra> you have my full support to get it to main :)
<siretart> until when are MIRs processed?
<StevenK> xfish.c:183: warning: incompatible implicit declaration of built-in function 'strncpy'
* StevenK sobs.
<ogra> siretart, no idea, beta freeze ?
* StevenK throws 19 builds at the archive.
<pkern> ogra: libxml++2.6's main inclusion was approved, so Gobby could go in. But I would need a UVF exception for bug #114023 (sobby)...
<ogra> pkern, yeah, lots and lots of thganks for doing the MIR :)
<ogra> why does sobby need an UVF ?
<pkern> ogra: I guess I would also need one for sobby to go in?
* Hobbsee curses the lack of active freenode staffers.
<ogra> s/UVF/UVFe/ ?
<Hobbsee> oh, wait, there's 1.
<pkern> ogra: New configuration file option to support session files in it (only change upstream). Canonical sysadmins requested that some time ago. (OTOH they used an unsupported broken init script which caused the data loss...)
<iwj> siretart: You might consult the release team about whether this needs or gets a freeze exception.
<iwj> siretart: If you can tidy up the package and the MIR report then personally I don't see why we shouldn't promote the package.
<cjwatson> cryptsetup? it's late, but I'd be inclined to take it
<cjwatson> the relevant feature is partman crypto support, which we've been putting off forever
<pkern> ogra: Well, it would be a sync from Debian w/o an Ubuntu change.
<cjwatson> cryptsetup can clearly be promoted without that though, and my inclination would be to shove in partman-crypto ...
<siretart> I'm too busy this week for this. I'd need to defer that until next week
<ogra> cjwatson, iirc there was a lot of work to do for usplash integration (but thats some time ago, i didnt look since)
<siretart> It would be really great if someone else could take over it, if it makes sense at all to work on it for gutsy
<cjwatson> I haven't looked at it
<Hobbsee> ubotu: ping
<cjwatson> but I would really like cryptsetup to move on rather than continually stalling because it isn't the right time in the release process or whatever
<siretart> ogra: seveas told me at sevilla that he had work for it in the pipe in usplash. ATM it just tells usplash to exit when prompting for a password
<cjwatson> Seveas hasn't done anything to usplash since UDS AFAIK
<siretart> oh :(
<ogra> siretart, yeah, thats not nice
<ubotu> host not found
<pkern> Poor ubotu.
<ogra> heh
<cjwatson> ubotu: learn to check your arguments
<Hobbsee> cjwatson: some morons just bot attacked #ubuntu again, so ubotu fell off the planet.
<cjwatson> sure, I meant that it's clearly just doing "ping ''" or something when told 'ping'
<Hobbsee> it's just a factoid, i'ts not an actual ping
<cjwatson> wouldn't a factoid be "ping is host not found" or similar?
<cjwatson> ubotu: ping www.ubuntu.com
<Hobbsee> cjwatson: sure, if the <reply> tag isnt used
<cjwatson> hmm, apparently not
<Hobbsee> !no ping is pong
<ubotu> I'll remember that Hobbsee
<Hobbsee> !ping
<ubotu> ping is pong
<Hobbsee> !no ping is <reply> pong
<cjwatson> ah, I see
<pkern> Doesn't ubotu reply on "bug #NNNNNN" requests stated by anyone in the channel?
<cjwatson> pkern: yes
<pkern> cjwatson: I did one and it didn't answer but a long time later "host not found".
<ogra> bug 1
<ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
<ogra> works
<Hobbsee> pkern: yes, the bot sometimes lags under excessive load
<Hobbsee> !no ping is <reply> pong
<ubotu> I'll remember that Hobbsee
<Hobbsee> !ping
<ubotu> pong
<pkern> bug #121653
<ubotu> Launchpad bug 121653 in linux-source-2.6.22 "[gutsy]  Suspend to Ram does not work on Z61m" [Undecided,Confirmed]  https://launchpad.net/bugs/121653
<Hobbsee> cjwatson: there you go, like  ^
<pkern> Yep, now it works. \:
<pkern> ogra: It didn't earlier.
<ogra> it has its days ... :)
<Hobbsee> yeah, well, it doesnt help when stupid morons try to flood it off freenode.
<ogra> that as well
<Hobbsee> ogra: it basically depends on seveas' connection.
<pkern> ogra: So what I need to do for an UVFe? Just debdiffing the versions and subscribe someone special?
<Hobbsee> !uvfe
<ubotu> Sorry, I don't know anything about uvfe - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Hobbsee> !uvf
<ubotu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
<Hobbsee> !uvfe is <alias> uvf
<mvo> !4g8
<ubotu> Sorry, I don't know anything about 4g8 - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Hobbsee> !uvfe is <alias> uvf
<ogra> mvo, ?
<Hobbsee> stupid bot, stop lagging
<ogra> mvo, does your daughter *already* reach the keyboard ?
<StevenK> Riddell: Thank you for the rubber stamp.
<Hobbsee> !uvfe is <alias> uvf
<pkern> Hobbsee: So I need a new bug for it. Fine.
<Hobbsee> damned bot.  replies in one channel, but nto another.
<mvo> ogra: I was just curious if it would do something apt-cache-ish
<Hobbsee> or aliases are broken
<ogra> hehe
<Hobbsee> mvo: !info 4g8 gutsy(defaults to feisty)
<Hobbsee> mvo: when it's not half dead.
<sladen> cjwatson: gerard moved onto other things after the feature freeze came.  I can enquire how far the partman crypto stuff got.  usplash password asking was one of the issues he mentioned, and there was a second issues somewhere  (aswell as needing the promotion to main)
<mvo> thekorn: "bughelper -p apt -T apt 'E:Dynamic MMap ran out of room,' dup" gives me a error here, is that known?
<dholbach> mvo: yes, broken since the new LP layout - the API-breaking version will fix it
<Hobbsee> good morning dholbach
<ogra> pkern, you removed the comment from the gobby MIR in the queue but didnt move the entry to the other section
<pkern> ogra: It's approved but not promoted?
<dholbach> mvo: but I'm on a sprint, so I'm not going to break py-lp-bugs and bughelper without being able to test it properly from here
<dholbach> hi Hobbsee
<ogra> pkern, right
<ogra> pkern, oh, sorry ... my fault
<pkern> ogra: I struggle with Ubuntu's procedures sometimes, but this one should be right I think. (Although net6 and obby should be listed there, too.)
<ogra> they will be pulled in as deps anyway tough
<Hobbsee> https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/135584 yay, stupid bugs.
<ubotu> Launchpad bug 135584 in ubuntulooks "default theme in Ubuntu is a huge mistake " [Undecided,New] 
<mvo> dholbach: sure
<dholbach> mvo: I'll do that next week - or thekorn can tell you which branches to use
<cjwatson> sladen: who is gerard?
<soren> iwj: What's depisok?
<iwj> A function in dpkg/depcon.c
<iwj> Err, dpkg/src/depcon.c I mean.
<soren> Ah, ok.
<sladen> cjwatson: the guy I had here working on ubiquity/usplash/partman crypto
<soren> iwj: I thought it was supposed to make sense to us mere mortals. :)
<sladen> cjwatson: I think (well, hope) he spoke/interacted with you
<ion_> hobbsee: Heh, the Human theme is one of the few themes i actually like. :-)
<cjwatson> sladen: I don't recall that
<cjwatson> sladen: unless it was a sufficiently different name that it failed to register
<Hobbsee> ion_: actually, what i should write in that bug report is "then switch to another flavour of ubuntu, like kubuntu or edubuntu"
<iwj> soren: Err.  I could explain the implications but they're a bit complicated.  Mainly there are some circumstances now where if you force apt, or drive dpkg by hand, you'll get packages deconfigured as they ought to have been where previously they weren't.
<sladen> cjwatson: I'll enquire
<pkern> ogra: UVFe request submitted. *cough*
* ogra hugs pkern 
<pkern> If there wasn't that graphical splash screen I would already have Ubuntu installed under KVM. *cough*
<sladen> cjwatson: https://code.launchpad.net/~glledo/ubiquity/ubiquity-crypto  I don't know what state it's in
<cjwatson> oh, glledo
<cjwatson> yes, he did speak to me, haven't had much of a chance to review yet though since it's dependent on the lower layers working first
<sladen> cjwatson: the status of the bits and pieces needed is at:  http://codebrowse.launchpad.net/~glledo/ubiquity/ubiquity-crypto/annotate/gerard.lledo%40gmail.com-20070828150527-vd3gtds6li3loxw6?file_id=readme.partmancrypto-20070726090920-tyt6yud2781kc0c6-1
<sladen> meh.  the delights of distributed RCS
<soren> iwj: I see. The changelog just made me curious. :)
<cjwatson> sladen: right, what I mean is that a lot of that gets to go away once it's in main and properly seeded and stuff
<iwj> Yay, now I have _two simultaneous glibc builds_ going.
<iwj> I suppose they'll be done by tomorrow morning ...
<bddebian> Heya
<Hobbsee> Chipzz: i told kmos about his ddclient sync, not the powertop one
<Hobbsee> Chipzz: the powertop one seems to have been forgotten about, by others of the motu-uvf team.
<StevenK> What's the bug number? I'll look now.
<Hobbsee> Kmos: you keep saying you wont ask for any more sync requests, but you never seem to action that.
<Hobbsee> StevenK: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/129572
<ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Incomplete] 
<Hobbsee> StevenK: last time i checked, it had no changes, but LP has screwed with the panels.
<StevenK> Hobbsee: Thank ye
<StevenK> Hobbsee: zul_ ACK'd 1 minute ago
<Hobbsee> ah, neat.
<StevenK> Kicked to Confirmed
<Hobbsee> StevenK: can you check that u-a is subscribed, etc, etc, etc?
<Hobbsee> as required?
<Hobbsee> great, thanks :)
* StevenK nods.
<StevenK> Hobbsee: All done.
<Hobbsee> infinity: FYI, what Kmos is talking about is universe, nto main.  but the same applies (particularly as i'm on both teams)
<Hobbsee> Kmos: i said i wont process that one, nor others from you at this point in UVF, because i've got no confidence in any of them, due to the contradictions.  That is not hating you, that is simply stating the facts as they stand - i have other things that i want to see happen, and the teams have got the rest of the bugs to deal with too.
<sladen> iwj: what's preventing cryptsetup promotion to main?
<sladen> iwj: security issues, usplash passphrase integration?
<iwj> sladen: Oh, just some minor problems.  No showstoppers, but the package (and the MIR report) are just in need of a bit of tidying up.
<iwj> sladen: Perhaps I ought to just fix it up myself.
<iwj> I don't really want to fix up every broken MIR but I'm quite keen on this package and it seems to be languishing.
* sladen pants breathlessly in iwj's direction
<iwj> How alarming.
<sladen> iwj: given the nature of this package, it is one that I /would/ rather was fixed up directly, if you're willing to
<iwj> Sure.
<iwj> My glibcs are still building :-).
* siretart hugs iwj for taken care of cryptsetup's MIR :)
<iwj> OMG it's statically linked against libgcrypt, libgpg-error, libnsl.
<sabdfl> asac: am now in a spot with both wired and broken wpa networks
<sabdfl> would you like me to help debug this?
<dobey> hi sabdfl
<iwj> siretart: Are you using cryptsetup yourself ?  For the root fs ?
<iwj> sladen: ^
<\sh> hmmm...one question to our firefox gurus...any reason why we have a package for the adblock plugin , but not for adblock plus? is there a reason behind this decision?
<sabdfl> hey dobey
<sladen> iwj: not on /this/ machine.  But have done on the test installs
<Hobbsee> \sh: out of curiousity, do we actually install any filter with that, and if so, which one?
<iwj> sladen: OK, good.  I might ask you to test a package before I upload it.  I don't have a suitable setup here and it would save time if I got to break yours instead :-).
<\sh> Hobbsee, well, that was my problem..I thought it's adblock plus with the filter abos...but it's just plain...
<Hobbsee> \sh: abos?
<dobey> sabdfl: how's it going?
<sabdfl> good thanks dobey
* Hobbsee is reasonably sure \sh isnt talking about the slang form of "Aboriginies"
<\sh> Hobbsee, nope...I meant subscription ;) damn DEnglish sometimes ,-)
<Hobbsee> \sh: ahhhh...
<Hobbsee> \sh: means my german should improve.  one day...
<iwj> OIC.  "# cannot depend on libraries in /usr !"
<sladen> iwj: remember this is going to need to run from initramfs before / even exists
<asac> sabdfl: yes ... let me switch context ...
<siretart> iwj: I'm using it for my home partition
<asac> sabdfl: i think what i wanted to test was to use wpa_supplicant manually ... e.g. not through wpa_supplicant.conf
<iwj> sladen: Yes, in some setups.
<iwj> siretart: Hmm.
<siretart> iwj: I've been bitten enough with my previous installation been root on lvm
<soren> I'm packaging a piece of software whose only code file is a python script installed in /usr/bin/.. IIUIC, the python packaging policy only says what to do about modules and extensions and this is neither.. Should I just leave it like this or am I required to modulify it and provide a wrapper script, etc.. ?
<iwj> siretart: As you say.
<asac> sabdfl: because thats the way network-manager uses wpa supplicant
<siretart> iwj: it was just too painfully racy, so that I came to the conclusion that its not worth the efford to do it with ubuntu. sadly :(
<asac> (and is not doing very much otherwise in wpa case)
<siretart> iwj: but for home partitions and crypted usb sticks/disks, it's great!
<iwj> I expect it will substantially bloat your initramfs.  You don't have any problems with that then ?
<sabdfl> asac: that's fine
<asac> sabdfl: wait a second i will outline the steps, e.g. commands
<sladen> soren: you can put the python program straight into  /usr/bin  ;  see 'lsb-release' for such an example 'all' python package
<siretart> well, it will drag in libssl and cryptsetup. I don't see big problems for that, at least not on i386 and amd64
<geser> is there some tool to check if the depends of a deb file can be fulfilled from the archive?
<iwj> siretart: Mmmm.
<soren> sladen: Wicked. Thanks.
<siretart> I have to admit that I don't know if a big initramfs size affects silo or palo
<iwj> ATM it statically links against those but I think that's really bad.
<iwj> But if I change that then anyone whose /usr needs cryptsetup will lose.
<soren> sladen: So... I don't even have to mess about with python-{central,support} or anything?
<ogra> siretart, libssl ??
<sladen> soren: apt-get source lsb-release
<soren> sladen: Clever you.
<iwj> ogra: No, libgcrypto.
<ogra> ah
<iwj> Err, libgcrypt.
<ogra> well, something with sane licensing :)
<sladen> iwj: if you get suitably annoyed by looking at the package, you could probably knock up a better, alternative over the weekend
<siretart> err, sorry, nothing of that. I mixed it with wpasupplicant
<iwj> siretart: So how bad do you think it would be if I were to break anyone with /usr as a separate encrypted filesystem.
<iwj> sladen: I think I'd just have the same the problem as this package is trying to solve.
<soren> sladen: I'm not entirely sure what the semantics of XS-Python-Version: current is as opposed to XS-Python-Version: all..
<iwj> I think I understand now why it was done this way but I don't like it.
<iwj> From a security support POV static linking is really bad.
<siretart> iwj: I'd expect it to just work, though we'd need to test it first
<soren> sladen: If I belive my package will work with whatever is current, that's the same as saying "it should work with all of them", isn't it?
<iwj> siretart: No, if I make the change I have in mind it will break.
<siretart> iwj: the current plan is to redisign the integration of cryptsetup's initscripts
<iwj> But only if /usr is a separate encrypted filesystem.
<iwj> We're not redesigning anything at this stage, surely ?
<iwj> I'm hoping to fix this up well enough for it to go in main.
<siretart> no, not for gutsy. maybe for hardy
<cjwatson> redesign => not gutsy, I'd have thought
<iwj> Right.
<siretart> with 'redesign', I mean cryptsetup <-> udev integration
<iwj> siretart: So my question is: how many people have (a) separate /usr AND (b) cryptsetup AND (c) encrypted /usr ?
<siretart> it would involve crafting some kind of 'passphrase cryptsetup agent'
<iwj> siretart: I don't want to think about that right now :-).
<siretart> :)
<cjwatson> soren: XS-Python-Version: current => only include support for whatever the current version is, require trivial rebuild at some point when that changes; XS-Python-Version: all => include support for all currently supported versions
<soren> iwj: The issue is the same with an encrypted root filesystem, isn't it?
<iwj> soren: No, because the initramfs tools will automatically pick up all of the needed libraries.
<ion_> siretart: Someone should implement libwhat and what-UIs. ;-)
<siretart> I wouldn't expect many users having seperate crypted /usr. If we encounter it makes problems, we could easily prevent it in the installer
<siretart> we don't support conversion of filesystems to crypted anyway
<iwj> soren: (I think.  I mean, we ought to test that but I don't anticipate a problem.)
<cjwatson> soren: that's a summary, but http://wiki.debian.org/DebianPython/NewPolicy and search for XS-Python-Version
<soren> iwj: Oh, clever. Why doesn't this work with an encrypted /usr then? At initramfs generation time, it's not encrypted, I suspect?
<iwj> siretart: My worry is that if I just make this binary dynamically linked I will make those machines unbootable if they exist already.
<iwj> soren: At initramfs generation it's mounted.
<cjwatson> you could make the initramfs deal with mounting /usr too in that case ;-)
* cjwatson runs away
<iwj> cjwatson: That had occurred to me :-).
<soren> iwj: Yes, that's what I meant.
<siretart> iwj: there are already feisty users which managed to boot with crypted root without too much trouble, according to malone
<ogra> encrypted /usr ? :)
<iwj> siretart: No, no, listen to me very carefully.
<siretart> iwj: TBH, I don't really see the point of an crypted /usr
<iwj> The problem I plan to create is ONLY if /usr is separate AND it is encrypted.
<sladen> iwj: ignore the /usr issue.  think the encrypted / issue through
<iwj> If it's part of an encrypted /, it should be fine.
<iwj> sladen: Right.
<iwj> Good.
<soren> iwj: So.. When it's mounted, the initramfs tools will grab the libs and put them into the initramfs ?
<iwj> That's what I was hoping to hear.
<iwj> soren: Right.
<siretart> ah, right
<soren> iwj: And how do you intend to break this? :)
<iwj> soren: I don't.
<sladen> iwj: how did you mount it ?...
<soren> sladen: magic
<sladen> chicken.  egg.
<iwj> sladen: Well, if it was encrypted / then all is well because the last initramfs mounted it.
<asac> sabdfl: http://pastebin.mozilla.org/190473
<iwj> If it's separate encrypted /usr then you lose.
<iwj> ATM that works because cryptsetup is statically linked and doesn't need anything from /usr.
* sladen blinks.  maybe I missed something
<siretart> cryptsetup is statically linked? not on my machine..
<siretart> it doesn't link to anything in /usr, though
<iwj> siretart: It's partially statically linked.
<siretart> aah, and that's what you want to change
<siretart> right?
* beuno managed to have the whole encrypted system with: https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto
<iwj> siretart: Right.
<siretart> iwj: why?
<cjwatson> soren: the initramfs tools do that automatically assuming you use copy_exec
<cjwatson> iwj: (and so you could happily dynamically link the copy in the initramfs)
<soren> cjwatson: Right, got that. What I'm not getting is why this doesn't work if /usr is encrypted..
<iwj> siretart: Because static linking is EBW.  In particular, it makes security support a PITA.
<iwj> cjwatson: Right.
<cjwatson> soren: because the initramfs isn't responsible for mounting /usr; that's the one in /
<soren> cjwatson: Ah.
<cjwatson> iwj: though actually, that would only work if all the library packages triggered an initramfs update
<soren> Yes, of course.
<cjwatson> otherwise you would effectively need to upgrade cryptsetup or otherwise trigger update-initramfs anyway
<iwj> cjwatson: Uh ?  The initramfs is generated all in one go.
<siretart> iwj: I see. well, as said, I don't expect many (of any!) user to just encrypt /usr. And we can prevent them doing so by some magic in the installer(s)
<iwj> After you get the new cryptsetup, next time mkinitramfs runs it will pick up all of the new libraries.
<cjwatson> iwj: the security support problem is that if we upload say libgpg-error in a security update then the cryptsetup binary doesn't get updated automatically
<soren> iwj: How is this more secure than linking it statically?
<cjwatson> iwj: an upgrade containing only libgpg-error will not automatically run mkinitramfs
<iwj> siretart: I'm less worried about new installs.  After all, "new install with pathological configuration doesn't boot" is a lot less bad than "my existing install doesn't boot".
<cjwatson> iwj: thus it's essentially the same problem unless libgpg-error triggers an initramfs update
<iwj> cjwatson: I don't see the problem.  The old initramfs is still fine, surely.
<cjwatson> iwj: it's fine but it still contains the buggy libgpg-error
<asac> sabdfl: after doing that, you should see in the wpa supplicant shell that it successfully authenticates ... and a message in wpa_cli shell that you successfully associated
<iwj> soren: If (eg) there's a bug in libgpg-error, we don't want to have to rebuild cryptsetup (and fourteen other packages).
<cjwatson> the ideal situation is one in which uploading libgpg-error fixes up the initramfs too
<iwj> cjwatson: OIC.  We could issue the security fix for libgpg-error with a call to trigger initramfs generation.
<siretart> iwj: aah, now I understand what you are worrying about. well, we haven't cared much for this kind of users (installing random packages from universe) in the past
<soren> iwj: You argued that statically linked binaries were a security problem because we'd need to rebuild them to get security updates. If you still have the borken versions in the initramfs it doesn't help much, does it?
<cjwatson> my point exactly
<siretart> I hold network-manager in breezy I think as example
<cjwatson> but only necessary when cryptsetup is installed
<cjwatson> so it's a bit messy
<iwj> cjwatson:   if test -f ... yada
<iwj> Or cryptsetup could do it.
<asac> sabdfl: for instance i see http://pastebin.mozilla.org/190474 i wpa_cli shell
<iwj> interest /usr/lib/libgpg-error.so.0
<cjwatson> cryptsetup can only do it if it can be triggered by any of its dependent ... what you said
<iwj> and then on activation say  dpkg-trigger update-initramfs  :-)
<iwj> The whole initramfs arrangements are a bit shonky really.
<soren> iwj: I'm not entirely sure how your new dpkg trigger system works, but would it be possible for copy_exec to make a list of files that should trigger a new initramfs?
<iwj> soren: No.
<soren> winkle: ok
<soren> whoops
<iwj> Lists of trigger interests are supposed to be static.
<soren> iwj: ok
<Chipzz> soren: but that doesn't matter anyway, seriously
<cjwatson> one could generate a trigger interest list using ldd in cryptsetup's build process
<sladen> iwj: but the regeneration only needs to happen /if/ something causes libgpg-error to be copied into the initramfs.  Is it is the utility causing libgpg to be pulled in that should somehow mark the hook to update-initramfs;  whether that's possible with the current hooks, I don't know.
<soren> Chipzz: Why?
<cjwatson> it's really just shlibdeps on steroids
<Chipzz> having an outdated version in the initramfs would require your system to be unbootable to be exploitable
<Chipzz> because
<iwj> sladen: There's no machinery for that kind of thing right now.
<Chipzz> from the moment you pivot_root
<Chipzz> they're gone
<iwj> Chipzz: Very good point.
<cjwatson> assuming that there's no way to nobble the filesystem such that the version in the initramfs will do something crazy
<Chipzz> so in reality you got bigger problems (like a fscking *broken* system) to worry about than some *hypotethically* exploitable program
<soren> Chipzz: We don't pivot_root anymore, actually :)
<iwj> cjwatson: Yes, but our root mounting arrangements are already hopelessly weak against anyone who can introduce block devices with hostile contents.
<cjwatson> Chipzz: (pivot_root is dead, long live run-init)
<cjwatson> iwj: mm
<Chipzz> but the binaries are still gone, right?
<iwj> (Big bug that but no way am I going to try to have that battle against the entire universe.)
<cjwatson> Chipzz: my concern is really more that we end up with mystically broken systems whose bugs go away when you run update-initramfs
<soren> Chipzz: Yes, but your root file system is still mounted using them.
<iwj> So I think the conclusion is I can dynamically link this without trouble.
<cjwatson> due perhaps to bugs that aren't security holes
<sladen> we should replace UUID with PKI shared UUIDs
<Chipzz> soren: which does not matter since they can't be invoked by a user anyway
<iwj> sladen: Yay, openssl in the initramfs.
<Chipzz> the way they're invoked is very controlled and very limited
<cjwatson> Chipzz: cryptsetup may not suffer much from this but I have real bug reports that are examples of this problem so don't tell me it's not a problem
<sladen> as at the moment the / UUID is a shared secret that allows a race-condition for taking over boot :)
<Chipzz> cjwatson: there is a difference between "broken" and "exploitable"
<soren> Chipzz: You're making assumptions about not-yet-discovered vulnerabilites. :)
<cjwatson> Chipzz: I don't care. I'm talking purely about the initramfs updating arrangements which aren't sensitive to that distinction.
<cjwatson> logically the initramfs should be updated whenever the source of anything copied into it is changed
<iwj> sladen: Things are much worse if you use lvm.
<cjwatson> we do not at present have the ability to do that in all cases
<iwj> cjwatson: I think we need a dynamic trigger interests feature.
<cjwatson> cryptsetup's linkage stuff is just a special case of that
<Chipzz> btw
<cjwatson> iwj: tools to help build the trigger interests at package build time might help
<Chipzz> statically linking only pulls in the functions which are effectively used
<iwj> cjwatson: *shudder* but yes.
<cjwatson> iwj: like I say, shlibdeps ...
<Chipzz> so part of a lib may be broken/exploitable, and still not affect statically linked programs
<cjwatson> seems near enough the same thing :)
<Chipzz> cjwatson: care to point me to some bugreports? I'm actually interested in some of these cases ;)
<soren> Chipzz: "We're probably not vulnerable" is rarely a sensible approach to security.
<iwj> Chipzz: Also true but of course when the vuln in the lib is found the security guys have to go madly haring round trying to figure out what's vulnerable.
<Chipzz> not that I have enough knowledge to fix them, just curious
<cjwatson> Chipzz: comments near the end of bug 131961
<ubotu> Launchpad bug 131961 in busybox "Segfaults during boot (from mount)" [High,Fix released]  https://launchpad.net/bugs/131961
<cjwatson> unfortunately I forget exactly what broke when I tried to make busybox-initramfs call update-initramfs
<cjwatson> I think it was something to do with initramfs-tools not necessarily being configured yet since it depends on busybox-initramfs, so it might be able to go away with triggers
<Chipzz> soren: really, things like cryptsetup would only exercise certain codepaths of broken libs, and I figure in controlled ways
<Chipzz> and it's hard to replace those binaries with ones that would actually exploit the problem
<cjwatson> iwj: could I just have busybox-initramfs call 'dpkg-trigger --no-await update-initramfs' if dpkg-trigger is available?
<Chipzz> cjwatson: oh, heh, busybox... now *that* is an example of uncontrolable code paths ;)
<Chipzz> by it's very nature even :)
<iwj> cjwatson: Yes.
<Chipzz> cjwatson: one could argue about the sanity of the way busybox is written I guess ;)
<iwj> Anyway, I'm off to catch my train to go climbing now.  If anyone has any more to add feel free, and I'll catch up on the log tomorrow.
<bryce> Riddell, 132405 - xterm sync - you may have already sync'd it.  It looks extremely minor to me, having only two bug fixes neither of which seem terribly critical.
<Riddell> bryce: ok
<iwj> TTFN all.
<bryce> Riddell, btw fyi, I have been organizing the backport fixes from xserver 1.3.99 to our 1.3.0 here:  https://wiki.ubuntu.com/X/Fixes_to_Backport
<sabdfl> asac: i have to head to the "other office" in 10
<sabdfl> can we have a stab at NM now?
<asac> sabdfl: what do you mean by "stab" ?
<sabdfl> well. you tell me what to type. i type it and tell you what i see ;-)
<asac> sabdfl: i posted above?
<sabdfl> right now i've switched to "manual config" and it works fine
<sabdfl> ah
<asac> yes ... what is important that we see that wpa_cli works the way i posted
<asac> sabdfl: if the wpa_cli doesn't receive the associated events, then network-manager doesn't see them and doesn't try to get an ip
<pkern> "Is the system clock set to UTC?" is a bogus question in the installer when the current system clock content is now shown to the user... *cough*
<pkern> s/now/not/
<ogra> pkern, thats onyl done by d-i
<ogra> *only
<ogra> ubiquity doesnt asjk that question anymore
<pkern> ogra: Correct, I am currently trying to install a minimal gutsy tribe...
<ogra> ah
<soren> pkern: https://bugs.launchpad.net/ubuntu/+source/clock-setup/+bug/68861
<ubotu> Launchpad bug 68861 in clock-setup "edgy text mode installer: show the current time when asking about system clock being in utc" [Wishlist,Confirmed] 
<cjwatson> ogra: (which is in itself a bug)
<pkern> soren: Thanks.
<ogra> cjwatson, indeed...
<cjwatson> clock-setup has NTP support in d-i trunk so I'm hoping this will get a lot better for networked users in hardy
<cjwatson> Riddell: do you know whether KDE uses pmi to decide whether to offer suspend/hibernate?
<Riddell> cjwatson: it uses HAL
* Hobbsee finally heads to bed.
<Riddell> although power manager may fall back to some other method if HAL isn't running
<mjg59> Riddell: HAL will always claim that suspend and hibernated are supported with our kernels
<Riddell> mjg59: why?
<cjwatson> mjg59: would there be a problem with making it use pmi?
<mjg59> Riddell: Because hal just tests whether the kernel provides the functionality, not whether any sort of policy forbids it
<cjwatson> mjg59: in this crazy loop-mount-from-NTFS case it would be really useful to be able to nobble pmi to say that suspend and hibernate aren't supported
<mjg59> cjwatson: Doubt it, but I'm not familiar with the code
<cjwatson> I thought policy was allowed in hal
<mjg59> cjwatson: It's allowed, but nothing does it
<cjwatson> mjg59: would there be another place where pmi integration would be better?
<mjg59> On boot we could probably check the status with pmi or whatever, and then set the keys in hal
<Riddell> mjg59: so does gnome-power-manager use pmi to check if it's available?
<cjwatson> Riddell: not any more
<mjg59> I've no clue. I really haven't checked this code lately.
<cjwatson> mjg59: we can't just call it each time it's queried?
<cjwatson> Riddell: ogra took that out in the gutsy cycle
<mjg59> cjwatson: No
<cjwatson> blast
<mjg59> hal is a status repository
<mjg59> It updates information as events happen, it doesn't generate the data on request
<cjwatson> hmm, hal queries something called /usr/bin/pm-is-supported already, which we don't have
<cjwatson> oh, yes we do, it's in pm-utils in universe
<cjwatson> hmm. so that looks much better than what we have but it does all kinds of stuff and I don't fancy making the call myself
<cjwatson> I think I'll just patch hal to ask pmi if pm-is-supported isn't there
<mjg59> I was looking at moving over from acpi-support to pm-utils
<mjg59> But mdz thought we were too close to FF at the time
<cjwatson> yeah
<ion_> pm-is-supported seems to give the expected results on my hardware. Would be nice to have HAL query it by default.
<cjwatson> ion_: it already does.
<cjwatson> ion_: but we don't install pm-is-supported by default so I'm going to make it use pmi as a fallback, which we do install by default.
<cjwatson> (for now)
<ion_> I meant having HAL query it by default in the default installation, that is having it installed alongside HAL by default. :-)
<ion_> Alright
<mjg59> ion_: We can't.
<mjg59> pm-utils would break a lot of stuff right now.
<ion_> Ok
<calc> mjg59: any news about the amd64 vbetool?
<mjg59> calc: Nope. Your bug is still weird.
<calc> mjg59: ok heh
<mjg59> I'll probably get some work done on it during XDS
<cjwatson> mjg59: aside from being obvious clone-and-hack, does http://people.ubuntu.com/~cjwatson/tmp/90_pmi.patch look vaguely reasonable?
<cjwatson> I haven't tried it yet ...
<mjg59> cjwatson: Yeah, looks basically sane
<ion_> Interestingly, pmi says my hardware supports suspend and hibernate, pm-utils say it only supports hibernate. Suspend doesnt work on my computer, but i havent investigated the reason  it might simply be the nvidia proprietary driver.
<cjwatson> I'll leave a changelog note saying it can go away once pm-utils is in place
<mjg59> Should bcm43xx-fwcutter be promoted?
<mjg59> Given that restricted-manager bails with a weird error otherwise
<cjwatson> it's kind of crazy and relies on URLs which keeps  changing
<cjwatson> s/s  / /
<cjwatson> but nothing else provides the same functionality
<mjg59> cjwatson: In that case, it might be better to leave it out of r-m?
<calc> could it request a url which redirects to the current one?
<mjg59> calc: Awkward copyright issues
<cjwatson> I think (a) it probably ought to be promoted to restricted (b) r-m should cope with it being absent
<mjg59> cjwatson: It copes to the extent of "The software source for the package is not enabled"
<mjg59> Which makes sense to me, but probably not to most :)
<calc> mjg59: hmm then download a file that it parses which contains the current url to the files, that would get around the linking issue (maybe?)
<mjg59> It'd also be nice if it warned that it needed network access
<elmo> hmm, I have a crash report on the live cd
<kagou> \o/ sz
<zasf> mjg59: i did the hack wich prompts "The software source for the package is not enabled"
<zasf> I understand it is meaningless to the most
<zasf> but you can't know wich repo belongs to if you that repo is not enabled
<zasf> I wonder how command-not-found behaves if user tries to execute a command
<zasf> for wich needed repo is not enabled
<pygi> easy :P
<pygi> it tells you to enable the repo :p
<zasf> hehe but wich one?
<pygi> well, depending on the app you're trying to execute?
<zasf> :P
<pygi> it has it's data source, you know =)
<zasf> ah, ok :)
<Lamego> /usr/share/command-not-found/programs.d/
<zasf> isn't repositories data duplicated?
<pygi> now I'll do ":P" :P
<zasf> so r-m could be smart enough to read that dir
<zasf> find out wich repo is needed and prompt "why don't you open 'software sources' and enable XX repo"?
<Lamego> couldn't it be even smarter ? "Do you want to enable the repository XPTO containing this software?"
<mjg59> Though it would also be nice if it pointed out that you'll need network access
<mjg59> Right now it says "Enable firmware", not "Download and enable firmware"
<milian> is k3b currently not working?
<zasf> mjg59: that's because bcm43xx-fwcutter is not in main
<cjwatson> zasf: (main or restricted)
<milian> i.e. is this known: :-[ WRITE@LBA=10h failed with SK=5h/ASC=21h/ACQ=02h] : Invalid argument
<milian> :-( write failed: Invalid argument
<milian> or should I file a bug report?
<zasf> if user has no other internet access rather than wireless.. he has no chance
<mjg59> zasf: No, it *needs* network access - there's no other way for it to get the firmware
<zasf> mjg59: he can also cut it from local (win partition or driver cd)
<mjg59> zasf: Not through restricted-manager
<mjg59> Or can they?
<zasf> mjg59: they can
<mjg59> zasf: restricted-manager will search their hard drive?
<zasf> no
<zasf> user can point where fw is
<zasf> trough a 'browse' button
<mjg59> Ok
<mjg59> cjwatson: In that case, fwcutter probably ought to be in ship
<ogra> zasf, where would that browse button be ? i dont see it here
* ogra has a brooadcom card he doesnt use so no driver installed ....
<zasf> i'll upload a screenshot shortly
<ogra> and no option to select any location for anything here
<pkern> mkinitramfs takes forever on qemu proper *cough*
<ogra> oh, you are talking about a future version ?
<zasf> gutsy's version
<ogra> zasf, using that here
<ion_> pkern: It takes forever on real hardware. :-)
<ogra> checking the broadcom firmware checkbox only gives me a dialog asking if i want to enable it ... then it pops up gdebi and installs fwcutter
<pkern> ion_: Hm... well I devote a core to that qemu emulation. But then I guess it took forever the last time, too, so probably I just need to wait another half an hour...
<zasf> kate.homeunix.net/~matteo/Screenshot-restricted-manager.png
<ogra> zasf, and how do i get to that window ?
<ogra> oh !
<zasf> ogra: enable fw..
<ogra> it comes *after* gdebi ran
<ogra> and after the gdebi win was closed ...
<zasf> what did you use gdebi for?
<ogra> i didnt, r-m calls it to install fwcutter
<zasf> k
<ogra> which i didnt have
<zasf> it calls synaptic
<ogra> well, similar ui :)
<zasf> :) yes
<zasf> there are still problems (LP #135000), but it works
<ubotu> Launchpad bug 135000 in restricted-manager "unresponsive at broadcom firmware installation" [Undecided,In progress]  https://launchpad.net/bugs/135000
<ogra> well, fwcutter should definately get seeded (even installed by default imho) to avoid the synaptic stuff ...
<sbalneav> ogra: Did you update nbd-client, or nbd-server?
<ogra> sbalneav, ? its the same source ?
<ogra> i just applied your patch
<zasf> mjg59 ogra pygi Lamego: thanks for your suggestions, I'll see if I can improve r-m a bit
<zasf> I gotta go now, see you later
<ogra> and checked that the manpage ended up in my testbuilt binary
<sbalneav> right, same source, but two different packages, it splits into nbd-client, and nbd-server.
<sbalneav> the patch was for nbd-server
<ogra> yeah
<ogra> ogra@laptop:~/packages/nbd-2.9.6$ dpkg -c /var/cache/pbuilder/result/nbd-server_2.9.6-1ubuntu3_i386.deb |grep man|grep gz
<ogra> -rw-r--r-- root/root      4010 2007-08-29 17:41 ./usr/share/man/man5/nbd-server.5.gz
<ogra> -rw-r--r-- root/root      2824 2007-08-29 17:41 ./usr/share/man/man1/nbd-server.1.gz
<sbalneav> ah, ok
<ogra> all fine here
<sbalneav> I just saw an update for nbd-client come down.
<sbalneav> server hasn't updated yet, I guess
<ogra> yeah, as i said, same source package
<sbalneav> oh, wait, no, mine wouldn't :)
<ogra> both should be updated at the same time
<sbalneav> I've GOT the new one installed :)
<sbalneav> durrrr
<ogra> right, you have the patch in your binary already :)
<calc> iwj: got another MIR for you if you have time... libwpg :)
* ogra vanishes for another hour
<pkern> ion_: Hm, there are currently two mkinitramfs currently concurrently.
<pkern> ion_: http://durotan.0x539.de/~pkern/two-mkinitramfs.png
<dilomo> hi
<pkern> Is Ubuntu's boot prompt *after the installation* graphical (i.e. is a pixmap used in grub)?
<LaserJock> pkern: after installation of what?
<pkern> LaserJock: Gutsy Tribe fwiw
<LaserJock> no, I don't believe so
<pkern> LaserJock: Fine, thanks.
<LaserJock> the idea is to keep grub as out of the way as possible
<LaserJock> that's why the menu isn't show by default
<pkern> LaserJock: Ah, nice.
<LaserJock> I mentored a Google Summer of Code student working on a grub config gui
<dilomo> and what is the progress bar like?
<LaserJock> perhaps when that gets integrated then it'll be easier to do
<pkern> Yep, no graphics... yay.
<_MMA_> I have GIMP crashing on 2 machines if I resize a image. Should I post this as a bug? http://paste.ubuntu-nl.org/35583
<ion_> mma: Try running G_SLICE=always-malloc gimp. Ive had some crashing problems with it and that seems to be a workaround. I havent got around to investigating and reporting the problem yet.
<LaserJock> I was doing some research last night and gnumeric wouldn't start up at all
<LaserJock> fun crazy gutsy gibbon
<_MMA_> ion_: Yeah. Thats works. :( Shame though.
<ion_> mma: If you report it, please mention the bug ID to me, ill subscribe to it.
<ion_> (Perhaps its reported already, i havent even checked that.)
<_MMA_> ion_: Ok Well best I can do is post the pastebin. Is that fine for now?
<ion_> mma: Its probably easiest to post a bug report with apport.
* _MMA_ is unsure how to use apport. :(
<_MMA_> ion_: Bug 135650
<ubotu> Launchpad bug 135650 in gimp "GIMP crashes when trying to resize an image." [Undecided,New]  https://launchpad.net/bugs/135650
<ion_> Thanks
<_MMA_> np
<Mithrandir> hm, anybody know what runs the stuff in /etc/xdg/autostart when the session starts?
<ion_> xfce4-session :-)
<jwendell> Mithrandir, gnome-session ?
<ion_> In gnome, probably gnome-session.
<Mithrandir> well, whenyou're not using xfce4-session or gnome-session?
<Mithrandir> like, when  you're using startx and just a window manager.
<ogra> is it started then ?
* ogra wouldnt expect that
<Mithrandir> hm, is there a tool to "execute" .desktop files, then?
<ion_> mithrandir: xdg-open
<LaserJock> that works on .desktops?
<ion_> Seems to.
<Mithrandir> ion_: ah, thanks a lot, I'll try that.
<ogra> well, doesnt that need an url ?
<ion_> ogra: It accepts plain file paths as well.
<alex-weej> cohoba is unmaintained upstream and has died a death. what's the procedure for dropping support for it in Ubuntu?
<dholbach> alex-weej: file a bug report, subscribe 'ubuntu-archive' to it
<alex-weej> ok
<ion_> Is it just me, or has it already been removed from the archive?
<Mithrandir> ion_: except it didn't work.
<ion_> mithrandir: Strange. Here it works.
<Mithrandir> can you look in your mailcap file and see if there's anything referencing it?
<Mithrandir> even on my desktop, it just opens it in a text editor.
<Mithrandir> that's hardly useful. :-P
<ion_> mithrandir: Ah, xdg-open uses open_xfce(), which calls exo-open, which DTRT with .desktop files.
<ion_> mithrandir: If youre running gnome, it does something else.
<Mithrandir> ah, ok.
<Mithrandir> so there might not be any utility which DTRT with .desktop files
<ogra> Mithrandir, proably in the xdg-utils package
<ion_> mvo: I noticed a way to detect an Xfce environment from xdg-opens code: xprop -root _DT_SAVE_MODE | grep ' = "xfce4"$' >/dev/null 2>&1
<ion_> mvo: Perhaps thats helpful with the compiz launcher.
<ion_> They could just use xprop -root _DT_SAVE_MODE | grep -q ' = "xfce4"$' though :-)
<alex-weej> Amaranth: yo
<alex-weej> https://bugs.launchpad.net/bugs/91783
<ubotu> Launchpad bug 91783 in compiz "Compiz's default Human-glass look does not "work" visually" [Wishlist,New] 
<Amaranth> dude
<Amaranth> haven't we gone over this before?
<sladen> BenC: did CONFIG_BLK_DEV_IO_TRACE get dropped at some point?
<BenC> sladen: Not that I'm aware of
<sladen> BenC: I was wondering why I couldn't blktrace;  one mention I found was that it worked <feisty
<sladen> oh there's a bug #118303  open
<ubotu> Launchpad bug 118303 in linux-source-2.6.22 "CONFIG_BLK_DEV_IO_TRACE is not enabled preventing blktrace from working" [Unknown,Fix committed]  https://launchpad.net/bugs/118303
* sladen slow claps ubotu 
<BenC> sladen: it should be fixed in gutsy
<BenC> wont be in feisty
<alex-weej> Amaranth: i was just giving you the bug ID...
<sladen> BenC: the "Fix Commited" is for the Debian BTS report, not the Ubuntu one;  is it also now fixed in Gutsy?
<BenC> sladen: doesn't appear so
<geser> doko: have you time to look at the gnupginterface debdiff in bug #36733?
<ubotu> Launchpad bug 36733 in adonthell "package includes *.py[co]  files" [Medium,Confirmed]  https://launchpad.net/bugs/36733
<doko> geser: well, that should be triaval, could you have a look yourself?
<geser> doko: I provided it, I need now a main sponsor for it
<BenC> sladen: enabled and pushed for next upload
<sladen> BenC: woo, thank you
<superm1> infinity, cprov it would appear that promethium (xen-amd64) is freezing again on the same build: https://launchpad.net/+builds/promethium
<doko> geser: uploaded
<geser> doko: thanks
<cprov> superm1: garr ...
<superm1> cprov, don't worry about sorting it out right now, you guys have more pressing issues to get the launch going :)
<cprov> superm1: I let it stuck so infinity can debug the problem (he should show up soon)
<superm1> okay sounds good
<bigon> Is there any way to get the ubuntu developer keyring?
#ubuntu-devel 2007-08-30
<mneptok> have to learn to live. reach into the light. changing all the time.
<TomaszD> Hi. I'm looking for Michael Vogt or someone responsible for displayconfig-gtk
<TomaszD> I was wondering why isn't a translation template available for this application
<Kmos> talk to mvo
<TomaszD> mvo, if you are responsible for displayconfig-gtk, why isn't there a translation template available?
<TomaszD> is a translation still considered a moving target?
<mvo> TomaszD: let me have a look
<TomaszD> mvo, sure. It's just that it stands out terribly among other, translated modules in the menu
<TomaszD> and it's an essential part of the system now, so it should be available for translation, I guess
<mvo> TomaszD: its missing from launchpad (the translation template)?
<TomaszD> mvo, https://translations.launchpad.net/~displayconfig-gtk/
<TomaszD> it's not there or am I looking in the wrong place?
<beuno> TomaszD: it's the wrong URL, but it still seems not to have translations: https://launchpad.net/displayconfig-gtk/
<mvo> it looks like some missing magic in the debian/rules file
* mvo goes to fix it
<TomaszD> ah, I see. "Translation setup needed"
<TomaszD> mvo, thank you! I'll be going now, it's 1AM...
<mvo> TomaszD: yeah, for me too
<alex-weej> doko: you up?
<ion_> An entertaining talk about version control systems (with emphasis on git, obviously) from Linus Torvalds: http://youtube.com/watch?v=4XpnKHJAok8 (http://ash-v131.ash.youtube.com/get_video?video_id=4XpnKHJAok8). Not exactly on-topic, sorry for that.
<realist> Is that a link to his google talk?
<ion_> Yes.
<realist> Way off topic - way old news :-)
<realist> Still a good presentation though!
<realist> Especially where he ridicules code.google, and svn - knowing that the developers for both are in the audience
<Toadstool> nice any call to hwclock on my tx1215nr makes the system freeze with "/dev/rtc does not have interrupt functions. Waiting in loop for time to change in /dev/rtc." :/
* Hobbsee waves
<RAOF> It's hobbseemaster flash!
* Hobbsee twirls around in a puff of smoke
<Hobbsee> RAOF: coming to slug tomorrow?
* RAOF checks his schedule...
<RAOF> Awesome.  What an excellent conjunction.  SpockSoc's playing _Invasion_ which was crap :)
<RAOF> You may well see me there :)
<Hobbsee> haha
* Hobbsee pokes TheMuso_
<RAOF> Oooh, lifeless is talking.  Cool.
<Hobbsee> nice
<highvoltage> RAOF: where is that?
<RAOF> highvoltage: http://maps.google.com.au/maps?f=q&hl=en&q=173-185+Sussex+Street,+Sydney+NSW+2000
<RAOF> High-performance python!
<moyogo> hi, anybody in charge of xkeyboard-config around?
<Hobbsee> probably a little aerly for that
<moyogo> ok :-)
<Hobbsee> good morning seb128, fabbione
<seb128> hey Hobbsee
<fabbione> morning
<seb128> hi fabbione
<seb128> Hobbsee: do we have a list of bugs nominated for gutsy and waiting to be approved or not somewhere?
<Hobbsee> seb128: um, there would be a list somewhere yes, but like i siad on that bugmail, we really dont use it
<Hobbsee> we tend to only use it a little for tribes - but choose to use the milestone stuff instead
<seb128> what bugmail?
<seb128> what tribe?
<seb128> maybe my question was not clear ;)
<seb128> you know, you can nominate a task for gutsy
<seb128> and then it's listed with an approve or decline option
<seb128> re Hobbsee
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<Riddell> RAOF: what standard does KDE not follow?
<RAOF> Viewports, IIRC.
<RAOF> Making the KDE workspace switcher get freaked out under Compiz
<Kmos> can someone have a look at bug 129572
<ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/129572
<Hobbsee> Kmos: is it urgent?
<Kmos> Hobbsee: ups, it's already acked 2 times
<Kmos> Hobbsee: no
<Hobbsee> Kmos: and why would the general motu-uvf people be here?
<Hobbsee> Kmos: i thought seb128 told you about bringing up bugs that were not urgent, but that were $yourpetbugs.
<Kmos> Hobbsee: because you don't check my bugs? and jono told me to ask anything I want here
<Hobbsee> Kmos: i do, occasionally.
<Hobbsee> i prefer not to, but i do regardless.
<Kmos> Hobbsee: i just want to finish these ones, because I won't file syncs anymore.
<Hobbsee> they will be finished. just be patient, and accept that people have other things to do too.
<Kmos> Hobbsee: yeah, like me now.. need to go, and getdeb will have more updates today.
<Hobbsee> cool
<seb128> Kmos: ubuntu-archive has been subscribed less than 1 day ago, you need a little patience ;)
<Kmos> seb128: I see that 1 minute ago, sorry.. i just need to wait now
<seb128> right
<doko> iwj: please could you review the MIRs for drac and libwpg?
<Kopfgeldjaeger> hi
<ogra> doko, if you rebuild mknbi, you might want mkelfimage as well
<ogra> (even though i suspect there are not many netbooting lpia machines with LinuxBIOS yet :) )
<doko> ogra: already built for lpia
<ogra> oh, ok
<ogra> i just saw the mknbi one, sorry
<iwj> doko: Sure.
<iwj> (Morning)
<doko> iwj: thanks, I asked tkamppeter to to write one for cupsddk (b-d of splix) as well
<doko> seb128: who's usually doing the Gtk Perl stuff?
<wolfe> input hot plugging!
<wolfe> hell has froze over!
<wolfe> I can't wait for Version 1.4 of the X server :) maybe I'll just built it myself
<TomaszD> glatzor_, hey I noticed you're also responsible for displayconfig-gtk. I told mvo yesterday that there's no translation template in rosetta available and he said he'll fix it but nothing changed in Rosetta, so I'm thinking that maybe he forgot and you could do this, there seems to be some missing debian/rules magic missing. The webpage is https://translations.launchpad.net/displayconfig-gtk/
<TomaszD> *-missing
<TomaszD> :] 
<glatzor_> TomaszD: thanks. we just need to upload it.
<TomaszD> glatzor_, ok, ETA on this? This is quite urgent you know :] 
<glatzor_> TomaszD: perhaps tomorrow. I want to fix some bugs before.
<TomaszD> glatzor, alright. Thanks.
<TomaszD> just keep in on the radar please, this isn't a thing to forget ;] 
<glatzor> TomaszD: you don't need to be afraid of this
<glatzor> TomaszD: if you want to keep track of this issue subscribe to LP #134576
<TomaszD> glatzor, great tip, thanks
<Riddell> seb128: upstream says there's a fix to the gtk API change, do you know where I could find it? http://bugzilla.gnome.org/show_bug.cgi?id=463773#c10
<TomaszD> subscribed
<seb128> doko: nobody
<seb128> Riddell: there is no gtk API breakage
<seb128> Riddell: it's just making issues with incorrect usage where it was not
<seb128> it's on my list of things to look at though
<Riddell> ok, there's a fix to the change which makes flash and acroread break :)
<seb128> that's not upstream
<seb128> I think this guy is working for some non major distro
<seb128> or bsd or something
<Riddell> anyway, if you help me find that patch I can test it
<seb128> dunno what he patched and where
<jdstrand> hi infinity
<jdstrand> in the ubuntu-server meeting the other day, they suggested I issue a bug report for the LAMP test page
<seb128> Riddell: well the comment is clear enough, how do one trigger the bug? I can test a change if I know how to test
<jdstrand> if you haven't seen it yet, it is bug #135624
<Riddell> seb128: testcase is here https://bugzilla.novell.com/show_bug.cgi?id=294385#c55
<jdstrand> bug 135624
<ubotu> Launchpad bug 135624 in php5 "should provide LAMP test page" [Low,Triaged]  https://launchpad.net/bugs/135624
<ubotu> Novell bug 294385 in GNOME "glib2 busyloops, blocking Konqueror and Opera on flash sites" [Blocker,Assigned] 
<seb128> Riddell: have you seen http://people.mandriva.com/~boiko/patches/kdebase-3.5.7-fix_flashplayer_nsplugin.patch ?
<Riddell> seb128: yes, but adding a dependency from kde to gtk is an ugly ugly workaround
<saispo> lol seb128 :)
<seb128> hi saispo
<seb128> saispo: why "lol"?
<saispo> hi ;)
<saispo> you use mandriva patches ? :p
<Riddell> we use patches from wherever they come from, if they fix problems
<seb128> Riddell: the comment you pointed shows that libflashplayer is buggy, it doesn't give a way to trigger the bug
<seb128> saispo: why not? ;) In fact I don't, GNOME works fine, I suggest a workaround for kubuntu
<saispo> seb128: yes i see :)
<moyogo> anybody in charge of xkeyboard-config around?
<Riddell> seb128: novell 294385#c55?  it has test code in it to recreate the issue (regardless of who's fault the issue is)
<ubotu> Novell bug 294385 in GNOME "glib2 busyloops, blocking Konqueror and Opera on flash sites" [Blocker,Assigned]  https://bugzilla.novell.com/show_bug.cgi?id=294385
<seb128> Riddell: right, I was being lazy and wondering if that happens with real world applications in Ubuntu
<moyogo> it would be nice to have the latest xkb-data to have the new keyboard layouts in gusty
<seb128> like something I can install, run, notice it's buggy
<Riddell> seb128: well yes, flash in non gtk browsers and acroread
<moyogo> like gn which allows to type Nko for example
<moyogo> that would help localizers to work with gusty
<cjwatson> moyogo: I'll have a look in a bit - on the phone now
<moyogo> thanks
<cjwatson> (I don't do xkeyboard-config as such but I do console-setup which is related)
<seb128> bah
<seb128> "expr: syntax error" when running acroread
<seb128> Riddell: acroread is not the same issue and will not be fixed by this change
<seb128> they access to GTK+ internal structure in a non documented way
<seb128> and bad luck for them there is no stability guaranty for those
<Riddell> seb128: ok, try opera or konqueror with flash then
<seb128> and the tooltip API has been deprecated and replaced by a new one
<seb128> k, will do that
<moyogo> ArneGoetje: ping
<doko> iwj: cupssdk MIR is now available as well
* iwj looks.
<iwj> Uh, Apple's CUPS is GPLv2-only ?
<iwj> doko: Also approved.
<iwj> I like these nice simple packages.
<doko> iwj: do you want something more demanding, including license review?
<iwj> Perhaps.  What would I be letting myself in for ? :-)
<cjwatson> licence review is an archive admin function, surely
<cjwatson> it shouldn't be in universe if its licence isn't free
<iwj> cjwatson: That was my understanding.
<iwj> I've certainly not really been looking at licensing.  (My comment above was an aside, prompted by happening to stumble across a GPLv2 notice.)
<cjwatson> not to say it isn't worth sanity-checking, but I don't think it's worth spending lots of time on deciphering legalese at the MIR stage ...
<cjwatson> (some "free" licences have obviously had rather too many lawyers involved.)
<doko> iwj: icedtea
<iwj> OMG
<Riddell> seb128: gtk compile errors "/home/jr/src/gtk/gtk+2.0-2.11.6/modules/printbackends/cups/gtkcupsutils.c:638: error: dereferencing pointer to incomplete type"
<manchicken> Anybody know who may be able to fix network-manager issues?  I'm having a heck of a time with bug #93360.
<ubotu> Launchpad bug 93360 in dhcdbd "Dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason" [Undecided,Confirmed]  https://launchpad.net/bugs/93360
<thom> manchicken: asac
<asac> manchicken: what wifi chipset?
<Treenaks> Also, anybody around to look at bug 119266? I haven't had out-of-the-box sound since I upgraded this box to gutsy
<ubotu> Launchpad bug 119266 in linux-source-2.6.22 "Intel HDA Sound device doesn't work in gutsy" [Low,Fix committed]  https://launchpad.net/bugs/119266
<jwendell> Treenaks, it works now, since last linux-ubuntu-modules
<Treenaks> jwendell: oh, I see the reboot icon now..
* ogra curses debconf ...
<ogra> cjwatson, i'm trying to rework my udeb scripts for ltsp http://paste.ubuntu-nl.org/35650/ results in a ot of text output "... return: ... Illegal number" in the debconf screen, do you have any hints why that happens or where it comes from ?
<cjwatson> ogra: sounds like your debconf communication has got out of sync
<cjwatson> or something else is interfering with stdio
<ogra> oh, ok
<cjwatson> I'm prepared to bet large sums of money it's not debconf's fault
<ogra> surely my fault :)
<cjwatson> I'm on the phone but I see one problem
<cjwatson> will let you know in a bit
<JanDM_> hi, since alsa 1.0.14 I had a problem with my sound card. So I asked on alsa-devel, and they created a patch,
<JanDM_> but this patch is not included in ubuntus current alsa version
<JanDM_> so i have to compile alsa myself with every kernel update,
<JanDM_> can I ask to include it somewhere?
<ogra> JanDM_, i guess best is to discuss that in #ubuntu-kernel
<JanDM_> okay, thank you!
<ogra> (not sure though, depends if its for a module)
<JanDM_> ogra: yes it's a kernel module
<ogra> then -kernel should be right
<cjwatson> ogra: ok, your problem is probably that 'cat $FIFO | while read line' uses stdio, which is getting in the way of using debconf
<ogra> oh, ok
<cjwatson> ogra: I encountered this same problem in the past in archive-copier
<cjwatson> ogra: what you should do instead is:
<ogra> so i need to redirect that as well
<cjwatson> while read line <&9; do ...; done 9<$FIFO
<ogra> ah, right
<cjwatson> ogra: also why is it all within 'while true'? you should probably remove that otherwise it'll just sit in an infinite loop - the 'while read line' is good enough as a loop
<ogra> yeah, thats for playing
<cjwatson> ogra: you also might want to put 'rm $FIFO' before 'exit 0' ;-)
<ogra> i had that in two scripts initially, echoing stuff to the fifo :)
<ogra> yeap, what i have here locally evolved already a bit :)
<ScottK> Mithrandir: If you have a minute to look into a licensing question, I've consulted a couple of other MOTUs and were are unsure if http://revu.tauware.de/details.py?upid=139 would be suitable for multiverse or not.  Technically the package is ~OK, so I wanted to get a read on if it could be accepted in the archive before I pushed on the packager to fix it up some more.
<Riddell> "It is NOT PERMITTED to distribute ANY OF THESE FILES for commercial (or profit) purposes." I think that's ok for multiverse, although elmo will know for sure
<ogra> cjwatson, works (outside of d-i at least) thanks a lot :)
<cjwatson> ogra: you're welcome
<ScottK> Riddell: Thanks.
<elmo> Riddell: that's ok for multiverse, assuming permission for non-{commercial,profit} purposes is granted
<ScottK> elmo: That's, I think, the real question.
<ScottK> If it says you can't distribute for commerical purposes, can one infer permission to do it for non-commercial?
<elmo> ScottK: no
<ScottK> elmo: Thanks.
<StevenK> Could someone wave the magic stick at zziplib's sparc build and raise it's priority? I'd like to see if it builds so it can rescued from NEW.
<Mithrandir> ScottK: I'll take a look
<ScottK> Mithrandir: elmo said he thought not, but a second opinion would be useful.  Thanks.
<ogra> cjwatson, i assume archive-copier doesnt chroot into a sub-chroot in /target .... seems it doesnt work for me as soon as ltsp-build-client starts to run stuff inide the chroot
<ogra> *inside
<cjwatson> ogra: that's irrelevant to debconf
<cjwatson> probably a red herring
<cjwatson> perhaps you lost stdout somewhere else
<ogra> well... somehow the chrooted commands end up on the debconf screen again
<ogra> yeah
<cjwatson> debconf couldn't care less whether you've chrooted
<ogra> obviously ...
<cjwatson> we do it all the time
<cjwatson> all you need to do is send commands down the right fd
<lamont> seb128: gnome-power-manager still hates some architectures:
<lamont> gpm-profile.c:342: warning: cast increases required alignment of targgpm-profile.c:342: warning: cast increases required alignment of target typeet type
<lamont> gpm-profile.c:342: warning: cast increases required alignment of target type
<lamont> stupid mouse
<cjwatson> from the code you showed me earlier, it would in fact be unable to tell whether ltsp-build-client is chrooting itself or not
<ogra> cjwatson, right, that means ltsp-build-client needs internal redirects ...
<cjwatson> err
<cjwatson> surely absence of internal redirects
<cjwatson> if you don't redirect, fds get left alone
<cjwatson> basic Unix
<ogra> right, and the chrooted commands use stdout it seems ...
<ogra> instead of my redirect
<cjwatson> so? it's the same stdout that you redirected to the fifo
<cjwatson> no
<cjwatson> that is not possible
<ogra> hmm
<cjwatson> "stdout" is just an fd
<cjwatson> when you redirect, you *throw away* the old fd
<cjwatson> ltsp-build-client doesn't have it
<ogra> /usr/share/debconf/confmodule: line 42: 3: Bad file descriptor
<ogra> thats what i got now
<ogra> after it extracted templates for apt from the CD#
<doko> go thunderbird!
<cjwatson> does ltsp-build-client talk to debconf anywhere?
<cjwatson> oh, it's installing packages, isn't it?
<ogra> indeed
<ogra> andits setting the frontend iirc
<cjwatson> so you cannot do this whole scheme
* ogra greps
<cjwatson> it will be a race condition
<cjwatson> you can't run ltsp-build-client in the background and simultaneously talk to debconf from somewhere else
<ogra> hmm
<cjwatson> ltsp-build-client needs to handle the debconf interaction itself, and it probably needs to use in-target to chroot
<cjwatson> which will deal with the debconf passthrough gubbins you need
<ogra> no, i dont have in-target in normal installs, wont work
<cjwatson> check whether it's there then
<ogra> phew ... thats a lot of plugins to change then
* ogra looks through them
<cjwatson> that's probably not the right approach
<cjwatson> pick apart in-target and do its chroot setup stuff at the top level if you're being called in a context with a debconf frontend already running
<ogra> ok
* ogra goes to dig
<mjg59> http://www.ubuntu.com/getubuntu/download - the language on the second option "64 bit AMD and Intel computers" seems potentially confusing
<cjwatson> and, on the same condition, have ltsp-build-client source the confmodule and do the progress output itself
<mjg59> Someone just told me they interpreted it as (64 bit AMD) and Intel computers
<cjwatson> mjg59: I think there's an ubuntu-website project for bug reports on that
<mjg59> Cool.
<Riddell> ogra: I had to sync the usplash-theme-ubuntu.c in kubuntu usplash with ubuntu to fix verify CD, edubuntu may need the same
<ogra> Riddell, thanks fo rteh hint
<bddebian> Heya
<jwendell> seb128, around?
<iwj> This is quite tedious.  My shiny disk-full logging libc doesn't seem to be very happy.
<bddebian> Is the archive closed off for NEW already or not?
* ScottK would guess that as long as it's 30 AUG somewhere, it's OK.
<bddebian> ScottK: Cool, help me fix up sdlmame then ;-P
<ScottK> Sorry, trying to do $WORK right now.
<bddebian> pfft, work, schmurk :-)
<alex-weej> doko: ping
<seb128> jwendell: yes
<jwendell> seb128, did you see my comment on bug 34805?
<ubotu> Launchpad bug 34805 in vino "ALT GR key don't work." [Medium,Confirmed]  https://launchpad.net/bugs/34805
<seb128> jwendell: now I did, do you want to get the Ubuntu package patched with it?
<jwendell> seb128, no, i want to commit it in upstream in order to get it ready for 2.19.92
<jwendell> seb128, but i'd like to see some tests before commit
<mjg59> seb128: mixer_applet2 still seems to be causing wakeups
<seb128> mjg59: yes, we got a bug about that, I need to check if the current gstreamer tarball already has the required API or if that's CVS only
<seb128> jwendell: gutsy is a good way to get testing ;)
<mjg59> seb128: It's in the released version, AFAICT
<seb128> mjg59: let me have a look
<Artimus> Is anyone able to get in touch with the people that run the Ubuntu Mailing Lists?  It's not honoring my unsubscribe requests, it's been 3 days and I still haven't gotten the confirmation email.  My inbox is being flooded, I'd like to unsubscribe, but mailman won't honor my choice.
<cjwatson> Artimus: #canonical-sysadmin
<jwendell> seb128, the problem is that the patch is insane, and i don't know if i or mark is able to fix some side effect
<jwendell> seb128, so, if i detect something is wrong, i won't apply it
<seb128> k
<dholbach> fabbione: who do you think I should assign bug 61151 to?
<ubotu> Launchpad bug 61151 in system-config-cluster ""separated" spelt incorrectly" [Low,Fix released]  https://launchpad.net/bugs/61151
<fabbione> dholbach: is fix released?
<dholbach> fabbione: oh sorry - it's all good then
<fabbione> dholbach: eehheh
<dholbach> calc: is bug 133793 ok?
<ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Incomplete]  https://launchpad.net/bugs/133793
<dholbach> lamont: how does bug 33586 look to you?
<ubotu> Launchpad bug 33586 in nmap ".desktop file cleanup for nmapfe" [Wishlist,Incomplete]  https://launchpad.net/bugs/33586
<lamont> dholbach: it looks like a bug in lp that I should review. :-)
* lamont does so
* dholbach hugs lamont
<seb128> mjg59: ok, the patch is not working
<mjg59> seb128: Hm. How so?
<seb128> mjg59: it has "#ifdef HAVE_GST_MIXER_NOTIFIES"
<seb128> and I'm not sure what should define HAVE_GST_MIXER_NOTIFIES
<seb128> greping for it in /usr/include doesn't return anything
<mjg59> seb128: Can you try just making that true?
<lamont> dholbach: I'll be working on my packages this weekend (postfix, bind, nmap, packit, etc.)  all of which have some bugs to be fixed... This should get in then.
<lamont> if it's still open next week, please poke me.
<dholbach> lamont: you ROCK
<dholbach> lamont: hope you don't mind me assigning that bug to you
<lamont> please do
<dholbach> I just thought you were the best one to get it done ;)
<lamont> dholbach: generally speaking, if I'm the debian maintainer, you're welcome to assign it to me.
<dholbach> the bug patch lists are quite long, so I'll try to badger people some more
<lamont> and I'll either assign it back to you, or fix it. :-)
<lamont> and yes, I'm in a bit of an interesting mood today
<seb128> mjg59: yes, looks like the gst-plugins-base0.10 version we have is enough, I'll do the change and upload
<mjg59> seb128: Thanks!
<seb128> no problem ;)
<dholbach> iwj: what do you think about bug 63506?
<ubotu> Launchpad bug 63506 in adduser "Mistake in deluser.conf manpage" [Undecided,Confirmed]  https://launchpad.net/bugs/63506
* lamont heads to the office
<dholbach> thanks lamont
<iwj> dholbach: I think we should send the patch to the Debian BTS and we shouldn't bother with it.  It's hardly the kind of thing worth carrying a diff for, surely ?
<iwj> I mean, shouldn't bother patching our package.
<dholbach> iwj: ok
<iwj> Do you agree ?  I'm happy to forward it if you like.
<iwj> ("hash" is the correct term.)
<dholbach> I think that the patch author could do that
<iwj> Yes.
<iwj> :-)
<dholbach> ok good
<dholbach> calc: can you add the patch on bug 134112 to your next upload?
<ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
<dholbach> it looks quite straight forward
<dholbach> we need more people going through the sponsoring queue and assigning reviews to people
<dholbach> and I need to fix http://daniel.holba.ch/sponsoring/ - I'll do that next week, when I'm home again
<seb128> ah, you changed the team to send mails on a list
<seb128> that explain why I didn't get sponsoring mails for some time
<dholbach> yeah, we talked about that a week or two ago
<dholbach> that was decided in the meeting
<seb128> right, I didn't notice it would stop it to send me mails
<dholbach> I didn't think it'd do that
<seb128> well, when a team has no list all the members are mailed
<TomaszD> hello, I'm the editor of a special edition Linux+ magazine about the upcoming Ubuntu 7.10. I'm currently writing articles about it and I need to get one answer. Will downloading language packages during installation work for the final version? Because it does not work at the moment
<seb128> TomaszD: that's likely a bug we will fix yes
<TomaszD> seb128, ok, thanks.
<dholbach> calc: also please check out the patch on bug 5462, if you have the time?
<ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
<seb128> TomaszD: I don't work on ubiquity though, is that known in launchpad?
<seb128> TomaszD: maybe evand or cjwatson know about it
<TomaszD> seb128, I'm not sure, but it's a bug that kind of stands out
<TomaszD> so they probably know about it
<TomaszD> I think I even saw it mentioned somewhere, but that's as vague a statement as they get
<cjwatson> TomaszD: I hadn't noticed that bug, but I'd like to fix it; could you file it with details (attach /var/log/syslog to the bug)?
<TomaszD> cjwatson, no problem, does the syslog stay after installation on the drive where I installed ubuntu?
<evand> I believe it's bug 131294 , which is assigned to me, but I haven't had a chance to review yet.
<ubotu> Launchpad bug 131294 in ubiquity "does not install language packs for the target language" [High,Confirmed]  https://launchpad.net/bugs/131294
<TomaszD> ahh, I knew I saw it somewhere!
<cjwatson> TomaszD: /var/log/installer/syslog after installation
<TomaszD> cjwatson, I'll attach that to this bug report soon
<TomaszD> cjwatson, attached
<TomaszD> oops, mixed up your names, requested by cjwatson not seb128
<TomaszD> I have to go now, bye
<seb128> TomaszD: that's ok, thanks
* Starting logfile irclogs/ubuntu-devel.log
<seb128> mjg59: the new patch is still buggy, the volume icon is not updated correctly
<mjg59> seb128: Hm.
<mjg59> seb128: I'll look into it.
<seb128> thanks
<mjg59> seb128: If you could put your package somewhere, that would help
<seb128> mjg59: I'll upload the package with the buggy patch for now
<mjg59> Ok, cool
<seb128> if you have a fix feel free to apply and upload ;)
<mjg59> Will do
<snikker> why if a "filename.templates" in (in the po folder) start with a comment (#) or a blank line, the templates file in the packaged version (with debuild) start with 2 blank lines?
<gustavold> hi, where the glib's function g_log() sends the data to? stdout? Is there a way to modify it, for example sending it to syslog ?
<snikker> why if a "filename.templates" in (in the po folder) start with a comment (#) or a blank line, the templates file in the packaged version (with debuild) start with 2 blank lines? This happen in dapper
<ion_> Does it echo in here, or is it just me?
<seb128> gustavold: that's not really the right chan to ask coding questions
<gustavold> seb128: where should I?
<seb128> gustavold: by default it sends the log to stdout or stderr, depending of the level
<seb128> you can g_log_set_handler () to change the behaviour
<seb128> gustavold: not sure, #gnome on gimpnet maybe
<gustavold> seb128: ok, thank you
<ion_> utt
<ion_> Whoops
<ion_> I was typing :screen mutt, but in the middle of that, the screen window closed and the rest of the line went to the program in the remaining window, namely irssi. :-)
<mathiaz> ogra: do you remember why pitti doesn't want ot use dbconfig-common for moodle ?
<mathiaz> ogra: and also why not use wwwconfig-common ?
<ogra> first of all he didnt want it ust for moodle in main
<ogra> second he didnt want to *just replace* a security broken system with one thats only slightly better (in his opinion)
<mathiaz> ogra: you're talking about dbcommon-config or wwwconfig-common ?
<ogra> the clear advice he made was to replace wwwconfig-common with plain scripts for mysql and postgres creation
<ogra> mathiaz, both
<mathiaz> ogra: ok. Thanks for the clarification.
<ogra> wwwconfig-common was refised by the security team
<ogra> *refused
<ogra> dbconfig-common would only replace it ... have a slightly better security but wouldnt really gain anything
<ogra> but we'd still have that extra dep
<mathiaz> ogra: ok. But it seems that there is a need for a common way to handle database setup.
<ogra> mathiaz, i personally really dont care if it has either, i just want it in main
<mathiaz> ogra: I see your point. I'll discuss that with pitti when he's back.
<ogra> and i dont want pitti to freak out if he comes back and throw it out again :)
<ogra> so the directive from my side was, replace the helper scripts with plain postinst stuff ones
<ogra> -ones
<ogra> seems moquist made some good progress n the mysql fron here ...
<mathiaz> ogra: that makes sense then.
<mathiaz> ogra: do you wanna get it into main for gutsy ?
<ogra> but we have tons of postgres users out there ... so that needs to be supported as well
<ogra> mathiaz, i wanted it in main for breezy :P ... indeed i do :)
<mathiaz> ogra: I see... Why not drop mysql then ?
<mathiaz> ogra: and just support postgresql
<ogra> postgres you mean
<ogra> moquist doesnt have any postgres support in yet
<ogra> and there are likely as many postgres as mysql users
<mathiaz> ogra: well. I've seen some code about posgres.
<mathiaz> ogra: ok. So you wanna support both explicitly.
<ogra> yep
<moquist> ogra: I uploaded a version with postgres support last night.
<ogra> until now i always said i'll rather leave it in universe than having it crippled ... but we have some projects where i'll need it in the future
<moquist> ogra: I uploaded a version with *tested* postgres support last night.
* ogra hugs moquist 
* moquist hopes his package changes don't suck
<moyogo> cjwatson: did you get a chance to look at updating xkeyboard-config?
<ogra> moquist, depends if you can please iwj with them :)
<moquist> ogra: See your inbox when you get a chance. I've got questions in there that somebody needs to answer, sometime. There are three questions, and I think that only the first one absolutely *must* be answered before this package can get into main.
<ogra> i'll have a look
* moquist nods
<ogra> moquist, apache2 as a conf.d dir afaik
<ogra> *has
<ogra> as well as sites-available and mods-available ...
<ogra> moquist, so we should be able to just drop moddle configs in there and use the native apache tools to enable them
<ogra> moquist, i dont really care about old apache ... and ssl in the 2 version shouldt behave differently to the non ssl variant, its just some config change
<moquist> ogra: I hadn't checked until now, but the package is already using apache2/conf.d correctly. I believe the preinst script is just trying to clean up from older versions of the package (of apache?) that didn't use a conf.d directory [correctly] .
<ogra> moquist, for point 2 just dont ask for these values if you dont need them :)
<ogra> ah, k
<ogra> i think we can ignore apache1 ...
<moquist> ogra: Right, which is what I figured, except that if they want postgres running somewhere other than localhost then we need to know so we can bail. Or maybe we just don't ask, and the package assumes localhost for postgres. ?
<ogra> have a question for it ("you run postgres, by default we do that locally, do you want a different setup")
<ogra> preseed that and make sure it doesnt get asked on CD installs
<ogra> (since we'll have a defined setup there anyway)
<ogra> moquist, for point 3 we have dependencies ;)
<moquist> The question should also inform them that they'll have to set up the DB manually if they don't take the default. It's always annoying when software says "Do you want the default?" and you say "no" and then it says "Fine then, I'm going to stop helping you."
<moquist> ogra: Right; I wasn't sure if we could/should change them.
<ogra> right, something in that direction
<ogra> sure, lets change them as we need
<moquist> great
<ogra> you should in any case have a: postgresql-client|mysql-client in the deps ...
<ogra> the servers in a similar way in Recommends
* moquist nods
<ogra> if we need more we'll do that through edubuntu-server
<ogra> (thats what it's for :) )
<ogra> did upstream ever answer your mailping ?
<moquist> Hmm. These deps are already a bit messed up; we're always getting postgresql-client and libdbd-mysql-perl. That doesn't seem right.
<ogra> (upstream == debian here)
<moquist> ogra: No, but I only pinged once.
<moquist> And I didn't really have anything done at the time.
<ogra> well, if we're done lets offer him code :)
<mayeco> when we have a kde4 project in launchpad?
<ogra> ready made code is more tempting :)
<moquist> *when* we're done. we definitely aren't yet.
<iwj> ogra: I was redoing the cryptsetup MIR and I saw a statement presumably from you saying `note that there are some motu tools that even generate MIRs from the template page'.  Can you point me at those please ?
<iwj> ogra: Because I don't think that's a very good idea.  The point of a report is to summarise the results of investigation and analysis, not just to repeat some formula.
<ogra> iwj, LaserJock wrote some stuff but dropped them again when the format changed
<iwj> Oh, good.
<iwj> I'm not trying to make life difficult, obviously.
<iwj> In fact, that's almost precisely it.  The point of the report isn't just a hoop to jump through, it's to document the results of the investigation so that we can make a sensible decision, and so on.
<ogra> right :)
<iwj> If the formatting of the report is harder than the figuring out what to write in it, then we're doing something wrong.
<ogra> we should even have deeper discussions about the apps we include imho ... but thats a matter of time to invest we still lack manpower for imho
<iwj> I think we'll have to realise that we're constantly going to lack manpower.
<ogra> well, but compare the clean small main of warty with what we have today :)
<iwj> I don't think it's a huge problem to have much stuff in main.  Having it installed by default is a different matter.
<ogra> well, but a constantly growing main has indeed some relation to constant lack of manpower
<iwj> True.
<iwj> But that's just the world of software, really.
<ogra> indeed
<Riddell> mayeco: what would you need one for?
<iwj> siretart: Could you please try the cryptsetup .debs from http://www.chiark.greenend.org.uk/~ian/d/cryptsetup/ ?  I think it shouldn't break anything for you but I haven't tested it at all so beware.  I hope you don't mind me using you as alpha-testers :-).
<iwj> sladen: ^
<mayeco> Riddell: hi you are the kde mantainer, dont you thing will be more easy to find kde4 bugs?
<iwj> If and when I get a `yes' from you I'll upload and I think that will allow us to promote the package.
<mayeco> Riddell: dont you think?
<Riddell> mayeco: I don't think it's very useful to report upstream kde 4 bugs to launchpad, you can report packaging bugs of course
<mayeco> Riddell: ahhh... so bug should go to kde.org?
<Riddell> mayeco: bugs.kde.org if you think it'll be helpful to them (but given the state of kde 4, there's plenty needing fixed without bugs being reported)
<mayeco> Riddell: yeah... do you build kde4 is very buggy?
<mayeco> Riddell: but is really kool
* iwj goes to have dinner.
<LaserJock> Riddell: do you know who's archive day it is today?
<Riddell> LaserJock: nobody's
<Riddell> nor tomorrow either since pitti is away
<LaserJock> Riddell: well, NewPakackageFreezeUniverse just happened
<LaserJock> and there was some confusion as to the actual time it went into effect
<LaserJock> should an email to ubuntu-devel suffice to let ubuntu-archive know when we declared it frozen?
<Riddell> LaserJock: ubuntu-devel-announce I'd say
<Riddell> LaserJock: but I don't see any point in setting a to-the-minute deadline
<Riddell> just let people have until the end of their day
<LaserJock> well, the release schedule says that all deadlines are 00:00 UTC
<Mithrandir> ScottK: no, it's not ok.  It doesn't give redistribution rights.
<ScottK> Mithrandir: Thanks.
* asisak thinks lot of confusion could be saved if we specified 24:00 the day before as deadline. You could not misinterpret it in the "dangerous" way. Worst case you would still have one day left.
<Mithrandir> I think specifying the freeze down to the minute is silly.
<LaserJock> well, I know
<LaserJock> but with Feisty we had some problems
<LaserJock> and packages that were supposed to get in didn't etc.
<LaserJock> so we need to be clear with ubuntu-archive what packages they need to review
<LaserJock> and if we don't set a hard deadline we tend to get people pushing it and pushing it
<LaserJock> for the New Packages Freeze anyway
<Mithrandir> from -archive's point of view, anything _not in_ by a freeze doesn't matter, and needs an exception.
<Mithrandir> whether it's uploaded half a year or a day in advance doesn't matter.
<LaserJock> in the past we've considered that anything uploaded to NEW by freeze should be reviewed
<Mithrandir> then there is a disconnect there.
<LaserJock> yes, which causes problems like every release
* ScottK can probably find a co-consipirator in motu-uvf for a blanket exception if you want one...
<bddebian> Doh
<LaserJock> it's a big deal for contributors when the *finally* get their package through REVU
<LaserJock> and then it sits in NEW and doesn't make it into the release
<sistpoty> hm... imo the gist of new freeze is to get devs focussed on bug fixing, right? so processing everything in the new queue until package freeze seems like a good idea to me
<bddebian> Mithrandir: Are you saying from the archive admins point of view anything not already accepted into the archive by the freeze is out?
<Mithrandir> bddebian: that's always been my understanding as a member of both the release and the archive team, yes.
* ScottK wonders if can be writtien as one big freeze exception or we need one per package ...
<LaserJock> that hasn't been the MOTU understanding for the last 2 releases anyway
* _MMA_ can attest to a exception pretty much being worthless.
<bddebian> Yikes that would have been good to know
<Mithrandir> ScottK: mailing -archive with a list should be fine.
<LaserJock> well, I think the key is that whatever MOTU decides to do that the archive team needs to be informed
<ScottK> Mithrandir: OK.  I'll find a co-conspirator in motu-uvf and do that.
<ion_> So, seems like qtpfsgui (in the depomaniak repository) isnt going to get included. :-(
<ScottK> soren: Are you awake/online?
<Mithrandir> _MMA_: without an exception, you will not have your thing accepted, with it, you might have it accepted, but you don't have any guarantees.
<asisak> ion_: we have uploaded it well before the freeze
<bddebian> LaserJock: Doesn't that need to work the other way?  We can't "inform" the admins of anything, they have the power, no?
<_MMA_> Mithrandir: Because of the work involved, especially for new contributors, it should.
<LaserJock> bddebian: well, that's the thing
<ion_> asisak: Very recently? Thats great to hear.
<asisak> ion_: 2007-08-28 13:20 CEST
<LaserJock> the problem is that there is a disconnect (sometimes a big one) between what gets uploaded and what actually makes it in
<LaserJock> it's very harmful for contributors if they get something all the way through REVU
<LaserJock> it's good packaging and it's all set
<_MMA_> It's very deterring just to go through the packaging work. Then to have to go through the exception process and it _still_ not get in. That wont keep people contributing.
<LaserJock> and it doesn't make it in because ubuntu-archive couldn't get to it in time
<Mithrandir> _MMA_: I don't have 24 hours a day extra to pull out of my magic hat.  Do you?
<asisak> ion_: it sits in the NEW queue
<LaserJock> Mithrandir: you don't need an extra day
<_MMA_> Mithrandir: Sure, but if you're the only one shouldering this, things are very wrong.
<Mithrandir> really, it's not like -archive is conspiring to not have packages in the archive, it's just that we don't have the time to do so.
<asisak> Mithrandir: I was sure packages uploaded in time will be processed.
<Mithrandir> _MMA_: I'm not, but all of the archive team has other things to do too.
<LaserJock> but that's the deal though Mithrandir
<LaserJock> if it goes by upload time then you don't have to worry about it so much
<_MMA_> Thats where I think we're failing. People are taking on too much.
<ion_> asisak: Ok, thanks.
<Mithrandir> asisak: I don't know where you got that impression from, since it was certainly nothing like what I was trying to communicate when I was release manager.
<LaserJock> we just need to know what will get processed, not *when* it will get processed
<LaserJock> Mithrandir: that has been the MOTU understanding since dapper
<Mithrandir> LaserJock: that has not been discussed with those who actually process packages, nor with the release team.
* asisak does not want to force anyone anything. We should define our processes in a way where developers / MOTUs can see what a deadline exactly means.
<Mithrandir> LaserJock: hence, send a list from a member of motu-uvf granting an exception for the packages that should go in.
<Mithrandir> there's still no magic in them being accepted, but they might be processed then.
<Mithrandir> _MMA_: if you think that I should resign from the release and archive teams, I could do that, sure.  I don't think that'd make more packages get through.
<_MMA_> LaserJock: But shouldn't "what" be determined by a date? Since getting involved I was under the impression that what the freeze dates were for. (looks like you were as well)
<LaserJock> Mithrandir: which packages need exceptions then?
<_MMA_> Mithrandir: You're taking this personally. There's no need.
<Mithrandir> _MMA_: no, I'm explaining to you what the consequences of your suggestions would be.
<bddebian> I still think it would be ideal if we could have a Universe archive admin but I don't know if that is feasible given the resources
<Mithrandir> LaserJock: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/ is the current NEW queue.
<_MMA_> I made no specific suggestions. My only one would to be that we take on less and have specific jobs that we can complete as expected.
<Mithrandir> bddebian: we don't have the infrastructure to be granting per-component archive admin privileges.
<bddebian> Mithrandir: I know.  As I said, it would be nice.
<Mithrandir> yeah.  Like ponies.
<LaserJock> Mithrandir: so you're saying everything that is currently in the NEW queue needs an exception?
<bddebian> ponies!!
<Mithrandir> LaserJock: anything source, I'd say.
<Mithrandir> I don't think we're going to have a freeze for binaries.
<LaserJock> ok, but that's clearly unacceptable
<LaserJock> we gotta figure something out here
<_MMA_> lol. Great.
<LaserJock> there is a package from the 7th in there
<sistpoty> Mithrandir: imo using exceptions to get a fixed date for new packages freeze is a workaround of the policy. Hence we should fix the policy instead.
<Mithrandir> if you want to grant a blanket exception, find out what's from before the freeze and mail that list to -archive.
<Mithrandir> it really doesn't seem that hard to me.
<sistpoty> if it's only about getting that list, let's make that policy that motu-uvf could take care of, what do you think?
<sistpoty> Mithrandir: should I send a mail to -devel for further discussion on the topic?
<Mithrandir> sistpoty: sure, feel free.
<Mithrandir> I'm not going to be able to respond before Monday, but others might.
<sistpoty> Mithrandir: ok, will do.
<sistpoty> sure, I've got quite a mail backlog here as well ;)=
<_MMA_> Mithrandir: So say the list sent to -archive contains everything in NEW? Or even half? What then? The work involved there can be the same as just processing it now.
<mjg59> seb128: Ok, I see the breakage you're referring to
<Mithrandir> _MMA_: "just processing" NEW in the current state is probably a full day's work.
<_MMA_> Ok.
<LaserJock> well, there's not a huge rush in getting it processed
<LaserJock> people just want stuff they uploaded before the Freeze to make it to Gutsy
<bddebian> People in Hell want ice water ;-P
<_MMA_> Thing is, if its not processed in a timely manner they can miss the date to even file an exception.
<Mithrandir> and people in Ubuntu want ponies.
<LaserJock> it's not that big of a deal
<LaserJock> just process what's in the queue up until Freeze
<LaserJock> if that takes a week, fine
<_MMA_> Well it was for us. ;) We had to resort to using our own repo because of it.
<LaserJock> 2 weeks, I'm ok with that
<LaserJock> _MMA_: no, that wasn't the problem
<_MMA_> Even after freeze exceptions our packages weren't processed. Thats what happened.
<_MMA_> We relied on "the system" instead of being the "squeeky wheel" like this time around. (which sux)
<seb128> _MMA_: "us" being?
<_MMA_> Ubuntu Studio
<seb128> you are in such in a hurry than waiting a few days for new packages is not acceptable?
<_MMA_> No. Im commenting on my personal experiences with the freezes and exception process I went through with Feisty.
<seb128> the ubuntu-archive team got new member this cycle so it should be better
<_MMA_> And thats the thing. :) With Feisty we did "wait a few days". Then that turned into weeks. Then we needed exceptions. Ant still the packages didnt make it into the archives.
<LaserJock> seb128: he's saying that the packages *never* got processed for that release, even after an exception
<asisak> seb128: I guess the issue is not that you have to wait. It is that you submit new packages before the appropriate freeze.
<asisak> seb128: and they are not processed, though.
<LaserJock> yes, we aren't complaining about how long it takes to get them processed
<_MMA_> seb128: Oh sure. It has been better totally. Thanx to Riddlel and us not relying on "the process" we go all our packages in this time. I just worry about new people coming in now and what they will take from this if they hit what I did the 1st time around. ;)
<LaserJock> we just need know that they *are* going to get processed at some point before release
<_MMA_> s/go/got
<sistpoty> if you wait a few more minutes, you can proofread my mail to get this sorted out ;)
<seb128> LaserJock: that's weird
<seb128> asisak: well, don't summit it 1 hour before the freeze and except having an archive admin around to jump on it
<mjg59> seb128: Ah, got it
<mjg59> seb128: cb_volume needs to force a refresh
<seb128> mjg59: ah, cool
<seb128> mjg59:   http://bugzilla.gnome.org/show_bug.cgi?id=370937 if you want to comment on the upstream bug
<ubotu> Gnome bug 370937 in mixer "Exessive CPU Utilisation" [Minor,New] 
<mjg59> Previously it didn't need to, since that would arrive after the scheduled update
<LaserJock> seb128: we've got packages going back to the 7th in NEW!
<seb128> LaserJock: it's not even 1 month and it's middle of summer with people on holiday
<seb128> LaserJock: I don't think it's really an issue
<asisak> seb128: sure. I think it still would be more reasonable to have a deadline that means: I can upload packages, and they will (eventually) get processed.
<seb128> asisak: that's the case now, no?
<seb128> we usually try to clean the queue before a freeze
<asisak> seb128: no. :)
<_MMA_> seb128: from the chat here obviously not.
<_MMA_> :(
<seb128> asisak: example of package which had issues this cycle?
<asisak> As far as I understand the words of Mithrandir mean exactly the opposite. Packages in the NEW queue at the moment of the freeze need an exception.
<LaserJock> seb128: look at NEW! Mithrandir says that none of the source will get processed with an exception
<LaserJock> *without
<asisak> seb128: not a concrete package. Only in theory...
<mjg59> seb128: I'll comment upstream and upload
* asisak has no problems at all. He wants to understand what a freeze exactly means.
<seb128> mjg59: thanks
<bddebian> Damn are we still arguing this? :-)
<sistpoty> ok, anyone want to proofread http://paste.ubuntu-nl.org/35700/ ? (and any good ideas welcome, though of course you could also follow up then *g*)
<_MMA_> bddebian: Who's arguing?
<seb128> asisak: if you want my opinion people complain too much ;)
<seb128> that could use clarification though
* asisak shuts up and cries
<asisak> s/cries/hacks/
<seb128> I don't think there is a clear policy
<sistpoty> seb128: yes, and that's imo the source of problems ;)
<seb128> I did NEW processing until late yesterday and I don't think we have such of an issue
<LaserJock> seb128: there are packages weeks old in NEW
<_MMA_> seb128: How so? I'm sure Laserjock and people in -motu think it pretty clear.
<seb128> LaserJock: against, it's summer and people tend to take holidays, you can't blame them for that
<seb128> it creates some delay
<ScottK> sistpoty: Dunno if you want to deal with it in this mail or not, but I think there are two issues: 1.  What to do for gutsy since there clearly is a misunderstanding.  2.  What to do for Hardy Herron and follow.
<LaserJock> seb128: what the heck are you talking about?
<seb128> LaserJock: NEW processing is made by people, not robots
<LaserJock> I'm not complaining about them not getting reviewed in a timely fashion
<seb128> if it takes some time it's because some people are not there and other are busy
<seb128> so stop saying that items are weeks old there
<LaserJock> I *said* several times, the issue is what happens at the freeze
<seb128> that's not really an useful information
<LaserJock> they are that old!!
<_MMA_> seb128: There is.
<seb128> yes, and I'm telling you why
<LaserJock> I uploaded a package on the 22nd
<seb128> because people are on holidays for some weeks
<LaserJock> I want assurance that it will get proccessed
<_MMA_> But the "why" shouldnt matter.
<LaserJock> I don't care *when*
<LaserJock> I just want it in Gutsy
<Daviey> There should be more people doing it then.. there is the talent
<seb128> LaserJock: ok, so the fact they are weeks old doesn't matter there
<LaserJock> seb128: no
<Daviey> holiday's etc are not an excuse imo
<seb128> what we need to define is if the upload or the processing counts
<asisak> seb128: exactly.
* asisak hugs seb128 
<LaserJock> but Mithrandir was saying that they won't get processed without an exception
<_MMA_> If the people involved in processing, cant process, why are they doing it? Its such a crutial part.
<seb128> LaserJock: we need a policy, we don't have one for that at the moment afaik
<_MMA_> *crucial
<Daviey> ompaul is here to sort it out.. don't worry :)
<seb128> _MMA_: everybody deserves some holidays, you are not fair there
<LaserJock> seb128: MOTU have had one, but it seems ubuntu-archive didn't know/understnad
<ThorstenSick> Hi I am new to ubuntu development, but _maybe: I got a good idea: is it possible to priorize packages of new software ? So new contributors will not be disappointed. Software where older versions have already been checked will have to wait in the queue...
<bddebian> haha
<seb128> LaserJock: maybe MOTU didn't communicate it clearly out of their land? ;)
<Daviey> seb128: true!  not saying that..  but if holidays are getting in the way - there *needs* to be more people.. Ubuntu has the talent
<mjg59> ThorstenSick: Packages that are already in the archive do not need reviewing
<_MMA_> seb128: Sure. I never said that. If someone goes, someone else takes over.
<seb128> _MMA_: easy to say, not easy to find people trusted, not too busy, etc
<seb128> _MMA_: and I don't think the current delay is that bad
* ScottK quietly suggests people stop arguing on IRC and we take this to the mailing list.
<sistpoty> ScottK: ok, thanks for the suggestion, will put it in
<seb128> we just need to say we allow packages uploaded before the freeze
<LaserJock> seb128: well, we understood that ubuntu-archive had the same policy
<Daviey> Yes.. /me grabs his lighter fluid to squirt on the ML
<_MMA_> seb128: Again. The issue isnt the delay. Its things not getting processed period. :)
<seb128> LaserJock: I'm telling you that I'm not aware of a policy
<seb128> _MMA_: things always get processed
<seb128> _MMA_: the queue was empty one month ago
<_MMA_> Not true at all.
<seb128> we have nothing waiting for over a month there
<seb128> and everything get either accepted or rejected
* ScottK sets a cron job: "ScottK quietly suggests people stop arguing on IRC and we take this to the mailing list."
<seb128> _MMA_: well, I've access to the queue and do NEW work almost every week
<seb128> I can tell you it was empty some weeks ago
<seb128> and that I look quite often at it
<joejaxx> ScottK: +m ftw?
<LaserJock> seb128: this happens every release though it seems
<Daviey> GOTO $(now-10mins)
<seb128> LaserJock: can't speak for previous cycle, I'm one of the new members
<seb128> the team was too small previous cycle
<seb128> it should somewhat scale now
<_MMA_> Sorry man. You havnt seen everything Ive said. :) I had 4 packages sitting in NEW that werent processed for Feisty. Nobody touched them then I was told they would need exceptions. Still were never processed. Same thing will happen now.
<Daviey> seb128: and it seems that the team is still too small - if holidays are an issue
<seb128> Daviey: holidays and distro team workload create some delay
<_MMA_> Daviey: +1 but like he said, "easy to say, not easy to find people trusted, not too busy, etc"
<seb128> that's not that of an issue thoufg
<seb128> though
<seb128> we will catch up soon
<seb128> don't base your opinion on previous cycle though, the team was too small
<seb128> it should be better now
<_MMA_> seb128: So _you're_ saying everything currently in NEW _won't_ need an exception?
<sistpoty> ok, mail sent to -devel, I guess it might be a good thing to follow up for the discussion *there*
<ogra> and for the policy as far as universe is concerned the motu council should define whats the deadline (upload or build)
<mjg59> _MMA_: Seb is not in a position to say that.
<Chipzz> seb128: sure it matters that they are weeks old. If they are weeks old, that implies that other packages got processed right away
<ScottK> CRON: "ScottK quietly suggests people stop arguing on IRC and we take this to the mailing list."
<_MMA_> mjg59: Sure. And who is?
<sistpoty> ogra: MC has until now merely acted to discuss new applications, since the motu team can make decisions during meetings
<mjg59> _MMA_: The archive team as a whole should determine this policy, probably in conjunction with the release team.
<Chipzz> seb128: since you claimed you had been doing archive duties yesterday
<ogra> sistpoty, imho defining procedures and freze dates if part of the MC work
<mjg59> If no policy currently exists, then arguing on IRC will not achieve anything
<ogra> *is
<mjg59> Chipzz: Correct, NEW is not processed as a fifo
<Chipzz> and that's exactly one of the complaints I think
<Chipzz> starvation
<Daviey> mjg59: why not?  that would seem logical?
<mjg59> Some packages are more important than others
<mjg59> Some packages are easier to process than others
<sistpoty> ogra: sure, but only together with MOTUs not merely from a place above... but imo that's a completely different discussion ;)
<mjg59> That's not going to change
<_MMA_> mjg59: I dont feel we're arguing. :) There seems to be a slight miss-communication and lack of man-power in the end.
<Chipzz> mjg59: sure I understand that. but that doesn't mean that less important/easy packages should be delayed again and again
<Chipzz> mjg59: you need to do them at one point
<mjg59> They will be done at some point
<ogra> sistpoty, right, i just wanted to point out that the issue for a universe freeze should be brought to the MC instead of having a wild discussion in -devel ;)
<_MMA_> mjg59: "miss-communication" as far as policy.
<Daviey> Chipzz: I apprciate that some packages are show-stoppers if not done first
<Daviey> Ie halting an beta release
<Chipzz> I didn't say I didn't (appreciate that). I'm saying you cannot keep using that as an excuse
<ScottK> I really don't think all this finger pointing is helpful.
<soren> ScottK: Wazzup?
<Chipzz> may be a hard limit on how long packages can be in the new queue
<mjg59> Chipzz: Do you have any evidence that there are packages that have never been processed?
<ScottK> soren: I'll PM you...
<Chipzz> mjg59: I wasn't saying never
<sistpoty> ogra: sure, but archive admins have something to say to this as well ;)
<soren> ScottK: Uh, is it secret? Cool!
<bddebian> heh
<LaserJock> mjg59: there are some that get dumped to the next release
<Chipzz> mjg59: I'm guessing that the complaint is about too long delays
<sistpoty> sheesh, that was denglish again
<mjg59> Chipzz: No, the complaint is nothing to do with delays
<ogra> sistpoty, about their job of processin probably, but the MC should set the dates and policies for the devs
<ogra> sistpoty, as the TB does for main
<mjg59> The complaint is whether packages in NEW before UVF should still enter the release
<Chipzz> but anyway, something like: sure there may be showstoppers, but if a package is longer in the queue than say 2 weeks (arbitrary number), you have to do that first?
<sistpoty> mjg59: not uvf, but npf... we got a new tla there ;)
<mjg59> sistpoty: Eh, whichever :)
<sistpoty> hehe
<mjg59> But it's a legitimate question, and one that should be discussed with the archive, release and motu bodies
<bddebian> sistpoty: ach the acronyms.. my eyes....
<Chipzz> which may be an incentive to do the less important packages sooner rather than later
<mjg59> Not argued on IRC
<CharlesEdwardPax> Hi, folks, I'm hoping someone can help me get started with the new PPA system on Launchpad.
<CharlesEdwardPax> I have a handy little application in Python using libglade called Gladex (http://www.openphysics.org/~gladex/), which is hosted in Launchpad bzr. I hacked together a Makefile that will output a binary package when the user types "make package"; this is located in the bzr repository. This is fine for personal use and distribution to those who don't mind poking around a bit. However, in the hopes of distributing to a wider
<CharlesEdwardPax> The problem I'm having is making a source package that won't make PPA's automated build system puke. All the tutorials and documentation I've found are more complex than I would hope for.
<CharlesEdwardPax> Does anyone have an example or can point me to some good information on how I need to structure the code in the bzr repository and what files must be included in the bzr repository?
<Daviey> s/argued/discussed
<Kmos> CharlesEdwardPax: ask on #launchpad
<mjg59> CharlesEdwardPax: My understanding was that PPA packages need to conform to the same standards as normal distribution packages
<seb128> re
<seb128> Chipzz: sure I process feature goals before random games
<Daviey> CharlesEdwardPax: keep in mind that PPA won't currently sign packages
<seb128> Chipzz: you think we should not apply a priority for goals?
<Chipzz> seb128: it's a simple question of scheduling
<Chipzz> even the kernel has the same principle
<seb128> Chipzz: it's a simple question of being overworked already
<seb128> I wanted to 1 hour of NEW handling
<seb128> I started with things blocking people
<Chipzz> sure there may be important processes, but to prevent starvation, sometimes less important processes get processed first
<CharlesEdwardPax> I'm new to packaging, so I don't really know where to start. I've looked at the Ubuntu Packaing Guide, but I can't quite figure things out.
<seb128> right, when we are processing "random" things waiting it makes sense to use order
<asisak> CharlesEdwardPax: #ubuntu-motu is better place for this
<Daviey> CharlesEdwardPax: join #ubuntu-mot --- they will help more
<seb128> when you know what is blocking people or what is a gutsy goal you start with those though
<Chipzz> seb128: in this concrete example (Ubuntu Studio), packages actually *were* blocking people...
<seb128> Chipzz: ubuntu studio packages are not old in the queue
<asisak> It seems e.g. we are blocking seb128 now...
<Chipzz> seb128: the example was from the feisty release
<Chipzz> seb128: I'm sure you can find examples for this release too
<seb128> Chipzz: I was not in the team by then and as said don't compare with feisty, the team got several new people since and should scale better now
<mjg59> Chipzz: You're being needlessly aggressive. Please tone this down a bit.
<seb128> there is 3 items which are 3 weeks old in the queue
<seb128> every else is newer than 2 weeks
<Chipzz> seb128: btw, please understand, I'm not critisizing you personnally btw ;)
<seb128> in the middle of holidays I don't think it's that of an issue
<seb128> s/every/everything
<seb128> Chipzz: I understand that, don't worry ;)
<CharlesEdwardPax> Which would be a better place #launchpad or #ubuntu-motu ?
<Kmos> CharlesEdwardPax: both
<seb128> I don't think that 2 weeks of waiting in august is an issue though
<asisak> CharlesEdwardPax: for development issues #ubuntu-motu
<LaserJock> CharlesEdwardPax: if you want to learn how to package #ubuntu-motu
<Daviey> CharlesEdwardPax: packaging #ubuntu-motu / #launchpad for PPA
<Chipzz> seb128: but who's to say that throwing more resources (ie people) at it actually solves the fundamental problem?
<LaserJock> I don't think 2 weeks is bad normally at all
<LaserJock> a lot of times Debian is 2 weeks-1month
<CharlesEdwardPax> I'll check them out. Thanks, everyone.
<Daviey> but 2 weeks right before UVF?
<seb128> Chipzz: what do you mean? saying what?
<ScottK> CRON: "ScottK quietly suggests people stop arguing on IRC and we take this to the mailing list."
<sistpoty> thanks ScottK
<LaserJock> but on a 6month release cycle does mean that we need to get stuff processed at some point
<seb128> Chipzz: it's easy to say "we need extra volunteers", that's now how it works though
<Chipzz> seb128: saying that as ubuntu grows, the new queue may grow bigger and you'll need to add more people again
<asisak> Chipzz: Sure, as "Adding manpower to a late software project makes it later"
<seb128> Chipzz: we did add several people this cycle
<bhale> I don't expect to see Canonical allow volunteers to process NEW
<seb128> Chipzz: we added the people who are fit for the job and wanting to do it
<seb128> Chipzz: if you know of other people we match the description let we know though
* ScottK writes a reply to sistypoty's email....
<Chipzz> bhale: I was not suggesting that at all; quite the contrary
<Chipzz> bhale: pls read what I said
<sistpoty> bhale: why not (if no access to the DC were needed)?
<Chipzz> 22:06 < Chipzz> seb128: but who's to say that throwing more resources (ie people) at it actually solves the fundamental problem? 22:07 < Chipzz> seb128: saying that as ubuntu grows, the new queue may grow bigger and you'll need to add more people again
<bhale> sistpoty: oh, I am thinking of the bad old days. you are correct.
<mjg59> Chipzz: If the queue gets impractical for the current team to handle, then the order of processing will make no difference.
<sistpoty> bhale: well, we're not there yet ;)
<seb128> Chipzz: ?
<seb128> Chipzz: there is also ton of bugs without a reply
<seb128> sure we could do with extra contributors
<Chipzz> what I was implying is rather than adding more people you may also need to impose some rules on how what gets processed
<seb128> the things is that volunteer decide by themself what they want to do
<mjg59> Chipzz: No, that doesn't help.
<pkern> What's the policy for syncing new Debian revisions (for both main and universe, and taking the current point in time into account)?
<seb128> that's not up to us to pick somebody and assign him tasks
<Kmos> pkern: man requestsync
<Chipzz> pkern: make sure there is a valid reason other than "It's new"?
<seb128> Chipzz: "stop processing things blocking people or which are goals and process random games nobody cares first because they are waiting longer"?
<Chipzz> ;)
<Daviey> seb128: That's quite extreme.. that's not what Chipzz means
<seb128> Daviey: well, either you force a "first uploaded, first processed" rule which means that
<seb128> or you let people act in function of what think should have the priority
<seb128> which is what we do now
<Chipzz> seb128: what I was proposing was something in between actually ;)
<seb128> Chipzz: how would you define it then?
<Daviey> But the bottom line is that the team shouldn't be that stretched that they need to prioritise
<seb128> Daviey: well, and we should not have bugs without a reply
<Daviey> v. true
<seb128> Daviey: the issue is that we have too much to do for the number of people we have
<Daviey> Some go back to 2005!
<LaserJock> Daviey: we'll always be stretched
<seb128> and that's not something a rule will make better
<Chipzz> seb128: a hard limit on how long something should be in the queue
<seb128> Chipzz: how long would be the limit?
<Daviey> then it gets dumped if it goes past the hard limit :)
* ScottK has sent a reply to sistpoty's mail on ubuntu-devel....
<joejaxx> ScottK: i do not think people are getting your hints :(
<pkern> Kmos: Thanks. This means that I need to wait for the next Debian mirror pulse at the earliest.
<ScottK> No, they aren't.
<Chipzz> seb128: say, package n (not-important) is uploaded one week ago, and the (for the sake of argument, here arbitrary chosen) limit is 2 weeks, and you package i (important) which is uploaded now
<seb128> what hints?
<EvanCarroll> I hope the fonts get a comlete overhaul before gutsy is released. Merge FB puts my DBI at 110,65, dropping all my default font sizes down to 6, still leaves them entirely too big for my liking.
<seb128> IRC != mail
<EvanCarroll> DPI*
<pkern> Kmos: And I don't have my GPG key available on my gutsy QEMU image.
<seb128> I don't get those mails yet
<joejaxx> ScottK: yeah it is quite unfortunate
<Kmos> pkern: that's bad :)
<Chipzz> package i gets precedence because it's important and there are no non-important packages in the queue older than the limit (2 weeks)
<seb128> Chipzz: we have freezes going on a week for tribe, I don't think 2 weeks is a reasonable delay
<seb128> it means people have to process everything in the week after the freeze
<pkern> Kmos: Actually the packages I want to sync are currently transitioning from universe to main but I just added missing translations to the Debian packages. (One-line change.)
<Chipzz> seb128: like I said, 2 weeks is arbitrarily chosen and meant just to be an example. work with me here
<Kmos> pkern: ask in #ubuntu-motu about that
* ScottK wonders if Canonical offered expedited NEW processing as a paid service, people would put their money where their mouth is....
<pkern> Kmos: So even if I get a component mismatch currently motu is still my point of contact? Fine.
<Daviey> ScottK: naa
<Chipzz> scenario b: package n (non-imp) is in the queue for 3 weeks and thus exceeds the limit. even though package i is important, package n gets precedence to prevent starvation
<seb128> ScottK: I think 3 weeks is already a long delay for things in NEW this cycle
<seb128> almost every is processed before that
<seb128> I don't think have to wait 10 days is that of an issue
<seb128> most of the time we process new uploads in the week
<ScottK> NEW has been much better this time than in Feisty.
<ScottK> Agreed.
* ScottK just wished people would quit kvetching and go do something productive.
<seb128> ScottK: the team got new member, that's going in the good direction
<ScottK> Absolutely.
<seb128> so what is the issue?
<sistpoty> Chipzz: scheduling strategies don't have humans to interact. ;)
<Mithrandir> which has something to do with having three and four archive admins rather than.. just me.
<Mithrandir> :-P
<Chipzz> sistpoty :)
<snikker> why if a "filename.templates" in (in the po folder of a source code) start with a block comment (#), the templates file in the packaged version (build with "debuild -uc -us") is replaced with a blank line?
<ScottK> We had a disconnect this time around about what exactly New Package Freeze means.  We've had it before.  We'll muddle through this time like we always do.
<Chipzz> seb128: also note that scenario b could be proactively prevented
<ScottK> The imporant thing is to have a clear/coordinated policy for next time around.
<seb128> I agree that we need to decide how the freezes applies
<Kmos> snikker: #ubuntu-motu
<seb128> if that's the upload of processing which counts
<seb128> and that will be fixed
<seb128> I'll raise the issue
<seb128> anything else that should be discussed in your opinion?
<snikker> Kmos: i've already asked there, but with not answer...
<Mithrandir> Chipzz: seriously, trying to enforce that would a) not work and b) make at least me much more liable to quickly find a reason to reject the unimportant package rather than finding all the problematic bits of it.
<Kmos> snikker: wait for someone to answer you..
<snikker> Kmos: ok
<Chipzz> Mithrandir: I was afraid of something like that ;)
<Chipzz> Mithrandir: you could come up with variants of it though
<Chipzz> say, if there are n packages exceeding the limit you only have to process one
<seb128> trying to enforce rules over overworked people doesn't work
<seb128> you will like just lead them to stop volunteering for the work
* bddebian breaks out the whips!
<Chipzz> or have the uploader do part of the work (like with sync requests)
<seb128> s/like/likely
<Mithrandir> Chipzz: really, that's not how it works.  Do you think we should be blocked on upstream replying to concerns about a package and block everything on that?
<Chipzz> Mithrandir: I indeed don't think we should. but what I'm referring to is working on the new queue, not letting as many packages through as possible ;)
<Chipzz> seb128: likewise the argument was that if new contributors don't get their packages processed in a reasonable amount of time, they will stop volunteering too
<_MMA_> "seb128: you will like just lead them to stop volunteering for the work" And whats wrong with that? My feeling is if you cant do the job why take it on? There's nothing wrong with that.
<mjg59> _MMA_: Then nobody does the job. Which is kind of bad.
<seb128> Chipzz: I think the delay has been reasonable through this cycle and that there is no reason for such a discussion
<Chipzz> in which case I guess it boils down to: well, I guess a MOTU volunteer is more dispensable than an archive admin...
<seb128> as said we had 3 packages in NEW for 3 weeks
<seb128> everything else is 2 weeks or newer
<seb128> and that's probably a busy time in the cycle
<_MMA_> mjg59: Something close to what's being said now anyway right?
<seb128> _MMA_: nobody else is going to do it ;)
<Mithrandir> Chipzz: it's certainly a tradeoff between spending time on making sure we get new blood and doing other work.
<mjg59> _MMA_: No.
<EvanCarroll> right. I think that is the default.
<EvanCarroll> m/t
<seb128> _MMA_: you think that no processing NEW is better than having a few weeks of delay, I don't think there is lot to discuss there
<Chipzz> seb128: but then, I'm just throwing in some idea's on how *possibly* to make it more fair :)
<Chipzz> seb128: if you think there is no problem, then we (I) should stop this discussion ;)
<seb128> well, I would like to be proved that is has been an issue this cycle first
<_MMA_> seb128: You keep focusing on a delay. Thats not the issue _at_all_. Its things making it in before freeze and not being processed.
<seb128> _MMA_: did you read the chan?
<seb128> <seb128> if that's the upload of processing which counts
<seb128>  and that will be fixed
<seb128>  I'll raise the issue
<seb128>  anything else that should be discussed in your opinion?
<seb128> <seb128> I agree that we need to decide how the freezes applies
<LaserJock> _MMA_: seb128 is on to discussing delays with Chipzz  :-)
<seb128> _MMA_: I think that things uploaded before the freeze should be accepted and that will be discussed
<seb128> anything else?
<_MMA_> Well thats fine but its been said its not up to you. :( If it actually happens then yeah, that great. ;)
<xtknight> i've encountered quite a weird problem (firefox failing on 64bit after updates all the time).  any ideas??  Bug 133786
<seb128> _MMA_: I didn't say I would decide, I wrote that I would raise the issue for discussion
<ubotu> Launchpad bug 133786 in ubuntu "Bus error when running Firefox or Epiphany" [Undecided,New]  https://launchpad.net/bugs/133786
<_MMA_> seb128: ;)
<cjwatson> in the past, ISTR things that were in place before freeze generally getting an exception on that basis
<cjwatson> just throwing my oar in a bit late
<cjwatson> as an archive admin I have certainly accepted things on that basis
<seb128> I was going to do that
<cjwatson> whether it happened for feisty or not, I don't know
<seb128> but I'll raise the point at the distro team meeting for clarification
<bddebian> w00t cjwatson is here now, fresh meat!!
<Chipzz> bddebian: .net? :)
<bddebian> Hrm?
<Chipzz> freshmeat.net ;)
<Chipzz> don't know it?
<bddebian> Oh, hehe
<mjg59> seb128: Fixed, uploaded
<seb128> mjg59: thanks
<EvanCarroll> I'm not sure how to file a bug report on the gutsy fonts that will help it seems like a few people have a good idea of the problem
<EvanCarroll> has something to do with the DBI scaling mechanism of the new X
<EvanCarroll> I just can't my fonts down to a reasonable size.
<EvanCarroll> I'm using mergefb (as are most poeple wth dual monitors) so my resolution is 1024*2 x 768
<mjg59> system/preferences/appearance/fonts/details
<EvanCarroll> it totally rapes my fonts, even if i edit the libgnome default down to 7
<EvanCarroll> mjg59: they are at 6.
<EvanCarroll> mjg59: can't go any lower.
<mjg59> EvanCarroll: No. That gives you the DPI setting.
<EvanCarroll> 158
<EvanCarroll> thats it i bet
<mjg59> bryce: He's right, though. The default DPI is horrifically horked.
<mjg59> Even on single monitor setups.
<EvanCarroll> thanks a ton, I saw suggestions for this feature and didn't see any note of it being implimented
<mjg59> My user name doesn't actually fit in the gdm box
<EvanCarroll> I think you guys are shooting yourself in the foot if this "Feature" is in launch... Regression time if you ask me.
<EvanCarroll> hahahahah
<EvanCarroll> I've got a better one, my gvim holds 29characters.
<EvanCarroll> maximized.
<ion_> Gnome shouldnt override the DPI value IMO. Instead, we should make X guess it better. For instance, the displayconfig-gtk monitor database could contain their physical sizes and add a DisplaySize setting to the config.
<EvanCarroll> I had to go down to vritual-line 7 to edit the libgnome2 file
<ion_> That is, for monitors that report it incorrectly.
<EvanCarroll> anyone know how one resets the fonts to the original-factory settings
<EvanCarroll> I forget what the normal ubunte sizes are 10/10/11/11/10 top to bottom ?
<deadwill> any news on bug #124775 ?
<ubotu> Launchpad bug 124775 in vmware-player-kernel-2.6.15 "No kernel modules for the 2.6.22 kernel" [High,Confirmed]  https://launchpad.net/bugs/124775
<mjg59> It's filed against an utterly bizarre package
<EvanCarroll> found it, font size settings are stored in ~/.gconf/desktop/gnome/interface/%gconf.xml
<EvanCarroll> actually only 3 of the 5 that you can configure are stored there
<EvanCarroll> grr!!! gnome and your inconsistancies
<EvanCarroll> window font and fixed fonts not in there
<EvanCarroll> I'll delete my whole gconf I suppose
<tepsipakki> EvanCarroll: just use gconf-editor and set the default from there
<EvanCarroll> tepsipakki: I don't know what the default is =[
<tepsipakki> right click on the setting, then choose the one that reverts to the default
<tepsipakki> don't know what it's called in english/your locale :)
<EvanCarroll> I just know I want the default font sizes on everything again, and I only want to change my DPI because having all of my fonts set to 6 and my dpi correctly set to the 95ish half of what it was detected at, makes all of my font-size 6 look like a font-size 6 now
<EvanCarroll> ah
<EvanCarroll> i didn't know gconf editor had that option
<EvanCarroll> wonder where it stores therem /etc/skel maybe
<tepsipakki> no, /var/lib/gconf
<tepsipakki> oh wait, /usr/share/gconf is better
<seb128> tepsipakki: what are you trying to do?
<tepsipakki> seb128: help :)
<tepsipakki> seb128: EvanCarroll wants to reset the font sizes to the default values
<lizet> HELLO
<EvanCarroll> I butchered every font-size in gnome to 6, rather than changing my borked dpi value
<EvanCarroll> I'm sure this will be a FAQ on launch lol
<seb128> gconftool-2 --unset /desktop/gnome/interface/document_font_name /desktop/gnome/interface/font_name /desktop/gnome/interface/monospace_font_name
<tepsipakki> yes, that's the cool way to do it :)
<EvanCarroll> awesome, thats most of them.
<EvanCarroll> I'll wiki it tonight.
<EvanCarroll> still a few more. that I borked as far as individual applications, the move to resolution independence is surely the right step, I'd go with a year of datacollection on monitors though
<EvanCarroll> capture the name of the monitor from DPMS and the users size-preference in gnome at least the big 6 to infer you are in the right ballpark
<EvanCarroll> seb128: tepsipakki thanks again.
<seb128> you're welcome
<tepsipakki> bummer, he left already
<cjwatson> Riddell: do you think you could grab amarok2 out of NEW and frob it to fix debian/copyright? It needs to list the LGPL and the GFDL
<LaserJock> cjwatson: is the make-web-indices script in ubuntu-cd what's used to create the pages on cdimage.ubuntu.com, etc. ?
<cjwatson> LaserJock: yes
<cjwatson> LaserJock: some of them are tweaked a bit by hand though
<Riddell> cjwatson: ok, I'll do that now
<LaserJock> cjwatson: if I want to make some changes to the Edubuntu descriptions can I give you a patch or would you rather handle it yourself?
<cjwatson> LaserJock: mail me a patch
<cjwatson> Riddell: thanks!
<Caesar> Is there a way to see all bugs that effect Feisty?
<Caesar> Or is launchpad package-oriented?
<cjwatson> Caesar: https://bugs.launchpad.net/ubuntu/feisty but obviously that's only bugs that have been explicitly annotated as affecting feisty
<cjwatson> launchpad doesn't have version tracking
<Caesar> :-(
<cjwatson> (not my idea, I put it in the original design ;-))
<ogra_> cjwatson, al my work on the udeb was moot :( i cant get any output from mksquashfs through any pipe at all so i have to find another way... (that was the main reason to touch the udeb)
<ajmitch> good morning
<Riddell> cjwatson: amarok2 -0ubuntu2 uploaded
<noah__> Hey! In Ubuty Gutsy, /etc/mysql/my.cf, the last line says !includedir /etc/mysql/conf.d, but settings in here doesn't get applied.. bug?
<soren> noah__: Possibly. File a bug with some more information and I'll look at it tomorrow.
<mathiaz> noah__: what are you trying to set in conf.d ?
<noah__> mathiaz: default-character-set=utf8 for [mysqld]  and [client]  amongst others
<noah__> soren: can i email you a remind? i'm too lazy to write a bug report right now.
<noah__> reminder*
<mathiaz> noah__: you'd better file a bug - so that we can track it.
<soren> noah__: WEll, the e-mail you send to me would have to contain more information as well.
<noah__> soren: i'll give you a test case.. can't figure out which email i used for registering on launchpad and i don't feel like reregistering atm
<soren> noah__: You remember your username?
<noah__> no
<soren> noah__: What's your name?
<noah__> soren: https://bugs.launchpad.net/ubuntu/+bug/136225
<ubotu> Launchpad bug 136225 in ubuntu "my.cnf includedir not working as expected" [Undecided,New] 
<pygi> asac, we need to talk (preferably once I wake up) ... I didn't hear from you in few days o.O
<asac> pygi: yeah ... i somehow lost the current/state/idea :)
<pygi> asac, you know that's not good :p
<pygi> asac, we can't *really* update libswfdec since it depends on unrelease libming
<asac> thats really a shame
<asac> how could that happen?
<asac> what does debian do?
<asac> (they have swfdec 0.5.x, right?)
<pygi> asac, they have debian 0.5.1
<pygi> we can get that as well
<pygi> but can't get 0.5.2
<asac> whats the difference?
<asac> why does 0.5.2 pull in a new lib, pygi ?
<asac> maybe its just testcases? which we can exclude from build?
<pygi> asac, it's due to vivi
<pygi> and yes, we could exclude it
<pygi> but: a)we gotta have it ready by *yesterday* b)I'm going to trip tomorrow, early morning (00:10AM)
<pygi> and I won't be at home for most of the day :-/
<pygi> so much to do :(
<seb128> pygi:  what about swfdec?
<pygi> seb128, we are talking about swfdec now =)
<seb128> I noticed
<pygi> well, trying to get new release in :)
<pygi> if you don't mind :p
#ubuntu-devel 2007-08-31
<pygi> seb128, well, and do some changes to packaging ofcourse so it would play nice with FF and other browsers
<seb128> pygi: I think you will get an uvf easily for 0.5.2
<pygi> seb128, indeed =)
<pygi> but it has to be done today :P
<pygi> (if I'm not wrong today is the last day for NEW packages)
<pygi> asac, you still alive? :)
<pygi> seb128, asac : ok, good night now :) Asac, I'll poke during the day, hopefully we can get something done :)
<Kopfgeldjaeger> gn8
<geser> mathiaz: Hi, are you going to merge fetchmail? the last Debian upload fixes CVE-2007-4565. I guess keescook would be happy.
* keescook likes fixed CVEs.  :)
<mathiaz> geser: not in the immediate time. You wanna do it ?
<geser> I will do it then.
<ion_> Avahi 0.6.21: This is an important bugfix release.
<mathiaz> geser: excellent! - Thanks.
<bathym> some ubuntu official devel in security hand?
<keescook> bathym: I think I want to say "yes".
<LaserJock> heh
<bathym> ^^
<bathym> i search him :P
<keescook> bathym: what's up?
<ajmitch> keescook: are you sure you want to admit to that?
<bathym> query, if it`s possible
<keescook> bathym: go ahead and ask.  :)
<bathym> Nafallo: ping
<lifeless> bryce: if you are around, I have a question about CRT displays and laptops
<bryce> lifeless, about to head to dinner actually, but can try to answer if it's a quickie
<lifeless> ok.
<lifeless> basically, fn-F8 doesn't seem to work in X on my dell d430
<bryce> yup
<lifeless> which has a 945
<lifeless> is this likely to be fixed before release, or is there a test driver I can grab?
<lifeless> I have a presentation to give tonight ;)
<bryce> upstream marked it "won't fix" actually, so there's no fix available
<bryce> mjg59 might be able to explain it better, but as I understand it the issue is that acpi is not passing along the key combo correctly
<mjg59> Dells don't send acpi events for that
<mjg59> There needs to be something in userspace listening for the correct key
<lifeless> sadness
<lifeless> is someone working on this? Is there anything trivial I can do other than subscribing to the bug (which # is it  ?)
<bryce> lifeless: 'rez' in launchpad is the tester at dell who has reported many of these previously
<bryce> same issue happens with dell + nvidia
<lifeless> what would be lovely is if plugin the monitor, then it just works as xinerama or something
<kylem> lifeless, just mash it manually with xrandr.
<lifeless> but thats a different discussion
<lifeless> kylem: oh lovely, 1.2 is here isn't it
<kylem> if you're on 945.
<bryce> lifeless: yeah I'm hoping for hungry hippo we can put some work into that
<ajmitch> kylem: is there hope for us on older intel chips (i915)?
<kylem> yes, just use -intel...
<bryce> kylem: btw, did you get a chance to put the discover-data upload in?  I noticed I'd listed 'feisty' in the changelog and uploaded a fixed version
<ajmitch> useful, no doubt it's better than last time I used it, when it broke compiz :)
<kylem> not yet. was going to leave it until tomorrow. guess i can do it now.
<bryce> no hurry
<bryce> ok, getting called to dinner.  bbl
<mjg59> bryce: We discussed this in London
<mjg59> bryce: The solution is pretty straightforward, but it needs some code adding to gnome-settings-daemon
<lifeless> kylem: thanks
<kylem> no problemo.
<lifeless> kylem: xrandr --auto is love
<kylem> lifeless, lol.
<lifeless> I like things that just work.
<lifeless> :)
<LongPointyStick> pkern_: it means you need to see !uvf, and file an exception for anything you want synced.
<LongPointyStick> i *wish* kmos would stop giving out wrong information.
<ajmitch> heh
* RAOF is looking forward to lifeless' presentation :)
<ajmitch> what's he presenting?
<RAOF> How to write fast python
<ajmitch> interesting
<RAOF> Indeed.
<RAOF> Hence the 'looking forward to it' :)
<ScottK> Step 1: Get someone other than ScottK to write it.
<bddebian> haha
<lifeless> huh
<jml> RAOF: when/where's this presentation?
<RAOF> jml: SLUG, this evening.
<jml> RAOF: man I wish I could live in a city.
<RAOF> Heh
<ajmitch> hobart not enough of a city?
<LaserJock> city? who wants a city?
<ajmitch> jml: come on, I'm in dunedin :)
<Amaranth> RAOF: record it
* RAOF doesn't have any form of recording equipment.
<lifeless> jml: come to sydney then
<lifeless> it will be recorded anyway I expect by the slug av folk
<jml> lifeless: I'll look out for it.
<sponix> can I gripe here ?
<nixternal> nope
<nixternal> this is a development channel, griping won't get you far around here
<LaserJock> sponix: maybe a bug report might work?
<sponix> apt-get install vsftpd <enter> "The following packages will be REMOVED:  gadmintools gproftpd proftpd proftpd-mysql proftpd-pgsql"
<sponix> why can you have 5 flavors of web server installed, but only one ftp daemon flavor ?
<sponix> is it against the law to run proftpd on 65534 and vsftpd on inet port 21 ?
<LaserJock> sponix: must be the dependencies
<sponix> vsftpd has _no_ deps
<infinity> No, all ftp daemons conflict.
<sponix> minus glibc
<infinity> As do all MTAs.
<infinity> Etc.
<nixternal> yup
<sponix> but now webservers ?
<RAOF> No, for some reason.
<sponix> s/now/not/
<infinity> http daemons are the odd one out here, due to many requests to allow multiples (for things like using lighttpd to server static content and apache to serve dynamic)
<infinity> s/server/serve/
<sponix> how do I give it the "force-it-you-biatch" flag, to keep it from nuking my other pkg while installing ?
<sponix> well, vsftpd for anon && proftpd for pr0n !
<infinity> proftpd does anon quite well too...
<infinity> And does vhosting...
<RAOF> You'd pull the source package, remove the conflicts:, and rebuild.
<infinity> Not sure why anyone would really want more.
<sponix> infinity:  I know, but vsftpd is a bit lighter for that
<infinity> But, yes, you could rebuild one of the source packages to not Provide and Conflict ftp-server.
<infinity> sponix: If proftpd is already running anyway, I'm not sure what's heavy about having it bind to two ports and have it serve anon on one.
<sponix> hmm, apt-get build-dep vsftpd ?
<infinity> Seems heavier to run two daemons.
<RAOF> apt-get source vsftpd
<sponix> infinity:  because its not what I _want_ *Grin*... Thats what t3H LuNiX is all about, it does what I fsck'n want it to
* RAOF wonders idly why aptitude doesn't provide a "get the source package" option.
<sponix> I still wonder why aptitude exist in the first place
<RAOF> Because it's your one-stop apt shop.
<infinity> sponix: Ahh, but it only does exactly what you want if you build it yourself, really.
<sponix> ls
<sponix> ha.. oops :P
<sponix> when I suck it down with that apt-get source vsftpd does it apply the patches, or do I need to do that ?
<nixternal> you need to apply the patches
<sponix> Duh, it says it .. never mind
<RAOF> nixternal: What??
<infinity> See, and I just realised which "not a support channel" channel we're in, too.
<sponix> nixternal:  sorry... it says that it applied the diff
<nixternal> oh, the diff..I was thinking debian/patches..sorry
* RAOF was about to search the wiki for a building-from-source package page, and be done with it.
<sponix> infinity:  yeah... I appreciate the help, and I'm sorry to take away from devel for my petty prefs ;)
<sponix> RAOF:  good idea... thanks for the help
<RAOF> sponix: https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff?highlight=%28debdiff%29 minus the debdiff part should do.
<infinity> sponix: apt-get install devscripts fakeroot ; apt-get source vsftpd ; apt-get build-dep vsftpd ; sed -i -e 's/ftp-server//g' vsftpd-*/debian/control; (cd vsftptd-* && dch -i && dpkg-buildpackage -rfakeroot -uc -us -b)
<sponix> RAOF:  RTFM ! *Grin*
<infinity> sponix: There.  Now we can stop talking about it.
<sponix> infinity:  that was above and beyond the call of duty. Especially since you think I'm a tard for wanting multiples ... Thanks a ton though
<infinity> sponix: Don't feel too bad, I think everyone's a "tard"... There's a reason they don't let me lurk in support channels.
<beuno> the parameter could be called 'args' inside the method as it is in the
<beuno> caller and have a better docstring.  I can fix that and merge it if
<sponix> aye, how long as the Redhat cluster suite be in the repos ?
<beuno> er, wrong window  :D
<infinity> sponix: Since before dapper.
<sponix> just noticed it yesterday
<StevenK> infinity: libnss-db!
<sponix> Now if they just port the AD && coolkey stuff I'll be all set
<infinity> StevenK: Never heard of it.
<StevenK> infinity: Hmph
<infinity> StevenK: I'll clear that off my TODO tonight.
<infinity> StevenK: I've got a lull in OMG URGENT stuff, finally.
<StevenK> infinity: *nods* Just want a "Okay, looks fine." or a "Uh, this is broken." and I'll fix it or upload it.
<Chipzz> infinity: actually, devscripts is (knowingly) missing a dependency on some perl package for dch to work properly (as an aside ;))
<YokoZar_> Which is correct for a control file:  libncurses5-dev | libncurses-dev [i386]   or  libncurses5-dev [i386]  | libncurses-dev [i386]   -- I want neither on non i386
<infinity> YokoZar_: The latter.
<YokoZar_> infinity: thanks
<siretart> iwj: sure. btw, the comment in the 2nd hunk of debian/rules is a bit confusing. The cryptsetup binary isn't statically linked, is it?
<Tonio_> hi
<soren> noah__: Thank you very much!
<TomaszD> does anyone know why the translations for xdg-user-dirs are not picked up at all?
<pkern_> LongPointyStick: I thought uvf is for new upstream revisions and not Debian revisions?
<asisak> ArneGoetje: I was told you might help me to handle bug 119588. It is not pressing at all, but I look for someone who can take care of this eventually.
<ubotu> Launchpad bug 119588 in ubuntu "Wrong rendering of Arabic characters" [Medium,Incomplete]  https://launchpad.net/bugs/119588
<ArneGoetje> asisak: I'll have a look
<asisak> Thanks, ArneGoetje. Feel free to assign the bug to the right person.
<seb128> ion_: hi, do you get bug #135650, could you try to get a valgrind log?
<ubotu> Launchpad bug 135650 in gimp "GIMP crashes when trying to resize an image." [Medium,Incomplete]  https://launchpad.net/bugs/135650
<iwj> siretart: You're right, that comment is confusing.  It's statically linked _against libcryptsetup_ but dynamically against external libraries.
<ArneGoetje> iwj: could you please review https://wiki.ubuntu.com/MainInclusionReportLibhangul for me? Thanks. :)
<iwj> ArneGoetje: Sure.
<siretart> iwj: I can confirm that your test package didn't blow up my system. (but I don't have crypted root, "only" crypted /home)
<iwj> siretart: That's a very helpful report, thanks.
<iwj> I think with another quick test here I should be able to upload it.
<ulaas> would like to report a scsi problem with gutsy tribe5 alternate install. this should be the right place, correct?
<Amaranth> ulaas: http://bugs.launchpad.net/ubuntu
<Ng> is the output of the scripts in /etc/acpi/ sent anywhere when, for example, sending&resuming?
<seb128> Riddell: is that ok to upate icon-naming-utils to 0.8.6? The new version fixes some icon themes we have at the moment
<soren> Ng: There's a bit in /var/lib/acpi-support ?
<soren> Ng: What are you looking for specifically?
<Ng> soren: hoping for some output of vbetool post, because it hangs quite a bit atm in gutsy for me
<soren> Ng: Don't think that's stored anywhere. You can disable the vbetool stuff in /etc/default/acpi-support, though.
<Riddell> seb128: sure
<seb128> Riddell: thanks
<Ng> soren: I need to post the card or I don't get the backlight, but sometimes it hangs and eats CPU (LP #134868)
<ubotu> Launchpad bug 134868 in vbetool "100% cpu on resume" [Undecided,New]  https://launchpad.net/bugs/134868
<iwj> ArneGoetje: Approved, thanks.
<Ng> soren: but I can add some more debugging myself I guess :)
<Kopfgeldjaeger> ho
<soren> Ng: Ah, I see.
<soren> Ng: It doesn't happen on my X40, FWIW.
<soren> Ng: Ah.. I have tweaked it, though.
<Ng> soren: it never happened to me in feisty and vbetool is the same version in gutsy
<soren> Ng: I've set it to do doubel console switching.
<Ng> soren: I've enabled that this morning to see if it helps, but I'd never needed it before. in feisty the acpi stuff on this machine was 99% reliable, certainly moreso than windows
<soren> Ng: Did you use the -intel driver in Feisty, too?
<Ng> soren: yes, the i810 didn't like resuming very much, I found
<Ng> +driver
<soren> Ng: Ok... I don't remember if I enabled the double console switching already back then, actually.
<soren> Ng: Feisty was fine for me with i810.
* soren -> lunch
<Ng> soren: 8086:3582 for your graphics chip?
<soren> Ng: Yup.
<iwj> ogra: I have to say that reworking this cryptsetup main inclusion report hasn't given me a very good feeling about any similar reports from the same author in the future.  I've found a couple more falsehoods in it and it doesn't really seem like the package was investigated during the preparation of the original report.
<ogra> iwj, well, that was a very old one, done with the old copy and paste habit, sorry for that
<ulaas> zul, u around?
<iwj> ogra: I don't think "the old copy and paste habit" is and excuse for multiple false statements, really.
<iwj> s/and/an
<ulaas> if anyone is interested about bug 127872 . i have a system with the same bug/scscichipset. and have time to get debug info from installer?
<ubotu> Launchpad bug 127872 in linux-source-2.6.22 "scsi drives not detected " [Undecided,Incomplete]  https://launchpad.net/bugs/127872
<ogra> iwj, what are the fals statements ? i have the first iteration of the doc open ...
<iwj> That there are no binaries running as root, for example.
<ogra> (there are not many statements at all)
<ogra> ah
<iwj> I don't know what the Debian BTS looked like when you wrote the report but by now I wouldn't say that "maintainence in Debian is good" without further qualification.  If you look at the Debian BTS and at LP it's clear the package has some "issues".
<ogra> well, form an update pov its well maintained
<iwj> I just wanted to point out that the next time I read a review from the same author I might treat the assertions in it with a bit more scepticism than I would hope would be necessary.
<iwj> And because of that I have to do more work myself and it may not always be at the top of the queue.
<ogra> and i see two oustanding bugs marked as important and one in pending upload
<iwj> Did you read the one about the data loss ?
<ogra> no, at least there is no bugtitle indication something like that anywhere
<iwj> 428288
<ogra> and i would expect such a bug to be tagged important, which it obviously isnt
<iwj> My point is that if I can't rely on the report author to have done the research then I have to do it myself.  That's not really the role of the approver, for obvious reasons.
<ogra> right
<iwj> So next time I will expect you to understand why perhaps your report doesn't go straight to the top of the list.
<ogra> i'll try to be more careful with future reports ... this was actually one i added really from the template since i had discussed it in person with pitti before
<iwj> As I said just ^ up there, copying text from the template is no excuse for inclusion of false statements.  The one about no binaries running as root is a cut-and-dried example.
<ogra> you will very likely get a new moodle report from me for gutsy if the edu team gets the package ready
<ogra> i'll try to make that as good as i can ;)
<iwj> Now if it were just that one little slip in an otherwise thorough review then I wouldn't be so bothered but that's not the case.
<ogra> well, that was the report you started to change the policy for ...
<ogra> and i didnt touch it after you rejected it ...
<iwj> Are you asserting that the previous policy was to encourage the inclusion of false statements in MIRs ?!
<ogra> no, but it made it easy to let one statement slip through
<cjwatson> surely we have had this discussion about MIR policy at length before, and established that Ian was just making it clearer
<ogra> which cant happen witrh the new tmplate
<iwj> Well I think that as the review author you ought to take responsibility for that.
<ogra> cjwatson, right, and that was actually the last MIR i wrote personally
<ogra> iwj, i will do that if i write my next one
<iwj> I see, well, I hope you'll forgive me if I still take a somewhat sceptical approach to the next one.
<ogra> iwj, no, i actually appreciate that, simply as a selfcontrol mechanism :)
<iwj> Thanks.
<seb128> mjg59: bug ##136346 for you probably
<seb128> bug #136346
<ubotu> Launchpad bug 136346 in gnome-power-manager "gutsy: g-p-m 2.19.6-0ubuntu4 breaks brightness control" [Undecided,New]  https://launchpad.net/bugs/136346
<iwj> cjwatson: So I think I've finished rewriting this review report but I was wondering if you would like to quickly look over the report and give me a second opinion ?   My view is that we probably ought to include it despite the fact that it does have some problems.
<iwj> cjwatson: https://wiki.ubuntu.com/MainInclusionReportCryptsetup is the wiki page.
<cjwatson> iwj: looking
<EtienneG> hey guys
<EtienneG> 6.06.2 is advertised as being due today, 2007-08-31
<cjwatson> EtienneG: where? we changed that
<EtienneG> I have not heard much about it ... just curious if we are going to make it
<cjwatson> pushed to next month
<EtienneG> cjwatson, https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
<cjwatson> I'll correct that, thanks
<cjwatson> (as soon as I dig up the new date)
<EtienneG> cjwatson, thanks, would like to know the new date
<cjwatson> EtienneG: https://wiki.canonical.com/Ubuntu6.06.2
<cjwatson> ha, it's a bit out of sync though
<EtienneG> cjwatson, thanks a lot !  who's the release manager for that one ?
<cjwatson> fixed
<cjwatson> pitti
<Fujitsu> Yay, secret documents.
<cjwatson> (on holiday atm)
<cjwatson> Fujitsu: the date in the public URL noted by EtienneG is up to date now
<Fujitsu> Ah, good.
<cjwatson> the full list is private at the moment because an awful lot of the drivers for the specifics of 6.06.2 are Canonical partners of one kind or another
<EtienneG> cjwatson, sorry for bugging you during your holiday.  Not get away from the computer !!!  :)
<EtienneG> s/Not/Now/
<cjwatson> EtienneG: I'm not on holiday; pitti is
<EtienneG> cjwatson, ok, sorry then!
<EtienneG> he is having a well-deserved one
<Chipzz> cjwatson: got a second to look at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/125247 ? should be just applying :)
<ubotu> Launchpad bug 125247 in vim "Apache config files in /etc/apache2/sites-available and /etc/apache2/sites-enabled do not alwyas have proper syntax highlighting" [Undecided,Triaged] 
* Hobbsee waves to EtienneG
<cjwatson> Chipzz: sorry, no; I think somebody else has touched-it-last-maintainership of vim by now ;-)
* EtienneG wave to Hobbsee back !
<Hobbsee> :)
<soren> Chipzz: That would be me.. :/
<soren> Chipzz: Oh, but I'm not core-dev. :)
<Chipzz> soren: not important really, but is an easy fix, and it didn't get triaged yet though
<Mirv> mjg59: hi, vbetool / libx86 debug output has now been going for ca. 7 hours, and the log file is 100MB. just because I don't know anything about instruction dumping works, is it sure other processes don't matter? ie. it only logs whatever the vbetool is doing? I'll let it be probably for this evening and night still.
<mjg59> Mirv: Ok, once it's got that big it's /probably/ ok to stop it
<mjg59> But yes, it'll only dump what vbetool is doing
<Mirv> I'm yearning for the crash to happen :)
<mjg59> Could you gzip what it's done so far and attach that to the bug?
<kleinernik> hi, i want to help with bugfixing, i found a bug on lunchpad and i think i have got a patch to fix this bug. i uploaded this patch to lunchpad. it is not an important bug, but for me it is a good starting point. can anyone help me, i don't know what to do next, i.e. how to find someone to prove my fix and point out what are the next steps ..
<Hobbsee> kleinernik: you might want to see https://wiki.ubuntu.com/MOTU/Contributing
<kleinernik> Hobbsee: thank you
<mjg59> Mirv: Though, ideally, it would be better if we could wait for it to actually crash, yeah
<soren> Could someone please upload http://people.ubuntu.com/~soren/upload/dovecot/ for me?
<seb128> Hobbsee, soren: does the goocanvas exception is also granted for pygoocanvas? ;)
<Hobbsee> seb128: yes
<zul> soren: sure
<zul> soren: its ok to upload this one?
<seb128> Hobbsee: thanks
<iwj> cjwatson: Did you have an opinion about cryptsetup ?  If you're too busy I can ask someone else or just go ahead based on my own opinion.
<cjwatson> iwj: whoops, sorry. I think it's reasonable for promotion with your changes. Could you file a bug against partman-crypto to note that it needs to forbid mounting a partition that needs cryptsetup on /usr, though?
<StevenK> cjwatson: Since cryptsetup actually lives in /usr?
<cjwatson> iwj: what are we doing about things like bug 105394?
<ubotu> Launchpad bug 105394 in cryptsetup "Upstart needs some key pressed to show "Enter Passphrase" on boot /  cryptsetup problem" [Undecided,New]  https://launchpad.net/bugs/105394
<cjwatson> StevenK: libraries it uses apparently
<StevenK> cjwatson: Which is fair enough. Avoiding chicken and egg problems is good.
<cjwatson> iwj: bug 90914 has a patch which looks perhaps helpful in part
<ubotu> Launchpad bug 90914 in cryptsetup "initramfs cryptroot usplash support" [Undecided,Incomplete]  https://launchpad.net/bugs/90914
<seb128> Riddell: how do I get flash non free being used by konqueror?
<Riddell> seb128: settings->configure konqueror->plugins->scan for new plugins
<Riddell> assuming you have it installed somewhere it's searching
<Riddell> although it should do that on startup anyyway
<seb128> utch
<Riddell> oh, it does it at KDE startup, which I guess means not for you
<seb128> 5 Configure items in the settings menu, KDE is impressive :p
<Riddell> horrific isn't it
<Riddell> one day I'll fix that
<seb128> no plugins in the configure konqueror
* seb128 installs konqueror-nsplugins
<StevenK> cjwatson: Shouldn't the patch use usplash_write if $count -gt 3 at the end instead of just echo'ing?
<iwj> cjwatson: 105394> I don't think we're doing anything about it :-/.  I haven't tested that setup myself but I imagine one response would be `use luks' although of course we don't know if luks is affected too.
<iwj> cjwatson: 90914> Yes, perhaps.
<seb128> Riddell: flash works fine in konqueror for me
<iwj> cjwatson: I think really the package needs some maintenance in Ubuntu but the question is really whether to put it in main now.
<Riddell> seb128: with the current gtk or a patched one?
<seb128> Riddell: current gutsy
<seb128> I was trying to get the bug to fix it
<seb128> but not way
<Riddell> seb128: oh, that'll be our patch we added which adds a dependency on gtk
<iwj> cjwatson: I think I'll call myself the maintainer of the package but I don't propose to fix it up very much for gutsy.  It really needs rather more invasive changes which ought to be done earlier in a cycle.
<seb128> Riddell: oh, you did use the workaround?
<iwj> cjwatson: So, err, thanks.
<Riddell> seb128: for now, but obviously I'd much rather have a workaround in gtk than have konqueror depend on gtk and do the workaround for it
<Riddell> seb128: you'll need to downgrade to 4:3.5.7-1ubuntu15 or earlier, or just use opera
<iwj> cjwatson: partman-crypto> bug 136382
<ubotu> Launchpad bug 136382 in partman-crypto "disallow encrypted separate /usr" [Undecided,New]  https://launchpad.net/bugs/136382
<Riddell> asac: any idea what bug 136376 is all about?
<ubotu> Launchpad bug 136376 in flashplugin-nonfree "automatic update for mozilla-flashplayer make using flashplayer impossible" [Undecided,New]  https://launchpad.net/bugs/136376
<gnomefreak> ok here is good too ;)
<Hobbsee> Mithrandir: could you give back krusader on all arches, please?
<Mithrandir> Hobbsee: given-back
<Hobbsee> Mithrandir: thankyou :)
<asac> Riddell: looks like the alternative is no installed for firefox
<StevenK> Mithrandir: libzzip-0-12 and libzeroc-ice-cil can be NBS'd out of the archive at your leisure.
<StevenK> infinity: Ping, you said tonight.
<Mithrandir> StevenK: I'm on too bad a line to want to do any non-urgent archive work, but thanks\.
<Mithrandir> s/\\//
<StevenK> Mithrandir: Meh, whenever
<Mithrandir> yeah, sorry. :-/
<Mithrandir> just being on the wrong side of the atlantic.  It's not as bad as being in .au, but getting there.
* Hobbsee snorts
<StevenK> You're helping, Mithrandir, really.
<StevenK> :-P
* Hobbsee pokes Mithrandir in the ribs repeatedly.
<bddebian> Heya
<asac_the_2nd> Riddell: ok on amd64 its completely broken... the alternative just points to the wrong file ... e.g. the 32-bit one.
<StevenK> Mithrandir: Have you got a sec to poke at kxdocker?
<Hobbsee> StevenK: what about it?
<Hobbsee> StevenK: it's gone, isnt it?
<Mithrandir> StevenK: what kind of poking?
<StevenK> It's marked superseded
<StevenK> But what about kxdocker-data?
<Hobbsee> StevenK: it's been removed, iirc
<Hobbsee> that should have been gotten in the removal request
<Hobbsee> hmm, seems its' a separate source
<StevenK> Yup.
<StevenK> But so it has.
<StevenK> Mithrandir: Do you want a bug to kill kxdocker-data?
<Hobbsee> seb might be able to do it, he's on a more stable connection
<Mithrandir> StevenK: please, or just get seb to do it.
<seb128> StevenK: it needs removal?
<Hobbsee> seb128: yes
<seb128> rational?
<Hobbsee> seb128: "because i said so"
<seb128> Hobbsee: well, just a small rational for the removal text would be nice
<StevenK> seb128: It's data files for kxdocker, which was killed before and has been broken since Edgy
<Hobbsee> seb128: there's one, right there :P
<seb128> like superceded, or not maintained upstream, or ..
<Hobbsee> seb128: because kxdocker got removed to brokenness, and someone forgot to ask for removal of both
<seb128> Hobbsee, StevenK: removed
<Hobbsee> thanks
<Hobbsee> seb128: really, "because i said so" is a perfectly valid reason...
<bddebian> Hell have no fury....
<StevenK> Actually, it's 'hath'
<seb128> Hobbsee: right, double checking doesn't hurt though and I like to do things because I agree and not because I've been told to do them ;)
<bddebian> I know.. I couldn't think of the spelling atm.. :-(
<Hobbsee> seb128: i know :)
<bddebian> Hell hath no fury like a woman with a point stick!.. :-)
<Hobbsee> seb128: coerced.  with Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<Hobbsee> es
* seb128 runs away from Hobbsee
* Hobbsee chases after seb128
<bddebian> Damn I'm having a hard time getting motivated again.. :-(
* Hobbsee pokes bddebian with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  to motivate him
<bddebian> Gah, sorry, wrong channel
* bddebian cowers back to -motu
<Hobbsee> bddebian: you can run, but you cant hide..
<Mithrandir> bddebian: but she's very tickly.
<bddebian> Heh
<StevenK> But tickling Hobbsee is dangerous for one's ribs
<maswan> StevenK: you need a long pointy stick of tickling then?
<bddebian> Hobbsee: Are you coming to Boston?
* Hobbsee stomps on Mithrandir's feet
<StevenK> maswan: Or a straightjacket
<bddebian> hah
<Hobbsee> bddebian: perhaps.  we'll see.
<Hobbsee> StevenK: yes, you've finally learned this, it seems :P
<Hobbsee> Mithrandir: you shouldnt give away my secrets like that
<bddebian> I can't decide whether to go or not..
* ScottK is poindering the same question.
<bddebian> ScottK: Where are you?
<ScottK> Outside Baltimore, MD, USA
<Mithrandir> StevenK: I'll hold her, and you can tickle?
<bddebian> Oh crap, you are closer than me then :-)
<ScottK> bddebian: Where are you?
<Riddell> asac_the_2nd: flashplayer-nonfree in feisty is broken?
<bddebian> ScottK: Close to Philly
<Hobbsee> Mithrandir: you do that, and i'll beat both of you.
<asac> Riddell: huh ... is this bug for feisty?
<StevenK> Mithrandir: Works for me :-)
<Mithrandir> Hobbsee: we can throw you into the harbour, like a bale of tea, then?
<ScottK> bddebian: Philadelphia is closer to Boston than Baltimore....
<bddebian> Really?
<Hobbsee> Mithrandir: no, i dont think so
<ScottK> Yeah.  I'm south of you.
* bddebian obviously flunked Geography :-)
<nixternal> haha
<nixternal> ya, you have about a 1.5 hour lead time on baltimore silly :)
<ScottK> About two hours driving in good traffic depending on where in Philly and how close.
<bddebian> Well I'm an hour or more NW of Philly
* ScottK went to University in Philadelphia in a previous century.
<nixternal> oh ya, I forgot turnpike traffic is nuts around philly
<nixternal> but I prefer philly turnpike traffic over nyc turnpike traffic
<Hobbsee> Mithrandir: something tells me you'd be a little too wounded to do that
<bddebian> It's soo close I'd like to go but I have no idea what I'd bring to the table so I dunno..
<Riddell> asac: I don't know, I could be wrong on that
<asac> Riddell: honestly, I can't get much our of that bug report ... when was the last flashplugin roll-out we did?
<nixternal> haha, Mithrandir is trying to recreate the Boston Tea Party with a barrel of LongPointyStick
<nixternal> :p
<Mithrandir> indeed.  The Ubuntu Tea Party will be great.
<nixternal> hahaha, nice
<asac> Riddell: he claims that he just received an update ... i don't understand that ... maybe he is talking about something different? some third party extension?
<bddebian> Not nearly enough caffeine in Tea for nixternal
<nixternal> nope, need a couple of starbucks red eyes for me
<StevenK> seb128: Do you mind also killing libapache-mod-lisp; Apache 1.x only, Debian bug #431034
<ubotu> Debian bug 431034 in ftp.debian.org "RM: libapache-mod-lisp -- ROM; obsolete; FTBFS" [Normal,Open]  http://bugs.debian.org/431034
<bddebian> StevenK: File a bug ya lazy bum.. ;-P
<StevenK> bddebian: Hmph
<seb128> StevenK: done
<StevenK> seb128: Danke
<Riddell> asac: nothing very recent according to https://launchpad.net/ubuntu/+source/flashplugin-nonfree
<Riddell> asac: I've no idea what the mozilla-flash is he's talking about
<asac> yeah ... his description is just confusing and just guesswork. Lets wait for his answer.
* Hobbsee ponders this MOTU interview request
<Hobbsee> should make asac do it, instead of me.
<asac> huh?
<asac> Hobbsee: i think you are perfect for that :)
<Hobbsee> asac: behind motu interviews.  yo ushould do one
<Hobbsee> asac: bah.  i manage to have far too high a profile, even without doing interviews.
<Hobbsee> asac: besides, what i'm wokring on keeps changing
<bddebian> Hobbsee: Well that's better than working on nothing like me :-)
<asac> bddebian: i have some work ... fix flashplugin-nonfree package for real :)
<bddebian> What's wrong with it?
<asac> well ubuntu5 - which you sponsored ;) - caused some mess ... now that i looked at it i saw that it messed up the target path of the amd64 alternative
<gnomefreak> bddebian: might be better to ask what isnt wrong with it
<asac> in ubuntu4 it pointed to the npwrapper.libflashplugin.so file in /var/lib/...
<asac> now it points to the 32-bit binaries
<asac> but i am not sure if the regression slipped in in ubuntu5 ... might have slipped in later as we are already at ubuntu8 :)
<bryce> mjg59: I must have not been in the discussion in London about the font sizes (or my memory is failing me).  Was someone going to be adding the code to gnome-settings-daemon?
<bddebian> Egads
<seb128> bryce: what code?
<bryce> seb128: don't know, mjg59 referred to adding some code
<mjg59> bryce: Sorry, no, not the font sizes
<mjg59> bryce: The display hotkey stuff
<bryce> ahh, yes
<mjg59> Something needs to catch the keycode and run xrandr --auto
<Amaranth> oh, this was the bug filed against metacity and compiz and assigned to seb128
<bddebian> I don't have an amd64 though.  Wanna send me one to test with? :-)
<bryce> ok I do remember that.
<Amaranth> if someone adds it to metacity we can add it to the integration stuff so compiz gets it too
<seb128> bryce, mjg59: it's on my list of changes, I'll do it next week
<bryce> awesome
<gnomefreak> bddebian: i tried that excuse already ;)
<bddebian> heh
<mjg59> I suspect it makes more sense in gnome-settings-daemon than metacity/compiz
<Amaranth> mjg59: true
<seb128> yes
<bryce> btw, things are looking fairly good for including the latest -ati, which has xrandr 1.2 support and theoretically could enable hotplug projectors for all ati cards
<mjg59> bryce: The font size issue is separate. The server is caluclating DPI information now, which GTK is using. Sadly, it seems to be somewhat insane stuff.
<mjg59> bryce: I suspect that hardcoding it to 100 would do
<bryce> however in testing we've been finding a few regressions, so doing this change is not going to be without some pain.  However upstream is actively developing so I'm hoping the issues will gain fixes soonish
<seb128> mjg59: it used to be set to 96 dpi and I think we will do that again for gutsy
<bryce> mjg59: yes that's what seb128 and I decided to do.  don't know if the change is in yet
<mjg59> Ok, 96 should work
<seb128> bryce: no, will do that next week as well
<bryce> seb128: ah excellent
<bryce> Amaranth: btw, we're switching the default driver from intel hardware from -i810 to -intel soonish; the one major bug we know of is that Xv video playback in compiz is horked (sometimes?) with -intel.
<Amaranth> bryce: it's always broken
<bryce> however it sounds like Xv playback on -i810 is anyway, and it's more likely we'll see a fix for -intel than -i810
<bryce> s/anyway/iffy anyway/
<Amaranth> bryce: if i had to guess i'd say totem is picking the first offered xv output which is the textured video one but that only works with exa
<Amaranth> but i don't own intel hardware so i can't test
<Amaranth> it'd be stupid for the driver to offer it if it doesn't work
* bryce nods
<bryce> if you have patches or solutions in need of a test, I got one of the dell intel laptops I could run tests on
<Amaranth> someone with intel hardware should check in gstreamer-properties to see what Xv 'devices' are offered
<Amaranth> i don't know how to query for the info directly, i suppose xvinfo
<mjg59> Yes, the first channel will be textured video
<mjg59> 965 has no hardware overlay
<Amaranth> xvinfo | grep Adaptor
<mjg59> So compiz = no xv on 965 on xaa
<Amaranth> mjg59: so we have to use Exa?
<Ng>   Adaptor #0: "Intel(R) Video Overlay"
<mjg59> "have"
<Ng> 855GM
<Amaranth> Ng: right, you're fine
<mjg59> But if you want a composited desktop, yes
<mjg59> 855 has no textured video
<Ng> I don't use compiz, but I want -intel to be default very much :)
<Amaranth> it's apparently only on the 965 since it only does textured video
<mjg59> 915 and 945 have textured and overlay, with textured by default
<mjg59> 965 only has textured
<Amaranth> mjg59: shouldn't the driver just claim to not support any xv adaptors if exa isn't enabled?
<mjg59> Amaranth: No, because it works fine if you're not using composite
<Ng> mjg59: can I bug you about vbetool, or should I go after someone else? :)
<bryce> my machine's only a 845GM, but here's xvinfo and lspci for it:  http://people.ubuntu.com/~bryce/tmp/
<Amaranth> mjg59: how?
<mjg59> Ng: YOu can try
<mjg59> Amaranth: ?
<mjg59> Textured video doesn't require exa
<Ng> mjg59: it seems to be the same version as in feisty, but my X40 is now failing to resume a fair amount, with vbetool eating all the CPU
<bryce> that's without compiz running, I don't know if that makes a difference for xvinfo
<Amaranth> mjg59: I was told the textured video output required exa no matter what
<mjg59> Amaranth: No
<Amaranth> bryce: it doesn't
<Amaranth> isn't Exa really...broken?
<mjg59> If you mean "Is EXA ready for deployment", I suspect not
<bryce> er, that should be 945GM not 845GM.  coffee hasn't reached my fingers yet apparently
<Amaranth> bryce: do you get the bug?
<Amaranth> bryce: from what mjg59 has said only 965 users should have this problem
<bryce> hmm, let me check
<bddebian> asac: BTW is flashplugin the one that you yelled at me for because it's in bzr?
<Ng> mjg59: (134868 in LP. More than happy to do more debugging if I can)
<Amaranth> i wish we could just default to the gl output in gstreamer :)
<mjg59> Amaranth: ? No.
<mjg59> Amaranth: Textured video is the default in 915 and 945
<bryce> I don't recall seeing it, but I can check again
<Amaranth> whee
<mjg59> 16:53 < mjg59> 915 and 945 have textured and overlay, with textured by default
<Amaranth> Drivers are always so messed up :/
<Amaranth> hrm
<Amaranth> i suppose we could add a gdk_screen_is_composited check or something to totem to tell it to use a different video output
<Amaranth> i think totem can override the gstreamer default, anyway
<mjg59> Still leaves 965 broken
<Amaranth> why?
<mjg59> Because it has no overlay hardware
<Amaranth> i meant to tell it to use the non-xv sink
<mjg59> Oh. No, we can't do that.
<mjg59> Performance would be dire.
<mjg59> You wouldn't get any hardware scaling
<Amaranth> ok then, the gl sink
<bryce> yup, I definitely can reproduce the bug here
<bryce> tried on the Experience_ubuntu.ogg video and got a blank screen in totem.  Same with a ripped dvd movie
<mjg59> Amaranth: I suspect that that won't work well either
<Amaranth> oh, but that's in universe
<Amaranth> bryce: blank screen is different
<mjg59> I mean, I could say "Compiz is not ready for production use" again
<Amaranth> bryce: you should get a crash
<bryce> Amaranth: ah
<bryce> no, no crash
<Amaranth> i could have sworn mvo fixed the bug you seem to have
<Amaranth> mjg59: i hate drivers :P
<Ng> while you're talking about 3d stuff and intel chipsets - after a suspend/resume, all 3d textures on my 855GM are replaced with noise (so if you're using compiz, every window is entirely made of random noise)
<Amaranth> apparently no one knew how horrible the new nvidia driver was before switching to it
<Ng> (soren confirms seeing it on his too, fwiw)
<bryce> this laptop is a few days out of date, so if it's a recent fix that may be why.  I'll update and check again
<Hobbsee> night all
<Amaranth> we could always use Xgl... :D
<asac> bddebian: no
<asac> bddebian: maybe gnash?
<bddebian> Oh maybe
<bddebian> I break so many things it's hard to keep track :-)
<bryce>  -> breakfast.  bbiab
<asac> hehe
<ooo>  /server -m irc.master-online.org:12000
<Amaranth> grr
<doko> After unpacking 58.2MB disk space will be freed.
<doko> Do you want to continue [Y/n] ?
<doko> Bus error
<doko> (Reading database ... 25795 files and directories currently installed.)
<doko> iwj: ^^^ on sparc, this is a dselect-upgrade, continues ok after the bus error. which program is it that fails with the bus error?
<iwj> Boggle.
<iwj> This is dselect's apt method ?
<iwj> Or apt's dselect method, or something ?
<iwj> I don't know what that message is from.
<ion_> seb128: Yeah, ive been fighting with gimps internal functionality that catches crashes and prints stack traces. I just cant seem to turn it off. Because of that, apport doesnt detect the crashes and using gdb is difficult. gimp --stack-trace-mode=never doesnt seem to work.
<ion_> seb128: Almost all dialogs do crash without G_SLICE=always-malloc.
<ArneGoetje> doko: sun-java6 deppends on libstdc++5, which is not in gutsy anymore. So, the packages are uninstallable.
<cjwatson> libstdc++5 | 1:3.3.6-15ubuntu2 |         gutsy | amd64, i386, powerpc
<doko> ArneGoetje: it should be, in universe
<cjwatson> not even, it's still in main
<doko> hrm
<ArneGoetje> not on the taiwan mirror, it seems
<ArneGoetje> my aptitude cannot find it
* ArneGoetje is pulling the package informations from the main archive server... pretty slow... :(
<ArneGoetje> ok, found it.
<mjg59> What's responsible for determining which types of block device to automount now?
<ArneGoetje> seems the '++' needs to be escaped when searching for the package name...
<ArneGoetje> doko: do you know which releases use sun-java5 ? the fonts entries there need to be fixed too, I suppose. (except the font packages on older systems have other configurations...)
<doko> ArneGoetje: back to dapper, but I can add different versions of this file for every release if needed
<alex-weej> doko: last week, you sync'd pyopengl from debian unstable. problem is that the version is 3.0 alpha, and i'm getting pretty bad performance out of it. :(
<ArneGoetje> doko: uh... that means I have to try out every release since dapper...
<doko> alex-weej: well, at least it works with python2.5. what are the problems?
<doko> ArneGoetje: well, dapper and gutsy should be sufficient
<alex-weej> doko: i don't know specifically because i don't have any python opengl benchmarks :(
<alex-weej> doko: does 2.0.1 not work with python 2.5?
<alex-weej> https://bugs.launchpad.net/bugs/135736
<ubotu> Launchpad bug 135736 in pyopengl "Serious performance regression from recent update from 2.0.1 to 3.0" [Undecided,New] 
<alex-weej> fwiw, there is an upstream stable 2.0.2 iirc
<alex-weej> oh wait
<alex-weej> maybe it isn't alpha after all :( i must have gotten confused :$
<LaserJock> oh wow, python 3.0a1 is out
<alex-weej> doko: does 3.0.0a6 mean alpha-6?
<doko> alex-weej: I wouldn't mind 2.0.2, but this has to be checked on amd64, not just i386
<alex-weej> doko: 2.0.2 isn't stable, i was wrong.
<alex-weej> doko: also it is only with one specific game (i don't have any other pyopengl apps to test)
<alex-weej> but it is consistent across r300 and fglrx on i386
<alex-weej> doko: how difficult is it to get APT to downgrade a package anyway? if it's easy i guess it's not release critical
<bryce> alex-weej: often it's as simple as just specifying the version.  E.g.:
<bryce> apt-get install xserver-xorg-core=2:1.3.0.0.dfsg-4ubuntu
<alex-weej> bryce: i mean automatically
<alex-weej> for "the masses"
<bryce> ah, nfc
<alex-weej> nfc?
<bryce> no friggin clue ;-)
<bryce> good question tho
<doko> alex-weej: either add an epoch (not recommended when debian doesn't do it), or have something like: 3.0.0a6really2.0.1...
<alex-weej> heh :E
<broonie> In other words, apt will never downgrade without explicit user intervention.
<bryce> oh yeah, epochs
<doko> Source: qt-x11-free
<doko> Version: 3:3.3.8really3.3.7-0ubuntu9
<bryce> *shudder*
<azeem> there should be multi-level epochs
<LaserJock> heh
<LaserJock> that sounds fun
<alex-weej> doko: so what should i do?
<alex-weej> doko: try to find someone on amd64 and see if they get it too?
<doko> yes, that would be best
<alex-weej> anyone here? :P
<bddebian> doko: Is kaffe supposed to include a /usr/lib/kaffe/include dir?
<doko> bddebian: I have no idea about kaffe
<bddebian> Damn, OK, sorry
<bddebian> Hmm, maybe the includes should come from gcj
<bddebian> Weird, there is a /usr/lib/kaffe/pthread/include which is a symlink to ../include but that dir doesn't exist
<bddebian> POS
<bddebian> Ahh, it's in the -dev package
<bddebian> Heh, nice build-deps
* bddebian stops talking to himself
<bddebian> Any archive admins still aboot?
<yatiohi> Hello
<yatiohi> can i install somehow pthread man pages?
<yatiohi> i m new to ubuntu :)
<ScottK> yatiohi: #ubuntu is for help.
<yatiohi> oh, sorry :)
<norsetto> !support | yatiohi
<ubotu> yatiohi: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
<ion_> Could someone please take a look at bug #136439? I reported it and another person set its status to invalid. In my opinion, he didnt understand what im saying and set the status to invalid based on his misunderstanding.
<ubotu> Launchpad bug 136439 in gimp "--stack-trace-mode doesnt seem to work" [Undecided,Invalid]  https://launchpad.net/bugs/136439
<DoctorMO> hello everyone
<DoctorMO> is this a good place to talk about ideas for Hardy Heron?
<LaserJock> DoctorMO: probably not so much
<DoctorMO> LaserJock: drat
<LaserJock> DoctorMO: we're still focused on Gutsy Gibbon
<LaserJock> DoctorMO: best thing I can think of is to do a proposal on ubuntu-devel-discuss or something
<LaserJock> writing up a wiki page spec is also helpful
<LaserJock> if it's it's more than trivial
<DoctorMO> LaserJock: yea, always a case. more than trivial; trivial changes I would impliment and bypass going up stream etc
<geser> ion_: have you tried to talk to pedro_ about it?
<ion_> In the bug discussion, yes. In IRC, no.
<maxamillion> i recently heard that there is a need for a pypanel hacker for ubun2 and i was sent here from #ubuntu-artwork to ask ... is there any validity to this or was i mis-informed?
<decriptor> anyone in here working on XEN
<decriptor> or is there no future for XEN in ubuntu
<kitche> decriptor, looks to me Xen works fine in ubuntu
<decriptor> without having to bootstrap
<decriptor> it
<decriptor> other distros have some xen stuff on the cd so that you can install it as a paravirtualized guest right off the cd
<decriptor> suse seems to be the only one that does this well
<decriptor> with fedora  the only install option is netowrk
<decriptor> ubuntu its you have to bootstrap it
<decriptor> I'm kind of guessing that ubuntu isn't going to seriously support XEN?    more support pushed towards KVM?
<LaserJock> decriptor: XEN is a  big thing for Ubuntu
<LaserJock> we just need people of course
<decriptor> ah
<decriptor> LaserJock: just finding it really hard to find anyone interested in it
<LaserJock> well, that's the nature of the beast
<decriptor> suse seems to have the heaviest develop right
<decriptor> so I'm wondering if others aren't working on it much and moving towards KVM
<LaserJock> they can also pay people to work on it
<kitche> decriptor, of course Xen is big with Novell
<decriptor> does that mean it can't be elsewhere
<kitche> sure it can just not like how Novell does it since Novell knows know Xen works inside and out
<decriptor> true
<decriptor> novell has some big resources working on it
<decriptor> but
<LaserJock> decriptor: so we don't have as much resources
<LaserJock> decriptor: that doesn't me we don't care about XEN
<decriptor> that's not why I thought that
<decriptor> most ubuntu users that I know only talk about KVM
<decriptor> and I get almost no response when asking about XEN
<LaserJock> maybe KVM is just hotter, I don't know
<LaserJock> the fad of the day ;-)
<decriptor> I think you have a very good point in and outside of the conversation
<decriptor> :-/
<PauloZanoni> I added a "script.sh" in the rc2.d directory, its first line contained "#!/bin/bash", but ubuntu was running it as if it were a SH script (not BASH). then, I renamed it to "script" and ubuntu started running it as a BASH script... WHY is ubuntu looking at file name extensions???????
<sbalneav> PauloZanoni: It doesn't
<PauloZanoni> sbalneav: It happened only when the script was at rc2.d ...
<PauloZanoni> there was a link to it there =)
<PauloZanoni> sbalneav: just a correction: the link in rc2.d must have ".sh" in its name for the "bug" to be reproduced
<sbalneav> It's not a bug.
<sbalneav> have a look at /etc/init.d/rc
<sbalneav>        # Debian Policy 9.3.1 requires .sh scripts in runlevel S to be sourced
<sbalneav>         # However, some important packages currently contain .sh scripts
<sbalneav>         # that do "exit" at some point, thus killing this process.  Bad!
<sbalneav>         #[ S = "$runlevel" ]  && sh=.
<PauloZanoni> sbalneav: I see....
<PauloZanoni> sbalneav: isnt the unix philosophy to not look at file names?
<sbalneav> Debian Policy 9.3.1 requires .sh scripts in runlevel S to be sourced
<PauloZanoni> sbalneav: hmmm.... ok, thanks!
<sbalneav> sometimes you may need things sourced, instead of executed separately.
<sbalneav> if you do, you put a .sh.
<sbalneav> it's a well defined policy for rc scripts.
<Kopfgeldjaeger> gn8
#ubuntu-devel 2007-09-01
<FireRabb1t> hey... i just accidently uploaded a packge to upload.ubuntu.come that REALLY should not have been uploaded
<FireRabb1t> where do these files go / how can I get this deleted?
<FireRabb1t> alright according to https://wiki.ubuntu.com/UbuntuDevelopment, anything with an unknown key is just silently ignored.. is there anyone here from Canonical that can confirm this?
<azeem> that's the case, yes
<FireRabb1t> do the files get deleted?
<azeem> I don't know about that
<azeem> I assume at some point they will
<FireRabb1t> azeem: do you know who in here would know?
<azeem> if they know, they will answer
<FireRabb1t> fair enough, thanks :)
<asac> FireRabb1t: should be no problem if your key hasn't the power to upload
<asac> FireRabb1t: of course only if its an accident ;)
<FireRabb1t> yea, it was. forgot the 'local' on 'dput'. :)
<mekius> hey, working on a custom live cd here and have a few questions
<mekius> does the live cd get copied to the hard drive upon install or does the installer use dpkg to install packages?
<LaserJock> the squashfs gets copied
<LaserJock> there aren't any .debs on the live cd
<mekius> ok, i thought so
<mekius> so whatever is on the live cd is pretty much what will be on the installed system?
<mekius> obviously with a different init
<LaserJock> some packages are removed after it's copied
<mekius> ah ok
<mekius> are there any plans to make customization any easier, or any advice on being able to see changes without having to rebuild an iso and load it up in qemu each time?
<LaserJock> mekius: well, there is Reconstructor and Ubuntu Customization Kit GUIs for it
<LaserJock> mekius: and for sure there are some people that would like to make it easier
<LaserJock> but I don't think there is anything specifically in the works right now
<mekius> yeah, but they require rebuilding the iso everytime and testing with qemu, then doing it all over again heh
<LaserJock> well
<mekius> ok
<LaserJock> you don't know exactly what you're going to get until you built the .iso
<mekius> i did see a wiki entry about some people with suggestions, but don't know if anyone started anything
<LaserJock> we even do that for Ubuntu disks
<mekius> well i know with archie, an arch based live cd, they offer a tool that will take a partition and make a live cd out of it
<LaserJock> we build the .isos and test, and if there's a bug or something we rebuild new ones
<mekius> so you can just customize it while it runs and then just pack up an iso
<LaserJock> well, you can kinda do that
<LaserJock> you mount the .iso loopback
<LaserJock> and chroot in
<LaserJock> and you can make changes
<LaserJock> and then get out and repack the squashfs and .iso
<mekius> yeah, right now i've got it unpacked
<mekius> and i chroot in and do some karate and kick shit around, then exit and build a new iso
<mekius> run it in qemu to test it, then rinse and repeat
<LaserJock> yep, sound about right
<mekius> alright, just sucks cause i can't see the effect of alot of my changes until i boot the iso and see something is screwed heh
<mekius> i know it's not easy :)
<mekius> sorry for the rant here heh
<LaserJock> yep, that's pretty much how the Ubuntu devs do it too
<mekius> jumped on to a project and found this method very time consuming :)
<LaserJock> that's about the most easy going rant we've had in here fore a while ;-)
<mekius> :)
<LaserJock> I do know there are other people interested in that kind of thing
<mekius> i try not to completely bash anyone for what they do, i'm sure this works fine for doing small updates, especially when you know the system well
<LaserJock> it's just getting time and resources together to get something put together
<mekius> just hard for someone starting out trying to do things quickly :)
<mekius> yep, i hear ya
<mekius> resources are always an issue in open source :)
<mekius> how many people here work for Canonical?
<LaserJock> I think there's gotta be like 20 or so people for Ubuntu development
<mekius> k
<LaserJock> total
<mekius> thats a pretty good amount :)
<LaserJock> well, depends
<LaserJock> I think it's much smaller than say Red Hat or Novell
<LaserJock> but having paid people definitely helps
<mekius> oh sure
<LaserJock> we have around 80-100 total devs
<mekius> red hat and novell are alot more dug in
<mekius> they have a lot of contracts to take care of
<mekius> LaserJock: you do alot of dev?
<LaserJock> mekius: I do what I can, which unfortunately isn't as much as I'd like :-)
<mekius> yeah :)
<LaserJock> I work mostly on Edubuntu these days
<mekius> ah ok
<mekius> good project, get em while their young :)
<LaserJock> heh, yeah
<mneptok> LaserJock: it's >20 on the distro team
<LaserJock> mneptok: >30?
<LaserJock> I remember when there was 15, but they keep adding people
<mneptok> LaserJock: dunno. i can't keep track of new employees, either.
<mneptok> but i know it's >20
<LaserJock> LP gets the lions-share
<LaserJock> but still, Debian's got ~1000 devs
<LaserJock> gentoo's got 300+
<LaserJock> I'd love to see numbers for RH and Novel
<kylem> redhat has more people working on their kernel than canonical has engineers
<kylem> (exaggeration, but still)
<mneptok> kylem: but none of them have your scintillating criminal record.
<LaserJock> there must be something about "bad boy" kernel hackers ;-)
<kylem> mneptok, shh, i had that pardoned.
<mneptok> pardoned != expunged
<mneptok> you was robbed
<whiprush_> LaserJock: ping
<LaserJock> whiprush_: pong!
<whiprush_> LaserJock: dude, you on im?
<LaserJock> whiprush_: how are you?!
<whiprush_> let's chat
<LaserJock> IRC or jabber?
<whiprush_> jabber
<whiprush_> jorge.castro@gmail.com
<mike>  I am a Vista 64bit Ultimate user, and I would like to transfer over to linux, but so far in 7.04 64bit and 32 dont mesh.  What do you guys recommend?
<desrt> mike; you're in the wrong channel for this type of question
<mike> Which channel then?
<desrt> mike; but if i had to make a recommendation it would be to just run 32bit.  there are not enough compelling reasons to use 64bit for normal situations
<mike> I just figure I ask developers straight up.
<desrt> #ubuntu
<desrt> see topic ^^.  no support question :)
<mike> desrt, who is 64 bit for at this time?
<desrt> mike; people who don't mind the disadvantages of running 64bit
<desrt> basically, anything that comes in binary form (flash player, some video codecs, etc) won't work at all
<desrt> since there are only 32bit versions of these binaries around
<mjg59> flash can be made to work with minimal difficulty
<mjg59> And most of the interesting video codecs are supported by ffmpeg
<desrt> out of process linked against 32bit libc?
<mjg59> desrt: Yeah
<desrt> interesting
<mjg59> nspluginwrapper
<mike> except mpeg avc encoding!
<mjg59> Has the handy side effect that it's out of process
<desrt> mjg59; are there any good reasons to actually use 64bit, though?
<desrt> mjg59; i find flash doesn't usually cause me trouble.  java is another story.
<mjg59> desrt: You can use it to out of process stuff on the same architecture, too
<mjg59> mike: If you want to use stuff where there's no 64-bit codec, then right now 32-bit is a much easier choice
<ScottK> desrt: If you are doing CPU intensive processing using software optimized for 64 bit.
<desrt> mjg59; i'd have imagined that to be the case :p
<mjg59> desrt: Mildly better performance, access to more than 3GB of RAM
<desrt> i'd imagine performance to be mildly worse under common workloads
<mjg59> Nothing especially compelling. I'm doing it so I'm encouraged to fix the bugs
<desrt> the whole 8-byte-pointer thing is a pretty annoying hit to take
<mjg59> Basically every benchmark ever has shown x86_64 to be slightly faster than ia32
<mike> I know this is a stupid question.  But in my Vista Ultimate I can still run 32bit apps on the fly with no hiccups.    I know you probably can't easily answer this.   But why cant my 32bit linux apps play nice inside a 64bit nix OS?
<desrt> are they benchmarking integer math performance or something?
<desrt> mike; they absolutely can
<mjg59> mike: They can, but we don't have the infrastructure to make this easy
<desrt> mike; you can run 32bit linux apps out of the box on ubuntu amd64
<mjg59> desrt: The extra registers help
<desrt> mike; but you need to have 32bit libraries to go with them.... and those don't currently ship as part of the 64bit version of ubuntu
<desrt> mjg59; ahh.  good call.
<mike> I got Intel CD2 at 3.2ghz with 64 bit Ubunut currenlty instaleld.
<desrt> mjg59; i imagine the ip-relative addressing speeds up shared libraries too
<desrt> no more bx-setting thunk
<mjg59> mike: The difficulty in running 32-bit applications on 64-bit ubuntu is a failure on our part
<mjg59> But I don't think anyone's actively working on it right now
<desrt> the best solution is going to involve changes to apt/dpkg
<mjg59> It's all been architected, just not implemented
<mjg59> Tollef wrote his thesis on it, IIRC
<desrt> i guess there would need to be two different sorts of dependencies
<desrt> same-arch (for libraries) and any-arch (for stuff that is merely shelled out to)
<mjg59> We already have that, effectively
<desrt> do tell?
<mjg59> Oh, I see what you mean
<mjg59> Yeah, it would only special case libraries
<desrt> on the other hand you could probably do it in the build infrastructure
<desrt> and generate 3264 versions of all libraries
<desrt> for arch "amd64" but containing 32bit code installed to /lib32
<mike> So apt/dpkg    is only set up currently for one or the other?
<desrt> with some very rare exceptions, yes
<desrt> you either have a x86 system or an amd64 system
<Amaranth> looking for a kubuntu person :)
<desrt> amd64 has some very rare "32bit version" packages like libc
<Amaranth> need to get the patch from http://bugs.kde.org/show_bug.cgi?id=147557 in
<ubotu> KDE bug 147557 in general "When using compiz, the "Server List" window widgets do not appear, and the window cannot be closed..." [Crash,Resolved: fixed] 
<desrt> you can build and install more of them yourself but you're basically on your own for it
<mike> How come in Synpatic after adding the repository for something like Skype, how come and wont let me download and install it?
<desrt> because skype is a binary for which only a 32bit version is available
<desrt> these are all the reasons you should use 32bit :)
<mike> but mjg59 said that 32bit apps work out of the box in 64bit.
<desrt> mjg59; do you know if there is some way to run the CPU in 64bit mode with the exception of pointer-size?
<mjg59> desrt: Not to the best of my knowledge
<desrt> so you can get access to extra instructions/registers...
<mjg59> mike: No, I said they didn't
<desrt> mike; actually, i said that.  and it's true.  but the way debian packaging works won't allow you to do it.
<mike> my ba
<mike> Do you guys use 64 or 32?
<xtknight> 32bit does work on all amd64 CPUs.  the 32bit apps dont necessarily right off, since they need to look for their 32lib libs.  sometimes "linux32 prog" will help.
<desrt> mike; and if you wanted to install skype for yourself (outside of the packaging) you'd have to build a lot of libraries for it first
<xtknight> otherwise put libs from i386.deb into (use "mc" to get files out of a deb) /usr/lib32/
<desrt> i use 32bit because i don't feel like dealing with the hassles.  mjg59 uses 64bit because it's his job to fix the hassles. :)
<desrt> (for a rather loosely defined meaning of "job", admittedly...)
<mike> Are you guys the actually developers ofr Ubuntu?
<desrt> some of us more than others.  me, not so much :)
<xtknight> i'm only a user
* desrt does odd ubuntu work here and there but spends more time working on gnome directly
<mike> what about mjg59?
<desrt> oh.  he's elite.
<desrt> if you have a laptop, he's the reason that it works
<mike> He is the man?
<desrt> no
<desrt> he's actually three men
<mike> wow
<desrt> ya.  seriously.
<mneptok> and a baby
<mike> props to you mjg59
<mneptok> and a hydra
<LaserJock> mike: he's on the Ubuntu Technical Board ;-)
<LaserJock> or at least I think he still is
<mike> Now tell me the truth do you guys use Vista or OSX?
* desrt uses osx to install firmware upgrades on his macbook
<mike> or true nix users?
<LaserJock> I use OS X a lot, never even seen Vista
<desrt> (apple doesn't release a firmware upgrader for linux...)
<desrt> other than that i never use either
* ScottK has an old hard drive with Win2K on it somewhere, but hasn't used it other than for customer support in over a year.
<desrt> well, actually... i use macos when i'm trying to fix my sister's broken computer...
* ScottK has seen Vista on someone else's machine and wasn't impressed.
* mneptok gestures fratically at #ubuntu-offtopic
<mneptok> +n
<mike> Vista is nice eyecandy that is bloated out the wazooo
* desrt played with vista in a computer store once while waiting for the clerk to be free
<desrt> i've heard the eyecandy isn't even that nice :p
<mike> better than xp then lol
<desrt> ya... but not as good as macos from 4 years ago
<mike> I really appreciate you guys taking the time to talk to me.
<ScottK> IMO Windows peaked at Win2K.
<ScottK> I will confess to mostly care about reliability, so my perspective is a bit unusual.
<desrt> before they started changing the visual style with every release to make you think that it was new and shiny? :)
<mike> So I guess I should but my 32bit Ubunut and reinstall over my current 64bit one?
<desrt> mike; running a 32bit system is, without a doubt, easier
* ScottK is currently reading a nice blog entry about the MS WGA outage last weekend.
<mike> I swear the only reason I use M$ is cause of games
<desrt> mike; particularly if you're gonna be putting in stuff like skype
<desrt> mike; get a wii.  i hear they're fantastic :)
<mike> x360 for halo 3!  NO comparison
<mike> i got a ps3 too
<desrt> use them :)
<mike> modded xbox
<desrt> my aunt and her boyfriend got me to ubuntu them up a few months ago because they were sick of the crap with windows
<desrt> his games ran like crap on ubuntu so he just stopped playing them eventually
<desrt> then he bought a wii and is happier than ever :)
<mike> What about adobe equivilant products.  Nice WYSIWG alternative.      Premier, Macromodia ?
<desrt> nothing yet, unfortunately
<desrt> but i think we'll be seeing a shift from adobe in the coming years..
<desrt> fortunately, most "home users" don't use that stuff
<ScottK> For PDF the tools are actually, IMO, better on Linux.
<mike> I just like having the ability to do anything
<desrt> ya.  evince is fantastic.
<LaserJock> ScottK: yes, way better
<desrt> has windows got a pdf viewer yet?
<desrt> or do you still have to install the adobe crap?
<mike> Windows doesnt even have a native dual pane file manager, errr
<desrt> what happened to fileman.exe?
* desrt remembers the good old windows 3.1 days
<mike> Is there a WIKI for the next Gusty release?
<mike> I would like to see what it offers
<desrt> you can probably get a good idea by reading the release notes for the tribe releases
<LaserJock> it's a bit tough to see, even at this point a lot can change
<desrt> start here: http://www.ubuntu.com/testing/tribe5
<desrt> then read backward tribe4, tribe3, ...
<desrt> it'll give you a good overview of the new stuff that has gone in so far
<mike> Better dual monitor support, sweet.
<desrt> Smooth shutdown splash
<desrt> The splash screen displayed on shutdown no longer flickers briefly to a black screen during the shutdown process. A[A[A
<desrt> thank god :p
<ScottK> There is also https://wiki.kubuntu.org/GutsyGibbon/Tribe5/Kubuntu to consider too.
<mike> Do you test in VMserver are do you do a real install?
<desrt> kubuntu is for chumps :)
<mike> agree
<desrt> mike; to be honest, it's probably reasonably safe at this point to install gutsy tribe on your normal machine
<ScottK> Kubuntu is for people who actually like to have choices ;-)
* ScottK has a real install on a spare hard drive.
<desrt> there may be some bumps, of course.... and there will be lots of updates to download every day... but it probably works OK
<mike> So now if I go back to 32bit, i cause I need to ditch a gb of memory or two that wont be used
<desrt> how much ram do you have in there? :p
<ScottK> How much memory do you have?
<mike> Like I said I got all the power toys
<desrt> you can run 32bit ubuntu with PAE and get access to up to about 64GB
<mike> Was going to build another Quadcore and overclock it, but holding off the see these new 45nm CPUs coming out.
<desrt> i doubt you have more than that :)
<desrt> the limitation is on the amount of memory that a single process can use -- that's 3GB
<desrt> the system as a whole can use more
<desrt> without PAE the most memory that it makes sense to have is 4GB
<desrt> (but a bit of it will be wasted due to memory-mapped buffers of devices)
<kylem> no, you will get the full 4G per process on all our kernels.
<desrt> kylem; on 32bit?  i doubt it.
<mike> Now does linux have a MPEG AVC encoder?   FFMPEG only decodes.    And is there 1337 video editing softweare?
<kylem> ha. whatever. don't listen to me, i don't know anything about this at all.
<desrt> mike; probably not as per your definitions of l33t :)
<desrt> kylem; k :)
<mike> desrt from a surface level, not diving what is under the hood.   Gnome hands down right?
<desrt> mike; i'm biased.
<mike> I notice a couple KDE apps look funny i gnome.   I think I tried k3b, just looked a bit off.
<mike> *in
<desrt> kde and gnome use different toolkits for drawing and different themes...
<desrt> on top of that they have rather different design philosophy and artwork
<desrt> so it can be a bit jarring :)
<RAOF> mike: You'd be after "x264" on the MPEG4 AVC encoding front.  You can build it into ffmpeg, if you want.
<mike> So should I wait until october of stable Gutsy or put 7.04 32bit back on?
<desrt> kylem; erm.... you're someone who should probably know a bit about virtual memory...
<kylem> indeed.
<desrt> so i don't believe you when you say you don't know anything about it
<kylem> it was sarcasm.
<desrt> so correct me
<dobey> kylem: he's canadian. they don't have sarcasm there.
<kylem> as it happens, i know a lot about virtual memory...
<desrt> do you have some sort of a kernel-entry trampoline these days?
<kylem> eh? we invalidate the tlb, it costs us a bit, but it's not a big deal.
<desrt> so you _do_ have a trampoline?
<mike> DL gutsy tribe 5 now.  Great DL speed
<desrt> is that upstream or a patch?
<kylem> upstream. see CONFIG_HIGHMEM4G
<mike> Why doesnt torrent become main stream to DL large files?
<dobey> mike: it has become maintstream
<mike> 600 KB/s and climbing
<LaserJock> mike: cause torrents suck :-)
<LaserJock> at least for some people I guess
<mike> Well I got the download page for trribe 5 and by default it sends me to http link
<dobey> mike: gunzonline.com uses it. blizzard uses it for world of warcraft. etc...
<dobey> it's a pain in the ass though
<LaserJock> it always seems like torrents are soooo much slower than just using http/ftp for me
<mike> If it is main stream then by defualt download link shouldnt link me to the torrent?
<dobey> mike: mainstream doesn't mean everyone uses it by default
<dobey> mainstream merely means "in widespread use"
<minghua> Also less people downloads Tribe releases than final downloads.
<dobey> i think numerous online games using it, pretty much classifies it as "mainstream"
<dobey> especially with world of warcraft being one of those
<minghua> So even if bittorrent is the default link for final release, it makes sense to go back to http/ftp for tribe.
<mike> But does it make sense for the server?
<dobey> the server?
<mike> bandwith placed on server
<LaserJock> like every time we release and the Canonical servers and mirrors get absolutely hammered :-)
<dobey> if you're using bittorrent, there is virtually no bandwidth being used by the server for the download
<LaserJock> yep
<mike> bandwith cost money so I was just wondering about 'mainstream'
<LaserJock> that's why torrents are available
<ion_> Its a pity multicasting hasnt been more popular.
<dobey> bandwisth ~= cost of water, at least in the US :)
<desrt> kylem; everything i'm reading about this HIGHMEM4G tells me that it has nothing to do with virtual address space layout
<desrt> kylem; nothing to do with the kernel/user split, anyway....
<ion_> Id like to order twenty liters of bandwidth.
<dobey> that'll be $0.05
<hile> so how many bits does it fit to one liter
<dobey> depends on what counts as a bit i guess
<dobey> is a molecule a bit or a byte?
<hile> a byte, I'd say
<mike> random question.  What is the  i386 name used for 32 bit desktop edition?    I though 386 was a reference back to 1985 with the 80386 processor
<dobey> hile: so each atom is a bit?
<hile> not so sure
<dobey> or are electrons bits?
<LaserJock> the spin on the electron  is a bit
<RAOF> Hm.  Is there any easy way to install *all* the dbgsym packages for all the packages I have installed?
<mike> randome question #2 how come ntfs-3g made me copy the files over to ext3 partiion before being able to execute/process ?
<kylem> huh, i thought x86 might have joined the 20th century. guess not. loss.
<mike> About to check out tribe 5 here.   Umm.  I got a dilema.   1 blacnk HDD,   2 HDD  has two OS on it;   64 7.04 and Vista Ultimate.      I want to install Gutsy to blank hdd.    But then I would have 3 OS.   i want to get rid of 64bit 7.04
<desrt> kylem; seems not to be the case, in fact :/
<desrt> kylem; i like my syscalls fast anyway :)
* LongPointyStick waves
<Riddell> calc: congratulations
<Amaranth> anyone know how to make apt show it's reasoning for upgrading a package?
<Amaranth> for why it thinks an upgrade is available, i mean
<Amaranth> i have a feeling i need mvo for that one :)
<zasf> cjwatson: goog morning
<geser> Amaranth: apt-cache policy pkgname
<zasf> cjwatson: how do I know if bcm43xx-fwcutter will be in main/restricted and thus shipped with gutsy cd?
<Amaranth> geser: no
<Amaranth> geser: that just shows the weights
<Amaranth> i want to know why it thinks two packages are different and one has a higher weight than the other
<geser> ah
<Amaranth> i've got what i'm pretty sure is a PPA bug
<Amaranth> well, or apt
<Amaranth> need to figure out why it always thinks the remote version is newer than the local version
<Amaranth> no matter how many times you do the 'upgrade'
<geser> ah, that problem
<Amaranth> different than the original, that was fixed
<Amaranth> this is a completely different problem that apparently only i have
<geser> have you checked that the package with that version is only in one repo?
<Amaranth> but it doesn't happen with the same package in the actual archive
<Amaranth> geser: there is an older version of the package available in regular feisty
<Amaranth> otherwise there is nothing else
<Amaranth> apt-cache policy shows 3, 2 dupes of the new one and the old one
<Amaranth> (one is remote the other is local)
<Amaranth> the only thing i can think of is the ~ppa1 bit
<Amaranth> but that doesn't do anything to the other packages i have in there
<geser> wait for mvo or dig in the source code
<Amaranth> i think i'll wait for mvo :)
<Amaranth> my dig into nautilus/libeel turned me off looking at other people's code for awhile
<stgraber> asac: ping
<stgraber> asac: I have spent some more minutes on that open network problem with ipw3945+NM, I checked with ipw3945 without NM and the no-automatic-association (default module parameter) seems to work fine but as soon as I start the NM, it connects to my wired LAN (so it shouldn't do anything with the WLAN card) but also associate to the first open wlan it finds ...
<stgraber> which is I'm pretty sure not a wanted behaviour at all
<Treenaks> same with ipw2200 -- that associates to the first AP it can the moment you load the driver
<Treenaks> (which might be illegal in some places...)
<Amaranth> Treenaks: dude, that is no annoying
<Treenaks> Amaranth: 'no' -> 'so' or 'not'?
<Amaranth> so :)
<Amaranth> before i login i'm on the neighbor's 'linksys' network
<Amaranth> that is illegal here :)
<Treenaks> Amaranth: here it's only illegal if there's a "no access" sign (meaning "it's encrypted" or "the ssid contains words that can be interpreted as such")
<Treenaks> "linksys" and "default" are the new "Welcome" signs :)
<Amaranth> hehe
<Kopfgeldjaeger> hi
<jc-denton> hi all
<jc-denton> in never ubuntu distros disks are always called /dev/sdx
<jc-denton> is that correct
<jc-denton> how can i figure out if the disk behind is ata, sata or scsi
<jc-denton> because i can't enable 32bit io and dma so far
<Nafallo> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<pkern> jc-denton: hdparm -I <dev>
<pkern> jc-denton: That won't tell you the type of disk, but the capabilities.
<pkern> jc-denton: It will also show you which DMA mode is currently used (asterisk). But I don't think that you have to mess with that nowadays.
<cjwatson> whoopsie. sorry for breaking hibernate for everyone. fixed in powermanagement-interface 0.3.17
<whiprush_> meffie: hi
<IntuitiveNipple> cjwatson: Thanks for that :)
<DoctorMO> prod: https://wiki.ubuntu.com/PimSyncPlan
<DoctorMO> I'd like to get feedback on my ideas, something other than 'wow you'd be my hero'
<pygi> DoctorMO, :P
* ScottK was thinking more like, "Who's going to do the work ..."
<LaserJock> yes
<LaserJock> we are full of good ideas that never get implemented :-)
<bluefoxicy> so it looks like Gutsy has totally destroyed the separation of privileges security model on ssh :D
<bluefoxicy> is anyone here running feisty still that can snag me something?
<LaserJock> bluefoxicy: depends on what it is ;-)
<bluefoxicy> LaserJock:  find a pid of sshd, cat /proc/$pid/status | grep CapEff
<bluefoxicy> actually, just grep Cap
<LaserJock> CapInh: 0000000000000000
<LaserJock> CapPrm: 00000000fffffeff
<LaserJock> CapEff: 00000000fffffeff
<bluefoxicy> hmm.
<bluefoxicy> LaserJock:  check dmesg and see if you see something like "Capability LSM initialized as secondary" twice, one late in the boot process (30 seconds or so)
<bluefoxicy> this may not be a gutsy thing (I'm thinking it's the way AppArmor is done right now, but perhaps not...)
<IntuitiveNipple> I only see the one in Fiesty 32-bit "[    2.467828]  Capability LSM initialized"
<LaserJock> [   20.021888]  Capability LSM initialized
<LaserJock> same here, only 1
<bluefoxicy> LaserJock:  that's probably way too late.
<bluefoxicy> when caps are initialized that late in the boot process, any process before them gets full caps (i.e. the whole separation of privileges model used by things like ssh or anything else that drops caps is destroyed)
<bluefoxicy> IntuitiveNipple:  can YOU check to see the CapEff on sshd?  Yours is probably running under something less permissive, I'm guessing...
<IntuitiveNipple> bluefoxicy: The same as LaserJock's
* bluefoxicy hrms.  Checks something out.
<IntuitiveNipple> CapInh: 0000000000000000
<IntuitiveNipple> CapPrm: 00000000fffffeff
<IntuitiveNipple> CapEff: 00000000fffffeff
<bluefoxicy> hmm.  I'm getting the same string after restarting ssh.  Maybe I'm wrong on how this works.
* bluefoxicy will have to examine this more; but holds off on filing a bug.
<bluefoxicy> LJ, IN:  thanks.
<LaserJock> np
<cjwatson> bluefoxicy: ssh doesn't use capabilities as such, just seteuid etc.
<cjwatson> bluefoxicy: I suspect you'll find the sshd network child process still drops its privileges just fine
<bluefoxicy> cjwatson: hmm.  Theo gave a presentation touting the capabilities sep.. oh ok
<bluefoxicy> that's probably working then, since the child process will exec() angd get caps.
<cjwatson> bluefoxicy: you misunderstood the word "capabilities". also OpenSSH people always talk about "privilege separation" not "capability separation".
<bluefoxicy> cjwatson:  they talk about privilege separation using capabilites IIRC
<cjwatson> wrong.
<cjwatson> sshd forks a child which chroots to an empty jail, does setgroups+setregid+setreuid, listens to network communication, and passes sanitised versions of that communication over a simple protocol to the parent.
<cjwatson> so parsing bugs can do much less damage
<cjwatson> that's what sshd privsep means
<bluefoxicy> hmm o.o
<bluefoxicy> I need to research this more.  That seems sane though.
<cjwatson> oh and that process is only used during authentication, so you won't see it hanging around afterwards.
<cjwatson> i.e. no amount of grep Cap /proc/*/status will show anything interesting unless you nobble sshd to hang around during authentication a bit longer
* bluefoxicy wonders what lingering daemons do drop caps these days
<cjwatson> (after auth, the child with user privileges is perfectly good for parsing network data)
<zul> heylo
<ion_> hiho
<ion_> Really nice that xubuntu-desktop switched to gnome-screensaver.
<DoctorMO> LaserJock: yea
<jdong> https://wiki.ubuntu.com/DevelopmentCodeNames
* jdong giggles
<jdong> "Hard Heron with 5 years of support!"
<IntuitiveNipple> You just wait for Grumpy!
* pkern waits for "Antidisestablishmentarian Affenpinscher"..
<IntuitiveNipple> is that a flavour of hog? :p
<IntuitiveNipple> For "I", I'd love to see 'Inquisitive Imp' :)
<alesan> re
<alesan> do you have any idea what is the package for the "logout" button? gnome people told me it is ubuntu-patched
<LaserJock> alesan: boy, I have no idea
<alesan> any idea how to find out? I would very much like to disable the "fading" thing
<ScottK> If I were to guess it would be in gdm, but no promises.
<alesan> ok thanks
<alesan> bye
<gnomefreak> ski would think either gdm or gnome-session
<gnomefreak> gnome-session-manager if not gnome-session
<mike> desrt you here?
<mike> desrt told me to use 7.10 tribe 5, but my monitor res is acting up big time
<asac> stgraber: there?
<stgraber> asac: yep
<asac> cool
<asac> sorry been out for the day ;)
<asac> stgraber: are you still in the same environment (where nm associates with the open-network?)
<stgraber> yes
<stgraber> any idea why NM would associate with the first network it finds even if it's connected to wired and then shouldn't do anything with vlan ?
<asac> good what does sudo iwlist scan give you?
<asac> stgraber: does network-manager know about the first network?
<asac> stgraber: e.g. is it displayed as connected ... or did you find out with ifconfig et al
<stgraber> it's not marked as connected but I can see the associate using iwconfig
<asac> yes ok that makes sense then
<stgraber> my current test is : connect to wired LAN, then kill ipw3945d and unload ipw3945, then reload it
<asac> stgraber: can you explicitly switch back to wired after that?
<stgraber> NM is still connected to the wired LAN but iwconfig shows the association to the open net
<mjg59> asac: I can't associate my ipw3945 with an open network. It seems the driver never sends the association event.
<asac> mjg59: yes for open networks its probably a driver bug
<stgraber> doing the same with NM turned off doesn't automatically associate
<asac> mjg59: however it appears to work better with wpa supplicant ... no idea why its different
<stgraber> asac: what do you mean by "after that", at this point I never disconnect from wired LAN nor asked NM to connect to a WLAN
<asac> stgraber: so you are just associated without ip?
<stgraber> yes
<asac> stgraber: ok then nm didn't receive the association event
<stgraber> I'm connected on my wired network, then load the ipw3945 driver and a few seconds after iwconfig shows an association
<stgraber> but I never asked NM to connect to a wifi network :)
<asac> stgraber: what do you see in logs?
<asac> does nm officially try to bring up the interface?
<stgraber> no
<stgraber> http://paste.stgraber.org/3263
<asac> the logs don't even mention the device?
<stgraber> ^ What happens after the "modprobe ipw3945"
<asac> stgraber: ok ... can you try to explicitly reconnect to the wired network
<asac> then do the driver reload?
<stgraber> exactly the same behaviour, I load the driver, the second after it's connect to an open wlan
<deadchip> is Scott Tankard around maybe?
<deadchip> i've got something for the automated-testing proposals
<deadchip> i'm the upstream maintainer of BMP, and the old XMMS based BMP is proposed for the automated testing stuff, but it's an deprecated app
<deadchip> BMPx has replaced it since a good while from our side, and it would be much better if it would receive the testing instead
<deadchip> it's available in Debian and thus to ubuntu users at the moment through Debian
<deadchip> however I don't want to just change this in the wiki
<deadchip> anyone knows whom i can contact about this?
<deadchip> ermm Scott T. is just the last editor of the page i don't know if he's the guy responsible for this
<ScottK> A link to the page you are discussing wouldn't hurt.
<mhb> yes
<mhb> ScottK: I thought the same thing :o)
<asac> stgraber:
<asac>         /* Device must be up before we can scan */
<asac>         if (nm_device_bring_up_wait (NM_DEVICE (self), 1))
<stgraber> asac: yes, but doing : modprobe ipw3945 + ifconfig eth1 up doesn't associate without NM
<crimsun> deadchip: to which URL are you referring?
<deadchip> crimsun: https://wiki.ubuntu.com/Testing/Suite/Desktop
<deadchip> well i've changed it now, as the edit history showed other people added their apps there, etc
<deadchip> it's really no use at all to add BMP to the testing because upstream (we) won't be making any changes to it
<crimsun> right, that's fine.
<geser> doko: you forgot to change the maintainer field for your last upload of gcc-snapshot to Debian unstable
<deadchip> so everything that would be a potential fix would end with ubuntu developers
<deadchip> ok
<asac> stgraber: what network manager does from what i see is just unsetting the essid to "" ... then scanning
<asac> maybe you get an association if you just do that?
<stgraber> asac: ok, just tried and indeed doing : iwconfig eth1 essid "" makes the card to associate
<asac> ok then its either a feature or a driver bug
<asac> so what issue is left?
<asac> you cannot connect to open networks right?
<stgraber> asac: yes
<asac> ok
<asac> you have nm sources?
<stgraber> asac: and I think that automatic association might be the problem (as it shouldn't be associated and asking NM to connect to a public WLAN doesn't make it associate to the selected one)
<asac> stgraber: nm-device-802-11-wireless.c line 531 533
<stgraber> I think so but I'll have to update them anyway (didn't pull for a while)
<stgraber> asac: ubuntu.0.6.x ?
<asac> there is are association / disassociation event cases there that appear to be not processed
<asac> stgraber: yes
<asac> stgraber: maybe add nm_info("wireless_event_helper - associated event");
<asac> stgraber: and nm_info("wireless_event_helper - disassociated event");
<asac> to see if you get those events
<stgraber> k
<asac> stgraber: while you build ... can you post a log of a connect attempt to open network?
<stgraber> I'm updating my pbuilder, as soon as I no longer need the network I'll
<asac> k
<stgraber> asac: http://paste.stgraber.org/3288
<asac> stgraber: what does iwconfig show you?
<asac> stgraber: are you associated?
<asac> when it hangs in stage 1
<stgraber> yes I'm asociated but I also was before asking NM to connect
<stgraber> s/also/already/
<asac> yes right
<asac> stgraber: its starnge that you only see "DevicePrepare ) scheduled" ... but not *started*
<stgraber> asac: http://paste.stgraber.org/3289
<asac> its not much that could go wrong ... its basically just an idle timeout
<stgraber> with the two nm_info lines
<asac> stgraber: ok can you do a connect attempt now
<asac> and wait till nm gives up ... at best note which time that is in log :)
<stgraber> I doubt it'll give up, I always had to kill it as I wasn't even able to select wired connection :)
<asac> huh?
<asac> hmm
<asac> sounds reasonable
<asac> maybe a dead log?
<asac> i mean i wondered why preparation is not started for you ... its basically just attaching and idle source
<asac> so not much that could go wrong
<asac> s/dead log/deadlock/
<stgraber> this try seems a bit better (which is strange as nothing is different except the two nm_info ...) : http://paste.stgraber.org/3290
<stgraber> and I was able to switch back to wired LAN
<stgraber> but no disassociated/associated event line shown :(
<asac> stgraber: i don't see any association event now
<asac> didn't you reload driver?
<stgraber> this log start just before I click on the open wlan name in NM, the NM auto-association was before I think
<asac> but you are associated to another network? or the right one?
<stgraber> I only have one open network here, so it's the same network I'm automatically associated to and I'm trying to connect
<asac> stgraber: ok now switching rflink ?
<asac> what happens then?
<stgraber> switching rflink ?
<asac> well turn radio off and on
<asac> there should be something :)
<stgraber> a ok, let me try
<stgraber> works
<asac> what did yousee in log?
<asac> did you just get an assocaited event?
<stgraber> if I do it while it's at stage 1 or just before it doesn't work (iwconfig shows unassociated), if it's at stage 2 or after it just works fine
#ubuntu-devel 2007-09-02
<asac> so you actually wait till nothing happens anymore ... then you turn off and on and it associates ? e.g. goes to stage3 et al?
<asac> or does it start from stage 1 again, but this time goes through to stage 5?
<stgraber> asac: http://paste.stgraber.org/3291
<stgraber> I receive an associated event after switch rfkill back on
<stgraber> then it continues at stage 2
<asac> yes great
<asac> i see it
<asac> why the hell goes all usb down?
<stgraber> my kill switch also kills my bluetooth card which is USB :)
<asac> stgraber: apparently it doesn't resent the associated event if you set the same essid again
<asac> stgraber: ah ok
<asac> stgraber: ok when you hang at stage 2
<asac> does setting essid to "" trigger the association even again?
<asac> stgraber: or better ... set to a not existing one ... then set the right onw again
<asac> maybe it just continues
<stgraber> setting to not existing works
<stgraber> setting to "" doesn't change the essid (iwconfig still shows the same)
<stgraber> when setting to a not existing one, I see a "disassociated event", then a "associated event" and it connects correctly
<stgraber> so the main problem is that NM try to deassociate using essid "", which in fact doesn't deassociate :)
<asac> stgraber: i look at the driver code now ... i am not really adept in kernel code
<asac> but from what i read it skips reassociation when essid is changed :/ in case you are already associated
<asac> stgraber: yeah we should probably set to no-existing instead of any/off
<asac> stgraber: i don't really understand the logic in this driver code
<asac>         IPW_DEBUG_ASSOC("[re] association triggered due to BSSID change.\n");
<asac>         if (!ipw_disassociate(priv))
<asac>                 ipw_associate(priv);
<asac> ipw_disassociate returns 0 iif you are currently not associated/associating
<asac> for me it looks like it should just be ipw_disassociate(priv); ipw_associate(priv);
<asac> without if
<asac> further it treats any in the same way as off ... in both cases it runs ipw_associate
<asac> imo it shouldn#t do that for off
<asac> only for any
<asac> stgraber: wanna try to patch those two places?
<stgraber> if you have an easy way to rebuild the driver yes
<asac> easy way?
<asac> does building modules fail for you?
<asac> stgraber: have you tried to build the sources from upstream site?
<stgraber> yes
<stgraber> and had some problem with the ieee80211 thing
<asac> stgraber: why do you need that? don't we have that installed/build already?
<stgraber> asac: what cmd do you use to build upstream ipw3945 ?
<stgraber> a simple "make" complains about duplicate ieee80211 thing
<asac> stgraber: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=bash
<asac> that builds for me at least
<asac> stgraber: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash
<asac> stgraber: maybe try unmodified 1.2.2 first5
<asac> if that work we can test things
<stgraber> asac: http://paste.stgraber.org/3292
<asac> hmm
<asac> ok
<asac> try to: apt-get install ieee80211-source module-assistant
<asac> then
<asac> sudo module-assistant prepare
<asac> sudo module-assistant unpack ieee80211-source
<asac> after that it should ubild
<stgraber> asac: looks like the ieee80211-source isn't complete, net/ieee80211_radiotap.h is missing
<asac> stgraber: what did you do?
<asac> for me it just builds
<asac> did you try to tweak the INC variable? i didn't need that
<stgraber> I had to as module-assistant extract to /usr/src/module and ipw3945 looks for /usr/src/ieee80211
<asac> stgraber: did you run module-assistant prepare?
<stgraber> yes
<asac> stgraber: for me the headers are found ... they are from the unpacked sources (now that i look at it) ... but are in kernel headers directory
<asac> stgraber: but prepare should have installed the headers for you?
<asac> stgraber: http://paste.stgraber.org/3293
<asac> stgraber: http://paste.stgraber.org/3294
<Kopfgeldjaeger> bye
<stgraber> asac: I have the same result for the find cmd ...
<asac> does the make command print the same?
<asac> and you really run: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash
<asac> thats strange
<stgraber> yes
<asac> you must have someelse messed up ... /usr/src/linux link exists?
<asac> /usr/src/linux-headers-2.6.22-10-generic as well?
<stgraber> linux -> linux-headers-2.6.22-10-generic
<asac> stgraber: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash IEEE80211_INC=/lib/modules/2.6.22-10-generic/build/include/
<stgraber> same
<asac> then i can't tell ... maybe you are not up-to-date or something
<asac> stgraber: maybe you added some links when you tried to do ieee8... stuff manually in the past?
<stgraber> asac: I'm downloading the complete source tree, maybe it'll find the required bits here :)
<asac> stgraber: i doubt that its the required bits
<asac> your system has something wierd :)
<stgraber> I reinstalled all 2.6.22-10 packages this morning after trying to manually build ipw3945 so my system should be clean
<asac> stgraber: strace -eopen -f make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash &> /tmp/out
<asac> please post it
<stgraber> http://paste.stgraber.org/3295
<asac> stgraber: better: strace -eopen -f make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash 2>&1 | grep ieee8 > /tmp/out
<asac> ok
<asac> ok
<stgraber> compiled (using linux-source)
<asac> stgraber: does /lib/modules/2.6.22-10-generic/build/include/net/ieee80211.h exist?
<asac> stgraber: well please install generic kernel
<asac> to test
<stgraber> that's -generic, I just did : apt-get source linux-image-2.6.22-10-generic and used that as IEEE80211_INC and worked
<stgraber> ieee80211.h doesn't exist
<stgraber> anyway, I can now make the module so that should be good (even if I normally wouldn't have had to download the ubuntu kernel source package)
<asac> stgraber: ok so wait a sec
<asac> stgraber: http://paste.stgraber.org/3296
<asac> try that patch
<asac> DISCLAIMER: i don't know what i do ;)
<stgraber> 2 out of 2 hunks FAILED -- saving rejects to file ipw3945.c.rej
<stgraber> on clean upstream ipw3945-1.2.2
<asac> can you edit it manualyl that way?
<stgraber> yes
* LaserJock looks a backscrool
<asac> stgraber: good
<LaserJock> it's all asac and stgraber for 3 hrs
<asac> LaserJock: yeah ... apparently everyone else have their issues sorted out already ;)
<LaserJock> gutsy is perfect! let's go home
<asac> of course its perfect ... but still there are things that can be improved ;)
<asac> stgraber: the idea is that you receive an association event in case you set a new essid :) and that you don't try to associate if essid is set to off
<stgraber> module compiled, let's try to replace the current one :)
<stgraber> asac: result with NM is still the same
<stgraber> (and no event received)
<asac> stgraber: please set iwconfig essid to off
<asac> and see if it still reassociates (e.g. nm stopped)
<stgraber> asac: exactly the same behaviour as before, off doesn't seem to make it deassociate at all
* Fujitsu wonders which package he should file a bug under about the keyboard accessibility stuff.
<asac> stgraber: how did you run iwconfig exactly?
<stgraber> iwconfig eth1 essid off
<asac> stgraber: in man they say that you should escape if you use the keywords
<asac> stgraber: iwconfig eth0 essid -- "ANY"
<asac> is one example
<stgraber> asac: well, if I do : iwconfig eth1 essid -- "off" it'll be the essid "off", not the action off
<stgraber> asac: so -- "off" will work, but "niofnbdiono" would have done the same :)
<asac> oh right ;)
<stgraber> btw, why does "off" deassociate+associate, shouldn't it only deassociate ?
<asac> stgraber: well the patch i gave you should fix that
<asac> stgraber: current behaviour is any+off deassociate + associate
<asac> so i made this patch :)
<asac> did you apply it ;) ?
<stgraber> yes :)
<stgraber> hmm, right that's the first part of your script (didn't really read the code :))
<asac> script :)
<asac> thats a .c file patch
<stgraber> he, it's 2 o'clock :), yes it's C :)
<asac> stgraber: can you please try one more thing for today: build with CONFIG_IPW3945_DEBUG=1
<asac> oh its already the default
<stgraber> yes, but I'd need the debug value to pass to the kernel module
<asac> yes
<wasabi> Hmm. Looking for guidelines on what's accepted in -updates
<asac> stgraber: try 0xffffffff or something
<asac> stgraber: i think its 0x1800
<asac> that should be SCAN + ASSOC
<stgraber> tried with 0xffffffff and 8 (which is WX) and I have no output :(
<asac> how did you load?
<asac> stgraber: try echo 6144 > /sys/bus/pci/drivers/ipw3945/debug_level
<stgraber> I have some debug info with that, but nothing when doing the essid off
<stgraber> asac: when doing the essid off with debug being 6252 I see : Sep  2 02:39:21 laptop kernel: [52117.597673]  ipw3945: U ipw_wx_set_essid Setting ESSID to ANY
<asac> wow
<asac> you have a bit more log for me?
<stgraber> http://paste.stgraber.org/3298
<stgraber> ^ a bit :)
<stgraber> at least it's clear that NM sets the ESSID to ANY and then the driver try to associate
<asac> stgraber: well ... as you see off is any
<asac> (somehow)
<asac> you tried it manually right?
<stgraber> hmm, you are right that could well be OFF too as both shows ANY :)
<stgraber> last log line is a manual "iwconfig eth1 essid off"
<asac> i see in code that i touched AP code not essid
<asac> for essid its just zero length string
<asac> which means any
<asac> apparently wireless tools already does that
<asac> e.g. convert off to empty
<asac> stgraber: in that log you get an associated event
<asac> what kind of testrun was it?
<asac> just setting to off while nm was running?
<stgraber> it's what I get when loading the module with NM running
<asac> but not the complete log
<stgraber> so NM setting the device to OFF (-> ANY), then scanning for network and finally me doing the "iwconfig eth1 essid off"
<asac> well
<asac> yes ... stgraber this issue is not really my problem here ... my problem is that we don't get an associated event when setting essid explicitly
<asac> ok now that i see that we cannot differentiate between off and any we have to do try it the hard way
<asac> stgraber: have you tried that explicitly connecting in applet still doesn't work?
<asac> (i don't think it will ... but who knows)
<asac> stgraber: last try for today: http://paste.stgraber.org/3299
<asac> stgraber: its in the ...set_essid method
<asac> and bascially reassociates explicitly when you set essid explicitly ... even though both are the same
<asac> stgraber: still there?
<stgraber> asac: yes
<stgraber> asac: I was just testing
<asac> ok
<asac> have you tried the patch? ... to test just set the essid to the same value like you had before
<stgraber> it works better (I can now connect to an open wlan)
<asac> with that latest patch?
<stgraber> I just have some weird thing while switching from a WLAN to another
<stgraber> yes
<asac> ok
<asac> wait a second lets try something not so brutal
<stgraber> as you deassociate+associate, it first associate to the first network it finds, then switch to the right one
<stgraber> the other main problem is that it still associate with the first network it finds, even if it now lets you connect to it or to another that still cause a problem
<stgraber> ipw3945 seems not to scan networks the same way if it's associated or not
<stgraber> for example, if it's associated with FON_BEVAIX which is my public WLAN, it will only find my WPA networks after 5 minutes or so :)
<asac> stgraber: http://paste.stgraber.org/3300
<asac> e.g. replae the two lines we just had with the one line in that patch
<stgraber> I have the same behaviour with iwlist eth1 scan where I need to run it 5-6 times before I see all my networks
<stgraber> k
<asac> it should just send a assoc event ... without actually reassociating
<asac> stgraber: i thought your interface is always associated??
<asac> (aeh not for nm of course)
<stgraber> asac: remember, it's always associated because NM first send this essid off, without NM it isn't
<asac> stgraber: actually i think its not right to call it directly
<asac> probably it should be queue_work(priv->workqueue, &priv->link_up);
<stgraber> hmm, build fails
<stgraber> /home/stgraber/Desktop/ipw3945-1.2.2/ipw3945.c:12249: warning: implicit declaration of function ipw_link_up
<asac> oh
<asac> yeah try what i said above then
<asac> warning makes it fail?
<asac> maybe better that way
<asac> queue_work(priv->workqueue, &priv->link_up);
<stgraber> yeah, I managed to do : Wired -> public -> WPA1 -> WPA2
<asac> then it stalled?
<stgraber> then wanted to come back to public but NM had the bug I showed you before (got stuck at Stage 1)
<asac> e?
<asac> which bug do you refer to? ... ah the hang
<asac> hmm
<asac> yes
<asac> that should be something different then
<asac> stgraber: so what was the default kernel parameter used for no auto association?
<stgraber> parm:           associate:auto associate when scanning (default 0 off) (int)
<stgraber> so currently, except that hang (which is more or less random) and the fact that it real slow to have a full list of network when associated, everything works fine :)
<asac> stgraber: auto? ... didn't you say its 0 ?
<asac> stgraber: i found the thing in code ... if associate there is an extra scan suspend_time
<asac> so it might be reasonable that you don't get lots of results ... especially since ipw appears to jump on the first wifi it sees ... and probably forgets about the scan results
<stgraber> that's a problem when the first wifi it sees is a public hotspot and your personal wifi is detected only after a couple of minutes :)
<asac> yeah we can look into that the next days
<asac> its probably driver specific
<asac> stgraber: can you try to not set to auto ?
<asac> (i wonder why we have that set to auto at all)
<stgraber> associate=0 by default so it doesn't auto-associate when scanning
<asac> ok
<asac> then thats a bug
<stgraber> the associate comes from NM doing the essid ANY/OFF
<asac> stgraber: we can try to fix that tomorrow
<asac> i think i know how to make the driver to obey not to do that.
<stgraber> cool :)
<asac> well don't hope too much
<asac> :)
<asac> stgraber: imo when you have associate=0 ... then setting ANY/OFF should not associate
<asac> right?
<stgraber> yes, but that's not the current behaviour :)
<asac> yeah question is if thats the desired behaviour?
<asac> if so i see the place to add that
<stgraber> I don't see why off should associate at all ...
<stgraber> even with associate=1
<asac> but i don't see a use case for auto association at all
<asac> stgraber: off doesn't exist
<stgraber> right :)
<asac> the difference is probably already eliminated on user-space in wireless-tools
<asac> though not really sure
<stgraber> ok, so basically if associate=0 then the driver should only deassociate not deassociate+associate
<asac> yes
<asac> so with associate=0 it means OFF
<asac> while with associate=1 it means ANY :)
<asac> no idea what that would break ;)
<asac> i think the only thing that wouldn't happen is that user gets initially connected to some random network
<asac> which might be nice for noops ... but on the other hand often not the right network anyway
<stgraber> which is current behaviour for most other drivers no ?
<asac> no idea ... i just got dragged into this driver thing ...
<asac> do they all get an assocaite paratmeter?
<asac> can you see that?
<stgraber> bcm43xx doesn't
<stgraber> and same for madwifi
<asac> stgraber: what parameters do those get?
<stgraber> countrycode (for the channel limit I guess), outdoor (?), xchanmode (extanded channel mode), rfkill (enable rfkill), autocreate (autocreate if), ratectl, ath_debug for madwifi
<asac> stgraber: so how is the current behaviour?
<stgraber> locale (?), country (same as madwifi), noleds (disable led), fwpostfix (choose what firmware to load)
<asac> if you boot ... you still get an associated wifi next to your connected wired?
<stgraber> with bcm43xx and madwifi doing : iwconfig if essid off( or any) doesn't make the card to associate
<asac> ok so maybe its really just off for them
<asac> and ipw implemented just any :)
<stgraber> :)
<asac> well they tried to implement off ... but failed ;)
<asac> because they forget the associate config test when essid is set
<asac> and associate always
<asac> wow they even overwrite the associate parameter once you configured essid off/any
<asac> stgraber: last for real: http://paste.stgraber.org/3303
<stgraber> asac: can you paste your .c somewhere so I'm sure mine is clean :)
<asac> does it fail?
<asac> i mean we were diverged from the beginning :)
<asac> stgraber: http://people.ubuntu.com/~asac/ipw3945.c
<asac> no idea if i edited something else at some point
<asac> (seemed like i did because you couldn't apply the patch)
<asac> stgraber: sorry i made a mistake :)
<stgraber> FATAL: Error inserting ipw3945 (/lib/modules/2.6.22-10-generic/ubuntu/wireless/ipw3945/ipw3945.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<stgraber> oh, saw the mistake :)
<stgraber> s/deassociate/disassociate/
<asac> yes
<asac> stgraber: should work with that imo
<asac> stgraber: ok reuploaded the .c file (which compiles) ... but still no idea what else i edited at some point in there
<stgraber> good this one doesn't auto-associate, I can also connect to a network without any problem, but switching back to Wired, it associates with my Open wifi in the background
<stgraber> so problem is 50% solved :)
<stgraber> well, more 80% I'd say :)
<asac> hmm
<asac> ok
<asac> does it harm your ability to go back to wifi?
<stgraber> I'll try one more time but I think the only thing it'll cause is that it'll scan less frequently after you did : wired -> wifi -> wired
<asac> ok
<stgraber> argh, no, I can't go back to wifi :(
<asac> stgraber: well i would need a driver debug log then again :)
<asac> but maybe tomorrow
<stgraber> as usual, as it's already associated with the network it doesn't reassociate
<stgraber> so problem is half-solved :)
<asac> stgraber: don't you see an associated evnt in log?
<asac> (the output we added to network manager)?
<asac> when trying to go back?
<stgraber> yes :)
<stgraber> (which is strange ...)
<asac> you see it?
<asac> where does it hang?
<asac> maybe its again the other hang issue?
<asac> and next time you try it works longer?
<stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  SUP: sending command 'ENABLE_NETWORK 0'
<asac> e.g. you can go to wired/wifie more than once?
<stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  SUP: response was 'OK'
<stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  Activation (eth1) Stage 2 of 5 (Device Configure) complete.
<stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  wireless_event_helper - associated event
<stgraber> no it's not the hang issue as I can go back to wired with having to kill NM
<asac> what happens after that?
<stgraber> nothing till I switch back to wired
<asac> stgraber: but no Activation (eth1) Stage 2 of 5 (Device Configure) successful. ?
<asac> before that?
<stgraber> asac: http://paste.stgraber.org/3304
<asac> stgraber: ok i think the link_up is not enough then
<asac> with disassociate/assocaite instead of the queue_work( ... link_up) it should work i hope
<asac> but not today :)
<asac> night!
<stgraber> good night
<asac> and thanks for all the testing !
<stgraber> no problem
<jds663> was Xgl made default in this last batch of updates and how the heck do I stop it from trying to load?!? It's way too slow for my card..
<jds663> the cpu load is at 100% xgl... and I have never run that xserver
<mjg59> No. It's in universe. We've never shipped it by default
<jds663> this is strange after an update it's refusing to boot without it.. and ive even removed the package so now it just "stops" when i login and goes no further.. could this have been the kubuntu team? and where might I look to find out where it is executing this.. ive looked in kdmrc and several Xsession/X11 files...
<Maczimus> Love Gutsy, was there a recent update that makes ATI cards work with the effects?
<rohith> <test>
<stgraber> asac: I've just built the ipw3945 driver with the latest ipw3945.c you've uploaded and it's almost perfect (deassociation works fine when setting any)
* Hobbsee waves to stgraber
<stgraber> asac: the only problem is that if I do the following : wired -> public -> private1 -> private2 -> private1 -> public (failed and fallback to wired)
<stgraber> asac: so I can connect to an open network only if it's the first network I try to connect to, otherwise it doesn't even try to associate (iwconfig shows off/any)
<stgraber> hi Hobbsee
<stgraber> asac: http://paste.stgraber.org/3308 (log of first connect to open network (working))
<stgraber> asac: http://paste.stgraber.org/3307 (log of switch from WPA to open network (not working))
<StevenK> infinity: Ping, re: libnss-db some more. And I have a question about a promotion.
<asac> stgraber: i need the full driver logs
<asac> stgraber: and how about wired -> public ->  wired -> public -> wired -> public ... i assume it doesn't work as well?
<stgraber> right
<stgraber> ok, I've the debug message, now let's try to have some interesting ones :)
<stgraber> asac: http://paste.stgraber.org/3311
<stgraber> btw, it looks like a wpa_supplicant problem
<asac_> stgraber: i was off :/
<asac_> 13:33 < stgraber> ok, I've the debug message, now let's try to have some interesting ones :)
<asac_> 13:39 < asac> huh?
<asac_> stgraber: if you have debug=0xffffffff
<asac_> then it should be interesting enough ;)
<asac_> stgraber: ok i think i found the log on your paste server
<asac_> 3311?
<asac_> stgraber: hmmm that run is again a bit strange ... we see:
<asac_> #
<asac_> Sep  2 13:36:07 laptop NetworkManager: <info>  Error opening supplicant global control interface.
<asac_> #
<asac_> Sep  2 13:36:07 laptop NetworkManager: <WARN>  real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
<asac_> we didn't see that before, right?
<jc-denton> how can i check if a box is performing well?
<asac> stgraber: you know our workaround we did in nm to unset the essid in stage1? ... probably we don't want that anymore now.
<stgraber> asac: right, I tried to disable the patch but after that I wasn't able to apply the wpa_supplicant patch anymore
<Hobbsee> jc-denton: #ubuntu for support, please see teh /topic
<jc-denton> well
<jc-denton> last time i asked there for something specific, nobody had a clue
<jc-denton> here people know stuff..
<asac> stgraber: ok will do it
<Hobbsee> jc-denton: run top, and look at the stuff off that.
<jc-denton> heh
<Hobbsee> jc-denton: it still doesnt make it the right channel (it's nothing to do with ubuntu development), and it's also a weekend.
<jc-denton> well i did that
<Hobbsee> "run well" is not very descriptive, either.
<jc-denton> well i don't have anything running on the box
<Hobbsee> does a low load mean that it's running well?  no runaway processes?
<jc-denton> i tested disk io with hdparm
<jc-denton> and it seems to work fine
<jc-denton> but when i run apt-get install something
<jc-denton> for example
<jc-denton> "building dependency tree" takes some time
<jc-denton> and it's a fresh install
<jc-denton> on my laptop it's much faster and i have many things installed
<soren> jc-denton: If you want help even though you're asking user questions in a development channel, you could at least have the decency to ask proper questions that we can actually answer.
<sits> .o0 ( hmm, I wonder if jc-denton can get answers here then maybe I should try too )
<jc-denton> lol
<sits> jc-denton: I jest I jest
<Hobbsee> sits: that's why we discourage such things
<sits> jc-denton: but people do go by convertion
<soren> jc-denton: With the information you've given, "you can check if someone has hammered on it with an axe" would be a possible response to "how can i check if a box is performing well?
<Hobbsee> sits: because people *do* do that
<Hobbsee> soren: *snorts with laughter*
<sits> (I really did have a question before you arrived but read the topic and thought.. Hmm better not)
<jc-denton> well ok
<Hobbsee> soren: good thing i didnt have my water in my hand!
<jc-denton> i checked disk io with hdparm
<jc-denton> it seems fine
<jc-denton> although hdparm says it supports only 16 bit for io
<soren> jc-denton: Well, when you run apt-get update on a machine from the early nineties, it takes some time.
<Hobbsee> sits: what's the quesiton, out of curiousity?  we'll see if you can phrase yours better than jc-denton can
<jc-denton> it's not that old
<soren> jc-denton: Oh. I didn't know. You didn't say.
<jc-denton>  IO_support   =  0 (default 16-bit)
<jc-denton> however if i run hdparm -tT speed seems to be resonable
<soren> jc-denton: Building dependency trees is not really an io-bound operation.
<sits> Hobbsee: is gnome-power-manager in Gutsy broken with regard to dbus?
<jc-denton>  Timing cached reads:   624 MB in  2.00 seconds = 311.73 MB/sec
<jc-denton>  Timing buffered disk reads:  172 MB in  3.01 seconds =  57.10 MB/sec
<jc-denton> soren: cpu?
<sits> I have just tried compiling the python test example, fixing it because the example I had was old and then testing the gnome-inhibit applet while closing my laptop's lid
<soren> jc-denton: Yes. Does it have one?
<jc-denton> celeron 2.6 ghz or so
<sits> jc-denton: those speeds are very high. Now here's a bit of advice before a flee in terror
<Hobbsee> sits: ah.  got no idea, ask ogra on monday
<soren> jc-denton: It's quite possible that people in #ubuntu could actually answer your "question" if it had any information in it.
<Hobbsee> sits: (or wait for an update)
<jc-denton> so building dependency tree is a cpu bound operation?
<sits> jc-denton: I'd check your CPU usage when you do update. I have used servers with a throughput lower than 311Mbyte/s
<jc-denton> that's already a hint
<soren> jc-denton: Well, even with a 100 GHz machine it's not an instantaneous operation.
<sits> jc-denton: I would have thought so but this is easier for you check than me. Top will help you out.
<jc-denton> humm
<soren> jc-denton: You may remember that all you've said is "it takes some time".
<sits> if I just couldn't stop myself then I would crack out oprofile and start looking at the performance stats that that produced couple with cachegrind runs
<jc-denton> well on my laptop its less then a sec
<sits> jc-denton: at a more basic level you can go on a syscall hunt by looking at the output produced by strace
<soren> jc-denton: That sounds nice. You have still not told us how long it takes on the machine that you think is having problems.
<Hobbsee> soren: heh.   with this kind of thing, i'm not surprised that people whine about their questions in #ubuntu not being answered.
<soren> Hobbsee: Quite.
<jc-denton> soren: how can i mesure that?
<sits> jc-denton: but the time it should take will be hard to pin down. You will need to do a lot of serious work to be able to answer that with any accuarcy
<soren> jc-denton: How did you measure it on your laptop?
<jc-denton> err measure
<jc-denton> just by looking
<soren> jc-denton: That sounds like a good starting point. Do that.
<sits> OK that's enough spam from me.
<soren> jc-denton: Dude....
<jc-denton> wait
<sits> Hobbsee: thanks for the advice - it's a bit busy in here for me so see you round!
<soren> jc-denton: I suggest you stop this, take your time to actually formulate a question with actual information in it, and then come back.
<Hobbsee> where 'come back' is to #ubuntu
<soren> jc-denton: So far, all you've given us is "'apt-get install' takes longer than I expect it to on a machine with a cpu and a harddrive in it. Why is that?"
<soren> jc-denton: With that amount of information, I might as well advice you to check if you're running it on 110 V rather than 230 V.
<Hobbsee> soren: "because someone smashed it with a hammer out of sheer frustration, due to the user's incompetence at asking questions"
<soren> jc-denton: I don't mean to be offensive. I'm just trying to make it very clear that you need to give us something to work with here.
<Hobbsee> jc-denton: you'll probably find http://www.sabi.co.uk/Notes/linuxHelpAsk.html helpful
<jc-denton> aha
<Hobbsee> to stop wasting other people's time, and all...
<jc-denton> Mr Blissex
<soren> ?
<jc-denton> http://rafb.net/p/FSEmmu48.html
<jc-denton> so can you have a look at this
<jc-denton> soren: heh thx i didn't think about the power
<soren> jc-denton: that's a start. Some information about the differences between the two machines might be good, too.
<jc-denton> how can i check the temperature of the cpu
<Hobbsee> jc-denton: now you're *really* getting back to #ubuntu type questions.
<jc-denton> well then thx for first
<jc-denton> the hint that building dependency tree is a cpu bound operation already gave me some hint
<soren> jc-denton: Ok, here's a list of info to gather so that you can ask again in #ubuntu and probably get an answer: Contents of /proc/cpuinfo, output from "uptime", those timings you already gave, output of "free". That's just about the minimum of information that is needed to even start helping you.
<jc-denton> free is ok
<soren> No!
<Hobbsee> jc-denton: no, no.  you take the list, then you ask #ubuntu.  you dont ask us.
<jc-denton> lol sry
<soren> You can't just say "free is ok". If you want anyone to give you answers, you have to give them information!
<jc-denton> i'll stop asking
<soren> Oh, also add the contents of /etc/apt/sources.list to the list of stuff to provide.
<soren> The *entire* contents, I might add. Not just the stuff you find interesting.
<jc-denton> humm maybe
<soren> jc-denton: You need to understand that the answer probably lies in one of those pieces of information, but if *you* look at them individually, they probably will all look fine, but you have a problem don't you. So it might just be that you're misinterpreting stuff, and if there's something that's annoying, it's people asking for help, but refusing to give the information that makes it possible to help them.
<jc-denton> i see
<soren> jc-denton: More information is *always
<soren> * better than less.
<jc-denton> not always
<jc-denton> if there is too much it's probably not good
<jc-denton> but better a bit more then a bit too less
<soren> When asking for help, yes.
<Hobbsee> jc-denton: then people can sift through it.
<jc-denton> i agree
<soren> In my 13 years in this business, I have only once or twice had someone give me too much information when I was supposed to help them.
<Hobbsee> oh dear.  people, please stop filing crap bugs.
<soren> And by "too much" I mean "so much information that it became annoying trying to make sense of it".
<soren> Hobbsee: do you have a bug number, or is it just a general observation? :)
<Hobbsee> soren: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/136761
<ubotu> Launchpad bug 136761 in firefox "Cannot open some website......" [Undecided,New] 
<soren> It's not "too much information" when there's information that turns out not to be relevant to the problem.
<Hobbsee> soren: there was also one about how windows XP was much more automated and simple, and linux should be fixed to be like it, in this day and age...yada yada yada
<soren> Hobbsee: Have you fixed that one yet?
<soren> Hobbsee: Otherwise get on it, and make it snappy!
<Hobbsee> soren: nope!
<soren> Aw, come on.
* Hobbsee has checked for ie-specific code on the website, though
<Hobbsee> vaguely
<soren> Oh, I meant the "make linux more like XP" bug.
<Hobbsee> soren: ahh.  sure, where fixed is "hit it with the WONTFIX stick"
<Hobbsee> oh, and telling him to run the command that he was writing over
<Hobbsee> i'd really like to know why it's telling them to report it, though.
<zul> Hobbsee: there was also a bug report on why cant i fix my windows dll
<Hobbsee> zul: *lovely*
<zul> lemme see if can see still find it :)
<zul> firefox has like advocacy bugs where they encourage users to write to the webmaster and ask them to fix it
<Hobbsee> i'd prefer a stab-over-http for that particular webmaster, though
<zul> Hobbsee: yes we know how violent you are ;)
<Moniker42> hey, are the Gutsy wallpapers going to be available in 1920x1200?
<Moniker42> because some of them look very nice indeed... but the previous wallpapers haven't been available in double-mega-Dell size :)
<geser> Mithrandir: please give-back ladcca on lpia. Thanks.
<geser> Mithrandir: please give-back sdlgfx on lpia. Thanks.
<geser> Mithrandir: please give-back date on lpia. Thanks.
<geser> Mithrandir: please give-back quadprog on lpia. Thanks.
<geser> Mithrandir: please give-back vr and rgl on lpia. Thanks.
<AlinuxOS> https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677
<ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
<AlinuxOS> tribe 5 is out.
<AlinuxOS> asac, hello do you have some news regard this ?
<Hobbsee> !weekend | AlinuxOS
<ubotu> AlinuxOS: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<AlinuxOS> Hobbsee, uh... sorry! :)
<AlinuxOS> Hobbsee, + devels, have a nice weekend!
<Mark_27> hi all
<Hobbsee> AlinuxOS: :)
<Hobbsee> AlinuxOS: i wish.  i'll have a nice weekend, if you'll do this rotten physics assignment for me?
<Hobbsee> doko: please fix gcc-snapshot maintainer field in debian, if you havent done so already.  motu list doesnt need to hear about it
<bddebian> Heya
<doko> Hobbsee: you are not the first one ...
<Hobbsee> doko: ah cool.  didnt think i would be, i just saw more mail hit the ML
<alex-weej> Hobbsee: are you doing a physics degree?
<bddebian> doko: Is there any chance I could bug you about a Java package for a minute?
<Hobbsee> alex-weej: i was.  it's now a computing degree, but i'm still taking bits of physics
<Mithrandir> geser: all given-back
<Hobbsee> good morning Mithrandir!
<bddebian> Mithrandir: Hi.  jmagick has been in the archive since Dapper at least and was FTBFS.  I got it to build but the binaries are in NEW.  Is that because it has never successfully built before?
<Mithrandir> bddebian: probably, yes.
<bddebian> OK, thx
<ScottK> Mithrandir: would you please give-back taskjuggler on lpia?
* mneptok rubs Mithrandir with dpkg-scented love oil
<bddebian> haha
<stgraber> asac: did you manage to disable the patch ?
<mike__> deser you around?
<mike__> desrt around?
<asac> stgraber: wow :) ... i took some rest, was at sport
<stgraber> asac: me too :)
<asac> stgraber: maybe i can get things up later ... i have to cleanup the ipw3945 code as well ... there is still this OFF/ANY thing in place for the set_bssid case ... which might cause troubles :)
<asac> stgraber: i will let you know
<asac> stgraber: maybe one thing ... do you always see:
<asac> #
<asac> ep  2 13:36:07 laptop NetworkManager: <info>  Error opening supplicant global control interface.
<asac> #
<asac> Sep  2 13:36:07 laptop NetworkManager: <WARN>  real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
<asac> or did it just happen the one time you captured the debug output?
<asac> (in http://paste.stgraber.org/3311)
<stgraber> asac: it always happen when I do : wired -> something -> public
<stgraber> asac: so I have it everytime NM fails to connect
<asac> stgraber: ok ... what is something?
<asac> do you get it as well when you just do wired->public->wired->public ?
<stgraber> yes
<asac> stgraber: wow the git branch of ipw is a mess
<asac> stgraber: it just stopped to receive commits short after 1.2.0
<asac> stgraber: http://www.intellinuxwireless.org/repos/?p=ipw3945.git;a=summary
<asac> stgraber: on sourceforge there is no cvs ... so this should be the real home
<stgraber> asac: that's maybe because intel is developing iwl3945 ?
<asac> maybe ... but still they should push their commits to that repo
<asac> even if they don't do active development on it :)
<asac> that branch is just stuck at 1.2.0 + 5 commits
<asac> last commit 6 months ago
<asac> while last release was on  Jul 31 2007
<asac> email sent to intel devs ... lets see :)
<asac> stgraber: can you please apply these two patches (manually) and tell me if they break more things ?
<asac> stgraber: http://ipw3945.sourceforge.net/patches/ipw3945-1.1.3-2.6.20-register.patch ([PATCH 1/1]  Change call to the deprecated pci_driver_init to pci_register_driver)
<asac> stgraber: http://ipw3945.sourceforge.net/patches/ipw3945-1.2.1-inta-fix.patch (Fix potential driver lockup problem)
<asac> oh and:
<asac> http://ipw3945.sourceforge.net/patches/ipw3945-1.1.4.essid.patch (bogus character appended to ESSID)
<asac> which i already saw in log
<asac> to test things like hibernate/suspend would be nice to know as well
<stgraber> aren't they already included as we are using 1.2.2 and your patches are 1.1.3, 1.1.4 and 1.2.1 ?
<asac> i don't think so ... if you see that they are ... fine :)
<alex-weej> is it possible to "burn" ISO files to a flash device?
<alex-weej> so i can boot from flash instead of wasting CDs all the time?
<asac> you can copy the content to a flash filesystem i guess
<asac> but i am the wrong person to ask :)
<asac> alex-weej: you can use RW cds :)
<alex-weej> of which i have none
<alex-weej> :P
<stgraber> asac: at least I can't apply any of them
<asac> yeah :) ... but get two and be happy for a long time
<alex-weej> i'm just thinking it would be cool if we could easily support using flash devices to bootstrap an ubuntu system rather than wasteful (and harmful-to-the-environment!) CDs
<stgraber> 1.1.3 and 1.1.4 seems to be already applied (according to patch)
<Mithrandir> alex-weej: sure, it's just slightly more fiddly to write an image to a USB device, and in practice I believe it requires a linux machine already present.
<stgraber> and it's unable to apply 1.2.1
<asac> stgraber: ok fine
<asac> they are either in ... or the source-base has drifted away too far to tell from a glance
<asac> i think its safe to assume that we have them
<stgraber> asac: manually looking at the code I didn't find where I'd manually patch 1.2.1
<alex-weej> i'd imagine the installer would be much quicker to copy from USB than CD too, or are the reads from CD generally pretty sequential?
<asac> probably
<asac> it should work ... wait till someone who knows the details pops-up
<broonie> Flash devices aren't usually enormously fast, either.
<asac> maybe try tomorrow
<asac> broonie: maybe the throughput is bad ... but the access-latency should be better
<asac> (just out of my guts)
<leip`> " gpgme created no signature for './dists/feisty/Release.new'!
<leip`> :-(
<leip`> Google offers no help
<leip`> this time..
<cjwatson> alex-weej: CD seeks do suck, though we sort the files in the ISO9660 image in an attempt to minimise seeks
<leip`> I'm trying to add my new package to my new repository
<alex-weej> ok
<leip`> Packaged and " reprepro includedeb feisty <package-name-and-path>
<cjwatson> alex-weej: as far as USB goes, depends on the device and whether it's USB2
<cjwatson> (obviously)
<alex-weej> i mean i know there are guides and stuff to do this, i just think it would be incredibly cool and edgy if we supported install-from-USB or something
<desrt> so... how's the tribe?
<leip`> No default secret key... hmm..
* leip` googles
<asac> stgraber: oh no ... i cannot even clone that git repo ... (while iwlwifi works) ... so i think its completely abandoned
<cjwatson> alex-weej: err, we do - it's been documented in the installation guide since hoary or thereabouts
<stgraber> uhm, so they really want everyone to switch to iwlwifi ? (it's still marked as devel release on their website)
* alex-weej wonders why he has wasted about 100 CD-Rs
<asac> stgraber: no idea ... hope the devs reply
<cjwatson> if you're using that many, RWs would be a better idea anyway
<Mithrandir> alex-weej: I wonder why you didn't just get some RWs instead.
<alex-weej> hyperbole alert :P
<Mithrandir> it's not like they're hard to get.
<cjwatson> https://help.ubuntu.com/7.04/installation-guide/i386/boot-usb-files.html
<alex-weej> that is awesomely, awesomely cool
<alex-weej> bit hopeless for windows users though i guess
<asac> stgraber: now that we have ipw3945 improved ... maybe we can do the same for iwlwifi too :) ... wasn't it you who claimed that it works like a charme?
<stgraber> asac: no but I heard it does, only problem is that here it creates an interface called wlan0_renamed or something similar that NM doesn't detect
<stgraber> asac: so I wasn't really able to test it
<leip`> Man, pgp wants me to do random stuff to seed it's random number generator, but I'm in an ssh session!
<asac> stgraber: there was a guy in a bug that claimed that it just worked with nm
<leip`> And it ran out of random bits and is asking me to do more
<asac> stgraber: ok ... he revised his claim
<leip`> I tried typing random stuff and sleeping it and doing a find / ... but it's still stuck there
<leip`> *gpg
<leip`> *whatever...
<asac> stgraber: ok he says that he needed remove iwl again ... and then insert it ... finally he had just wlan0
<asac> stgraber: http://paste.stgraber.org/3315
<asac> stgraber: just look at the bottom of bug 121439 for more info
<cjwatson> leip`: I believe disk I/O typically feeds the entropy pool
<ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Confirmed]  https://launchpad.net/bugs/121439
<asac> :)
<cjwatson> leip`: (may take a while, but it's one approach you can take remotely)
<leip`> cjwatson: How can I skim off /dev/random? Perhaps I can create a script
<cjwatson> leip`: hm? you shouldn't have to do anything to it directly
<cjwatson> leip`: just do stuff on disk, it'll feed in randomness automatically
<leip`> cjwatson: I thought you could echo random stuff out of /dev/random?
<cjwatson> leip`: oh, sure, but that won't help you fill up /dev/random with more randomness :)
<cjwatson> leip`: dd is the traditional shell tool for extracting random bytes
<stgraber> asac: it's still wlan0_rename here :(
<asac> stgraber: did you try to blacklist as one of the last comments suggests?
<cjwatson> (obviously it does lots of other stuff too, but when applied to /dev/random - or more usually /dev/urandom if your application is not cryptographic)
<siretart> asac: FYI, I'm noticing bug #124706 even with wpasupplicant 0.5.8. therefore I can say you that I don't see any regression nor improvement regarding NM and ipw3945 :(
<ubotu> Launchpad bug 124706 in network-manager "NM sometimes drops connection before associating, logfile says assertion `dev != NULL' failed " [Undecided,Confirmed]  https://launchpad.net/bugs/124706
<asac> siretart: yes ... we are currently trying to improve the driver
<leip`> cjwatson: Thanks for the info
<asac> siretart: however i found in ipw bugtracker that some issues just happen with 0.6.0 ... but in the end those issues should be due to the driver as well.
<asac> siretart: so lets first see how far we get with driver fixes
<leip`> cjwatson: I'm doubling the result of find over and over again switching between two files
<siretart> asac: fixes in the ipw3945 or iwl3945 driver?
<leip`> 244M test  336M test1
<leip`> haha
<cjwatson> leip`: there's probably little point in that since it will only be hitting the cache, not the actual disk
<asac> siretart: for us: ipw3945
<asac> siretart: as thats most likely what we will ship
<cjwatson> leip`: I'd try writing arbitrary (though not actually random) stuff, reading it back, deleting it, repeating
<siretart> ok
<cjwatson> possibly throw in a sync after each write
<leip`> cjwatson: Why aren't my two monsterous files hitting disk?
<stgraber> asac: blacklist + reboot doesn't help
<asac> siretart: i will bring up our ipw code somewhere ... will let you know :) ... maybe you can help to test ;)
<leip`> cjwatson: I "cat test >> test1 && cat test1 >> test"
<asac> stgraber: hmm ok
<leip`> finished!
<siretart> asac: sure
<stgraber> asac: ok, managed to have it rename to wlan0 using an udev rule
<asac> stgraber: rock
<stgraber> asac: this driver works like our patch ipw3945 minus the daemon, which is great
<stgraber> It also fails to connect to open network when doing wired -> wpa -> public or wired -> public -> wired -> public
<stgraber> which tends to show that this bug isn't driver related but NM related
<stgraber> this driver also seems a bit faster to associate than the ipw3945
<cjwatson> leip`: you may not have forced a sync, so they could still just be in cache ...
<cjwatson> (conceivably. dunno.)
<cjwatson> ha! working whatis/apropos for non-English languages
* leip` applauds
<stgraber> asac: same "couldn't connect to the supplicant" thing
<cjwatson> only a 45K diff or so ;-)
* cjwatson -> games
<leip`> hmmm apt-get remove on my package is leaving stuff...
<asac> stgraber: i doubt that the above example shows that its not-driver related
<asac> but we will see
<asac> stgraber: i have pushed an ipw branch that contains our current changes (cleaned-up)
<asac> stgraber: https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
<asac> stgraber: can you try to build that and submit a debug log of the wired->public->wired->public testcase?
<asac> stgraber: maybe its better now ... as the previous log really ran into the code i placed in the wrong method ;)
<asac> stgraber: what happens if you try multiple times when you get that "couldn't connect to the supplicant"  thing?
<asac> stgraber: does it work again? or never?
<stgraber> argh, it seems that I can't unload iwl3945 ...
<asac> stgraber: yeah ... that was pointed out in bug :)
<asac> you should reboot i guess
<stgraber> argh, brb then :)
<stgraber> ok, so I always have that : real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
<stgraber> problem is that I can't really force it to try again as it fallback to wired
<stgraber> asac: ^
<asac> stgraber: opk i updated the nm ... dropped the hack we introduced et al:
<asac> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
<asac> stgraber: why not? can't you just click on the wireless network ap again?
<stgraber> hmm, yes, doesn't help
<asac> stgraber: ok ... please try the branch above
<stgraber> pulling
<asac> stgraber: maybe it helps here ...
<asac> stgraber: otherwise ... have you build the ipw branch?
<stgraber> yes, that's the ipw3945 I'm currently using
<asac> stgraber: if it works i would ask siretart to see if he can reproduce the "cannot connect" issue and then see if using older wpasupplicant helps
<asac> stgraber: can you please post a debug log of wired->public->wired->public as well?
<asac> stgraber: i just want to confirm that the driver behaves now as i want it to behave :)
<asac> stgraber: but at best test the new network-manager from my branch
<Kano> hi, is there a special trick needed to use firmware in /lib/firmware/$(uname -r)?
<asac> stgraber: hmm i see that there are still two patches in the dev.opennet branch that i didn't want ... anyway they should do no harm for us
<Kano> hmm maybe in hotplug functions
<stgraber> asac: I haven't been able to reprodue the wired -> public -> wired -> public problem, it only happens when doing wired -> wpa -> public now
<asac> stgraber: ok so bouncing betweek public -> wired works as long as you try?
<stgraber> asac: http://paste.stgraber.org/3316
<asac> stgraber: what case is that?
<asac> the wpa?
<stgraber> wired -> wpa -> public
<stgraber> I tried 4-5 times switching between wired and public without any problem, so previous problem might have been the "NM got stuck at stage 1" problem :)
<stgraber> which seems to appear randomly
<asac> stgraber: does it still appear at all?
<asac> stgraber: i think yesterday it might have been due to the cruft patch we had
<asac> stgraber: is all this with opennet.dev network-manager?
<stgraber> no
<stgraber> haven't built it yet
<asac> stgraber: ok ... the log appears to be incomplete anyway
<stgraber> I stopped the log when NM showed the connect to wired icon
<asac> he?
<asac> i mean i don't see that wpa succeeded
<stgraber> strange
<asac> i think its imcomplete ... because otherwise you would not have seen the wireless icon in nm-applet
<asac> anyway ... try with new network-manager please
<asac> the old one is just two aggressive
<stgraber> asac: ~line 1437
<asac> i only see 500 :)
<stgraber> hmm
<stgraber> pastebin limitation :)
<asac> http://paste.stgraber.org/3316
<asac> stgraber: try pastebin.mozilla.org
<asac> or just upload :)
<stgraber> same limitation, will upload
<stgraber> http://www.stgraber.org/download/debug-nm
<asac> stgraber: ok we are struck by wpasupplicant cleanup issues as it looks like
<asac> stgraber: can you try with new nm ... and if we still get that let me know?
<stgraber> ok, just tried new NM
<stgraber> results aren't good
<stgraber> same problem with switching from wpa to public
<stgraber> + had a NM crash
<stgraber> + failed to switch from public to wpa
<stgraber> the crash happened when connecting to WPA network
<asac> stgraber: please comment out the last patch in series (41p_set_enc_key_NULL_in_wireless_real_init.patch)
<stgraber> k
<asac> stgraber: can you still switch open->wired and back?
<stgraber> asac: yes
* Bsims_ grrs my connection reboots at random and no one in #ubuntu knows why... any ideas I tried reinstalling dhcdbd and all related
<Bsims_> I want to know what to file a bugreport against
<alex-weej> asac: do you know much about rt2x00?
<alex-weej> Bsims_: just file it against ubuntu if in doubt, someone will triage it
<alex-weej> or "don't know"
<asac> alex-weej: don't know the name at all :) ... whats that? realtek? ralink?
<alex-weej> asac: yeah
<asac> alex-weej: yeah doesn't answer my question :)
<alex-weej> ralink
* Bsims_ nods I noticed that trying to run BT will automaticaly trigger it but after a reboot it should just work again
<alex-weej> the project took the open source ralink drivers and improved them, then they started the "rt2x00" driver which was supposed to unify them all. but rt2x00 isn't finished, it's still beta, and it doesn't work.
<asac> only thing i have heard of ralink is that the drivers are a mess :)
<alex-weej> yet we're bundling it.
<Bsims_> but that is not the case
<alex-weej> the older drivers work better, but they're not distributed anymore :/
<asac> alex-weej: i guess the older drivers have their own share of deficiencies as well :)
<alex-weej> asac: at least they associate with WAPs
<alex-weej> (and FWIW i've had no problems running rt73)
<alex-weej> with my linksys usb dongle
<Bsims_> Ah it is in the buglist https://bugs.launchpad.net/ubuntu/+source/dhcdbd/+bug/93360 but will someone at least set a importance level for it
<ubotu> Launchpad bug 93360 in dhcdbd "Dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason" [Undecided,Confirmed] 
<Bsims__> sorry it died again was anything addressed to me
<alex-weej> no
* Bsims__ nods and tries shutting it down for a bit
<stgraber> asac: it seems that the opennet NM also try to associate in background ...
<asac> he?
<asac> stgraber: it never was ment to fix anything in this regards
<stgraber> no, but the driver change fixed that :)
<asac> yes ... and now its back?
<stgraber> yes
<stgraber> doing : iwconfig eth1 essid off
<stgraber> disconnect and connect 3s after ..
<asac> well ... but with the current gutsy nm that doesn't happen?
<stgraber> indeed, with current gutsy NM + patched driver that doesn't happen
<asac> stgraber: could you at least connect to WPA now that you dropped the NULL wep key patch?
<asac> stgraber: but this auto-associate doesn't affect the overall usability, right? e.g. open network connecting dstill works?
<asac> stgraber: maybe its the *NEW* driver that makes this auto-association happen again?
<asac> e.g the one from bzr?
<stgraber> ok, I've reloaded everything and now auto-association doesn't happen anymore (maybe it was caused by the kill+reload I had to do a minute before), I can switch between WPA network correctly
<asac> ok ... and then going back to open doesn't work?
<stgraber> WPA -> open still fail
<asac> ok ... thats what we need to figure out now ... does iwconfig still show the wpa key for your device?
<stgraber> but I didn't have the supplicant error this time, so it might have been the random "got stuck at stage 1" thing
<asac> hmm
<stgraber> no it doesn't
<stgraber> let me try again
<asac> so its stuck?
<asac> and you cannot switch to wired?
<asac> siretart: where did you post your wpa 0.5.8 packages?
<asac> siretart: maybe you can push them to a paa?
<stgraber> second try, same result got stuck at stage 1
<asac> stgraber: without the wpa supplicant "cannot connect" ?
<asac> stgraber: is the process still alive? e.g. can you switch to wired now?
<stgraber> and finally third try I have the supplicant error ...
<asac> so which one is easier to reproduce for you now?
<stgraber> no, when I got stuck at Stage 1 I can't select wired I have to kill NM
<asac> so we can concentrate on that one for now :)
<stgraber> the supplicant one was less random in the past
<stgraber> good, I was able to reproduce the supplicant one
<stgraber> Sep  2 22:42:27 laptop NetworkManager: <info>  Error opening supplicant global control interface.
<stgraber> Sep  2 22:42:27 laptop NetworkManager: <WARN>  real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
<asac> stgraber: yes .... thats really interesting
<asac> stgraber: both issues could be related if the device worker is not running
<siretart> asac: the 0.5.8 packages are still at http://siretart.tauware.de/upload-queue
<siretart> asac: and for the ppa, you still haven't answered me to which ppa we should push it
<asac> siretart: ah ... ok i can either upload to mine ... or to yours :)
<asac> thanks for the info
<asac> stgraber: can you try the wpasupplicant packages from http://siretart.tauware.de/upload-queue ?
<stgraber> building
<siretart> asac: feel free to upload to yours. beware that the version is currently lower than the package currently in gutsy
<asac> siretart: yes thats ok i think
<stgraber> asac: same problem with that wpasupplicant
<zasf> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<zasf> !weekdays
<ubotu> Sorry, I don't know anything about weekdays - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<zasf> !weekday
<ubotu> Sorry, I don't know anything about weekday - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<asac> siretart: do you know how the clean way to shutdown wpa supplicant is?
<asac> siretart: e.g. not using kill
<asac> e.g. something like EXIT when in wpa_cli
<asac> but i didn't find anything
<asac> siretart: another question is if we can stop wpasupplicant from doing anything by DISABLE_NETWORK 0 ... and then set AP_SCAN 0
<asac> ?
<asac> siretart: hmmm we use interface_add ... is there something like interface_RM ?
<asac> siretart: ok found interface_remove ... it is
<soren> asac: TERMINATE?
<soren> asac: Or is that not what you're asking? :)
<asac> soren: yes i found
<asac> soren: thanks
<asac> works great i guess :)
<soren> \o/
<soren> asac: np
<asac> soren: you have ipw3945 as well?
<soren> asac: Nope.
<asac> good for you ... so you don't need to test for me ;)
<asac> soren: does your nm work?
<soren> asac: atheros (and access to and ipw2200) if you ever need them for testing.
<soren> asac: Yeah, no problems here.
<asac> i have an ipw2200 bug as well
<asac> wait
<asac> stgraber: i pushed a new patch that should shutdown wpa supplicant more gracefully
<asac> to .opennet branch
<stgraber> ok
<asac> stgraber: i think you won't have to test ... i see the wpasupplicant error here as well
<soren> asac: Well, "no problems" is not entirely true, actually, but it's not really nm's fault. I've come across a few AP's whose DHCP servers seem to not work with dhclient. I haven't gathered enough debugging info to file a bug yet, though.
<asac> soren: when you are sure that its dhclient ... then i am out of that ;)
<stgraber> asac: looks like "terminate" isn't the right command
<asac> stgraber: yes it needs to be UPPER case
<asac> anyway the problem does not really go away
<asac> stgraber: but maybe try yourself (as you have 0.5.8 supplicant)
<asac> my wpa supplicant often gives me busy results when adding the interface
<asac> stgraber: i often get:
<asac> asac@hector:~/ubuntu_nm/wpasupplicant.stable.debian$ sudo wpa_cli -g /var/run/wpa-global INTERFACE_ADD wlan0 "" "" /var/run/wpa-run
<asac> 'INTERFACE_ADD wlan0                    /var/run/wpa-run                ' command timed out.
<asac> on command line
<asac> but i can afterwards just go ahead and use it as normal ... and wpa_supplicant actually starts scanning et al after that command
* sladen picked up another ACM magazine with mako inside the front cover today.  And I *still* don't understand the advert...
<stgraber> asac: http://paste.stgraber.org/3319
<stgraber> Have to wake up early, see you
<asac> stgraber: ok night!
#ubuntu-devel 2008-08-25
<dholbach> good morning
 * slangasek waves
<dholbach> hi slangasek
<lifeless> dholbach: do you have a script to repeat what you say on every channel ? :)
<dholbach> no, it's easy enough without a script :)
<RAOF> <up><enter>!
<persia> Depends on the client.  Some clients have <up> bound to the channel.  Paste/enter can help.
<stgraber> some clients also have /msay that just sends a message to all channels (irssi doesn't)
<dholbach> does the "report a bug" menu item work for you guys in intrepid?
<dholbach> ok... seems to be generally broken
<nxvl> dholbach: you are early today, good morning
<nxvl> dholbach: mimi needed to wake up earlier?
<dholbach> nxvl: exactly :)
<dholbach> nxvl: how are you doing?
<nxvl> good
<nxvl> it was a good and quiet weekend
<nxvl> waiting for news which i expect to get tomorrow morning or the day after it
<nxvl> i hope
<ion_> stgraber: Haven't tested, but i assume /fore chan /say foo works.
<ion_> stgraber: Oh, in fact /fore win foo should work, which i consider almost a bug. IMO the syntax should be /foreach <object> <command> <args> instead of /foreach <object> /<command> <args> where a missing / causes it to send messages.
<wolfe> persia: you there?
<persia> wolfe: Typically, although I much prefer content with my alerts.
<wolfe> persia: oh, sorry :)
 * persia waits for content, planning to go back into context soon.
<wolfe> persia: if someone were using a sensor for detecting when someone was speaking, what type of sensor and where would it be placed?
<wolfe> persia: I'm starting to get in to anitronics >.>
<wolfe> *animatronics
<wolfe> though mostly for special costumes =]
<persia> I'd probably rely on bone conduction for that, placing a sensor just before the ear or just under the ear.
<wolfe> hmm
<wolfe> I'm thinking about making a kangaroo custome which has a moving jaw and eyes
<wolfe> just something cute
<wolfe> I'm probably going to make it somewhat complex if I can... like this.. http://www.youtube.com/watch?v=B2u7ekG51to
<wolfe> I wonder how much money they spent for the specified 30 second commercial xD
 * persia doesn't have the right combination of software to watch youtube, but suspects "bunches" is roughly correct.
<ion_> youtube-dl and whatever player you prefer.
<wolfe> its a korean commerial of this kangaroo who is selling SENS. With moving eyes, jaw, and ears.
<persia> ion_: Actually, there are a wide variety of combinations that work.  However, having said combinations installed tends to cause me to watch videos, which is not something I tend to find to be the best use of my time :)
<zver> hello. when somebody fix depends on pgbouncer to postgresql-8.2 in intrepid   ?
<persia> zver: Specific tasks like that don't tend to be scheduled.  You might open a bug about it, or wait until someone does it.
<zver> persia: ok
<ArneGoetje> if we do a Fake-Sync, because the same package has been maintained in parallel in debian and ubuntu, do we need to copy the package history of the ubuntu package into the resulting changelog? or is it not necessary?
<yao_ziyuan> i just bought a new Samsung DVD recorder and it can read a data CD well under win xp but not well under ubuntu 8.04 + kde 4.1.
<yao_ziyuan> someone told me this could have something to do with the kernel driver
<yao_ziyuan> so, is it true that new hardware must wait some time for the linux kernel to catch up?
<ArneGoetje> the point is: the original tarball comes as .zip and has been repackaged by two different individuals, once for debian and once for ubuntu and has been maintained in parallel since then.
<persia> ArneGoetje: Generally, a fakesync should only happen in the case where we'd like to do a real sync, but the orig.tar.gz differs.
<ArneGoetje> persia: that's the case here
<persia> Personally, I don't tend to keep Ubuntu packaging information when I do a fakesync, and I tend to use a -Nbuild1 version so that it goes away in the future.
<dholbach> persia: what happens if Debian uploads a   -<N+1>?
<persia> dholbach: The sync fails, and it gets dumpted into manual merges on MoM.
<persia> dholbach: I suppose perhaps using Nubuntu1 means that the flag is raised beforehand, so it's less confusing.
<dholbach> yeah, I thought so
<ArneGoetje> persia: ok, so use ubuntu1 and drop the old ubuntu changelog and use the debian one instead... ?
<RAOF> Then what happens if debian uploads $VER+1-1?
<persia> RAOF: Then one needs to request a sync from the archive admins.
<persia> ArneGoetje: That sounds right to me.
<RAOF> Fair enough.
<ArneGoetje> persia: ok, thanks
<persia> yao_ziyuan: Sometimes.  It depends on the hardware.  If new hardware is introduced for which there is no support by any existing drivers, someone needs to add it.  As the owner of hardware so affected, you're in an excellent position to do so.
<persia> Note that much of the hardware being produced these days adheres to various standards to reduce the driver development effort by the hardware manufacturers, and so is not so affected.
<fabbione> hi guys
<Simira> morning fabbione
<fabbione> hey Simira
<Simira> fabbione: how is your family?
<fabbione> Simira: pretty good thanks
<fabbione> and you?
<Simira> fabbione: enjoying life in Cambridge for the weekend
<fabbione> Simira: ehhe vacation or work?
<Simira> fabbione: your kids, they are 2 and 3 years old now?
<fabbione> Simira: nah... 2 and 8 months
<Simira> fabbione: vacation, Debian BBQ + some sightseeing
<fabbione> Simira: lucky you ;)
<Simira> fabbione: sounds lively :)
<Simira> fabbione: yup, lucky me
<fabbione> Simira: they are two little angels with big red horns ;)
<Simira> I can imagine
<\sh> hmm...is there any way to download the ubuntu netbook remix somehow? I would like to test it on my aspire
<davmor2> \sh: there is no current build if that is what you mean.  You can however install it menually.
<\sh> davmor2: you mean "install ubuntu via usb cd, and install the packages fom the remix ppa"
<davmor2> \sh: yeap
<\sh> ok :) that's easy ,->
<davmor2> /sh: there should be an image for intrepid at some point as far as I know just not yet :)
<\sh> davmor2: well, I just want to remove this linpus linux on it...looks quite nice, but it's somehow fedora based...
<emgent> moin
<bigon> could someone have a look at https://bugs.edge.launchpad.net/ubuntu/+source/enchant/+bug/261075 ?
<ubottu> Launchpad bug 261075 in enchant ".pc files indirectly adds --export-dynamic to the linker flags" [Undecided,New]
<devfil_> bigon: in Debian it is fixed, so a merge should be enough
<bigon> devfil_, it will require a merge as there are ubuntu changes made by slangasek
<asac> ogra: where do i find warren again?
<persia> bigon: devfil_: Although I don't usually advocate this pre-FeatureFreeze, the option so far unmentioneed is to port the specific patch from Debian without a full merge.
<ogra> asac, #ltsp but he is on boston time ... and usually hangs out here as well
<bigon> persia, yeah of course but the last debian upload only fix this issue
<ogra> no idea in what other channels he usually is
<asac> ogra: ok thanks. ill try to remember that for later today ;)
<ogra> tjaalton, what in hal calls debian-setup-keyboard (i want to do something similar for touchscreens so the calibration can sit in a different place)
<ogra> tjaalton, what in hal calls debian-setup-keyboard (i want to do something similar for touchscreens so the calibration can sit in a different place)
<ogra> tjaalton, i have http://paste.ubuntu.com/40402/ but no idea how to call it or from where
<stefanlsd> Does firefox hang  for anyone else when trying to access   www.axxess.co.za  ?
<emgent> stefanlsd: me too
<stefanlsd> emgent: thanks. yeah. maybe flash. i've been getting it lots lately.
<thorwil> stefanlsd: not here. i have flash-block ...
<emgent> true, go via links2 -g
<emgent> :)
<stefanlsd> thorwil: mm. good idea. think i'll try that :)
<ogra> asac, does midbrowser use ubufox anywhere ?
<emgent> 100% CPU
<emgent> nice..
<asac> ogra: it doesnt. why?
<asac> is that wanted?
<ogra> heh, no
<ogra> i'm just cleaning up the current ubuntu.mobile seed (new for intrepid)
<ogra> and was dropping FF in favour of MB
<asac> good
<asac> ogra: is the home applet using xul 1.9 in intrepid?
<ogra> no idea, ask the maintainer .. i dont use it anywhere yet
<asac> ogra-Q1 <- isnt running the home screen?
<asac> what a hoax ;)
<ogra> asac, http://people.ubuntu.com/~ogra/ubuntu-mobile-intrepid.png
<ogra> thats how my ubuntu-mobile on te Q! looks like atm
<ogra> plain gnome, three extra apps
<ogra> *Q1
<asac> nice
<ogra> and settings
<asac> ogra: nm 0.7?
<ogra> whatever is in ubuntu-desktop :)
<asac> ogra: tbird is in the seeds?
<asac> good news ;)
<asac> wel ... partially good news.
<ogra> why partially ?
<asac> the bad is that tbird 3 probably wont be able to use system-xul
<ogra> meh
<asac> because the whole mailnews mess turns out to be too hard to migrate before 3.1
<ogra> will we switch before release ?
<asac> ogra: unlikely
<ogra> well, then i'm fine
<asac> i think in intrepid+1 they will have a release
<ogra> ubuntu-mobile is a first shot only now
<ogra> fine tweaking will be done in intrepid+1 ... for intrepid having it basically usable and not to ugly is enough
<tjaalton> ogra: 10-x11-keymap.fdi
<tjaalton> ogra: so you'd need to match the device and add the callout
<ogra> ah
 * ogra will test that later today
<tjaalton> ogra: create a new fdi file for evtouch.. that could then be added to the package
<dholbach> maybe somebody could give a session at Ubuntu Developer Week about  https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases  ?
<ogra> tjaalton, right, but it needs matches for the touchscreen devices as well
<tjaalton> ogra: yes
<ogra> tjaalton, so it will rather be multiple files ... which i'd still like to see in hal-info to get at least the right drivers (many touchscreens default to "mouse" or "evdev" if hal doesnt know anything about them)
<ogra> which simply doesnt work
<tjaalton> why multiple files?
<ogra> i'd also like to see evtouch in the default selection of input drivers but thats likely something bryce has to decide
<ogra> because there are plenty of devices
<tjaalton> they can all be in the same file, see synaptics
<ogra> with different ways of recognizing them as touchscreens
<ogra> hmm, that would become a complicated file
<tjaalton> tough :)
<ogra> i'd like to find a way to categorize them and have one file per category
<persia> tjaalton: There are lots of classes of touchscreens.  Should they really all the the same file?
<ogra> i.e. there are the ones with input.mouse capabilities you can only recognize by other info ... then there are some that register as input.touchpad etc
<ogra> HW wise thats a big mess
<persia> I'd think one file per class of touchscreens would make more sense.
<tjaalton> one per driver?
<ogra> well, what i said above applied to evtouch alone
<tjaalton> right :)
<ogra> there are other touchscreens with other drivers (serial ones etc)
<tjaalton> and wacom
<ogra> right
<persia> tjaalton: But even in the evtouch case, there are some that identify themselves as touchscreems, and some that identify themselves as mice.  Can these not also be separate files?
<tjaalton> persia: yes they could, but I still don't see why keep them separate
<Hobbsee> lifeless: use /ame
<Hobbsee> lifeless: it seems to be the standard
<lifeless> Hobbsee: ?!
<tjaalton> persia: not that it would be a huge issue to me.. the fdi files will eventually be upstream (like synaptics has)
<Hobbsee> lifeless: earlier you asked about a script to broadcast the same thing on multiple channels :)
<lifeless> Hobbsee: no
<Hobbsee> well, commented on it
<lifeless> you misread the intent of my question :)
<Hobbsee> or reinterpretted it.  but yes :)
<Adri2000> amsn srus for dapper and gutsy are tested and can be copied to -updates now, bug #243722
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,Fix committed] https://launchpad.net/bugs/243722
<huats> I am not very familiar with python-support, so if someone is, I'd like to ask a few questions
<persia> huats: You may find #ubuntu-motu to be a more useful forum for that sort of question.
<huats> :)
<huats> ok
<huats> thanks persia
<soren> When does slangasek usually show up?
<pwnguin> as soon as the germans leave ;)
<cody-somerville> soren, thats a difficult one to answer... usually he just doesn't leave at all :P
<pwnguin> those IRC stat generators could probably answer such a question
<persia> soren: He's UTC-7, so probably not for a few hours yet.
<soren> persia: Cool. Thanks.
<persia> pwnguin: Those aren't necessarily accurate.  For quite a while I had about even stats in all timezones in one channel.
<zul> soren: soon probably :)
<asac> geser: are you openvpn master? look at bug 260291
<ubottu> Launchpad bug 260291 in openvpn "Network Manager 0.7, openvpn, VPN Connection Failed" [High,Confirmed] https://launchpad.net/bugs/260291
<asac> appars to have regressed with one of the last openvpn uploads
<zul> asac: what happened?
<zul> asac: : ping *sigh* itll be fixed today
<geser> asac: sorry no, I'm not a openvpn master
<asac> zul: ?
<asac> geser: ok thanks. just found your name in the changelog there ;)
<zul> asac: openvpn
<asac> zul: oh. you know that bug?
<zul> asac: yeah its in the NEWS file
<zul> im modifying the init script so its backwards compatible
<asac> zul: rock. can you close that bug in the upload?
<zul> asac: yep
<asac> ill close the network-manager-openvpn task as invalid then
<asac> thanks
<zul> asac: fix has been uploaded
<LaserJock> dholbach: I'll have a look at the matplotlib merge (I've been communicating with upstream on it)
<dholbach> LaserJock: excellent
<dholbach> gracias
<LaserJock> Bitte schÃ¶n
<slangasek> soren: much later than 6:45 :-)
<soren> slangasek: Slacker.
<soren> :p
<soren> :)
<bazaar> hi. why does gettext output a standard char * pointer, and not wchar_t * -- shouldn't the output be wide characters as it some unicode/utf stuff?
<slangasek> no, char * is the standard type for strings in Unix
<slangasek> and UTF-8 is not a wchar representation
<ion_> Yeah, UTF-8 is an 8-bit encoding.
<bazaar> so do chinese characters fit in a char * ?
<bazaar> 'how do ...
<persia> bazaar: A sequence of bytes, with the most significant bits being a flag for the renderers.  Documentation on the UTF-8 encoding may be helpful.
<soren> Err.... Can someone explain what I need to do to bug 251480 to get it listed on https://bugs.edge.launchpad.net/ubuntu/+source/kvm?
<ubottu> Launchpad bug 251480 in kvm "X hangs in Intrepid in KVM" [High,Confirmed] https://launchpad.net/bugs/251480
<Laney> soren: It probably doesn't show as it's Fix Released
<soren> Laney: Except the hardy task, which is "confirmed".
<Laney> soren: Yes, but the +source/kvm page only shows Ubuntu tasks, AFAICS
<Laney> soren: It does show at https://bugs.launchpad.net/ubuntu/hardy/+source/kvm
<LaserJock> yeah
<soren> Well, i guess I can add an intrepid task, set that to fix released, and set the "general" state to "Confirmed".
<LaserJock> the plain bugs listing doesn't show release targeted bugs, you have to go to the release specific bug listing
<soren> Mky
<soren> mkay, even.
<soren> Yeah, that didn't help. :(
<LaserJock> soren: now you're makin' a mess :-)
<soren> Yeah :(
 * soren goes and stands in the corner
<slangasek> bugs that are fixed in the latest dev release are not expected to show up under ubuntu/+source/
<slangasek> only under ubuntu/$targeted_release/+source
<soren> That seems suboptimal. It'll usually be fixed in the latest dev release first. I don't want it off my radar until it's fixed everywhere, I think.
<LaserJock> although I would think one would assume that the ubuntu/+source list would give all open bugs and that you'd use ubuntu/<devel release>/+source if you wanted to weed out others
<geser> it's known as bug 121602
<ubottu> Launchpad bug 121602 in malone "Bugs open for earlier series are hard to find once closed for later series" [High,Confirmed] https://launchpad.net/bugs/121602
<soren> geser: Thanks.
<kees> slangasek: okay for me to move from md5 to sha512 in pam?
<tseliot> superm1: did you have a look at the code I wrote for you?
<superm1> tseliot, yeah it looked good.  it is going to be in the next -common upload
<superm1> thanks
<tseliot> superm1: great :-)
<slangasek> kees: well, no objections on my side :)
<bryce> tseliot, superm1: I spoke with ATI about the fglrx/xserver 1.5 issue.
<bryce> so they're aware of it and are also anxious to find a solution.  I presented several options and am waiting to hear back.
<superm1> bryce, what options did you present to them?
<superm1> of course the most ideal is that they just get support for xorg 1.5 :)
<bryce> a) revert the change that removed the symbols (which sounds like a gordian knot)
<tseliot> bryce: shall we try to reintroduce the AllocatePrivateIndex or whatever it's called in the xserver?
<bryce> b) put in a stub version of the symbol (which we'd need their assistance with)
<bryce> c) a hotfix version from them that doesn't use the symbol
<superm1> yeah, i don't think (a) is a feasible solution at this point
<superm1> especially with how big of a change that is
<jcristau> b doesn't sound like a feasible solution to me
<bryce> d) SRU the version with 1.5 support post-release
<bryce> jcristau: yeah I indicated (c) would be the best option.  I don't know what miZeroLineScreenIndex does exactly but assume a stubbed function would cause breakage elsewhere.
<jcristau> bryce: that symbol is just the tip of the iceberg
<jcristau> bryce: there are multiple abi and api changes between 1.4 and 1.5
<bryce> (d) I think is a bad option because all fglrx users would break on upgrade.
<superm1> not to mention that we don't have all the other integration pieces (eg jockey) fully tested with the new way of doing things
<bryce> one option I didn't present but that I guess also belongs on the list is e) reverting to xserver 1.4
<jcristau> bryce: at least the xace-selinux work, and pci-rework
<materic> Hi i need a help for running a just compiled code. can i address the question?
<tseliot> bryce: miZeroLineScreenIndex is not the only problem. I have tried to fix that and I got an error about AllocateScreenPrivateIndex. AFAIK miAllocateGCPrivateIndex is used in X now.
<bryce> materic: wrong channel -> you want #ubuntu
<tjaalton> bryce: you forgot to add a smiley ;)
<bryce> :-D
<bryce> morning tjaalton
<tjaalton> hi all
<bryce> fwiw Intel also wishes us to revert back to 1.4, but I think the issue they are seeing is just a normal bug we can probably solve in the next 1-2 months
<jcristau> tseliot: right, the devprivates rework is a major api/abi change
<bryce> another option I did not mention is to just drop -fglrx as a supported driver
<tseliot> bryce: that would certainly solve our problem ;)
<bryce> anyway, if anyone else has more ideas on options I'm all ears, that seems to be the scope though.
<superm1> would reverting back to 1.4 mean that newer drivers have to be reverted too?
<tjaalton> bryce: intel? what bug exactly?
<bryce> superm1: I'd assume we'd have a big mess on our hands
<jcristau> all that because ati can't get their act together?
<bryce> tjaalton: unfortunately they filed it private and didn't subscribe me, so I only have a vague description to go by
<ramses-sv> run active_notice
<tjaalton> bryce: ok
<bryce> tjaalton: it's with a newer / unreleased chipset so I suspect it's just a normal hw support issue, nothing earth shattering
<tjaalton> bryce: ok, at least our current driver doesn't support Xv for G45, since one of the patches disable textured video
<tjaalton> and the chip doesn't support anything else
<tjaalton> also, we have 2.4.0 while there is 2.4.1 ready to be merged
 * bryce nods
<bryce> hey, any idea of when xserver 1.5 will be released?
<tjaalton> when mesa 7.1 is released
<tjaalton> at least GEM is dropped from it so there's no need for a new libdrm as well
<jcristau> mesa 7.1 should come this week, according to brian
<tjaalton> so it seems
<tseliot> bryce: in any case I think we should prevent dist-upgrades from crashing X because of the 2 NVIDIA legacy drivers and of the ATI driver.
<elmo> bryce: do you know why we still ship i855-crt in main?
<tjaalton> tseliot: that's doable by "blacklisting" those drivers, and let them use nv/ati instead
<tjaalton> after upgrade
<tseliot> tjaalton: ok but if a driver is set in the xorg.conf you can blacklist the kernel module
<bryce> elmo: no, I'm not familiar with that package, why do you ask?
<tseliot> tjaalton: but that wouldn't prevent X from crashing would it?
<tjaalton> tseliot: no, but a forced dexconf run would
<elmo> bryce: I filed a bug on it, years ago, saying "we should either demote/remove this package, or actually apply the patches people send for it", and people keep pinging me about the bug
<elmo> I'm pretty sure it's entirely obsoleted by xrandr
<elmo> but I'm also guessing ;-)
<bryce> elmo: could be
<tjaalton> shocking, it is still in main
<bryce> elmo: I don't recognize it as a package on the ubuntu-x package list; maybe it's just cruft?
<verwilst> hm, i just made a deb but it installs stuff in /usr/usr/lib/...
<elmo> bryce: I think it is, yeah.  if you guys don't want it, no one else will :)
<tjaalton> bryce: should be removed. no code changes since 01 Sep 2004 :)
<tseliot> tjaalton: ok, so we would have to detect the card and see if it's not supported by a driver which works with X and force a dexconf if required, since we don't want to break nvidia-glx-177 and 173
<superm1> tjaalton, tseliot alternatively just not offer dist-upgrades if any of those packages that will cause breakage are present, at least until sorted out
<bryce> yeah, poking through it, it looks like a ubuntu-only package that has become direly obsolete.  I'll file a removal request
<bryce> elmo: thanks
<elmo> bryce: np, thank you :)
<tseliot> superm1: yes, that's an option, unless you're doing the dist-upgrade from the command line
<tjaalton> cmdline is hard.. those people will notice when/why X doesn't work ;)
<tseliot> superm1, tjaalton: maybe we could reuse nvidia-common for such hardware check
<bryce> is there any reason we should keep i855-crt in universe, versus removing it entirely?
<bryce> since we're not even shipping -i810 anymore I'm guessing it'd be useless in universe anyway
<tseliot> tjaalton: very often do they use the command line and do things they shouldn't
<tjaalton> bryce: no, ditch it. no changes upstream since May 2004
 * tseliot > bbl
<bryce> ok, lp #261259
<ubottu> Launchpad bug 261259 in i855-crt "Please remove i855-crt from the archive" [Undecided,New] https://launchpad.net/bugs/261259
<bryce> hm, wonder if there's any other ancient X cruft that escaped our cleanup
<tjaalton> maybe if there's a list of packages that are only in ubuntu. should be pretty easy to check
<bryce> yeah was just trolling around for that.  anyone know if there is such a list?
<kees> slangasek: if I change common-password, what do I need to do to the .md5sums file?
<LaserJock> bryce: http://qa.ubuntuwire.com/multidistrotools/all.html#notinA
<bryce> LaserJock: aha thanks
<bryce> lotta kde stuff there...
<ogra> we're ahead wrt KDE
<bryce> "p0rn-comfort" ??
<Riddell> debian isn't changing to KDE 4 until after their next release
<Riddell> and today I discovered Mithrandir and a large proportion of Debian punting along the river Cam which is no way to get a release out of time :)
<Riddell> s/of/on/
<LaserJock> lol
<bryce> ok, I didn't spot any additional X cruft in that list.  At least, nothing we don't already know about
<kees> bryce: ... hunh.  that appears to either predate the original-maintainer stuff (and hasn't been updated since original upload) or has been long-since removed from Debian.
<slangasek> kees: nothing at all \o/
<kees> slangasek: I like the sound of that.  :)
<kees> slangasek: should I renumber the current pam bzr to ubuntu5 (instead of 4.1) add my md5->sha512 change and upload the results, or is that change not something you want in intrepid?
<slangasek> kees: er, yes, renumber to ubuntu5, sorry; as for uploading, I have more changes pending today
<slangasek> kees: but I don't know of any reason we can't switch from md5 to sha512 for intrepid
<slangasek> I'm relying on your judgement that this is better for security :)
<kees> I'm just trying to think ahead for the next LTS.
<kees> slangasek: I've committed my changes to bzr so you can roll them into your pending changes for the next upload.
<slangasek> ok
<slangasek> kees: oh, I guess I read what I wanted to above rather than what you said; yeah, we need to do something wrt the change to the common-password template, but the code's not there yet to do this, so you needn't worry about it anyway :)
<slangasek> that'll push back the upload a bit, though; need to have that sorted before we go changing the template further
<kees> slangasek: okay -- I have yet to really understand the per-package profile stuff you've made.  I've only poked around the edges so far.
<mathiaz> slangasek: kees has run into an issue when installing slapd in non-interactive mode and a debconf level of critical - the admin password for cn=config is not generated
<mathiaz> slangasek: kees suggested to use a random password for cn=config if debconf is unable to prompt for the password
<slangasek> mathiaz: er, and then how will the user find out that password, or be able to change it?
<mathiaz> slangasek: well - the other option is to not put a password
<kees> slangasek: if the admin is crazy enough to have their debconf set that high, shouldn't it be their problem?  :)
<slangasek> why is either of these options better than failing when using the noninteractive frontend? :)
<kees> slangasek: because i can't automatically install slapd for testing in intrepid now.
<slangasek> kees: preseeding?
<kees> slangasek: I shouldn't have to know that in advance to have an installable package.
<slangasek> I think leaving the system with no way to administer the config is some pretty bad foot-shooting
<slangasek> you don't have to know that in advance unless you insist on using the non-interactive frontend
<kees> I'm using the non-interactive frontend.  ;)
<kees> there should be a viable default.
<slangasek> there *isn't* a viable default
 * kees holds his face
<slangasek> the default you're proposing leaves the user without a viable server, because it can't be administered
<kees> okay, so, prior to slapd installs, I just need to run "echo set slapd/internal/adminpw asdfasdf | debconf-communicate" ?
<slangasek> yes
<mathiaz> kees: well - you have to compute a proper string for slapd/internal/adminpw
<slangasek> mathiaz: he should be able to set the cleartext question, instead?
<slangasek> (which is the one I meant to say 'yes' to)
<mathiaz> slangasek: yes -
<mathiaz> kees: you can set the cleartext password with slapd/cfgpassword1 and slapd/cfgpassword2
<mathiaz> kees: ^^ these are the ones for the cn=config password
<kees> mathiaz: okay, well, I guess my main issue is I want to get the test-openldap.py regression test to pass again.  :)
<mathiaz> kees: ok - so you'd probably have to add support for slapd.d/
<mathiaz> kees: slapd.conf is no longer the default in intrepid
<slangasek> well, slapd can be /made/ to run with slapd.conf, you just don't get any of the package management support then
<kees> hrm, okay, well, I guess I will leave this alone for a bit -- I need to study a lot of openldap before I can dig in.  perhaps jdstrand will have some time to poke at it (he wrote the tests originally)
<mathiaz> slangasek: on a related note, I've managed to build the nss overlay
<mathiaz> slangasek: so I'm planning to ship the nss overlay in the slapd package directly
<slangasek> sounds reasonable
<jdstrand> I'd argue that people updating the package should be using the regression tests ;)
<kees> jdstrand: I agree.  ;)
<slangasek> then you'd better put them in the package instead of in an external repo... :)
<kees> slangasek: it can't sanely run from a build-test
<slangasek> hmm, why not?
<jdstrand> slangasek: not really an option for these tests
<jdstrand> generally, the qa-regression-testing scripts need external tools, install things in the default locations, etc
<kees> slangasek: it requires many additional packages, and performs a full (destructive) test of many many ldap functions.
<slangasek> additional packages --> Build-Depends
<jdstrand> slangasek: they are not just tests for binaries, bbut entire package tests
<slangasek> testing ldap functions -- upstream already has a test suite that does quite a bit of LDAP destruction :)
<slangasek> but ok, if you want a full-package test, that doesn't help
<jdstrand> slangasek: we change backends, sasl, and loads of other stuff
<jdstrand> even added some kerberos stuff
<slangasek> well, all that should be testable in a build tree
<slangasek> hmm, maybe not kerberos :)
<slangasek> but backend testing is already in the upstream testsuite
<jdstrand> slangasek: perhaps, but I don't think the security team (who has been doing most of the work on these) has the resources to update the packages-- not to mention, adding the tests to intrepid's build doesn't help when we want to test on dapper
 * slangasek nods
<kees> well, basic stuff seems to work, so I've uploaded a new openldap with PIE enabled...
<jdstrand> kees: what doesn't work anymore?
<YokoZar> Hmm, I'm getting hangs at login now but it's NOT the snd_pcsp issue...something else
<kees> jdstrand: test-openldap.py on intrepid
<jdstrand> kees: right, I meant what tests fail?
<kees> jdstrand: yes.  ;)
<jdstrand> oh-- all of them
<jdstrand> cool
<kees> jdstrand: it can't even figure out where the daemons are.
<jdstrand> nifty
<kees> jdstrand: so I've relegated this to the "post-freeze bug fixing" part of my TODO list
<jdstrand> I can say it was working the last time I touched it :)
<jdstrand> but that was before all the cnconfig work
<kees> right, that seems to be the "problem".
<jdstrand> kees: oh, well yes-- if we are pure cnconfig, then all our on-the-fly slapd.conf will have to be migrated
<jdstrand> (and I haven't done that either)
 * kees nods
 * jdstrand is finally up to speed
<dupondje> mysql got broken in AMD64
<mathiaz> dupondje: which bug are you refering to ?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/261066
<ubottu> Launchpad bug 261066 in mysql-dfsg-5.0 "mysql-server  5.0.67-0ubuntu1 not starts" [Undecided,Invalid]
<dupondje> ok got it fixxed
<dupondje> mysq-common 5.0.67 gets installed on AMD64 pc
<dupondje> but the mysql-server & mysql-client are still old versions (because build failed ...)
<kees> infinity: is this a result of the sbuild patch you made?
<kees> linux-kernel-headers: installed (negative dependency) (bad version ~*=PROVIDED=*= <= 2.5.999-test7-bk-17)
<kees> (while compiling dovecot)
<kees> infinity: hrm, I guess not.
#ubuntu-devel 2008-08-26
<LaserJock> siretart: around?
<ArneGoetje> hmm... seems update-notifier doesn't work anymore in intrepid... is this a known issue?
<ArneGoetje> @native-English-speakers: "In order to use your new langauge settings, please logout and re-login at your earliest convenience." Would this be an appropriate message to display to users? If not, suggestions please... :)
<ArneGoetje> s/langauge/language/
<bryce> ArneGoetje: looks good to me
<bryce> I might use 'enable' instead of 'use' but it reads fine either way
<ArneGoetje> bryce: thanks
<ArneGoetje> argh!!! seems the latest kernel modules update on intrepid hosed my system!!! no network, no X... :(((
<ArneGoetje> uff... no... just my own stupidity... :D
<mneptok> ArneGoetje: i rarely utter these words, but in this case ...
<mneptok> "mine's bigger"
<ArneGoetje> mneptok: your stupidity?
 * mneptok stares and drools
<mneptok> :)
<ion_> Mine isn't that big per se, but it's very concentrated.
<LaserJock> anybody notice apt-cacher behaving weirdly lately? it's acting kind of flaky and the apt-cacher report says 100% cache misses and 0 transfers
<slangasek> ArneGoetje: "please log out and log back in at your earliest convenience", IMHO
<ScottK> slangasek: Would you be up for a bit of late night archive admining?  I'm uploading kde 3.5.10 to hardy-backports now and it'd be nice to have it all ready there when Riddell wakes up.
<dholbach> good morning
<dholbach> who of you would like to give a session at Ubuntu Developer Week? https://wiki.ubuntun.com/UbuntuDeveloperWeek/Prep still has some free slots
<StevenK> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep perhaps
<dholbach> yes :)
<siretart> LaserJock: no, was already in bed
<siretart> morning, folks!
<LaserJock> siretart: I just had an emacs question
<LaserJock> siretart: emacs22 doesn't seem to like fonts
<siretart> LaserJock: well, it is an text editor, not a word processor after all ;)
<LaserJock> it helps my eyes if the fonts look decent though
<LaserJock> I'm supposed to use this for *everything* right? ;-)
<ajmitch> M-x make-me-coffee
<LaserJock> I tried and tried to get emacs22-gtk to load DeJavu or Bitstream fonts
<LaserJock> ended up just running emacs -nw in a terminator window
<siretart> LaserJock: Hm. I've been happy with the default fonts choosen by emacs-gtk
<LaserJock> ajmitch: I'm sure there's lisp code somewhere for that
<ajmitch> undoubtably
<RAOF> Don't you need emacs-snapshot in order for emacs to have non-eyebleeding font rendering?
<LaserJock> RAOF: I *thought* as long as it was >= 22 it should work
<siretart> LaserJock: did you already read chapter 27.16?
<RAOF> I'm fairly sure you'll find emacs-snapshot to work; it does for me, and 22 doesn't.
<ScottK> slangasek: If you're up for it, bug #261366 is all uploaded now.  Just needs accepting.
<ubottu> Launchpad bug 261366 in hardy-backports "Please update to KDE 3.5.10 in hardy-backports" [Wishlist,In progress] https://launchpad.net/bugs/261366
<ScottK> Good night all.
<siretart> good night, ScottK!
<LaserJock> RAOF: ok, so maybe our normal emacs packages aren't built with xft support?
<RAOF> That would appear to be the case.
<LaserJock> interesting
<LaserJock> I thought xft was considered stable in emacs 22
<LaserJock> in any case, the best solution for me seems to be emacs -nw :-)
<RAOF> emacs-snapshot works.  Or there's always emacs -nw, which is what I was using for a goodly while.
<dholbach> at last Ubuntu Developer Week we had a session about "Working With Debian" - is anybody interested in doing a session like that? I think it'd be great to have it
<siretart> is there already a bug for hotkeys broken on thinkpads in intrepid?
<tjaalton> siretart: do they produce events (xev)?
<siretart> dholbach: what did that talk cover? - and when would the lessen happen?
<siretart> tjaalton: no, not on my X60s
<siretart> tjaalton: upgraded to intrepid yesterday
<dholbach> siretart: https://wiki.ubuntu.com/MeetingLogs/devweek0802/Debian is the session log
<dholbach> siretart: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the current schedule
<tjaalton> siretart: try the .27 kernel. they seem to work fine on my X61 with it
<dholbach> so there are still some open slots
<siretart> tjaalton: is there a package for the .27 kernel yet? - or how can I try that out?
<tjaalton> siretart: http://kernel.ubuntu.com/pub/next/2.6.27-rc3/intrepid/
<tjaalton> the rc4 version is uploaded to the archive and built, just not published
<tjaalton> even suspend works with this (and not .26) :)
<siretart> suspend to ram works for me on .26, I didn't try out hibernate, though
<tjaalton> mine just resumes right away with .26
<siretart> tjaalton: oh, that directory misses lrm. I expect that would break my wireless (iwl3945), right?
<RAOF> siretart: I don't believe so, no?
<siretart> okay, then lets try
<tjaalton> siretart: nope, works fine
<RAOF> at least, I'm using that rc3 kernel and my iwl works
<navandres1972> hi everyone
<navandres1972> short question
<navandres1972> there is some a way to develop iphone code on ubuntu??
<dholbach> siretart: would you be interested in such a session?
<siretart> dholbach: why not, but I'm not sure if I find enough time to prepare myself. I'd be more happy to do that session in a team. please give me a few hours to check
<dholbach> who would be interested to give a session about "working with debian" together with siretart?
<siretart> tjaalton: booting .27 now. it enables bluetooth at bootup now? huh?
<siretart> tjaalton: yes, with .27 many hotkeys (not all) now do emit events in xev. thanks!
<tjaalton> siretart: cool
<siretart> tjaalton: bug 256887 however is present with .27 as well
<ubottu> Launchpad bug 256887 in hotkey-setup "thinkpad_acpi complains that hotkey-setup is doing the wrong thing" [Undecided,Confirmed] https://launchpad.net/bugs/256887
<siretart> perhaps not that surprising, but anyway. perhaps some hotkey guru might want to look at the package?
<fabbione> morning guys
<fabbione> Riddell: ping?
<baali> http://ubuntuforums.org/showthread.php?t=634034 is there any solution to this post,
<baali> i am stuck with same thing
 * fabbione really needs an archive admin to new a package
<dholbach> fabbione: I can't help you with that - sorry, but do you think you could take a look at bug 259579?
<ubottu> Launchpad bug 259579 in redhat-cluster "cman init script points at an incorrect doc path" [Low,Confirmed] https://launchpad.net/bugs/259579
<fabbione> dholbach: looking
<dholbach> yoohooo!
<fabbione> dholbach: oh absolutely.. i need to rework the init script anyway
<fabbione> that section is not even used in ubuntu packages.. it comes from debian
<dholbach> fabbione: nice... it turned up on my sponsoring queue radar and I thought that you might be the best person to talk to about it
<fabbione> dholbach: i'll take care of it
 * dholbach hugs super-fabbione
<fabbione> but i need people to new corosync so that new openais can build so that i can upload a new redhat-cluster :)
<fabbione> otherwise i can upload but it will stall there :)
<dholbach> yeah, that makes sense :-/
<sdh> hm
<sdh> if there's a bug in package foo on hardy, but it's fixed in the new version (which is in debian testing), do i need to file a bug on launchpad?
<cjwatson> if you want it fixed in intrepid+1, no; if you want it fixed in intrepid, yes; if you want it fixed in hardy, yes, with extra justification as to why it's worth changing hardy
<sdh> cool, ok thanks
<sdh> i'll go for intrepid :)
<cjwatson> in any of the "yes" cases, it will help to use the "also affects distribution" link to add a reference to the Debian bug URL
<soren> cjwatson: Did you say my debian-cd changes got merged?
<sdh> cjwatson: there is no bug url for debian, they just redesigned stuff and fixed it by chance :)(
<cjwatson> soren: yes
<cjwatson> sdh: oh, ok
<soren> cjwatson: Hm... Ok.
<dholbach> kees: did jdstrand talk to you about a security session at Ubuntu Developer Week? Does anybody of the MOTU SWAT know when you guys planned to hold such a session?
<Riddell> fabbione: pong
<fabbione> Riddell: hi, sorry i need some of your help to new a package because i think seb128 forgot about it (even if he said he was going to do it)
<fabbione> Riddell: do you have time now?
<Riddell> fabbione: can do
<fabbione> Riddell: ok awesome. main had src: openais that has been spitted upstream into 2 sources. source one: corosync (need both src and binary new) and openais (new version)
<fabbione> Riddell: i didn't file a MIR for corosync (on seb128 input since it's just a split), but it needs to go in main
<fabbione> Riddell: corosync is now a Build-Dep for openais and redhat-cluster
<Riddell> looking
<fabbione> thanks
<fabbione> Riddell: thanks.. got the emails
<soren> cjwatson: Do you have a minute to spare? It's about those debian-cd changes.
<Riddell> fabbione: accepted corosync
<fabbione> Riddell: awesome thanks again
<cjwatson> soren: go ahead
<soren> cjwatson: When I added the "minimal server" install option, I put it into gfxboot.cfg, because the code I copied did that, but it seems that it actually belogs in text.cfg (and has to look differently), but I'm not sure at all where to put the code then.
<cjwatson> soren: why does it belong in text.cfg? the other similar options aren't there
<soren> cjwatson: PErhaps we have a different understanding of "similar" :)
<soren> Well, ok, let's start from the top.. Where does it belong?
<dholbach> evand: What do you think about a session about the Installer (and the Team behind it) at Ubuntu Developer Week?
<soren> ...and then let's deal with how we're going to put it there afterwards.
<cjwatson> soren: I don't see what's wrong with gfxboot.cfg. text.cfg is only used for fallbacks when gfxboot doesn't work
<cjwatson> (that's a simplification, but close enough)
<soren> cjwatson: Okay. Well, it doesn't seem to work.
<cjwatson> that's a better place to start than randomly moving it around :)
<soren> cjwatson: The option isn't shown.
<soren> Heh, true.
<soren> I just went looking for where the options that actually /did/ show up were defined, and they're all in text.cfg.
<soren> So now I'm not sure at all :/
<cjwatson> does the thing you're seeing look like gfxboot? for example, does it have the menu bar across the bottom?
<soren> cjwatson: Yes.
<soren> cjwatson: Are you implying that if you start up a recent server ISO, you actually see the "install minimal system" option?
<cjwatson> rsyncing the image now to have a look
<cjwatson> I'm implying nothing right now
<soren> cjwatson: I rsynced only half an hour ago... I'll do it again.
<cjwatson> I don't see why that would help
<cjwatson> today's build won't have finished yet
<cjwatson> hmm, or maybe it has actually, sorry
<soren> Oh, you said "rsync/ing/ the image now to have a look"... I thought you told me to rsync it to have a look.
<soren> :)
<cjwatson> oh, right, sorry :)
<soren> Not your fault I can't read :)
<fabbione> Riddell: corosync is built everywhere. not sure you need to NEW binaries as well
<cjwatson> soren: oh, it's showing up in the F4 menu
<cjwatson> I guess that isn't ideal if you aren't finding it
<cjwatson> although conceptually it's the proper place
<soren> Oh!
<soren> Hm..
<soren> It's not quite what I expected, no.
<soren> cjwatson: Hm... Let me think about that for a bit.
<ogra-Q1> tsk
<ogra-Q1> empathy is really weird
<ogra-Q1> but then its probably not designed for IRC first place
<siretart> tjaalton: any chance we can enable the ext4dev module? I couldn't mount a usb-hardrive of a from a friend of mine because of lacking ext4dev module in the kernel
<ogra-Q1> siretart: in a linux-ubuntu-modules-gambling package :)
<tjaalton> siretart: you probably want to ask BenC?-)
<siretart> ok :)
<ogra> is the pam note in the channel topic stil relevant ?
<ogra> *still
<ogra> afaik we're at 1.0.1-3ubuntu4
<waistless> I know this isn't support, but is there anyway I can find a package which contains a bugfix I REALLY need?
<waistless> i.e this bug which has supposedly been fixed https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/44233
<ubottu> Launchpad bug 44233 in util-linux "mount udf dvd fails, possible wrong fstab entry" [Medium,Confirmed]
<ogra> waistless, well, its fixed .. the prob is that nobody seems to have opened a new bug for the second issue that showed up along debugging ever
<waistless> :( ok, any workaround?
<ogra> comma separated fstab options are definately parsed properly now (whic s what this bug is about)
<ogra> open a proper new bug that adresses the other issue as is stated several times in that bug, so triagers can assign it to the right package and the right people look at it
<ogra> bte, discussing bug handling is probably better done in #ubuntu-bugs :)
<ogra> *btw
<waistless> just asking, what is the other issue? (i've missed it)
<waistless> udf doesn't mount at all?
<evand> dholbach: sure
<dholbach> evand: NICE
<dholbach> evand: any slot on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep that you'd like to have?
<evand> dholbach: Fri 1800 UTC
<dholbach> evand: shall I add it to the schedule for you?
<evand> sure, thank you
<dholbach> evand: what title would you like?
<evand> Introduction to the Installer Team
<dholbach> nice :)
<dholbach> evand: thanks a bunch!
<evand> any time
<dholbach> done... once the wiki has saved the page :)
<ogra> Riddell, could i ask you to fix Bug #244531 for me (as you are archive admin of the day it seems), so dholbach stops poking me about bug #211710 :)
<ubottu> Launchpad bug 244531 in xaos "Please sync xaos 3.4-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/244531
<ubottu> Launchpad bug 211710 in xaos "Wrong characters codification in Xaos translation - broken UTF support" [Undecided,Confirmed] https://launchpad.net/bugs/211710
<Laney> (why is Xaos in main?)
<ogra> Laney, part of edubuntu
<Laney> ah
<ogra> or ubuntu-education ... or however we call it today :P
<mpt> Does anything that ships with Ubuntu by default use Tcl/Tk?
<Riddell> ogra: done
 * ogra hugs Riddell 
<mpt> (I mean, anything on the CD)
<ogra> mpt, i dont think so (else Tcl/Tk would be on the CD)
<mpt> ah, the age-old question
<mpt> Without actually burning a CD, how do I tell which packages are included on the CD?
<ogra> http://cdimage.ubuntu.com/daily/current/intrepid-alternate-i386.list
<cjwatson> .list or .manifest file alongside the image
<ogra> or http://cdimage.ubuntu.com/daily-live/current/intrepid-desktop-i386.manifest
<cjwatson> (.list is the ISO contents; .manifest is the live filesystem contents where appropriate)
<mpt> ah, thank you
 * mpt bookmarks
<ogra> note thats only for the current unstable CD .... for the released ones other links apply indeed
 * fabbione takes a lock on lvm2
<ogra> s/CD/CDs/
<cjwatson> anyone know what this means in Xorg.0.log? (EE) config/hal: couldn't initialise context: (null) ((null))
<cjwatson> breaking oem-config in VMs, I think
<sistpoty|work> cjwatson: hal wasn't started yet iirc
<cjwatson> mm, I was just coming round to that ...
<cjwatson> aha, I'm starting oem-config at 12
<sistpoty|work> kdm is sadly started too early as well :(
<ogra> *sigh* vbox modules out of date again
<dholbach> jdstrand: did you have a chance to talk to the fine folks of the MOTU Swat team about a "Making Ubuntu more secure" session? :)
<dholbach> (at Ubuntu Developer Week)
<jdstrand> dholbach: no, not yet
<fabbione> slangasek: ping?
<fabbione> Riddell: a new version of redhat-cluster is building now (only i386 is built already) that has a library soname bump. It will need some NEW love once it's all built and new lvm2 that build-deps on these new bits has been already uploaded.
<fabbione> Riddell: that will complete the soname transition :)
<fabbione> Riddell: thanks dude
<dholbach> jdstrand: it'd be great if you could pick a slot on https://wiki.ubuntu.com/UbuntuDeveloperWeek later :)
<dholbach> jdstrand, kees: thanks a lot! :)
<fabbione> dholbach: that bug is solved in the last upload.. just pending build/new propagation
<fabbione> dholbach: the one you mentioned this morning..
<dholbach> fabbione: yeah, I saw it on intrepid-changes - thanks a lot for that!
 * dholbach hugs fabbione
<fabbione> dholbach: no problem.. hopefully i will find the time to improve those scripts.. they really need some extra love
<fabbione> later
<dholbach> see you fabbione - have a nice day
<fabbione> dholbach: you too thanks but i'll be back later to check on this small transition :)
<fabbione> just need 5 more builds :)
<dholbach> alrighty
<dholbach> :)
<Adri2000> could any archive admin copy amsn srus (dapper, gutsy) to -updates please? it's bug #243722
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,Fix committed] https://launchpad.net/bugs/243722
<dholbach> slangasek: are you interested in running a session about "How to make an archive admin happy?" at Ubuntu Developer Week?
<StevenK> dholbach: Isn't that "File lots of removal requests" ? :-P
<Hobbsee> StevenK: s/archive admin/ release manager/ --> don't upload new stuff during a freeze!
<dholbach> StevenK: I guess there are so many way to make archive admins happy, including sending pizza, gift vouchers, etc - lots to cover in an one hour session
 * Hobbsee accepts pizza, gift vouchers, coke, and a few other bits :P
<ion_> But isnât cocaine illegal?
<StevenK> I suspect it's the liquid coke made by Coca-Cola Corp
<Hobbsee> not that coke :P
<mkrufky> its always nice when there's a large moment of silence after incriminating statements
<nxvl> good morning!
<Riddell> anyone know how to do jockey releases?  for lack of pitti
<zul> asac: ping
<asac> zul: ?
<zul> asac: do you handle network-manager-openvpn or is that similar to openvpn?
<asac> zul: huh? dont understand that question
<asac> zul: i posted the patch i will upload to the bug
<asac> it also passes --script-security 2
<zul> asac: gotcha thanks
 * dholbach hugs kees
<dholbach> my security friends :)
<fabbione> Riddell: still around?
 * kees hugs dholbach
<fabbione> hey kees
<kees> dholbach: I haven't had a chance to ask any of them yet.  I will bring it up with them.
 * dholbach hugs kees back :)
<kees> fabbione: hola!
<fabbione> i guess Riddell has gone for the day
<fabbione> hmmm just need somebody to new 4 libraries...
<fabbione> so i can get offline too
<kees> dholbach: jdstrand and I are on national holiday on the 1st, so how about 19.00 UTC on the 5th?
<dholbach> kees: sounds perfect to me!
<dholbach> kees: shall I put it on the wiki?
<kees> dholbach: "Introduction to the Ubuntu Security Team" should be good.
<dholbach> rock on!
<kees> dholbach: yeah, if you've got it open for edits
<Riddell> fabbione: hi
<dholbach> kees: added
<Riddell> fdoving: onto it
<fabbione> Riddell: hey... can i bother you one last time for today?
<Riddell> fabbione: onto it
<fabbione> Riddell: redhat-cluster -> NEW
<fabbione> Riddell: it's a bunch of soname changes.
<fabbione> Riddell: nothing fancy.
<dholbach> thanks a lot kees, thanks a lot jdstrand!
<fabbione> Riddell: they should hit the same pockets as now.. lvm2 depends on libcman2 and libdlm2 that will be removed. the new lvm2 is Depwait already in LP
<Riddell> fabbione: accepted
<fabbione> Riddell: so everything should clear automagically
<fabbione> Riddell: awesome.. thanks!
<fabbione> ok i am off again :)
<kees> dholbach: any time.  :)
<slangasek> fabbione: pong?
<slangasek> dholbach: I guess I could; can you tell me what makes an archive admin happy? :-)
<dholbach> slangasek: making sure stuff builds, having checked licensing thoroughly, adhering to freeze dates, etc :)
<slangasek> ScottK: is the kde from last night processed, then?  I don't see it in the queue
<dholbach> slangasek: I thought there was a lot of stuff that made archive admins unhappy :)
<Riddell> slangasek: yes
<dholbach> BenC: you ROCK!
<slangasek> dholbach: ok, so "how to avoid making the archive admins unhappy", that's easier perhaps :)
<dholbach> :-)))
<dholbach> there's only one slot left right now: https://wiki.ubuntu.com/UbuntuDeveloperWeek - would that work out for you?
<slangasek> dholbach: ah, Monday is a US holiday
<tseliot> dholbach: did you have the time to upload this? https://bugs.launchpad.net/ubuntu/+source/envyng-core/+bug/260862
<ubottu> Launchpad bug 260862 in envyng-core "Update EnvyNG in Intrepid" [Undecided,New]
<slangasek> dholbach: and I already have (wholly unexciting) plans for that day
<dholbach> slangasek: argl :-(
<dholbach> tseliot: no, I'm sorry - I subscribed bryce to the bug instead
<tseliot> dholbach: ok, no problem ;)
<dholbach> slangasek: would the same slot on thursday work for you? pedro_: do you think you could swap with the Monday 20 UTC one?
<slangasek> thursday is doable for me
<pedro_> dholbach: yup no problem
<mdz> cjwatson: were there any issues with the server seed bits which are now landed?
<slangasek> dholbach: is there a template of some sort that describes what kind of content I should be trying to put together?
<dholbach> slangasek, pedro_: thanks so much - going to update the wiki
<dholbach> slangasek: we have logs of the previous sessions if that helps: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Previous
<cjwatson> mdz: soren reported that the menu item for minimal-system is hard to find (it's on F4 at the moment; we may move it); otherwise I haven't heard of any issues yet
<dholbach> slangasek: a big part of the sessions will be Q&A
<mdz> cjwatson: is it present in the current daily  builds?
<cjwatson> mdz: yes
<cjwatson> I haven't tested it end-to-end since it landed, trying to get oem sorted out first ...
<slangasek> dholbach: ok.  I think I can piece something together then, thanks
<dholbach> slangasek: you ROCK!
 * cjwatson lights up the Keybuksignal hopefully
<mdz> cjwatson: thanks
<nealmcb> mdz: re posting to ubuntu-devel you say "there's a ticket open with the Canonical IS team about it (#26726)"  That doesn't seem to be a relevant launchpad or rt ticket - typo?  And does it work to post from an ubuntu.com address as suggested by https://rt.ubuntu.com/Ticket/Display.html?id=655
<cjwatson> it's in the Canonical RT rather than the Ubuntu one
<mdz> nealmcb: that's a different RT instance (where I don't seem to even have an account)
<cjwatson> (I only just found out they were separate)
<cjwatson> the Ubuntu one is new, I believe
<nealmcb> oh dear....
<fabbione> slangasek: all sorted.. thanks
<elmo> mdz: 'ubuntu' / 'ubuntu'
<mdz> cjwatson: there's still a Community queue on the old one...
<nealmcb> I'm not subscribed with my ubuntu.com address, but allowing posts from @ubuntu.com would seem like a good idea
<mdz> elmo: will this obsolete the old Community queue?
<elmo> yes, it already has
<cjwatson> mdz: saying "{Obsolete}" on it ...
<nealmcb> where is the old one?  what is the community queue?
<elmo> mdz: in 26726, did you try adding him to 'accept_these_nonmembers'?
<elmo> mdz: i.e. https://lists.ubuntu.com/mailman/admin/ubuntu-devel/?VARHELP=privacy/sender/accept_these_nonmembers
<elmo> nealmcb: the "old one", is the Canonical private RT
<cjwatson> yes, that's the key I use I think
<nxvl> did libcupsys2-dev has been superseded?
<mdz> elmo: by the way, when I click on the queues on the home page, I get an empty list of tickets (used to display all non-closed tickets).  an explicit search works, though
<nealmcb> elmo: I though you were saying ubuntu/ubuntu worked on the old one - maybe I misparsed mdz's "that"
<mdz> elmo: most of the moderators are not list admins, so they can't change that
<mdz> nealmcb: that (rt.ubuntu.com) is a different RT instance from the one I was referring to in my email
<mdz> cjwatson: could you add the person referenced in the thread to that filter to address the immediate issue?
<cjwatson> mdz: your last comment references one of your own posts
<elmo> mdz: so you want moderators to be able to add people?  does it need to be within the mailman system?
<geser> nxvl: yes, it was replaced with libcups2-dev and libcupsys2-dev is now a transitional package
<nealmcb> cjwatson:   while you're at it, whitelisting me (neal@bcn.boulder.co.us == https://edge.launchpad.net/~nealmcb) would be delightful :)
<nxvl> geser: thank you
<mdz> cjwatson: yes, because he CCed me and his message wasn't in the archive yet
<cjwatson> mdz: done for the one before that
<mdz> elmo: it would be ideal if it were via the mailman system, but I think it would be workable to have something else
<cjwatson> mdz: in the UI, it's Privacy options... -> Sender filters -> accept_these_nonmembers
<elmo> mdz: well, I just don't fancy hacking on mailman is all - unless I'm missing some easy alternative?
<mdz> cjwatson: I'm not at all convinced that I have the right admin password
<mdz> elmo: moderators need to be able to whitelist people.  what are the risks of making them admins?
<mdz> that sounds like the easiest route
<mdz> cjwatson: thanks
<elmo> mdz: assuming you trust the moderators to not be malicious or grossly incompetent, not much?
<mdz> elmo: one thing we discussed before was having a LP team whose members were whitelisted, that's another option
<elmo> mdz: sure, that's easy on my side too - I thought the concern there was asking upstreams/other distro folks to create LP accounts
<mdz> elmo: hmm, you're right, that's not ideal
<moquist> james_w: thx for your REVU comments; I'm catching up after a trip so I'm not sure how soon I'll get back to all that.
<james_w> moquist: no problem, sorry to leave it so late
<james_w> I didn't realise you were here, I only looked on -motu
<moquist> np
<RainCT> mdz: Hey. We've created Launchpad team ~ubuntu-dev-without-bugmail so that it can be added to other teams instead of ubuntu-dev, so that it eats the bugmail (by having a contact address set). Can you please accept the invitation of ubuntu-dev to join it?
<RainCT> mdz: this is necessary, for example, so that MOTUs can commit to the mythbuntu branches (where some packages are maintained)
<mdz> RainCT: done
<RainCT> mdz: thanks!
<mdz> elmo: if your recommended solution is to use the admin interface and accept_these_nonmembers, please put that into the ticket and close it out
<slangasek> sbeattie: on bug #91873, you don't think there's any chance that this patch could cause us to ignore a /legitimate/ EIO?
<ubottu> Launchpad bug 91873 in eject "eject -T doesn't close the tray" [Low,Fix committed] https://launchpad.net/bugs/91873
<sbeattie> slangasek: it's possible but I think eject already is ignoring legitimate EIO errors, as on multiple systems here, ioctl(3, CDROMEJECT, 0) returns -EIO every time on successful eject events.
<slangasek> sbeattie: isn't CDROMEJECT the exact case that this patch addresses?
<sbeattie> yes.
<slangasek> then it would seem that eject wasn't ignoring those before
<sbeattie> eject -T wasn't. eject with no arguments does.
<slangasek> ah, ok, I see that in the other strace snippet
<sbeattie> personally, I think both eject and the kernel are buggy here, but that eject's buggy behavior may be due to working around the kernel always returning EIO.
 * slangasek nods
<slangasek> kees: hmm, I thought samba also did PIE natively?
<slangasek> ah, only if built with --enable-pie
<slangasek> er, no
<slangasek> it's not built with PIE because we're setting --disable-pie
<kees> hahah
<kees> oops
<kees> I missed that.
<slangasek> well, it was breaking things on the ports when upstream first turned it on
<slangasek> so it got disabled, and never revisited
<kees> slangasek: right, I suspect they're not correctly testing for it.
<kees> slangasek: hardening-wrapper DTRT wrt to archs
<kees> nice, and they've already enabled relro.
<kees> slangasek: what do you think, should I revert the wrapper dep and go with the "native" PIE option?  it looks like they pass it down into the build correctly.
<slangasek> kees: that would seem to simply things, yes?
<kees> yup, let me do a rebuild, one sec
<cjwatson> mdz: server seed isn't working right, unfortunately - I'll sort it out
<mdz> dendrobates: ^^
<mdz> cjwatson: thanks
<dendrobates> mdz: ack
<cjwatson> (it's getting offered, but not preselected)
<nxvl> how is the Freezes thing? i can upload new features until tomorrow or until Thursday?
 * Laney eyes mysql
<slangasek> nxvl: through end of day on Thursday
<mathiaz> slangasek: https://wiki.ubuntu.com/IntrepidReleaseSchedule -> Freezes normally happen at the start of the given date, UTC time. So last minute changes need to happen the day before.
<mathiaz> slangasek: ^^ - has this changed ?
<slangasek> mathiaz: oh; well, that's not what I did with FeatureFreeze last time, but we can go with what's printed there instead
<slangasek> nxvl: in that case, through end of day on Wednesday ;)
<superm1> slangasek, would you be able to include the nvidia drivers as installable on the DVD image?
<jdstrand> slangasek: eek, I much preferred your first reaction. Perhaps is would be better to update the wiki?
<jdstrand> (it certainly would be for me)
<slangasek> superm1: "include the nvidia drivers as installable" - as opposed to what, exactly?  aren't they already there, via restricted?
<superm1> slangasek, i dont believe they're on the DVD images as of yet for intrepid
<jdstrand> slangasek: I'm half kidding, but the time would be most welcome
<superm1> slangasek, but yes as installable without needing intarweb access
<slangasek> jdstrand: giving people more time before the freeze always makes it "better" in that it lets everyone get more done, but then it takes time away from the freeze, so a line always has to be drawn somewhere...
<superm1> slangasek, i don't believe they're explicitly listed in the seeds atm
<jdstrand> slangasek: sure-- my point is I liked where you drew your line before :)
<slangasek> jdstrand: what are you working on that you're worried is going to miss the freeze?
<nxvl> slangasek: heh, no, please make it happend at the end of Thursday :P
<slangasek> superm1: ok; which package should be seeded for this?
<jdstrand> slangasek: an audit for landscape
<superm1> slangasek, nvidia-glx-177, nvidia-glx-173, nvidia-glx-96, nvidia-glx-71
<superm1> slangasek, that should get the 4 different variants
<jdstrand> slangasek: kees and I are racing against the clock, and TBH, I thought it was end of day thursday myself
<slangasek> jdstrand: ah.  landscape itself isn't uploaded until the audit is done?
<jdstrand> slangasek: technically, no
<nxvl> slangasek: or you can still say it's taking place at the end of Wen so people prepare for it, but make it happen the end of thu
<nxvl> slangasek: and we won't say anything
<nxvl> :P
<slangasek> jdstrand: well, "freeze exception granted" then :P
<jdstrand> slangasek: works for me :)
<slangasek> nxvl: well, the "freeze at beginning of the day" is noted on the release schedule wiki page, and the freeze isn't an archive-level freeze so the timeline is always fuzzy; I don't see the justification for pushing back the freeze as a whole
<nxvl> slangasek: yeah, i'm just kidding
<nxvl> slangasek: you can't blame me for trying
<nxvl> :D
<slangasek> james_w: ping-a-ling
<james_w> hey slangasek
<slangasek> james_w: hi, looking over bug #261445, which dholbach pointed me at
<ubottu> Launchpad bug 261445 in devscripts "debcommit should use --fixes argument to bzr commit when appropriate" [Undecided,New] https://launchpad.net/bugs/261445
<james_w> slangasek: great, thanks
<slangasek> james_w: I'm trying to think through what may or may not be a relevant corner case
<slangasek> I've never used --fixes before, but I love it immediately; what I'm wondering is whether this patch to debcommit could do the wrong thing if the changelog entry is added in a separate commit after the actual change
<slangasek> but then I guess one probably wouldn't use debcommit in that case...
<james_w> slangasek: you mean that you commit the fix, and then commit the changelog entry with debcommit, which leads to --fixes putting the property on the wrong commit?
<slangasek> james_w: basically, yeah
<james_w> yeah, that would be not great
<slangasek> but as I thought about it, I realized I probably wouldn't use debcommit there
<slangasek> but wanted to get your opinion anyway :)
<james_w> --fixes isn't precise, as bug fixes can span multiple commits etc.
<slangasek> sure
<slangasek> so I'm nitpicking for no reason :-)
<james_w> you could say that the bug is fixed by the point where it is added, so it's ok, but you /could/ commit the changelog first, so that falls down
<james_w> it's not precise, but I think it's better than nothing, and I don't think a heuristic can do any better, and heuristics is all we have with debcommit
<slangasek> right; I was more wondering whether there was any reason one would want to have an override switch
<james_w> possibly
<slangasek> well - I haven't found a convincing case for it myself
<slangasek> so I'm going to go ahead and sponsor as-is :)
<james_w> adding a bug number to a changelog entry from long ago, but you shouldn't do that
<james_w> great, thanks.
<Riddell> BenC: linux has been split into lots of -modules packages?
<slangasek> Riddell: are you looking at the d-i packages?
<slangasek> (udebs)
<Riddell> slangasek: oh possibly, firewire-core-modules-2.6.27-1-generic-di et al in New
<BenC> Riddell: udeb's are for the debian-installer...has nothing to do with what's installed on your system
<Riddell> yeah, the di should have given it away
<BenC> So should the .udeb extension :)
<BenC> Wait, it doesn't show that does it
<slangasek> Riddell: we have a script kernel-overrides on drescher that facilitates mapping overrides from one kernel to the next; or if you prefer, I'm happy to process those, I just had noticed you were actively processing and didn't want to get in your way :)
<slangasek> BenC: queue doesn't show the extension, no :)
<nxvl> i need some help here
<nxvl> on actually deciding what to do
<nxvl> Bug 260899
<ubottu> Launchpad bug 260899 in courier "some courier executables can't load libraries in /usr/lib/courier-authlib " [High,Confirmed] https://launchpad.net/bugs/260899
<nxvl> the problem is issue because of courier-authlib libs being rpathed
<nxvl> issued*
<nxvl> so, the solution i find is: a) still having it with the rpath to the libs
<nxvl> b) move courier-authlib libraries to /usr/lib insted of /usr/lib/courier-authlib
<nxvl> NCommander: what do you think?
<NCommander> well, courier-authlib ATM is internal to courier
<NCommander> But its packaged in a way that anyone in theory could link against it
<nxvl> but different package and source
<NCommander> argh
<NCommander> I thought authlib was built through courier
<nxvl> is not even the same source package
<nxvl> nop
<NCommander> whoops
<nxvl> nop
<NCommander> In that case, we need to dump the things in /usr/lib
<nxvl> source package is called courier-authlib
<NCommander> Thats the proper fix
<NCommander> as well as properly rename the library to follow the debian policy on libraries
<NCommander> (should be libcourier-authlib, not courier-authlib)
<nxvl> that would break SO many thing
<nxvl> things*
<NCommander> There are only four or five packages depending on courier-authlib
<NCommander> Most from courier itself
<NCommander> (check the rdepends yourself)
<nxvl> NCommander: i think that's is a change that is better to be done in debian
<NCommander> Upstream is non-cooperative
<nxvl> really?
<NCommander> Yeah
<nxvl> that's why i spend more time here than in debian
<nxvl> :D
<baastrup> hey is is posible to force a broken package to be oki?
<NCommander> ScottK tried in the past to get fixes upstream
<NCommander> Including the libtool fixes
<NCommander> so the fix needs to be made here
<nxvl> zul: something to add before i make the changes?
<slangasek> james_w: oh, the patch pulls in Dpkg::Changelog, which wasn't previously used anywhere; do we need a depends/recommends on libparse-debianchangelog-perl?
<slangasek> or is that not the same module?
<nxvl> cjwatson: around?
<slangasek> james_w: ah, no, Dpkg::Changelog is in dpkg-dev, already a dependency, so nevermind
<cjwatson> nxvl: yes
<nxvl> cjwatson: can you please read the recent backlog about the courier-authlib issue i have just pointed
<nxvl> cjwatson: and give me your thoughts on the topic
<nxvl> cjwatson: it's a small log
<cjwatson> nxvl: my gut feel is that courier-authlib is essentially private to courier, despite being a separate package (presumably due to being distributed as a separate source package upstream). The courier-authlib-dev package is just so that other bits of courier can be built against it. This theory is supported by the package descriptions for courier-authlib and courier-authlib-dev
<cjwatson> nxvl: so my recommendation would be to put the rpath back rather than making it a public library
<nxvl> cjwatson: ok
<nxvl> cjwatson: thank you for your time
<nxvl> :D
<cjwatson> hth :)
<cjwatson> I'll stick that comment in the bug
<nxvl> thank you!
<nxvl> i will sponsor Javer's diff
<cjwatson> the recommendation to avoid rpath is aimed at public libraries; generally speaking it's worse to make private libraries public when they weren't intended to be than to drop in an rpath
<cjwatson> the consequence of the former approach is that you get a library in /usr/lib whose upstream isn't interested in managing its soname properly or in advertising its API properly, or things like that
<cjwatson> we should of course be careful that dependencies are tight enough to avoid two versions of authlib ending up in the same process space if its soname ever changes
<james_w> is anyone willing to sponsor a merge/update of devmapper and lvm2?
<james_w> who would be best to ask for that?
<slangasek> james_w: "ubuntu-main-sponsors"? :)
<james_w> slangasek: if only :-)
<slangasek> james_w: devscripts uploaded, after a bit of puzzling over why dpkg-buildpackage -b && dpkg-buildpackage -S caused desktop2menu.pl to disappear from the source package
<slangasek> james_w: have you forwarded this patch to the Debian bug, or will you?
<james_w> slangasek: done prior to filing the Ubuntu bug
<slangasek> james_w: ok, great :)
<james_w> thanks for sponsoring
<cjwatson> _MMA_: so remind me what the situation with ubuntustudio tasks was? I seem to remember that there was some particular task you wanted preselected, while still displaying the tasks question
<cjwatson> (background: it's now actually possible to do that in tasksel, at least once I upload this fix)
<_MMA_> Well we have 5 tasks. The -desktop was the one we were trying to get preselected and hidden from users.
<cjwatson> preselected *and* hidden? hmm
<_MMA_> So in the end users would only *see* 4.
<cjwatson> ok, slightly different kettle of fish then
<cjwatson> can't really do that with a debconf multiselect
<_MMA_> Well, in the end, preselected is a great step in the right direction.
<cjwatson> do you want the CDs changed to preselect that, then?
<_MMA_> The -desktop task, sure. That would be great. (If you're pokin' around in there)
<james_w> slangasek: "Can't read from ../scripts/desktop2menu.pl: No such file or directory"
<james_w> slangasek: I assume that was what you saw?
<james_w> it only happened for me with --twice, so I assumed it would survive the buildds
<soren> cjwatson: Have you heard of issues like this before: https://bugs.edge.launchpad.net/ubuntu/+source/udev/+bug/248096
<ubottu> Launchpad bug 248096 in udev "If having lvm with name "kvm", /dev/kvm can't be used by kvm" [Undecided,New]
<soren> cjwatson: (people naming their volume groups in such a way that device nodes go missing)
<doggymenz> why ubuntu use usplash instead of bootsplash?
<doggymenz> bootsplash already existed, it had many feature and was stable
<doggymenz> why ubuntu had todo usplash instead? its not good
<RainCT> doggymenz: because bootsplash works in the kernel level, and usplash in userspace (or at least that's what Wikipedia says)
<doggymenz> oh okie
<doggymenz> im not sure usplash is stable
<wgrant> How do you define "stable"?
<doggymenz> i add vga=795 or something, to kernel parameter, then i loose my terminals, and usplash can look strange, like get 2 progressbars
<doggymenz> and it lacks functionality, you cant press escape to see boot messages
<RAOF> Because intrepid's uvesafb is currently broken, yes.
<doggymenz> oh
<doggymenz> when its fixed?
<RAOF> When it gets fixed.  I don't know.
<RainCT> doggymenz: I think you can see the messages pressing Ctrl+Alt+F1
<doggymenz> oh
<doggymenz> intrepid will have 2.6.27?
<wgrant> Does.
<doggymenz> awesome
<doggymenz> mine only has 2.6.26
<wgrant> Some of the binaries are in NEW>
<doggymenz> i dont know what is NEW<
<wgrant> It's the queue where new packages sit.
<doggymenz> oh
<slangasek> james_w: er, heh; I didn't try rebuilding again after the first build test
<NCommander> cjwatson, out of curosity, is there a reason there are no Xubuntu Ports CD images made?
<slangasek> james_w: let me fix up the references to desktop2menu.pl, then
<james_w> slangasek: it failed on the buildds
<slangasek> james_w: yep, it fails here too if I try another rebuild
<NCommander> RAOF, confirming a binary rebuild fixes miro
<slangasek> I'll have it fixed up soon enough
<cjwatson> NCommander: http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ is the place to look
<james_w> slangasek: it appears as though "remove desktop2menu.pl in Ubuntu" translates to "remove it in the clean rule and hope for the best"
<slangasek> james_w: in the build rule, oddly
<james_w> though that may be a bit unfair
<slangasek> s/build/install/
<NCommander> cjwatson, it appears the PowerPC CDs aren't even attempted
<RAOF> NCommander: Thanks.  I suppose I get to prepare a SRU.
<james_w> slangasek: oh yeah
<james_w> slangasek: surely it should just delete the installed copy?
<slangasek> james_w: that would have made more sense, yes :)
<NCommander> (I looked at at the the debian-cd source, and I couldn't figure out how the distribution/ports of distribution thing works out)
<Zetto> Someone please take a look at Bug 144745
<ubottu> Launchpad bug 144745 in udev "Webcam detected, but not working - Bad module" [Undecided,Invalid] https://launchpad.net/bugs/144745
<NCommander> RAOF, I can do the SRU if you want
<james_w> slangasek: sorry for not fixing it up when I saw it
<RAOF> NCommander: That'd be cool.  Thanks.
<qwerty6523> hello
<NCommander> RAOF, if I give you a debdiff, will you upload to Hardy proposed?
<RAOF> NCommander: I need to check the SRU documentation first :)
<Zetto> bug 144745 - Two modules aren't loaded in the right order
<ubottu> Launchpad bug 144745 in udev "Webcam detected, but not working - Bad module" [Undecided,Invalid] https://launchpad.net/bugs/144745
<slangasek> james_w: ah, leaving desktop2menu.pl in place causes build failures because of some wildcard rules in scripts/Makefile; I'll just yank the whole thing out
<NCommander> Well, you upload the proposed fix (in this case, just a changelog entry), file the bug, and then subscribe Main SRU
<cjwatson> NCommander: they are, but there's a nasty little problem with the way the local mirror on the build machine is laid out
<RAOF> Yeah, that was my understanding.
<cjwatson> soren: I hadn't heard of issues like that before. I suppose we could blacklist certain VG names in partman-lvm
<RAOF> NCommander: Oh, seems like asac's been assigned to that bug.
<NCommander> I'll add my two cents
<RAOF> And the debdiff; why not :)
<asac> RAOF: is this about the gnome-python breakage?
<RAOF> Since gnome-python-extras is in main I can't upload for you anyway :)
<RAOF> Yeah.
<RAOF> Just checking that a rebuild fixes it, and it does.
<asac> RAOF: how do you reproduce that in hardy?
<asac> RAOF: is that just PPC?
<RAOF> asac: By asking NCommander to fire up his PPC box, and try to start miro
<asac> NCommander: did it actually ever work?
<NCommander> Yeah
<NCommander> Took forever to build
<asac> when?
<RAOF> Yeah, just PPC as far as I can tell.
<NCommander> Just now
<asac> NCommander: no
<NCommander> Like 20 minutes ago
<asac> NCommander: i mean: did miro ever work in hardy?
<NCommander> I never used it before
<NCommander> What I did was
<NCommander> Install miro
<asac> this bug appears to predate hardy release ... thats why i am wondering if this is a regression or just slipped through release QAY
<NCommander> Confirmed it didn't work
<asac> NCommander: ok
<NCommander> I can check dapper if miro existed back then
<asac> NCommander: can you downgrade to the hardy xulrunner-1.9 version?
<asac> NCommander: i think its 1.9~b5 something
<NCommander> Link me to the deb
<soren> cjwatson: Ok. I still want to get Keybuk's input, though. Maybe there's clever udev magic that work around it somehow.
<asac> NCommander: sudo apt-get install xulrunner-1.9=1.9~b5+nobinonly-0ubuntu3 xulrunner-1.9-gnome-support=1.9~b5+nobinonly-0ubuntu3
<asac> NCommander: maybe you need to downgrade some other apps in the same move
<NCommander> Bah
<asac> or remove them (to test)
<NCommander> I think I need to remove GNOME to test this
<NCommander> asac downgrading
<Zetto> Hi all, bug 144745 can easily be solved incluing a mudule in '/etc/modprobe.d/blacklist'
<ubottu> Launchpad bug 144745 in udev "Webcam detected, but not working - Bad module" [Undecided,Invalid] https://launchpad.net/bugs/144745
<asac> NCommander: ok. so its not a regression. thanks for testing. I am subscribed to it, so Ill get to it asap
<NCommander> I posted the changelog entry
<NCommander> (you can take credit for it if you want)
<asac> he?
<asac> ah
<NCommander> asac, its a no-changes binary rebuild
<asac> ok
<NCommander> You shouldn't have any issues getting that approved
<NCommander> asac, I'm willing to take over dealing with the SRU bit, unless you want it
<asac> NCommander: can you upload?
<NCommander> asac, not an MOTU
<NCommander> sadly
<NCommander> I can post the source package to my PPA
<NCommander> Then you just need to grab it and resign (I'll set the changelog to hardy-proposed)
<asac> ok. ill do that then. you can then take care for organising testing/feedback in bug and getting verification
<asac> NCommander: if its just a respin, then you dont need to
<NCommander> Sure, no problem
<NCommander> SHould I reassign to myself?
<weed37> evening
<sbeattie> NCommander: if you've got a ppc box available and some free time, it'd be great if you could verify the SRU fix for 220890
 * NCommander takes a look
<NCommander> Launchpad #220890
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,Fix committed] https://launchpad.net/bugs/220890
<NCommander> lazyness rocks
<NCommander> sbeattie, what's the GNOME metapackage? (I did a -server install, since I was using it as a server, but this box has been retired so ...)
<RainCT> NCommander: ubuntu-desktop?
<NCommander> I should have known that
<NCommander> sbeattie, ok, checking. As an aside, what's the issue with this and PPAs slangasek referred to
<james_w> dear archive admins, will there be a sync run prior to feature freeze?
<RainCT> james_w: sorry for the wait. I've just advocated wadllib, and will test-build launchpadlib now
<james_w> RainCT: thanks, don't worry about the wait
<james_w> as long as it's less than 24 hours :-)
<sbeattie> NCommander: I think PPAs don't support building for ppc anymore, so test python-apt packages couldn't be built and sitributed for ppc via that channel.
<sbeattie> s/sitributed/distributed/
<NCommander> A pity that was dropped
<RAOF> PPAs never supported building for PPC, at least that I can remember.  The xen infrastructure the PPA builders use only works on x86, IIRC.
<NCommander> I wish they'd just extend PowerPC/SPARC PPAs. They could use QEMU ;-)
<elmo> NCommander: no, we couldn't.  qemu doesn' tprovide secure sandboxing
<elmo> it also has serious limitations as a buildd (e.g. a 256Mb memory limit)
<elmo> raof's right, we've never supported anything other than x8 based architectures because that's all that Xen supports
<NCommander> elmo, QEMU supports up to 1024, I ran a hurd buildd in it
<elmo> hmm? ok, maybe that's only on arm then
<ion_> Why an arbitrary memory limit?
<NCommander> elmo, I take it a process barrier isn't strong enough protection?
<RAOF> Couldn't you run qemu in a xen sandbox? :)
<NCommander> (it won't be impossible for someone to break into a Xen buildd if a dom0 expilot in the hypervisor was ever found)
 * NCommander has a powerpc buildd running against his PPA :-))
<elmo> NCommander: PPA builds allow you to intall your own packages, so, no it's not
<NCommander> If I understand PPAs correctly, the xen based environment works with a snapshot, and after each build, resets it, right?
<NCommander> (and Xen PowerPC does exist now)
<elmo> Xen 'exists' for a number of different platforms
<elmo> it's only usable in production for x86
<elmo> NCommander: yes
<cjwatson> james_w: you mean like an autosync? those stopped at debian import freeze
<NCommander> I guess I'm slow then on why QEMU won't be acceptable (even if you put it in a Xen image),
<NCommander> Since QEMU can be snapshotted
<NCommander> (is that even a word ;-)
<NCommander> sbeattie, my PPC box is installing GNOME< but it might take awhile. its not that fast
<james_w> cjwatson: no, running over all of the outstanding sync requests.
<elmo> NCommander: because as I said, qemu does not provide secure sandboxing
<cjwatson> oh, right. I should think so but probably won't be the guy in the chair myself ...
<elmo> NCommander: upstream are on record are saying security is not and never has been one of their concerns
<NCommander> elmo, I just said put qemu in an Xen domU. I dunno, doesn't that solve that issue?
<sbeattie> NCommander: no worries, your help is appreciated!
<elmo> oh, I see what you mean
<NCommander> yeah
<james_w> cjwatson: ok, thanks. I'm assuming there will be, but if it was a no then I would have to change my approach.
<NCommander> Even if qemu gets hacked, the xen image provides an affective barrier
<NCommander> And then its a modification to the build-worker to make sure the xen image gets reset after each build
<elmo> NCommander: *shrug* that'd be viable, but slow.  qemu on the fastes x86 is still slower than e.g. modern arm hardware
<NCommander> well, userland emulation pretty fast, my laptop can slaughter my 1Ghz PowerpC
<cjwatson> james_w: prior practice has been that there is, at any rate
<james_w> thanks, good to know
<NCommander> elmo, then again, I'm an m68k Debian porter, so my concept of slow and yours are in two very different worlds
<Darklock> haha
 * cjwatson seems to recall that elmo is not entirely without m68k experience
<NCommander> Sometimes I dream at night of bootstrapping Ubuntu m68k
<NCommander> THen I wonder why I have no social life
<NCommander> hell, I've bootstrapped armel Ubuntu
<NCommander> (mostly, I finished building about half of the base packages once I canadianed crossed the compiler)
<jdstrand> NCommander, elmo: I think the situation is improving wrt to qemu and security do to other developers, and I seem to remember the kvm folks at least saying they are interested
<jdstrand> s/do/due/
<NCommander> jdstrand, well, couldn't we just plop Qemu in Xen
<NCommander> It can't be any less secure then the current PPA setup
<slangasek> cjwatson: the difference being that elmo wised up several years ago? ;)
<NCommander> slangasek, without m68k, I'd never gotten a chance to run a dak setup or britney
<jdstrand> NCommander: I didn't say it *was* secure yet, just improving. besides, I thought xen had a ton of qemu code anyway
<NCommander> Now if thats a good or bad thing, thats anyones guess ;-)
<NCommander> slangasek, I dunno, we've proven its possible to run java and KDE on m68k
<NCommander> Our buildd cluster is close to the speed of a quad-core x86 :-)
<cjwatson> StevenK: what's antimony:/srv/cdimage.ubuntu.com/moblin.copy/ and can it die?
<cjwatson> NCommander: a fine demonstration of the difference between bandwidth and latency :-)
<slangasek> NCommander: I've called for phasing out the Debian alpha port because I think we're beyond the point of diminishing returns wrt to keeping it afloat; I'm probably not the person to try to impress with tales of running KDE on m68k
<NCommander> slangasek, we only build it because we have it, no one in their right mind uses it
<cjwatson> I suppose the difference is that an m68k requires fewer electrical substations to keep it running
<NCommander> (although as a joke, I think someone tried to run it, it took roughly an hour to get to the desktop)
<NCommander> That, and coldfire will be coming out soon, we're waiting on freescale to help with the toolchain
<cjwatson> is this like Duke Nukem Forever?
<NCommander> m68k - proving that glibc 2.5 just can't die yet
<NCommander> slangasek, w.r.t. to Alpha, I feel if we simply axe the requirement that all packages must be built, it would be quite feasible to keep
<NCommander> As it stands, now that the FTP masters are offically axing ports
<NCommander> m68k and hurd just got axed
<slangasek> cjwatson: my Alpha runs on a single ATX power supply, thanks :)
<NCommander> I expect mips(el) and hppa might end up going too, they've beening having a lot of buildd issues recently
 * NCommander wishes he had an alpha
<NCommander> slangasek, know where one can get one relatively cheaply?
<slangasek> cjwatson: but it's still dissipates more heat than any other machine in the house, and I use it for nothing - I want it off
<slangasek> NCommander: Germany, apparently
<slangasek> otherwise, eBay
<NCommander> slangasek, what are you using it for?
<slangasek> building d-i daily images
<slangasek> and porting work when needed
<slangasek> so it's entirely for others' benefit, not for my own
<NCommander> You could just replace it with a qemu instance ;-)
<slangasek> I'll sit here and wait while you get qemu working for alpha, shall I
<NCommander> hrm
<NCommander> It's still dev-only
<NCommander> n/m ;-)
<NCommander> slangasek, you have the only dev machine for alpha thats open for DDs?
<slangasek> no, my alpha isn't open for DDs.
<NCommander> slangasek, it sounds like the alpha port though in general having issues, which kinda suprises me, hppa's been dead from HP for longer than alpha, and its still kicking
#ubuntu-devel 2008-08-27
<slangasek> no, hppa just doesn't have someone willing to give it a dignified end
<slangasek> it's been in worse shape than alpha for longer
<NCommander> Using linuxthreads on glibc 2.7 :-P
<NCommander> (which is what the m68k plan is if our compiler ever gets to the state that it has __thread)
 * NCommander kicks ubuntu-cd alive
<superm1> slangasek, so as to make sure that those changes to the seeds don't forget forgotten prior to alpha5, is there a particular place you'd like to see seed bugs filed at?
<slangasek> superm1: hum, there ought to be a place, but I don't know what it is
<slangasek> cjwatson: superm1 pointed out that nvidia drivers aren't included on the DVD currently; is there any reason you know of that they shouldn't be?
<cjwatson> slangasek: not that I know of; maybe seed tweaks needed after they got split out from linux-restricted-modules
<cjwatson> superm1: historically we've stuck seed bugs on ubuntu-meta
<SJobs> is there someone who is great with kernel so they can check it out and reverse engineer how the hyper-visor(ps3) communicates with it and see if you can find exploits ?
<NCommander> sbeattie, ok, GNOME is installed, and dinner was eaten, testing now
<superm1> cjwatson, okay thanks.  i've filed a bug  there
<calc> is it normal for lintian on ubuntu to not know about Maintainer field differing from Changelog?
<calc> i notice it is warning a lot about that while repackaging OOo
<NCommander> sbeattie, confirming original bug works as expected
<calc> ah maybe its because i versioned the package incorrectly, heh
 * calc adds ubuntu1 to the package name
<NCommander> calc, why are you repackaging OOo?
<calc> NCommander: split source packages
<NCommander> ah
<wgrant> So it won't take a decade to build?
<calc> yep ubuntu1 fixed it
<NCommander> YAY
<NCommander> It took three weeks to build on m68k
<calc> wgrant: it will still take a decade to build but there will be like 20 source packages instead
<NCommander> I think we FINALLY added that beast to NFU
<wgrant> calc: But it will no longer be like KDE where a typo fix in some documentation makes me download 60MB of icons again?
<calc> wgrant: probably not, at least that is the hope :)
 * NCommander hugs calc
<calc> of course OOo is still in early stages of being split so this may not make it for intrepid, not sure yet
<calc> its being split in go-oo not upstream, at least not yet
<NCommander> BenC, ping
<NCommander> calc, if you need a beta tester, I'll help
<calc> NCommander: when i get it far enough along to be usable for testing i'll post on the relevant lists/forums
 * calc is still working on getting the first source to build properly
<NCommander> calc, PPAs are your friends
<NCommander> If you run into FTBFS issues, hit me up
<NCommander> I'm fairly good at resolving them
<calc> NCommander: yep i have 3.0b2 in there now
<calc> the main issue is that i am converting a 3600 line rules file and getting it to build at the same time :)
<NCommander> Ow
<calc> NCommander: oh btw i used to maintain kde for debian (long ago)
<NCommander> 3600 LINE?!
<calc> well 3599 lines actually :)
<NCommander> *blinks*
<NCommander> For the love of god ...
<NCommander> I've built OOo from source
<calc> so far the new rules is only 409 lines
<NCommander> How the heck can that beast be 3600?
 * NCommander discovers the Ubuntu-smokers group .
<calc> NCommander: OOo is very complicated :)
<NCommander> I realize that
<NCommander> But 3600?
<NCommander> Christ, there are packages in Debin that are smaller that including all the source in the orig.tar.gz
<NCommander> (not many, but sitll)
<calc> 409 lines for the new split package is just very basic support for the configure options, not much of anything in it yet
<NCommander> sbeattie, can't confirm the fix
<NCommander> Doesn't work right
<sbeattie> bugger.
<NCommander> sbeattie, its now recongizing archive.ubuntu.com as a third party software
<calc> http://pastebin.ubuntu.com/40799/
<calc> stuff like that
<NCommander> Sources still pull from there, so it needs to recongize both
<sbeattie> gar.
<NCommander> let me post my sources.list
<NCommander> sbeattie, I lost the bug, please relink
<calc> i'm trying to clean up as i go along since the current rules has evolved over 6 years and not really cleanly in some ways
<sbeattie> Launchpad #220890
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,Fix committed] https://launchpad.net/bugs/220890
<sbeattie> NCommander: is what you're seeing the same as bug 244093 or something different?
<ubottu> Launchpad bug 244093 in python-apt "Checking security repository in Updates adds deb line to Third-Party Software" [Medium,In progress] https://launchpad.net/bugs/244093
<NCommander> You mean security.ubuntu-ports.org in third-party software?
<sbeattie> yeah, something like that.
<NCommander> Nope
<NCommander> Just archive.ubuntu.com is showing up in third party
<NCommander> actually
<NCommander> Also the CDs are
<calc> all that use system stuff in OOo should be default, they ship copies of all those libs in the monolithic source (gag)
<sbeattie> NCommander: I have to run. Can you report your results as a comment to bug 220890? Thanks for testing it out!
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,Fix committed] https://launchpad.net/bugs/220890
<NCommander> sbeattie, I also uploaded a screenshot
<sbeattie> excellent, thanks!
<NCommander> I'm subscribed, so if any more testing needs to be done, hit me up
<StevenK> cjwatson: It's a copy of the older dailies. I didn't want to delete them in case someone missed them. It looks like no one has ...
<lifeless> EFAILTOUNDERSTANDUPGRADES: https://bugs.launchpad.net/bugs/75073
<ubottu> Launchpad bug 75073 in adept "missing conflicts or replaces: possible conflicts with Adept <<2.1 versions" [Undecided,Confirmed]
<poopcheese> I ASK THAT THE UBUNTU DEVELOPERS REMOVE ALL PROGRAMS THAT USE MONO.
<StevenK> Joining an IRC channel and yelling it isn't way to get it done.
<wgrant> I ask that Mono trolls don't shout nor troll.
<poopcheese> for me it is
<poopcheese> microsoft could sue the devels
<poopcheese> REMOVE IT
 * Hobbsee requests that poopcheese does something constructive.
<poopcheese> PLUS IT IS MADE MY NOVELL
<poopcheese> YOUR MEAN
<wgrant> I didn't know she had one.
<poopcheese> =/
<ssweeny> the caps lock key is not an Awesome Button
<ion_> wgrant: I borrowed my mean to her.
<Hobbsee> poopcheese: mono will not be removed at this time.
<poopcheese> WHY NOT
<RAOF> ssweeny: No, but it is CRUISE CONTROL FOR COOL!
<poopcheese> IT IS A PIG
<wgrant> RAOF: This is true.
<Hobbsee> poopcheese: and drop the caps.
<poopcheese> SRY MY KEYBOARD IS LIKE THIS
<ssweeny> poopcheese, you're free to apt-get remove mono and any programs that use it
* Hobbsee changed the topic of #ubuntu-devel to: archive: open | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<poopcheese> HAHA I DONT HAVE MONO ON MY COMPUTER IN FACT I USE WINDOWS XP WHICH IS MORE ADVANCED THAN LINUX AND UBUNTU
<Hobbsee> poopcheese: then why are you here?
<ajmitch> to provide constructive criticism, obviously
<Hobbsee> ajmitch: you haven't seen the half of it...
<wgrant> Because with Windows you can entirely avoid .NET. Mhm.
<ajmitch> I don't think I want to :)
<wgrant> Anyway, that was some nice pre-lunch entertainment. Have fun!
<Hobbsee> +z is a lovely mode...
<ion_> hobbsee: You really want to still see his messages? :-)
<Hobbsee> ion_: i'll deop soon.  or boot him.
<Hobbsee> ion_: but sure.  he might actually become constructive.
<Hobbsee> well, that was interesting.
<StevenK> It becomes no fun if he can't troll.
<Hobbsee> I think we need a sign saying "you need this much IQ to join this channel", though
<vorian> i'll have to leave then :'(
<Hobbsee> vorian: you can speak english, without capslock.    you're ok...
<vorian> yay!
 * Hobbsee ponders the ethics of forwarding to ##psychiatric-help-required or something
<StevenK> slangasek: Are you around?
<StevenK> slangasek: mysql-dsfg-5.0 failed to build on both i386 and amd64, I'm pondering just giving them back since the testsuite errors look ... odd
<calc> is there a way to get ppa builds for port systems?
<calc> eg easy testing of all archs without uploading to the main archive?
<LaserJock> PPAs are Xen, so it's limited to what Xen can do, from what I understand
<LaserJock> and so far that i386 and amd64
<StevenK> And lpia
<LaserJock> ah, right
<NCommander> meh, launchpad is slow tonight
<dholbach> good morning
<NCommander> StevenK, where's the build log?
<dholbach> can somebody moderate my mail on ubuntu-devel-announce?
<NCommander> is kubuntu-desktop broken for anyone else?
<cjwatson> dholbach: done
<dholbach> cjwatson: thanks a lot
<dholbach> cjwatson: you're up very early
<cjwatson> NCommander: yes. http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html
<cjwatson> dholbach: couldn't sleep; about to go back and try again
 * dholbach hugs cjwatson
<NCommander> oh yay, the output of britney
<NCommander> it looks like a few FTBFS are causing amd64 some grief
<LaserJock> argg, a lot of edubuntu on that list :(
<cjwatson> LaserJock: probably just due to kde
<LaserJock> perhaps, I tried to clean up a bunch of that
<NCommander> I didn't know Ebuntu was Kubuntu based
<NCommander> It looks like python-qt4 is the holdup
<cjwatson> it has some KDE components
<LaserJock> I'll maybe get a chance to look at it more tomorrow
<LaserJock> NCommander: it's Edubuntu not Ebuntu and it includes KDE-Edu
<NCommander> er, my bad
<NCommander> sorry, sorta late
<NCommander> It looks like python-qt4 failed
<NCommander> and then a bunch of packages got stuck behind it
<LaserJock> we also have an edubuntu-desktop-kde meta package for KDE'ers
<NCommander> edubuntu is susposed to be deployable over a thin client, right?
<LaserJock> that's a common use-case yes
<NCommander> I dunno, but GNOME seems kinda heavy to deploy to thin-clients, unless I'm mistaken that edubuntu is gnome based
<LaserJock> well, it entirely depends on your environment
<NCommander> well, whats the best way I could get started to try it out?
<LaserJock> for sure some people with not-so-great-networks/servers or with a lot of clients find it better to go with something lighter
<LaserJock> we used to ship XFCE as well, but when it got moved to Universe we stopped
<LaserJock> but people can install whatever DE they like with the thin clients, the Edubuntu addon CD just provides an educational layer on top
<LaserJock> NCommander: trying out what?
<NCommander> edubuntu
<NCommander> I dunno if I'm explaining myself well
<LaserJock> well, you can grab an .iso, burn it, and pop it in :-)
<NCommander> Why was Xfce moved to universe?
<LaserJock> well, it's easier for people to work on it
<NCommander> I thought canonical offered support for Xubuntu, or did that cease at some point
<LaserJock> they never did
<LaserJock> it used to be to build a CD using the Ubuntu infrastructure it had to be in Main
<NCommander> Right. but they were able to fix that
<LaserJock> but that's no longer the case, both Xubuntu and Ubuntu Studio build from Universe
<NCommander> Is Edubuntu supported by Canonical?
<LaserJock> yes
<highvoltage> NCommander: Edubuntu has an IRC channel as well, on #edubuntu
<NCommander> Neat
<NCommander> I'm suprised though no other *buntu distros have shot up
<LaserJock> how do you mean?
<LaserJock> there's a bazillion of them on distrowatch ;-)
<NCommander> I know emgent was trying to get wmaker-ubuntu off the ground, and Fluxbuntu also been working
<NCommander> I mean offically on launchpad
<LaserJock> well, it's rather difficult to build a derivative within the archive you're deriving from :-)
<LaserJock> not impossible by any means, but the "easy" way is to fork off your own repo
<NCommander> Well, I think emgent was simply going to try and get a meta package into universe, then use the cd burner scripts
<LaserJock> mhm
<NCommander> which is how I would roll any new distribution
<NCommander> Unless for some reason I needed packages that were unsuitable for the *verse
<LaserJock> I know of at least 5 derivatives in Universe
<NCommander> Myth, Xfce, Studio
<NCommander> What are the other two?
<LaserJock> Ichthux and Ubuntu ME
<raphink> hello
<LaserJock> heh, hi raphink
<raphink> hi LaserJock :)
<NCommander> I didn't realize Ubuntu ME was that far off the ground yet, I thought it was still in conceptional stages.
<jpds> hi raphink
<raphink> hello jpds
<NCommander> morning jpds
<NCommander> LaserJock, once kfreebsd-i386 gets off the ground, I won't mind seeing an Ubuntu distribution ported to it (I've been keeping my eye on nexenta, but it seems to be struggling)
<raphink> what does nexenta have to do with kfreebsd ?
<raphink> just wondering
<NCommander> I don't like the Linux kernel
<LaserJock> Linux without the Linux ;-)
<NCommander> I actually have a strong dislike for it
<raphink> hehe I see ;)
<NCommander> (I ran NetBSD for years before I finally got sick of ports)
<raphink> and darwing is dead, too
<raphink> although you can still use macports
<NCommander> fink is alive and kicking
<raphink> yes
<NCommander> I actually learned a LOT abotu Debian packaging through fink
<raphink> ah ok
<NCommander> Mostly because I helped debug a rather nasty bug four or five years ago
<NCommander> And helped bring the i386-darwin port into the world before Intel OSX  was released :-)
<raphink> I use MacOSX, but I strongly dislike how I can't get my hands behind the polished stuff
<NCommander> I won't mind seeing a Debian/Darwin
<raphink> at least not as easily as on linux
<NCommander> What I want is a kfreebsd designed system (jails :-)).
<raphink> ok
<NCommander> Solaris just ... well, it plain sucks on laptops
<raphink> but it rocks on servers
<NCommander> yeah
<NCommander> my server is running kfreebsd-i386
<NCommander> Maybe if I get bored this weekend I'll bootstrap Xubuntu kfreebsd-i386
<NCommander> :-)
 * NCommander is smacked a few times with a tree
<LaserJock> a Linux tree?
<LaserJock> :-)
<NCommander> The freebsd kernel is actually available in Ubuntu
<NCommander> apt-get source freebsd
<StevenK> NCommander: http://launchpadlibrarian.net/17093486/buildlog_ubuntu-intrepid-i386.mysql-dfsg-5.0_5.0.67-0ubuntu3_FAILEDTOBUILD.txt.gz
<mdke> with Ubuntu 8.04.1 my computer keeps freezing so that the only solution is to turn it off or reset it. How does one go about figuring out what the cause of that is and collecting useful information to file a bug?
<mdke> I have a hunch that it's firefox because it always seems to happen when I am using firefox, but that might just be because I use firefox more than other applications
<NCommander> StevenK, looks like the buildd had a seizure somewhere in there
<StevenK> NCommander: I'm pondering bashing the give back button
<NCommander> what's stopping you?
<StevenK> Fear of breakage
<lucas> mdke: check your ram?
<NCommander> StevenK, how can be be broken worse?
<NCommander> StevenK, did it FTBFS with the same error on multiple architectures?
<StevenK> NCommander: Similar error
<StevenK> NCommander: IE, test suite failure on amd64
<StevenK> However, i386 is a little more important since it builds Arch: all
<NCommander> is it a new upstream release or whatnot?
<StevenK> NCommander: Nope
<NCommander> what was the change?
<mdke> lucas: ah, I'll try that, thanks
<mdke> lucas: I hadn't thought that it could be hardware related
<StevenK> NCommander: Damn it, mysql failed the same way
<NCommander> StevenK, I'm looking at it
<NCommander> I can't figure out what changed
<StevenK> NCommander: I wonder if you have a machine faster than me to build it on
 * NCommander grabs the soruce
<NCommander> This is the version in intrepid, right?
<StevenK> NCommander: Right
<NCommander> Ok, I'll see if I can get it to build
<StevenK> NCommander: palmer is no slouch, and it takes it nearly an hour to build
<NCommander> Well
<NCommander> I have a distcc cluster
<NCommander> -j10 ;-)
<StevenK> NCommander: It gives a log, I'd like to see the log
<NCommander> The testing log, right?
<NCommander> (I wasn't going to roll it in a pbuilder instance yet, so I can do some debugging)
<NCommander> Its almost as if your causing the connection thread to crash and burn
 * NCommander looks at the changelog
<NCommander> It looks like the PIE hardening is what broke it
<StevenK> Yes
<NCommander> bah, I use dto run down this issue with m68k
<soren> Wow. A package that manages to build on HPPA, but fails on i386 and amd64.. That's a first (to me).
<StevenK> soren: Yes.
<NCommander> Ouch
<NCommander> Given the sorry state of hppa's compiler
<StevenK> What is this PIE hardening, and why did it break MySQL?
<NCommander> PIE stands for position independent code/executable
<NCommander> StevenK, ever program in ASM?
<StevenK> Oh, right
<NCommander> Its got a performance hit on i396
<NCommander> *i386
<StevenK> Now I get it, I just hadn't heard of it in terms of hardening
<NCommander> Yeah, that's a first for me
<NCommander> I mean, I get the theory
<NCommander> But Windows is completely position dependent
<NCommander> I"ve never heard as PIE as a hardening defense
<StevenK> Why do I have this feeling that it's SEGVing or something when it runs that test
<NCommander> StevenK, its probably a thread reaching an abend
<NCommander> But its got to be a compiler issue
<NCommander> PowerPC is PIE by default (amd64 too), and they're not blowing up
<NCommander> ER wait
<NCommander> Stupid quesiton
<NCommander> Is this failing on just i386?
<NCommander> Cause I'm compiling on amd64 ;-)
<StevenK> amd64 blew up too
<NCommander> Ok
<NCommander> good
<soren> What the...
<NCommander> BTW, mind doing me a favor as I hunt this down?
<soren> http://launchpadlibrarian.net/17103261/buildlog_ubuntu-intrepid-hppa.mysql-dfsg-5.0_5.0.67-0ubuntu3_FULLYBUILT.txt.gz
<NCommander> Can you sponsor an upload into Debian?
<soren> The hppa builds shows lots of test failures, too, but doesn't seem to care.
<NCommander> WTF
<NCommander> Well
<NCommander> UGH
<NCommander> MY EYES
<StevenK> Haha
<StevenK> NCommander: I suppose
 * Hobbsee notes this has nothing to do with her myspace page, either.
<NCommander> I'm an m68k buildd admin
<NCommander> I've sen funky failures
<NCommander> Perl 5.10 and linuxthreads
<NCommander> Yum
 * StevenK tells his Sid chroots, "Update thyselves!"
<StevenK> Hobbsee: Twitch
 * Hobbsee grins
<NCommander> StevenK, http://mentors.debian.net/debian/pool/main/c/codeblocks/codeblocks_8.02-1.dsc
<Hobbsee> StevenK: it's *lovely*!
<NCommander> As an aside, slangasek already took off running
<NCommander> Upstream shipping a debian folder
<NCommander> *shipped
 * StevenK joins his fellow Steve in running away
<NCommander> Crap
<NCommander> Lost another DD
<StevenK> :-P
<NCommander> seb128 was going to do it, but his sid chroot "mysteriously" broke
<StevenK> Sounds ominious
 * NCommander watches StevenK randomyl break
<NCommander> Seriously, how the hell does the hppa buildd not FTBFS
<NCommander> That just plain hurts
<StevenK> Haha
 * NCommander looks at the harding patch
<NCommander> I swear
<NCommander> if this is because some idiot doesn't know how to apply -PIE, I'm going to hurt the security team
<StevenK> NCommander: -fPIE?
<NCommander> Well, a good source of segfaults is when -fPIE and -fnotPIE combine
<NCommander> By your powers combined, I am caption Segfault!
<NCommander> I ... WTF
<StevenK> Yes. By your powers combined, I'm Captain SIGFPE
<NCommander> The HPPA build did fail its test suite
<NCommander> Miserably
<StevenK> Oh. Dear. God. We channeled the same thing.
<StevenK> Doing. It. Wrong.
<NCommander> The servers were restarted 122 times
<NCommander> Hrm
<NCommander> Oh shit
<NCommander> I see the issue
<NCommander> I'm going to hurt the security team if I'm right
<StevenK> No fair huring kees.
<StevenK> Er, hurting
<NCommander> Er, ok
<NCommander> I see why it failed on hppa I think
<NCommander> Was the the same failure on amd64?
<StevenK> i386 failed in the subselect test
<StevenK> amd64 failed in ps_7ndb
<NCommander> it looks like its trying to call code from outside mysql that isn't PIE
<NCommander> Which would cause an instant segfault
<StevenK> Why would ps_7ndb pass on i386, and fail on amd64? :-)
<StevenK> And subselect passes on amd64 and fails on i386
<NCommander> StevenK, its running the test suite
<StevenK> I think the MySQL test suite needs more kittens
<NCommander> We could simply back out the hardening_patch
<NCommander> binlog_killed_simulate         [ skipped ]   Test need debug binaries
<NCommander> Bah
<NCommander> Fixing this might be a plain nightmare
<StevenK> NCommander: In terms of with PIE-hardening?
<NCommander> Probably
<NCommander> ever look at mysql's codebase?
<StevenK> Nope. And I'd rather keep my eyes
 * NCommander codes in cobol for fun sometimes
<NCommander> I perfer my sanity :-)
<StevenK> "Fun" you say
<NCommander> I also like x86 ASM
<NCommander> What messes with my head
<NCommander> Is I've seen x86 ASM thats more clear to me then your average perl script
<StevenK> My last job was as a Perl coder
 * StevenK knows more about Perl internals than he cares to admit
<NCommander> "You shoot yourself in the foot, but six months later, you have no idea how you did it"
<NCommander> I had to fix a FTBFS deep within herny on m68k
<NCommander> That was wonderful
<NCommander> mostly because building perl was something like a 10 hour job
<StevenK> If you use a doorstep arch, it is
 * StevenK hides
 * NCommander crowbars StevenK 
<StevenK> :-P
<NCommander> Hurd is a doorstep arch, we actually *gasp* released a few times
 * wgrant clobbers StevenK with an m68k box.
<NCommander> wgrant, use an s390 one
<NCommander> Leaves a bigger mark
 * StevenK counters with the ultrasparc he has lying around here
 * NCommander uses slangasek's alpha
<NCommander> BHAHAHAHAHA
 * StevenK has one of those, too
<NCommander> you know
<NCommander> if mysql passes its test suite
<NCommander> I'm going to be pissed as hell
<NCommander> I hate migrating bugs
<StevenK> What did you change?
<NCommander> nothing
<NCommander> But I have that funny feeling
<NCommander> that the PIE bug will appear differently on different machines
<NCommander> Ugh
<NCommander> ndb_alter_table                [ disabled ]  failed for some reason
<NCommander> O_O;
<StevenK> Haha
<NCommander> Well, now I know why hppa didn't actually "fail"
<StevenK> No, just 3/4 of the test suite was disabled
<soren> NCommander: I'm quite sure kees did a test build with PIE enabled before he uploaded it. Has anyone talked to him?
<NCommander> Well, I'm getting the feeling looking at the build logs we're dealing with a migrating bug
<NCommander> i.e., it might appear different places based on kernel version, compiler version, etc.
<StevenK> soren: That's why I'm retiscent to just upload a fix. It's 2am in $TZ, though
<NCommander> The quick fix is to removing the harding-wrapper
<NCommander> And let security figure out the FTBFS
<NCommander> But given the fact the test suite was timing out with -fPIE enabled
<NCommander> I dunno
<NCommander> That sounds like quite a performance hit
<NCommander> and at best, a minor security fix
<NCommander> and only really help if your using something that randomizes the address space to prevent a return-to-libc attack
<StevenK> I thought we already enabled address space randomization in Hardy
<NCommander> I can't say I know
<NCommander> But its ineffective expect on AMD64
<NCommander> Its possible to brute force a return-to-libc attack on i386
<NCommander> Its kinda said mysql built on every architecture expect the release ones -_-;
<NCommander> wait
<NCommander> ...
<NCommander> WTF?!
<NCommander> #   intrepid lpia   Successfully built  (DONE)
<NCommander> HOW IS THAT IN THE LOVE OF GOD POSSIBLE
<StevenK> Yes.
<NCommander> o_o;
<NCommander> I.
<NCommander> O_o;
 * NCommander is speechless
<NCommander> lpia doesn't include any glibc/compiler changes does it?
<StevenK> Um, just compiler flags
<NCommander> YEah
<NCommander> It looks like the issue on hppa/amd64 is the ndb storage library
<NCommander> i386 is suffering from its own issues
<NCommander> StevenK, your going to love this
<NCommander> ps_7ndb                        [ pass ]          10331
<NCommander> (on amd64)
<NCommander> StevenK, were you able to reproduce the FTBFS on 127.0.0.1?
<StevenK> NCommander: I didn't try it
<NCommander> StevenK, Ok, whoever did the harding seems to not have read the MySQL manual
<NCommander> It needs --with-pic passed as a configure script option
<NCommander> Or things will explode it seems
<StevenK> NCommander: Ahhh
<NCommander> I'm not sure if it will make a difference yet
<NCommander> Note
<NCommander> Oh
<NCommander> That's pretty
<NCommander> -fPIC is passed as an arguement already
<NCommander> Now
<NCommander> If memory serves
<NCommander> If the same option is passed to GCC more than once
<NCommander> Doesn't it act like a toggle?
<StevenK> NCommander: Manual page doesn't say so
<NCommander> Hrm
<NCommander> It's stack-protector
<NCommander> Known issue with mysql and -fstack-protector
<NCommander> IT causes random segfaults
<NCommander> BTW
<NCommander> All 492 tests were successful.
<NCommander> :-P
<NCommander> so, to fix this
<NCommander> We need to disable the stack protector
<NCommander> StevenK, I'm rolling a patch
<StevenK> I thought the stack protector was enabled in Hardy?
<NCommander> Programs won't use it if not compiled with -fstack-protector
<wgrant> Stack protector has been on by default since before Hardy, IIRC.
<wgrant> It is at least in Hardy.
<NCommander> Meh
 * NCommander scratch that
<NCommander> My mistake
<NCommander> Unless mysql turns it off
<NCommander> Well, solving this now is a process of elimation
<NCommander> If *ahem* I could reproduce the FTBFS
<soren> wgrant: Since edgy.
<wgrant> soren: I thought so, but I don't recall specifically verifying that before Hardy. Thanks.
<soren> NCommander: GCC in Ubuntu defaults to -fstack-protector. You need to explicitly pass -fno-stack-protector to disable it.
<NCommander> Ok
<NCommander> So that rules that out
<NCommander> I'm looking for known bugs
<NCommander> It might be worth turning off the hardening PIE, and let mysql handle it directly
<NCommander> But ... bah
<NCommander> Until I can recreate this on demand ...
<StevenK> And pass --with-pic ?
<NCommander> StevenK, maybe
<NCommander> I'm uploading the package as is to my PPA
<NCommander> I need to confirm the segfaults
<NCommander> Since it passed my system without segfaulting
<NCommander> and we know the issue is intermittiant
<NCommander> lpia passed, while i386 didn't
<NCommander> And palmer failed, but mine passed
<StevenK> NCommander: palmer won't build for the PPA, either
<NCommander> I'm aware of that
<NCommander> But if I can't reproduce here, then I got to try reproducing in the PPA
<NCommander> Unless you want to start randomly feeding the buildds packages and see what builds
<StevenK> NCommander: Well, sure.
<StevenK> NCommander: Merely stating
<StevenK> Aww. ~ncommander doesn't exist
<NCommander> Nope
<NCommander> Its ~sonicmctails
<NCommander> :-)
<NCommander> https://edge.launchpad.net/ubuntu/+ppas - BTW, I dunno if you saw this, but needless to say, I have no life :-)
<NCommander> 55 uploads by hand in a week
<soren> NCommander: Yes, please calm down. You making everyone else look bad.
<NCommander> Well, someone asked me to package xfce 4.4, and then gnat 4.2
<NCommander> It's not my fault there are a lot of things to build :-P
<StevenK> NCommander: Doing NBS work for Gutsy I uploaded ~ 95 packages in the space of 3 hours
<NCommander> NBS?
<StevenK> Not Built from Source
<NCommander> Right, but uploaded?
<StevenK> Remember the libcurl mess?
<NCommander> Vaguely
<NCommander> Didn't the soname not change on an ABI break?
<StevenK> NCommander: That was ~ 95 uploads, most of them no-change rebuilds (-4 -> 4build1, for example), but I still added changelog entries, rebuilt the source, signed ~ 90 changes files and uploaded the whole lot.
<NCommander> my pipe couldn't handle that many uploads in such a short peroid of time
<StevenK> NCommander: Only source, and no origs
<NCommander> Oh
<NCommander> n/m ;-)
<NCommander> I didn't realize you joined my cruft busting group
<NCommander> (I need to send some emails to it, but I keep getting sidetracked)
<StevenK> I've been cruft busting since Edgy
<NCommander> Sweet
 * NCommander bends buildd.py to work on PPAs
<NCommander> I've discovered how anonying poor buildd administration can be
<NCommander> Especially if you have seven or eight packages pending builds, and they form a chain of dependencies
<jpds> NCommander: If you can make a --ppa flag for it, please give me a patch against lp:ubuntu-dev-tools
<StevenK> NCommander: If they build depend properly, most of them should hit DEPWAIT and then retry themselves
<NCommander> I've never seen a PPA package properly leave dep-wait
<NCommander> (they enter it just fine, just never leave)
<StevenK> Hmm. Hotel California buildd states
<NCommander> Yeah, but they haven't been like that since '79
<NCommander> StevenK, you can help speed up the process by rescoring my PPA to take priority on the buildds ;-) *smacked*
<NCommander> (it sucks when the i386 translations build hits and i386 builds take forever)
<NCommander> StevenK, this is going to take awhile to build, got any other strange FTBFS that need looking at?
<Fritz> anyone willing to help with a question?
<StevenK> NCommander: That's it
<NCommander> Do I need to get this done before the FF?
<NCommander> Or can we get an FFE for it
<StevenK> NCommander: It's fixing a build failure ...
<NCommander> so FFE :-)
<NCommander> Just making sure
<NCommander> I work well under pressure
<NCommander> SO I wanted to know how fast I had to turn around a patch
<StevenK> NCommander: In which case, I wanted the patch yesterday.
<NCommander> This will probably take a day or two to run down. I'm seeing if I can reproduce on real i386 hardware
<NCommander> (as in hardware I control)
<Fritz> i have an hp tx1000, wifi and touch screen funtions are not working with ubuntu, any ideas?
 * StevenK peers at samarium
<NCommander> Fritz, wifi probably means firmware missing
<Fritz> what can i do?
<NCommander> Check Restricted Drivers (System -> Administration -> Restricted Drivers)
<NCommander> See if one is available for your wifi card
<NCommander> Note: You need to be connected to the internet on that machine to get the firmware
<Fritz> ethernet wont work, can i do it comp to comp, or use windows drivers?
<NCommander> If you have windows drivers
<NCommander> ndiswrapper might get you online
<NCommander> But I'm sorta blocking on the specifics
<NCommander> First see if Ubuntu offers to download firmware
<Fritz> will do, thank you.
<NCommander> If it does, then your at least in the right ball part w.r.t.  to getting wifi going
<NCommander> s/part/park/g
<NCommander> Man, my list of icons has gotten very long O_O;
<NCommander> StevenK, why were you looking for my profile page out of curosity
<StevenK> NCommander: To find your PPA
<NCommander> Ah, "You are at a long and slow Launchpad. Exits are in all directions"
<NCommander> ^Launchpad page
<NCommander> StevenK, BTW, if this doesn't FTBFS
<NCommander> I think I'm going to loose my mind
<cjwatson> you should always loose your mind anyway; keeps it free from unnecessary constraints ...
<cjwatson> </pedant>
<StevenK> Bwaha
<NCommander> Prolonged exposure to debian-cd already loosed my grip on my sanity
<NCommander> lol, I say debian-cd, and he drops
<NCommander> StevenK, so if it passes in the PPA, then what?
<NCommander> I can't reproduce, and its so hard to reproduce, its hard to tell if the harden-security is a regression or not
<StevenK> Then I'm not sure.
<StevenK> Then I think we beg cjwatson
<NCommander> for all we know, this issue been going on since 0ubuntu1
<NCommander> cjwatson, please build xubuntu powerpc CDs :-)
<NCommander> Oh wait
<cjwatson> beg me for what?
<NCommander> wrong begging
<StevenK> Nah, 0ubuntu2 added the patch
<NCommander> No, I mean before hardened was enabled
<NCommander> Its possible this is a lurking issue
<NCommander> cjwatson, we're dealing with an FTBFS on amd64/i386, but passes on lpia/hppa :-)
<StevenK> cjwatson: mysql-dfsg-5.0 FTBFS on i386 and amd64 due to an unclear issue
 * NCommander hears the scream from here
<NCommander> sweet, sweet music
<NCommander> Maybe it means palmer having hardware issues
<StevenK> I hope not.
<NCommander> actually, it would also mean the amd64 buildd having them too
<NCommander> DktrKranz, how goes the gnat-4.2 transition
<cjwatson> so this is "random failure of user_limits.test
<cjwatson> "?
<NCommander> and how can I help to speed that up before the freeze
<NCommander> cjwatson, no, its random tests on different goes
<NCommander> It passed on my amd64
<NCommander> hppa had a non-critical failure
<NCommander> It failed on the buildd
<NCommander> the security machine where they did the work likely passed it
<DktrKranz> NCommander: it involves hardy, no need to hurry right now, better focus on pre-FF bugs now
<NCommander> Ok
<NCommander> I may move the packages into a temp group
<cjwatson> NCommander: has anyone tried the upstream commit http://lists.mysql.com/commits/49751 (referenced from http://bugs.mysql.com/bug.php?id=23921)? that fix isn't specific to a single test
<NCommander> my PPA getting cluttered
<NCommander> cjwatson, No, but this might be the issue
<NCommander> The PIC code slows down mysql slightly
<NCommander> Might JUST be enough to trigger a random failure
<NCommander> expect palmer made the same failures
<NCommander> If this doesn't fail
<NCommander> I'll backport this fix, and then hit StevenK to try it on the real buildds
<NCommander> If THAT does fix it, I think we can rule it out to the hardening fixes (which is what I thought it was since the FTBFS only showed up after the security team added them)
<NCommander> Is mysql main or universe?
<NCommander> (if I don't have to constantly torment StevenK, thats a good thing for my future as a potential core-dev)
<StevenK> Main
<NCommander> so much for core-dev
<NCommander> Although at this point, UUC would be nice :-)
<NCommander> cjwatson, connection issues?
<NCommander> StevenK, so how goes reviewing codeblocks ;-)
<StevenK> I ran screaming, remember?
<NCommander> crap
<NCommander> Well, I can run screaming from this bug
<NCommander> So run back
<cjwatson> NCommander: router was playing up so I rebooted it
<NCommander> My router runs Debian mips :-)
<NCommander> so how goes your morning cjwatson
<cjwatson> not inclined to random chat with FF tomorrow, really :)
<NCommander> ah ok
<NCommander> StevenK, why aren't you going crazy with the last day before FF?
<NCommander> StevenK, it passed the build that failed on the main buildd
<NCommander> s/build/test/g
<StevenK> NCommander: I probably should be
<NCommander> so what gives ;-)?
<NCommander> (if you have things for me to do, I'd be glad to work while I wait for these things to build)
<StevenK> NCommander: Currently off duty while waiting for dinner
<StevenK> I'll panic when I'm working again
<NCommander> Well, if you need some FTBFS/packaging/Ada work done
<NCommander> Drop me an email
<NCommander> (yes, I said ada)
<NCommander> StevenK, you are going to love this
<NCommander> It passed the test that failed
<NCommander>  uh
<NCommander> Shit
<NCommander> I think I crahsed the PPA machine
<NCommander> StevenK, FTBFS/packaging/Ada
<NCommander> er
<NCommander> StevenK, https://edge.launchpad.net/+builds
<StevenK> NCommander: Hm, I see that.
<StevenK> NCommander: "Bad"
<jpds> cjwatson: Have you seen http://labs.mozilla.com/2008/08/introducing-ubiquity/ ?
<cjwatson> jpds: heh. well, it's an English word, it's going to be hard to claim a monopoly
<Treenaks> cjwatson: tell that to the terminator people :)
<Ng> Treenaks: harsh ;)
<Treenaks> Ng: well, I heard they're considering a name change because another project had the terminator name
<Treenaks> Ng: same with firebird->firefox, but I'm not sure if that's a "proper" English word
<Pici> terminatorx probably...
<jpds> Treenaks: Ng is terminators author.
<Treenaks> jpds: ah! didn't know
<Treenaks> Ng: sorry then :)
 * Pici either
<cjwatson> I'm not renaming ubiquity again. The Mozilla project is different enough that, well, whatever.
<Ng> Treenaks: we're considering it, but probably not doing it ;)
<Treenaks> cjwatson: also, the Mozilla project has renamed before.. :)
<thom> i'd think a bigger objection to terminator is that it's un-googleable :)
<tacone> thom: "terminator linux"
<Treenaks> terminator -skynet
<tacone> terminator -hasta -la -vista -baby ?
<Ng> thom: I think the kind of people likely to be using multiple terminals simultaneously can cope with that :)
<davmor2> Guys why do any graphical changes you make in OEM mode not get carried forward to end user?  E.g. change backdrop, switch on compiz etc
<cjwatson> because those are stored in the home directory, and it's extremely unclear what if anything should be copied over from there to the newly created user
<cjwatson> for example, it's not unusual for the username to end up hardcoded in files in the home directory (e.g. absolute paths)
<cjwatson> the safe option is to create the new user from scratch, and that's what we do
<cjwatson> $ grep -r cjwatson .gconf | wc -l
<cjwatson> 12
<davmor2> cjwatson: doesn't that then negate the whole purpose of the oem mode?  Isn't the idea that you set things up as you want the end user to see them and then the end user adds there details?
<cjwatson> you set the computer up, not necessarily the user account
<cjwatson> if you want to set up default user accounts, use something like sabayon
<cjwatson> s/default /defaults for /
<davmor2> OKay thanks for that then :)
<cjwatson> the core purpose of the oem mode is to allow the end user to enter their personal settings the first time they boot a system that somebody else installed
<cjwatson> the customisation possibilities afforded by that kind of arrangement are incidental, not the whole purpose
<StevenK> cjwatson: Okay, can we talk about this MySQL thing? Should I prepare an upload with that patch, since NCommander's test on the PPA buildds has caused samarium to offline itself twice now.
<cjwatson> StevenK: my direct knowledge of MySQL can be counted on the fingers of one foot; if you think it's sane, you should probably go ahead
<StevenK> cjwatson: Same. But MySQL being broken is causing ubuntu-mid to be uninstallable, which is holding me up, so I care until it's fixed, either by me or someone else.
<cjwatson> I'd JFDI if I were you
<Hobbsee> cjwatson: he'll quote you on that..
 * StevenK grins
<StevenK> "But Colin said yes!"
 * ogra wonders what in -mid depends on mysql
<StevenK> ogra: gstreamer-plugins, somehow
<ogra> bah
<StevenK> Yes. I don't get it either.
<ogra> StevenK, hmmm, i see gstreamer0.10-plugins-bad and gstreamer0.10-plugins-ugly in the -mid deps
<StevenK> ogra: That's what I meant
<ogra> we should only have -base and -good
<ogra> kirkland, ping (i was contacted by edubuntu users about #120375 ... you need an upload bitch ?)
<zul> ogra: kirkland is still on holidays but he pops in from time to time
<ogra> zul, ok
<ogra> zul, thanks :)
<ogra> he at least leaves his clientconnected, so i count on the fact that he reads the ping at some point :) )
<zul> ogra: yep he does he is backpacking in scotland though apparently
<Riddell> hmm, mvo on holiday, guess I'll just have to hijack UpdateManager without permission
<cjwatson> tseliot: can we make the nvidia modalias packages architecture: all? the current situation causes uninstallability on architectures other than amd64 and i386
<tseliot> cjwatson: but AFAIK NVIDIA doesn't support other architectures or am I missing something?
<cjwatson> tseliot: well, in that case make nvidia-common architecture: amd64 and i386 only
<cjwatson> can't have it both ways ;-)
<cjwatson> tseliot: actually, though, I think you're mistaken. I know there have been powerpc systems shipped with nvidia cards.
<tseliot> cjwatson: ah, ok I see your point now. I have to talk to mvo before I do it, since he uses nvidia-common in update manager
<TheMuso> Yes powerpc systems did have nvidia cards.
<cjwatson> Apple shipped its 12" PowerBooks with nvidia for some time
<TheMuso> s/did/do/
<TheMuso> and G5s as well.
<\sh> grmpf....does anyone know how to force dkms and this somehow broken fglrx driver to build for intrepids kernel?
<cjwatson> tseliot: making the modalias packages architecture: all shouldn't need mvo's help, I think. If you just need somebody to do the upload then I can do that
<tseliot> cjwatson: ok but is there a proprietary driver (on Linux) which works on PPC?
<tseliot> cjwatson: making it amd64 and i386 only might cause him some trouble though
<TheMuso> tseliot: no there is not, and never likely to be.
<tseliot> TheMuso: right that's my point.
<tseliot> cjwatson: we should make nvidia-common amd64 and i386 only but I have to make sure that this doesn't cause problems to Update manager
<jdstrand> soren: as you know, I have been working on ufw's package integration (see UbuntuFirewall). Basically, packages can declare profiles for ufw to use in its rules.
<soren> jdstrand: Right.
<jdstrand> soren: currently, packages need to drop files into /etc/ufw/applications.d, but I don't think I like that location, in part because if these changes ever get into debian, the location will likely need to be more general
<jdstrand> eg /etc/fw.d
<cjwatson> tseliot: I just checked: update-manager only build-deps on nvidia-common on amd64 and i386, and it takes care to cope gracefully if nvidia-common is missing at run-time
<soren> jdstrand: You think?
<jdstrand> soren: so that other applications could use them (the declaration themselves are not ufw speicific, just a title, description and port declaration
<jdstrand> soren: :)
<cjwatson> tseliot: so I don't think restricting nvidia-common's architectures should regress anything in update-manager
<soren> jdstrand: Hm... I guess.
<jdstrand> soren: so I was curious as to your opinion on this
<jdstrand> cjwatson: if you'd like to weigh in, that would be great too ^^
<tseliot> cjwatson: ok, then I'll change the package and ping you back with the link or would you prefer if I filed a bug report and put the link there?
<cjwatson> tseliot: either works fine
<tseliot> cjwatson: ok
<jdstrand> soren: it isn't so much about other firewall apps using them, as much as making sure that packages don't have to change the location if another app wants to
<jdstrand> use those profiles
<soren> jdstrand: Right. Hmm..
<zul> jdstrand: I take those ufw needs to be sponsored today?
<cjwatson> (I suggest "firewall" rather than "fw", but that's trivial)
<jdstrand> I kinda liked /etc/firewall.d, but that is used by cfengine (at least)
<cjwatson> ah
<cjwatson> I question the Hungarian .d
<soren> O_o
<ion_> /etc.d
<jdstrand> zul: yes, but as I am changing a location, I will do all those
<zul> jdstrand: coolio
<jdstrand> cjwatson: I'm not married to it-- did it more out of habit
<soren> cjwatson: Hungarian .d?
<cjwatson> the original semantics of .d (as best as I can reverse-engineer them) were something that could also be in a parallel .conf file, but that had a split-out form
<cjwatson> I don't think we should necessarily be using it for all directories :-)
<jdstrand> heh
<ion_> Indeed
<cjwatson> soren: http://en.wikipedia.org/wiki/Hungarian_notation
<jdstrand> actually, I wonder if firewall-profiles would be appropriate?
<jdstrand> though that seems to imply too much
<soren> cjwatson: Oh, right.
 * soren totally didn't make that connection
<cjwatson> jdstrand: do you think it's likely that such other applications will actually exist?
<soren> And just as importantly: Do you think it'll share its config file format with ufw?
<cjwatson> it's laudable to design for the future, but it's also easy (a) to go too far (b) to forget other things that such future applications will need and so wind up having to change lots of stuff anyway
<cjwatson> there are packages in Debian that e.g. ship configuration for particular editors, and I think this is generally considered OK
<jdstrand> cjwatson: doubtful, but I'd like to get ufw included in debian, and also the changes to the packages that drop files into this directory, so wanted a sane location
<jdstrand> that said, they maintainer script would still need to call ufw, so Debian would need to accept ufw whole-hog anyway to accept those changes
<cjwatson> I actually think it might be preferable to use your own namespace for now (and I don't think that would be as much of a problem for package integration in Debian as you think), rather than grabbing a nice chunk of namespace that (from Debian's perspective) you might not make good use of
<jdstrand> which is more doubtful, so I suppose my current location is ok
<cjwatson> why does the maintainer script need to call ufw, rather than ufw registering a trigger on /etc/ufw.d/ ?
<jdstrand> cjwatson: TBH, I am not familiar with this process. can you point me somewhere to learn more?
<cjwatson> I can point you to man-db as a (perhaps slightly overworked) example
<cjwatson> the triggers specification is here: http://lists.debian.org/debian-dpkg/2007/04/msg00076.html
<cjwatson> (but is very much package-manager-theoretical)
<jdstrand> cjwatson: thanks. this is all excellent feedback
<cjwatson> jdstrand: the menu package is a simpler example, I think
<cjwatson> this works as long as all the maintainer scripts would just be calling ufw with the same arguments and having it import all the new configuration it finds
<cjwatson> if they need to use different arguments it won't work as it stands
<jdstrand> cjwatson: hmm, it needs one argument that is different
<cjwatson> ah, in that case just do what you have to do for now and skip the triggers bit
<cjwatson> however: what happens if ufw is installed *after* a package that ships a file in /etc/ufw/ ?
<cjwatson> does it know how to import that configuration when it's configured itself?
<jdstrand> cjwatson: yes
<cjwatson> in principle, then, could you do whatever ufw.postinst does to import all configuration in every maintainer script?
<tseliot> cjwatson: would this lintian error be tolerated? build-depends-indep-without-arch-indep
<cjwatson> tseliot: no, that will cause problems - you need to change Build-Depends-Indep to Build-Depends in debian/control
<tseliot> ok
<jdstrand> cjwatson: the profiles in question aren't really imported per se. on each invocation, ufw checks the /etc/ufw/applications.d directory and uses what it finds. the postinst bits do two things-- update the running firewall if there are rules that reference the profile, and add a new rule for the specified profile if the admin setup ufw to do that
<jdstrand> (by default ufw will not add any rules)
<cjwatson> ok, ignoring my wording snafu though, do you see what I'm getting at?
<TheMuso> For a RAID4 array, what is the minimum number of disks you need for the array to be functional, i.e not degraded?
<pascal> Are others having trouble using the arrow keys in Intrepid? I installed Alpha 4 and after that I'm not able to use arrows keys, delete and some other keys. Works fine if I boot up in hardy
<cjwatson> we're trying to use triggers where possible rather than adding a chunk to every maintainer script, because ultimately it's simpler to maintain, and it's generally faster (particularly when you take into account doing this for all the random things done in maintainer scripts)
<jdstrand> cjwatson: IIUC, you're saying maybe I could make it triggerable
<cjwatson> right
<cjwatson> doing so usually involves having a way for the triggered package to just suck in all the stuff that was done, as if each package had run an individual command
<cjwatson> for instance it's so much better for man-db to automatically update itself when packages update manual pages than it would be for every package to have to say mandb -f /usr/share/man/man1/ls.1.gz or whatever
<jdstrand> cjwatson: right-- I really like the idea, and I can absolutely make it work with the 'update' part, but have to think about the '--add-new' part
<cjwatson> ok, it shouldn't block your work for feature freeze or anything - I just wanted to raise it since it seemed like an obvious extension
<jdstrand> (there was great interest in that aspect, though personally I don't like adding rules to a firewall via package installation)
<tseliot> cjwatson: here's a file containing the links to the files: http://albertomilone.com/ubuntu/nvidia-common/links.txt
<jdstrand> cjwatson: thanks again-- really excellent feedback :)
<TheMuso> nvm got my answer
<cjwatson> argh, dupload is consistently timing out while uploading ubuntu-meta (a whole 37KB)
<ogra> still your network ?
<cjwatson> I don't know what's wrong, scp is timing out on that file as well
<\sh> bryce: this screen-resolution-extra stuff for the gnome applet, how does it work? I have here an ATI card, with radeon driver running, two screens, but I'm unable to move one screen to the left or to the right, but this applet says so. and nothing is changed in xorg ... how does it work then?
<cjwatson> to multiple different hosts
<cjwatson> weirdness threshold exceeded; I think I'll just reboot
<ogra> tedg, seen Bug #229618 ?
<ubottu> Launchpad bug 229618 in xscreensaver "please merge xscreensaver 5.05-1 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/229618
<tedg> ogra: Yeah, I'm curious what you're thinking there.  Merge the changelogs differently?
<ogra> no idea, i'D just grab the mentioned 5.07 to get tormods changes in (i bet he has done them in debian)
<ogra> beyond tht the usual megre policies apply
<tedg> ogra: Sorry, I hadn't read the last comment...  now I'm up to speed.
<tedg> My personal feeling is that tormod should do it, are version updates (5.05 to 5.07) effected by feature freeze?
<\sh> grmpf...in gnome + kde4.1 the dual head stuff doesn't work with the radeon driver...regarding the logs it find everything and initializes it
<ogra> tedg, yes, feature freeze == upstream version freeze ... though i do think getting an exception wouldnt be to hard, but i'm not the one to decide
<ogra> \sh, dual head like one head gnome and the other kde ? :P
<\sh> ogra: lol...
<ogra> btw, sorry, but we didnt make it to froscon
<\sh> ogra: na serious...I see the two screens...gnome: sending one screen to the left or right is dropping me to no signal on screens , and kde screen resolution tool doesn't do anything...
<ogra> works fine here with itel card.... no radeon around ...
<ogra> *intel
<tedg> ogra: Okay, I'll reply to the bug and then do it if tormod doesn't have time.
 * Adri2000 needs an archive admin
<cjwatson> tseliot: done
<cjwatson> ah, my networking problems were due to having both wired and wireless interfaces up at the same time
<Adri2000> cjwatson: could you please copy two packages from -proposed to -updates for me?
<tseliot> cjwatson: great :-)
<cjwatson> Adri2000: bug number?
<Adri2000> cjwatson: bug #252689
<ubottu> Launchpad bug 252689 in soyuz "Permit to upload a new package with the same name-version of another package already uploaded (PPA)" [Undecided,New] https://launchpad.net/bugs/252689
<Adri2000> no, sorry
<Adri2000> bug #243722
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,Fix committed] https://launchpad.net/bugs/243722
<Adri2000> (was reading #launchpad at the same time :p)
<cjwatson> Adri2000: ok, can't do it right this minute but I'll queue it up
<Adri2000> ok, thanks
<cjwatson> tseliot: that failed to build because your debian/rules does its hard work in binary-indep but it now needs to be in binary-arch. Shall I just fix it and reupload?
<tseliot> cjwatson: weird, it didn't fail here. Please fix it. Thanks again
<cjwatson> tseliot: you probably did debuild -b (or no arguments) rather than -B
<cjwatson> http://launchpadlibrarian.net/17115976/buildlog_ubuntu-intrepid-amd64.nvidia-common_0.2.2_FAILEDTOBUILD.txt.gz
<tseliot> cjwatson: right, I can see the problem now. Sorry
<cjwatson> fixed
<tseliot> ok
<mterry_> Does anyone know if a program can tell when a VT switch happens?  Some event that can be caught?  (I'm looking at UNR launcher bug 237761)
<ubottu> Launchpad bug 237761 in netbook-remix-launcher "ume-launcher stop working after a suspend" [High,In progress] https://launchpad.net/bugs/237761
<ogra> mterry_, you can put scripts into pm-tools
<ogra> that can trigger something for you
<ogra> mterry_, /usr/lib/pm-utils/ have a look there
<ogra> you can execute any kind of script at resume with that
<mterry_> ogra: Hmm, interesting.  But I'm looking for any VT switch, not just resume
<ogra> you could check for fgconsole
<ogra> grep fgconsole /etc/init.d/usplash
<ogra> have a look there
<ogra> not sure how to do that from C in a clean way thouh
<mterry_> ogra: Also a good tip, but doesn't work from X
<cjwatson> there's a VT_WAITACTIVE ioctl you can use to wait for a given console to become active
<ogra> mterry_, well, works from X for me ... but needs suid rights
<cjwatson> the thread can't do anything else while doing that though
<mterry_> ogra: Ah, right you are
<ogra> sudo fgconsole properly returns 7 here
<mterry_> cjwatson: :-/
<ogra> there was a tool to work around the sudo from mjg59 ... not sure we still have it nowadays
<mterry_> cjwatson, ogra: Sigh, I was hoping for a nice X event or something
<cjwatson> I think there's a consolekit dbus message that gets sent
<ogra> mterry_, how about asking the WM about being mapped ... does it really need to be the console ?
<ogra> i.e. mapping the wallpaper could just triger your event
<ogra> or something like that
<bryce> \sh: stay tuned; the code you need isn't in the archive yet
<ogra> bryce, i consider touchscreens not working a regression bug and thus not FF critical, do you agree ?
<bryce> ogra, bug #?
<ogra> none yet, but iÃll file one before FF :)
<ogra> esentially it is "no evtouch based touchscreens work after hal-input switch"
<bryce> "doesn't work" has such broad meaning...
<ogra> bryce, isnt configured at all
<mterry_> cjwatson: This consolekit dbus stuff looks promising.  Thanks
<ogra> better ?
<mterry_> ogra: Not a bad idea either about mapping
<ogra> bryce, i have http://paste.ubuntu.com/40402/
<bryce> ogra: yes
<ogra> bryce, but i have no time to test the matching fdi stuff that needs today
<ogra> bryce, works similar to the kbd stuff with sourcing the console defaults
<ogra> that way we can ship a common fdi and can have specific setups in /etc/default/evtouch
<ogra> if i get around it in time for intrepid i'll fixx the calibration tool to write to /etc/default/evtouch
<bryce> I would want to think that evtouch should at least work even if not configured, by using acceptable defaults
<ogra> it doesnt
<ogra> simply because X likes to pick mouse or evdev for the devices
<bryce> anyway, I would think FF wouldn't inhibit posting fixes to a bug like this
<ogra> great
<cjwatson> dendrobates: who has the baton on getting an updated landscape-client into the archive right now? I gather kirkland is on holiday - has it been handed off to somebody else, or is it going to slip past FF?
<cjwatson> dendrobates: I've added the pkgsel question as I understood the specification
<dendrobates> cjwatson: I do.  Currently the security team is reviewing it.
<dendrobates> cjwatson: if we just uploaded it, it would slip into main without review, due to the empty package alrready there.  We are trying to avoid that.
<cjwatson> understood, I just wanted to know whom I needed to sync up with about the installer bits
<cjwatson> dendrobates: #ubuntu-installer?
<\sh> bryce: you mean screen-resolution-extra and python-xkit?
<bryce> yes
<\sh> bryce: it's in universe...and I installed it somehow
<bryce> also, the screen-resolution-extra has a minor bug I found, that tseliot will be posting a fix for today
<bryce> oh great
<bryce> it requires a patched gnome-control-center
<\sh> ah :)
<bryce> http://bryceharrington.org/ubuntu/ScreenRes/
<bryce> the bug is that you have to change "time.time()" to "str(time.time()" in one of the python files
<\sh> bryce: in the meantime, what's the best way to generate an xorg.conf file, and set the virtual stuff manually?
<ogra> bryce, bug #261873
<ubottu> Launchpad bug 261873 in xf86-input-evtouch "make evtouch devices work with hal-input in intrepid" [Undecided,New] https://launchpad.net/bugs/261873
<bryce> \sh, https://wiki.ubuntu.com/X/Config
<ogra> bryce, hoping my blog entry gets me some more touchscreen info for others
<\sh> bryce: thx :)
<jdstrand_> why in the world did citadel-server get pulled into my schroot buildd?
<cjwatson> Provides: imap-server, pop3-server?
<soren> jdstrand_: When building what?
<jdstrand_> soren: when dist-upgrading it
<soren> Yikes.
<soren> I haven't a clue.
<jdstrand_> this is my -source
<jdstrand_> yeah, me either, no time to figure it out-- it was mostly rhetorical
<LaserJock> jdstrand_: do you have devscripts installed in your chroot?
<jdstrand_> LaserJock: why yes I do
<LaserJock> jdstrand_: that'd most likely be it
<LaserJock> Recommends made devscripts pull in quite a bit more than it used to
<jdstrand_> LaserJock: I'd say. thanks for the tip
<jcristau> jdstrand_: stuff depending on / recommending m-t-a, pulls in citadel-mta
<jdstrand_> sure, I just didn't know what that 'stuff' was-- the schroot is pretty barren
<BenC> mdz, slangasek, cjwatson: We're discussing the 2.6.27 move and contingency plan on #ubuntu-kernel IRC meeting right now, if interested
<dholbach> does anybody know what the problem is in bug 260873?
<ubottu> Launchpad bug 260873 in lua-gtk "Please sync lua-gtk (0.8+20080510-2) from Debian (main) to Ubuntu (universe)" [Undecided,Incomplete] https://launchpad.net/bugs/260873
<BenC> cr3: Could I ask you to join #ubuntu-kernel to talk about certification testing with 2.6.27?
<cr3> BenC: sure thing
<\sh> hmmm..what happend to evolution and its exchange support? it doesn't work in intrepid anymore :)
<cjwatson> dholbach: the problem seems to be that ARCH isn't set in Makefile, so ./configure gets --host without an argument, and thus runs out of options during option processing (that's the "can't shift that many" bit)
<dholbach> thanks a lot cjwatson
<geser> dholbach: see Debian bug 493424
<ubottu> Debian bug 493424 in lua-gtk "lua-gtk: FTBFS with /bin/sh -> dash" [Important,Closed] http://bugs.debian.org/493424
<dholbach> geser: great... thanks!
<geser> dholbach: testing right now if the new version builds
<dholbach> geser: thanks a lot
 * dholbach hugs super-geser
<jdong> I'm seeing a lot of dscverify can't find debian keyring errors from dpkg -x since Intrepid; is this supposed to happen?
<jdong> err, dget -x
<jdong> i.e. grabbing a dsc URL off Launchpad; these packages should be signed by Ubuntu
<cjwatson> not a valid assumption
<cjwatson> for packages we've synced from Debian, they'll be signed by keys in the Debian keyring
<cjwatson> we don't re-sign the .dsc
<jdong> ok
<cjwatson> perhaps somebody should add the Ubuntu keyring to the list of keyrings checked by dscverify, though
<jdong> hmm this particular package is an Ubuntu one
<cjwatson> (/usr/share/keyrings/ubuntu-archive-keyring.gpg)
<jdong> oh is the Ubuntu keyring not recognized by dscverify?
<cjwatson> right
<geser> dholbach: the new lua-gtk version starts building but fails during the tests :(
<cjwatson> however, we don't actually export a list of all keys of all Ubuntu maintainers anywhere
<cjwatson> ubuntu-archive-keyring.gpg just has the keys that sign the Release file, not the keys that sign .dscs
<cjwatson> so, err, you're screwed right now. best just ignore .dsc verification errors
<jdong> cjwatson: thanks for the info :)
<dholbach> geser :-/
<dholbach> geser: maybe best to just close the sync request for now
<geser> perhaps, I've added the last build failure to the sync request
<LaserJock> QA Team meeting in 10 min. in #ubuntu-meeting
<soren> jdstrand_: Just a friendly suggestion: A dh_ufw might be in order.
<jdstrand_> soren: maybe some day, but not today. the dpkg triggers cjwatson suggested worked great
<jdstrand_> (after I changed a couple of things)
<jdstrand_> soren: but thanks for your suggestion :)
<soren> Well, not just for instrumenting postinst, but also to pick them up automagically from the debian directory and put them in the right place.
<soren> That way, if we decide "something" needs to be done to ufw rule files, we only need to change it in one place.. But yeah, "some day" is fine. :)
<apachelogger> kees: I am not sure if you know already, but the hardening for mysql-dfsg-5.0 broke half of mysql, thus breaking _all_ of KDE
<apachelogger> kees: compare binary package list of https://edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/5.0.67-0ubuntu1 with https://edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/5.0.67-0ubuntu2
<cjwatson> apachelogger: it hasn't built yet - StevenK and others were investigating that this morning and we think we have a possible fix
<kees> apachelogger: It failed to build only on amd64 on the buildds before hardening, and failed on i386 only after hardening.
<kees> apachelogger: both of which I haven't been able to reproduce.
<cjwatson> apachelogger: we think in fact the problem was at best only tangentially related to hardening; it's a timing issue in the tests
<kees> cjwatson: ah, good to hear
<cjwatson> apachelogger: which appears to have been fixed upstream unless I'm much mistaken, so we can pull back that patch
<tedg> How do I find what changed in debian policy between two versions?  ie from 3.7.3 to 3.8.0
<cjwatson> tedg: upgrading-checklist
<saivann> I would need some help with a ubuntu package, can a ubuntu developer help me?
<saivann> It's concerning missing files in /usr/lib32 in my x64 package
<kees> tedg: install "debian-policy" and look at the upgrading-checklist file in /usr/share/doc/debian-policy/
<apachelogger> cjwatson: shouldn't ubuntu3 have fixed the issue then?
<apachelogger> we can't testbuild/upload any KDE software right now since it FTBFS
<cjwatson> apachelogger: that's quite different from the upstream fix
<apachelogger> ok
<cjwatson> it is not obvious that simply reverting hardening will reliably fix things
<cjwatson> the problems are transient
<cjwatson> StevenK: so what happened to that mysql upload?
<apachelogger> most awkward kind of problems, due to upcoming FF :)
<tedg> Cool thanks kees and cjwatson
<cjwatson> kees: perhaps you could grab the patch out of this morning's scrollback and have a look over it
 * kees goes digging
<cjwatson> http://bugs.mysql.com/bug.php?id=23921 -> http://lists.mysql.com/commits/49751
<cjwatson> kees: ^-
<kees> zul: were you able to reproduce the failures ever?
<kees> zul: I'd like to try reverting your ubuntu3 changes, and applying the upstream patch.
<zul> kees: it fails in different places locally never consistenly
<zul> kees: cool with me
<kees> alrighty, I'll give it a go.
<jdstrand_> soren: that's a really good idea. i've put it on my todo list. thanks!
<tseliot> slangasek: are you the archive admin today?
<soren> jdstrand_: I think dh_installudev will make a good template. If you decide to do it, don't forget to add it to cdbs as well.
<tseliot> slangasek: never mind, problem solved
<slangasek> tseliot: fwiw, the day assignments are documented on https://wiki.ubuntu.com/ArchiveAdministration
<tseliot> slangasek: ok thanks
<emgent> hello
 * Caesar sniggers at slangasek re #216990
<Caesar> Dude, that has just been a disaster from start to finish
<slangasek> :(
<slangasek> well, lesson learned, that's why pam-config-framework is done for intrepid
<Caesar> Cool
 * Caesar wishes he had more time to pay attention to Intrepid's dev cycle
<Caesar> Unfortunately we're still up to our eyeballs in Hardy deployment shenanigans
<slangasek> ah, you should be using update-manager --no-shenanigans
<slangasek> I don't know why we didn't make that the default
<slangasek> zul: samba 3.2.3-1 in the pipe, includes a security fix (intrepid-only); you're welcome to merge it if you notice it showing up on MoM before I do, or if you opt to do it by hand, or if you know a better way to merge without first waiting for MoM to see it :)
<slangasek> (mumble, need an Ubuntu VCS branch for that, mutter)
<zul> slangasek: cool on my todo list
<Caesar> slangasek: we don't do upgrades, we just reinstall
<Caesar> Cuts out a whole slew of problems
<slangasek> Caesar: oh, well in /that/ case, I guess --no-shenanigans won't help you ;)
<Caesar> :-)
<Caesar> Most of our shenanigans are self-inflicted
<jdstrand_> zul: are you doing that today? cause I've got the ufw integration bits I need to upload
<zul> jdstrand_: as soon as it appears on MoM ill probably do it
<jdstrand_> zul: then let me give you a debdiff when I'm done
<zul> jdstrand_: no problem
<BenC> Anyone know why I can't get any more than 2 workspaces when I have compiz enabled?
<BenC> Is there a way to reset (IOW purge) all compiz settings under gconf?
<Treenaks> BenC: gconftool-2 's recursive-unset feature should be able to do that
<Treenaks> BenC: (you can find the compiz-subtree using gconf-editor)
<BenC> Treenaks: thanks
<ion_> Which reminds me, i should write a tool that unsets all userâs gconf keys that match the system defaults, so that everything not specifically changed follows any package changes. Unless such a tool already exists, of course.
<BenC> ion_: you should just port gconf to use dpkg's conffile handling *snicker*
<ion_> :-)
<ion_> dpkgâs conffile handling could use some work itself. Perhaps iâll get around to that some year.
<BenC> ion_: there's userspace toolks to handle conffiles better now...can't recall the name of it
<ion_> benc: Btw, in case you didnât notice my recent message, i modified http://heh.fi/patches/grub/01-last-good-boot-update-delay (Sorry for the repetition if you did.)
<slangasek> BenC, ion_: ucf
<slangasek> which requires you to un-conffile it first, fwiw
<BenC> ion_: saw it, thanks
<slangasek> (and also badly needs to be integrated with dpkg instead of being a separate package, but it needs other fixes worse than that :)
<ion_> benc: Iâll try to remember that you do read all messages. Some people tend to miss messages sent when they were away. :-)
<slangasek> jdstrand_: were there other packages that provided auth-client-config profiles in hardy?
<slangasek> ah, ldap-auth-config
<jdstrand_> slangasek: yeah-- that and ecryptfs were the only two I knew off
<jdstrand_> of
<mathiaz> kees: did you make any progress with mysql ?
<slangasek> jdstrand_: ok.  Do you have an opinion on whether installing libpam-ldap alone should cause auto-configuration of the auth method going forward?  I'm inclined to think it should
<mathiaz> kees: apache2 fails to build because of this.
<slangasek> jdstrand_: given that, e.g., ldap-auth-config isn't in Debian currently
<mathiaz> slangasek: I've uploaded a new version libgems-ruby to intrepid a couple of hours ago. It created a new binary package, which is required by another package (passenger) I'd like to upload to the archive before FF. But as of now passenger doesn't build.
<slangasek> mathiaz: so you need a bit of new processing?
<mathiaz> slangasek: yop :)
<slangasek> ok, looking
<kees> mathiaz: yeah, I *finally* got the upstream patch working, and I will upload as soon as it finishes the current testing cycle
<kees> mathiaz: apache2> really?
<mathiaz> kees: yes - it requires libmysqlclient1.5-off to build
<kees> mathiaz: oh!
<kees> I thought you meant PIE broke it, which would have be interesting given my testing.  :P
<mathiaz> kees: http://launchpadlibrarian.net/17119738/buildlog_ubuntu-intrepid-amd64.apache2_2.2.9-3ubuntu2_FAILEDTOBUILD.txt.gz
<kees> mathiaz: yeah, lots of stuff needs mysql -- that's why I've spent all morning working on it.  :)
<mathiaz> kees: have you looked at the build failure for i386 ?
<mathiaz> kees: I can reproduce it, and it's always the same test that fails (subselect)
<kees> mathiaz: that's what this is supposed to fix.  oh!  well then I'll give you this debdiff -- I haven't been able to reproduce it.
<mathiaz> kees: are you  refering to http://bugs.mysql.com/bug.php?id=23921 ?
<kees> yeah
<mathiaz> kees: IIUC this would help in fixing the build failure for amd64
<mathiaz> kees: http://launchpadlibrarian.net/17097260/buildlog_ubuntu-intrepid-amd64.mysql-dfsg-5.0_5.0.67-0ubuntu3_FAILEDTOBUILD.txt.gz
<mathiaz> kees: http://launchpadlibrarian.net/17049756/buildlog_ubuntu-intrepid-amd64.mysql-dfsg-5.0_5.0.67-0ubuntu1_FAILEDTOBUILD.txt.gz
<kees> mathiaz: there wasn't a build failure for amd64.  :)  https://edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/5.0.67-0ubuntu2
<mathiaz> kees: ^^ these are failures in two differents tests
<kees> mathiaz: that's what the mysql upstream fix is supposed to fix -- the random failures being seeing due to timing.
<jdstrand_> slangasek: well, I have always had my reservations about that, but that is the point of your work :)
<kees> mathiaz: ubuntu1 failed only on amd64.  ubuntu2 only on i386, ubuntu3 only on amd64.
<slangasek> jdstrand_: well, it doesn't have to be auto-enabled, and it doesn't have to be in the package that provides the PAM module - it could be in any package that depends on the PAM module
<mathiaz> kees: ubuntu3 also failed on i386
<slangasek> jdstrand_: but I would think that people shouldn't install the libpam-ldap modle if they don't intend to use it
<mathiaz> kees: in the same test as ubuntu2
<mathiaz> kees: so it seems we're having two bugs.
<jdstrand_> slangasek: that could be said of most any software
<slangasek> I say it about most software :)
<jdstrand_> heh
<kees> mathiaz: hrm, that could be.  I'll get this debdiff to you to test on your failing i386
<mia33> lookin 4 cc numbrs
<mathiaz> kees: ok. I'll give it a try - I can reproduce the build failure on i386.
<kees> mathiaz: can you try building with: http://people.ubuntu.com/~kees/mysql-dfsg-5.0_5.0.67-0ubuntu4.debdiff
<slangasek> jdstrand_: the point is, we already have one toggle (package installed or not) that lets people specify their preference; why do we need a second one to declare whether to enable the module, instead of using that one?
<jdstrand_> slangasek: if we can safely enable it without breaking a local login, then I suppose that enabling it on install would be ok. that said, ldap-auth-config is really dendrobates thing (though I did quite a bit of packaging work), so I am not sure what his long term intentions are
<slangasek> (and, in fact, you can use pam-auth-update to disable the module again for testing)
<jdstrand_> slangasek: especially with your latest work
<slangasek> oh, ok
<slangasek> dendrobates: ping, then :)
<dendrobates> slangasek: yes
<slangasek> dendrobates: from above, wrt ldap-auth-config, do you see any reason that we shouldn't move the pam part of this down into libpam-ldap directly now that pam-config-framework is in?
<dendrobates> slangasek: seems like that would be the correct thing to do.
<slangasek> ok, I'll sneak that change in ahead of FF today then :)
<liw> I'm having trouble deciding how to treat system-cleaner's state file (contains state of packages the user has indicated should/should not be removed); should I treat it as a config file (i.e., not remove until purge), or as normal application data (remove when package is removed, not wait until purge)
<liw> opinions?
<pwnguin> well, given the goal is to reduce disk usage
<pwnguin> make that easy as possible ;)
<pwnguin> then again, I dont think I'd use the tool
<pwnguin> you should seek opinions from your users!
<slangasek> mathiaz: libgems-ruby accepted
<mathiaz> slangasek: thank you ! :)
<dendrobates> slangasek: so landscape-client is currently being reviewed by kees/jdstrand.   What other review do you want?  There is a empty package in main, and I don't want this to slip in unreviewed.
<slangasek> dendrobates: well, MIR is not really my department...
<slangasek> dendrobates: if it's gotten the security review, then that's the main thing for the MIR team, I think
<ogra> slangasek, but post MIR is your dept. right ?
 * ogra is about to add sshfs to ltsp-client and this to the cd
<slangasek> uhm, post-FF feature changes are my department
<ogra> *thus
<slangasek> to which CD?
<ogra> alternate
<ogra> its about 300k or so
<slangasek> and no new deps?
<slangasek> I guess we can spare 300K :)
<ogra> not afaik
<ogra> good :)
<ogra> MIR was approved but i'm late as usual with ltsp for FF
<dendrobates> slangasek: I want you to be aware that I am holing off on uploading this until the security review, so it doesn't slip into main.  This will mean a ffe.
<slangasek> dendrobates: sure; jdstrand_ talked to me about that yesterday already
<ogra> https://bugs.launchpad.net/ubuntu/+source/sshfs-fuse/+bug/254651 well, ubuntu-archive is you :)
<ubottu> Launchpad bug 254651 in sshfs-fuse "Main Inclusion Report" [Undecided,In progress]
 * ogra just noticed it was moved on
<ogra> YIPPIEEEE !!!!
 * ogra dnces
<ogra> *dances too :D
<ogra> finally ....
<ogra> took me the whole day to finally get hal-input working in ltsp
<persia> I'm well behind on backscroll, but if anyone is still trying to sort out the perl 5.10 and threads issue, there's a package on the RCbugs page that appears to be perl and threads and has a new upstream in Debian.
<kees> mathiaz: any love for the mysql build yet?
<mathiaz> kees: the test are currently running
<mathiaz> kees: I should have a answer in a few minutes
 * kees really hopes this works.
<mathiaz> kees: nope - the subselect test failed
<mathiaz> kees: I've search mysql bug tracker for reference about pie and subselect on i386, but nothing came out
<kees> mathiaz: well... that sucks.  let me see if I can reproduce here again...
<kees> mathiaz: are you running an intrepid kernel?
<kees> mathiaz: if so, are you seeing any segvs in dmesg for the server?
<mathiaz> kees: nope - I'm running sbuild on a hardy server
<kees> amd64?
<mathiaz> kees: yes
<kees> it should show i386 segvs too in hardy... nothing in dmesg?  (apport would ignore it since the test server isn't packaged)
<mathiaz> kees: that's the command I use to build mysql:  sbuild -A -d intrepid-i386 mysql-dfsg-5.0_5.0.67-0ubuntu4.dsc
 * kees nods
<mathiaz> kees: nothing
<kees> well, hopefully I can reproduce, but that this point, I'm leaning towards ripping out PIE and dealing with it in intrepid+1.
<kees> the "Lost connection to MySQL server" is ominous.
<jdstrand_> zul: debdiff in bug #261544 is ready for you
<ubottu> Launchpad bug 261544 in samba "Please add UFW profile integration with Samba" [Undecided,In progress] https://launchpad.net/bugs/261544
<jdstrand_> slangasek: I don't know if you or zul is preparing the samba upload, but if you do, can you incorporate ^^
<slangasek> jdstrand_: zul said the magic words "it's on my TODO list", so I was going to cede it to him :)
<jdstrand_> heh, fair enough :)
<ogra> slangasek, may i point you kindly to bug #262036 ?
<ubottu> Launchpad bug 262036 in ltspfs "please sync ltspfs 0.5.3-2 from debian unstable" [Undecided,New] https://launchpad.net/bugs/262036
<kees> [244640.179532] mysqld[11269]: segfault at 57aafec8 ip 55f220e0 sp 57aafe9c error 6 in libc-2.8.90.so[55ee4000+13d000]
<ion_> Those hex numbers translate to ASCII âSwitch to Postfixâ. ;-)
 * ion_ slaps himself
<ion_> Postgres, duh.
<kees> hehe.
<kees> actually, the "6" translates to: No page found (PF_PROT==0) | Write (PF_WRITE==1) | Userspace (PF_USER==1) | No reserved bit (PF_RSVD==0) | Regular memory access (PF_INSTR==0)
<tormod> slangasek: can you please take a look at bug 192772? either sync or merge is fine. I have given up on rtg.
<ubottu> Launchpad bug 192772 in linux-wlan-ng "please merge linux-wlan-ng 0.2.9+dfsg-1 from Debian main unstable" [Low,Fix committed] https://launchpad.net/bugs/192772
<ogra> tormod, hey
<tormod> ogra: hey
<ogra> tormod, not sure where tedg is at atm, i asked him for a xscreensaver package before feature freeze today but seems nothing happened, are your changes in debian ?
<ogra> (i assumed so)
<tormod> ogra: tedg promised me to do a 5.07, but he left IRC and I see nothing
<ogra> tormod, right, same here :/
<ogra> tormod, any intrest in becoming ubuntu developer ? :)
<tormod> ogra, basically I have prepared 5.07-1, but it's not released.
<tormod> ogra: interest yes, but I don't know about time :)
 * ogra would really like to see the screensaver situation in one hand in both distros ... 
#ubuntu-devel 2008-08-28
<tormod> ogra: I try to coordinate it, but I needs devs to follow up...
<ogra> yeah, i know what you mean
<ogra> i suck at sponsoring, sorry for that :(
<LaserJock>  /join #ubuntu-motu
<LaserJock> bah ;-)
<tormod> it's the same situation for linux-wlan-ng (see above). I prepare everything, and the debdiffs just rot in launchpad.
<tormod> LaserJock: the ideal situation would be to be sponsored without having to hang out in IRC and bug people :)
<ogra> yeah, indeed
<tormod> ogra: and that is really not the case today.
<ogra> tormod, well, in fact i think we're only talking the second time on IRC ... and i did at least some of your syncs/uploads
<ogra> IRC simply has the big advantage of being a lot speedier
<tormod> ogra: most of my uploads are only after asking someone on IRC, you must be the exception
<ogra> well, but then i'm always uploading last minute which isnt pleasant for either side either
<tormod> ogra: but the point is there shouldn't be any need for pinging, LP has the debdiff and u-m-s is subscribed.
<ogra> right
<ogra> LaserJock, btw did xaos happen ?
<ogra> i didnt follow that one
<tormod> xaos happened
<ogra> yay, good
 * ogra was pondering to finally take that in debian to get that darn .desktop file in 
<ogra> joey refused to take hat for years
<ogra> *that
<tormod> ogra: yeah he just ignored any request about it :)
<ogra> but you got it in now :)
 * ogra hugs tormod 
 * tormod hugs back
<ogra> ok, so what do we do with xss now ?
<ogra> wait for ted ?
<ogra> add a sync request ?
<tormod> if FF really is 00 UTC and not 23:59, I guess it's time to do something.
<ogra> i simply havent looked at the source since ted took over so i'm not even aware which ubuntu changes we have
 * ogra is massively busy getting the last ltsp bits sorted
<tormod> can we request a sync for a package that is not released? :)
<ogra> we can sync from experimantal
<ogra> if slangasek hanst a to long TODO list i guess
<ogra> *hasn't
<tormod> it's only in git so far, I can't upload in Debian neither.
<slangasek> er, pick on the archive admin on duty, not me :)
<ogra> oh, who is that today ?
 * ogra goes checking
<slangasek> tormod: surely there's a difference between syncing and merging for 192772, and they shouldn't both be "fine"?
<tormod> they both better than doing nothing
<slangasek> oh, I see, I commented on it and suggested a sync instead of a merge :)
<tormod> yeah and since then nobody did anything about it
<ogra> slangasek, meh, seb128 ?
<tormod> I would prefer a merge
<slangasek> tormod: right; merge looks better at the moment, I was hoping that someone would champion getting the description/recommends fixed in Debian
 * ogra sighs deeply ... so i can give up on ltsp as well then ... no ltspfs no ltsp
<tormod> it has so low priority...
 * lamont cries a little at the maintainer swap in the ubuntu upload of his package
<lamont> while understanding why it happens
<cjwatson> lamont: as is standard
<lamont> cjwatson: both the crying and the understanding?
<lamont> yeah
<cjwatson> :-)
<ogra> so is there a replacement for seb128 while he is on holiday ?
<lamont> ogra: I'm pretty sure he's irreplacable.
<ogra> i dont really wnat to trash my whole workday for a single sync that doesnt happen
<slangasek> well, not as such, no.
<slangasek> what sync are you waiting on?
<slangasek> something from experimental?
<ogra> ltspfs
<ogra> no
<ogra> bug #262036
<ubottu> Launchpad bug 262036 in ltspfs "please sync ltspfs 0.5.3-2 from debian unstable" [Undecided,Fix released] https://launchpad.net/bugs/262036
<tormod> slangasek: can I trust you do the lwlan upload?
<cjwatson> ogra: the one slangasek did an hour ago then? :)
<ogra> oh
<slangasek> haha
<ogra> *grin*
<ogra> sorry
<ogra> the other one was tormod's request for xscreensaver
<slangasek> yeah, experimental ones would take me a lot longer, I never remember the commandline opts
 * TheMuso suggests ogra track intrepid-changes. :p
<ogra> TheMuso, i'm in massive-stress-get-ltsp-in-before-FF mode :)
<TheMuso> hehehe
<cjwatson> echo NUM -S experimental | syncbugbot
<cjwatson> OBVIOUSLY
<slangasek> :-)
<Mizutsuki> hiya, all.  I've got a bug I really want looked at, is there anything any of you can do or anything I can do that will increase the odds of the bug getting developer attention?
<slangasek> tormod: yes
<tormod> Mizutsuki: try to get it confirmed by other users, and get it triaged (ask in #ubuntu-bugs about that)
<tormod> slangasek: thanks a lot!
<Mizutsuki> tormod: it's been confirmed by 3 other users, and no one is talking in #ubuntu-bugs, how do I get it triaged?
<tormod> Mizutsuki: well you can ask there even if nobody is talking at the moment
<Mizutsuki> tormod: sorry, I was inspecific, no one was talking to *me*, no one replied to my query
<Mizutsuki> tormod: oh, wait, there it goes
<Mizutsuki> patience!
 * calc wants food, but his wife disappeared with his car and i don't want to make a large meal :-\
<lukehasnoname> walk to Burger King
<lukehasnoname> that way you earn it
<calc> i left it at my parents because its not safe to ride it around here
<ogra> calc, cycle *fast* :)
<calc> lukehasnoname: houston, tx, usa
<calc> ogra: hahaha :)
<lukehasnoname> calc, me too. You live on Nasa Rd 1?
<NCommander> calc, order a pizza
<cjwatson> 7 lane ... 45mph. does not compute
<calc> NCommander: oh yea that could work
<NCommander> cjwatson, sounds faster then NYC's cross-bronx expressway
<calc> cjwatson: its just a normal road, not a highway
<NCommander> A seven lane normal road?
<calc> its 3 lane each way and a middle turn lane
<NCommander> Where the heck do you live?
<calc> NCommander: see above (Houston)
<NCommander> ah
<calc> we have mass transit (just buses) but its not so great
<cjwatson> calc: I can't think of many three-lane-each-way "normal roads" over here that aren't at least A roads and defaulting to 70mph
 * NCommander lives out in Rocheseter, NY
<calc> freeways (highways) around here tend to be 9-11 lanes total and 65mph
<NCommander> calc, do you have an i386 or and amd64?
<NCommander> Or other?
<calc> both sorta
<calc> a core 2 duo desktop running amd64 and a core 2 duo laptop running i386
<calc> the laptop is running i386 since it won't resume on amd64
<calc> oh and another amd64 running *cough* windows xp (my wife's machine)
<slangasek> dendrobates: why is there a dependency loop ldap-auth-config -> ldap-auth-client -> libpam-ldap ? :)
<calc> i've converted her to all open source software except Photoshop
<calc> too bad CS3 doesn't run well under wine yet
<calc> well and then all her plugins on top of that :\
<dendrobates> slangasek: hmm, let me look, I don't recall that.
<cjwatson> james_w: so bzr-builddeb 2.0 branch == package version 1.0?
<cjwatson> james_w: are you going to want this in Debian experimental (unstable?) anyway? if so it might be easiest for me to upload to Debian and then sync
<james_w> cjwatson: yes, I'd like it in experimental. I'd like that to not make it more difficult for Intrepid though.
 * lamont heads off to back-to-school night. 
<james_w> cjwatson: it should be package version 2.0, maybe the breakage meant that you have an older revision.
<cjwatson> definitely http://bzr.debian.org/pkg-bazaar/bzr-builddeb/trunk/ ?
<cjwatson> I have revision 258
<james_w> yeah, it seems that bug has left the branch at an arbitrary revision.
<james_w> it should be correct now
 * TheMuso manages to get the main pieces of alsa in before FF. Yay! Now for plugins...
<zul> jdstrand_: this patch http://launchpadlibrarian.net/17125350/samba_3.2.1-1ubuntu6.debdiff ?
<cjwatson> james_w: ok, just upgrading my Debian chroot
<ogra> hrm, wher is my accepted mail for the last upload
<ogra> slangasek, did you flick the switch already?
<slangasek> ogra: FF isn't a physical switch
<slangasek> ... or even a software switch :)
<ogra> :)
<ogra> Date: Thu, 28 Aug 2008 01:51:56 +0200
<ogra> Source: ltsp
<ogra> geez
<ogra> why did it take 9 mins ... that tested my nerves
<ogra> :)
<zul> slangasek: just doing a testbuild of samba-3.2.3 locally first
 * ogra is relaxing again ... all done phew
<cjwatson> james_w: should I install bzr 1.6 in the chroot? I notice you don't seem to build-depend on it
<cjwatson> hmm, let me put that a different way. do I *need* to install bzr 1.6 in the chroot?
<james_w> no, I don't think I use any 1.6 specific stuff in this version
<cjwatson> ok
<cjwatson> ogra: the cron job is 0-50/5; the 55 slot is used for security uploads
<cjwatson> ogra: so an upload at :51 would wait nine minutes or so for processing, but would still be safe to get into the :03 publisher run
<ogra> cjwatson, heh, well, i survived it :)
 * ogra parties to have it managed in time :)
<kees> d'oh *hand+face*  sync wasn't fast enough.  ;)
<kees> I'll work it out.
<slangasek> jdstrand_: I think auth-client-config needs to be changed to not touch /etc/pam.d/common-* anymore too, yes?
<cjwatson> james_w: bzr-builddeb 2.0 uploaded to Debian experimental and synced to intrepid; all looks good enough
<james_w> cjwatson: great, thanks.
<james_w> "good enough", was there anything you noticed that I should fix?
<cjwatson> few lintian bits and bobs
<cjwatson> one selftest failed with bzr 1.5
<cjwatson> FAIL: bzrlib.plugins.builddeb.tests.test_import_dsc.DistributionBranchTests.test_sync_to_other_branch
<cjwatson>     not equal:
<cjwatson> a = ['cjwatson@sarantium-20080828002443-9uuqywufj7px33w7',
<cjwatson>  'cjwatson@sarantium-20080828002442-g2jcltja25pdgb0n',
<cjwatson>  'cjwatson@sarantium-20080828002444-xol3l3lm46kanotn']
<cjwatson> b = ['cjwatson@sarantium-20080828002443-9uuqywufj7px33w7',
<cjwatson>  'cjwatson@sarantium-20080828002444-xol3l3lm46kanotn']
<james_w> that's supposed to be XFAIL, I don't know why you got a failure
<slangasek> hmm, and tormod is off, and the proposed merge of linux-wlan-ng is no longer valid due to archive drift :/
<StevenK> cjwatson: It failed due to other reasons on my machine, and I didn't persue it due to impending FF.
<qwerty6523> hi
<qwerty6523> hello
<NCommander> Argh, why does every one of my email to ubuntu-devel require moderator approval!
<soren> NCommander: Because you're not a member of ubuntu-dev, I think.
<NCommander> I should be subscribed
<Adri2000> aren't all @ubuntu.com whitelisted?
<Adri2000> NCommander: that is not enough
<soren> Open to all to subscribe, posting moderated for non-developers
<NCommander> I don't have an @ubuntu.com ;-)
<soren> @ubuntu.com is all members, so I presume it's more limited than that.
<Adri2000> NCommander: maybe you can get someone to whitelist your address then :)
 * NCommander wishes he was a UUC :-P
<NCommander> I want the shiny @ubuntu.com email
<NCommander> hrm
<NCommander> I need an Ubuntu i386 box
<NCommander> soren, ubuntu-vm-builder doesn't recongize intrepid as a distro
<TheMuso> NCommander: Are you using intrepid's ubuntu-vmbuilder?
<NCommander> yeah
<TheMuso> ok just checking. :)
<soren> NCommander: I'm aware.
<bytor4232> Wow.  rtorrent is a pretty cool torrent client.
<NCommander> I'm trying to murder a FTBFS involving mysql on i386
<NCommander> (and inconsistently on amd64)
<soren> NCommander: It'll be replaced quite soon.
<bytor4232> wops. Sorry guys, wrong channel.
 * NCommander hopes a chroot works then
<nxvl> NCommander: that FTBFS is just a failure on the sleep in the tests
<nxvl> NCommander: or something like that
<nxvl> it fails on random tests
<NCommander> No
<nxvl> not always on the same
<NCommander> On i386 it always does
<NCommander> Same test
<NCommander> Four times
<nxvl> NCommander: on my machine it fails in a different one than LP
<NCommander> I'm trying to determine if its just the same bug however
<NCommander> Yeah
<NCommander> I think its the same bug, just not 100% sure
<NCommander> OH YES
<NCommander> it uses dpatch
<NCommander> THANK YOU MYSQL PACKAGERS
<nxvl> dpatch is kewl
<NCommander> I can't find the mysql bug about that though
<NCommander> nxvl, quick googling help please?
<nxvl> NCommander: it's not, ping zul or mathiaz on that
<nxvl> NCommander: they have been working on the bug
<NCommander> There was already a prewritten patch for that bug
<NCommander> It was fixed in 5.1
<mathiaz> NCommander: 5.0.67-0ubuntu4 should fix the problem - it's currently building and should be available in the archive within a few hours
<NCommander> mathiaz, ok, good
<NCommander> You creeped out StevenK with the weird behavior. Its the first time any of us saw something build on hppa, and fail miserably on amd64/i386 :-)
 * nxvl doesn't remember for what rebuild was waiting for mysql
<mathiaz> nxvl: apache2 failed to build
<nxvl> mathiaz: but that's in main
<nxvl> got it, it was courier
<[gnubie]> anyone knows how to set gcc-4.1 as the default gcc version as opposed to gcc-4.2 on ubuntu-8.0.4.1?
<calc> [gnubie]: just change the symlink?
<[gnubie]> calc: is that all?
<[gnubie]> i mean, will it inherit the rest of the components for gcc-4.1?
<slangasek> [gnubie]: the compiler, when invoked, has its own internal path that it uses to find the other components; not that I really recommend this, since /usr/bin/gcc is part of a package and changing the symlink isn't going to be persistent across package upgrades (if they're needed for some odd reason)
<slangasek> [gnubie]: why do you want to change the default compiler?
<calc> oh yea if you are changing it for packaging reasons then changing the symlink is not a good idea
 * calc wonders why gcc isn't in alternatives
 * calc notes he misread what slangasek said wrt package
<slangasek> it isn't in alternatives because this isn't meant to be a user-selectable *choice*; the version of gcc that "gcc" points to on the system is meant to be something that other packages can rely on
<slangasek> i.e., it's supposed to point to the one that works
<calc> wouldn't they all work, or are there abi issues?
<calc> i know for g++ that has in the past often broken abi
<slangasek> calc: if they all "worked", we wouldn't need more than one in the first place... )
<calc> well newer ones are more strict and so don't work for some definition of work ;-)
<[gnubie]> i'm rebuilding asterisk to .deb package. everytime i make a call, i hear a choppy/robot sound. i asked google and says it is because of using gcc-4.2
<calc> but yea i defer to you knowing more about what compilers work, i don't mess with the defaults
<calc> i just know for other things like java it doesn't seem to much matter so its changeable
<calc> [gnubie]: there is at least one really easy hackish way to fix it
<calc> create a dir, symlink in that dir gcc to whatever gcc you want
<[gnubie]> i just want to build the asterisk related packages using < gcc-4.2
<calc> and then add that dir to the path
<calc> er just while building
<slangasek> we end up shipping multiple versions of gcc because each of them have different bugs, so people need to be able to pick their bugs for that reason; but the set of bugs we get with "gcc" is meant to be stable
<tedg> Can other folks get to "packages.debian.org"?
<calc> tedg: no
<slangasek> [gnubie]: do you happen to have a link to a more detailed explanation of why gcc-4.2 is the problem?
<calc> tedg: or its really really slow
<slangasek> [gnubie]: anyway, for a one-time build, any of the above methods work :)
<calc> ccache does the dir in the path trick
<[gnubie]> slangasek: i'll check out the exact url for you.. but i also asked #asterisk that it is also because when using gcc-4.2
<[gnubie]> here is one => http://bugs.digium.com/view.php?id=11243
<[gnubie]> i both have gcc-4.2 and gcc-4.1 installed on my ubuntu-8.0.4.1-server system
<tedg> calc: I've got it now...  took a little while.
<tedg> So the diffstat between xscreensaver 5.05 and 5.07: 731 files changed, 21620 insertions(+), 17376 deletions(-)
<calc> hmm the list looks like they use bad optimization numbers
<calc> "In 1.2.26 if you change "OPTIMIZE+=-O6" in the Makefile to "OPTIMIZE+=-O2" everything sounds fine."
<calc> iirc over O2 is not really recommended
<bryce> tedg: tormod was looking for you earlier
 * [gnubie] waves again..
<[gnubie]> sorry, i was disconnected.. my X freezes again.. :(
<tedg> bryce: Ah, it'd be nice to see him too -- the 5.07 seems a little crazy.
<tedg> I guess we're still "alpha" though.
<soren> If an archive admin could apply a bit of NEW love to vm-builder, that'd be lovely. Now, if you will excuse, I'm going to pass out.
<NCommander> StevenK, ping
<StevenK> NCommander?
<NCommander> StevenK, can you sponsor an upload into main for me
<NCommander> FTBFS fix
<NCommander> Already merged ont the ubuntu-desktop branch
<StevenK> NCommander: I suppose so, if you don't mind waiting a little while?
<NCommander> no problem
<NCommander> I'm currently hunting bugs in qt
 * StevenK is plotting buying lunch, since my stomach is threatning to run off to do the job itself
 * NCommander had a similar plan ;-)
<StevenK> And mysql-dfsg-5.0 FTBFS on amd64. Dear.
<NCommander> StevenK, I crashed the PPA build server last night on mysql :-)
<StevenK> NCommander: Twice.
<NCommander> Damn evil package
<StevenK> NCommander: I got elmo to fix it the first time.
<NCommander> I only built it once O_o;
<NCommander> it did build on AMD64
<StevenK> It will get requeued, and did.
<NCommander> impressive
<NCommander> I've never crashed a build server for
<NCommander> elmo probably wants to murder me
<LaserJock> NCommander: it didn't FTBFS on your machine?
<NCommander> I run AMD64 and nope
<NCommander> I only have a debian i386 machine
<NCommander> LaserJock, can you build and see if its FTBFS on subselect for you?
<NCommander> the AMD64 may be a transition failure since it did build on the PPA server
<ScottK> Surely because mysql is using Launchpad now all the great collaboration that enables will make this easy to solve.
<ScottK> Sorry.  Couldn't help it.
<NCommander> rofl
<LaserJock> ScottK: well, obviously it's because we're using those deprecated things called source packages ;-p
<LaserJock> fascinating, nautilus crashes on my ~/Documents every time
<NCommander> LaserJock, it could be worse, It could be gcl
<lifeless> or gch
<lifeless> sorry, ghc
<NCommander> gcl has a wonderful 70MB diff :-)
<lifeless> oh
<lifeless> WTF
<LaserJock> NCommander: you wouldn't mind merging a new gcl would you ? :-)
<NCommander> Ahem
<ajmitch> I think most of us said something along those lines when hearing of that diff
<NCommander> That's FROM debian the 70MB
 * LaserJock watches NCommander twitch in the corner
<NCommander> No patch system
<NCommander> All changes inline
<NCommander> The entire source code of configure * 10 + bintuil 2.8.16
<NCommander> (this is not a joke)
<LaserJock> bah, patch systems are for the weak!
<NCommander> Seriously
<RAOF_> That still doesn't sound like 70mb worth of diff, though?  Where's the rest?
<pwnguin> probably in .CVS files
<LaserJock> pwnguin: maybe RCS/ ?
<RAOF_> Heh.  Of course.
<NCommander> RAOF_, binutils is 40MB alove
<NCommander> *alone
<NCommander> its 70 uncompressed
<NCommander> 15 compressed
<RAOF_> Really?  Wow.
<NCommander> yeah
<NCommander> We have a FTBFS caused by changes in gcl
<NCommander> wgrant took off screaming
<pwnguin> heh
<NCommander> I broke the language rules in -motu
<NCommander> And someone else just went WTF
<pwnguin> i dont even get why there are language rules
<NCommander> And that was it
<NCommander> LaserJock, your a core-dev, please upload my FTBFS fix ;-)
<pwnguin> then again, I have like the 20th quote on bash.org so i may be culturally biased
<NCommander> I have a few quotes on bash.org
<NCommander> where was the #ubuntu-* quote database
 * LaserJock hopes he's not on bash.org
<LaserJock> NCommander: despite being a core-dev I'm already waaay over my alloted *buntu hours for the day, sorry
<LaserJock> I've got a paper draft due ASAP
<wgrant> NCommander: Argh, you're a top-poster.
<pwnguin> heh
<NCommander> damn
<NCommander> THat's what I get for using webmail
<pwnguin> psh
<pwnguin> we just need better threading clients and quote detection
<pwnguin> im told thunderbird has it
<RAOF_> NCommander: There's a "better gmail" firefox extension that changes their broken top-posting default :)
<NCommander> I use gmail almost constantly
<pwnguin> even then, you're supposed to quote only what you reply to
<NCommander> It hasn't done that to me in a LOG time
<NCommander> er
<NCommander> LONG
<pwnguin> you might want to ask upstream about this do away with gems thing
<NCommander> Getting rid of gems completely is a bad idea also
<NCommander> pwnguin, BTW, you a core dev?
<pwnguin> no
<NCommander> bah
<NCommander> StevenK, are you back yet ;-)
<StevenK> NCommander: Er, yes. Sorry.
<NCommander> NP
<NCommander> StevenK, https://bugs.edge.launchpad.net/ubuntu/+source/notification-daemon/+bug/262079
<ubottu> Launchpad bug 262079 in notification-daemon "Patch for FTBFS bug on notification-daemon" [High,Confirmed]
<StevenK> NCommander: notification-daemon is maintained in bzr.
<NCommander> StevenK, the patch was already merged int
<NCommander> *in
<NCommander> But the person who merged it was not a core-dev
<StevenK> NCommander: Ah, coll
<StevenK> Er, s/ol/oo/
<NCommander> cooll? ;-)
<NCommander> Oh
<NCommander> wait
<NCommander> regex failure
<RAOF> You fail at finite-state-machining.
<RAOF> :)
<StevenK> Haha
<NCommander> Crap
 * NCommander reinstalls apt-get install fsm
<StevenK> NCommander: there So.
<NCommander> uploaded?
<StevenK> s/\(\w+\) \(\w+\)\./\2 \1/
<NCommander> o_o;
<RAOF> Ooh, backreferences.  No longer regular!
 * NCommander gives StevenK some fiber to help with his irregularities
 * NCommander runs
<pwnguin> i have to wonder
<StevenK> NCommander: notification-daemon also has debian/control.in
<pwnguin> why is there PEAR, CPAN, gems, etc
<NCommander> the control file wasn't modified
<NCommander> Just rules and changelog
<StevenK> Yes it was.
<NCommander> ?
<NCommander> I didn't change it
<NCommander> argh
<StevenK> % diffstat < notification_daemon_ftbfs.debdiff | grep control
<StevenK>  notification-daemon-0.3.7/debian/control   |    2 +-
<NCommander> Oh
<NCommander> whoops
<NCommander> I did change it
<NCommander> I bumped the standards version
<StevenK> Naughty
<StevenK> I think that's a pointless change for fixing the FTBFS
<NCommander> Well, that got merged into the bazaar branch >.>;
<NCommander> whoops
<LaserJock> pwnguin: people had to figure out how to install stuff on slackware? :-)
 * ScottK smacks NCommander in the head with a cold, wet, dead fish to help him remeber for next time.
 * NCommander hits ScottK with GNOME
<NCommander> Nothing like sending GNOMEs into space
<StevenK> NCommander: So, drop the control change, or what?
<ScottK> Fortunately it's well established that I'm impervious to Gnome.
<NCommander> I sent a gnome into space in Half-Life 2 a few weeks ago
 * NCommander stabs ScottK with an xfce ax
<NCommander> StevenK, can you fix the patch for me?
<StevenK> NCommander: To not patch control?
<NCommander> or I can roll a new one
<NCommander> yeah
<NCommander> And zap the changelog entry
<NCommander> I'll grab seb128 in the morning to pop that change from the bazaar repo and properly fix it
<NCommander> (its already been merged so there isn't much I can do about it)
 * StevenK introduces NCommander to filterdiff
<NCommander> what's filterdiff?
<NCommander> ack
<NCommander> regex
<NCommander> EW
<StevenK> Sigh. Learn regular expressions, will ya?
<StevenK> :-P
<NCommander> I can use regex
<NCommander> I just can't memorize them
<StevenK> % filterdiff -x '*/control' < notification_daemon_ftbfs.debdiff | lsdiff
<StevenK> That's a shell glob, anyway
<NCommander> Doesn't fix the changelog :-P
<NCommander> I'll properly reroll the diff
<StevenK> Fix the changelog how?
<StevenK> Oh right, dropped that line.
<NCommander> I noted in the changelog I bumped the standards version
<StevenK> NCommander: http://wedontsleep.org/~steven/changes.debdiff
<NCommander> Looks good
 * StevenK test builds
<NCommander> StevenK, BTW, you'll find this amusing: http://savannah.gnu.org/project/memberlist.php?group=hurd
<NCommander> Probably explains my love of pain
<NCommander> (thats the list of commiters for GNU hurd)
<LaserJock> NCommander: I once tried to get gcl working ... ;-)
<NCommander> Even I have my limits of pain
<NCommander> I wonder if lisp is on the shoot your self in the foot language list
<NCommander> Lisp
<NCommander>     You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...
<NCommander> Sounds about right
<StevenK> NCommander: What's the link to that list?
<NCommander> http://www-users.cs.york.ac.uk/susan/joke/foot.htm
<NCommander> I think I've used at least 90 percent of these
<NCommander> rofl on the 370 JCL one
<NCommander> (I've never used it, but I've worked with old foges who has)
<NCommander> I appericate teh Ada ones: The Department of Defense shoots you in the foot after offering you a blindfold and a last cigarette.
<StevenK> "You hear a gunshot and there's a hole in your foot, but you don't remember enough linear algebra to understand what happened."
<StevenK> NCommander: I have a C vs C++ one in my .signature
<StevenK> C offers you enough rope to hang yourself.
<StevenK> C++ offers a fully equipped firing squad, a last cigarette and a blindfold.
<NCommander> I greatly appericate the perl one
<NCommander> Ruby
<NCommander> Your foot is ready to be shot in roughly five minutes, but you just canât find anywhere to shoot it.
<NCommander> :-)
<pwnguin> im glad ocaml doesn't let you shoot feet ;)
<NCommander>     You shoot yourself in the foot, but can unshoot yourself with add-on software.
<NCommander> Things we need for Ubuntu ^
<NCommander> Paradox: Not only can you shoot yourself in the foot, your users can too
<NCommander> Woo!
<NCommander> Sounds like Vista
<ion_> *plop* Are you sure you want to shoot yourself in the foot? *plop* Are you sure you want to shoot yourself in the foot? *plop* Are you sure you want to shoot yourself in the foot? *plop* Are you sure you want to shoot yourself in the foot? *plop* Are you sure you want to shoot yourself in the foot?
<NCommander> UGH
<NCommander> PICK
<NCommander> AHHHH
<NCommander> TAKE IT AWAY
<NCommander> MAKE THE BAD MAN STOP
 * NCommander has touched a PICK system
 * LaserJock wonders if Debian would have a debconf question asking which type of weapon you'd like to shoot yourself with
<ion_> It looks like youâre shooting yourself in the foot. âClippy
<NCommander> We should add that to hello
<NCommander> StevenK, how goes the upload?
<StevenK> NCommander: You distracted me.
<NCommander> StevenK, sweet. Maybe we should however properly change the stands version
<NCommander> ...
<NCommander> *shot*
 * NCommander undistracts StevenK 
 * StevenK waits
<ScottK> LaserJock: Debian would have 12 different binary packages for the bindings to the different weapons so you could pick each up efficiently in it's own special way.
<NCommander> StevenK, for what
<StevenK> NCommander: For you to notice.
<LaserJock> Depends: .45 | .357 | 9mm
 * NCommander wonders if he's been added to the canonical quotes page
<LaserJock> Recommends: powder
<LaserJock> Suggests: pistol ( >= 1900)
<NCommander> How about the next REVU day someone packages shot, I'll package pistol, and you package hole
<StevenK> Suggests: hollow-point-bullet | bullet
<NCommander> shit
<NCommander> WTF have I done
<LaserJock> !language > NCommander
 * NCommander enjoys his Dvorak keyboard while you argue about shooting yourselves in the foot
<ubottu> NCommander, please see my private message
<ion_> Free software: you shoot yourself in the foot, but the gun is community-developed with public specs.
<NCommander> No
 * [gnubie] waves.. gtg now.. thanks..
<NCommander> FSF Revolution OS: You want to shoot yourself in the foot, but the kernel will be done "real soon now"
<NCommander> StevenK, still distracted?
<StevenK> NCommander: Hm? I uploaded it, what else do you want? :-)
<RAOF> NCommander: But at least the gun will be both free and highly modular.
<NCommander> StevenK, you did?
<NCommander> Sweet
<NCommander> autotools
<StevenK> NCommander: [15:26] < StevenK> NCommander: For you to notice.
<ion_> The gun consists of independent parts that talk to each other over sockets for security and stability, and it will be done any time now.
<NCommander> You can't avoid shooting yourself in the foot
<RAOF> NCommander: Not really.  You _can_ avoid shooting yourself in the foot, but it's rather like a forbidden temple, but with arrays of guns rather than the more traditional blow darts.
<NCommander> meh
<NCommander> COnsidering at some point people started handing me libtool issues
<NCommander> "Only the ancient guru can tell you how to shoot yourself in the foot"
<RAOF> You merely need to be a famous explorer to avoid being shot in the foot.
 * NCommander hits StevenK with a libtool missile
<NCommander> man
<NCommander> Its scary how many packages depend on mysql
 * StevenK resists
 * NCommander wields his +7 autotools mastery lance
 * NCommander rolls a d20
 * RAOF can bring a dicebot ot make these rolls more interesting :)
<NCommander> Ubuntu D&D
<NCommander> That's what we should do during the hard freeze
<StevenK> You need to roll at least a 16 from 4d6 to upload?
<RAOF> No, that'd be HERO
<RAOF> !skill 8-
<ubottu> Sorry, I don't know anything about skill 8-
<NCommander> !skill dice
<ubottu> Sorry, I don't know anything about skill dice
<RAOF> ubottu, why aren't you joybot?  It would understand me :(
<NCommander> !help
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
<NCommander> !joke
<ubottu> You might think your joke is funny, but you may confuse new users who follow your advice or irritate people who attempt to answer your question.
<NCommander> o_o;
<NCommander> I just wanted a random joke
<dholbach> good morning
<NCommander> morning dholbach
<dholbach>  hi NCommander
<NCommander> So, a new name for the next release is coming soon
<ion_> nin
 * NCommander wants Jacking Jackrabbits
<StevenK> I am not uploading to a release called 'jacking'
<NCommander> rofl
 * RAOF is sad we missed a perfect opportunity to use iguanas.  Iguanas are cool.
<NCommander> Jazzing
<StevenK> Or 'jazzing'
 * ScottK was in favor of the Iguanas too.
<NCommander> Jazzing Jackrabbits
<RAOF> NCommander: Sure you're not thinking of the parallax-scrolling platformers?
<NCommander> lol
<NCommander> I hope when we get to P we can use Phoenix
<NCommander> Posthumous Phoenix
<NCommander> eer
<NCommander> wait
<RAOF> NCommander: You do realise you appologised for top posting in a top-post? :)
<NCommander> whoops
<NCommander> goddamn it Google
<ScottK> It's recursion.
<RAOF> NCommander: Get extensions->better gmail.  :)
 * NCommander looks
 * NCommander installs
<NCommander> neat
<NCommander> wow
<NCommander> Damn
<NCommander> I love firefox extensons
<NCommander> Its sad that you need a BS in just about anything in the tech field to get a tech job
 * LaserJock is happy with his BA in a non-tech field
<cjwatson> NCommander: I added an explicit note to Ubuntu policy saying that you should not modify Standards-Version in Ubuntu uploads of packages originating in Debian, BTW
<NCommander> Ok
<NCommander> must have missed that
<LaserJock> cjwatson: btw, has it decided whether to make an ubuntu-policy package or to just diverge debian-policy?
<cjwatson> LaserJock: I understand the former, just haven't done it yet
 * NCommander debating on lunch
<StevenK> NCommander: Isn't it like 1am?
<NCommander> 2
<NCommander> LIfe with a sleep disorder
<NCommander> woo
<StevenK> cjwatson: antimony is mostly cleaned up -- davidm requested I keep the images aside, and we discussed it, and decided they could die.
<cjwatson> ok, thanks
<StevenK> cjwatson: There's one more directory, but davidm disappeared before I could ask. It will get sorted out my tonight
<tjaalton> hum, i should try harder not to highlight *timo* :)
<NCommander> StevenK, how's the space issues on antimony
<StevenK> There's space issues on antimony?
<NCommander> I thought there were
<NCommander> Maybe I'm just not caffienated enough
<StevenK> cjwatson: There is?
<cjwatson> we're a bit better off now
<cjwatson> 240GB free or so
<NCommander> I should be doing bug work
<NCommander> Ah
<NCommander> That was weird
<RAOF> You decided to try out nouveau, and found it supported enough 3d to make Elisa work?
<NCommander> No
<NCommander> Guy wanted to wash his cloths through a car wash went I went to the gas station
 * NCommander is debating porting prime95 to x86_64
<NCommander> been itched for an opportunity to learn x86_64 ASM
<RAOF> Surely it's not much different from IA32?
<NCommander> RAOF, in some respects it isn't
<NCommander> In others it is
<NCommander> And *puke*
<RAOF> ?
<NCommander> It uses RAW SSE instructions
<NCommander> Christ
<NCommander> I like pain, but thats pushing it into the gcl level
<NCommander> RAOF, know any good bugs I can help fix?
<ion_> #1
<RAOF> Not really.  Not offhand.
<dholbach> http://daniel.holba.ch/harvest has a new look! thanks bdrung!
<dholbach> if a package uses lzma compression and ships udeb packages, do they need to pre-depends on dpkg (>= 1.14.12ubuntu3) too?
<dholbach> (just not sure if the lzma compression affects udeb packages as well
<dholbach> I just had a rejected upload with 3 warnings from soyuz regarding the lzma thing, I fixed one occurrence, there are two udebs left now - do I put the pre-depends there too?
<slangasek> I think you'll need to fix the udebs to not use lzma compression, because there's no lzma-udeb
<dholbach> hrm
<dholbach> ArneGoetje: ^ do you think you can look into this? I'll back out the lzma change for now
<cjwatson> I agree
<cjwatson> udebs aren't unpacked with dpkg (mostly), they're unpacked with udpkg
 * NCommander takes a chainsaw to the backports queue
<matiit> Hi, i have one ask... In Ubuntu 8.10 You are planning to release "Exit strategy"... Will it be a mainstream patches added to gnome 2.24 or a ubuntu-only thing?
 * soren glances at https://edge.launchpad.net/ubuntu/intrepid/+queue and sends the archive admins a thought
<NCommander> soren, damn
<NCommander> It was over 100 though this afternoon
 * NCommander confirms another backport :-)
<soren> Cool.
<NCommander> Since there are no major bugs that I'm good at fixing, I'm attacking the massive buildup of hardy backports
<NCommander> (the queue is over 100 for wanted backports so I'm working them in batchs)
<NCommander> soren, BTW, ubuntu-vm-builder seems broken in Intrepid; I get LIBVIRT unbound variable
<soren> 01:39:13 < soren> NCommander: I'm aware.
<soren> 01:39:33 < soren> NCommander: It'll be replaced quite soon.
<NCommander> Oh
<soren> :)
<NCommander> On that
<NCommander> I meant it didn't recongize intrepid as a dist
<soren> I know.
<NCommander> Now I'm saying it just doesn't work on intrepid
<NCommander> :-)
<soren> Don't make me cut'n'paste those lines again.
 * NCommander hides
<NCommander> So how goes your night/day/whenver soren ?
<soren> NCommander: HEre's a hint: http://launchpadlibrarian.net/17131990/vm-builder_0.8_source.changes
<NCommander> haw
<NCommander> awesome
<soren> NCommander: Sort of just getting started here. I was up till 6 in the morning.
 * NCommander kisses the ground soren walks on for writing such a handy tool
<soren> Heh :)
<NCommander> woot
<NCommander> cmake is backportable without changes
<NCommander> (2.4 is a freaking antique)
<matiit> NCommander: In Ubuntu 8.10 You are planning to release "Exit strategy"... Will it be a mainstream patches added to gnome 2.24 or a ubuntu-only thing?
<NCommander> Exit Strategy?
<NCommander> Is that the unified dialog box?
<matiit> https://wiki.ubuntu.com/DesktopTeam/Specs/ExitStrategy
<matiit> NCommander: ^
<NCommander> It's likely going to be Ubuntu-only
<NCommander> We're likely going to use the SuSE patch
<wgrant> Those look like mpt drawings.
<matiit> but will be possible to get it running on Arch?
<matiit> NCommander: ^
<NCommander> Arch?
<NCommander> Like ArchLinux?
<matiit> NCommander: ArchLinux
<matiit> ya
<NCommander> Last I check its still not implemented in Ubuntu
<NCommander> I don't run GNOME anymore, and Xfce still using the six button switchboard
<NCommander> It should be possible to find the patch from SuSE (I think the source package is gnome-session), and then applying it to the archbuild script
<NCommander> But I don't know about archlinux to give you specifics
<matiit> ok
<matiit> But ubuntu wiil not provide own patches?
<matiit> NCommander: ^
<NCommander> I don't know
<NCommander> Please ask a member of the desktop team
<matiit> NCommander: what's channel
<NCommander> #ubuntu-desktop
<matiit> thx
<MacSlow> asac, since which 3.0 release of ff they support the theora/vorbis-based video-tag?
<asac> MacSlow: 3.0 ... no release; 3.1 is where that is currently being worked on.
<asac> MacSlow: if you want to try, we have builds i think
<MacSlow> asac, ah ... so the video-tag support hasn't officially shipped yet ... I guess I remembered blizzards remarks from GUADEC wrongly then ... thanks for the heads up!
<asac> MacSlow: yeah. thats still alpha stuff. but should progress quick
<emgent> gmoin
 * ogra wonders if cjwatson is awake already
<verwilst> easy question
<verwilst> how do i list the files that are inside a .deb?
<ogra> dpkg -c
<verwilst> hm
<ogra> or --content
 * verwilst re-reads the manual
<verwilst> ah yes, in the small-print ;)
<verwilst> hm, i have created a new subpackage in control and rules
<verwilst> how do i build only that one?
<verwilst> instead of a full dpkg-buildpackage?
<liw> verwilst, it's not necessarily possible, depends on how debian/rules is written
<verwilst> oh
<cjwatson> ogra: I've been awake since 7 or something, but was feeling ill and went back to bed. Sort of back now
<ogra> cjwatson, just a question about fuse .... debian drops the fuse-source package (and bumps standards) ... i was wondering if you consider that merge worthy
 * ogra is in mobile meeting atm, no hurry
<cjwatson> ogra: it doesn't sound essential, but I don't object to it
<ogra> i wasnt sure about DKMS and fuse ... do we plan to have fuse in the kernel package ?
<ogra> s/have/keep/
<ogra> i imagine for DKMS we'd need the fuse-source package
<cjwatson> ogra: we've shipped fuse as part of our kernel package for some time, and since it's in the mainline kernel I don't see why we would stop
<ogra> ah, k
<verwilst> hm, im trying to upgrade the zabbix deb
<cjwatson> I'm happy to have fewer separate kernel module packages rather than more
<verwilst> and in the mean time add the new proxy app
<ogra> ++
<verwilst> but it doesnt build the proxy
 * ogra isnt a friedn of the DKMS idea at all anyway
<verwilst> i just see dpkg-deb: building package `zabbix-proxy-mysql' in `../zabbix-proxy-mysql_1.5.4-0ubuntu1_i386.deb'.
<ogra> but thats because i most of the time build images where dropping gcc is requested
<verwilst> and that's it
<verwilst> nothing else about actually compiling
<verwilst> did i forget to add anything?
<verwilst> ill pastebin my rules
<ogra> verwilst, thats a better question for #ubuntu-motu btw
<verwilst> oh
<verwilst> ok
<NCommander> ScottK, does the "no backporting interpreters" ever have any exceptions, or is it a hard rule
<ion_> For instance, hardy could really use a fresh bf interpreter.
<NCommander> ion_, file a backport request if ScottK says its ok
<nxvl> good morning
<NCommander> morning nxvl
<ScottK> NCommander: Everthing can have an exception with enough testing is my view.
<NCommander> There are no rdepends
<NCommander> So I think its safe :-)
<NCommander> ScottK, as an added bonus, the backports queue is down to 60% new (22 percent drop from this morning)
<ScottK> For an interpreter, one has to assume code has been written to use it, so it's not just the repo.
<NCommander> Its said the version in hardy is unusable due to its age
<Hobbsee> ScottK: s/testing/bribes/ ?
<NCommander> Two major releases have been done upstream
<NCommander> DktrKranz, thanks, you just helped me drop the backports queue down. Want help on doing these SRUs?
<ScottK> NCommander: If it's totally broken, then maybe SRU?
<NCommander> DktrKranz, what are your thoughts
<pwnguin> ScottK: of course, bf is a brainf*ck intepreter, so nobody's intended to write code for it
<DktrKranz> testing, testing, testing :)
<NCommander> pwnguin, I think its safe to backport that one, file a bug
<ScottK> Ah.
<DktrKranz> this won't be a "minimal" diff
 * ScottK didn't read the scrollback.
<NCommander> Nope
<pwnguin> i think it's worthless in the first place :)
<NCommander> ScottK, well, I was talking about vala, not bf ;-)
<NCommander> DktrKranz, firefox was allowed to update as per an SRU.
<DktrKranz> NCommander: firefox has exception
<NCommander> That can't be minimal by any way you define it
<NCommander> DktrKranz, well, its your call on gnunet 0.8
<NCommander> If not, I'll backport
<pwnguin> I doubt a single backport will fix the stale vala problem
<DktrKranz> NCommander: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<NCommander> Well, vala we'll deal with later
<NCommander> Lets deal with GNUnet
<DktrKranz> NCommander: this deserves to be fixed, but also to be analized very good. I'd do some tests about it, just to make sure everything is safe enough.
<NCommander> Ok, so one of us (and I have that odd feeling your going to drop this on me :-P), needs to roll the patch, and we need to confirm no regressions in the rdepends
<DktrKranz> let's make sure we don't fall with that mess in intrepid too, eventually filing FFe bugs
<NCommander> On which packages?
<NCommander> gnunet is unaffected in intrepid
<DktrKranz> Probably I overlooked that, but I read something about "some packages are not synced yet"
<NCommander> ugh
<NCommander> Pretty
<NCommander> morning cody-somerville
<cody-somerville> Morning
<NCommander> cody-somerville, how goes it?
<cody-somerville> Not too shabby. Heart aches but body and mind are both well rested :-]
<NCommander> cody-somerville, help with hardy backports ;-)
<NCommander> wooo, backports queue down to 51 \0_
<ogra> hmm, so update-manager wants to remove console-tools
<soren> ogra: Does it say why?
<cjwatson> ogra: that's correct; it should install kbd in its place
<soren> Oh, really?
<ogra> cjwatson, gracias ... btw i'm free for the rest of the day in case you wanted to call at some point
<soren> Seeing console-tools on the list of packages marked for removal would have made me ctrl-c my way out of there straight away :)
 * dholbach felt more adventurous :)
<dholbach> I checked the new package relationships more closely before pressing <enter> though :)
<cjwatson> ogra: will do, thanks
<cjwatson> https://launchpad.net/ubuntu/+source/ubuntu-meta -> 1.111
<andrew_sayers> cjwatson: Do you know if the openssh team have looked into using socialist millionaire protocol (used in otp) to make key exchange easier?
<ogra> now who invents such names ?
<ion_> Ha
<andrew_sayers> If it's just waiting on someone to put some time in, I'd be happy to write up a patch or something.
<cjwatson> andrew_sayers: firstly, I think it'd have to be done in the IETF secsh working group rather than openssh
<cjwatson> andrew_sayers: secondly, from Wikipedia's description of the protocol, it seems to me that it depends on the client and server already sharing some secret information
<cjwatson> andrew_sayers: the point when you have to do host key fingerprint checking is precisely when you first contact a server, before you can have shared any secret information with it
<cjwatson> andrew_sayers: after that, the SSH protocol already deals with checking host keys without the inconvenience of asking people to verify fingerprints; so I don't see what this would gain?
<andrew_sayers> cjwatson: Cutting the amount of secret data that needs to be shared down to an amount that my mum would be prepared to spell out over the phone.
<andrew_sayers> (Which is the most secure channel most people have access to)
<cjwatson> andrew_sayers: isn't that just a matter of producing a reduced version of the host key, rather than replacing the whole key exchange protocol?
<cjwatson> I don't think you'd find much support for the latter, but there has been some experimentation of late with displaying the host key in different ways so that might be a different matter
<andrew_sayers> That sounds quite good, do you know where I could look?
<cjwatson> VisualHostKey in ssh_config(5). It isn't what you're looking for but it's an example of other kinds of experimentation along similar lines.
<andrew_sayers> Okay, thanks.  If I come up with something else interesting, is there somewhere I should post my findings?
<cjwatson> while I haven't seen a cryptographic analysis, I suspect that chucking away bits of the host key is not much weaker than choosing a weak passphrase for socialist millionaire's.
<cjwatson> openssh-unix-dev@mindrot.org I guess
<cjwatson> http://www.openssh.com/list.html
<andrew_sayers> Yeah, I had a feeling it might come back to key length in the end.
<andrew_sayers> Anyway, I'll poke around with VisualHostKey, see what else I can do, and post there if I find anything good.
<andrew_sayers> Thanks as always!
<cjwatson> no problem
<broonie> Is there any team likely to have an interest in the NIS package?
<cody-somerville> cjwatson, Whats the status of moving the xubuntu seeds branch to xubuntu-dev?
 * NCommander wakes up
 * Hobbsee runs 240v through NCommander
 * NCommander is sent beyond the reaches of time itself
<NCommander> cjwatson, is there anything we can do to help with the xubuntu seeds?
<cjwatson> not have multiple people nag me about the same thing before I've had a chance to reply? :)
 * NCommander hides behind cody
<cjwatson> oh, hmm, I'm a moron, I thought this required a Launchpad change and it doesn't
<cjwatson> (woo)
<NCommander> \0/
<cjwatson> done
<NCommander> Hobbsee, do you like killing me?
<Treenaks> NCommander: Hobbsee loves killing people for fun & profit 8)
 * NCommander comes back as a vampire and hits her with 120V current
<ScottK> NCommander: They have 240v in Australia, so that's probably not very impressive.
<NCommander> I'm aware
<NCommander> Hrm
<Treenaks> ScottK: "Your puny 120V can't hurt us!"
 * NCommander locks Hobbsee and the Launchpad developer team in a closest
<NCommander> bahahahahahaha
<Hobbsee> heh
<Hobbsee> Treenaks: i've not killed anyone for profit yet, afaik.
<cjwatson> cody-somerville: it turned out that I was an idiot and the Xubuntu seeds move didn't require a Launchpad change at all
<cody-somerville> fabulous :]
<cjwatson> cody-somerville: I just needed to change the target of a mirror we maintain on people.ubuntu.com - so I've done that and the ~xubuntu-dev branch is now official
<cjwatson> cody-somerville: I'm rebuilding xubuntu-meta now with an adjusted update.cfg
<cody-somerville> Splendid. Thank you muchly.
<Treenaks> Hobbsee: for charity, then?
<cjwatson> sorry for the delay, thought it was harder than it really was
<NCommander> cjwatson, what does this explicately mean
<cjwatson> NCommander: I'm sorry?
<NCommander> Uh
<NCommander> Does the mean uploading to the xubuntu specific packages has been limited to xubuntu-dev, or an I mistaken?
<cjwatson> no, it means that control of the Xubuntu seeds has been given over to xubuntu-dev
<NCommander> Oh
<NCommander> Ok
<NCommander> I guess the next question is where is that controlled in launchpad?
<cjwatson> it's not. I have arranged for the seeds mirror in http://people.ubuntu.com/~ubuntu-archive/seeds/xubuntu.intrepid/ that Launchpad looks at to be a regularly updated branch of the ~xubuntu-dev/ubuntu-seeds/xubuntu.intrepid branch
<NCommander> oh very cool
<NCommander> thank you cjwatson
<NCommander> DktrKranz, https://bugs.edge.launchpad.net/hardy-backports/+bug/248055
<ubottu> Launchpad bug 248055 in gtk-gnutella "gtk-gnutella cannot connect to newer network - ancient version detected" [High,Won't fix]
<NCommander> so much for the backporting gnutella versions
<siretart> broonie: I'd suppose the server-team would
<siretart> broonie: why do you ask?
<ogra> oh
 * ogra sees his thin client build using 2.6.27 already
 * \sh just realized, that 2.6.27 breaks vmware-server
 * ogra hopes it finally fixes vbox and kvm
<ogra> at least vbox was unusable since intrepid started
<\sh> ogra: vbox is totally unsuable (at least for me) when testing 64bit versions
<ogra> right, i dont use it for that
<\sh> ogra: I  have to..that's why I have my gooldesx ;) but for this I need a windows installation to run the virt-center to administer it ;)
<\sh> yuck...
<\sh> your kernel was build with gcc 4.3.1 but you try to build the kernel module now with 4.3.2 ...
 * emgent huggs \sh 
<\sh> btw..does canonical has a good relationship with adobe? :)
<\sh> crimsun: latest flashplugin doesn't work for me (the 10.0.1.128+10.0.0.525ubuntuX) ... no flash applet wants to load...any advise?
<ogra> mailto:support@adobe.com ?
<ogra> *g*
<\sh> ogra: oh I phoned them already
<\sh> because the flashplayer on all supported OS does not work with proxies when using RTMPT connections (which should use the browser exported http methods)
<\sh> I even mailed this guy who was sending to ubuntu-motu ML because of better flashplugin integration on adobe side
<\sh> right now, rich media apps which are depending on flash/flex are not working in corporate environments who are mostly using proxy server to access the web...
<\sh> ogra: http://bugs.adobe.com/jira/browse/FP-519 ;)
<tjaalton> \sh: have you tried the latest version (10rc1)?
<tjaalton> not in ubuntu..
<\sh> tjaalton: nope...not now...
<\sh> tjaalton: I think i have to install the libflashplayer.so into /usr/lib/firefox-3.0.1/plugins/ right?
 * ogra goes our for 1h
<ogra> *out even
<andrew_sayers> cjwatson: FWIW, there are enough stations on the tube to represent an SSH key exchange in 16 rounds of Mornington Crescent ;)
<tjaalton> \sh: no, you can install it in your firefox profile directory
<tjaalton> \sh: or, ~/.mozilla/plugins to be exact
<cjwatson> andrew_sayers: heh :)
<kees> tedg: hrm, I need to upload a bugfix to vte, but its bzr is ubuntu-desktop (which I'm not a member of).  Can you merge a branch for me?
<\sh> tjaalton: doesn't work I'm on amd64...and the new flashplayer needs some more libs then ia32-libs has :(
<tedg> kees: Sure.
<kees> tedg: okay, thanks, gimme a sec to finish testing...
<LaserJock> james_w: ping
<james_w> hey LaserJock
<LaserJock> james_w: did you see that bzr-svn FTBFS on anything but i386?
<james_w> I thought it was chroot-wait, maybe I misread.
<LaserJock> it's set to FTBFS, but it's because of deps
<james_w> ah, yeah, I was looking at this with John the other day in a PPA build
<james_w> we really couldn't work out what was going on
<LaserJock> james_w: perhaps a buildd problem?
<james_w> is there an rmadison that will list hppa etc?
<james_w> libsvn-dev | 1.5.1dfsg1-1ubuntu2 |      intrepid | amd64, i386
<james_w> does that mean it's not on lpia?
<cjwatson> rmadison relies on the mirror on rookery, which only has the primary architectures (not lpia either)
<cjwatson> best I can offer you is to look at Launchpad
<LaserJock> in any case, I would think amd64 would work
<cjwatson> https://edge.launchpad.net/ubuntu/intrepid/+package/libsvn-dev
<james_w> yeah, amd64 looks like it should be installable
<cjwatson> it might just have happened not to be installable at the time
<LaserJock> cjwatson: perhaps
<LaserJock> that might explain why all arch's but i386 fail the same way
<kees> tedg: okay, ~kees/vte/alt-screen-scrolling-fix_bug-106995 is the branch to merge please.
<LaserJock> I'm retrying amd64 to see
<james_w> thanks
<emgent> siretart: libass nice commit :)
<LaserJock> bah, of course mysql and linux had to jump in the build queue first :-)
<tedg> kees: Done.
 * kees hugs tedg
<tedg> Man, when on the dev distro one should be able to configure apt so it tells you which packages it's NOT touching.  The list would be shorter.
<tjaalton> \sh: ah, ok
<\sh> tjaalton: hopefully they get rid of the additional packages...if not, we have to include a lot of crap in ia32-libs...at least one lib I already requested...
<superm1> \sh, why not make ia32-libs into smaller packages and the ia32-libs package a meta then?
<\sh> superm1: then you can go and create for all 32bit lib packages those ia32-libs style packages...I hope pitti and other won't like it very much (me neither)
<superm1> \sh, i wasn't aware exactly how they were generated in the first place as i don't use amd64 on the desktop at all.  i believe i see that it would turn into a maintenance mess
<cjwatson> I don't think there's anything wrong with ia32-libs* depending on lib32* (e.g. lib32z1)
<\sh> cjwatson: if lib32* is generated from source directly, (multi-arch) then ok..but pushing all binary lib packages which are not doing that into one single package is a mess...
<\sh> and when I understood the usage and workflow of nspluginwrapper correctly on amd64, it needs the 32bit libs for the plugins ... and this means for ia32libs , adding libcurl plus adding more symlinks, because i.e. flashplugin10 needs libcurl.so.3 and that is normally a link to libcurl.so.4
<\sh> the same goes for adobe fms (to name at least one commercial project) imho a mess
<Chipzz> superm1: I think I saw some talk about that on #debian-dev the other day
<desarrollo> Hi
<desarrollo> Im starting at Free Soft and I want to collaborate when I ready
<kees> This is just what we needed for freeze day!  http://www.gnome.org/~jdub/2005/mdz-big.jpg
<desarrollo> Can somebody to guide me at this new adventure?
<joaopinto> desarrollo, you mean Open, not Free
<LaserJock> kees: lol
<desarrollo> ok
<desarrollo> Im very vad with the English language
<tedg> Riddell: Ping.  Do you guys use the xscreensaver-* packages for the KDE screensavers?
<Riddell> can't say I've used a screensaver since 1989
<tedg> Riddell: I'm trying to update the .desktop files, and the new version of the xslt script adds a "ShowOnlyIn=GNOME"
<tedg> Riddell: All the cool kids are doing it.  And partying like it's _1999_ :)
<Riddell> tedg: I don't think it uses the .desktop files from xscreensavers
<Riddell> kscreensaver has its own .desktop files for the xscreensavers
<tedg> Riddell: Okay, cool.  I'll put that in, it's probably better then so that they don't get confused between the two sets.
<cody-somerville> cjwatson, when do you plan to upload xubuntu-meta?
<BenC> bryce: I'm getting the same symptoms in bug #260933
<ubottu> Launchpad bug 260933 in xserver-xorg-video-intel "[intrepid] xserver crash for xvideo on intel gma3100 (dup-of: 256820)" [Undecided,Incomplete] https://launchpad.net/bugs/260933
<ubottu> Launchpad bug 256820 in xserver-xorg-video-intel "[gma965] x server crashes when watching movies" [High,Confirmed] https://launchpad.net/bugs/256820
<BenC> bryce: anything I can do to help it?
 * bryce looks
<BenC> bryce: I don't get the xserver crash, but I get the underruns in the Xorg.0.log
<BenC> bryce: and funky glitches when starting applications
<BenC> bryce: compiz is disabled
<bryce> ah yes this one
<jpds> bryce: Many thanks for the ubuntu-dev-tools bugs, please keep them coming.
<BenC> bryce: Actually, compiz suddenly (with latest update) doesn't even start...glxgears even complains and wont run, even though glxinfo and xorg.0.log report glx is enabled
<bryce> BenC: it looks like upstream at intel is already working the issue (which may be why you're not seeing the crash any longer).
<bryce> hmm
<bryce> jpds: ah cool, glad to see such quick progress on the issues!  :-)
<BenC> $ glxgears
<BenC> Error: couldn't get an RGB, Double-buffered visual
<jcristau> BenC: might want to upgrade the server
<bryce> BenC: do you know whether it was the -intel 2.4.1 update, or the -mesa 7.1 update that introduced those issues?
<bryce> the mesa update was yesterday, the -intel update was a few days earlier
<jcristau> bryce: the flickering comes from the ddx
<BenC> bryce: I did a complete update today, so no idea
<bryce> jcristau: ah
<jcristau> glx issues should be gone with latest xserver
<BenC> jcristau: I upgraded everything just an hour ago, and since i still have a xserver, I assume I have the latest :)
<jcristau> BenC: well, you can upgrade without restarting X
<BenC> jcristau: restarting X was the first thing I did
<bryce> BenC: dpkg -l xorg-server ?
<jcristau> xserver-xorg-core, even
<BenC> crazy...there's already an update the xserver-xorg-core
<BenC> slow archives...updating again and will let you know
<BenC> bryce: I'm still getting the screen flicker on app starts and the underrun in xorg.log, but at least glxgears works now
<BenC> ii  xserver-xorg-core      2:1.4.99.906-2ubuntu2  Xorg X server - core server
<bryce> that flicker is due to a gnome issue
<bryce> I get that too.  it's a known issue already reported upstream iirc
<BenC> bryce: are you sure? I get the underrun everytime I start an app, and I get the flicker with it
<jcristau> no that's a driver bug
<BenC> I assumed the flicker was a side affect of the underrun
<BenC> ok
<jcristau> it's made worse because gtk bonghits, but it's still a driver bug
<bryce> jcristau: are you sure?  what I heard was that it was due to gnome making xrandr calls too frequently
<jcristau> bryce: RR calls didn't use to make my laptop panel flicker
<BenC> (II) intel(0): EDID vendor "SEC", prod id 17495
<BenC> (II) intel(0): Printing DDC gathered Modelines:
<BenC> (II) intel(0): Modeline "1440x900"x0.0  108.20  1440 1486 1556 1928  900 909 918 935 -hsync -vsync (56.1 kHz)
<BenC> (II) intel(0): EDID vendor "SEC", prod id 17495
<BenC> (EE) intel(0): underrun on pipe B!
<BenC> that's what I see everytime I start an app
<bryce> jcristau: the bug I saw at fdo was closed as WONTFIX, and said it was a gnome issue
<BenC> so I believe that xrandr is being called too frequently, but I can see it being a driver bug that it is flickering
<bryce> jcristau: also, I was seeing it on -nv as well as -intel
<jcristau> intel used to blank the vga monitor so it could probe the tv output. that part is arguably not a bug. but, there's no reason to make the lvds flicker, and it didn't use to, and it doesn't if i revert one commit
<BenC> bryce: another issue I had, that I've been ignoring for awhile...I can't get any more than 2 workspaces under compiz...no matter what I set it to in the workspace-viewer pref
<BenC> bryce: that you, or should I bang someone else over the head? :)
<BenC> I mean "buy them a beer if they fix it"
<bryce> BenC: heh
<bryce> BenC: let me try reproducing, one sec
<pwnguin> that sounds like a regression
<BenC> it definitely is...I had compiz working with 5 work spaces in hardy
<BenC> I cleared all my compiz settings too, and still didn't help
<jcastro> BenC: if you do it through the compiz config thing that works, but not via the applet thing in the panel. (I just tried it)
<BenC> jcastro: in hardy, it used to be synced between them
<jcastro> right
<BenC> maybe a patch went missing from our compiz-gnome
<jcastro> I was just saying that it actually works, it's probably the applet
<BenC> jcastro: which setting did you change? I want to go back to compiz
<pwnguin> as i recall, theres viewports and workspaces
<\sh> BenC: good to see you, any clue how to get rid "implicit declaration of function 'kill_proc'" for a kernel module (namely vmware-server -> vmmon) that one is still bugging me to run my vmware stuff on 2.6.27 ;)
<pwnguin> compiz decided viewports were the way to go
<jcastro> BenC: I choose "custom" for that effects in the appearance dialog and it launches ccsm or simple-ccsm if you have those installed
<BenC> \sh: convert kill_proc usage to kernel_thread
<pwnguin> there used to be a patch or something to fix the workspace switcher applet
<\sh> BenC: cool...will try that tomorrow morning on the office station..thx
<BenC> jcastro: thanks, that fixed it
<BenC> well, it put duct tape over it, but I'd like to see the old behavior return
<bryce> BenC: hrm, compiz is crashing on the test system I usually use, can't reproduce at the moment.  but I'd suggest talking to compiz folks first.
<jcastro> ok, only thing that broke for me in .27 seems to be that locking the screen/screensaver locks up the machine
<BenC> jcastro: that's odd...what gfx card?
<jcastro> intel, hp2510p laptop
<jcastro> investigating
<bryce> jcastro: is this with xscreensaver?
<BenC> I have intel too...didn't get any lockups with screen lock
<jcastro> bryce: the default gnome one afaik
<bryce> hmm
<bryce> jcastro: can you ssh into the machine?
<bryce> (once it's locked up)
<jcastro> that's what I am investigating
<jcastro> am I supposed to get mode-setting and flicker-free hotness or did that not make it?
<bryce> benc was looking at putting in GEM to the kernel, but dunno if that's in yet
<BenC> that sucked
<ion_> Gem?
<BenC> jcastro: I'd be reluctant to say that's a regression in 2.6.27...I've been running it for several weeks and screen lock never killed things until the update I did today
<BenC> jcastro: if you can go back to 2.6.26 and not get a lockup, I'll consider it :)
<jcastro> ok, I will investigate, since it doesn't happen in .26. :D
<BenC> crappy
<BenC> it's never locked up for me until now
<BenC> jcastro: do you see underruns in xorg.0.log under 2.6.26?
<Laney> Is 2.6.27 in the dailies?
<Laney> Actually, are they even building atm?
<BenC> Laney: the ISO's should have a package list with them to check the contents
<Laney> BenC: http://cdimage.ubuntu.com/daily/current/ - guess they're not being made currently
 * Laney was going to test on the eee
<evand> Laney: Note that you're looking at the alternate CD images, and the package list for that set can be found in http://cdimage.ubuntu.com/daily/current/source/intrepid-src-1.list
<evand> (FWIW, the latest live CD images still have the 2.6.26 kernel)
<BenC> probably have 2.6.27 live-daily tomorrow
<BenC> slangasek: Can you keep an eye on linux 2.6.27-2.3 (which is almost done building) to process it into new so lrm can build behind it?
<bryce> BenC: I can confirm the # desktop issue with compiz.  And I do think it's likely to be a compiz bug of some sort.
<bryce> BenC: so talk with amareth or mvo
<slangasek> BenC: I'm currently working through the NEW queue, so hopefully so
<ion_> mkrufky: Thanks for the information!
<mkrufky> huh, ion_ ?
<mkrufky> that probably wasnt meant for me
<ion_> !away | mkrufky
<ion_> Well, meh.
<mkrufky> am i breaking some netiquette by doing that?
<mkrufky> am i really annoying people?
<ScottK> slangasek: If you have some time in the course of your archive admin'ing, backports is in need of some love.
<mkrufky> anyway, unless there is an official netiquette about that, i will continue to do it
<ScottK> mkrufky: Yes.  When there are hundreds of people in the channel it's annoying.
<mkrufky> is it better for me to send in a bot as my proxy?
<mkrufky> ...or is this room logged publicly?
<ScottK> Yes it is.
<LaserJock> james_w: amd64 worked
<LaserJock> james_w: I hit the retry button on all the other archs
<mkrufky> isnt it bad netiquette to have a publicly logged channel without posting info about that in the channel topic?
<slangasek> ScottK: yep, I've seen the list; that takes a back seat to getting NEW processed for FF, though
<mkrufky> i will respect the netquette, i'll try to remember to log out of this room when i would mark myself away
<mkrufky> although that may become more annoying than the nick change, but oh well
<ion_> mkrufky: IRC supports marking yourself away so that only the people interested of your away status see it.
<ScottK> slangasek: Understand.
<LaserJock> james_w: hmm, bzr-svn still had the same problem on lpia, I guess we can try again later
<broonie> siretart: Someone should at least turn off the NetworkManager integration by default, plus there's a bunch of other long standing bugs.
<mika_videodev> does anyone here know something about Marillat's version of: libavcodec, libavformat, ffmpeg etc ... ?
<mika_videodev> or medibuntu, for that matter ?
<jpds> mika_videodev: #medibuntu might help there.
<LaserJoc1> bryce: around?
<mika_videodev> I was thinking of developing a video editor ... is stuff related to that somehow offtopic here, then ?
<LaserJoc1> mika_videodev: this channel is for the development of Ubuntu, not really developing *with* Ubuntu
<bryce> LaserJoc1: yah
<mika_videodev> 1. And who really decides, what apps are to be considered as part of ubuntu ? 2. Those responsible of developing ubuntu itself (does that include kubuntu as well?) : Would you have any interest to standardize ubuntu in a way that makes it easier to install "wild" spplications to run under ubuntu (that are not part of the official ubuntu distro) ? - right now, even if someone makes that kind of app, it seems likely that when the next ubun
<mika_videodev> tu is released, too many libraries change in an incompatible way, and breaks the correct operation of such apps...
<LaserJoc1> bryce: I'm manually setting touchpad options in xorg.conf but it seems that the hal-config is over-riding it
<LaserJoc1> bryce: is that normal?
<bryce> LaserJock: I think so
<LaserJock> hmm
<LaserJock> so how is one supposed to set up stuff? :-)
<bryce> LaserJock: I posted some directions for fixing hal configs at http://wiki.ubuntu.com/X/Config
<bryce> basically, instead of putting those settings into xorg.conf, you put them in .fdi files
<bryce> it's a little different (and not really much easier), but not too hard, and on the plus side you can make them apply by restarting hal, instead of restarting xorg.
<james_w> LaserJock: thanks
<pwnguin> so how long does a flabewar have to go without forward progress before it the TB should be involved?
<bryce> LaserJock: also use lshal to review settings
<pwnguin> blah
<_MMA_> mika_videodev: Try http://lumiera.org and #lumiera.
<mika_videodev> lumiera: a not-ready video editor (application). And i am seeking for information, where to get sources for video libraries and how to compile them into a useful format ( = libsomething.so + libsomething.h )
<mika_videodev> I do know how to write apps. But it's the libraries here that are difficult to deal with. A good app needs good libraries. But installing those "as is" may break existing apps
<mika_videodev> and a website explaining the relations between: libavcodec, libavformat, and ffmpeg and possibly others would be a good help
<_MMA_> ï»¿#openlibraries ï»¿#openvideo ï»¿#ffmpeg ï»¿#lumiera #cinelerra ï»¿Those channels will help. But this is all very off-topic for here.
<test34> I did an update in Intrepid and the Update Manager got uninstalled and the Nvidia driver stopped working.. (The kernel was updated in that update)
<NCommander> ScottK, would backporting debhelper be a fessible backport?
<NCommander> (its a blocker on a lot of other backports)
<ScottK> I don't think so.
<ScottK> Personally I've been re-engineering debian/rules to work with the earlier debhelper.
<ScottK> This is 'fun' with the new debhelper 7 short form.
<LaserRock> NCommander: speaking of that, why did you mark the git-buildpackage as Invalid?
 * NCommander checks
<LaserRock> *git-buildpackage backport bug that I filed
<NCommander> LaserRock, I marked it Incomplete
<NCommander> Not invalid
<NCommander> Incomplete has special meaning on backports
<LaserRock> so what does that mean?
<NCommander> I'm about to comment on it
<NCommander> LaserRock, https://bugs.edge.launchpad.net/hardy-backports/+bug/246493
<luisbg> LaserRock: long time no see
<NCommander> LaserRock, sorry for the confusion
<LaserRock> NCommander: right, but that doesn't answer the question
<NCommander> LaserRock, It has a build-dep that would require a lot of trouble to backport
<LaserRock> I built it just find without any modifications or updated deps, what did you need?
<NCommander> It didn't build in pbuilder Hardy
<NCommander> Hold on, I'll rebuild it and clarify
<NCommander> (I've done 50 some confirmations on less than 24 hours, I can't remember the specifics of each one ;-))
<LaserRock> well, when I filed the bug it built just fine
<NCommander> LaserRock, standby
<NCommander> LaserRock, its possible you built a different version then me.
<LaserRock> very possible
<LaserRock> NCommander: hence why it's good to actually put information in the bug report ;-)
<NCommander> LaserRock, my mistake. It appears to meet its build-deps now
<NCommander> That was one of the first ones I did
<NCommander> So I apologize if this builds
<NCommander> LaserRock, it doesn't install
<NCommander> Its got a build-dep on a newer devscripts then what's in Hardy
<NCommander> er, Depends
<calc> when i create a new package it setups up separate build-arch/build-indep targets, is it safe to merge those into just a single build target?
<calc> since there is no way to separate out the arch/indep builds in my source
<calc> iirc it used to just call build directly (at least in debian) but i don't know what ubuntu does on that front
<james_w> calc: yes, they are optional
<cjwatson> you can just have a single build target, yes
<calc> ok
<calc> install targets are optional as well, right?
<calc> iirc it just calls build then binary-(arch/indep) ?
<cjwatson> cody-somerville: uploaded now; took a little longer than usual because I had to fix germinate a bit
<cody-somerville> cjwatson, thanks
<cjwatson> calc: policy lists the required targets (section 4.9): build, binary, binary-arch, binary-indep, clean
<calc> ok thanks :)
<cjwatson> install is just a widespread convention
<LaserJock> bryce: It looks like I got a .fdi for Synaptics Touchpads that works, I'll add it to the wiki page
<stgraber> speaking of touchpads :) any reason why mine suddenly started ignoring clicks ?
<stgraber> I can still scroll but I can't click (well, I can but I need to use the buttons and I hate that)
<RAOF> stgraber: Probably the same problem that LaserJock's just kindly attaching a fix to the wiki for :)
<LaserJock> stgraber: were you setting those via xorg.conf?
<stgraber> LaserJock: I don't have a xorg.conf
<LaserJock> stgraber: ok, probably still applies though :-)
<LaserJock> I had stuff tweaked in mine and found out that HAL had it's own idea of what my touchpad should do
<LaserJock> stgraber: ok, I put my example on https://wiki.ubuntu.com/X/Config
<stgraber> so in your case tap-to-click is on by default ?
<LaserJock> no
<LaserJock> well, I don't think so anyway
<stgraber> ok
<LaserJock> I was turning it of in xorg.conf but I don't think it was using that config
<LaserJock> normally I do have to explicitly turn it off
<stgraber> it seems to have been on by default a day or two ago and no is off by default
<LaserJock> but it seemed to me that tap-to-click and horizontal scrolling are off by default now
<LaserJock> stgraber: yeah, same observation here
<RAOF> And here.  And System->Preferences->Mouse->"Tap to click" doesn't work :)
<stgraber> RAOF: I don't even have the touchpad tab in that window anymore
<LaserJock> yeah, that was removed
<LaserJock> stgraber: well, I just tried setting MaxTapTime to 150 and restarting HAL but it didn't change anything
<RAOF> Not here?  But I haven't restarted X after todays updates, so maybe...
<stgraber> LaserJock: confirmed, that doesn't work :(
<LaserJock> perhaps I'm not restarting HAL right :/
<LaserJock> stgraber: did you try restarting X?
<stgraber> yes
<stgraber> (II) Synaptics touchpad driver version 0.15.0
<stgraber> (**) Option "Device" "/dev/input/event7"
<stgraber> (**) Option "MaxTapTime" "180"
<stgraber> I get that in X's log but that still doesn't work
<LaserJock> hmm
<LaserJock> well when I turned off the vertical scroll it worked :/
<LaserJock> but when I turn it back on in the .fdi file and restart HAL it doesn't come back on
<LaserJock> stgraber: I don't know dude, I got what I wanted :-)
<NCommander> so uh, jpds, jdong, this is an apology for flooding your mailboxs
#ubuntu-devel 2008-08-29
<jpds> NCommander: Hmm?
<NCommander> jpds, I've roughly caused anyone in ubuntu-backports to get 100 or so emails due to my work on cutting the queue down to size
<NCommander> (120 NEW to less than 30)
<NCommander> jpds, https://bugs.edge.launchpad.net/hardy-backports - I think the pretty pie graph says it better than I can
<NCommander> (as a note, the NEW was at 85%-ish when I started)
<jpds> NCommander: I don't have any mail from that.
<NCommander> Hrm, it looked like ubuntu-backporters got any email that was sent due to changes on the bugs in backports
<NCommander> Guess I'm wrong
 * jpds hugs NCommander 
<NCommander> yeah, can I be an Ubuntu backporter?
 * NCommander runs
 * NCommander still has to attack the gutsy and dapper queues ;.;
<jpds> NCommander: You have to be ~motu first.
<NCommander> sadly ;.;
<NCommander> I don't even meet the time requirements for UUC
<NCommander> jpds, well, could you at least move some things from triaged/confirmed to inprogress ;-)
<jpds> NCommander: Later.
<jpds> Fri Aug 29 00:07:32 BST 2008
<NCommander> Oh
<NCommander> Damn time differences
<jpds> Night!
<NCommander> 07:32 is morning O-o;
<NCommander> Unless thats 12 hour time
<NCommander> Backports for hardy should be done by then
<tormod> ogra: just discovered that tedg decided to make his own xscreensaver 5.07-0 instead of using all my work in 5.07-1. So much for avoiding duplicate work.
<soren> NCommander: 07:32 is morning, but 00:07:32 is just a few minutes past midnight :)
<NCommander> oh
<NCommander> whoops
 * NCommander wonders how long until the archive admins handle the backports queue
<CarlFK> cjwatson: guessing you can tell me what package this should be against https://bugs.launchpad.net/ubuntu/+bug/262451
<LaserJock> how interesting, Firefox opens a new blank window every time I open a tab or move to a different webpage
<LaserJock> and if I close one FF crashes completely
<soren> LaserJock: Those are probably from the pluginwrapper thingie.
<soren> Not that knowing that will help anything, but meh. :)
<LaserJock> soren: ahh, right, I did upgrade that recently :/
<slangasek> CarlFK: the assertion is in dpkg, so there's a dpkg bug
<CarlFK> slangasek: thanks
<slangasek> CarlFK: if fixing that bug doesn't fix the overall problem, then iterate ;)
<NCommander> wooo, ten backport NEW bugs left
<calc> i must be doing something wrong
<calc> my $dest = "test/foo/bar/baz";
<calc> mkdir -p $dest;
<calc> why does that not work in perl?
<calc> tells me: Use of uninitialized value in mkdir at ./test.pl line 4.
<slangasek> which line is line 4?
<calc> the mkdir line
<slangasek> "mkdir -p $dest" is wrong, regardless
<slangasek> perl isn't shell
<calc> oh what should it be?
<calc> its a snippet from another script in ooo-build
<StevenK> mkdir($dest);
<calc> does perl mkdir make leading dirs?
<slangasek> well, either you need to call system("mkdir -p $dest"), or you need to implement -p yourself, I think
<calc> ok
<StevenK> I'm not certain, but I don't think so.
<slangasek> or use mkpath from File::Path
<calc> ok
<calc> i'm trying the system()
 * calc isn't sure how this worked for the person who wrote it
<calc> i didn't think you could call commands directly but he is apparently at least trying to do it all throughout the code
<calc> lol
<slangasek> maybe the intrepreter line at the top is a red herring, and he's invoking it as sh ./haha.pl
<slangasek> superm1: hum, why does mythbuntu-log-grabber build-depend on *both* python-central and python-support?
<StevenK> slangasek: Just to be sure
<slangasek> oh; isn't it better to use python-cya for that?
<slangasek> ... why is there a library named "libass"?
<slangasek> -rw-r--r-- root/root      3019 2008-08-28 18:02 ./usr/include/ass/ass_types.h
 * slangasek shakes his head
<StevenK> Teehee
<lifeless> at least they don't have a 'hats' class
<slangasek> hah
<calc> slangasek: nope its definitely perl but looks like buggy perl
<NCommander> StevenK, hola
<StevenK> NCommander: I'm starting to get the impression you only talk to me when you want my GPG key.
<NCommander> StevenK, no, I wanted you to confirm I have no life
<NCommander> StevenK, https://bugs.edge.launchpad.net/hardy-backports
<StevenK> You don't need me to do that ...
<NCommander> I finished processing the backports queue (112 bugs) for Hardy within 24 hours
<StevenK> I think I hear slangasek screaming
<slangasek> StevenK: maybe he means that he wants you to triage that he has no life
<NCommander> Yes well, causing slangasek to run in fear is always an amusing passtime
<slangasek> the ~ubuntu-archive queue is only 48 bugs, I think you mean you hear ScottK and jdong screaming
<NCommander> I already got compaints that I flooded a few peoples inboxs
<NCommander> 118 bug handling causes a lot of email sent
<NCommander> s/handling/handed
<NCommander> ... handled
 * Hobbsee is thinking of /dev/null'ing all non-bugmail from launchpad.
<StevenK> slangasek: The pain will end up in your lap soon enough :-P
<NCommander> The easy solution would to simply make me an archive admin and then delgate the task to me
<NCommander> That way all the pain is self-inflicted
<NCommander> Once I'm an MOTU, I can also spare ScottK and jdong pain ;-)
<slangasek> StevenK: I'm subtly putting load on other people in the right places so that the backports queue will reach ubuntu-archive right when pitti is back and I'm on holiday ;)
<StevenK> NCommander: Your easy solution has some remarkable assumptions. :-P
<StevenK> slangasek: Haha!
<NCommander> slangasek, I'll make sure pitti knows you were to blame for that
<slangasek> NCommander: no, there's a specific backporters team, MOTUs aren't empowered to ack backports on their own
<NCommander> Or else I'm going to get yelled at for making his job hard
 * StevenK is waiting for pitti to come back so we can run a broom through NBS
<Hobbsee> slangasek: i didn't think you were supposed to admit to that in a public channel?
<NCommander> slangasek, er, ubuntu-backporters which can add the archive admins to ack it
<NCommander> Right now, everything sitting on ScottK and jdong because I'm not an offical backporter so they need to ack everything before it goes to the arch admins
<NCommander> I'm hoping to start dapper backports next :-)
 * NCommander hears the screaming
<jdong> *sigh* I just got back on campus after 12 hours at the airport trying to convince the guy at the ticket counter that a 2:15 flight doesn't work at 3:01 even if the DOS window says it hasn't taken off....
<NCommander> jdong, don't check your mailbox then if you don't want to have a worse day
<jdong> and then had to convince the guy beside him Washington DC *does* do daylight savings time, and even if they didn't it would be an hour in the wrong way.
<jdong> and too late. I did take a peek at the bug queues I was tending to before vaction.
<jdong> and it doesn't look fun.
<NCommander> I tested every hardy backport
<StevenK> jdong: You want to talk to -> NCommander
<NCommander> That's 120-ish bugs
<slangasek> Hobbsee: that just makes more fun watching people try to prove it
<jdong> plus in the coming 3 days I have to figure out what classes I am going to go to take this term :)
<jdong> NCommander: if you've left comments on said bugs, I will be chewing through the queue this long weekend
<NCommander> jdong, yup
<NCommander> jdong, https://bugs.edge.launchpad.net/hardy-backports - No NEW bugs left
<NCommander> Now I need to start on gutsy
 * NCommander hears swearing
<slangasek> jdong: it doesn't work even if the DOS window says it hasn't taken off, because the DOS window doesn't correspond to reality?
<jdong> note above comment about stress of choosing MIT courses for this term; my progress here *may* be slow
<jdong> slangasek: I think they're still having those airport system difficulties they were having earlier this week
<jdong> slangasek: I really didn't want to be sent on a wild goose chase through a shuttle and two terminals to look at an empty boarding gate :)
<NCommander> jdong, well, I'm going to be in Boston sometime in September. If you want to flog me while I'm there for doing the testing grunt work, then we should meet up :-)
<jdong> NCommander: cool :) hopefully the queue will be cleared by then
<NCommander> StevenK & jdong: https://answers.edge.launchpad.net/hardy-backports/+question/43509
<jdong> *sigh* thanks for all the hard work that you've put into triaging these backports but please don't goof around with the bug reporting system :)
 * NCommander zaps it
<NCommander> It was just a joke :-)
<slangasek> try Yahoo Answers
<NCommander> And now its not on hardy-backports anymore
 * NCommander attached it to his private project
<jdong> ok now to figure out where to steal food since that was the one thing I forgot to pack....
<jdong> I am guessing espresso beans have no nutritional content at 10:00PM
<slangasek> their nutritional content is slight, at all hours
<jdong> it also tends to decay the longer you use them :)
<slangasek> also they tend not to be very filling
<NCommander> true, but without caffiene, most Ubuntu contributors would slowly be going insane as they fought sleep deprivation in the mornings
<jdong> will I be surprised in a not-fun way if I update my Intrepid at the moment?
<NCommander> jdong, no issues here updating since the FF
<NCommander> jdong, roughly speaking, how bad is the backports-testers manpower, ScottK said it wasn't great, but I'm worried if I start attaching debdiffs to fix things that don't compile, its just going to sit and not get touched
<slangasek> I think you might want to take a step back and wait to see how the backport team manages the queue you've already given them, at this point
<NCommander> maybe a good idea
<NCommander> I can go work on FTBFS's for awhile
<cody-somerville> NCommander, I have something for you to do
<NCommander> shoot, cody-somerville
<cody-somerville> NCommander, call my bank and harass them as to where the wire containing my pay went - I'm rather hungry :P
 * NCommander falls over
<NCommander> Ok, what's your account info, security information, bank, etc?
<NCommander> StevenK, backports and uploads aside, how are you in general?
<cody-somerville> StevenK is always horrible.
<cody-somerville> Haven't you met him?
<NCommander> no
<NCommander> But he sounds like an interesting individual to meet
<cody-somerville> Well, I'm sure you will in December.
<NCommander> What's December?
<cody-somerville> UDS
<NCommander> I can't afford a plane ticket to California ;.;
<cody-somerville> Thats why you'll get sponsorship
<NCommander> who in there right minds would sponsor me ;-)?
<NCommander> *their
<cody-somerville> mneptok
<NCommander> who or should I say what is that?
<cody-somerville> although mneptok is never in his right mind so that might be a trick question
 * StevenK glares at cody-somerville
<cody-somerville> gah!
 * cody-somerville ducks.
 * NCommander watches cody-somerville explode from StevenK's glare
<NCommander> which comes the next question is how do I apply?
<cody-somerville> NCommander, I dunno if they take applications. It works a bit differently each release cycle.
<NCommander> (for sponsorship)
<cody-somerville> NCommander, They won't be looking at sponsorship until around October anyhow.
<NCommander> after intrepid+1 releases, right?
<cody-somerville> Well, usually they start sponsorship stuff roughly 3 months before UDS. This year, UDS is the second week of December.
<NCommander> Oh shoot
<NCommander> I remember we had this chat, and I wasn't sure if I was going to be able to go
<NCommander> Well, with a little luck I can
<cody-somerville> I don't remember having this chat but I'm glad you do :0
<NCommander> It's at the Googleplex, right?
<cody-somerville> Indeed it is
 * NCommander looks at his uni's schedule
<NCommander> So this is the 7-12th?
<cody-somerville> 7-13th most likely
<cody-somerville> actual summit is 8th-12th
<NCommander> That should work fine
 * cody-somerville doesn't have much choice.
<NCommander> Well, your not an active student cody-somerville
<NCommander> I am ;-)
<cody-somerville> I'm a student :P
<cody-somerville> I learn everyday
<NCommander> I look forward to meeting all of you there then
<cody-somerville> NCommander, omgz, we can like form a posse like the server team does :P
<slangasek> ...
<NCommander> I work with too many subgroups. I'll have to divide myself.
<NCommander> The question is which group should get which bodypart ?
<cody-somerville> NCommander, I propose a new posse. The "I contribute to almost everything in Ubuntu" posse.
<moquist> I need my postinst to behave differently depending on which binary package (from a common src package) is being installed. Is there a variable I can check, or should I have multiple postinst scripts, or is there yet a third alternative I have not imagined?
<NCommander> Nah, that's too exclusive and snotty, I'm an average joe
<NCommander> moquist, I personally recommend multiple postinst scripts
<slangasek> moquist: you don't get the package name available to you at runtime, no
<moquist> OK. So if I just create <binpkg1>.postinst and <binpkg2>.postinst, that should do the trick.
<slangasek> moquist: because the postinst being executed is always extracted from the .deb, it's expected that the postinst already knows what package (and what package version) it comes from
<slangasek> yes
<moquist> NCommander, slangasek: thx
<slangasek> you could create a common one too and munge it in debian/rules, if you find that more maintainable
<moquist> oooooo
<moquist> I'm not sure. I haven't tried breaking it up yet.
<TheMuso> n/c
<slangasek> moquist: just don't write a 50-line abstraction in make that you use to generate all your maintainer scripts, like some developers I know :)
<moquist> heh; not likely
<moquist> would it be bad form (at least?) to simply chuck a config value into debconf that tells me which .config ran, which would tell postinst how to behave...?
<cody-somerville> slangasek, Is it possible to have a second Xubuntu experimental daily build that also pulls from a PPA?
<slangasek> moquist: mm, yes, that would be bad form. :)
<slangasek> cody-somerville: it's possible, but why is it needed?
<slangasek> well - anything's /possible/, but I don't actually know that pulling from PPAs is /feasible/ on antimony
<slangasek> (and it wouldn't make me particularly happy, personally)
<cody-somerville> slangasek, To make testing of xfce 4.6 easier. We're currently opting to keep 4.4 in the archive since there is uncertainty as to the Xfce4 project's ability to meet follow through on their time based release schedule after missing several deadlines.
<slangasek> hmm
<StevenK> slangasek: I've done those changes to livecd-rootfs. They aren't pretty.
<StevenK> Which is why I didn't push them into the bzr branch
<slangasek> cody-somerville: so were you wanting liveCDs, or just alternates?
<cody-somerville> I was thinking liveCDs
<TheMuso> ouch
<slangasek> yeah, I don't think that would pass muster
<slangasek> since there's no trust path to ppas, and liveCDs run the maintainer scripts (== untrusted code) during building
<cody-somerville> Well, the only people who can upload to the PPA are going to be the same people who can upload to the archive once we do the archive reorganization.
<slangasek> TTBOMK, we don't have signed PPAs yet -- therefore there's no trust path to the PPA, regardless
<cody-somerville> However, I understand that doesn't negate trust concerns
 * cody-somerville nods.
<NCommander> cody-somerville, it would be possible to build CDs ourselves, but due to the way cdimage works, it doesn't support laying multiple APT repositories over each other. If we would like to create a livecd, we'd likely have to use a different tool for it
<NCommander> (the only way to do it with cdimage is create a apt repo that has all of universe and main on it, and then upload the beta packages to that and let it run)
 * _MMA_ would just use Reconstructor. As long as the PPA packages would upgrade over what's in the archive.
<NCommander> _MMA_, Reconstructor?
<cody-somerville> I would so use moblin-image-creator me self :P
<_MMA_> http://reconstructor.aperantis.com
<NCommander> damn
<NCommander> Handy tool
<cody-somerville> Well, it is past my bed time. I need to get my beauty sleep for my skydiving this weekend.
<_MMA_> cody-somerville: In any event, as long as you didn't need to do it daily (as it would be a pain) you could make the disk manually and upload it somewhere to get testing.
<_MMA_> NCommander: It's how *many* of the Ubuntu off-shoots are made.
<NCommander> damn
<NCommander> That would make my life easier
 * _MMA_ goes back to his family.
<jdong> oh boy, I just ate 3lbs of carved chicken breast... I think I'm gonna puke
<NCommander> jdong, O_O;;;;;
<NCommander> jdong, can you look at this one quickly? https://bugs.edge.launchpad.net/hardy-backports/+bug/260998
<NCommander> ubottu seems still broken
<mneptok> cody-somerville: i'm a left-brain type person :P
<NCommander> hello Mr. mneptok :-)
<mneptok> arr!
 * NCommander hides
<cody-somerville> NCommander, where do I send my Matin Pitt's fanboys club membership dues to?
 * Hobbsee runs a sword through mneptok
<NCommander> cody-somerville, Matin Pitt?
<mneptok> cody-somerville: lurve_that_goatee@pitti.org
<cody-somerville> NCommander, you're a member :P
<cody-somerville> :D mneptok
<NCommander> I haven't been charged dues yet
<NCommander> And even if they did, I got no money
 * NCommander feels like he should be doing something
<StevenK> Argh. pitti.org is domain-squatted
<NCommander> rofl
<NCommander> Spammers love pitti too
 * NCommander StevenK so what usually happens during UDS?
<NCommander> er
<StevenK> NCommander: Lots of planning, lots of drinking
<NCommander> I feel left out
<NCommander> I don't drink :-/
<NCommander> (nor could I if I wanted to, I'm only 20)
<StevenK> Wait for UDS in Australia, the drinking age is 18 here
<NCommander> Doesn't change the fact that I just don't drink ;-)
<mneptok> StevenK: i'd actually start younger if i had to live in Oz.
 * mneptok runs
<StevenK> Ha
 * calc wishes bad things to the people who thought putting external libraries into OOo was a good idea :-(
<calc> lets add a bunch of libraries to OOo and patch them instead of doing the real foss thing and getting the changes upstream, GAR
<TheMuso> calc: That reminds me of another FOSS project that I am involved with packaging/updating for UbuntuStudio.
<NCommander> What's the proper preprocessor symbol for detecting linux?
<NCommander> It's _LINUX, right?
<lamont> NCommander: most of the code I've seen uses __linux__
<superm1> slangasek, yeah just to be sure ;)  I'll get nick and/or thomas to take care of that
<NCommander> thanks lamont just making sure
<superm1> NCommander, did you see my comment on the DKMS backport bug?
<NCommander> superm1, I did, just haven't reponsed yet
<superm1> NCommander, ah okay
<NCommander> It's an issue of rdepends. When we do a backport, we have to check all the rdepends,
<NCommander> superm1, if your update breaks something in the kernel, we're going to get a LOT of pissed off users :-)
<superm1> NCommander, nothing "in the kernel" depends on it that's installed by default.
<superm1> there should be 1-3 different packages that use it, but they are all optional packages
<NCommander> But a lot of systems have restricted modules
<NCommander> And as a group, we can't test them
<superm1> in hardy restricted modules aren't built by dkms
<NCommander> I have hardware for one of these modules
<superm1> that starts with intrepid
<NCommander> Oh
<NCommander> THat's different
<NCommander> I apologize for that misunderstanding then ;-)
<superm1> no problem.  wouldn't have been clear if you were just joining development this time around
<NCommander> I'm testing to see if the dkms builds properly
<NCommander> &on hardy
<NCommander> if it does, I'll mark it confirmed, otherwise it goes to incomplete until someone can properly port it
<superm1> i probably should have just attached my hardy build log to save that time, but more eyes doesn't hurt i suppose
<NCommander> We have to do it since we also test installability and such
<NCommander> Or at least I do
<NCommander> I'm not going to ack soemthing without confirming itmyself :-)
<NCommander> you've got backports! (mail)
<NCommander> superm1, I still see the dkms has rdepends
<NCommander> on hardy
<superm1> yeah on envy packages and lirc-modules-source
<NCommander> nvidia too
<superm1> hence the envy packages bit
<NCommander> superm1, I confirmed your dkms backport
<superm1> thanks NCommander.  btw since when are you part of ~ubuntu-backporters? I don't recall ever talking with you on backports in the past?
<NCommander> I'm not a backporter, I'm a tester
<NCommander> But there has been no testers so I ran the entire queue through the testing queue
<NCommander> (120-ish bugs)
<NCommander> I hope to join the backporters group once I become an MOTU
<superm1> ah okay :)
<superm1> that's good, the backporters group goes up on good runs and then dormant for a while
<NCommander> Well, I might have scared them off
<NCommander> They have gotten roughly 100-200 emails from me
<StevenK> So this week might be a "dormant" one
<NCommander> Yup
<NCommander> Once they start processing the queue, I'll work on the maybe fixing the backports that need real porting
<ScottK> NCommander: I only see 24.  That's not so bad.
<lukehasnoname> So did Pidgin end up keeping its reign?
<NCommander> ScottK, jdong got sick when he saw his inbox cause he has ALL of them I've done right along
<NCommander> ScottK, I'm proud of the fact that the new queue is 0 on hardy backports
<ScottK> Yeah, well I'm smart enough not to get the generic backports bugmail.
<NCommander> rofl
<NCommander> Care to look them over and move them to In Progress?
<ScottK> Doing it now.
<ScottK> It's a battle between the Scotch and it's effect on my typing to see how far I get.
<NCommander> I thought it would just be Launchpad
<ScottK> Launchpad is inept enough that I need to give it an advantage.
<ScottK> NCommander: Please make sure you say the package runs.
<NCommander> which one?
<ScottK> subtitleditor.  Fortunately the original reporter already said it and I'm choosing to believe them.
<NCommander> Oh shoot, I ran it, forgot to note it >.<;
<dholbach> good morning
<siretart> broonie: that 'someone' might or might not be mvo. Perhaps you should write him an email about that? - if in doubt, CC the ubuntu-server mailing list
<NCommander> ScottK, thanks for looking on the triaged bugs thus far
<NCommander> Any buildd admins alive?
<NCommander> or core devs who are willing to retry a build?
<jpds> NCommander: Which one?
<NCommander> postfix on all architectures it failed
<NCommander> Soyuz marked it failure, it was actually a dep-wait
<NCommander> jpds, I'm currently working on fixing buildd to work on PPAs :-)
<jpds> NCommander: Erm, okay, you need a core-dev as it doesn't work with me.
<NCommander> I guess that's been changed :-/
<NCommander> jpds, for obvious reasons, I can't test scoring of PPAs, so you should test that for me once I post my branch
<jpds> NCommander: u-d-t branch?
<NCommander> yes
<jpds> Yay, more patches.
<NCommander> Any specific option you want for ppa's?
<NCommander> I was going to use --ppa but -p might be better
<jpds> NCommander: You can have -p and --ppa, look at the # Retry options in trunk.
<NCommander> the what?
 * NCommander is checking
<jpds> NCommander: lines 43 - 48 in buildd.
<NCommander> Yeah
<NCommander> SO I'll add it at the end
<NCommander> I was going to make it buildd --ppa *other ops*
<NCommander> But if I move it towards the end, the code is cleaner :-)
<NCommander> Oh wait, I see
<NCommander> bah, I haven't done much with options parser
<jpds> Cool paste and change the strings? :)
<jpds> Copy*
<NCommander> Sorta working on that
<NCommander> This is fun
<NCommander> There is no great way to handle individual users and group PPA detector
<NCommander> jpds, I think we'll need a --ppa, and a --ppa-group :-/
<jpds> NCommander: Whatever adds ppa support.
<NCommander> Ok
<NCommander> Ugh
<NCommander> I need to extend checkSourceExists
<cjwatson> Laney: the reason there wasn't an alternate CD yesterday was that I was trying to do too many things at once when uploading debian-installer the previous night and as a result it failed to build. That's fixed now so we should get new alternate CDs shortly.
<wgrant> Um, what do I file a bug against if my machine decides to fsck /home, but continues booting while fscking so I don't have a home directory?
<cjwatson> I'd go for sysvinit
<cjwatson> (which still provides initscripts)
<wgrant> cjwatson: Thanks.
<wgrant> Ah, bug #255562.
<ubottu> Launchpad bug 255562 in sysvinit "Parallel fsck leads to unhelpful error message at login" [High,New] https://launchpad.net/bugs/255562
<Fahrenheit> Hi All
<Fahrenheit> How can i compile my C++ programs in Ubuntu?
<jpds> !b-e | Fahrenheit
<ubottu> Fahrenheit: Compiling software from source? Read the tips at https://help.ubuntu.com/community/CompilingSoftware (But remember to search for pre-built !packages first)
<lukehasnoname> So is Pidgin default in Intrepid?
<ogra> luckily
<Ng> is the current intrepid shutdown dialog a temporary thing?
<lukehasnoname> ogra: Agreed.
<ogra> Ng, there was a discussion on the dekstop ML or so i think ... or on ubuntu-devel
<Ng> ah
<Ng> it's..... pretty horrible, and it suggests that if you don't pick an option it will just shut down after a minute, same for the logout. that seems even worse than being ugly, it's potentially harmful :/
<ogra> lukehasnoname, i like it, but it has massive security issues with IRC ... like ignroring the /msg command ... so "/msg nickserv passwd" is automatically exposed to the channel :)
<ogra> i dont get why they filter irc commands in irc (btw /me works)
<ogra> Ng, it shuts down for you ?
<ogra> youre a lucky guy
<ogra> the shutdown part works on none of my systems here
<ogra> i have to log out and shut down from gdm everywhere
<Ng> ogra: I don't know, I never use Shutdown, I only ever Suspend, so having it shutdown for me if I fail to click anything for a minute would be really quite annoying ;)
<ogra> yeah
<ogra> also havig two dialogs is annoying and bloats the menu
<ogra> Ng, mdz asked that in "Subject: 	Logout dialog (Re: Installation report: Ubuntu desktop 20080723 amd64)" on -devel
<Ng> cool, got it
<ogra> seens the new dialog comes from opensuse
<ogra> and upstream will keep it that way
 * ogra sometimes wonders what they smoke at suse ... they also designed that horrible control center shell there :)
<lukehasnoname> I don't know about Ibex, but I like Hardy's menu just fine
<lukehasnoname> and effing with it for the sake of changing it is something I'm against
<ogra> intrepid has two dislogs instead
<ogra> one for logout
<lukehasnoname> boo urns
<ogra> one for suspend/resume/reboot
<ogra> (and halt)
<lukehasnoname> phail
<lukehasnoname> What sucks is that if I want to continue using Ubuntu without some "major" customizations of my own I need to to to Ibex (wireless N networking, several major package upgrades, and some other stuff) but people seem determined to change so many things for the sake of changing it.
<lukehasnoname> Of course they have their own little rationale, but they're often wrong :)
<Fahrenheit> can i compile C# or VB in ubuntu?
<lukehasnoname> mono
<lukehasnoname> sudo apt-get install monodevelop gmcs
<ogra> Fahrenheit, this isnt really the right channel to discuss app developent ... its for discussing development of ubuntu, not for development on ubuntu :)
<Fahrenheit> :)
<lukehasnoname> I'm still right though
<Fahrenheit> whrere can i ask these Qs?
<lukehasnoname> ubuntuforums.org or ##linux or #ubuntu
<ogra> well, #ubuntu-motu comes closer to it but i'm not sure they o beond packaging much
<ogra> *go
<ogra> try it :)
<verwilst> lukehasnoname: #mono ;)
<verwilst> euh
<verwilst> Fahrenheit: #mono
<verwilst> :P
<Fahrenheit> M4n`/ T4|\|X><
<cjwatson> ogra: broken logout is known - it's to do with consolekit/policykit integration problems
<ogra> ah
<cjwatson> err, I mean broken shutdown/restart not-from-gdm
<ogra> yeah
<ogra> i got what you meant :)
 * NCommander feels like doing something useful
<ogra> NCommander, porint the old ogout dialog to intrepid ? ;)
<ogra> *porting
<NCommander> ogra, link and info?
<ogra> NCommander, https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/251211
<ubottu> Launchpad bug 251211 in gnome-session "intrepid uses the upstream session dialog" [Wishlist,Triaged]
<ogra> NCommander, and https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025857.html
<NCommander> Oh, this one
<NCommander>  who wrote the original patch?
 * ogra cant remember
<ogra> but should be noted in the changelog somewhere and in the credits
<NCommander> Well
<NCommander> This might not be that hard to rewrite if I'm following the code right
<NCommander> ogra, is this the normal logout dialog box?
<NCommander> ogra, hrm, I'm looking at the code, I trying to make sense of it
<NCommander> Once I figure out where its loading the interface data, I can bend it to my will ;-)
<ogra> NCommander, that would be massively cool !
<NCommander> But there were plans to switch it from the six button switchboard
<emgent> jcastro: around ?
<dholbach> emgent: it's 7:39 where jcastro lives.
<emgent> yeah saw that, thanks Daniel :)
<dholbach> :)
<emgent> okkay people see you in 8 sept. i go to Amsterdam
<emgent> bye, and good work!
<norsetto> emgent: can we have a little talk in about 1 hour? I'm in a meeting now
<jpds> Have a nice trip emgent.
<emgent> norsetto: uhm ok cesare
<norsetto> emgent: I have some tips for Amsterdam ;-)
<huats> norsetto: !!!!
<norsetto> huats!!!!
<warp10> norsetto: do you have tips for Barcellona too?
<warp10> :)
<jpds> warp10: Yeah, visit me and RainCT.
<norsetto> warp10: nope, only been there once
<huats> norsetto: tips for amsterdam ? I asked you and you said no :(
<emgent> hahha
<norsetto> huats: you were there with your fianceÃ© ...
<huats> there are different treatments :)
<warp10> jpds: that would be great... I should be there in late september :)
<huats> ah ok :)
<huats> I understand :)
<jpds> warp10: Cool.
<BenC> mdz: re: bug #262539 what lrm drivers are you using?
<ubottu> Launchpad bug 262539 in linux "2.6.27 REGRESSION, hangs during boot while preparing restricted drivers" [High,New] https://launchpad.net/bugs/262539
<mdz> BenC: DISABLED_MODULES="ath_hal fc fglrx ltm"
<mdz> BenC: only nvidia is being  linked there
<mdz> BenC: and not loaded yet, of course
<BenC> mdz: lrm doesn't link nvidia...it's already built from dkms
<BenC> mdz: you can totally uninstall lrm in this case :)
<BenC> mdz: but I would like to find out what is causing the hang
<mdz> BenC: oh, right
<ogra> BenC, do you need a bug about ath5k not working on the Q1 ?
<BenC> ogra: yeah, and let rtg know so he can look into it
<ogra> good, i wasnt sure
<tseliot> mdz: which flavour of the nvidia driver do you use?
<mdz> tseliot: 173
<tseliot> mdz: this morning I added a patch in order to make 173 work well with 2.6.27. tjaalton should do the upload sooner or later.
<tseliot> just FYI
<mdz> tseliot: ok, I'll bear that in mind, thanks
<mdz> tseliot: there is a bug in this version which causes my system not to reboot properly
<mdz> I wonder if I should try a later version, if it still supports my card
<tseliot> mdz: works well with 2.6.27. What's the model of your card?
<mdz> tseliot: 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5500] (rev a1)
<mdz> tseliot: I've had this problem for ages across multiple kernel versions.  it works fine when I use nv
<tseliot> mdz: unfortunately your card is not supported by 177
<tseliot> did you report the problem to NVIDIA?
<Treenaks> tseliot: Geforce FX5500 is only supported by _older_ nvidia drivers
<Treenaks> tseliot: nvidia likes to strip support for older cards from newer drivers
<mdz> tseliot: I reported it to Launchpad as bug 94855
<ubottu> Launchpad bug 94855 in nvidia-graphics-drivers-173 "HP Pavilion a650e (amd64 running Ubuntu/i386) doesn't reboot" [Undecided,New] https://launchpad.net/bugs/94855
<tseliot> Treenaks: being the maintainer in Ubuntu, I know what you mean ;)
<tseliot> mdz: maybe if you report the problem here NVIDIA can help you: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
<mdz> tseliot: I don't reboot very often; I have more urgent bugs to deal with (and ones we can fix in Ubuntu ;-) )
<tseliot> right ;)
<dholbach> ember: for some reason http://bazaar.launchpad.net/~ember/5-a-day-data/main/files has the files of all contributors in it :)
<ember> dholbach: i've had a problem with it, when testing the applet, let me fix it
<dholbach> ember: it seems that lots of commits of others are in the history of the branch
<ember> it's seems that was an old 5-a-day-data not -ember
<dholbach> ah
<ember> dholbach: well my 5-data-ember has those files, isn't it normal?
<dholbach> no
<dholbach> daniel@lovegood:~$ ls /home/daniel/.5-a-day-dholbach/
<dholbach> data  team
<dholbach> daniel@lovegood:~$
<ember> dholbach: i think it's fixed, thanks
<dholbach> ember: np :)
<\sh> asac: crimsun: ping pong peng kaboom...flashplugin on x86_64 with nspluginwrapper doesn't do any network connects via rtmp
<asac> \sh: is that a nspw 1.1.0 regression?
<asac> to test you need to --reinstall flashplugin-nonfree
<\sh> asac: I don't know...I just rechecked many times on many workstations i386 flashplugin-nonfree + rtmp connects (livestreaming) and x86_64 bit
<asac> maybe ia32-libs issue?
<\sh> asac: I did many times...I'd test with 9.0.0.124 and with intrepids one (which is working now from scratch)
<asac> \sh: try with old nspluginwrapper as well
<\sh> asac: could be, not sure, when I check tcpdump no network stream flows
<\sh> asac: from hardy? doesn't work :)
<\sh> asac: the same issue...since yesterday I had hardy :) and I wasn't sure if I'm stupid or the software...now I'm sure :)
<\sh> s/since/until/
<asac> ok. but that is with 10 on hardy?
<\sh> asac: didn't test..do we have the 10 on hardy? because the one from adobe doesn't work, because libcurl.so.3 is missing and some other libs
<asac> \sh: most likely you can just install the intrepid flash pacakge
<\sh> asac: bug #246911 for ia32-libs lists all necessary libsmissing for flash10
<ubottu> Launchpad bug 246911 in ia32-libs "[Wishlist] please add libnspr4-0d to ia32-libs" [Wishlist,Confirmed] https://launchpad.net/bugs/246911
<asac> hmm
<emgent> (query asac
<emgent> ops.
<asac> emgent: whats up?
<emgent> asac: not here :)
<\sh> hmm..pitti is on holiday?
<\sh> asac: if you have an x86_64 machine with ff + fp-nonfree, you can test against www.webzooms.tv, create an account and try a livecast...(I'm the admin of this company...so it's free of charge and I can always delete your account on your behalf ;))
<Adri2000> cjwatson: did you forget me and my amsn srus, or is it still on your radar?
<Adri2000> oh chand, hi ;)
<chand> Adri2000: hi
<ember> asac: the name of the plugin finder is what i'm using on Npp-*
<asac> really
<asac> ok
<cjwatson> Adri2000: still on my radar, sorry
<ember> and futuresplash is also enable on about:plugins
<ember> attaching the diff on the bug.
<Adri2000> cjwatson: ok, no problem
<mdz> dendrobates,cjwatson: I just tested DNS resolution using openjdk-6-jre-headless and the test program from the Debian bug, and it works fine without libnss-mdns
<cjwatson> interesting
<cjwatson> I'll note that in the bug
<mdz> dendrobates: I assume someone tested this on the server team; did they see the same result?
<dendrobates> mdz: yes.
<mdz> cjwatson: perhaps doko is being overly cautious based on the problems in Debian
<mdz> cjwatson: those bugs are also on sun-java6, not openjdk-6
<cjwatson> dendrobates: did anyone actually say that in a bug report? :-)
<cjwatson> mdz: yes, though I'd be surprised if there were changes in this area
<cjwatson> anyway, I've noted it in the bug and will get progress on Tuesday. I really don't think it needs somebody to dive into it before then especially since I think doko has other openjdk things he's been working on
<calc> wow nvidia appears to be taking a beating over their 8x00 and 9x00 cards
<dendrobates> cjwatson: I don't know if it was directly communicated in the bug report, but Theirry did say everything worked properly without it.
<calc> http://www.theinquirer.net/gb/inquirer/news/2008/08/28/nvidia-55nm-parts-bad
<cjwatson> it wasn't clearly communicated in the bugs I saw
<calc> i guess that is one way to make their lack of documentation not an issue (bankruptcy)
<calc> oh btw i found a patch to make OOo build with openjdk-6 :)
<cjwatson> I noticed that, the javascript engine stuff?
<calc> yea i think that is it, rhino
<calc> i didn't look into detail what it is used for
<calc> OOo ships its own hacked up copy
<BenC> jcastro: FYI, I can reproduce the screenlock hang on 2.6.26-5...what about you?
<jcastro> BenC: nope, I can't
<ScottK> slangasek: For future issues: I discussed KDE 4.1.1.  We expect 4.1.2 and possibly 4.1.3 to be coming into Intrepid at some point too.  Some of that will depend on how the 4.1.1 experience goes.
<slangasek> ScottK: noted, thanks
<mathiaz> slangasek: re bug 227744 - do you think it's worth doing a SRU for hardy ?
<ubottu> Launchpad bug 227744 in openldap2.3 "dapper upgrade to hardy: openldap silently refuses to start when unable to open SSL certificates - main: TLS init def ctx failed: -64" [Unknown,Confirmed] https://launchpad.net/bugs/227744
<slangasek> mathiaz: not on its own, no; seems possible to cover that in documentation rather well
<mathiaz> slangasek: ok - which documentation are you refering to ?
<slangasek> the server guide, for instance, plus wherever is most suitable to get the answer picked up by google? :)
<mathiaz> slangasek: it seems that this is upgrade instructions related - would the release notes be an approriate place ?
<mathiaz> slangasek: or the bug is enough ?
<slangasek> ah, I was thinking in terms of documenting that the permissions have to be right, rather than the upgrade issue
<slangasek> mathiaz: are there other openldap bugs that would be SRU candidates?
<slangasek> mathiaz: note I only said I don't think it's worth doing an SRU for on its own
<mathiaz> slangasek: may be - I'm going through the bugs in LP and move the relevant one from openldap2.3 to openldap
<mathiaz> slangasek: well - we may see another SRU for openldap.
<brandon|work> the 2.6.24-19-generic is compiled for what arch (like compared to the 2.6.24-19-[686-486])??
<Robot101> brandon|work: er, any x86 processor, that's what the genericness is
<brandon|work> ok, so it just isn't optimized for any given x86?
<mnemo> how can I list all the .SO files currently loaded into a process?
<sistpoty> mnemo: ldd on the binary gives you shared libraries loaded when starting if that's enough... otherwise I guess pmap might lead closer if the binary dlopens stuff
<mnemo> ldd works for the statically linked ones indeed, thanks
<mnemo> but I also need the dlopen'd ones
<mnemo> hmm
<sistpoty> mnemo: sorry, can't really give you help on pmap, haven't used it myself yet. or maybe lsof might help?
<sbeattie> pmap (which reads the contents of /proc/<pid>/maps) will be what you want I think.
<slangasek> lsof -p is the classic method
<mnemo> lsof -p `pidof X` also lists some non-.SO files under /proc
<mnemo> aahh, now I did "ps auxf" and I saw that the "X" process has a child process called x-session-manager
<sbeattie> yes, lsof is showing all the files currently open by the process.
<mnemo> and that's the one with all the .SO's loaded
<mnemo> so I was just looking at the wrong process
<mnemo> lsof -p `pidof x-session-manager` | grep -F .so
<mnemo> that one works for me
<mnemo> thanks a ton guys
<slangasek> kirkland: how are things looking wrt ecryptfs?  no problems surfacing with the pam stuff?
<mathiaz> kees: are you handling https://bugs.launchpad.net/ubuntu/+source/openldap2.3/+bug/250465 ?
<ubottu> Launchpad bug 250465 in openldap2.3 "CVE-2008-2952: BER Decoding Remote DoS Vulnerability" [Undecided,Fix released]
<kees> mathiaz: it's on my list, but haven't gotten to it yet.
<mathiaz> kees: ok - just checking that you have it because I've closed the bug for intrepid.
<kees> mathiaz: let me rephrase that...
<ericab> can someone help me with ubuntu quick?
<kees> mathiaz: http://www.ubuntu.com/usn/usn-634-1
<kees> mathiaz: (already done...)
<mathiaz> kees: great ! :)
<kees> mathiaz: you can check on per-CVE stuff here for example: http://people.ubuntu.com/~ubuntu-security/cve/CVE-2008-2952
<doggymenz> someone can fix this bug? https://bugs.launchpad.net/ubuntu/+bug/223829
<ubottu> Launchpad bug 223829 in ubuntu "Locale es-AR appears instead of es-ES in Firefox, and Firefox start page uses Google UK instead of use google.com" [Undecided,New]
<doggymenz> i think it can be fixed in 1 minute
<doggymenz> just change .co.uk to .com or something
<doggymenz> im not british, so i dont want use british google, cuz british are idiots they are responsible for driving on the wrong side of the road, spicegirls, and imperial measure system (feet, inch, yard, pound, etc)
<ScottK> doggymenz: Insulting people is not going to motivate them to fix your bug.  Rather the opposite.
<doggymenz> oh ok
<doggymenz> well, they should use .com since its neutral, instead of .co.uk with is specific to some users
<cjwatson> I have assigned your bug to the proper places, at least
<doggymenz> its not my bug, but thanks
<doggymenz> is it safe to run 'sudo update-initramfs -u' or will my computer break?
<smarter>  doggymenz: should be safe, if you didn't do anything nasty with initramfs scripts
<doggymenz> ok
<doggymenz> wow, lots of stuff happend
<doggymenz> just wanted usplash.conf updates
<doggymenz> someone can fix this bug?
<doggymenz> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269
<ubottu> Launchpad bug 246269 in linux-meta "Switched from vesafb to uvesafb, but uvesafb can't work without v86d" [Undecided,Invalid]
<Chipzz> LOL
<Chipzz> perl developers endorse ubuntu ;P
<Chipzz> http://use.perl.org/~nicholas/journal/37278
<Chipzz> :PPP
<slangasek> tseliot: do you have bug references currently, for the two nvidia drivers that don't work with 2.6.27?
<tseliot> slangasek: let me check, I have a lot of bug reports...
<tseliot> slangasek: nvidia 96 : https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-96/+bug/251107
<ubottu> Launchpad bug 251107 in nvidia-graphics-drivers-96 "[Intrepid] nvidia_drv.so: undefined symbol: AllocateScreenPrivateIndex" [Undecided,New]
<tseliot> slangasek: I have added nvidia 71 to that bug report since the problem is the same
<slangasek> tseliot: thanks, marked for release-noting
<tseliot> slangasek: good idea
#ubuntu-devel 2008-08-30
<Peaker> hey, how come building python package from source runs its unit tests like 5-6 times (or more)?  why run them at all, and then why re-run them?
<azeem> "why run them at all?"
<azeem> was that a serious question?
<Peaker> yeah - why run the unit tests as part of the build of the package?  they were run by those who distributed the source in that form
<Peaker> most sources don't have a UT to run when building the package...
<azeem> do you consider this a feature?
<slangasek> changes to build environments can (and do) introduce regressions.
<azeem> Peaker: the point of unit tests is testing the binaries
<Peaker> I think its for testing the source
<Peaker> the binaries will correspond to the source anyway, we have compilers we trust :)
<azeem> Peaker: welcome to the real world
<kees> Peaker: it's testing him in shared library form, static library form, maybe in other build ways
<azeem> also, welcome to different architectures, etc.
<Peaker> kees: does it ever get differing results ?
<kees> Peaker: yup
<Peaker> is there any way to cancel the unit tests?
<azeem> export DEB_BUILD_OPTIONS=nocheck
<azeem> might help
<Peaker> thanks
<azeem> well, not cancel, but disable
<slangasek> kees: hmm, do you know of any toolchain behavior changes between hardy and intrepid, that wouldn't show up as added CFLAGS?
<kees> slangasek: there was a lot of changes between gcc 4.2 and 4.3.
<kees> slangasek: 4.3 is MUCH pickier about C++ stuff especially.
<slangasek> but no deliberate behavior changes on C code, that you know of?
<slangasek> I'm trying to debug the milestoned sysklogd bug
<slangasek> I think, but haven't yet proven, that klogd is failing to call its internal openlog() implementation, the one that supports LOG_KERN
<kees> slangasek: I'm personally not aware of anything that wouldn't yell loudly duriung compile.  (4.3 is more strict about builtins)
<slangasek> but then when I've proven that, I'm still not sure *why* it's doing this
<kees> (gah, 2.6.27 keeps io deadlocking on me...)
<kees> (but only until I switch tasks or something hmpf)
<kees> slangasek: which bug #?
<slangasek> kees: bug #255635
<ubottu> Launchpad bug 255635 in sysklogd "Kernel messages not logged to /var/log/kern.log" [High,Triaged] https://launchpad.net/bugs/255635
<slangasek> build the same source on hardy, it works fine
<slangasek> (expected, the source hasn't changed much)
<kees> wait, built with the intrepid toolchain?
<kees> oh you meant build on hardy with intrepid source
<slangasek> yes
<kees> have you tried compiling with -U_FORTIFY_SOURCE ?
<kees> (on intrepid)
<slangasek> not yet
<kees> but I confirm -- my kern.log is empty.  :)
<kees> but it is getting into my messages file
<kees> I do see some warnings from fortify, but nothing that would seem to indicate this kind of magic.  http://launchpadlibrarian.net/16992758/buildlog_ubuntu-intrepid-i386.sysklogd_1.5-2ubuntu5_FULLYBUILT.txt.gz
<kees> slangasek: *sigh*
<slangasek> ?
<kees> CFLAGS aren't imported by upstream
<kees>         ${CC} ${SKFLAGS} ${SYSLOGD_FLAGS} $(DEB) -c syslogd.c
<slangasek> I know; how does that /break/ the build? :)
<kees> SKFLAGS= $(RPM_OPT_FLAGS) -O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce
<kees> no, but it's frustrating my attempts at -U_FORTIFY_SOURCE
<kees> and I love the use of RPM_OPT_FLAGS
<azeem> -DSYSV FTW
<slangasek> we could always fix this bug by replacing sysklogd with rsyslog
<wgrant> I would have thought we would be doing that anyway.
<kees> Aug 29 16:56:28 gorgon klogd: Kernel log daemon terminating.
<kees> Aug 29 16:56:30 gorgon kernel: Inspecting /boot/System.map-2.6.27-2-generic
<kees> somehow, it is fortify.
<slangasek> are you sure it's not glibc?
<slangasek> because my money is on glibc
<kees> well, fortify is all implemented in glibc, so yeah, I'd bet it's a bug in glibc too, but cramming -U_FORTIFY_SOURCE does fix the behavior.
<slangasek> well, except that I can't find any evidence of this in the glibc headers :)
<slangasek> heh, ok
 * kees wonders if there is a macro for openlog that causes the first arg to be ignored and replaced with argv[0]
<kees> hm, guess not.  wtf
<slangasek> no, but if I edit the syslog.c source to add a printf() to openlog, it only shows up if I build syslog.c with hardy
 * kees scratches his head
<slangasek> no, I take that back
<slangasek> I'm just confused because the printf() is dumped to syslog, and buffered very oddly such that it shows up at the end :)
<kees> slangasek: freaky -- it _is_ calling it with "kernel" as the arg (says the disassembly)
<kees> slangasek: is it something else that causes it to direct stuff from klogd into kern.log?  if I juse use "logger -t kernel" it all goes into messages too.
<slangasek> kees: logger -t kernel uses the glibc openlog() implementation
<slangasek> which doesn't permit LOG_KERN
<kees> what is klogd.c using?
<slangasek> (it selects by facility anyway, so even if glibc let you, you would have to use logger -p kern.foo)
<slangasek> it uses the openlog() implementation in syslog.c
<kees> ah-ha
<slangasek> so, recompiling just klogd.c on hardy fixes it
<kees> slangasek: yup, -U_FORTIFY_SOURCE only klogd.o fixes it for me too.  wtf.
<Peaker> its taking hours to build the python package, arrg
<slangasek> Peaker: so the question we've jumped right over, why are you rebuilding the python package?
<Peaker> slangasek: I thought it would be a quick way to test a source-level change I was contemplating
<Peaker> a bug that has been annoying me for more than a year now, I think
<slangasek> ah, well, good reason :)
<azeem> Peaker: so a bug that annoyed your for more than a year is not worth several hours of unattended cpu cycles?
<azeem> you*
<Peaker> azeem: it makes the debug/test cycle quite a long one
<Peaker> and its unnecessary :P
<azeem> Peaker: you don't need to start over each time I assume
<slangasek> well, yes; in that case, call ./debian/rules build, and don't bother moving things into packages after each test cycle?
<slangasek> s/after/for/
<kees> Peaker: did DEB_BUILD_OPTIONS=nocheck debuild ....  not work?
<slangasek> assuming that debian/rules build isn't the part that's getting stuck in the testsuite, that is
<Peaker> slangasek: does that avoid running the unit tests like DEB_BUILD_OPTIONS=nocheck does? or is that env-var still necessary?
<Peaker> kees: I haven't tried yet - I thought it would be wiser to let it finish building (I am not sure whether that was the right thing)
<azeem> Peaker: check debian/rules
<slangasek> you would still want to set that var, to be safe
<slangasek> or check, yes
<azeem> depends on whether they are run by build or binary
<kees> slangasek: fortify_source appears to be redirecting the syslog calls away from syslog.o
<kees> +                 U __syslog_chk@@GLIBC_2.4
<kees> +                 U __vfprintf_chk@@GLIBC_2.3.4
<kees>                   U __vsprintf_chk@@GLIBC_2.3.4
<kees> +                 U __vsyslog_chk@@GLIBC_2.4
<slangasek> ahh
<kees> at least, that's my guess
<slangasek> doh, I was staring so hard at openlog, I didn't think to look at syslog
<slangasek> yes, that stands to reason
<kees> slangasek: shall I upload it with that fixed?
<slangasek> just adding -U_FORTIFY_SOURCE for klogd.o?
<kees> yup.
<slangasek> yeah, go for it
<kees> donions
<slangasek> thanks
<kees> sorry for the glitch.  I blame everything on fortify_source first.  ;)
<slangasek> heh
<slangasek> thing was, I /knew/ about syslog_chk because I'd seen it in objdumps, and didn't think to look for a local syslog() implementation to go with the openlog one... :)
<kees> yeah, kind of a twisted source, klogd.  :P
<kees> now if only I could fix firefox to run with fortify_source....
 * slangasek grins
<wgrant> Aw, who changed "Yes, do as I say" to "I am aware that this is a very bad idea"?
<NCommander> Morning (or evening) wgrant
<wgrant> NCommander: Early afternoon, NCommander.
<NCommander> wgrant, I'm timezone challenged ;-)
<NCommander> wgrant, can I call on you to sponsor a FTBFS fix?
<slangasek> wgrant: hmm, in apt-get ?
<wgrant> slangasek: Yes.
<slangasek> aww
<wgrant> NCommander: Perhaps; depends how big it is. I'm mildly busy at the moment.
<NCommander> wgrant, relatively small debdiff, maybe 30 lines
<wgrant> I'd recommend going through the usual u-u-s mechanism.
 * NCommander will wait then
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/alsaplayer/+bug/262581
<ubottu> Launchpad bug 262581 in alsaplayer "FTBFS fix for alsaplayer" [Undecided,New]
<Awsoonn> Is there a better place to talk about intrepid?
<Awsoonn> are there any known issues wiht the latest intrepid kernel and the nvidia drivers?
<wgrant> A friend of mine had to remove and reinstall nvidia-177 to get it working.
<wgrant> But it apparently does work.
<Awsoonn> wgrant: any logs or other data i should grab before doing that?
<Awsoonn> thing that might be usefull to whoever works on that.. bryce maybe?
<wgrant> That's probably tseliot's domain.
 * Awsoonn wonders if he's around
<NCommander> wgrant, could you reset the build records on postfix on all architectures? Soyuz goofed and marked it failed vs. dep-wait.
<wgrant> That sounds mainish.
<wgrant> I'm not a core-dev.
<NCommander> I thought you were
 * NCommander hides
<NCommander> ScottK, are you around?
<ScottK> Breifly
<ScottK> Briefly even
<NCommander> Can I ask you to retry a build on Postfix?
<NCommander> (soyuz failed to mark it dep-wait and failed it instead)
<ScottK> Is mysql fixed?
<NCommander> yeah
<NCommander> I'm going through the build failure logs trying to find the ones that are dep-waits that are resolved vs. actual failures
<ScottK> Sure.  I'll try one arch and we'll see what happens.
<NCommander> Got to get that FTBFS count down ;-)
 * NCommander wants zero FTBFS if possible ;-)
<ScottK> Queued for retry.
<ScottK> I did amd64
<NCommander> THanks Scott
 * NCommander continues working on FTBFS fixes
<NCommander> ScottK, can you reset the build record on amarok-kde4 on sparc? It bombed with Bus Failure, so it seems that is a transient failure
<NCommander> hola LucidFox
<ScottK> Postfix worked.  Let me do the other archs fist.  Please give me a link for amarok-kde4
<NCommander> ScottK, http://launchpadlibrarian.net/16999884/buildlog_ubuntu-intrepid-sparc.amarok-kde4_1.90-0ubuntu1_FAILEDTOBUILD.txt.gz
<NCommander> Ideally, I'd like to resolve every single FTBFS in main :-)
<ScottK> NCommander: I need the package page, not the build log.
<NCommander> oh, d'oh
<NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/amarok-kde4
 * ScottK loks
<ScottK> looks
<ScottK> What about hppa?
<NCommander> Also, kde4bindings is another misidentified dep-wait, which was cleared (dep-wait python-qt4)
<NCommander> I keep the hppa tab hidden on qa's page
<NCommander> hold on
<NCommander> HPPA should be dep-wait, I'm not sure all the dependencies are in place
<ScottK> NCommander: If it's depwait and not FTBFS it'll take care of itself in time.
<NCommander> it does?
<NCommander> Wait
<NCommander> No, it should be dep-wait
<NCommander> but its not
<ScottK> Sure.  Depwait will undepwait and build in turn.
<ScottK> hppa was FTBFS.
<NCommander> Looking at the log, its dep-wait
<NCommander> Or it should be
<NCommander> It failed because not all its build-deps were installable
<ScottK> Yes.  I wonder about that, but that's how it works.
<ScottK> build-deps missing or insufficient version you get depwait.  Not installable, you get FTBFS.
<NCommander> It's a limitation in sbuild
<ScottK> I don't understand why we would want that.
<NCommander> Which I think is due to a limitation in apt-get
 * ScottK wonders if there's already a bug in soyuz on that.
<NCommander> Well, I'm asking cprov, because I know where changes have to be made in both apt-get, and sbuild to trigger the correct behavior
<wgrant> There's been a bug about it for some time.
<NCommander> From the way I understand it, the dep-wait status is triggered by sbuild's return code
<NCommander> I guess log-parsing determines what should be dep-waited on
<wgrant> Bug #160439
<ubottu> Launchpad bug 160439 in launchpad-buildd "Some builds fail when they should depwait" [Medium,Triaged] https://launchpad.net/bugs/160439
<ScottK> Fixing that would be high on my soyuz list.
<NCommander> Yup
<ScottK> If, of course, I'd been asked for a soyuz input.
<NCommander> What's MANUALDEPWAIT
<NCommander> I assume that means the build is just randomly retried vs waiting for a specific dependency
<wgrant> NCommander: I don't know why the MANUAL bit is there.
<wgrant> It's automatically retried when the missing build-depends appear.
<NCommander> Well, I know on Debian dep-wait is a status we, as buildd-maintainers have to set packages to automatically
<NCommander> I assume SOyuz is smart enough to determine proper dep-waits
<wgrant> Correct.
<NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/pigment - care running this one on amd64?
<NCommander> (a lot of these FTBFS are dep-wait mistakes)
<ScottK> Yes.  To get kde3.5.10 to build it took a LOT of retries due to this problem.
<NCommander> kdeutils also needs it on all archs expect HPPA
<NCommander> ScottK, https://edge.launchpad.net/ubuntu/intrepid/+source/kvkbd/0.5.99-0ubuntu1 - here too
<NCommander> ugh, your kidding, logwatch is still broken
<ScottK> NCommander: Done.  I'm off to bed.
<NCommander> Thanks
<moquist> my package (moodle) depends on moodle-postgres | moodle-mysql, and I'm writing separate postinst scripts for moodle, moodle-postgres, and moodle-mysql, which come from the same src pkg. moodle.postinst creates a config file that differs depending on whether moodle-postgres or moodle-mysql is installed.
<moquist> I don't know how I can (appropriately, non-hackishly) known in moodle.postinst which database is being used, without asking the user (which is an extra question that the user might get wrong, anyway).
<moquist> slangasek: I'm not going to put something in debconf that I can look up later, but that's the best way I can think to do this. :\
<moquist> ...or I could try to be clever and detect which database has been created...but that seems ridiculously over-complicated and error-prone.
<moquist> ogra: ping
<Eleaf> pong
<slangasek> moquist: you might want to look into wwwconfig-common
<moquist> this is in main; wwwconfig-common isn't allowed IIRC
<moquist> slangasek: I'm in the process of implmenting this using shared/moodle/db_<param>, and db_setting shared/moodle/db_server in moodle-<dbtype>.config...should I just stop now? :\
<slangasek> wwwconfig-common isn't currently present in main; that doesn't mean that it's better to reinvent the wheel if a solution exists that could be pulled in to main
<slangasek> I don't know if wwwconfig-common is considered unsuitable for main for some reason, but I think it's worth investigating
<moquist> slangasek: it is.
<slangasek> it is what? unsuitable for main?
<moquist> slangasek: the whole reason I ever touched this package in the first place was to get rid of the dep on wwwconfig-common (in gutsy days)
<moquist> yeah, unsuitable for main
<slangasek> hrm
<slangasek> why is it unsuitable?
<moquist> I don't know that.
<moquist> ogra might know more details; he got me started
<moquist> slangasek: I'll just finish what I'm doing and post it for review. at least I'll learn something from this, even if I end up undoing things.
<NCommander> Is there anyone who can retry universe builds for me?
<NCommander> Riddell, ping?
<Riddell> hi NCommander
<NCommander> Riddell, could you retry kdebindings? I've been running down FTBFS all morning, that one is a dep-wait misidentified as a failure :-)
<Riddell> what's that script called for retrying?
<NCommander> buildd
<NCommander> ALso dovecot if I can get main retrys out of you
<NCommander> (I've sorta been torturing MOTU for the universe all morning ;-))
<Riddell> NCommander: done
<NCommander> Riddell, thank you
 * NCommander hates transient failures
<NCommander> RainCT, as an aside, your update maintainer script broke on updating the changelog in intrepid
<RainCT> NCommander: uhm.. here it works. which error did you get? (and it's not mine, although I may have contributed to it)
<NCommander> no error
<NCommander> RainCT, its your name in the man file
<NCommander> Just no changelog entry
<RainCT> NCommander: "and this *manual page* by Siegfried"
<NCommander> whoops
 * NCommander slinks away
<RainCT> NCommander: and it doesn't add the changelog entry anymore. that was discussed in ubuntu-motu@ and it was decided(?) that it isn't necessary anymore to document that in the changelog file
<NCommander> oh
<NCommander> bah
<NCommander> Ok
<NCommander> Stupid question, what preprocessor symbol is defined on Linux
<NCommander> Riddell, you'll be happy to know that with the exception of lpia (and dep-wait on hppa), it appears kdebindings4 now properly builds on at least amd64/i386
<Riddell> yay
<NCommander> Riddell, I'm working on resolving the FTBFS on koffice, which appears to be longstanding
 * NCommander is going to try and get the FTBFS count on amd64/i486 to under 20, and the other architectures to be under 50 within universe (and main if any are still left there)
<NCommander> Riddell, BTW, where can I file bugs for changes to P-a-s?
<geser> NCommander: see the comment in P-a-s who to contact
<NCommander> I saw that
<NCommander> There is no Ubuntu specific P-a-s, is there
<NCommander> Mostly cause I can't see ubuntu specific packages getting in there like linux-lpia
<Riddell> P-a-s?
<NCommander> Packages-arch-specific
<NCommander> It tells the buildds what not to build.
<geser> NCommander: no, Debian and Ubuntu share a common P-a-s
<NCommander> bah
<crevette> hello
<crevette> is a Feature freeze request is necessary for package in universe ?
<azeem> universe is handled in #ubuntu-motu I believe
<crevette> I would like to request a sync for nemiver
<crevette> okay
<crevette> thanks
<NCommander> Riddell, do you know where I can download buildd chroots? I'm going to try and squash the SCons + buildd issue
<asac> tjaalton: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context)
<asac> tjaalton: (me trying X1950 with ati -> direct rendering: no)
<asac> tjaalton: doest it mean we have the wrong version of something?
<jcristau> asac: it means you have incompatible versions of the dri driver and libGL or X
<asac> jcristau: ok. so why do i get that in intrepid atM?
<asac> is there an upload pending?
<jcristau> you shouldn't get that
<asac> but i do ;)
<jcristau> libGL.so.1 and /usr/lib/xorg/modules/extensions/libglx.so should export _glapi_tls_Context
<jcristau> unless you've replaced one of them with the fglrx version, or something
<asac> ok ... lets check if that is diverted
<asac> cool
<asac> at least i had it installed ... which explains it i guess
<asac> jcristau: no success
<asac> still the same thing
<jcristau> asac: something's wrong, then :)
<asac> jcristau:  nm -D /usr/lib/xorg/modules/extensions/libglx.so |grep tls
<asac> 0000000000000008 B _glapi_tls_Context
<asac> 0000000000000000 D _glapi_tls_Dispatch
<asac> ok i think i have an idea
<asac> jcristau: ok i had clutter in /usr/lib/xorg/
<asac> thx
<kees> asac, fta: I think I found the problems with xulrunner/firefox's misuse of realpath() (it wasn't setting MAXPATHLEN correctly)  I've got the debdiffs in bug #263014 that fix it for me (I can run and use firefox with FORTIFY_SOURCE enabled).  Can you review it and let me know it qualifies for upload?
<ubottu> Launchpad bug 263014 in xulrunner-1.9 "fails to run when built with FORTIFY_SOURCE" [Undecided,New] https://launchpad.net/bugs/263014
<fta> kees, we have a patch in upstream bugzilla for a while
<fta> hold on, let me check
<fta> mozilla bug 412610
<ubottu> Mozilla bug 412610 in Startup and Profile System "MAXPATHLEN too small for glibc's realpath()" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=412610
<azeem> uh
<azeem> glibc's realpath() can deal without MAXPATHLEN, no?
<fta> kees, i expected this upstream patch to be committed long ago, that why i didn't use the patch. then i forgot about it :P
<fta> but upstream is not sure about the best approach
<fta> kees, btw, it's more widespread than you debdiff, there are several places where this MAXPATHLEN is needed.
<fta> youR
<fta> (and also several packages)
<kees> fta: ah, yeah, the upstream RH patch looks more complete -- can we use that?  I'd really like to actually fix the root causes since they are real issues.
<kees> fta: actually, the last patch looks very close to mine: https://bugzilla.mozilla.org/attachment.cgi?id=335369
<fta> kees, sure, I will grab the patch and merge it.
<kees> fta: and please revert the -U_FORTI...
<fta> yes
 * kees hugs fta
<fta> :)
<kees> fta: did you report the "cvs" problem too?  I can't find any notes on FORTIFY in "cvs" or "mozilla-devscripts".
<fta> i didn't, just in the wiki. it seems the problem disappeared since.
<kees> ah, very good.  I will drop it from the wiki for now then.
<fta> tseliot, this bug 259808 is killing me. Seems i'm not alone to have issues with 177.70
<ubottu> Launchpad bug 259808 in xorg-server "X Lockup in Intrepid (infinite loop)" [Undecided,Confirmed] https://launchpad.net/bugs/259808
<kees> fta: shall I assign you to 263014?
<fta> kees, yes please
<kees> fta: cool, done
<tseliot> fta: can you try with kernel 2.6.26 +177.70 and see if it solves the problem? If it doesn't you should report the problem to NVIDIA
<tseliot> actually, either way you should report to nvidia: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
<fta> tseliot, reported to nvidia.
<tseliot> fta: great, I hope they fix it before they release the driver as stable
<fta> tseliot, could I use 177.68 with 2.6.27-2 ?
<tseliot> fta: yes, sure
<fta> tseliot, it doesn't make any sense: I tried all variations of kernel 2.6.26-5 / 2.6.27-2 and nvidia 173.14.12 / 177.70, Xorg locks with mplayer/xv (not to mention corrupted consoles, corrupted display, corrupted boot splash, dead keyboard/mouse when gdm is doing autologin) Yet, i only started to see those X locks today with 2.6.27-2 & 177.70.. now it's everywhere. It has to be something else.
<leszek> hi
<leszek> where can I found the config / python file  where the default filesystem is set by ubiquity / partman !?
<leszek> is it in /home/leszek/Downloads/live/edit/usr/lib/ubiquity/ubiquity/components/partman.py !?
<leszek> aynone any idea on this partman default system question ?!
<leszek> anyone awake !?
<jpds> leszek: http://jldugger.livejournal.com/16594.html
<leszek> :)
<tseliot> fta: can you try with both the "vesa" driver and the "nv" driver? Just to make sure that it's a driver problem and not hardware problem
<cjwatson> leszek: it's not configurable, nor is it in python; it's set in shell code in /lib/partman/free_space/50new/do_option
<cjwatson> (in several places; it's not particularly designed to be easy to change that right now)
<cjwatson> leszek: p.s. don't reask your question three times in a 13-minute interval, please. It's excessive
<leszek> sry
<leszek> and thx ;)
<cjwatson> leszek: although as far as ubiquity's UI is concerned, the default for a new partition is effectively the first in numeric order in /lib/partman/valid_filesystems/, I suppose
<cjwatson> that might be easier to customise
<leszek> ah ok thx
#ubuntu-devel 2008-08-31
<TimStarling_> why are there so few debug symbol packages?
<TimStarling_> are we meant to make our own?
<wgrant> TimStarling_: http://ddebs.ubuntu.com. Also see https://wiki.ubuntu.com/DebuggingProgramCrash
<TimStarling_> thanks
<asac> fta_: can you ask for review and landing an such for the upstream bug (realpath=
<fta> top is acting strangely with the new kernel.. http://paste.ubuntu.com/42162/
<\sh> hmmm directfb is manual dep wait because of tslib..but tslib is universe...and directfb is main...is there a MIR ?
<pecisk> cdimages.ubuntu.com down?
<Adri2000> pecisk: works here
<persia> pecisk: I've heard of difficulties from others.  There are three IP addresses behind that name: you might try to get your local resolver to try a different one.
<pecisk> persia: how can I find those IPs?
<_MMA_> persia: Working fine again here. (for the moment)
<dmoerner> pecisk, it's not working for me either, and i keep hitting chromium.canonical.com (91.189.88.39)
<pecisk> yep
<pecisk> the same here
<dmoerner> pecisk, try beryllium.canonical.com
<pecisk> dmoerner: thanks, it worked
<NCommander> roughly speaking, what would it take to get Canonical to invest in allowing a port of Ubuntu?
<_MMA_> NCommander: What do you mean bu "port" and "allow"?
<_MMA_> *by
<_MMA_> port=derivative?
<NCommander> port as in ubuntu-powerpc, ubuntu-hppa, etc.
<NCommander> The port port :-)
<_MMA_> Ahh...
<_MMA_> So "allow"?
<NCommander> er
<_MMA_> There's nothing really stopping someone from building a disk.
<NCommander> To get it hosted on ubuntu-ports at the very least
<_MMA_> If thats what you want.
<NCommander> The problem is that only sourceful uploads are allowed
<_MMA_> Ahh... Hosting. More to the point. :)
<NCommander> Wlel, I've been told any port of Ubuntu unless allowed by Canonical can't bear the name Ubuntu
<NCommander> (its somewhere in the trademark legal goop, not interested in finding it ATM)
<NCommander> which of course makes sense
<_MMA_> Yet more details. :)
<NCommander> I know an Ubuntu armel port is in progress
<geser> in which port are you interested?
<NCommander> mips
<_MMA_> Yes. Anything you want to call "Ubuntu*" and hosting would need permission/help.
<NCommander> And maybe m68k-coldfire once freescale cleans up the toolchain
<NCommander> (m68k-coldfire is different from regular m68k :-P)
<_MMA_> NCommander: As far as disk hosting, I think resources are short. Do we have repos for mips?
<NCommander> No, not yet, I'm not actually going to do any porting until I find out more specifics first
<NCommander> My mips board is 133Mhz
<NCommander> Way too slow to do it
<NCommander> (although I have built GCC on it before ....)
<_MMA_> NCommander: It really might take you doing it yourself 1st.
<NCommander> Of course, I know that
<NCommander> I'd personally want an armel port, but I'm already told its in progress
<NCommander> But I figure if armel getting done, once I have a faster MIPS box, I might want to do a Ubuntu port on it
<_MMA_> Maybe a question for the tech-board?
<_MMA_> Well, this is more a Canonical issue.
<NCommander> Yeah
<_MMA_> (line it too blurry sometimes IMO)
<NCommander> I'm not so worried about the trademark, I won't remind naming the port
<_MMA_> s/it/is
<NCommander> But I'd like to see it on Ubuntu-ports if it got off the gorund
<NCommander> But to do that, Launchpad needs to host the autobuilders
<elmo> NCommander: err, no it doesn't?
<NCommander> Every port on ubuntu-ports handles buildd management through launchpad
<NCommander> I was under the impression canonical had to host the autobuilders themselves
<elmo> obviously, handling buildds through launchpad is the preferred way of doing things, but it's certainly not the only way
<NCommander> Right, wanna-build/buildd/etc works fine against Ubuntu
 * NCommander has run the former on amd64
<NCommander> Who's in charge of handling the Ubuntu-ports?
<NCommander> s/-//g
<woli> i
<woli> hi-
<woli> is there a tutorial on making panel-embeded aplications?
<Chipzz> woli: incorrect channel; please read topic
<philwyett> If any moderators of the ubuntu-devel list are in the house. Could you bump a few messages through please? I am already up to 3 awaiting being thrown back at me. :-D
<philwyett> Evening all by the way. ;-)
<cjwatson> philwyett: the content of two of your mails appears to be entirely quotation of other people's text. Is this accurate or is it the moderation interface lying to me?
<cjwatson> philwyett: if it's just the moderation interface cutting it off, OK, but please consider trimming your quotes to a more reasonable level; usually you should only quote the specific bit you're replying to
<philwyett> cjwatson: I did not trim the originals no and additional content is always at the bottom. I shall trim other words down in future.
<cjwatson> philwyett: in this case the length means I'm unable to review the additional content, which makes me uncomfortable about moderating it. Could you please resend with trimmed quotes?
<wgrant> Why is apport-gtk telling me that my copy of Ubuntu isn't genuine?
<philwyett> cjwatson: Yes I will resend trimmed. A bug should be filed about the restrictive moderation interface also. ;-)
<philwyett> cjwatson: Resent trimmed down. Thanks for moderating these for me.
<cjwatson> philwyett: done, thanks for the resend
<philwyett> cjwatson: No problem. Many thanks.
#ubuntu-devel 2009-08-24
<ebroder> Who do I need to annoy to get bug #369203 fixed?
<ubottu> Launchpad bug 369203 in python2.5 "Python2.5.4 curses.initscr() fails" [Undecided,Confirmed] https://launchpad.net/bugs/369203
<ScottK> ebroder: Is there a patch and a test case?
<ebroder> Sure. The patch is attached in my comment. The test case is `python -c 'import curses; curses.initscr()'`
<ebroder> I can edit the bug description to more clearly link to my patch if you'd like
 * ScottK didn't open the bug.  Let me look.
<ScottK> doko: What do you think about the proposed fix in 369203?
<ScottK> Let's wait a bit and see what that brings us.
<ebroder> Sounds good
<pitti> Good morning everyone! end of holidays, at last :)
<TheMuso> Hey pitti!
<pitti> hey TheMuso, how are you?
<TheMuso> pitti: Well thanks.
<thumper> anyone know the quality of the ati HD3450?
<thumper> I'm looking at a new laptop and can have either this or on-board intel
<thumper> wondering about upcoming KMS
<thumper> bryce: if you read the scrollback, ATI radeon hd 3450, good or not, KMS?
<dholbach> good morning
<highvoltage> good morning dholbach
<dholbach> heya highvoltage!
<highvoltage> had a good weekend dholbach?
<dholbach> absolutely - we had some friends here from Austria
<dholbach> how about yours?
<highvoltage> heh, I watched Sound of Music again Saturday afternoon, so saw some old Austria scenes and got an Austria fix as well
<dholbach> haha :-)
<highvoltage> visited that computer lab in that poor area I told you about saturday morning, it was going better there than I expected. it was nice seeing it in use, there was a class running on how to use gmail and search things on the internet.
<dholbach> cool - so they had no specific complaints?
<highvoltage> nope, there was a few computers that weren't set to boot from the network and that's why they weren't working, so I just showed them how to set the bios settings and that already fixed most of their problems
<highvoltage> I got the relevent contact details, I'll put them in touch with the ngo-interviewers
<dholbach> rock and roll :)
<stochastic> In Bug #416778 lool has requested some further public discussion on including the Jack audio server in Main.  I'm not sure where to initiate that discussion, is here appropriate?
<ubottu> Launchpad bug 416778 in libffado "main inclusion request for libffado" [Undecided,Incomplete] https://launchpad.net/bugs/416778
<stochastic> or is the bug tracker the best place for that conversation?
<StevenK> stochastic: ubuntu-devel-discuss@lists.ubuntu.com would be my suggestion
<tkamppeter> pitti, hi
<\sh> moins
<pitti> hi tkamppeter
<pitti> tkamppeter: BTW, we can change the pdftoopvp enabling to be an Ubuntu specific patch, then we can add it to the Debian trunk and drop the Ubuntu branch again
<pitti> I'll do that soon
<tkamppeter> pitti, OK
<tkamppeter> pitti, I have discovered that CUPS now does not only have 2 libs (libcups, libcupsimage), but 4 new libs added (libcupscgi, libcupsdriver, libcupsmime, libcupsppdc). Do we need 8 additional binary packages (including -dev) now?
<mvo> could someone please have a quick look at http://launchpadlibrarian.net/30714313/zlib_1.2.3.3.dfsg-13ubuntu2.debdiff if that looks ok?
<mvo> (context is bug 402178)
<ubottu> Launchpad bug 402178 in zlib "gzopen64 implicitly converted to pointer" [Undecided,New] https://launchpad.net/bugs/402178
<pitti> tkamppeter: I think for now we can probably keep them in libcups, unless they have different SONAMEs (or likely to get different ones in the future)
<pitti> tkamppeter: ah, just saw your 1.4 updates
<tkamppeter> libcups has SONAME 2, all the new ones SONAME 1.
<StevenK> That sounds like the SOVER, not SONAME
<pitti> tkamppeter: then the new ones need a new package
<pitti> StevenK: SOVER?
<tkamppeter> I have done everything to make the new CUPS build: adapted patches, taken a patch from Red Hat to make the new dnssd backend build (the original uses an API which is probably not available under Linux), adapted the PDF filter package to work with both 1.3 and 1.4, fixed small bugs in the new CUPS, ...
<tkamppeter> StevenK: pitti called this SONAME in a conversation with robert_ancell on #ubuntu_desktop.
<pitti> tkamppeter: thanks muchly
<tkamppeter> pitti: Remaining is now to obsolete cupsddk and to distribute the files to the binary packages of CUPS and to package all the new libraries.
<tkamppeter> pitti, if you make a conditional patch to solve the pdftoopvp problem, can you make it in a way that it applies only to Debian and not to Ubuntu, this way one can have the debian/local/filters/pdf-filters being exactly the upstream tarball.
<pitti> tkamppeter: yes, I can also do it the other way around ("disable-pdftoopvp.dpatch")
<pitti> tkamppeter: I won't actually check for "Ubuntu", I'll check the version number of poppler
<liw> pitti, hmm... I have devicekit-disks 006-0ubuntu1 installed, but I still get the dialog that wants me to mount an unmounted partition on my hard disk
<pitti> liw: right, that's expected; gvfs doesn't yet use the new "no interactive" option
<pitti> there's a gvfs task still open
<liw> pitti, ok, then I'll wait some more
<tkamppeter> pitti, this is even better
<soren> lool: Hey. Thanks for your work on euca2ools!
<soren> lool: The binary depends on pyton-boto 1.8a, but we're at 1.7c. Can you sync 1.8a from Debian?
<pitti> soren: he can't, but I can
<soren> pitti: Oh, lovely. Thanks!
 * soren thought lool was archive admin
<StevenK> He's in ubuntu-mir, but he isn't an archive admin
<soren> Ah.
 * soren is having trouble keeping up with people's hats.
<liw> is there a tool to compare two versions of the same lib*.so and see if there are changes in the exported symbols?
<pitti> liw: hm, diff the nm -D output?
<dholbach> or use check-symbols from the ubuntu-dev-tools package?
<soren> pitti: \o/ Thanks for the boto sync.
<pitti> soren: de rien
<dholbach> nm -D <lib1> | cut -d' ' -f3 | sort -u > lib1; nm -D <lib2> | cut -d' ' -f3 | sort -u > lib2; diff -u lib1 lib2
<pitti> dholbach: do you know bash's <() trick?
<pitti> diff -u <(nm -D ...) <(nm -D ...)
<dholbach> how'd you rephrase it?
<dholbach> ah
 * dholbach needs to try that
<pitti> pretty handy to work without creating temporary files
<pitti> <(command) runs command in a pipe and its stdout becomes a file name-like argument
<dholbach> although the mighty slangasek says that objdump -T or readelf -s would be better than nm -D
<dholbach> https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/184906
<ubottu> Launchpad bug 184906 in ubuntu-dev-tools "check-symbols should use something other than nm -D" [Wishlist,Confirmed]
 * pitti bows to slangasek's ELF skills
<mpontillo> remember to pass -W to 'readelf' - otherwise long symbol names can get cut off!
<liw> . o O (nothing is ever easy with shared libs, is it?)
<dholbach> probably best to just read the diff ;-)
<tkamppeter> pitti, any suggestion about the library packaging for CUPS?
<pitti> tkamppeter: as I said, if they have a different soname, they need a new package
<pitti> tkamppeter: will any other program actually use these libraries, though?
<tkamppeter> pitti, that is the case.
<tkamppeter> pitti, currently most probably not.
<lool> soren, pitti: I had filed a sync request saturday though
<soren> lool: I wonder why I didn't see that..
<soren> lool: Oh, right, I decided not to wait for Launchpad to load because I (mistakenly) "realised" that you were an AA and could have done it yourself if you wanted.
<lool> soren: I think I saw no subscriber to euca2ools bugmail either
<soren> lool: No, I hadn't gotten around to that yet.
<soren> (it was only synced on Friday)
<lool> I mean that explains you didn't see the sync bug
<soren> Oh, right, right.
<lool> I sent the changes to the euca folks in the changelog and at the top of /Makefile BTW
<lool> Didn't get any answer yet but that was over the WE
<mvo> slangasek: what is your opinion on bug #414943 ? do you think its important enough to add code to update-manager to check for this situation (that the user has a old kernel as default in his grub.cfg?)
<ubottu> Launchpad bug 414943 in update-manager "update-manager/grub should warn about old kernels ahead of the automatically generated ones" [Low,Triaged] https://launchpad.net/bugs/414943
<cjwatson> mvo: thanks for clearing up that lsb_release bug!
<mvo> cjwatson: my pleasure :)
<tkamppeter> pitti, what about creating packages libcups-extra1 and libcups-extra-dev for the 4 extra CUPS libraries?
<pitti> tkamppeter: they all have soname 1? "extra" sounds a bit weird, maybe pick one of the existing names?
<tkamppeter> They are all of soname 1, but picking one of the lib names is also not good, they are completely different.
<pitti> tkamppeter: however, I don't really like "extra", it's a hack; either we put them all into an existing package, or we should package them properly
<tkamppeter> putting them into "cups" is bad, as then a program only needing one of the libs would pull in the CUPS daemon.
<pitti> tkamppeter: there's no way to statically link them to cupsd, until other programs actually need them?
<pitti> well, other binaries might need them as well
<pitti> seems there's no really good way of avoiding 4 new libs :/
<tkamppeter> pitti, they can also be used by CUPS clients on a daemon-less server
<pitti> right
<tkamppeter> Or by PPD-generating programs, imagine the CUPS daemon would run on OpenPrinting, only because there is a program generating driver packages.
<tkamppeter> pitti, now I discovered that there is a package named cups-common, I could put the libraries there.
<pitti> tkamppeter: no, that's arch:all, and not meant for libraries
<pitti> tkamppeter: let's just package them properly instead of wasting time on ugly and policy breaking hacks which we'll need to fix later anyway
<tkamppeter> pitti, I could switch that to arch:any
<pitti> once one of the libs changes ABI, it would break everything
<tkamppeter> So I will make real library packages. Even if these libraries are not meant as API libs for apps, sooner or later someone will use them and then we have to change our packages to avoid side effects.
<ogra> pitti, hey, what is supposed to provide IRC in the default install ? testing my armel images i cant find anyone
<ogra> s/anyone/anything/
 * ogra wonders if armel is missing something, given that much of out user support is centered around IRC i cant imagine we dont have it by default
<pitti> ogra: we don't have IRC right now; we'd need to install telepathy-idle for that
<pitti> it's a known issue
<pitti> you can install it in the live system, of course
 * pitti -> lunch
<ogra> pitti, but we'll pull it in ?
<ogra> (later)
<pitti> ogra: probably, yes
<ogra> i would see it as a large regression to not have IRC by default
<ogra> enjoy your lunkc, thanks
<ogra> *lunch
<Laney> Is there any way to retry a build which was attempted on a previous release, short of an upload?
<sistpoty|work> Laney: you mean as in binNMU?
<Laney> no, there was an FTBFS which was attempted in Jaunty
<Laney> I was wondering if it could be tried again under Karmic
<Laney> give-back
<sistpoty|work> Laney: ah, no idea actually then
<cjwatson> err, it ought to have had a karmic build record created, I'd've thunk
<cjwatson> ask #launchpad?
<Laney> doesn't seem to have
 * Laney moves over there
<ogra> does anyone see a reason why Arch: all packages wouldnt be built with a debian/control like: http://paste.ubuntu.com/258590/
<cjwatson> debian/rules is relevant too
<ogra> well, rules is pretty empty
<Cyberkilla> Hello, does anyone here know anything about the nvidia drivers in karmic a4?
<ogra> http://paste.ubuntu.com/258615/
<Cyberkilla> For some reason, 185.18.31, 185.18.36 and 190.x.x give me artifacts, then system crashes (laptop resets itself).
<cjwatson> ogra: debian.mvl-dove/rules then
<cjwatson> follow the yellow brick road
<Cyberkilla> I had to revert to 185.18.14.
<Cyberkilla> You're speaking in riddles to eachother:O
<ogra> http://paste.ubuntu.com/258616/
<cjwatson> not especially
<ogra> right, the dove rules are a bit more intresting :)
<cjwatson> ogra: now you need to find which of the included files defines the binary-indep target
<Cyberkilla> It is an NVidia GeForce 8400M GT, inside of a Sony Vaio VGN-AR41E laptop
<cjwatson> Cyberkilla: I don't know anything about this but perhaps generic advice is better than nothing. https://wiki.ubuntu.com/X/Reporting has general advice on reporting good-quality X bugs that contain a decent amount of information, and links to some pages with more details. #ubuntu-x may have more experts paying attention, although not necessarily right at this moment
<Cyberkilla> Thanks a lot. I appreciate your response: )
<ogra> hmm, looks ok to me, it properly calls the dbheper commands with -i ... unless the package names dont get handed over i dont see why it wouldnt even attampt a build
<ogra> though, hmm, i wonder if the "build-indep:" at the top prevents it somehow
<ogra> http://paste.ubuntu.com/258619/
<stefanlsd> pitti: are you ok if i upload the calibre stuff i've done?
<ogra> seems to be an empty target
<pitti> stefanlsd: sure; I need to commit all the changes back to the debian bzr branch anyway, a couple of more changes don't make a big difference
<pitti> stefanlsd: we should have an Ubuntu branch probably, since I can't upload 0.6 to Debian right now (blocked on doko's magic --install-layout=deb change in python2.5)_
<doko> pitti: ???
<stefanlsd> pitti: ok, great. wont we get a branch now with james_w import stuff anyways?
<pitti> oops, sorry, that was meant to be "2.6 available in experimental"
<pitti> doko: sorry, the --install-layout=deb change was just blocking the cdbs distutils.mk fix
<pitti> not calibre
<pitti> stefanlsd: yes, but please don't use it
<pitti> for packages which already have a bzr branch, the auto-import stuff is pretty useless
<doko> ahh, ok
<cjwatson> ogra: build-indep is probably irrelevant
<ogra> well, the main file calls it, but comparing to the generic kernel package its identical
<cjwatson> ogra: I suggest setting DH_VERBOSE=1 and going through the output with a fine tooth-comb
<ogra> well, thats more than i want to do personally, its actually rtg's package, but he is "fixing" it by just dropping all Arch: all packages, i thought i could find something obvious to suggest
<ogra> i dont mind losing Arch:all -headers ... and -docs should be identical to the mainline kernel anyway
<ogra> -source concerns me a bit if users want to cross build kernels for armel SoCs though
<cjwatson> I sympathise but am unlikely to have a chance to figure this out, sorry
<cjwatson> of course the debhelper commands that are called with -i are not the only relevant parts; you need to make sure that something is actually installed into the package build directories too
<ogra> yeah, i would have asked "cjwatson can you help with ..." if i really wanted you to help solving it ;) thanks a lot for the pointers though :)
<ogra> dont want to keep you from your actual work ;)
<ogra> i'll discuss with rtg
<cjwatson> that's ok, I just wanted to make it clear that I was disengaging rather than just going silent :)
<ogra> slangasek, rtg claims the "Arch: all" packages of linux-fsl-imx51 were not built because you objected, i dont see how you would technically have been able to prevent them from building nor why they wouldnt have at least been in the NEW queue, can you tell me anything about that ?
<tkamppeter> pitti, which maintainer scripts are needed for library packages? AFAIK one has to call "ldconfig" after installation and after removal. Or is this done automatically, without needing an explicit maintainer script?
<pitti> tkamppeter: don't add explicit scripts, dh_makeshlibs will care about it
<tkamppeter> pitti, then I can perhaps remove some superfluous scripts from the CUPS package.
<cjwatson> dh_makeshlibs> assuming that you have the #DEBHELPER# token in any explicit maintainer scripts you do have in the source package
<cjwatson> (obviously if you don't have explicit maintainer scripts in the source package then there's no need to add them just for #DEBHELPER#)
<tkamppeter> pitti, debian/libcups2.postinst and debian/libcupsimage2.postinst do nothing more than providing #DEBHELPER#, so they can get removed.
<pitti> tkamppeter: correct, they are just cruft
<happyaron> pitti: hi, I've replied to that bug about tor
<lool> Hey who's administering http://qa.ubuntuwire.com/ ?
<lool> I'd like to get a package or two installed to fix http://qa.ubuntuwire.com/uehs/no_updated.html
<lool> It's lacking the perl ssl support libs to use https
<ogra> lool, i think that was siretart once, not sure thats still true though
<sistpoty|work> lool: you can ask at #ubuntuwire or write a mail to admin@lists.ubuntuwire.com
<geser> lool: or ask wgrant
<lool> sistpoty|work: thanks
<lool> Too many people to ask  :)
<lool> I prefer shooting an email
<sistpoty|work> heh :)
<ogra> why ? many people means many options to pick your favorite answer *g*
<sistpoty|work> or many possibilities to say "no, I'm not responsible..." *g*
<highvoltage> Riddell: heh, in Africa, "eina" means "ouch"
<highvoltage> (just saw it coming through karmic-changes)
<tkamppeter> pitti, is bug 418097 really a CUPS bug?
<ubottu> Launchpad bug 418097 in cups "package cups-client 1.3.11-1ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/doc/ia32-libcups2/changelog.ia32-libs-tools', which is also in package cups-bsd" [Undecided,New] https://launchpad.net/bugs/418097
<tkamppeter> pitti: Or is it of ia32-libs providing 32-bit libcups2?
<pitti> tkamppeter: looks like an ia32-libs bug; cups itself doesn't build 32 bit libs on amd64
<happyaron> pitti: hi, if only for hardy to karmic, or rather say in 4-5 releases, I can do it.
<kirkland> NCommander: ping
<kirkland> NCommander: what's the status with the kvm backports to hardy/intrepid ?
<kirkland> NCommander: those have been sitting there for a while, now
<NCommander> kirkland, let me check, libvirt should have gone through, its been in the NEW queue for awhile
<sistpoty|work> kirkland: I just took a glance at qemu-kvm... are the sources of the bios files in pc-bios somewhere in the package? I can't find the source for openbios-* for example
<kirkland> sistpoty|work: lemme check
<sistpoty|work> kirkland: thx
<kirkland> sistpoty|work: i'm just responding to your email about qemu-kvm on -devel
<sistpoty|work> kirkland: cool, thanks :)
<kirkland> sistpoty|work: thanks for looking at that package; i *welcome* more eyes on it :-)
<sistpoty|work> sure thing, no problem ;)
<kirkland> sistpoty|work: the source is at http://www.openfirmware.info/OpenBIOS, though upstream qemu is releasing those as blobs in 0.11
<cr3>  /join #python
<cr3> nice! :)
<sistpoty|work> kirkland: hm... that's gpl-2, right? can we distribute it that way in ubuntu then?
<kirkland> sistpoty|work: hmm, well qemu is GPLv2 and LGPL
<NCommander> cjwatson, any archive admin, can you please promote the linux-mvl-dove udebs so d-i can build? The kernel itself got kicked to main, but the udebs are still in universe
<sistpoty|work> kirkland: yep, but I mean the bios... don't we as ubuntu have to make the sources available or offer s.th. written then? (I'm no licensing expert though)
<cjwatson> NCommander: done
<NCommander> cjwatson, thanks, I'll have a revised branch that has been fully test built for you ASAP
<doko> ScottK: looks ok
<ScottK> doko: Thanks.
<kirkland> sistpoty|work: hmm, i'm not sure about that one ...  qemu and kvm have always shipped at least some bios.bin's as prebuilt bios blobs;  I'll have to check under what conditions this has been approved in the past
<sistpoty|work> kirkland: I think if the source from which a prebuilt blob is available in the package, that would work... but as I wrote, I don't have too much clue with legalize ;)
<sistpoty|work> is available along with the blob even.
<kirkland> sistpoty|work: so you're suggesting I grab that source, and drop it in the debian dir and debian/copyrights for good measure?
<sistpoty|work> kirkland: yes, but the tough thing is to make sure that it matches the blob. and I'm suggesting to ask someone who knows for sure ;)
<kirkland> sistpoty|work: the other option is to add --disable-blobs to the ./configure optiosn
<sistpoty|work> kirkland: and to remove it from the source tarball, yes, if it's still working then
<kirkland> sistpoty|work: well, it would break some of qemu's arches, IIUC
<_sick> anyone knows if the idb (intel debugger) works with the gdb machine interface ?
<sistpoty|work> kirkland: hm... :/
<kirkland> sistpoty|work: talking with the qemu maintainers privately right now, they feel that they're covered, because one of the qemu maintainers is also an openbios maintainer
<kirkland> sistpoty|work: and their intention is to ship the source of the openbios blobs in 0.12
<sistpoty|work> kirkland: oh, cool :)
<kirkland> sistpoty|work: but 0.12 is karmic+1
<kirkland> sistpoty|work: they're in 0.11-rc1 right now ... i just asked if they'd add the openbios sources to -rc2 ...  discussing now
<kirkland> sistpoty|work: qemu upstream says shipping those sources in -rc2 is probably not going to happen;  i'd need to drop them in our package
<mathiaz> jdstrand: bug 407428 - this is a hard one
<ubottu> Launchpad bug 407428 in openssh "sshd zombie processes and strange behavior after karmic upgrade" [High,Confirmed] https://launchpad.net/bugs/407428
<jdstrand> mathiaz: yes it is. I haven't found a reproducer yet
<jdstrand> mathiaz: I've tried for some time, off and on
<mathiaz> jdstrand: yeah - I run into this one all the time
<jdstrand> me too
<mathiaz> jdstrand: when I clone vm
<mathiaz> jdstrand: and they start for the first start, I run into this issue
<mathiaz> jdstrand: but I haven't been able to reliably reproduce it
<jdstrand> mathiaz: does it happen every time you clone a vm?
<mathiaz> jdstrand: yes
<mathiaz> jdstrand: if I reboot the vm, it's gone - sometimes
<jdstrand> mathiaz: maybe the bug can be triggered when ssh notices a new interface and starts listening on it
<jdstrand> mathiaz: oh, in the vm or the host do you see this?
<mathiaz> jdstrand: in the vm only
<jdstrand> ok, nm my comment then
<tkamppeter> pitti, I have completed the packaging of CUPS 1.4.0 now.
<tkamppeter> pitti, can you now add the conditional patch for deactivating pdftoopvp in Debian and then upload the resulting package to Debian and Ubuntu. Thanks.
<pitti> tkamppeter: great, thanks!
<pitti> tkamppeter: yup, on my list
<tkamppeter> pitti, another problem is that we now have to blacklist the usblp kernel module. How should this be done? Should CUPS add a config file to /etc/modules.d for doing that or should it simply be part of the default configuration for the kernel modules?
<tkamppeter> With the module loaded the "usb" CUPS backend does not see any printer.
<pitti> tkamppeter: blacklist? why?
<pitti> tkamppeter: oh, so that the module doesn't grab the raw device?
<pitti> tkamppeter: ideally we'd just not build it at all in the kernel
<pitti> tkamppeter: but that's an issue in Debian as well then
<tkamppeter> pitti: Yes.
<pitti> it just seems like a bad design to me, though
<pitti> tkamppeter: I guess for now we need to add it to the default blacklist in module-init-tools, yes
<tkamppeter> pitti, OK.
<pitti> ok, need to run (dinner and Taekwondo), see you all tomorrow!
<tkamppeter> pitti, it is really a bad design, a good usb backend would work both with and without usblp kernel module.
<NCommander> cjwatson, publisher runs every hour, on :03, right?
<ScottK> Last I heard publisher runs were taking over an hour to finish though (this may have been fixed).
<mathiaz> james_w: hey - are you going through the NEW queue?
<mathiaz> james_w: and rejected merb?
<james_w> yeah
<cjwatson> NCommander: yes
<NCommander> cjwatson, hrm, then the udeb should be in main now, no?
<mathiaz> james_w: the reason for rejection was the inclusion of spec testing?
<james_w> mathiaz: I rejected it as I sponsored a newer version in to NEW
<mathiaz> james_w: oh - cool
<mathiaz> james_w: does this mean that merb has been accepted now?
<NCommander> cjwatson, I'm just wondering if udebs are special w.r.t. to promotion and such
<cjwatson> ScottK: that was fixed - they're down to a bit over half an hour now - but the publisher is crashing
<ScottK> cjwatson: Thanks.  Good to know (the fixed part anyway).
<cjwatson> NCommander: they're not special, the publisher's crashing
<NCommander> cjwatson, oh. bah :-/
<NCommander> cjwatson, sorry for the noise, I was just wondering what was going on
<james_w> mathiaz: no
<james_w> mathiaz: I don't have time to complete the review today
<mathiaz> james_w: ok - so there is a new version of merb in the NEW queue that fixes the issue you've found?
<james_w> yeah
<mathiaz> james_w: but you won't have to process the NEW queue today?
<james_w> it's a repacking to remove all the embedded code
<james_w> well, I've spent a few hours on it today
<james_w> so it's that I want to do some other things today
<mathiaz> james_w: sure :)
<mathiaz> james_w: thanks for sponsoring a new upload of merb :)
<james_w> np
<mathiaz> jtimberman: ^^ - so your last upload to REVU for merb is already in the NEW queue (ie has been sponsored by james_w) ?
<jtimberman> Guess so, I haven't seen an email about that from the system.
<james_w> it is
<jtimberman> mathiaz: i fixed the issue it was rejected for, and a new issue james_w found.
<jtimberman> does that mean it still needs archive admin review and upload to the universe?
<james_w> yeah
<james_w> https://edge.launchpad.net/ubuntu/karmic/+queue
<jtimberman> Ahh
<jtimberman> oh, stompserver is in the queue.
<mathiaz> jtimberman: right - merb and stompserver are already in the queue
<mathiaz> jtimberman: and chef needs another advocation
<mathiaz> jtimberman: ^^ is that accurate picture of the chef packaging effort?
<mathiaz> jtimberman: coderay and libsyntax are available in karmic
<jtimberman> mathiaz: stompserver was rejected on Friday and I uploaded it fixed on REVU, is the one in the queue the right one?
<jtimberman> mathiaz: stompserver was rejected, and i uploaded the new version to REVU that fixed the blocking issue.
<jtimberman> mathiaz: i see it as rejected on the queue too, does it need a new upload to NEW?
<mathiaz> jtimberman: meh - I don't know
<mathiaz> jtimberman: the times are all different
<jtimberman> one time zone to rule them all.
<mathiaz> jtimberman: I can't figure out whether I've uploaded the latest
<mathiaz> jtimberman: let me look into that a bit later.
<jtimberman> mathiaz: okay.
<slangasek> ogra: er, I never said to not build the Architecture: all packages - are we playing telephone, here?
<ogra> slangasek, well, something is wrong
<ogra> the 300.4 package had three Arch: all packages
<ogra> but they werent picked up anywhere for build it seems
<ogra> doing a local armel build they appear
<ogra> ogra@dove:~/linux-mvl-dove-2.6.31$ ls ../*.deb
<ogra> ../linux-headers-2.6.31-200_2.6.31-200.4_all.deb         ../linux-image-2.6.31-0-dove_2.6.31-0.1_armel.deb      ../linux-mvl-dove-doc_2.6.31-200.4_all.deb
<ogra> ../linux-headers-2.6.31-200-dove_2.6.31-200.4_armel.deb  ../linux-image-2.6.31-200-dove_2.6.31-200.4_armel.deb  ../linux-mvl-dove-source-2.6.31_2.6.31-200.4_all.deb
<slangasek> ogra: then you're not doing a proper local armel build the way the buildds do.  The buildds only build Arch: all packages on the i386 buildd
<ogra> i'll try buiulding the package on a i386 machine, but i suspect we hit a soyuz bug or some weird PAS wildcard setting
<ogra> yes, i know how our infrastructure works :)
<ogra> i did the local build to exclude packaging bugs
<slangasek> the relevant detail here is https://launchpad.net/ubuntu/karmic/+source/linux-fsl-imx51/2.6.31-100.7 showing only armel in the 'builds' tab
<ogra> but our infrastructure seems to not like that setup
<ogra> 100.7 has all ARCH: all packages dropped
<ogra> that was rtg's workaround for now
<ogra> 100.4 and 100.5 had them enabled
<slangasek> er
<ogra> ah, no only 100.4
<ogra> there seem to be no build attempts on i386 for 100.4
<slangasek> I don't see why he would have dropped the doc and source packages
<ogra> and i think thats either soyuz or PAS
<ogra> yes, i wanted to keep -source :(
<slangasek> (the headers package, yes, I did say there was no point in having the headers split between two packages)
<ogra> for people cross compiling the kernel packages
<ogra> i dont care about .docs
<ogra> *-docs
<ogra> since i assume there is nothing added to the fsl version
<ogra> keeping -source would have been nice and i'd like to see it coming back ...
<slangasek> it doesn't matter whether there's anything added - you want the -docs package built so that the -docs package matches the kernel package and can be pulled in via linux-meta
<ogra> anyway, do you have an idea what blocks them from building on i386 ?
<ogra> slangasek, well, rtg sees the issue as resolved and i couldnt convince him of the opposite
<slangasek> ogra: it's not P-a-s, so you'll have to ask soyuz folks
<ogra> ok, thanks for looking
<ogra> hmm, wasnt there a dedicated soyuz channel ?
<al-maisan> ogra: yes, #soyuz
<al-maisan> on the Canonical Ltd. server
<ogra> heh, i meant a public one :)
<ogra> doesnt seem like though
<al-maisan> try #launchpad then, and ping cprov :)
<cjwatson> the publisher seems like it might be running again, so we'll see
<james_w> cjwatson: hi, is there anything special to watch out for with -di packages in NBS?
<james_w> there's a whole bunch in there currently, and I didn't clear them out earlier with the rest as I didn't want to create havoc
<cjwatson> james_w: don't process them yet, I have a d-i upload in the works to move to -6
<cjwatson> NCommander: are you waiting for this publisher run in order to do a test build?
<james_w> so my wariness was well placed :-)
<cjwatson> NCommander: you could just add universe/debian-installer to UDEB_COMPONENTS in build/config/common
<ogra> cjwatson, now that the mvl and fsl kernel packages are in main, is there anything special we need to do for d-i to pick them up ?
<NCommander> cjwatson, ah
<mathiaz> jtimberman: the stompserver package sitting in the NEW queue is the last one you've uploaded to REVU (fixing the issue from the first rejection)
<ogra> they both should have the proper naming scheme now
<cjwatson> ogra: stuff like what NCommander's doing for dove, presumably
<jtimberman> mathiaz: cool, thanks for checking!
<ogra> well, that had happened for imx51 already
<ogra> unless you dropped it :)
 * ogra hugs lamont for ARMv7 buildd love 
<ogra> and you even doubled the amount !!!
<lamont> ogra: 4 -> 6 isn't double. :-p
<lamont> one more inbound though - look forward to seeing korlan
<lamont> and a rimu replacement
<ogra> it was 3 for nearly all of the last 6 months
<lamont> and then we get more
<cody-somerville> doh. The latest nvidia updates broke my X.
<ogra> the fourth one was rarely seen online
<ogra> cody-somerville, get proper hardware :P
<cody-somerville> ogra, whats considered proper hardware these days? :P
<ogra> intel ?
<cody-somerville> no thanks
<ogra> no probs here even with external 1920x1200 LCD
<lamont> ogra: yeah - podocarpus was offline for much of that
<ogra> yup
<mathiaz> james_w: http://paste.ubuntu.com/258796/ <- have you already seen this?
<mathiaz> james_w: I was trying to import an upstream tarball in a bzr branch
<cjwatson> ogra: sure, it needs one set of config files per subarchitecture
<james_w> mathiaz: I think so, one minute
<ogra> cjwatson, well, then i assume imx51 is fine from jaunty still
<ogra> though we might have to add hardware detection strings for the newer babbage boards, i will have to compare them
<cjwatson> ogra: yes. mvl == dove, fsl == imx51?
<cjwatson> (ish)
<ogra> right
<ogra> fsl is only in the source package names
<ogra> the binaries should be mainly compatible to jaunty
<james_w> mathiaz: yeah, that should be fixed in the next upload
<james_w> mathiaz: remember you found that problem with the spurious conflicts when merging from Debian?
<mathiaz> james_w: when is the next upload schedule?
<mathiaz> james_w: or is there a version available from a PPA?
<mathiaz> james_w: for testing?
<mathiaz> james_w: yes
<james_w> mathiaz: that will now be gone if you use the merge-package command, thanks to al-maisan
<james_w> I can upload now
<mathiaz> james_w: \o/
<mathiaz> james_w: that would be great
<al-maisan> :)
<mathiaz> james_w: so another question
<mathiaz> james_w: there is an upstream bzr branch as a git import
<mathiaz> james_w: https://code.launchpad.net/~vcs-imports/sssd/trunk
<mathiaz> james_w: I've been working on packaging it - lp:~mathiaz/sssd/ubuntu-pkg
<mathiaz> james_w: and doing daily builds of the upstream branch using bzr builddeb
<mathiaz> james_w: as a native package
<mathiaz> james_w: now upstream is going to release a tarball
<mathiaz> james_w: how should I proceed for applying the debian packaging to the upstream tarball?
<james_w> hmm
<mathiaz> james_w: I've tried to branch the lp:~mathiaz/sssd/ubuntu-pkg branch but I don't see I could import the upstream release tarball
<james_w> mathiaz, al-maisan: uploaded
<james_w> mathiaz: you need something to do with merge-upstream
<mathiaz> james_w: so the other option was to have two different set of branches
<james_w> you've just been using "bzr merge" on the upstream branch?
<mathiaz> james_w: which is when I run into the bug mentionned above as
<Tonio_> siretart: hi ! I just found out a little issue with your latest ffmpeg upload...
<mathiaz> james_w: hm - for my daily builds (native package) I've just bzr merge ../trunk into ubuntu-pkg/
<mathiaz> james_w: that works fairly well
<james_w> ah, native package
<james_w> yeah
<Tonio_> siretart: the unstripped libavformat seems to have been dropped from it, but there are still conditionnal deps to it on the -dev package and so on...
<mathiaz> james_w: yes - because it's an snapshot from the upstream git-import
<james_w> so I need to think about the best UI for this, but I can tell you how to get unblocked
<Tonio_> siretart: it the removal an error, or should the deps be fixed ? although I couldn't find the package in debian, when it's supposed to be a merge... so I don't know what to do on that point :)
<james_w> mathiaz: if you run "bzr merge-upstream <released tarball> <upstream branch> [-r revision tarball corresponds to]"
<james_w> mathiaz: then it will fail because it can't find an "upstream-" tag, but as it is currently a native package then it doesn't
<james_w> mathiaz: make sense for there to be one.
<Ampelbein> hey there. could some core-dev restart the builds for gnome-system-tools? https://edge.launchpad.net/ubuntu/+source/gnome-system-tools/2.27.3-0ubuntu1 - The dependency (libpolkit-gtk-1-dev) is available and published now.
<james_w> mathiaz: so I suggest you tag the tip of your current branch with the "upstream-" name it specifies, run the command again, and then delete the tag
<james_w> mathiaz: we need some way to say "stop looking for the tag and just use the tip".
<geser> Ampelbein: depwait should get retried automatically
<Ampelbein> geser: is there a timeframe for retrying?
<geser> Ampelbein: libpolkit-gtk-1-dev needs to be promoted to main as g-s-t is in main
<Ampelbein> geser: ok, I thought that binaries automatically get promoted when their respective sourcepackage is in main.
<geser> no, it possible that a source package in main build packages which are in universe
<mathiaz> cr3: http://paste.ubuntu.com/258821/ <- checkbox upgrade testing failed
<cr3> mathiaz: beautiful, patch doesn't preserve permissions :(
<cr3> mathiaz: fix pushed to alpha-4 branch
<ogra> seems that since a while my machines dont have any DPMS functionallity anymore, does anyone else see that ?
 * ogra wonders what that is 
<maco> Keybuk: wow that init/upstart logging bug sure gets a lot of attention
<ogra> maco, it did even before upstart existed
<ogra> bootlogd is broken since ubuntu exists
<maco> i thought it broke around feisty
<maco> but i dont recall seeing multiple-comments-per-day until the last month o so
<maco> *or so
<ogra> no, i remember i had a spec i worked on at ubuntu down under (pre-hoary uds)
<maco> though on the other hand quite a lot were people arguing with scott about which should be the master bug :P
<maco> wow
<ogra> and then upstart came
 * maco bows to your ancientness :P
<mathiaz> cr3: so you don't need any patch to upgrade to 0.8?
<ogra> so even if bootlogd would have been fixed, it couldnt have been implemented
<cr3> mathiaz: that particular patch was backported to 0.7.2, so I removed the file
<ogra> maco, there was some noise about logging boot messages at the ubuntu-users ML ... if they pick up a topic they dont let loose easily ;)
<maco> ogra: ah just like u-d-d
<ogra> way noisier, but similar, yes
<ogra> average amount of posts per day is around 300
<maco> yikes! glad im not sub'd to that
<maco> i left u-d-d and started taking advantage of kmail's ignore-thread feature to avoid such things
<ogra> heh
 * ogra calls it a day anyway 
<highvoltage> ogra: at 20:34, it's a bit overdue :)
<lamont> dchroot: pthread_mutex_lock.c:87: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
<lamont> have we figured out why jaunty likes to do that (armel)?
<mathiaz> cr3: I've uploaded a new version of checkbox
<mathiaz> cr3: https://code.launchpad.net/~cr3/ubuntu/karmic/checkbox/alpha-4/+merge/10445
<mathiaz> cr3: however I can't set the merge proposal to 'Merged'
<mathiaz> cr3: I think only you can set the Status of branch
<cr3> mathiaz: done thanks man! sorry for the few problems encountered, I guess that's to be expected from not proposing a merge in such a long time :(
<evand> is it sufficient to put a universe package waiting to go into main in the live seed for it to appear in component mismatches?
<ScottK> Yes.
<evand> weird, it's (ubiquity-slideshow-ubuntu) not appearing in component-mismatches.txt on p.u.c/~ubuntu-archive, despite me making the seed change at 15:42
<evand> perhaps I'm just being impatient :)
<evand> thanks ScottK
<ScottK> evand: I think component-mismatches is only updated ~4 times a day.
<evand> ah, that would do it
<mathiaz> james_w: hm - trying your receipe for bzr builddeb you mentionned above about sssd
<mathiaz> james_w: I'm running into the same error (in import-dsc)
<mathiaz> james_w: I don't see the new bzr-builddeb package uploaded to karmic yet?
<ScottK> sistpoty: Time for motu-release meeting on #ubuntu-meeting.
<sistpoty> hi ScottK
<sistpoty> thanks for the reminder
<ScottK> No problem.
<sebner> huhu sistpoty ScottK :D
<sistpoty> hi sebner
 * ScottK tries to remember who's on the team.
<ScottK> At 5 after I say we go with who we have.
<sistpoty> makes sense
<ScottK> Wrong channel though.  Whoops.
<highvoltage> "About me: Reinhard Tartler, PHD Student of Computer Science in Erlangen, Germany"
<sebner> highvoltage: ?
<highvoltage> the Germans actually have a city named after Erlang!? brilliant.
<sebner> highvoltage: I think the city is older :P
<highvoltage> sebner: :)
<jtimberman> i'm looking into creating a build environment for packages, and am interested in sbuild, if i'm running on a jaunty system, i can build packages for other ubuntu and debian releases as well right?
<robbiew>  slangasek: is it worth announcing on the mailing list that Feature Freeze is this Thursday?...or was that already done and I just missed it :/
<kirkland> bryce: hiya
<kirkland> bryce: so i'm looking at a few things with kvm + X
<bryce> kirkland, hey
<kirkland> bryce: hey
<kirkland> bryce: first, there seems to be a regression in the qemu/sdl since this morning
<kirkland> bryce: http://pastebin.ubuntu.com/258928/
<thumper> hi guys
<bryce> since this morning?
<thumper> where do I find the level of X support for various chipsets?
<kirkland> bryce: i think so...  i was running qemu-kvm this morning, did a few graphical installs
<kirkland> bryce: now, i'm bombing out with that sdl or framebuffer erro
<kirkland> error
<bryce> kirkland, new kernel?
<kirkland> crw-rw---- 1 root video 29, 0 2009-08-24 09:30 /dev/fb0
<kirkland> bryce: yeah, i think so
 * kirkland notes that he's not a member of video
<kirkland> bryce: i don't *think* i need the framebuffer ... i just want an sdl window to pop open
<bryce> yeah I don't even have the /dev/fb0 device on this bux
<bryce> box
<bryce> kirkland, however I *am* in the video group
<kirkland> bryce: okay, nevermind ...
<bryce> could it just be a quirk of how your user account got setup?
<kirkland> bryce: that one was a dumb mistake on my part
<kirkland> bryce: i was ssh'd to localhost :-/
<bryce> heh!
<kirkland> bryce: okay, that one is solved ...
<kirkland> bryce: now to your questions :-)
<kirkland> bryce: regarding the X server
<kirkland> bryce: let me first make sure I understand the purpose of those hacks
<bryce> sure
<slangasek> robbiew: yes, will send an announcement mail this afternoon
<kirkland> bryce: okay karmic host, karmic guest .... default desktop loads at 800x600
<robbiew> slangasek: cool...thnx
<bryce> kirkland, the purpose of dexconf is to write out the default xorg.conf
<kirkland> bryce: the goal is to run without an xorg.conf, right?
<bryce> kirkland, so what these hacks do is detect if kvm/qemu/vbox is in use, and if so to hardcode a particular driver in the xorg.conf
<bryce> kirkland, indeed; in fact already we've switched to running without xorg.conf in karmic
<bryce> so... dexconf has become vestigial
<bryce> thus, two options
<bryce> one is to have the kvm/qemu/vbox use cases deliberately run 'sudo dexconf' during install so the hacks still get triggered and an xorg.conf still gets put in place
<bryce> two is to get rid of the hacks and move the logic into the xserver's automatic driver selection code, so xserver "knows" about kvm/qemu/vbox
<kirkland> bryce: cool, so i think i agree that (2) is preferential
<bryce> the latter is not has hard as it sounds, just add an extra case section in a switch statement
<bryce> most of the effort is testing, to make sure it's set up right
<bryce> what I can do is, if you tell me the pci id's, rough up a patch that I *think* will do it
<bryce> then you can test and/or tweak the patch to make sure it works well, and we stick it in
<kirkland> bryce: you want the pci id's of the cirrus video device in the qemu-kvm guest?
<bryce> kirkland, that's right
<kirkland> bryce: sure, let me fire one up
<bryce> also vbox if that's handy
<kirkland> bryce: i can't help you there, sadly :-/
<kirkland> bryce: we should be able to offer higher than just 800x600 with the cirrus driver, huh?
<kirkland> bryce: at least 1024x768?  any higher?
<bryce> kirkland, I would imagine so... does kvm implement the asm call to retrieve EDID from the virtual monitor?
<bryce> that's the proper way that video modes are communicated these days
<kirkland> bryce: i'm in the qemu code right now... what am I looking for?
<kirkland> bryce: http://pastebin.com/f5584d17e
<kirkland> bryce: that's lspci -v on a karmic host/guest with cirrus driver
<sbeattie> bryce: one sec, and I'll grab the pci-ids from vbox (at least with jaunty host/guest)
<kirkland> sbeattie: thx
<bryce> kirkland, ok now my knowledge of how all this dark magic works is a bit incomplete
<kirkland> bryce: okay, i don't see any references in the source code to edid
<kirkland> bryce: i'm talking to upstream, though
<kirkland> bryce: so, i suspect the answer is "no"
<bryce> however on the X side it queries...  I2CBus (?) with the monitor id, which returns an EDID_block structure
<bryce> this is done through DDC or DDC2, which is the communication protocol for the monitor
<sbeattie> bryce: lspci -vvnn at http://pastebin.com/f2dc49bb8
<bryce> kirkland, I'm looking at the code in xorg-server-ubuntu-git/hw/xfree86/ddc/ btw
<bryce> mm, there's a DDC.HOWTO in that directory too
<kirkland> bryce: okay, upstream says "no" to EDID/asm call
<kirkland> bryce: it's not implemented
<bryce> kirkland, alright, so then in the kvm case unless resolutions are set in xorg.conf, you'll be stuck with generic defaults
<bryce> (which might include 1024x800, I'm not sure)
<bryce> er 1024x768
<bryce> kirkland, hey can you post 'lspci -vvnn'?  The default lspci output does not provide the pci id's
<bryce> sbeattie, thanks
<kirkland> bryce: sure
<bryce> sbeattie, hehe 80ee:beef
<kirkland> bryce: http://pastebin.com/f1302c310
<sbeattie> bryce: in vbox's case, X defaults to 640x480 and 800x600. vbox supports many more modes, dapper's X config sets 1024x768 and that works and hwinfo --framebuffer is able to find a bunch.
<bryce> kirkland, hmm, cirrus is already in there
<bryce>         case 0x1013:                driverList[0] = "cirrus"; break;
<bryce> kirkland, try moving aside your xorg.conf and restarting X and see if it gets the driver right
<kirkland> bryce: k
<bryce> sbeattie, got an Xorg.0.log you can pastebin for me?
<kirkland> bryce: i have no xorg.conf :-)
<bryce> sbeattie, fwiw vbox's driver wasn't already in there; I can add it easily though.  Maybe the reason for the reduced resolution set is just missing its driver
<sbeattie> bryce: one sec.
<bryce> kirkland, so... you're up and running with no xorg.conf?  how is the resolution selection (run 'xrandr')?
<kirkland> bryce: correct
<kirkland> bryce: up and running, no xorg.conf (fresh karmic kvm install from this morning)
<kirkland> bryce: resolution options are 800x600 and 640x480
<bryce> kirkland, ok, had you also tried with the xorg.conf present?  If not, try running 'sudo dexconf', restarting X, and seeing if they pop in at that point
<kirkland> bryce: http://pastebin.com/f4dbc041d
<sbeattie> bryce: http://pastebin.com/f2dc49bb8 from an alpha-3ish karmic amd64 guest.
<kirkland> bryce: dexconf fails with exit code 10
<bryce> kirkland, hrm, any error messages other than that?  I guess it didn't produce an /etc/X11/xorg.conf?
<kirkland> bryce: no xorg.conf written
<kirkland> bryce: no errors
<kirkland> bryce: sh -x just shows it exec'ing debconf dexconf
<bryce> kirkland, ok well the good news is kvm still works even in the new X setup... just that due to lack of EDID it's not getting its full set of resolutions
<kirkland> bryce: heh, yeah
<bryce> sbeattie, I'm guessing this same thing will affect vbox, unless it also provides a virtual monitor with EDID
<bryce> the dexconf breakage is... troubling...
<bryce> but let's leave that aside for the time being
<kirkland> bryce: this launch-from-the-command-line i think is mostly a developer-only use case
<kirkland> bryce: i suspect most users will use some form of libvirt, which will launch with a vnc server
<bryce> kirkland, ok, how does that use case differ exactly?
<kirkland> bryce: well, most of my developer-level testing, i just run kvm from the command line, which pops open an SDL window
<kirkland> bryce: most users, though, i think will use something like virt-manager
<kirkland> bryce: which adds a bunch of options to kvm, including -vnc
<kirkland> bryce: i'm testing that now ....
<kirkland> bryce: stand by :-)
<kirkland> bryce: when i'm launching from the command line, mine looks like this: "/usr/bin/kvm -m 512 -hda karmic-desktop.img"
<kirkland> bryce: when virt-manager launches, it looks like: /usr/bin/kvm -S -M pc -m 512 -smp 1 -name karmic-desktop -uuid 132868d4-ba99-3c44-a158-20e51435b9f6 -monitor pty -no-reboot -boot d -drive file=/local/virt/iso/karmic-desktop-amd64.iso,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/karmic-desktop.img,if=virtio,index=0 -net nic,macaddr=54:52:00:03:06:95,vlan=0,model=virtio -net tap,fd=18,vlan=0 -serial pty -par
<kirkland> allel none -usb -vnc 127.0.0.1:0 -k en-us -soundhw es1370
<kirkland> bryce: note the -vnc
<cjwatson> ScottK: FWIW component-mismatches is supposed to be updated hourly
<bryce> sbeattie, kirkland: ok here's the patch for driver detection goodness - http://people.canonical.com/~bryce/virtual_devices.patch
<kirkland> bryce: cool, are you going to build that somewhere that I can verify it for you?
<bryce> kirkland, I don't think there is a need for you to test this one since it won't fix anything for your kvm
<bryce> checking bug reports...
<kirkland> bryce: how complicated is this EDID response?
<kirkland> bryce: is that something I can craft easily enough?
<kirkland> bryce: from the qemu side, i mean
<bryce> kirkland, no clue but I've located a patch that mdeslaur found from redhat for this
<bryce> kirkland, see bug 349331
<ubottu> Launchpad bug 349331 in kvm "limited screen resolution" [Low,Confirmed] https://launchpad.net/bugs/349331
<bryce> bug 237164 looks similar/dupe-ish
<ubottu> Launchpad bug 237164 in xorg "kvm needs to correctly simulate a proper monitor" [Medium,Invalid] https://launchpad.net/bugs/237164
<kirkland> bryce: that cirrus driver patch looks promising; is that something we could carry as well?
<kirkland> bryce: yes, the latter was the one I was most aware of
<kirkland> bryce: and trying to solve in this half-day of working on qemu-kvm's video issues
<bryce> kirkland, see in particular https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/237164/comments/13
<ubottu> Launchpad bug 237164 in xorg "kvm needs to correctly simulate a proper monitor" [Medium,Invalid]
<bryce> kirkland, yeah I can pull that patch in
<NCommander> kirkland, an archive admin should have done the backport ages ago
<NCommander> kirkland, (sorry, just got to looking at this)
<NCommander> kirkland, its properly subscribed on our end
<kirkland> NCommander: thanks
<NCommander> kirkland, I dunno why its stuck :-/
<kirkland> bryce: i can confirm that an F11 guest has much higher resolutions available :-)
<bryce> hrm, -cirrus lacks a patch system...
<kirkland> bryce: well, it has 1024x768
<kirkland> bryce: which is much better
<bryce> kirkland, so nice of redhat to fix it !upstream ;-)
<kirkland> bryce: *wink*
<cjwatson> I'm currently engaged in upstreaming a patch that originated with Red Hat
<cjwatson> it happens more often than the marketroids might care to think ;-)
<cjwatson> (actually, we're reimplementing the significant bits in a different way)
<kirkland> cjwatson: if you have any AA bandwidth available, could you finish the kvm-84 backport task?
<kirkland> cjwatson: it's been in the queue for several weeks now
<cjwatson> kirkland: done for intrepid-backports
<kirkland> bryce: i added a task for xserver-xorg-driver-cirrus (Ubuntu) to bug #349331
<ubottu> Launchpad bug 349331 in kvm "limited screen resolution" [Low,Confirmed] https://launchpad.net/bugs/349331
<kirkland> bryce: you can close that task in your upload
<bryce> cjwatson, yeah it seems like it redhat used to be better at pushing patches upstream; only really distro-specific patches sat there.  Lately though I'm finding I have to pull more stuff from their trees.
<bryce> kirkland, thanks
<bryce> sbeattie, ok your vbox pci id support is uploaded to karmic.  You should be able to run vbox with no xorg.conf now
<sbeattie> woo
<bryce> sbeattie, although potentially you may see reduced resolutions available when doing so, as kirkland has run into
<bryce> sbeattie, let me know if that's the case and we can maybe adopt a similar approach for fixing that
<bryce> sbeattie, the fix is in xorg-server_1.6.3-1ubuntu4
<sbeattie> bryce: cool, thanks so much; I'll give it a go and let you know what the result is.
<kirkland> NCommander: okay cjwatson approved it for intrepid-backports;  so we're going to give that a few days before approving it for hardy-backports?
<NCommander> kirkland, he has to accept kvm, and autobackport libvirt as per the bug, but yes
<kirkland> NCommander: okay, i'll sit tight
<NCommander> kirkland, sorry about this getting lost in the pile
<kirkland> NCommander: it happens, no worries;  let's try to get it out to hardy by week's end, cool?
<NCommander> kirkland, sure
<bryce> kirkland, okay!  Patch uploaded for -cirrus
<kirkland> bryce: cheers, thanks;  i'll try it out in a bit
<bryce> kirkland, I had to re-add the patch system and stuff, and to the best of my knowledge it should load and work, but please test and let me know.
<kirkland> bryce: you bet
<bryce> ok, heading out to buy some fish.  be back later.
<fbond> slangasek: https://wiki.ubuntu.com/PointReleaseProcess indicates that an archive snapshot is made for point releases.  Is this snapshot publicly accessible somewhere?
<slangasek> fbond: no, it isn't
<fbond> slangasek: I'm building a product on top of Ubuntu.  For this product, many builds will be created over time, and I'd like to be able to choose a consistent set of package versions for builds made at different times.
<fbond> Is my best option to mirror the archives and create my own snapshots?
<slangasek> fbond: hmm, for those purposes I think that's what makes the most sense
<fbond> (Basically, I need to organize my builds around my own concept of a "release".  My plan was to mimic Ubuntu's releases, e.g. 8.04.2, etc.)
<fbond> slangasek: Is there at least some way to determine which package versions are present in the official snapshots?
#ubuntu-devel 2009-08-25
<slangasek> I think the reason we keep the snapshots is primarily to ensure we can satisfy the license requirements for the point release ISOs after the fact
<slangasek> fbond: that's not published either, except in the .manifest and .list files that accompany the ISOs (which are the only packages we care about for the snapshot, really)
<fbond> slangasek: I see.
<fbond> slangasek: What is the likelihood of at least making a list of package versions public?
<fbond> (I'll even write the script if you want. ;)
<slangasek> fbond: you really care about the full list of packages, including those not included in the point release ISOs?  I could publish the Packages files somewhere, I'm just confused why you would want that list
<slangasek> the manifests for the ISOs are already public
<fbond> slangasek: My builds may pull any package from the archives, and they do not build ISOs.
<slangasek> fbond: but then, why do you want the lists for those particular snapshots?
<fbond> slangasek: Mostly because it is a convenient way to declare release points.
<slangasek> hmm
<slangasek> well, let me grab those Packages files out for you, then and publish them somewhere
<slangasek> which archs do you care about?
<fbond> slangasek: I only care about x86 right now.
<fbond> slangasek: I'd rather not have to bug you again after every release.
<slangasek> "x86" as in "i386", or as in "i386 and amd64"?
<fbond> i386, sorry.
<slangasek> well, you can always pull the Packages files yourself the day of the point release then? :)
<fbond> I would only want to trouble you with this if you feel it is something that is appropriate to do both now and in the future.
<fbond> slangasek: Ah, sure, I don't mind doing that.
<fbond> How long is the window where I am guaranteed to have correct contents?
<slangasek> given that security updates can happen at any time and be published to -updates, not long
<fbond> slangasek: Right, that is my concern (and maybe I'm being nitpicky).
<slangasek> is it really a bad thing if you end up with an extra security update in your snapshot compared to the Ubuntu point release?
<fbond> slangasek: Um, no, I suppose not.  Okay, you're right, I can live with that.
<fbond> In that case, I only need the most recent release now.
<fbond> (I'm not making retroactive releases.)
<fbond> I can pull it myself for future releases.
<fbond> slangasek: Err, not the most recent.
<fbond> The most recent hardy point release.
<fbond> 8.04.3, then.
<slangasek> fbond: http://people.canonical.com/~vorlon/8.04.3
<fbond> slangasek: Thanks, that's perfect!
<dtchen> TheMuso: i've rolled a newer git snapshot of PA due to the last-minute fixes; it WFM in lp:~ubuntuaudiodev/pulseaudio/ppa
<TheMuso> dtchen: Ok thanks.
<TheMuso> dtchen: I'll fetch the orig from the ppa and use what you committed to bzr.
<dtchen> TheMuso: great, thanks
<sbeattie> bryce: bah, xorg-server upload failed to build due to: libdrm-dev: Depends: libdrm-radeon1 (= 2.4.12+git20090801.45078630-0ubuntu1) but it is not installable
<cjwatson> sbeattie: fixed archive-side; should succeed if retried in ~1.5 hours
<Ampelbein> cjwatson: could you do a promotion of libpolkit-gtk-1-dev to main? the source (https://edge.launchpad.net/ubuntu/+source/policykit-1-gnome) is already in it and it is needed for the gnome-system-tools build to start.
<TheMuso> Ampelbein: I think he has gone to bed.
<TheMuso> GOing by a comment he made in #ubuntu-installer.
<Ampelbein> TheMuso: oh, ok. i think it can wait till tomorrow.
<Ampelbein> thanks
<jtimberman> how often does the NEW queue get reviewed by AA?
<kees> jtimberman: AA queue is processed daily, but source and binary NEW can take longer sometimes.
<jtimberman> kees: I only ask because I'm eager for my packages to get into Universe before Karmic Feature Freeze.
<kees> jtimberman: I suspect if they're uploaded before FF, you'll be okay, but I'm not an archive admin, so I may be wrong.
<jtimberman> kees: Here's hoping. They were advocated / uploaded to new by at least one AA each, so I'd think they're fine at this point :-)
 * ccheney didn't realize until today that url icons could be animated
<slangasek> siretart: the new ffmpeg package build-depends on openjpeg, which is not in main. Are you preparing an MIR for that?
<slangasek> siretart: or should the build-dep be dropped? (I notice --enable-libopenjpeg is specifically not set in debian/confflags)
<superm1> mathiaz, ping.  are you planning on bringing 38_scripts__mysqld_safe.sh__signals.dpatch to mysql server 5.1?
<mathiaz> superm1: hmmm - yes.
<mathiaz> superm1: could you open a bug task for mysql-dfsg-5.1?
<superm1> mathiaz, sure
<superm1> bug 418396
<ubottu> Launchpad bug 418396 in mysql-dfsg-5.1 "need to port 38_scripts__mysqld_safe.sh__signals.dpatch from mysql server 5.0" [Undecided,New] https://launchpad.net/bugs/418396
<ScottK> slangasek: siretart is just about to leave/just left for 3 weeks of vacation.  I believe sistpoty volunteered to help out, but I'm pretty sure it didn't include that exact question.
<ScottK> doko: I just uploaded the python2.5 fix in 395321, but I don't have access to your bzr repo, so please don't forget to update it.
<ScottK> ebroder: python2.5 uploaded.  Thanks for pointing it out.
<dtchen> as a heads-up, 2.6.31-7-generic breaks encrypted lvm really, really badly.
<slangasek> ScottK: ah.  well, my best guess in his absence is that the openjpeg build-dep should be dropped
 * StevenK grumbles at readline-common now wanting a version of dpkg that doesn't exist in Ubuntu
<StevenK> Oooh, it's better. A version of dpkg that doesn't even exist in Debian.
<Hobbsee> uh oh.  I think i upgraded my karmic yesterday, with encrypted lvm
<TheMuso> Hobbsee: You'd be fine, since 7-generic would have only been deployed a few hours ago.
<Hobbsee> oh, excellent
<TheMuso> If that.
<StevenK> slangasek: Have you heard about the readline-common issue?
<slangasek> StevenK: only what you've said here; but looking at the dep, I see only that it wants dpkg (>= non-existent-version) | install-info
<slangasek> StevenK: so where is this failing?
<dholbach> good morning
<highvoltage> good morning dholbach
<dholbach> hola highvoltage!
<pitti> Good morning
<siretart> slangasek: I've already dropped the build-dep on openjpeg in my packaging branch
<siretart> doh, I've dropped yasm, not openjpeg. but yasm is in the same situation...
<slangasek> siretart: hmm, I didn't notice yasm in components-mismatches, but ok:)
<siretart> slangasek: uploading new package with same version number now
<slangasek> what do you mean, same version number?
<slangasek> ffmpeg wasn't in new, reuploading with the same version number will be rejected
<siretart> oh, doh
 * siretart just wike up. sorry
<siretart> uploading ffmpeg_0.5+svn20090706-1ubuntu2 now...
<tkamppeter> Any bluez expert around?
<lool> kees: Assigned you to LP #418223; good to go for me but related to web services security so I'd prefer if you'd have a look
<ubottu> Launchpad bug 418223 in rampart "MIR for rampart" [Undecided,New] https://launchpad.net/bugs/418223
<lool> (C library)
<ogra> doko, the deps in readline-common on dpkg 1.15.4 break image builds, are you updating dpkg too ?
<ogra> doko, (we have 1.15.3.1ubuntu1 atm)
<cjwatson> ogra: hope not, it's not released upstream yet
<ogra> ouch
<ogra> well, then the dep needs to be bumped down
<ogra> (if that doesnt break readline indeed)
<cjwatson> be careful of http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo
<ogra> hrm, all that extra fun ...
<ogra> do we actually *need* the new readline ?
<iulian> Could someone please moderate my mail sent to ubuntu-desktop?
<doko> cjwatson, ogra: this is lintian's suggestion. should we just turn around the dependency for now?
<ogra> i'd be fine with that but dont know how the install-info changes cjwatson referred to might break then
<cjwatson> lintian may be running a little ahead of implementation
<ogra> ah, well, then lets just give it a try
 * ogra prepares a package with flipped dep
<cjwatson> ogra,doko: see also http://bugs.debian.org/538665 which was the policy bug
<quadrispro> james_w: hi! are you around here?
<james_w> yeah
<quadrispro> james_w: regarding bug #417631, I received a mail from Harry Rickards right now, he updated the debian/control again and I need to re-upload the package, so please drop lives from the queue
<ubottu> Launchpad bug 417631 in ubuntu "Sync lives 1.0.0-4 from debian sid (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/417631
<ogra> cjwatson, hmm, d-i seems not happy with the new naming scheme of imx51
<james_w> quadrispro: what queue?
<quadrispro> karmic NEW, I think
<ogra> i wonder why it picks up dove just fine with the high abi number
<cjwatson> ogra: dunno, can one of you guys figure it out?
<ogra> just looking
<SteveA> I just updated my desktop machine and now X won't start.  Failed to load module "nvidia".
<ogra> cjwatson, looks like NCommander hardcoded all armel versioning to 2.6.31-200 ignoring subarches :/
 * ogra digs around
<SteveA> commenting out the nvidia line in xorg.conf gets me X
<ogra> ah, no i'm wrong, phew
<cjwatson> ogra: no, not as far as I can see - he put it in build/config/armel/dove.cfg
<ogra> yep
<quadrispro> james_w: the package is lives_1.0.0-4ubuntu1
<james_w> rejected
<quadrispro> thanks!
<StevenK> SteveA: What happens when you 'sudo modprobe nvidia' ?
<SteveA> StevenK: sorry -- too late. I got X working by commenting out the line mentioning nvidia in xorg.conf, then started x with startx.  Then I tried turning on Visual Effects in the Appearance Preferences
<SteveA> it asked me if it's okay to download and install a driver, so I clicked okay, entered my sudo password
<SteveA> and it's downloading and installing a driver
<SteveA> it's now asking me to restart the computer in a very confusing an round-about way
<SteveA> StevenK: I just stopped x.  If I do "sudo modprobe nvidia" I get the response FATAL: Module nvidia not found.
<StevenK> SteveA: This is on Karmic?
<SteveA> yes, latest packages from the archive
<SteveA> 64 bit
<SteveA> StevenK: after rebooting, I still don't get X.  X tries to load the nvidia module, but cannot, because it is not found.
<StevenK> SteveA: Is the 'nvidia-common' package installed?
<ogra> sigh, why doesnt bzr tags spit out its list ordered by commit ?
<SteveA> yes, apt-cache policy reports 0.2.15
<StevenK> ogra: | sort -k 2 ?
<ogra> pfft, it should do that iself
<ogra> instead of ordering by tag
<StevenK> SteveA: That's odd. File a bug using 'ubuntu-bug nvidia-common'
<pitti> tkamppeter: I removed hal-cups-utils from karmic FYI, no reverse dependencies any more, and it's obsolete
<tkamppeter> pitti, OK, thanks.
<tkamppeter> pitti, others to remove are foomatic-db-hpijs and cupsddk
<cjwatson> Keybuk: FYI I'm just uploading a debhelper 7.3.15 merge now, mostly because it has a bunch of other stuff I want, but it also includes some changes to dh_installudev. I've merged it very carefully and test-built it with two packages one of which uses --priority and one of which doesn't; some autoscript code changes but I think the changes are correct. If you notice any weirdness, though, please let me know ...
<Keybuk> ok will do
<pitti> tkamppeter: cupsddk not before the new cups is uploaded, no?
<tkamppeter> pitti, yes
<pitti> tkamppeter: the printconf and ebox-printers packages still depend on foomatic-db-hpijs (plus some *-desktop packages which are just seed fixes)
<tkamppeter> pitti, do printconf and ebox-printers depend on foomatic-db? The functionality of our current foomatic-db-hpijs package is completely replaced by foomatic-db.
<pitti> tkamppeter: they do apparently
<tkamppeter> pitti, if so, it is enough to let printconf and ebox-printers depend only on foomatic-db.
<pitti> tkamppeter: ok, so I'll remove the package; would you mind uploading these two with the dependencies dropped?
<pitti> (both universe)
<tkamppeter> pitti, I can do so.
<pitti> tkamppeter: thanks; removed
<tkamppeter> pitti, are the two maintained upstream?
<pitti> tkamppeter: I don't know, but it's a packaging-only change anyway, I guess
<pitti> I don't know whether that functionality merging was done in debian, though
<tkamppeter> printer setup tools directly depending on Foomatic smell like CUPS 1.1.x.
<pitti> printconf sounds stale, ebox I'm not sure about
<pitti> tkamppeter: I blacklisted it now, so that it won't come back through autosyncs
<sistpoty|work> cjwatson: do you maintain p-a-s for ubuntu? If so, could you please restrict faumachine to amd64 i386 lpia? (needs to get ported to non-x86 arches, which is sadly non-trivial)
 * ogra thought we dont have our own p-a-s
<sistpoty|work> ogra: we certainly do, as faumachine is restricted to amd64 i386 in debian
<sistpoty|work> (and I still get failed build logs from ubuntu from time to time)
<tkamppeter> pitti, printconf (source package name foomatic-gui) is synced with Debian and it seems that Debian is also upstream, as there is no .diff.gz.
<Keybuk> cjwatson: heh, looks like automake1.11 clobbers the old automake1.10 package
<cjwatson> Keybuk: I just sponsored a merge of the updated automake1.10 from Debian that creates an automake1.10 binary
<Keybuk> ahh
<Keybuk> I was about to do one
<Keybuk> heh
<cjwatson> sistpoty|work: 'bzr checkout lp:~ubuntu-core-dev/packages-arch-specific/ubuntu'
<Keybuk> and suddenly your 11:16 mail turns up
<cjwatson> sistpoty|work: please forward any changes made there to Debian
<sistpoty|work> cjwatson: oh, cool, thanks! will do
<SteveA> StevenK: thanks.  bug 418521
<ubottu> Launchpad bug 418521 in nvidia-common "On upgrade, X did not start because nvidia module is not available" [Undecided,New] https://launchpad.net/bugs/418521
<sebner> pitti: grr, I'd like to but I can't provide the information you need (comment 42, external SATA USB thing)
<pitti> sebner: oh, still broken even with the udev rules moved aside?
<sebner> pitti: no, moving aside the rules worked *always* but this is still the "workaround" and I can't provide you information to debug it :\
<pitti> sebner: why? calling skdump doesn't work?
<SteveA> how odd... my machine isn't shutting down properly either
<sebner> pitti: yep, I told you some weeks ago: Failed to open disk /dev/sdb: No such file or directory  (sdb is sane, but safely tried sdb1 too)
<pitti> sebner: if you still get USB timeouts even with the udev rules moved aside, this seems like a completely different problem then, and a real kernel bug
<pitti> hmm
<Laney> If I p-a-s ghc6 to non-ia64, will I also have to list all of the rdeps too?
<pitti> Keybuk: (reviewing sreadahead) uh, you really don't like patch systems, do you?
<Keybuk> pitti: no
<Keybuk> I like revision control systems
<sebner> pitti: It was working some time ago though
<Keybuk> bzr diff lp:sreadahead lp:~ubuntu-core-dev/sreadahead/ubuntu
<pitti> Keybuk: it's promoted now; should I demote or remove readahead?
<Keybuk> you can remove if you like ;-)
<pitti> it's just the metapackages sucking it in, no real rdepends
<Keybuk> yeah
<pitti> ok, then away with it :)
<pitti> so i'll rebuild meta once the main promotion gets published
<sebner> pitti: ok, strange thing. Pluggin in works now. pops up in /media etc. But if I run skdump etc it get's ejected etc. I can use it if I power off the the external harddrive and re-plug
<pitti> sebner: right, that behaviour of skdump is what upstream is interested in (together with the output)
<pitti> is jmicron:/dev/sdb any better?
<sebner> pitti: both suck. Either Failed to open disk jmicron:/dev/sdb: No such device or Failed to open disk /dev/sdb: Invalid argument
<pitti> ok; well, if /dev/sdb isn't even present it won't work at all, of course
<sistpoty|work> Laney: yes, as ghc6 then won't be available on ia64...
<sebner> pitti: As I said, I start the commands, disk gets ejected, fail messages appear
<pitti> sebner: right, please copy the output and dmesg and describe the behaviour in the bug report, I'll forward it to upstream
<sebner> pitti: dmesg before or after the eject?
<pitti> after
<sebner> pitti: aye aye Sir
<sistpoty|work> Laney: however we still have 6.8.2 (binary) on ia64 available, so I don't think p-a-s for ghc6/ia64 is the right thing
<sebner> pitti: grr LP is slow :PÂ· done :)
<Keybuk> HAHA! I get a Timeout Error whenever I visit bugs.lp/~scott
<Keybuk> no more bug fixing for _me_ today :D
<sistpoty|work> Keybuk: I can send you a screenshot :P
<Daviey> Keybuk: AFAIK .lp isn't a TLD.. so no wonder you are having issues. :)
<Keybuk> Daviey: well, ICANN are saying they'll let anyone buy TLDs
<Keybuk> then we *could* have .lp
<Keybuk> and .egg
<Daviey> !
 * Daviey hides.
<Keybuk> bdmurray: is Pedro away today?
<Laney> sistpoty|work: I thought a b-d on a p-a-sed package would have that effect
<Laney> and I'm just a bit wary about having an outdated binary that we can't fix
<sistpoty|work> Laney: a b-d is only a b-d. it will fail if the package is unavailable. Otherwise you'd need to have a b-d with an arch-restriction ala ghc6 [amd64 i386 ... ]
<sistpoty|work> Laney: but there aren't any plans to drop support for ia64 entirely in ghc6, are there?
<Laney> no
<sistpoty|work> Laney: having the old version is imho still better than nothing, as otherwise we'd need to bootstrap ghc6 on ia64 again (or rather pester a buildd admin with that), once it's working ok
<Laney> nah, ghc's buildsystem can handle that
<sistpoty|work> oh, cool, so that changed nowadays :)
<Laney> it builds itself in two stages
<Laney> stage 1 can use an existing ghc, but I don't think we do that for our builds anyway
<Laney> https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html - see from "But please aware"
<Laney> makes me think that it does cascade through build-deps
<sistpoty|work> Laney: I don't think so, but that this rather refers to an arch restricted b-d line of mono
<Laney> dunno
<sebner> pitti: the error with jmicron was done *after* unplugging/replugging the drive  ;)
<Keybuk> urgh
<Keybuk> pitti: the majority of bugs filed against udev are now keyboard related
<Keybuk> lol
<sebner> pitti: btw, new bug filed #418571
<sebner> pitti: grr, bug 418571
<ubottu> Launchpad bug 418571 in libatasmart "Can't use external Harddrive because lots of USB Resets" [Undecided,New] https://launchpad.net/bugs/418571
<pitti> sebner: hm, I thought you said that'd make /dev/sdb appear
<pitti> sebner: thanks
<sebner> pitti: nope, with both commands, the drive disappears/gets ejected
<pitti> sebner: ah, so /dev/sdb existed before, and if you do the skdump jmicron:/dev/sdb you actually get that "doesn't exist" error message, even though it did exist before?
<sea-gull> why .pc files are included in *-dev packages?
<pitti> sea-gull: where else would they be?
<sebner> pitti: right ^^, I move the rules thing away and the plug the harddrive in and it appears in /media which means that /dev/sdb is present. If I run these commands sdb is ejected which (I think?) leads to this error messages
<pitti> sebner: ah, ok; thanks; that wasn't clear; can you please get an strace of the jmicron one as well?
<sebner> pitti: sure
<sea-gull> pitti: for example, why pango.pc is included in libpango-dev, no in libpango?
<sea-gull> pitti: if we're installing lib then it should be possible to link them
<sea-gull> pitti: why do I need *-dev package if I don't change the sources?
<pitti> sea-gull: the .pc file isn't necessary at runtime
<pitti> just if you build apps against a library, in which case you'll need the other files in -dev as well (header files, and the .so at least, but also the pkgconfig file)
<sea-gull> pitti: hm, right. I forgot about header files: it's logical that they're in -dev.
<sebner> pitti: attached
<pitti> sebner: danke
<sebner> pitti: gerne :), Why do I have a different problem but the same error messages (-71), moving rules works around etc?
<pitti> sebner: you said that after moving the udev rules away, pluggin in the device would still get timeouts and missing /dev/sdb for you
<pitti> that isn't what this bug is about
<sebner> pitti: nah, I said moving udev rules away and plugging in makes the drive to appear and make it usable so no timeouts. xD You should really read more carefully xD
<pitti> sebner: right, and the other issue is that other people didn't get their hd ejected with skdump; the command actually succeeded, but caused usb resets afterwards
<sebner> pitti: right
<pitti> well, this bug has become pretty confusing anyway, with different people having different results, so it's easier to track each problem separately
<sebner> right
<sebner> pitti: anyways, I'm off now. still thankful for all your work
<ttx> ubuntu-archive: I reviewed component-mismatches for any Eucalyptus-related MIR that I would have missed -- I don't get why the old "eucalyptus-javadeps" stills shows in the list, however. It generates a lot of bogus entries.
<ttx> it says [Reverse-Depends: eucalyptus-cloud] but it's no longer true
<james_w> since when?
<ttx> since Monday. and eucalyptus was added to seed after that.
<james_w> "Generated: Tue Aug 25 13:35:02 BST 2009"
<james_w> ok
<ttx>  /scary/ bogus entries, I might add.
<cjwatson> because it's out of date on ia64. component-mismatches checks all architectures.
<soren> Oh? I didn't think it ever built on ia64.
<soren> I only checked i386, amd64, lpia.
<soren> cjwatson: How do you check that easily? rmadison only shows amd64 and i386.
<cjwatson> lp_archive@cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate$ grep ^eucalyptus-javadeps all_*
<cjwatson> :-)
<soren> cjwatson: Ah :)
<cjwatson> (only ask questions whose answers you believe you will like)
 * soren needs to adjust his expections
<Keybuk> I hate looking at e2fsprogs git
<Keybuk> it's so utterly confusing
<Keybuk> I think Ted does it deliberately
<Keybuk> he has three branches "master", "next" and "maint"
<Keybuk> and ALL THREE are tagged with the release number
<Keybuk> but the release may be off any one of them
<directhex> you'd prefer a naming scheme like "donut" "eclair" and "flan"?
<evand> he would
<ogra> yummy
<jtimberman> Any AA able to accept for upload new packages chef, merb, stompserver for Karmic?
<ScottK> jtimberman: They just need to be uploaded by feature freeze, they can go through New after.
<Keybuk> directhex: I'd prefer names like "stable" or "v1.14" ;)
<Keybuk> and I'd prefer "patches that are headed for 1.14.x go into one branch, and ALL 1.14.x releases are made off that branch"
<jtimberman> ScottK: If there's any last minute / final changes required, that's okay?
<ScottK> jtimberman: Bug fixes can come after.
<ScottK> That includes getting rejected and having to upload again.
<jtimberman> ScottK: Cool. It wasn't clear to me.
<Amaranth> ah, feature freeze
<Amaranth> aka "upload new broken stuff and claim everything afterward is just a bug fix" :)
<ScottK> Let's see, compiz hacker, right?
 * Amaranth hides
<Amaranth> ScottK: We've been stuck on that second step for a couple years ;)
<cjwatson> which reminds me, better get my arse in gear with man-db 2.5.6
<jtimberman> Amaranth: Hopefully not for Chef! I work for the company that wrote it, and I've tested it w/ the packages *quite* extensively.
<Amaranth> jtimberman: oh, not talking about your stuff specifically
<Amaranth> but there are two times my karmic system is most likely to stop working: initial debian import and feature freeze :P
<jtimberman> Amaranth: I'm sure, I was interjecting anyway ;)
<jtimberman> Hopefully not due to optional packages in universe :D
<jdstrand> dholbach: hi! so, I've got ufw being translated in LP (https://translations.launchpad.net/ufw/trunk) and want some advice. As an upstream, I'd like to include these translations in my upstream tarball. However, some are far from complete. In your opinion, is it better to include only the mostly translated ones or to include all (to possibly encourage others to participate)?
<dholbach> jdstrand: you could ask pitti, afaik there's some sniplet of code that takes care of that
<dholbach> hey mako
<dholbach> pitti: where was that code again - was it in ubuntu-docs?
<mako> dholbach: hey there
<jdstrand> dholbach: thanks, I'll wait for pitti :)
<Tonio_> siretart: ping ?
<siretart> Tonio_: pong
<Tonio_> siretart: don't know if you saw my messages yesterday, but there is a pretty hdge problem with ffmpeg...
<Tonio_> siretart: seen them ?
<Tonio_> siretart: the unstripped packages have been removed, but there are still internal deps on it
<siretart> Tonio_: note sure, but did you recheck after my latest uploads have been accepted? and did you read my recent mail to ubuntu-devel?
<Tonio_> siretart: see for example : sudo apt-get install libavformat-dev libavformat-unstripped-52
<Tonio_> siretart: hum no I didn't check out today, let me have a look :)
<siretart> Tonio_: if you have some time, please change ubuntu-restricted-extras to depend on 'libavcodec-extra-52'. The other packages (avutil, avformat) are pretty identical to their counterparts in main. no need to depend on them AFAIUI
<siretart> it might still make sense to help apt's dependency solver, though
<Tonio_> siretart: yes that was my plan (also with kubuntu)
<siretart> thanks
<Tonio_> but probably the conditional deps on the unstripped packages hould be dropped from the control file in ffmpeg package right ?
<siretart> they are auto generated by dpkg-shlibdeps
<Tonio_> siretart: nope :)
<siretart> they are :-)
<siretart> ah, not in the metapackage, right
<Tonio_> siretart: Depends: libavcodec52 (>= 4:0.5+svn20090706-1ubuntu2) | libavcodec-unstripped-52
<siretart> this comes from the .shlibs file
<Tonio_> siretart: hum you don't get my point I think :) afaics, this is simply manually added to the control file
<siretart> tell me the line, then
<Tonio_> siretart: 161 for example
<TonyTheTiger> hey can someone help me write a driver for the xbox 360 hori ex2 fighting stick.
<siretart> oh, for the -dev packages only. right
<siretart> doh, you're right. after the rename these deps need to be updated as well. my bad
<Tonio_> siretart: yep
<Tonio_> siretart: will you do that or should I ?
<Tonio_> I'll take care of the ubuntu restricted packages
<siretart> I'm on it
<Tonio_> great
<siretart> OTOH, the provided transitional packages should prevent further damage...
<ScottK> siretart: Did you see slangasek's question last night about ffmpeg depends?
<siretart> ScottK: I've seen his mail on the mailing list...
<ScottK> OK.
<ScottK> He also had another on last nigh.
<ScottK> t
<ScottK> Let me see if I can find it.
<siretart> ScottK: ah, that was about libopenjpeg. already fixed this morning
<ScottK> OK.  Good.
<ScottK> That's the one.
<pitti> jdstrand: for my projects I usually just download the entire translation tarball for my project and add them
<pitti> jdstrand: but if you want to go ahead and only select well-translated ones, that's possible of course
<Tonio_> ScottK or siretart, any idea where the sources for the restricted-extra packages are stored ?
<pitti> jdstrand: it won't affect the langpacks, though, they just take everything
<jdstrand> pitti: re langpacks> ack
<Tonio_> it is structure like a seed package, so I suspect there's a bzr branch somewhere, but I can't find it, therefore not fix it :)
<pitti> jdstrand, dholbach: I'm not aware of a script; however, nowadays LP can create a "translation branch" for you which you can just merge from
<jdstrand> pitti: what is your reasoning to import all of them?
<pitti> jdstrand: partly "common practice", partly "I don't want to check and judge"
<jdstrand> pitti: heh, fair enough. I'll do the same. thanks! :)
<siretart> Tonio_: apt-get source kubuntu-restricted-extras works just fine for me
<Tonio_> siretart: yep, sure, I was just wondering if there's a place to commit to :)
<siretart> no VCS field, no commit
<dholbach> jdstrand, pitti: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-docs/ubuntu-karmic/annotate/head%3A/debian/rules
<Riddell> Tonio_: I'm pretty sure there sin't
<Riddell> isn't
<jdstrand> dholbach: cool, thanks :)
<Tonio_> Riddell: oki :)
<pitti> dholbach: how does that fetch translations from LP?
<tkamppeter> pitti: I have uploaded foomatic-gui and ebox-printer without foomatic-db-hpijs dependency now. foomatic-gui is not completely obsolete. It is not recommended for CUPS 1.2 and newer, nowadays it servs for users of non-CUPS spoolers, like the LPRng in Debian and in Ubuntu Universe.
<pitti> tkamppeter: I saw, thank you
<dholbach> pitti: I dunno
<tkamppeter> superm1: hi
<pitti> tkamppeter: oh, can you please put your cups 1.4 orig.tar.gz somewhere? (I guess it's an svn snapshot with autoconf etc. run, but I'd rather use your tested one)
<tkamppeter> pitti, should be on http://www.linuxfoundation.org/~till/tmp/cups_1.4.0~svn8773.orig.tar.gz now. Please wait for my upload to complete.
<pitti> tkamppeter: I'll use "pkg-config --atleast-version=0.11 poppler", that should suffice as test whether to apply the patch, right:?
<tkamppeter> pitti, yes. Only Ubuntu-only dependency of pdftoopvp is Poppler 0.11.x.
<tkamppeter> pitti, the tarball is completely uploaded. Did you already download it?
<ScottK> Tonio_: Just in the archive, AFAIK
<Tonio_> ScottK: yup seems like :)
<pitti> tkamppeter: got it
<pitti> tkamppeter: I re-added the ubuntu check to ubuntu-disable-browsing.dpatch, too; should be okay now
<tkamppeter> pitti, sorry, I have overlooked that there was a check in the patch when I have regenerated all the patches.
<tkamppeter> pitti, please remove the entry "Everything except the handling of the now integrated CUPS DDK is done." from the beginning of the debian/changelog, I have forgotten to remove it.
<pitti> tkamppeter: done
<pitti> tkamppeter: hm, package FTBFSes for me
<tkamppeter> pitti, what did you change in debian/control?
<pitti> tkamppeter: I added the pkg-config b-dep
<pitti> tkamppeter: http://people.canonical.com/~pitti/tmp/cups_1.4.0~svn8773-1_i386.build -> do you get the same?
<tkamppeter> pitti, I have built it without your changes (my commit of yesterday evening) on my current Karmic and there it works.
<pitti> tkamppeter: hm, i just reenabled pdftoopvp
<pitti> something seems to be utterly wrong with the test sutie
<pitti> E [25/Aug/2009:17:38:06.297790 +0200] [cups-driverd] Bad driver information file "/usr/share/ppd/openprinting/Kyocera/ReadMe.htm"!
<pitti> E [25/Aug/2009:17:38:06.587960 +0200] [cups-driverd] Skipping "/usr/share/ppd/1-local-admin": loop detected!
<sebner> pitti: I'm wondering if both traces are useful for you. jmicron one is a funny one with: write(2, "Failed to open disk jmicron:/dev/sdb: Success\n", 46) = 46
<tkamppeter> This has nothing to do with the presence of pdftoopvp. Problem is the following:
<pitti> lrwxrwxrwx 1 root root 20 2009-07-31 20:59 /usr/share/ppd/1-local-admin -> /usr/local/share/ppd
<pitti> eww, that looks wrong
<pitti> ah, you removed them from postinst already
<tkamppeter> The links /usr/share/ppd/1-local-admin and /usr/share/ppd/2-third-party make parts of the PPD repo read twice by CUPS. CUPS finds inodes which it has already read and thinks there is a link loop. For this it logs an error message.
<tkamppeter> In addition, from CUPS 1.4.0 on no non-PPDs in the PPD repo are permitted.
<pitti> tkamppeter: so if I have openprinting-ppds installed, cups' test suite fails?
<pitti> is that a bug in the test suite, in cups, or in openprinting-ppds ?
<tkamppeter> You have to manually delete /usr/share/ppd/1-local-admin, /usr/share/ppd/2-third-party, and /usr/share/ppd/openprinting/Kyocera/ReadMe.htm, then CUPS will build.
<pitti> (I guess in openprinting-ppds)
<pitti> tkamppeter: so perhaps the Readme should be moved to /usr/share/doc/ ?
<tkamppeter> Once it is a bug of the test suite, it should not check the health of the system but only of the CUPS package.
<pitti> *nod*
<tkamppeter> Second, the 2 links are part of CUPS. I have modified the maintainer scripts of CUPS to drop these links.
<bdmurray> Keybuk: I don't believe so
<tkamppeter> Third, the /usr/share/ppd/openprinting/Kyocera/ReadMe.htm is part of openprinting-ppds, source package foomatic-db. I will upload a fixed version today or tomorrow.
<pitti> DktrKranz, pochu: congrats to your new DD badge!
<pitti> tkamppeter: ok, great; thanks!
<pochu> pitti: :D thanks!
<tkamppeter> pitti, can you report a CUPS STR on the test suite? The test suite's results should not depend on the installed system, but only on the CUPS package itself.
<pitti> tkamppeter: so now it just fails with "PPD import FAILED"
<pitti> Dateien ppd/stcolor.ppd und ppd2/stcolor.ppd sind verschieden.
<pitti> etc.
<ogra> evand, is usb-creator to do anything if i give it a .img file and point it to my SD mmc card ? i seem to just get a stuck progressbar window
<pitti> tkamppeter: can do, it should use the local ppd directory only indeed
<evand> ogra: is there anything relevant in /var/crash or ~/.usbcreator.log?
<ogra> its sittring there, i doubt it created any crash report
 * ogra digs
<tkamppeter> pitti, this one I did not get. Does CUPS ship ready-made PPDs of its sample drivers and tries to regenerate them from its .drv file?
<tkamppeter> pitti, perhaps it uses system resources here, too.
 * pitti tries to buildl with C locale
<DktrKranz> pitti: thanks!
<ogra> evand, http://paste.ubuntu.com/259338/ is the log
<tkamppeter> I succeeded to build CUPS on Ubuntu Karmic. Are you trying on Debian Unstable?
<directhex> go go gadget jaunty
<ogra> evand, thats an old logfile it seems, timestamp is from aug. 16th
<pitti> tkamppeter: hah, that was it; apparently it doesn't like being run in a German locale
<evand> ogra: what version are you using?
<pitti> tkamppeter: I'll report this, too
<tkamppeter> pitti, one should do away with translated logs, the cause a lot of problems, including bug reports which are not understandable.
<ogra> evand, 0.2.2
<pitti> tkamppeter: I guess the tests regenerate the PPDs somehow and compare them to the original, to ensure that the regeneration works; but that introduces German strings, causing them to differ
<tkamppeter> pitti, my boxes are all set up in English.
<pitti> tkamppeter: s/I guess/it looks like/
<tkamppeter> pitti, strange that these PPDs are not globalized.
<lool> pitti: Hey would you mind looking at NEW binaries for linux-meta-mvl-dove on armel?
<pitti> tkamppeter: "globalized"? it does use the local ppds for the tests, as it seems
<pitti> lool: to main, I presume?
<lool> pitti: Yes
<lool> pitti: Thanks a lot
<tkamppeter> pitti: Globalized PPDs are an invention of Mike Sweet, PPDs containing translations into many languages, see CUPS PPD extensions.
<tkamppeter> Perhaps I am promoting them more than Mike, once having moved the Gutenprint project to use them and second supporting them in the Common Printing Dialog.
<pitti> lool: ugh, that's an entirely new kernel
<lool> pitti: Yes, like linux-fsl-imx51
<lool> pitti: I'm sorry you discover about this now; the kernel team discussed this plan with slangasek during the sprint I believe
<lool> pitti: I just know I need the new meta packages for the dove image build for A5  :)
<pitti> lool: yes, I heard about it, don't worry
<lool> Ok cool
<pitti> it'll just take a bit more than 30 seconds, that's what I meant
<lool> Ok
<tkamppeter> pitti, all you FTBFS problems should not occur on the build servers, they should not have CUPS and openprinting-ppds installed, and they should also use English locale.
<pitti> tkamppeter: right, but I like the package to be buildable on my system, too :)
<pitti> I'll fix the locale issue
<pitti> W: libcupsppdc1-dev: spelling-error-in-changelog contraints constraints
<pitti> wow, lintian is really good these days
<superm1> hi tkamppeter, what's up?
<tkamppeter> piit, me too. Would be bad to run a pbuilder only to try out a small fix.
<tkamppeter> superm1, it is an incompatibility of bluez with the new CUPS 1.4, bug 418465.
<ubottu> Launchpad bug 418465 in bluez "bluetooth CUPS backend should not take more than 10 seconds in discovery mode" [Medium,New] https://launchpad.net/bugs/418465
<tkamppeter> The thing what has to be done is that the bluetooth CUPS filter should run less than 10 seconds in discovery mode.
<pitti> tkamppeter: hm, it's not just translations, indeed most of the numbers in the ImageableArea are wrong; I'll file a bug upstream
<tkamppeter> superm1: One would need to set its timeout to 8 seconds, so that it finishes in less then 10 seconds.
<tkamppeter> pitti: Then I am wondering why the tests got passed for me.
<pitti> tkamppeter: you aren't usin German locale
<tkamppeter> pitti: The numbers in ImageableArea change with locale?
<pitti> apparently so
<tkamppeter> pitti: Does a comma get inserted instead of the decimal point? Then the PPDs built on systems with non-English locale are completely broken.
<pitti> tkamppeter: see http://www.cups.org/str.php?L3300
<pitti> tkamppeter: no, most paper format boundaries are "0,00"
<pitti> tkamppeter: so I won't workaround this for now, and wait for Mike's response
<pitti> tkamppeter: but I'll upload it to Debian experimental and karmic
<tkamppeter> pitti, the boundaries should be 0.00 and not 0,00.
<pitti> lool: why does it produce a package "linux-headers-2.6.31-201"? that looks weird
<pitti> or in general, why does it use such a weird abi?
<cjwatson> pitti: can you confirm whether a blacklist in pkgstriptranslations would be a reasonable way to stop bombarding Rosetta with a load of .po files that are in the source package but shouldn't be imported?
<cjwatson> pitti: I see that it fishes out .po files already
<pitti> tkamppeter: in my sid chroot it fails with "E [25/Aug/2009:16:17:48.540155 +0000] [CGI] Unable to create avahi client: No such file or directory
<pitti> tkamppeter: I guess that's just a missing build dep, like avahi-utils or so? did you happen to get this already? (if not, I'll figure it out)
<tkamppeter> pitti, no for me all works correctly.
<pitti> tkamppeter: urgh, I bet it needs a running d-bus or something such
<robbiew> Keybuk: nice "inutes"
<robbiew> heh
<pitti> tkamppeter: you didn't test it in a pbuilder or so, I take it?
<tkamppeter> No, no pbuilder test.
<Keybuk> robbiew: the meeting confirmed that we couldn't agree on what "M" means
<Keybuk> so I felt it best to omit it
<pitti> cjwatson: right now it doesn't remove any po files, but we can certainly teach it to; what do you have in mind?
<robbiew> lol
<cjwatson> pitti: ubiquity/d-i/source/...
<pitti> cjwatson: originally we said we'd be cautious, get everything, and leave it to LP to decide which it wants, so that we avoid having to rebuild a thousand packages if the importer has a bug
<cjwatson> apparently the volume of files that have to be reviewed there is a serious problem for Arne :-/
<Keybuk> cjwatson: boy do I have a *brilliant* bug; you'll like this one.  bug #412972
<ubottu> Launchpad bug 412972 in procps "can only kill processes with -9 in karmic from SSH sessions, -TERM does not work" [Medium,Incomplete] https://launchpad.net/bugs/412972
<cjwatson> Keybuk: there's a not dissimilar bug on openssh that alleges that sshd's signal mask is wrong
<cjwatson> I haven't looked into it yet ...
<cjwatson> (largely because most of the analysis happened while I was on holiday)
<Keybuk> why would that make kill() return -ESRCH though
<Keybuk> it's the same reporter, interestingly
<Keybuk> if it were the signal mask, the kill() should succeed from the client side but just not be delivered to the receiving side
<Keybuk> (it'll be still queued)
<Keybuk> to me, -ESRCH starts to imply that there's something funny with pid namespaces going on
<cjwatson> hmm
<cjwatson> I'd be astonished if sshd messed around with that
<cjwatson> maybe some PAM session stuff?
<Keybuk> dunno
<Keybuk> the reporter says that if he runs "sleep 100"
<Keybuk> then attempts to kill -TERM that pid, he gets -ESRCH
<Keybuk> he hasn't elaborated which of the sleep or kill is running under ssh yet
<pitti> lool: so, packages look okay to me except for the weird ABI; if that is intended, I'll new them
<superm1> tkamppeter, did cups previously kill backends?
<superm1> or just let them keep running?
<chrisccoulson> who do i subscribe to a bug report requesting a package be demoted from main to universe?
<Keybuk> chrisccoulson: that takes place automatically
<Keybuk> well, entirely manually
<Keybuk> but the people who do it manually do it automatically
<chrisccoulson> Keybuk - so i shouldn't need to explicitly request it?
<Keybuk> chrisccoulson: assuming that nothing in main depends on that package (including ubuntu-meta), no
<Keybuk> it'll be flagged for removal and the archive admins will get around to it
<chrisccoulson> Keybuk - thanks
<mathiaz> Keybuk: hi - I've got an issue with a daemon that is using dbus
<mathiaz> Keybuk: https://fedorahosted.org/pipermail/sssd-devel/2009-August/000257.html
<mathiaz> Keybuk: one of the upstream dev noted it may be related to the version of libdbus in karmic
<mathiaz> Keybuk: https://fedorahosted.org/pipermail/sssd-devel/2009-August/000261.html
<mathiaz> Keybuk: how can I debug this thing to figure out where the problem may be?
<Keybuk> I doubt it
<Keybuk> it's far more likely a bug in whatever security policy they've installed with the daemon
<Keybuk> you can rebuild libdbus with --enable-verbose-mode and then use DBUS_VERBOSE=1 to see what each end is doing
<mathiaz> Keybuk: ok - where can I find the security policy?
<Keybuk> /etc/dbus-1/system.d
<mathiaz> Keybuk: hm - AFAICT there isn't any security policy installed.
<Keybuk> then that's why it fails ;-)
<Keybuk> if there's no security policy, then the bus daemon will *deny* all messages
<Keybuk> tbh, it's probably even refused the service from registering any name on the bus to begin with
<Keybuk> /etc/dbus-1/system.d/Upstart.conf is as good an example of a security policy as any
<Keybuk> note that it's all <allow...>, because the default for everything on the system bus is <deny...>
<ion> SSSD â more precisely, offline caching of network credentials â seems exactly what iâve wanted for a long time.
<mathiaz> Keybuk: great - thanks for the help.
<Keybuk> mathiaz: in particular, note that it allows the root user to own the "com.ubuntu.Upstart" name
<Keybuk> (even root needs permission to take a name)
<ogra> pitti, didnt you promote the dove package today ?
<Keybuk> and that it allows the root user to send messages to "com.ubuntu.Upstart" using the "com.ubuntu.Upstart0_6" interface
<Keybuk> (even root needs permission to send messages)
<pitti> ogra: I checked the dove kernel in NEW, and asked lool about the weird ABI number (201)
<pitti> ogra: if that's intended, I'll NEW it
<debfx> any chance pidgin 2.6.1 makes it into karmic? (bug #415908)
<ubottu> Launchpad bug 415908 in pidgin "Please merge pidgin 2.6.1-1 (main) from Debian experimental (main)" [Unknown,Fix committed] https://launchpad.net/bugs/415908
<ogra> pitti, oh, i thought you promoted them to main too
<ogra> pitti, reading my backscroll lool apparetnly only asked for de-newing
<pitti> ogra: sure, I set it to main, but didn't accept them yet
<ogra> oh, please do so :)
<pitti> ogra: I asked him for "main?" and he said yes
<ogra> the ABI numbers were chosen by the kernel team
<pitti> ogra: okay
<ogra> 100+ for imx51 200+ for dove
<ogra> 300+ for netbook i think
<ogra> or some such ...
<ogra> pitti, the depending linux-image-dove needs to go to main too
<pitti> ogra: hm, linux-image-dove is already in karmic universe (just -z0 are NEW)
<pitti> was that intended?
<ogra> no, but it happened :P
<ogra> it was intended by the kernel team though
<ogra> so its all fine as is
<ogra> but we need all of that in main to build livefs'es
<pitti> so why should one kernel be in main, the other in universe?
<ogra> we dont build z0 images
<ogra> and never will
<pitti> so why shold -dove-z0 go to main, and -dove stay in unverse?
<ogra> z0 is a dead architecture, but some of us have that board
<pitti> that doesn't make sense to me then
<ogra> no, all -dove to main
<ogra> all -dove-$suffix can stay where it is
<pitti> but that's not what happened
<pitti> -dove *is* in karmic, and in universe
<pitti> -dove-z0 is NEW
<ogra> i think lool assumed the -dove stuff was in main already
<ogra> so meta for -dove and linux-image for -dove are needed in main
<ogra> the rest i totally dont care where it lands
<pitti> okay
<ogra> sorry for that chaos
<pitti> so I'll move the existing -dove meta packages to main
<pitti> and -z0 to universe
<ogra> -dove and -imx51 are a mess atm
<ogra> yes, please
<pitti> all done
 * ogra hugs pitti 
<tkamppeter> superm1: Previously CUPS left backends running as long as they wanted, making device discovery very long.
<tkamppeter> superm1: Now CUPS starts all backends at once and kills all backends which remain running after 10 seconds.
<pitti> tkamppeter: ah, Mike ack'ed the locale bug
<tkamppeter> superm1: So a CUPS backend must finish quicker than 10 seconds, or it must report each discovered device immediately when it discovers the device.
<tkamppeter> pitti, great. There seem to be two problems, ',' as decimal separator and also different numbers.
<lool> pitti: Sorry was in calls
<lool> pitti: Kernel team said they wanted to avoid namespace clashes and so used 0/100/200 for ABI base numbers in subarches
<pitti> lool: don't worry, all settled
<ogra> lool, all sorted now
<lool> pitti: I dont know why exactly since we have a prefix of imx51 or dove already, but I trust them that it's needed
<lool> pitti, ogra: Cool thanks
<tkamppeter> pitti, is all working with the CUPS upload now?
<pitti> tkamppeter: got interrupted by desktop team meeting, resuming cups work now
<tkamppeter> pitti: OK.
<pitti> tkamppeter: no, still need to figure out the broken package build (avahi failure)
<tkamppeter> I have added two avahi libraries to the build dependencies. Does this not do everything needed.
<tkamppeter> pitti: ^^
<pitti> avahi_client_new() fails
<pitti> tkamppeter: as I said, I need to strace it and see where it fails
<tkamppeter> pitti: Strange, I have updated my Karmic before working on CUPS 1.4.
<pitti> tkamppeter: I already said, it only happens in a chroot or pbuilder
<pitti> I suspect it needs some running dbus or so
<pitti> Keybuk: udev> thanks for cleaning up my bug list
<Keybuk> pitti: :D
<superm1> tkamppeter, well i'm not sure where the timeout is defined, you might need to talk to upstream about it
<superm1> it might be something like a default dbus timeout too
<tkamppeter> superm1: The other alternative is to output a printer's entry as soon as it gets discovered.
<superm1> tkamppeter, well i think you'll need to find out where the hang up is then first
<tkamppeter> superm1: All output which the program produces in the first 10 seconds will be captured by CUPS, everything coming out later not.
<cody-somerville> How do I make the fonts in the latest firefox not so ugly?
 * ogra hands cody-somerville some nice calligraphic quill and some waterproof ink for his screen
<cody-somerville> :)
<mathiaz> james_w: hey - could your bump the dbus import in the packaging branch queue?
<james_w> mathiaz: no, sorry
<james_w> mathiaz: LP going down at the weekend caused a lot of problems for it, and I'm busy with other things to bring it back up
<jjohansen> cody-somerville: you can try changing the default font, or try chrome
<james_w> mathiaz: I'll try and get to it soon, but don't block on having it to do your work
<mathiaz> james_w: sure - it's not urgent
<cody-somerville> jjohansen, I tried but it still looks weird
<cody-somerville> jjohansen, I wish firefox would just use the system default font like it used to
<mathiaz> james_w: just more convenient - and I'm not blocked at all by this.
<james_w> great
<jjohansen> cody-somerville: yeah
<jjohansen> cody-somerville: have you tried editing via about:config
<cody-somerville> no
<sgallagh> Keybuk: ping
<ogra> cody-somerville, didnt change here
<ogra> for me it uses the system default
<cody-somerville> ogra, are you using firefox 3.5.2?
<ogra> whatever fontconfig uses for sans, serif and mono
<ogra> yup, thats what the about win says
<ogra> looks like it always did
<ogra> cody-somerville, probably fontconfig doesntg get along with your nvidia driver or something
<cody-somerville> ogra, well, as soon as I upgraded, it started using font size 16
<cody-somerville> ogra, firefox wouldn't happen to maybe looking to gconf for defaults would it?
<ogra> not that i know of
<ogra> but DPI settings might change between releases
<ogra> thats X related
<ogra> mine defaults to 16 here
<ogra> but doesnt look any different from the rest of the screen
<ogra> is that gnome or xfce ?
<ogra> afaik gnome leaves the DPI size totally to the X server nowadays
<Keybuk> sgallagh: hi
<mathiaz> Keybuk: it turns out that sssd doesn't use the dbus daemon
<ogra> while it didnt use to before
<kirkland> Keybuk: around?
<mathiaz> Keybuk: http://paste.ubuntu.com/259439/
<sgallagh> Keybuk: Hi, mathiaz asked me to talk to you about D-BUS
<Keybuk> gah
<Keybuk> the Keybuk Deli Counter queue begins -> there
<mathiaz> Keybuk: this is what sgallagh was doing to debug the dbus issue with sssd
<kirkland> "no soup for you!"
<Keybuk> right :)
<Keybuk> sgallagh: so you're using a peer-to-peer dbus connection?
<sgallagh> Keybuk: Yes, the monitor acts as a server in this case.
<sgallagh> Keybuk: (also the Data Provider has a server for other portions of the code as well, but it's exhibiting the same behavior, so it's easier to just talk about the monitor)
<Keybuk> ok
<Keybuk> can you pastebin the strace you were talking about
<Keybuk> http://paste.ubuntu.com/259440/
<Keybuk> is what I see when establishing a peer-to-peer connection
<sgallagh> Keybuk: Do you want both the working and non-working versions for comparison
<sgallagh> Also, probably easier to email them, as they're fairly large...
<Keybuk> just cut the relevent bit out of the strace
<Keybuk> but sure
<Keybuk> (socket through to the first write() after BEGIN is fine)
<sgallagh> Actually, might take a few. My VM got hosed as I tried to drop the 1.2.12 version of libdbus in place to see if it fixed things. Big mistake.
<kirkland> Keybuk: so i encountered a regression after upgrading today ... i'm using encrypted swap, boot is hanging trying to modprobe padlock-sh
<kirkland> Keybuk: the module is in my /lib/modules dir
<Keybuk> kirkland: nothing to do with me
<kirkland> Keybuk: nothing to do with initramfs?
<Keybuk> kirkland: no idea, I've not touched it certainly
<kirkland> Keybuk: cool, thanks.
<kees> kirkland: does ecryptfs need a hook to copy that module into the initramfs?
<kirkland> kees: hmm, i've never had to copy it there before
<mr_pouit> mayb/w 14
<mr_pouit> grr
 * kirkland thanks pitti
<NCommander> Riddell, ping, can you please promote linux-dove (and all the binaries from linux-meta-mvl-dove)) to main ASAP? (hopefully before the next publisher cycle
<sgallagh> Keybuk: http://paste.ubuntu.com/259446/ (the Karmic version)
<NCommander> or any archive admin?
<sgallagh> Keybuk: http://paste.ubuntu.com/259449/ (the working Fedora version)
<pitti> NCommander, Riddell: but I already did?
<NCommander> pitti, LP says its still in universe
<NCommander> (the binaries that is)
<pitti> NCommander: only the -z0 stuff, as per ogra's request
<NCommander> pitti, https://edge.launchpad.net/ubuntu/karmic/armel/linux-dove/2.6.31.201.2 - Component: universe
<pitti> $ change-override.py -c main linux-dove linux-headers-dove linux-image-dove
<pitti> hmm
<pitti> that's in my bash history
<pitti> me does again
<NCommander> pitti, that time it bumped to main
<NCommander> pitti, Component: main/Status: Pending
<NCommander> pitti, BTW, are you using your g10code PGP smartcart yet?
<pitti> NCommander: no, just returned from holidays, and zero time to play with it this week :/
<pitti> are you?
<NCommander> pitti, I wrote a guide on how to generate subkeys and set it up, BUT, there seems to be a bug when using a 3072 encryption keys
<NCommander> (3072 authentication and signing keys seem to be ok)
<sgallagh> Keybuk: I'm not sure the problem is in libdbus anymore. I just dropped the .so from my fedora rawhide machine (also running 1.2.16) onto the Karmic VM and got the same results.
<Tonio_> siretart: should I replace the all "unstripped" stuff in the restricted extra packages ? that also concerns libavformat, libpostproc and libswscale (I don't know much about ffmpeg, so better asking !)
<Keybuk> sgallagh: no, it doesn't look to me like it is
<Keybuk> looks like libdbus is fine
<sgallagh> Keybuk: I'm kind of at a loss why this is failing on Ubuntu only. It works just fine on Fedora and opensuse.
<kirkland> bryce: rock!
<kirkland> bryce: 1024x768 karmic guest today :-)
<bryce> kirkland, excellent
 * YokoZar wants to read the Ubuntu User magazine article about Wine...
<jpds> YokoZar: Red or white?
<jdstrand> kees: regarding libdrools-core-java MIR: it looks ok from a packaging perspective. I am curious about debian/patches/drools-compiler-compilation.patch since it is undocumented, but other than that no issues
<NCommander> are there any known issues with publisher at the moment?
<NCommander> I have a package resolutely stuck in universe
<kees> jdstrand: cool, can you add your notes to the MIR wiki: https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages
<jdstrand> kees: sure, np. I've yet to do eucalyptus-commons-ext
<kees> jdstrand: cool.  My eyes have started to cross, so I'm done with MIRs for the moment.
<cjwatson> NCommander: looks fine. what package?
<NCommander> cjwatson, linux-dove, and all the linux-meta-mvl-dove binary packages except the z0 ones
<cjwatson> NCommander: madison-lite on cocoplum shows all those as being in main
<NCommander> cjwatson, any idea why its still in universe in ports.u.c?
<cjwatson> the universe link will hang around for a while. have you checked main as well?
<NCommander> cjwatson, not there
 * ogra goes mad trying to find all occurences of "babbage" in any code to peel it out with a toothpick
<NCommander> cjwatson, correction
<cjwatson> NCommander: the files are in http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-meta-mvl-dove/
<ogra> god, why did we every change that name
<NCommander> cjwatson, there as of 10 minutes ago
<NCommander> cjwatson, I'm starting to think I have a proxy between me and the UK
<cjwatson> seems plausible
<NCommander> (its not the first time I've had this issue)
<NCommander> cjwatson, sorry for the noise
<cjwatson> np
<ogra> * Chose mouse-modules-2.6.31-0-babbage-di, mouse-modules-2.6.31-100-imx51-di out of mouse-modules to satisfy rootskel-gtk
 * ogra falls over in tears
<NCommander> cjwatson, I do have some debian-cd changes that need merging to get dove images spinning. If my rootfs's properly build, would you be interested in helping do the merge?
<ogra> i dont think i have ever seen a bigger mess in all my ubuntu years
<cjwatson> NCommander: not before tomorrow morning
<cjwatson> but then, sure
<ogra> cjwatson, thats a very good statement ...
<pitti> tkamppeter: I didn't test the new cups 1.4 on Ubuntu yet; I take it you did? (takes me quite some effort to test with a real printer)
<pitti> tkamppeter: it's uploaded to Debian experimental now, about to uplaod to karmic
 * ogra decides to follow that hidden suggestion and go on fixing the mess with a clear head 
<tkamppeter> pitti, OK.
<NCommander> ogra, is there anything I can do to help?
<pitti> tkamppeter: I finally got it to build, and sent the sugested avahi patch change upstream
<ogra> NCommander, no, i think i solved the last issue for imx51 live builds now, i'll dig deeper into d-i tomorrow
<tkamppeter> pitti, it principally works, but there are some things to polish. I have already done some adaptations on s-c-p (today's upload).
<tkamppeter> pitti, I have seen it in CUPS bug 3066.
<NCommander> ogra, I think dove will work since I can finally see the metapackages in main here
<ogra> NCommander, great and it looks like your livefs build will complete too, so lets merge that debian-cd stuff tomorrow ...
<tkamppeter> ubottu went sleeping already.
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<ogra> and we need to chase lamont it seems, clementine got its clock wrong again
<ogra> but thats for tomorrow too
<tkamppeter> CUPS STR 3066
<NCommander> ogra, <lamont> totally right, it just thinks it's in taipei
<ogra> NCommander, i thought he fixed that a few days ago
<lamont> ogra: it still thinks it's in taipei
<ogra> we talked about it on the weekend already
<ogra> lamont, ah, ok
<lamont> does it matter lots and lots?
<ogra> if it remains like that i'm fine and wont be surprised again if my logs are from tomorrow :)
<lamont> though I should fix it I suppose, it's kinda low on the ZOMG scale
<ogra> no, only for the log timestamps
<ogra> right, put it on very low importance level :)
<pitti> tkamppeter: ok, basic tests work fine here, too; uploading to karmic now
<ogra> NCommander, http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-dove/ should have a build log to inspect in about 1h or so, if you see it rolling a squashfs at the end thats a good sign :)
 * ogra is off for the day
<NCommander> ogra, thanks, I'm running one here too.
<NCommander> ogra, I  may ask Steve to handle merging the d-cd changes if I'm still awake
<kees> pitti: if you have a moment, can you do MIR assignments for https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages ?
<pitti> kees: about to fall to bed, but I'll attack it ASAP
<kees> pitti: ah! no worries, I made a bunch of headway on it today.
<pitti> kees: FYI, lool and I decided to promote the lot tomorrow, and do reviews afterwards, to take the pressure out (FF crunch)
<kees> pitti: sounds good
<pitti> kees: I also hope to get some done soon, but there's some higher-urgency FF stuff that I have to do
<pitti> kees: (not to the least, security-apport-abort-handler :) )
<kees> pitti: yeah, that's why I hadn't gotten to it yet.  but I got a ton of stuff done yesterday to clear the way
<pitti> kees: thanks muchly
<kees> pitti: yea, I'd love to see that get in too.
<pitti> kees: if the stuff is in main already, we can review the packages after FF
<pitti> (IMHO)
<kees> my "before FF" list is waaay too long, like everyone else's.  :)
 * kees nods
<kees> excepting libxml-security-java, most of the stuff I've found is minor.
<pitti> good night everyone
<ion> ght
<jdstrand> kees: fyi only-- all the reviewneeded NEW re-review should be done. james_w did the lion's share of that, and I finished the 2 he left for me
<kees> jdstrand: cool, great.  I worked through most of the ones he hit plus all the security-review ones
<kees> (and then I colorized the wiki!_
<jdstrand> kees: I saw that. it's purty
<kees> I was thinking it was actually blinding, but useful.  :)
 * jdstrand finds it blindingly beautiful
<kees> haha
<kees> this is ... strangely familiar.
 * jdstrand nods
<jpds>  /13
<slangasek> StevenK: so is readline-common's dep a problem in practice, and if so why?
<StevenK> slangasek: ogra uploaded a new one -- but livecd-rootfs really wasn't dealing with it well
<slangasek> hrm, ok
#ubuntu-devel 2009-08-26
<YokoZar> Hmm, it seems like wine1.2-gecko was deleted from the archive
<YokoZar> or maybe it never built in the first place...
<TheMuso> /c/c
<Redman> #ubuntu-programming
<al-maisan> Hello there! The new 2.6.31-7-generic kernel gets stuck  (i.e. just sists there, won't boot up) on my lenovo T61 after unlocking an encrypted physical volume. What's the best way to debug this?
<StevenK> al-maisan: Does it work if you boot -6?
<al-maisan> StevenK: yes, that's what I fell back to ..
<al-maisan> i.e. that's the kernel I am running presently
<TheMuso> al-maisan: Someone reported that the 7 kernel breaks encrypted lvm in here yesterday, I think it was dtchen, who is not currently around atm.
<al-maisan> TheMuso: ah, I see, so it's a known issues. That's good. Thanks for letting me know!
<TheMuso> Whether a bug has been filed, I don't know.
<TheMuso> I'd say there has been.
<al-maisan> OK. I'll search for it.
<al-maisan> TheMuso: Bug #418514
<ubottu> Launchpad bug 418514 in linux "linux-image-2.6.31-7.27-generic fails to boot lvm" [Medium,Confirmed] https://launchpad.net/bugs/418514
<TheMuso> al-maisan: good to hear that there is one.
 * TheMuso notes that he is not affected by this.
<al-maisan> Yeah .. just wanted to make sure it's a known issue.
<TheMuso> Hrm so its not just encrypted LVM, but LVM as well. Hrm maybe I'll have to avoid that kernel as well, since I use LVM not encrypted here...
<al-maisan> yep.
<dholbach> good morning
<vorian> evening!
<al-maisan> good morning dholbach :)
<dholbach> hey al-maisan!
<pitti> Good morning
<StevenK> pitti: Morning!
<pitti> hey StevenK
<StevenK> pitti: It seems all of libcupscgi1 libcupsdriver1 libcupsmime1 libcupsppdc1 cups-ppdc ended up in universe, I promoted them about 15 minutes ago
<pitti> StevenK: ah, thanks
<StevenK> pitti: When you have a sec, could you look at bug 419029 ?
<ubottu> Launchpad bug 419029 in humanity-icon-theme "Please promote humanity-icon-theme" [Undecided,New] https://launchpad.net/bugs/419029
<pitti> StevenK: approved, bug updated
<pitti> no-brainer
<StevenK> pitti: Thanks, I'll promote it
<dholbach> can we all try to unsubscribe the sponsors teams from requests that are very old and waiting for input?
<dholbach> the list is HUGE
<dholbach> vorian: what about bug 386428?
<ubottu> Launchpad bug 386428 in xom "Please merge xom_1.2.1-1 (universe) from debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/386428
<dholbach> ArneGoetje: what about bug 407649?
<ubottu> Launchpad bug 407649 in scim-anthy "Sync scim-anthy 1.2.7-1 (main) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/407649
<dholbach> ogra: can you take a look at bug 385850?
<ubottu> Launchpad bug 385850 in hundredpapercuts "Ship fewer screensavers by default" [Low,Confirmed] https://launchpad.net/bugs/385850
 * nixternal hugs dholbach 
 * dholbach hugs nixternal back
<ArneGoetje> dholbach: pitti will take care of the sync today
<pitti> already done
<pitti> oh, I didn't know that you filed new sync bugs, please close them
<pitti> I thought the requests in the MIR bug were enough
<pitti> dholbach, ArneGoetje ^
<ArneGoetje> pitti: oh, sorry, that one is scim-anthy
<pitti> oops, indeed, sorry
<dholbach> yep
<pitti> I synced ibus
<pitti> nevermind me then
<dholbach> if scim-anthy should go to universe, we should be able to sync it
<dholbach> and not promote a new recommends to main
<ArneGoetje> dholbach: well, I will change the language-support-input-* dependencies today to pull ibus instead of scim. So, I think it's safe to put it into universe
<dholbach> pitti: looks good to you?
<pitti> sure, but it shouldn't be done before it actually gets demoted
<dholbach> ok
<dholbach> I'll leave it like that then
<ArneGoetje> so, change the seeds and language-support- stuff first?
<pitti> yes
<dholbach> if anybody could double-check bug 414298 I'd appreciate it
<ubottu> Launchpad bug 414298 in devscripts "Please merge devscripts_2.10.53 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/414298
<ojwb> mvo: any issues with that xapian-core patch?
<mvo> ojwb: no, its seems to be working just fine. no open bugs or crashreports since I uploaded it
<mvo> thanks again for the patch!
<ojwb> cool, I'm just preparing a new upstream release
<dholbach> I guess the "machine does not power down on shutdown" bug is already known? IIRC it happens since the -7 kernel
<mvo> dholbach: I have it here too
 * pitti too
 * TheMuso is not yet on 7 due to the lvm bug.
<ArneGoetje> pitti: would it be possible to seed ibus-m17n with its dependencies onto the LiveCD?
<pitti> ArneGoetje: I didn't compare sizes yet; how much space does scim and the default tables take?
<ArneGoetje> pitti: how do I find out?
<pitti> apt-cache show packagename | grep ^Size
<pitti> for all the scim related packages we ship by default
<pitti> you can use the .manifest files on cdimage.u.c. daily-live/current to see the list of packages which we ship by default
<ArneGoetje> thanks, that would help alot
<pitti> an easier method might be to have a clean chroot, and then do "apt-get install <all packages>" and see how much stuff apt needs to download
<pitti> with "all packages" being either all seeded scim or all to-be-seeded ibus packages
<pitti> that's quick for comparing, since it also considers all library dependencies
<pitti> sudo apt-get install ibus ibus-m17n on my system -> 3370kB
<pitti> (I think you needed some more, right?)
<kagou> Hi,is it possible to collect data for an existing bug ? I mean that ubuntu-bug collect data for a package or a PID but not for an existing bug.
<pitti> kagou: yes; man apport-collect
<kagou> oh
<kagou> damned ! thanks pitti
<pitti> :)
<kagou> may be ubuntu-bu should be enhanced to report to bug too ?
<ArneGoetje> pitti: I'll make a list
<pitti> kagou: yes, it could be made clever enough for that
<cjwatson> oh, seriously, -7 breaks lvm? that's going to be amusing for the installer work I need to get done TODAY
<cjwatson> how exactly does it break lvm? the bug is not very clear, and the one clear symptom (padlock_sha failing to load) wouldn't affect ordinary lvm
<cjwatson> so I wonder if some bug conflation is going on
<kagou> pitti, I'v open a bug for that #419093
<slytherin> Hi, with latest pulseaudio in karmic, I have very low volume for songs etc. Is this expected?
<TheMuso> slytherin: No, this is not expected.
<slytherin> Ok. I will log a bug when I go home.
<TheMuso> slytherin: Is this on your ibook?
<slytherin> TheMuso: No. My PC. I never had to turn the speaker volume to full before (in jaunty).
<TheMuso> slytherin: ok then, please file a bug when you get the chance.
<slytherin> I will tonight.
<\sh> I wonder how do I get sound from flashplayer on karmic 64bit again..the app doesn't show up in pulse mixer somehow...so I don't know where pulseaudio is routing the audio stream to
<ogra> mumble, no glazor
<ArneGoetje> pitti: are you sure I need to gret for ^Size: and not for ^Installed-Size?
<ArneGoetje> grep
<dholbach> TheMuso: not sure if you noticed, but python-louis is in universe
<TheMuso> dholbach: an MIR has been written for it and it has been approved.
<TheMuso> dholbach: I would not have done that otherwise.
<dholbach> ah ok
<pitti> ArneGoetje: yes; we are interested in the compressed size (.debs)
<ArneGoetje> pitti: ok...
<taavikko> any way for ubuntu-bug to just create the report e.g"test.report" which then could be sent via ssh to other machine and reported that way?
<pitti> taavikko: unfortunately not with ubuntu-bug; it's meant to be a parameter-less easy interface
<pitti> taavikko: you can use apport-cli -f -p <package> and save the report, see manpage
<pitti> taavikko: or, if it's a crash (not a bug report), just don't send it and scp /var/crash/... file
<taavikko> thanks pitti :) seems ubuntu-bug works in xterm session so no nee
<pitti> taavikko: yes, it uses apport-cli if there's no $DISPLAY
<\sh> if any archive admin of the day can look at bug #419099 that would be great...we would like to get this solved before FF
<ubottu> Launchpad bug 419099 in fai "Please remove fai source package and all resulting binary packages from karmic" [Undecided,New] https://launchpad.net/bugs/419099
<taavikko> thanks for all the work on ubuntu-bug/apport it makes it so much easier to provide better info on bugs.
<pitti> *beam* :)
 * pitti does the finishing touches for intercepting assertion messages in apport
 * directhex calls assert() in some platform code, to make pitti feel needed
<pitti> directhex: Keybuk has plenty of them apparently :)
<directhex> pulse is chock full of 'em
<pitti> ArneGoetje: so, ibus ibus-gtk ibus-m17n pull in 3.5 MB
<ArneGoetje> pitti: http://pastebin.ubuntu.com/259752/
<pitti> ah, that's probably imprecise since I have scim installed
<pitti> which might share some tables
<ArneGoetje> pitti: the numbers in that list are the grep'ed Size: field
<pitti> ArneGoetje: ah, nice
<ArneGoetje> pitti: what apt-get gives you is the Instaled-Size, AFAIK
<pitti> ArneGoetje: that's not just scim->ibus, but also font changes? or are the fonts related to ibus?
<ArneGoetje> pitti: no, font changes are extra
<pitti> ArneGoetje: it gives you both ("Es mÃ¼ssen 3459kB an Archiven heruntergeladen werden." -> deb size)
<pitti> ArneGoetje: ok
<ArneGoetje> pitti: I might do some more font shuffeling, so this list is not final in that regard
<pitti> ArneGoetje: thanks for the analysis
<pitti> ArneGoetje: the seed changes are blocked by the im-switch update, right?
<ArneGoetje> pitti: yeah
<ArneGoetje> pitti: can we discuss the im-switch changes somewhere?
<pitti> sure, /msg?
<ArneGoetje> pitti: ok
<ogra> glatzor, moo
<glatzor> ogra, servus!
<glatzor> ogra, the armel failure?
<ogra> glatzor, you dropped my fix from packagekit :'(
<ogra> yeah
<ogra> hughsie always forgets to drop -Werror from his tarballs
<glatzor> ogra, in the 0.5 series it is optional
 * ogra had that issue a thousand times with gnome-power-manager beforte
<ogra> well, it makes armel ftbfs
<glatzor> ogra, I will rework the patch
<ogra> thanks a lot
<ogra> though it would be nice if he could disable it upstream before rolling a release
<ogra> i know seb128 rants about that all the time too :)
<glatzor> ogra, it is also always a topic on the maling list :)
<pitti> ogra: what's wrong with -Werror?
<pitti> ogra: I'd rather get an armel build fix upstream than to kludge around with it?
<ogra> pitti, armel (sparc and ppc too) often have simple warnings ...
<ogra> pitti, seb always tells me its gnome policy that there is no -Werror in the released tarballs
<liw> why does armel have lots of simple warnings?
<pitti> ogra: I don't know, if that's the policy he should stick to it of course
<pitti> but still, I actually like programs which don't have warnings, too
<ogra> liw, feel free to fix them ... if the app works fine but a build dies because of Werror i perfer to just drop the Werror according to the upstream policy
<liw> ogra, why do the warnings happen on armel but not on x86?
<pitti> that should depend on the actual warning
<ogra> right
<pitti> we had warnings about pointer misalignments which were real bugs
<liw> (I'm not worried, merely mildly curious)
<pitti> ^ me too
<ogra> liw, because certain kinds of vars are handled differemntly for example
<ogra> /usr/include/gstreamer-0.10/gst/gstmessage.h: In function 'gst_message_ref':
<ogra> /usr/include/gstreamer-0.10/gst/gstmessage.h:302: error: cast increases required alignment of target type
<ogra> thats the current warning that makes packagekit die for example
<liw> that sounds like a real bug to me :)
<liw> (but then I'm a C standards compliance purist)
<ogra> the app functions as its supposed to
<pitti> sounds like a potential bug, though
<lifeless> even on sparc ?
<lifeless> :)
<pitti> it wouldn't be the first time that sparc crashes because of a misaligned variable
 * liw wants to sell his hardcover paper copy of the 1999 C standard, thoug
<dholbach> cjwatson: should juli_ be able to upload stuff (libnb-javaparser-java) already?
<cjwatson> yes
<dholbach> thanks cjwatson
<ogra> lifeless, well, http://qa.ubuntuwire.com/ftbfs/ ... packagekit is dep wait on sparc :)
 * ogra thinks if a warning should be a bug or error it should actually spit out an error and not a warning
<ogra> we have tons of packages that build with warnings in the build logs
<ogra> they simply dont have Werror set :)
<Keybuk> pitti: but sadly my asserts don't make it into apport :-(
<pitti> Keybuk: they should now :)
<Laney> happyaron: I'm just looking at tor. Do you know if upstream are going to give you any help with supporting old releases?
<pitti> (not uploaded yet, still finishing touches)
<Keybuk> pitti: how?  I don't use assert() :p
<Keybuk> pitti: also the kernel doesn't wait for apport to complete before panicing yet
<pitti> Keybuk: ah, I thought you did, since you pushed for it in https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-apport-abort
<pitti> Keybuk: the latter point is what I asked about in the whiteboard, that point isn't clear to me
<happyaron> Laney: they seems won't, but I think if update the package in repository is acceptable for us, I can do it
<Laney> you mean a new upstream version?
<Keybuk> pitti: the __assert_msg stuff?  If that works, I can certainly put the message in there :-)
<pitti> Keybuk: right
<happyaron> Laney: I can catch up with the new releases in upstream repository, and re-pack the packages for ours
<Keybuk> pitti: I saw that someone has proposed a patch to make the kernel wait for apport to finish before making the process a zombie as well
<Laney> happyaron: The SRU policy doesn't usually allow for that though
<happyaron> Laney: yeah, this is the key problem now
<pitti> Keybuk: I thought the whiteboard said something about apport needing to defer close()ing stdin until it's fully done or so?
<happyaron> Laney: I've mentioned in that bug, upstream can raise version number however they like to
<pitti> Keybuk: actually, apport doesn't do any special magic to close stdin
<pitti> it just reads until EOF
<Laney> it's a bit of a difficult issue really
<Keybuk> pitti: doesn't work, the kernel still panics too early
<Laney> happyaron: I would appreciate it if you could talk to some members of the SRU team
<Laney> if you can work out some arrangement with them then we should go ahead
<happyaron> Laney: where can I find them?
<Keybuk> pitti: http://lkml.org/lkml/2009/6/22/368
<Keybuk> pitti: we need part of that patch set
<Laney> happyaron: https://launchpad.net/~motu-sru/+members
<happyaron> Laney: how much time do we still have from now to DIF?
<Laney> FF is what you care about, and it's tomorrow
<Laney> I would rather get an exception than rush though
<didrocks> liw: Hey, I'm reading this discussion (bug #329060) about the automatic symlinking of identical changelog files. What does this (as I have it also in my pbuilder), dpkg-buildpackage, pkgbinarymangler?
<ubottu> Launchpad bug 329060 in lintian "Please disable "debian-changelog-file-is-a-symlink" warning" [Undecided,Confirmed] https://launchpad.net/bugs/329060
<happyaron> cody-somerville: hi
<cody-somerville> happyaron, hello
<liw> didrocks, I don't know what does the symlinking of identical changelogs
<happyaron> cody-somerville: I would like to ask you about some SRU issue about tor
<cody-somerville> happyaron, Okay.
<didrocks> liw: ok, and there is nothing written in wiki.ubuntu.com? In any case, I think i'll try to patch at least lintian
<cjwatson> didrocks: cdbs
<liw> didrocks, patching lintian (in Ubuntu) to not warn about that would be good, yes
<happyaron> cody-somerville: as I want tor could reintroduce to ubuntu, we need to update it whenever upstream update the package, or upstream will be unhappy to the packages they don't support
<cjwatson> the warning is still correct for Debian though, so that isn't upstreamable
<didrocks> cjwatson: I'm using debhelper 7 in the present case, so where is the common denominator? :)
<cjwatson> if you're using debhelper 7 I'm not sure I believe you that automatic symlinking is happening :)
<cjwatson> to the best of my knowledge dh7 doesn't do that
<happyaron> cody-somerville: I mean we need to keep the package up-to-date rather than keep it a specific version in our repository as other packages
<cjwatson> try DH_VERBOSE=1 to see what's going on?
<didrocks> cjwatson: It's just appear on a package which uses dh7 (and I didn't notice it before)
<cjwatson> maybe the package is doing it for itself?
<didrocks> cjwatson: yeah, I'm testing that now :)
<cjwatson> as in, hand-coded stuff in debian/rules
<pitti> cjwatson, didrocks: it's done by /usr/share/cdbs/1/rules/debhelper.mk
<didrocks> cjwatson: not from what I see
<cjwatson> pitti: right, that's why I said "cdbs", but it's not a native debhelper thing
<cody-somerville> happyaron, Is there a particular reason why?
<pitti> so all cdbs packages which include that (IOW, pretty much _all_ cdbs packages) get it
<pitti> cjwatson: right, just to confirm you, it's not done in dh proper
<didrocks> pitti: cjwatson : ok, i didn't see but the package is using dh 7 commands, but it includes debhelper.mk. So, here is the explanation :/
 * didrocks will fix this
<didrocks> thanks ;)
<happyaron> cody-somerville: we have tor in our repository before, but once upstream filed a bug to request a deletion of it because they don't want us ship the old version of their software that they don't support any more, and if we want to reintroduce it, we need to keep it up-to-date or upstream may file another bug to do it again
<cody-somerville> happyaron, What sort of changes are made between versions? How often do they release?
<pitti> didrocks: what package in particular, BTW?
<pitti> didrocks: (please note that if you drop cdbs for packages which have translations, you also need to do a lot of other stuff manually, like createing POT files, adding gettext domains to desktop files, and the like)
<didrocks> pitti: it's upstream cairo doc package (not yet in ubuntu). They want to replace the current ubuntu package but I have to fix a lot of issues first.
<pitti> didrocks: ok, doesn't sound like something that would be on the CDs then
<happyaron> cody-somerville: mostly security updates, and they update it not very frequently but not very regular, either
<didrocks> pitti: ok, so maybe, it's better to remove the debhelper 7 overrides call and change them in cdbs equivalent?
<pitti> didrocks: your choice
<didrocks> pitti: yes, little chance it hits the CD ;)
<cody-somerville> happyaron, ever any non-security updates? ie. new features
<happyaron> cody-somerville: we can jump over several releases, just keep the package's version is still supported by upstream is bearable
<happyaron> cody-somerville: that will take nearly one year for a new one, and the old one will be dropped to unsupported
<jack> meep...i'm someone who "steals" a lot of ubuntu packages and stuff for fink/macos x
<jack> just packaging indicator-applet...i wonder what else i need to make that worthwhile ;)
<jack> libdbusmenu is done already, too
<pitti> jack: I think it's best to talk to tedg or kenvandine in #ubuntu-desktop, but both of them are in USish timezone and still asleep
<jack> :)
<jack> no suggestions? any fancy apps that use libindicate or libdbusmenu?
<pitti> jack: indicator-applet itself is just the base functionality, you need "plugins" to do useful stuff with it; like indicator-evolution, the pidgin plugin, or indicator-session
<ojwb> look at the reverse dependencies?
<jack> the ubuntu pdb unfortunately doesn't let me walk dep chains
<pitti> indicator-messages, too
<jack> ojwb: sure, just what i was thinking :)
<ojwb> jack: ah, no ubuntu install i guess?
<jack> pitti: ok cool, will try the pidgin stuff next
<jack> ojwb: i'm still running kubuntu-feisty on my old craptop
<jack> the rest are all macs
<Laney> happyaron: How does Debian get away with it? The version in Lenny hasn't been updated
<happyaron> Laney: they have a so-called trust chain, and the maintainer of tor in Debian is who work for upstream deb repository
<Laney> does that get around the security holes?
<Riddell> jack: a chroot would work.  on the kubuntu side konversation has support and I should upload kmail and kopete today with it
<jack> Riddell: work for what? feisty!
<jack> that's almost previous-millenium-ubuntu
<Riddell> a karmic chroot would work for feisty yes
<Riddell> jack: oh and libindicate-qt of course
<jack> but i don't have a box that would be good enough for karmic ;)
<Riddell> jack: so make a chroot so you can find the rdepends and do apt-cache search and whatnot
<jack> but i can't install current ubuntu pkgs without a working karmic ;)
<jack> i just harvest from packages.ubuntu.com, mainly
<ttx> james_w: around ?
<jack> without ever having seen the stuff running on a current ubuntu box
<james_w> hi ttx
<ttx> james_w: hey :)
<ttx> james_w: about the repacking notes for jetty6
<ttx> james_w: it's the orig.tar.gz from debian experimental. There is a README.source that documents it. Do you want me to +dfsg it ?
<ttx> james_w: also do you know how repacking should be stated in the new debian/copyright format ?
<happyaron> Laney: they update it in unstable as far as I know, I didn't do research on how they solve it for stables
<ttx> james_w: note sure adding non-URI stuff to the Source: line is ok. Maybe I can use Disclaimer:
<james_w> ttx: I'm not sure I'm afraid
<james_w> ttx: I wouldn't consider it a blocker seeing as it is already in
<Laney> happyaron: That's the main issue though isn't it?
<ttx> james_w: well, kees sees it as a MIR blocker. Maybe you can chime in on bug 418836
<ubottu> Launchpad bug 418836 in jetty6 "MIR jetty6" [Undecided,Incomplete] https://launchpad.net/bugs/418836
<happyaron> Laney: okay, I will do it right now
<Laney> ie why is it OK for Debian to ship old releases but not Ubuntu
<james_w> ttx: yeah, I'd use disclaimer
<happyaron> Laney: they update it to the version upstream support, 0.2.0.34 in lenny and etch-backports
<happyaron> Laney: upstream requested a deletion for our 0.1.x version's packages
<Laney> so that changes things a bit
<Laney> ie we don't need to update to the current release all the time
<happyaron> Laney: yes, I agree, keep it the version upstream support is ok, only when it's not supported any more we need to update it
<Laney> right
<Laney> cody-somerville: ^^^
<cody-somerville> Are they fine with the updates going into -backports instead of -updates?
<happyaron> cody-somerville: for older releases is ok, but how to do it for current release if update is needed?
<cody-somerville> happyaron, You simply need to request a backport.
<cody-somerville> happyaron, If the new version is only security fixes, a security upload can also be done.
<happyaron> cody-somerville: but if there is a new release with new features, I think this is the most difficult thing to concern?
<cody-somerville> happyaron, If there is new features, the updated version could go into backports.
<happyaron> cody-somerville: I have said it's okay for older releases, but what about current release, just like Jaunty, there is no backports before Karmic is out
<cody-somerville> happyaron, AFAIK, there is.
<cody-somerville> happyaron, I just looked and there is definitely packaged in jaunty-backports
<happyaron> cody-somerville: oh, that's good, what I need to do is request for security updates/backports, right?
<cody-somerville> happyaron, https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages <-- backports process
<happyaron> cody-somerville: that's good
<happyaron> Laney: ~
<cody-somerville> happyaron, https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures <-- Security updates process
<Laney> depends if you consider backports to be first-class
<happyaron> Laney: I don't think so in fact
<Laney> they aren't enabled by default for example
<happyaron> Laney: security updates can solve part of the problem, but -updates will be better than -backports I think
<happyaron> cody-somerville: if a new releases with features updated, how can it added to -updates?
<Laney> When upstream decide to stop supporting a series, it's likely that the new one introduces new features right?
<Laney> but also has security fixes and so on
<cody-somerville> happyaron, It won't, it'll go into -backports
<happyaron> Laney: yes, new feature and unsolved bugs
<happyaron> Laney: oh, I mean the old one has unsolved bugs, a typo
<Laney> well the original problem is that upstream don't want us to ship their unsupported releases right?
<happyaron> yes
<Laney> So is an update in -backports good enough for them?
<happyaron> Laney: debian just backport it, if we can include it to -updates, things will be better
<happyaron> Laney: and debian deleted the package from etch but include it again in backports, that means users can only get in in backports
<tkamppeter> pitti: Hi
<pitti> hi tkamppeter
<tkamppeter> pitti, we have talked about a CUPS SRU for Hardy in DFublin, do you remember which problem we talked about?
<pitti> tkamppeter: no, I'm afraid not
<tkamppeter> I have found two SRU candidates: bug 372118 and bug 307471, but what we talked about in Dublin was something else.
<ubottu> Launchpad bug 372118 in cups "CUPS does not work with Firefox, HTTPS bug (Hardy LTS)" [Undecided,Fix released] https://launchpad.net/bugs/372118
<ubottu> Launchpad bug 307471 in cupsys "Multi bin printing broken in OpenOffice.org due to cupsys pstops filter bug" [Undecided,Fix released] https://launchpad.net/bugs/307471
<tkamppeter> pitti: ^^
<pitti> two weeks of holiday don't help for remembering..
<pitti> anyway, lunch time, bbl
<happyaron> Laney: what to do next?
<Laney> happyaron: I don't know :(
<taavikko> Any thoughts? https://bugs.launchpad.net/bugs/419126
<ubottu> Launchpad bug 419126 in gdm "gdm loops after logging in" [Undecided,New]
<TheMuso> cody-somerville: What has xubuntu done regarding theming the new gdm for karmic?
<cody-somerville> TheMuso, I'm going to upload gdm-2.20 today
<TheMuso> cody-somerville: Oh so the older GDM? Ok.
<cody-somerville> TheMuso, right
<TheMuso> Fair enough, I can understand why you want to stick with that.
<ogra> hrm, who made my laptop so unstable
<Daviey> o/
 * ogra just upgraded and experiences hangs 
<debfx> is pidgin 2.6 going to make it into karmic?
<hyperair> if not today, never =(
<slytherin> hyperair: why never?
<hyperair> er unless you count backports
<ogra> up to the MOTU i'd guess
<TheMuso> Afaik pidgin is still main.
<hyperair> yeah pidgin's still in main
<ogra> given the default gets switched to telepathy anyway i would guess it goes to universe
<hyperair> no, there are a fair few things in main that aren't default
<hyperair> e.g. irssi
<ogra> right
<Laney> there's a diff up for sponsoring
<ogra> because main devs take care for irssi
<hyperair> quickly sponsor it then! =O
<ogra> if nobody does that for pidgin it will go to universe
<debfx> telepathy depends on libpurple (pidgin)
<ogra> so that lib would sty in main
<ogra> *stay
<Laney> can you have source in universe and binary in main?
<TheMuso> No
<Laney> thought not
<TheMuso> You can have the other way around however.
<Laney> yes
<hyperair> you can?
<hyperair> how does that work?
<ogra> ah, i didnt know libpurple has no own source
<hyperair> isn't pool/ sorted by component/source/?
<TheMuso> Binaries can be built from source packages in main and they go to universe due to not being needed/depended on by anything in main eg seeds etc.
<ogra> right
<ogra> TheMuso, while i have you here, any idea about the FTBFS of pulse on armel ?
<hyperair> hmm i thought you could only copy source packages, not binaries without sources
 * ogra doesnt really get why pulse needs CPU assembler for volume control
<hyperair> heh assembler? seriously?
<TheMuso> ogra: Nor do I, but there are CPU optimizations for arm, SSE, and mmx. I have pinged the guy who wrote the arm code about the error.
<TheMuso> ogra: It was not Lennart who wrote it.
<ogra> ah, k, but it was forwarded, thats good
<TheMuso> The SSE/MMX code is in x86 assembler as well.
<ogra> TheMuso, thanks for that
<TheMuso> ogra: np.
<TheMuso> No response so far.
<ogra> well, i didnt know there is specific arm code, probably we just need to make sure it gets actually used, i'll take a look later
<TheMuso> ok thanks
<slytherin> hyperair: Tomorrow is FF, If someone prepares detailed report for FFE for pidgin and FFE is approved it can still go on.
<ogra> might be it doesnt know its actually on arm
<ogra> and tries SSE
<TheMuso> ogra: No it knows its on arm.
<ogra> hmm, k
<TheMuso> ogra: I suggest you look at the build log, that will probably help you work out a lot at a glance.
<ogra> i did already
<ogra> i'll try a local armel build though
<hyperair> slytherin: hmm true, that
<debfx> could someone consider sponsoring pidgin-plugin-pack (bug #256419), the current version in ubuntu is really old
<ubottu> Launchpad bug 256419 in purple-plugin-pack "pidgin-plugin-pack needs updating" [Wishlist,Confirmed] https://launchpad.net/bugs/256419
<pitti> ttx: hm, is https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages supposed to be complete? it's e. g. missing axis and axis2c
<ttx> pitti: the C bits have their own MIR pages. This was supposed to track java stuff
<pitti> ttx: ah, ok
<ttx> pitti: what do you mean by "axis" ? there is just axisÃ©c and rampart on the C side
<ttx> axis2c, even
<pitti> ttx: I wanted to promote the lot now, and review it afterwards, but we need open MIR bugs or being in that table for everyting
<ttx> pitti: those were opened.
<ttx> Note that component-mismatches lists a lot of unnecessary stuff
<pitti> ttx: it's a build dep of libmx4j-java
<ttx> pitti: for some reason it thinks the old "eucalyptus-javadeps" is needed
<pitti> ttx: not really, it's usually fairly accurate; what's an example of "unnecessary"?
<ttx> pitti: axis was in main before, methink
<ttx> pitti: unnecessary = eucalyptus-javadeps and all its dependencies.
<pitti> ttx: ok, I think I'll do it the other way around; I promote eucalyptus and all the packages on that wiki page, and then we'll see in c-m what's left
<ttx> pitti: that includes the scary glassfish and the jboss stuff
<pitti> o eucalyptus-javadeps: eucalyptus-javadeps
<pitti>    [Reverse-Depends: eucalyptus-cloud]
<ttx> pitti: "apt-cache show eucalyptus-cloud" doesn't show eucalyptus-javadeps
<ttx> (and it is right)
<ttx> pitti: it was required for euca 1.5. But I spent the most part of this cycle getting rid of it
<ttx> no clue why it shows now as a eucalyptus-cloud dep.
<pitti> cjwatson: hm, any idea why c-m shows above dependency, although it doesn't exist?
<cjwatson> I answered this yesterday in ttx's hearing :)
<cjwatson> it's because c-m checks all architectures and it's still needed on ia64
<ttx> beh
 * ttx blames soren, then :P
<pitti> ah, thanks
<ttx> I guess 1.6 failed to build on ia64 and still carries 1.5
<cjwatson> 14:24 London time on this channel
 * ttx is too busy trying to enable testsuites in poorly-coded java stacks
<cjwatson> somebody could remove the ia64 packages for the time being as a slightly unusual option, perhaps
<pitti> okay, will do that
<apachelogger> mvo: do you want apturl to either start apturl-gtk or apturl-kde, or just use 2 bins (latter would obviously make -gtk and -kde conflict due to registration in firefox)
<Riddell> conflicting isn't good, then you probably couldn't install ubuntu-desktop and kubuntu-desktop together
<apachelogger> true
<pitti> ttx: ok, ia64 packages removed; thanks for the heads up
<pitti> this should clear c-m in two hours
<ttx> pitti: cool. I tried to triplecheck the list for any missing stuff but had trouble with that in the way.
<mvo> apachelogger: hm, better to have a single binary I guess, but if two packages is easier, that is fine with me as well
<pitti> ttx: after promoting the list in the wiki, we'll see what's left
<soren> cjwatson: I'm /reasonably/ sure it would build on ia64 if only the buildd's would ever get to it.
<soren> cjwatson: So if someone with the appropriate powers could put it to the front of the queue...
 * soren forgets who can do that these days
 * soren will brb
 * soren returns
<apachelogger> mvo: how about that: have apturl check for KDE_FULL_SESSION invoke apturl-kde if set, otherwise apturl-gtk ... keep -kde and -gtk as binaries as well, so the user can also call apturl-kde if KDE_FULL_SESSION is not set accordingly
<mvo> apachelogger: sounds good to me
<cjwatson> soren: I can, one moment
<soren> cjwatson: Excellent, thank you!
<cjwatson> soren: yes, well. the problem is that the kees/toolchain PPA is DOSing the buildds. It's next in the queue, but that's 23 hours from now
<soren> *blink*
<soren> He has a single job that takes that long?
<ScottK> Might have been nice to do that the day AFTER feature freeze.
<cjwatson> soren: openjdk apparently
<cjwatson> ScottK: we can probably live with the ia64 and powerpc buildds being unavailable even today; the other buildds are fine
<ScottK> Certainly.
<pitti> soren: even more curious, two different openjdk versions are building at the same time..
<pitti> but there's still no LP API to cancel a build, so I can't help here; you need lamont for that if its urgent (which it isn't, I think)
<lamont> we've been giving kees crap about that :-)
<pitti> how does one get the grub menu nowadays?
<slytherin> pitti: what do you mean by 'get'?
<rickspencer31> Keybuk: ^
<pitti> well, I want to see and use it
<rickspencer31> slytherin: well ... when I boot, it just skips grub
<superm1> Keybuk, are you going to plan on pulling in newer udev releases after FF still, or will you start cherry picking fixes as necessary?
<pitti> it's apparently the new grub2 default
<rickspencer31> and doesn't ask me how to get there
<Keybuk> superm1: depends what else goes into the udev releases
<slytherin> pitti: rickspencer31: the timeouts are very small (5 sec and 3sec).
<bdrung_> Keybuk: you talked yesterday about three unit standards and O'Reilly Style Guide, do you have a link for that?
<pitti> slytherin: they are 0 for me
<pitti> (apparently)
<pitti> I don't see the menu at all
<Keybuk> bdrung_: http://oreilly.com/oreilly/author/stylesheet.html
<Keybuk>  * K = 1024; k = 1000. So a 56 kbps modem is equal to 56,000 bps, while 64K of memory is equal to 65,536.
<lamont> would someone please find whoever thought having the transcodebuild do "make -j" was a good idea and beat them over the head with some hardware?
<lamont> oh wait.  did I say that out loud?
<slytherin> pitti: yu canc hange the timeouts in /etc/default/grub and then run upgrade-grub
<bdrung_> Keybuk: but that would only apply for K/k, not for M or G
<evand> pitti: I believe you can still hit escape to enter the menu.
<cjwatson> what he said
<slytherin> And yes, escape should work, provided you figure out when to use it
<Keybuk> bdrung_: indeed
<cjwatson> this will change
<rickspencer31> yes
<rickspencer31> thanks evand
<cjwatson> specifically it will change to showing you the menu if (a) you are multi-booting or (b) you hold down shift at boot
<bdrung_> Keybuk: so it is no alternative
<Keybuk> bdrung_: still worth mentioning
<cjwatson> or if you change the default configuration of course
<bdrung_> so we are back to 2 solutions
<Keybuk> cjwatson: is it still waiting during a timeout, or did that get fixed?
<cjwatson> Keybuk: I'm working on it with upstream
<cjwatson> it's actually quite difficult to get it right in a way that doesn't totally funt upgrades, but I'm working on it
<cjwatson> I have something that *works*, but only if you are careful to run grub-install as well as update-grub
<cjwatson> so I'm holding off until I get a bit of backward compatibility sorted out
<Keybuk> upgrades from grub1->grub2
<Keybuk> or just updates from grub2->grub2?
<cjwatson> grub2->grub2
<cjwatson> don't worry, I will get it done
<Keybuk> ah right, at worst that's only developers and competent people :p
<cjwatson> my bug mailbox disagrees with the latter :-/
<jdstrand> soren: oh! I forgot to mention I added an apport hook for libvirt-bin
<Keybuk> cjwatson: I said "developers and" :P
<cjwatson> hah
 * liw wonders what Kelvin-Bels would measure
<Keybuk> dh_installinit is making my head explode
<jdstrand> soren: it'll grab stuff related to apparmor debugging when using apport*. Having people use 'apport-collect -p libvirt-bin <bug number>' after the initial report will likely prove helpful :)
<Keybuk> the parts of my brain that understood Perl have long since atrophied
<cjwatson> I actually have the backward compat entirely working now apart from USB keyboards, and USB is making my head hurt
<Keybuk> :-/
<soren> jdstrand: You rock! :)
<jdstrand>  5
<jdstrand> o/
<mathiaz> apw: hey - I'm trying to debug an issue with an upstream
<mathiaz> apw: and one of the question is whether the karmic kernel carry specific scheduler patches
<cjwatson> hmm, I'm beginning to wonder if I've found a bug in qemu's USB keyboard implementation
<evand> cjwatson: is it the ctrl-alt-arrow issue?
<cjwatson> no
<evand> ah, nevermind then
<cjwatson> it doesn't seem to be reporting modifier keys held down at boot
<cjwatson> despite me prodding the idle rate
<ttx> pitti: component-mismatches was refreshed. There are a few on that list that were in main before, thus shouldn't require MIR: axis backport-util-concurrent bouncycastle commons-beanutils dom4j jaxme junitperf libcommons-collections3-java libcommons-discovery-java libjaxen-java libjdom1-java libmx4j-java libxpp2-java libxpp3-java xom
<cjwatson>             /* TODO: Implement finite idle delays.  */
<cjwatson> hmm :-)
<ttx> pitti: commons-beanutils has new depends (maven-repo-helper/libstax-java) but I'll fix that now. Someone must have synced a part of the new debian maven stack inadvertantly
<pitti> ttx: we need to check them again for complying with the default-jdk policy, though
<pitti> ttx: there also seem to be some stragglers, like rampart
<slytherin> ttx: Only yesterday I was wondering why libcommons-collections3-java got moved to universe. :-)
<ttx> pitti: So you want to track them in the MIR page as well ? Or my promise to fix default-jdk on them is sufficient ?
<mathiaz> Keybuk: hi - we're still tracking down the libdbus issue we ran into yesterday for sssd
<ttx> pitti: for axis2c and rampart, please see soren. I already have trouble staying afloat with the java stuff.
<pitti> ttx: oh, did you already check them?
<pitti> ttx: would be nice to add the ones to the wiki page which still need conversion
<mathiaz> Keybuk: dropping Rawhide libdbus into karmic doesn't fix the problem
<ttx> pitti: no. and based on my experience, they probably are not ok.
<mathiaz> Keybuk: however it works correctly on a rawhide system
<pitti> ttx: ok, can you put the lot on the wiki page for now, then?
<pitti> I get them promoted
<mathiaz> Keybuk: so we're not sure if libdbus is the culprit here. But that's the only symptom we have so far
<ttx> pitti: worksforme.
<mathiaz> Keybuk: We successfully open a socket and start the D-BUS communication, but it never completes the handshake
<mathiaz> Keybuk: We see about half of the handshake (it requires a BEGIN/OK and an ID/ACK). We're only seeing BEGIN/OK, but the ID/ACK never gets sent, and so subsequent requests don't go through
<mathiaz> Keybuk: what else could wrong at this level?
<Keybuk> mathiaz: that usually indicates a bug in main loop handling in the application
<Keybuk> it's not supplying libdbus with the new data received on the socket
<mathiaz> sgallagh: ^^
<pitti> ttx: promoted; let's see in 1.5 hours, when publisher ran and c-m refreshes again
<sgallagh> Keybuk: Yeah, that's what I'm investigating now
<ttx> i'm fixing commons-beanutils in the meantime, shouldn't require any maven-repo-helper stuff in main
<Keybuk> sgallagh: are you using libdbus directly in native mode?
<ttx> (yet)
<sgallagh> Keybuk: Thing is, though, I LD_PRELOADed the tevent library that is working in Fedora, and I still don't get a result
<Keybuk> or are you using some other bindings (like gdbus, gbus, egg-dbus, dbus-glib, etc.)
<sgallagh> That provides our entire mainloop
<sgallagh> Keybuk: I wrote the mainloop integration for libtevent
<Keybuk> ok
<sgallagh> Keybuk: As previously stated, it works fine on Fedora and OpenSUSE
<Keybuk> it could be any kind of difference though
<sgallagh> Keybuk: I don't follow that
<Keybuk> follow which?
<sgallagh> "it could be any kind of difference though"
<sgallagh> Keybuk: Can you elaborate?
<Keybuk> if you're starving a socket, any number of differences between Ubuntu and Fedora could be the casue
<Keybuk> even down to kernel scheduling
<Keybuk> buffer sizes
<Keybuk> differing glibc versions
<Keybuk> differing optimisation flags
<Keybuk> etc.
<Keybuk> it would still mean the bug was in your main loop
<sgallagh> Keybuk: Ok, I can eliminate most of those (I've already tested them)
<sgallagh> I mounted my Ubuntu disk in Fedora and chrooted it, so that eliminates the kernel scheduling
<Keybuk> do you have a full strace of the each side of the attempt to make a connection?
<sgallagh> Keybuk: Yeah, I sent it to you yesterday, didn't I?
<Keybuk> no
<sgallagh> Keybuk: (02:59:42 PM) sgallagh: Keybuk: http://paste.ubuntu.com/259446/ (the Karmic version)
<sgallagh> (02:59:54 PM) NCommander: or any archive admin?
<sgallagh> (03:00:43 PM) sgallagh: Keybuk: http://paste.ubuntu.com/259449/ (the working Fedora version)
<sgallagh> That's just the side making the connection, not the side receiving it, but since that's the side that's failing to send the second half of the message, it should be sufficient for examination
<Keybuk> sgallagh: no, I need to see both sides
<Keybuk> and only on Ubuntu
<sgallagh> Keybuk: Ok, just a minute. I have that one too
<sgallagh> Hmm, gotta regenerate it. /tmp got wiped out
<Keybuk> can you regenerate both at the same time then please
<sgallagh> Keybuk: Of course.
<Awsoonn_> Has anyone installed using today's alt cd image with success?
<sgallagh> Keybuk: http://fedorapeople.org/~sgallagh/sssd_err.tar.bz2
<Awsoonn_> Should I file a bug on the fact installation will not complete, and grub2 appears to not be configureing itself correctly or wait for the next alpha?
<sgallagh> Keybuk: .2114 is the monitor, which receives the connection, .2115 is the data provider, which initiates the connection to the monitor
<sgallagh> Keybuk: On .2114, FD 10 is the connection from the data provider. On .2115, FD 11 is the connection to monitor
<Keybuk> sgallagh: err, so
<Keybuk> the monitor says OK
<Keybuk> write(10, ""..., 37)                      = 37
<Keybuk>  | 00000  4f 4b 20 37 33 64 36 34  39 33 61 38 65 38 34 30  OK 73d64 93a8e840 |
<Keybuk>  | 00010  66 35 31 33 39 35 39 62  65 64 39 34 61 39 35 34  f513959b ed94a954 |
<Keybuk>  | 00020  66 66 61 0d 0a                                    ffa..             |
<Keybuk> sgallagh: honestly though
<Keybuk> this strace looks rather broken
<Keybuk> you have multiple dbus socket connections on both ends
<sgallagh> Keybuk: It's not broken, they both act as a D-BUS server for different processes
<sgallagh> That's why I specified the specific file descriptors for one example
<Keybuk> right
<sgallagh> Keybuk: A quick architecture description:
<Keybuk> but you never read from it in the client again
<Keybuk> in fact
<Keybuk> you appear to be not even checking your epoll_ctl return values
<Keybuk> epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=26154624, u64=26154624}}) = -1 EEXIST (File exists)
<Keybuk> so you're not even *polling* for read
<Keybuk> (the last epoll_ctl on fd 11 is:
<Keybuk> epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=26154448, u64=26154448}}) = 0
<Keybuk> so there's no EPOLLIN there
<Keybuk> so you'll never get notified of the pending data
<Keybuk> and thus never complete
<rtg> kirkland, any more info on padlock-sha ?
<sgallagh> Keybuk: Uh, read a little further. We're doing an EPOLLIN immediately after the write
<sgallagh> And that's the last thing we see
<Keybuk> no you're not
<sgallagh> Keybuk: Which file are you looking at?
<tkamppeter> pitti, hi
<Keybuk> sssd_err.2115
<Keybuk> write(11, ""..., 18) = 18
<Keybuk>  | 00000  41 55 54 48 20 45 58 54  45 52 4e 41 4c 20 33 30  AUTH EXT ERNAL 30 |
<Keybuk>  | 00010  0d 0a                                             ..                |
<Keybuk> epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=26154624, u64=26154624}}) = -1 EEXIST (File exists)
<sgallagh> Keybuk: EPOLLIN is right on that line you copied...
<Keybuk> can you paste me that line of source code ;)
<kirkland> rtg: hadn't gotten to that yet today :-/
<rtg> kirkland, np, I've been buried myself
<sgallagh> Keybuk: I have no idea where that line of code is. It's buried in D-BUS
<Keybuk> no
<Keybuk> it's in your main loop integration
<sgallagh> sorry, buried in TEVENT
<Keybuk> right
<Keybuk> anyway
<Keybuk> tevent is broken
<sgallagh> Keybuk: Except that it works on non-Ubuntu platforms
<Keybuk> so?
<Keybuk> it's still broken
<sgallagh> Keybuk: You still haven't explained to me what's wrong with that line
<Keybuk> yes I have
<Keybuk> <Keybuk> you appear to be not even checking your epoll_ctl return values
<sgallagh> Keybuk: You said "You never do an EPOLLIN", but what you pasted specified EPOLLIN...
<Keybuk> your attempt to add EPOLLIN to the set is returning an *error*
<Keybuk> therefore it *failed*
<Keybuk> your code obviously doesn't even check
<sgallagh> Keybuk: Ok, I'll accept there's a bug there and I'll open that upstream.
<sgallagh> Keybuk: However, why did it fail?
<sgallagh> Keybuk: Why are we getting EEXIST when trying to do epoll_ctl? That doesn't even make sense
<james_w> "EEXIST op was EPOLL_CTL_ADD, and the supplied file descriptor fd is already registered with this epoll instance."
<Keybuk> sgallagh: yes it does
<Keybuk> sgallagh: james_w quoted the relevant bit of the epoll_ctl(2) manpage
<cjwatson> shame about the historical strerror(EEXISTS)
<james_w> eglibc difference perhaps?
<Keybuk> doubt it
<cjwatson> I'd be amazed
<Keybuk> more likely Fedora patched their libc to workaround some bug ;)
<james_w> good :-)
<Keybuk> they like to do that
<Keybuk> anaconda does something wrong, rather than fix anaconda, they workaround it in libc
<sgallagh> Keybuk: Well, opensuse must have patched it somehow too, then
<Keybuk> sgallagh: probably just took the patches from fedora verbatim
<Keybuk> could be a difference between glibc 2.9 and 2.10 of course too
<Keybuk> or a kernel difference
<sgallagh> Keybuk: rawhide is using glibc 2.10, and I already mentioned that I tried running it under the rawhide kernel using a chroot
<Keybuk> right, we're using eglibc 2.9
<james_w> are we?
<Keybuk> I think so
<james_w> confusing version number if so
<Keybuk> oh, no 2.10
 * Keybuk ran that on jaunty :p
<sgallagh> Keybuk: If you're running that crazy libc wanna-be, how can you be sure the problem is on my end? :-P
<Keybuk> sgallagh: because the manpage says what you're trying to do is not supposed to work
<sgallagh> Keybuk: Is it because we're trying to set EPOLLERR and EPOLLHUP again there?
<Keybuk> no
<Keybuk> it's because you may only call EPOLL_CTL_ADD *once* for any file descriptor
<Keybuk> all subsequent calls must be EPOLL_CTL_MOD
<sgallagh> ah, gotcha
<sgallagh> Keybuk: Thanks for the help. I'll get this over to the tevent upstream
<pitti> tkamppeter: heh, flooding Mike with STRs.. :)
<BluesKaj> Riddell, a report : seems the Kubuntu Karmic Printer Configuration GUI has been fixed for my setup , at least .
<tkamppeter> Yes, there are a lot of bugs in the new web interface.
<Riddell> BluesKaj: great, thanks
<tkamppeter> pitti, what should we do concerning the usblp kernel module? Did you do anything in this direction already?
<ttx> pitti: new component-mismatches run: wsdl4j: was in main before, please promote, will add to the default-java watchlist. libstax-java and maven-repo-helper should disappear from list as soon as the new commons-beanutils is published. That leaves axis2c (bug 418225) and rampart (bug 418223).
<ubottu> Launchpad bug 418225 in axis2c "MIR for axis2c" [Undecided,Incomplete] https://launchpad.net/bugs/418225
<ubottu> Launchpad bug 418223 in rampart "MIR for rampart" [Undecided,New] https://launchpad.net/bugs/418223
<pitti> tkamppeter: no, I didn't; for now we should add it to /etc/modprobe.d/blacklist.conf, I think
<ogra> cjwatson, in the installed seed i see "* Kernel-Version: 2.6.31-7-imx51 2.6.31-7-iop32x 2.6.31-7-ixp4xx 2.6.31-7-orion5x 2.6.31-7-versatile" ... could that be the cause i dont get any udebs for 2.6.31-100-imx51 on the alternates ?
<ogra> s/installed/installer/
<pitti> ttx: where is that list, btw? not on https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages ?
<tkamppeter> pitti, would it work to add a file /etc/modprobe.d/cups.conf to the CUPS package which contains only the line "blacklist usblp"?
<pitti> tkamppeter: it would (well, shoudl be blacklist-usblp.conf then), but I'm not sure we want that
<ttx> pitti: what list ? the default-java watchlist ? or the component-mismatches list ?
<pitti> ttx: the default-java checklist
<ttx> it's on  https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages
<ttx> below the "MIR needed" stuff
<slangasek> ttx: in bug #303458, your last comment is that you would nominate bug #357581 for an SRU... were you intending to prepare the SRU, and if so, could you go ahead and do that and upload it to the queue?  The 'nominated for $release' list is all noice, and the SRU team doesn't look at it
<ubottu> Launchpad bug 303458 in samba "segfault in pam_smbpass.so" [High,Fix released] https://launchpad.net/bugs/303458
<ubottu> Launchpad bug 357581 in apparmor "abstractions/smbpass missing entry for /var/lib/samba/*.ldb" [Undecided,Fix released] https://launchpad.net/bugs/357581
<pitti> ttx: aah, got it
<tkamppeter> pitti, can you contact the appropriate person or modify and upload the appropriate package by yourself?
<ttx> slangasek: we intend to use that list, in fact, for server packages. So that accepted nominations can be used as a starting point for those wanting to work on MIR.
<ttx> slangasek: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20resources
<mathiaz> ttx: s/MIR/SRU/
<pitti> tkamppeter: I can upload it, I just wonder if usblp is still useful, or whether having it should depend on having cups installed
<ttx> mathiaz: right. Man, I need some rest
<slangasek> ttx: ok, so your nomination didn't mean you had any plans to work on it yourself?
<mathiaz> slangasek: that is correct.
<pitti> ttx: re-promoted
<ttx> slangasek: no. If I intend to work on it, I'd assign myself
<slangasek> ttx: ok; the nomination happened before this new server team nomination scheme was discussed, so I wasn't sure
<cjwatson> ogra: yes, you need to make the seeds match
<ttx> slangasek: that said, I should really work on that. Just didn't have time so far[tm]
<ogra> cjwatson, right, i guess thats also the reason why i see things like "! Pruned block-modules-2.6.31-100-imx51-di from installer"
<ogra> cjwatson, what i dont get though is why it is also doing: "! Pruned block-modules-2.6.31-0-babbage-di from installer" ... it shouldnt know anything about babbage
<cjwatson> it's pruning all the stuff in the archive that provides block-modules (which it's been asked to install) but that doesn't have any of the possible Kernel-Version field values
<cjwatson> it knows about babbage because babbage is in the archive
<ogra> well, in universe
<cjwatson> yes, and it's been asked to look at universe, evidently!
<ogra> i thought d-i doesnt take universe into account
<ogra> ah
<cjwatson> that's not d-i. that's germinate.
<ogra> ok
<cjwatson> "pruned" means that it is *not* going to include the package
<ogra> yep
<ogra> thats what i guessed with my sparse english knowledge :)
 * ogra curses LP
<cjwatson> germinate does what you tell it to do - it's only in sync with d-i's behaviour if you give it options that match d-i's behaviour
<tkamppeter> pitti, with CUPS usblp is useless and disturbing, at least for all backends shipping with Ubuntu, but I am notr sure whether there are proprietary manufacturer-supplied backends based on usblp.
<ogra> does anyone get https://code.launchpad.net/~ubuntu-core-dev to load ?
<beuno-lunch> ogra, s/curse/files a bug
<ogra> the recent days code.lp.net gives me timeout over timeout
<beuno-lunch> ogra, it does on edge: https://code.edge.launchpad.net/~ubuntu-core-dev
<ogra> right, edge works fine
<beuno-lunch> I think there have been optimizations done to that page, that have not propagated to production
<tkamppeter> pitti, without CUPS (for example with LPRng from Universe) the usblp module is useful as only access to USB printers via /dev/usb/lp*.
<Keybuk> I wish LP would pick a theme
<ogra> non edge tells me i can choose to disable access to edge for the next 2h
<Keybuk> pages jumping style is damned confusing
<ogra> which i didnt even try to reach :P
<beuno-lunch> Keybuk, the 3.0 goal is for *all* pages to have the same styling
<beuno-lunch> which is why we're not rolling out to production
<beuno-lunch> untill the 420 templates have been updated
<beuno-lunch> they will look like the project page in edge, roughly
<dholbach> kirkland: rtg said you might know a bit about bug 277556 - I was pinged about it and really don't know what to do with it
<ubottu> Launchpad bug 277556 in open-vm-tools "should build kernel modules with dkms" [Undecided,Confirmed] https://launchpad.net/bugs/277556
<Keybuk> beuno-lunch: oh, I know ;)  it's just confusing ;P
<beuno-lunch> Keybuk, but it keeps you guessing, which is always "fun"
<beuno-lunch> Launchpad: The game
<Keybuk> Launchpad so needs a fail whale equivalent for timeout errors
<evand> ta-widder
<Keybuk> INTO THE LAUNCHPADSPHERE!
<evand> lol
<lool> I understand what the live and ship-live seeds are for but I need a refresh on what the ship seed is for -- is this for .debs included on the alternate CD?
<Keybuk> yes
<Keybuk> (and this is the point cjwatson comes along and says "no, it used to be, but I changed it")
<ogra> lol
<kirkland> dholbach: looking ...
<kirkland> dholbach: so i'd agree that dkms is good for this sort of thing
<cjwatson> Keybuk: not in this case :)
<kirkland> dholbach: seeing as i spend almost every day, all day working on kvm, i don't know much about open-vm-tools
<dholbach> kirkland: who could help out with this?
<kirkland> dholbach: hmm, good question; someone in #ubuntu-virt probably
<kirkland> dholbach: would probably be a community person, MOTU
<dholbach> I was pinged about it and don't know what to do about it
<kirkland> dholbach: b/c we canonical-server are very kvm focused
<dholbach> well, we all touch packages that we probably don't use every day :-)
<dholbach> kernel modules and dkms is nothing I'm good at or would be comfortable judging
<tkamppeter> pitti: Got answers on some of the CUPS STRs, GUI stuff gets all postponed to 1.5, due to I18n.
<tkamppeter> pitti, superm1: Have fixed bluez-cups for CUPS 1.4, will make it available soon and also report upstream.
<ogra> cjwatson, is there any delay wrt germinate pulling the most recent seed versions ? i triggered a ports alternate build after the seedchange showed up on the LP ui but germinate didnt pick up my change
<cjwatson> ogra: none in germinate, but there may be a slight delay (wouldn't expect any more than a few minutes) in the internals of codehosting
<ogra> ok, i'll wait for 20min before starting my next try to be sure
<dholbach> cjwatson: shouldn't juli_ and apw be members of ~ubuntu-dev?
<cjwatson> oh yes, thanks, I'll correct that
<dholbach> super, thanks :)
<ogra> did they pay the bribe ?
<dholbach> yes, all well-received over here
<ogra> oh, *you* get it ?
<ogra> thats why my account is always empty, damned
<cjwatson> fixed
<dholbach> thank cjwatson
<Daviey> it's offical, dholbach is a reciever not a giver.
<ogra> oh, how mean
 * Daviey retracts.
<tgpraveen1> Andreas Moog
<tgpraveen1> ^^ anyone his irc name?
<ion> /who
<Daviey> tgpraveen1: Ampelbein
<cjwatson> tgpraveen1: https://launchpad.net/people in future
<cjwatson> his Launchpad user page has his IRC nick
<kees> soren: I was trying to solve some feature issues before feature-freeze in openjdk-6.  the testsuite doesn't behave the same between local system, Xen PPAs, and bare-metal buildds.
 * soren desperately tries to remember the question he asked kees
<kees> soren: actually, I guess that was also directed at ScottK (openjdk-6 test builds)
<bdmurray> cjwatson: should the postfix bug task for bug 383697 still be open?
<ubottu> Launchpad bug 383697 in lsb "lsb_release crashed with ImportError in <module>()" [High,Fix released] https://launchpad.net/bugs/383697
<dholbach> slangasek: hum... pam asked me if it should restart gdm - was that always the case?
<lamont> bdmurray: ew
<slangasek> dholbach: did it ask /only/ about gdm?
<dholbach> slangasek: no gdm cups cron and something else
<slangasek> hmm, there's supposed to be an exception if the only services running are defaults
<dholbach> gdm cups cron atd
<dholbach> now on the other machine
<slangasek> dholbach: using update-manager, or apt-get?
<dholbach> apt-get
<slangasek> ah
<slangasek> yes, that happens then
<dholbach> ok
<dholbach> nevermind then
<slangasek> we suppress the message if using update-manager
<dholbach> I just thought "my mom would probably just clicked 'ok go ahead'" :)
<dholbach> have a great rest of your day - I'm out, see you tomorrow!
<cjwatson> bdmurray: maybe
<slangasek> dholbach: and clicking 'go ahead' is the right thing to do
<slangasek> it sends gdm a kill -HUP
<dholbach> if it's done differently in update-manager that's fine
<slangasek> (well, it calls /etc/init.d/gdm reload)
<cjwatson> bdmurray,lamont: probably not TBH, in order to fix debconf we had to make lsb_release quasi-essential
<cjwatson> bdmurray: but I think it's lamont's decision whether to close it
 * dholbach -> dinner
<lamont> cjwatson: I'll look at it late tonight/tomorrow
<bdmurray> lamont,cjwatson: thanks
<ogra> cjwatson, Running tools/boot/karmic/boot-armel+imx51 1 /srv/cdimage.ubuntu.com/scratch/ubuntu/ports_daily/tmp/karmic-armel+imx51/CD1
<ogra> debian-installer has kernel ABI 2.6.31-200-dove, but no corresponding udebs are on the CD!
<ogra> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/ports_daily/tmp/karmic-armel+imx51/bootable-stamp] Error 1
<ogra> cjwatson, but ... ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep KERNELVERSION build/config/armel/imx51.cfg
<ogra> KERNELVERSION = 2.6.31-100
<ogra> KERNELVERSION := $(KERNELVERSION)-imx51
<ogra> any idea what i'm doing wrong here ?
<kees> pitti: I've replied to your whiteboard questions for security-karmic-apport-abort.  I'm excited to test the new feature!  :):)
<cjwatson> ogra: sorry, I'm out for a while
<ogra> ok
<pitti> kees: \o/
<pitti> kees: so far I just have test cases on various levels, I didn't really test it end-to-end yet
<pitti> kees: but I wanted to kick in the feature in time for FF :)
<kees> pitti: yeah, absolutely.  I will poke at it too -- I actually had a situation last night where I was wishing this feature was done (having an assert in a sub-process's thread and gdb didn't want to attach to it)
<pitti> kees: right, I couldn't quickly find a packaged program which would assert for me :)
<kees> pitti: heh, normally, that's a good thing.  ;)
 * ccheney` bbl, lunch
<slangasek> pitti: heck yeah, you don't have to tell me twice to remove files from acpi-support :-)
<pitti> that particular bug seems to be tricky, though
<pitti> I don't really know where that duplication comes from
<slangasek> pitti: it can't be caused just by brightness control in hardware; that doesn't explain where the X keypress is coming from
<pitti> slangasek: right, I wrote that in the recent followup
<slangasek> ok
<pitti> obviously the key is hardwired
<slangasek> hmm?
<pitti> but there should still just be one event per keypress
<slangasek> he's seeing an X event
<slangasek> without the udev keymap, without acpi-support
<pitti> and it's apparently not from acpid
<slangasek> so where is that getting into X?
<slangasek> "hardwired" doesn't answer this
<pitti> slangasek: right, I suppose the kernel default is already correct?
<pitti> ah, no, that wouldn't explain the "unknown key" dmesg spam
<pitti> is it possible that there's a kernel module which also translates the acpi events to input events somehow?
<slangasek> sure, possible
<slangasek> we probably need 'lsinput' from him (or /lib/udev/findkeyboards)
<pitti> there's lsinput.log and udev db dump
<slangasek> oh
<tkamppeter> superm1: I have attached the fix for bluez to bug 418465, can you upload it? Thanks.
<ubottu> Launchpad bug 418465 in bluez "bluetooth CUPS backend should output device listings immediately when it discovers the devices (in discovery mode)" [Medium,Fix committed] https://launchpad.net/bugs/418465
 * slangasek looks at the bug, then :)
<pitti> slangasek: http://launchpadlibrarian.net/30857479/lsinput.log doesn't seem to have anything magic, though
<tkamppeter> superm1: I will also submit my patch upstream.
<slangasek> pitti: right; no kernel module input device listed there
<pitti> and http://launchpadlibrarian.net/30857464/udev-db.txt looks okay, too
<pitti> slangasek: hardwired> the dells are the same; pressing them controls the screen brightness, and their events are just used for notification feedback
<pitti> but I still have no clue where the xevs come from with no udev and no acpid
<pitti> â© it's a kind of magic â«
<pitti> so we spent so many hours to figure out how to get these keys _working_
<pitti> and now we struggle with getting them to work a little less intensely..
<kees> slangasek: so, selinux loads policy from the root filesystem, while in the initramfs.  why can't it use tools in /sbin to do that?
<slangasek> kees: well, I suppose it can in that case, but twitch
<slangasek> kees: TTBOMK, the only other thing the initramfs ever execs off the root fs is init
<kees> slangasek: very true, but I'd like to avoid having them rearchitect it the day before feature freeze (it's been like this since hardy, IIRC).
<slangasek> ok
<kees> the recent /share bug was due to mistakes in trying to minimize deltas with debian (and will absolutely get fixed)
 * slangasek nods
<slangasek> kees: fwiw, I latched onto that bug reading #debian-devel in passing, where Manoj had a good rant going about why this shouldn't be needed - feel free to check with him how this is actually working in Debian, if at all :)
<kees> slangasek: okay
<pitti> hm, for a while DNS resolution takes ages here; I thought it'd be a problem with my provider, but my wife doesn't have this problem; and now I discovered this:
<pitti> $ host archive.ubuntu.com
<pitti> archive.ubuntu.com has address 91.189.88.40
<pitti> ;; connection timed out; no servers could be reached
<pitti> (also takes several seconds)
<pitti> does someone else have that, too? (current karmic)
<slangasek> not here
<pitti> I just have one NS in /etc/resolv.conf, and no resolvconf
<slangasek> "no servers could be reached" means it's not reaching your own NS, surely?
<kees> pitti: not me either, though I'm not strictly fully up to date.
<pitti> I just added archive.u.c. to /etc/hosts, and now apt-get update etc. is snappy again
<pitti> ok, thanks for checking
<pitti> dig @192.168.2.1 archive.ubuntu.com works fine
<pitti> hmm
<pitti>  28197/host
<pitti> udp        0      0 0.0.0.0:5353            0.0.0.0:*
<pitti> does that look normal?
<pitti> (while host is running)
<tkamppeter> pitti, superm1: I have fixed bug 418465, and also reported it to bluez upstream with my patch.
<ubottu> Launchpad bug 418465 in bluez "bluetooth CUPS backend should output device listings immediately when it discovers the devices (in discovery mode)" [Medium,Fix committed] https://launchpad.net/bugs/418465
<superm1> tkamppeter, okay i'll take a look at soon.  i'd like to make sure that upstream accepts it without requesting changes first
<ogra> cjwatson, i think i found one of the probs at least, debian-cd/tools/boot/karmic/boot-armel+imx51.calc is never read bacause build_all.sh seems to look for boot-armel.calc (i.e. $FULLARCH only) ... (that doesnt explain why it tries to install the dove kernel on imx51 though)
<Caesar> Hey slangasek has there been any decision made yet on whether 10.04 *won't* be LTS?
<slangasek> Caesar: I believe we're still waiting to find out what Debian is deciding to do for squeeze, and whether there's any advantage to deferring the LTS to better cooperate with the squeeze freeze
<ogra> cjwatson, oh, ignore me FULLARCH=$ARCH+$SUBARCH, i was worng
<Caesar> slangasek: ok, is there some sort of drop-dead date for a decision?
<slangasek> Caesar: the Debian release team has said they'd gather input throughout the month of August and make a decision at the end of this month; the Ubuntu decision should come shortly thereafter
<Caesar> slangasek: ok thanks
<sebner> slangasek: did you already make a decision about boson(-data), I made another comment on the bug
<slangasek> sebner: I was looking at it because it was my archive day; I figured the next AA on duty would pick it up :)
<sebner> slangasek: ah so I'm sorry, and still if you have time ... FF is annoying :P
<slangasek> sebner: "b-p"?
<slangasek> (https://bugs.launchpad.net/ubuntu/+source/boson-data/+bug/418268/comments/2)
<ubottu> Launchpad bug 418268 in boson-data "Please sync boson-data from Debian(Unstable)" [Wishlist,Confirmed]
<sebner> slangasek: build-dependency
<slangasek> ok
<sebner> slangasek: MOTU slang :P
<slangasek> why is it not b-d? :)
<sebner> slangasek: because I'm stupid xD
<slangasek> sebner: so anyway, my understanding is that we were getting rid of all the reverse-deps of the KDE3 libs if they're not getting ported to KDE4
<slangasek> not just because of FTBFS, but because the libs are obsolete
<slangasek> the removal bug was #288949
<sebner> slangasek: IIRC it FTBFS because some old libs had dependencies on new ones and there were conflicts etc. (It was just the time kde3 -> kde4) but it builds now again. don't ask me why
<slangasek> ah, and that does say it needed a KDE3 kdemultimedia to build... so if that's not an issue, yeah, the removal reason seems to no longer stand
<slangasek> ok, I'll bring it back
<sebner> slangasek: thx, and as you can see (my ppa) it really builds
<sebner> slangasek: I'll upload boson myself (needs fakesync)
<sebner> slangasek: at the rest of his life (as I consider upstream dead)
<slangasek> sebner: please add tasks for other source packages you're asking to sync, rather than just commenting in the bugs, btw :)
<sebner> slangasek: it's just those two :P
<sebner> but ok
<sebner> ^^
<slangasek> yes; the difference is that the archive admin tools pick up the source package names from bug tasks automatically for syncing
<sebner> slangasek: I thought your run them like: "sync-package foo foo1 bar bar1"
<sebner> *you
<slangasek> no, we run 'sync <bugnum>' :)
<sebner> uhh nice
<sebner> slangasek: I'll file another sync bug for the music package then
<slangasek> sebner: boson-data can't be synced, because 0.13-3 was previously in the archive
<slangasek> needs a version bump
<sebner> slangasek: versions bump or fakesync?
<slangasek> version bump
<slangasek> just 0.13-3build1
<sebner> slangasek: ah kk, Thanks for your help and sorry for the noise :)
<slangasek> no worries
<tkamppeter> superm1: I got already an aanswer from upstream, they want it, but ask me to send the patch in GIT format.
<RainCT> james_w: can rejected source packages be downloadeed from LP or are they deleted?
<james_w> deleted I think
<RainCT> ok nvm then :)
<tkamppeter> superm1: I have sent the GIT-formatted patch now.
<ogra> cjwatson, ha ! got it the check_kernel_sync call just needed $FLAVOUR appended (must be funny to read your backlog seeing me going back and forth through the code :) )
<jsteel> Does anybody know how ubuntu kernels are versioned? Specifically I'm looking for what exactly the 60 means in 2.6.24-24.60. I'm trying to create a custom kernel and want to know if I should name it 2.6.24-24foo1 so that I can upgrade it to 2.6.24foo2 and so on. Or should I call it 2.6.24-24.60foo1? I cant find anywhere a reference that describes Ubuntus kernel versioning.
<evand> jsteel: I'd suggest using 2.6.24-24.60~foo1
<jsteel> evand: why the ~?
<jsteel> evand: And then when 2.6.24-24.61 comes out, would it upgrade overtop of mine?
 * ogra suggests #ubuntu-kernel :)
<jsteel> ogra: thanks. I was looking for that channel but I couldnt find it.
<evand> jsteel:  http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version and yes, it would install over top of yours
<jsteel> evand: Thanks a lot. I'll check that out
<pitti> kenvandine, StevenK: if gwibber should stay in universe, can it then be removed from the UNR seeds? othewise it does need an MIR (but I thought it wasn't quite ready for that?)
<jsteel> evand: Ah yes, I've already read that. It didn't help me with the difference between 24 and 60 in 24.60
<pitti> kirkland: qemu-kvm b-deps on bochs; is that really intended? if so, needs a MIR
<kenvandine> pitti, yes... it can be removed
<kirkland> pitti: arg.... yeah so it does need an MIR :-/
<lool> Is an archive admin around?
<lool> I mistakingly uploaded a package to karmic instead of ppa
<lool> It's ubuntu-moblin-ppa-keyring; should be rejected from NEW
<kirkland> lool: i'll kick it
<lool> Thanks a lot
<kirkland> lool: gone
<lool> It just showed up
<lool> and gone thanks
<kirkland> james_w: ping
<james_w> hey kirkland
<kirkland> james_w: hey, i'm going to give mass-sync.py a try ... where can I find it?  i don't see it on cocoplum
<james_w> lp:ubuntu-archive-tools
<kirkland> james_w: ah, gotcha
<kirkland> james_w: my bad ... last week i meant that sync-bug-bot.py was flimsy for me
<kirkland> james_w: i hadn't tried mass-sync.py
<cjwatson> yeah, syncbugbot was always flimsy because it did screen-scraping
<cjwatson> ogra: ah, glad to hear it
<kirkland> james_w: hrm, not quite there yet
<kirkland> james_w: http://pastebin.ubuntu.com/260028/
<kirkland> james_w: i've gone to that page and given the tool access to LP
<kirkland> james_w: but i still get the backtrace, rather than it waiting for me to hit enter
<james_w> just run ./mass-sync.py first
<kirkland> james_w: ah, it's crashing on the input file
<kirkland> james_w: gotcha, thanks
<james_w> mathiaz: I'm unsure about "usr/lib/cmpi/*.so" in debian/install in opendrim-lmp-baseserver
<james_w> what sort of shared libraries only need *.so?
<mathiaz> james_w: plugins
<mathiaz> james_w: there are plugins for the sfcb daemon
<mathiaz> james_w: these are plugins for the sfcb daemon
<james_w> ok
<mathiaz> james_w: cmpi is actually a standard interface defined for CIM brokers
<mathiaz> james_w: sfcb is such a CIM broker - and thus can load these plugins
<james_w> you had me at plugins
<mathiaz> james_w: there are other CIM brokers (not available in Ubuntu for now) that could also load these
<mathiaz> james_w: ok cool. Thanks for reviewing the package :)
<mathiaz> james_w: are you reviewing them on REVU or in the NEW queue?
<james_w> New
<mathiaz> james_w: cool - thanks
<mathiaz> slangasek: hi - so I'm waiting on openldap 2.4.18 for the disconnected mode for pcache that was discussed at UDS
<mathiaz> slangasek: 2.4.18 is in final testing but won't be released before FF
<mathiaz> slangasek: so I'm going to need a FF exception
<mathiaz> slangasek: should I file it now?
<james_w> kees: could I trouble you for a quick approval of bug 419506 so that I can fix that wadllib bug?
<ubottu> Launchpad bug 419506 in lazr.restfulclient "[MIR] MainInclusionReport for lazr.restfulclient" [Undecided,New] https://launchpad.net/bugs/419506
<slangasek> mathiaz: yes, please go ahead
<kees> james_w: sure, one sec
<kees> james_w: done
<cjwatson> superm1: I don't suppose you could use a dedicated user for dkms rather than nobody? you could use adduser --system on debian/ubuntu to create one
<cjwatson> superm1: using nobody is really a bug, even though it works at the moment
<superm1> cjwatson, i was hoping to avoid having to create another user just for builds, but yeah I can look into it
<cjwatson> superm1: the problem with nobody is that running stuff as it dilutes the principle that user nobody has no non-trivial privileges - in this case it means that something allegedly sandboxed as user nobody can hijack your dkms builds and inject replacement kernel modules!
<james_w> thanks kees
<superm1> cjwatson, yeah that sounds sensible.  i was trying to get away from doing the builds as root so that a rogue makefile didn't have the potential to hijack your entire system during a build.  (figured this was a step in that direction)
<cjwatson> right, it makes some sense to drop privileges I agree
<cjwatson> but better to keep it contained
<superm1> right.
<mathiaz> slangasek: I've also been working on getting sssd in karmic
<mathiaz> slangasek: unfortunately the daemon suffers from a  fatal bug that make it totally unusable in karmic for now
<mathiaz> slangasek: upstream is working right on a patch
<mathiaz> slangasek: upstream is working right *now on a patch
<slangasek> mathiaz: that's a new package, then?  FFe bug once upstream has something ready then, please
<mathiaz> slangasek: yes - it would be a new package
<mathiaz> slangasek: ok
<simon-o> Hi, when I want to request a merge which depends on another package being merged first (which I also requested), how do I mark that in the bug?
<cjwatson> simon-o: just put it in the bug description
<simon-o> cjwatson: thanks, will do that.
<soren> When does FF actually kick in?
<mathiaz> soren: in 2 hours 7 mn
<soren> \o/
<c_korn> does anyone know why there is only the remuco-server in karmic but not the client? http://packages.ubuntu.com/source/karmic/remuco-server also the debian bug report does not mention why the client directory has been removed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416379
<ubottu> Debian bug 416379 in wnpp "RFP: remuco -- mobile phone remote music control" [Wishlist,Closed]
<c_korn> hm, ok README.Debian just mentions that the client jar has to be downloaded from sourceforge
<Rudy27> Hi
<kees> does anyone here have ATI (and/or use fglrx-installer)?  superm1: around?
<mneptok> kees: i'd be happy to test anything superm1 wants to send me for free ;)
 * mneptok is a magnanimous cat
#ubuntu-devel 2009-08-27
<soren> cjwatson: around?
<kees> mneptok: hah, yeah, but then you have to fix the stuff he ships you.  ;)
<cjwatson> soren: sort of
<soren> cjwatson: You forgot to commit or push to the eucalyptus packaging branch when you uploaded it.
 * cjwatson blinks
<cjwatson> turnabout is fair play, I suppose :)
 * soren blushes at cjwatson's blinking
<soren> :)
<cjwatson> fixed
<soren> ta
<cjwatson> odd, normally I use a wrapper script which causes me to remember to do that, in this case I must have forgotten ...
<soren> I'm still trying to get used to this setup.
<soren> I still haven't quite worked out when to use dch (and which heuristic to use) and when to use debcommit.
<cjwatson> I use DEBCHANGE_RELEASE_HEURISTIC=changelog, DEBCHANGE_MULTIMAINT_MERGE=yes, dch to add changelog entries (which I do any time I make a non-trivial change), debcommit to commit anything other than trivial changes
<soren> DEBCHANGE_RELEASE_HEURISTIC=changelog makes dch put the "UNRELEASED" as the release, right?
<soren> So when you're releasing, you just "dch --release", save, "debcommit --release"?
<soren> Or is there a shortcut I'm not aware of?
<slangasek> soren: that's the way
<slangasek> (and DEBCHANGE_FORCE_SAVE_ON_RELEASE=no is nice, but that hasn't been merged to Ubuntu yet :()
<soren> Cool, thanks.
 * soren adds to his .bashrc
<slangasek> soren: or .devscripts
<soren> slangasek: Ah. Thanks.
<cjwatson> yes, you want it in .devscripts, I don't think it works right in .bashrc
<cjwatson> I have http://paste.ubuntu.com/260110/ as ~/bin/ubuntu-release
<cjwatson> watch out for dch -r's slightly coarse time granularity - you have to wait a second :-/
 * soren hasn't heard of debrelease before
<cjwatson> it is for very, very lazy people like me
<soren> cjwatson: Ah, I see what it does. That's convenient.
 * soren wonders if there's more he can reasonably manage to do before FF kicks in.
<cjwatson> I have a new grub2 building here, I do hope it works ...
 * soren throws in the towel and wanders off to bed
<soren> 11 months old babies don't care much when their parents go to bed. They'll happily wake up at 6 AM even though their father didn't stagger to bed until 2 AM. :)
<cjwatson> I noticed that
<cjwatson> GOOD MORNING DADDY ISN'T IT A LOVELY DAY
<cjwatson> *grunt*
<TheMuso> StevenK: That is a close one.
<StevenK> TheMuso: Which? window-picker-applet? It's all bug fixes.
<TheMuso> StevenK: ah ok
<maco> https://bugs.launchpad.net/ubuntu/+source/jhbuild/+bug/419363 would require packaging and getting up on REVU and getting 2 advocates by tomorrow, huh?
<ubottu> Launchpad bug 419363 in jhbuild "jhbuild is heavily outdated, update it" [Undecided,New]
<chrisccoulson> maco - if you're talking about uploading to REVU and getting 2 advocates by tomorrow in order to meet the FF deadline, then it's too late ;)
<maco> chrisccoulson: ok
<maco> and FF covers everything or just main?
<chrisccoulson> maco - it's everything. I haven't looked at whats changed in jhbuild though
<maco> major version releases, it seems
<chrisccoulson> maco - that would need to follow the process at https://wiki.ubuntu.com/FreezeExceptionProcess
<maco> so i guess that means it freezes at the *start* of thursday, not the end of it
<chrisccoulson> yeah, it gets all confusing due to timezones ;)
<chrisccoulson> but the e-mail went out about 1hour ago
<superm1> kees, what's up?
<kees> superm1: I'd like to test some changes to fglrx-installer and nvidia, but I don't have ATI hardware that fglrx works on
<kees> superm1: it's as simple as:  sudo apt-get install execstack; sudo execstack -c /usr/lib/dri/fglrx_dri.so /usr/lib/libGL.so.* /usr/bin/amdcccle  and then making sure X still loads, and ccc still works, etc
<superm1> kees, has to be on karmic?
<kees> superm1: better if it is -- jaunty i386 -desktop kernel won't break if the executable stack is executed.
<superm1> kees, well i've got a jaunty box right here actually thats i386.  how do i undo this if this breaks?
<kees> sudo execstack -s /usr/lib/dri/fglrx_dri.so /usr/lib/libGL.so.* /usr/bin/amdcccle
<kees> if you're running jaunty i386 -desktop it won't break if it's broken.  i386 -server will break if it's broken, though.
<kees> for jaunty it'd be better to test on amd64
<superm1> i've only got i386 -desktop
<superm1> so still a good test case?
<kees> unfortunately not, the markings will have not affect there (since -desktop in jaunty lacks PAE and nx-emulation)
<kees> I can test nvidia amd64, and nvidia i386, but I've got no ATI anywhere.
<kees> (well, no fglrx-supported-ATI)
<superm1> kees, i'd say throw something out on ubuntu-devel ML then and see if you can grab someone to help out
<kees> yeah, it's probably more a bug-fix than a feature, so I probably don't need to rush it in tonight.
<Amaranth> kees: nvidia actually works with that turned on now?
<kees> Amaranth: dunno, haven't tested it yet.
<kees> Amaranth: nvidia is actually worse than fglrx; they're compiling with such an old gcc that it doesn't include ELF header with the stack flags.  :P
<Amaranth> kees: yay RHEL 2 support
<kees> heh
<kees> Amaranth: yup, seems to work fine with nvidia (at least on jaunty 180)
<Amaranth> kees: One of their customers must have made it a requirement :)
<Amaranth> yay
<kees> Amaranth: now I wonder if it was just fixed in newer drivers, I don't have -173 -96 or -71 hardware...
<Amaranth> kees: Pretty sure it didn't work a couple years ago
<kees> well, I'll try to find some people with older nvidia hardware to test those.  /me prepares a ppa
<StevenK> And now gnome-orca is broken
<StevenK> TheMuso: Right, python-speechd is in universe, and gnome-orca is in main.
<StevenK> TheMuso: This makes ubuntu-netbook-remix and ubuntu-desktop livefses unbuildable
<TheMuso> StevenK: right I think pitti promoted speech-dispatcher but didn't promote python-speechd.
<StevenK> Not according to LP, he didn't. The source for speech-dispatcher is still in universe.
<StevenK> TheMuso: Is there an MIR bug for this?
<TheMuso> StevenK: yes just a sec.
<TheMuso> bug 419036
<ubottu> Launchpad bug 419036 in speech-dispatcher "[MIR] speech-dispatcher" [Undecided,Fix committed] https://launchpad.net/bugs/419036
<TheMuso> hrm maybe I misread the bug...
<TheMuso> although it is marked fix committed
<StevenK> Fix Commited means "MIR approved", Fix Released means "It's been promoted"
<TheMuso> right
<StevenK> Anyway, I'll promote it now
<TheMuso> ok
<TheMuso> StevenK: thanks I owe you one.
<StevenK> TheMuso: Actually, there are a whole bunch of binary packages - do they all need promotion?
<TheMuso> StevenK: No, you should only need to promote speech-dispatcher, python-speechd, libspeechd2, and libspeechd-ev.
<TheMuso> libspeechd-dev even
<StevenK> Bah. Just missed the publisher.
<StevenK> Heh, no, I haven't.
<TheMuso> haha
<StevenK> TheMuso: Done.
<TheMuso> StevenK: thanks again
<StevenK> TheMuso: Should I demote gnome-speech while I'm at it?
<ScottK> StevenK: If you have a few moments, there are a couple of backports sitting in Jaunty New that it'd be nice to get pushed through.
 * StevenK grumbles at ScottK 
<TheMuso> StevenK: may as well
<ScottK> I can do kontrolpack, but quassel's my upload, so if you could take that one, I'd appreciate it.
<StevenK> ScottK: If I'm going to do one, I may as well do them both
<ScottK> StevenK: Thanks.
 * StevenK fiddles the overrides of quassel-dbg
<StevenK> ScottK: Accepted.
<ScottK> StevenK: Thank you.
<StevenK> ScottK: I should rescue protobuf from hardy-backports, too?
<ScottK> Please.
 * StevenK blinks
<StevenK> libprotobuf3 is in main in jaunty, karmic and jaunty-backports, but universe in intrepid-backports?
<ScottK> Doesn't really matter for backports.
<wgrant> StevenK: It was in universe pre-Jaunty...
<ScottK> They are all equally unsupported and Main can build on Universe in backports.
<StevenK> ScottK: Crackports ignores the OGRE model? Ugh
<ScottK> StevenK: It pretty much has to or you'd end up having to do backports only promotions to backports stuff with new depends and we don't have a mechanism for that.
<dholbach> good morning
<highvoltage> guten morgen dholbach!
<dholbach> hey highvoltage!
<highvoltage> dholbach: how are things?
<dholbach> good good - I'm just waking up slowly :-)
<highvoltage> dholbach: heh, same.
<TheMuso> Does anyone plan on filing an MIR for liblqr, as it seems imagemagick has not been built for ages due to requiring liblqr-1-0-dev
<TheMuso> which puts it in dep wait.
 * TheMuso checks to see if imagemagick can be built without it.
<pitti> Good morning
<pitti> TheMuso, StevenK: no, I just approved speech-dispatcher; I still had some questions for it, and seeds need changing
<TheMuso> Morning pitti.
<TheMuso> pitti: right. The issues pointed out were addressed, and questions answered.
<pitti> ah, read the further backlog
<pitti> StevenK promoted, was the MIR bug closed then?
<TheMuso> yes
<pitti> and was gnome-speech demoted along?
<TheMuso> yes
<pitti> great
<StevenK> I didn't demote gnome-speech, acutally
<StevenK> Should I drop the lot to universe?
<TheMuso> oh ok
<TheMuso> Yes nothing should be depending on it.
<TheMuso> in main at least
<ttx> pitti: good morning
<StevenK> Right, confirmed with checkrdepends.
<pitti> hey ttx
<StevenK> pitti, TheMuso: gnome-speech dumped to universe.
<TheMuso> ok great.
<pitti> \o/
<TheMuso> ok seems imagemagick is doing fine without liblqr. Will upload assuming the build is successful, unless someone does plan to file an MIR for liblqr.
<TheMuso> s/assuming/if/
<ttx> pitti: do you know what was the outcome yesterday night for axis2c and rampart ? Would you consider preemptively promoting them as well to let Eucalyptus reach the CD ?
<pitti> ttx: oh, sure; sorry that this got dropped, yesterday was too crazy
<ttx> pitti: I can only imagine, it was already crazy for me :)
<pitti> ttx: promoted
<ttx> pitti: thanks !
<pitti> kirkland: did you see this in component-mismatches:
<pitti>  o kvm: kvm
<pitti>    [Reverse-Depends: Ubuntu.Karmic virt-host seed]
 * TheMuso is a little surprised at hearing his CPU fan spin up with the imagemagick build.
<pitti> kirkland: seems this needs some seed fix?
 * soren hugs pitti
<soren> pitti: Thanks for the axis2c and rampart promotions.
<pitti> yw :)
 * soren is puzzled why apport decided to bombard him with crash reports just now
<ttx> soren: you're past-FF, now you can concentrate on crash reports.
<soren> ttx: heh :)
<highvoltage> how consderate of apport
<ttx> highvoltage: that's part of its AI adaptive features.
<pitti> I pushed the crash nagging lever up two notches yesterday
<soren> pitti: I just tried the Eucalyptus build again, and it ended up in depwait?
<soren> pitti: Oh,I need to wait for a publisher run, don't I?
<tkamppeter> superm1: hi
<pitti> soren: yes
<lool> Does someone know why we pull things like ubiquity, casper, or even lupin-casper in livecd-rootfs instead of the live seeds?
<lool> I mean why LIVELIST="ubuntu-live^ laptop-detect casper lupin-casper" instead of LIVELIST="ubuntu-live^" + seeding?
<slangasek> I guess cjwatson or lamont might have an answer
<StevenK> lool: hysterical raisins, I suspect
<maxb> If there are any main-sponsors or ubuntu-release members who would like to weigh in on LP 406245 it would be appreciated - it's missed FeatureFreeze whilst waiting for sponsorship, but I think it's important for Karmic
<ubottu> Launchpad bug 406245 in subversion "Merge subversion 1.6.5dfsg-1 (main) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/406245
<ogra> cjwatson, u bumped the dove ABI in d-i (just in case you are rolling a package right now, there is a pending change)
<ogra> s/u/i/
 * pitti blinks
<pitti> ValueError: Invalid value '"Medium"' for parameter 'importance': valid values are: "Unknown", "Critical", "High", "Medium", "Low", "Wishlist", "Undecided"
<pitti> go launchpadlib
<pitti> james_w: did you ever happen to see this by chance? happens since recently, probably with new wadllib or so
 * pitti files bug
<dholbach> '"Medium"' != "Medium"
<dholbach> or am I wrong?
<pitti> right, seems wadllib quotes it once too often or so
<pitti> dholbach: right, it's probably that
<pitti> my code didn't change in ages, though, and I don't see what's wrong
<pitti> task.transitionToImportance(importance='Medium')
<geser> pitti: I've seen this yesterday, bug #418802
<ubottu> Launchpad bug 418802 in python-wadllib "requestsync crashed with ValueError in validate_param_values()" [Critical,Fix released] https://launchpad.net/bugs/418802
<pitti> geser: ah, thanks
<james_w> yeah, I need to update the bug
<james_w> I forgot that it was blocked by the ugly python-oauth MIR
<james_w> and I'm not sure what to do about it
<ttx> cjwatson: eucalyptus should reach the CD now that all of it was promoted... when should the cloud installer part hit the daily CD ?
<cjwatson> ttx: it's in the archive, you know the rules I'm sure :)
<ttx> cjwatson: cool, thanks :)
<cjwatson> the node installation isn't really right yet though
<cjwatson> and need a small change to CD bits to get a boot option in place
 * cjwatson promotes eucalyptus-udeb
<apachelogger> mvo: salut, apturl-kde additions pushed to trunk branch (not yet uploaded), please have a quick look (especially at the translation stuff, I am not quite sure how to test pot creation) and upload if you are good with it
<mvo> apachelogger: thanks, will do
<evand> pitti: I'm slightly confused by bug 400179.  It says you promoted pywebkitgtk, but it lists udev as the package and I don't see it in the overrrides file.
<ubottu> Launchpad bug 400179 in pywebkitgtk "pywebkitgtk main inclusion review" [Medium,Fix released] https://launchpad.net/bugs/400179
<pitti> package is still pywebkitgtk; I'll re-promote it
<pitti> it's not the first time that a change-override.py command was just silently not working :/
 * cjwatson sighs at people projecting single bugs in grub2 that affect them into "it shouldn't be the default"
<pitti> evand: done
<cjwatson> BTW is anyone here successfully running GRUB2 with Windows ME?
<cjwatson> there's a really really weird bug report about WinME thinking it's a virus
<evand> pitti: thanks!
<evand> Anyone have a Karmic machine and a USB disk (that they don't care about) handy and want to test for me whether DeviceKit-disks' PartitionTableCreate dbus method is broken?
<pitti> evand: o/
<pitti> what do you want me to do?
<pitti> I have an 1 GB USB stick which I can trash at will, thath should suffice?
<evand> pitti: cool.  I'm seeing "Error creating partition table: timeout (10s) waiting for change" when calling PartitionTableCreate with 'none', [] in d-feet.
<evand> pitti: can you reproduce that?
<pitti> 'none' literally?
<evand> yes
<evand> it will clear the partition table
<pitti> evand: is 'none' even legal? shouldn't that be "mbr" or so?
<pitti> evand: right, I get the same error
<pitti> evand: it does work fine with 'mbr', []
<evand> if you say mbr when a partition table exists, you get an error, I believe
<evand> indeed, "device already has a partition table of given scheme"
 * pitti tries
<pitti> oh nice, palimpsest can also partition now
<pitti> ok, I have an existing partition table now
<evand> (I'm implementing a "format the device" method here, so it needs to wipe everything (including the boot sector), and then create a msdos style partition table and a single fat32 partition spanning the disk)
<evand> okay
<evand> thanks!
<pitti> 'org.freedesktop.DeviceKit.Disks.Error.Failed: device already has a partition table of given scheme'
<pitti> confirmed
<pitti> that's "mbr", [] with an already existing mbr
<tkamppeter> superm1: hi
<pitti> evand: so it seems the bug is that 'none', [] works, but doesn't give a proper return code?
<evand> pitti: indeed, it's timing out, but otherwise works
<pitti> ok, that should be fixed then
<evand> indeed, I'll file a bug report
<tkamppeter> pitti, have you ever submitted a patch to a vger.kernel.org mailing list?
<pitti> tkamppeter: no, I didn't
<pitti> the #ubuntu-kernel folks certainly did, though
<evand> pitti: filed as bug 419796
<ubottu> Launchpad bug 419796 in devicekit-disks "PartitionTableCreate method times out when 'none' is specified as a parameter." [Undecided,New] https://launchpad.net/bugs/419796
<ddeath> Hi
<ddeath> The console application won't display user information when running under X Session
<ddeath> It is correct behavior?
<IntuitiveNipple> Which would be the correct mailing-list to ask a very technical question about python-support, CDBS, and adding a "python-mlt" binary package to "mlt" - the main issue being how to run python-support only for python-mlt (not all the mlt binary packages), or how to recreate python-support's binary-arch output manually?
<ddeath> Hi.
<directhex> hm. it's not clear to me from xorg.0.log which input device is used in the event that xinput thinks there are "multiple" mice
<ddeath> Could anybody look on my library and ask god to include it into Ubuntu?
<ddeath> https://sourceforge.net/projects/cli2gui/
<slangasek> directhex: all of them?
<directhex> slangasek, hm, then i need to debug it. assuming xev isn't lying to me, it's not seeing any events at all from the side buttons or side-wheel
<directhex> (II) Microsoft Microsoft Wireless Optical Mouse? 1.00: Found 5 mouse buttons
<directhex> lies
<sebner> directhex: no wonders it doesn't work with ubuntu
<sebner> slangasek: now in NEW (again) :)
<slangasek> sebner: yep, accepted
 * sebner hugs slangasek and showers with with cookies :)
 * hyperair wishes mdadm and lvm2 are installed on the livecd by default
<Keybuk> hyperair: you can use the alternate CD to install with them
<Keybuk> or you can just apt-get install them if you need to mount an LV or MD device
<hyperair> Keybuk: yes, yes i know. but i'd like to avoid having to apt-get install them all the time =\
<Keybuk> "all the time" ?
<Keybuk> you break your MD arrays *that often*? :p
<hyperair> for recovery purposes
<hyperair> more like i'm trouble shooting grub, and it's refusing to read anything
<hyperair> Loading Stage1.5Read Error
<Keybuk> remember that if they were on the Live CD, they'd be on the default install for everyone
<hyperair> so i tried grub2, and i got Loading kernel.. Read error
 * hyperair whacks grub
<hyperair> eh? really?
<cjwatson> Keybuk: not actually quite true ...
<sebner> Keybuk: is it possible that e2fsprogs broke anything? Since the updates fsck fails on boot. Telling me root partition needs a manual fsck. I do and reboot, works. On the next day I start the laptop again, same issue
<cjwatson> the installer would have to remove them for everyone
<Keybuk> cjwatson: well, you could uninstall them, but that's just wasting effort ;-)
<cjwatson> Keybuk: consider that ubiquity is not on the default install for everyone :)
<Keybuk> sebner: fsck will give you detailed output, what is it?
<cjwatson> the real reason we don't have them on the live CD yet is that it would cause quite a bit of confusion since ubiquity doesn't support LVM or RAID yet
<Keybuk> cjwatson: actually we *removed* them from the set a while back
<sebner> Keybuk: on bootup it just tells me, fsck died on /dev/sda and needs a manual fsck
<Keybuk> we didn't want LVM or RAID on desktop installs because they're expensive
<sebner> *dev/sda3
<cjwatson> Keybuk: right, I know
<cjwatson> Keybuk: but nevertheless that's the reason they aren't in the live seed
<cjwatson> what's in the desktop install is a red herring I think
<Keybuk> sebner: and what does the output of fsck -y /dev/sda3 say?
<Keybuk> cjwatson: I'd say that u6y shouldn't support them
<cjwatson> I want it to (at least LVM, maybe not RAID), just haven't had time
<Keybuk> the experience would be much better if we waited to support btrfs instead
<sebner> Keybuk: Checking inodes etc, result is always 0.4% non-contiguous
<Keybuk> sebner: see, what you're not doing here is pasting me the exact output
<sebner> Keybuk: well, next time I boot up I'll make notes ;)
<Keybuk> sebner: there's a particular e2fsck change that outputs a particular piece of information
<Keybuk> if you don't have that, then no, I don't think the update will have "broken" it
<Keybuk> you could simply be failing to unmount the filesystem properly on shutdown, etc.
<slangasek> ArneGoetje: was ttf-vlgothic meant to directly replace tt-sazanamic-gothic?  because the bzr log says they're meant to be smaller, but vlgothic is 2MB larger than sazanami-gothic
<sebner> Keybuk: Uhhh, that may be a point. since some days it hangs on shutdown
<Keybuk> sebner: there you go then, unclean/dirty filesystem -> fsck required
<sebner> Keybuk: not sure if it's because of the -7 kernel. I'll try
<ArneGoetje> slangasek: ttf-vlgothic is preferred over ttf-sazanami-gothic by Japanese users.
<slangasek> ArneGoetje: but it cost us 2MB on the CDs that we already didn't have... :/
<ArneGoetje> slangasek: together with the other changes I made, we actually gained space according to the Size: numbers
<slangasek> ArneGoetje: which changes?
<slangasek> the arabic / chinese changes?
<slangasek> it's a slight net gain, yes
<ArneGoetje> slangasek: http://pastebin.ubuntu.com/259752/
<ArneGoetje> slangasek: I might reshuffle and repackage fonts further to gain extra space while supporting as many scripts as possible on the LiveCD.
<torkel_> sebner: there are a couple bug reports blaming -7 kernel to hang on shutdown
<slangasek> ArneGoetje: hmm, yep, those numbers look good
<slangasek> and in fact, alternates /are/ down in size vs. alpha-4
<slangasek> so why are the liveCDs up
<slangasek> possibly livefs build failures
 * ArneGoetje doesn't know how size calculation for the LiveCD works
<slangasek> much less precisely :-P
<torkel> sebner: for instance #418509
<directhex> f-spot 0.6.1.1 should give you a couple of meg
<slangasek> ArneGoetje: right, this libgd2 conflict is breaking the livefs builds.  Why does libm17n-0 care about xpm support?
<ArneGoetje> slangasek: no idea
<slangasek> hmm, I'll have a closer look
<ArneGoetje> slangasek: thanks
<pitti> StevenK: would you have a minute to source NEW media-player-id? It's a small data-only package, but needed by new rhythmbox
<agutierr> hello all: I am using preseeds to make unattended ubuntu install. Well, someone knows how to tell installer NOT to install a package (Network-manager :-). Thanks!
<pitti> StevenK: it's more or less converted data to hal, and I'll maintain it, so it's fine for main
<pitti> StevenK: s/to/from/, of course
<sebner> torkel: cool, thx for the hint
<pitti> james_w: retracers just failed with
<pitti>   File "/usr/lib/python2.6/dist-packages/launchpadlib/errors.py", line 20, in <module>
<pitti>     from lazr.restfulclient.errors import *
<pitti>   File "/usr/lib/python2.6/dist-packages/lazr/restfulclient/__init__.py", line 19, in <module>
<pitti>     import pkg_resources
<pitti> ImportError: No module named pkg_resources
<pitti> james_w: that's just a missing dep from -launchpadlib to python-pkg-resources, do you agree? I'll do the change now
<james_w> restfulclient
<james_w> I'll upload, sorrt
<pitti> ah, ok
<pitti> james_w: don't worry, I can do it, just checking with you
<james_w> already half way through
<pitti> heh, ok :) (so was I)
 * pitti drops and fixes retracers instead
<pitti> james_w: thansk!
<james_w> thank you
<james_w> I guess pkg_resources isn't something that people are required to put in setup.py?
<pitti> as requires?
<pitti> they shold, it's not a built in module
<james_w> lazr.restfulclient_0.9.3-0ubuntu2 uploaded
<pitti> yay you
<james_w> and bug filed upstream
<james_w> I'm concerned about python-oauth though
<pitti> I thought using the other API version was okay?
<directhex> i really should work out how to make my mouse not suck
<Laney> stop using a dyson
<directhex> it worked before the new hrad disk, so that implies it worked with manual xorg.conf manglement
<james_w> pitti: I thought so, dobey has objections to using it though
<james_w> pitti: the issue isn't entirely fixed for server implementations, but we have none of those in Ubuntu
<pitti> james_w: is it strictly required in p-launchpadlib? it wasn't necessary so far
<james_w> the old version had an embedded copy
<james_w> u1 still does
<pitti> ugh
<james_w> and dobey has objections to us using the system copy instead of the embedded one, for reasons that aren't entirely clear to me
<pitti> but then we can just as well promote it, if it already has been in main covertly
<pitti> an explicit package is so much easier to support than trying to find hidden copies
<james_w> he has valid concerns about the code, but I don't see why that stops us using the exact same code from a single package
<james_w> exactly
<james_w> he is proposing a fork to fix the issues as he finds upstream to be too slow responding to his concerns and patches
<cjwatson> agutierr: err, it's tricky to exclude a package from a task, easiest way is to use preseed/late_command to remove the package after it's installed
<agutierr> cjwatson, the problem, on the installer I only have apt-install, not apt-remove command
<james_w> it's your call as to what goes in, I have made it clear to him that we are not shipping karmic with an embedded copy of oauth.py when it is packaged separately
<james_w> I'm not sure what the situation will look like when we release though, potentially both projects will use the fork and we drop the python-oauth package
<slangasek> ArneGoetje: ok, no reason m17n-lib needs libgd2-xpm specifically - fix uploaded
<slangasek> ArneGoetje: thanks for your work on getting the CDs smaller :)
<cjwatson> agutierr: apt-install is just a wrapper
<cjwatson> agutierr: 'in-target apt-get purge network-manager' or similar ought to do it
<agutierr> ahh
<agutierr> ok!!!
<agutierr> so much thanks
<slangasek> TheMuso: why does speech-dispatcher use libaudio-dev?  Surely nothing should be using that today?
<slangasek> TheMuso: (pulls it into the CDs now by default)
<ogra> oh my, pulse as it is hacked up for arm support upstream now will never work if you dont compile it on the machine you want to use it on :/
<ogra> (reads /proc/cpuinfo inline from the code at buildtime)
<pitti> doko: does dh_pycentral change a #!/usr/bin/python2.6 shebang line into #!/usr/bin/python ?
<pitti> doko: can I tell it not to? (it really only works with 2.6, and I would like to upload it to debian experimental)
<doko> pitti: no, not automatically. do you call python2.6 setup.py explicitely?
<doko> some build systems replace it automatically
<pitti> doko: I don't, should I?
 * pitti tries, thanks
<Keybuk> *blink*
<Keybuk> /dev/sda1: Superblock last mount time (Thu Aug 27 14:34:07 2009,
<Keybuk>         now = Thu Aug 27 12:44:59 2009) is in the future
<pitti> doko: it's correct in debian/tmp, though, just changed in debian/calibre
<pitti> so it's not the upstream build system
<doko> pitti: which package
<pitti> doko: calibre
<pitti> doko: that's why I thought it was dh_pycentral
<doko> pitti: unstable, karmic?
<pitti> doko: right
<doko> right what?
<pitti> oops, karmic
<doko> :)
<pitti> can't upload to sid (ENOPYTHON2.6)
<doko> pitti: well, you call python, not python2.6. that's like setuptools doing this
<pitti> doko: ah, thanks
<doko> likely even
<pitti> doko: ah, no, the install command installs into debian/tmp/, and that is correct
<pitti> the shebangs get changed in the debian//tmp -> debian/calibre mangling (and it's not dh_install, I'm sure)
<pitti> but anyway, python2.6 setup.py install still does the trick
<pitti> doko: thanks!
<doko> pitti: is bug 320743 filed with the help of apport? IMO apport should not file this kind of report, and point the user to remove the corrupt archive
<ubottu> Launchpad bug 320743 in java-access-bridge "package libaccess-bridge-java None [modified: /var/lib/dpkg/info/libaccess-bridge-java.list] failed to install/upgrade: corrupted filesystem tarfile - corrupted package archive" [Undecided,New] https://launchpad.net/bugs/320743
<pitti> doko: ah, can't build it for 2.6 anyway, since all the dependencies are only available for 2.5
<pitti> doko: looking
<pitti> doko: indeed; apt shouldn't create those in the first place, but I'll filter them out in the hooks for now; thanks for pointing out
<doko> \o/
<doko> is arky an automated tester?
<tkamppeter> pitti, a question about bug 419834
<ubottu> Launchpad bug 419834 in hplip "Needs porting to policykit-1" [High,Triaged] https://launchpad.net/bugs/419834
<liw> hm, in my karmic desktop, I seem to have a sound volume control in the gnome panel that I can't get rid of
<liw> in the notification area widget
<ion> liw: System â Preferences â Startup Applications, uncheck Volume Control, i think.
<liw> what a sucky way to control that
<ion> Meh
<pitti> hi tkamppeter
<directhex> hm
<directhex> why is mouseemu installed by jaunty's ubiquity install?
<tkamppeter> pitti, hi
<directhex> found it. stupid ubiquity
<Keybuk> is it wrong that I have a post-it note on a netbook with "DO NOT REBOOT!" in large letters?
<pitti> tkamppeter: you had a question about hplip PK-1 porting?
<ion> keybuk: Any progress with the mount daemon, btw?
<Keybuk> ion: yes
<Keybuk> it's not really a daemon
<Keybuk> ion: you can actually do fully native upstart-based filesystem mounting ;)
 * Keybuk figured out how
<soren> Keybuk: Depends.. Is it turned off?
<ion> keybuk: Awesome
<Keybuk> soren: no ;)
<Keybuk> ion: but the fully native upstart one is bloody inefficient ;-)
<soren> Keybuk: Then I'd say yes, it is wrong :)
<ion> Heh
<highvolt1ge> mount daemon? that's called an incubus right?
<ion> keybuk: That will handle local mountpoints depending on network mountpoins, fsck et al?
<Keybuk> highvolt1ge: or a succubus, depending on your inclination
<Keybuk> ion: yup
<ion> keybuk: How about the parallelizing of fsck instances that work on physically separate devices?
<Keybuk> ion: yes
<ion> (or blocking fsck instances that work on the same physical device, depending on how you look at it)
<soren> Keybuk: I don't think you traditionally get to make a choice between incubi and succubi.
<soren> Perhaps that's why they're so dreaded.
<highvolt1ge> Keybuk: indeed
<LordMetroid> Is there a netinstall for the alpha4 or how would I go about installing alpha4 in order to help
<LordMetroid> Ahh, #ubuntuone already answered, sorry
<tkamppeter> pitti, yes.
<tkamppeter> pitti, you say in the bug that it is enough to remove the PK support from HPLIP, simply use a ==disable option?
<pitti> tkamppeter: no, I didn't
<pitti> tkamppeter: the PK client code can be entirely removed, but the PK server code needs to be ported
<cjwatson> Keybuk: wild speculation from me in bug 412972, wonder if you could look
<ubottu> Launchpad bug 412972 in procps "can only kill processes with -9 in karmic from SSH sessions, -TERM does not work" [Medium,Incomplete] https://launchpad.net/bugs/412972
<pitti> tkamppeter: previously, the callers of PK-protected methods had to do PK stuff themselves to get authorization after a denied call, etc.; that was changed, PK does it all by itself now
<cjwatson> hmm, actually, the most recent SigBlk mask doesn't match
<pitti> tkamppeter: entirely disabling PK is legitimate, of course, but that would lead to reduced functionality?
<directhex> ooh, sigblk mask issues? i remember those from f-spot
<pitti> tkamppeter: do you know what part of hplip uses that, I guess user tools to check ink level and such stuff?
<tkamppeter> pitti, HPLIP uses it to gain privileges for setting up queues and installing the proprietary plug-in.
<al-maisan> Hello there, I am doing archive administration today and have a question:
<al-maisan>  given a package P listed for demotion to universe: If I don't find P mentioned in any of the seeds and "checkrdepends P" shows no packages in main depending on P then it's safe to demote the latter.
<al-maisan> Is that right?
<tkamppeter> For normal users seeing ink levels ACLs are used.
<pitti> tkamppeter: hm, I thought queues were handled by cups
<pitti> al-maisan: in fact, component-mismatches does that very check
<james_w> al-maisan: listed by component-mismatches?
<cjwatson> al-maisan: yes, that's generally sane, though if I can I usually also try to look through history to find out why it used to be in main, just as a double-check
<tkamppeter> pitti, HPLIP serves for all distros, also the ones where there are no privileged users in the lpadmin group.
<pitti> al-maisan: if a package appears there, it's _technically_ safe to promote; however, sometimes that's a bug, and it's missing seeding or a dependency
<cjwatson> sigblk> I noted that su blocks a bunch of signals, and then (later) calls pam_close_session
<cjwatson> without restoring the signal mask
<pitti> al-maisan: for example, a common case is transitional packags which don't have rdepends any more; but we need to keep them in main (and seed them) so that upgrades work
<cjwatson> so that suggests to me that possibly a PAM session module might end up restarting a daemon on session close, or something
<cjwatson> (which is obviously crazy but I'd imagine it'd be fairly indirect)
<al-maisan> pitti: ah, how interesting!
<tkamppeter> pitti: For us it means that an unprivileged user can start hp-setup and then a login/password dialog appears when finishing queue setup. If a privileged user logs in there, the queue should get set up (not tested by me).
<ScottK> al-maisan: Or something that got promoted because it's needed as a build-depend, but the new upload hasn't happened yet.
<pitti> tkamppeter: hm, given that we actually use lpadmin instead of admin for printers, the former actually sounds sane as well?
<al-maisan> ScottK: gotcha, thanks!
<pitti> tkamppeter: anyway, if the existing PK functionality is disposable, disabling it is certainly fine
<pitti> but I have no clue about hplip, and what that would break, so I rather don't do that
<tkamppeter> pitti: I have build HPLIP simply with PK support all the time. I do not really know whether it is PK client or PK server, or perhaps  both.
<pitti> tkamppeter: both, I presume
<al-maisan> so, the nvclock/smartdimmer packages are listed for demotion to universe. Can somebody please explain how this came about..?
<pitti> tkamppeter: cups doesn't have PKified calls, so it can only provide these services itself
 * directhex bugs ~ubuntu-installer with a buggy bug
<pitti> al-maisan: you can use "checkrdepends nvclock jaunty" to see what it was used by in jaunty
<Keybuk> cjwatson: yeah
<Keybuk> clearly it's a signal mask issue
<lool> kirkland: Hey I see qemu-kvm pulls bridge-utils as a Depends; neither kvm nor qemu did this in the past, could it be removed or at least relaxed?  I never used it on my laptop and would prefer continuing to avoid setting up a bridge there
<Keybuk> but from what
<al-maisan> cjwatson: so, when you "look through history", where do you look?
<al-maisan> pitti: thanks!
<pitti> -- jaunty/main amd64 deps on smartdimmer:
<Keybuk> cjwatson: there's a sneaky quick fix, of course ;)  make ssh an upstart job
<pitti> hal
<tkamppeter> pitti, can you add some references/additional info to the bug report, so that the HP guys can migrate HPLIP easily?
<pitti> al-maisan: so, apparently it was dropped from hal; I'll check the changelog
<cjwatson> al-maisan: seeds, .debs, etc.
<cjwatson> directhex: there are already bugs about mouseemu, don't bother
<pitti> tkamppeter: I gave a link to the porting guide
<cjwatson> directhex: there's no way to detect "do you have a one-button mouse", unfortunately
<tkamppeter> pitti, OK
<directhex> cjwatson, sure there is.
<cjwatson> directhex: so we just check "is it an Intel Mac"
<cjwatson> directhex: oh?
<directhex> cjwatson, no intel desktop mac has ever had a single button mouse
<directhex> cjwatson, only laptops do
<cjwatson> directhex: bluff
<cjwatson> directhex: I have one just to my left
<pitti> al-maisan: ah, I see the confusion
<pitti> al-maisan: I need to add back the dependency, please leave it in main for now
<al-maisan> pitti: also: "jaunty/main i386 deps on smartdimmer: acpi-support"
<pitti> al-maisan: right, but that's truly obsolete
<liw> cjwatson, is it the mighty mouse? (the mighty mouse in my apartment has at least two buttons: right side is a hidden button, can be clicked separately though)
<al-maisan> pitti: right, will do.
<cjwatson> liw: I forget, I don't use it much
<directhex> cjwatson, mighty mouse has shipped by default since october 2005. intel macs appeared in 2006
<cjwatson> patch welcome to turn it off for desktops
<cjwatson> the relevant source package is hw-detect
<liw> (the mighty mouse right button is so well hidden it might as well not exist, though)
<directhex> cjwatson, isn't it as simple as inserting "laptop-detect &&" or am i missing something?
<pitti> al-maisan: hal uploaded, thanks
<al-maisan> pitti: thank you :)
<directhex> liw, the mighty mouse looks physically single-button. if it has a scrollball, it has 4 clickables & is a mighty muse
<directhex> cjwatson, does the mouse to your left have a scrollball?
<cjwatson> directhex: and depending on laptop-detect-udeb, I suppose
<cjwatson> yeah, it does
<liw> directhex, that's the one I mean, yes
<cjwatson> ok, my apologies
<directhex> cjwatson, then it's 4-button, and mouseemu would likely prevent one from working
<directhex> probably the "squeeze it like you mean it" button
<cjwatson> here's another question
<cjwatson> WHY does mouseemu prevent it from working? it should just pass through those events
<cjwatson> there's an argument that that would be a more complete fix
<directhex> i agree. still working on that bug
<directhex> looks 100% by design to me
<ogra> directhex, yo
<directhex> ogra, yup?
<ogra> directhex, is there any chance i can get some mono people look at Bug 391124 ?
<ubottu> Launchpad bug 391124 in tomboy "tomboy crashes on ARM hardware if notification icon is clicked" [High,Confirmed] https://launchpad.net/bugs/391124
<ogra> i'm a bit lost with it
<cjwatson> directhex: by design> how so? it's definitely meant to pass through mouse events
<ogra> but we need to include tomboy in the arm images ... its apparently only tomboy having issues, f-spot works fine as expected so no general mono prob imgo
<ogra> *imho
<directhex> cjwatson, define "pass through". mouseemu for me appears to swallow all real mouse events (event6), and regurgitates them itself under its virtual device (event5) - but the virtual device lacks buttons
<directhex> ogra, have you spoken to sandy?
<cjwatson> directhex: defining it by mouse_event and passthrough in the source code
<ogra> directhex, only on the bug yet
<ogra> (see the last two comments)
<cjwatson> directhex: I'm not saying your symptoms are untrue; but when you say "bad design" that suggests that you think it's deliberate in the code, rather than a bug
<cjwatson> the virtual mouse device does this to set up buttons:
<cjwatson>         ioctl(ui_mouse_fd, UI_SET_KEYBIT, BTN_LEFT);
<cjwatson>         ioctl(ui_mouse_fd, UI_SET_KEYBIT, BTN_RIGHT);
<cjwatson>         ioctl(ui_mouse_fd, UI_SET_KEYBIT, BTN_MIDDLE);
<cjwatson> what else should it be doing?
<directhex> cjwatson, passing BTN_SIDE, BTN_EXTRA et al?
<cjwatson> directhex: that sounds sensible. Is it only the buttons after the third that it breaks for you?
<directhex> cjwatson, yes. well, scrolling works, where scrollwheels are seen in x as buttons 4 and 5
<cjwatson> and are there any drawbacks to passing extra buttons? presumably, ideally, we should only pass through those buttons which the real mouse has
<jpds> MacSlow: Please prod bug #419928 when you have time.
<ubottu> Launchpad bug 419928 in notify-osd "notify-osd ignores postion setting" [Medium,Confirmed] https://launchpad.net/bugs/419928
<cjwatson> otherwise I guess there might be some software that acts differently on the assumption that there's a scrollwheel present when there isn't
<directhex> cjwatson, yes - or, if X is happy with it, not swallowing button presses for all buttons. i'm not sure about the best approach
<MacSlow> jpds, "prod"?
<MacSlow> jpds, what do you mean by this?
<jpds> MacSlow: Take a look.
<ogra> MacSlow, prod = stochern/stupsen :)
<directhex> cjwatson, Bug #419947 if you want to write some notes on it
<ubottu> Launchpad bug 419947 in mouseemu "Mouseemu prevents use of multi-button mice" [Undecided,New] https://launchpad.net/bugs/419947
<MacSlow> jpds, done
<directhex> ogra, my instinct is that it's a gtk# bug
<directhex> ogra, let me find mkestner
<ogra> directhex, thanks a lot
<cjwatson> directhex: thanks
<directhex> ogra, he seems offline. try pinging mkestner@novell.com - he's the gtk# maintainer, and it seems to be dying in the binding in the binding layer - something about menu positioning, perhaps? this isn't on a normal gnome desktop is it?
<jpds> MacSlow: So notify-osd bubbles should be coming up half-way down the screen?
<ogra> directhex, thats a normal gnome desktop under armel if i either click the tray icon or the "notebook" button
<directhex> cjwatson, if X uses a composite of all mice plugged in, then could mouseemu simply not swallow events outside the range it emulates, so those few buttons go through "real" event6 rather than emulated event5?
<ogra> directhex, and as i said above it must be something tomboy uses that f-spot doesnt, f-spot works fine on the same desktop
<MacSlow> jpds, see my comment on https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/419894 (which #419894 is a duplicate of)
<ubottu> Launchpad bug 419894 in notify-osd "notify-osd images appear at the middle right of screen" [Undecided,Invalid]
<directhex> ogra, well, i know tomboy uses non-standard decorations in tis context menu, perhaps that's related
<ogra> yeah, might be
<directhex> ogra, certainly sandy is the first port of call, but i have a hunch it's gtk# - sandy can confirm though
<ogra> i wouldnt call it a general gtk# bug though
<jpds> MacSlow: Aha, OK.
<directhex> time to catch a bus!
<ogra> since f-spot uses gtk# too and doesnt have any issues, probably that makes it easier to intersect
<blackxored> hello all
<cjwatson> directhex: I'm not sure you can do that - AFAICS you either grab all events or none
<cjwatson> argh. I HATE PATCH SYSTEMS. (just ate my code)
<mvo> quilt?
<mvo> dholbach had this idea of having a "edit-patch" script that would provide a common editing interface on top of all the different ones
<mvo> (that would at least make working with them a bit easier)
<cjwatson> dpatch. I hate them all almost equally though
<dholbach> and prompt you to fill out the PatchTaggingGuidelines stuff afterwards
<mvo> :)
<mvo> dholbach++
<sistpoty|work> edit-patch --eat-my-code :P
<chrisccoulson> liw - i'm not sure i agree with bug 419912
<ubottu> Launchpad bug 419912 in gnome-media "gnome-volume-control-applet gives no way to remove it from the panel (notification area)" [Undecided,New] https://launchpad.net/bugs/419912
<chrisccoulson> nm-applet (the other persistent notification icon) doesn't have an option to exit either
<liw> chrisccoulson, the fact that it is a persistent notification is irrelevant to me, I just want an easy way to get rid of it
<chrisccoulson> and if you give users an easy way to quit it, there is no obvious way to relaunch it again (because it is a session agent rather than an application that you launch from the menu's)
<liw> so make it easy to put it back, too, no worries
<chrisccoulson> hmmm, i'm not sure. perhaps you could report it to the Gnome bugzilla though and discuss it with upstream?
<liw> the ubuntu default session is under ubuntu's control, right?
<chrisccoulson> yes, but adding an option in the applet to exit would be better off coming from upstream
<liw> then please forward the bug
<pochu> pitti: hi, do you plan to upload media-player-id to Debian too?
<pitti> pochu: can do eventually, but I'm a little tight on time right now
<pitti> pochu: it needs an ITP first, and all that
<pitti> pochu: do you want to upload the the rb to debian?
<pitti> (or RFP)
<pochu> pitti: I looked yesterday at switching rb to gudev
<pochu> pitti: but libgudev is in experimental only right now anyway, so no hurry :)
<pitti> uh, still?
<pitti> it becomes ubiquituous, debian should get the latest udev..
<pochu>       udev |    0.141-2 |      unstable | source, alpha, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
<pochu>       udev |      146-1 |  experimental | source, alpha, amd64, armel, hppa, i386, powerpc, s390, sparc
<pochu> so yeah
<sebner> pitti: the comments aren't that useful (SATA -USB -71), hmm? :(
<pitti> didn't have time to look at the replies yet, sorry; crazy FF rush with 16-hour days, etc.; will get to it soon, promised
<sebner> heh, np
<al-maisan> quick sanity check: ibus-qt/ibus-qt4 are listed for demotion to universe and were only added in karmic. Is it OK to go ahead and demote them?
<pitti> ArneGoetje: ^ isn't it supposed to replace skim in Kubuntu, too?
<pitti> al-maisan: probably just not seeded yet
<Riddell> pitti: hmm, I think we want those ibus-qt packages
<al-maisan> pitti: aha, so I should hold off then.
<ArneGoetje> we do want ibus-qt in the kubuntu seeds
<Riddell> ArneGoetje: I'll add that then
<al-maisan> Thanks for the info
<ArneGoetje> Riddell: I'm not sure of the kubuntu seeds in the moment, I did some reshuffeling for the ubuntu seeds. http://pastebin.ubuntu.com/259752/ I guess, replace ibus-gtk with ibus-qt and the rest can be the same, or what do you think?
<cjwatson> directhex: I'd appreciate it if you could give http://paste.ubuntu.com/260391/ a try
<Riddell> ArneGoetje: and add kimpanel too?
<directhex> cjwatson, i have an abominable memory. if you email that to me, i'll try it out at home tonight (i'm not at the mac anymore)
<Riddell> pitti: re bug 418688 can I move it to main for the sake of FF and look into a wrapper script shortly?
<ubottu> Launchpad bug 418688 in plasma-widget-kimpanel "[MIR] plasma-widget-kimpanel" [Undecided,Incomplete] https://launchpad.net/bugs/418688
<cjwatson> directhex: shall I just put it in the bug?
<directhex> yeah, that works
<ArneGoetje> Riddell: yep
<directhex> maybe i could expense a many-button gaming mouse for the office, that's work
<directhex> any benefit it would give to my Quake Live scores would be a side-effect
<cjwatson> directhex: indeed, ignore that pastebin URL, since I missed a bit. Updated version in the bug
<al-maisan> hmm .. what happened to gnome-terminal in karmic so it does not honour cmd line args like "--geometry 110x20+0+5" any more?
<al-maisan> bug #418555
<ubottu> Launchpad bug 418555 in gnome-terminal "geometry option isn't applied" [Medium,Triaged] https://launchpad.net/bugs/418555
<al-maisan> .. and http://bugzilla.gnome.org/show_bug.cgi?id=592435
<ubottu> Gnome bug 592435 in general "--geometry not working" [Normal,New]
<pitti> Riddell: kimpanel> sure, please go ahead; it seems to be by and large fine
<pitti> Riddell: I'll add some official blessing to it
<pitti> Riddell: [done]
<lool> bryce: I'm giving back xorg-server on i386 to see if it builds now; it seels it was just a transient libdrm installability issue which caused it to FTBFS
<LordMetroid> Dang, everything just crashed on my alpha4
<cjwatson> bryce,jdstrand: is bug 407428 still happening for you, right now?
<ubottu> Launchpad bug 407428 in openssh "sshd zombie processes and strange behavior after karmic upgrade" [High,Confirmed] https://launchpad.net/bugs/407428
<Keybuk> it's amazing how much slower the PPA system is once the US is awake...
<ScottK> Needs higher build scores for developers ....
 * lool gives three cheers to paulliu, StevenK and others who helped shape http://people.canonical.com/~lool/moblin-virtualbox.png
<lool> And OEM team and every who participated in the moblin beta work
<dholbach> lool: that looks sweet!
<lool> Still built from a PPA but on cdimage; hopefully we'll merge as much as possible into Ubuntu proper
<dholbach> pitti: did you get in touch with Don Scorgie about it? I'm sure he could help
<dholbach> (gnome-help->langpack)
<cjwatson> for the replaces fields? how?
<dholbach> I though we were pondering a different installation path or something
<pitti> dholbach: no, I didn't; the problem really just occurred to me yesterday; he's the GNOME help guru?
<dholbach> pitti: rarian guru and knows a lot about the gnome help stuff
<pitti> ah
<pitti> dholbach: thanks, I'll talk to him; failing that, lool just had a good idea as well
<kees> pitti: woohoo!  bug 419658
<ubottu> Bug 419658 on http://launchpad.net/bugs/419658 is private
<kees> well, it's an assert bug.  :)
<pitti> nice! just saw it
<pitti> kees: I think automatic duplication should work as well, let's see..
<kees> pitti: so, I just noticed that when upstream rewrote my patch, they also renamed the variable (from __assert_msg to __abort_msg), so I'm going to update our eglibc to match upstream's patch, and then swap it in apport.
<kees> pitti: cool!
<pitti> eww, a glibc was detected..
<pitti> kees: eek, I actually did check the upstream patch, but that failed to catch my eye
<kees> heh, yeah, mdz was complaining a while back that the malloc error string is confusing.
<pitti> kees: yes, we should do that to avoid divergence, thanks
<pitti> kees: oh, it has an address in the assert message, so it might not match after all (for duplicates)
<kees> pitti: I'll get that up today; I built the "fixed" eglibc overnight, and confirmed that it works correctly just now.
<kees> could the dup-checker learn to ignore 0x[0-9a-f]* ?
<pitti> kees: it should be filtered in def crash_signature()
<pitti> kees: perhaps not *, but [6-]
<pitti> to filter out small numbers like 0x02
<kees> pitti: ah, good idea.
<kees> pitti: should I try to fix the malloc error message to be more clear?
<pitti> kees: is that an ubuntu patch?
<pitti> kees: if so, sure
<kees> pitti: no, the malloc errors are upstream.  I actually meant "should I send a patch to upstream to improve..."
<kees> I'll see what they say, it's always entertaining...
<pitti> kees: not really important at least to me, but if you wish
<pitti> but it's so much fun
<kees> hehe
<pitti> reminds me of the discussion about strings like "OMG computer burning" in the kernel
<kees> we need more of those kinds of easter eggs.  :)  /me is sad that the new gdm doesn't include the "insert a quarter" easter egg now.
<pitti> yeah, that was cute
<kees> pitti: oh, btw, should the retracer learn to unwind to the first non-libc stack location for the source retrace?
<kees> pitti: otherwise, everything will look like:  StacktraceTop:__kernel_vsyscall (), *__GI_raise (sig=6), *__GI_abort () at abort.c:88, etc...
<pitti> that would certainly be good
<pitti> we don't use stacktracetop for dup matching for assertions, so it's not immediately urgent
<pitti> but stacktracetop is still convenient for developers to look at
<kees> true, though it's sometimes really hard to isolate where a fortify crash happens, so I'll likely try to work on that as it would hugely improve the speed of debugging.
<kees> actually, nevermind, the full stack trace is sufficient.
<kees> you're right, stacktraceTop is a cosmetic issue.
<directhex> halfway there, cjwatson!
<bryce> cjwatson, I've not seen it the last few days
<martinald> hi guys, i am looking to create a GUI frontend to dmg2img for ubuntu. i am wondering if anyone in the ubuntu community would be willing to spend 10 minutes going through what the best programming language and GUI toolkit I should use
<martinald> i am very experienced in web programming but I have very little experience of linux GUI programming
<martinald> or if someone could point me to a correct channel that would be much appreciated
<directhex> martinald, c# and gtk!
<directhex> martinald, mor generally, i don't know of any generalist channels for development *on* ubuntu, this is for development *of* ubuntu
<jdstrand> cjwatson: re sshd> it hasn't for a little while, but I've rebooted a lot lately. I'll keep an eye out for it though
<ebroder> Anyone from ubuntu-sru that could look at bug #330766? It's causing problems for our site deployment, and we were hoping it would be fixed by the time term starts here (in a week)
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<billybigrigger> anyone aware of the errors in ubuntuone?
<billybigrigger> causing %100 cpu usage?
<pitti> [ubuntu/karmic] fteqcc 3343+svn3223-1build1 (Accepted)
 * pitti tries to pronounce that
<pitti> looks like git revision numbers are actually used as package names now? :-)
<vorian> keep your teeth together when trying
<vorian> it makes it much easier
 * sistpoty is innocent :P
<ScottK> Speaking of which: Sput shouldn't netsplits be added to the list of events one can hide?
<ScottK> Whoops.  Wrong channel.
<rtg_> kirkland, you around?
<kees> james_w: did anything ever happen with gnome-system-tools and getting it to launch the "self" password changer?
<james_w> ah
<james_w> no
<james_w> I completely forgot about that proposal I'm afraid
<kees> james_w: I'd like to try to get a FFe for it; do you have a guess at how long it might take to implement.  it's the only thing that is blocking the ecryptfs feature for the installer.
<james_w> ah, because it currently bypasses pam and so changing your password means you can't log in?
<kees> correct
<james_w> and you would be happy with changing anyone elses password using that causing them to be unable to log in?
<james_w> well, not happy I guess :-)
<kees> the idea was that if you went to users&groups and selected yourself, it would change the password tab to match the "about yourself" screen that has a proper password-via-PAM thing
<kees> not happy, but we felt at UDS it was a reasonable compromise.
<james_w> ugh
<james_w> users-admin seems to be bust anyway
<kees> james_w: can I assign 307019 to you, then, as a catalyst for the g-s-t work?
<james_w> I'm just trying to look at this problem, a first glance suggests it could be serious
<james_w> but go ahead, even though having a g-s-t bug assigned to me will make me cry
<kees> james_w: is it hard to have it just launch the "about me" dialog?
<kees> heh, okay
<james_w> no, I think that would be quite easy
<james_w> you can't do groups from there
<kees> okay, right, that's the work-around that would unblock ecryptfs for karmic.
<kees> right, I mean, within g-s-t, if you select yourself and go to the password tab, it would just have a single button to launch "About Me", rather than the regular password tab.
<james_w> ah
<james_w> it's not a tab, but an area on the first tab
<james_w> still possible to have a button of course
<james_w> plus gnome-about --change-password to get it to show it's password changer only
<james_w> that's probably not too much work
<james_w> it's just the danger of pulling at that hanging thread
<kees> james_w: well, the "contact" tab should have the launcher, and the password area should have the launcher.
<kees> I think it's okay to just launch the entire about-me dialog?  maybe drop the "Contact Information" tab in Account Properties, and just replace the Password section of the "Account" tab with a buttonr eading "Change password or contact informatin" ?
<james_w> oh, the "contact" tab because that's also present in the other one?
<james_w> I think the gnome-about-me one doesn't use gecos for that info
<james_w> I think that would be a good suggestion though
<kees> oh, heh, yeah, if the about-me doesn't actually change gecos, nevermind on that.  :P
<james_w> it seems GNOME ignores gecos though, so whatever about-me changes might be more useful to change for the average desktop user
<eurythmia_> if I wished to start contributing as a dev, should I run a dist-upgrade to karmic, or should I perform a clean isntall?
<highvoltage> eurythmia_: jaunty will be fine
<highvoltage> eurythmia_: you could use karmic as well, but there are risks associated with it
<eurythmia_> highvoltage: so, there shouldn't be any *major* differences between the libraries I would be building against if I were using jaunty?
<highvoltage> eurythmia_: look up pbuilder on the ubuntu wiki, pbuilder will sort that out for you, it creates a chroot for the package you want to build and also makes sure that you have the correct build dependencies installed in the chroot
<highvoltage> eurythmia_: so you can build packages for pretty much any version regardless of the release you're running
<eurythmia_> highvoltage: ahh. I hadn't gotten around to reading much about pbuilder yet, but that's pretty neat.
<eurythmia_> thanks.
<highvoltage> you're welcome
<eurythmia_> there's a lot to read when starting to develop (for any project), but I'm making *some* headway.
<highvoltage> eurythmia_: if you're interested in packaging, you might want to check out the #ubuntu-motu channel. MOTU is the right place for getting started with packaging, this channel isn't really appropriate for that
<highvoltage> eurythmia_: yes indeed, there's lots of reading work
<eurythmia_> highvoltage: actually, I'm interested in the kernel, but it's been suggested that everyone starts with MOTU.
<highvoltage> eurythmia_: it's a good suggestion, whatever you contribute to in ubuntu, it's pretty much necessary to know how to contribute those changes, and to do that you have to understand some core processes and be familiar with debian packaging
<highvoltage> eurythmia_: there's also am #ubuntu-kernel channel where the kernel guys hang out. they could probably sponsor your initial patches and contributions
<eurythmia_> highvoltage: yep, I'm already there :)  ... I suppose I'll also try my hand out at the MOTU thing to get started.
<sistpoty> erm, highvoltage, eurythmia_: right now, you *should* be using karmic, especially for kernel stuff. otherwise it'd be pretty hard to test changed, wouldn't it?
<sistpoty> s/changed/changes/
<highvoltage> sistpoty: you can test some things in a virtual machine as well, or on the hardware that you're testing the bugs with
<eurythmia_> is there a testing machine?
<eurythmia_> or are you referring to a personal test machine?
<sistpoty> highvoltage: no, not really in a sufficient matter (for a kernel()
<eurythmia_> sistpoty: actually, depending on which part of the kernel is being worked on, VMs are ideal for kernel testing.
<highvoltage> sistpoty: I just can't afford instability on my laptop, and I think it's like that for many other people, I have a bunch of other machines that I run karmic on though
<eurythmia_> I don't do hardware or drivers ... so it would be okay for me to not run the kernel on a physical machine
<sistpoty> eurythmia_: that really depends if it's in anyway related to timing/hardware. if it is, no chance for a vm
<eurythmia_> sistpoty: heh, timing issues are their own special brand of bad ... even with the right hardware, there's no guarantee that they'll be reproducible ;)
<sistpoty> highvoltage: you're right, that I wouldn't recommend karmic for the average user ;)
<sistpoty> heh
<directhex> cjwatson++
<highvoltage> anyway, sistpoty has much more experience than me so I trust his judgement. I'm just not that convinced that you always *have* to be on the development version on your actual production system in order to contribute
<sistpoty> highvoltage: sorry for not being clear enough, what you just stated is certainly right... just this occurance is certainly a special case ;)
<highvoltage> sistpoty: ok :)
<eurythmia_> highvoltage,sistpoty: thanks, both of you, for your input. :)
<highvoltage> eurythmia_: pleasure and good luck.
<james_w> kees: bug updated with some suggestions that you may want to stomp out before we get carried away
<kees> james_w: checking, one sec
<james_w> sorry, shouldn't have pinged you, I'm sure you are subscribed and could respond when ready
<kees> james_w: well, it's in recent memory, so my latency is lower.  :)  no problem.  :)
<jtimberman> I want to use sbuild for package build testing for hardy through karmic, should the build host node be karmic?
<kees> james_w: I'm fine with any of those, but prefer ones that use pipes or fd over dbus.
<james_w> kees: any concrete reason?
<kees> jtimberman: yeah, it's easier to set up the debootstrap bits (i.e. no work).
<kees> james_w: simply that they are ancient methods that are very well understood.  dbus is still "new", and negotiating ssl over a message-passer just makes me want to cry.
<james_w> oh, I wouldn't have gone for that one, I just like the idea :-)
<james_w> but I would characterise that as natural security professional wariness, I wondered if there were reasons why DBus may present a larger surface or similar
<james_w> thanks for your time
<kees> james_w: heh, yeah, my programming conservatism really comes out on these kinds of things.  ;)
<kees> james_w: np, I've commented on the bug too.
<james_w> thanks
<james_w> I'll see how Milan feels about the suggestions
<james_w> coding suid helpers would be more work, but fits my tendencies better than GUI coding :-)
<kees> I think that's why I like the named pipe best: no extra helpers.  backend is already running as root, iirc
<james_w> yeah, probably the easiest to implement as well
<directhex> cjwatson, poke poke
<mathiaz> jtimberman: my main build server is running hardy - and I build packages from dapper to karmic with it
<ebroder> Anyone from ubuntu-sru around who could look at either bug #330766 or bug #328575? They're causing problems for our site deployment, and we were hoping to get them fixed as soon as possible
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<ubottu> Launchpad bug 328575 in dbus "[gnome-terminal SRU] Cannot start gnome-terminal (or x-terminal-emulator) because of gconf error" [Unknown,In progress] https://launchpad.net/bugs/328575
<mathiaz> jtimberman: however I had to fix sbuild in hardy as it broke with karmic
<jtimberman> mathiaz: already installing karmic ><
<jtimberman> which is fine, because i'm going to manage the node with chef, so i can use the chef packages from karmic directly :)
<mathiaz> jtimberman: oh well. in that case - if you find a bug don't forget to report it!
<jtimberman> mathiaz: definitely.
<mathiaz> jtimberman: sounds like a good plan
<lifeless> jcastro: you should hang in #bzr somedays ;)
<lifeless> jcastro: also  -- bzr-builder < jamesw at u.c>   - is the changelog author for quicklies build
<lifeless> jcastro: you may want to tweak/fix that
<jcastro> lifeless: That's a limitation of how he's set it up iirc, he mentioned it at the sprint
<lifeless> jcastro: sadly I wasn't there
<lifeless> its just _odd_ to have you uploading his changelog :)
<jcastro> lifeless: yeah I was just mentioning that it's a known thing.
<jcastro> lifeless: really james_w is just hijacking everyone's karma
#ubuntu-devel 2009-08-28
<jtimberman> Can an sbuild host also build packages for debian lenny?
<ojwb> jtimberman: you'll need a lenny chroot
<TheMuso> slangasek: Ah thats for NAS support, I will drop it then.
<TheMuso> I don't expect people to be using that for speech output.
<slangasek> I don't expect people to be using it at all, I thought it was obsolete before ESD. :)
<jtimberman> ojwb: thats all? neat.
<TheMuso> I am surprised its still in main actually.
<ojwb> jtimberman: I've not done it with sbuild, but with pbuilder it is
<jtimberman> ojwb: cool, i'll give it a whirl
* StevenK changed the topic of #ubuntu-devel to: karmic alpha-4 released | Archive: open, FeatureFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<TheMuso> ogra: Thanks for the pulseaudio arm fix.
<StevenK> fabbione: Any plans to update redhat-cluster? It is now keeping 2 libraries in the archive that are NBS.
<mdz> slangasek, er, I just noticed something missing from the release manifest
<mdz> slangasek, the DVDs!
<TheMuso> dtchen: Do you need help with an FFE for that snapshot?
<dtchen> TheMuso: no, it's probably best to wait until 0.9.16 final for the FFE
<dtchen> if the situation becomes dire (PA eating cats and such), yeah, then FFE for a snapshot seems more appropriate IMO
<ScottK> TheMuso: Did you see -rt uploads are approved?
<ScottK> dtchen: Isn't PA eating cats a design goal?
<ScottK> ;-)
<dtchen> well, my feline is ok, so everything must be fine!
<TheMuso> ScottK: I did, I will be looking to get things back in sync on the weekend.
<TheMuso> superm1: Are you using the new gdm for mythbuntu? If so, is your gdm wallpaper different to the wallpaper shown in the desktop session?
<superm1> TheMuso, it's going to be different, but that part hasn't been done yet.  right now i'm just trying to fix all of the rdepends of ttf-bitstream-vera
<superm1> our live disks have been broken for over a week because it was ripped out of the archive
<superm1> TheMuso, is there some documentation how to build a package that does that though with the new gdm era?
<TheMuso> superm1: THis is the sticking point. The new gdm uses part of gnome-session, and thereby uses gconf keys to set wallpaper. These keys happen to be exactly the same as whats used for the gnome desktop proper.
<superm1> TheMuso, so is it possible to override them with a gconf file of higher priority?
<TheMuso> superm1: If you do that, its done for the desktop as well.
<TheMuso> Thats not so bad for you since you use XFCE, but, for studio for example, that doesn't work.
<superm1> oh i see
<superm1> so what's your solution for studio?
<TheMuso> Don't have one yet, trying to nut that out. Also trying to work out a solution for xsplash.
<TheMuso> xsplash won't be as difficult to work out, but still something that needs to be addressed.
<superm1> there's always the option of not using xsplash too at least
<TheMuso> nYes, true enough.
<TheMuso> As for gdm, the best I can come up with so far is that the gdm package sets a particular filename for the wallpaper on package install for the gdm user. Then derivatives/ubuntu use the alternatives system to point to their wallpaper.
<TheMuso> That doesn't solve the problem of setting a different window theme for gdm however.
<superm1> at least for mythbuntu that's less of a concern.  most people will be using autologin, so won't even be seeing it
<TheMuso> Right.
<slangasek> mdz: ah, true.  Also, ports images aren't documented anywhere there - should they be?
<dholbach> good morning
<highvoltage> hola dholbach!
<dholbach> hey highvoltage
<spstarr> would it not be safer to make logrotate.conf save a years worth of logs vs only 4 weeks?
<ScottK> Not particularly.
<ScottK> If you really care about a year of logs, you probably don't want to save them on the box in question anyway.
<spm> spstarr: at $job-1 to... -start; some types of logs would have to be retained according to the archives act; which i think is around 20-50 years. the rest I think were 7 years. YMMV. :-)
<spstarr> ScottK: servers even if you send it over network
<spstarr> its still nice to have
<ScottK> Well it depends on how much space you have to spare
<fabbione> StevenK: no? I orphaned the packages months ago
<fabbione> StevenK: there is an ubuntu-ha team you can talk to
<fabbione> StevenK: they took over all the ha cluster stack
<spstarr> ScottK: 1 year of standard logs + compressed should not full a big disk up that fast :)
<ScottK> Depends on what your server is.
<spstarr> right
<NCommander> ScottK, mind doing a quick archive-admin task for me?
<ScottK> NCommander: Depends on what and how quick?
<NCommander> ScottK, can you punt linux-mvl-dove through binNEW queue?
<ScottK> No.  For reasons I don't remember I'm not supposed to New kernels due to LP U/I issues.
<NCommander> ScottK, argh. NP I guess
<robert_ancell> dholbach, thanks for the sponsoring
<dholbach> robert_ancell: no worries
<dholbach> robert_ancell: just trying to ease some of seb's workload when he gets back :)
<robert_ancell> dholbach, yeah me too :)
<ojwb> mvo: I've uploaded a new xapian-core package to debian which incorporates that patch upstream and fixes an unrelated bug - should I file a request for a FF exception?
<mvo> ojwb: that would be very nice, I will add my support for the FF exception too when its in LP
<ojwb> ok
<cjwatson> directhex: you poked?
<cjwatson> jcastro: takes ten seconds to hack your local bzr-builder to change the address :)
<directhex> i did. i was going to ask to hear why you're not going to the debian-uk bbq
<cjwatson> directhex: visiting my mother-in-law
<directhex> skipping beer & meat for the MIL? o_o
<cjwatson> it was my wife's idea, not mine ;-)
<davmor2> directhex: that's cause he is sensible you let the MIL down once and you'll never hear the end of it :D
<ogra> did compiz get nasty for anyone else the recent days ?
<bryce> ogra, yes
<ogra> ah, k
<bryce> ogra, the workaround I've found is to downgrade to the mesa and libdrm in the x-retro ppa
<bryce> (or just shut off compiz)
<ogra> well, mine is to use metacity for now :)
<bryce> bug's known and reported upstream
<ogra> oki
<ogra> thanks :)
<taavikko> bryce: did the gdm loop bug went to upstream?
<bryce> taavikko, check the bug report, I always set a watch when upstreaming bugs.
<quadrispro> jerone-mobile: I'm on bug #417533
<ubottu> Launchpad bug 417533 in mediatomb "Add to default config.xml settting to treat mimetype video/x-mkv as mkv" [Undecided,New] https://launchpad.net/bugs/417533
<jerone-mobile> quadrispro, sweet! Thanks!
<quadrispro> argh... ftbfs
<quadrispro> jerone-mobile: done, thank you
<EricInBNE> I want to get involved in the android execution environment development.
<EricInBNE> Is there a git tree anywhere? all i see is this: https://wiki.ubuntu.com/Specs/AndroidExecutionEnvironment
<pochu> NCommander, persia: ^
<ogra> evand, usb-creator neither shows me .img files if i selected them, nor does it see my SD card
<evand> ogra: using 0.2.3?  Can you pastebin me the output of devicekit-disks --dump?
<ogra> http://paste.ubuntu.com/260821/ voila
<evand> ogra: that SD card doesn't have any formatted partitions, correct?
<ogra> yes
<ogra> it had one usb-creator showed before i erased it
<ogra> it doesnt show the device though
<ogra> which is what i need for .img
<evand> ogra: filed as bug 420438 .  I'm on it.
<ubottu> Launchpad bug 420438 in usb-creator "DeviceKit-disks backend does not show a device unless it has a formatted vfat partition" [High,Confirmed] https://launchpad.net/bugs/420438
 * ogra subscribes
<ogra> evand, is that the reason why i dont see the .img file i selected in the top list ?
<ogra> or is that a separate issue ?
<evand> ogra: nope, that's a different bug that I'm about to fix in trunk.
<ogra> ah, cool
 * ogra goes back to use usb-imagewriter for now then :)
<evand> heh, incidentally, usb-creator for Windows would work fine here :)
<ogra> yeah, apparently
<NCommander> stgraber, when you get a chance, can you binNEW linux-mvl-dove please?
<ei-grad> hi all
<NCommander> stgraber, ignore that, ping went to the wrong person
<ei-grad> is there any news about alpha-5 to be released?
<cjwatson> ei-grad: that's next week, not this
<cjwatson> http://wiki.ubuntu.com/KarmicReleaseSchedule
<ei-grad> oh, thanks)
<tkamppeter> pitti, hi
<soren> I have an executable compiled with "-L/some/path -lfoo" so that it'll find /some/path/libfoo.so.0. However, the final executable can't find /some/path/libfoo.so.0 (ldd lists libfoo.so.0 (with no path)) and there's no rpath set. What gives?
<tkamppeter> pitti, hi
<al-maisan> Should I still be seeing MTRR issues like the following after booting the newest kernel:
<al-maisan> [    1.015500] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
<al-maisan> [    1.015571] [drm] MTRR allocation failed.  Graphics performance may suffer.
<al-maisan> This is from dmesg on a karmic machine that runs yesterday's kernel
<al-maisan> Linux Px4 2.6.31-8-generic #28-Ubuntu SMP Thu Aug 27 14:42:57 UTC 2009 x86_64 GNU/Linux
 * soren pulls some more hair out
<soren> Does libtool usually take care of adding rpaths matching the paths passed with -L ?
<liw> hmm... I just upgraded to current karmic, rebooted, and now I have a black screen, no bootup messages; ping responds, ssh does't
<evand> liw: Perhaps remove "quiet splash" from the kernel command line and see what happens?
<liw> ah, second attempt, after power cycling, results in usplash
<evand> weird
<liw> indeed
<jcastro> cjwatson: wow that was easy, I'll add it to the docs
<ogra> mterry, tickle
 * mterry lols
<ogra> mterry, a littel birdy told me you are (partially) supposed to take ccheney's responsibilities in the desktop team ?
<mterry> ogra, I'm swapping with him in terms of teams, but it hasn't really worked out that I took his responsibilities and he mine
<mterry> ogra, but maybe I can help?
<ogra> i'm looking for someone with more knowledge about OO.o than me to attack Bug #417009 since he completely refuses to even touch it
<ubottu> Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,New] https://launchpad.net/bugs/417009
<cjwatson> ogra: mterry swapped into the foundations team rather than desktop, fwiw
<ogra> and we have obligations to ship oo.o
<ogra> cjwatson, oh. chris is foundation ?
<lool> We do ship it but ... it's broken  :)
<cjwatson> chris is desktop
<mterry> cjwatson, ogra: oh right, I swapped with doko!  heh, whoops
 * mterry is confused
<highvoltage> lool: lol
<cjwatson> ogra: tony espy (awe) was the one who swapped with chris
<ogra> lool, just to echo from a different channel: \o/ That's the attitude!
<ogra> :P
<ogra> cjwatson, hrm
<ogra> i wonder who can do any OO.o bugwork then if chris refuses to look at them :/
<ogra> i'm sure awe isnt the guy who knows anything about it
<lool> cjwatson: ogra is stuck on this bug; do you see someone in the foundations or desktop team apart of ccheney and doko who both report being busy who could help unstuck him?
<lool> Or even fix the bug   :-P
<doko> lool: not until Sep 09 (vacation until then)
<ogra> doko, well, such an offer is more than nothing ... we can re-milestone ... happy to test any patches or suggestions, i just dont know where to look or what to do exactly
<ogra> i'd even to all testbuilds myself
<lool> doko: Do enjoy your holidays BTW
<ogra> yeah, dont lurk so much here
<doko> lool: the babbage travels with me ...
<ogra> now thats what i call passion for arm :)
<lool> doko: It's your little armel netbook so to say
<cjwatson> lool: perhaps Rick Spencer can help; OO.o has ceased to be a foundations responsibility in general
<ogra> well, probably worth to bring it up in the release meeting
<lool> cjwatson: k thanks
 * liw reports that he has an ugly, kitten-killing proof-of-concept patch for apt to use zsync for updating Packages lists
<liw> http://files.liw.fi/temp/apt-packages-zsync-diff-01-proof-of-concept.diff for anyone who wants to read it and send me comments via e-mail (I'm done for today and won't be watching irc)
<greg_g> mpt: before I respond to the list, I just want to make sure, is the (current) plan to have a "Price: Free" for every package in the Software Store by default?
<ogra> liw, btw, how about using an rsync wrapper for downloading the .zsync files to minimize traffic ? :)
<mpt> greg_g, for 1.0, yes
<ogra> i noticed that my .iso/.img downloads always need to download 1.4M of .zsync even if the changes in the iso/img are less
<greg_g> mpt: ok, thanks. I'm going to start my email confirming that point, but thanks for the clarification here. :)
<mpt> greg_g, see bug 419295 for more details
<ubottu> Launchpad bug 419295 in software-store ""Price: Free" in every software description sounds cheesy and is redundant!" [Undecided,Confirmed] https://launchpad.net/bugs/419295
<greg_g> mpt: ahh, thanks, again.
<mpt> yw
<liw> ogra, damn you're fast... I didn't have time to close irc :) a) rsync isn't running on mirrors b) the zsync files are on the order of kilobytes for package lists c) when I tested things against ISOs, zsync won (.zsync + file data downloads was less than rsync's total transfer amount)
<ogra> liw, lol
<liw> ogra, however, my iso testing was not extensive, I may have just hit a particularly lucky day to test things; if you have evidence that rsync is better, this needs to be looked at further
<ogra> liw, well, would only make sense for the isos where you actually are above 1MB with the .zsync files
<liw> ogra, and for isos, you should already be able to update the .zsync file with rsync, since cdimage.u.c has rsync server-side; talk to whoever maintains the download script about that :)
<ogra> but go away now ! i didnt read the brackets above, i dont wnat to hold you back from getting your well deserved weekend we can talk next week :)
<liw> ogra, have a good weekend, you deserve it too, please try to avoid doing too much arm-wrestling
<ogra> heh, will try to :)
<ogra> MacSlow, do you have a bug open already for notifications showing up in the vertical center of the screen since the last upgrade ?
<ogra> (started with todays upgrade for me)
<MacSlow> ogra, not really a bug... see https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/419894
<ubottu> Launchpad bug 419894 in notify-osd "notify-osd images appear at the middle right of screen" [Undecided,Invalid]
<MacSlow> ogra, discussion regarding this happens on the ayatana mailing list (or also here in #ayatana)
<ogra> i dont want to discuss it :P i would just like to be able to read my stuff without having anything that covers the text :)
<ogra> but i see that opinion stated on the bug already ... i would just add "me too" noise
<james_w> I've just seeded kerneloops-daemon in desktop-common and server-ship
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=daemon
<james_w> should I regenerate all the meta packages now, or is that something that we tend to batch up?
<ScottK> ogra: Me too noise is probably good.  I understand the response so far has been that not very many people complained, so it was probably OK.
<cjwatson> ogra: does d-i's dove.cfg need to go to -202? I see that's in NEW
<ogra> yeah
<ogra> and the platform seed
<ogra> NCommander, was supposed to ping me once it's out of NEW
<cjwatson> I'll take care of it
<ogra> but feel free to take it
<ogra> cool
<ogra> thanks
<LordMetroid> I get hash sum errors for karmic alpha 4 main, and universe repositories from Sweden
<ogra> cjwatson, any idea how to avoid that extra work for you or anyone would be appreciated btw, with the additional abi numbers for armel it starts to get messy
<cjwatson> ogra: don't use different abi numbers :)
<cjwatson> other than that, not really
<ogra> heh, to late i guess
<cjwatson> LordMetroid: more often than not this is caused by intercepting proxies between you and the mirror
<LordMetroid> ok
<cjwatson> LordMetroid: wget --no-cache on the relevant URLs may clear it
<LordMetroid> I'll try that
<ebroder> Any archive admins around? Bug #368471 has been tested but stuck in jaunty-proposed since May
<ubottu> Launchpad bug 368471 in openafs "openafs-modules-dkms should depend on dkms" [Undecided,In progress] https://launchpad.net/bugs/368471
<cjwatson> ogra: processed through NEW. I'll have to upload d-i before it's made it into the archive, so I expect it'll fail to build, but that's because I'm going to have to leave fairly on-time today - if you need it, feel free to hit retry once it's ready
<ogra> cjwatson, will do, i dont think its urgent atm
<cjwatson> oh my, why is the current d-i .tar.gz 49MB
<cjwatson> ogra: plz not to be storing movies in d-i
<ogra> damned, you catched me :P
<ogra> i didnt put anything into it that i'm aware of
<cjwatson> oh, you uploaded the .bzr too
<cjwatson> debdiff's always a good idea, it catches this sort of thing
<cjwatson> d-i's .bzr is massive because that branch used to include the installation guide (with all translations) too
<ogra> oh, crap
<ogra> yeah, i didnt export
<ogra> sorry
<cjwatson> I never export, I just use debuild
<cjwatson> rather, debuild -i -I
<cjwatson> ebroder: nobody tagged it verification-done ...
<cjwatson> ebroder: and Steve said "it seems to me that the fix is incomplete"
<ebroder> Oh, huh - I missed that
<cjwatson> ebroder: so I'm not convinced it ought to be promoted to -updates just yet
 * ebroder nods
<ebroder> I guess I'll get back to you, then
<ebroder> cjwatson: Thanks
<slangasek> lool: no reason to use the -meeting channel for side discussions
<lool> slangasek: k
<slangasek> lool: manifest> if you're suggesting replacing the 'image type' with a value that doesn't correspond to what we use in the publisher, yes, I would object
<lool> slangasek: Ok; if you're actually using the subtypes then forget about it  :)
<lool> I thought it was some high level memo of the type of image d-i / ubiquity or live / ami etc.
<slangasek> lool: the object is to be able to hook this manifest into the publishing itself
<lool> woah the wiki page?
<slangasek> well, I would've been happy to have it other than in the wiki, but mdz wanted a Manifest in the wiki for other reasons
<lool> Well ok
<lool> wiki would better be up at the time of release  :)
<lool> slangasek: Ok well that's all I had then, thanks
<slangasek> tkamppeter: is cups Recommends: cups-ppdc the right relationship?  what needs cups-ppdc during normal operation?  (it's a small package, but I'm reviewing CD diffs, so might as well ask)
<slangasek> lool: I can pull it down in advance and cache it :)
<ogra> lool, meh, i forgot that export doesnt work for init-top scripts :(
<ogra> i need to find another hack for mxcfb
<lool> ogra: You could write an usplash.conf file?
 * lool kicks himself for suggesting awful things to ogra
<ogra> indeed i could but that would result in a lot of extra code ... checking there isnt one, checking its empty if there is one etc
<ogra> i liked the three line hack i had before more :/
<tkamppeter> slangasek: These are only tools for PPD manipulation, we can move them to Suggests:.
 * ogra decides to ponder more about that over the weekend and call it a day now
<lool> Keybuk: hey how much do we care about bugs due to not using an initrd?
<lool> Keybuk: An ARM person reported me that :Apparently rc-sysinit.conf parses /proc/cmdline for "-b|emergency", "0|1|2|3|4|5|6|s|S" and "-s|single", but /proc isn't mounted at this stage if there was no initrd."
<soren> Could someone from ubuntu-release team take a peek at bug 420644? I'd /really/ like to have aworking eucalyptus before I leave for the weekend.
<ubottu> Launchpad bug 420644 in rampart "[FFe] Update rampart to 1.3.0" [Undecided,New] https://launchpad.net/bugs/420644
<mdz> slangasek, if you want to put the manifest in bazaar or something, it's fine with me.  I just want it to be accessible, not behind the scene
<mdz> s
<slangasek> mdz: ok, will think about that :)
<Turl> hi fta, may I PM you?
<soren> slangasek: Is that something you could look at? ^^
<maxb> LP 406245 has been pending sponsorship for some time now. Is there possibly a kind core-dev who could be enticed to take a look at it?
<ubottu> Launchpad bug 406245 in subversion "Merge subversion 1.6.5dfsg-1 (main) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/406245
<mathiaz> kees: what's the state of moving puppet to main?
<kees> mathiaz: last I looked, it had a giant list of things to fix.  zul was working on it, IIRC.
<zul> yeah its getting there
<mathiaz> kees: do you mean that the puppet MIR wiki page is the biggest wiki page of the world?
<kees> mathiaz: uhm, no?  /me looks around, confused.
<zul> mathiaz: the only thing that is remaining is debian bug 525852
<ubottu> Debian bug 525852 in puppet "postrm will remove files owned by puppetmaster on purge" [Important,Open] http://bugs.debian.org/525852
<mathiaz> kees: your usage of the term giant made me picture such a wiki page
<kees> mathiaz: heh
<fta> Turl, sure
<mathiaz> zul: are you planning to push these changes to the Debian maintainer and get their input on it?
<mathiaz> zul: IIRC the debian maintainer are pretty keen on having puppet in sync between Debian and Ubuntu.
<zul> mathiaz: thats the goal
<zul> mathiaz: but I dont think there is an easy fix for the postrm bug
<soren> slangasek: Do you think it's something you could get to within the next couple of hours?
<greg_g> can someone moderate my email to -devel (from greg@grossmeier.net)? Thanks!
<slangasek> tkamppeter: right, I think Suggests: is the correct relationship; do you want a bug report?
<slangasek> soren: sorry, what is it you were pointing me to?
<soren> slangasek: heh.. 2 sec.
<soren> 17:00:27 < soren> Could someone from ubuntu-release team take a peek at bug 420644? I'd /really/ like to have aworking eucalyptus before I leave for the weekend.
<ubottu> Launchpad bug 420644 in rampart "[FFe] Update rampart to 1.3.0" [Undecided,New] https://launchpad.net/bugs/420644
<slangasek> ok
<slangasek> yes, pulling it up now
<soren> Fantastic, thank you.
<penguin42> does anyone know of something that documents the way hibernate/suspend works from the desktop? In the sense of how things like screensavers should know to lock and how I might hook the same thing to unmount a disc or anything else?
<LordMetroid> Why are there no icons whatsoever in the alpha 4 release?
<penguin42> LordMetroid: On the menus?
<LordMetroid> Amongst other places
<penguin42> LordMetroid: They've been turned off as a UI feature - they can be turned back on
<penguin42> LordMetroid: System->preferences->Appearance has a 'Show icons in menus'
<LordMetroid> The ubuntu one cloud upload/download arrows also do not exist and on the gnome-applet-sus it is not an off button anymore
<slangasek> mathiaz: you didn't subscribe ubuntu-release to bug #419515 :/
<ubottu> Launchpad bug 419515 in openldap "[FFe] Update to 2.4.18" [Undecided,New] https://launchpad.net/bugs/419515
<penguin42> LordMetroid: Ah the sus button I think is a straight bug; the others may be bug 407621
<ubottu> Launchpad bug 407621 in libgnome "(design decision) Icons missing from context menu , dialogue buttons , firefox bookmark favicons" [Wishlist,New] https://launchpad.net/bugs/407621
<slangasek> kenvandine: bug #417964 was marked in the desktop team release status as 'fixed last week'; the Ubuntu task is still open?
<ubottu> Launchpad bug 417964 in devicekit-disks "Authentication always required to unmount media" [High,Confirmed] https://launchpad.net/bugs/417964
<slangasek> mm, reopened after closure
<soren> slangasek: Thanks for the ack.
<kenvandine> slangasek, yeah...
<kenvandine> upstream bug must have been fixed though
<kenvandine> it's assigned to pitti, so he will see it sunday
<slangasek> kenvandine: ok
<mathiaz> slangasek: hm - I though I'd subscribe ubuntu-release once the FFe would be ready
<tkamppeter> slangasek: cups-ppdc issue is fixed in the Debian BZR repo of CUPS now, so it will go into our next CUPS package.
<mathiaz> slangasek: right now it doesn't have all the content needed for a proper FFe
<mathiaz> slangasek: as I don't have all the infomration myself
<slangasek> mathiaz: ok... the bug was brought up in this morning's release meeting as "bug filed", so I chased it down
<slangasek> mathiaz: ... and then I marked it incomplete anyway for the reasons we both know... sorry :)
<sebner> slangasek: I suppose meebey talked to you?
<slangasek> sebner: yes; I have yet to follow up with the ftp team
<sebner> slangasek: what's the actual consens? He wasn't that happy with your stuff
<slangasek> sebner: <shrug> "consensus" is not relevant; complying with the license is
<sebner> slangasek: IIRC, he is the same opinion as me. People can read the warranty stuff themselves when reading the full GPL .P
<mdke> cjwatson: can you advise whether bug 415108 should also be fixed in released versions of Ubuntu?
<ubottu> Launchpad bug 415108 in installation-guide "Online Installation Guide contains link to page with pornography" [High,Fix released] https://launchpad.net/bugs/415108
<J_P> Anyone know if are there a effort to port ubuntu to Nokia N900?
<sistpoty> ogra: we need better buildds, or you can't have mplayer for armel: S:29: Error: selected processor does not support `pld [r1]'
<sistpoty> ogra: (from http://launchpadlibrarian.net/30948228/buildlog_ubuntu-karmic-armel.mplayer_2%3A1.0~rc3%2Bsvn20090426-1ubuntu5_FAILEDTOBUILD.txt.gz), and I don't have the slightest clue about armel :(
<bluefoxicy> Hey guys, awesome idea for a DOS against Firefox
<bluefoxicy> configure a Web server to continuously request authentication.
<bluefoxicy> The box pops up, you can't click tabs
<bluefoxicy> configure it to always respond with an HTTP auth request so when you click ok/cancel it just pops up again
<bluefoxicy> and there you go, browser is frozen.
<slangasek> except that it doesn't work that way
<jdstrand> kees: ok, sun-java5 for dapper/hardy and sun-java6 for hardy/jaunty are approved and pending in -proposed
<kees> jdstrand: thx!
<jdstrand> kees: and appropriate bugs are all updated
<jdstrand> kees: sure!
<slangasek> jdstrand: hrm?  did someone from motu-sru approve those?
<bryce> slangasek, do I need a FFe for updating git snapshots of -ati from our current git snapshot?
<jdstrand> slangasek: this is a new policy: https://wiki.ubuntu.com/StableReleaseUpdates#sun-java*
<jdstrand> slangasek: we were told to operate as if that has been approved (these are security releated)
<bryce> slangasek, for -ati kms we've planned to be doing updates of the git snapshot through up to their release
<cody-somerville> doko, Is the Sun java 5 plugin not available in karmic? I only see java 6 plugin.
<jdstrand> slangasek: and it is expected to be voted on in the next TB meeting
<jdstrand> (voted on and approved)
<slangasek> bryce: if there's going to be non-bugfix changes, yes; a single umbrella FFe would be enough, though
<slangasek> jdstrand: ah; approved by pitti then, ok
<jdstrand> slangasek: well, pitti isn't who directed us
<slangasek> jdstrand: though if "security related" were the rationale, wouldn't it rightfully go to -security first?
<jdstrand> slangasek: but since they are security related, I took that on
<slangasek> jdstrand: hrm, who did? pitti is who edited the wiki page
<jdstrand> slangasek: mdz speaking with doko and security@
<slangasek> ok
<jdstrand> slangasek: the SRU page says go to use -proposed for these, so I did even though they *may* ultimately go to -security
<jdstrand> slangasek: they need testing so -proposed is appropriate
<slangasek> ok
<bryce> slangasek, bug 420803
<ubottu> Launchpad bug 420803 in xserver-xorg-video-ati "FFe for updating -ati/mesa/libdrm git snapshots until their individual releases" [Wishlist,New] https://launchpad.net/bugs/420803
<slangasek> bryce: thanks, will look
<bryce> slangasek, heh, and of course the libdrm release announcement just now hits my inbox ;-)
 * slangasek laughs
#ubuntu-devel 2009-08-29
<lordmetroid> bug 420873
<ubottu> Launchpad bug 420873 in ubuntu "Eclipse is missing required dependencies and will not install" [Undecided,New] https://launchpad.net/bugs/420873
<lordmetroid> bug 1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<lordmetroid> bug 420889
<ubottu> Launchpad bug 420889 in ubuntu "Nautilus do not like shutting down" [Undecided,New] https://launchpad.net/bugs/420889
<ScottK> lordmetroid: There's really no point in tossing random bugs into the channel.  People likely to work on a particular package likely get the bugmail too.
<lordmetroid> I see, cause I toss UbuntuOne bugs into the UbuntuOne channel and they seemed to like it so I thought I would do the same here
<lordmetroid> Thanks for clearing that up
<ScottK> We get a few more than they do.
<lordmetroid> I understand
<ScottK> We have an entire IRC channel for this if people want it.
<TheSteve0>  I keep trying to download the dailys of karmic and it can't get past 100 megs before bombing out
<TheSteve0> are there torrents or somewhere else other than cdimage to download nightly images?
<sbeattie> TheSteve0: there are torrent files published alongside of the isos and you can also use rsync/zsync/wget -c to continue an aborted download.
<TheSteve0> sbeattie: I do not see the torrents listed here http://cdimage.ubuntu.com/daily/20090828/
<TheSteve0> where should I look for the seeds
<wgrant> TheSteve0: Do you want the alternate CD, or the desktop CD?
<wgrant> The former is probably easier to get.
<TheSteve0> wgrant - I don't care - I just want to use the nightlies for karmic
<TheSteve0> I am nuking my laptop and figure alpha 5 is close enough that I should just go with nightlies
<wgrant> TheSteve0: Grab the .jigdo and .template for the CD you want from that page, heeding the warnings in red at the top.
<TheSteve0> wgrant: and then what do I do?
<wgrant> Then 'jigdo-lite whateveritis.jigdo'. That will try to grab all the files from a mirror, which should be faster than cdimage and more likely to work than a torrent.
<TheSteve0> wgrant: rock - thanks
<wgrant> TheSteve0: Some files might no longer be present on the mirrors. If jigdo tells you that, finish the image off by rsyncing from cdimage.
<mdke> kees: I saw the slight edit war on https://help.ubuntu.com/community/RootSudo - I'd say that the best option is to revert it again if you aren't convinced by the user's arguments and contact him (cc ubuntu-doc@) to explain
<lifeless> whats current best practice for automake* as a build-dep
<lifeless> just a versioned dep on it?
<kees> mdke: yup, though given it's always on a timed out wiki lock, I wonder if he hasn't realized it yet.  was going to email him anyway.
<kees> superm1: so... fglrx-installer and nvidia-173 didn't work at all on karmic to start with?  :P
<mdke> kees: cheers
<manuel> hi
<manuel> i have a problem with hal when i use my laptopp for 1 or 2 hours hal is using my hdd to 100 percent and i cant work anymore
<manuel> i tracked it down to hal-acl-tool --reconfigure
<manuel> this command is called every milisecond or so and cause the hdd spin
<manuel> why and how can i stop this?
<joaopinto> manuel, have you checked launchpad for bug reports  ? If not please report it
<maxb> Hi, LP 406245 is an upstream update that's been waiting for main-sponsorship for some time. It was filed before FeatureFreeze, missed FeatureFreeze whilst waiting for sponsorship, and now has an approved FFe. Is there anything appropriate to do to draw sponsors attention to it?
<ubottu> Launchpad bug 406245 in subversion "Merge subversion 1.6.5dfsg-1 (main) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/406245
<manuel> how could i search efectiflyy after my bug?
<joaopinto> manuel, https://bugs.launchpad.net/, if you can't find it, report it
<manuel> ok thanks
<larsivi> I get following errors when upgrading today, in the configuration of dkms
<larsivi> /etc/init.d/dkms_autoinstaller: line 1: syntax error near unexpected token `)'
<larsivi> /etc/init.d/dkms_autoinstaller: line 1: `invalid GC parameter) 13'
<larsivi> a warning says it is missing LSB information
<manuel> what should be in the bugreport?
<larsivi> manuel: good question ...
<manuel> i will pastebin it here so you can have a look
<manuel> larsivi: can i attach a file on the bug report?
<manuel> http://pastebin.org/13077
<manuel> https://bugs.launchpad.net/ubuntu/+source/hal/+bug/421051
<ubottu> Launchpad bug 421051 in hal "hal-acl-tool --reconfigure bother hdd -> work impossible" [Undecided,New]
<Q-FUNK> hi! I'm wondering if there's any plan to fix GDM to be able to use themes for gdmgreeter again?
<Lutin> is requestsync known to be broken in karmic ?
<Q-FUNK> Lutin: in what way?
<Lutin> Q-FUNK: http://pastebin.ca/1547065
<Q-FUNK> odd
<Q-FUNK> I was gonna say that the only breakage I've seen is when Debian's log server hasn't been updated, but what you've pasted is Python crashing.
<Q-FUNK> mind you, I've had a lot of other Python apps crashing in Karmic, but not requestsync
<Q-FUNK> still, I'd venture that it's cuased by yet another generic breakage in Karmic's Python
<wgrant> No.
<wgrant> It's the launchpadlib split.
<Lutin> oh, and when trying to launch it from within a schroot I get this: http://pastebin.ca/1547069
<Q-FUNK> wgrant: ah?  so requestsync needs to have its depends adjusted?
<wgrant> A couple of days ago we got the new launchpadlib, where most of the code now lives in lazr.restfulclient.
<wgrant> Q-FUNK: No - ubuntu-dev-tools code needs to be fixed to work with the new one.
<Q-FUNK> wgrant: ah,ok. it's a known issue then.
<wgrant> Lutin: That's caused by an incompatible version combination of launchpadlib, lazr.restfulclient and wadllib. How'd you install them>?
<wgrant> Q-FUNK: I don't think it is.
<wgrant> Q-FUNK: I hadn't seen it mentioned before now.
<Lutin> wgrant: huh, "apt-get install ubuntu-dev-toolsÃ©
<Lutin> s/Ã©/"
<Q-FUNK> wgrant: ok, can you file a bug for it?
<wgrant> Lutin: Hm, odd.
<wgrant> Q-FUNK: I can't reproduce right now, so I'd rather somebody who can did.
<Q-FUNK> Lutin: would you file the bug, then, please? include wgrant's explanation about what causes it
<Lutin> sure
<Q-FUNK> thanks!
<Laney> Installed-Size: [-10024-] {+8728+}
<Laney> anyone want to save some CD space? ;)
<hyperair> ooh O_o
<Abdullah9> any one can help me ?
<Abdullah9> any 1?
<ldlework_> YokoZar: are you around?
<superm1> kees, no idea on nvidia-173, but fglrx is getting support from AMD later in the cycle. you'll be better off evaluating your change on jaunty until that happens I believe
<kees> superm1: okay, noted.  thanks!
<Rocket2DMn> kees, this RootSudo stuff is going to turn into a digital shouting match
<kees> Rocket2DMn: yeah, I've emailed him via LP now.  I figure the docs team plus the security team is more than enough weight.  :P
<Rocket2DMn> kees, I had hoped my note would be enough, but I guess not.  I pinged mdke in the doc team channel to get his feedback as he is also a CC member, but he hasn't responded yet.
<Rocket2DMn> kees, for the record I don't really like the idea of that info being on that page, I know we don't allow it on the forums, but I was overruled by the doc team and matthew, so I will support that decision
<kees> Rocket2DMn: yeah, mdke and I chatted somewhere in scroll-back there -- he asked me to email him.
<Rocket2DMn> I think I was offline when you chatted with him
<kees> Rocket2DMn: ah, didn't know about the ban on that in the forums.
<kees> I think it's useful information especially for server admins with an existing fixed admin process in a heterogeous data center.
<kees> strictly speaking, it's fundamentally no more or less secure -- it's a usability characteristic, and people can get themselves into odd situations on the desktop if they actively log in as the root user.
<Rocket2DMn> yeah, there is info in the serverguide about enabling root on servers.  I think the community docs are primarily for desktop users though, and not those in a managed environment
<kees> You have a fair point.  Perhaps link to the server docs then?
<Rocket2DMn> however, I'm not here to argue the point, I'll back the decision that the doc team and security team reach.  I made my argument and it was heard, that is enough
<Nafallo> man sudo_root <-- both desktop and server have this one AFAIK
<kees> Rocket2DMn: sure, yeah, I didn't know about the forum ban on it.  regardless, thanks for watching the page.  :)
<kees> Nafallo: hunh, good point.  :)
<Rocket2DMn> hehe, "rtm" isn't very useful on the wiki
<kees> it demonstrates parity between on-system docs and wiki docs.  :)
<Rocket2DMn> yeah kees , it's no problem, the situation is above me.  Now I just watch it unfold :)
<kees> heh, cool.  I gotta run...
<Rocket2DMn> ok, cool, thanks kees
#ubuntu-devel 2009-08-30
<Flakeparadigm> Hello, I have a question about something in Karmic.
<sololxy>  hi,how can find the source code of getty? i just find the source of agetty. i guese that is the code.But, i want to know  whether someone change the name getty to agetty, and when and how he or she change it. i check the utli-linux source, but in configure.am and Makefile.am, there is no such information. can anyone help me? thx
<Rocket2DMn> lol kees , i told you so :)  That guys changed the page back
<kees> Rocket2DMn: I'm gonna wait until monday and talk to mdke about it.  "man sudo_root" is not as easily changed.  ;)
<Rocket2DMn> kedars, ok, I'm curious to see what happens with this
<Rocket2DMn> kees, ^
<kees> me too; though I guess I don't really have a vested interest in it -- I just hate to see useful information disappear.  but if that's been the determination of the forums, I can see the point of removing it.  I don't believe it to be "insecure", though.  that's just silly -- sudo in ubuntu is one-credential-gets-you-root anyway, so no different realy.
<Rocket2DMn> well, the debate is deeper than that, for instance, you can track sudo commands a lot easier than commands simply run as root
<Rocket2DMn> but again, not here to discuss whether or not it should be there.  The point is that this guy won't listen to decisions made by official ubuntu teams
<Dyllan> Hi all. I have written a script designed specifically for my company environemnt and would like to make the script available in a .deb file for easy installation by the staff. The script needs to be dumped into /usr/bin and in programs menu, all info i have found for making a .deb is too complicated for my needs, any ideas? - thanks
<pitti> Good morning
<pitti> slangasek, jdstrand: I didn't take a look at the sun-java* stuff yet, but will do; as per the recent discussion, they should be generally ok for hardy
<Dyllan> When i install my custom .deb file, everything install and works 100%, however the gdebi app does not show the 'Re-Install' option or 'Installed' it only shows 'Install' so it's like it doesnt recognise it is installed, any ideas, do i have to add something to my control file? - thnkas
<lifeless> Dyllan: to reinstall you need it listed in the repositories I think
<pitti> Dyllan: "install" should just work, though
<pitti> Dyllan: I don't think gdebi even has more complex UI cases than simply "install this .deb"
<pitti> it's just a gui wrapper for sudo dpkg -i foo.deb
<lifeless> pitti: I inferred 'gdebi app' as 'synaptic :P
<Dyllan> Understood, so it is normal that i cannot 'Search' for the package in Snyaptic either? It IS there, but i have to scroll alphabetically do find it. This is normal behavious for both the gdebi and synaptic?
<lifeless> Dyllan: the search works on the apt list of packages, not the dpkg list of installed packages.
<lifeless> Dyllan: so yes, this is normal
<Dyllan> I can settle for the fact that it doesnt get treated like a .deb in the repo, just want to make sure im doing everything correctly and that its ubuntu's way of working not something i have done wrong/
<lifeless> but arguably a bug in the xapian search index creation/hooks.
<Dyllan> Ok, excellent.
<Dyllan> makes sense.
<Dyllan> now i gotta try and get it into the repo ;P
<LCID_Fire> Hello, I get a warning on a changed ABI when I try to build a kernelpackage from source. Can someone explain what the correct way to handle the ABI is?
<sistpoty> statik: ubuntuone-client debdiff uploaded, thanks. please merge into bzr.
<svarg> hi
<svarg> why isnt the ubuntu release scheduled for october not have a long term support release?
<pitti> svarg: 10.04 will most probably be LTS
<Laney> why should it?
<Laney> ;)
<pitti> because we planned it that way :)
<svarg> pitti but i'd been hearing earlier that 9.10 was to be LTS :(
<pitti> svarg: not from anywhere officially for sure
<pitti> no, 9.10 will definitively not be LTS
<pitti> 9.10 (karmic) is a "latest crack and intrusive changes" release
<svarg> before 9.04 was released, 9.10 was supposed to be LTS
<pitti> no, it wasn't
<pitti> where did you see this?
<svarg> erm ok
<svarg> good i came in here
<svarg> friend of mine
<sebner> pitti: still a 16 hour day? I don't want to annoy but hardware issues are annoying :\
<pitti> it's 2nd on my list now
<svarg> thakns for the info pitti
<Amaranth> From the sound of it's still a bit up in the air whether or not 10.04 will be LTS too
<pitti> Amaranth: it'll be official in less than a month
<pitti> Mark traditionally introduces the new release name, theme, and LTSness around beta time
<sistpoty> ludicrous llama :)
<pitti> lazy lobster!
<sistpoty> heh
<pitti> lamenting lizard?
<sistpoty> lusty leopard?
<pitti> sebner: the workaround with moving the udev rules aside should still work, though?
<sebner> pitti: sure
<svarg> pitti: was under the impression that it was to be. which is why i hadnt upgraded my comp at home
<svarg> guess i could now now that this is cleared
<svarg> nyways, found an alternative so its ok
<Madkiss> hi folks
<Madkiss> just a little question; when I install Kubuntu 9.10 alpha, I get a very, very boring KDE4 standard theme after the installation; does anybody in here know whether this is the one that is going to ship with 9.10 or will there be some graphical tuning?
<ScottK> Madkiss: Kubuntu tries to stick to upstream KDE pretty closely.  There was a plan to do some themeing work for this development cycle, but it didn't get done due to lack of volunteers to do the work.
<Madkiss> I see, so 9.10 is indeed going to ship with the KDE 4.2 standard theme?
<sebner> ScottK: You're free to look at a FTBFS (I'm not into kde/qt stuff), seems to be a libarts issue. Source package is twinkle
<ScottK> Madkiss: 4.3, not 4.2, but yes.
<ScottK> sebner: Thanks.
<Madkiss> ohmigad.
<Madkiss> ;-)
<sebner> ScottK: O_o Thanks for what?
<ScottK> sebner: For pointing it out.
<ScottK> Madkiss: It takes people to do the work.  Please join #kubuntu-devel if you're interested in being part of the solution.
<sebner> ScottK: heh, we can thank each other when it's fixed :)
<Madkiss> ScottK: well. Given that I have maintained Qt3 for like two years or some such for Debian, I am at least not scared to the shit when seeing KDE/Qt-Stuff ... might be a good idea indeed
<ScottK> sebner: If you wanted to look at vtk, that needs some love too.
<ScottK> Madkiss: We'd love to have the help.
<sebner> ScottK: what kind of love? Update to 5.4?
<ScottK> sebner: Fix the build failures
<sebner> ScottK: heh, you say that so easy. (Even so I only support i386 in my heart :P) I'll do my best
<ScottK> I didn't say it was easy.
<ScottK> sebner: There is a patch in Debian bts that may be relevant for the armel build failure.
<ScottK> The rest, dunno.
<sebner> ScottK: ah thanks for the hint. I'll take a look
<sebner> ScottK: btw, some info what I've done with twinkle. Evidently it needs libarts-dev b-d so I tried with --without-arts but without a result :(
<ScottK> OK.
<ScottK> sebner: It's a voip client.  How much use will it be with no sound support?
<sebner> ScottK: good point but more use than non-installable though
<ScottK> I was thinking about removal.
<sebner> ScottK: yeah, but that's more like the worst case aka the "last way"
<ScottK> I know we aren't going to rewrite it to provide sound without arts.
<ScottK> So I'll say again, what's the point in a voip client that has no sound?
<sebner> ScottK: afaik it has 2 ways for sound?!
<ScottK> OK
<sebner> ScottK: I'm only wondering why it built in Debian. They still have libarts but it was not pulled in iirc (looking at the buildlog)
<aladin_> hello, i have a big problem.. someone can tell to me the equivalent to "dpkg --force all" in apt?
<maxb> From memory it's something along the lines of -oDPkg::Options::=--force-all but NEVER USE --force-all
<maxb> There is always a more specific option you should be using instead
<aladin_> [15:45] <aladin_> dpkg: error processing /var/cache/apt/archives/linux-image-2.6.30.5_2.6.30.5-10.00.Custom_i386.deb (--unpack):  trying to overwrite `/lib/firmware/whiteheat.fw', which is also in package linux-image-2.6.29.4 dpkg-deb: subprocess paste killed by signal (Broken pipe) [15:46] <aladin_> if i use dpkg -i --force all package.deb work all fine [15:46] <aladin_> but if i use apt-get -f install package.deb do not w
<sebner> ScottK: I'm wondering where I can test the armel fix as I don't want to upload several times into the archive
<ScottK> sebner: Talk to NCommander.
<sebner> ScottK: Aye Aye, Sir
<aladin_> ScottK-desktop:
<aladin_> ScottK: able to help me ?
<ScottK> aladin_: No
<maxb> devicekit-power still fails to notice that I'm on battery unless I am when I boot - this has been the case for several alphas now. Is there anything I can/should be doing to ensure the issue doesn't slip and persist into Karmic release?
<highvoltage> hey, I'm working on a man page for do-release-upgrade. It's --help says that you can use --frontend to choose a frontend, but what are they options?
<Hobbsee> highvoltage: gtk and qt, i think
<Hobbsee> not sure of syntax, etc
<Dyllan> hi all.
<Dyllan> Is there a way to install pre-deps from a .deb i have created? I specify the pre.dep in the control file, but gdebi just fails to install and complains that the pre-dep is needed which makes perfect sense, but i would like for it to be installed automatically if possible?
<ScottK> sebner: Twinkle fixed.  'twas a build-dep problem.  Nothing to do with arts.
<sebner> ScottK: O_o, what's the missing b-d?
<ScottK> sebner: libccrtp needed a rebuild.
<sebner> ScottK: wth O_o
<sebner> ScottK: crazy. anyways, thx for your help. If I stumble over a kde/qt package that not build can I talk to you again?
<ScottK> sebner: Sure or just ask in #kubuntu-devel.
<sebner> great :)
<Dyllan> Is there a way to install pre-deps from a .deb i have created? I specify the pre.dep in the control file, but gdebi just fails to install and complains that the pre-dep is needed which makes perfect sense, but i would like for it to be installed automatically if possible?
<joaopinto> Dyllan, does dpkg -i fail ?
<Dyllan> joaopinto: Well I am trying to avoid doing anything from the command line, this is a custom .deb that will be downloaded by others, non power users, who i want to be able to just download, double-click on .deb and it installs with dependencies.
<joaopinto> anyway, probably #ubuntu-motu is a better place to ask
<ulaas> irc through empathy... Hmm i must be going crazy.... Anyway, my notifications popup vertically in the middle of my screen. who to blame?
<pitti> ulaas: please report a bug against notify-osd
<ion> Itâs supposed to be a feature, according to the changelog.
<ion> No, i donât like it either. :-P
<ulaas> pitti, is there a way to pop it up with a debug message just to be sure?
<pitti> bwah, I just got it, too now
<pitti> I never saw it before
<pitti> ulaas: notify-send in the libnotify-bin package
<pitti> must have gotten a new version recently, too
<pitti> this can't be deliberate, can it?
<ulaas> pitti, please not
<ion> /usr/share/doc/notify-osd/changelog.Debian.gz
<ion> Itâs a deliberate mistake, just like the blurry font rendering that has been the default in Ubuntu for a while. :-P
<sebner> pitti: heh, and now my specific problem? Though my strace etc output looks nearly the same as the othres
<sebner> *pthers
<sebner> *others
<sebner> arghs
<ion> You just dereferenced a null pointer.
<ScottK> pitti: The middle pop-up is by design.
<ScottK> Lots of 'discussion' on the ayatana ML about it.
<maxb> !info bzrtools karmic
<ubottu> bzrtools (source: bzrtools): Collection of tools for bzr. In component main, is optional. Version 1.18.0-0ubuntu1 (karmic), package size 61 kB, installed size 416 kB
<maxb> ^^^ Unfortunately, that appears to actually contain bzrtools 2.0.0
<ScottK> NCommander or pitti: I'd appreciate it if you'd rescore libccrtp ahead of the other Universe stuff as it needs to get built and published on ia64/sparc before twinkle or twinkle will fail.
<wgrant> ScottK: Argh, what? It looks ridiculous.
<ScottK> wgrant: Which looks ridiculous?
<wgrant> ScottK: The not-quite-middle-aligned notify-osd.
<ScottK> wgrant: Oh.  Right.  Well that's part of the benifit of using Ubuntu, you get most of the work the design team does.
#ubuntu-devel 2010-08-30
<didrocks> good morning
<dholbach> good morning
<G> dholbach: hey
<G> dholbach: you are part of the Server Team right?
<dholbach> g: no, I'm not
<G> oh okay :)
<G> dholbach: sorry, I'd just thought your name had come up in the meeting minutes
<dholbach> I'd be a bit surprised - I hope they didn't assign me work while I wasn't there :)
<Besogon> hi. Could you tell me how a package deletes menu files as my package don't delete them
<Besogon> hey
<Besogon> What rule does tell to the debuilt how exactly my packaged shoul be removed
<Besogon> should
<G> dholbach: haha sorry, obviously I've got names confused (or a more possible case, I am completely confused about everything :)
<dholbach> G: no worries :)
<pitti> Good morning
<geser> Guten Morgen pitti
<pitti> mr_pouit: great to hear, thanks
<pitti> hey geser, good morning
<Besogon> people, to delete menu files I should write postrm file, will I?
<Besogon> ÑÑÐ´Ð·
<Besogon> help
<Besogon> need advise about build deb. postrm script
<Besogon> No one alive
<pitti> Besogon: you don't need to remove files from a package in maintainer scripts
<pitti> uninstalling a package will remove all files that it ships
<OdyX> pitti: Hi, just saw your comments on usb-modeswitch. Thanks for the investigation, I wrongly assumed udev versions in Debian and Ubuntu were close.
<OdyX> pitti: is it possible to get a fix in udev by adopting Debian's patch or would you prefer to get an Ubuntu-specifically updated usb-modeswitch ?
<Besogon> pitti, I'm trying to build a package and install some menu file
<Besogon> also as deinstall them
<Besogon> the deb package can install menu files using makefile but not uninstall them
<Besogon> which script should I use to do that
<azeem_> 10:47 < pitti> uninstalling a package will remove all files that it ships
<Besogon> pitti,
<Besogon> postrm or prerm
<azeem_> 10:47 < pitti> Besogon: you don't need to remove files from a package in maintainer scripts
<pitti> OdyX: both sid and Maverick have udev 161
<Besogon> azeem_, so how can I do that in other way. *.menu and *.desktop files aren't deleted bu dpkg.
<pitti> OdyX: how does Debian modify udev to make this work?
<OdyX> pitti: there is a patch that adds that /lib/udev/hotplug.functions
<azeem_> Besogon: then this would be a bug in dpkg
<OdyX> (in Debian)
<azeem_> Besogon: they are shipped in the .deb?
<pitti> OdyX: ah, I see; that's what provides wait_for_file()
<OdyX> exactly
<tkamppeter> pitti, hi
<Besogon> azeem_, no. But they are being installed indeed. I used a manual https://wiki.ubuntu.com/PackagingGuide/Complete
<azeem_> how are they installed?
<pitti> hey tkamppeter, how are you?
<Besogon> azeem_, debuild utility
<azeem_> debuild builds .debs
<Besogon> azeem_, give me a secon
<Besogon> d
<azeem_> either they are shipped in the .deb, or they are somehow installed at install time
<tkamppeter> pitti, fine.
<OdyX> pitti: I am considering "conditional patching" based on dpkg-vendor, but a fix in udev is cleaner (for me) :-)
<azeem_> Besogon: maybe they are not shipped, and the files you have on your harddisk are from a previous manual install
<pitti> OdyX: how does upstream usb-modeswitch handle that? hotplug.functions isn't something that upstream could rely on?
<OdyX> pitti: it does not, it uses the wait_for_file function "inline"
<pitti> OdyX: and you don't want to just use that in usb-modeswitch?
<OdyX> pitti: I am at fault on that bug, because I wanted to play smart and avoid code duplication by using Debian's functions.
<OdyX> pitti: nah, on Debian it's a code duplication.
<pitti> OdyX: well, it's not really "at fault"
<Besogon> azeem_, no. I tryed to install and uninstall the files some times. This files are installed but they are not shown in dpkg -L and not deleted
<pitti> OdyX: I don't mind much adding that file to our udev package
<Besogon> azeem_, http://pastebin.com/1cPmJssS
<Besogon> azeem_, this is my makefile
<tkamppeter> pitti, I can reduce the default installation by another 18 MB, replacing the Foomatic data in /usr/share/foomatic by another compressed PPD package.
<OdyX> pitti: AFAIK, alsa-utils uses it too (hence patched in Ubuntu)
<pitti> tkamppeter: niice!
<OdyX> pitti: or I can do conditional patching (almost done now ;-) )
<azeem_> Besogon: then they are likely from a manual install and not a packaging issue
<Besogon> azeem_, all after string 19 are not shown in deb
<pitti> OdyX: nah, if this breaks several packages, I'll just add it to our udev
<pitti> seems easier than playing catch-up
<ion> Hereâs an inotify-based wait-for-file, but in its current incarnation it requires the directory in which the file is supposed to appear to exist. http://github.com/ion1/wait-for-file
<tkamppeter> pitti, main disadvantage is that the package foomatic-db will take 2 hours to build on my box (generate all PPDs and then compress them).
<OdyX> ion: Debian's udev's wait_for_file is useful at boot time, to wait on /usr to be mounted e.g.
<tkamppeter> pitti, but this will not be a problem for the end user.
<Besogon> azeem_, what is a manual install?
<OdyX> tkamppeter: why are you generating the PPDs again ? didn't we decided to get rid of the prebuilt ones ?
<azeem_> Besogon: running "make install" as root
<azeem_> outside of debuild
<azeem_> with /usr as prefix
<pitti> OdyX: hm, which bug # was that again?
<tkamppeter> OdyX, I am looking into making Foomatic faster and less space-consuming. So I have tested building all PPDs and compressing them with pyppd, as the XMLs take space and the listing of all PPDs via "lpinfo -m" is slow.
<pitti> OdyX: so we'll reassing that to udev and I'll ship the file in udev; sounds ok?
<pitti> OdyX: bug 625110  is most likely a dupe?
<ubottu> Launchpad bug 625110 in usb-modeswitch (Ubuntu) "usb-modeswitch 1.1.4 doesn't switch any device" [Undecided,Confirmed] https://launchpad.net/bugs/625110
<Besogon> azeem_, ok. Now I've looked through the alacarte and found none of this files. Now I'm making sudo debuild
<pitti> OdyX: nevermind, got the bug mail
<OdyX> pitti: fixing that in udev seems very fine to me. Thanks in advance !
<tkamppeter> OdyX, my plans are adding a binary package named foomatic-db-compressed-ppds to the foomatic-db source package keeping all other binary packages. The distro can then decide to use foomatic-db-engine plus foomatic-db OR foomatic-db-compressed-ppds.
<pitti> OdyX: ok, great!
<tkamppeter> OdyX, note also that foomatic-db-compressed-ppds will NOT contain foomatic-rip.
<OdyX> tkamppeter: so that would be a re-introduction of foomatic-filters-ppds we had before, right ?
<Besogon> azeem, in tmmfortran-1.0/debian I don't see menufiles.
<azeem> Besogon: I don't have time to look into this, sorry
<Besogon> azeem, pity
<tkamppeter> OdyX, not really, as foomatic-rip will not be contained in the package.
<Besogon> Who can help me with makefile and building deb file
<tkamppeter> OdyX, my former abolishing of foomatic-filters-ppds was the huge waste of space of uncompressed or individually gzipped PPD files. I completely underestimated the great compression potential of pyppd, which was not ready that time.
<Besogon> aha I undestand
<tkamppeter> OdyX, using foomatic-db-compressed-ppds instead of foomatic-db and foomatic-db-engine saves 18 MB on an installed system (great for live CDs) and listing all Foomatic PPDs gets vastly faster, even faster than serving the Foomatic database from MySQL.
<OdyX> tkamppeter: nice.
<Besogon> hey. I return
<Besogon> back
<Besogon> Why a package I made don't copy a file in etc directory?
<Besogon> I see it file in the list dpkg -L
<Besogon> But actually the one wasn't copied
<Besogon> What does it mean?
<ion> Itâs so bright and vivid. Itâs almost starting to look like a triple rainbow.
<AnAnt> Hello, could someone approve: LP #626711
<ubottu> Launchpad bug 626711 in sl-modem (Ubuntu) "Sync sl-modem 2.9.11~20100718-2 (restricted) from Debian unstable (non-free)" [Wishlist,New] https://launchpad.net/bugs/626711
<pitti> AnAnt: done
<AnAnt> pitti: thanks
<AnAnt> pitti: & thanks for texlive-bin too
<oubiwann> pitti: hey man, I'm trying to run apport-collect <bug number>
<oubiwann> pitti: but I'm a beta tester, so I get edge
<oubiwann> pitti: and as a result, an ncurses login screen
<oubiwann> pitti: but I can't continue in the ncurses view, once I enter my email/pass
<oubiwann> pitti: any clues, hints, etc.? or is this a known bug?
<pitti> oubiwann: ncurses login? that's new
<pitti> oubiwann: last time I had this, it just opened a page in my browser
<pitti> oubiwann: oh, are you in a chroot or something without firefox?
<pitti> oubiwann: ncurses login screen> that's w3m or so?
<oubiwann> pitti: ssh connection, yeah
<oubiwann> pitti: yeah, looks like it... maybe links/lynx
<pitti> oubiwann: then it's better to open the URL that it prints out locally
<ogra_cmpc> oubiwann, there is a bug about LP login not working with w3m iirc (dont ask me about the bug # though)
<oubiwann> ogra_cmpc: sweet, thanks
<barry> hi folks, i'm having an odd problem updating one of my early maverick machines and i'm wondering 1) if this is a bug worth reporting/investigating; 2) what's the safest way to fix the problem
<barry> i have both libgirepository1.0-0 and -1 installed apparently.  the former has a [!] icon in synaptic (not sure exactly what that means).  apt-get, update-mgr, and landscape all fail to update the machine because of this.  if i explicitly mark the -0 for reinstallation, apt wants to remove a *ton* of packages, which i'd rather not let it do ;)
<seb128> libgirepository1.0-0 is deprecated
<seb128> nothing should depends on it
<barry> seb128: yep, you see my problem :)  it appears as though a ton of things do depend on it
<seb128> doubteful
<seb128> sudo apt-get remove libgirepository1.0-0
<seb128> what does that want to do?
<barry> seb128: hmm, it looks like it just wants to remove that one package.
<seb128> see ;-)
<seb128> dunno why update-manager would fail on that
<barry> seb128: u-m, landscape, *and* synaptic ;)
<seb128> what does apt-get dist-upgrade say?
<barry> nothing to do
<barry> let's see what u-m says now
<seb128> what version of libgirepository1.0-0 did you have?
<barry> seb128: it was 0.6.something iirc.  seems like doing the manual removal has made at least u-m and synaptic happy again
<barry> seb128: i need to reboot that machine and then we'll see if landscape is happy to
<barry> very odd though; i was sure i tried an apt-get remove and saw tons of other removals.  maybe it was apt-get install --reinstall tho.  seb128 thanks
<seb128> np
<tkamppeter> OdyX, ping
<OdyX> tkamppeter: pong
<tkamppeter> OdyX, was there ever a foomatic-db package in Debian which provided the foomatic-filters-ppds package?
<OdyX> tkamppeter: Lenny (current stable) has f-f-ppds, built from src:foomatic-filters-ppds. Squeeze had foomatic-filters-ppds built from foomatic-db-engine and now ships it as a "dummy" package
<tkamppeter> OdyX, I am looking into pre-building the PPDs from the build of foomatic-db without duplicating upstream source code and without modifying foomatic-db-engine upstream.
<OdyX> tkamppeter: then you need to B-D on foomatic-filters, right ?
<tkamppeter> OdyX, looks like that I have to build foomatic-db-compressed-ppds out of the foomatic-db-engine build then.
<tkamppeter> OdyX, foomatic-filters is never needed to pre-build the PPDs.
<OdyX> tkamppeter: you may want to take a look at the git history of foomatic-db-engine
<OdyX> http://git.debian.org/?p=collab-maint/foomatic-db-engine.git;a=commitdiff;h=2254476
<tkamppeter> OdyX, problem is that a foomatic-db-engine installed into the system by BD can only build PPDs from the XML data installed into the system, not from the XML data in the current package's source tree.
<OdyX> huh, sucks....
<tkamppeter> OdyX, thanks for the link.
<G> zul: do you happen to be around by any chance?
<zul> G: yes
<G> zul: hey, I noticed that the Server Team seems to have a slightly different SRU policy for accepting packages
<zul> G: yeah
<G> zul: regarding something like Bug 589063 (I believe libvirt/KVM etc falls under Server), whats the best way to get it 'accepted'?
<ubottu> Launchpad bug 589063 in seabios (Ubuntu) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Confirmed] https://launchpad.net/bugs/589063
<zul> G: send a note to the ubuntu-sever mailing list
<G> zul: so, as a reply to the e-mail you send out weekly?
<zul> G: yep
<G> zul: argh, server-list doesn't have reply mugging
<G> zul: sorry for the fact you'll get it twice
<zul> G: thats fine
<G> zul: okay there we go, thanks
<zul> G: no problem
<G> zul: I'd been working off the main SRU policy, didn't realise (actually more like forgot) that there was a seperate Server policy :)
 * G has a poke at other virt bugs
<G> zul: btw, whats the process for getting fixes into maverick at this stage as well
<zul> G: open up a bug
<G> bug already exists
<zul> G: then someone should be already looking at it
<G> zul: okay, (just isolating a patch for the bug atm)
<zul> G: bring it up on #ubuntu-server
<G> zul: okay will do
<theclaw> hi
<theclaw> I have a package with executables, and want to create a package with debugging symbols of those executables; however, if I use dh_strip --dbg-package, it strips the executables, making them non-executable
<theclaw> any idea how to fix this?
<penguin42> theclaw: Has it also created separate -dbg debs ?
<theclaw> penguin42: yes
<penguin42> I *think* those should have the debug symbols
<theclaw> penguin42: "file /path/to/debugbin" says "... not stripped", "file /path/to/normal_bin" says "... stripped"
<theclaw> (I said "strips" above when I should have said "doesn't strip", sorry)
<theclaw> do executable files have to be stripped so that they can be executed?
<penguin42> no
<penguin42> and stripping shouldn't change whether it can execute
<theclaw> hmm.
<ScottK> didrocks: Your ubuntu-netbook-default-settings upload will affect U/I, right?
<didrocks> ScottK: one of the icon will slightely change and nautilus removal in the installation, right. the issue is that it will probably change again later as we don't have the list of things to display by default (and it's an issue, I agree)
<ScottK> didrocks: My understanding is that post U/I freeze such changes need an FFe with an ack from the docs team.
<ScottK> Mostly so they know not to do any screenshots of that yet.
<didrocks> ScottK: I wasn't thinking it was such impacting. I was planning to send an email to them as we will likely have some changes in any case. Thanks for the reminder.
<ScottK> didrocks: Please open an FFe bug (feel free to say all the planned changes) and subscribe them.
<didrocks> ScottK: doing it now, ubuntu-docs is the team, right?
<ScottK> didrocks: AFAIK, yes.
<didrocks> ScottK: thanks, doing it
<ScottK> didrocks: Do you mind reuploading with the FFe bug in debian/changelog?
<didrocks> ScottK: sure, if it's not accepted already?
<ScottK> It's not.
<ScottK> I'll reject so you can reupload.
<didrocks> ok, great :) thanks
<didrocks> well, once launchpad won't timeout again ::
<ari-tczew> https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/avogadro/maverick
<ari-tczew> hmmm, why latest release has dated earlier than previously?
<graphitemaster> hey why can't I request anymore CD's?
<graphitemaster> i used to request everytime a new version came out, my internet is not the fastest ya know, it's bad enough it takes me two months to download an iso
<tkamppeter> OdyX, I have solved my problem, one can redirect to an alternative XML database via the env variable FOOMATICDB with all tools of foomatic-db-engine.
<didrocks> ScottK: reuploaded
<penguin42> is it possible to build i386 packages on x86-64 using pbuilder or the like?
<ScottK> cjwatson: Your blog post on grub2/windows made the news picks section on http://www.groklaw.net/
<geser> penguin42: yes, if you have an i386 pbuilder
<penguin42> geser: Ah so just pubilder --architecture i386 ?
<geser> yes
<penguin42> nice, I'm jsut building a modifed Maverick Mesa that fixes a radeon issue, and it works great, but Google-earth is 32bit
<didrocks> ScottK: will you have the time to accept the -settings package (would be nice to have it for tomorrow respin image)
<ScottK> didrocks: Need to get an ack from the docs team first.  Maybe you can find someone to look at it.
<tkamppeter> OdyX, I succeeded to make a foomatic-db package with foomatic-db-compressed-ppds now.
<didrocks> ScottK: I still wonder as I've seen no UNE documentation. Don't know who can give such an exception for it
<ScottK> didrocks: I'm not sure, but I'd ask someone on the docs team.  If they aren't doing docs, then just them saying that is more than enough.
<didrocks> mdke: do you know if there are some people working on UNE documentation? seems not (asked to some doc core team member as well and they don't know) ^
<seb128> didrocks, what did you change?
<didrocks> seb128: just added the evo express icons in the launcher and removed nautilus. Still not the definitive launcher in any case
<seb128> ScottK, you need an ack from the documentation team?
<ScottK> seb128: Post U/I freeze for things in Main we normally do that.
<seb128> ScottK, https://wiki.ubuntu.com/FreezeExceptionProcess doesn't say that
<seb128> "Every change of the user interface (either a string or the layout) requires you to notify the documentation and translation teams. Please include a link to these posts in the mailing list archives of ubuntu-doc@ and ubuntu-translators@. "
<seb128>  
<seb128> it says to notify and subscribe ubuntu-release
<seb128> it doesn't say you need to wait for them to ack the change
<ScottK> Actually that's right.  Thanks for pointing it out.
<ScottK> Now that they've been notified, I'll accept it
<seb128> ScottK, thanks
<didrocks> thanks seb128 and ScottK :)
<seb128> yw
<ScottK> didrocks: Accepted.  In the future, please inform them before upload on post-U/I freeze changes that affect U/I.
<didrocks> ScottK: sure, will do for upcoming changes, thanks for the notice
<penguin42> 32bit pbuilder worked nicely - thanks!
<seb128> slangasek, review of ubuntu-sso-client would be appreciated by the u1 team I think
<seb128> it fixes some bugs which break clients right now
<seb128> slangasek, the rhythmbox upload fixes a crash which seems to happen to quite some users
<seb128> if you can review that as well
<seb128> thanks
<neeraj> for bug 511225, should I file a ff'e request separately?
<ubottu> Launchpad bug 511225 in sugar-0.88 (Ubuntu) "running sugar causes left-click not to work properly in GNOME" [Critical,Confirmed] https://launchpad.net/bugs/511225
<tkamppeter> OdyX, ping
<OdyX> tkamppeter: pong
<slangasek> seb128: accepted both
<tkamppeter> OdyX, I have created the foomatic-db-compressed-ppds now and it is working nicely. I made it conflicting with foomatic-db-engine to avoid duplicate PPD entries which deliver PPDs from different data sources. My problem is now to make updates from Lucid to Maverick smoothly migrate.
<OdyX> tkamppeter: for sweet upgrades, you should look after "Provides" (which only works if the relationship is non-versioned)
<tkamppeter> OdyX, to let the update only happen in Ubuntu I thought about replacing foomatic-db, foomatic-db-engine in the dependencies of ubuntu-desktop by foomatic-db-compressed-ppds, does the conflict of foomatic-db-compressed-ppds with foomatic-db-engine remove foomatic-db-engine then?
<OdyX> tkamppeter: IMHO you should leave the choice. That means using "Provides" and converting "Depends" or "Recommends" into alternative relationship, with the one you want first..
<OdyX> tkamppeter: but the answer to your question is probably yes.
<tkamppeter> OdyX, Ubuntu is CUPS-only, there it is no problem to make the default installation to use a CUPS-only solution. In Debian I want to leave the choice.
<slangasek> seb128: do you know why gir-repository ftbfs now?  (looks for vte headers in the wrong path; wants rebuild to get rid of dep on libavahi-core6)
<OdyX> tkamppeter: I mean leaving the choice between compressed and non-compressed
<OdyX> tkamppeter: but I agree with your strategy.
<seb128> slangasek, no but I will get it fixed, thanks for pointing it
<slangasek> seb128: looks like pkg-config --variable=includedir vte spits out the wrong path
<slangasek> (/usr/include, not /usr/include/vte-0.0)
<seb128> slangasek, seems buggy indeed
<seb128> slangasek, can you open a bug about that?
<slangasek> ack
<seb128> thanks
<slangasek> Daviey, smoser: do you know why eucalyptus-udeb depends on libavahi-core6-udeb when nothing else in eucalyptus wants libavahi?
<slangasek> (the package now needs a rebuild for the libavahi-core ABI change, just wondering if it should be future-proofed in the process)
<smoser> ttx might be able to answer more, but i'm guessing its so that the nodes can find a server and populate the server field
<slangasek> ok
<achiang> quick process question -- when ubuntu moves from version N to N+1, how do the changelog lines for the packages get updated (so they are built properly)? is it automatic or is it manual on a per-package basis?
<achiang> e.g., foo-package (1.0) lucid; urgency=low ; how does that get rebuilt for maverick (if at all)?
<micahg> achiang: old entries don't change, new entries have the new release name
<smoser> achiang, i believe that initially, its a binary copy over.
<achiang> smoser: so if foo-package is copied from lucid -> maverick, but didn't need any updates for maverick, then its release field in the changelog remains the same?
<ccheney> what happened to the ubuntu amd64 daily live image? it seems to not been produced for the last several days
<smoser> achiang, it sure appears that that is the case.
<smoser> for example, on my maverick system here, i have /usr/share/doc/notify-osd-icons/changelog.gz with 'notify-osd-icons (0.6) lucid; urgency=low'
<achiang> smoser: makes sense. so if a developer actually needs to make a change to the package, then s/he will s/lucid/maverick/ for the last  changelog entry, as micahg said
<smoser> right. they *have* to to get it re-built for maverick
<micahg> achiang: no, a new entry will be added
<achiang> micahg: right, i meant that, i just wasn't clear in what i wrote. :)
<achiang> smoser: micahg: thanks
<smoser> ccheney, i believe size issues
<superm1> smoser, ccheney no, according to http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/maverick/daily-live-20100830.log: "mkfs.msdos: command not found"
<smoser> manjo, ^ (you asked about that earlier)
<manjo> smoser, also the i386 iso won't boot without a hack
<superm1> from usb or from cd?
<manjo> smoser, you need to do sed -i -e 's/ui gfxboot/gfxboot/' /media/New\ Volume/syslinux/syslinux.cfg to the usb stick
<manjo> superm1, I have not tried CD
<superm1> that's only if you are burning from usb-creator on 10.04 however (and only on USB)
<manjo> superm1, correct
<manjo> superm1, I am running lucid on my desktop @ home
<superm1> manjo, that's bug 608382
<ubottu> Launchpad bug 608382 in usb-creator (Ubuntu) "Maverick images build on lucid fail to boot - different syslinux version" [High,Triaged] https://launchpad.net/bugs/608382
<manjo> smoser, superm1 also the installer supposed to show me a list of networks that I can chose from but all I see if a pink area ... no list
<manjo> currently my install is stuck on retreveing files 2of6
<manjo> detailed message says "*** Message: useQuirks: 0 / 0 /"
<superm1> manjo, that could be a bug in a lot of areas, i think best to do is to ubuntu-bug ubiquity (ctrl-alt-t from the installer right now should get you a terminal), and then also attach lspci
<manjo> superm1, :) its a chicken and egg problem, I don't have wifi to file a bug, since no wifi got listed by the installer
<cjwatson> ccheney: NCommander fixed that earlier today
<cjwatson> ScottK: hm, not sure I want even more publicity, oh well :-/
<ccheney> cjwatson: thanks
<manjo> cjwatson, when you get a chance can you look at my mail about UEFI ?
<cjwatson> manjo: yes, I will do, but I'm technically on holiday today and it will take a good chunk of time to answer your mail
<manjo> cjwatson, np, sorry to bug you.
<cjwatson> manjo: and in small chunks of time I have at the moment, I need to focus on the beta release
<manjo> cjohnston, totally understand, its bad timing I know
<manjo> cjwatson, ^
<janimo> Hello, does anyone here know which application was used to create the syslinux boot splash used as the first image on the LiveCD ?
<janimo> I'd like to replicate that look for a deirvative and being quite a beginner in graphic manipulation it would help to at least know that I am not trying to do it using the wron g tools (gimp in this case)
<janimo> thanks
<cjwatson> janimo: I think I used something akin to the instructions in debian-installer/build/boot/x86/pics/polverini_b.README, but it was quite a while ago and I don't remember
<janimo> cjwatson: thank you, I'll read that
<janimo> cjwatson: I see a few images in that directory, but they are debian or pre-10.04 ubuntu. Is the original Lucid one available as well? Besides the conversion routines desribed in that readme and for which I used Gimp
<janimo> before, I was curious if there is a raw file for the png or jpg from which it was generated, and maybe an artist who can tell what tools and effect were used
<cjwatson> janimo: I really don't remember unfortunately
<janimo> cjwatson: np, thanks anyway
<cjwatson> I don't seem to have them locally in the place I was expecting
<cjwatson> I have a vague memory that michaelforrest did it
<sidh> Greetings
<sidh> not sure if I'm asking to the right chan , but since i upgrade xubuntu 10.04 LTS , i get freezes with nfsclient when copying big files (2.1 GB)
<sidh> does this problem has been reported ?
<sidh> (i made no change in my mount options)
<ScottK> cjwatson: Right.  It was intentional I didn't start out with "Congratulations ....".
<tkamppeter> OdyX, are you currently working on Foomatic? It would be nice if you do not commit to GIT in the next days, to make it easier for me to commit my results.
<OdyX> tkamppeter: I'm not. What I wanted in is already in. And in any case, if I would, I would in the master-squeeze branches.
<OdyX> tkamppeter: feel free then !
<tkamppeter> OdyX, OK.
<ScottK> gilir: Is  awn-applets-common supposed to include anything other than translations?
<gilir> ScottK, no, only translations
<ScottK> gilir: OK.  Does it need to be arch any?
<ScottK> didrocks: You didn't happen to see 627030 when you were working on Evolution, did you?
<didrocks> ScottK: not really, my bugmail is closed (it's quite late here), just a quick fix for beta. In any case I'll upload after beta evo 2.30.3 and look at this one so
<ScottK> didrocks: OK.  Thanks.
<didrocks> yw
<gilir> ScottK, no, should be arch all, I'll fix it for the next upload
<ScottK> gilir: OK.  I'll go ahead an accept it.
<tkamppeter> OdyX, ping
<slangasek> pitti: do you have any idea what this error message is?  I can't reproduce it in a local build, even with pkgbinarymangler installed: Error: Package: and Architecture: do not alternate in debian/control
<slangasek> pitti: from http://launchpadlibrarian.net/54444678/buildlog_ubuntu-maverick-i386.emdebian-crush_2.2.4ubuntu1_FAILEDTOBUILD.txt.gz
<slangasek> hmm, maybe it's a parallel building problem
<soren> slangasek: Maybe it gets confused by "Package:pdebuild-cross" (no space)
<soren> slangasek: As for why you can't reproduce it, I have no clue.
 * soren didn't try
<slangasek> soren: good catch, I'll fix that and give it another try.  Would still like to know where this error comes from though :(
<soren> slangasek: I can reproduce it.
<slangasek> soren: in what env?
<soren> slangasek: sbuild
<soren> (maverick)
<slangasek> hmm
<soren> with pkgbinarymangler installed.
<slangasek> infuriating
<slangasek> soren: thanks :)
<soren> Sure thing.
<soren> slangasek: Adding the space fixes the build.
<soren> Just FYI.
<slangasek> ack
 * soren wanders off
<pitti> slangasek: it means that a Package: record in debian/control either has zero or more than one Architecture: fields; I wasn't sure how to interpret those cases, and at best they would only "accidentally" be right, so I thought to play it safe
<pitti> soren, slangasek: ah, interesting little buglet in the mangler then
<slangasek> pitti: ok, where does that message /come/ from? :) I can't find it in the code
<slangasek> pkgbinarymangler /is/ the current package name, right?
<pitti> slangasek: it's actually from pkg-create-dbgsym
<slangasek> ahh
<pitti> slangasek: but yes, it's the current name for that part
<slangasek> I didn't have pkg-create-dbgsym here
 * slangasek files a bug
<pitti> thanks
 * pitti waves good night
#ubuntu-devel 2010-08-31
<neeraj> Let say package A depends on B. And B on C. Now including B as a dependency of A will install C also.. right? Or we have to add both B and C as a dependency.
<JontheEchidna> Other than libraries which are automatically hanlded, dependencies can change. So while at the moment B would bring in C, it's best to assume that it might not always do so, and depend on both B and C
<JontheEchidna> neeraj: did you catch my message before you lost your connection?
<robert_ancell> slangasek, ping
<slangasek> robert_ancell: hithere
<robert_ancell> slangasek, hey, question about this vte include problem - what package is using it in this way.  There seems to be an inconsistency in how "includedir" is defined
<slangasek> robert_ancell: both gir-repository and vinagre both FTBFS this way
<robert_ancell> slangasek, ok, looking into what they're doing - note that vinagre has it's pkg-config file set up the same way
<micahg> any archive admins want to sync a security update? :)
<robert_ancell> slangasek, vinagre builds for me, and appears to have built fine in the archives - do you have a build log?
<slangasek> robert_ancell: hmm, didn't keep a log; don't even remember now for sure that I did build it, as opposed to inspecting the source visually.  Will double check and get back to you in a bit
<robert_ancell> ok
<slangasek> robert_ancell: ah; no, I didn't try to build vinagre, I just looked at the source to confirm that it expected "vte/vte.h" as a header rather than "vte-0.0/vte/vte.h"
<slangasek> robert_ancell: so it may just be gir-repository affected by ths
<nigelb> kirkland: beautiful blog post :)
<pitti> Good morning
<G> pitti: evening
<geser> good morning
<dholbach> good morning
<mvo> hey dholbach
<dholbach> heya mvo
<jibel> mvo, good morning, we've found another culprit causing bug 614993.
<ubottu> Launchpad bug 614993 in xorg-server (Ubuntu) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: xserver-xorg-video-v4l demoted to universe" [Critical,In progress] https://launchpad.net/bugs/614993
<jibel> mvo, xserver-xorg-video-radeonhd has been removed from maverick and is blocking the upgrade.
<jibel> mvo, but that does'nt fix the pb for everybody and there is still another one.
<mvo> thanks jibel, I look at it again
<mvo> jibel: odd that it worked for me, but maybe I had the wrong set of package, I investigate
<jibel> mvo, I'm able to reproduce the issue on a fresh 10.04.1
<jibel> mvo, but that doesn't fix it for bdmurray and another reporter. There is probably something left from a previous upgrade.
 * mvo nods
<mdke> didrocks: don't think so
<lucidfox> dholbach> Just saw your post on Planet Ubuntu... So are the Launchpad daily builds a feature that allows anyone to request Launchpad to do daily builds from VCS without any manual intervention or setting up your own daemons?
<dholbach> lucidfox, yes, the code needs to live in Launchpad though (vcs imports)
<lucidfox> Neat
<dholbach> https://help.launchpad.net/Packaging/SourceBuilds/
<lucidfox> Yes, saw that page :)
<dholbach> https://help.launchpad.net/Packaging/SourceBuilds/KnownLimitations is current breakage, but being worked on
 * lucidfox goes to set up a daily build for Pinta
<dholbach> some of them will be fixed in the next LP release
<jibel> mvo, that's xserver-xorg-video-dummy which is blocking the upgrade. it provides xserver-xorg-video-7 in maverick
<mvo> jibel: yeah, I just found it out as well, I'm preparing a new xserver-xorg-core
<mvo> jibel: it appears there is also -glamo
<mvo> jibel: and (just to be on the safe side) I merged some from debian (vga, i81, imstt) that we probably don't need, but they will not hurt (and make the merge later easier)
<didrocks> mdke: thanks for the info :)
<mvo> jibel: next thing is to debug apt so that its either more clever or gives at least better debug output
<jibel> mvo, yep. apt.log gives no clue about what's wrong.
<mvo> jibel: indeed :/
<mvo> jibel: thanks for keeping a eye on this bug! much appreciated
<jibel> mvo, have a look at -glide too
<mvo> jibel: aha, thanks. I missed that one (was in a amd64 chroot and that is i386 only afaics)
<mvo> jibel: the updated breaks list http://paste.ubuntu.com/486211/
<dholbach> if anybody has a tiny bit of time, can you branch  lp:~dholbach/harvest/release-prep  follow the instructions in the INSTALL file and play with it and see if there's anything glaringly broken? :-)
<G> dholbach: having a poke
<jibel> mvo, I think that -newport, -psb, tga, unichrome and -via are missing from that list.
<G> dholbach: how long should the manage.py update take?
<dholbach> g: the first one takes a bit longer
<mvo> jibel: thanks, that makes sense (modulo -via,that is just a transitional package)
<G> oh, never mind, something happened :)
<mvo> jibel: I add them now
<persia> jibel, -psb works?  I thought it was unsuitable for use still.
<OdyX> tkamppeter: ping
<jibel> persia, I don't know if it works but I can install it in hardy and then upgrade to a release where it's not available anymore.
<persia> jibel, Ah, OK.  So a lucid thing, rather than a maverick thing?  I believe it was available for hardy and jaunty (and not intrepid).
<jibel> persia, yes. it was only available in hardy from what I've found. I haven't checked intrepid.
<persia> I'm fairly certain that if it was in intrepid, it was pointlessly broken, because Intel never released binaries that worked with that kernel and X.
<persia> For jaunty, it was only available in a PPA, but lots of folks with that hardware (which was common at the time) installed from there.
<Kmos> hi persia
<persia> Hey Kmos.  Are you going to submit your "I'd like to be involved again" application soonish?  I've been waiting.
<persia> (otherwise I'm supposed to ask you to leave the channel)
<Kmos> I was thinking I was still banned from talking here. but I'm stopping now
<G> dholbach: that looks pretty neat!
<G> dholbach: any particular bits you want tested?
<dholbach> g: just something glaringly obvious that breaks :)
<dholbach> g: so we can get it out there and deployed
<dholbach> if we have to fix small stuff later on, that's fine
<G> dholbach: the only thing I'd say is for the bug numbers, include the bug titles
<dholbach> g: there's an open bug in harvest-data about that
<dholbach> thanks a lot for your review!
<G> dholbach: ooh, here is one
<G> Packages all unticked, Opportunities->sponsoring, Pidgin, a code branch has appeared, is that intentional?
<G> ahhh actually I guess it is
<dholbach> yes
<\sh> hmm...who approves new uploads for bugfixes these days?
<persia> \sh, If you break freeze, ubuntu-release.  if you don't, you.
<persia> (check if it's seeded first: generally apt-cache show works, because it ends up in tasks)
<\sh> persia, aehm...it's zend-framework, new bugfix release but new upstream version too...I uploaded it regarding the ffe guidlines...(all universe)
<\sh> and now it sits in "approval state" :)
<seb128> dholbach, would be nice to have a way to display the opportunities not listed
<seb128> dholbach, or to know why those nn are not listed
<dholbach> seb128, not listed because the opportunity lists are not chosen :)
<dholbach> or the filtering limited :)
<persia> \sh, Oh, that's the release team.  They've just got the upload queue on manual.  Check in #ubuntu-release if you need it fast, or wait a bit, and they'll likely push it.
<\sh> persia, thx :)
<seb128> dholbach, would be nice to have a "select all opportunities"
<seb128> dholbach, oh, it seems clicking on "selected" does that
<dholbach> seb128, yes, how do you think that could be made more obvious?
<seb128> changing the label
<seb128> "limit to selected"
<seb128> or something which indicates it's a filter and not only a title for the sublist
<dholbach> and I guess the same for packagesets?
<seb128> yes
<seb128> I though those were just titles
<seb128> I didn't get that you could click to toggle
<seb128> dholbach, otherwise great work ;-)
<dholbach> seb128, bug 627340
<ubottu> Launchpad bug 627340 in harvest "Change label of "selected" and "package sets" to "limit toâ¦"" [Low,Triaged] https://launchpad.net/bugs/627340
<dholbach> seb128, it was mostly Dylan McCall's doing
<seb128> dholbach, danke
<seb128> dholbach, is he on IRC?
<seb128> dholbach, if not just tell him great work from me ;-)
<dholbach> seb128, sometimes - he's in west canada, so at the other end of the world :)
<seb128> ;-)
<seb128> dholbach, btw the fedora things is pretty useless
<seb128> not your fault but they let all the old patches on their cvs it seems
<seb128> so we get tons of things listed which are old and outdated and not used
<dholbach> yeah, I guess so
<dholbach> I hope we can fix bug 581719 quickly
<ubottu> Launchpad bug 581719 in harvest "Speed up "making opportunities go away"" [Medium,Confirmed] https://launchpad.net/bugs/581719
<dholbach> if it's a one click operation, I hope that'll make it easier for people to make use of that list
<seb128> that would be nice
<G> seb128: are you sure?  if you look at something like Autoconf if it was that case you'd get a heap of them
<seb128> I would not dislike having the label telling you about opportunities not listed doing the "list those" on click
<dholbach> seb128, I'm not sure I understand - can you rephrase?
<G> dholbach: the thing that bugs me the most is the bit on the left
<dholbach> g: what's that?
<seb128> G: http://cvs.fedoraproject.org/viewvc//devel/autoconf/
<seb128> G: ?
<G> when scrolling it gets confusing w/ where I am on the page
<G> dholbach: because it's not smooth/stuck at the top etc
<G> the bouncing around is distracting
<seb128> dholbach, I think I was asking for what "permalink" does
<seb128> the wording is just not obvious
<dholbach> g: what's bouncing around?
<G> dholbach: the left bit w/ the filtering options
<seb128> dholbach, I'm browsing the list and just show that gnome-session has 11 opportunities
<seb128> dholbach, I was wondering if there was a way to quickly see those without changing the filtering
<dholbach> seb128, so a 'reset filters' link?
<dholbach> ah ok
<G> dholbach: if you say display all packages w/ fedora patches and scroll to the bottom it gets a little sickening
<seb128> dholbach, no, just a "show me all the opportunities for that source"
<dholbach> seb128, do you think you can file a bug explaining how you'd like it to work?
<seb128> dholbach, well "permalink" does it
<dholbach> ah ok
<seb128> just not inline
<seb128> but I can work with that
<dholbach> maybe you can file a bug for that, so it's inline?
<seb128> ok
 * dholbach hugs seb128
<dholbach> â¦and submit a patch :-P
 * seb128 hugs dholbach
<seb128> lol
<seb128> let's see
<seb128> but lunch first
<dholbach> :)
<G> dholbach: haha
<dholbach> g: it's not bouncing for me
<seb128> dholbach, great work to Dylan and you in any case
<G> seb128: can't check any other packages, looks like their CVS server has died
<G> dholbach: might just be firefox for me
<G> let me try my mac
<dholbach> seb128, maybe we can fix http://bugs.launchpad.net/fedora-patches-overview too
<dholbach> (it's what produces the fedora.csv list)
<G> dholbach: I don't think it's broken
<G> it's just that some maintainers don't delete unused patches
<dholbach> yeah, I guess
<G> and it's not much use changing it now
<seb128> dholbach, ;-)
<G> because I can tell you, that Fedora are moving to git
<dholbach> I'm very glad you find it generally useful though
<seb128> G: they are moving to git for how many years now?
<G> seb128: they are serious this itme
<G> *time
<seb128> I'm waiting to see
<seb128> I don't doubt they want to
<seb128> they just seem to be busy with other things
<G> seb128: their release engineering team are building the architecture for it now as I understand
<seb128> ok
<seb128> they might have the same issue on git though
<G> and I know when I was involved in their Infra side (back in March) they were getting alive demo going
<seb128> if the issue is due to people not doing a vcs delete
<G> seb128: nah, as I recall they are going to exploded source
<seb128> ok
<seb128> let's wait then and see what they come with ;-)
<seb128> seems interesting
<tkamppeter> OdyX, hi
<G> seb128: well thats what I last heard anyway
<cjwatson> last time I tried to look in Fedora's CVS, there was a note up saying that they'd already moved to git, and when I looked there it seemed to have unexploded source
<ttx> slangasek: re: eucalyptus-udeb/avahi: the udeb uses avahi to detect existing components and provide default sane "next" installation choices.
<tkamppeter> OdyX, hi
<OdyX> tkamppeter: hi
<mehranhu> hello
<mehranhu> Im having a problem in ANDOID lnux kernel driver
<mehranhu> can someone help me?
<mehranhu> I want to READ a file in a kernel driver.
<mehranhu> is there some set of APIs available.
<persia> We don't really do much android stuff here.  Are you sure there isn't a more relevant channel?
<mehranhu> android person dont know much about Linux-C
<mehranhu> so i think you are most suitable to help me
<mehranhu> can we read file in linux kernel?
<amitk> mehranhu: sys_read() is not really supposed to be used from inside the kernel. If you are using it you're doing something wrong
<mehranhu> what should i use?
<mehranhu> i didnt found any API over the internet
<amitk> mehranhu: you're not looking hard enough :) http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad ,  http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1763.html, http://www.linuxjournal.com/article/8110
<jdstrand> micahg: did you ever get an AA to perfrom your security copy?
<G> whats the rules of regressions between releases?
<persia> G, regressions are bad.  File a bug.  mark it a regression.  The folks in #ubuntu-bugs and #ubuntu-testing likely have good pointers to wiki pages with procedures to handle that sort of thing (I forget them offhand)
<G> persia: yeah, it's an already filed bug but feeling more and more like a regression
<persia> Yeah.  Chat with the folks in #ubuntu-bugs, and make sure it has all the rights tags, status, etc.
<G> ahhh I went into -testing, if I don't get anything there soon I'll pop into -bugs
<G> persia: thanks though
<micahg> jdstrand: no, bug 622900
<ubottu> Launchpad bug 622900 in phpmyadmin (Ubuntu) "Please sync phpmyadmin 4:3.3.5.1-1 (universe) from Debian testing (main)" [Medium,Confirmed] https://launchpad.net/bugs/622900
<micahg> jdstrand: thanks
<cjwatson> cking: do you have an amd64 system with UEFI to which you could attach a serial console or some other way to debug early code?
<cking> cjwatson, afraid not, I sent mine to manjo in TX
<cking> cjwatson, we could ask manjo to ship it to you, but it's a big dev box
<cjwatson> probably not a plan
<pitti> cjwatson: how do I find if I have UEFI?
<pitti> cjwatson: I have a fairly recent ThinkPad X201, with current maverick amd64 on it
<pitti> "find out"
<manjo> pitti, your bios should say UEFI v2.1
<cking> pitti, check in /sys/firmware perchance
<pitti> $ ls /sys/firmware/
<pitti> acpi  memmap
<cjwatson> cking,manjo: so, the current situation is as follows
<pitti> cking:  find /sys/firmware -iname '*efi*'
<pitti> -> nothing
<pitti> I guess that's a bad sign?
<cjwatson> current amd64 (only) CDs contain a GRUB EFI build
<manjo> I think sys firmware only has interrupts and such
<jdstrand> micahg: sure
<cjwatson> you can boot them using either BIOS or UEFI on a system capable of doing either
<cjwatson> GRUB appears to boot the kernel fine; I used a test kernel cking gave me at the sprint which issues beeps right at the start of head_64.S
<cjwatson> however, there is no output from the kernel
<cjwatson> this is obviously a showstopper but it's not quite clear what's going on
<manjo> cjwatson, is there a 64bit image I can get to on cdimage ?
<cjwatson> the 'newreloc' branch was landed recently in GRUB upstream, and there's a possibility that it was due to the initramfs being loaded incorrectly in which case that might fix it
<cjwatson> otherwise, it's hard to say
<cjwatson> manjo: yes, any current amd64 one
<manjo> ah yesw
<cjwatson> newreloc was a pretty significant piece of work though
<manjo> cjwatson, let me try down the latest x64 iso and give that a spin on my box
<manjo> give me 30mts or so
<cjwatson> right, it's always possible it was just this system, though I'm doubtful
<manjo> I just got a new box from intel with latest build of uefi
<manjo> I was wanting to install it anyways
<manjo> but x64 image was not available for the last few builds
<cjwatson> right, only landed recently.  would have been longer ago except that there was a PATH issue in the daily builds
<manjo> cjwatson, now downloading image ... will report back soon
<cjwatson> thanks
<cjwatson> I'll see if I can get to network-console
<pitti> manjo, cjwatson: sorry, no trace of UEFI in BIOS or /sys
<G> pitti: as I recally UEFI & 'BIOS' are mutually exclusive
<G> i.e. you have one or the other
<pitti> ok, s/BIOS/the ASCII GUI thing for configuring hardware/ :)
<cjwatson> G: not true
<cjwatson> G: I have a laptop just here --> that lets you select at boot time
<G> cjwatson: between BIOS & UEFI?
<cjwatson> G: I mean, it's probably a BIOS compatibility shim over the top of UEFI or something, but it lets you select either, yes
<G> ahhh right yeah
<G> yeah, I'd say it's a compatibility hack over the top
<cjwatson> but functionally, that's all that's relevant
<G> cjwatson: yeah, but for the most case, I am right is saying you can have one over the other at any particular time?
<cjwatson> sure
<G> *only one
<G> personally I'm hoping UEFI catches on fast
<cjwatson> G: I have mixed feelings
<manjo> pitti, does any of your "boot" options in bios say uefi ?
<pitti> manjo: no
<manjo> pitti, if you have uefi bios it should give you an option in boot menu to switch between legacy and uefi
<G> cjwatson: definately for servers, the 2TB boot partition thing has been a nightmare for ages, but for desktops, it will (hopefully) push the HDD makers away from the ugly 2TB+ hacks (like the WD Advanced Format drives)
 * manjo wonders why we need 2TB on clients ... don't we have cloud for storage ?
<persia> manjo, reduced latency
<G> manjo: haha, storage clouds make me laugh, especially when I'm sitting here w/ my 1.5Mbit down, 400kbps up link :)
<G> manjo: but the other reason is that I create a ton of backups/shelve a heap of data to refer to later (not exactly important enough to warrant offsite backup but interesting enough to warrant something near-by)
<manjo> cjwatson, I get a splash screen...
<manjo> cking, what was the problem that cjwatson reported ?
<manjo> cjwatson, I am going to proceed with the install ... looks like the CD booted fine (I need to double check that I booted in UEFI mode), UEFI CD/DVD was my 1st boot device and it looked like it recognized it as such
<cjwatson> manjo: do you get into the installer?
<cjwatson> G: GPT is the best feature of UEFI
<manjo> cjohnston, yes
<cjwatson> manjo: coo
<manjo> I am on allocate drive space etc...
<manjo> but I see a problem there :)
<cjwatson> let me know how it goes!  my test machine doesn't get that far
<manjo> select drive space : 360GGB ATA
<manjo> below that
<manjo> Ubuntu 0.0 B
<manjo> what is that ?
<G> cjwatson: yeah, hence why I want to see UEFI more common :)
<cjwatson> manjo: I believe I've seen that bug on BIOS too
<manjo> cjwatson, copying file now ... installing ..
<cjwatson> manjo: I was expecting you to try server first :)
<cjwatson> I can give desktop a try
<manjo> cjwatson, was the problem on server iso not desktop ?
<cjwatson> yeah
<manjo> s**t
<cjwatson> good to know that desktop seems to work though
<cjwatson> that's useful in itself
<manjo> ok will try the sever iso on another machine
<cjwatson> do double-check that it booted in UEFI mode though
<manjo> yep will do once its done installing
<manjo> I need to reseed my server iso anyway
<manjo> cjwatson, even if it booted cdrom in legacy mode I should be able to boot the HDD in UEFI mode correct ?
<cjwatson> probably not since if it did that it would have put a BIOS version of grub there
<manjo> cjwatson, bad newsw
<manjo> cjwatson, grub install failede
<manjo> cjwatson, grub-efi package failed to install into /target/
<cjwatson> manjo: logs?
<cjwatson> (with any luck I can try this too, in 1h45m or so)
<manjo> cjwatson, http://kernel.ubuntu.com/~manjo/logs/logs.tgz
<manjo> cjwatson, let me know if you need more info ... I will wait  on reboot
<ScottK> superm1: Is the mythbuntu-common upload one that you need in for beta?
<manjo> cjwatson, were you able to get the logs ?
<cjwatson> yes
<superm1> ScottK, yes ideally
<ScottK> OK.  Let me check.
 * manjo standing by
<cjwatson> hm, I just queued up a mythbuntu build
<cjwatson> oh well, you can just do another one later
<cjwatson> manjo: ok, just a seed bug, fixed (though not in time for current beta builds)
<manjo> can I work around ?
<pitti> Keybuk: does ureadahead have some minimum blocking time on SSD as well? it seems the boot blocks on that on my system (http://people.canonical.com/~pitti/bootcharts/donald-maverick-20100805-1.png)
<ScottK> superm1: Accepted.
<superm1> thanks
<ScottK> No problem.
<cjwatson> manjo: uh, not sure
<cjwatson> manjo: certainly not easily except by remastering the CD (which is in itself rather challenging)
<cjwatson> actually, wait, the seed change was in ship-live!
<cjwatson> not live - so that means the build in progress should pick it up
 * manjo fingers crossed
<Keybuk> pitti: not usually
<manjo> cjwatson, ok will try the server cd to make sure it can make progress like desktop..
<Keybuk> I think it may read the pack before going into the background
<Keybuk> but that's no time
<manjo> cjwatson, you need anymore info from this box before I reboot ?
<Keybuk> pitti: get a blktrace of that?
<pitti> Keybuk: I'll read about it (never used that so far)
<cjwatson> manjo: nope
<cjwatson> manjo: actually
<cjwatson> manjo: cat /proc/fb
<pitti> Keybuk: but thanks (I mainly was curious about whether this is expected); so I'll put that on my todo list
<cjwatson> manjo: and can you try ctrl-alt-f1 and see if you see anything on the console?
<manjo> I am on f1
<manjo> proc/fb == 0 inteldrmfb
<cjwatson> ok
<manjo> there was noting on f1 when I switched
<cjwatson> but there is now?  what did you do?
<manjo> ?
<Keybuk> pitti: no, but it's hard to tell what's going on there
<manjo> I switched to f1 to copy logs etc to usb stick and put it up on kernel.ubuntu.com
<cjwatson> manjo: do you mean that there was just a login prompt or something on ctrl-alt-f1 when you switched?
<manjo> right
<manjo> just a log in prompt
<cjwatson> by "anything" I meant "not a blank screen" :-)
<cjwatson> as in, is the console working
<manjo> :) yeah console was working
<Keybuk> pitti: for example, it could be that ureadahead is reading the things that modprobe already has loaded
<manjo> heh I have gotten used to seeing a working console that Q confused me sorry
<Keybuk> so it's null reads, that still cost syscall time
<Keybuk> blktrace would reveal more detail
<cjwatson> so it's possible that efifb isn't working, but that things get sorted out when inteldrmfb is loaded
<cjwatson> in which case we'll need to bloat up the amd64 d-i initramfs some more
<cjwatson> and figure out *why* efifb isn't working
<cjwatson> or maybe there's some other difference between your machine and mine
<cjwatson> I'm not entirely convinced that my initramfs is coming up
<manjo> cjwatson, booting server now
<manjo> cjwatson, server iso install in progress ...
<cjwatson> that will suffer from the same problem at grub-efi, but cool, it works
<cjwatson> that's an astonishing relief
<cjwatson> now I need to figure out what's different about this box
<manjo> cjwatson, yeah I guess its going to be the same fate... but I will let it make progress
<manjo> cjwatson, ok hit the same spot ie bug
<manjo> cjwatson, so you think the beta build for live server & desktop will pick up your fix ?
<besogon> Just for a survey: what do you, developers, use for building a package?
<manjo> cjwatson, I am 99.999% sure that I am booting UEFI mode, the 1st boot option on my boot list is EFI DVD/CDROM and it does not seem to fail that ie it hits option 1 and boots CDROM. \
<cjwatson> yes, you are booting in UEFI mode
<cjwatson> the desktop build just completed has picked it up (but is oversized and needs investigation); not sure if server will be respun
<manjo> cjwatson, ok I have DVD I can use to burn image on
<manjo> cjwatson, so if I reseed now I should get the latest correct ?
<cjwatson> yep
<manjo> cjwatson, which build should I use ? daily-live/current ? or daily/current ?
<cjwatson> the former
<manjo> daily-live it is
<manjo> cjwatson, will test that bad boy in couple of mts
<SpamapS> pitti: howdy, I submitted another optimization to the WI tracker today as a merge proposal. Should speed it up a lot actually.
<pitti> SpamapS: I saw, thanks!
<SpamapS> pitti: I'm trying to add some useful little panels to the HTML report, like a list of assigned bug tasks in ubuntu.. but I don't want to add this to collect. I'm wondering, do you know if there is a launchpad/ajax proxy available on people.canonical.com?
<pitti> SpamapS: I'm afraid I don't even know what an ajax proxy is :/
<SpamapS> pitti: I'm thinking of opening up an RT ticket to allow for one. That would let us put in some on demand stuff and not have to collect it all.
<SpamapS> pitti: its just a program that would be running on there to get around javascript's "same-origin" restriction.
<SpamapS> pitti: basically I can't ask launchpad.net for JSON from a script that originated on people.canonical.com
<SpamapS> pitti: but if we could have a script on people.canonical.com that proxied directly to api.launchpad.net, there's no problem. :-P
<SpamapS> actually I wonder if launchpad supports JSONP ..
<superm1> cjwatson, with that respun oversized disk, on an e6410 it looks like there is a grub menu, but selecting the first option just yields a black screen
<manjo> superm1, I did not want to hear that ! vanhoof ^^
<manjo> superm1, on intel efi test bed.. its booting and installing as of now
<manjo> vanhoof, I should try this iso on 4310 I have an make sure we see an install menu etc on maverick
<cjwatson> superm1: seems that there are different results on different machines.  I get a blank screen too
<cjwatson> superm1: the next thing I'm going to try is the grub newreloc branch, since I'm becoming convinced that the initramfs isn't being loaded properly
<cjwatson> but this is why I wanted somebody to try with a serial console
<superm1> cjwatson, i can likely get a port replicator that has a serial port if it would be useful
<cjwatson> it's amazingly hard to debug this when the amount of information you get is a blank screen
<manjo> cjwatson, the new iso fails grub install
<manjo> executing grub-install on /dev/sda failed ...
<manjo> I will put up the logs in a minute
<vanhoof> manjo: perhaps he doesnt have the fix that was just released?  also there is 554569 which has helped a few people w/ 6410's, but its not been released yet
<cjwatson> that might be a grub-installer bug; it probably shouldn't be offering device selection on EFI, and should be calling grub-install without a device argument
<cjwatson> vanhoof: which fix?
<vanhoof> cjwatson: 561802
<vanhoof> which was released today in .42, but is only resolving a bug for UMA based 6410's
<vanhoof> cjwatson: the 6410/6510 are a big pain atm :)
<cjwatson> possible, though both those bugs seem a bit late for the symptoms I'm seeing at least
<cjwatson> superm1: you might also try 'set gfxpayload=keep'
<superm1> vanhoof, this is a UMA 6410, if I boot the DVD in legacy mode, i do get gfx.  it's only in EFI mode that the black screen comes up
<cjwatson> (in grub, before the 'linux' command)
<cjwatson> I'm not sure why I left that out, I think that was an oversight; you need gfxpayload=keep on EFI or you don't get a console
<cjwatson> well, you might get a KMS one
<manjo> cjwatson, logs are in http://kernel.ubuntu.com/~manjo/logs/logs-respiniso.tgz
<cjwatson> manjo: right, as I thought
<manjo> cjwatson, if you put in a fix today... will we have it in tomorrows spin of the iso ?
<manjo> cjwatson, or are you planning on repinning ?
<manjo> respinning
<superm1> cjwatson, unfortunately no improvements with set gfxpayload=keep on the line before the linux line
<ara> mdeslaur, hello
<mdeslaur> hi ara
<ara> mdeslaur, I am getting an error when trying to create a vm in virt-manager
<mdeslaur> ara: which error?
<ara> mdeslaur, can you have a look to the traceback, please?
<ara> http://pastebin.ubuntu.com/486396/
<cjwatson> manjo: I think I'm too late for beta now, but can work on things for post-beta
<cjwatson> manjo: perhaps you could try applying http://paste.ubuntu.com/486399/ to /usr/share/grub-installer/grub-installer before starting ubiquity?
<manjo> cjwatson, ok will do and retry
<mdeslaur> ara: what are you doing to get that issue? also, could you paste the end of ~/.virt-manager/virt-manager.log ?
<manjo> Sarvatt, your ppa ios ready ?
<manjo> is
<mdeslaur> ara: do you have anything related in dmesg?
<ara> mdeslaur, I am just creating a VM without harddisk
<ara> mdeslaur, http://pastebin.ubuntu.com/486402/
<ara> mdeslaur, it does not seem to be anything relevant in dmesg
<Shock> I've modified the nethogs package to adapt to terminal size changes. How do I generate a patch suitable and useful for inclusion in Ubuntu?
<Shock> I didn't find the wiki information clear enough
<mdeslaur> ara: which version of libvirt0? if you restart libvirt with sudo /etc/init.d/libvirt restart, does it help?
<ara> version:  0.8.3-1ubuntu8
 * ara tries restarting
<Sarvatt> manjo: i386 is, amd64 is still waiting publication but you can just grab the deb
<manjo> Sarvatt, ack
<ara> mdeslaur, same thing after restarting
<mdeslaur> ara: can you walk me through reproducing it?
<ara> mdeslaur, sure
<ara> create a new VM, any name
<ara> select and ISO image as installation media
<ara> and leave os type and version as "generic"
<ara> leave ram and number of cpus with the default values
<ara> uncheck "Enable storage for this virtual machine"
<ara> and click on Finish
<mdeslaur> ara: darn, that works for me :(
<mdeslaur> ara: do your other VMs still work?
<mdeslaur> ara: where is your iso file located?
<ara> mdeslaur, yes
<ara> mdeslaur, somewhere in my $HOME
<mdeslaur> ara: did the iso get chowned to libvirt-qemu:kvm ?
<ara> mdeslaur, mmm, it did
<ara> mdeslaur, why did that happened?
<mdeslaur> ara: yeah, stupid new libvirt chowns everything it touches
<mdeslaur> ara: ok, that's normal
<manjo> Sarvatt, with your ppa install I only see 1366x768
<ara> mdeslaur, mmm, some other thing
<Sarvatt> manjo: you rebooted? thanks for checking!
<ara> mdeslaur, I have running another machine that has that ISO associated as well
<manjo> Sarvatt, ofcourse!
<mdeslaur> ara: as a test, could you try copying it over?
<ara> mdeslaur, copying whatÂ¿
<Sarvatt> manjo: have you tried maverick on that machine to see if its any different by any chance?
<mdeslaur> ara: make a copy of the iso, to see if it's the fact that you're using it twice that libvirt doesn't like
<ara> mdeslaur, OK, will do
<manjo> Sarvatt, did few weeks back and same results .. yes was going to try the new beta spin that just happend
<ara> mdeslaur, or I can try shutting down the other machine, for that matters
<mdeslaur> ara: ok
<Sarvatt> manjo: of course it wouldn't be that easy, thanks for the info :)
<ara> mdeslaur, yes, that seems to be the problem
<mdeslaur> ara: argh...what a piece of *&"/%/$&
<mdeslaur> hehe
<ara> mdeslaur, :)
<cjwatson> manjo: so, no joy booting the desktop image here either
<mdeslaur> ara: could you please file a bug?
<ara> mdeslaur, it is a regression, AFAIK, I never had that problem before
<mdeslaur> ara: under "libvirt"
<ara> mdeslaur, sure, will do
<manjo> cjwatson, :(
<cjwatson> manjo: doesn't seem to be doing much in the way of CD access, so I rather suspect that this is not a graphics issue, but a memory map issue
<mdeslaur> ara: thanks :)
<cjwatson> manjo: still, it's good to know that it's not completely toast, just only on certain systems
<cjwatson> that's a state I can work from
<manjo> do you have an SDV that intel shipped ?
<cjwatson> it's a Dell laptop
<cjwatson> don't want any more hardware ... ;-)
<manjo> heh
<cjwatson> (plus, would in general rather have broken hardware than working hardware if it's something I'm meant to fix)
<mdeslaur> ara: curiously, I can't reproduce...I can access the same iso twice without problems...
<mdeslaur> weird
<ara> mdeslaur, mmm, it does not seem to be the issue, as I reproduced now again having one the machines started (but without the ISO associated to it)
<mdeslaur> ara: ok, cool. Could you send me the .xml files of those two vms?
<ara> sure, will do
<manjo> cjwatson, can't find /usr/sbin/grub-installer
<cjwatson> manjo: I believe I said /usr/share/grub-installer/grub-installer
<manjo> ah
<cjwatson> smoser: what kind of state are ec2/uec builds in?
<cjwatson> (for the purpose of posting to iso.qa)
<smoser> cjji think they're good.
<smoser> cjwatson,
<smoser> i was going to start a testing run this afternoon.
<cjwatson> should I be posting them?
<ara> mdeslaur, where does virt-manager store those xml by default?
<mdeslaur> ara: /etc/libvirt/qemu
<manjo> cjwatson, installing with modified grub-installer now
<ara> mdeslaur, sent them to your inbox
<mdeslaur> ara: thanks
<smoser> cjwatson, please post the 20100831, yes.
<cjwatson> smoser: sorry, help for the stupid needed - 20100831 is a server build rather than an ec2/uec build, isn't it?
<cjwatson> smoser: post-amis-to-iso-tracker.py seems to need an input file in some format
<smoser> yeah. here.
<smoser> http://uec-images.ubuntu.com/maverick/20100831/published-ec2-daily.txt
<cjwatson> oh, right, duh
<cjwatson> so 'curl http://uec-images.ubuntu.com/maverick/20100831/published-ec2-daily.txt | ./post-amis-to-iso-tracker.py'?
<cjwatson> er, only with correct syntax
<manjo> cjohnston, installer stuck in determining grub boot device ...
<cjwatson> smoser: OK, posted.  What do I do for UEC?  Just post the server image build id?
<manjo> cjwatson, ^^
<smoser> yeah. just use the serial
<smoser> 20100831
<cjwatson> manjo: can you be a bit more exact?
<cjwatson> ok
<cjwatson> smoser: done
<smoser> cjwatson, i've never run that script, but if it reads from stdin, that is what i would expect
<smoser> thanks.
<cjwatson> it needs a file name, so I adjusted
<manjo> cjwatson, it says "Determining GRUB boot device ..." and is just hung there, no details in the message window, just Message: UseQuirks:
<hunger> Could someboby please sync sash from debian unstable into maverick to fix bug no. 609201? Thanks!
<cjwatson> hunger: nothing to sync, it's 3.7-10 in both
<hunger> cjwatson: Can you then please have it rebuild?
<cjwatson> hunger: can you first check that a no-change rebuild fixes it?  I don't have a 64-bit machine terribly convenient
<hunger> cjwatson: It coredumps right on start for all amd64 mashines I tried it on. The version I build from the debian/unstable package works fine.
<cjwatson> well, the unstable source package is the same as the maverick one, so I guess that's good enough
 * hunger wonders what went wrong with the package then if it is the same sources.
<cjwatson> built at different times with different toolchains.  did you build it from unstable using a current maverick system?
<hunger> cjwatson: A fairly current maverick, yes.
<hunger> cjwatson: Less than 1 week old.
<cjwatson> I've uploaded a no-change rebuild
<cjwatson> would appreciate a check that that fixes it, once it buils
<cjwatson> *builds
<hunger> cjwatson: Sure.
<Shock> I've modified the nethogs package to adapt to terminal size changes. How do I generate a patch suitable and useful for inclusion in Ubuntu?
<njin> ev, cjwatson: hello, i want to help in triaging Ubiquity, is possible ? Actually i'm on bugsquad under mentoring of pedro_
<Shock> bzzz
<cjwatson> Shock: what wiki page have you already looked at, and what did you find confusing about it?
<cjwatson> that would be easier than telling you it all from scratch
<cjwatson> Shock: (fundamentally, any patch in 'diff -u' format will be usable, though; depends whether you want to bother with the sponsorship process)
<Shock> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<Shock> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<Shock> https://wiki.ubuntu.com/UbuntuDevelopment/Patches
<Shock> https://wiki.ubuntu.com/UbuntuDevelopment
<Chipzz> Shock: yes, but the 3 first all describe different things
<Shock> too much info; I'm not able to discern which applies to my usecase: I've modified a program and I want to make the modifications available to Ubuntu
<Chipzz> Shock: I'll try to summarize (from the urls)
<Shock> would it be sufficient it I opened a bug in launchpad and attached my diff?
<cjwatson> are you familiar with producing patches in general?
<Shock> yes
<cjwatson> Shock: yes, it would
<Shock> i've already produced the diff
<Shock> thanks, I'll do that then
<Chipzz> Shock: 3) is normal patch; 2) is inter-deb-version diffs (to see what changed between 2 uploads; takes the package as a whole into consideration)
<Shock> any particular format the patch needs to be in?
<cjwatson> then just do that.  there are more minutiae involved if what you're trying to do is to produce a new version of the package that somebody can just upload
<cjwatson> which is useful if you're in training to become an Ubuntu developer
<Chipzz> and 1) is a system to *apply* patches (i fyou have multiple in 1 package)
<cjwatson> but if you just want to submit a drive-by patch, then a unified diff ('diff -u') is sufficient
<Shock> cool
<Chipzz> (1) is closely related to *building* the packages; 2) is entirely not)
<Shock> which of the urls I listed apply to 1, 2 and which to 3?
<Chipzz> lemme rephrase that: 1) only gets involved when building packages
<Chipzz> 1) 21:20 < Shock> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<Chipzz> 2) 21:20 < Shock> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<Chipzz> 3) 21:20 < Shock> https://wiki.ubuntu.com/UbuntuDevelopment/Patches
<Shock> those are 2, i guess
<Chipzz> nope
<Chipzz> debdiff's are used to "audit" uploads
<Shock> oh, i see
<Chipzz> lets say cjwatson wants to upload a new version of a package; ppl *may* (but will not always) request a debdiff
<Chipzz> the debdiff will contain all changes and hence you can see what changed on the source-level
<Chipzz> to see if no unnecessary changes were introduced for example
<Chipzz> patch-systems are more of this sort
<Chipzz> lets say you have a package, and you make 2 seperate changes wrt the upstream source, lets call them patch_a.diff and patch_b.diff
<Chipzz> now you need a way to easily apply those to the source
<Shock> i know what patch systems are, e.g. quilt
<Chipzz> ah k
<Chipzz> good
<Shock> i'm not sure how they fit in the overall picture in package development
<Chipzz> trijntje: Dutch or Flamish? :)
<Shock> especially as I've seen several patch systems used
<Shock> dpatch, cdbs...
<trijntje> Chipzz: Yeah, Dutch
<Chipzz> they're a convenience feature mostly
<Chipzz> Shock: and which one... is a matter of taste
<Shock> so, if I'm a package maintainer I can use the one that suits my taste?
<Chipzz> trijntje: nick gives you away ;)
<Chipzz> yes
<Chipzz> BUT
<Chipzz> if you're just changing someone elses package
<Chipzz> that's a different thing
<Shock> even though others that might want to contribute to my package will need to learn the one I chose for my package?
<Chipzz> for security uploads, the introduction of patch systems is disallowed for example
<Chipzz> yeah
<Shock> isn't that a higher barrier to entry for drive-by contributors?
<trijntje> Chipzz: so it wasnt my IP ;)
<Chipzz> trijntje allmost instantly reminded me of katrijn(tje) :)
<Chipzz> Shock: not necessarily
<Shock> Chipzz: how so? :)
<Chipzz> Shock: I don't think most maintainers require you to submit patches to them in the form of their preferred patch system
<Chipzz> it only applies if you're doing an upload
<Chipzz> like cjwatson said, regular patch will be just fine
<Shock> Chipzz: if you use cdbs in your package and I only know dpatch, don't I need to learn cdbs?
<Chipzz> Shock: you just submit a regular patch
<Shock> ok
<trijntje> Chipzz: I just picked a random dutch sounding name, but now people think i'm female and a famous singer..
<Chipzz> unless you want to try building it yourself *integrated* into the patch system
<Shock> thanks Chipzz, cjwatson
<Chipzz> Shock: but nothing prevents you from just hacking on the package and submitting a patch resulting from that
<Chipzz> although the maintainer will have to convert it to his favorite patch system, and hence it may take longer to process
<Chipzz> but that's a different matter :)
<Shock> :)
<manjo> cjwatson, if I set -x in grub_installer script where does the the messages go ?
<manjo> I don't see it on the console
<manjo> cjwatson, the install is stuck in "determining grub boot device.. "
<manjo> this is after I applied your patch
<manjo> cjwatson, logs in usual place named logs-withgrubpatch.tgz
<arek_deepinit> hi all. i got problem with my display. from time to time it goes out of sync for about 1/10sec, dunno what is reason, im on gnome and i got ati x1550graphics, its really annoying
<arek_deepinit> please help
<Shock> arek_deepinit: try in #ubuntu, this is not a support channel
<arek_deepinit> whoops
<arek_deepinit> wrong room
<arek_deepinit> ye, i meant #ubuntu
<arek_deepinit> sorry
<cjwatson> manjo: oh, sorry, my bad
<manjo> cjwatson, :)
<cjwatson> manjo: http://paste.ubuntu.com/486487/ should be better
<manjo> I have another one for you
<cjwatson> (extra 'else break')
<manjo> Bug# 627672
<manjo> cjwatson, ok will try that
<cjwatson> manjo: I'm not dealing with ubiquity much this cycle; ev will probably need to look at that
<ev> manjo: I'm going to take a look at that bug first thing in the morning.  Before I go though, are you able to reproduce it with a CD, or is this only occurring on the USB disk?  What did you create it with, is it a stock Ubuntu image?
<ev> thanks in advance
<manjo> ev, no CDrom on my netbook
<manjo> ev, will update the bug with that info
<SpamapS> is there any reason we don't like to use 'console output' in upstart jobs? Its very disconcerting that we won't be warned or informed about any problems when starting critical things like sshd.
<slangasek> james_w`, lifeless: if I have a bzr packaging branch that doesn't contain pristine-tar info, but I want to start carrying that going forward, how can I import just the current package?
#ubuntu-devel 2010-09-01
<slangasek> (alternate answers accepted: a step-by-step of grafting LP's package history into my branch with richer revision history)
<james_w`> slangasek: if you are preparing a new upstream at the same time then you can use merge-upstream by tricking it
<james_w`> slangasek: otherwise you can basically do the same thing, and re-merge the same version that is currently there
<slangasek> james_w`: how does that work? :)
<slangasek> james_w`: I consistently get an error whining that it can't find the previous upstream version
<james_w`> slangasek: you find a revision that you want to be the current tip of the "upstream" branch and tag that with upstream-$UPSTREAM_VERSION
<james_w`> that will stop it whining about that
<maco> james_w`: does this have a wiki page?
<james_w`> after you have done the import then you can delete that tag again
<james_w`> maco: it does not, as far as I know
<maco> bcurtiswx was trying to do a merge with upstream last night and my bzr-fu started whimpering
<maco> (he was asking me for help)
<slangasek> james_w`: oho, thanks
<james_w`> ah, his was straight forward if it was the case I helped him with earlier
<james_w`> that should have a wiki page at least
 * maco grumbles about varying definitions of "straightforward"
<james_w`> heh
<james_w`> I mean the usual case, not trying to do it for the first time like Steve
<ev> manjo: thanks
<james_w`> maco: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVersion
<maco> james_w`: thanks
<slangasek> james_w`: seems I need to create tags for both the old and the new upstream versions?
<james_w`> slangasek: it should be creating the new upstream version for you
<james_w`> slangasek: what command are you running?
<slangasek> ah, so I only needed the one for the old upstream version
<slangasek> I misunderstood then
<james_w`> yeah, it just needs a hint of where to start, then it will do the rest
<slangasek> bzr merge-upstream --version 1.1.2 ../pam_1.1.2.orig.tar.gz ../bzr/bzr/Linux-PAM/tags/Linux-PAM-1_1_2/
<james_w`> the error you were getting to start with was that it didn't know where to pick up the "upstream branch" from, and so didn't want to act
<james_w`> that looks fine
 * slangasek nods
<slangasek> thanks :)
<slangasek> james_w`: so should this "create the tag yourself" hack be documented on the wiki page?
<james_w`> slangasek: probably, yes
<msehudi> Hi guys. I'm a noob in kernel development. How do you load and use a kernel after building it?
<RAOF> msehudi: Sounds like you want to be in #ubuntu-kernel.  You need to set up your bootloader to load the new kernel, but if you're using the Ubuntu build process that'll be done automatically when you install the package.
<msehudi> thanks :)
<pitti> Good morning
<dholbach> good morning
<dholbach> maco, HAPPY BIRTHDAY!
<maco> dholbach: danke!
 * maco hugs dholbach
 * dholbach hugs maco back
<geser> good morning
<smb> pitti, Morning Martin, could you put on your danger sensitive sunglasses and accept the uploaded Lucid kernel and lbm for sru? (in the case of lbm it probably makes sense to accept both -24 and -25?)
<pitti> smb: ok, will do an SRU round
<smb> pitti, \o/
<pitti> smb: can you please reupload lbm with -v to include the last two changelog records?
<smb> pitti, Which one? The 24 or th -25 or both
<pitti> smb: the -25 one
<pitti> smb: same for linux-meta
<smb> pitti, ok, can do
 * pitti rejects the current uploads
<pitti> smb: thanks
<pitti> smb: linux was uploaded twice (same version), so I'll reject the older upload and look at the newer; ok?
<pitti> https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 FYI
<pitti> one 18 hours ago, one 11 h
<smb> hm, let me check
<smb> I am unaware of the second
<smb> pitti, How on earth would it be possible to upload the same version twice?
<pitti> smb: you can upload as many broken or duplicated versions to the unapproved queue as you like :)
<pitti> but you can only accept one version
<smb> pitti, Hm, I thought it would not let me upload anything again when it had gone into accept
<pitti> right
<pitti> but it wasn't accepted yet
<pitti> it's in "unapproved"
<smb> right, for some reason I thought I need to increment the version even then. But so I can upload the just rejected packages only with more history
<pitti> correct
<pitti> usually, when this happens, I look at the most recently uploaded one
<smb> Probably ok, though very weird. I am pretty sure I did upload only once
<smb> ...
<smb> If I am not dream walking
<tkamppeter> pitti, hi
<pitti> hello tkamppeter, how are you?
<tkamppeter> pitti, fine, as you have perhaps seen from earlier IRC discussion and from my weekly report I have cleaned up another 18 MB from the installed default system.
<pitti> tkamppeter: from foomatic ppds? right, I saw that; nice work!
<smb> pitti, Hm, one seems to contain the orig tar.gz and the other not... Mine should not...
<cjwatson> 18MB> coo
<pitti> tkamppeter: that's uncompressed in the installed system, right? the .deb size shouldn't be affected that much, since that's already compressed, right?
<tkamppeter> pitti, I have replaced the Foomatic XML by a compressed PPD archive, saving said space and made printer driver listing (the "searching for drivers" in s-c-p, or simply "lpinfo -m") significantly faster.
<pitti> http://cdimage.ubuntu.com/daily-live/20100901/ is still the same size as a few days ago
<smb> pitti, Is it possible for you to see who did the upload?
<smb> pitti, Of the newer one
<cjwatson> pitti: well, there was some language-pack fiddling in there
<pitti> smb: not really, I'm afraid
<tkamppeter> pitti, I could not upload due to beta freeze. I have prepared all packages.
<pitti> tkamppeter: ah, that explains it
<pitti> cjwatson: oh, just saw in the seeds; so something else got added to the CDs recently, or grew?
<smb> pitti, Ok, hold off. I want to investigate there
<pitti> cjwatson: the day after the OO.o dependency fix landed, they all fit
<pitti> smb: okay
<tkamppeter> pitti, in terms of .deb files it saves only half a meg, but there is still the speed advantage, which is probably much bigger when running a live system from a CD-ROM.
<tkamppeter> pitti, what has to be done to get the change onto the CDs are two steps, first me uploading the changed packages and then a core-dev changing the seeds from pulling foomatic-db and foomatic-db-engine to pulling foomatic-db-compressed-ppds.
<cjwatson> pitti: the update-seeds cron job was stuck on a lock, so seed changes weren't being applied properly
<cjwatson> which caused considerable confusion
<pitti> ah, I see
<pitti> cjwatson: oh, and the other issue is that we recently got a langpack update, so the delta packages aren't empty
<pitti> cjwatson: it's not a biggie for beta, and for final we'll coordinate this more carefully
<cjwatson> nod
<pitti> smb: sconklin pinged me last night, so maybe it was him?
<pitti> smb: ok, please let me know when I should look at them
<pitti> at least the lucid SRU queue is empty except for this linux upload now
<OdyX> pitti: sorry to ask, but where as the udev upload been stuck ? (I don't know the exact process, but saw you'r tagging in the bzr.)
<pitti> OdyX: it's held in unapproved; we are in beta freeze
<pitti> OdyX: it'll go in tomorrow evening, if things go as planned
<OdyX> ah okay. But there's reasonable hope to get that in, right ?
<cjwatson> not for beta
<pitti> OdyX: not into beta
<cjwatson> it'll go in for final
<pitti> OdyX: but certainly into maverick
<pitti> OdyX: people installing beta can just upgrade
<OdyX> okay. Otherwise I can release an usb-modeswitch not requiring the /lib/udev/hotplug.functions...
<pitti> OdyX: don't worry
<tkamppeter> OdyX, hi
<OdyX> pitti: Okay. Thanks for your time to explain the basics of Ubuntu release management. :->
<OdyX> tkamppeter: hi
<pitti> heh
<tkamppeter> OdyX, if you want to see how my new replace Foomatic-XML-by-PPD-package looks like, all is on git now.
<OdyX> tkamppeter: yeah, saw that. As Debian is in freeze, I probably wont take a look before its release, but thanks for your work !
<tkamppeter> pitti, one question about the migration from old XML ugliness to the new lightweight PPD archive: I made foomatic-db conflicting with the new foomatic-db-compressed-ppds and plan to replace foomatic-db and foomatic-db-engine by foomatic-db-compressed-ppds in the seeds (ubuntu-desktop, ...). Would the migration work then or do I need more.
<pitti> tkamppeter: the new packages should conflicts:/replaces: the old ones; without the replaces:, apt will hold back the new ones instead of installing the new ones and removing the old ones
<tkamppeter> pitti, especially I want to avoid a "Replaces: foomatic-db" in foomatic-db-compressed-ppds as the PPD archive does not exactly replace foomatic-db, it only provides the PPDs to CUPS.
<pitti> tkamppeter: can you install them in parallel?
<pitti> tkamppeter: well, but the net result is the same, it supplies PPDs to cups; so replaces: wouldn't be really wrong from a semantics point of view?
<tkamppeter> pitti, yes, but I want that foomatic-db is removed for updaters so that once they get the space free, second there are no duplicate listings of the same PPDs, once coming from XML and second coming from the archive, and third there is no XML being processed making "lpinfo -m" slow.
<pitti> tkamppeter: right; so I think C:/R: will do fine
<tkamppeter> pitti, so if I do the "Replaces:" can I be sure that the Build-depends: foomatic-db in the gutenprint package really installs foomatic-db on the buildds and not foomatic-db-compressed-ppds? This build process needs the actual XML.
<pitti> tkamppeter: it doesn't affect build-depends
<pitti> tkamppeter: the buildd chroots have neither pacakage installed, so they will install whatever you specify in the B-Dep: line
<tkamppeter> pitti, so build-depends always pulls the native packages and never Provides:?
<pitti> tkamppeter: I think what you mean is "provides"
<pitti> tkamppeter: but first, real pacakges are preferred over virtual ones, and second I don't think you need provides her
<pitti> e
<tkamppeter> pitti, s/Provides/Replaces/
<pitti> tkamppeter: right; if there is a package "a" and a package "b" which "provides: a", an apt-get install a will always install a, not b
<pitti> (unless b is already installed)
<pitti> tkamppeter: replaces don't have that kind of magic
<tkamppeter> OdyX, would it be a problem for Debian if I add Replaces: foomatic-db to foomatic-db-compressed-ppds?
<pitti> it would be weird _not_ to do it in Debian
<pitti> tkamppeter: Conflicts: too, please; otherwise the other package wouldn't be removed
<tkamppeter> pitti, adding the C:/R: (C: was already there, adding R:).
<smb> pitti, apparently the second upload was done by tim. It is mostly the same, just is an upload which contains the orig.tar.gz. I would prefer to re-upload my version which has the diff only. Could you reject that currently uploaded one?
<pitti> smb: well, can do, but having the orig.tar.gz doesn't hurt really
<pitti> it'll be rejected if it's different from teh archive, and ignored otherwise
<smb> Hm, ok. The rest was the same. Then lets go with this one
<smb> And I prepare the lbms and meta
<pitti> okay
<ricotz> sebner, hello
<sebner> ricotz: hoi, what can I do for you? Currently a little bit short on time though
<ricotz> sebner, could you upload a new docky package to the lucid queue?
<sebner> ricotz: just uploading?
<ricotz> sebner, https://edge.launchpad.net/~ricotz/+archive/staging/+files/docky_2.0.6-0ubuntu1.dsc
<DktrKranz> mvo: what about moving gdebi maintainer address to ubuntu-dev-team@lists.alioth.debian.org, so ubuntu-devel doesn't get spammed with PTS/BTS mails?
<ricotz> sebner, yes, as lucid-proposed
<sebner> ricotz: sure, give me a minute
<ricotz> sebner, thank you!
<mvo> DktrKranz: oh, excellent idea
<mvo> DktrKranz: *cough* should have done that ealier, feel free to change bzr
<tjaalton> pitti: I tried to backport cups from maverick to lucid to see if it fixes a bug I'm seeing, but the packaging fails when it complains about changed libcups2 symbols
<pitti> tjaalton: oh, what's the symbol diff?
<tjaalton> pitti: so should I just skip that test in the build, or?
<tjaalton> pitti: hang on
<pitti> tjaalton: I made it quite picky on symbol changes recently, since a previous upload wreaked a lot of havoc due to a changed gnutls
<tjaalton> pitti: http://pastebin.com/TLiEF94X
<DktrKranz> mvo: doing now :)
<pitti> tjaalton: ugh, lucid's dpkg-gensymbols apparently doesn't understand regexps yet?
<sebner> ricotz: done, no problem yw :)
<pitti> tjaalton: so, you can drop those two lines from debian/rules:
<pitti> DPKG_GENSYMBOLS_CHECK_LEVEL=4
<pitti> export DPKG_GENSYMBOLS_CHECK_LEVEL
<tjaalton> pitti: alright, I'll give it a go, thanks
<pitti> smb: ugh, quite an update :)
<smb> pitti, Ok, lbm and meta for -25 uploaded again.
<smb> pitti, Heh, yeah four upstream stable version have some footprint
<smb> Unfortunately we were delayed quite a bit by security
<smb> and sprints
<tjaalton> smb: does it have the "slow umount" fix?-)
<smb> tjaalton, yes
<tjaalton> smb: sweet
<smb> pitti, If it is an relief for you, I am running most of it for quite a while now
<G> pitti: thanks for approving the lucid SRU :)
<pitti> no problem
<ricotz> pitti, hello, are ready to have a look at docky?
<pitti> smb: FYI, I'll be on vac this Friday and next week, in case there are problems with this
<pitti> ricotz: will do later; need to get back to some other work
<smb> pitti, Tbh I was planning the same for next week. :)
<pitti> smb: nice timing!
<ricotz> pitti, no problem thanks
<smb> pitti, hehe
<tjaalton> pitti: yep, built fine with that change
<tkamppeter> pitti, where are the seeds for Ubuntu originally defined? In ubuntu-meta? Or is ubuntu-meta only a machine-generated derivative of the original definitions?
<cjwatson> the latter.  lp:~ubuntu-core-dev/ubuntu-seeds/platform.maverick lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick
<tkamppeter> cjwatson, thank you.
<cjwatson> the update script in ubuntu-meta generates it (mostly by just calling germinate-update-metapackage)
<htorque> hello, i'm looking for the right package to report a bug on: whenever the X server fails to start, i'm stuck at the plymouth splash screen (five red dots, system only reacts to sysrqs) rather than getting a login prompt.
<raphink> htorque: I'd say upstart
<raphink> just a guess though
<G> raphink: I was thinking more plymouth/xorg package for relevant video card
<G> it sounds like more a framebuffer issue
<raphink> G: the problem is not that X doesn't start, it is that it doesn't switch to a console login
<htorque> exactly
<G> well the thing is, plymouth really does start X
<raphink> so it seems the problem is in dependency resolution of starting services
<G> so it's more the transition isn't working
<raphink> plymouth starts X and fails
<G> htorque: out of interest, what Xorg/vid card are you running?
<raphink> then plymouth should still die and leave the user with a way to log in
<htorque> G: nvidia 6600 gt
<htorque> i can reproduce this by just renaming the device driver in xorg.conf to something bogus
<G> htorque: try booting with "nomodeset" before filing a bug
<apachelogger> james_w`: hi, what do you make of http://paste.ubuntu.com/486741/
<james_w`> apachelogger: fixed in the next version I believe
<apachelogger> james_w`: I'll try trunk then ... merging all of core kde manually is a bit horrible ... thanks :)
<james_w`> apachelogger: should be http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/471
<apachelogger> james_w`: yay, works :)
<james_w`> good
<cjwatson> manjo,cking,superm1: interesting progress on figuring out what's wrong with EFI boot on this Dell laptop
<cjwatson> firstly, the grub newreloc branch doesn't help
<cjwatson> however, booting a 32-bit kernel rather than a 64-bit kernel works just fine
<cking> cjwatson, that's very useful data point. wonder why that is
<cking> cjwatson, so the 64 bit kernel is being executed and hangs, or just never gets executed?
<cjwatson> cking: I can check again, but I believe your beeping kernel reached the beeps
<cjwatson> er, led-flashing, that is
<cking> cjwatson, hrm. Have you tried booting into a non-debug 64 bit kernel?
<cjwatson> I've tried the one that's on the maverick server amd64 CD, which I assume is non-debug
<SpamapS> ttx: question about bug 625882
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/625882)
<SpamapS> bug 625882
<ubottu> Launchpad bug 625882 in libdbi (Ubuntu) "libdbi0: ABI breakage without package name change" [High,New] https://launchpad.net/bugs/625882
<SpamapS> ttx: upstream released a fixed version that is just the ABI bump...
<ttx> SpamapS: sounds good. want it targeted against Maverick ?
<SpamapS> ttx: but now it would seem we need to rebuild everything that build-deps on libdbi0-dev ..
<ttx> uh
<SpamapS> ttx: the issue is that libdbi0 has broken error codes
<ttx> SpamapS: how many packages would that be
<SpamapS> ttx: source packages, I think 9
<SpamapS> ttx: total binary packages depending on libdbi0 is like 15
<ttx> SpamapS: that still sounds like a worthwhile goal
<ttx> SpamapS: but you should run it past the release team (I'd suggest, after beta release)
<ttx> SpamapS: I can do that for you on the release meeting if you don't get hold of them before.
<SpamapS> ttx: is there a build-depends version of 'apt-cache rdepends' ?
<ttx> hm, it's all in universe
<ttx> ah no, some MIR was done on it
<ttx> SpamapS: there is a tool, I think in ubuntu-dev-tools
<ttx> I would check it out if I weren't deep in eucalyptus mud right now
<SpamapS> ttx: yes libdbi had to be MIR'd because of rrdtool's dependence
<SpamapS> ttx: no worries, I'll ask the release team what they think.
<SpamapS> pitti: looking into that key error now. I think I have a fix
<pitti> SpamapS: ah, thanks
<SpamapS> pitti: just pushed to lp:~clint-fewbar/launchpad-work-items-tracker/parallel-reports
<SpamapS> pitti: I don't think I ever let my run all the way to the global reports. oops. :-/
<pitti> SpamapS: merged, thanks!
<SpamapS> pitti: hopefully the thing runs a bit faster now?
<pitti> SpamapS: I don't know, it doesn't tell me the time
<pitti> but I suppose it does
<jacekmigacz> Question about GDM: how to get a pointer for structures hidden under the hood as priv attributes? For example how to aquire GdmGreeterSession.panel?
<SpamapS> pitti: well given that all 3 are relatively similar in CPU/IO needs, and that they only read from the sqlite db (so no blocking on eachother AFAIK), it should mean nearly 3x improvement. ;)
<ricotz> pitti, hello, do you have time for a sru?
 * pitti is in meeting, later
<cjwatson> cking: any suggestions for where I might go from here?
<cjwatson> I'm not perhaps entirely stuck but getting pretty close
<cjwatson> cking: are we going to have to bisect LED-flashing at various points or something gross like that?  I've confirmed that the LED-flashing kernel you gave me at the sprint does indeed flash the LEDs
<cking> cjwatson, this is the point where I boot with quiet and splash disabled - if I don't get any console output then I fall back to putting flashy LED code into the kernel in the initial boot stages to see where it fails
<cjwatson> I've not been using quiet or splash at all
<cjwatson> could I have the exact patch you used for http://kernel.ubuntu.com/~cking/uefi/?  I couldn't see exactly how to plumb in your assembler
<cking> cjwatson, lemme dig it up
<SpamapS> cjwatson: Curious about something regarding openssh. Is there any reason the upstart job doesn't run it with -D (so that it doesn't have to use expect fork) ?
<cking> cjwatson, email'd
<cjwatson> SpamapS: I don't recall.  Probably because I don't regard 'expect fork' as a particular hardship and wanted to keep it as close to the same as prior init scripts as possible
<SpamapS> cjwatson: sounds reasonable. One issue I'm seeing is that if you break the config file, and do 'start ssh' the start command returns as successful....which is confusing.
<cking> cjwatson, however, I think one needs to shove the LED flashy code into x86_64_start_kernel() in  arch/x86/kernel/head64.c - also, I suggest using earlyprintk=vga
<cjwatson> will vga work here?
<cking> cjwatson, not 100% sure. It's been a while since I had to resort to this.
<cjwatson> doesn't appear to do much with an unmodified kernel
<cking> cjwatson, that's why it's probably best to see if the kernel made it through x86_64_start_kernel() with flashy LEDs as a starting place
<manjo> cjwatson, just sent you info in a mail
<pitti> robbiew, cjwatson, skaet: FYI, I just documented the broken USB 3G cards in tech notes; not sure whether you consider it important enough for that, if not, please just kill it again (or ask me to do that)
<robbiew> pitti: thnx...I think it's worth keeping in
<pitti> (fix is sitting in unapproved)
<skaet> pitti,  thanks!
<seb128> hey skaet, how are you?
<skaet> seb128,  doing well.  Watching how it all comes together, and helping where I can.
<seb128> skaet, excellent
<pitti> skaet: so you are currently absorbing all the MilestoneProcess, BetaProcess and "how to unscrew the archive" bits? :-)
<skaet> pitti,  yup trying to.  firehose is on full ;)
<seb128> jdstrand, bug #627812
<ubottu> Launchpad bug 627812 in gdm (Ubuntu) "GDM restarts when pressing SHIFT+2" [Low,Incomplete] https://launchpad.net/bugs/627812
<seb128> that seems similar to the plymouth race pitti debug in portland last year
<seb128> pitti, ^ remember the gdm crashing on first enter use we had in portland?
<pitti> seb128: yes, I do
<seb128> we started receiving quite some bugs about that for a week
<pitti> the keystrokes went to both gdm and the underlying console with a getty underneath
<seb128> do you know if there is anything which changed recently which could introduce back that issue?
<pitti> because gdm wasn't started on vt7 initially
<pitti> we still have an ugly hackish patch for this
<seb128> jdstrand, ^ can you verify on what vt gdm is started?
<seb128> pitti, I'm wondering if some update broke that
<pitti> seb128: I'm not aware of anything
<seb128> pitti, we got 5 bugs this week that seem similar
<pitti> doesn't happen here, anyway
<seb128> pitti, ok thanks
<seb128> I don't have it either
 * pitti checks bzr
<seb128> jdstrand, I meant bug #626723
<ubottu> Launchpad bug 626723 in xorg-server (Ubuntu) "gdm restarts on initial login" [Undecided,Confirmed] https://launchpad.net/bugs/626723
<pitti> jdstrand: and, do you have /var/run/gdm/firstserver.stamp ?
<pitti> jdstrand: ^ take care, that dir is not readable for users, so you need sudo ls
<shadeslayer> kenvandine: around? :D
<kenvandine> shadeslayer, hey
<shadeslayer> hey
<shadeslayer> kenvandine: i was told you work on gwibber
<kenvandine> yup
<shadeslayer> so what are you doing about the OAuth switch for lucid?
<kenvandine> about to upload to -proposed
<shadeslayer> ok
<kenvandine> did a stable release last night
<shadeslayer> since choqok has a similar problem
<kenvandine> seems a bunch of clients are broken
<seb128> pitti, thanks, I've asked that on the bugs as well
<shadeslayer> ill be requesting a upload to proposed as well
<kenvandine> we just got twitter to agree on a compromise a few days ago... not sure what choqok is doing about the consumer key
<shadeslayer> kenvandine: choqok 0.9.90 has OAuth support
<shadeslayer> but now i need 2 SRU's , qoauth and choqok
<jdstrand> pitti: I do have /var/run/gdm/firstserver.stamp
<jdstrand> seb128: tty8
<jdstrand> $ sudo lsof -p 4093 | grep tty
<jdstrand> Xorg    4093 root    7u   CHR                4,8      0t0       4616 /dev/tty8
<jdstrand> let me see something...
 * jdstrand -> reboots
 * jdstrand -> back
<superm1> cking, cjwatson i should be able to help get a port replicator that works on a e6410 if you would like me to help do some instrumentation / debug over serial rather than you having to mess around with the meaning of different beeps or LED flashes
<cking> superm1, that's v.useful
<jdstrand> seb128, pitti: ok, please see comment #9 in bug #626723
<ubottu> Launchpad bug 626723 in xorg-server (Ubuntu) "gdm restarts on initial login" [Undecided,Confirmed] https://launchpad.net/bugs/626723
<seb128> jdstrand, ok, seems a different issue then
<seb128> jdstrand, the stracktrace in the log suggests xorg quits but not sure why
<skaet> ogasawara, could you check if bug 605619 still needs to be documented in the release notes from the linux perspective?   grub2 is resolved, but I can't tell if something needs to be done on linux side or not.
<ubottu> Launchpad bug 605619 in linux (Ubuntu) "display goes to sleep while system is in use" [Undecided,Invalid] https://launchpad.net/bugs/605619
<skaet> urk.
<skaet> bug 605614
<ubottu> Launchpad bug 605614 in linux (Ubuntu Maverick) "[ATI] GPU lockup with gfxpayload=keep" [Undecided,New] https://launchpad.net/bugs/605614
<cjwatson> skaet: it's still open because it needs to be cleared up for natty, as we'd like to turn that grub2 option back on (enables smooth visual transition from the bootloader to the OS), but it's no longer an issue for maverick
<ogasawara> skaet: I don't believe it needs a release note from a linux package perspective since the the kernel issue was trigged if gfxpayload=keep, and grub2 switched back to gfxpayload=text for Maverick
<skaet> cjwatson,  thanks,  will edit out of notes then.
<ogasawara> skaet: but like cjwatson said, we want to keep the linux task open for Natty
<skaet> ogasawara,  thanks.
<skaet> cjwatson,  bug 612370 looks like its in,  ok to edit out that comment as well?
<ubottu> Launchpad bug 612370 in sqlite3 (Debian) "Sync sqlite3 3.7.0-1.1 (main) from Debian unstable (main)" [Unknown,Confirmed] https://launchpad.net/bugs/612370
<SpamapS> Hmm, so if I am renaming a -dev library (from libdbi0-dev to libdbi-dev) .. should I use Replaces, Conflicts *and* Provides? Packages that build-depend on libdbi0-dev will build just fine w/ libdbi-dev ...
<hunger___> cjwatson: sash works again! Thanks!
<ricotz> cjwatson, hi, do you have time for a sru?
<ScottK> SpamapS: I think Replaces/Breaks these days.
<soren> Does anyone happen to have a launchpad-driven daily build of anything for Maverick that works?
<soren> I have one that doesn't, and I'd like to see one that does work so that I can work out what the difference is.
<superm1> cking, cjwatson here's the output from a serial console: http://paste.ubuntu.com/486907/
<manjo> superm1, were you able to install maverick on EFI based system ?
<manjo> superm1, or did you have to hack ?
<superm1> manjo, that's booting from the amd64 daily in efi mode
<superm1> with serial console enabled
<manjo> superm1, reason I ask is yesterday I was not able to install
<manjo> superm1, this is live CD ?
<superm1> yes
<manjo> ah
<manjo> ok
<cking> superm1, looks like the calls to the EFI firmware are screwing up badly there
<manjo> superm1, what version of EFI ?
<manjo> 2.1 ? 2.3 ?
<superm1> how can I check?
<cking> concurs with what cjwatson was seeing, e.g. it's fairly early in the kernel boot, just after  x86_64_start_kernel() was entered
<manjo> superm1, should say in your bios I guess
<superm1> manjo, not seeing it anywhere in the firmware settings at least
<manjo> superm1, I have a fairly new intel engg test bed with 2.1 and live CD works fine with 2.1
<manjo> when I hit F2 to get to fw
<manjo> I see Bearlake Release # and EFI2.1.0 PI1.0 x64
<superm1> i suspect that is obfuscated from the stable firmware release on this machine
<manjo> superm1
<manjo> superm1, go to EFI shell and type ver
<superm1> manjo, the efi shell is disabled for customer BIOSes
<manjo> superm1, you can select boot manager
<manjo> superm1, :)
<manjo> ok
<manjo> superm1, I think you load the legacy bios 1st, then use duet to do EFI, which intel EFI guru says can cause memory map issues, leacy does not have any memory map, so using duet to do memory map later you might have issues. Intel says only dell does this, and duet is not recommended to use on productiuon systems.
<manjo> superm1, so this could be a dell EFI implementation issue you are hitting
<superm1> however EFI worked with Windows 7...
<superm1> i'm not sure on the actual implementation detail here though if duet was used
<manjo> yeah they say using duet can cause strangeness.. if it works on their waybridge implenentation then it should be the duet memorymap that is causeing the problems
<manjo> superm1, can you check with your bios ppls ?
<superm1> sure, i'll see what i can find out
<ni|> what is the next version after lucid called?
<ni|> 10.04 broke my portrait monitors for 3d accell and i want to try that before doing the whole crazy video song and dance
<jpds> ni|: maverick.
<ni|> anyone run portrait monitors?
<ni|> nobody seems to know how to get proper acceleration
<ni|> everything is fine in Normal mode; however, when i run orientation left everythign esplodes and goes really slow
<ni|> i'm running Gallium and all.
<ni|> (radeon)
<cjwatson> skaet: 612370> looks fair enough to remove
<cjwatson> hunger: glad to hear it
<cjwatson> superm1: oho, information.  must get myself a serial console setup ...
<SpamapS> ScottK: on Breaks/Replaces vs. Conflicts/Replaces/Provides , my thinking is that anything that will build against libdbi0-dev will also build against libdbi-dev .. and according to debian policy, thats the correct way to make sure there's only one of something that is installed and provides the same dependencies.
<SpamapS> ScottK: IIRC, breaks is more for packages that configure the system in incompatible ways
<lifeless> SpamapS: breaks/conflicts is not about configuration
<lifeless> SpamapS: its about what phase of the dpkg transaction the graph incompatibility is permitted at
<SpamapS> "When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks be installed unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured."
<lifeless> yes
<lifeless> configuration in the very narrow sense of debian policy, not in the sense of 'oh, and I put my files in /srv'
<lifeless> a configured package isn't necessarily useful, but it is in a valid state to *run*
<SpamapS> right, in the maintainer scripts configure, etc. right?
<cjwatson> SpamapS: there was a recent change to Debian policy to be explicit that Breaks+Replaces is better than Conflicts+Replaces in nearly all situations.
<lifeless> cjwatson: \o/
<cjwatson> that's what ScottK is referring to.
<lifeless> cjwatson: I must have missed that update going by
<cjwatson> 3.9.0 or thereabouts I think
<SpamapS> cjwatson: In this case, I also want to Provide the old package, since anything that build-depends on libdbi0-dev will build just fine w/ libdbi-dev... or should we just force the issue and make all of them change their control files?
<cjwatson> the only reason Conflicts was needed with Replaces was to stop you going back to the old version with the replaced files, and the agreement on -policy was that Breaks was sufficient for that.  This is *independent* of anything to do with Provides.
<SpamapS> as I type that, it seems its better to fix all the build-depending source packages rather than have them silently build against libdbi-dev.. :-P
<cjwatson> Providing a specific version of a library in a different version seems kind of evil though.
<SpamapS> well the original author should have named it libdbi-dev .. but didn't, they named it libdbi0-dev...
<cjwatson> libdbi0-dev Provides: libdbi-dev would be reasonable; libdbi-dev (unless it's version 0) Provides: libdbi0-dev is kind of weird
<lifeless> yeah
<SpamapS> totally agree
<cjwatson> if it's still version 0 or otherwise API-compatible then I think it's fine
<cjwatson> as in if it's just a renaming, not associated with a major version bump
<superm1> cjwatson, tomorrow manoj said he is going to come on site to see the panic in person and use mine.  http://accessories.us.dell.com/sna/products/Docking_Station/productdetail.aspx?c=us&l=en&s=bsd&cs=04&sku=430-3114&mfgpid=206120&chassisid=8560 is the one you are looking for (there is a simple one too,  but it doesn't include serial)
<SpamapS> and we have to touch all the build-rdepends anyway because they may be using libdbi0=0.8.3, which is not ABI compatible with libdbi0=0.8.2, which they most likely built against
<SpamapS> cjwatson: I'm for clarity over magical build successes, so I'll drop the provides, and change conflicts to breaks.
<cjwatson> I can't say I'm keen on paying $200 just for sercon ;-)
<cjwatson> sorry and all that ;-)
 * tyarusso needs to learn about the SRU process - about to go read docs, but feel free to chime in if you want to walk me through it.
<cjwatson> manjo: if you're still around, at the moment, bug 627672 is much more urgent than any of the EFI things
<ubottu> Launchpad bug 627672 in ubiquity (Ubuntu Maverick) "[Maverick Beta] install from USB stuck retrieving files 2/6 Hp Mini" [High,New] https://launchpad.net/bugs/627672
<cjwatson> (and has a pending request for information)
<manjo> cjwatson, ack
<tyarusso> Grrr.  The wiki's SRU page sounds a lot like this (bug-fix update to Nagios) won't qualify.  Lots of bug fixes though.  Feel free to look if you're bored - http://sourceforge.net/mailarchive/message.php?msg_name=4C7EC89C.5070604%40nagios.org
<tyarusso> meanwhile, I should go home.
<manjo> cjwatson, I am going to add those debug info mario requested
<manjo> cjwatson, will do it right now
<SpamapS> hmm.. isn't it a very broken thing if a shared lib has the .la file in it?
<SpamapS> shouldn't that file be in the -dev package?
<cjwatson> manjo: thanks
<manjo> cjwatson, complete logs uploaded with debug-ubiquity as superm1 requested.
<manjo> to bug 627672
<ubottu> Launchpad bug 627672 in ubiquity (Ubuntu Maverick) "[Maverick Beta] install from USB stuck retrieving files 2/6 Hp Mini" [High,New] https://launchpad.net/bugs/627672
<superm1> manjo, peculiar, is your usb disk missing  /cdrom/dists/maverick/main/binary-i386/Packages ?
<superm1> and if so, do you have any idea what would could have caused that in the first place (did you manually extract the ISO on the stick and forget it, or anything like that)?
<manjo> nope I just used usbcreator and make that stick
<manjo> I can try it again with todays iso
<superm1> did you set the persistence option when you made it?
<manjo> I don't recall
<cjwatson> I think that's a red herring, don't we usually see that message?
<cjwatson> I'd expect only /cdrom/dists/maverick/main/binary-i386/Packages.gz
<superm1> oh right.
<manjo> ok so I am off the hook :)
 * manjo goes back to collecting logs for cjwatson on uefi 
<cjwatson> manjo: do you still have this system booted?
<cjwatson> the one with the USB stick
<manjo> cjwatson, just turn it off...
<manjo> I can reboot and restart the install if you want
<cjwatson> manjo: at the point where it fails, can you see if /target/etc/apt/apt.conf.d/00NoMountCDROM exists, and if /target/cdrom is mounted?
<cjwatson> sorry, my reactions were too slow :)
<manjo> np let me resrtar the install .. will take a few mts
<cjwatson> I'm wondering if apt-cdrom's configuration changed or something
<manjo> cjwatson, I can use todays iso if that makes any diff ...
<manjo> but its booting now and I will be able to ans your Q
<cjwatson> first law of debugging, don't introduce unnecessary variables
<cjwatson> well maybe not first, but certainly well up there
#ubuntu-devel 2010-09-02
<manjo> cjwatson, just booted, /target/etc... does not exist
<manjo> and I don't see /target/cdrom...
<cjwatson> manjo: it won't exist until you run through the installer to the failure point
<manjo> do I need to start the install to see that  ? \
<manjo> ah I thought so
<cjwatson> nothing under /target exists until then
<manjo> pita
<manjo> cjwatson, install in progress.. will take a few mts
<cjwatson> not seeing any relevant changes in apt
<manjo> cjwatson, oh! no! it finished install
<manjo> cjwatson, it worked this time
<manjo> cjwatson, let me try again
<manjo> cjwatson, sent you /var/lib/partman/devices/* tgz
<cjwatson> thanks
<manjo> cjwatson, do you need anything else from that machine? can I power if off ?
<manjo> cjwatson, superm1 sorry I can't reproduce it anymore
<manjo> cjwatson, superm1, my 2nd time around install going though
<cjwatson> manjo: the UEFI one?  go ahead and power it off
<manjo> cjwatson, thanks
<cjwatson> manjo: those logs match my prediction
<cjwatson> so it's a simple matter of programming to fix
<manjo> cjwatson, on the hp mini I can reproduce it anymore
<cjwatson> manjo: regarding the USB installation: just a hunch, but do/did you have persistence enabled in usb-creator?
<cjwatson> I'm reading through apt's code for identifying CD-ROMs
<manjo> cjwatson, sorry I don't recall... iirc I think I did
<manjo> I always do ... so I must have 90% sure
<cjwatson>       // We use a kilobyte block size to advoid overflow
<cjwatson>       sprintf(S,"%lu %lu",(long)(Buf.f_blocks*(Buf.f_bsize/1024)),
<cjwatson>               (long)(Buf.f_bfree*(Buf.f_bsize/1024)));
<cjwatson>       Hash.Add(S);
<cjwatson> the code above assumes that CDs are read-only and never change
<manjo> ah
<cjwatson> but a USB stick with persistence enabled might change its free blocks count
<cjwatson> I'd suggest you try another patch and see if it makes a difference, but ...
<manjo> cjwatson, let me recreate this USB stick and try again... I will update the bug with that info you assked me earlier about /target/... and mount /target etc
<cjwatson> yes, I bet that creating it from scratch will make a difference
<cjwatson> this is only a guess - I just can't see anything else that would matter
<manjo> right ... I am on it
<cjwatson> not entirely sure what to do about it
<cjwatson> setting Debug::identcdrom=true during installation would probably avoid it, at the cost of making that entry in apt-cdrom's database invalid for later use
<kklimonda> hmm, apt-get autoremove is broken..  debian bug 594689 - is it on the radar?
<ubottu> Debian bug 594689 in apt "apt 0.8.0 breaks autoremove" [Important,Open] http://bugs.debian.org/594689
<manjo> cjohnston, creating  persistence of 351 mb
<cjwatson> kklimonda: better wait until mvo is aroundd
<cjwatson> -d
<manjo> cjwatson, creating  persistence of 351 mb
<kklimonda> cjwatson: ok, will ask him. thanks :)
<cjwatson> manjo: http://paste.ubuntu.com/487007/ applied to /usr/share/ubiquity/plugininstall.py may deal with it
<cjwatson> if my hypothesis is true
<manjo> cjwatson, ok will try that in a sec ... booting new usb stick with persistance & todays iso
<cjwatson> I think it is coffee time
<ev> nice catch
<cjwatson> does persistence work the way I'm recalling?  the free blocks count on statvfs("/cdrom") would change?
<manjo> cjohnston, ok hit the problem now
<manjo> cjwatson, ^
<Edgan> pitti: Can you tell me what kernel version-release is supposed to have gone into lucid-proposed for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092 ?
<ubottu> Launchpad bug 585092 in linux (Ubuntu Lucid) "giant IO delays on unmount" [Medium,Fix committed]
<manjo> cjwatson,  /target/etc/apt/apt.conf.d/00NoMountCDROM exists
<manjo> cjwatson, /target/cdrom mounted -- yes
<manjo> cjwatson, I have the system live right now if you need me I am around
<manjo> cjwatson, with that change to .py does ubiquity needs to be restarted ? if so how do I restart it ?
<manjo> cjwatson, I am guessing your ans will be .. new iso needs be created with that change ?
<cjwatson> manjo: I'm afraid it's re-create USB stick from scratch, boot to live session, patch that file on the fly, then start the installer
<cjwatson> manjo: normally it would be easier, but since this is so delicate with regard to persistence I think we have to be safe
<cjwatson> manjo: well
<cjwatson> manjo: maybe it would be worth applying it on the fly now and running, since that would be a quicker way to weed out any stupid mistakes I may have made, but it won't be a full test
<manjo> cjwatson, ack will try that
<cjwatson> maybe best to reboot
<cjwatson> so reboot to live session, patch on the fly, start installer; then, re-create USB stick from scratch, boot to live session, patch that file on the fly, then start the installer
<manjo> cjwatson, so 2 tests
<cjwatson> yeah
<manjo> ok
<cjwatson> sorry it's time-consuming
<manjo> yep np
<manjo> glad I can help
<manjo> cjwatson, so its way past your bed time I am guessing
<manjo> its almost time to wake up and make coffee :)
<cjwatson> especially as my stepson starts secondary school tomorrow
<manjo> I think I trashed my disk on the last reboot, let me recreate it again
<manjo> cjwatson, sorry could not do your 1st test coz my usb stick was trashed by the prev install attempt, so I have to recreate it and patch the file on the fly and start ubiquity -d
<manjo> cjwatson, install is making progres ... will update you shortly
<cjwatson> ok, the first test was just an optimisation attempt anyway
<cjwatson> thanks
<manjo> cjwatson, its past that point .. so I think you did it .. will tell you for sure when its done installing
<cjwatson> that would be quite a relief if so
<manjo> cjwatson, install complete
<manjo> cjwatson, do you need any logs ?
<manjo> I did start with -d so you could have more info
<cjwatson> syslog and installer/debug would be good just to check
<manjo> ok
<manjo> will mail those to you
<cjwatson> thanks so much - I know this has been a time-consuming tet
<cjwatson> *test
<manjo> cjwatson, no thank you
<manjo> cjwatson, logs in the mail
<cjwatson> confirmed that that did the right thing
<cjwatson> committed
<cjwatson> superm1: I have an idea what might be going on.  Will try a few things tomorrow
<hv> hi. where should I channel my frustration about idiosyncrasies in maverick's gtk theme?
<crimsun_> perhaps a[n existing] bug report on light-themes?
<hv> (I have specific lines I would like to change in /usr/share/themes/Ambiance/gtk-2.0/gtkrc)
<hv> *sigh*, that does not make me feel any better.  I'll try anyways ...
<hv> btw, do they have an irc channel?
<crimsun_> perhaps http://lists.ubuntu.com/mailman/listinfo/ubuntu-art and #ubuntu-artwork
<hv> thanks.
<hv> well, it's a ghost town there.
<hv> are both themes (Ambiance and Radiance) designed to be light themes?
<crimsun_> hv: IIRC the former certainly isn't
<hv> they have hardcoded light colors (e.g., I can see #e2e1e1) in the gtkrc file.  Are there kids designing the themes again?
<hv> (few years ago there were a few kids designing the themes)
<superm1> cjwatson, re EFI  on the 6410 i'm assuming?  well if you need any additional debugging output from serial console with what you have in mind, just lemme know
<superm1> manjo, i've received confirmation that the implementation on the 6410 is not via DUET, it is native.
<robert_ancell> Is there an easy way I can get what's in the upload queue?
<ejb> what's the easiest way to get the lucid kernel source?
<cody-somerville> robert_ancell, https://edge.launchpad.net/ubuntu/maverick/+queue
<robert_ancell> cody-somerville, thanks, now I just need to work out if I can get that via launchpadlib
<cody-somerville> robert_ancell, I think you need to call getPackageUploads on a distro_series
<robert_ancell> awesome, just what I need
<robert_ancell> cody-somerville, I get a series_collection_link, how do I convert that into a series collection?
<robert_ancell> go it: launchpad.distributions['ubuntu'].getSeries(name_or_version='maverick').getPackageUploads().  Trial and error is the winner of the day!
<lifeless> robert_ancell: what do you need the upload queue for?
<robert_ancell> lifeless, updating http://people.canonical.com/~seb128/versions.html so it shows packages that are in the upload queue as up to date
<TheMuso> ejb: Go to http://kernel.ubuntu.com/git and find the ubuntu-lucid git tree, and clone it.
<ejb> Anyone know of good up to date tutorials on writing kernel modules?
<ejb> I want to disassemble a function in my kernel but there aren't symbols... is there a symbol file that I can load into gdb?
<RAOF> ejb: Yup.  linux-image-$(VERSION)-dbgsym is, or should be, available from the dbgsym repository.
<pitti> Good morning
<pitti> Edgan: 2.6.32-25.43
<ricotz> pitti, good morning
<ricotz> hello, could someone have a look at this sru? https://bugs.edge.launchpad.net/docky/+bug/584094
<ubottu> Launchpad bug 584094 in docky (Ubuntu) "Non-square items dont properly darken" [Undecided,New]
<tkamppeter> pitti, hi
<iainfarrell> sladen: ping
<pitti> hello tkamppeter
<cjwatson> kenvandine: any reason for reopening bug 627565 in maverick?
<ubottu> Launchpad bug 627565 in gwibber (Ubuntu) "Twitter dropping support for basic auth" [High,Triaged] https://launchpad.net/bugs/627565
<seb128> cjwatson, he's probably sleeping but that seems a bug triaging mistake to me
<cjwatson> can wait 'til he wakes up
<pitti> ricotz: have a question in bug 584094
<ubottu> Launchpad bug 584094 in docky (Ubuntu Lucid) "Non-square items dont properly darken" [Undecided,New] https://launchpad.net/bugs/584094
<pitti> ah, I just got confused about gwibber, seems cjwatson beat me to it
<tkamppeter> pitti, I have found a possible apport bug.
<tkamppeter> pitti, see bug 628030. Here ghostscript segfaults but probably apport did not pop up therefore, as the user has called apport through the printing infrastructure (probably the failed job pop-up).
<ubottu> Launchpad bug 628030 in ghostscript (Ubuntu) "Cannot print from pdf, /usr/lib/cups/filter/pdftoraster failed" [High,Confirmed] https://launchpad.net/bugs/628030
<ricotz> pitti, i was having lunch, i commented on your question
<sladen> iainfarrell: morning
<lool> pitti: Could you please remove the lucid-proposed gallery2 package immediately?
<lool> the current upgrade path allows for the lucid version's postrm to rm -rf /usr/share/gallery2 /etc/gallery2
<lool> LP #578137
<ubottu> Launchpad bug 578137 in gallery2 (Ubuntu Lucid) "gallery2 2.3 php 5.3 incompatibility" [Undecided,Fix committed] https://launchpad.net/bugs/578137
 * lool is a bit pissed of from that rm -rf /
<azeem> lool: "rm -rf /" sounded *really* bad for a second
<lool> I think it's pretty much the last straw; I will give up on gallery2
<lool> I'm happy that it was in a vm  :-)
<pitti> lool: I thouht that was intended, and the preinst makes a backup?
<pitti> ricotz: replied
<pitti> lool: ah, saw your reply
<pitti> lool: done
<lool> Thanks
<pitti> tkamppeter: hm, I need /var/log/apport.log for that
<ricotz> pitti, replied
<pitti> ricotz: this needs fixing in maverick, too; do you plan to upload to Debian and have it synced? or direct U upload?
<ricotz> pitti, i have planned to do so, but there are some other new mono packages coming which needs some packaging and buildsys changes
<ricotz> pitti, so these new packages should go in first which are also needed for banshee 1.7.5
<pitti> ricotz: understood
<tkamppeter> pitti, I have asked the user in bug 628030 now.
<ubottu> Launchpad bug 628030 in ghostscript (Ubuntu) "Cannot print from pdf, /usr/lib/cups/filter/pdftoraster failed" [High,Confirmed] https://launchpad.net/bugs/628030
<tkamppeter> pitti, when I reproduced bug 628030, I had exactly the same problem as the original poster, only pop-ups for the failed job, not for the segfault. I have mailed my apport.log to you now.
<ubottu> Launchpad bug 628030 in ghostscript (Ubuntu) "Cannot print from pdf, /usr/lib/cups/filter/pdftoraster failed" [High,Confirmed] https://launchpad.net/bugs/628030
<pitti> tkamppeter: "report /var/crash/_usr_bin_gs.1000.crash already exists and unseen"
<pitti> tkamppeter: so it seems apport does pick up the crash, but since you didn't look at the previous one yet, you don't get a new one
<albertz> hi. is this the right place to ask for help on the xserver? or in #ubuntu-app-devel? i am working on a mouse wheel acceleration patch
<seb128> cjwatson, do you have any opinion on bug #618281? ie the update for this cycle?
<ubottu> Launchpad bug 618281 in ntfs-3g (Ubuntu) "NTFS-3G: A new upstream version is available: 2010.8.8" [Undecided,New] https://launchpad.net/bugs/618281
<seb128> cjwatson, I'm just trying to clean the nominated bugs list
<cjwatson> keeping ntfs-3g up to date usually works out to be a good plan
<seb128> so I accept the nomination
<seb128> thanks
<cjwatson> it does have new features but they seem mostly mount-option-controlled
<cjwatson> or "if you don't have this then your filesystem won't work anyway"
<tkamppeter> pitti, reporter of bug 628030 hass attached apport.log.
<ubottu> Launchpad bug 628030 in ghostscript (Ubuntu) "Cannot print from pdf, /usr/lib/cups/filter/pdftoraster failed" [High,Confirmed] https://launchpad.net/bugs/628030
<dholbach> cjwatson, hey Colin - how are you doing? Who can change which packageset a package belongs to? do we still have mismatches between package-in-packageset and seeds every now and then?
<cjwatson> respectively: fine, thanks; theoretically TB but in practice me; yes
 * dholbach hugs cjwatson
<StevenK> cjwatson: Hi, do you have time today to talk about a change I'm doing for initialising a new distroseries?
<dholbach> thanks Colin - I just asked because of the current discussion on ubuntu-devel@
<geser> dholbach: the owner of the packageset can change it and the owner of most packagesets is the TB (the DMB only owns the mozilla and zope package set). So asking cjwatson is always right :)
<dholbach> great, I just didn't want to reply to the mail saying "yeah, just ask Colin to fix it"
<cjwatson> StevenK: I would suggest choosing a day other than beta release day
<cjwatson> dholbach: I'll catch up on it after beta release
<tkamppeter> pitti, it seems that I have found a solution for most of the problems where Ghostscript fails when used with the CUPS Raster device: CUPS should not se a RIP_MAX_CACHE at all, not even a big one like 1/4 of system memory, simply none at all so that Ghostscript determines its memory use by itself. Then Ghostscript always works correctly.
<StevenK> cjwatson: Since moving to Launchpad I've lost track of the special Ubuntu days, sadly. Is tomorrow okay?
<cjwatson> yes
<dholbach> cjwatson, sure
<dholbach> geser, cjwatson: thanks
<tkamppeter> pitti, in CUPS one can easily implement it by defaulting the cache to an invalid value, like "auto".
<soren> Uh... If I'm runnig "apt-get dist-upgrade -fy" I shouldn't be asked about modified conffiles, should I?
<kenvandine> cjwatson, thx for gwibber
<Keybuk> grr @ bzr
<Keybuk> bzr log should invoke $PAGER
<Laney> there's a plugin for thatâ¢
<dholbach> geser, if a package moves into the 'sugar' packageset, who can upload it?
<ogra> all the sweet guys and gals :)
<chrisccoulson> lol
<Laney> the union of sugar packageset uploaders and component uploaders
<geser> dholbach: https://launchpad.net/~ubuntu-sugar-uploaders is the uploaders team for that package set
<Laney> dholbach: I would love it if I could give the sponsoring page my LP ID and have it filter to the stuff I can upload
<dholbach> ok, let me follow up on the thread
<dholbach> it's time bug reports get filed
<dholbach> I wanted the discussion to be something different :)
<Laney> yeah sorry
<nigelb> Laney: +1 ;)
<Laney> I don't have any tools apart from an alias to wget -q -O- $URL | patch -p1
<geser> dholbach: btw do you have any preference on a python templating toolkit? I've started to split the code and the HTML template for the sponsoring page using Mako
<dholbach> geser, I expect that once Harvest is up and running the sponsoring page can go away
<geser> ah ok
<dholbach> maybe it can, maybe it can't, let's see
<dholbach> does the templating toolkit need anything special set up on people.c.c?
<geser> besides python-mako being installed, no
<Laney> really?
<dholbach> ok
<Laney> can I filter by type of opportunity to recover the original sponsor page?
<dholbach> Harvest is currently just waiting on IS right now and looking for contributors :-)
<dholbach> Laney, you can, but it's not up and running yet
<Laney> cool
<dholbach> bzr branch lp:harvest; less harvest/INSTALL
<dholbach> it's really trivial to set up
<dholbach> (for local testing)
 * Laney isn't really a harvesty type of developer
<Laney> although maybe I am for certain areas...
<dholbach> I'm sure you are ;-=
<dholbach> ;-)
<G> dholbach: I'll put my hand up to contributing
<dholbach> awesome, just propose a merge to lp:harvest and somebody will have a look
<dholbach> I also documented the release process, so I hope it'll be easy soon to get new releases out there: https://wiki.ubuntu.com/Harvest/ReleaseProcess â¦ once it's up and running
<G> okay, that'll be tomorrow (or more like today)
<dholbach> sure sure, take it easy :)
<G> dholbach: it's 1am, but the project will also include "learn bzr" :)
<StevenK> dholbach: You have two 'lp:~' in your template mail to RT
<dholbach> StevenK, fixing
<dholbach> G: interesting you should mention that, in the LoCo Directory team we just discussed a "getting started with LD" guide or at least short snippets
<G> LD = LoCo Directory or Launchpad Dev? :P
<G> I'm assuming LoCo
<dholbach> g: loco directory, sorry :)
<nigelb> dholbach: nifty release page
<G> dholbach: btw, what is your prefered way for merging fixes, 1 branch for each little fix, or 1 branch for a bunch of little fixes?
<dholbach> g: exactly
<dholbach> and propose a merge
<G> yeah, but for little fixes, which is the prefered number of branches (1 or X)
<dholbach> G: it's fine to bundle a few fixes if they're all obvious or better fixed in one go
<G> dholbach: okay, just wanted to check :)
<kklimonda> mvo: is debian bug 594689 on your radar?
<ubottu> Debian bug 594689 in apt "apt 0.8.0 breaks autoremove" [Important,Open] http://bugs.debian.org/594689
<mvo> kklimonda: yes, its in the apt ubuntu branch already
<kklimonda> thanks
<mvo> kklimonda: but thanks for the reminder, I will upload into the queue shortly
<ivoks> Keybuk: question; copyright in com.ubuntu.Upstart.Instance.xml; is that a bsd(ish) license?
<SpamapS> Keybuk: Is there a good list somewhere of best practices for upstart jobs?
<mvo> seb128: re bug #620297 - so did you break vte ;) ?
<ubottu> Launchpad bug 620297 in gdebi (Ubuntu Maverick) "gdebi-gtk fails with ''dpkg: unable to read filedescriptor flags...."" [Low,Confirmed] https://launchpad.net/bugs/620297
<seb128> mvo, no, but robert_ancell might have
<seb128> there is a new version in the queue as well
<seb128> if you have a bug please assign to him for investigation
<seb128> robbiew, wouldn't be useful to have a meeting after beta to know where we stand?
<robbiew> seb128: what would we discuss?  I suppose if there's an OMG bug(s), we could discuss that....but we would be discussing that tomorrow regardless
<robbiew> I'm not against having one tomorrow
<robbiew> as I'm not running it ;)
<seb128> robbiew, rather where we stand, what is the beta status, what issues have been spotted, what should get cracked for final, etc
<seb128> I guess we can wait a week for that
<seb128> but it puts us a few days before hard freeze
<robbiew> hmm
<seb128> I would imagine know is the right time to be cracking on issues that will need to be fixed in the 2 weeks coming
<seb128> know -> now
<seb128> "cracking the whip on the issues", or rather at least making people aware of the priorities
<robbiew> right
<robbiew> good point
<seb128> no skat?
<seb128> skaet rather ;-)
<seb128> oh
<seb128> skaet, hey ;-)
<seb128> skaet, how are you? I was discussing tomorrow's meeting with robbiew
<skaet> seb128,  heya.
<seb128> skaet, do you feel we should have one to check status after beta?
<robbiew> seb128: how about we have the meeting, but scale back the agenda
<robbiew> to just a status check
<seb128> just to make sure we are on track and we discuss things that need to be worked next?
<pitti> he just cancelled it, didn't he?
<seb128> pitti, well that's what I'm discussing there
<seb128> pitti, ie scrollback
<pitti> OIC
<seb128> it seems that the end of the cycle meeting are the useful ones
<lucidfox> dholbach> I don't understand where Ubuntu people get all the money for their plentiful travels all over the world o_O
<seb128> we need to make sure everybody knows what we need to do and where we stand
<dholbach> lucidfox, it's my first and only holidays this year
<seb128> robbiew, I'm fine having just a status check or no meeting, I guess your call and skaet's one
<seb128> robbiew, I would just pointing that we only have 2 weeks before hard freeze and a status update could be useful
<robbiew> seb128: ack
<robbiew> and that was very welcome ;)
<cjwatson> personally I'm not going to be much good for anything tomorrow, but ...
<robbiew> cjwatson: yeah...I figured that
<seb128> I'm sure work is mostly tracked in each team
<cjwatson> I'm OK with a status check, would rather not have to prepare a detailed report
<robbiew> exaclty
<robbiew> and "exactly"
<robbiew> I'll shoot out an invite...30min...state of the universe meeting
<robbiew> :)
<skaet> sounds good.
<seb128> yeah, I don't see the point to do a spec etc update
<seb128> just a status feedback from beta
<seb128> could help to raise some issues which are maybe not tracked
<seb128> cjwatson, robbiew, skaet: thanks
<robbiew> seb128: no..thank you :)
<seb128> ;-)
<skaet> seb128,  yup there are likely some that need discussing.   thank you.
<tkamppeter> pitti, ping
<nigelb> lucidfox: now you get an idea of how much dholbach is paid and/or how stingy he is :p
<pitti> tkamppeter: o/
<lucidfox> nigelb> That's stingy?
<nigelb> lucidfox: well, stingy to save up enough to go there I mean
<lucidfox> the only times I've been abroad were on vacations to Turkey funded by my parents when I was younger
<tkamppeter> pitti, in CUPS one can easily implement it by defaulting the cache to an invalid value, like "auto".
<tkamppeter> pitti, it seems that I have found a solution for most of the problems where Ghostscript fails when used with the CUPS Raster device: CUPS should not se a RIP_MAX_CACHE at all, not even a big one like 1/4 of system memory, simply none at all so that Ghostscript determines its memory use by itself. Then Ghostscript always works correctly.
<tkamppeter> pitti, in CUPS one can easily implement it by defaulting the cache to an invalid value, like "auto".
<pitti> tkamppeter: that won't provoke any side effects in cups, like error messages?
<pitti> but if it works, sounds nice
<pitti> I remember this one
<tkamppeter> pitti, I have modified GS upstream that with missing or invalid RIP_MAX_CACHE it determines its memory needs automagically and then it works perfectly. The change I have also backported to Ubuntu.
<pitti> tkamppeter: hm, is that only read by gs? I thought it was a cups option, not a gs one
<tkamppeter> The only other consumer of RIP_MAX_CACHE is imagetops and I have looked in the source and it defaults to 32 MB then. As it worked for years with 8MB this should not be a problem.
<tkamppeter> pitti, more a problem is that the CUPS package is also used by Debian, and Debian most probably does not have my patch in GS, so that their GS 8.71 defaults to 8MB with invalid RIP_MAX_CACHE. This means that Debian users will get a lot of problems.
<tkamppeter> pitti, so we would need switch between Debian and Ubuntu when applying the patch, or somehow get my GS patch into Debian ASAP.
<pitti> tkamppeter: you could apply the patch only in Ubuntu
<pitti> tkamppeter: look at e. g. debian/patches/ubuntu-default-error-policy-retry-job.dpatch
<pitti> tkamppeter: it has a shell script header which checks lsb_release for Ubuntu
<pitti> we already have two ubuntu specific patches there
<tkamppeter> pitti, so I make the existing patch for 1/4 of system memory Debian-only and the new patch of auto Ubuntu-only. Later on, when http://bugs.ghostscript.com/show_bug.cgi?id=691586 gets fixed, we can return to 1/4 of memory for all.
<ubottu> bugs.ghostscript.com bug 691586 in PDF Interpreter "Ghostscript segfaults when rendering a certain PDF file with the CUPS Raster device." [Major,New]
<pitti> tkamppeter: right, you could change debian/patches/dynamic-default-ripcache-size.dpatch to only apply if we are not on Ubuntu
<tkamppeter> pitti, can I do
<tkamppeter> [ "`lsb_release -is 2>/dev/null`" = "Debian" ]
<tkamppeter> to check whether the distro is Debian or should I better do
<tkamppeter> [ "`lsb_release -is 2>/dev/null`" != "Ubuntu" ]
<pitti> tkamppeter: !ubuntu, please
<pitti> tkamppeter: since we always want one or the other
<pitti> and in the other one we test == Ubuntu
<ion> Thereâs dpkg-vendor, too
<OdyX> pitti, tkamppeter, you can also use dpkg-vendor snippet
<OdyX> (which is more robust than lsb_release IMHO)
<pitti> right, it is
<pitti> I just didn't switch to that yet because it does not yet backport well
<OdyX> tkamppeter: is your gs fix important ? (aka a Release-Critical in Debian ?)
<OdyX> pitti: right
<pitti> but it's certainly much more elegant
<Keybuk> ivoks_away: it's a little known GNU licence :p
<tkamppeter> pitti, I will do the changes in the next hour or so, please do not commit to CUPS.
<pitti> tkamppeter: I won't touch it until September 13, when I'm back from vacation :) (which starts pretty much "now")
<Keybuk> pitti: enjoy!
<OdyX> tkamppeter: could you please report a bug with severity > important on the Debian BTS ?
<pitti> Keybuk: thanks! looking forward to it -- a week of bicycling, tenting, then Vienna, and no computers :)
<Keybuk> pitti: yeah, I just had a very enjoyable weekend with no computer
<nigelb> pitti: Have fun :)
<seb128> cjwatson, ev: is somebody watching ubuntu slideshow bugs?
<cjwatson> I can't say I am
<seb128> or rather is somebody working on updating those
<seb128> ie bug #628809
<ubottu> Launchpad bug 628809 in ubiquity-slideshow-ubuntu (Ubuntu Maverick) "f-spot still mentioned in installer" [Low,New] https://launchpad.net/bugs/628809
<ev> seb128: the slideshow is being redesigned for 10.10
<seb128> ev, is being? wasn't uif 2 weeks ago?
<seb128> or 1 week ago rather ;-)
<ev> it's nearly there, we just decided against putting it in beta because we wanted to land a finished product
<seb128> ev, do you have any idea when the new design will land? translators will need time to work on those
<seb128> ev, hum, ok
<ev> of course, but I don't have an ETA
<ev> Dylan is working on it with support from Roz
<seb128> ok thanks
<seb128> can you make sure the f-spot -> shotwell change is included in their work?
<ev> absolutely
<seb128> ev, thanks!
<ev> sure thing
<tkamppeter> pitti, still there?
<tkamppeter> Is the beta already out (= beta freeze over)? I did not get any e-mail and the Topic tells only FeatureFreeze.
<seb128> tkamppeter, no
<seb128> tkamppeter, see topic
<seb128> tkamppeter, but you can upload, the updates queued will go in after the freeze end
<smoser> anyone know, is there any command line interface to blueprints ?
<Keybuk> nope
<Keybuk> blueprints is the part of Launchpad that got left on the doorstep of the orphanage in a shoebox
<smoser> good deal.
<smoser> was going to try to hack something like editmoin for blueprints, but didn't want to duplicate any effort.
<ScottK> Got roughed up a bit before being dropped off too.
<tkamppeter> OdyX, hi
<OdyX> hi tkamppeter
<tkamppeter> OdyX, for Debian you should merge all Ubuntu changes (= upstream bug fix patches) into the feature-frozen version. These are all my cherry-picked bug fixes (some coded by me) from the 8.71 -> 9.00 development period of Ghostscript. 9.00 missed our Feature Freeze and is also relatively risky as it added ICC support, a big feature addition, therefore the bump of the major number.
<OdyX> tkamppeter: for ghostscript you mean ?
<tkamppeter> OdyX, in a non feature-frozen Debian version you should directly put Ghostscript 9.00.
<tkamppeter> Yes, I mean Ghostscript.
<OdyX> yeah sure, but we are in _full_freeze_ in Debian :)
<OdyX> tkamppeter: does this fix one of http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ghostscript&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no
<OdyX> or http://security-tracker.debian.org/tracker/source-package/ghostscript <- one of those ?
<tkamppeter> OdyX, what does it mean? Also bug fixes not accepted any more, only CD fixes? One week before landing?
<OdyX> tkamppeter: this means that Debian only accepts updates that fix "serious bugs" (> important)
<OdyX> tkamppeter: the freeze is slightly relaxed these days, so a good rational'ized upload can still get trough, but it has more chance if it fixes bugs without adding "risky" changes
<tkamppeter> OdyX, the mentioned bugs are not fixed (no one reported them to Ubuntu), the ones from the first link are fixed in 9.00, so a backport of the fixes could perhaps be done.
<OdyX> tkamppeter: we have a big issue here on Debian: ghostscript is basically unmaintained, so any help is greatly welcome. :(
<tkamppeter> OdyX, the most important fixes are three or four patches which fix several segfaults when the CUPS Raster output device is used with PDF input and tyhis is quite common in Debian, as CUPS is synced with Ubuntu.
<OdyX> tkamppeter: I will try to address those issues next week, but I'll need your assistance. Right now I'm too busy.
<El_Presidente> is this possible that this bisection result http://yfrog.com/n2bildschirmfotovp is the problem of my bug i filed here https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/572146
<ubottu> Launchpad bug 572146 in alsa-driver (Ubuntu) "crackling sound from microphone with 2.6.32-21 kernel" [Undecided,Incomplete]
<slangasek> kirkland: have you noticed that the update-motd files shipped by base-files aren't marked as conffiles?  lintian warns quite loudly about this now
<kirkland> slangasek: i have not noticed that
<kirkland> slangasek: is that something you'd like me to fix by RC?
<slangasek> kirkland: I think that would be advisable; should just require updates to debian/conffiles in the source package
<slangasek> (unfortunately base-files doesn't use the debhelper magic to do this for us)
<kirkland> slangasek: yeah, that package is rather old fashioned
<tkamppeter> OdyX, OK, let us sort out Ghostscript next week.
<OdyX> tkamppeter: thanks
<lifeless> marjo: hey, who runs the retracer these days?
#ubuntu-devel 2010-09-03
<lifeless> kees: around?
<kees> lifeless: in and out, sup?
<lifeless> mailed you
<kees> okay
<bcurtiswx> if i'm trying to start learning GTK+, what program(s) should I install ?
<bcurtiswx> is there a good beginners guide out there?
<bcurtiswx> nvm about what packages, got that
<fagan> bcurtiswx: this isnt a channel for app development its for discussion on developing ubuntu itself
<fagan> #ubuntu-app-devel is the one I think for that
<bcurtiswx> fagan, muchas gracias
<fagan> no problem
<bbigras> Someone knows a tutorial to create a DEB when I got an install script provided with the sources?
<fagan> bbigras: this isnt a support channel for app development in ubuntu its a channel for developing ubuntu
<fagan> you should ask your question on #motu
<fagan> or #ubuntu-motu maybe
<fagan> I forget
<micahg> bbigras: #ubuntu-packaging is more apropriate
<fagan> its late
<fagan> oh your right I forgot about that one
<fagan> well I always asked for help in #motu because theres always someone around
<bbigras> thanks but I thought ubuntu developement meant mostly packaging.
<micahg> bbigras: yes, but this channel focuses on package in the archive in main or restricted
<fagan> and development work going on
<bbigras> I see, thanks!
<fagan> features and bug fixes
<fagan> its interesting how many people come here for development help though even though it says  (not support, not app development) in the title
<dholbach> good morning
<tjaalton> hum, netgen seems to be missing from lucid, though lp shows the binaries in https://edge.launchpad.net/ubuntu/+source/netgen
<tjaalton> maybe it failed to build? the new version was released too late for lucid
<tjaalton> I'll just grab it from testing/maverick
<geser> tjaalton: FTBFS: https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries
<geser> the version in lucid got uploaded in jaunty and as we couldn't build it anymore in lucid (FTBFS in a rebuild test) the binary debs got removed
<tjaalton> geser: yeah, makes sense
<tjaalton> just that the lp page is confusing then ;)
<geser> the source is still in lucid just not the binary debs
<tjaalton> yes, but lp shows both for lucid
<tjaalton> but, lunch ->
<geser> you have to look at the binary publication page: https://edge.launchpad.net/ubuntu/lucid/i386/netgen
<wgrant> tjaalton: It shows that the binaries were built. It doesn't say they're published.
<tjaalton> wgrant: that conflicts with the removal then
<wgrant> tjaalton: Hm?
<wgrant> tjaalton: They were still built. They were just removed later.
<tjaalton> wgrant: that makes no sense? why were they removed then?
<tjaalton> wgrant: my point is that lp should not show the debs if they were removed :)
<geser> tjaalton: netgen 4.4-15 got uploaded to jaunty, and later copied (source+binary) to karmic and lucid. During lucid we noticed in a rebuild test that we can't build the package anymore and decided to not publish the binaries anymore (as we can't support them, e.g. security upload or SRU)
<cjwatson> they were in the lucid *series* at some point, just not in the 10.04 *release*
<geser> LP (or more the librarian) still have them (like other debs for superseded uploads), they just not published anymore (on archive.u.c)
<tjaalton> and _that's_ confusing
<cjwatson> it's probably best not to go through LP to find what's published in a given release unless you're pretty familiar with it.  you could just use rmadison
<tkamppeter> when is the beta freeze supposed to end?
<cjwatson> it's ended, just haven't quite reopened the archive yet.
<cjwatson> in progress on that
<cjwatson> I think I'd like to clear through binutils and eglibc first though
<\sh> could someone release the NEW queue for maverick, pls? :)
<raphink> \sh: don't you think there's enough packages already? :p
<cjwatson> \sh: not the first priority
<cjwatson> (yeesh, what is it with day-after-beta and are-we-there-yet?)
<cjwatson> james_w`: hmm, I do hope the importer isn't going to get too badly confused with me accepting packages from unapproved during codehosting downtime
<\sh> raphink, I'm just interested in one...so we can start testing maverick with FAI ;)
<lifeless> cjwatson: does anyone other than pitti know enough about the apport retracers to say if they are fixed or not
<raphink> \sh: I'm just kidding ;-)
<cjwatson> lifeless: seb128
<lifeless> seb128: ping
<\sh> raphink, I know :)
<seb128> hi
<raphink> \sh: have you packaged (DC)Â² yet?
<cjwatson> hm, let me see, those binutils and eglibc uploads don't look like they'll have a significant effect on other packages
<seb128> cjwatson, hello
<seb128> oh retracers
<\sh> raphink, nope...I'm just busy with daily business...the rollout of lucid was postponed because of other urgend company tasks so right now I don't have the time to work fulltime on (DC)Â²
<raphink> who uses these anyway
<seb128> yeah, let me just remove the lock and see if they crash or run
<raphink> :)
<cjwatson> seb128: robert_ancell's folks uploads dropped the changes from version 0.1.14.1-0ubuntu2, which added two build-depends.  I therefore suspect that these uploads will fail to build.  Do you have a way of checking whether this was intentional?
<cjwatson> (the dropped upload fixed bug 621423)
<ubottu> Launchpad bug 621423 in folks (Ubuntu) "folks-0.1.14.1 FTBFS" [Undecided,Fix released] https://launchpad.net/bugs/621423
<seb128> didrocks, ^
<StevenK> Hah, I read that sentence the other way the first time
<StevenK> "Wha, Robert's parents uploaded something?"
<didrocks> seb128: ok, fixing it
<seb128> didrocks, did you do an update for it in the ppa?
<seb128> cjwatson, didrocks: we might just be able to sync on debian
<seb128> they have the new version and this change I think
<seb128> didrocks, ^ can you check?
<seb128> didrocks, thanks
<didrocks> seb128: let me see, upstream made a new revision for the ppa
<didrocks> seb128: sure, checking
<didrocks> seb128: yeah, they get the change, let me just build it and test it before acking on the sync
<netepal> Can somebody guide me how can I contribute to ubuntu
<cjwatson> http://wiki.ubuntu.com/ContributeToUbuntu has some notes
<cjwatson> very much depends on your interests
<netepal> which skill set is needed
<cjwatson> all of them! :-)
<netepal> meaning which languages are needed?
<cjwatson> depending on what you want to do - see that page, it has lots of links
<cjwatson> again, it depends
<cjwatson> there's no one single language used in Ubuntu development
<cjwatson> most of the core system is in C, C++, shell, Perl, Python, in no particular order
<cjwatson> but the much more important thing is which language is used in the package(s) you want to work on.  I generally advise people to be flexible
<netepal> ok then I can work in C/C++
<netepal> are you also a contributor
<cjwatson> yes
<netepal> how do you contribute
<cjwatson> I mainly work on the installer and the boot loader
<netepal> ok! cool
<didrocks> cjwatson: seems to work well. Can you sync folks from debian experimental? do you want a bug report for the request?
<cjwatson> didrocks: I can, please file a bug for it
<seb128> dpkg: ../../src/archives.c:809: tarobject: Assertion `r == stab.st_size' failed.
<seb128> hum, not nice
<cjwatson> do you have the .deb that produced that?
<didrocks> cjwatson: when you have some time: bug #629351
<ubottu> Launchpad bug 629351 in folks (Ubuntu) "Sync folks 0.1.16-1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/629351
<seb128> cjwatson, not really, it's a retracer crash when installing gnome-applets
<cjwatson> actually, that's kind of a "somebody seems to have changed this symlink between lstat and readlink" assertion
<seb128> "Preparing to replace gnome-applets-data 2.30.0-3ubuntu2 (using .../gnome-applets-data_2.30.0-3ubuntu2_all.deb) ...
<seb128> Unpacking replacement gnome-applets-data ...
<seb128> dpkg: ../../src/archives.c:809: tarobject: Assertion `r == stab.st_size' failed.
<seb128> "
<cjwatson> or at least that's the way it looks to me
<seb128> but retracers are special environments
<cjwatson> if it's straceable that might help
<cjwatson> quite
<seb128> cjwatson, I've logged in and it's not happening with an apt-get install
<G> is it just me or are others getting connection refused from launchpad?
<seb128> cjwatson, I will ping you if I manage to reproduce it or get detail
<G> (bazaar sorry)
<seb128> G: the code hosting is down for upgrade
<seb128> "Launchpad: Code hosting offline 8.00-9.30 UTC on Friday 3rd September"
<G> oh just saw that
<G> doh :)
<G> seb128: thanks
 * G whacks self
<seb128> cjwatson, lifeless: bug #628688, retracers seem to work, thanks
<ubottu> Bug 628688 on http://launchpad.net/bugs/628688 is private
<soren> When is the unapproved queue going to be flushed?
<soren> This week sometime?
<lifeless> seb128: hi
<seb128> hey
<lifeless> is the retracer happier ?
<lifeless> at least as far as talking with lp ?
<didrocks> cjwatson: thanks a lot :)
<seb128> retracers are happier yes
<seb128> they manage to get the crash file and retrace it
<lifeless> seb128: great
<seb128> running it by hand worked but didn't untag it, so that could be a bug but that's not going to stop retracing
<lifeless> seb128: we've put a bandaid in place to get access for you
<seb128> we can untag the need-retracing by hand if required
<seb128> thanks
<lifeless> we're now working as hard as we can on the permanent solution, and we should be able to deploy it without downtime [other the the regular rollout process]
<seb128> the lack of retracer started being an issue for maverick since it means crash bugs don't reach triagers
<lifeless> yeah, it was an unintentional side effect of making private bug attachments... private
<seb128> the bandaid seems to be enough to get the retracers running so no hurry from our side for other changes
<lifeless> but all the short term options to address it are unpleasant
<lifeless> the tagging thing is AFAIK unrelated
<seb128> ok
<lifeless> so please do investigate/file a bug
<seb128> will do
<seb128> thanks again for working on the issue
<lifeless> no probs
<lifeless> we're sorry it took so long to get the bandaid in place: there was some confusion involved
<cjwatson> soren: I'm in the process of flushing it
<cjwatson> argh, acronym frustration.  What does SDV stand for in the context of "Intel SDV" (i.e. some kind of development board)?
<cjwatson> a friend tells me "software development vehicle"
<soren> cjwatson: Cool, thank you!
 * soren crosses stuff off his list
<ogra> cjwatson, i bet mjg59 knows ;)
<OdyX> tkamppeter: uhâ¦ I'm not the ghostscript maintainer; even not trough a team, so any update will be hard. You (or me) should get in contact with the real maintainers. Note by the way that Debian has had 6 releases since the Ubuntu "fork"
<tkamppeter> OdyX, perhaps one could move GS maintainership from the current maintainer to you. You should ask him whether he would continue maintaining GS and then he would need to update it regularly, at least for upstream releases and a merge from Ubuntu before Debian Feature Freezes, or he could pass maintainership to you.
<cjwatson> didrocks: gnome-control-center also dropped an Ubuntu change, this one 1:2.30.1-1ubuntu3 from maco.
<cjwatson> didrocks: seems like some kind of process sanity check might be called for here?
<cjwatson> the periods when archive admins will catch this kind of thing are pretty narrow.
<didrocks> cjwatson: is it my upload?
<cjwatson> didrocks: no, Robert's, but I assume he's asleep and seb128 redirected me to you earlier when I asked him :)
<didrocks> hum, robertâ¦ yeah, I think we should discuss with him, he made some of those kind of issues recently :)
<didrocks> cjwatson: ok, I'll fix that in some minutes, please reject the upload
<didrocks> and talk with him
<didrocks> thanks cjwatson and sorry for the noise!
<ogra> can someone let linux-ti-omap4 out of the unapproved queue ?
<cjwatson> working on the unapproved queue in general
<cjwatson> I will get to it soon - doing it roughly in reverse upload order
<cjwatson> er, upload order
<ogra> ah, great, thanks
<seb128> cjwatson, didrocks: I can check for that one, I redirected to didrocks before because I know he did some updates on the empathy stack yesterday
<didrocks> seb128: thanks :)
<seb128> I guess that one is a case of "somebody sponsored a change and didn't commit to the vcs"
<cjwatson> ogra: this isn't an ABI bump?  gosh
<ogra> its a version bump
<ogra> 2.6.34 -> 2.6.35
<ogra> (at least it should be)
<cjwatson> so it is, I just can't read
<cjwatson> accepted
<ogra> thanks a lot
<Valente> Hi everybody!
<Valente> I would like to ask firstly if I can use this chat for solve problems
<Valente> And if not which chat should I look for?
<Valente> Hi! Could you tell me if I can use this chat for asking for help?
<Hobbsee> #ubuntu
<G> dholbach: hey, I've got a question for you reg Harvest when you've got a moment
<dholbach> g: sure
<G> dholbach: wrt the show all opportunities options (I know Permalink does it but I'm thinking of a way to tie everything else in), what would you say to using jquery to display it as an inline pop-up
<G> (similar to how launchpad does some of the assign/linking UI)
<dholbach> g: do you think you can file a bug about that and discuss it there - that'd be a good question for Dylan
<dholbach> g: he's the ui mastermind :)
<G> dholbach: ahhh right okay, will do :)
<dholbach> thanks a bunch G
<dholbach> G: I'll have a look at your merge proposal in a bit
<G> dholbach: okay, I'll put the other one in (the change the text for the filtering)
<dholbach> super
<G> dholbach: is there a quick way to regenerate the pot files?
<dholbach> G: ./manage.py update-template
<G> dholbach: ohhhhhh
<dholbach> G: (from ./opportunities/management/commands/update-template.py
<dholbach> )
<G> and here was me thinking taht was for templates etc
<G> I'd tried everything but :)
<G> I'll do that for my second merge proposal so it'll get picked up (the index translations are missing from the pot file)
<dholbach> G: commented on your merge proposal
<G> dholbach: oh thats a very good point :)
<dholbach> :)
<G> will get on that in a moment :)
<dholbach> super
<G> dholbach: tbh, I think it would be best to leave it as _lazy though so there is an obvious difference :)
 * ogra wonders where doko is
<dholbach> ogra: oo.o conference
<ogra> bah
<dholbach> G: hm, not sure
<ogra> he should find someone there to fix armel builds :P
<dholbach> G: "Always use lazy translations in Django models." - I think it's fine to call it _ there :)
<dholbach> http://docs.djangoproject.com/en/dev/topics/i18n/internationalization/
<G> dholbach: okay
<dholbach> ROCK
<cjwatson> \sh: fai accepted
<\sh> cjwatson, thx a lot
<dholbach> Q: merged, thanks
<G> dholbach: no problem!
<AnAnt> Hello, is there a way to detect wether the pulseaudio is the sound server in use ?
<directhex> AnAnt, well, "aplay -L" gives a hint about it
<AnAnt> directhex: thanks
<kenvandine> cjwatson, how many people do we want to get to verify the twitter/oauth change for gwibber before putting it in -updates?
<kenvandine> cjwatson, it has to be better than what is already there, since we know the version in lucid doesn't work at all for one of the 2 most popular services
<cjwatson> oh, I was going to waive the aging period on that
<cjwatson> remind me of the bug number?
<kenvandine> bug 627565
<ubottu> Launchpad bug 627565 in gwibber (Ubuntu Lucid) "Twitter dropping support for basic auth" [Undecided,Fix committed] https://launchpad.net/bugs/627565
<kenvandine> i had at least 3 people that confirmed it in the ppa
<kenvandine> and 1 for sure on the bug... and one that complained about the save button
<kenvandine> so i assume it worked for him
<kenvandine> we know the save button can be more obvious, not a new problem :)
<bilalakhtar> kenvandine: add 1 more, I have also confirmed
<cjwatson> kenvandine: what do the last three comments on bug 613420 indicate?
<ubottu> Launchpad bug 613420 in gwibber (Ubuntu) "gwibber doesn't receive tweets n" [Low,Confirmed] https://launchpad.net/bugs/613420
<kenvandine> bilalakhtar, thx!
 * kenvandine looks
<cjwatson> kenvandine: and could somebody validate that bug 583316 is fixed in lucid-proposed?
<ubottu> Launchpad bug 583316 in gwibber (Ubuntu Lucid) "tr.im should be removed from advanced dropdown in gwibber-preferences" [Undecided,Fix committed] https://launchpad.net/bugs/583316
<kenvandine> cjwatson, bug 613420 is probably a case of him authorizing and not seeing the "Save" button
<ubottu> Launchpad bug 613420 in gwibber (Ubuntu) "gwibber doesn't receive tweets n" [Low,Confirmed] https://launchpad.net/bugs/613420
<kenvandine> bilalakhtar, can you confirm bug 583316 ?
<ubottu> Launchpad bug 583316 in gwibber (Ubuntu Lucid) "tr.im should be removed from advanced dropdown in gwibber-preferences" [Undecided,Fix committed] https://launchpad.net/bugs/583316
<kenvandine> you should be able to open gwibber prefs and not see tr.im in the combobox
<bilalakhtar> kenvandine: verified
<seb128> dholbach, do you know who is working on example contents?
<seb128> dholbach, ie bug #595248
<ubottu> Launchpad bug 595248 in example-content (Ubuntu) "Presenting_Ubuntu incorrect transition time" [Undecided,Fix committed] https://launchpad.net/bugs/595248
<dholbach> seb128, I was told the design team was working on it
<seb128> dholbach, ok
<slomo> cjwatson: hi :) could you sync gst-plugins-ugly0.10 0.10.16-1 from debian/experimental? there are no ubuntu changes and no ubuntu changes are necessary and it's in universe
<cjwatson> it's really a lot easier with a bug, we have tools to process sync request bugs semi-automatically
<cjwatson> but, done
<slomo> cjohnston: thanks, i didn't know there are tools for this, sorry
<ScottK> cjwatson: Would you please rescore glib2.0.  It just affects powerpc and should save us some FTBFS due to archive skew.
<cjwatson> ScottK: done
<cjwatson> dunno how much difference it will make - 13 mins vs. 12 mins according to the web interface :)
<cjwatson> I think it was probably already first in the queue
<ScottK> OK.  Thanks.
<cjwatson> kenvandine: ok, aging period waived, copied
<kenvandine> cjwatson, thx!
<cjwatson> in future I don't suppose we could avoid waiting four months from the announcement of a service being turned off before arranging not to rely on it any more? ;-)
<kenvandine> cjwatson, i wish... :/
<kenvandine> cjwatson, until less than 2 weeks ago it was looking like we would have to drop twitter support all together... which would not have been popular
<kenvandine> there was a great article on arstechnica yesterday about the whole ordeal :)
<directhex> the one where segphault hacks the super secret official twitter oauth keys?
<kenvandine> directhex, yeah... that was awesome
<kenvandine> :)
<kenvandine> they told us if we published the key anywhere in source it would be revoked
<kenvandine> and they did revoke at least one for being committed to github
<directhex> use theirs
<kenvandine> directhex, i am sure it is just a matter of time before someone posts a website listing keys
<kenvandine> they did extend the deadline twice because they hadn't found a solution for open source clients... but ultimately decided open source clients weren't important enough to delay any longer
<kenvandine> sad...
<cjwatson> kenvandine: ... lovely
<kenvandine> finally compromised with us when we had a week left...
<kenvandine> i just hope they don't retaliate against segphault's article by revoking our keys :)
<dholbach> apachelogger, thanks!
<apachelogger> dholbach: any time :)
<smoser> cjwatson, just wanted to make sure you saw this, but I didn't see your response until just now.  see my comment https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/613463
<ubottu> Launchpad bug 613463 in grub2 (Ubuntu) "[10.10 - Alpha 3 (candidate)] Prompts misleading grub dialogs during UEC Node installation." [Undecided,New]
<smoser> as to why mtools and grub-rescue-pc files would not work.
<cjwatson> smoser: you could extract the files from it and regenerate
<smoser> well, yes, but then i still have to depend on xorriso, and i also have to know details about the internals of that image.
<smoser> and what flags to send to xorriso and such.
<cjwatson> I realise it isn't pretty but I'm not going to have time to change this for maverick now and I don't want to get that badly ouot of sync with Debian (and of course Debian is frozen)
<smoser> yeah, i understand that.
<smoser> right now, we just have a missing dependency in eucalyptus-nc.
<cjwatson> also I'm not sure you in fact need xorriso
<smoser> how else would i master the iso image ?
<smoser> if you think doing that is loads cleaner, i'm willing to re-work it.
<cjwatson> you said you were creating a boot floppy
<smoser> yes.
<smoser> oh.
<smoser> i see, you're saying just grab the files from the iso and make a floppy that is not iso format
<cjwatson> yeah
<cjwatson> just treat it as a silly delivery mechanism
<smoser> well, i wish i'd have seen your comment before. if you think that i should chase that, i will.
<smoser> one other benefit of my usage of grub-mkimage is that i only include modules in the original floppy that are needed to load the secondary loader.
<smoser> ie, don't need a bunch of filesystems for that.
<smoser> and my images are not *tiny*.
<smoser> but thats probably not a big deal.
<smoser> if you think i should chase this i will. right now the only broken-ness is the missing dependency.
<geser> looking for a core-dev to sponsor bug #625798
<ubottu> Launchpad bug 625798 in tickcount (Ubuntu) "Don't use int constants with a long data type." [Medium,Triaged] https://launchpad.net/bugs/625798
<cjwatson> smoser: I think it's the most viable approach for maverick
<cjwatson> for natty, the approach of splitting out -modules packages is fairly tempting
<smoser> cjwatson, you think i should re-work to using the grub-rescue-pc ?
<smoser> or you think we should just go with what we have now (lack of dependency)
<cjwatson> smoser: if you have time to rework it on top of grub-rescue-pc, I think that would be good.  but I don't know what issues the lack of dependency is causing you
<smoser> cjwatson, without root can i easily get files off a iso9660 filesystem ?
<cjwatson> bsdtar
<cjwatson> or isoinfo
<smoser> isoinfo -x only does one file at a time, right ?
<cjwatson> yeah.  bsdtar has more convenient syntax but is in universe (though I imagine that's changeable)
<smoser> so i'd have to crawl its ls-lr output and pick them out.
<cjwatson> I do exactly that in d-i
<smoser> with isoinfo ?
<smoser> wowl
<cjwatson> yeah, painful
<apw> if i have a file which i want to be installed by each kernel but that file only needs to exist once (this is a common udev rule) is there a sensible way to describe that?
<smoser> cjwatson, should i just across the board run 'tolower' on isoinfo ls-lr output ?
<smoser> or will it end up not mattering.
<cjwatson> d-i doesn't bother
<cjwatson> oh, you're forgetting an option
<smoser> so in my recreated boot disk, though, it wont matter ?
<cjwatson> use -R
<smoser> ah
<smoser> i tried -J
<smoser> and it had no joliet extensions
<cjwatson> you want the Rock Ridge stuff - RR => Unixish, Joliet => Windowsish
<cjwatson> very very roughly
<smoser> right
<manjo> superm1, running late... I will be there around 1:00
<jdstrand> jcastro: hey. so the security team has the ability to tweet and dent things. how can I get that hooked into planetubuntu?
<jdstrand> jcastro: I should probably clarify, we have created a specific account for each that members of the security team can post to
<smoser> cjwatson, if you are, http://bazaar.launchpad.net/~smoser/%2Bjunk/starter-junk/annotate/head%3A/iso-extract is what i came up with.
<wookey> mvo: can I poke you about https://bugs.launchpad.net/ubuntu/+source/apt/+bug/620576 and https://bugs.launchpad.net/ubuntu/+source/apt/+bug/625042
<ubottu> Launchpad bug 620576 in apt (Ubuntu) "/usr/share/apt/ubuntu-archive.gpg is missing but necessary for fresh install" [Undecided,New]
<wookey> this seems like pretty serious breakage to me
<wookey> 625042 was OK in 0.7.26~exp12ubuntu3
<wookey> 620576 was OK before 0.7.26~exp12ubuntu3
<wookey> For the latter I'm not sure how it's supposed to work, so I'm not sure how it should best be fixed. Maybe the missing file should be put back, or maybe the code to copy it over is simply not longer needed
<wookey> No-one will notice these bugs in normal use, but I still think they are significant. And hopefully easy to fix.
<mvo> wookey: sure, let me have a look
<ScottK> cjwatson: Would you please rescore kdebindings kdebase-workspace (only affects armel).
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<ScottK> That should accelerate when we're done by 8 - 10 hours.
<achiang> hm, does anyone know what happened to xserver-xorg-input-keyboard / kbd in lucid? did the package just go away?
<fagan> ask on #ubuntu-x
<fagan> they would know
<achiang> thx
#ubuntu-devel 2010-09-04
<lamont> sigh.. what's the new gthumb?
<lamont> or is gthumb supposed to still be installable (looks like it)
<lamont> GLib-GIO-ERROR **: Settings schema 'org.gnome.Evince.Default' is not installed
<lamont> ^^ wtf is that about?
<Laney> did something break w/gcc-4.4/ppc? libgcc_s.so seems to have gone away
<cjwatson> Laney: ScottK and slangasek have been looking into that
<Laney> cjwatson: ah yes I missed the chat in #-release, thanks
<slangasek> cjwatson, Laney: so I haven't managed to get a test build done yet because I forgot to set DEB_BUILD_OPTIONS=nocheck (I've done so now, it's faster to build it all again than it is to let the testsuite run on davis); I was waiting for that to finish before pushing to the archive, given that lamont isn't around to restart the buildds anyway
<Laney> slangasek: the buildds appear to be on (at least that's how I found out about it, through FTBFS mails)
<slangasek> Laney: hmm, how recent was the last one?
<Laney> Date: Sat, 04 Sep 2010 08:55:50 -0000
<slangasek> my understanding was lamont put the buildds to manual
<slangasek> hmm
<slangasek> ok, perhaps I should just upload this then
<slangasek> har; except that in the meantime, gcc-4.4 has been upgraded in the davis chroot, so now it can't bootstrap
<slangasek> well, that answers /that/ question
<ogra_cmpc> slangasek, does linaro do any tegra2 work ? i just found out that the toshiba AC100 (tegra2, 512M, 8G SATA SSD) is sold around the corner here (for 380 euro which is a bit expensive but given you can do arm work on the go ...)
<slangasek> ogra_cmpc: nope, not on the roadmap
<ogra_cmpc> hmm, sad
<ogra_cmpc> just FYI it seems that on armel most packages FTBFS too with "C compiler cant create executables"
<slangasek> ogra_cmpc: gcc-4.4 breakage; I've just uploaded the fix, but I guess someone is need to going to have to re-bootstrap it by hand since gcc-4.4 itself now FTBFS on these archs
<ogra_cmpc> slangasek, ah, good, i was assuming someone already noticed it, just wanted to point it out in case :)
<ogra_cmpc> (since the above conversation seems to refer to ppc)
<slangasek> yeah, I had just noticed the armel breakage
<Laney> I since got some FTBFS from that too on armel
<Laney> such fun. :)
<slangasek> cjwatson, lamont: can you sort out from here what needs to happen to rebootstrap gcc-4.4?  I'm thinking about sleeping
<lamont> slangasek: I did put them on manual... looks like someone else put them back on auto...
<lamont> so... are we expecting these gcc builds now running to be what we need?
<nigelb> james_w`: ping? we both are supposed to coordinate package training for this month - just fyi
<ScottK> lamont, slangasek, Laney, and cjwatson: Looks like the same problem eventually affected armel too.
<lamont> ScottK: that was the scrollback from about 5 hours ago
<ScottK> lamont: OK.  Missed it.
<lamont> waiting for 4.4 13ubuntu1 to finish building
<ScottK> Yep.
<ScottK> Ah, yes.  scanned over that part.
<dupondje> do we have plans for NFS over IPv6 support ?
<jonasfa> i would like to develop something to let Android-devices owners to use it as a multi-touch trackpad
<jonasfa> where can i find any info on how to do that?
<fagan> hmmm interesting
<fagan> you should wait till monday and ask on #ubuntu-x
<fagan> they can help
<jonasfa> ok :) i'll start the android stuff, then ask for help on monday, as you said
<jonasfa> ty
<fagan> np
<fagan> or tuesday since its a us holiday
<fagan> since monday is a us holiday rather
<Hobbsee>  /quit
<MattJ> Hmm, for some reason it seems expat_2.0.1.orig.tar.gz in lucid is corrupted - it fails to extract here
<MattJ> (trying apt-get source libexpat1)
<MattJ> sigh - same with the real upstream tarball it seems
<MattJ> and there are bugs for it
 * MattJ pretends he was never here
<apparle> where is the package gcc3
<fagan> its just gcc
<fagan> there is no other package
<apparle> I want the old version
<fagan> you can grab that from packages.ubuntu.com
<fagan> but you shouldnt use the old versions
<apparle> there isn't any on packages.ubuntu.com
<apparle> at least for lucid
<apparle> and can't I keep them side by side as in hardy
<fagan> there is but you need to go to previous versions of ubuntu
<fagan> its not in the archive for a long time
<apparle> and why has it been removed in the latest repos
<fagan> because its old
<fagan> its been updated
<fagan> we always have the most recent compliers
<apparle> *still it was not hurting anyone. now it is hurting me :(
<jolan> what is the problem you're trying to solve by using gcc3?
<fagan> it takes effort to maintain packages
<apparle> and the concerned software is old really old
<apparle> ponyprog
<fagan> anyway this is off topic for this IRC channel really
<apparle> this topic-> the concerned software or gcc version?
<fagan> thats not what this channel is for
<fagan> this is the channel for developing ubuntu
<apparle> ok sorry guys... bye
<fagan> but its quiet at the moment so we can continue
<fagan> its fine
<apparle> ahh
<apparle> can I setup chroot to build using gcc3
<apparle> or are there any flags so that, gcc4 will build like gcc3
<fagan> why does it not build with the current gcc?
<fagan> have you tried just building it and see what it says?
<fagan> if you really need gcc 3 you should go to the last version of ubuntu that shipped it
<fagan> stick it in a vm or set up a dual boot with the old version
<apparle> fagan: check the software ponyprog. it is old very very old
<fagan> but have you tried to build it anyway
<fagan> it doesnt matter how old it still might build
<apparle> fagan: it uses some really old gui library .... and many other things... which generate so many errors
<fagan> ah ok
<fagan> well then your a bit stuck
<fagan> the only thing I could suggest is do it in a vm
<apparle> fagan: it pretty much depends on nothing, so I want to make a deb for it and use it.
<fagan> well then a vm is the best option
<fagan> make the deb in the vm and then it should work away
<apparle> okay, will try on hardy. thanks
<ScottK> fagan: We have versioned gcc packages, such as gcc-4.4 and gcc4.5 with one being the default.
<fagan> yeah but not as old as 3 though
<fagan> i actually thought we just had one but I saw that we had 4.4 and 4.5
<ScottK> apparle: There's a gcc-3.3 in Maverick that should be relatively backportable if you need libstdc++5.
<ScottK> fagan: We have bits of 3.3 back in maverick because lots of people need libstdc++5 to run popular closed source software.
<fagan> oh
<fagan> I didnt know that
<ScottK> apparle: If you can test building gcc-3.3 from maverick on lucid, I can see about getting an official backport done.
<ScottK> Gotta run.
<apparle> ScottK: so in maverick I should be able to compile it.
<apparle> ScottK: I'll try in beta
#ubuntu-devel 2010-09-05
<funkyHat> I just pushed a branch with a fix for #630592 ... who would it be best to mark as reviewer when I propose a merge to lp:ubuntu/gconf ?
<funkyHat> bug 630592
<ubottu> Launchpad bug 630592 in gconf (Ubuntu) "gconf FTBFS because build deps on libdbus-1-dev, libdbus-glib-1-dev were removed" [Undecided,New] https://launchpad.net/bugs/630592
<funkyHat> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship suggests ubuntu-sponsors but ubuntu-dev is already filled in on the form
<micahg> funkyHat: ubuntu-sponsors so that it shows up on the sponsoring list
<funkyHat> micahg: thanks â¢)
<funkyHat> And done
<dachary> Hi. I maintain a package (python-poker-network) which requires a running MySQL server in the postinst script. When I run apt-get install mysql-server python-poker-network it fails because .postinst is run although /etc/init.d/mysql-server has not been invoked yet. How can I work that around ?
 * 52AACAD66 is away: Zurzeit abwesend
<fagan> dachary: ask on tuesday there wont be anyone that can answer till then id say
<fagan> its a holiday weekend
<penguin42> dachary: You could also try #ubuntu-packaging
<micahg> fagan: the people in europe will be working Monday
<fagan> yeah
<dachary> thanks for the tip
<micahg> penguin42: it's a universe package, so #ubuntu-motu is a better place
<penguin42> micahg: Ah fair enough; I just thought since it was the mechanics of the packaging system
<fagan> well i dont think his question had anything to do with packaging
<penguin42> he seemed to have a dependency on something else running as part of his post install - shrug
<fagan> I think the he didnt start the process
<fagan> well anyway hes gone now so no point in dwelling on it
<fagan> :P
<micahg> fagan: it's a common problem actually
 * micahg just doesn't know how to fix it
<fagan> yeah but I suppose they shouldnt be asking on this channel anyway
<fagan> I generally direct them to the proper place
<fagan> but that question probably couldnt have been answered on
<fagan> #ubuntu
<micahg> fagan: -motu is more appropriate since it's a universe package
<fagan> yeah
<micahg> fagan: no, it's a dev question
 * 52AACAD66 is back.
#ubuntu-devel 2011-08-29
<micahg> ScottK: did we ever get approval for -backports opening at feature freeze?
<micahg> \o/ I got CMake and pkg-config to dance together
<RAOF> Wooooooo!
<TheMuso> /c/c
<pitti> Good morning
<pitti> tjaalton: aah, failsafe-x
<RAOF> pitti: Good morning!
<didrocks> good morning
<pitti> superm1: mythbuntu-live-autostart should be in beta-1?
<pitti> superm1: is ubiquity plugin migration to pygi necessary to work with the current ubiquity?
<pitti> slangasek: portmap wants to go to universe, do you know whether that's intended?
<infinity> pitti: Seems that rpcbind has replaced it?
<pitti> ah
<infinity> (seems like an odd wheel to have reinvented, but whatever, it's not like any of us particularly loved portmap)
<pitti> ah, removed from Debian as well, I'll follow suite
<pitti> "suit"
<infinity> Oh, they removed portmap completely?  Interesting.
<pitti> http://packages.qa.debian.org/p/portmap.html
<infinity> Indeed.
<infinity>    portmap |    6.0.0-3 | source, alpha, amd64, armel, hppa, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
<infinity> Closed bugs: 567502
<ubottu> Launchpad bug 561125 in linux (Ubuntu) "duplicate for #567502 WARNING: at /build/buildd/linux-2.6.32/kernel/softirq.c:143 local_bh_enable_ip+0x61/0x90() [ath9k]" [Undecided,Confirmed] https://launchpad.net/bugs/561125
<infinity> ------------------- Reason -------------------
<infinity> ROM; superseded by rpcbind
<infinity> ----------------------------------------------
<infinity> ubottu: That was a Debian bug, you silly bot.
<ubottu> infinity: I am only a bot, please don't think I'm intelligent :)
<dholbach> good morning
<ion> that.
<pitti> superm1: ah, saw your ping on #u-release, nevermind
<RAOF> slangasek: Yo!  Question re: -dev packages and multiarch - /usr/include isn't treated specially, is it?  Meaning that -dev packages which ship /usr/include (ie: everything) can't be Multi-Arch: same?
<doko> RAOF, the can, as long as the files are the same on any arch
<RAOF> doko: Thanks.  I might see if I can make the documentation clearer, then.
<RAOF> doko: http://wiki.debian.org/Multiarch/Implementation says âAlthough Debian policy currently doesn't allow -dev packages to be Multi-Arch: sameâ¦â.  Is that the documentation being wrong, referring to the case when there are arch-specific files in /usr/include, or something else? :)
<doko> RAOF, currently you cannot install them, but afaik, they are accepted into the archive
<RAOF> doko: Is this in Debian or Ubuntu?  My empirical testing suggests that i386 and amd64 -dev packages of libpciaccess are perfectly happy to be installed.
<RAOF> Ah, but not on Debian.
<doko> RAOF, dpkg is still missing the bits
<RAOF> Right; as my experimental schroot has taught me.  But a -dev package marked as Multi-Arch: same will not necessarily be a violation of policy?  Documentation fixing time :/
<doko> RAOF, afaik, no. there are already lots of those merged back
<pitti> ev: do you think it's ok to disable the xklavier bits in ubiquity for now?
<pitti> ev: (not necessary for b1)
<ogra_> Sweetshark, http://paste.ubuntu.com/677114/ is that already known (that armel, seems to affect all subarches) ?
<ogra_> s/that/that's/
<pitti> ogra_: yes, LibO FTBFSed again after 2 days of buildig :/
<ogra_> ah, k
<ogra_> should we unseed it to the milestone on arm ?
<pitti> ogra_: it doesn't seem to be part of ubuntu-desktop on arm, is it?
<ogra_> building it again will makes it hard to release in time i guess
<ogra_> *make
<ogra_> arm uses the same seed as everyone else i dont think we special case libO
<pitti> ogra_: ubuntu-desktop isn't shown as uninstallable on arm, that's why I thought it doesn't break images
<ogra_> intresting
 * ogra_ goes to check the seeds
<ogra_> desktop builds definitely fail due to it
<pitti>  * (libreoffice-writer) [i386 amd64 powerpc]
<pitti> and similar for other libo-* packages
<pitti> ogra_: I have preinstalled builds in the queue, waiting for new ubuntu-desktop
<ogra_> weird
 * pitti checks previous logs
<ogra_> i wonder what pulls them in
<pitti> last successful build is from 0822
<ogra_> yes, i know
<ogra_> archive skew ...
<ogra_> first telepathy-glib was out of sync with x86, then unity broke
<pitti> ah, I see in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu-omap4/20110829/livecd-20110829-armel.out
<pitti> live: * libreoffice-help-en-us
<pitti> could it be that one?
<pitti> ogra_: i. e. do the preinstalled ones use the live seed?
<ogra_> yes
<ogra_> when was that added ?
<pitti> Depends: libreoffice-writer | language-support-translations-en
<ogra_> seems the 22th build was fine
<pitti> l-s* doesn't exist any more
<pitti> ogra_: so let's update the live seeds to exclude that from armel?
<pitti> I don't think we'll get an armel LibO build plus testing by Thursday
<pitti> ogra_: committed
<pitti> now, I think we need two publisher cycles for that
<pitti> we need a main upload for this, /me looks
<ogra_> right, well, we need a bunch of other changes anyway,  linaro changed the bootloader conmpletely for omap4
<ogra_> dont bother to do testbuilds yet, i will need to do a set of uploads during the day
<pitti> ogra_: ah, ok; thanks, un-queueing then
<pitti> ogra_: shall I remove the other preinstlaled ones for server/kubuntu as well then?
<pitti> (from the tracker, I mean)
<ogra_> (namely i should have to do d-i, flash-kernel and debian-cd changes (and i hope thats enough, i dont know about any other fallout, but you never know)
<ogra_> kubuntu built ?
<pitti> might fail, I currenlty have a build running
<ogra_> yes, remove all omap4 builds, they wont boot atm
<ogra_> omap3 should be fine
<pitti> ogra_: ok, disabled omap4 for server and netboot
<ogra_> thx
<pitti> ogra_: server omap4 built, yes: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110829/
<ogra_> yeah, but wont boot either
<ogra_> the first stage bootloader is gone
<pitti> ok, then I'm cancelling the kubuntu-mobile build, too
<pitti> kbuutnu daily-preinstalled failed
<ogra_> yeah, thats a kde thing i think
 * ogra_ normally doesnt look at the kubuntu builds, but i think there is still stuff out of sync 
<pitti> ogra_: ok to add http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20110829.1/ to the tracker?
<ogra_> yep
<ogra_> did infinity enable x86 builds already for it ?
 * ogra_ checks
<ogra_> hmm, no
<pitti> ah, kubuntu failed due to libo, too
 * pitti fixes seeds
<pitti> done
<ogra_> thanks
<pitti> ogra_: but I guess the kubuntu images are waiting for the very same bootloader changes, so I'll wait for these with the rebuild
<ogra_> right
<ogra_> well, omap should build and work, just omap4 not
<ogra_> i wonder if we should disable ac100 and mx5 completely for now
<ogra_> they steal buildd time and delay the actual images we release
<pitti> yeah, they double image building time, as it seems
<ogra_> right
 * ogra_ goes and changes cdimage
<ogra_> disabled, future builds will only build omap/omap4 now
<Sweetshark> pitti: "Err http://ports.ubuntu.com/ubuntu-ports/ oneiric/main libpoppler-dev powerpc 0.16.7-2ubuntu1  404  Not Found
<Sweetshark> pitti: "Err http://ports.ubuntu.com/ubuntu-ports/ oneiric/main libpoppler-dev powerpc 0.16.7-2ubuntu1  404  Not Found
<Sweetshark> and lots more still on davis
<Sweetshark> I thought testing it on ppc might be faster as armel will again take 3 days to get to the possible breaker ...
<Sweetshark> pitti: ah, hmm, I seem to be allowed to do an update on that machine
 * Sweetshark installs half the world on porter-ppc
<jtaylor> is this the correct path for multiarch -dbg libraries? /usr/lib/debug/usr/lib/x86_64-linux-gnu/
<jtaylor> e.g. libxss1-dbg has it
<Sweetshark> pitti: k, building on amd64 and ppc again
<jtaylor> problem solved in debian-dev, path is correct
<pitti> Sweetshark: ah, "sudo apt-get update" works in the porter dchroots? nice
<Sweetshark> pitti: IIRC it did not in the armel one when I last tried. But it did in the ppc one.
<janimo> ogra_, who is working on the d-i armel fix? (u-boot.bin renamed for omap4)
<ogra_> janimo, lets see, we might not need a d-i change, i just finished the debian-cd one and was about to ask pitti for a testbuild
<ogra_> i think the d-i scripts just deal with the MLO binary that the post-boot script extracts
<janimo> ogra_, great
<ogra_> so we might only need to change that bit (which i just did)
<ogra_> i have to check the code again but it might be that this two line chaneg was enough
<Sweetshark> pitt
 * Sweetshark just decided to throw away the old LO packaging completely for ubuntu-p ... we have new repos anyway so that will make stuff a lot easier ... 
<cjwatson> infinity: wheel reinvention> portmap was rather fundamentally unable to do IPv6, AIUI
<doko> ERROR: The following files could not be found:
<doko> ERROR: File not found: libgcc_s.so.1
<doko> ERROR: File not found: libstdc++.so.6
<doko> Sweetshark, ^^^
<Sweetshark> pitti: at least the first breaker (in sal) vanished on ppc (not really a surprise, it helped on armel too). Now it is up to what happens in instsetoo_native ...
<Sweetshark> doko: known issue
<doko> Sweetshark, well, keep the proper files there, they don't hurt, if the linker script is installed?
<Sweetshark> doko: im currently trying a build with --without-system-stdlibs for ppc and armel as the existence of the linker script pretty much puts the whole exercise of packaging a .so from the system ad-adsurdum,
<doko> Sweetshark, no, wrong. you don't package the linker script, apparently only the shared lib
<doko> Sweetshark, btw, did you change the ix86 builds to build with -Os by intent?
<Sweetshark> (if you have a linker script that tells you to link against a static libs too, and you only package the dyn lib, but not the static libs, your not portable anyway. besides anyone creating c++ extensions on armel/ppc is out of his mind anyway. _And_ besides that the LO ABI will be horribly incompatible between distros anyway.
<Sweetshark> (on non-i386/amd64)
<Sweetshark> doko: no. gbuild introduced change maybe?
<doko> only if they need the synchronisation helpers
<doko> gbuild?
<Sweetshark> doko: new build system stuff
<ScottK> micahg: No.  I didn't get it together to actually ask yet.
 * ScottK waves to barry and wonders if he has power?
 * barry waves back to ScottK with a thankful "yes" and wonders the same about him
<ScottK> No.  No power.  All else fine though.
<barry> ScottK: we were camping last weekend.  the weather was fine in west va (a little rain, but not bad).  no cell service.  we were a little nervous about what we'd find when we got back, but our block was lucky this time.  we're usually the first to lose power and the last to get it back.  my son's school just got power back in the early am for the first day of school
<ScottK> No school here today.  Fortunately they canceled all of them so the middle child can watch over the youngest.
<barry> moco (apparently) changed their policy this year.  they don't close the whole county for a couple of schools.  we'll see what happens when it snows. ;)
<ScottK> Yeah.
<janimo> can someone accept the gmime upload? it is needed for arm images
<pitti> Sweetshark: ah, libreoffice-style-andromeda is NBS; I'll remove it from the DVD seeds to unbreak the DVD builds; sounds alright?
<janimo> thanks :)
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<Sweetshark> pitti: I am checking. there was something about andromeda (being killed or renamed)
<pitti> Sweetshark: right, I guess that was deliberate (it's hard to accidentally drop a binary package)
<Sweetshark> pitti: not that hard actually with the dark magic behind "./debian/rules control" ;)
<Sweetshark> pitti: but yes, drop it.
<ogra_> awesome, with the latest oneiric upgrade my laptop gained a second battery !
<Chipzz> cool
<Chipzz> better not upgrade, you might loose it again :P
<ogra_> sadly only in the panel :)
<Sweetshark> pitti: andromeda was the old "classic" default theme (aka the buttugly one). Since the upstream default is now tango, no need to keep the ugliness around.
<pitti> Sweetshark: ack, thanks for checking
<ogra_> GRRR
<ogra_> pitti, my build is broken
 * ogra_ checks why
<pitti> what is "your build" here?
<pitti> eek, last ubiquity FTBFSed
<pitti> so the initial "live/install" chooser is still broken
<ogra_> ARGh
<ogra_> so they not only moved around the first stage bootloader but also renamed the second stage binary, sigh
<ogra_> pitti, the omap4 server images you rolled for me
<pitti> ev: are you on the ubiquity FTBFS, or need help with this?
<ogra_> rsalveti, any idea why u-boot.bin was renamed ?
<doko> didrocks, clutk has a b-d on gir1.0-pango-1.0, which cannot be satisfied. what should be done with the package?
<cjwatson> pitti: it's a bank holiday today and he hasn't been around; I'm trying to find time to have a look but have other things I should be doing, so have SMSed him
<pitti> cjwatson: ah, thanks; I just checked the holiday calendar, but it wasn't there
<didrocks> doko: the arm team was the last clutk user AFAIK, we don't use it since 11.04 for unity
<cjwatson> yeah, people don't always fill in national holidays
<tumbleweed> doko: did anyone point you to bug 836246? (I don't know if we should be doing an rm in postinst or if it's a bug in ldconfig)
<ubottu> Launchpad bug 836246 in ncurses (Ubuntu) "cycle between ncurses/termcap linker scripts" [High,Confirmed] https://launchpad.net/bugs/836246
<cjwatson> pitti: ev is unavailable today, we'll see what we can do ...
<pitti> cjwatson: ok; at worst we have to release-note it, i. e. that the desktop CD boots straight into the live system
<doko> tumbleweed, looking
<cjwatson> I think that's a pretty bad worst; there are several bug fixes backed up behind that build failure as well
<doko> tumbleweed, I'll remove it in the postinst
<tumbleweed> doko: thanks
<superm1> tests are what's failing, maybe just turn 'em off to get it through the FTBFS and re-enable after beta
<pitti> superm1: the "invalid literal" ones are test suite artifacts, not real bugs?
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<doko> didrocks, ogra_ : please have a look at this ^^^ I'm neither desktop nor ARM ;-)
<mterry> I thought BetaFreeze only applied to main/restricted?  I just had a universe update held for approval.
<didrocks> doko: for me, if they don't use it, +1 to remove it
<superm1> pitti, i'm not entirely familiar with the test suite, i suppose someone will need to dig further to see
<tkamppeter> pitti, I have found a bug in our Ghostscript package. The X11 output does not work, which leads to evince, okular, and similar programs not being able to display PostScript files. I have already found the fix in the "make" command line and I am test-building now. How to proceed to get it into the beta1?
<tumbleweed> mterry: launchpad can't only hold main packages for approval. It should get approved fast
<tumbleweed> (only main)
<mterry> tumbleweed, ah, makes sense.  Thanks!
<geser> tumbleweed: s/main/seeded/ ?
<tumbleweed> geser: well, that
<geser> I still have to remember that we have seeded package in universe too
<pitti> tkamppeter: just upload it
<pitti> tkamppeter: we'll need to rebuild ubuntu anyway; kubuntu has workign images right now, but we probably need to rebuild them as well for the new ubiquity
<doko> didrocks, doesn't help if you don't subscribe ubuntu-archive in bug #705887 :-/
<cjwatson> superm1: strongly disagree until we know *why* the tests are failing (by which point we might well have a fix)
<ubottu> Launchpad bug 705887 in clutk (Ubuntu Oneiric) "Please remove clutk from the archive in natty" [High,Triaged] https://launchpad.net/bugs/705887
<cjwatson> superm1: for all we know they're regressions with serious run-time consequences
<cjwatson> I'm working on it in spare moments
<superm1> cjwatson, true, i suppose especially since these tests didn't have failures in the previous upload and those are all quite small fixes that went into this one
<tkamppeter> pitti, I will upload in some minutes.
<tkamppeter> pitti, uploaded.
<pitti> freeflying: hey, how are you?
<pitti> freeflying: I'm currently building Ubuntu Chinese Edition images with full support, but it's too big for 703 MB images
<pitti> freeflying: we currently install three fonts, each of which is about 9 MB: ttf-arphic-ukai ttf-arphic-uming ttf-wqy-zenhei
<pitti> freeflying: do you think we can drop one of them? that would be enough
<sladen> persia: ^^
<sladen> ArneGoetje: ^^
<doko> tkamppeter, pitti: is flphoto still needed by cups?
<doko> you did package it for hardy
<doko> didrocks, do you know somebody who would update glom? see bug #749267
<ubottu> Launchpad bug 749267 in glom (Ubuntu Oneiric) "glom version 1.16.2-0ubuntu1 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/749267
<didrocks> doko: I know of noone using glom on the desktop side and so able to test it and such
<didrocks> doko: maybe drop a message on #ubuntu-motu? some can be interested in it
<doko> didrocks, no, just looking through reports
<doko> dholbach, ^^^
<dholbach> doko, no idea, sorry
<tkamppeter> doko, flphoto needs CUPS it is not needed by CUPS.
<tkamppeter> doko, what is the problem of flphoto?
<dholbach> doko, bhavi seems to have a newer version in a PPA and upstream has what I guess is the newest upstream in a PPA as well - not sure if they build now though
<tkamppeter> pitti, ghostscript is uploaded and is waiting for approval.
<doko> tkamppeter, bug #770854 please subscribe to the package bug reports
<ubottu> Launchpad bug 770854 in flphoto (Ubuntu Oneiric) "flphoto version 1.3.1-0ubuntu5 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/770854
<dholbach> doko, ignore what I said about bhavi - I just noticed it was an older version
<dholbach> https://launchpad.net/~openismus-team/+archive/ppa then
<tkamppeter> doko, it the flphoto build failure looks like a problem of the tools which handle the translations:
<tkamppeter> doko: espmsg: Loading "po/it.po"...make[1]: *** [po/it] Bus error
<doko> tkamppeter, fix it
<tkamppeter> Anyone has ever seen this Bus error?
<pitti> uh, is espmsg a cups specific version of gettext msgfmt?
<doko> tkamppeter, else we'll have to remove the binaries from the archive
<pitti> freeflying, persia, ArneGoetje: actually we need to free 25 MB, not just 9, sorry (CD build just finished)
<pitti> the LibO -l10n stuff plus these three fonts plus sunpinyin is huuge :/
<pitti> cjwatson: ^ FYI, I got all the extra cruft (apt indexes, caches, pyc files, etc.) off the ubuntu-defaults-image iso now, so without the full Chinese lang support it comes out as 656 MB
 * pitti uploads ubuntu-defaults-builder 0.15 which now produces well-working images with full l10n support
<pitti> sunpinyin working well OOTB, yay
<tkamppeter> doko, pitti, flphoto depends on libgphoto2-dev and this package cannot be found by my Oneiric box. Is libgphoto2 obsolete? How could the build server arrive at the point of handling the translations?
<pitti> tkamppeter: it's libgphoto2-2-dev
<pitti> good night everyone
<didrocks> pitti: have a good evening :)
<slangasek> pitti: yes, portmap can go away now :)
<tkamppeter> pitti, thanks.
<doko> cyphermox, https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2704441
<micahg> there are a few of those
<bdmurray> mterry: could you review / sponsor https://code.launchpad.net/~brian-murray/update-manager/apport-dist-upgrade-question/+merge/73266
<mterry> bdmurray, looking
<mterry> bdmurray, I suspect you'd like to see this in place before beta lands?
<bdmurray> mterry: yes as beta means more upgraders
<mterry> i.e. you want me to upload despite BetaFreeze
<mterry> k
<mterry> bdmurray, how does translation work for the ui.yesno question?
<mterry> (and that can't be determined programatically?  bummer)
<bdmurray> mterry: For all the source package hooks no questions are translated since bugs end up in Launchpad and we prefer them in English anwyay
<mterry> bdmurray, fair
<mterry> bdmurray, is there an easy way to test this and/or you've run it through it's paces?  Looks fine from code review
<bdmurray> mterry: What I've done and you could do is just 'sudo cp debian/source_update-manager.py /usr/share/apport/package-hooks/source_update-manager.py' and then use 'ubuntu-bug update-manager'
<bdmurray> mterry: then when the ui question comes up answer yes and check and then no and check
<hallyn> how do we feel about absolute paths in scripts and such?  upstart jobs don't use them, but should general scripts?  (for /sbin/ip, ifconfig, etc)
<hallyn> Or do we trust that $PATH will be ok for root?
<hallyn> kees: ^
<kees> for upstart? we assume the path is sane.
<hallyn> i'm looking at /etc/qemu-ifup
<hallyn> brctl just moved from /usr/sbin/ to /sbin.  Q is is it better to just remove the paths, or fix them
<hallyn> I always felt paths are better, but then I didn't used to "control" the distro :)
<mterry> bdmurray, uploaded, but naturally waiting on release team approval to move out of upload queue
<hallyn> (so as develper of upstream I think you worry more about that)
<bdmurray> mterry: great, thanks
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> hallyn: Absolute paths should be avoided in distro scripts.
<infinity> hallyn: If the admin wants to replace brctl with his own version in /usr/local/sbin, that's his perogative, and your scripts shouldn't second-guess that.
<infinity> hallyn: (Sure, if he breaks things because of it, he gets to keep both pieces, but whatever, absolute paths don't guarantee the correct binary anyway, he could just as easily replace the one in /usr)
<infinity> hallyn: I think upstreams got into the habit of abolute paths because of the bad old days of Solaris shipping POSIX binaries outside the usual sane locations, so people started doing configure checks and hardcoding paths.  That's pretty obviously the Wrong Thing in an FHS-dominated Linux world.
<tkamppeter> doko, I have fixed flphoto now.
<hallyn> infinity: ok, thanks.  Then I'll push my fix as is, beta-freeze-gods allowing
<geser> doko: re bug #174851: I found recently a guide (on the debian-devel ML) how to bootstrap mig and gnumach and added it to the bug. Could you perhaps forward that comment to the internal rt ticket so it helps the person who has to deal with it?
<ubottu> Launchpad bug 174851 in mig (Ubuntu Oneiric) "mig and gnumach need a manual boot-strapping on the buildds" [Medium,Confirmed] https://launchpad.net/bugs/174851
<doko> tkamppeter, \o/
<tkamppeter> doko, are you using flphoto to print photos?
<doko> geser, I assume, we'll just use the debian binaries or the bootstrap
<doko> tkamppeter, no
<tkamppeter> doko, flphoto is in the queue now, only needs to get approved due to the beta freeze.
<doko> tkamppeter, thanks!
<doko> geser, but if it's not working like that, then please attach the info to the bug report
<geser> doko: already done, I've added that info from that mail as a comment to the bug
<jtaylor> is there something wrong with the Release file in the main archive? http://paste.ubuntu.com/677386/
<slangasek> jtaylor: evidently... yes
<slangasek> jtaylor: identified the two mirrors that are out of sync; flagged to IS
<jtaylor> thx
<mterry> bdmurray, heyo, are you looking after foundations bugs?  Could you see if bug 407862 needs attention?
<ubottu> Launchpad bug 407862 in rsyslog (Ubuntu) "Messages not being sent to system logs" [Undecided,Confirmed] https://launchpad.net/bugs/407862
<bdmurray> mterry: yes I'm the defect analyst for them
<hallyn> ScottK: I posted a debdiff to fix qemu-kvm bugs #833475, #835355, and #829492.  for freeze exception, do I file a separate 'feature exception' bug, or subscribe the release team to all three bugs?
<ubottu> Launchpad bug 833475 in qemu-kvm (Ubuntu) "/etc/qemu-ifup /etc/qemu-ifdown assume the wrong location for brctl" [High,In progress] https://launchpad.net/bugs/833475
<ubottu> Launchpad bug 835355 in qemu-kvm (Ubuntu) "qemu-common should Depend on bridge-utils" [High,In progress] https://launchpad.net/bugs/835355
<infinity> hallyn: debdiff looks sane to me.  I'm kinda curious, though, what on earth would be calling /etc/qemu/if* without qemu-kvm installed...
<infinity> er, qemu-if*
<hallyn> infinity: i think nothing, which is i presume why it's never come up before :)
<hallyn> In fact, I never use those scripts in thef irst place
<hallyn> (and i use kvm all the time)
<infinity> hallyn: I use them.  But yeah, not without qemu machines. :P
<infinity> *shrug*
<hallyn> well, now that qemu-linaro has its own qemu,
<infinity> It's still "correct" to have the dependency live in the same package as the scripts.
<hallyn> right
<infinity> Upload away, I'll approve the mess.
<hallyn> thanks!
<hallyn> put'ed
<Daviey> Is it just me, or does "chown -R www-data:www-data /usr/share/foo" where foo is the package contents seem bad?
<Daviey> (in postinst)
<cjwatson> seems silly
<soren> Daviey: Somewhat worrisome, yeah.
<cnd> I'm trying to run today's daily oneiric iso from a usb stick, but it just hangs during boot
<cjwatson> should just ship the files with the right ownership in the .deb, given that www-data is a global static user/group
<cnd> I see it failed to load fallback graphics devices
<soren> Daviey: Having Apache have write privileges in /usr seems.. Yeah, bad.
<cnd> and there's an error from udevd about /run/udev not being writable
<cnd> it's just sitting there after it successfully starts CUPS printing spooler/server
<cnd> what should I try?
<cjwatson> oh, yeah, there's what soren said too :)
 * cjwatson is a bit tired
<TheMuso> Could anybody with some apt knowledge give me a pointer to what might be the problem causing this bug? https://bugs.launchpad.net/ubuntu/+source/pyatspi/+bug/836798
<ubottu> Launchpad bug 836798 in pyatspi (Ubuntu Oneiric) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2'" [Critical,Confirmed]
<infinity> TheMuso: That sort of thing it often caused by unresolvable Depends/Conflicts/Breaks loops that apt can't work its way out of.
<TheMuso> Hmmmm ok.
<infinity> TheMuso: Might want to poke at related packages and see if there's a logical snag there.
<cjwatson> IIRC Pre-Depends can induce this
<TheMuso> infinity: Yeah, thinking the same now that you mentioned the possible cause.
<cjwatson> -o Debug::pkgProblemResolver=true
<cjwatson> may help
<TheMuso> thanks
<RAOF> cnd: Do any of the VTs have a usable console?  Does startx work?
 * infinity bangs his head on a desk.
<infinity> checking build system type... x86_64-pc-linux-gnu
<infinity> checking for ld used by gcc... no
<infinity> configure: error: no acceptable ld found in $PATH
<infinity> ^-- I beg to differ.
<slangasek> TheMuso: the python-pyatspi2 conflicts: on python-pyatspi looks wrong to me
<slangasek> TheMuso: oh, no, I see the file conflict; ignore me
<slangasek> TheMuso: ok, libatspi2.0-0 and libatspi1.0-0 - why do these conflict?
<TheMuso> ah crap yeah, in the early days I think they may have shared files,a nd I forgot to get rid of the conflict. I was looking at the same thing.
<TheMuso> Fixing...
<cnd> RAOF, when booted into single user mode, I get to the standard menu
<cnd> I tried resuming boot, but it just returned back to the same menu
<cnd> then I tried netroot
<cnd> and I found that lightdm didn't exist (which I found odd...)
<cnd> I tried to start gdm, got to low graphics mode, but my mouse didn't work
<cnd> kb did, but I couldn't select anything
<kees> where did the gnome font thumbnailer go?
<RAOF> cnd: Lightdm didn't exist, but gdm did?  That's odd.  And, um, I don't think I'll be much more help from here.
<cnd> heh
<infinity>   * Nuke aclocal.m4 before we run ./buildconf to ensure we get it
<infinity>     regenerated correctly, and we get an up-to-date libtoolization.
<infinity>  -- Adam Conrad <adconrad@0c3.net>  Mon,  9 Aug 2004 07:47:46 -0600
<infinity> Can I cry now because I had the solution to this problem seven years ago, and someone seems to have dropped it?
<infinity> Daviey / doko: The above seems to do more or less the right thing.  I'll test a few different scenarios here to make sure it's not a red herring.
<freeflying> pitti: ttf-arphic-ukai ttf-arphic-uming is not necessary for CD
<doko> slangasek, ^^^
<kees> smoser: say, please see my diff for nagios-plugins 1.4.14-5ubuntu3 and do the same in oneiric please :) that change keeps getting lost in that package, and I have no idea why.
<kees> smoser: you'll need to fix up some flawed format-strings too
<kees> check_radius.c:214:2: error: format not a string literal and no format arguments [-Werror=format-security]
<Daviey> infinity: Well i could not reproduce it locally.. and the archive seems to be rebuilding it OK this time.
 * Daviey doesn't like the machine gun approach.. it simply should not work.
<infinity> Daviey: It fails 100% here until I modify it.  But it is disconcerting that it's intermittent.
<Daviey> infinity: what is your build env?
<infinity> Daviey: debootstrap --variant=buildd, bare essential build-deps, shoestring, bubblegum.
<infinity> Daviey: (Basically, the same as the buildds)
<Daviey> wow, not seen someone use that as their normal workflow for a while.
<infinity> Daviey: Anyhoe, if shotgunning it is working for now (ew), I'll go eat some dinner.  But I might upload a proper fix later when I'm sure I can't reproduce it with this change.
<infinity> Daviey: The change is correct whether it fixes the problem or not, so...
<smoser> kees, was that to me ?
<kees> smoser: yup, you merged nagios-plugins and the debian/control change for PIE got lost :)
<smoser> indeed i did :-(
#ubuntu-devel 2011-08-30
<bryceh> slangasek, does the multiarch patch for libxaw on bug 834438 look sane to you?
<ubottu> Launchpad bug 834438 in libxaw (Ubuntu) "Please convert to Multiarch" [Undecided,New] https://launchpad.net/bugs/834438
<Daviey> infinity: sounds good to me!
<kees> smoser: it looks like it's more than just adding it back in, since they appear to have added vulnerable code now, too.
<kees> smoser: so you'll need to fix at least the one flaw that the compiler flags found
<smoser> suck.
<smoser> kees, that can wait til post beta?
<smoser> (i opened bug 837085)
<ubottu> Launchpad bug 837085 in nagios-plugins (Ubuntu) "hardened build option lost in debian/control" [Undecided,New] https://launchpad.net/bugs/837085
<kees> smoser: totally
<kees> smoser: no rush at all. I just happened to notice it today while running the packages-built-with-PIE regression tests
<Daviey> kees: I've noticed over the cycles that you re-introduce PIE on a number of packages. :/
<kees> Daviey: well, people don't always merge correctly. so I wrote regression tests. :)
<micahg> Debian is starting to get into PIE more as well
<kees> micahg: yup, totally. for every PIE change I make, I usually open a Debian bug for it.
<kees> micahg: most have been accepted.
<smoser> kees, it was completely a wrap-and-sort failure :-(
<smoser> eyeballs bad after 80 columns
<Daviey> 14:37 <zul> ok MIRs updates:
<Daviey> oops
<infinity> Away for a few hours, nick hilight me if you need me, I'll be back in the evening.
<kees> smoser: heh, no worries.
<slangasek> bryceh: yes, the patch looks correct to me provided that the package builds with it applied; bear in mind that this gets entangled with the freeze however
<slangasek> (feature freeze)
<bryceh> slangasek, should it wait for post-beta, or delay until p opens?
<slangasek> bryceh: there's risk of regression for reverse-build-deps, so I think it's "delay until p" (preferably pushing to Debian in the meantime)
<bryceh> ok thanks
<bryceh> robert_ancell, how come on some of my test boxes I see a greeter with a pretty password entry field on the left, and on other test boxes I see a centered dialog with more of a gnome-ish looking icon on it.  Am I missing some theme package?
<bryceh> hmm unity-greeter mayhaps
<robert_ancell> bryceh, it sounds like you're running unity-greeter on some boxes and lightdm-gtk-greeter on others
<bryceh> yep, installing unity-greeter did it
<TheMuso> /c
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
<ArneGoetje> pitti: where can I download the Chinese edition for testing?
<broder> cjwatson, stgraber: quick ping re plymouth-upstart-bridge. why not have it connect to the dbus daemon upstart itself runs on @/com/ubuntu/upstart? it seems like that would actually allow us to catch almost all of the events that happen at boot, instead of now when we only see things in the narrow window between when dbus starts and when gdm/lightdm do
<pitti> Good morning
<pitti> freeflying: ah, thanks
<pitti> ArneGoetje: it's not on any public place yet; you can build it with ubuntu-defaults-image, but it's by and large the standard CD plus the full Chinese support (as per language-selector), minus all other langpacks (we keep -en), plus the extra stuff from the ubuntu-defaults-zh-cn package
<ajmitch> morning pitti
<nigelb> Good morning pitti, afternoon ajmitch )
<nigelb> :)
 * nigelb tried to autocomplete afternoon.
<ajmitch> hi nigelb
<ajmitch> heh
<RAOF> :)
<ArneGoetje> pitti: I'm rebuilding the ttf-arphic-uming and ttf-arphic-ukai packages, which will add lzma compression to ukai and remove the dependencies on defoma and x-ttcidfont-conf for both packages.
<ArneGoetje> pitti: I will take a look at the dependencies for the language-support stuff and get back to you later... maybe we can throw something out which is not terribly important.
<pitti> ArneGoetje: I removed the two fonts as freeflying suggested (in bzr, not uploaded)
<ArneGoetje> pitti: ah...
<ArneGoetje> pitti: and still not enough?
<pitti> we can also put them back there, and only install a subset of the Chinese support on the CD, but that's harder to maintain and would still bother people with downloading 20 MB of stuff after installing
<pitti> ArneGoetje: still need to reduce by a bit, but shouldn't be so bad any more; I'll rebuild a CD with that and see what's left
<ArneGoetje> pitti: people will have to download additional packages anyways, since there is no way to fit all of them on the CD... we only need to choose which packages they have to download. ;)
<pitti> ArneGoetje: well, it's not actually that many -- with the two fonts gone, it'll almost fit, and the CD even has some extra stuff like sina/soho gwibber plugins, stardict, nanny, gufw
<ArneGoetje> pitti: but the OEM fonts are not included?
<pitti> OEM fonts?
<ArneGoetje> pitti: ok, they are not. In that case, users will want to download the uming and ukai fonts, otherwise they don't have Song/Kai style fonts for printing.
<ArneGoetje> pitti: but that's OK. For the live CD, the WQY-MicroHei font is sufficient.
<pitti> ArneGoetje: we also have ttf-wqy-zenhei
<pitti> i. e. with the full support we ship microhei, zenhei, and currently ttf-arphic-{uming,ukai}
<pitti> that seems a little excessive?
<pitti> ArneGoetje: ok, reverted the l-s commit
<pitti> I'll update ubuntu-defaults-zh-cn instead
<pitti> to only explicitly depend on a subset and not install the full chinese support
<pitti> that pretty much breaks the idea of check-language-support, but *shrug*
<ArneGoetje> pitti: not necessary, IMHO. ZenHei is the same style as MicroHei, but covers more characters IIRC. However, for daily use, MicroHei is sufficient.
<ArneGoetje> pitti: uming and ukai are different font styles, which are mostly used for printing.
<ArneGoetje> pitti: why would updating ubuntu-defaults-zh-cn break check-language-support?
<pitti> I mean, we can't use it, but would use an explicit dependency list
<pitti> it's not a big deal, we just need to update it whenever pkg_depends changes
<ArneGoetje> pitti: sure
<pitti> and it would still mean that Chinese users had to download stuff during installtion
<ArneGoetje> pitti: of course and I guess that's inevitable
<ArneGoetje> pitti: I just wonder why all of a sudden you care about a Chinese edition, when all the years we said we don't want specific language editions...
<pitti> ArneGoetje: we have had a Chinese Edition since Maverick
<pitti> but it's rather poor, it's exactly like the standard CD just with the language default being zh_CN
<pitti> now we want to do a proper Chinese one with more localization/special programs/web launchers etc.
<ArneGoetje> pitti: ah really? Will this also happen for other languages?
<pitti> ArneGoetje: not on cdimage.u.c. (at least just yet), but with ubuntu-defaults-builder we now offer tools for Locos etc. to build their own
<ArneGoetje> pitti: good.
<pitti> ArneGoetje: e. g. the French loco has been building French CDs for a long time, and now they get better tools
<ArneGoetje> pitti: does this also work with DVD images?
<pitti> not yet
<pitti> well, of course the defaults packages can pull in arbitrarily many dependencies
<pitti> but ubuntu-defaults-image currently bases off the standard Ubuntu CD set, not the USB/DVD one
<pitti> but that should be rather easy to add
<ArneGoetje> pitti: I can imagine that for some Locos DVD images should be more interesting... in TW for example a very popular Ubuntu spin-off is Ezgo, which puts everything education related, plus full localization on a DVD.
<ArneGoetje> pitti: anyways, I would suggest to remove the zenhei, uming and ukai fonts from the live CD, but let the users download them during insstallation.
<pitti> okay
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<didrocks> good morning
<pitti> doko_: nice, did you see sqlite on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
<pitti> doko_: do you want to have the honor of demoting it, or want me to? :-)
<dholbach> good morning
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<jamespage> morning all
 * dholbach hugs jamespage
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, can you approve c2esp? It is a fix of a security problem. The printer maintenance filter of the driver generates temporary files with a fixed name.
<cjwatson> broder: I would except that's formally private to upstart and other packages are not permitted to depend on its interface.  if I'd elected to make plymouth-upstart-bridge part of upstart, that might be different
<pitti> tkamppeter: ok, looks harmless enough
<tkamppeter> pitti, thanks.
<OdyX> tkamppeter: ah, I'm currently patching pxljr because it embeds both ijs and libjpeg (dunno how it could end in Ubuntuâ¦)
<tkamppeter> OdyX, IJS it embedded all the time, libjpeg I have embedded recently, because of bug 777670. Now, where libjpeg6b is fixed, the embedding is not needed any more.
<ubottu> Launchpad bug 777670 in pxljr (Ubuntu) "wrong colors on HPCLJ 3500/3600 printer after switching to 11.04" [Medium,Fix released] https://launchpad.net/bugs/777670
<OdyX> tkamppeter: I'd be happy to see an updated upstream release with libjpeg and ijs thrown out of the source (I'll upload 1.3+repack0 with a patch that enables build with system ijs and libjpeg).
<tkamppeter> OdyX, my Ubuntu package uses the pxljr upstream version with embedded libjpeg, one should somehow switch to the one without, but in a way that Ubuntu can merge it.
<OdyX> tkamppeter: oh, there is one upstream version without libjpeg ?
<tkamppeter> OdyX, you should contain upstream maintainer Hin-Tak Leung and send him a patch.
<OdyX> tkamppeter: will do once pxljr is accepted in Debian
<cjwatson> argh, so many broken cmake libraries in the archive
<cjwatson> it's like dependency_libs only worse
<doko_> pitti, heh, go ahead =) Daviey did give it back one more time, and it did succeed to build ...
<pitti> doko_: heh, sometimes being insistive seems to help :) demoted
<doko> Sweetshark, ping
<jtaylor> did the Release signing break again? got another bad signature from main archive made Tue 30 Aug 2011 11:16:37 AM CEST
<tkamppeter> pitti, can you approve system-config-printer? I had to apply a small patch as one of my patches from last week broke the printer maintenance buttons (head cleaning, ...).
<pitti> tkamppeter: sounds like that would have time until after b1, though?
<tkamppeter> pitti, OK. Will it get approved then? I am on vacation from this Thursday until the Friday of the next week.
<pitti> tkamppeter: yes, the queue will be flushed after b1
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tkamppeter> pitti, OK, so I simply upload further fixes which I will find and the not urgent ones get into Oneiric after b1. OK.
<Sweetshark> doko: pong
<hrw> is simple-ccsm used at all today?
<janimo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: janimo
<janimo> dholbach, hello. Can I unsubscribe sponsors from a bug? I see no such link in LP
<janimo> dholbach, AIUI needs-packaging bugs do not needs sponsors (yet) as packaging can be done without upload privileges
<dholbach> janimo, I added you to ubuntu-sponsors
<dholbach> does it work now?
<dholbach> janimo, is the new package in the bug ready to be sponsored maybe?
<dholbach> slangasek, hiya - how do you feel about bug 837383?
<ubottu> Launchpad bug 837383 in ia32-libs (Ubuntu) "Add libqt4-dbus, libqt4-gui, libxss1 to make skype work" [Undecided,New] https://launchpad.net/bugs/837383
<janimo> dholbach, there was no package attached, just a need-packaging tag, Thanks for adding me to sponsors
<janimo> hmm. there's a REVU link though. I stand corrected
<dholbach> stgraber, https://launchpad.net/arkose says there talks about an arkose-wrapper package - is that available somewhere?
<dholbach> janimo, no worries :)
<stgraber> dholbach: arkose-wrapper-gui /usr/share/arkose/wrapper-profiles/skype.conf
<stgraber> dholbach: on Oneiric
<dholbach> arkose-gui you mean?
<dholbach> yeah, I see it - thanks :)
<soren> dholbach: You can install all of those using multiarch these days.
<soren> dholbach: I got skype to work that way.
<dholbach> soren, yes,  I guess I should have just installed skype_something_i386.deb
<dholbach> soren, but people who upgrade might be in for a nice surprise
<OdyX> tkamppeter: do you have a possibility to test pxljr ? FYI, I pushed my work on http://anonscm.debian.org/gitweb/?p=collab-maint/pxljr.git;a=summary and I'd appreciate "review" (aka does it work).
<janimo> can someone allow gnome-utils in, so further patch pilots do not try to do the same work again?
<pitti> janimo: can't you just unsubscribe sponsors from the bug?
<slangasek> dholbach: 837383 is a wontfix - you need to install skype:i386 instead :)
<slangasek> dholbach: as soon as there's an updated skype package for oneiric in partner, ia32-libs in oneiric will declare a Breaks: on the old versions
<janimo> pitti, it is that what I could not do, before dholbach added me to the sponsors team. I though every uploader is a sponsor implicitly
<janimo> but turned out sponsors may need to remaIn subscribed as there is a REVU link on the bug I looked at
<tkamppeter> OdyX, will do.
<janimo> pitti, ah, you mean as an alternative to the moderation
<OdyX> tkamppeter: great, thanks.
<janimo> good idea, will do that, thanks!
<dholbach> slangasek, so we won't have a way to upgrade skype? (if I understand correctly, folks will have to upgrade, then notice that skype is gone, then install skype through software-center?)
<pitti> janimo: i. e. if you upload a package, and it won't hit the archive right away (freeze or SRU), I think ubuntu-sponsors should generally be unsubscribed to get it off the queue, yes
<tkamppeter> OdyX, I have downloaded your GIT, the debian/changelog seems not to be up-to-date yet.
<OdyX> tkamppeter: it's never. I prepare it just before uploading using git-dch + hand-editing.
<tkamppeter> OdyX, and where do I get the .orig.tar.gz to be able to build the package?
<OdyX> tkamppeter: try to build with 1.3+repack0-0ubuntu1 e.g
<OdyX> tkamppeter: git-buildpackage -S (will use pristine-tar
<OdyX> tkamppeter: or pristine-tar checkout pxljr_1.3+repack0.orig.tar.bz2; mv pxljr_1.3+* ../
<slangasek> dholbach: I believe they will be able to automatically upgrade to the i386 skype package
<dholbach> slangasek, that'd be nice
<slangasek> can't test this for certain until there's an i386-only skype package in the partner archive though
<dholbach> ok
<OdyX> tkamppeter: here it does compile against libjpeg8 and libijs-0.35, no idea if it works sanely though (and that's what I'd like to know)
<OdyX> tkamppeter: the thing is I cannot upload a source that uses embedded libraries to Debian.
<tkamppeter> OdyX, problem is that you do not provide the newest debian/changelog entry, as this one defines the version number.
<tkamppeter> OdyX, it would be much more convenient to have this entry in the GIT, so that one can simply build the package from the GIT.
<OdyX> tkamppeter: dch -b -v 1.3+repack0-0ubuntu1~local0 "TEST-BUILD"
<OdyX> tkamppeter: well, that's my imperfect git-dch workflow. I know it has flaws, but it works-for-meâ¢
<mr_pouit> superm1: xubuntu doesn't ship a default lightdm.conf file. If lightdm-set-default creates it with wrong values, then it should be fixed I guess (adding workarounds for that in the postinst looks like a bad idea?)
<superm1> mr_pouit, that's why i was proposing the user-setup solution to follow the casper solution rather than sed values that aren't put by lightdm-set-defaults
<tkamppeter> OdyX, why keeping changelog messages as private secrets, they can also be handled by version control.
<OdyX> tkamppeter: git-dch uses the commit messages to generate the debian/changelog, they are not secret. (This way I avoid writing them twice)
<OdyX> (and forces me to write nice commit messages. You can also use meta-tags: Signed-off-by, Reported-by, Closes, â¦ and assign stuff to people correctly with --author="â¦")
<tkamppeter> OdyX, it does not link for me, http://paste.ubuntu.com/678064/
<mr_pouit> superm1: sorry, I don't really follow the discussion, so I've probably no idea what you're talking about (I just reacted to some comments charlie-tca forwarded to me). I'm just saying that we don't ship any default config (and we don't intend to), we only rely on lightdm-set-default.
<OdyX> tkamppeter: do you have libijs-dev installed !?
<OdyX> (and libjpeg8-dev)
<charlie-tca> heh, I haven't been able to follow the discussion either. I just got asked and told we needed to do something
<superm1> mr_pouit, OK, it was discussion in #ubuntu-installer with ev and stgraber about user-setup's solution for lightdm autologin
<OdyX> tkamppeter: Agreed, my auto*foo is bad and I don't check those in the build process, but they are listed as build-depends)
<tkamppeter> OdyX and your package does not build-depend on these libraries.
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity, janimo
<infinity> Fair warning, my cable is out and I'm stuck tethering on 3G right now, but still happy to pilot urgent things, if people have any.
<OdyX> tkamppeter: huh ? It does.
<tkamppeter> OdyX, it build-depends on libjpeg-dev which conflicts with libjpeg8-dev (at least in Oneiric).
<OdyX> tkamppeter: huh ? In Debian, it's a "Provides"
<OdyX> tkamppeter: in any case, I have to go, sorry. I'd love some feedback per mail or as a separate branch on the git repo.
<tkamppeter> OdyX, in Ubuntu, libjpeg-dev is still provided by libjpeg62-dev and several library's -dev packages depend on libjpeg62-dev (libjpeg-dev).
<OdyX> tkamppeter: it should build with B-D: libjpeg-dev | libjpeg8-dev
<OdyX> anyway, I'm really late, have to go ! Cheers
<tkamppeter> OdyX, see you tomorrow.
<janimo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<Daviey> jdstrand: Did you get the mail from Thomas regarding the mythbuntu-bare reject?
<jdstrand> Daviey: I have it but didn't see it. I'll respond
<SpamapS> ARGH! mongodb now embeds spidermonkey in its source tree
<micahg> SpamapS: not a problem, Debian switched to v8 and we'll follow for P
<SpamapS> micahg: upstream is only going to support their in tree spidermonkey. :(
<SpamapS> They're also switching to static linking by default
<SpamapS> Basically "screw our users' security, we know better"
<Daviey> jdstrand: thanks
<micahg> SpamapS: hmm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631054#19
<ubottu> Debian bug 631054 in src:mongodb "mongodb: FTBFS against iceweasel 4.0 or 5.0" [Serious,Fixed]
<SpamapS> micahg: yeah, thats a sensible solution. I'm more concerne that upstream will now really dislike the Debian and Ubuntu packages.
<SpamapS> they already derride them because they're so far behind Mongo's usual release schedule
<pitti> lamont, infinity: could you please kill the linux build on crested?
<pitti> I set it to manual now as we are going to need some urgent uploads for beta-1
<pitti> and we can't afford having three linuxes build at the same time (each taking 6 hours)
<pitti> they just started, so not much will be lost
<pitti> lamont, infinity: linux build on yellow, too, please
<pitti> elmo: or can you do it? infinity can't any more
<infinity> pitti: IS contacted, deej is on it.
<pitti> infinity: cheers
<pitti> infinity: nice, done now; thanks!
<pitti> argh, darn
<pitti> infinity: someone switched it to auto (or the restarting did)
<pitti> infinity: we need crested build killed again :/
<pitti> ithanks
<infinity> pitti: Should be good to go.
<pitti> right
<pitti> sconklin: please ignore the linux build failures that you just got
<pitti> sconklin: we had to kill some amd64 builds, as they got in the way of beta-1 release, sorry
<pitti> sconklin: I'm retrying the builds and lowering their score
<infinity> sconklin: (And on a side note, please don't upload a ton of kernels to non-virtual PPAs during a beta/release freeze)
<sconklin> pitti, thanks for the warning
<infinity> sconklin: If you do it serially, that would be alright, but clogging up all the buildds in parallel can be problematic.
<sconklin> pitti, we don't really have any sort of interlock with stable cycle and freezes, nor do we want to.
<sconklin> and our whole cycle is that we tend to do them all at the same time. So I think this needs more discussion.
<pitti> sconklin: yeah, in most cases it's not a problem, just right now; so I had to kill the lucid/maverick ones, but they should build in a couple of hours
<infinity> sconklin: In an ideal world, we'd have slightly better control over how we can allocate these resources.  We'll revisit it. :P
<infinity> pitti: I'm going to steal one of your amd64 buildds for a 2-minute build and give it right back. :)
<pitti> infinity: sounds fine, please go ahead
<pitti> infinity: in fact, the other buildd would be fine to grab small packages, just not the linuxes
<infinity> Or... Nevermind, it just built on allspice.
<cjwatson> Picking 'sushi' as source package instead of 'maki'
<cjwatson> ... ah, one of *those* naming schemes
<pitti> frankly I'd rather pick a pizza now
<infinity> pitti: Send me one too, please.
<SpamapS> slangasek: with the upload of libpam-heimdal to maverick-proposed .. was the plan to also copy the binaries to natty-proposed ?
<SpamapS> slangasek: otherwise seems like the version needs to be 3.15-2ubuntu2.10.10
<slangasek> SpamapS: yes, was intending to copy the one binary to both
<SpamapS> slangasek: ok sounds good
<Sweetshark> sooo, whats the best way to binary patch something in a package? apart from "dont"?
<pitti> infinity: what was the package for the pizza IRC plugin again?
<ion> sweetshark: Iâm doing that hack with diversions. Itâs nasty, but it works. https://github.com/ion1/gsd-lcdfilter https://launchpad.net/~ion/+archive/gsd-lcdfilter/+packages
<kirkland> fresh install of ubuntu oneiric server today, and / is getting mounted read-only ... known bug or perhaps something new?
<kirkland> cjwatson: ^
<kirkland> cjwatson: i'm trying a second time now, to see if i can reproduce it
<infinity> pitti: You can just jam a pizza in your CD drive and udev will link it to /dev/pizza, which you can then DCC to me.  Thanks in advance.
<janimo> Sweetshark, what kind of binary patch?
<pitti> infinity: it failed at 97%, but that might be enough for dinner; add the missing slice of salami yourself
<infinity> pitti: If your pizza's being truncated, it's probably too high density, might need a Blu-ray player.
<broder> that would be one tasty pizza
<Sweetshark> janimo: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/756895 <- change to icons (pngs) done on the master branch, but after branch off of the release branch.
<ubottu> Launchpad bug 756895 in libreoffice (Ubuntu) "Include updated Humanity style" [Wishlist,Fix committed]
<doko> Laney, did you look at haskell on arm and powerpc and find out what is the blocking thing?
<Sweetshark> janimo: git can create binary patches, but I know if they can be applied to raw files without a repo below it -- also I would need git as a build dep (not that it would matter much for LO)
<janimo> Sweetshark, is doing that as a backport an option? I see that seems to be implied by your last comment on the bug. It may be cleaner that way
<broder> Sweetshark: libreoffice is a v3 source package, so just drop the icons in the debian/ directory and copy them over the original versions during build
<infinity> doko: Did you want me to do those ocaml syncs, or are you on it?
<infinity> doko: Oh, nevermind, I see them.
<doko> infinity, you could accept a few universe packages from unapproved instead ;)
<Sweetshark> broder: could do. but those images are quite a few ...
<Sweetshark> janimo: doing it as a backport is certainly an option.
<broder> Sweetshark: put the images in the same directory structure they'll be in when they're installed (i.e. if they're all going in /usr/share/icons/stuff, create a "debian/stuff" directory), then you can just specify "debian/stuff usr/share/icons/stuff" in a .install file
<Sweetshark> broder: its not that easy as LO is currently still a rather perverted package: Its *.orig tarball contains again tarballs with the real source which are then unpacked during the build. which makes all patching a PITA.
<broder> Sweetshark: yeah, i was looking - it's impressively messy :)
<broder> but i think you could patch this in in the install target of the rules file just before you call dh_install
<Sweetshark> broder: right.
<broder> so:
<broder> - put the images in the debian/ directory, so they get included in the debian.tar.gz
<broder> - patch debian/rules install target to include that debian/ subdirectory in the libreoffice-common.install file, or wherever it is that it's going
<Sweetshark> janimo: as for backports: I could also propose the commits to be cherrypicked to 3.4 for the 3.4.4 release, so they would be included in that release (which we would likely SRU anyway) http://wiki.documentfoundation.org/ReleasePlan/3.4#3.4.4_release
<janimo> Sweetshark, yeah, that would be best, it should be a safe change
<janimo> the less package changes the better :)
<Sweetshark> broder: naa, I have to copy the files into the source after the tarballs have been unpacked and before the "real" build is started. the images get packed again in some zip-file with some additional magic. And the zip-file is the stuff that goes in the final package later ;)
<Sweetshark> janimo: ohh, in LibreOffice we only have ~50 patches to upstream.
<broder> Sweetshark: you don't need the files to be in the original source. instead of replacing them at build time, you can replace them during the package's install target in place on the DESTDIR
<Sweetshark> broder: I am not installing the pngs, I am installing a special zip-file where the pngs have been packing into after some namemangling magic.
<infinity> Sweetshark: So, you need a bit of magic to copy from debian/ to the source tree before the build.  And if you want debian/rules clean to actually work, you need to back up the originals, and have clean put them back in place.
<infinity> Well, unless the build system is smart enough to pick up your copies if you put them in build/path/to/where/they/live/in/src/file.png
<infinity> Then no real magic required, you just need to put them there at the beginning of your build.
<Sweetshark> infinity: I dont have to care about the clean target, as clean deletes the unpacked tarballs completely regardless of if they are patched or unpatched.
<Sweetshark> infinity: right.
<infinity> Sweetshark: Shiny.  Then yeah, not terribly difficult sounding.
<Sweetshark> infinity: I was just hestitating to dump all the binaries in debian/ ..
<infinity> Sweetshark: Well, you could also do it as an extra orig tarball.
<infinity> Sweetshark: libreoffice.orig-icons.tar.gz
<infinity> (making sure that "icons" is a unique directory name not in the source)
<infinity> dpkg v3 format will unpack orig-$foo to $foo/ in the source.
<Sweetshark> infinity: yeah, thats what I had before (although that was the complete theme, not only the updates) ...
<Sweetshark> that would be 256 icons a approx. 4K each
<ahasenack> hi guys, for a new python package for lucid, or any other distro where dh_python2 isn't available, what is recommended: python-central or python-support?
<infinity> support, I believe, was the old new hotness before the new new hotness of dh_python2.
<infinity> But I lose track of these things.
<ahasenack> yeah
<ahasenack> I used -support in two packages but hit an issue with a twisted plugin, seems I need to create a .noinit file
<ahasenack> python-central works without this hack
<ahasenack> funny, the README of python-support even mentions twisted as a special case, calls it broken, etc ;)
<infinity> I won't disagree with that.
<infinity> Twisted and I aren't really on speaking terms.
<Sweetshark> heh, ok. the icons are ~1MB and the packaging repo for LO is >300MB -- no, I wont use a ext-tarball.
<doko> mrpt throws in every optimization level and sees what wins ... -g -O2 ... -Os ... -g -O2 -Os ... -O3 ...
<infinity> Sweetshark: Hrm?  Another tarball would have the same size effect as putting them in debian/, just lands them elsewhere in the source.
<infinity> doko: Niiice.
<doko> and then fails with
<doko> virtual memory exhausted: Cannot allocate memory
<doko> make[3]: *** [tests/CMakeFiles/test_mrpt_base.dir/__/libs/base/src/math/matrix_ops_unittest.cpp.o] Error 1
<doko> we optimize our tests!
<infinity> doko: Oh, was that the one that failed on arm after two days of grinding?
<doko> infinity, yes. you want to fix this before giving back stuff ... imo -O2 should be fine
<infinity> doko: It's vaguely on my post-beta radar.  Wasn't going to worry about it just now.  If you have a fix, go nuts. :P
<infinity> I didn't even notice that was the testsuite exhausting the VM, not the actual application.  That's pretty special.
<infinity> (well, it's g++, but I assumed it was g++ grinding on a massive cpp file that mattered, not a stupidly-written testsuite)
<infinity> ...
<infinity> CFLAGS="-g -O2 -Os" on the configure line?  Reall?
<infinity> y
<infinity> I had assumed broken build system, not broken maintainer. :P
<infinity> And then the build system adds O3 later.  Hahaha.
<infinity> doko: Yeah, this is special.  Thanks for the laugh.  I needed it. :)
<debfx> ScottK: is there some documentation available on how to upgrade packages to the version from backports?
<Sweetshark> doko, infinity: http://funroll-loops.info/
<debfx> ScottK: and is there a bug report about packages not being able to build-dep on other packages from backports?
<ScottK> debfx: I think so.
<ScottK> debfx: I don't think we've done documentation on this, but it's the same as installing from a pinned repository (which we do eocument)
<ScottK> debfx: Bug #828017 is the bug on build-deps.
<ubottu> Launchpad bug 828017 in Launchpad itself "UnparsableDependencies raised by retry-depwait script" [Critical,Triaged] https://launchpad.net/bugs/828017
<madnick> Anyone happen to know what invokes plymouth with a prompt to remove installation media?
<madnick> after desktop install :)
<debfx> ScottK: thanks
<broder> madnick: it's /etc/init.d/casper
<madnick> broder: thanks
<doko> I like this chromium start page ..
<doko> Most visited:
<doko>   lp: Oops ...
<astraljava> Okay, I'm a bit of a newbie (although having been involved with Studio since '06) when it comes to working with bzr branches and those becoming to packages. I have mainly been working with desktop in ubuntustudio seeds. Was recently informed though that that's not what I should ask for when wanting things uploaded.
<astraljava> ubuntustudio-meta is what needs to be uploaded.
<astraljava> So my question really is, how does it work, so that if I upload a new commit to ubuntustudio.oneiric branch, how soon can I ask for ubuntustudio-meta to be uploaded?
<cjwatson> astraljava: five minutes at most
<astraljava> cjwatson: Alright, thanks (again!) :)
<cjwatson> there's an every-five-minutes cron job that pulls to http://people.canonical.com/~ubuntu-archive/seeds/, which is where germinate-update-metapackage pulls from, which is what the ./update script in ubuntustudio-meta calls
<cjwatson> all a developer needs to do is run ./update, review the changes, and upload
<astraljava> Right, that's good info.
<Daviey> cjwatson: if --bzr is used, surely it can be done straight away?
<cjwatson> oh, yeah, that's probably true
<cjwatson> I figure five minutes isn't worth worrying about either way :)
<Daviey> good point.
<infinity> astraljava: Did you need someone to do said upload for you, or is this a hypothetical situation right now? :)
<astraljava> infinity: Colin took care of it this time. But I was advised to ask here in the future. Thanks, anyhoo! :)
<infinity> astraljava: I saw, yes.
<astraljava> Okay, one more question, ubuntustudio-menu has it's own branch in LP. How can we get a new .deb rolled from it? Does the feature freeze affect that now?
<infinity> astraljava: Feature Freeze affects pretty much everything, yes, but if there's sufficient justification, exceptions can be made.
<slangasek> in particular, the ubuntustudio team gets to tell us what is or isn't critical for ubuntustudio packages
<slangasek> (within reason)
<infinity> ^
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2011-08-31
<mwhudson> so still getting occasional freezes in natty then :( (sandy bridge)
<mwhudson> RAOF: good morning :)
<RAOF> mwhudson: Yo :)
<mwhudson> RAOF: is there any way i can debug random occasional system hangs
<mwhudson> ?
<RAOF> mwhudson: If it's a GPU hang then /sys/kernel/debug/dri/0/i915_error_state should contain a fine haul of GPU state that will be incomprehensible to mortals but very useful for people who've actually internalised the i915 developer docs.
<mwhudson> sadly it says "/sys/kernel/debug/dri/0/i915_error_state"
<mwhudson> how do i tell if it's a GPU hang?
<mwhudson> i was assuming it was but maybe not
<RAOF> If you ssh in then everything but the display should work.
<mwhudson> (looking at that file after rebooting obviously...)
<mwhudson> ah ok
<RAOF> Yeah, that file's only good while the kernel's up.
<mwhudson> it feels 'more hung' than that
<mwhudson> but haven't actually tried ssh for a while
<RAOF> If you turn on apport it should pick up on a gpu hang and record that data for you.
<mwhudson> how do i do that? :)
<RAOF> Twiddle the knob in /etc/default/apport
<mwhudson> so twiddled
<mwhudson> which will presumably prevent all hangs for at least a month
<RAOF> That's the way it rolls :)
<mwhudson> (i should say this situation would be good in some ways :p)
<RAOF> mwhudson: In case you're interested, oneiric now is doing well by this (particularly troublesome) SandyBridge.
<mwhudson> RAOF: right, i was somewhat assuming that the real answer is "upgrade to o"
<RAOF> Well, it shouldn't be.  :/
<RAOF> It might be the easiest answer, though.
<pitti> Good morning
<madnick> morning
<didrocks> good morning
<BigWhale> Where would I go to ask something about Vala and GTK3 and positioning of widgets? :)
<astraljava> Thanks infinity and slangasek! I'm filing that bug then, soon.
<jamespage> doko_: around?  have a bit of a maven2/antrun-plugin pickle caused by a sync last week that I could do with an opinion on
<doko_> jamespage, yes, online
<jamespage> doko_: OK - so there was a sync of maven-antrun-plugin last week which upped the version from 1.3->1.6
<jamespage> doko_: unfortunately this breaks anything using the antrun-plugin without an explicit version as 1.3 is declared in the global maven2 POM - I hit this is Debian when the change happened there
<jamespage> doko_: it needs a sync of maven2-core and maven2 to update to 1.6 - but that also pulls in two other package version upgrades - maven-plugin-tools and jtidy
<jamespage> doko_: I could either go for FFE's on those two packages (but there is a possibility of further impact that we are not aware of) or I could delta maven2-core and maven2 in Ubuntu to fix this specific issue
<jamespage> doko_: I raised the syncs and then had second thoughts - hence the ping
<jamespage> doko_: whats your opinion
<jamespage> ?
<doko_> jamespage, ouch. I wouldn't worry much about maven-plugin-tools, I'll have a look at jtidy
<jamespage> doko_: thanks
<jamespage> doko_: so we should go with the syncs/upgrades if possible then?
<doko_> urgh, jtidy update from 2007 to 2011 ...
<doko_> jamespage, jtidy hasn't many rdepends, and just jmeter is out of sync
<doko_> jamespage, well, I would aim for the syncs. it doesn't look too bad
<jamespage> doko_: ack - on it now
<OdyX> tkamppeter: could you please retry pxljr from the git repository; I fixed the repacking that threw too much stuff out and now the test command doesn't fail anymore here. Still have to try a real print, but linking + test-command works.
<agateau> bdrung: hi, I have been told you maintain lp-project-upload. It stopped working here. Do you have a few minutes?
<tkamppeter> OdyX, will do.
<OdyX> tkamppeter: (the issue what that I stripped more than needed of the jpeg convenience copy and then broke something. Restoring those files make the printing work here (tested over internet to my father's printer :-) )
<bdrung> agateau: i co-maintain ubuntu-dev-tools, but i didn't wrote lp-project-upload. looking at the source code, i found Martin Pitt (pitti) and Dustin Kirkland (kirkland).
<agateau> bdrung: oh ok, will ping one of them then, thanks
 * agateau picks a name at random
<agateau> pitti: hi, do you have a few minutes to look into an lp-project-upload problem?
<pitti> agateau: what's the problem?
<agateau> pitti: it fails to upload, telling me something like this: "Could not connect to Launchpad: File contains parsing errors: <???>"
<agateau> pitti: and then two other lines of <???>
<pitti> that sounds like a launchpad lib problem -- can you try moving ~/.launchpadlib away ?
<agateau> pitti: sure
<agateau> pitti: same error :/
<pitti> agateau: do you get the same with lp-shell ?
<agateau> pitti: never used lp-shell, let me try
<agateau> pitti: yes, with a backtrace
<agateau> pitti: http://pastebin.com/hzAqkWfj
<pitti> apparently something is wrong with your credentials file
<pitti> but I'm not sure where lplib takes that from; I had assumed ~/.launchpadlib/
<pitti>     def do_load(self, unique_key):
<pitti>         """Retrieve credentials from the keyring."""
<pitti> oh
<pitti> gnome-keyring
<pitti> so it somehow needs to be removed there, or better yet, the launchpad guys should have a look why the broken one got in in the first place
<pitti> I don't see an obvious one in seahorse
<agateau> could it be related to me running kde?
<pitti> and I really have no idea how lplib handles credentials since the natty version, I'm afraid; that made everything utterly complicated
<pitti> agateau: could be; it might try the KDE equivalent of the keyring
<agateau> pitti: so next step would be to ping the launchpad guy then, right?
<agateau> s/guy/devs/
<pitti> yeah; I'm afraid I have no knowledge about its current key handling :/
<agateau> pitti: no problem, thanks for pointing me in the right direction
<debfx> agateau: are you using natty or oneiric?
<agateau> debfx: oneiric
<debfx> I remember having similar issues with python-keyring in natty
<agateau> debfx: did you find a workaround?
<debfx> agateau: you could try to remove the launchpadlib entries from kwallet, maybe that helps
 * agateau tries
<agateau> debfx: it fixes in once: I get to authorize lp-shell from launchpad again, lp-shell works correctly, but if I start it again it fails
<agateau> debfx: there is probably something wrong with the way credential are stored
<tkamppeter> OdyX, the ijs_pxljr executable in your package is now built correctly. I can actually print in all three quality modes.
<OdyX> tkamppeter: yay, great. Then if you don't have more comments, I'll prepare the (secret) changelog and upload to Debian (where it will spend some time in NEW anyway).
<debfx> agateau: ah now I remember, I came up with this workaround: http://pastebin.com/raw.php?i=T0YiYKz6
 * agateau tries
<agateau> debfx: it works! thanks!
<agateau> debfx: did you file a bug for that?
<debfx> agateau: no, I'm not sure if it's a bug in launchpadlib oder python-keyring
<tkamppeter> OdyX, OK.
<agateau> debfx: I have no idea either, but I assume the launchpadlib devs would know
<debfx> s/oder/or/ ^^
 * agateau knows a bit of german :)
<OdyX> tkamppeter: cool, thanks for the review and test !
<tkamppeter> OdyX, I want to replace/update the upstream snapshot of foomatic-db in the foomatic-db package GIT. How do I proceed?
<OdyX> tkamppeter: uscan --verbose downloads the latest; then git-import-orig
<OdyX> tkamppeter: actually; git-import-orig --pristine-tar
<OdyX> tkamppeter: make sure to have a big enough TMPDIR (/tmp) or override it with TMPDIR=~/
<tkamppeter> I am in the foomatic-db directory cloned from GIT and I am in the master branch. There I have entered the command "uscan --verbose" and after some time the download into the parent directory  (..)  happened.
<tkamppeter> OdyX, ^^ Then I ran, staying in foomatic-db/, "git-import-orig --pristine-tar ../foomatic-db_20110831.orig.tar.gz" and get
<tkamppeter> gbp:error:
<tkamppeter> Repository does not have branch 'upstream' for upstream sources. If there is none see
<tkamppeter> file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
<tkamppeter> on howto create it otherwise use --upstream-branch to specify it.
<tkamppeter> OdyX ^^
<OdyX> tkamppeter: git checkout upstream
<OdyX> tkamppeter: this creates a "--track" branch from the upstream branch on the remote repository
<OdyX> you could checkout pristine-tar too
<OdyX> and then checkout master again before runninf the git-import-orig
<OdyX> ah tkamppeter: did pxljr compile with the B-D on libjpeg-dev or do you need a libjpeg-dev | libjpeg8-dev ?
<debfx> agateau: there you are: bug #838108
<ubottu> Launchpad bug 838108 in python-launchpadlib (Ubuntu) "authorization fails with the kwallet backend" [Undecided,New] https://launchpad.net/bugs/838108
<agateau> debfx: thanks, marked it as affecting me
<sladen> pitti: cjwatson: https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/835161  is this the timestamp file being created by packages too early---not entirely where to send it as presumably the fix to to have the menu back-off until it sees that the upgrade process has actually happened, beforing the reboot-required?
<ubottu> Launchpad bug 835161 in indicator-session (Ubuntu) "Red light on shutdown menu goes on before updates are complete" [Undecided,New]
<cjwatson> the timestamp file can't be created later without decoupling it from packages, which is bad for maintainability reasons
<cjwatson> so I think it'd be better for the menu to back off, yes
<tkamppeter> OdyX, for pxljr I did not need to modify debian/control. So the B-D on libjpeg-dev worked out for me, building the package with libjpeg62.
<tkamppeter> OdyX, import of new foomatic-db source worked for me now. Thanks.
<OdyX> tkamppeter: greatÂ²
<tkamppeter> OdyX, is it enough to "git commit -a", "git push", and "git push --tags" in master or do I have to do this sequence in all master, upstream, and pristine-tar?
<OdyX> tkamppeter: it depends on your configuration. I usually "git add" only what I want in the commits, then commit, then git push <remote> <branches,tags,..>, explicitely specifying what I want to push.
<OdyX> in your case that would be git push origin master upstream pristine-tar upstream/20110831 ubuntu/20110831-0ubuntu1 e.g.
<janimo> Sweetshark, can we close the 'enable binfilter on ARM' as wontfix?
<tkamppeter> Can it be that LP is down currently?
<sladen> tkamppeter: it was, I went and made drinks
<nigelb> sladen: Could use of time
<Sweetshark> janimo: yes, binfilter will be killed upstream anyway rather sooner than later (god riddance)
<janimo> tkamppeter, LP gave me some timeouts a few minutes ago too
<tkamppeter> It came back again.
<hallyn> slangasek: woudl you (as last submitter :) accept a merge of systemtap from sid for oneiric still?
<hallyn> bc without a commit from jun 21, it seems unusable
<hallyn> http://comments.gmane.org/gmane.linux.systemtap/17948 in particular
<slangasek> hallyn: it should go through the FFe process; of course if it's currently unusable, the barrier is lower, but we should still weigh the advantages of a full update vs. a cherry-pick
<hallyn> makes sense.  thanks.
 * hallyn starts by filing lp bug ...
<ScottK> jelmer: I see bzr 2.4.0-3ubuntu1 in the unapproved queue, so I'm going to reject 2ubuntu1.
<bdmurray> slangasek: this is a plymouth bug right? http://imgur.com/85iDX
<slangasek> bdmurray: what's the complaint?  That's the plymouth text screen; is the complaint that it's not graphical?
<bdmurray> slangasek: no the cursor at the end of the .....
<slangasek> bdmurray: ah - is that persistent? I wondered if it was caught mid-flight
<slangasek> would be a plymouth bug anyway, yes
<bdmurray> slangasek: it showed up close to the end and blinks
 * hallyn curses the warn-on-set-but-not-used busywork
<cjwatson> if you feel it's too much busywork, drop -Werror
<cjwatson> (which is a constant pain in the rear at a distribution scale anyway)
<hallyn> i'm not adding -Werror though...  i thought that was being auto-added now?
<cjwatson> no
<cjwatson> that would be insane
<hallyn> yeah...
<hallyn> eh, I think I see it, thanks
<bdmurray> slangasek: bug 838218
<ubottu> Launchpad bug 838218 in plymouth (Ubuntu) "blinking cursor seen at EOL during test boot screen" [Medium,New] https://launchpad.net/bugs/838218
<slangasek> bdmurray: ta
<cr3> pitti: how could I tell what might be the impact of adding a dependency to the size of the desktop image?
<cr3> hm, that actually sounds like a job for germinate which I endup having to relearn every six months :(
<infinity> Am I missing some critical package to make GTK3 applications get properly themed in Xubuntu, or are they just doomed to be ugly?
<pitti> cr3: try to apt-get install it in a live session
<superm1> infinity, you need to pick a GTK theme in the xfce4-appearance-properties that contains a GTK3 option
<superm1> just fixed it for mythbuntu by creating a copy of Ambiance's gtk3 theme and Dust's gtk2 theme in a single "Mythbuntu" theme
<infinity> superm1: Ahh, oh.  Is there a way to tell that from the UI, or do I just need to dig through the filesystem?
<lynxman> Hey everyone, I'm trying to solve bug 818177
<ubottu> Launchpad bug 818177 in linux (Ubuntu) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<micahg> infinity: please file a bug if we're not seeding something, I think our first GTK3 theme just got in
<superm1> infinity, don't beleive there is any way to tell from the UI.  The only themes that I know of in the archive right now are Ambiance and Radiance
<lynxman> jhunt_: Daviey: you around here?
<Daviey> lynxman: urgh, that strace is horrible.
<mr_pouit> infinity: you can try the latest greybird, there's a gtk3 theme (using the unico engine)
<lynxman> Daviey: it's on a serial link through a VPN through a java interface, I do apologise for its lameness
<ogra_> infinity, uglyness is the new bling ;)
<pitti> superm1: and gnome-theme-standard, which provides Adwaita (upstream GNOME default)
<superm1> pitti, ah cool, wasn't aware of that
<cr3> pitti: nice and simple, thanks!
<Daviey> lynxman: mountall --debug > mountall.log 2>&1 ?
<lynxman> Daviey: I still have no way to recover any file from the system :)
<Daviey> lynxman: does it have net access, allowing you to throw the output as txt somewhere?
<lynxman> Daviey: it does but the bnx2 module is also broken
<Daviey> *sigh*
<lynxman> Daviey: so no network for me
<Daviey> lynxman: ok.. just mountall --debug then.
<lynxman> Daviey: posted in bug
<Daviey> lynxman: does it block there, or repeat?
<lynxman> Daviey: block
<apw> lynxman, so that is a whole new UUID ?  from what was previously noted as mounted as slas
<apw> root
<lynxman> apw: whole new uuid indeed
<apw> lynxman, if you do a cat /proc/mounts where is / is it that a394 (ending) UUID ?
<lynxman> apw: no, just a regular "rootfs / rootfw rw 0 0"
<lynxman> apw: no, just a regular "rootfs / rootfs rw 0 0"
<Daviey> apw: wait *394 is swap
<lynxman> Daviey: still the uuid from mountall != uuid from df -h
<apw> lynxman, there are two lines for / in /proc/mounts, the seconf one has the UUID
<lynxman> *doh* true
<apw> lynxman, and yes it is likely trying to instantiate swap ... do a blk-id on your swap device
<hrw> superm1: bug 833884 got debdiff
<ubottu> Launchpad bug 833884 in mythbuntu-control-centre (Ubuntu Oneiric) "mythbuntu-control-centre version 0.63-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/833884
<lynxman> apw: second line has the uuid and it's the same shown by df -h
<apw> lynxman, and blkid /dev/<swap disk>
<superm1> thanks hrw!
<superm1> do you need a sponsor?
<lynxman> apw: no swap definitions in /proc/mounts
<hrw> superm1: yes, otherwise I would not add but would upload
<Daviey> superm1: Shouldn't that go into bzr?
<lynxman> df -ha
<superm1> hrw, ok.  Daviey will put it in bzr and upload then
<apw> lynxman, no they are in /etc/fstab
<apw> lynxman, what does blkid on your swap device say, presumably you know where that is as you created it recenty
 * apw is suspicious you have lost your swap id
<lynxman> apw: it's there yes :)
<lynxman> apw: and it fits with what mountall tries as well
<apw> lynxman, ok so ... blkid will tell us if the real disk has a swap marker on it, and therefore any UUID at all
<Daviey> superm1: argh
<hrw> superm1: bug 833901 has same solution
<ubottu> Launchpad bug 833901 in martian (Ubuntu Oneiric) "martian version 0.12-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/833901
<lynxman> apw: /dev/.blkid.tab does not exist, the soft link from /etc/blkid.tab is broken :/
<apw> lynxman, you can just trun blkid on /dev/cciss<xxx> whatever the partition you added as your swap
<lynxman> apw: tried that before, returns empty, I tried it again now
<lynxman> apw: same for the / partition
<hrw> superm1: bug 833892 is probably also yours
<ubottu> Launchpad bug 833892 in mythbuntu-log-grabber (Ubuntu Oneiric) "mythbuntu-log-grabber version 0.9-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/833892
<apw> lynxman, so /dec/cciss/c0d0p1 is / ?  and c0d0p5 is swap ?
<lynxman> apw: yes, exactly
<apw> lynxman, and blkid /dev/cciss/c0d0p1 and blkid /dev/cciss/c0d05 both return nothing ?
<lynxman> apw: correct
<apw> that is unexpected, how did it find / if that is the case
<lynxman> apw: good question
<apw> so if swapon -s shows no swap and you are sure p5 is your swap you could try re-adding the swap record
<apw> mkswap /dev/cciss/c0d0p5
<apw> and see what blkid says on it then
<hallyn> smoser: you around and have a minute?
<lynxman> apw: yeah, no swap, reswapping that
<lynxman> hah
<lynxman> apw: /dev/cciss/c0d0p5 : No such file or directory
<apw> lynxman, erm perhaps looks see what they are really called then
<apw> and go back to the blkid phase
<smoser> hallyn, here.
<hallyn> smoser: well here is what is happening,
<lynxman> apw: /dev is almost empty, no sd* no disk, just fd, core, ram, pts, std(err|in|out), shm
<hallyn> udev looks at /dev/ptmx, and if it is not the same device type, ownership and perms as expected, then it replaces it
<hallyn> this is fine for lxc, bc it creates the device and bind-mounts it from /dev/pts/ptmx.  So it is the right dev ice type, and udev doesn't replace it
<hallyn> libvirt-lxc creates a symlink, so udev replaces that
<lynxman> apw: /proc/mounts shows udev mounted at /dev properly
<smoser> replaces it as in "re-mounts" ?
<apw> lynxman, so you have no devices in /dev
<hallyn> no, creates /dev/ptmx.udev-tmp, then does mv /dev/ptmx.udev-tmp /dev/ptmx
<smoser> and then why is udev's replacement no good ?
<hallyn> It does this in a pretty generic piece of code, which I'm not sure we should complicate for this
<lynxman> apw: no devices in /dev/
<hallyn> smoser: bc a simple /dev/ptmx device is wrong inthe container
<hallyn> you must use /dev/pts/ptmx
<hallyn> that is why /dev/ptmx must be either a symlink or a bind mount to that
<smoser> ok.
<apw> lynxman, so its like udevd didn't do its thing correctly
<apw> lynxman, is udevd running ?
<hallyn> so...  hm, i suppose this means lxcguest could just create it the right way, rather than libvirt doing it
 * hallyn tries
<lynxman> apw: it's running, parent process with 2 children
<lynxman> apw: also upstart-udev-bridge is started
<smoser> hallyn, how will you make it not racy
<hallyn> yeah that works
<hallyn> because lxcguest starts on startup
<smoser> right.
<smoser> wel...
<smoser> that could potentially happen in parallel to udev though
<smoser> right?
<apw> lynxman, does udevadm trigger --action=add
<apw> do anything
<hallyn> smoser: i suppose lxcguest would have to start on starting startup?  if that's possible
<hallyn> or just on starting udev
<lynxman> apw: it tries to create devices and fails on all of them "failed: Read-only file system"
<smoser> hallyn, well, i think we're ok.
<apw> lynxman, ok so try touch /dev/X
<smoser> udev starts on virtual-filesystems
<hallyn> smoser: while i've found the generic code doing this, what kills me is i still haven't found the list where it finds ptmx as one of the devices to check
<lynxman> apw: yeah same, Read-only file system
<apw> ok that is not right
<hallyn> smoser: right, but 'start on startup' doesn't give enough guarantee
<apw> what does the /dev line look like in /proc/mounts
<lynxman> apw: udev /dev devtmpfs rw,relatime,size=2018084k,nr_inodes=504521,mode=755 0 0
<apw> what does df /dev say
<lynxman> apw: none   30846908 1466844 27813088 6% /dev
<lynxman> apw: Filesystem 1K-blocks Used Available Use% Mounted on
<smoser> hallyn, lxcmount.cofn already starts on starting mountall
<smoser> oh..
<smoser> but its udev
<smoser> for petes sake
<apw> lynxman, but ... it says udev in /proc/mounts, so its not the same place
<lynxman> apw: its type udev mounted in /dev
 * Daviey has a udev overload.
<lynxman> Daviey: udev!
<apw> lynxman, is there more than one line for /dev in /proc/mounts
<hallyn> smoser: yeah...
<hallyn> Daviey: are you missing devfs?
<apw> lynxman, as i have the same line in /p/mounts and yet df on my /dev says udev not none in the first column
<lynxman> apw: as a matter of fact... /dev returns same used space and free space as /
<cjwatson> udev udev udev udev udev udev udev udev MUSHROOM MUSHROOM
<hrw> bug 835768 got debdiff - sponsor anyone?
<ubottu> Launchpad bug 835768 in xtrs (Ubuntu Oneiric) "xtrs version 4.9c-3.2ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835768
<apw> lynxman, cat /proc/mounts | grep /dev
<lynxman> cjwatson: ktraceee ktraceee oooh it's a ktraceeeee
<apw> i think you have a bind mount on there too
<lynxman> apw: I also have devpts, no other lines for /dev
<apw> lynxman, ok lets try unmount /dev
<apw> and see what it does
<apw> then df /dev
<micahg> hrw: sorry, was supposed to be piloting today, but had to reschedule will get to it next week unless someone else does it first
<lynxman> apw: okay!
<lynxman> apw: says /dev not mounted, hah
<lynxman> apw: if I do mount /dev now all the devices show up
<hrw> micahg: no problem
<lynxman> apw: so it looks like it can't mount /dev?
<hrw> bug 835765 also got sponsors subscribed
<ubottu> Launchpad bug 835765 in van.testing (Ubuntu Oneiric) "van.testing version 3.0.0-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835765
<apw> lynxman, though /dev is mounted as we come out of the kernel and gets mount --move'd i think into real /
<Daviey> hrw: Yeah, no problem for micahg.. superm1 kindly assigned them to me.
<apw> so we need to try and trace why that failed ...
<hrw> Daviey: so far my way of going though bugs is: check, fix, upload debdiff, subscribe sponsors (unless bug got someone assigned in meantime)
<hrw> Daviey: one day I will try to find out all those bugs, make a list and apply for motu to make this road shorter
<lynxman> apw: so... suggestions on how to get that traced?
<Daviey> hrw: sounds like a good work flow.. The only thing that would make it more streamlined for the sponsor is to propose it for merging into the bzr branch (as listed in debian/control)
<Daviey> hrw: sounds wonderful!
<hrw> Daviey: I do not have too much sympathy to bzr (trying to be politicaly correct)
<micahg> Daviey: I still prefer debdiffs to bzr branches :)
<Daviey> micahg: Yeah, that is great.... unless the package is maintained in bzr. :)
<micahg> Daviey: sure, but most aren't at this point
<Daviey> yeah
<smoser> hallyn, you need my instance ?
<hrw> bug 835763 this time
<ubottu> Launchpad bug 835763 in python-ldap-doc (Ubuntu Oneiric) "python-ldap-doc version 2.3-2.1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835763
<hallyn> smoser: no, i'm using my own, thanks.
<hallyn> (you'd replaced the container so iw as afraid of stepping on your toes)
<smoser> i just run that lxc-libvirt-whatever script
<smoser> and it kills it and starts over
<smoser> and i'd jjust rsynce'd from dist.
<smoser> btw, hallyn, thank you for your work on this.
<hallyn> smoser: np.  this one was a doozy :)  I'm pinging #virt to get their opinion right now.
<tgm4883> jdstrand, Daviey said to ping you over here regarding a reply to the mythbuntu-bare rejection email?
<jdstrand> tgm4883: yes, I plan to repsond today. sorry for the delay, the email got misfiled
<tgm4883> ok, i'll look for it then a little later
<Daviey> misfiled in Junk. :)
<tgm4883> I blame Daviey, it had to be some British metric system conversion issue
<Daviey> most likely.
<mterry> zul, so you uploaded a new python-dingus with dh_python2 support, and it's just waiting on archive-admin approval?
<zul> mterry: right
<mterry> zul, cool
<bdmurray> what package that uses dkms can I install and have it fail to build because I don't have the right hardware or something?
<kees> hmm zaptel?
<kees> bdmurray: I haven't looked in a while, but the zaptel drivers might fail
<stgraber> is zaptel still in the archive? I thought it got replaced by dahdi
<kees> stgraber: that very well could be. like I said, it's been a while since I had my asterisk server running
<bdmurray> well regardless dahdi-linux built okay
<bdmurray> bug 790478 seems rather unnecessary
<ubottu> Launchpad bug 790478 in dahdi-linux (Ubuntu) "package dahdi-dkms ... failed to install/upgrade: dahdi kernel module failed to build (You do not appear to have the sources for the ... kernel installed.)" [Undecided,Confirmed] https://launchpad.net/bugs/790478
<slangasek> I'm not sure why any module would fail to build due to lack of hardware
<bdrung> tumbleweed: merged and bug #838361 opened
<ubottu> Launchpad bug 838361 in ubuntu-dev-tools (Ubuntu) "[syncpackage] downloads .dsc files into current directory" [Medium,New] https://launchpad.net/bugs/838361
<tumbleweed> oh right
 * tumbleweed forgot about that
<bdmurray> I was thinking about something lik bug 711397
<hallyn> hm,
<hallyn> E: Invalid Release signature (key id 40976EAF437D05B5)
<hallyn> debootstrapping natty
<hallyn> uh, oneiric
<jtaylor> is it using the correct keyring?
<jtaylor> there were some Release signing issues the last few days, probably your mirror is not yet updated
<cjwatson> as far as I know there is nothing wrong with the master archive in this regard
<hallyn> ok, thanks.
<cjwatson> a mirroring problem is a lot more likely
<hallyn> i'd believe it
<cjwatson> (I saw problems on gb.archive but not archive)
<jtaylor> I saw problems on master archvie yesterday
<cjwatson> are you 100% sure there is not a transparent web proxy between you and the archive?
<cjwatson> ISPs often pull this kind of stsunt
<cjwatson> *stunt
<jtaylor> thats possible
<cjwatson> $ gpg --verify Release.gpg Release
<cjwatson> gpg: Signature made Wed Aug 31 21:18:32 2011 UTC using DSA key ID 437D05B5
<cjwatson> gpg: Good signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
<jtaylor> didn't really checked, was working again an hour later
<cjwatson> sorry, that's in cjwatson@cocoplum:~/ubuntu/dists/oneiric
<cjwatson> (i.e. true master)
<ScottK> cjwatson: Not sure if it might be related, but I've been trying to run ./update in kubuntu-meta for the last hour and getting errors like W: http://archive.ubuntu.com/ubuntu/dists/oneiric/main/binary-i386/Packages.bz2 was corrupt
<cjwatson> it's possible there's some problem on the central mirrors
<cjwatson> might be worth letting #ubuntu-mirrors know
<ScottK> OK.
<cjwatson> (for clarification, though I think ScottK knows this already - archive.ubuntu.com is a mirror too, the archive is a hidden master arrangement)
<ScottK> Yep.
<ScottK> jtaylor: As I'm looking at your debian/changelog entry in http://launchpadlibrarian.net/78520283/libindicate_0.5.91-0ubuntu3_source.changes trying to decide if it's important for Oneiric Beta 1 or not, I'm finding what you wrote not very helpful.  It's better to be a little more verbose and describe the actual problems that are fixed (at least briefly).
<jtaylor> hm yes they were described better in the merge proposal
<jtaylor> the patches were seemingly accidentally dropped in an older revision
<jtaylor> causing build failures and memory leaks
<jtaylor> the patches were dropped in 0.5.90-0ubuntu1 whih had some rules refactoring
<jpds> cjwatson: Which problems?
<cjwatson> jpds: same as what ScottK reported above - Release and Packages out of sync while trying to update metapackages
<cjwatson> except on gb.archive in my case rather than archive
<bdmurray> superm1: could you look at / incorporate my patch in bug 766160?
<ubottu> Launchpad bug 766160 in dkms (Ubuntu) "apport hook should identify duplicates" [Medium,In progress] https://launchpad.net/bugs/766160
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<ion> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ion, robert_ancell
<ion> Wow. I didnât expect that to work for anyone.
<ion> Sorry for the noise.
<ion> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<micahg> ion: anyone can be a pilot :)
<lynxman> hah
#ubuntu-devel 2011-09-01
<infinity> ion: Does this mean you'll be sponsoring my uploads and reviewing my patches and such? ;)
<ion> infinity: It did from 02:25:49 to 02:26:17 (UTC+3).
<infinity> Damnit, I missed my chance.
<lynxman> it was such short... but intense piloting
<kees> anyone else seeing "debsums: invalid package name" errors?
<kees> seems related to doing sums on transitional packages
<ion> kees: Yeah. Thereâs a bug report about it on Launchpad.
<ion> Bug #809924
<ubottu> Launchpad bug 809924 in debsums (Ubuntu) "debsums "invalid package name"" [Medium,Confirmed] https://launchpad.net/bugs/809924
<stgraber> kees: debsums might be a bit broken at the moment because of the changes that happened to it to make it multiarch aware. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616066
<ubottu> Debian bug 616066 in debsums "/usr/bin/debsums: should not access dpkg's internal database directly, but use dpkg-query" [Important,Open]
<stgraber> kees: what's in Oneiric is based on a relatively hacky script I wrote back the sprint but I probably missed some corner cases that have been addressed by the newer version of the patch in Debian
<kees> stgraber: ah, cool
<mynameisdeleted> I'd like to submit artwork to the ubuntu project
<mynameisdeleted> whats the process for doign that?
<hammma> where can I suggest ideas for the unity project?
<sladen> hammma: ayatana-design
<sladen> hamma: https://launchpad.net/~ayatana
<sladen> hammma: should be a subscribe link at the bottom
<hammma> thanks
<pitti> Good morning
<didrocks> good morning
<YokoZar> Is there an environment variable that will set bzr launchpad-login ?
<infinity> YokoZar: Setting it with 'bzr launchpad-login' isn't enough?
<YokoZar> infinity: meh, I figured I could put it in bashrc along with the long list of other environment variables I have there like BZR_EMAIL
<infinity> You could put "bzr launchpad-login whoever" in bashrc...
<broder> bzr launchpad-login just sets a variable in ~/.bazaar, right?
<YokoZar> for some reason I thought it did something a bit more complex than that, like verify the name somehow
<infinity> launchpad_username in bazaar.conf, yeah.
<YokoZar> ok then since it's persistent there's no need for environment variable or bashrc messing ;)
<infinity> Nope, not if you always have a bazaar.conf.
<dholbach> good morning
<pitti> hey dholbach
<geser> Hi pitti, dholbach
<dholbach> hi pitti, hi geser
<pitti> hey geser, wie gehts?
<geser> pitti: I'm fine. And you?
<pitti> pretty well, thanks! a bit in crunch mode due to the late respin for beta
<dholbach> Ursinha, happy birthday!
<jibel> pitti, where is the code of the apport duplicate finder ? it's doing things that doesn't make sense.
<pitti> jibel: it's all in lp:apport, but where exactly depends on the nature of what you are seing
<pitti> "seeing"
<pitti> jibel: what's an example?
<pitti> jibel: we recently added some non-crash dupe things to the ubuntu hook (/usr/share/apport/general-hooks/ubuntu.py); these are fairly new and might cause false positives
<jibel> pitti, it marked bug 837503 and bug 837288 as duplicates of bug 837042. In its logic it is probably right but we should probably add rules to say "Don't touch a report that is in this state".
<ubottu> Launchpad bug 837503 in ubiquity (Ubuntu Oneiric) "'Prepare for shipping' not available on DVDs" [High,Triaged] https://launchpad.net/bugs/837503
<ubottu> Launchpad bug 837288 in ubiquity (Ubuntu Oneiric) "oem-config-remove-gtk crashed with SystemExit in _on_failure(): 1" [Medium,Confirmed] https://launchpad.net/bugs/837288
<ubottu> Launchpad bug 837042 in ubiquity (Ubuntu Oneiric) "wrong encoding for input in oem-config" [High,Confirmed] https://launchpad.net/bugs/837042
<jibel> like don't touch what is triaged
<jibel> or also bug 837282 as duplicate of bug 619363, one is a timeout of dbus the other is a dbus service not found
<ubottu> Launchpad bug 619363 in aptdaemon (Ubuntu) "duplicate for #837282 aptdaemon dbus backend crash in self._transaction.run(defer=True)" [Undecided,Confirmed] https://launchpad.net/bugs/619363
<ubottu> Launchpad bug 619363 in aptdaemon (Ubuntu) "aptdaemon dbus backend crash in self._transaction.run(defer=True)" [Undecided,Confirmed] https://launchpad.net/bugs/619363
<pitti> jibel: right, that DuplicateSignature looks totally inadequate for a manually created bug report
<pitti> bdmurray: ^ I think ubuntu.py should only add these for crash bugs perhaps, not for manually filed bugs?
<pitti> jibel: so for that I think the code is in /usr/share/apport/package-hooks/source_ubiquity.py
<pitti> line 73 ff.
<pitti> it sets the DuplicateSignature regardless of the ProblemType
<pitti> it shuold only do that for "Crash" and perhaps "Package", but not "Bug"
<pitti> bdmurray: ^ do you agree?
<pitti> jibel: bug 837288 should keep the DuplicateSignature, though, do you agree?
<ubottu> Launchpad bug 837288 in ubiquity (Ubuntu Oneiric) "oem-config-remove-gtk crashed with SystemExit in _on_failure(): 1" [Medium,Confirmed] https://launchpad.net/bugs/837288
<jibel> pitti, the signature is wrong. It is not the error in the Traceback but from ubiquity syslog, which is not what triggered the crash.
<pitti> jibel, bdmurray: first fix: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/oneiric/apport/ubuntu/revision/1834
<pitti> bdmurray: can you look into the wrong DuplicateSignature in 837288?
<pitti> jibel: right; I meant for these kinds of bugs it makes sense to keep a DuplicateSignature, but not for the other two (ProblemType Bug)
<pitti> jibel: I'll remove that faulty master bug from the dup db in a moment
<jibel> pitti, agree. for crash reports it makes sense to keep the signature.
<lynxman> jhunt_: ping
<jhunt_> lynxman: hi
<lynxman> jhunt_: hey :)
<lynxman> jhunt_: I've been fighting with a bug the last day, very nasty one
<lynxman> jhunt_: looks like a race condition in the initrd ramfs when your root or swap are in extended partitions
<lynxman> jhunt_: which makes udev not mount properly and you can't boot up
<lynxman> jhunt_: in oneiric server
<lynxman> jhunt_: bug 818177
<ubottu> Launchpad bug 818177 in linux (Ubuntu) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<jhunt_> lynxman: I'll take a look...
<lynxman> jhunt_: adam_g suggested a small patch to /usr/share/initramfs-tools/scripts/init-bottom/udev
<lynxman> jhunt_: just want to make sure it makes sense from the foundations side as well
<lynxman> jhunt_: thanks :)
<infinity> jml: I bet it suspends great, it just fails to resume. ;)
<cjwatson> tkamppeter: it's too late to change beta-1 for anything short of an emergency
<pitti> tkamppeter: this kind of bug can be fixed perfectly with a  post-installation upgrade
<tkamppeter> cjwatson, pitti, OK. Probably beta1 users update regularly anyway, as it is not a final.
<cjwatson> yes, I think that can be expected
<cr3> is there a debian script or something for a package to modify the configuration file of another package when it doesn't have a convenient *.d directory, ie should be able to add either lines or a section on install and then remove that on uninstall
<pitti> cr3: if it's a dpkg-managed configuration file (so-called "conffile"), this is not allowed
<pitti> cr3: if it's a non-managed file, there are no scripts for this, as every conffile looks different; the usual approach is to use sed, etc.
<cr3> pitti: /etc/sysctl.conf, I'm only writing a convenience optimization package for use in the cloud, not intended for the real archives :)
<pitti> cr3: but these things need to be done very very VERY careful; it must never touch a file of an unkonwn/unexpected format, the code needs to be idempotent, etc.
<ogra_> cr3, you want /etc/sysctl.d/ instead
<pitti> cr3: sysctl.conf is a conffile; what ogra said
<ogra_> that can override /etc/sysctl.conf and you only drop a file in place with your package
<cr3> awesome, I didn't even notice sysctl.d! I can't remember last time I actually did an ls of /etc, strange :)
<cr3> but now I have to modify /etc/postgresql/$version/main/postgresql.conf :(
<pitti> cr3: that's not a conffile
<pitti> cr3: also, that file isn't guaranteed to exist (there might be more/other/differnet clusters), but as long as it's for a personal package, that's fine
<cr3> pitti: yeah, it's personal but I'm still trying to be minimally careful, like not just appending blindly and so forth
<bdrung> cjwatson: are you working on a patch for xmms2?
<bdrung> oh, now i got the mails. thanks for your work.
<cjwatson> bdrung: I'm working on all the remaining libav NBS dependencies (that Fabrice doesn't beat me to)
<bdrung> :)
<cjwatson> it's just a bit tedious
<bdrung> cjwatson: can you give me your patch as real file / attachment? i copied the inline patch and 'patch' complains about it.
<cjwatson> bdrung: perhaps easiest to grab it from https://launchpadlibrarian.net/78695385/xmms2_0.7DrNo%2Bdfsg-2build2_0.7DrNo%2Bdfsg-2ubuntu1.diff.gz
<cjwatson> minus the debian/control bit of course
<Daviey> slangasek: Do you have thoughts on, bug 835625 .. smelling multiarch related.
<ubottu> Launchpad bug 835625 in cyrus-sasl2 (Ubuntu) "package libsasl2-2 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu2 failed to install/upgrade: libsasl2-2:i386 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu2 (Multi-Arch" [Undecided,New] https://launchpad.net/bugs/835625
<jibel> pitti, do you still get bug 831884
<ubottu> Launchpad bug 830061 in ubiquity (Ubuntu Oneiric) "duplicate for #831884 ubiquity-dm crashed with AttributeError in run(): 'Pixbuf' object has no attribute 'render_pixmap_and_mask'" [High,Fix released] https://launchpad.net/bugs/830061
<jibel> ?
<pitti> jibel: I didn't notice apport popping up for this
<jibel> not  the master, the first report.
<jibel> 831884
<pitti> jibel: but I didn't do a test case with an existing user account, so there was nothign to migrate
<pitti> jibel: ah, no, I don't get 831884 any more
<jibel> it is still an issue there with ubiquity 2.7.25
<pitti> I tried the beta-1 on the very same machine (Mini 10), plus my workstation (X201), both worked fine
<jibel> I tried on an eeepc, same error. another system work fine booted from CD. I'll try from USB.
<lynxman> jhunt_: hey sir o/ any feedback on bug #818177?
<ubottu> Launchpad bug 818177 in linux (Ubuntu) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<jhunt_> lynxman: can't recreate the problem myself yet, but the proposed solution sounds reasonable, although maybe we should have some sort of timeout waiting for udev?
<lynxman> jhunt_: okay, I'll figure out a patch with a timeout value then :
<lynxman> :)
<bdmurray> pitti: one issue with using if report['ProblemType'] != bug is bug 712677
<ubottu> Launchpad bug 712677 in ubiquity (Ubuntu) "Does not report crashes during "Install Ubuntu" installs" [High,Triaged] https://launchpad.net/bugs/712677
<Andy80> hi all
<Andy80> I've read that Oracle retired their license for distributing their SDK on Linux... does it mean we will be able to distribute only OpenJDK in the Software Center?
<pitti> bdmurray: right, we need to fix that
<bdrung> cjwatson: uploaded xmms2 to sid. i did more changes: http://anonscm.debian.org/gitweb/?p=pkg-xmms2/xmms2.git
<cjwatson> ok, dh_python2 will need an FFe though
<slangasek> Andy80: what Oracle has retired is their standing public redistribution license; given that the sun java packages currently available through Software Center are part of the Canonical Partner archive, not part of Ubuntu itself, it's not clear from this whether Oracle will maintain that particular relationship
<Andy80> slangasek: ok, so it's a different agreement, not the general one. Thanks
<slangasek> Andy80: well, I'm not actually privy to whether Canonical does have a separate license agreement for those packages - but by virtue of the package's presence in partner, I can say there's a direct *relationship*, so they may work something out :)
<slangasek> Daviey: thanks, bug #835625 triaged
<ubottu> Launchpad bug 835625 in apt (Ubuntu Oneiric) "package libsasl2-2 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu2 failed to install/upgrade: libsasl2-2:i386 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu2 (Multi-Arch" [High,Triaged] https://launchpad.net/bugs/835625
<pitti> stgraber: oh, bfb? I thought that was gone in oneiric now, does 2d still have it?
<stgraber> pitti: it's still called bfb (as in the file) but that's now the dash launcher
<pitti> jibel: trying a zh_CN install with the oneiric desktop CD now; which one is simplified Chinese, the third-last or second-last in the language list?
<pitti> stgraber: ah
<jibel> pitti, this one ä¸­æ(ç®ä½)
<slangasek> the simpler one, obviously! :)
<pitti> jibel: ah, it does look a tad simpler, doesn't it
<pitti> jibel: merci!
 * pitti now trying to do a "blind" install
<stgraber> pitti: anything in particular you want to test?
<pitti> jibel: still curious that I don't see it when I create a chinese user in a running system, or in the live session
<stgraber> pitti: I just did a chinese test install for Edubuntu
<pitti> stgraber: bug 771510
<ubottu> Launchpad bug 771510 in indicator-sound (Ubuntu Oneiric) "missing translations for Simplified Chinese" [High,Incomplete] https://launchpad.net/bugs/771510
<pitti> stgraber: and the two related ones for two other indicators
 * pitti retitles the bug
<stgraber> pitti: ok, I have an installed chinese system here, let me have a quick look
<pitti> bug 771510
<pitti> stgraber: some indicators show "Empty Label" in them
 * pitti figures out how to select US keyboard layout
<stgraber> "Label Empty" actually
<pitti> ah, right; bug updated
<stgraber> session/me, sound and date all have the problem
<pitti> yeah, seems everyone gets it but me..
<pitti> I'm currently doing a clean test install with zh_CN right from the start
<pitti> seems it doesn't happen in live session or post-install
<stgraber> ouch, and seems like we also have some font problem (might be related
<pitti> ah, with the "guess your keyboard layout" button I was able to find US :)
<stgraber> pitti: default chinese keyboard is US
<stgraber> pitti: http://www.stgraber.org/download/unity-chinese.png
<stgraber> that doesn't look too good :)
<pitti> whee
<pitti> I didn't get that
<pitti> after jibel's latest post I'm beginning to think it's a broken locale setting
<stgraber> for some reason I didn't get that in the live session either, only on the installed system
<pitti> stgraber: do you mind to post the output of "locale" to that bug, plus ~/.profile and /etc/default/profile ?
<stgraber> pitti: and you'd be right, locale is wrong
<pitti> if it is locale, then it'll also explain why I didn't get it with a test user
<stgraber> pitti: I have zh_CN not zh_CN.UTF-8
<pitti> as control-center sets it right
<pitti> accountsservice, I mean
<pitti> stgraber: I bet that's it; it's getting an invalid LC_CTYPE and chinese $LANGUAGE
<stgraber> restarting session with the right locale
<stgraber> everything looks good now
<pitti> ok, so we should just attach the wrong files; my install is almost through, will do it afterwards unless you beat me to it
<stgraber> ok, so I guess that bug should be changed to: "/etc/default/locale set to zh_CN instead of zh_CN.UTF-8 when installing in Chinese"
<stgraber> pitti: attached the screenshot and /etc/default/locale to the bug
<stgraber> I guess this will need re-assigning but not sure to what, localechooser?
<stgraber> pitti: it very well might explain bug 838845
<ubottu> Launchpad bug 838845 in ldm (Ubuntu) "Chinese glyphs (and potentially some other languages) aren't rendered properly in ldm" [Medium,Triaged] https://launchpad.net/bugs/838845
<pitti> stgraber: very probabl
<pitti> e
<pitti> stgraber: I updated the bug and will add a few dupes
<pitti> stgraber, jibel: ok, reproduced here as well; I updated the bug and duped the others
<pitti> Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<pitti> (freeze lifted, go wild)
<pitti> didrocks: ^ you might fancy uploading unity-2d
<didrocks> pitti: ah nice, I'm preparing the next release of unity-2d with the unity one right now :)
<tkamppeter_> pitti, It looks like that LP has a problem with the two s-c-p uploads approved at once. It seems that it has picked the older one, 1.3.6+20110824-0ubuntu2 instead of 1.3.6+20110831-0ubuntu1.
<pitti> tkamppeter_: it should have accepted both
<tkamppeter> pitti, See https://launchpad.net/ubuntu/+source/system-config-printer, which shows the old version and https://launchpad.net/ubuntu/+source/system-config-printer/+changelog which includes the new version.
<tkamppeter> pitti, I got two accept e-mails, but the one for the old version came after the one for the new version.
<pitti> tkamppeter: the latter page shows unpublished sources, too; all is well
<tkamppeter> pitti, yes I can access the newer version's page through a link on the changelog page.
<cjwatson> don't worry about mail ordering
<slangasek> if both are accepted, the higher version will win
<cjwatson> just leave it an hour or so and everything will sort itself out
<tkamppeter> OK, thanks.
<bdmurray> superm1: Did you see my patch in bug 766160?
<ubottu> Launchpad bug 766160 in dkms (Ubuntu) "apport hook should identify duplicates" [Medium,In progress] https://launchpad.net/bugs/766160
<qmr> Why is empathy the default IM client?
<hallyn> how come /dev/mqueue is not mounted  by default on an ubuntu system?  Just obsolete?
<kirkland> jml: ping
<jml> kirkland: hi
<kirkland> jml: i'm not able to reproduce https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/838807
<ubottu> Launchpad bug 838807 in ecryptfs-utils (Ubuntu) "Lose access to Private directory after logging out then logging in again" [High,New]
<jml> kirkland: ah, ok. I can reproduce it easily and lots.
<kirkland> jml: hmm
<kirkland> jml: actually, hang on
<jml> kirkland: I mean, sucks to be logging out all the time.
<kirkland> jml: i'm encrypting all of $HOME, you're encrypting $HOME/Private
<jml> kirkland: yep
<kirkland> jml: let me try to reproduce that
<jml> kirkland: ok. thanks.
<kirkland> jml: oh, one more thing
<kirkland> jml: ls -alF $HOME/.ecryptfs/auto-mount
<kirkland> jml: and is this a recent thing?  or has it been doing this for a while?
<jml> -rw-r--r-- 1 jml jml 0 2008-10-14 07:09 /home/jml/.ecryptfs/auto-mount
<jml> kirkland: for a while
<kirkland> jml: dang
<kirkland> pitti: ping?
<kirkland> pitti: you encrypt *just* $HOME/Private, right?
<kirkland> pitti: have you seen https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/838807 yet?
<ubottu> Launchpad bug 838807 in ecryptfs-utils (Ubuntu) "Lose access to Private directory after logging out then logging in again" [High,New]
<cjwatson> I think I've seen that.  I can't log out right now though, and it seems fine on the first login after booting (which this is)
<cjwatson> -rw-r--r-- 1 cjwatson cjwatson 0 2008-08-20 14:14 /home/cjwatson/.ecryptfs/auto-mount
<kirkland> hmm, is there any chance that subsequent logins are short circuiting the pam stack in lightdm?
<slangasek> twitch?
<kirkland> jml: one more thing ...  could you try with ssh?
<kirkland> jml: ie, logout of your desktop, and then ssh in/out repeatedly, and see if it's automounting/unmounting
<kirkland> jml: i just tried that with an encrypted private, and ssh logins seem to be behaving properly
 * kirkland logs out to test this
<jml> kirkland: ok. sure. sorry for delay.
<jml> umm
<jml> I need something to log in with.
<kirkland> jml: ssh?
<kirkland> jml: if you're running an ssh server there, you can drop to a tty, login as root or another user, and ssh jml@localhost
<jml> kirkland: ahh, right.
<kirkland> jml: i just logged in/out 10x times with a test user and an encrypted private directory, with no luck reproducing the problem
<jml> kirkland: ok. will try that.
<kirkland> jml: do a mount | grep ecryptfs in between logins
<kirkland> jml: to see if you're getting unmounted properly
<jml> ok
 * jml tries.
<kirkland> jml: hmm, I'm just not reproducing this
<tgm4883> jdstrand, ....
<jandrusk> Really? Dead link off of "Create" section of developer.ubuntu.com? http://developer.ubuntu.com/create/qt/
<superm1> bdmurray, yeah but i don't have access to sponsor it until next week.
<jml> kirkland: so I tried logging out, but I need to reconfigure my SSH server :)
<superm1> it looks fine to me though
<jml> kirkland: give me a bit longer.
<jml> kirkland: when I log in on the tty as jml, I get an error.
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Beta 1 Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, robert_ancell
<kirkland> jml: np;  i'll get this solved for you, but we'll need to work together a bit to triage it, since I'm not reproducing it
<jandrusk> It's the last link on the left on 'QT creator'.
<jml> kirkland: but I think it's the one in the paste in the bug report
<kirkland> jml: are you in your desktop now?
<jml> kirkland: yes.
<kirkland> jml: okay, give me a couple of pastebins ...
<kirkland> jml: ll $HOME/.ecryptfs/
<kirkland> jml: and
<kirkland> jml: ll $HOME/.ecryptfs
<jml> kirkland: http://paste.ubuntu.com/679942/
<jml> kirkland: going to try the SSH thing again now.
<kirkland> jml: hmm, okay, i do see one aberration
<kirkland> jml: minor, but let's try this ...
<kirkland> jml: echo "$HOME/Private" > $HOME/.ecryptfs/Private.mnt
<kirkland> jml: ie, set your private mountpoint
<kirkland> jml: i think that should default to $HOME/Private, but it's possible that it's not doing so for you?
<jml> kirkland: ok. done that. Will log out and log in again.
<kirkland> jml: k
<jml> kirkland: no joy.
<jml> kirkland: want me to try the SSH thing, now that I have a properly configured server?
<kirkland> jml: okay ls -alF /dev/shm/ecryptfs-jml*
<jml> kirkland: -rw------- 1 jml root 2 2011-09-01 18:28 /dev/shm/ecryptfs-jml-Private
<jml> kirkland: but this is while it is mounted
<kirkland> jml: cat /dev/shm/ecryptfs-jml-Private
<jml> 1
<kirkland> jml: okay, good
<kirkland> jml: yeah, try ssh
<kirkland> jml: you can even do it in your desktop session
<kirkland> jml: just ssh in and out of localhost
<jml> kirkland: ssh works while I'm in desktop session (thing shows up as mounted).
<jml> kirkland: shall I try outside of desktop session?
<kirkland> jml: ecryptfs-umount-private
<kirkland> jml: make sure it gets unmounted
<kirkland> jml: mount | grep ecryptfs
<kirkland> jml: and then try in and out of ssh a couple of times (3?  4?  5?)
<jml> kirkland: http://paste.ubuntu.com/679951/ (line 25 is when I umount)
<kirkland> jml: ooh, so you can reproduce it with ssh alone?
<kirkland> jml: dpkg -l ecryptfs-utils
<jml> kirkland: apparently so. although I notice that with SSH I don't get the warning about keyctl_search, which I *do* get when I do a tty login after first desktop logout
<jml> ii  ecryptfs-utils      90-0ubuntu1         ecryptfs cryptographic filesystem (utilities)
<kirkland> jml: okay, do: keyctl list @u
<kirkland> jml: this should show 2 keys in your keyring
<kirkland> jml: well, 2 if you're encrypting filenames
<jml> no, only one.
<kirkland> jml: 1 if you're not
<jml> I don't know if I'm encrypting filenames. I chose the option on install some three years ago :)
<kirkland> jml: wc -l $HOME/.ecryptfs/Private.sig
<kirkland> jml: :-P
<kirkland> jml: if that wc is 1, then you're not
<kirkland> jml: if it's 2, then you are
<jml> 1
<kirkland> jml: or, ls $HOME/.Private
<kirkland> jml: and if you see normal filenames, then you're not encrypting filenames
<jml> kirkland: right. they are all there.
<kirkland> jml: if you see: ECRYPTFS_FNEK_ENCRYPTED.FWYkiiM.WVXtxUQ5kMZ3hnYV7a7TNI7Ya0xUZWDbvgdLrupba-Nlw.EU--
<kirkland> jml: then you are :-)
<kirkland> jml: okay, good
<jml> kirkland: so, keyctl list @u has one key. Are there details there that you would like to see?
<kirkland> jml: no need
<kirkland> jml: okay, can you get it back to the point where you reproduce the problem, and then see if keyctl list @u shows 1 key?
<jml> hmm. by "reproduce the problem", do you mean, say, in an ssh session?
<kirkland> jml: sure
<kirkland> jml: reproduce is "ssh in, enter password, but ~/Private is not mounted"
<kirkland> jml: also, pastebin "md5sum /etc/pam.d/*"
<jml> kirkland: http://paste.ubuntu.com/679960/
<kirkland> jml: oooh, your /etc/pam.d/common-auth and /etc/pam.d/common-password differ from mine
<kirkland> jml: could you pastebin those two files?
<jml> kirkland: sure.
<jml> http://paste.ubuntu.com/679966/
<jml> http://paste.ubuntu.com/679968/
<jml> kirkland: have 1 key under ssh
<jml> oh
<jml> but when I remount the thing I have two keys
<kirkland> jml: oh ho ho, that's interesting, that gives me an idea
<kirkland> jml: -auth   optional                        pam_smbpass.so migrate
<kirkland> jml: that's inconsequential here
<jml> also, the numbers are slightly different
<jml> "1000    0" for one, "1000   1000" for the one that appears after mounting
<jml> ok
<jml> kirkland: sorry, I don't quite grok the "-auth" line.
<kirkland> jml: oh, i just looked at your minor pam differences, and it's just an smbpass thing, which should have nothing to do with this
<jml> ah right.
<kirkland> jml: okay, so those two numbers are uid and gid, and that shouldn't matter here
<kirkland> jml: but you're saying sometimes you have 2 keys in there, and sometimes 1?
<jml> kirkland: when ~/Private is mounted, I have two
<jml> kirkland: otherwise, 1
<jml> kirkland: but maybe that's because I've been using the interactive command to mount it? /me really doesn't know. Not sure what it has on first login
<kirkland> jml: okay, when private is mounted, could you give me the output of "mount | grep ecryptfs" ?  you may choose to fuzz the sig hex numbers, as these are hashes of your keys
<kirkland> jml: i'm think i'm on the track here
<jml> /home/jml/.Private on /home/jml/Private type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=XXXXXXXXXXX)
<kirkland> jml: okay, take a mental note of the true value of your ecryptfs_sig=XXXXXXXXXXX
<jml> got it.
<kirkland> jml: now, do whatever you do to reproduce the problem (ie, get it to not auto mount)
<kirkland> jml: and before mounting do your keyctl list @u
<kirkland> jml: see if that hex key id is in the list
<kirkland> jml: if i understand you correctly, there will be 1 and only 1 key in your list, and it won't be ecryptfs_sig=XXXXXXXXXXX
<jml> kirkland: correct.
<kirkland> jml: then do ecryptfs-mount-private
<kirkland> jml: enter your pw, see that private mounted, and now keyctl list
<kirkland> jml: and you get two keys in the list
<kirkland> jml: which includes the necessary ecryptfs_sig=XXXXXXXXXXX
<jml> kirkland: correct again.
<kirkland> jml: okay, i have an idea of what's wrong
<kirkland> jml: see line 46 of /usr/bin/ecryptfs-mount-private ... I need to simulate that in pam_ecryptfs.c
<kirkland> jml: okay, give me a little while to get this reproduced and tested;  i'll put a package in a ppa for your testing
<kirkland> jml: thanks for your patience
<jml> kirkland: thank you for helping me debug this
<jml> kirkland: or, umm, the other way around.
<jml> kirkland: anyway, I'm grateful :)
<kirkland> jml: :-)  yes, thank you
<kirkland> jml: how much longer until your EoD?
<jml> kirkland: I'm an hour past it.
<kirkland> jml: okay, it might be on the morrow for you then
<jml> kirkland: but I'll be around online most of the evening.
<kirkland> jml: cheers, though, you'll have a ppa package waiting for you
<jml> kirkland: ok, thanks. :)
<kirkland> jml: okey doke
<pdtpatr1ck> Question .. what's the preferred method for building a package.. there's dkpg-buildpackage -rfakeroot .. there's fakeroot dpkg-buildpackage -F .. there's debuild -S -sa and then sudo pbuilder build <package_version.dsc>
<infinity> pdtpatr1ck: Any of those except for "fakeroot dpkg-buildpackage".
<slangasek> pdtpatr1ck: debuild is a better interface than dpkg-buildpackage for developer use cases; fakeroot never needs to be specified manually becuase it's a default; what infinity said; and use of debuild vs. pbuilder has more to do with your workflow than whether one is a "preferred method".
<infinity> pdtpatr1ck: "dpkg-buildpackage -rfakeroot" will only use fakeroot during the bits where it needs to (and debuild, pbuilder, and sbuild will all call dpkg-buildpackage in that same manner)
<slangasek> if you already have a dsc, you're not going to be running 'debuild -S -sa', so the last two are orthogonal
<pdtpatr1ck> Great .. much appreciated guys
<infinity> slangasek: Is it sad that even though I know debuild is easier and less typing, muscle memory dictates that I still type "dpkg-buildpackage -rfakeroot -uc -us -S" every time?
<infinity> slangasek: Worse still, because -rfakeroot is the default now, and I still type it.
<infinity> Silly fingers.
<pitti> kirkland: no, I switched to full $HOME encryption a few cycles ago
<pitti> kirkland: yeah, I think I saw it sometimes; seems to be some kind of race condition or mis-counting sessions
<slangasek> infinity: you're losing valuable seconds of your life that way!  best to just let the autobuilders do it all for you
<infinity> slangasek: *glare*
<slangasek> <cackle>
<pitti> infinity: "bzr bd" !!!11!
 * infinity packs up his toys and goes home.
 * pitti is still a bit grumpy about debhelper claiming 'dh', a command that nobody ever types into a shell
<infinity> I imagine you'll get over it.
<infinity> Besides, I type it in shells.
<infinity> dh --no-act can be handy.
<pitti> still, it's so un-Huffman-y
<pitti> infinity: but anyway, I think you already LARTed me for my collection of aliases :)
<infinity> You were a math major turned programmer, weren't you?
<pitti> no, just a lazy typer :)
<infinity> And I may have.  It sounds like the sort of thing I'd make fun of.
<smoser> hey all. i'm looking at trying to find a solution for bug 838968 .
<ubottu> Launchpad bug 838968 in ifupdown (Ubuntu) "static-network-up event does not wait for interfaces to have an address" [Undecided,New] https://launchpad.net/bugs/838968
<smoser> i'm wondering if there is any way suitable for that a daemon could avoid polling to see if all of a list of network interfaces are up and have IPs assigned to them.
<smoser> s/suitable for that/suitable for ubuntu boot where/
<hallyn> smoser: wasn't SpamapS working on an event for that?
<smoser> hallyn, you're funny.
<smoser> its broken :)
<smoser> and i want to fix it.
<stgraber> too bad upstart can't react to netlink activity yet...
<hallyn> don't suppose there is a udev uevent when an address is defined?
<smoser> polling is probably *really* light, but it just seems dirty.
<hallyn> stgraber: are you thinking NETDEV_CHANGENAME?
<slangasek> smoser: I think it's a bug in dhclient and/or ifupdown
<smoser> its by design in dhclient
<slangasek> yeah, I think the design is wrong :)
<stgraber> hallyn: yeah, didn't remember the name though :)
<DoctorPepper> hi guys !!!
<slangasek> smoser: is there a reason you think it's correct for dhclient to background itself before it's gotten a response from the DHCP server and applied it?
<slangasek> I think this is a bad design that only exists to work around historic limitations, but maybe I'm missing something
<stgraber> hallyn: there's also NETDEV_CHANGEADDR but that might be for the mac address but maybe NETDEV_CHANGE would work then (haven't played with these in a while, just had to google for them again :))
<smoser> slangasek, i dont have a good reason.
<slangasek> stgraber: ^^ perhaps you have an opinion there
<smoser> but even if i did, it in that bug info, it seems like ifupdown is going on immediately as opposed to waiting 60 seconds.  although in attempts to reproduce that outside of boot, i can't see it.
<slangasek> ifupdown is going on immediately because dhclient has backgrounded and ifupdown has no channel by which to detect that the interface isn't actually up
<stgraber> smoser: any reason we don't simply put a script in /etc/dhcp/dhclient-exit-hooks.d ?
<smoser> slangasek, when run after boot, it doesn't do it immediately, dhclient holds around until it gets an IP address.
<slangasek> stgraber: because ifupdown and networkmanager already emit events when interfaces are "up", and we should fix *that* to work as intended instead of adding more layers
<smoser> i have the luxury of working on a system where the driver is apparently bad and a dhcp request is taking like 45 seconds, so i know this :)
<slangasek> stgraber: since ifupdown and network-manager still have to have them for the static interface case
<smoser> slangasek i just assumed that the static interface case was more straight forward. is it not?
<slangasek> smoser: I did see another bug report recently about *statically* configured interfaces getting the up event emitted before the driver was ready to tx/rx - maybe you have the same issue?
<slangasek> smoser: er, from upstart's perspective static vs. dynamic is (and should be) the same model
<smoser> stgraber, so, saying theres a hooks dir there, how would you tie that all together to ?
<DoctorPepper> chrisccoulson: i need your  help  , i am trying to build  globalmenu-extension for installing on a non ubuntu distribution (archlinux) , but  when running autoconf  i get the following error : build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES when the build fails
<smoser> slangasek right, i agree it should be the same.
<stgraber> smoser: as slangasek said before, it's probably not a good idea to add yet another hook, but otherwise a workaround would have been to change the ifupdown script not to send the event when doing dhcp and add a hook in dhclient to send the event when it gets an ip
<chrisccoulson> DoctorPepper, you need autoconf2.13
<chrisccoulson> i'm sure you already asked me that a while ago, and i gave the same answer ;)
<smoser> stgraber, right... and then i' dhave to have another upstart job that ran on if-really-up, and determine if all interfaces were up in *that* and fire the event.
 * stgraber starts liking NM for that ;) at least we have one piece of software starting everything and that knows the state of all NICs
<stgraber> smoser: yeah, that'd get even more of a mess than what we currently have...
<DoctorPepper> about 6 month ago but back then  i was impossible to build  it since i was using  fedora  the whole appmenu infrastructure  wasnt avalaible
<smoser> yes.
<smoser> but it would give me a solution
<smoser> which i need
<smoser> :)
<DoctorPepper> chrisccoulson: i got another error : ./allmakefiles.sh: line 104: ./toolkit/toolkit-makefiles.sh: No such file or directory
<DoctorPepper> what should ido ?
<smoser> slangasek, how much would you hate me if i did something like that? if it was clearly marked as "the only consumer of 'is-really-up' events is 'static-networking-up.conf', DO NOT USE IT YOURSELF"
<slangasek> smoser: a lot :P
<slangasek> smoser: that's a lousy workaround - fix the real bug
<smoser> do you really think "fix the real bug" is even an option for 11.10 ?
<slangasek> ifupdown shouldn't say the interface is up until it's up; whatever is causing it to say it's up before it is is a bug
<slangasek> yes
<smoser> changing dhclient to not bacakground itself would be seemingly invasive at this point.
<chrisccoulson> DoctorPepper, looking in the README file would be a good start
<slangasek> I disagree.  We're not making dhclient not background itself, we'd only be changing *when* it backgrounds itself.
<stgraber> smoser: is dhclient being called with -d?
<stgraber> smoser: if so, that's your bug
<smoser> stgraber, i dont thin it is. but i think you're reading the man page wrong.
<smoser> -d just says "never background"
<stgraber> wasn't the manpage but yes I read it wrong ;)
<smoser> i did the same thing
<DoctorPepper> chrisccoulson:  i worried about one thing   i see  two option  disabling both ogg and web  would this affect the ability  to play ogg and web video on the browse
<chrisccoulson> DoctorPepper, no, they have no effect at all
<chrisccoulson> the build system is copied straight from firefox, so those build options just stop you depending on them
<smoser> SpamapS, ^ slangasek says "make it work right".
<SpamapS> smoser: so is dhclient backgrounding itself too early?
<chrisccoulson> DoctorPepper, in fact, the build system is basically from https://launchpad.net/mozilla-build-system ;)
<DoctorPepper> ok thanks
<smoser> SpamapS, so i think there are 2 issues.  1, by design dhclient is not what we'd like.
<smoser> 2. i swear i'm seeing ifupdown emit the interface immediately, but i can't see how.
<slangasek> where is it said that this is by design in dhclient, btw?
<slangasek> in fact, dhclient has a '-nw' option
<slangasek> which we should avoid using :)
<slangasek> (and we're not, in either ifupdown or NM - so dhclient daemonizing before IP is acquired is certainly a bug)
<SpamapS> slangasek: it daemonizes after 60 seconds I believe
<smoser> yeah... so maybe i'm having old daemons in my head.
<smoser> i know it used to do this "no ip found for XX seconds backgrounding"
<slangasek> right; and that's not a sensible thing to do with a modern init system
<smoser> and actually, i can verify that right now on a system not connected . if i 'sudo ifup eth1' then it *does* return and dhclient is in daemon mode afterwards
<stgraber> are we sure it's dhclient daemonizing when it shouldn't and not ifupdown starting it in the background to start with (I see quite a few fork() in ifupdown's code)?
<slangasek> not sure at all
<smoser> i'm not usre.
<smoser> then *it* would have to be performing the "wait for a little while".  i can test it easily on my unconnected eth1
<slangasek> you can run dhclient directly with the same options as ifupdown does, check the behavior?
<smoser> yeah. thats what i was going to do.
<slangasek> what's the full dhclient commandline it uses, btw?  I only have ifupdown-managed dhcp on Debian machines handy, not Ubunut
<stgraber> smoser: can you try: killall dhclient3 ; ifconfig eth0 0.0.0.0 ; dhclient3 eth0; ifconfig eth0?
<stgraber> smoser: I just did it a few times here and I always get an IP when dhclient returns
<SpamapS> I only see two fork's in ifupdown's code
<slangasek> stgraber: yes, but in your case you *are* getting an IP so that's a racy test :)
<DoctorPepper> is anyone from the appmenu team here ?
<slangasek> more interesting is to see what happens when you aren't
<smoser> slangasek, ok. i verified.
<smoser> time sudo dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp3/dhclient.eth1.leases eth1
<smoser> that comes back in 1 minute and 0 seconds and change
 * slangasek nods
<smoser> and syslog shows
<smoser> Sep  1 16:01:35 mabolo dhclient: No DHCPOFFERS received.
<smoser> Sep  1 16:01:35 mabolo dhclient: No working leases in persistent database - sleeping.
<smoser> and dhclient on eth1 still running per 'ps'
<slangasek> so there's a built-in timeout of 60 for dhclient
<smoser> right.
<slangasek> I wonder if we can set that to -1
<slangasek> or if the timeout is fine and we just need to fix the behavior *when* it times out
<SpamapS> "To run force dhclient to always run as a foreground process, the  -d flag  should be specified. "
<slangasek> we don't want it to always run as a foreground process
 * SpamapS notices a bug in the man page. :)
<SpamapS> -1 for a timeout would mean what though?
<DoctorPepper> can anyone tell me why   installation of ubuntu on lvm encrypted partitions dont boot ?
<smoser> SpamapS, no.
<slangasek> SpamapS: that it would wait forever for a server instead of the current behavior, which is that it waits for 60 seconds and then *backgrounds anyway* as if it had succeeded
<smoser> slangasek is wanting it to background when and only when it gets a connection.
<SpamapS>        The -1 flag will cause dhclient to try once to get a lease.  If it fails, dhclient  exits  with  exit  code
<SpamapS>        two.  In  DHCPv6  the -1 flag sets the max duration of the initial exchange to timeout (from dhclient.conf,
<SpamapS>        default sixty seconds).
<SpamapS> Sounds like thats what you want.
<slangasek> right - devil's in the details.  What does "try once" mean here?
<slangasek> does it mean it will never try to renew?  that it will only send out one request packet?
<SpamapS> DoctorPepper: this is for discussion of development of Ubuntu. You may want to try #ubuntu if you're talking about a stable release, or #ubuntu+1 if you're trying this on oneiric.
<DoctorPepper> SpamapS: actually  i tried it  on both 10.04 , 11.04 and oneric  always the same results  failure to boot
<hrw> apparmor messages should rather not appear in dmesg - right?
<stgraber> -1 seems to do what we want. It tries until it reaches the timeout, when it does it exits with exit 1. If it gets an IP before the timeout, it'll go in the background and renew it as usual
<kirkland> jml: fixed!
<kirkland> jml: package pushed to ppa:ecryptfs/ppa
<kirkland> jml: but i've reproduced the problem and tested the solution here locally
<slangasek> SpamapS, stgraber: my testing concurs, -1 does seem to DTRT at least for the cases of reliable and non-existent dhcp servers.  I don't know about an intermittent one, though
<kirkland> jml: i'm confident enough that I'm just going to push
<slangasek> stgraber: did you test to make sure it will retransmit the requests?
<smoser> we may want to bump the timeout on it too.
<slangasek> hrw: apparmor is a kernel lsm, so it will log in dmesg
<SpamapS> it seems to just skip the daemonization step
<smoser> 60 seconds is reasonable, but if its not blocking, then it might as well be longer.
<stgraber> slangasek: what I tested is the behaviour with link and no DHCP (waited a minute and died), with link and dhcp (got an IP went in the background) and with an existing lease (renewed it)
<stgraber> smoser: I wouldn't change that timeout as it's likely going to affect NetworkManager too
<hrw> slangasek: thx
<smoser> stgraber, so can you test no link, start it, plug in link, what happens.
 * hrw -> sleep
<slangasek> smoser: well, would anything else in the boot sequence wind up blocking indefinitely if we raised the timeout?
<slangasek> and is that a good or bad thing?
<smoser> plug in link after ~ 30 seconds or so, to make sure that dhclient is re-transmitting its requests if the first dont go through.
<slangasek> SpamapS: "seems"?  it still daemonizes here on successful lease, which is what we want
<SpamapS> slangasek: with the failsafe boot, boot happens 30 seconds after 'filesystem' no matter what.
<stgraber> can we set the timeout on the command line so we don't have to change it for everyone?
<stgraber> smoser: it's an LXC container, the "no link" case is a bit of a problem to implement ;)
<slangasek> stgraber: how about the "DHCP server not running yet, gets started in the middle" case?
<SpamapS> slangasek: right, on receiving a lease it always daemonizes. "onetry" mode just skips the daemonization after reaching the initial timeout.
<slangasek> SpamapS: right - 'swhat we want
<stgraber> slangasek: that I can try
<slangasek> so, have we analyzed this to death now? :)
<stgraber> slangasek: works fine
<SpamapS> it only takes 4 people to analyze it
<SpamapS> :)
<smoser> but this is good.
<smoser> SpamapS, and i think i ssee the flaw in our /etc/network/if-up.d/upstart logic.
<smoser> we are reading /var/run/network/ifstate for "is interface up".  (ie, just checking that the interface is in there).  I think that ifupdown is pupulating that immediately.
<smoser> populating it immediately even.
<SpamapS> That would be.. unfortunate, but makes sense.
<slangasek> heh, that's true
<SpamapS> So instead of trusting that, being in there means its "up" .. we have to additionally check that it has the configuration intended?
<SpamapS> god I hate ifupdown's code
<smoser> SpamapS, well not really. we can just make our own
<smoser> that only is populated on successful bringup
<stgraber> SpamapS: bah, it's just a big manpage that happens to have C in it (and some other things) ;)
<smoser> hm... but races
<SpamapS> stgraber: you forgot the bit that turns "defn" to C
<SpamapS> and the bit that turns nowebm to "defn"
<smoser> can that perl script compile this conversation into working code ?
<stgraber> ;)
<SpamapS> so  yeah, looking at the code, I think its adding it to say "I've got this don't try to do it"
<SpamapS> not to sya "this is up"
<SpamapS> so we can simply replace that with our own state managed by if-up.d/upstart ...
<smoser> thats what i said.
<SpamapS> smoser: setting bootytraps?
<smoser> but we have to avoid racy-ness.
<SpamapS> smoser: I'm prepared to simply ignore /var/run/network/ifstate entirely
<smoser> i'm prepared to do that too
<smoser> but its not as simple
<SpamapS> smoser: what I need is "what should be up" (ifquery gives us that) and then a canonical source of what *is* up.. initctl list gives us that.
<smoser> as you can't just "echo $IFACE" >> /var/run/my-really-up-state
<slangasek> initctl list seems like a good choice
<slangasek> alternatively, you could use 'pidof ifup' + /var/run/network/ifstate
<SpamapS> the race isn't as important since this is forward only..
<SpamapS> if something comes up, then goes down again, we don't really care.. thats not something we can solve.
<SpamapS> what we want is the moment at which they were all "up"
<smoser> i dont follow that.
<slangasek> if ifup is still running for an interface you care about, and it's not the *current* interface, then you're not ready yet... oh, except those can race each other, so ignore this.
<slangasek> initctl list is the best
<SpamapS> right, because start/running is only achieved after ifup --allow auto $INTERFACE returns
<slangasek> well, no
<slangasek> it's achieved *within the upstart hook* :)
<smoser> network-interface (eth1) start/running
<slangasek> oh
<slangasek> right
<slangasek> thinking of the wrong event, sorry
<smoser> that is from my system, where eth1 is unplugged
<SpamapS> initctl list | grep '^network-interface .* start/running$'
<SpamapS> smoser: thats because ifup didn't error out
<SpamapS> it should have
<SpamapS> because we're calling dhclient wrong, it didn't
<smoser> right.
<smoser> ok.
<slangasek> you could have an instantiated job that does nothing but catch the net-device-up event
<SpamapS> one issue, do we want it trying ifup.. forever?
<slangasek> and then enumerate *those* jobs with initctl list
<smoser> why another layer of indirection, slangasek ?
<SpamapS> slangasek: thats sort of what the if-up.d/upstart script is already.. so it wouldn't be too far fetched to simply move all of this into that job.
<slangasek> smoser: because there's no other way currently that lets you count interfaces as "up" that's not racy
<smoser> i think its ok.
<slangasek> SpamapS: you couldn't move *all* of it into that job... you couldn't move the part that emits the event you're trying to catch ;)
<smoser> in the if-up.d of all of them you just say "are all auto interfaces up" (other than self) and emit if that is the case.
<slangasek> you have no way to determine that's the case
<slangasek> that's the bit that needs solved
<slangasek> /var/run/network/interfaces is an imperfect proxy
<slangasek> it tells you "ifup has been called", not "the interface is up"
<smoser> oh, and initclt list was not sufficient ?
<smoser> fyi: network-interface (eth3) start/running
<slangasek> yes, it's not sufficient
<smoser> eth3 is not in interfaces at all
<slangasek> consider two interfaces, eth0 and eth1
<slangasek> both are detected in parallel, so ifup is launched for each
<slangasek> dhcp runs in parallel on each, finishes within a split second of each other
<slangasek> so /etc/network/if-up.d/upstart is called for each interface; emits the 'net-device-up' event, which doesn't directly start any uniquely identifiable jobs that will show up in 'initctl list'
<slangasek> at this point, you'll see this output in initctl list:
<slangasek> network-interface (eth0) start/starting
<slangasek> network-interface (eth1) start/starting
<slangasek> you can ignore your *own* interface, but what about the other?
<slangasek> if you say "it's starting, that's close enough", you risk emitting the event before the interface is actually up
<slangasek> if you say "it's starting, we'll do nothing and let the *other* script handle it when it starts", you risk both scripts doing the same thing and nobody emitting the event
<SpamapS> slangasek: indeed, race found.. so we should sync these up...
<SpamapS> wait-for-state to the rescue?
<Laney> cody-somerville: can you vote on chase and brian please?
<SpamapS> hrm no.
<slangasek> right, so one way to do that is to instantiate a job for each interface, at a point in this script before it does the initctl check
<slangasek> has to be done synchronously, of course, not using -n
<slangasek> but the last of the interfaces to do so is guaranteed to see all interfaces as up
<slangasek> (...then you just have to deal gracefully with our event being emitted multiple times, which you already have to do)
<jml> kirkland: testing now
<smoser> slangasek, we were avoiding multiple times with mkdir /var/run/network/static-network-up-emitted . but maybe im' missing something.
<kirkland> jml: thanks!
<kirkland> jml: man this bug has a bunch of dupes
<slangasek> smoser: ahh yes
<SpamapS> slangasek: hm.. I'm trying to remember if emitting a sync event returns when the goal is changed to start, or when the jobs have entered start/running
<slangasek> smoser: a perfectly cromulent semaphore :)
<smoser> exactly
<SpamapS> if the former, then we still have the race.
<SpamapS> Well except now we don't care about start/running .. just start/
<SpamapS> so I think that will work
<slangasek> true
<SpamapS> since we're really just using upstart as a synchronous place holder
<jml> great. I have to get a libreoffice update at the same time :)
<SpamapS> which makes me wonder if we shouldn't just use /var/run/network dirs for simplicity sake...
<smoser> SpamapS, i couldn't avoid a race there either.
<slangasek> SpamapS: right, and does that seem reasonable or should we just do it all in /run :)
<SpamapS> jml: if we never updated openoffice, I would never have an excuse to check facebook. ;)
<slangasek> rather than making init do it for us
<smoser> how would you avoid the race?
<slangasek> smoser: by having this script write to /run/network, instead of starting an upstart job
<jml> SpamapS: heh.
<smoser> when you ccheck "are all other interfaces done" you risk a race of 2 jobs saying "nope, the other isnt done yet"
<jml> SpamapS: sadly, I get plenty of chances.
<SpamapS> smoser: create the dir, /var/run/network/ifup.$INTERFACE , then ls /var/run/network/ifup.* .. compare with /etc/network/interfaces list..
<slangasek> SpamapS: why a dir instead of a file? in this case no collisions
<SpamapS> smoser: as long as you only check after you've updated yours, you are ok
<SpamapS> Whoa
<SpamapS> earthquake
<slangasek> also, /run/network please, /var/run is a compat symlink :)
<slangasek> how bad?
<barry> seriously?  what's with all this seismic activity?
<smoser> SpamapS, i think there is a race still.
<slangasek> he's in California, he's statistically ignorable :P
<slangasek> smoser: there isn't, because you're doing a filesystem-level test and set :)
<SpamapS> not much
<smoser> eth0 touch /var/run/network/ifup.eth0; eth1 touch /var/run/network/ifup.eth1
<SpamapS> Los Angeles area.. sometimes I think I feel them and its just a big truck.. old building..
<smoser> wait...
<slangasek> smoser: each instance must create its own flag file *before* checking the list.  Therefore, whichever one creates its file *last* is guaranteed to see all of them
<barry> slangasek: :)
<smoser> eyah..i guess.
<smoser> k.
<smoser> much easier.
<slangasek> as long as we're using a POSIX filesystem, that is ;)
<smoser> as long as we dont remove them.
<slangasek> which we shouldn't
<smoser> i think we're kind of screwed if /run is not POSIX
<SpamapS> slangasek: we decided to put off non posix support for /run until after systemd migration... 15.10 maybe? ;)
<SpamapS> http://earthquake.usgs.gov/earthquakes/recenteqscanv/FaultMaps/118-34.html
<slangasek> just making sure your code isn't portable to Win32 ;)
<SpamapS> 4.1 in the valley
<smoser> SpamapS, ok
<slangasek> s/your code/you know your code/
<smoser> so i'm still going to make the /var/run/network/static-network-up-emitted dir.
 * slangasek nods
<smoser> or touch that. or something. so that when i come up i can say "has that event happened?"
<slangasek> the mkdir is best because you only want it to succeed once
<kirkland> jml: what's the word?
<jml> kirkland: ssh test failed. trying logout of desktop session.
<smoser> SpamapS, i have to run. i'll put together a merge proposal later.
<Daviey> smoser: don't break it.
<SpamapS> smoser: ok THANKS!
<kirkland> jml: hmm, i don't get it ... i reproduced your setup and the bug here exactly
<kirkland> jml: and this is fixing it for me
<kirkland> slangasek: howdy
<slangasek> kirkland: hiyo
<kirkland> slangasek: okay, a grep shows: http://paste.ubuntu.com/680126/
<kirkland> slangasek: so all of these can/should be dropped to a LOG_DEBUG?
<slangasek> kirkland: my position is that at least the first 2 should not be logged at all unless the module is being passed some debugging option
<slangasek> because "pam_sm_authenticate: Called" is bloody useless output
<slangasek> unless you're debugging the module
<kirkland> slangasek: agreed, okay
<slangasek> kirkland: also, please put the module name *in* the log messages :)
<kirkland> slangasek: agreed
<jml> kirkland: v91?
<kirkland> jml: hmm
<slangasek> kirkland: we actually have a pam helper function in current Linux-PAM that you could use, fwiw (pam_syslog())
<kirkland> jml: i think i might have push a bad upload to the ppa
<kirkland> jml: ie, without the fix
<jml> kirkland: ah, ok.
<jml> kirkland: I've got to head now -- laptop and mental batteries are fading
<jml> kirkland: but I can test on the morrow if you upload to your ppa again.
<kirkland> jml: k
<Apteryx> Hey, I've got a really trivial patch (one mirror line to add to /usr/share/python-apt/templates/Ubuntu.mirrors
<dupondje> Somebody pushed some upgrades :D
<Apteryx> I made a patch, showing the added line, see: http://pastebin.com/EFF2mvhv
<Apteryx> What's the process to get this line incorpored efficiently in Ubuntu 11.04 and later?
<Apteryx> I could report a bug against python-apt, but it seems almost overkill.
<kirkland> jml: ecryptfs-utils_92-0ubuntu1~ppa1_source.changes uploaded to ppa:ecryptfs/ppa
<stgraber> Apteryx: this is a generated file, so shouldn't be patched
<slangasek> Apteryx: as stgraber says - the correct procedure is to get your mirror registered with launchpad
<slangasek> see https://launchpad.net/ubuntu/+archivemirrors
<slangasek> (and the 'register a new mirror' button)
<slangasek> if it's already registered and what's needed is to refresh the mirror list in the package, please do file a bug against python-apt
<stgraber> Apteryx, slangasek: http://paste.ubuntu.com/680146/ is the diff from what we currently have in python-apt and what's in Launchpad
<stgraber> Apteryx: what version of Ubuntu was that patched written for? I see the uqam mirror at the top of LOC:CA in the current package
<stgraber> Apteryx: http://paste.ubuntu.com/680147/ is what we have in Oneiric
<sladen> skaet: are we unfrozen now post beta1 ?
<slangasek> sladen: we are now in feature freeze again instead of beta freeze, yes
<skaet> sladen.  yup
* slangasek changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, robert_anc
<skaet> thanks slangasek. :)
<slangasek> sure :)
<sladen> ta :-)
<slangasek> tedg: hi
<tedg> slangasek, Unfortunately I need to run... I was just logging out.
<slangasek> tedg: ok
<tedg> I'll assume you'll implement the highlander directive and we're all happy :-)
<slangasek> :)
<slangasek> well, wanted to talk through it with you
<slangasek> the reason apt has such a problem with it is because the breaks is so deep in the dependency tree
<slangasek> if it were done against the indicators themselves, which seems perfectly appropriate, apt would sort it out
<slangasek> but I realize there are a lot more of those, so it's hard to be comprehensive
<tedg> slangasek, Hmm, okay.  I have no specific concern there, but we just thought if we did it lower it would be more complete.
<tedg> Which I guess is kinda the problem :-)
<slangasek> yeah :)
<tedg> slangasek, So, in a nutshell, I'm totally open to ideas, but I think we need to have something to protect for that situation in the package.
<slangasek> agreed
<slangasek> I'll see what I can come up with
<tedg> Cool, thanks.  I'll run around in 100 degree heat with 5 year olds ;-)
<SpamapS> err.. can somebody explain this one for me...
<SpamapS> http://paste.ubuntu.com/680171/
<SpamapS> I have python3 3.2-3 installed, but it says the >= 3.2 < 3.3 dependency is not satisfiable..
<barry> SpamapS: i've seen that before too, and i don't understand it either
<barry> tumbleweed: ping
<SpamapS> maybe its to signal that python3-profiler isn't a separate package anymore.. which is cool
<barry> SpamapS: i find apt's error messages to be about as cryptic as you can get ;)
<jelmer> Sweetshark, hi
<jelmer> Sweetshark, just noticed you registered a libreoffice import - unfortunately we don't support git imports over http using the smart server protocol yet, I've fixed the URL
<jelmer> Sweetshark, There was already an import at lp:~vcs-imports/libreoffice/trunk; that failed to scan for some reason
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_anc
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso, robert_a
<pdtpatrick_> Which team would I ask this question to? .. why does the shell built-ins navigate better than for instance /usr/bin/less? ... here's an example.
<pdtpatrick_> http://pastebin.com/BLXiiV4M
<pdtpatrick_> notice how if u use cd it would add the /
<pdtpatrick_> when u tab to autocomplete
<pdtpatrick_> when u use less .. if u tab - it just creates a space instead of realizing you're navigating a directory
#ubuntu-devel 2011-09-02
<SpamapS> hrm.. python experts of ubuntu fame.. where is all the missing time going: http://paste.ubuntu.com/680217/
 * hallyn curses whoever decided it was ok to overwrite power setting on a package upgrade so as to enable suspend (aka unclean reboot) after 30 idle mins
<TheMuso> Hrm. Dealing with source format 3 packages with patches in packaging branches is somewhat painful.
<TheMuso> Seems that 1) the .pc dir is included with the merge, and 2) some of the files that are meant to be in the .pc dir to point to debian/patches are not getting included.
<SpamapS> TheMuso: indeed, the two things seem to conflict constantly. If you keep the patches unapplied in the branch, its simpler (but then you don't see patched files in the branch.. which can have its own barrel of worms)
<micahg> TheMuso: there's an option to not include patches applied in the .pc dir
<TheMuso> SpamapS: Yeah. Just working on a fix from a contributor, and had to do it the conventional way, just to keep my sanity.
<TheMuso> micahg: There is?
<TheMuso> In packaging branches?
<micahg> TheMuso: pure packaging or UDD branches?
<TheMuso> micahg: pure packaging.
<TheMuso> Sorry, distributed development
<TheMuso> so udd
<micahg> well, either way actually, there was some discussion a while back on debian-devel I think, it's part of source format 3
<micahg> or wait, maybe it's a debhelper option
<micahg> I know there's some way to do it...
<TheMuso> micahg: Well whatever it is, I think we need it for udd branches.
<TheMuso> So we don't have to deal with the mess of .pc contents.
 * micahg wonders if that's git only...
<micahg> TheMuso: http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/
<micahg> option 2
<TheMuso> micahg: Right we need that for UDD>
<TheMuso> But its somewhat different, because when you branch a UDD branch, it has the .pc directory in it.
<TheMuso> tahts my point.,
<ion> Too bad that doesnât mention git-dpm. Itâs really nice.
<ion> Oh, it does mention it. :-)
<slangasek> hallyn: dunno what caused the behavior change, but this seems to have fixed it for me: gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
<smoser> slangasek, or SpamapS you west coasters, if you'd like to review https://code.launchpad.net/~smoser/ubuntu/oneiric/ifupdown/lp838968/+merge/73741
<smoser> i just uploaded the cloud-init portion
<smoser> it results in something like:
<smoser> http://paste.ubuntu.com/680239/
<hallyn> slangasek: thanks, i'll have to look into that.  (i did meta-a and picked 'power' which brought up the powe rsettings, and picked nothing there.  but prefer a cmdline)
<hallyn> soren: hi, regarding the libvirt not starting VMs bc it couldn't create a cgroup this morning - if you still have a box you can test this on, could you try the package from http://people.canonical.com/~serge/libcgroup-fix-libvirt
<hallyn> if that works, i'll commit that for bug 828061
<ubottu> Launchpad bug 828061 in libcgroup (Ubuntu) "cgroup-bin prevents libvirt from starting" [Critical,In progress] https://launchpad.net/bugs/828061
<hallyn> smoser: ^ you also might be good tester?
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_a
<slangasek> ScottK: you said you could reproduce Debian bug #633461 - I can't, with the current python2.7 in experimental
<ubottu> Debian bug 633461 in gobject-introspection "gobject-introspection: fails to install with Python 2.7: E: pycompile:234: Requested versions are not installed" [Important,Open] http://bugs.debian.org/633461
<slangasek> ScottK: is this really still an issue?
<ScottK> It is, but as long as we remember to binNMU it after 2.7 is default it will go away.
<ScottK> Since 2.7 is the last python, I think that's an adequate solution.
<slangasek> ScottK: hmm; how/why is it an issue?  (given that I can't reproduce it)
<pitti> Good morning
<ion> that.
<ScottK> slangasek: I don't recall.  Heading to bed now, I'll see if I can remember to try it again tomorrow.
<slangasek> ScottK: ok, 'night
<micahg> pitti: or slangasek could I get one of you to please copy thunderbird lucid from ubuntu-mozilla-security to lucid-security?
 * micahg wonders if any other archive admins are available
<pitti> micahg: doing
<micahg> pitti: thanks
<pitti> micahg: done
<micahg> pitti: thanks!
<didrocks> good morning
<doko_> pitti, is the libindicate build failure on powerpc transient?
<pitti> doko_: very well possible, the new gobject-introspection was lagging behind yesterday
<pitti> doko_: retried
<pitti> if it fails again, I'll investigate
<dholbach> good morning
<pitti> yay, libo built on powerpc
<pitti> Sweetshark: ^ nice!
<pitti> hey dholbach
<htorque> RAOF: killed X on intel
<htorque> oops, wrong channel, sorry
<dholbach> hey pitti
<soren> pitti: I just noticed a bunch of you guys just expired from the techboard, but I don't recall any mention of an election during your meetings?
<doko_> pitti, libindice still ftbfs on powerpc
<geser> huh, we have no TB anymore?
<pitti> yeah, we mentioned it to sabdfl, he needs to re-new our membership for about four weeks
<pitti> elections will be held soon
<pitti> doko_: ah, ok; I'll tell Ken
<soren> pitti: Ok, cool. I really just wanted to make sure I hadn't missed it. :)
<jml> kirkland: v92 works. Thanks!
<hrw> shit. quilt/oneiric works different then quilt/lucid ;(
<hrw> gcc-4.[56]/oneiric fails to patch on lucid
<pitti> ev: FYI, I landed pygobject 2.90 in oneiric yesterday, this breaks ubiquity; I have a branch which fixes most of it, but this afternoon I'll go through the whole installation to check for more breakage; you should have a merge proposal from me by Monday
<ogra_> hmm, no mvo ...
<pitti> ogra_: holidays
<ogra_> update-manager refuses to upgrade here, complaining it cant find a -meta
<ogra_> but ubuntu-desktop is installed
<anthony_dev> hi guys. I got a problem and I think its a bug of Libre Office. where I should post info about this?
<ion> anthony_dev: Run ubuntu-bug /usr/bin/libreoffice
<anthony_dev> ion thanks, I'll try it later at home. at work I have Windows.
<hrw> ok, found
<hrw> doko_: gcc-4.[45]/debian/patches/gcc-multilib64 patch does not apply under non-multiarch systems
<hrw> doko_: gcc-multiarch.diff is applied always - so looks like gcc-multilib64-multiarch should also be applied always
<bambee> hello, these days on oneiric, I've strange problems with my mouse. Sometimes the mouse freezes completely (the keyboard works and the system too), a workaround is to unplug/replug the mouse, and then it works again
<ion> Anything interesting in the X log or syslog?
<bambee> My X log : http://paste.ubuntu.com/680481/
<ion> At the point of the mouse disappearing, that is.
<doko> pitti, bryce_ bryceh, cjwatson: is there a reason that xcb-util-renderutil is not in oneiric? and if yes, what is the replacement for it?
<doko> hmm, still in libxcb-util0-dev ?
<doko> didrocks, pitti: uploaded unity to fix the b-d on libxcb-icccm4-dev, but I get a bzr error to check in the change. could you check in the change?
<didrocks> doko: did you push it to the vcs? I don't find your change
<doko> didrocks, did you read my message???
<didrocks> "check in the change", ok
<didrocks> doko: waiting for the diff to generate and then will check it in
<doko> thanks!
<didrocks> yw :)
<bambee> ion: it happens again, I just saved my syslog and my Xorg.log : http://paste.ubuntu.com/680520/, http://paste.ubuntu.com/680522/
<doko> didrocks, pitti: feel free to work on bug 839526, if it's not for the dx team
<ubottu> Launchpad bug 839526 in utouch-gesturetest (Ubuntu Oneiric) "package needs b-d on libxcb-icccm4-dev, but ftbfs" [High,Confirmed] https://launchpad.net/bugs/839526
<didrocks> cnd: once you are around ^
<bambee> ion: perhaps "Sep  2 14:28:45 linux-EX58-UD4P acpid: client 1267[0:0] has disconnected"
<doko> and promoted libxcb-icccm4 libxcb-icccm4-dev
<cjwatson> doko: xcb-util-* got merged into xcb-util upstream, AFAIK
<pitti> ev: I just finished two ubiquity test installs with my pygobject fix branch, they both succeeded now; MP sent: https://code.launchpad.net/~pitti/ubiquity/pygobject-2.90/+merge/73802
 * pitti -> back to travel/weekend
<smoser> hallyn, is there a reason you'er not using grep -q ? but rather [ -n "`grep ..`" ] ?
<hallyn> smoser: nope
<smoser> - if [ -n "`grep "/sys/fs/cgroup" /proc/mounts`" ]; then
<smoser> + if grep /sys/fs/cgroup /proc/mounts; then
<smoser> + if grep -q /sys/fs/cgroup /proc/mounts; then
<smoser> obviously not a big deal.
<smoser> cjwatson, i'm told you know some tool to check what upload permissions someone (I) have
<OdyX> smoser-has-upload-on ?
<micahg> smoser: edit_acl.py in lp:ubuntu-archive-tools
<cjwatson> what he said
<hallyn> smoser: yeah i'm usually more comfortable with 'test' ('[') i guess but i'll make the other change you mentioned, get rid of '.sh' suffix
<hallyn> smoser: but if you can verify that it works for you then i can ask someone to push :)
<cjwatson> much more efficient to test exit code vs. testing length of string output
<hallyn> that way leads to system-d :)
<hallyn> not just testing length, also forking off a task to do it
<hallyn> (iow - agreed)
<smoser> cjwatson, i don tknow about "much" more efficient
<smoser> but definitely at least char compare better.
<smoser> hallyn, i will test.
<cjwatson> well, ok :)
<hallyn> \o/
 * hallyn takes on some Daviey-isms
<kirkland> jml: \o/
<kirkland> jml: thanks for ALL of your help
<kirkland> jml: that bug had 4 dupes
<jml> kirkland: :D
<Daviey> hallyn: :o
 * Chipzz wonders what's up with .sh/.pl/.py extensions for programs anyway
<Chipzz> don't we have shebangs for a reason? and shouldn't wether a program is in perl/python/shell/whatever be an implementation detail the user doens't care about?
<OdyX> Chipzz: that's 10.4 of the Debian policy: "(â¦) scripts (â¦) in the system PATH (â¦) should not include an extension (â¦)"
<Chipzz> OdyX: right. but the tool micahg was talking about probably isn't packaged even
<OdyX> ah yeah, sorry; I lacked context.
<cjwatson> *shrug* not that important.  maybe some day we'll get round to renaming them
<Chipzz> cjwatson: I was actually more wondering why ppl do that than complain
<Chipzz> it's rather ugly imho
<Daviey> edit_acl.py isn't packaged, i just have it symlinked into ~/bin/ .. There are more importiant disasters in the world than fixing unpackaged file extensions :)
<Daviey> Chipzz: If you fix that, you will break my symlink, and for that, i will hate you.
<Chipzz> Daviey: I don't even remotely have access to that machine :)
<Daviey> Chipzz: you do, if i pull a branch where someone 'fixes' it.
<doko> Sweetshark, http://people.canonical.com/~ubuntu-archive/NBS/  please look at the libreoffice* packages, and remove these in the OOo build
<Chipzz> Daviey: no interest in "fixing" it, like I said, rather more wondering why ppl do it. but I think I'm going to shut up about it, only adding noise to the channel :)
<lenios_> sorry if that's not the best place to place, but does anybody know how to disable dh_shlibdeps (looks like it's now default on 11.10) when packaging with pbuilder cdbs?
<cjwatson> that's generally a really bad idea
<lenios_> i know
<cjwatson> and it's been the default forever
<cjwatson> why would you want to disable it?
<lenios_> i need i386 libs to run a lotus notes on an amd64 system
<cjwatson> doesn't look like cdbs offers a way to disable it in general
<cjwatson> what's the package you're building?
<lenios_> i need to run lotus notes
<cjwatson> with 11.10 you should use an i386 version of it with multiarch
<lenios_> can't change this one, so i'm trying to package libs and put them in /opt/lib32
<cjwatson> better to just build it as a straightforward i386 package
<cjwatson> 11.10 supports installing i386 packages on amd64 systems
<cjwatson> and hopefully has enough multiarch-capable libraries to support whatever you need
<lenios_> i need old libs
<cjwatson> you could multiarchify them; http://wiki.debian.org/Multiarch/Implementation
<lenios_> for example libeel2-2, which is only in hardy
<cjwatson> probably no more difficult than trying to bodge something together with /opt/lib32
<cjwatson> in fact I suspect it'd be easier since it's a fairly standard process
<lenios_> wait, /usr/lib is going to be /usr/lib/<triplet> for all libs?
<lenios_> notes is hardcoding /usr/lib path
<lenios_> i hope it can work with LD_LIBRARY_PATH=/usr/lib/i386 like it works with LD_LIBRARY_PATH=/opt/lib32
<cjwatson> you shouldn't need LD_LIBRARY_PATH for that
<cjwatson> the toolchain already knows about it
<lenios_> i'll try
<cjwatson> (and it's /usr/lib/i386-linux-gnu/, or /lib/i386-linux-gnu/)
<lenios_> oh, i've seen that
<SpamapS> smoser: so, re the new behavior of dhclient to have -1 passed.. how do we know when to retry bringing up that interface? I strikes me that this changes the behavior quite fundamentally
<SpamapS> smoser: currently, if I 'ifup eth0' .. it will eventually get an IP and find its way to DHCP land.
<SpamapS> smoser: but with this change, it won't have that chance.. it will just fail, and I'll have to manually 'ifup eth0' after plugging it in.
<smoser> SpamapS, i thought the same, but slangasek said its busted, fix it.
<smoser> now, it will try for 60 seconds and then say "yes i did that"
<smoser> which i agree is fundamentally broken.
<smoser> (if you were not plugged in)
<SpamapS> Its also the suck if you have dark network cables that you plug in and let time out..
<SpamapS> Not sure why somebody would do that, but as a change in critical behavior, I think we'll need to mention it in the release notes.
<doko> o xcb-util-wm: libxcb-ewmh1 libxcb-ewmh1-dev
<doko>    [Reverse-Depends: Rescued from xcb-util-wm, libxcb-ewmh1-dev]
<doko> kees, are you ok to promote this (no other mir team member here)
<kees> doko: promote which? all 3?
<doko> kees, right
<kees> doko: i will go read there over quickly, one sec
<kees> doko: +1 it's pretty small
<hallyn> smoser: http://people.canonical.com/~serge/libcgroup-fix-libvirt2 has the fixes you suggested.  D'oh, without credit in the changelog, sorry.
<cjwatson> zul: bug 798925 / bug 805656 - how about xenwatch?  is it intrinsically specific to xen 3.3 or would it be straightforward to update to 4?
<ubottu> Launchpad bug 798925 in xen-3.3 (Ubuntu) "Please remove xen-3.3 from Ubuntu" [Undecided,Incomplete] https://launchpad.net/bugs/798925
<ubottu> Launchpad bug 805656 in xenner (Ubuntu) "Please drop xenner from Oneiric" [Undecided,New] https://launchpad.net/bugs/805656
<zul> cjwatson: lemme have a look
<smoser> hallyn, if [ -n "`status cgconfig | grep "start/running"`" ]; then
<smoser> if status cgconfig | grep -q "start/running"; then
<cnd> didrocks, interesting, I'll upload a fix for gesturetest
<hallyn> smoser: no
<smoser> no?
<hallyn> no, bc if it's not running, 'status' will print garbage to stderr
<hallyn> and in dash i could find no clean way to get rid of that
<hallyn> 2>&/dev/null doesn't seem to work
<smoser> 2>/dev/null
<hallyn> i think it complainted about that
<hallyn> complained even
<hallyn> lemme try
<cjwatson> 2>/dev/null is portable
<hallyn> right, and & means fd :)  so what i typed was wrong in any case
<smoser> you need to redirect the first half.
<smoser> status cgconfig 2>/dev/null | grep -q "start/running"; then
<hallyn> well id on't know why it complained in my euca instance, unless i had a typo there too.  but it works here
<hallyn> i'll change that IF you test it successfully :)
<hallyn> (and then i can credit you too :)
<bambee> bdrung: ping, debuild is totally borked with parallel jobs
<bambee> I don't know if it has something to do with your last revision, but it worked just fine before
<Laney> bambee: 'borked' doesn't say much.
<bambee> Laney: when I try to build a package with "debuild -j8", there is only a single job
<bambee> same thing with pbuilder (using a correct .pbuilderrc)
<tumbleweed> debuild takes -j options?
<tumbleweed> bambee: you are aware of DEB_BUILD_OPTIONS?
<bambee> it did... at least few months ago it worked fine
<Laney> dpkg-buildpackage does
<tumbleweed> oh, neat, I just have it in my bash profile...
<bambee> tumbleweed: yes I am
<bambee> http://paste.ubuntu.com/680665/
<bambee> my pbuilderrc
<Laney> try it with just dpkg-buildpackage. it's unlikely to be anything to do with devscripts. (likely the package in question)
<tumbleweed> the package should also be following DEB_BUILD_OPTIONS not MAKEFLAGS (according to debian policy)
<bambee> Laney: trying
<SpamapS> smoser: so, re bug 839595 .. if we're going to raise it above 30 seconds, I'd actually think more like 2 minutes .. the thinking being that there may be complex and slow network configs going on leading up to the minute of DHCP waiting..
<ubottu> Launchpad bug 839595 in upstart (Ubuntu) "failsafe.conf's 30 second time out is too low" [Undecided,New] https://launchpad.net/bugs/839595
<smoser> SpamapS, i think that is reasonable.
<smoser> one other "benefit" for it being larger
<smoser> is that if the user has misconfigured /etc/network/interfaces, they're more likely to know
<smoser> and fix it
<SpamapS> smoser: I'm still concerned about the fact that we're not going to fork dhclient off to re-try the auto interface's dhcp forever.. maybe we need to start our own daemon to do that.
<SpamapS> smoser: yeah I'd love to actually print a plymouth message at 90 seconds saying something like "Boot waiting 30 more seconds for network interfaces to be configured.." so that they see it very clearly.
<smoser> SpamapS, cloud-init-nonet does something like that.
<smoser> but not a plymouth message
<smoser> just an echo.
<smoser> sleep 30 , echo a message, sleep some more
<jtaylor> is glib2.0 not multiarch coinstallable anymore?
<jtaylor> trying to install it will remove half the system since .18
<smoser> SpamapS, ^ will tha tnot do what you wanted ? or did you mean something special by "plymouth message". if there is a command to do it, just substitute for echo.
<shbk> hello, does anybody know where I can find  in /proc (another place) information about my keyboard,motherboard,video card, peripheral devices? for example I found info about processor (/proc/cpuinfo),RAM(/proc/meminfo)
<cjwatson> device information is more likely to be found in /sys
<cnd> doko, I can't reproduce your build failure for utouch-gesturetest
<cnd> I used bzr bd --builder=pdebuild from our packaging branch
<cnd> and with an updated oneiric pbuilder chroot
<doko> cnd, did you change the b-d?
<cnd> doko, no
<cnd> why do I need to change the b-d?
<cjwatson> because libxcb-icccm1-dev is no longer built by any source package and thus is due to disappear from the archive.  see http://people.canonical.com/~ubuntu-archive/nbs.html
<doko> cnd, because it's gone, only the binary -dev package is still in the archive
<cnd> oh
<cnd> doko, I'm curious, why is libxcb-icccm1 gone now?
<cjwatson> upstream changes
<cnd> cjwatson, ok, but why now?
<infinity> Replaced by libxcb-icccm4-dev/libxcb-icccm4?
<cnd> it seems late in the cycle
<cjwatson> it was actually ages ago
<infinity> I assume.
<doko> cnd, well, as you can see from the build log, incompatible changes, and packages are renamed for that reason
<cjwatson> it's just that we haven't managed to clean up the NBS packages until now
<cnd> ahh
<cjwatson> this is the point in the cycle when we traditionally sit for ages fighting to do that
<cjwatson> if people haven't noticed and sorted it out earlieer
<cjwatson> *earlier
<hallyn> smoser: is cgroup-bin+libvir testing ok for you?
<smoser> hallyn, i'll test now.
<smoser> i suppose the bzr branch is broken for that?
<hallyn> you know it might not be.  it's broken for the things i touch most often so i tend not even check right now
<hallyn> smoser: i can push a bzr tree, gimme a min
<hallyn> you know what's broken?  Alt-friggin-tab in unity
<bambee> Laney: I found, "warning: jobserver unavailable: using -j1.  Add `+' to parent make rule."
<cjwatson> hallyn: I got fed up and just turned it off ...
<cjwatson> ccsm -> Ubuntu Unity Plugin -> Switcher -> Key to start the switcher -> Disabled
<hallyn> does that bring alt-tab back for actual application switching?
<hallyn> I assume there's a way to fix it in the compiz manager...
<cjwatson> I suppose I should have filed a bug but given that it was exposed as a preference I assumed it was just a "some people hate this, we know" kind of thing
<cjwatson> yes, and that *is* the compiz manager
<hallyn> doh. right.
<hallyn> cjwatson: yay!  thx
<cjwatson> welcome
<hallyn> smoser: lp:~serge-hallyn/ubuntu/oneiric/libcgroup/fix-libvirt
<infinity> cjwatson: Remind me again exactly when and how a Mac user wants amd64+mac versus amd64?
<cjwatson> infinity: if they don't want their system bricked
<cjwatson> (depending on the exact vintage)
<infinity> So, they always want +mac, is what you're driving at?
<cjwatson> infinity: also if they want the image to boot (again depending on the exact vintage, and that's why it was created)
<cjwatson> infinity: yep
<tjaalton> amd build of latest unity somehow failed to build unity-common and unity-services
<tjaalton> sorry, unity-services is fine
<Laney> is there a private contact address for the TB?
<cjwatson> infinity: I went into more detail in http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image
<infinity> cjwatson: Irksome, since we only build it for ubuntu.
 * infinity scraps suggesting trying kubuntu and xubuntu to his mac friend.
<tjaalton> *amd64 build of unity, somehow broken. archive has unity-common 4.12.0-0ubuntu1, while unity is -0ubuntu2. and this one confirms that no unity-common got built: https://launchpad.net/ubuntu/+source/unity/4.12.0-0ubuntu2/+build/2761299
<tjaalton> ..which breaks upgrades, unity wants to deinstall itself
<cjwatson> infinity: mjg59 did figure out how to make it unnecessary, and I have a to-do item somewhere to explain that to the xorriso developer so he can implement it
<cjwatson> s/the /a/
<infinity> tjaalton: Hrm?
<infinity> tjaalton: Common is arch:all, no?
<infinity> tjaalton: Which would be from the i386 build.
<tjaalton> infinity: ah.. ok :P but still, not in the archive
<infinity> tjaalton: Define "the archive".  Mirrors suck. :P
<tjaalton> the main one
<tjaalton> mirrors suck, yes
<tjaalton> at least for the devel series
<infinity> unity-common | 4.12.0-0ubuntu2 |       oneiric | all
<infinity> It's in "the main one".  When I say "mirrors suck", that includes our own.
<infinity> archive.ubuntu.com is still a bunch of mirrors. :P
<infinity> (moral of the story: patience)
<tjaalton> heh, ok
<tjaalton> that was an unfortunate dinstall run, then
<infinity> cjwatson: Would be pretty shiny to make it go away, if for no other reason than to allow flavours to boot on mac without us building N more images (which we won't do)
<tjaalton> anyway, thanks for confirming
<cjwatson> infinity: indeed, I don't *like* its presence, it's just necessary right now
<cnd> doko, cjwatson: would I need an FFe for a micro-release update of utouch-gesturetest, the only change being the ftbfs against newer xcb-icccm?
<infinity> cnd: No.  If the only change is literally just the FTBFS fix.
<cnd> ok
<infinity> (Unless you consider "it builds now!" to be a new feature)
<cjwatson> indeed.
<cnd> the FF process says microreleases that just fix bugs like this are "okay", but it's unclear if that means "okay without and FFe", or "usually they are okay to get an FFe"
<cjwatson> cnd: no need for an FFe, since they don't contain new features
<infinity> cnd: Fair enough.  And we do appreciate caution over the alternative.  But yeah, strictly bugfixes that don't implement new features (or change old ones) are fine without an exception.
<Laney> The part of the version string that changes has no bearing on whether the upload needs an exception or not. I guess that paragraph is there because people were unclear about whether they could upload new upstream releases.
<cjwatson> Would anyone like to take on bug 789268?  I've posted an explanation of what needs to be done, but given that the reporter's LP display name is "deleted" and username "to-delete", I'm guessing they're no longer interested
<ubottu> Launchpad bug 789268 in batmand (Ubuntu) "Please remove batmand-gateway-(source|dkms) from the Ubuntu archives (FTBFS)" [Undecided,Confirmed] https://launchpad.net/bugs/789268
<zul> cjwatson: xenwatch has been updated to libxen-dev, with regards to xenner it wont build with the new xen library and there hasnt been a new version in like 2 years so we might as well drop it
<cjwatson> zul: yeah, I know there's a removal request for that, that's fine
<cjwatson> zul: thanks, I'll process those once xenwatch has built so that the reverse-depends chain is clear
<cjwatson> I just don't like breaking the archive by removing stuff, especially at this point in the cycle
<zul> cjwatson: ok
<doko> jtaylor, why didn't you upload your fix for debian bug 632114?
<ubottu> Debian bug 632114 in mooproxy "ftbs with --as-needed" [Wishlist,Open] http://bugs.debian.org/632114
<doko> jamespage, did you get FFe's for the maven syncs?
<jtaylor> doko: I have no upload rights
<jtaylor> its sitting in the sponsor queue
<doko> jtaylor, you should get some ;-) asked MOTU about this?
<jtaylor> yes, I'll apply for motu soon
<bdrung> bambee: what was the result with dpkg-buildpackage?
<jtaylor> doko: my unfinished(!) application is here in case you already want to endorse https://wiki.ubuntu.com/JulianTaylor/MOTUApplication
<SpamapS> smoser: congrats btw!
<bambee> bdrung: same thing
<doko> barry, what is your obsession with pyside? ;-P
<pdtpatrick> 11.10 really hates nvidia drivers doesn't it .. keeps getting stuck on Checking battery state if u use nvidia-drivers. And this is using the Additional drivers feature
<san_1989> i am going to  develop device driver for usb bridge cable in linux(ubuntu 11.04)...any suggessions?any good reference sites?..or any good channel that handling it..?
<SpamapS> slangasek: an old, ugly bug seems to have reared its head.. can you review my comments just posted to bug 462169 ?
<ubottu> Launchpad bug 462169 in samba (Ubuntu Lucid) "nmbd dies on startup when network interfaces are not up yet" [High,Triaged] https://launchpad.net/bugs/462169
<barry> doko: i take that bug as a personal affront :)
<san_1989> anyone help me...
<smoser> slangasek, your comments / re-review and of would be appreciated (https://code.launchpad.net/~smoser/ubuntu/oneiric/ifupdown/lp838968/+merge/73741)
<Daviey> adam_g: Did someone from foundations look at your branch for bug 818177?
<ubottu> Launchpad bug 818177 in linux (Ubuntu) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<adam_g> Daviey: hasn't gotten any response on LP, but i believe lynxman spoke to someone from foundations here yesterday
<lynxman> Daviey: jhunt reviewed it and he thought it was okay if we added a timeout on wait_for_udev
<lynxman> Daviey: did you go to SL6 yet? I could still go :P
<slangasek> SpamapS: reviewed :)
<Daviey> lynxman: Not yet.. but am closer.
<lynxman> Daviey: :)
<SpamapS> slangasek: that is incredibly confusing.. UGH... thanks though.
<slangasek> SpamapS: so that new bug report needs an smbd.log and the smb.conf showing what exactly they're doing, because smbd is not supposed to need the interface up before it starts, in the general case
<slangasek> smoser: my opinion on the ifupdown merge hasn't really changed; I think returning results in global variables is a horrible pattern in any language, and I don't think that's a change to be made during Feature Freeze
<smoser> wait. what? slangasek ?
<smoser> i thought i said yesterday that i thought it was too late in a release for this.
<smoser> and you said otherwise.
<smoser> you're really objecting only on the basis of a global variable ? after complaining about forks other places ?
<smoser> i'm fine to change that, but my personal feeling is that _RET as a return variable in shell is completely acceptable.
<slangasek> smoser: I think it's perfectly appropriate to fix the bug at this point in the cycle, but inappropriate to restructure the code like that in the process
<smoser> well, i'm more than willing to put it back the way it was, but I think restructuring of that loop is several orders of magnitude less likely to cuase fallout than adding '-1' to dhclient.
<smoser> but i will shut up now
<smoser> as i want that change in
<slangasek> I agree, it is less risky - but there's also less benefit, as in none that I can see :)
<smoser> do you also disagree to the check for mkdir ?
<slangasek> I do, but it's not worth arguing about because it's clearly low risk
<smoser> slangasek, ok. i'm going to ditch the mkdir also
<slangasek> smoser: ok, cheers
<smoser> but not because you said to
<smoser> :)
<slangasek> :D
<smoser> only because if there were a trailing slash on it anyway then it would actually make the lock dir
<smoser> ie if someone did: MARK_STATIC_NETWORK_EMITTED=/run/network/mylock/
<smoser> and i dont want to deal with that now.
<slangasek> adam_g: 818177> fwiw, doesn't look like you'd set foundations as a reviewer, so I've only seen it now because the bug was assigned
<slangasek> adam_g: anyway, I talked about this issue with someone (hallyn, I think?) a couple of weeks ago... this change only moves the race, it doesn't fix it :/
<slangasek> smoser: heh, fair enough
<slangasek> ah no, it was smoser, I was just having another conversation with hallyn at the same time
<adam_g> slangasek: ah, right. i figured it was just a bandaid but worth submitting to get discussion going, since its a nasty one
<slangasek> more like smacking bubbles in the wallpaper than a bandaid :)
<adam_g> well, a bandaid for my specific boo-boo :P
<slangasek> :-)
<slangasek> adam_g: I would recommend talking to udev upstream about this, and maybe check what dracut is doing as far as udev handling in initramfs... maybe this is a known solved problem already, or maybe it needs an upstream fix
<smoser> bug 818177
<ubottu> Launchpad bug 818177 in linux (Ubuntu) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<smoser> slangasek, ok. please take one last glance at that MP and then i can upload.
<slangasek> smoser: looks good, ship it! :)
<smoser> thank you for not objecting to the new comments
<smoser> :)~
<slangasek> haha
<slangasek> smoser: also, congrats on the new core-dev status :)
<cjwatson> quick, assign him some bugs
 * slangasek grins
<slangasek> well, ifupdown being one's second upload as a core-dev isn't too shabby :)
<cjwatson> "brave"
<stgraber> ;)
<stgraber> slangasek: oh, just noticed that iscsi bug, seems like I'll be having some fun next week ;) Only briefly played with iscsi back in 8.04 and tried very hard to avoid it since then.
 * cjwatson breathes a sigh of relief since I handled the last n iscsi bugs
<cjwatson> it's usually networking being torn out from under iscsi at some inconvenient time
<slangasek> smoser, SpamapS: we still need to deal with the flipside of this bug, which is that during normal operation, a network interface that's properly configured and is going to come up should *never* hit the dhclient timeout - whether we deal with that by treating the ifup command as succeeding or failing
<slangasek> (as SpamapS has pointed out)
<slangasek> cyphermox, cjwatson, stgraber: what would the consequences be outside ifupdown (i.e., NM + installer) if we raised dhclient's initial timeout limit from, say, 60 seconds to 300?
<slangasek> stgraber: you mean you don't have airborne nanomachines in your office that boot over iscsi?! The illusion is shattered
<cyphermox> hehe
<cyphermox> slangasek: I think NM has it's own timeout, I'll check
<slangasek> cyphermox: right, that's what I would hope - ideally we could have dhclient called with -1 everywhere and an infinite timeout, and let the network managers (whichever they are) handle timeouts
<slangasek> smoser: the other question is, why is it taking >60s for your interface to prime itself :)  kernel bug?
<smoser> yeah. apparently you can add some kernel flags to help the driver, per Daviey.
<smoser> but it was useful in that we found this.
<slangasek> indeed
<slangasek> has anyone asked the kernel team about setting those flags by default, or otherwise dealing with the slowness?
<smoser> i dont think so. but i know nothing more than i thought i'd found a time warp to 1995 when daviey said "I had to add some kernel flags to make dhcp work"
<stgraber> I have some switches that currently need somewhere between 30 and 45s to negociate a link, "by design" :)
 * slangasek chuckles
<stgraber> at least most servers run with static IPs so I only use dhcp at install time where I usually need between 2 and 3 retry before they get an IP...
<stgraber> I'm not sure how netcfg handles the dhcp timeout but if it has its own, I'd suggest it be raised to some higher value (twice what it currently is would be nice, you can easily skip it anyway)
<slangasek> stgraber: could you check into netcfg and see?  It'd be nice to close this out today
<slangasek> and if everything that calls dhclient does its own timeout, I'd rather raise dhclient's internal timeout exponentially instead
<slangasek> to avoid any risk of false negatives
<stgraber> slangasek: ok, from a quick read of netcfg's code, it's starting "dhclient -1" with a custom configuration "-cf xyz" that contains a custom timeout set to the value of netcfg/dhcp_timeout in debconf
<slangasek> ok, cool
<cyphermox> slangasek: yup, NM already has a timeout set to 45 s
<slangasek> excellent, so we can update dhclient with impunity
<cyphermox> stgraber: if your switches take 30 to 45s to negociate for client nodes, turn portfast on to those ports ;)
<Apteryx> Hi everyone. When packaging new release of a software, what's to do with old patches?
<stgraber> cyphermox: yeah, I guess I'll simply turn STP off entirely on all my switches. All unused ports are shutdown anyway and most of the others require 802.1x, so it's pretty unlikely that a loop would appear ;)
<cyphermox> Apteryx: you'd then want to see if those are still needed, and if so, try to apply them / fix them so they work on the new release.
<Apteryx> cyphermox ok... man this is hell, there's like 44 patches to track.
<cyphermox> stgraber: heh, you never know when a link stops working. stp is good to have, but it's up to you. portfast on cisco hardware (and I'm sure there's an equivalent on others) makes sure it skips the stp stuff and comes up usually in < 15 s
<cyphermox> stgraber: also, any luck with DHCPv6 and my patch to deal with DUIDs ? ;)
<stgraber> I guess I'll start by turning portfast on then (I'm currently using small cisco gigabit switches)
<stgraber> cyphermox: I'm "almost" there ;) I now have my scripts generate my test VMs automatically, just need to get the d-i preseeding done and it'll be NM's turn.
<Apteryx> cyphermox, but will the patches even apply? The versionning is different and is often found in filenames.
<cyphermox> Apteryx: depends on software, but usually the version number for the software is irrelevant (though if it bumps a lot then the code base is likely very different and thus the patches might be more difficult to apply)
<Apteryx> cyphermox, I'll give it a try, thx!
<cyphermox> Apteryx: sure. it may well look worse than it is, but you really need to try to know. what application is that for?
<Apteryx> cyphermox, this is pulseaudio
<Apteryx> cyphermox, I'm having a hard time understanding Ubuntu's versionning scheme. I want to update pulseaudio version from 0.9.22 to 0.99.3-0.1. Old package version was: 1:0.9.22+stable-queue-24-g67d18-0ubuntu3.1
<Apteryx> What's the leading '1:' ?
<cyphermox> Apteryx: is the upstream version number 0.99.3-0.1?
<Apteryx> cyphermox, 0.99.3 and 0.1 is kind of a release candidate version.
<cyphermox> the leading 1: is the epoch value which you usually shouldn't change. if it's there for a package, you'll need to keep it
<Apteryx> I understand that the digit following 'ubuntu' in the version number is for the ubuntu package specific revision, what about the leading digit of 'ubuntu'? (in this case 0)
<Apteryx> Would "1:0.99.3-0.1-0ubuntu1" be a sane version number?
<cyphermox> nope, the - has a special meaning.
<cyphermox> I'm not sure where you get the 0.1 from, but 0.99.3 appears to be the lastest version available for pulseaudio
<cyphermox> so you'd use 1:0.99.3-0ubuntu1 for version number, assuming you'd use http://freedesktop.org/software/pulseaudio/releases/pulseaudio-0.99.3.tar.gz as the source tarball
<cyphermox> the - and following numbers are used for package revisions in Debian and Ubuntu, so you can't really have it in version number for the upstream project
<Apteryx> cyphermox, Yeah, I think I made up the 0.1 xD, sorry about that.
<cyphermox> np :)
<Apteryx> cyphermox or at least can't find trace of it anywhere now.
<Apteryx> Apparently I have a missing /usr/share/cdbs/1/rules/autoreconf.mk file on my system. Shouldn't this come with cdbs?
<jtaylor> no dh-autoreconf
<Apteryx> jtaylor, thank you!
<SpamapS> slangasek: indeed I must have jumped the gun a bit on that duplication.. smbd does have the ability to bind to a specific IP tho, right?
<SpamapS> n 15
<slangasek> SpamapS: yes, it does, but it's not enabled by default - if you want to be conservative, I suppose you could make smbd wait for the all-auto-interfaces event, though I'm inclined to think someone fiddling these parts of smb.conf should also update the upstart job for their specific (non-standard) requirements
<SpamapS> slangasek: that sounds very... strange to me, that one would have to update the start script order just for what is basically a normal very common config change.
<slangasek> SpamapS: I don't see why you would say this is a very common config change
<slangasek> I think most people who make this change are doing so without a good reason
<SpamapS> Like not wanting samba on the insecure network.. ?
<slangasek> that can be specified with 'interfaces = eth0' - no hard-coding of IPs
<SpamapS> same problem though
<slangasek> I don't think so
<slangasek> I believe you'll find the behavior differs
<SpamapS> It just polls until eth0 has an IP?
<slangasek> I believe that's what it does, yes
<SpamapS> so its the one well behaved daemon that does it right. ;)
<SpamapS> slangasek: I believe you, I really do... I'm just worried that we're unnecessarily burdening people.. what good reason is there to start smbd before all network interfaces are up?
<slangasek> in the pathological case, because the machine has loopback smb mounts in /etc/fstab? :)
<slangasek> I don't feel too strongly about doing it this way, honestly; the current start condition predates the availability of the "all interfaces" event
<SpamapS> slangasek: I'm fairly convinced that we can simplify everyone's life by simply moving most things to runlevel 2
<SpamapS> slangasek: the few things that *need* to start before then already do.
<slangasek> well, smbd can't be moved to runlevel 2
<slangasek> because it *could* block the filesystem event
<slangasek> waiting for all interfaces merely slows down the boot; waiting for filesystem could block it entirely
<SpamapS> Right.. hm.
<SpamapS> loopback to the local smbd .. thats just.. nuts. ;)
<slangasek> no more nuts than hard-coding ip addresses in your smb.conf ;)
<infinity> Loopback to local smbd isn't as uncommon as you'd think.
<infinity> Though it sounds odd.
<SpamapS> I still think thats a pretty common use case and not one to derride.
<SpamapS> the ip thing, not the loopback samba mount
<SpamapS> the loopback samba mount sounds crackers to me. ;)
<infinity> And, I dunno, binding to interfaces SHOULD be more common than binding to IPs.
<infinity> But I can't say what people actually do.  Just what they should. :P
<slangasek> SpamapS: why would you hard-code the IP?
<SpamapS> infinity: unless you want just a specific IP on a specific interface.
<SpamapS> because eth0 has 20 IPs, and you only want to provide smbd on one of them.
 * slangasek thinks about this
<slangasek> why would you not configure alias interfaces in that case, if you mean to provide different services?
<infinity> By "eth0", you mean "eth0 and 19 aliases", or actually eth0?
<SpamapS> if you also added interfaces = eth0 .. would it wait to bind() until eth0 was fully configured.. how would it even know that the ip you wanted was ready
<SpamapS> slangasek: you think it would be easier to have 'interfaces = eth0:14' instead of binding to the IP I mean?
<infinity> SpamapS: Yes.
<SpamapS> lol.. ok
<SpamapS> I guess I think differently.
<infinity> SpamapS: Since eth0:14 might have your IPv4 and IPv6 IPs for all the services associated with that alias.
<infinity> (For instance).
<SpamapS> I never grouped things like that.. but I did make multi-tenant systems where IP was the method of separation .. not interface.
<SpamapS> Its far enough off from the generic case that I think its ok to just let people figure it out.. but "all static network interfaces are up" does seem better to wait for than "a network interface is up"
<slangasek> the latter does mean smbd will be up and ready to go sooner for users who don't have that particular scenario
<slangasek> but I'm not going to fight it if you go with the more conservative start rule
<SpamapS> problem is, this guy who started this conversation has a static IP via network manager, which the new event doesn't touch
<slangasek> hah
<SpamapS> and for good reason.. too hard to predict what n-m is doing. :p
<slangasek> yep
<SpamapS> For now I think we can just rely on smbd's robustness and not change anything yet
<slangasek> I've at least asked for a copy of the relevant config on the bug, so we can verify that it really only happens under the circumstances I've suggested (namely, 'bind interfaces only = yes' + 'interfaces = $IP')
<dupondje> mmmm did gnome-shell just break ?
<dupondje> segfaults here :(
<cjwatson> slangasek: yeah, as stgraber said, d-i already sets its own DHCP timeout
<bdrung> bambee: then it's not a problem of debuild. either your package fault or dpkg-buildpackage
<cjwatson> I wouldn't advise raising the netcfg default further, because it's synchronous and long timeouts annoy people without a DHCP server
<cjwatson> the current value is a compromise, already raised a bit from what's in Debian
<stgraber> cjwatson: yeah, I didn't know the timeout was configurable through debconf before. I now changed my default pxe settings for d-i to set it to 120s, that should fix my problem
<slangasek> cjwatson: oh yes, I wasn't intending to change any timeouts in netcfg, didn't realize that's what stgraber was referring to
<slangasek> I am bumping the timeout in isc-dhcp though
<stgraber> slangasek: I just mentioned that the 60s timeout was a bit short for me in d-i and that I wouldn't mind it being 120s but I can see that being annoying for quite a few users ;)
<slangasek> stgraber: yeah, a timeout in the installer critical path has a slightly different role :)
<bambee> bdrung: the package is kde-workspace, it's not a package fault. Already checked with downstream and upstream. The error comes from make itself
<bambee> the makefile is generated by cmake, it does not make sense
<bdrung> so it's a cmake bug?
<slangasek> -
<Apteryx> Hello, is commenting the patch in the file debian/series (quilt used as patching system) enough to prevent it being merged?
<Apteryx> I thought so, but pbuilder keeps failing on an already commented out patch!
<cjwatson> should be.  quilt(1) says: "Lines in the series file that start with a hash character (#) are ignored."
<cjwatson> perhaps your working tree is inconsistent in some way
<cjwatson> I would suggest checking that 'quilt pop -a' then 'quilt push -a' works, for starters
<Apteryx> cjwatson, I'll check this.
<DoctorPepper> hi guys !!!
#ubuntu-devel 2011-09-03
<cjwatson> Laney: is anyone working on nemerle?  last thing that build-depends on libmono-dev and so the last thing holding libmono-dev and libmono0 in oneiric ...
<Quintasan> Good morning
<bambee> bdrung: well, after some tests... parallel builing works when I build the package from source by hand (ie unpack && cmake && make -jN) , it does not work with dpkg-buildpackage... :\
<Laney> cjwatson: no, it has been broken by mono for ages. I guess we should remove the binaries.
<cjwatson> Laney: the binaries are already gone.  I suppose we could ignore that build-dependency and remove libmono-dev anyway, if you don't want to remove the source
<Laney> we occasionally tussle with upstream about it
<Laney> so yeah, I'd ignore it for those purposes. The next upload will have to get rid of it anwyay.
<cjwatson> OK, removed, thanks
<Laney> https://bugzilla.novell.com/show_bug.cgi?id=689533 for example
<ubottu> bugzilla.novell.com bug 689533 in misc "Nemerle Compiler self compiling crashes the runtime." [Critical,Reopened]
<bradm> nice error with oneiric, "gnome-session[4124]: CRITICAL: We failed, but the fail whale is dead. Sorry...."
<bdrung> tumbleweed: around?
<tumbleweed> bdrung: only just (global jamming, so I'm running around a lot trying to help people fix FTBFSs)
<bdrung> tumbleweed: i would like to release u-d-t 0.129
 * tumbleweed seems to remember something I had to do
<bdrung> tumbleweed: so the question: what is with your branch and bug #838361?
<ubottu> Launchpad bug 838361 in ubuntu-dev-tools (Ubuntu) "[syncpackage] downloads .dsc files into current directory" [Medium,New] https://launchpad.net/bugs/838361
<tumbleweed> that one, yes
<tumbleweed> that won't be specific to any branch of mine, it'll have been a problem, as soon as we added fakesync checking in cjwatson's branch
<tumbleweed> easy answer is chdir to /tmp somewhere, but that's obviously not right
<tumbleweed> yeah, fixing that properly is probably a bigger job than I have time for this after
<QMR> Why is empathy default IM client?
<bdrung> tumbleweed: and this MP: https://code.launchpad.net/~stefanor/ubuntu-dev-tools/syncpackage-close-bugs/+merge/72766 ?
<ubottu> Launchpad bug 72766 in Ubuntu "ethernet card was disabled after mainboard change" [Undecided,Invalid]
<bdrung> you failed, ubottu
<bdrung> tumbleweed: should i release 0.129 or wait for your changes?
<tumbleweed> bdrung: yeah I wouldn't want to merge that until I knew how launchpad was going to handle the bug closing
<tumbleweed> I suppose I could tame it to not parse changelogs, only close bugs provided on the command line
<bdrung> tumbleweed: yes, closing bug provided on the command line should be enough
<ScottK> doko_: Would you please retry guiqwt in the archive rebuild.  It should build now.
<ScottK> bdrung and tumbleweed: Except aren't LP bugs from debian/changelog currently closed on sync?  If I understand what you're discussing, that sounds like a regression.
<tumbleweed> ScottK: it is indeed a regression, but it'll be fixed RSN
<ScottK> OK.
<tumbleweed> we thought we were going to have to fix it client side, but launchpad is moving faster than we thought
<shnatsel> cjwatson: thanks for fixing the Germinate bug so swiftly!
<shnatsel> cjwatson: also, I've written two simple scripts that ease maintenance of Germinate lists in simple cases: https://code.launchpad.net/~shnatsel/ubuntu/oneiric/ubuntu-meta/tools (I'm pretty sure I'm not the first one to do it, but I couldn't find any)
<dupondje> what app exactly takes care of backlight ?
<dupondje> seems to be some bug in it :)
<bdrung> tumbleweed: there are typos in there which i will fix when merging it :)
<tumbleweed> sorry :)
<bdrung> np
<dupondje> anyone ? :D
<tumbleweed> dupondje: it's also irritating me, I haven't looked for bugs yet. I'm guessing gnome-power-manager / upower / gnome-screensaver is to blame
<cjwatson> shnatsel: um, I think you have it backwards - the files in ubuntu-meta are *output* files produced by germinate-update-metapackage
<cjwatson> shnatsel: they're changed by changing the seeds and then running the ./update script in ubuntu-meta
<shnatsel> cjwatson: cool. What's the input then? XD
<cjwatson> seeds, see 'man germinate'
<dupondje> tumbleweed: what issue do you have exactly ?
<cjwatson> lp:~ubuntu-core-dev/seeds/platform.oneiric lp:~ubuntu-core-dev/seeds/ubuntu.oneiric etc.
<tumbleweed> dupondje: backlight goes off before the screensaver starts, can't turn it on until I've logged in again
<shnatsel> cjwatson: lol. Thanks for clarification! Dropping the branch.
<cjwatson> you're welcome
<bdrung> tumbleweed: syncpackage bug closing works. tested with ubuntu-dev-tools ;)
<tumbleweed> heh, thanks
<dupondje> tumbleweed: other issue here. When I set backlight very low, it goes higher (clearer) with inactivity
<cjwatson> shnatsel: erm, seeds -> ubuntu-seeds in the above branches
<tumbleweed> dupondje: that's been an issue for ages (again, no idea about filed bugs)
<dupondje> first time I notice it ... weird :
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/221475
<ubottu> Launchpad bug 221475 in gnome-power-manager (Ubuntu) "Brightness increases higher than settings" [Low,Confirmed]
<dupondje> god ... :D
<bdrung> tumbleweed: should i wait for bug #838361 or can i do the upload?
<ubottu> Launchpad bug 838361 in ubuntu-dev-tools (Ubuntu) "[syncpackage] downloads .dsc files into current directory" [Medium,New] https://launchpad.net/bugs/838361
<tumbleweed> bdrung: I'm currently quickly hacking on the harvest thing
<bdrung> k
<tumbleweed> and I think the UnicodeDecodeError thing in submittodebian is worth doing
<bdrung> k, do that
<YokoZar> Is vmware easy-install a supported case or is that vmware's proble
<YokoZar> *problem?
<dupondje> tumbleweed: ok fixed my bug :D
<tumbleweed> bdrung, cjwatson: +localpackagediffs thinks libsdl-sound1.2 is blacklisted, any idea why?
#ubuntu-devel 2011-09-04
<exobuzz> erm - i386 	8 	598 jobs (11 hours)  holy cr*p that's a bit queue. have some of the builders been taken off to do something else ?
<exobuzz> only 3 amd64 and 5 i386 builders. :(
<StevenK> exobuzz: Yes, they are dealing with kernel SRUs.
<exobuzz> i see.
<exobuzz> thanks for the info.
<apw> have the archive keys changed for onieirc?  getting BADSIG all of a sudden on 'update'
<cjwatson> apw: not as far as I know
<cjwatson> might be transient Release vs. Release.gpg skew?
<apw> cjwatson, yeah i'll monitor it for a bit and see if it goes away ..
<cjwatson> we probably ought to roll over the keys to something stronger at some point, but it's not currently planned
<and7ey> Hi all! Need your help to compile openzwave-control-panel (http://code.google.com/p/openzwave-control-panel/source/browse/) Ubuntu 10.04. Now I am getting an error that file is not found - http://askubuntu.com/questions/59972/how-to-compile-openzwave-control-panel-on-ubuntu-10-04
<and7ey> how can I fix the following error: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
<and7ey> what should I install to get rid of the following error: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."  ?
<Chipzz> and7ey: this is not the correct channel to be asking these questions in; the topic specifically mentions "not app development"
<Chipzz> and the package you're missing is probably libtool or autoconf or somesuch
<and7ey> Chipzz: ok
<shnatsel> hello everybody
<shnatsel> would anybody point me where can I get the code for building images from seeds?
<sladen> shnatsel: -> #launchpad  might be able to point you to the specific code
<shnatsel> sladen: thanks!
<shnatsel> sladen: I've been looking for something I could run locally, actually :)
<sladen> shnatsel: I must say, my mind has gone completely blank about how this stuff works at a low-level anymore
<sladen> shnatsel: https://help.ubuntu.com/community/InstallCDCustomization  might offer some guidance
<shnatsel> sladen: that's a good sign. That's a sign of progress and ease of development :)
<sladen> shnatsel: if not, check about in 24 hours when the Monday-Friday people will be around
<shnatsel> sladen: thanks!
<shnatsel> sladen: that wiki page describes lots of manual ways to do it, I tried lots of them in the past and ended up using UCK. But I know Ubuntu uses something simple and automatic that parses seeds, so I'm looking for it :)
<shnatsel> sladen: I think I'll write some documentation as soon as I find it
<jtaylor> doko__: now that pari built on arm genus2reduction should build too
<Florian> hello, I have a question about building a package using bzr bd
<Florian> I created a patch using dquilt and refreshed, but when I issue bzr bd -- -S --us -uc it complains about not finding the patch file
<Florian> Is there something I forgot?
<Florian> the error I got was: "dpkg-source: error: cannot read monster-masher-1.8.1.orig.dVBshx/debian/patches/add-esound-as-dependency.patch: No such file or directory"
<jelmer> Florian: is the patch file versioned?
<Florian> what exactly do you mean? I did add the dquilt patch according to the debain maintainer guide http://www.debian.org/doc/manuals/maint-guide/modify.en.html
<jtaylor> did you commit the patch? you ahve to do bzr add patch-file
<jelmer> Florian: if you run "bzr st" the patch should be listed as "added" rather than "unknown"
<Florian> jelmer, the patch is listed as unknown: unknown:
<Florian>   .pc/.quilt_patches
<Florian>   .pc/.quilt_series
<Florian>   .pc/add-esound-as-dependency.patch/
<Florian>   debian/patches/add-esound-as-dependency.patch
<jelmer> Florian: you should be able to add it by running "bzr add debian/patches/add-esound-as-dependency.patch"
<Florian> thanks, that did it!
<highvoltage> stgraber: this one: https://bugs.launchpad.net/ubuntu/+source/speechd-up/+bug/316511
<ubottu> Launchpad bug 316511 in speechd-up (Ubuntu) "udev rule is almost certainly wrong" [Critical,Confirmed]
<shbk> hello, I've found function   man 2 getcpu.  I included it successful, but when I compile I receive error: no such function. I opened file  /usr/src/linux-headers-2.6.32-33/include/linux/getcpu.h  and noticed that there are not any description of funcition, only this http://paste.debian.net/128405/    . what is this ? there is function?
<mdke> pitti: sorry for being a pain, but please could you take a look at bug 841340 some time in the next couple of weeks, it will be needed to reenable stripping of documentation translations into the language packs for oneiric
<ubottu> Launchpad bug 841340 in pkgbinarymangler (Ubuntu) "Needs to strip translations from /usr/share/help" [High,New] https://launchpad.net/bugs/841340
<Apteryx> Hi!
<Apteryx> Could someone help me figure out how the build process works for the pulseaudio package? I'm trying to package 0.99.3 (instead of the 0.9.22 currently available), and am stuck on how quilt is used in the process.
<TheMuso> Apteryx: What version of Ubuntu are you trying to package for?
<Apteryx> TheMuso, I'm using Ubuntu 11.04 natty (32 bits).
<Apteryx> and packaging for it.
<TheMuso> Apteryx: Ok. The way quilt is used in the pulseaudio package is actually part of the source package format. Version 3.0 of the source package format uses quilt as the patch system, so the packager themselves do not need to include quilt commands in the rules file, or in the build dependencies.
<TheMuso> So when you unpack a source format 3 package with patches included, these patches automatically get applied.
<Apteryx> TheMuso, but for pulseaudio I don't think they are using format 3.0
<Apteryx> There was nothing in ./debian/source/
<Apteryx> So when building there was only a warning stating it was going to use 1.0
<TheMuso> Apteryx: Yes you are correct, the natty pulse package is not source format 3, and uses quilt in the rules file and is a build dependency.
<Apteryx> TheMuso, in the ./debian/rules file I tried to understand the "update-patch-series" target. They are using git format-patch to produce the series file (which I thought was processed by quilt).
#ubuntu-devel 2012-08-27
<BenC> Laney: I'll check on it
<BenC> Laney: hopefully that failure is something stupid like endian issues
<darkxst_> jbicha, any idea where I can file a bug against gdm off ricotz ppa?
<jbicha> darkxst_: you can go ahead and file against gdm, once we get the bugs worked out, I'd like to upload the newer gdm into ubuntu and filing that bug helps
<darkxst_> jbicha, ok
<darkxst_> jbicha, with a trivial patch and can now boot into gdm ;)
<jbicha> darkxst_: cool!
<jbicha> darkxst_: the other two major bugs we have are: broken locale support and the keyring doesn't get auto-unlocked
<darkxst_> jbicha, yeh I noticed the keyring thing
<jbicha> I'm guessing we should look at the PAM code for that
<darkxst> jbicha, looks like it is using the autologin pam profile
<darkxst> when it probably should be using /etc/pam.d/gdm (for password login)
<pitti> Good morning
<darkxst> jbicha, however when I change to the correct pam profile, gdm breaks ;(
<jbicha> darkxst: well that might not be it. What I was referring to is that upstream now ships 3 different PAM profiles
<jbicha> and the current Ubuntu profile is slightly different than the Debian one but I don't understand the GDM/PAM stuff
<jbicha> http://git.gnome.org/browse/gdm/tree/data
<darkxst> jbicha, yeh, and the debian packaging is using the gdm-autologin profile
<darkxst> jbicha, I think I fixed it
<darkxst> jbicha, you need to create another link in gdm.postinst
<darkxst> ln -s gdm /etc/pam.d/gdm-password
<darkxst> jbicha, I have to run, filed this https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1042052
<ubottu> Launchpad bug 1042052 in gdm (Ubuntu) "gnome keyring auto-login failure" [Undecided,New]
<dholbach> good morning
<dholbach> ogra_, would it be possible for you to swap with bilal on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable?
<tumbleweed> dholbach: can bilal make later on wednesday (ideally, I'd like to swap too, something came up on wednesday evening. an earlier slot or different day would be great)
<dholbach> tumbleweed, no bilal can only make Tuesday
<tumbleweed> ah, never mind then
 * tumbleweed will survive
<bilal> I'll be unavailable throughout Wednesday and Thursday
<dholbach> ivoks, happy birthday! :)
<ogra_> dholbach, i would have answered the mail if i could ... :)
<dholbach> ah ok, yes - you were CCed
<ogra_> (i got teh same meetings as barry)
<dholbach> I'm sure slangasek would understand, if you missed one and gave somebody else your notes :)
<ivoks> dholbach: thanks :)
<bilal> dholbach: so that leaves us with mterry, right? let's see if he agrees
<ogra_> dholbach, apart from the fact that i have to write up a summary of the meeting for the release meeting on friday, yeah :P
<dholbach> ogra_, there's always the logs and it'd give you an extra day to prepare your session :)
<ogra_> haha, you wont convince me :)
<dholbach> can somebody help me reject a few merge proposals?
<dholbach> can somebody please reject the following merge proposals? http://paste.ubuntu.com/1169455/
<pitti> dholbach: erledigt :)
<dholbach> danke pitti
<dholbach> pitti, do we have a tool which tells us if a source package can be safely removed? (check all packages if they're a depends or build-depends somewhere)
<hsn> what can i do for help translating ubuntu?
<pitti> dholbach: there is checkrdepends in ubuntu-archive-tools, but it needs a mirror to work with
<dholbach> ah ok, thanks pitti
<pitti> dholbach: there is reverse-depends and reverse-build-depends in ubuntu-dev-tools, but I guess they only check the architecture you are running on, not all of them
<dholbach> thanks
<dholbach> pitti, updated https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
 * ogra_ curses launchpad 
<ogra_> *LOUDLY*
<ogra_> thats the third time i file a bug today and end up at the error page ...
<ogra_> with all my input lost :(
<dholbach> pitti, did you get some bug reports about apport using 100% cpu for an extended period of time?
<Sweetshark> ogra_: cursing doesnt help, do the angry-old-man-fistshake!
<ogra_> heh
<ogra_> well, it helped to file bug 1042151
<ubottu> Launchpad bug 1042151 in libdri2 (Ubuntu) "MIR: libdri2 needs to be in main for pvr-omap4 (restricted) to build" [Undecided,New] https://launchpad.net/bugs/1042151
<ogra_> pitti, btw, the component-mistmaches tool that sends the reports to ubuntu-release doesnt seem to take restricted build-deps into account, is that on purpose ?
<Sweetshark> ogra_: http://www.sherv.net/cm/emo/angry/angry-old-man-smiley-emoticon.gif <- threaten lp with that
<ogra_> LOL
<pitti> erk, DSL reconnect
<pitti> dholbach: wiki> thanks
<pitti> dholbach: apport 100% cpu> not recently; can you reproduce it?
<pitti> ogra_: it's meant to consider restricted
<dholbach> pitti, it's happening right now and happened some days ago too
<dholbach> pitti, I can give you the logs and the crash file it's currently working on (at least according to lsof)
<pitti> dholbach: which process in particular is using the CPU? (check in top)
<pitti> dholbach: something called from a hook, or apport-gtk itself?
<dholbach>  /usr/bin/python3 /usr/share/apport/apport 2662 11 0
<pitti> oh, that part, it's still crashing
<dholbach> what do you want me to do? :)
<pitti> most of the activity is usually due to compressing core dumps; what crashed exactly?
<pitti> dholbach: can you strace it and check if it's still reading data?
<pitti> if it doesn't read anything but burns CPU, attaching gdb to it and seeing where it's currently stuck might help, too
<pitti> if the core dump is huge, compressing it will take a bit, but that's the only thing I'm aware of
<pitti> if it's stuck somewhere else, I'm interested in fixing that
<dholbach> I guess the core dump was huge and it just finished and redirected me to (https://launchpad.net/bugs/929219)
<ubottu> Launchpad bug 929219 in gwibber (Ubuntu Precise) "chromium-browser, gvfsd-http and others using eglibc crash with SIGSEGV in __nscd_get_mapping() or gethostbyname2_r()" [Undecided,New]
<dholbach> but it took like 10-15 minutes at the very least on a quad-core machine with SSD disk
<dholbach> sounds a bit weird
<pitti> how big is the .crash?
<dholbach> 29M
<pitti> ok, that's not exactly small; I'll take a closer look once the bug gets retraced and I can access it
<pitti> there might be a way to speed it up somehow, python's zlib might be much slower than calling gzip and piping
<dholbach> ok
<pitti> dholbach: oh, this bug -- LP timed out
<pitti> dholbach: oh, this bug -- LP timed out
<pitti> sorry, EFOCUS
<tumbleweed> everyhting seems to timeout these days :/
<ogra_> micahg, seeing the xubuntu build failures you might want the same seed change lubuntu-meta got recently
<ogra_> or mr_pouit ^^^
<doko> hmm, any qmake exports online?
<Sweetshark> moin all!
<Sweetshark> seb128: can you unconfuse me about source package clucene-core? there is a version 2.3.3.4-2 in debian but an autosynced 0.9.21b-2 in quantal. how is that?
<seb128> Sweetshark, http://packages.qa.debian.org/c/clucene-core.html
<seb128> unstable
<seb128>     save 0.9.21b-2
<seb128> sorry about the "save", select fail
<seb128> Sweetshark, we don't think from experimental by default
<Sweetshark> seb128: ah, doh - the debian package pages are even more confusing than lp. I took a wrong turn and got diverted to experimental.
<seb128> Sweetshark, I've a bookmark with a keyword on "http://packages.qa.debian.org/%s"
<seb128> so I can just "debsrc <source>" in my firefox and get to the summary page
<seb128> the pts pages are easy to ready and have most of the infos you need
<Sweetshark> seb128: so debian uses system clucene now: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661703 -- shall I continue to use the internal clucence copy (Im doing that now, but it makes the package bigger obviously) or shall we try to FFE clucene from experimental?
<ubottu> Debian bug 661703 in clucene-core "clucene-core: upload latest clucene git + contrib-libs to experimental" [Normal,Fixed]
<xclaesse> upgrades should *really* remove old kernel images and headers
<xclaesse> this weekend I had to fix my mother's computer: a 15G / partition full for a simple ubuntu installation (initial install was some years ago)
<xclaesse> reason: kernel images and headers accumulated (since 2.6.24) was taking ~9G
<seb128> Sweetshark, go for the ffe I guess
<xclaesse> seriously, it still had 2.6.24 kernels on a Precise system...
<seb128> xclaesse, yeah, it's a known issue (and surprisingly hard to get resolved) :-(
<xclaesse> seb128, it happened exactly 0 times to need an older kernel
<xclaesse> in all my ubuntu experience
<xclaesse> the package could just replace the previous one
<xclaesse> that should be trivial, no?
<xclaesse> (well, being a dev as well, I know things that seems trivial aren't :)
<ricotz> xclaesse, replacing the previous kernel is a *bad* idea!
<seb128> xclaesse, well, if there is a bug for your hardware on the new kernel one day you will be happy to have an old kernel to boot
<ricotz> xclaesse, seb128 a simple sweep-tool suggesting to remove *ancient* kernels of previous ubuntu release would be reasonable though
<Bluefoxicy> blah.
<Bluefoxicy> https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/1042194
<ubottu> Launchpad bug 1042194 in libmtp (Ubuntu) "MTP + Nautilus fails with a lot of files on device" [Undecided,New]
<Bluefoxicy> probably a duplicate of something, since there's 10 million MTP bugs listed in launchpad but none look quite like what I'm looking for
<Bluefoxicy> they're all like "Cannot use X device" or "cannot write files to Sony walkman"
<Sweetshark> seb128: https://bugs.launchpad.net/ubuntu/+source/clucene-core/+bug/1042192
<ubottu> Launchpad bug 1042192 in clucene-core (Ubuntu) "[FFE] new clucene version needed for LibreOffice" [Undecided,New]
<micahg> pitti: dholbach: reverse-depends and reverse-build-depends at least in 12.04+ should query ubuntuwire and check all archs AIUI
<dholbach> ah cool
<Laney> excuse me while I repeat my question from #-release yesterday
<Laney> to update P-a-s, do we just push to lp:~ubuntu-core-dev/packages-arch-specific/ubuntu?
<Laney> is there some workflow to sync it with Debian or something?
<jamespage> Laney, I'm pretty sure that is the right branch - P-a-S syncs periodically from it from memory
<Laney> I think I remember some weird workflow but I'm not sure
<Laney> https://wiki.ubuntu.com/PackagesArchSpecific
<mterry> ogra_, hello!  So this dri2 MIR: you mention it's a split out copy from mesa, but it doesn't look like it's the same content as the other dri2.c files in mesa?  (forgive me, I'm not super familiar with graphic drivers)
<ogra_> i dont think its a 1:1 code copy, no
<mterry> ogra_, OK.  And it's a separate upstream?  Like a fork of the code or something?  Why use this instead of mesa's libs?
<ogra_> there are no libs in mesa for dri2 atm, thats the point :)
<ogra_> everyone accesses it differently
<ogra_> this is an attempt to unify
<mterry> ah
<mterry> and the hope is that mesa would use it in the future?
<mterry> or at least various drivers (like the arm one does apparently) use it
<ogra_> mterry, http://paste.ubuntu.com/1169816/
<ogra_> rob is the upstream (thats also on irclogs.u.c in the #ubuntu-arm channel from 23rd if you want to see more context)
 * mterry reads
<mterry> k
<hrw> hi
<mterry> mvo, hello!  Btw, that phased-updates branch does still have an error in it on i386 branches.  I had told you that it didn't, but that's only when running nosetests3 directly on it.  If you run nosetests3 on the suite, previous tests that instantiate MyCache, which inits the apt_pkg system seem to mess one of your tests up
<hrw> I added debdiff to fix aptitude bug 824708 for precise. Can someone take a look at possible SRU?
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "aptitude can no longer show changelogs: "Changelog download failed: Download queue destroyed." Please merge the fixed version, 0.6.8, from Debian." [Medium,Fix released] https://launchpad.net/bugs/824708
<mterry> mvo, because the apt_pkg system is initialized with i386 and then later you try to use amd64, but it's ignored
<bdrung> kengyu: have you heard of wrap-and-sort?
<kengyu> bdrung, no. (sorry for the author) :-)
<bdrung> kengyu: now you have. ;) i recommend to use it :)
<kengyu> bdrung, yes, I will definitely try it. :-)
<bdrung> kengyu: http://lintian.debian.org/full/kengyu@lexical.tw.html
 * bdrung pressed crtl+w in the wrong window.
<smoser> cyphermox, around?
<cyphermox> smoser: yup
<smoser> i've just rebooted this system, logged back in, and busted resolv.conf
<smoser> (you helped me before with https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1034946)
<ubottu> Launchpad bug 1034946 in network-manager (Ubuntu) "dnsmasq and network manager broken if dnsmasq package has 'enable-dbus'" [Critical,Fix released]
<cyphermox> smoser: check if it's the same as https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1042275
<ubottu> Launchpad bug 1042275 in dnsmasq (Ubuntu) "dnsmasq updating resolvconf when it's not configured to do DNS" [Medium,Confirmed]
<cyphermox> basically, you'd see 127.0.0.1 in /etc/resolv.conf
<smoser> yes
<smoser> i do have dnsmasq installed
<smoser> just a bit of fyi, lxc installs: /etc/dnsmasq.d/lxc
<smoser> http://paste.ubuntu.com/1170081/
<smoser> anyone else with a second display running current unity in quantal?
<smoser> i can' make "auto hide the launcher", "sticky edges" or "launcher placement" work. it wont hide, appears on all displays, and i have that annoying sticky edges.
<smoser> cyphermox, so you're telling me "disable" ?
<cyphermox> smoser: I can test the dual display in a second (need to take my laptop because if i upgrade this system it might break)
<cyphermox> smoser: no, I'm telling you if it's the same thing we need to figure out why dnsmasq writes that file out when it really really shouldn't :)
<cyphermox> as a workaround you could disable the system dnsmasq, or the one from network-manager if the system one is properly configured
 * cyphermox is starting to dislike dnsmasq
<smoser> cyphermox, thanks.
<smoser> cyphermox, well, disabling the system dnsmasq makes my current pain point go away.
<cyphermox> yeah it's just not optimal if you need it ;)
<ogra_> infinity, did the branch for livecd-rootfs move or did colin actually not commit his changes
<infinity> ogra_: Eh?  Looks committed to me.  Or did you just do that?
 * infinity checks the log.
<infinity> revno: 602
<infinity> tags: 2.76
<infinity> committer: Colin Watson <cjwatson@canonical.com>
<infinity> branch nick: livecd-rootfs
<infinity> timestamp: Thu 2012-08-23 11:10:28 +0100
<infinity> message:
<ogra_> well, do i use the wrong branch ?
<infinity>   releasing version 2.76
<infinity> ^-- After that is a commit from you, so you clearly know where it lives. :P
<infinity>   checkout of branch: bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/
<ogra_> hmm, right, wrong local branch
<dobey> is errors.ubuntu.com broken?
<ogra_> works here
<dobey> ogra_: the list of all the errors loads too?
<ogra_> ah, no
 * ogra_ tries https://errors.ubuntu.com/?launchpad=false
<ogra_> aha
<ogra_> that seems to work
<ogra_> ev, ^^^
<dobey> hrmm
<ogra_> evil weather indicator
<dobey> evil errors reporting apparently mixing up version information :-/
<smoser> anyone else using xchat on quantal?
<smoser> the scrolling seems screwed up for me after last update
<smoser> by scrolling i mean grabbing the overlay scroll bar
<trism> did the compression options change on the quantal iso squashfs? I'm only getting ~4% complete on an iso from 2 days ago
<trism> with zsync that is
<trism> oh sorry, must have been a weird build on the weekend, an older iso is ~53%
<Laney> yeah, there was some slight bustage there
<roaksoax> jdstrand: howdy!! So I'm finishing up the packaging of the cobblerless maas, and I was wondering a few, security related things. 1. MAAS needs to be able to restart a service, so I was thinking to add maas to sudoers, is that a good approach? 2. MAAS needs to write files under both, etc/bind, /etc/dhcp/, What wuold the best approach to do so be? (maas runs as its own user/group)
<Laney> dobey: what's the point of those u1 uploads you just did? They don't appear to have any changes ...
<dobey> Laney: scheduled releases for beta1 freeze target
<micahg> dobey: releases for the sake of releasing seems pointless
<micahg> at least for a beta
<Laney> and it uses buildd time and bandwidth
<micahg> ah, I was mistaken then, not pointless, wasteful :)
<dobey> it's not releases for the sake of realasing. it's to keep our suite of projects the same version across the board so it's easier to support
<micahg> it's still doesn't make sense from the distro side of things (especially for a beta), I could see doing it for a final release though if that's what will be shipping in quantal at release
 * micahg isn't saying you can't do it, just that it seems to not make sense
<slangasek> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev, slangasek
<slangasek> ev: are you still piloting? :)
<ia> Hello. Probably this channel not for my question, but I take a chance. Let's say I have a hardware with cpu CPUNAME; If I want to compile C/C++ app for this, then I'm doing something like gcc -march=CPUNAME and it works. But how can I do cross recompilation of some existing deb package [from official ubuntu repo] for such CPUNAME? I guess, that should exist some [auto] tools for this, so when ubuntu dev team preparing packages for arm,x86 and x86-64 from the
<ia>  same sources/packages, they probably don't do all those stuff by hands. So I will be very appreciate for pointing me to any relevant direction for solution of this issue. Thanks.
<slangasek> ia: DEB_CFLAGS_APPEND=-march=CPUNAME dpkg-buildpackage -uc -us -B
<slangasek> this is not guaranteed to work for all packages; but it is the standard interface
<slangasek> and if it doesn't work, you can file a bug on the package (preferably in Debian)
<slangasek> ia: however, this is entirely unrelated to how packages are prepared for different architectures.  *that* is done by native compilation on the target architecture, using a gcc that outputs binaries for the target machine by default.
<ia> slangasek: right. I forgot about detail - let's say we need not only flag, but another CC value - instead of gcc something like ARCH-gnu-linux-gcc, then what?
<slangasek> ia: then for that, you want dpkg-buildpackage -a$arch, where $arch is an architecture name which is known to dpkg and which has a correct mapping to the GNU triplet you need
<slangasek> dpkg-buildpackage -a$arch is how you cross-compile.  Support for cross-compilation is much, much less complete in the Ubuntu archive compared with support for DEB_CFLAGS_APPEND
<ia> slangasek: very interesting, thank you; one more question - what about automation? let's say I want to do it not only with one package, but with all packages from 'main' part of repository - I guess, that somehow I should use apt-build? Any working recipes for such case?
<slangasek> ia: there are several tools for archive autobuilding; xdeb is one intended specifically for in-place cross-bootstrapping of a port
<slangasek> if that doesn't meet your needs, Ubuntu uses sbuild for the building and launchpad for the build scheduling; and Debian uses sbuild+wanna-build.
<slangasek> the hard part is figuring out which packages to build in what order for purposes of bootstrapping.  There's been some Google Summer of Code work in Debian around that this year, but the results haven't yet been incorporated into the mainline tools AFAIK
<ia> slangasek: interesting and useful information, thanks again. BTW, I think that it will be cool to see some articles (at wiki.ubuntu, for example) with detailed instructions how exactly ubuntu dev team is building packages - from upstream/debian sources to iso generation for misc. arch's, so anybody can repeat it; I think that it will be very interesting and useful for advanced users/developers. Probably somewhere such information is available already, but I
<ia> can't google it easily
<slangasek> ia: most of the things you're asking about aren't related to how Ubuntu themselves are building packages, and are in such rough form that they're not interesting to document at this stage :)
<jdstrand> roaksoax: hmm, sorry for the delay. I need to think about that. Can you send an email to security at ubuntu.com for what you are thinking you'd like to do?
<roaksoax> jdstrand: will do! Thanks!
<roaksoax> :)
#ubuntu-devel 2012-08-28
<darkxst_> jbicha, gdm reads locale from /etc/default/locale, but that is always en_US
<darkxst_> jbicha, if you change the locale in that file, gdm will load in another language fine
<jbicha> darkxst_: settings a different language works here, are you using ricotz' latest gdm from ~8 hr ago?
<darkxst_> jbicha, umm, so what was broken then?
<darkxst_> or is it fixed
<jbicha> darkxst_: I think the pam symlink fixed that too
<darkxst_> jbicha, ah cool!
<darkxst_> ubuntu works suprisingly well in a VM except gdm (and lightdm) are always at 640x480
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch
<slangasek> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
<bkerensa> stgraber: do you plan to get another landscape-client update in before Wednesday?
<_ruben> good morning xnox, i understood you're the (software) raid expert? :)
<xnox> _ruben: in a way, yes. Go on =)
<_ruben> xnox: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1020914 .. got some workarounds that "work", but looking for a clean solution
<ubottu> Launchpad bug 1020914 in mdadm (Ubuntu) "The disk drive for /boot is not yet ready or not present" [Undecided,New]
<_ruben> 2 disks, each disk has 2 partition, which has 2 mdadm volumes on top, one for /boot (ext2) and the other using lvm for the rest of the system
<xnox> _ruben: can you please install mdadm from precise-updates? =)
<_ruben> at boottime it gives the not yet ready message and allows me to enter the recovery shell
<xnox> _ruben: it has 3.2.5-1ubuntu0.2
<_ruben> i have 3.2.5-1ubuntu-0.2 installed
<_ruben> (not from -proposed tho)
<xnox> ok. bug report said Package: mdadm 3.2.3-2ubuntu1
<_ruben> ah yeah, i've done some updates in the meantime
<xnox> oh. ok.
<_ruben> its up to date as of yesterday
<_ruben> bug was created right after clean install a while ago, upgrade didnt fix it tho
<_ruben> the only "working" solution so far is adding nobootwait to fstab and doing a mount -a in rc.local
<_ruben> adding wait_for_udev to the initramfs mdadm script doesn't do anything (afaics)
<_ruben> xnox: when i do a strace mountall in the recovery shell, it doesn't show any signs of /boot and ends up hanging at a select() call .. if i mount /boot and then run mountall, booting continues (but in an odd state as mountall stays lingering about)
<_ruben> like it's waiting for an event to fire or smth like that
<xnox> if I am reading this right the events for the later partitions e.g. sd[a|b][3|4] didn't fire quick enough
<xnox> maybe because they are towards the end of the disk?
<xnox> I am pondering if a "better" "workaround" is to specify rootdelay parameters and set it to a high value e.g. 120 seconds
<xnox> _ruben: why is raid towards the end of the disk?
<_ruben> http://pastebin.ubuntu.com/1171271/
<_ruben> xnox: first 2 partitions are dell recovery
<xnox> _ruben: why is it 2 raids, instead of 1 partinionable raid.
<xnox> ?
<_ruben> xnox: that'd be old habit
<xnox> =)))))
<_ruben> does d-i even support partitionable raid (never really tried)
 * xnox probably not =))))
<dholbach> good morning
<_ruben> mornin
<xnox> dholbach: aloha =)
<dholbach> hey hey :)
<_ruben> xnox: i wonder why swap, / and /var/log do mount properly tho, those are on lvm tho
<xnox> _ruben: once md is up, udev fires and LVM volumes come up very quick, even on like external drives.
<xnox> those are not a problem =) ever.
<xnox> (tm)
<_ruben> so a lv comes up faster than a ext2 voluem?
<_ruben> i'd expect the latter to be "simpler" :)
<_ruben> xnox: where would i put those rootdelay params? willing to try anything ;)
<xnox> _ruben: it's a kernel / boot parameter "quiet splash rootdelay=120"
<xnox> either in /etc/default/grub & update-grub
<xnox> or simply in the grub menu with edit functionality
<_ruben> not ready yet ... wonder if it'll go on after 2 minutes
<_ruben> still not ready, seems rootdelay isn't gonna help here
<_ruben> this is odd, hitting M for manual recovery makes it continue to boot, but no recovery shell
<_ruben> and no mounted /boot either
<_ruben> xnox: heh, hitting M within those 120secs does give a recovery shell
<xnox> _ruben: now this is peculiar. and I bet cannot be reproduced in a VM?!
<_ruben> xnox: i could give that a try .. creating a vm with 2 similar sized extra partitions before the actual used ones
<xnox> _ruben: if boot is not ready, where does it take initramfs from?! so it is readable, but not assembled/synced?! I'll need to think about that one a bit more
<_ruben> xnox: perhaps grub reads off the raw disks and not the raid?
<xnox> _ruben: please try, that would be a massive help, if it is reproducible in a VM.
<xnox> _ruben: well... new enough grub understands md raid, but I don't know how knew  our grub is
<stgraber> bkerensa: no. I'm not maintaining that package, the landscape team is. I just happen to be the last uploader for it.
<_ruben> crap, lets create a 2-disk vm, not single disk :P
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ev> slangasek: nope :)
 * dholbach hugs ev
<xnox> ev: just a day and a bit later =)
<xnox> stgraber: how big is ltsp-* bits and bobs =)
<xnox> s/is/are/ ?
<xnox> stgraber: looking at edubuntu my understanding was that it's dvd because of all the education packages, not because of ltsp.
<stgraber> xnox: not terribly big, however they bring thing like isc-dhcp-server, tftpd-hpa, openssh-server, ...
<xnox> =/ guk
<stgraber> xnox: well, as I just replied to ubuntu-devel, Edubuntu DVD also contains a 500MB LTSP squashfs on top of the main squashfs ;)
<stgraber> because we want to have an i386 LTSP squashfs when installing on amd64 systems
<stgraber> alkisg's trick is really nice, but only works when your server is the same architecture as your clients, which isn't that often true in the LTSP world (most clients are old intel atoms at best, servers are usually big SMP systems with a lot of memory)
<xnox> stgraber: /me w
 * xnox waits 30s to see the follow-up to the follow-up
<xnox> I see.
<xnox> shipping a hybrid 32/64 bit is a no-go for ubuntu-desktop cd
<stgraber> right :)
<xnox> so the only path here is ubiquity with mdadm support
<stgraber> Edubuntu is great for that, we have plenty of space, the only concern at the moment is really the lack of RAID support in ubiquity as we'd usually point these users to the alternate media and with dropping it, wouldn't have anywhere to point them to
<stgraber> anyway, I have to run to the airport... talk to you later
<xnox> stgraber: yeah, i was wondering why are you up?!
<xnox> =)
<xnox> take care
<stgraber> hehe, yeah, having a flight at 7:30am does that to you ;)
<_ruben> xnox: install completed .. performing first boot .. fingers crossed :P
<_ruben> bugger, it boots just fine :/
<xnox> _ruben: yeah, VM hardware comes up instantly hence you don't get the bare metal experience.
<_ruben> xnox: indeed
<hrw> what is a proper way of fixing ftfbs for packages which just need rebuild? like lot of those haskell packages which ftfbs because of transition and build now
<hrw> ghc-mod for example builds but is listed as ftfbs
<_ruben> xnox: any other ideas you can think of?
<xnox> hrw: are those next in the queue? see http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<xnox> hrw: if you are sure they are, I can retry them. Strahnge I don't see ghc-mod on the list... is that the source package name?
<hrw> xnox: yes, its source name
<hrw> xnox: git-annex is other one
<iulian> hrw: Where do you see ghc-mod listed as FTBFS?
<xnox> _ruben: I've confirmed the bug and added it to the reliable raid spec for me to look at later. Busy with ubiquity right now ;-)
<iulian> The transition is almost over now. Just a few more rebuilds to go and we're done.
<hrw> xnox: github-backup, haskell-hledger-web also
<hrw> iulian: http://qa.ubuntuwire.com/ftbfs/ and https://launchpad.net/ubuntu/+source/ghc-mod
<xnox> hrw: ok, i've requeued i386 of ghc-mod, if that will be fine, I'll requeue other arches.
<hrw> xnox: thanks
<_ruben> xnox: ah, ok. i'll get on with the current workarounds active and continue this deployment. i'll likely have another set of 2 pretty similar boxes to be deployed soon. those will probably behave the same (i'm seeing this on 2 nearly identical boxes)
<xnox> _ruben: *sigh*
<xnox> hrw: ghc-mod: i386 success, amd64/powerpc requeued, arms are dep-wait anyway.
<xnox> hrw: git-annex: i386 re-queued
<Laney> xnox: hrw is motu and could have done this himself
<Laney> teach a man to fish ...
<Laney> ps. good morning
<xnox> Laney: good morning. I requested rebuilds myself from somebody the other day. Little did I know I can do it myself as a core-dev. =)
<xnox> Laney: plus this is my first time clicking that button! Exciting =)
<hrw> Laney: I asked which way would be proper and xnox said that this is part of transition and handled queue
<Laney> hrw: I know, I was suggesting that him showing you how to do it instead of doing it for you would have been more profitable
<xnox> hrw: tbh. Well my assumption was wrong =)
<Laney> as you'd have been able to learn
<Laney> (also, for these a retry is only good if it never built on any arch, as the others will need rebuilding anyway)
<hrw> Laney: I suspect that 'press rebuilt button for i386|amd64' was easiest answer
<xnox> hrw: that's what I did, after verifying.
<hrw> btw: bug 1028761 is ~fine to go or would require FFE?
<xnox> Laney: I checked that build-deps were uninstallable in the build-log. Did not suceed to build on any arch. Did i386 first, wait for it to succeed, then requeue other arches.
<ubottu> Launchpad bug 1028761 in git-annex (Ubuntu) "Sync git-annex 3.20120721 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1028761
<Laney> great, good work
<Laney> this transition is almost done now
<Laney> apart from investigating the arm problem, of course
<xnox> hrw: git-annex is in main (?!)
<hrw> Laney: armhf and haskell one?
<hrw> xnox: in Debian yes
<Laney> hrw: yeah
<Laney> see e.g. haskell-chell
<xnox> Laney: this is confusing https://launchpad.net/ubuntu/+source/git-annex why does it say main, when it isn't....
<Laney> the table at the top is about the Debian publishing for some reason
<Laney> presumably because it's synced and shows you the original place the package came from
<hrw> xnox: lower it says "release (universe)"
<xnox> hrw: hmmm.... true.
 * xnox doesn't like that
<hrw> speaking of main... bug 824708 has aptitude fix for precise which also fixes  bug #975793
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "aptitude can no longer show changelogs: "Changelog download failed: Download queue destroyed." Please merge the fixed version, 0.6.8, from Debian." [Medium,Fix released] https://launchpad.net/bugs/824708
<ubottu> Launchpad bug 975793 in aptitude (Ubuntu) "'aptitude safe-upgrade -d -y' enters infinite loop" [Undecided,Fix released] https://launchpad.net/bugs/975793
<hrw> its 'fix released' in quantal only
<xnox> i'd say you should never use this "aptitude safe-upgrade -d -y" in general, and especially on amd64 with multi-arch.
<hrw> xnox: but it is possible to use so...
<hrw> xnox: and -d == download only so its safe
<hrw> xnox: years ago I had similar command in cron for 5:23 to be able to do system updates at start of daily routine without waiting long time for downloads
<hyperair> xnox: why not?
<hyperair> also there's a patch on bugs.debian.org that fixes this
<xnox> hyperair: ok. fair enough.
<hyperair> i think safe-upgrade should be safe enough
<hyperair> full-upgrade -y is the scary one
 * xnox wishes aptitude would strop removing all of the i386 packages from my amd64 machine
<lifeless> don't use it then :)
<xnox> Laney: if the build finished recently e.g. github-backup on armel. Is it safe to rebuild others or a new upload required. Also why are they not in the transition tracker?
<xnox> lifeless: the answer to everything eh ;-) =))))
<hrw> xnox: I use aptitude on amd64 system which has i386/armel/armhf packages installed and it works
 * xnox ponders if hyperair and lifeless have highlighs on 'aptitude' keyword
<hyperair> haha
<hyperair> i don't
<hyperair> you just had good timing
<lifeless> xnox: I've had some weirdness from aptitude with multiarch
<lifeless> xnox: I don't know if its sorted yet
<hrw> xnox: you 'just' need to mark all other-arch packages to upgrade each time
<hyperair> lifeless: when anything conflicts, aptitude attempts to purge all :i386 packages
<xnox> hrw: joy.
<hyperair> lp 831768
<ubottu> Launchpad bug 831768 in aptitude (Ubuntu Precise) "aptitude cannot handle conflicts with multiarch enabled" [High,Triaged] https://launchpad.net/bugs/831768
<hyperair> corresponding debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672340
<ubottu> Debian bug 672340 in aptitude "aptitude: Dependency solver always uninstalls all foreign-architecture packages" [Important,Fixed]
<hyperair> debian bug has a patch
<hyperair> i'm using it locally since debian hasn't slapped on the patch yet.
<xnox> hyperair: you should propose debian release policy to "slap the patches from bts" as a GR =)
<lifeless> hyperair: yeah, that looks like at least part of it
<hyperair> heh
<hyperair> oh looks like the bug has been closed now
<hrw> it is with 0.6.8.1-1 upload
<hyperair> weird that the graph doesn't show it.
<hyperair> i didn't see any green entries in the graph so i assumed it wasn't done.
<hrw> merging should be much easier then it was with current quantal version
<hyperair> can we SRU this?
<hyperair> seems like an annoying enough bug.
<hrw> hyperair: to 12.04 you mean?
<hyperair> yes
<hrw> hyperair: first land it in quantal
<hyperair> yeah
<hrw> hyperair: then merge into my debdiff from bug 824708 and happy sruing
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "aptitude can no longer show changelogs: "Changelog download failed: Download queue destroyed." Please merge the fixed version, 0.6.8, from Debian." [Medium,Fix released] https://launchpad.net/bugs/824708
<hyperair> heh
<hyperair> maybe this weekend if i'm free
<hrw> hyperair: this way sru would fix 3 bugs at once
<hyperair> nice
<hrw> aptitude 0.6.8.1-1 is in incoming so far
<hrw> I will merge
<Laney> xnox: the tracker has a little blind spot where stuff has never built
<hrw> aptitude 0.6.8.1 really helps on multiarch systems
<hrw> I am uploading aptitude 0.6.8.1-1ubuntu1 to http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/
<hrw> done
<hrw> and this one should go though FFE process - right?
<xnox> yes.
<xnox> everything goes through FFe =)
<hrw> ok
<sladen> particularly if it's system wide and mission critical ;-)
<hrw> sladen: I am just motu so would not upload aptitude anyway ;)
<svenx> cjwatson: where's debian's source repo for grub2 these days? http://anonscm.debian.org/viewvc/pkg-grub/ was updated 2 years ago
<xnox> svenx: have you tried $ debcheckout ?
<xnox> svenx: http://anonscm.debian.org/bzr/pkg-grub/trunk/grub/ ?
<xnox> last commit 2012-08-24
<svenx> xnox: ah, i've looked in the wrong place
<svenx> thanks!
<xnox> svenx: no problem ;-)
<mr_pouit> seb128_: hey, do you know if "internal" indicator dbus services (e.g. ./usr/lib/indicator-messages/indicator-messages-service) will stay compatible?
<mr_pouit> seb128_: to know whether I can ship only the .so in the gtk2 package, or if I need to include everything
<seb128_> mr_pouit, hey, what are you trying to do? get old versions or get the new version built with gtk2?
<seb128_> mr_pouit, the indicator-messages protocol changed in quantal, you can't use the old version, like applications are ported from libindicate to libmessaging-menu
<hrw> ok, some ftfbs entries removed by retrying builds
<mr_pouit> seb128_: "last uploaded gtk2 version", so old version I guess (it's a bit messy though, some 12.10-0ubuntu1 uploads still had gtk2 support)
<seb128> mr_pouit, I don't know over time but I think that for quantal the service will stay compatible (out of indicator-messages where you really need the version uploaded yesterday because clients will work only with this one)
<mr_pouit> ok, so only indicator-messages will be problematic
<mr_pouit> thanks
<xnox> hrw: https://launchpad.net/ubuntu/+source/haskell-hledger-web/0.18.1-1 retries failed.
<hrw> ops, sorry
<xnox> hrw: http://xkcd.com/838/
<hrw> ;)
<hrw> ~curse torcs debian/rules
<hrw> giving up on that one. rewriting rules just to make one ftfbs less is waste of time
<hrw> made it.
<hrw> bug 941619
<ubottu> Launchpad bug 941619 in torcs (Ubuntu) "torcs: new versions 1.3.3 and 1.3.2 with security fixes available severity: important" [Medium,Confirmed] https://launchpad.net/bugs/941619
<zeusk> I'm getting totally corrupted display using the latest 12.10 nightlies on Nvidia adapter, is this a known bug ?
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<ogra_> safe flight !
 * xnox Zoom Zoom
<sconklin> @patch in
<udevbot> Error: "patch" is not a valid command.
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, sconklin
<xnox> sconklin: do we need to coordinate? I was thinking to take: llvm, ubiquity, ubiquity-slideshow as first candidates
<sconklin> xnox: go ahead, I generally only look at kernel anyway
<xnox> sconklin: ah... I see =)
<xnox> sconklin: I don't ever look at kernel =))))
<hrw> xnox: happy you
<xnox> hrw: well.... i file complex kernel bugs =) that's enough
<sconklin> xnox: it's what I do every day, so I'm tooled up for it, and know the workflow. bzr, not so much
<xnox> sconklin: as infinity puts it "pick one side of the syscalls and stick to it, otherwise you will go mad"
<sconklin> haha, had not heard that one but it's true
<ogra_> poor syscall developers then
<hrw> did I already said that I do not like torcs packaging?
<hrw> I do not understand why they call configure in clean step
<sconklin> to paraphrase Inigo Montoya: "You keep using that syscall. I do not think it does what you think it does".
<ogra_> hehe
<xnox> hrw: scons?
<xnox> that thing does that for no reason.....
<hrw> xnox: rather own + cdbs
<hrw> first FFe today: bug 1042752
<ubottu> Launchpad bug 1042752 in torcs (Ubuntu) "FFe: new version 1.3.3 with security fixes available" [Undecided,New] https://launchpad.net/bugs/1042752
<hrw> but I have a question about it. https://wiki.ubuntu.com/FreezeExceptionProcess says: "Up through RC, if a developer believes an upload of a new upstream release that just has bug fixes in it is warranted, they may upload it. The developer should explicitly document that this is a bugfix-only upload in the changelog or sync request." My debdiff is only patch to get it stop ftfbs in quantal (as 1.3.3 got uploaded but never built) - so it may look like 'meh, thats 
<xnox> hrw: what's the debdiff like against torcs_1.3.1-6.2.dsc  ?
<xnox> cause that is the effectively the changes you are trying to land =)
<hrw> xnox: good point
<iulian> 1.3.3 is already in quantal and thus no FFe is needed as it's just a bug fix.
<hrw> iulian: even when 1.3.3 never built in quantal?
<xnox> iulian: source tarball is, no binaries though.
<iulian> Well, the source is already in the archive so it doesn't really matter. You just work on the latest version which is 1.3.3.
<hrw> ok, so will run dput
<xnox> hrw: i disagree with iulian interpretation.
<iulian> Why?
<xnox> iulian: $ apt-cache show torcs | grep Version
<xnox> Version: 1.3.1-6.2
<hrw> basically I will just wait - have few other things on a list, bug is opened so let ubuntu release team decide there
<iulian> xnox: That's because there's no binaries.
<hrw> once I will get answer in a bug from someone from release team I will apply
<xnox> iulian: the binaries is what counts, not the source package. and it's the binaries we are freezing not the version strings on the source package.
<iulian> xnox: Try apt-cache showsrc torcs.
<xnox> iulian: but that is just my interpretation, and I am not on the release team or anything.
<iulian> hrw: You just got.
<xnox> iulian: I totally understand your point though. "It landed on time, let's make it build now"
<iulian> Correct.
<xnox> iulian: and well, you wear release team hat =)
<hyperair> xnox: hmm aptitude still has issues when doing install -f.
 * hrw builds source package, dput, close bug
<hyperair> i.e. the typical dpkg -i foo.deb; aptitude install -f still doesn't work well with multiarch
<xnox> yeah, I know =/
<xnox> hyperair: apt-ftparchive package ./ > Packages
<xnox> =))))
<hrw> xnox: I prefer dpkg-scanpackages - has less dependencies
<hrw> ;D
<xnox> hrw: learned something new ;-)
<hrw> xnox: effect is same and do not need libapt
<hrw> xnox: embedded linux work learnt me such tricks
<tumbleweed> iulian: ah, we both reviewed that at the same time
 * tumbleweed took a more middle-ground approval approach though :P
<iulian> tumbleweed: Hehe.
<hrw> ;))
<iulian> Oh well.
<hrw> builds started
<xnox> hrw: you built it locally first, right?! =))))))))
<hrw> xnox: several times
<hrw> xnox: https://bugs.launchpad.net/ubuntu/+source/torcs/+bug/1042752/+attachment/3280649/+files/torcs_1.3.3-5ubuntu1_amd64.build was in FFe bug
<ubottu> Launchpad bug 1042752 in torcs (Ubuntu) "FFe: new version 1.3.3 with security fixes available" [Undecided,Fix committed]
 * xnox hrw +1 point after FTBFS on the rebuilds. Current Balance: 0.
<hyperair> xnox: i use reprepro, but i don't really feel up to apt-get update.
<hyperair> xnox: when you've got loads of PPAs and live in a region where canonical's servers are slow..
<hyperair> well.. you don't really feel like doing apt-get update just for a single package you have locally
<hrw> hyperair: apt-cacher-ng on router (with hdd) helps
<hyperair> hrw: it does, but for some reason apt-get update still takes a long time.
 * tumbleweed develops against snapshots that are 6-12hours old and it's never been an issue (I guess I just stay clear of the fast-moving stuff)
<hyperair> apt-cacher-ng caches debs well enough, but doesn't do so well with package indexes.
<hrw> dpkg-deb: building package `torcs-data-tracks' in `../torcs-data-tracks_1.3.3-5ubuntu1_all.deb'.
<hrw> yay:)
<tumbleweed> apt-cacher-ng is terrible with indexes, and even worse with pdiffed indexes
<hyperair> yeah that
<hyperair> squid might do better
<ogra_> approx ftw !
<hyperair> approx?
<hyperair> oh nice.
<hyperair> is it more stable than acng?
<ogra_> apt-cache show approx ?
<ogra_> :)
<hyperair> ?
<hyperair> is it?
<ogra_> dunno, i have never used any other package cacher
<ogra_> its rock solid though
<hyperair> hmm
<hyperair> no problems whatsoever?
<hyperair> i should try it out
<hyperair> i wonder if i can import my existing archives
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek is starting in a bit more than 10 minutes in #ubuntu-classroom
<dholbach> ogra_, bilal, barry: ready for later on?
<ogra_> no, but i will be if i'm up to speak :)
<PaoloRotolo> Hi all!
<bilal> dholbach: yup :)
<dholbach> awesome
<barry> dholbach: getting there :)
<dholbach> great
<barry> dholbach: is it a problem if i have 3 hrs worth of material? :)
<dholbach> not at all :)
<dholbach> ok, got to start :)
<siretart> stgraber: just curious, does ltsp in quantal netboot the thinclients with root on nfs using live-boot?
<smoser> is it acceptable to write a file in /etc/ in a post install?
<smoser> to avoid it being a conf file ?
<smoser> and only create if non-existing and only remove on purge?
<stokachu> xnox, sconklin : feel like doing multi-arch sru reviews? :D:D
<xnox> stokachu: you still have some?! =)
<stokachu> xnox: yea all the ones from last week's meeting
<stokachu> i know slangasek is busy so i dont want to nag
<siretart> smoser: if you create it, I see no problem with it, but you need to pay special attention wrt. preserving local changes on upgrade. the ucf package may help with that
<smoser> siretart, well my thought was to never change it.
<smoser> only write the initial
<smoser> and then only if it did not exist.
<siretart> smoser: what if the local admin deleted the file and did not want to have it reintroduced on upgrades?
<siretart> with conffiles, dpkg does the right thing here.
<smoser> siretart, true.
<xnox> I used to be affect by arch:all skew, now I am also affected by arch:i386 skew =/
 * xnox multiarch.... win?!
 * xnox just did a "complex" downgrade of a locally compiled package back to the disto version
<Will123456> hey guys. i'm thinking about adding HUD support to blender, but it'd have to be ubuntu specific as the blender devs aren't interested. is this the right place to talk about it?
<seb128> Will123456, hey, try #ubuntu-unity rather
<Will123456> seb128: thanks :)
<xnox> please reject https://code.launchpad.net/~roger.light/ubuntu/precise/mosquitto/fix-972389/+merge/119973 ?
<xnox> or should I s/precise/precise-proposed/
<xnox> no fix in quantal yet, though
<killown> https://lists.ubuntu.com/archives/ubuntu-devel/2012-August/035675.html  DONT DO THAT
<killown> this alternate CD is a lot useful
<killown> I have a raid setup here would be useless if I would need install ubuntu 12.10 from scratch
<killown> I ubuntu devels really do that I will need to chance of distro, VERY VERY BAD DECISION
<killown> RAID is relatively straightforward to turn on post-install.
<killown> MAN how can I install without setup my raid before?
<killown> please ignore this request, it's insane
<xnox> killown: you would use mini.iso and get all the updates from the internet instead of downloading ~300MB of 0day SRUs
<xnox> killown: which has the exact same installer as the alternative installer including RAID.
<xnox> killown: sans the package pool, which you will have to pull from the network / mirror
<xnox> killown: or the server cd, if your hardware is amd64
<seb128> ev, hey, is e.u.c timing out of the start page (like default daily view) a known issue?
<ev> seb128: with launchpad=false set?
<seb128> ev, no, without it, just opening the page
<ev> seb128: oh, so even before you get any content at all you get a timeout?
<seb128> ev, right, I get "Loading..." in the table for 30s
<seb128> and then "an error occurred..."
<ev> oh, that
<seb128> like no content
<ev> yes - please set launchpad=false for now. There have been a number of speed ups to the launchpad color-coding in trunk, but we're blocked on another RT before those can land
<seb128> thanks
<ev> (the caching of open ID credentials one)
<ev> sure thing
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<xnox> but I will be back again later.
<stokachu> could someone look at bug https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/941673 it was marked fix released but i doubt a release is present
<ubottu> Launchpad bug 941673 in accountsservice "performance of accounts-daemon is very poor" [Medium,Confirmed]
<seb128> stokachu, set it back to triaged, you might want to point the qa team (or bdmurray) to the user who vandalized the bug that way
<stokachu> seb128: ok thanks, i tried to set it back the other day it just error'ed on me
<trism> doko: I don't think bug 1037566 is fixed, it is still missing the multiarch path to pyconfig.h, http://paste.ubuntu.com/1172348/
<ubottu> Launchpad bug 1037566 in python3.3 (Ubuntu) "invalid Python installation: unable to open /usr/lib/python3.3/config-3.3m/Makefile" [Undecided,Fix released] https://launchpad.net/bugs/1037566
<stgraber> siretart: ltsp uses nbd and doesn't use live-boot
<mterry> jdstrand, on the remote-login-service test suite errors, tedg told me those were expected failures, and he added code to not have the error output cause a test failure
#ubuntu-devel 2012-08-29
<jdstrand> mterry: that's cool-- it was just not obvious from the build log that it was the case
<mterry> jdstrand, yeah.  :-/  And trunk has a fix for the full path needing to be specified in the /etc file
<mterry> jdstrand, these pieces are coming together a bit fast
 * jdstrand nods
<darkxst> jbicha, any other show-stopper bugs for the iso?
<pitti> Good morning
<darkxst> anything I can do to resolve this? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1043077
<ubottu> Launchpad bug 1043077 in upstart (Ubuntu) "upstart restarts DM to quickly" [Undecided,New]
<pitti> DAMN YOU, Launchpad! you timeouted my carefully typed bug report
<siretart> stgraber: I see. are you aware of any other 'official' ubuntu project that depends on live-boot's nfsroot capabilities?
<dholbach> good morning
<geser> good morning
<nigelb> Hey dholbach and geser :)
<geser> I'm preparing a vim merge to make vim installable again. Could someone sponsor it later?
<dholbach> hey nigelb, hey geser
<geser> bug 1043035 is waiting on sponsoring if someone wants to upgrade vim in quantal
<ubottu> Launchpad bug 1043035 in vim (Ubuntu) "vim no longer installable dependancy problems" [Undecided,Triaged] https://launchpad.net/bugs/1043035
<xnox> posted to devel from the wrong email.
<PaoloRotolo> Hi all!
<xclaesse> why is gdesktopappinfo.h installed in /usr/include/gio-unix-2.0/gio/ ?
<xclaesse> it should be /usr/include/glib-2.0/gio/ no ?
<xclaesse> hm, that's what upstream does in make install it seems ... :/
<seb128> xclaesse, I don't think me move any include around...
<xclaesse> yeah, that's normal actually, my bad
<xclaesse> seb128, I've seen that because building gtk from source fails: gtk-launch.c:31:33: fatal error: gio/gdesktopappinfo.h: Aucun fichier ou dossier de ce type
<xclaesse> seems gtk-launch should be built extra unix flags
<xclaesse> I'm wondering how ubuntu package work around that
<seb128> xclaesse, not sure, we don't do anything I know about
<seb128> xclaesse, yeah, from the build log there is a bunch of -I parameters but I don't know where they are coming from looking at the Makefile.am...
<xnox> seb128: /usr/lib/x86_64-linux-gnu/pkgconfig/gio-unix-2.0.pc
<seb128> xnox, no
<seb128> xnox, I mean Makefile.am has
<seb128> gtk_launch_LDADD = $(LDADDS)
<seb128> gtk_launch_SOURCES = gtk-launch.c
<seb128> no CFLAGS
<seb128> xnox, I though that would only add the "pkg-config --libs gio-unix-2.0" bits
<xclaesse> ok ok, understood why it works for ubuntu package and not my build
<seb128> xclaesse, oh? why?
<xclaesse> I'm building with broadway backend, and in that case the configure.ac does not define have_gio_unix
<seb128> oh, ok
<xclaesse> still, that's an upstream bug, if it's not unix it should not try building gtk-launch
 * xclaesse will report that
<xclaesse> and that was already reported... awesome : https://bugzilla.gnome.org/show_bug.cgi?id=682824
<ubottu> Gnome bug 682824 in win32 "Don't build gtk-launch on Win32 environments" [Normal,Unconfirmed]
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin, smoser
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<dholbach> mterry, coolbhavi, tumbleweed, m_3: ready? :)
<coolbhavi> dholbach, yup :)
 * dholbach hugs sconklin
<tumbleweed> haven't started preparing anything, but I've doen this one before, so sure :P
<dholbach> sweet
<mterry> dholbach, I'm mostly ready, but I've not done this talk for a more Ubuntu-focused audience (usually for app dev week), so not sure how long it will be.  I suppose there's no harm in ending before an hour
<coolbhavi> dholbach, have already shared my notes with you
<coolbhavi> reg dat :)
<dholbach> mterry, cool
<dholbach> coolbhavi, allright
<m_3> dholbach: yup
<dholbach> cool
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in ~15 minutes in #ubuntu-classroom
<ev> mpt, bdmurray: https://bugs.launchpad.net/errors/+bug/1043426
<ubottu> Launchpad bug 1043426 in Errors "When we start pulling in more problem types, continue to track *just* crash problems in addition to the whole set" [Undecided,New]
<ev> and https://bugs.launchpad.net/errors/+bug/1043428
<ubottu> Launchpad bug 1043428 in Errors "Selecting a package or a package and version should change the average errors per day graph" [Undecided,New]
<ev> https://bugs.launchpad.net/errors/+bug/1043430
<ubottu> Launchpad bug 1043430 in Errors "Selecting a date range in the average errors per day graph should change the most common problems table to the matching date range" [Undecided,New]
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<roaksoax> cjwatson: ping
<dobey> slangasek: hey. do you know if gobject-introspection (libgirepository) has proper multiarch support? or am i totally breaking things by trying to convert my package to multiarch that provides a gir api?
<slangasek> dobey: TTBOMK there's no multiarch support for gir itself currently; so typelibs should continue to be shipped in /usr/lib/girepository-1.0, not in an arch-qualified directory
<slangasek> dobey: but as long as the gir bits are in a separate binary package, the shared lib could still be made M-A: same
<dobey> slangasek: and the gir package needs to be foreign?
<slangasek> dobey: no
<slangasek> it needs to not be marked Multi-Arch at all
<dobey> ah
<slangasek> because it's architecture-dependent and not co-installable
<slangasek> (the typelib files encode information about things like integer sizes, so are not arch-neutral)
<dobey> slangasek: and does dh_girepository move stuff back to non-ma dirs? or one has to do that manually?
<slangasek> I suspect you need to do that part manually
<dobey> ick, ok
<seb128> in the hate webkit serie
<seb128> doko, slangasek, others: can we get http://sourceware.org/bugzilla/show_bug.cgi?id=14302 in quantal?
<ubottu> sourceware.org bug 14302 in binutils "ar mishandles 4GB files" [Normal,Resolved: fixed]
<seb128> "ar: .libs/libWebCore.a: File truncated" is how webkit fails to build on amd64, seems to be due to that bug
<seb128> did I say that I hate webkit?
<dobey> seb128: libWebCore.a is > 4GB?! :(
<seb128> dobey, guess so
<seb128> the build dir is like 25G and ld takes over 3G of ram so I'm not surprised
<dobey> ffs it has really ballooned out in its age, hasn't it
<seb128> yeah, that's just insane
<seb128> doko, slangasek: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1043507
<ubottu> Launchpad bug 1043507 in binutils (Ubuntu) "webkit build fails on binutils limitation" [Undecided,New]
<sdh> im just catching up on the day's "developer week" logs
<sdh> is it correct that anybody can register to attend UDS?
<xnox> sdh: yes. It is an open for all event, if you can/prepared to pay your own accomodation, food and travel.
<xnox> sdh: you can apply for sponsorship to attend, but there is a very limited amount of those available.
<ajmitch> iirc sponsorship for the next uds has closed
<dobey> sdh, xnox, ajmitch: also, even if you can't attend in person, you can attend remotely via irc and the audio/video streams
<sdh> xnox: i would look to fund that myself
<sdh> xnox: does UDS tend to "sell" out?
<xnox> sdh: there is no "sell" out. There are many locals showing up on the day. So attendance does vary.
<xnox> sdh: for the plenary sessions it can be packed (e.g. when HP/Google/etc are presenting), other sessions can be quite empty (I did attend a session where there were only 3 people, we quickly made some decisions and went to visit other tracks)
<sdh> cool, so no rush to register?
<sdh> is there an agenda/plan anywhere?
<xnox> sdh: register if you think you might attend.
<xnox> sdh: uds.ubuntu.com In due course... everyone is busy with quantal right now =)
<sdh> sure, thanks xnox ;)
<xnox> sdh: it's a developer event, not a consumer / user event. Mostly we talk about blueprints.
<sdh> that's good
<xnox> sdh: see status.ubuntu.com for things that are lickely to be discussed.
<sdh> xnox: cool, will do. just checking then, it's ok to register and possibly back out in future
<xnox> sdh: and developing ubuntu =) not like any random "lets learn to code in python, but better!" =)
<sdh> i think i understand :)
<sdh> wow danish hotels are expensive !
<xnox> sdh: hint, all hotels in capitals & easy air-travel from USA and Europe are expensive
<sdh> thanks xnox i haven't travelled anywhere before
<sdh> :p
<slangasek> seb128: the upstream bug claims it only impacts 32-bit platforms, you report that it affects amd64?
<seb128> slangasek, hum, maybe a different issue then :-(
<slangasek> seb128: the "only impacts 32-bit" is what I would have expected, since size_t and friends are 64-bit already on amd64
<seb128> I didn't read the details, I just had a quick look since I had to run
<slangasek> seb128: and it looks like this .a is an intermediate file used for linking the final result, right?  So it's not enough to just disable static library builds?
<seb128> slangasek, I guess I can try that, I'm still unsure what is the best practice about static libs
<slangasek> seb128: if WebCore.a is an interim file that's linked into the final .so, disabling static libs doesn't help
<jtaylor> is someone already working on update vim? required since the last python update
<slangasek> seb128: but certainly, I don't think we should let anyone link statically to webkit ;)
<micahg> +1 :)
<tumbleweed> jtaylor: aah, you found geser's bug
<seb128> slangasek, in fact from the build log static build is already disabled "checking whether to build static libraries... no"
<slangasek> seb128: right, so I think this is just linking a convenience library
<slangasek> seb128: so unless you want to change -g options, there doesn't seem any way around it
<seb128> :-(
<seb128> webkit is a nightmare
<sdh> how so?
<seb128> sdh, takes 6 hours do build, ld takes over the 32 bit memory space allocation limit, requires patched make because it goes over the number of arguments limitations of the current version, hit some binutils bug on amd64 apparently, etc
<sdh> seb128: crikey, good reasons to complain ;)
<seb128> did I mention that they broke api without noticing several times this cycle?
<seb128> they are asking for hints on how they could see those before releasing at this point :p
<lifeless> seb128: API or ABI ?
<lifeless> seb128: I would have thought the former was easy to tell (and the latter tricky...)
<slangasek> seb128: so do libwebkitgtk-3.0-0-dbg and/or the dbgsym package actually get used?  1.2GB installed?
<seb128> slangasek, not by me, but I don't know if others do ... I guess some people working on webkit can make use of debug stacktraces
<seb128> lifeless, the first one, they dropped symbols from their public headers
<slangasek> seb128: well, simply disabling -g would bring the size down and let it build... is it maybe better to do that, and drop the dbg for now, than to have it not buildable?
<lifeless> seb128: -lol-
<seb128> slangasek, for sure better, still not ideal though...
<slangasek> seb128: so there are tools for checking API backwards-compatibility, but I'm not sure if they work for C++ or just C
<slangasek> seb128: indeed, not ideal; just trying to suggest a way to unblock while waiting for this fix
<seb128> slangasek, well, I'm not strictly blocked on that at this point, still waiting on upstream to sort their api,abi issues
<seb128> slangasek, I'm unsure but it might be that the previous version had the same issue on the ppa builders but built in the archive
<seb128> slangasek, not sure why that would happen though so I might recall wrongly
<slangasek> hmm
<slangasek> I don't know either
<seb128> I've played with the build flags quite a lot though
<slangasek> seb128: turning off -g completely should certainly let it build
<seb128> like I added -Wl,--reduce-memory-overheads in some previous upload because otherwise it was spending over 3 hours on ld on armel and the builders were killing the build as hanging...
<seb128> slangasek, thanks, I dropped -Wl,--reduce-memory-overheads just to see if that makes a difference
<seb128> if that doesn't I will drop -g in the next build to try that
<infinity> seb128: You could also try -gstabs instead of -g
<slangasek> yes, a little stabbing always helps when dealing with debug options
 * infinity smirks.
<seb128> I could just declare that I don't care enough about webkit, let it where it is and see if anyone else picks it up after some time ;-)
<seb128> I'm ready to pay a beer every night at UDS to whoever takes over it :p
<infinity> I'd fix it if I wasn't reviewing the mess in precise/NEW.
<ajmitch> seb128: just one? :)
<seb128> ajmitch, hey, I say "one every night", it's better than one :p
<chrisccoulson> seb128, BEEEEEEEEEEEEEER, you say?
<chrisccoulson> every night?
 * chrisccoulson thinks about that one
<seb128> chrisccoulson, indeed!
<seb128> chrisccoulson, and see I'm in a good mood if you take the offer I will double that offer
<seb128> chrisccoulson, and think about it, it would give you some extra perspective on how good firefox is ;-)
<chrisccoulson> lol
<doko> seb128, slangasek and this fix is in quantal, even if it doesn't help
<seb128> ok
<slangasek> doko: ok, thanks for looking
<slangasek> seb128: an strace of the failing ar command may help here
<seb128> slangasek, will try to get one
#ubuntu-devel 2012-08-30
<mterry> robert_ancell, what are your thoughts on using libgnome-desktop3 to set the average background color?  I'm not sure I want to propose rewriting how we do the background stuff we have at this late juncture, so it would mean we'd be using its background setting method even though the user never saw the root window
<mterry> robert_ancell, this is in reference to bug 1043572
<ubottu> Launchpad bug 1043572 in Unity Greeter "Shade notification colors according to current background" [Undecided,New] https://launchpad.net/bugs/1043572
<robert_ancell> mterry, should be ok
<mterry> robert_ancell, I'll try to whip something up, but in order to make it for UIF, I'll try to finish it tonight so you can review
<robert_ancell> ok
<pitti> Good morning
<malkauns> how do you create animated progressbars in gtk-3 ?
<dholbach> good morning
<cody-somerville> wtf
<cody-somerville> my e-mail to ubuntu-devel has been moderated
<cody-somerville> "The reason it is being held:
<cody-somerville>     Post by non-developer to moderated list."
<cody-somerville> Ugh. I'm the owner of ubuntu-core-dev. Pretty sure I'm a developer ;p
<ogra_> cody-somerville, sent under wrong address ?
<cody-somerville> Checked
<xnox> cody-somerville: wrong email alias? which email are you subscribed to with to the mailing list? @ubuntu?
<cody-somerville> Sender: cody-somerville@ubuntu.com
<ogra_> did you stop developing and mailman noticed ? :)
 * xnox ..... who will break the news out to cody?! =))))))))))) *giggles*
<cody-somerville> possibly :-)
<cody-somerville> mailman is written by barry so it's probably got all sorts of features ;)
<ogra_> haha
<jamespage> can someone help me understand why 'apt-get install bacula' in 12.04 results in 'bacula : Depends: bacula-server but it is not going to be installed'
<scott-work> stgraber: do you know to whom i would speak to learn how to set up ubuntu studio's profile for autotesting per https://blueprints.launchpad.net/ubuntu/+spec/other-q-ubuntu-flavors ?
<jamespage> I figure its something todo with unversioned dependencies on the bacula meta-package but I'd like to understand why it creates this issue (if that is the problem)
<scott-work> point me at documentation, an example, or another person would be helpful :)
<zul> jamespage:  good question and i dont think you are being a dumbass
<geser> jamespage: tested in my precise vm and apt is happy with the dependencies. try if "apt-get install bacula bacula-server" tells you more (you might need to repeat this with additional dependencies till you get to the real error)
<jamespage> geser, hmm -  "apt-get install bacula bacula-server" works just fine
<geser> interesting
<jamespage> geser, there is a version of bacula in -updates as well which I think is causing the problem
<jamespage> bacula -> bacula-server
<jamespage> bacula does not have a versioned Depends on bacula-server
<geser> I've -updates enabled in my precise vm and "sudo apt-get -s install bacula" shows no error
<jamespage> geser, odd - I get http://paste.ubuntu.com/1175807/ from exactly the same command
<geser> is this about an upgrade or fresh install of bacula?
<jamespage> geser, fresh install
<jamespage> relates to bug 1034962
<ubottu> Launchpad bug 1034962 in bacula (Ubuntu) "bacula dependency on bacula-server fails with held broken packages" [Undecided,Confirmed] https://launchpad.net/bugs/1034962
<jamespage> geser, my instance is fully up-to-date and is amd64 arch
<geser> jamespage: did you try if temporarily disabling the -updates repo "fixes" it?
<jamespage> geser, good point
 * jamespage tries it
<jamespage> hmm - odd - I still see the same issue
 * jamespage puts the idea about -updates confusing things in the bin
<geser> try activating some of apt's Debug settings like Debug::pkgProblemResolver, perhaps it gives a hint
<jamespage> geser, thanks for that pointer - I think I see the issue
<jamespage> I think its a Recommends down the depencency chain on a virtual package - this is fixed in quantal
<jamespage> precise: Recommends: bacula-sd-tools
<jamespage> quantal: Recommends: bacula-sd-mysql (>= 5.2.6+dfsg-2ubuntu1) | bacula-sd-tools
<hallyn> jodh: SpamapS: the upstart cookbook doesn't seem to mention anything about 'restart job' acting different from 'stop; start' when there is a pre-stop or post-stop stanza.  that is the case right?
<jamespage> zul, geser: its broken in oneiric as well
 * jamespage sighs
<geser> jamespage: you're probably right. I had Recommends disabled my precise vm and with Recommends enabled I get that error too
<jamespage> geser, testing that theory now; the Recommends has been like that since forever so suspect a change in resolver behaviour as well - but its def not right
<geser> but 'sudo apt-get -s install bacula -oApt::Install-Recommends=false' works again
<jamespage> geser, thanks for the help BTW
<jamespage> gema, ^^ why we need more automated test coverage of seeded packages which are not on ISO's
<gema> jamespage: excuse my ignorance, where do I find those seeds?
<jamespage> gema, launchpad - they are all owned by the ubuntu-core-dev team
<jamespage> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.quantal for example
<geser> jamespage: the interesting question is if this is a packaging bug in bacula or a regression in apt
<jamespage> geser, depends on what apt should do when trying to resolve a virtual package
<jamespage> I find it odd that it just picks one
<jodh> hallyn: well spotted. Yes, that is the case - the behaviour needs documenting in the man pages too. I'll add to the Cookbook this week if I get a chance.
<hallyn> jodh: thanks, wanted to make sure
<jamespage> mvo, any opinion on the discussion above?
<geser> assuming it ever worked as expected
<jamespage> geser, quite
<geser> btw this was Debian bug #602222
<ubottu> Debian bug 602222 in bacula "bacula meta-package not installable with recommended packages" [Serious,Fixed] http://bugs.debian.org/602222
<jamespage> geser, looks like thats been dropped during merges for some time....
<jamespage> geser, there is certainly a behavioural change in apt between natty and oneiric which reveals this issue
<soren> hallyn: I don't know if it answers your question, but restart and stop;start differ in that stop;start stops the job as upstart knows it in-memory and then starts it anew based on what's in the upstart job file now. Restart doesn't care what's on disk. It uses it's in-memory copy of the job description as it were when it was started.
<soren> hallyn: Whether there are differences wrt to pre-stop and post-stop handling.. I don't know.
<dholbach> gema, dpm, ScottK, bdrung: ready? :)
<dpm> dholbach, in 45 mins?
<gema> dholbach: dpm is starting, I am second!
<dholbach> yep
<gema> ready
<dholbach> just asking all speakers of today
<dpm> gema, yes dholbach is aware too, we've changed it in the calendar. Thanks again for swapping :)
<gema> dpm: no problem!
<bdrung> dholbach: yes as a ill developer can be
<hallyn> soren: yea, that bit is documented in the cookbook.  but also if there is a pre-stop or post-stop stanza, then 'restart' does not kill and restart it.  i only know bc that's been a problem with libvirt before
<hallyn> biab
<Peace-> just to report something that ubuntu devs should read http://www.wired.com/wiredenterprise/2012/08/osx-killed-linux/ that's maybe why developers can't do a good  programs for years things are keeping changing and they broke always the code you did before
<arges> Hello. If a debian bug targets the wrong package, is there a way to change the package it was targeted against, or should I file a new bug?
<pitti> arges: http://www.debian.org/Bugs/server-control
<arges> pitti, thanks
<pitti> arges: if you have the "bts" tool working, "bts reassign 12345 new-package new-version"
<pitti> otherwise mail the command to control@bugs.debian.org
<arges> ahh very nice
<ricotz> hello, could an archive-admin look into accepting clutter-gst-2.0 ? -- https://bugs.launchpad.net/ubuntu/+source/clutter-gst/+bug/1040930
<ubottu> Launchpad bug 1040930 in clutter-gst (Ubuntu) "FFe: Sync clutter-gst-2.0 1.9.90-1 (universe) from Debian experimental (main)" [Wishlist,Fix committed]
<seb128> ev, is e.u.c broken?
<ev> seb128: working fine here
<seb128> ev, selecting: 12.10, gnome-control-center, the past month gives me a "No data to display" which I find hard to believe ;-)
<seb128> like I know g-c-c has bugs, it should have collected at least one in august
<seb128> there is a solid list of those for 12.04 though
<ev> seb128: it's a sort of bug in the deployed version of errors.ubuntu.com....
<ev> it only shows problems with instance counts >= 20
<ev> whereas trunk takes the 100 problems with the highest instance counts
<seb128> so no g-c-c bug got >= 20 during august
<seb128> that's hard to believe
<ev> so looking at trunk, I see problems with 18, 16, and 9 instances (and so on)
<ev> in quantal.
<seb128> ok, maybe we have less quantal users that I though
<seb128> some bugs have > 3000 in precise for g-c-c during august and they are not fixed in quantal
<ev> in 12.04 we had 3447 instances for the biggest g-c-c problem
<seb128> yeah, I'm just surprise that we don't have a magnitude of some hundred for quantal at least
 * xnox quantal users don't use g-c-c but use dconf-editor?
<seb128> it means we don't get enough people running it yet at this stage to do work in a statistical way :-(
<seb128> ev, thanks for the responses
<ev> seb128: anytime :)
<seb128> xnox, could be, it means we don't have enough real datas to know what to work on though ... at this point we are basically back to IRC pings and launchpad :p
<ev> seb128: for what it's worth, ubiquity's top problem in 12.10 has 220 instances
<ev> so it could just be that g-c-c is lightly used so far
<ev> (software-center's is 1338)
 * xnox probably should look at those about ubiquity....
<seb128> ev, yeah, could be
<seb128> ev, ok, maybe I'm overlooking it but where are retraced stacktraces hidding?
<seb128> ev, I would like to get some debug infos for https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fgnome-control-center%3A11%3Ax86_64%3A%2Fusr%2Flib%2Fcontrol-center-1%2Fpanels%2Flibnetwork.so%2Bd0e5%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bfeca%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B28741%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B29242%3A%2Fus
<seb128> r%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bfca2%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B20d71%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B29099%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B29242%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbus-glib-1.so.2.2.2%2B110a7%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bfca2%3A%2Fusr%2Fl
<seb128> ib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B20d71%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B29099%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2B29242%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbus-glib-1.so.2.2.2%2B116e6%3A%2Flib%2Fx86_64-linux-gnu%2Flibdbus-1.so.3.5.8%2Be9a6
<seb128> arg
<seb128> sorry for the spam, I didn't see that 1 line would do that
<seb128> ev, that's the most reported g-c-c bugs for 12.04 in august
<seb128> bug
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek last day starting in 13 minutes in #ubuntu-classroom
<ev> seb128: that one failed to retrace
<ev> back in a few - need to help a colleague
<seb128> ev, ok
<stgraber> sconklin: that'd be me
<stgraber> oops
<stgraber> wrong tab-complete
<stgraber> scott-work: ^
<debfx> infinity: clang 3.1 ping :)
<karunCool> Hello
<scott-work> stgraber: sorry to bother you :)   i'll await the ping then
<karunCool> Hello anyone here
<karunCool> ???
<SpamapS> hallyn: re pre-stop screwing up restart.. its bug 703800
<ubottu> Launchpad bug 703800 in upstart (Ubuntu) "init: restart command fails to restart main process when pre-stop stanza exists" [Medium,Triaged] https://launchpad.net/bugs/703800
<hallyn> SpamapS: yup, thanks, i've marked it a dup
<bjf> slangasek: bug 1043936
<ubottu> Launchpad bug 1043936 in ubiquity (Ubuntu) "Fresh install of quantal server gets the interface name wrong" [Undecided,New] https://launchpad.net/bugs/1043936
<bjf> slangasek: this is something i mentioned last week in the release channel
<bjf> slangasek: i'm just now getting back to it
<slangasek> bjf: is this with or without preseeding of interface names?
<slangasek> bjf: fwiw this isn't ubiquity, ubiquity is only used in the desktop live installer
<bjf> slangasek: no preseeding of interface names
<slangasek> ok
<bjf> slangasek: i didn't know what to file the bug against
<slangasek> so it looks like we've failed to get biosdevname included in the target
<slangasek> bjf: can you confirm that the biosdevname package is missing on the system?
<bjf> slangasek: any log files you'd like me to attach?
<bjf> slangasek: i had to install biosdevname myself
<slangasek> bjf: have you rebooted since installing biosdevname?
<bjf> slangasek: no
<bjf> slangasek: can do if you'd like me to
<slangasek> bjf: so I expect that a reboot will rejigger the interface names now that biosdevname is present, and let things work as intended; we just need to sort out why the package wasn't included in the target
<bjf> slangasek: would you like me to reboot and see?
<slangasek> bjf: if that's ok, yes
<bjf> slangasek: np
<bjf> slangasek: i have no problem reprovisioning this system from scratch if that would help in any way
<bjf> slangasek: it's a test box and only takes about 10 minutes
<slangasek> bjf: I think if you can attach /var/log/installer/*, and confirm that a reboot is sufficient to fix the networking, that's all we need
<bjf> slangasek: just so you know, i had to fix up /etc/network/interfaces by hand to get it onto the network and install biosdevname
<slangasek> oh, then after reboot your config file and interface names will be criss-crossed ;)
<bjf> slangasek: nope, everything came up as eth0 still
<slangasek> bjf: ok, then /var/log/udev as well please
<bjf> ack
<bjf> slangasek: logs attached
<infinity> Riddell: Did you have any plans to fix the symbols files in telepathy-qt for ARM and PPC?  It's been FTBFS all month...
<bjf> slangasek: i also attached the preseed file that i'm using
<xnox> barry: I don't like OrderedDict. It should support being initialised with dictionary syntax yet preserving order. E.g. OrderedDict({'x':1,'a':1,'b':1}).items() == ['x','a','b'] should be True, but it's not =(
<xnox> barry: oh well, will change to tuple now =(
<xnox> barry: wait.... i simply don't need a dictionary in this case at all, just tuple of tuples.
 * xnox likes OrderedDicts again
<geser> :)
<barry> xnox: exactly.  the former suggestion would be impossible
<xnox> barry: phhhh if import print_functions changes print(), you could make former to work !!!! =)
<xnox> if barry.is_away(): self.make_black_magic()
<barry> xnox: if you'd like to submit a pep <wink> i can commit it for you, but i think it will not live long before the guido hammer fell :)
<xnox> barry: maybe on 1st of april
<xnox> =)
<barry> yes! we need a new april fools joke :)
<bjf> slangasek: i added biosdevname to my preseed file pkgsel/include and that seems to have done the trick
<bdrung> ScottK: developer week session in a few minutes
<slangasek> bjf: right-o - so we just need to fix it so that's done by default
<bjf> slangasek: ack
<kees> \o/ biosdevname
<xnox> kees: =)))) if only people new the things that get you excited ! =)
<kees> xnox: it's my secret sysadmin upbringing or something :)
<xnox> kees: I'm thinking to get a Linksys WRT router in a plush form now =)
<kees> ah!
<kees> I just built my first dd-wrt router :)
<geser> and if kees drops soon out of IRC we know why :)
<kees> geser: heh, so far I haven't null-routed myself :)
<smoser> pitti, around ?
<ScottK> jbicha: There's a bug in gnomebuntu-default-settings.postrm.  It still says Xubuntu.  Please fix and reupload.
<smoser> i was looking at bug 1018552 . i'm generally python illiterate.
<ubottu> Launchpad bug 1018552 in apport (Ubuntu) "ubuntu-bug on ec2 causes stack trace" [Undecided,Confirmed] https://launchpad.net/bugs/1018552
<smoser> data/general-hooks/ubuntu.py uses 'startswith' a lot of times. and seems to pass strings in.
<ScottK> smoser: The issue in that bug is a matter of type changes between python and python3.
<smoser> right.
<ScottK> In python, string and bytes are interchangeable, but in python3 they're different types.
<smoser> so i can easily fix that case, with: ami.startswith(b'ami-')
<smoser> but the file is loaded with those
<ScottK> The 'b' at the start makes is of type bytes and not type string.
<smoser> so all of thse uses of startswith should be fixed, no?
<ScottK> It depends on if it really should be bytes and not string.
<ScottK> Congratulations.  IME the is the most painful part of python/python3 porting.
<ScottK> When you trip over the added distinction in the two types you have to step back and figure out which one you actually want.
<ScottK> I'd ask barry  to look at it as he claims to understand this distinction well.
<smoser> ah. is see.
<smoser> the url.open returns bytes
<smoser> easiest to just change that to  a string i think
<ScottK> Probably, but I haven't looked at the code, so I don't have a very valid opinion.
<bdrung> smoser: you need to decode/encode it as some kind of string if the url returns a string
<barry> sorry, i'm deep into a few other things atm.  i could possibly help later
 * ScottK looks for a minion to ping barry every 5 minutes IOT ensure his productivity is completely destroyed.
<jbicha> ScottK: thanks
 * barry needs no extra help destroying his productivity
<smoser> barry, bdrung anyeone.. if you want to look at https://code.launchpad.net/~smoser/ubuntu/quantal/apport/lp1018552/+merge/122147
<smoser> i'm pretty sure that is right (at least it seems to test right)
<smoser> but it seems like theres other hplaces there in ubuntu.py that should also need to be fixed.
<barry> smoser: is this python3?
<smoser> yes.
<smoser> apport is python3
<barry> smoser: i'm uncomfortable with the blanket str() conversion.  probably better to .decode('utf-8') assuming the bytes are coming back as utf-8.  the problem is you need to know the encoding, or be told it out of band.  or you can just cross your fingers which is what this is pretty much doing ;)
<smoser> barry, i changed it
<smoser> you're looking at old diff i think
<barry> smoser: ah, sorry
<smoser> if ami and ami.startswith(b'ami'):
<barry> yeah, that's probably better
<barry> bytes is bytes :)
<smoser> do you think there are othe rthing sin that file that need to be fixed?
<smoser> well. i'm gonna upload this one.
<barry> smoser: i can't really tell from the diff context.  i'd have to review the code, but i don't have any time right now to do that :(
<smoser> fine.
<smoser> i'm uploading this one now
<soren> hallyn: Oh, ok. Interesting. That's good to know. Thanks!
<soren> hallyn: (re: upstart jobs and pre-stop and post-stop stanzas)
#ubuntu-devel 2012-08-31
<cjwatson> roaksoax: if you're going to ping me while I'm on vacation (or just generally, really), please at least tell me what it's about so I know whether I need to interrupt vacation for it ...
 * cjwatson should dust off that old contentless_ping.pl IRC script
<pitti_> Good morning
<sladen> morgen
<pitti_> smoser: can you please commit your apport changes to bzr?
<ricotz> pitti_, good morning
<ricotz> pitti_, i hope you have a moment to look at https://bugs.launchpad.net/ubuntu/+source/clutter-gst/+bug/1040930 ? it is already in the new queue
<ubottu> Launchpad bug 1040930 in clutter-gst (Ubuntu) "FFe: Sync clutter-gst-2.0 1.9.90-1 (universe) from Debian experimental (main)" [Wishlist,Fix committed]
<micahg> ricotz: he's not on the release team anymore IIRC
<ricotz> micahg, Laney approved it, it just needs an archive admin to unlock it, i think
<micahg> ah, ok
<pitti_> ricotz: you mean source NEW reviewing it?
<pitti_> oh, it's a sync, c'est facile
<ricotz> pitti_, yes, it is just a rename of clutter-gst with packaging adjustments so it is co-maintainable
<pitti_> ricotz: I can't see clutter-gst-2.0 in experimental
<pitti_> so it's not a sync?
<ricotz> pitti_, it is still in the new queue of debian
 * pitti_ NEW reviews
<ricotz> the fake-sync package in the quantal new queue
<ricotz> pitti, thank you
<pitti> ricotz: it's missing a few copyrights in debian/copyright
<pitti> ./clutter-gst/clutter-gst-auto-video-sink.h -> Fluendo, ./clutter-gst/clutter-gst-video-sink.c -> RedHat, etc
<pitti> licensecheck -r --copyright .
<ricotz> pitti, i see, i feared that :\
<ricotz> it didnt touch the copyright file
<ricotz> s/it/i
<pitti> ricotz: the rest looks fine to me; can you please add these two or three and reupload? (same version number is fine)
<pitti> I'll accept it then
<ricotz> pitti, ok, thanks
<pitti> smoser: ah, found the diff on LP; I'll revert your changes to .bzr-builddeb and dropping .bzrignore, and commit the actual fix
<pitti> smoser: committed; please use the Vcs-Bzr: branch next time
<ricotz> pitti, http://people.ubuntu.com/~ricotz/clutter/
<pitti> ricotz: debdiff LGTM, except
<pitti> -  [ Iain Lane ]
<pitti> +  [ Ian Lane ]
<pitti> :)
<ricotz> pitti, wow, sorry
<ricotz> one sec
<ricotz> pitti, fixed
<pitti> ricotz: danke, please upload and I'll wave it through
<ricotz> pitti, i can't upload it
<pitti> oh? no MOTU yet? I'd vouch for you :)
<ricotz> pitti, not yet :\, good to know :)
<pitti> ricotz: accepted
<ricotz> pitti, :)
<dholbach> good morning
<jibel> pitti, guten Morgen
<pitti> bonjour jibel
<jibel> pitti, software-center tests triggered an apport crash
<jibel> pitti, https://jenkins.qa.ubuntu.com/job/quantal-adt-software-center/14/ARCH=amd64,label=albali/artifact/results/_usr_share_apport_recoverable_problem.1000.crash
<pitti> jibel: thanks, I'll fix it ASAP
<jibel> pitti, thank you
<jibel> mvo, https://jenkins.qa.ubuntu.com/job/quantal-adt-software-center/14/ARCH=amd64,label=albali/artifact/results/dsc0t-run-tests-stdout
<jibel> mvo, only 4 failures left
<pitti> progress!
<jibel> mvo, pitti finally I fixed --user in autopkgtest
<pitti> jibel: btw, I uploaded a new gvfs to fix the three failures, and added a new test; I asked #u-release to accept it
<pitti> jibel: the chmod $TMPDIR? I saw the Debian bug you sent, merci!
<jibel> pitti, does it sound reasonable http://paste.ubuntu.com/1176767/
<pitti> jibel: is .. guaranteed to be created by adt-run? if so, yes
<jibel> pitti, yes, it's the result of mktemp called earlier in the code
<mvo> jibel: yipiee
<mvo> jibel: I investigate now
<vibhav> Will gnomebuntu be maintained by Canonical?
<seb128> no
<seb128> it's a community maintained flavor
<seb128> like kubunutu xubuntu lubuntu...
<vibhav> ah, thanks
<xnox> ev: are there reports against `glade' on e.u.c all generated by me ?
<ev> xnox: :)
<ev> xnox: stick the sha512 hash of your system uuid on the end of https://errors.ubuntu.com/user/
<ev> and you can see all your reports
<xnox> ev: awesome! where do I get the _salted_ sha512 of my system?!
<ev> so something like printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
<mvo> jibel: fingers crossed, I commited what hopefully fixes the last test failure in the env
<xnox> ev: I doubt that computers manufactured in Latvia have that unique.... half of my lspci says "TO BE FILED BY OEM"
<ev> xnox: it's required for Windows logo certification
<xnox> ev: and my product_uuid is 00020003-0004-0005-0006-000700080009   which has striking resemblance to 23456789
<ev> but in Quantal we fall back to the sha512 hash of your mac address
<xnox> ev: my laptop came without an OS, unformatted hard drive & BIOS
<xnox> ev: hmmm... product_uuid didn't show any reports... lets try mac addresses
 * cking notes that we do see a lot of DMI tables that have the default "TO BE FILLED BY OEM" DMI strings or even UUIDs such as "0A0A0A0A-0A0A-0A0A-0A0A-0A0A0A0A0A0A"
<dupondje> any eta on kmod yet ?
<pitti> dupondje: apparently apw has packages in his PPA, but they weren't uploaded for some weeks; I'm a bit afraid it's too late now, with FF and all :(
<apw> pitti, is it really a feature, its like for like
<pitti> apw: it's not me saying "no" to it, I was just guessing :( (I'm not ~u-release any more)
<apw> pitti, will ask the question, kernel has been a bit mad the last two weeks everything blowing up
<pitti> apw: so, if it slips to R, I guess it's not a biggie
<apw> pitti, if it does i'll make sure it goes in day one
<pitti> we have a rather big plumbing backlog either way
<pitti> (newer udev, XDG_RUNTIME_DIR, the systemd d-bus services, etc.)
<pitti> jibel: I reproduced that m..__file__ crash in a new test case in apport, looking at it now
<jibel> pitti, good that adt find bugs :)
<pitti> jibel: fixed in trunk now, thanks for pointing out
<dupondje> pitti: but we already have a depend on kmod ... :)
<pitti> dupondje: this obviously cannot be true as we don't have kmod in the archive :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/oss-compat/+bug/992991
<ubottu> Launchpad bug 992991 in oss-compat (Ubuntu) "oss-compat uninstallable: depends on non-existent package kmod" [High,Triaged]
<niq> Just trying to report a bug (missing packaging dependency), but I can't because I can't even guess the launchpad captcha
<niq> any advice?
<niq> The bug is, libnids-dev requires pcap-dev as a dependency
<mitya57> niq: first, I think you meant "libpcap-dev" instead of "pcap-dev";
<mitya57> second, both these packages come unchanged from Debian, so it's better to report this bug to bugs.debian.org
<xnox> niq: launchpad does not have captcha.
<niq> xnox: https://login.launchpad.net/ckGDxTf7g9gWHMvs/+new_account has an impossible captcha
<niq> and it talks of OpenID, but won't accept OpenID :(
<niq> mitya57: thanks, I hd wondered about that, but thought my first port of call should be the platform I encountered it on
<xnox> niq: launchpad is an openid provider, it does not offer to consume/login with other openids.
<xnox> niq: this must be new. Click the small refresh icon until it's readable? I hate captchas =/
<niq> xnox: yep, so it tells us.  It seems unhelpful to feature OpenID on a login page, as it misleads the reader into looking for how to use it to login
<niq> Tried the refresh a few times, still can't do it
<niq> tried the audio but it's silent (firefox on ubuntu)
<xnox> niq: needs flash
<niq> got flash
<ev> mpt: I don't see this apport branch you've submitted
<mpt> ev, pitti merged part of it I think (I haven't merged trunk to check yet). He disagreed with some of the terminology, and said it was past UI Freeze (even though I proposed for trunk, not for Q).
<mpt> https://code.launchpad.net/~mpt/apport/warmer-text/+merge/121841
<pitti> hello mpt
<ev> ah excellent
<pitti> I still don't like to break all translations for strings which do not really change meaning, TBH
<pitti> and "a bit of a problem" really sounds quite sloppy to me
<ev> pitti: I didn't think it was about changing the meaning? I thought the intent was the make the text warmer
<ev> and more friendly
<ev> since it's a fairly jarring experience as it is
<ev> like what Mozilla does with it's "this is embarrassing" text
<pitti> but perhaps not up to the point of being sneering?
<ev> "a bit of a problem" comes across as sneering to you?
<pitti> and I do not consider changing "application" to "app" any helpful, and it just breaks translations, things like that
<pitti> ev: it certainly does, if the crash just ruined an hour's work or so
<pitti> perhaps that's just me
<pitti> I merged some bits of that MP, for giving some extra advice with hangs, and fixing the string for CLI apps
<pitti> where "closed" really doesn't make sense indeed
<ev> I do see your point, but I think the general approach of making the text more friendly is the right one. So hopefully we can find a sentence that forms the right balance.
<pitti> do you consider the current ones particuarly frightening?
 * apw has just updated and has gsetting data conversion implode ... anyone else seen that?
<smoser> pitti, :-( sorry.
<ev> pitti: I think there's room for improvement, yes. The request itself came from people with much more experience in usability than myself.
<xnox> ev: "this is embarrasing" is humorous "a bit of a problem" translates very bad into Latvian & Russian. It makes it sound more like "none of my business, your problem"
<ev> pitti: while I have you here, might I ask what the historical reason is for not having ARM retracers?
<ev> was it lack of space on ddebs?
<ev> xnox: yikes
<xnox> ev: ddebs should use $ xz -9
<pitti> ev: we actually had had some for a while, but since then we just never got around to setting some up
<pitti> ev: the main blocker is that RT ticket to move to a proper postgresql duplicate DB
<pitti> ev: as we cannot share the sqlite one between different hosts
<ev> right
<pitti> ev: i. e. pretty much the same problem that we have between "your" and "my" retracers now
<ev> so apport-retrace should be able to handle ARM just fine
<ev> pitti: speaking of whichâ¦
<pitti> yes, it does
<ev> I was thinking a bit more about it when I wrote the first state of the error tracker email
<ogra_> do the backends actually work nowadays ?
<pitti> ogra_: backends?
<pitti> the packaging backend is exactly the same for all arches
<smoser> pitti, what did "revert your changes to .bzr-builddeb and dropping .bzrignore, and commit the actual fix" mean?
<ev> as a shorter term solution, could we not just have errors.ubuntu.com create bugs and dup the matching apport bug for a given crash signature to them
 * ogra_ remembers when NCommander maintained the arm retracers we simply didnt have any 
<ogra_> pitti, doesnt the retracer need to run the package too ?
<pitti> there is not much that's platform specific, except perhaps the crash analysis from the disassembl
<pitti> y
<ev> and then if errors already has a bug but finds one from apport the next time it syncs the duplicate_database.db, it just dups it then
<pitti> smoser: see the diff: http://launchpadlibrarian.net/114069072/apport_2.5.1-0ubuntu3_2.5.1-0ubuntu4.diff.gz
<pitti> smoser: I reverted the .bzr-builddeb/ and .bzrignore changes
<pitti> ogra_: which package?
<ogra_> pitti, dunno, any arm packages actually
<pitti> ogra_: a retracer by and large needs a checkout of apport trunk, python-launchpadlib, and a good deal of CPU and IO capacity
<pitti> ogra_: sure, but fortunately we have them in an archive? :-)
<ev> I'm suspicious of this as I can't imagine it didn't come up in our previous discussion about uniting the retracers.
<smoser> pitti, sorry. fwiw, i didn't do that. it must have been a result of 'bzr bd -S'
<ev> can't imagine why*
<pitti> ev: right, that would work
<pitti> ev: crashdb.py already works like that
<ev> pitti: and you're happy with that for the near term?
<pitti> ev: i. e. if the DB says the master bug is #i, but that has been duped to #k, it updates the DB to #k
<ev> yeah indeed
<ev> I remember reading that when working on the shared duplicate db
<ev> I guess my concerns revolved around it being real time?
<pitti> ev: yes, absolutely; we really should stop having two retracer instances
<ev> well this would still have two retracer instances
<ev> but it would let us have bug numbers for the crash signatures that aren't in launchpad yet
<ev> eventually yes, we absolutely should move retracing to one system
<ev> or find some other way of reducing the duplication of work
<pitti> oh, you mean have the LP retracers look at the cassandra DB for master bugs, too, instead of (just) the .sqlite file?
<pitti> ev: ^
<ev> no
<ev> the lp retracers keep on doing their thing
<pitti> ev: we indeed do not have code for that, but if that's easier than swithcing the errors.u.c. retracers to retracing LP bugs
<ev> when errors.ubuntu.com encounters a signature that does not yet have a bug number associated with it
<ev> it creates a bug
<mpt> ev, sorry I don't have time to deal with this today. I'll explain to ivanka why it isn't fixed yet, and make another MP next Thursday.
<ev> when it later syncs the launchpad duplicates database, any time it finds a crash signature where it already has a bug number it just dups the new bug to what it has already
<ev> so no changes to crash-digger and friends
<pitti> ev: ah, yes, that d' work
<ev> excellent
<ev> mpt: no worries and cheers
<pitti> ev: the LP retracers need to deal with this anyway, as bug triagers also dupe/unify bugs, etc.; I'm fairly sure this works, it also has test cases
<pitti> (and the LP backend test suite finally works again)
<ev> mpt: maybe she can drive a conversation with you, me and pitti
<ev> if she feels that there's a good argument to be made
<ev> pitti: yeah, it builds on the existing design well, which I very much like :)
<ev> and the real time stuff still happens
<pitti> smoser: presumably you used lp:ubuntu/apport, not the Vcs-Bzr: one? the package importer might have screwed it up
<smoser> pitti, yes.
<pitti> ev: so yes, that seems like a good first step indeed
<ev> because the errors.ubuntu.com bugs exist immediately. So if someone finds an issue via the website, fixes it and notes it in the upload, it doesn't matter if we're only syncing every 15 minutes or so with the apport db
<ev> eventually everything will get sewn together
<pitti> ev: and at some point we shoudl get rid of the LP ones altogether; the errors.u.c. retracers already seem a lot more powerful anyway
<ev> and we still get the nice path of crash signature -> 80 steps -> fixed binary package that we can then show users
<ev> pitti: ja
<ev> we just rolled out another machine for it
<ev> though disk space is persistently tight
<pitti> and the LP ones are still leeching on the porter boxes
<ev> we were just talking this morning about easing back on the number of i386 retracers we have
<ev> oh this reminds me
<ev> we don't handle the situation where some sources are invalid in the retracer sources.list well
<ev> we lost retracing for a while when the oneiric sources that were in the precise sources.list went away
<ev> because python-apt considered that fatal or some such nonsense
<ev> I'll file a bug for that now
<pitti> ah, right
<pitti> ev: the LP retracers fail due to that, stop themselves, and send me cron mail
<xnox>  smoser, those files end up in package if the package is using 1.0 format & debuild -S was run in the bzr checkout, instead of using bzr bd -S. Or the original tarball had them =/
<pitti> ev: so I immediately fixed up the configs
<ev> ahh
<ev> surely we can make python-apt do the right thing though
<pitti> ev: that's why I use these lock files, so that we do not continue retracing/untagging/ruining bugs when there is something wrong
<ev> right
<pitti> ev: yeah, one of the gazillion settings in apt.conf might do
<ev> I need to work on feeding failed retraces back through
<ev> lol
<pitti> ev: sorry that I had to kill so many ddebs for older releases, but we keep running out of space on macquarie
<ev> no worries
<smoser> xnox, i'm certain i didnot run debuild -S. I do recall for some reason that it complained of not havin the upstream tarball and prompting me.
<pitti> and in doubt I'd rather sacrifice oneiric than the current dev release
<smoser> which i should have just backed out at that point.
<ev> pitti: remind me: do we have an RT for making ddebs less shoestring and gum?
<smoser> anyway. sorry for the garbage.
<xnox> smoser: hmm... =/ *sigh*
<pitti> ev: there should be an entire spec for that somewhere, hang on
<ev> pitti: I know I'm supposed to make apport-retrace fetch from the publisher, but slangasek was saying we still very much need ddebs.u.c for other stuff
<xnox> pitti: ddebs should learn about xz -9 -extreme for space saving? =)
<pitti> ev: I think we actually tried that, but LP apparently is still not ready to grab and put ddebs into the librarian
<ev> ahh
<ogra_> xnox, ddebs should be a binary patch against debs ;)
<pitti> ev: OMG no, as soon as LP gets them, this ddeb-retriever abdomination should die and never come back
<ev> silly launchpad, always getting in the way of progress
<ev> pitti: maybe mention that to him? :) I'll try to remember to
<xnox> ogra_: !0_0!
<ev> pitti: elmo didn't seem to be a huge fan of ddebs.u.c either
<pitti> of course it could still be called ddebs.u.c., but not with my manual mucking of apt-ftparchive and grabbing ddebs from buildd apaches over cron
<ev> hahaha
 * xnox reboot testing
<dobey> it would be nice if the dbgsyms archives were signed with the same key as the main archives, and if they were installable in the main builders via Build-Depends
<ev> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1044362
<ubottu> Launchpad bug 1044362 in apport (Ubuntu) "Gracefully handle invalid apt sources in apport-retrace" [Undecided,New]
<pitti> dobey: yes, but on macquarie I (rightfully) cannot access the secret archive key
<pitti> ev: I think it's pretty much these: https://bugs.launchpad.net/launchpad/+bugs?field.tag=ddebs
<pitti> plus, I believe there is still an unsolved problem of how to obsolete them, so currently they would quickly fill the librarian
<pitti> wgrant: ^ ?
<dobey> hrmm; in migrating from cdbs to plain dh, how does one specify dh_makeshlibs for a particular binary package? searching internet/wiki isn't helping
<seb128> dobey,
<seb128> override_dh_makeshlibs:
<seb128>         dh_makeshlibs -plibmessaging-menu0 -V'libmessaging-menu0 (>= 12.10.0)' -- -c4
<seb128>         dh_makeshlibs -Nlibmessaging-menu0
<seb128>  
<seb128> dobey, that's one example
<dobey> ah ok
<pitti> or more generally, dh_... --remaining-packages
<dobey> N: Unable to locate package libmessaging-menu0
<dobey> hmm :)
<dobey> oh is that new in q?
<pitti> --remaining-packages? no, that's been around since debhelper 7 or 8
<dobey> no, libmessaging-menu0
<pitti> apparently, according to rmadison libmessaging-menu0
<pitti> cjwatson: btw, do you know why rmadison is so abysmally slow these days? it used to take a second or so until a couple of months/weeks ago
<pitti> or is that just me?
<ogra_> its like 10.20 secs for me
<ogra_> 10-20
<ogra_> thugh my desktop runs precise
<pitti> judging by the time difference between dobey's and my replies, it was almost a minute for me
<Laney> laney@iota> time rmadison -u debian gnome-terminal >/dev/null                                       ~/dev/canonical/packaging/desktop/pidgin
<pitti> hm, of course it's fast now
<Laney> rmadison -u debian gnome-terminal > /dev/null  0.08s user 0.01s system 10% cpu 0.784 total
<Laney> laney@iota> time rmadison -u ubuntu gnome-terminal >|/dev/null                                      ~/dev/canonical/packaging/desktop/pidgin
<Laney> rmadison -u ubuntu gnome-terminal >| /dev/null  0.06s user 0.04s system 3% cpu 2.606 total
<seb128> dobey, pitti: sorry, that's indicator-messages in quantal
<pitti> perhaps relatively few people use it, and I was the first one to try and now warmed up its cache
<dobey> pitti: i didn't use rmadison; was using apt-cache show
<dobey> pitti: anywya, what did you mean about --remaining-packages exactly? using that instead of -N for the second dh_makeshlibs in the override?
<pitti> dobey: yes; you can run dh_* for a bunch of explicit -P with special arguments
<pitti> and then dh_* --remaining-packages for all packages you haven't touched (with that particular dh_*) yet
<pitti> see man debhelper
<dobey> ah ok
<pitti> -Npkg1 -Npkg2 ... works as well, of courese
<pitti> "course"
<ev> pitti: out of curiosity, how are you checking for retracers failing due to invalid sources.list files? apport-retrace doesn't use exit codes as far as I can see.
<pitti> ev: IIRC, apport-retrace crashes with an exception, and crash-digger sees that the exit code is not 99, and does not remove the lock file
<pitti> the exception appears on stderr, which I get cron-mailed
<ev> oh interesting
<ev> cheers
<ev> pitti: 99 being apt having a transient network problem, right?
<pitti> ev: any transient problem, but it's only being used for Launchpad exceptions ATM
<ev> cool
<pitti> since I got bored having to restart them whenever LP wants decides to have a boo-boo
<pitti> s/decides//
<xnox> pitti: thank you for the 'md0 -> md127' comment / pointer! How could I forget about the homehost.... =)
<pitti> xnox: I didn't know about it either
<xnox> pitti: I knew it, but I forget about it, cause most of my mdadm testing happens on the same $hostname across reboots.
<slangasek> SpamapS: where did we ever get to wrt events being emitted for each sysvinit job that starts/stops?
<slangasek> SpamapS: I'm asking because the ifupdown-runlevel-1 bug is now sorta in the way of normalizing upstart in Debian
<slangasek> SpamapS: aha, we have 'unmounted-remote-filesystems', ok
<rbasak> I'm going to need linux 3.2.0-30 in precise-updates d-i netboot for maas to deploy highbank correctly. It's got an RTC fix I need, and is in precise-proposed at the moment. What's the policy on bumping d-i in a stable release in order to get a new kernel?
<arges> infinity, hello. looking at the lucid fix for pad.lv/979003 right now. first is pad.lv/956051 considered a dup?
<arges> infinity, second, stokachu  posted a debdiff for precise that builds, do i need to re-subscribe something to get this on the SRU list?
<infinity> arges: They're not technically dupes.  One is AVX, the other is FMA4, but the fix for both comes from the same patchset.  What's not clear to me without having the right hardware to test is if the FMA4 bug even applies to lucid.
<infinity> arges: lucid's glibc might be old enough that it doesn't even care (and therefor care incorrectly) about FMA4, in which case, the simpler AVX-only fix can be backported.
<infinity> arges: As for precise, there's been a larger and more correct fix from me in the queue for weeks.
<infinity> arges: (By "in the queue", I mean it's uploaded, just needs review and acceptance into proposed)
<arges> infinity, ok. yea for the lucid one, I  proposed the original patch in 979003 that should just disable AVX if we don't detect support in the kernel
<infinity> arges: See https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<infinity> arges: Yeah, the simple patch you proposed (the same as the one Debian's using, AFAIK) should do the "right" (rather violently) thing for Intel, I'm unsure about AMD without someone doing some testing.
<arges> infinity, ok so need to track down some AMD hardware...
<infinity> arges: It was definitely incomplete for precise (which is why I went with the much more complete fix), but older versions of glibc are missing half that code to start with. :P
<infinity> arges: Carlos and I were going to sit down and work on proper 2.13 and 2.11 backports upstream, but I think we kinda burned out after the 2.16 and 2.15 fix-test-release cycle.
<infinity> arges: To be fair, the "simple" patch may also need some fiddling for some corner cases.  But I *think* it'll just happily break AVX support completely even in cases when it shouldn't, which is marginally better than the other direction (sometimes keeping it on when it shouldn't).
<arges> infinity, ok i'll build a test package and see if somebody can verify on AMD/AVX/Lucid
<arges> with the first patch
<infinity> arges: I'm running around between conference rooms right now, but can you make a note to discuss this mor in-depth with me on Tuesday?
<infinity> arges: I agree that any fix is probably better than no fix at this point, but I also want to make sure it's as sane as we can get it.
<arges> infinity, sure will do... are you at plumbers?
<infinity> arges: Yeah.
<arges> infinity, cool. Yea i'll set something up
<infinity> arges: My gut feeling is that the FMA4 (AMD) bug shouldn't be an issue for lucid at all, cause I think the FMA4 code was introduced in 2.15.  Being able to test that for sure would be nice, though.
<infinity> arges: So, basically, someone who can reproduce 956051 on precise, but not on lucid, would be a good datapoint.
<arges> infinity, so that should just be bulldozer chips and later right?
<arges> yes
<infinity> arges: I've not paid attention to codename roadmaps in years, so not sure what a bulldozer is. :P
<arges> infinity, i believe its the model that has those extensions... anyway i'll do a bit more digging and set up some time to chat on tuesday
<infinity> arges: Spiffy, thanks.
<infinity> arges: And I'll try to coordinate with an SRU/AA member who isn't me to make sure the precise upload actually gets reviewed and accepted, now that precise isn't frozen anymore.
<infinity> arges: I missed the 12.04.1 window by just enough that we decided to delay it.
<arges> cool
<Logan_> jelmer or jml: ping
<jelmer> Logan_, pong
<Logan_> jelmer: could you please perform $ requeue_package.py --full empathy
<Logan_> per https://bugs.launchpad.net/udd/+bug/714622 - it's one of the 199 packages that fails to import, and I want to fix a bug :P
<ubottu> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed]
<jelmer> Logan_, done, thanks to mgz
<Logan_> jelmer: thank you :)
<Logan_> jelmer: do you know when I'll be able to branch the newer version? will it take a while to import?
<jelmer> Logan_, Martin said he used --priority so hopefully it will be pretty quick
<Logan_> awesome - I'll try in about an hour
<Logan_> thanks again!
<xnox> Is the circular dependency between grub-pc & grub-gfxpayload-lists well known on Lucid -> Precise upgrades?
<xnox> bug 1044499
<ubottu> Launchpad bug 1044499 in grub-gfxpayload-lists (Ubuntu) "package grub-gfxpayload-lists 0.6 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/1044499
<slangasek> xnox: I don't think it is
<xnox> slangasek: in grub-pc Conflicts: grub-gfxpayload-lists (<< 0.6)
<xnox> this should make grub-gfxpayload-lists be removed -> grub-pc upgraded -> new grub-gfxpayload-lists pulled in?
<xnox> or "new style" Brakes
<slangasek> xnox: Conflicts: << are strongly discouraged; is there a reason you need it to not be on the filesystem at the same time as the unpacked (but not yet configured) grub-pc?
<xnox> should be ok. as long as apt breaks the dependency cycle correctly with breaks.
<xnox> Also my fix for bug 978464  got reverted to "work around" bug 1009294 . Should this be fixed.....
<ubottu> Launchpad bug 978464 in grub2 (Ubuntu Quantal) "After LTS->LTS (lucid2precise) upgrade, upon reboot drops into grub recovery shell" [Critical,Fix released] https://launchpad.net/bugs/978464
<ubottu> Launchpad bug 1009294 in Ubuntu Precise "Grub update breaks automated dist-upgrade scripts on AMI images" [High,Fix released] https://launchpad.net/bugs/1009294
<xnox> wait....
<xnox> ignore me, it was deleted from -proposed
<Slayz> Hi. I am thinking of creating my own distribution based on ubuntu. Do you want to give me some words for this journey?
<cjohnston> good luck
<wjtaylor> How does gnome volume control interact with alsa?
<wjtaylor> I can't unmute my recording inputs in gnome, but ALSA seems to be set up correctly. Can I make these changes manually from the CLI
#ubuntu-devel 2012-09-01
<bjf> slangasek: looks like i have another biosdevname issue on a different server. it has biosdevname 0.4.1-0ubuntu2 installed on it. would you like a new bug or for me to add a new set of logs to the existing bug?
<cjwatson> new bug please
<bjf> cjwatson: ack
<cjwatson> your previous bug was very definitely just "biosdevname incorrectly not installed"
<cjwatson> bjf: oh, that said, we need a new debian-installer upload to incorporate my biosdevname fix
<cjwatson> bjf: so it might be worth holding off until that's in place just in case ...
<cjwatson> I'll sort out that upload before I go to bed
<cjwatson> shadeslayer: figured out that "isohybrid: binary.hybrid.iso: boot loader does not have an isolinux.bin hybrid signature" bug - it's a curious misbuild of syslinux-themes-ubuntu
<bjf> cjwatson: ack, i'll hold off
<bjf> cjwatson: i had added biosdevname to my preseed and i was getting the latest version. should i still wait for d-i changes?
<cjwatson> bjf: briefly, at what point are things failing?
* infinity changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bjf> cjwatson: i just reprovisioned a system, ifconfig -a says it has em1, em2, em3, em4 but "rename3" is in /etc/network/interfaces
<cjwatson> bjf: ok, go ahead and file that separately
<bjf> cjwatson: ack
<cjwatson> infinity: could you please push your last d-i upload to bzr?
<infinity> I so did.
<infinity> I blame the network here.
 * infinity gets out and pushes harder.
<infinity> Also, CIA is buggered.
<cjwatson> Yeah, server-side so can't do much about it
<cjwatson> I've been ignoring the giant tracebacks which are the client's response to the server ignoring it
<infinity> cjwatson: Committed and tagged, sorry about that.
<cjwatson> ta
<infinity> cjwatson: I suppose we could at least make cia-clients fail gracefully with a "remote is having a sad" message, instead of taking three weeks thinking before spewing a backtrace of doom.
<infinity> Or I could just un-cia all my checkouts.
<cjwatson> Or hack the client locally to be a no-op, which is probably better than unconfiguring a load of stuff one by one.
<cjwatson> I agree the current behaviour is suboptimal.
<Logan_> jelmer: it works now :)
<darkxst> jbicha, which GTK theme will you be using?
<darkxst> I have noticed that with the ambiance theme, the volume popup is now white
<darkxst> however I don't know if this is a bug or intentional on ubuntu's part
<pillarsdotnet> Packaging question: How can I make an amd64 package depend on libjpeg62:i386 ? https://bugs.launchpad.net/ubuntu/+bug/502920
<ubottu> Launchpad bug 502920 in Ubuntu "[needs-packaging] Canon UFR II driver needs packaging" [Wishlist,Confirmed]
<penguin42> any tags to use for 'permanently bricks machine' bugs? bug 1040557
<ubottu> Launchpad bug 1040557 in debian-installer (Ubuntu) "UEFI boot live-usb bricks SAMSUNG 530U3C laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
<nandersson_> Hi, I am setting up Ubuntu Core in a qcow2-filesystem that I now have mounted and chrooted. My final  steps would be to install the kernel (vmlinuz) and setup the bootloader. What would be best practise to pupulate /boot with vmlinuz? Should I do it by doing "apt-get install linux-generic" from within my chrooted environment, or should I copy vmlinuz, initrd and /lib/modules/$(uname -r) from my host?
#ubuntu-devel 2012-09-02
<cjwatson> penguin42: tags: don't care - but I've commented and reassigned that to the right place
<penguin42> cjwatson: Thanks, it's a bit nasty that one
<penguin42> cjwatson: There's an article somewhere by Matthew Garrett about efi bricking due to one bug he ran across
<cjwatson> Fundamentally I wish somebody else would deal with this in Ubuntu so that I don't have to fumble around guessing
<cjwatson> Anyway, after celebrating a wedding I should really be in bed not looking at ghastly bug reports :-)
<penguin42> hmm bed, that is a good idea
<nob> Anybody here know much about u1db
<cc11rocks> I want to fix bugs for Ubuntu 12.10
<cc11rocks> I'm assuming if I'm running that in a virtual machine, I have to install the dev packages and such (and make changes in/to) the guest image?
<MCR1> cc11rocks: http://developer.ubuntu.com/packaging/html/getting-set-up.html#upload-your-gpg-key-to-launchpad
<cc11rocks> I want to fix bugs (development). Should I be on this channel or #ubuntu-moto? If I should be on -devel or -motu, what is the different between the channels?
<MCR1> cc11rocks: Best for you would be to read the above link and execute necessary steps to get into development
<cc11rocks> Yes, I'm asking WHERE I set this up at?
<cc11rocks> Not how...
<cc11rocks> I already took notes on the Ubuntu Dev Week logs
<cc11rocks> I just need to know where to set up. In Ubuntu 12.10 or in current OS?
<MCR1> cc11rocks: If you want to fix a bug, bzr branch the source, fix the bug locally, commit it, create a branch on your launchpad account containing the fix and then propose this branch for merging :)
<cc11rocks> Okay thanks
<cc11rocks> So even if I'm fixing a bug for Ubuntu 12.10, I can fix it locally in Ubuntu 12.04?
<MCR1> yes
<MCR1> you might not be able to test your fix in all cases then, but you can still fix it ;)
<cc11rocks> Okay, thank you for your help
<cc11rocks> Do you know about the motu vs dev channel difference?
<MCR1> nope, sorry
<MCR1> cc11rocks: but development does not happen on the IRC channels - those are usually VERY quiet
<cc11rocks> Okay, thanks
<cc11rocks> I mean for help...
<cc11rocks> Considering I will be just starting fixing bugs, I'll probably need it
<MCR1> cc11rocks: Here you can see how development of Unity happens for example: https://code.launchpad.net/~unity-team/unity/trunk/+activereviews
<MCR1> cc11rocks: Follow the guide I posted to get set up...
<cc11rocks> iulian in moto said : "cc11rocks: Both and you might want to join -packaging as well. The difference is that -motu deals with unseeded packages and -devel with core packages."
<MCR1> aha, thx ;)
<cc11rocks> No problem.
<Bluefoxicy> lol
<Bluefoxicy> lol @ udd
<Bluefoxicy> apparently encryptfs doesn't actually include security.
<penguin42> ?
<cc11rocks> have run "bzr branch ubuntu:" + "happycoders-libdbg-dev" & "opj2dat" & "liborigin0" & "liborigin0-dev", etc. They ALL return bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/" + $packageName + "/"."
<cc11rocks> I ran them individually of course. I was just doing it in a quick format...
<cc11rocks> If any of you gave an answer, if you could repost as I had to restart lightdm...
<trism> cc11rocks: no answers, what are you trying to do? usually you would branch the source package, such as: bzr branch lp:ubuntu/libdbg
<cc11rocks> Okay, thanks
<cc11rocks> I'm just trying to get started by fixing one of the basic bugs at https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
<cc11rocks> It worked,thanks
<cc11rocks> Completed first bug fix : https://code.launchpad.net/~cc11rocks/ubuntu/quantal/libxml-csv-perl/typo-fix
<cc11rocks> Now what?
<cc11rocks> Etc : How do I know if my change is accepted, etc?
<trism> cc11rocks: click the "Propose for merging" button on your code.launchpad.net branch page, enter the information and then you will get email updates when somebody reviews the change
<cc11rocks> This correct? https://code.launchpad.net/~cc11rocks/ubuntu/quantal/libxml-csv-perl/typo-fix/+merge/122418
<trism> cc11rocks: looks fine to me
<cc11rocks> Thanks for your help trism :)
<cc11rocks> Have to go eat, then to work, but I'll try to fix some more basics when I get home :)
<iulian> robert_ancell: I can see that you've recently uploaded nemiver and gthumb. Do you have FFes for them?
<robert_ancell> iulian, no they contain only bug fixes, do they need ffes?
<jtaylor> Logan_: do you know if ruby-vmc can use ruby-json instead of ruby-json-pure?
<jtaylor> Logan_: ruby-json-pure is in a bad state and if ruby-vmc does not need it we should probably remove it (unless someone fixes it)
<Logan_> sec
<Logan_> jtaylor: okay so
<Logan_> according to http://rubygems.org/gems/vmc , one of the runtime dependencies is json_pure < 1.7.0, >= 1.5.1
<Logan_> so it appears to be a "yes," it needs it
<Logan_> I haven't tested it without ruby-json-pure, though
<iulian> robert_ancell: No, they don't, sorry. I just got lost in those big diff files and it appeared to me that some new functions were added. I've just read the ChangeLog and it's all good.
<jtaylor> Logan_: from what I ahve been told -pure is the same as nonpure just nonpure is using a C extension and is thus faster
<jtaylor> but won't work with other interpreters
<Logan_> okay, interesting
<iulian> robert_ancell: It'd be nice if you could mention "bug fix release" in the changelog in the future.
<robert_ancell> iulian, ok, will do
<iulian> Thanks.
#ubuntu-devel 2013-08-26
<TheMuso> /c/c
<RAOF> Is there some particular reason that armhf annoyingly languishes on ports.ubuntu.com, making it really annoying to have as a dpkg foreign architecture?
<stgraber> I believe not enough space on the archive mirrors (not those from IS, those in universities, ISPs, ...) was the usual response to that question.
<stgraber> basically adding armhf there would make us loose a potentially significant number of our current mirrors
<RAOF> Ah, of course.
<RAOF> I don't suppose they support any "don't mirror this, kthxbye" metadata? That would be too convenient.
<StevenK> RAOF: Which is difficult, due to pool/
<stgraber> RAOF: they'd need to run something like debmirror to achieve that, which they usually don't (most mirrors are simply straight rsync from archive.u.c)
<infinity> RAOF: It's a traffic/space tradeoff.  If and when armhf represents a significant portion of our traffic, we'd consider bloating mirrors and moving it.
<infinity> RAOF: Agreed on the awkward apt foreign arch setup, though, we could perhaps do something to make that less irritating.
<infinity> RAOF: (ie: if x86 mirror is *.ubuntu.com, use ports for !x86 automagically)
<RAOF> Or support [arch=!armhf] in sources.list
<RAOF> Hm. Or have an option requiring an explicit opt-in for non-native archs.
<pitti> Good morning
<pitti> slangasek: I tried upgrading without the transitional package (I didn't have that at first); the upgrade worked in some cases (my test in a chroot), but in others (me on work station and seb128) apt just held back stuff
<slangasek> pitti: well, but the transitional package appears to be incorrect, it doesn't implement the interface... so any third-party packages will be broken
<pitti> hm, if we can do something about /usr/lib/x86_64-linux-gnu/libgphoto2/print-camera-list it should actually be possible to make them co-installable
<pitti> but libgphoto2-portX aren't co-installable
<pitti> or wait, unless the /usr/lib/x86_64-linux-gnu/libgphoto2_port/0.10.0 is different in the older version
<pitti> slangasek: fix uploaded
<StevenK> pitti: Have you heard anything about calibre SEGVing on startup on current saucy?
<pitti> StevenK: not yet, but it seems I can reproduce
<pitti> I guess there's a new sip ABI once again
<pitti> StevenK: it'll need a rebuild, but I'll package 1.0 while I'm at it
<StevenK> pitti: Sounds excellent, thanks.
<dholbach> good morning
<mlankhorst> g'day
<dholbach> hi mlankhorst
<mlankhorst> heya
<dholbach> salut lool - Ã§a va?
<dholbach> lool, did you file the bug on click regarding permissions?
<hyperair> any archive admins around? messagingmenu-sharp is waiting for an ack. :)
<hyperair> (for several months now)
<seb128> hyperair, hey, didn't infinity said he would do it on friday?
<hyperair> yeah, but i forgot to ping him
<hyperair> i think i pinged yesterday or the day before, but didn't get a response
<seb128> that was w.e
<seb128> jibel, hey, welcome back, did you have good holidays?
<jibel> Salut seb128 , holidays were great, thanks
<seb128> jibel, nice!
<seb128> jibel, so, since you are back ... not sure anyone pinged you about that, but autopkgtest/britney seems unhappy for a week (and nobody was able to debug it with you and Colin not there)
<seb128> jibel, tests stay in RUNNING state
<seb128> eg http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has cups -> chromium-browser RUNNING
<seb128> or dh-python -> dh-python RUNNING
<seb128> jibel, could you help there? ;-)
<jibel> seb128, yes, pitti told me, I'm looking at this this morning
<seb128> jibel, thanks
<seb128> xnox, hey, did you see that your ardour uploads failed to build?
<Noskcaj> doko, Do you mind if i merge the latest debian revisions of python2.7 and 3.2?
<Noskcaj> oops, 3.3
<Noskcaj> doko, or more accurately, sync them, as i can't find a reason to keep the delta
<siretart> infinity: how do you think about doing the libav9 transition for saucy? I've noticed micahg and jbicha chatting about that yesterday in #ubuntu-motu
<ari-tczew> Noskcaj: don't you use requestsync script for syncs?
<smartboyhw> ari-tczew, I think Noskcaj's requestsync keep crashing
<smartboyhw> That's what I heard from him
<ari-tczew> smartboyhw: ok
<lool> dholbach: salut ! sorry, missed your ping; I doubt there is a permission issue with click, at least I couldn't reproduce it; I had other minor permission issues (due to adb shell's umask) which I reported, but the main being issue is packagekit crashing on installation
<dholbach> ok
<lool> dholbach: I started gdb-ing this a bit on friday, but was lacking -dbgsym for packagekit; resuming today I've seen there's packagekit-dbg which might be enough
<lool> the packagekit log dies with some warnings on percent count decreasing
<lool> but nothing interesting there
<infinity> siretart: I'd love to slide it in before feature freeze.  It'll be tight timing to get us to finish the transition, but I'd rather have it done and out of the way before we open 14.04 than agonize over whether or not we do it in an LTS cycle.
<infinity> siretart: I'm heading to bed right now (It's 4am), but if you want to start without me, you have my blessing, or we can discuss it when I wake up. :P
<jibel> seb128, incorrect RUNNING state is fixed, I'm now trying to understand the cause.
<seb128> jibel, thanks!
<pitti> jibel: was it due to per-arch tests arriving at differnt times?
<jibel> pitti, I do not know yet, I'll tell you when I'm sure.
<pitti> StevenK: ah, calibre 1.0.0 finally got imported, synced
<StevenK> pitti: Nice, thanks!
<dholbach> mitya57, 1180067 uploaded
<dholbach> mitya57, the test build took a while ;-)
<mitya57> dholbach: BIG thanks!
<dholbach> mitya57, no worries
<pitti> hm, what's the easiest way to find out why signond-dev isn't installable on powerpc?
<pitti> (https://launchpadlibrarian.net/148449058/buildlog_ubuntu-saucy-powerpc.shotwell_0.14.1-3ubuntu3_FAILEDTOBUILD.txt.gz)
<pitti> it's not on http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html
<pitti> but perhaps related to these qt depwaits
<pitti> hm, how did https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+changelog get into saucy in the first place? it didn't build on powerpc (depwait), thus it shouldn't have migrated?
<pitti> ah, https://launchpad.net/ubuntu/+source/qtjsbackend-opensource-src/5.0.2-3 isn't supported on ppc -- so how did that stack propagate, was it forced?
<seb128> pitti, yes, it was, and signon was deleted on ppc
<seb128> pitti, that stack can't exist on ppc, qtdeclarative uses v8 that's not available on ppc
<seb128> pitti, we had to do some forcing since some of those sources existed before (qt4 was available on ppc)
<pitti> seb128: but libsignon-glib-dev still exists on ppc and is now uninstallable
<seb128> pitti, drop ppc?
<pitti> seb128: it sounds wrong to drop shotwell on ppc, it doesn't use any of this?
<pitti> not that I care about ppc in any way, but changing all transitive reverse deps of that to drop ppc sounds very intrusive
<seb128> pitti, reality is that modern desktop don't run on ppc
<seb128> pitti, well, we patch shotwell to use ubuntu-online-accounts, which create that depends
<pitti> seb128: i. e. libsignon-glib binaries shoudl be dropped from ppc, and shotwell not built against it on ppc?
<pitti> ah
<seb128> pitti, we should probably stop doing that
<pitti> seb128: i. e. we somehow need to apply debian/patches/06_uoa.patch on !powerpc only?
<seb128> pitti, right
<pitti> pain
<seb128> pitti, but that's the tip of the mountain I think
<pitti> I guess I'd rather drop ppc from shotwell's arch:
<seb128> pitti, you are going to have similar issues in lot of desktopish components
<seb128> pitti, yeah, that might be easier
<seb128> pitti, and to reply to your britney comment, britney prevent increasing the number of issues, it doesn't enforce it to be 0
<seb128> pitti, e.g if a package never existed in an arch it's fine for it to migrate without that arch
<pitti> ah, so if I remove shotwell ppc from saucy and reupload with arch: i386 amd64 armhf, it ought to work?
<seb128> pitti, which is the case of qt5 and its rdepends
<pitti> ah, I don't even need to touch the arch: field then
<pitti> if that should ever get fixed, it'll just build again on ppc
<seb128> pitti, right, just deleting the binary should be enough (unless something depends on shotwell)
<seb128> pitti, correct, that's the best way (and why we keep other packages depwaiting on ppc)
<pitti> quite some meta packages do
<seb128> they depends or recommends?
<pitti> ah, recommends
<seb128> well, let's try deleting the binary on ppc and see what britney says
<pitti> done
<pitti> seb128: thanks for the explanation
<seb128> pitti, yw!
<ari-tczew> do we need to keep patches to fix DSO linking (in my case, patch from natty) in saucy?
<geser> if it's still needed then yes
<pitti> ari-tczew: just try p/sbuilding it without; you'll see if it still fails
<ari-tczew> pitti: without that one builds fine, just asking to make sure
<ari-tczew> but it's odd described in d/changelog: Resolve unresolved symbols in shared library.
<pitti> ari-tczew: these kinds of patches usually fixed build failures like "link failure: unresolved symbol blabla"
<pitti> ari-tczew: so it looks like you can drop it
<ari-tczew> thanks pitti!
<tvoss__> pitti, ping
<pitti> tvoss__: I just spoke 5 mins ago :)
<pitti> tvoss__: hey, wie gehts?
<ari-tczew> tjaalton: you have dropped a part of changes in merge libxvmc, but there is no info about that in d/changelog. could you explain me why these changes have been dropped?
<ari-tczew> (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/libxvmc/saucy/revision/16)
<tjaalton> ari-tczew: what changes?
<ari-tczew> tjaalton: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/libxvmc/saucy/revision/16 that's the merge done by doko
<ari-tczew> in your merge there are no changes in files d/rules and d/libxvmc1.install anymore
<ari-tczew> that's merge done by you http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/libxvmc/saucy/revision/18
<ari-tczew> tjaalton: i'm going to merge latest libxvmc from Debian and I can re-add the dropped changes, but I'm asking whether there is a reason to drop them or it was a false
<pitti> seb128: ah, shotwell propagated now, good
<seb128> pitti, excellent ;-)
<pitti> it seems britney doesn't wait for a successful autopkgtest, though
<seb128> pitti, is that how jibel fixed the "waiting for ever"? ;-)
<pitti> no, I think it's always been that (buggy) way
<pitti> if you introduce a new autopkgtest, then that won't be considered for propagation, only from the second time on
<pitti> like, if it would only consider tests which already exist in saucy
<seb128> oh, right
<pitti> which is how all these broken autopgktests make it into saucy in the first place
<tjaalton> ari-tczew: it was a year ago, no idea
<tjaalton> ari-tczew: do whatever works, but we'd like to host the diff in git.debian.org
<sil2100> slangasek: hi! Are you around?
<sil2100> slangasek: I think we'll have to schedule a meeting for UDS that would discuss the issue of FFe for Ubuntu Touch packages
<sil2100> slangasek: Didier asked me to make sure it's discussed on UDS anywhere
<sil2100> slangasek: we can of course attach it to some other meeting, but I guess we need to figure out to which
<xnox> seb128: yes, i know. I fixed 1 out of 2 problems with it, to make FTBFS more obvious.
<ari-tczew> tjaalton: you mean forward that change to Debian?
<slangasek> sil2100: I don't understand why we would need a UDS session to talk about an FFe for Ubuntu Touch packages; the FFe bug is already opened?
<sil2100> slangasek: because we want people to be aware that not only touch packages will need FFe's - since there are many many components that are shared between desktop and touch
<sil2100> slangasek: those might need FFe's as well
<sil2100> slangasek: for instance libunity is used for both, and most probably there will be changes needed for touch in it
<sil2100> So libunity, as one example, will also need FFe's - and I am to make sure that it will be clear to everyone
<spindritf> I need some packages that are not available in the official repo, I though I would use a PPA for that -- is this http://developer.ubuntu.com/packaging/html/ up-to-date documentation I should peruse for that?
<smartboyhw> spindritf, yes
<spindritf> thanks, smartboyhw
<roadmr> xnox: hello, sorry to trouble you, could you please have a look at bug 1216853? pxe installs over nfs are broken in 12.04.3 :(
<ubottu> bug 1216853 in casper (Ubuntu) "During PXE booting failed to mount nfs directory" [Undecided,New] https://launchpad.net/bugs/1216853
<janimo> ogra_, do you think it would make sense to take $ARCH into account in livecd-rootfs's auto/config and pass it to lb config?
<janimo> ogra_, I am again trying to build i386 touch image equivalents on an amd64 host
<ogra_> dont we take ARCH into account ?
<ogra_> i thought BuildLiveCD does
<ogra_> and calls live-build appropriately
<ogra_> janimo, you have to do it from a wrapper i guess
<janimo> ogra_, it is looked at in auto/build but apparently not in auto/config
<ogra_> janimo, i was actually pondering rootstock-ng :) which would be such a wrapper around the live-build calls
<janimo> ogra_, as an alternative to livecd-rootfs?
<ogra_> no
<janimo> aren't there too many scripts already?
<ogra_> as an alternative to BuildLiveCD
<ogra_> which is the actual master script
<janimo> and still no one-liner to exactly reproduce all our images
<ogra_> thats why
<ogra_> rootstock-ng --seed=ubuntu ...
<ogra_> something like that would be what i aim for
<janimo> ogra_, the android package in multiverse is the contents of the LXC container packaged as a deb?
<ogra_> i think thats just the binary blobs
<ogra_> xnox could help you with more details ... but UK is on a pleasure trip today :)
<mterry> xnox, will upstart 1.10 be pushed to saucy this week?
<slangasek> mterry: should be, but today's a bank holiday in the UK
<mterry> slangasek, gotcha
<slangasek> ogra_: https://blueprints.launchpad.net/ubuntu/+spec/foundations-s-phone-usb-shell looks like it may be a duplicate of https://blueprints.launchpad.net/ubuntu/+spec/appdev-1308-app-developer-mode; do you think we need two sessions about this?
<ogra_> slangasek, we surely dont, i was asked by plenty of people to register this spec though
<ogra_> so i think we definitely need one
<slangasek> ogra_: ok, marked as superseded
<xnox> mterry: it should be. jodh will be merging it and it should hit saucy this week, before thursday.
<ogra_> slangasek, which one ?
<xnox> janimo: ogra_: the android package ships system.img both as .img and .zip, so yes that's LXC container contents, in a deb.
<ogra_> slangasek, mhall119 doesnt relly go into technical detail
<ogra_> xnox, ah, i thought that was in main
<janimo> xnox, thnanks
<slangasek> ogra_: marked yours as superseded by the other, if more technical details need to be added feel free to take over the blueprint? :)
<ogra_> nah, i'm fine
<slangasek> ogra_: but if we're agreed that we don't need two separate sessions, let's use the one session to the fullest
<xnox> ogra_: it's in multiverse with M.I.R. for restricted in progress.
<ogra_> that at least means i dont have to run the session now :P
<ogra_> xnox, ah, ok ... now go away from your keyboard ! :)
<xnox> ogra_: =)
<xnox> ogra_: i don't want to cook bbq, so i'll just wait here until it's all done =))))
<ogra_> haha
<ogra_> enjoy
<slangasek> sil2100: so I still don't understand how it's useful/relevant to have a UDS session about this; the FFe process is that you file bug reports, say what you need, and discuss with the release team in the bug log
<slangasek> sil2100: if you already know what FFes you need, just file the bugs and subscribe ubuntu-release
<sil2100> slangasek: ok then, if you say it's not needed then let's not - just passing down what Didier asked me to do, we'll still have to identify the components that might change in the process
<roadmr> stgraber: hello, sorry to trouble you, could you please have a look at bug 1216853? pxe installs over nfs are broken in 12.04.3 :(
<ubottu> bug 1216853 in casper (Ubuntu) "During PXE booting failed to mount nfs directory" [Undecided,New] https://launchpad.net/bugs/1216853
<sarnold> pitti: is the retracer alive and well? e.g 1216923 and 1216924 are both over three hours old without a re-trace yet
<seb128> sarnold, no, retracers were down, I'm restarting them
<sarnold> seb128: thank you :)
<bdmurray> tjaalton: do you have any plans to fix bug 1159983?
<ubottu> bug 1159983 in sssd (Ubuntu Precise) "[regression-update] Can't change local users password" [Undecided,Triaged] https://launchpad.net/bugs/1159983
<tjaalton> bdmurray: yes, i'll revert the change
<bdmurray> tjaalton: okay, thanks
<sarnold> pitti: seb 128 has handled the retracer problems, thanks :)
<pepper_chico> I have a bounty here guys, a bounty! http://askubuntu.com/q/335489
<soren> kees, stgraber, pitti, cjwatson: TB meeting, anyone?
<cjwatson> soren: bank holiday, on vacation, sorry
<soren> Guess not.
<soren> cjwatson: np. Enjoy!
<roadmr> xnox: thanks for poking the pxe/nfs bug!!
<stgraber> soren: hmm, isn't the TB meeting next week anyway?
<robert_ancell> mterry, hey
<mterry> robert_ancell, hello
<robert_ancell> mterry, you forgot to put the .conf in tests/Makefile.am in that MP, otherwise ready to land!
<robert_ancell> nice work btw!
<mterry> robbiew, oh shoot, will fix
<mterry> robert_ancell, done
<mterry> robert_ancell, thanks.  I can prepare the other bits (actually using depthId and naming sessions) once support for nested mir happens, I suppose
<robert_ancell> mterry, approved - I'll release it into archive in a few days unless you need it earlier
<mterry> robert_ancell, no
<hallyn_> should isc-dhcp-client's Depends not be switched from iproute to iproute2?
<soren> stgraber: Totally. My bad.
<hallyn_> bc as it is, in saucy, if i apt-get install isc-dhcp-client:i386, it fails due to irpoute:i386 not being installed, but that no longer exists - only iproute2 is multiarch
<pepper_chico> whoever answered the bounty tks =)
<stgraber> hallyn_: yeah, we need to move everything to iproute2. I'll have ifupdown down pretty soon (I believe it's part of the merge I'm doing at the moment), I'll take a look at the rest too.
<hallyn_> stgraber: ok, thanks.
<stgraber> hallyn_: the list of rdepends on iproute is pretty long and I don't think there's a good reason to carry the delta of moving them all to iproute2, but for the usual ones (isc-dhcp, ifupdown, vlan, ifenslave-2.6,... sure)
<hallyn_> stgraber: or maybe iproute could just be made per-arch or something (so i can install iproute:i386).  or apt be taught not to care in that case
 * hallyn_ is out of his depths
<stgraber> hallyn_: we could mark it foreign, but doing so wouldn't help with lxc as we'd then get the armhf version of iproute2, which we don't want
<hallyn_> stgraber: right if isc-dhcp-client actually needs iproute2:arch then it just needs to depend on that.  anyway, since you say you're on it i've closed the bugs.lp.net page and wno't file a bug for it :)
<hallyn_> thx
<infinity> Your versioning of your initramfs-tools upload is going to confuse the crap out of me.  Now you've pretty much forced me to merge, so I don't forget. :P
<hallyn_> success?
<robert_ancell> mterry, did you just accidentally set https://code.launchpad.net/~mterry/lightdm/greeter-api/+merge/173794 to merged?
<robert_ancell> it doesn't seem to have merged, but the status changed
<mterry> robert_ancell, it got merged because I based the branch you had off of it, but reverted some of the changes that weren't ready
<robert_ancell> ah, confusing :)
<mterry> yaeh
<slangasek> stgraber: why would you get the armhf version of iproute2?
<stgraber> slangasek: the use case is an armhf container in which we install isc-dhcp-client:<host architecture> which depends on iproute which is a transitional arch:all package depending on iproute2
<stgraber> slangasek: if we make iproute multi-arch:foreign, the existing iproute2:armhf will satisfy the dependency (as it should) and so the container will be stuck with the armhf version
<slangasek> hmm
<stgraber> hmm, actually, none of that matters since iproute2 itself is multi-arch:foreign
<slangasek> I was going to say
<stgraber> LXC explciitly installs iproute2:amd64 and isc-dhcp-client:amd64, so having iproute foreign would work
<stgraber> I guess I should do that AND move our core packages to using iproute2, there's no good reason to have those depend on a transitional package
<stgraber> and maybe spend some time next cycle to see if we can kick the transitional package out entirely (one can hope, the rdepends list is pretty long)
<infinity> stgraber: We can't kick the transitional package out until 14.10, but we can certainly make things stop depending on it.
<stgraber> infinity: right, have it there for upgrades in 14.04 and have it gone for good in 14.10 would be reasonable
<stgraber> hallyn_: uploaded the new ifupdown and updated all the packages I had on my system which were directly depending on iproute. That should be enough to clear the transitional package from most default installs.
<hallyn_> stgraber: ok, i'll retry building an armhf saucy container tomorrow then (or have all the pkgs already finished building? :)
<stgraber> hallyn_: will likely be an hour or so because they're published in the release pocket (build + autopkgtest + ...)
<hallyn_> ok, thanks
<hallyn_> now if only my ipxe build would get going  - cmon, lil doggie...  go on...
<darkxst> xnox, I need to reset some gsettings on the live session that are set by ubiquity-dm, where is the best place to do this? _on_try_ubuntu_clicked?
<darkxst> bug 1204312
<ubottu> bug 1204312 in ubiquity (Ubuntu) "ubuntu GNOME live session background not set correctly" [Medium,New] https://launchpad.net/bugs/1204312
<xnox> darkxst: actually ubiquity-dm should be showing the correct background.
<xnox> darkxst: look in ubiquity-dm for list of background, or I should finally stop ubiquity from manually forcing a background url, and instead simply use gsettings (if available on a given flavour)
<darkxst> xnox, there are two issues, one our background is not listed
<xnox> ... and ubiquity force sets picture-uri which points to non-existing file.
<darkxst> the other is that we actually use an animated background so that is an xml file that only gnome-shell can display
<darkxst> so we would set to a static image in ubiquity, but still need to reset the key
<xnox> darkxst: gnome-shell or gnome-settings-daemon? as far as I know gnome-settings-daemon is the thing that displays the background picture both in ubiquity, unity and gnome.
<xnox> darkxst: or is really gnome-settings-daemon not used anymore to display background under gnome-shell?
<darkxst> xnox, backgrounds are in mutter
<darkxst> unity still uses  g-s-d background plugin however
<xnox> darkxst: comment out picutre-options & picture-uri in gesettings_keys list. And try both unity & your session. Everything should just work.
<xnox> darkxst: cause at the moment ubiquity is not settings any colors, so what you see is fallback already.
<xnox> arr.. "and try both ubiquity & your gnome-shell session" is what I meant.
<darkxst> oh I guess the animated backgrounds do work there after all
<darkxst> there is also the 'num-workspaces' setting which is not ideal
<xnox> darkxst: I guess we could reset the keys to default on exit.
<darkxst> xnox, that seems reasonable
<darkxst> xnox, btw didnt have any luck getting gnome-shell to run under raring cd. It complains about not being able to find ck session there.
<darkxst> It does run on saucy though if I borrow the vt logind session
<xnox> darkxst: how do you "borrow the vt logind session"?
<xnox> darkxst: cause that's really all that is needed to be added to saucy cd to work.
<darkxst> xnox, I just hardcoded XDG_SESSION_ID
<xnox> darkxst: *cough* is that really all that's needed?! =) excellent.
<xnox> Laney: see ^ darkxst - the easy way to integrate logind.... =)
<xnox> darkxst: does it make network-manager indicator work as well?
<darkxst> xnox, I didn't test that, but will check
<darkxst> xnox, yes it does
<xnox> darkxst: so what do you hardcode? XDG_SESSION_ID=c2 ?
<xnox> or XDG_SESSION_ID=c0 ?
<darkxst> XDG_SESSION_ID=c1
<darkxst> it seems sessions c1 - c6 always exist
<xnox> darkxst: of-course they do.
<darkxst> although actually network applet always works fine here
<darkxst> I suppose its wifi that had problems?
<xnox> darkxst: tty1-6 autologin into the default account.
<xnox> darkxst: wifi page within ubiquity & the wifi indicator had troubles.
 * xnox actually likes that.
<darkxst> ok I can't actually test that
<xnox> darkxst: but c1 session wouldn't be a tty/graphical session. I wonder if that matters at all.
#ubuntu-devel 2013-08-27
<TheMuso> xnox: According to loginctl show-seat output, yes, GUI session types are indicated/tracked.
<TheMuso> And same with loginctl show-session.
<mwhudson> hm
<mwhudson> i was sure that there was some way you could play linker tricks so that e.g. the cortex-a15-optimal version of memcpy is used on a15 but not a9
<mwhudson> does anyone know some names i can google for to learn more?
<darkxst> xnox, indeed I can connect to wifi with hardcoded tty session
<slangasek> mwhudson: do you mean IFUNC?
<mwhudson> slangasek: quite probably, thanks
<mwhudson> slangasek: yes, turns out i do
<slangasek> ok :)
<darkxst> xnox, well atleast the indicator can connect, ubi-wireless page is still broken
<ESphynx> xnox: can we hit you soon with a release in preparation for Saucy? ;)
<mwhudson> slangasek: hey, do you know if saucy will have glibc 2.18?
<slangasek> mwhudson: ICMP redirect infinity
<mwhudson> hee hee
 * mwhudson gets confuzzled
<mwhudson> does eglibc even have releases?
<slangasek> I'm not sure if 2.18 is released yet, and if it is, whether there's enough lead time to get it in before feature freeze, and if there is, whether that's a sane thing to do wrt risk
<mwhudson> _glibc_ 2.18 is released
<slangasek> well, it has some kind of release
<mwhudson> https://sourceware.org/ml/libc-announce/2013/msg00000.html
<ubottu> sourceware.org bug 2013 in libc "memccpy() gives inconsistent results on mmapped files" [Normal,Resolved: fixed]
<mwhudson> like two weeks ago
<bradm> anyone done any work with building jenkins?
<mwhudson> i've typed "mvn build" in ~/src/jenkins once or twice...
<bradm> I'm trying to backport jenkins from raring to precise, and its getting all confused between org.jvnet.hudson and org.jenkins-ci
<bradm> it looks like some of its dependencies are still using the old hudson path
<bradm> we don't really want to use war files for this if possible
<bradm> I guess we really should be looking at juju in the longer run
<pitti> soren: TB meeting? we already had one last week, didn't we?
<pitti> Good morning
<darkxst> xnox, are you still around?
<pitti> darkxst: will probably still take some 3 hours until he's back online (London time)
<darkxst> pitti, ok
<darkxst> ubiquity is really broken on current Ubuntu GNOME daily
<darkxst> bug 1217177
<ubottu> bug 1217177 in ubiquity (Ubuntu) "ubiquity freezes when run from ubuntu GNOME live session" [Undecided,New] https://launchpad.net/bugs/1217177
<Laney> xnox: look at loginctl show-session c<whatever> for both types and compare
<darkxst> Laney, hi
<Laney> hello!
<darkxst> So I can use the tty logind  session and gnome-shell and its built in networkAgent work perfectly
<darkxst> when trying the same with metacity/nm-applet, It connects the first time, but if wifi is already connected it crashes with a permission error
<darkxst> ^ in ubuiqty-dm
<Laney> doesn't do that with ck?
<darkxst> well that seems more like a polkit thing, than systemd?
<Laney> I haven't seen the error :-)
<darkxst> Laney, bug 1178638
<ubottu> bug 1178638 in ubiquity (Ubuntu Saucy) "Exception in GTK frontend when attempting to connect to wifi: no logind support" [High,Triaged] https://launchpad.net/bugs/1178638
<darkxst> by setting XDG_SESSION_ID I do get a wifi to connect
<darkxst> but if its a persistent USB, ubiquity will crash with the same error if wifi is already connected
<Laney> darkxst: that is controlled by org.freedesktop.NetworkManager.network-control
<Laney> try checking it with pkcheck
<darkxst> Laney, pkcheck seg faults when I try it on nm-applet
<Laney> err?!
<Laney> I usually just use --process $$ in a terminal
<Laney> but that sounds bad
<darkxst> Laney this is in a terminal (on the live cd)
<darkxst> err terminal and or tty
<Laney> well, that's bad
<Laney> get it bugged
<Laney> "pkcheck --action-id org.freedesktop.NetworkManager.network-control --process $$" is what I'd run
<Laney> but it shouldn't segfault in any case
<darkxst> oh right that doesnt segfault, but it doesnt return anything either
<Laney> that probably means it's authorised
<Laney> look at the return code (echo $?)
<darkxst> 0
<Laney> yep, authorised
<darkxst> yet the network indicator has no control at all
<darkxst> (over the connected wifi network)
<darkxst> i.e. cannot even disconnect
<darkxst> nor can connect to a different network
<Laney> still with the permission error?
<darkxst> network indicator just grays out most of the options
<darkxst> it doesnt crash like ubiquity does
<Laney> does loginctl show-session c<your thing> show it as Active=yes?
<Laney> I guess look in the code and see how it decides to do that
<darkxst> nope, none of the logind sessions are active
<Laney> could be your problem then
<Laney> it's pretty common for polkit to require active sessions
<darkxst> ok, guess I will try and a create a sesson for ubiquity-dm
<Laney> darkxst: I suggested that xnox look at what lightdm does there
<Laney> will require translation c -> python but you can get the spirit from that
<Laney> (IIUC)
<darkxst> Laney, except normally its pam_systemd that creates the sessions (I believe)
<Laney> darkxst: yes you're opening a pam session
<asac> seb128: what came out of the /etc/.../networking discussion
 * asac also gets asked
<seb128> asac, I opened https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1217263 for stgraber
<ubottu> Launchpad bug 1217263 in ifupdown (Ubuntu) "conffile change prompt on upgrade" [Undecided,New]
<asac> seb128: i took the change now :)
<asac> -> I
<seb128> same here ;-)
<asac> ok so we are in same boat
<asac> good
 * asac feels better
<darkxst> Laney, so I can I fire off a pam session on a non-login X instance?
<Laney> darkxst: what's one of those?
<darkxst> well when ubiquity-dm spawns an X server
<darkxst> there is no login
<darkxst> oh, if I create a conf file for ubiquity-dm it should register a pam session
<Laney> there must be a user?
 * Laney hands you over to xnox now :-)
<xnox> Laney: yeah, i'm poking lightdm. And it's interesting, they create their own Session object which handles: normal, guess, autologin. + other stuff.
<Laney> I guess they do more than you need to in ubiquity-dm
<Ampelbein> xnox: Hey there! You did the multiarch changes to boost1.53? Could you have a look at bug 1217237 ?
<ubottu> bug 1217237 in boost1.53 (Ubuntu) "Can't link to python_boost library due to multiarch changes" [High,New] https://launchpad.net/bugs/1217237
<xnox> Ampelbein: seems reasonable. Note /usr/share/dpkg/architecture.mk already defines DEB_HOST_MULTIARCH, but I'm not sure why rtupdate is needed as it hasn't been called before.
<Ampelbein> xnox: It is called in libboost-python1.53-dev's postinst.
<Ampelbein> xnox: debian/rules installs it to usr/share/python/runtime.d/libboost-python$(PKGVERSION)-dev.rtupdate
<xnox> Ampelbein: ok. are there symlinks needed for python3 as well?
<Ampelbein> xnox: No, I don't think so.
<xnox> Ampelbein: ok. I'll add that to multiarch packages.
<Ampelbein> xnox: The script queries 'pyversions -d' to decide which is the default python version and where to link too.
<Ampelbein> xnox: There is another problem with the multiarch locations of boost: The autotools ax_boost_base.m4 macro is unable to find them , but I think that needs a change to those macros. Unfortunately my knowledge of autotools is limited.
<xnox> Ampelbein: I did patch one version of ax_boost_*.m4 already, but it's a pain that everyone copied them and tweaked them.
<xnox> Ampelbein: that new rtupdate will be different on each architecture, and thus not co-installable. Also if this is to change symlinks after default runtime change, I'm not sure that is needed anymore as there is only one 2.7 left.
<Ampelbein> xnox: Hmm, right. Maybe name it to libboost-python$(PKGVERSION)-$(DEB_HOST_MULTIARCH)-dev.rtupdate?
<Ampelbein> xnox: Or, if 2.7 is definitely the only python2 runtime version left and there will be absolutely no change, just create the symlink with a *.links file?
<xnox> Ampelbein: yeah, i am thinking to just ship a link to 2.7 by default.
<xnox> Ampelbein: I do not like how upstream boost doesn't distinguish 3.x & 2.x libraries at all though (in a standard manner).
<Ampelbein> Agreed.
<Ampelbein> xnox: Can you point me to a patched ax_boost*.m4? There are a few other build failures with not finding boost libraries.
<xnox> Ampelbein: well, i was overriding BOOST_SUFFIX=py2.7 in some of them. but with symlink back in place they should all just work again for python2 case.
<darkxst> xnox, the ubuntuone sso stuff breaks on ubuntu GNOME
<xnox> darkxst: can you paste logs?
<xnox> darkxst: and/or better file a bug report & fetch logs from the live cd after the error.
<Ampelbein> xnox: Oh, ok. The failures I had in mind was for not finding boost_program-options. #1215896 and 1215906
<xnox> bug 1215896
<ubottu> bug 1215896 in synfig (Ubuntu) "synfig FTBFS on amd64: configure:22100: error: Could not find a version of the library!" [High,New] https://launchpad.net/bugs/1215896
<darkxst> xnox, its seems to just hang
<xnox> bug 121906
<ubottu> bug 121906 in xorg (Ubuntu) "Gutsy Tribe 1 installer does not configure X to use ATI driver for ATI All-In-Wonder Radeon 8500 DV (R200 chipset)" [Medium,Fix released] https://launchpad.net/bugs/121906
<darkxst> xnox, we don't ship ubuntuone
<darkxst> although I didnt see anything in ubiquity that actually uses u1
<xnox> darkxst: so. that page doesn't depend on ubuntuone. it does rest api's to ubuntu and stores a token in gnome-keyring.
<darkxst> xnox, right, that is what It looked like form the code
<darkxst> but when I start ubiquity it just hangs
<darkxst> xnox also it only happens from the live session, seem to work from ubiquity-dm
<xnox> darkxst: can you please file a bug with logs, cause e.g. syslog should tell you where it hung.
<darkxst> xnox, there are no logs
<darkxst> xnox, apart from what is in bug 1217177 I can't find anything more to give you
<ubottu> bug 1217177 in ubiquity (Ubuntu) "ubiquity freezes when run from ubuntu GNOME live session" [Undecided,New] https://launchpad.net/bugs/1217177
<darkxst> it runs fine under gnome-shell in my local session
<darkxst> but just sits there completely hung, when run from the liveCD session
<darkxst> and I don't know how to debug hangs in python
<rbasak> cjwatson: could you consider adding upload rights for mysql-5.5 to ~ubuntu-server-dev, please? I also noticed awstats, though I don't have anything I need to do with that package right now.
<rbasak> Or is cjwatson still away/on holiday?
 * rbasak isn't sure who to ask in his absence
<seb128> rbasak, he's back since today I think
<rbasak> Thanks
<seb128> he was around earlier at least
<rbasak> OOI, where do the exceptions actually go?
<debfx> rbasak: afaik https://code.launchpad.net/~cjwatson/+junk/packageset
<rbasak> Thanks!
<cjwatson> rbasak: awstats and mysql-5.5 done
<rbasak> Thank you!
<pitti> hey cjwatson, welcome back!
<pitti> cjwatson: I hope you had some nice holidays? it's been quite cold and rainy in my part of Europe last week
<cjwatson> We were above the clouds for a good part of the week
<cjwatson> (I exaggerate slightly but not by much)
<pitti> heh, always sunny there :)
<stgraber> asac, seb128: right, the right answer to the prompt is Y (take the change), however I have no clue why it's even prompting since I highly doubt you've both had local changes to that file...
<stgraber> I'll poke some more and possibly get slangasek to take a look too (we've both been adding migration code to that package to deal with migration of that conffile between two packages, looks like something's still missing)
<seb128> stgraber, hey, I provided the info I though would be useful on the bug report (Laney hinted on what those would be), let me know if you need more details
<stgraber> seb128: do you still have the pre-update /etc/init.d/networking around? if so, attaching that too would be good.
<xnox> Ampelbein: --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
<seb128> stgraber, I add the diff to the bug, you can patch -R it to get the pre version
<seb128> stgraber, but sure, can do that
<xnox> Ampelbein: and "include /usr/share/dpkg/default.mk" (or /usr/share/dpkg/architecture.mk if you want less pre-defines) to get DEB_HOST_MULTIARCH.
<stgraber> seb128: sure, but if LP ate or changed a single char when I copy/paste that back to my system, the md5sum will be wrong which will make it a pain to debug
<seb128> stgraber, done
<stgraber> thanks
<Ampelbein> xnox: Ok, that is the solution I have used for my package, pdfcube. I was just wondering if there was a better way. Thanks for looking into it!
<xnox> Ampelbein: uploaded fixed toonloop.
<xnox> Ampelbein: it's better than hacking m4 and is already supported.
<Ampelbein> xnox: I see, thanks again. I will upload some fixes later then.
<xnox> Ampelbein: excellent =)
<xnox> Ampelbein: i'm waiting for doko to do archive rebuild, then we'll be able to stop all of them easily.
<Ampelbein> xnox: Yeah, those were just the few I have found while trying to figure out the buildfailure in my own package.
<asac> stgraber: its the old issue of getting asked about conffile changes that never happene
<menace> is anyone aware if pxeboot via ipv6 works?
<asac> d
<asac> i always get those at least once when upgrading from release to new release
<stgraber> asac: yeah, but we already have a ton of code in ifupdown to avoid that, so I'm really surprised this showed up again... I'll have to re-read all the maintainer scripts and figure out what corner case we missed (since it clearly didn't happen in a raring -> saucy system and a clean saucy system when I tested here)
<seb128> stgraber, that box is 3 years old, and got regularly upgraded through every cycle, mostly following unstable
<seb128> stgraber, if that helps
<asac> seb128: i doubt it helps. as i said, i have weird debconf dialogs during upgrades
<asac> every release
<seb128> asac, stop editing your conffiles :p
<asac> and always i am pretty sure i never touched the file
<seb128> asac, stop installing weird/broken packages then ;-)
<asac> so 4 years ago i flied these as "packaging bugs, that touch /etc in maintainer scripts"
<asac> but i somewhat dont believe in that story anymore
<seb128> asac, but yeah, those stuff are easy to get wrong and bugs are not uncommon
<asac> seb128: like ifupdown :)
<cjwatson> If it's debconf, it's not conffiles
<cjwatson> Since conffiles aren't processed via debconf
<seb128> cjwatson, we are speaking about conffile diffs I think
<asac> yeah i might mix things up. sorry
<cjwatson> I know
<seb128> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1217263 in that specific case
<ubottu> Launchpad bug 1217263 in ifupdown (Ubuntu) "conffile change prompt on upgrade" [Undecided,New]
<seb128> cjwatson, welcome back btw, I hope you had good debconf and holidays ;-)
<cjwatson> I did, thanks
<asac> welcome back :)
<cjwatson> Good mountain air
<cjwatson> We got up as far as the snow line, albeit briefly
<seb128> nice
 * cjwatson is appreciating the lots of time he got to prepare for vUDS ... no, wait, the other one
<stgraber> seb128: it actually helps. I'll try a precise -> quantal -> raring -> saucy upgrade, see if that triggers it
<stgraber> seb128: if that doesn't, then it's most likely something that went wrong at some point in a dev release which will be close to impossible to track down
<seb128> stgraber, right :/
<stgraber> seb128: the diff you posted in the bug is exactly what changed between the last and current version, so there's clearly no local change but for some reason dpkg thought there was at some point and marked the conffile as modified
<seb128> stgraber, right, md5sum is the same between my .dpkg-old and the file from ifupdown-0.7.5ubuntu4
<smartboyhw> I heard that ubiquity is breaking installs everywhere:(
<slangasek> stgraber: 20-05-2013 12:08:20 > slangasek: the only case this doesn't test for is the possibility that in the *next* version of ifupdown the user installs, the md5sum of the conffile changes again
<jibel> pitti, I pushed the fix to adt-export-results to all the testing nodes
<pitti> jibel: merci
<chrisccoulson> hey, i'm leading a session in a few minutes. are there any pointers for how to set up the hangout etc? (dholbach / jono)
<chrisccoulson> i haven't done this with the new format yet
<dholbach> chrisccoulson, the track lead will start the session
<chrisccoulson> dholbach, thanks :)
<chrisccoulson> jdstrand ^^]
<jdstrand> ok, cool, so we are client, so that should be jasoncwarner
<dholbach> or seb128 I think
<chrisccoulson> oh, it's not actually in a few minutes. sorry, tz confusion ;)
<jasoncwarner> jdstrand sil2100 or seb128
<jdstrand> chrisccoulson: ^
<jasoncwarner> chrisccoulson ^^
<dholbach> chrisccoulson, you can then find the link to the hangout on the page of the session linked from http://summit.ubuntu.com/uds-1308/2013-08-27/
<chrisccoulson> thanks
<sil2100> chrisccoulson: I guess seb128 will be your lead
<sil2100> chrisccoulson: so he'll create the hangout for you
<sil2100> seb128: client2 ^
<frafu> Hi, Could anybody please tell me whether there is a place, where developers of software shipping with Ubuntu can get some free legal advice sponsored by Ubuntu/Canonical?
<chrisccoulson> sil2100, thanks
 * chrisccoulson pokes seb128
<chrisccoulson> is it fixed yet?
<seb128> lol
<seb128> sil2100, chrisccoulson, jasoncwarner: isn't that session in 50min?
<seb128> did I screw up my tz?
<sil2100> No, it's ok
<sil2100> It's in 50 min
<seb128> oh, pfiou, good
<chrisccoulson> seb128, no, i screwed up my tz ;)
<sil2100> Just poking ;)
<seb128> you scared me :p
<jasoncwarner> well chrisccoulson  and seb128 , I *did* screw up my tz and got up 2 hours early :/
<chrisccoulson> lol :)
<seb128> jasoncwarner, look at the good side, it gives you time for coffee ;-)
<TheMuso> I wish I was a coffee drinker, it could probably help me about now. :)
<seb128> qengho, hey, any news about the chromium build issue in saucy?
<qengho> seb128: I rolled the fix into the upcoming release.  I should receive webapps patches today, and then give it to builders.
<seb128> qengho, ok, thanks
<slangasek> apw jdstrand ogra_ infinity rsalveti sergiusens stgraber xnox: if I moved http://summit.ubuntu.com/uds-1308/meeting/21961/foundations-1308-touch-support-model/ up to start in a half hour, would that work for you?  I don't want to leave our one free slot on Foundations for the first hour on day 1, leaving us no slack if we need last-minute sessions scheduled
<jdstrand> slangasek: not for me. I need to be in the oxide session
 * ogra_ has to check 
<slangasek> (in fact, I thought Phonedations had another session Coming Soon)
<pitti> jibel: want me to update the other occurrences of VersionCompare in a-p-t?
<slangasek> jdstrand: ah, ok
<slangasek> I'll find something else to move
<rsalveti> slangasek: I got a conflict with the daily-release session
<slangasek> ara apw xnox ogasawara: could *this* session be moved up to the next hour (i.e., starting in 30m)?: http://summit.ubuntu.com/uds-1308/meeting/21883/foundations-irst-support/
<ara> slangasek, fine for me
<xnox> slangasek: yes, but is superm1 there?
<slangasek> xnox: he's not on the attendee list
<jibel> pitti, done in r224
<xnox> slangasek: and/or danjared
<pitti> jibel: ack, merci
<slangasek> ah, danjared: ^^ would you be happy to have the Intel Rapid Start session in 30m?
<slangasek> danjared: ^^
<ogasawara> slangasek: ok by me, but I don't think I'm required (but I am planning on listening in)
<slangasek> ogasawara: right... I was asking you as a proxy for the many kernel devs on your team who seem to not be on this channel :-)
<slangasek> anyway, I won't move it without danjared's ack
<danjared> slangasek: won't work for me :-\
<slangasek> danjared: ok, no worries
<slangasek> xnox: do you have access to kick http://package-import.ubuntu.com/status/ifupdown.html ?
<xnox> slangasek: yes, but it will have permissions errors pushing back.
<xnox> let me try though.
<slangasek> xnox: mm? why permissions errors?
<xnox> slangasek: see example http://package-import.ubuntu.com/status/cloud-init.html
<xnox> slangasek: who should I poke about that?
<ogra_> slangasek, what did you end up shuffling ? my personal calendar doesnt show changes
<slangasek> ogra_: in the end, nothing has moved
<ogra_> ok
<slangasek> xnox: so how do we fix that?
<cjwatson> <small>switch to dgit</small>
<slangasek> xnox: wait, you're asking *me* who to poke?
<slangasek> cjwatson: would like a more short term fix :)
<xnox> cjwatson++
<xnox> wgrant: any idea why this is happening to UDD importer or force requeue-all of any package which had tag mismatches? example post requeue http://package-import.ubuntu.com/status/cloud-init.html
<xnox> wgrant: looks approx. like this before requeuing http://package-import.ubuntu.com/status/ifupdown.html
<stgraber> xnox: do you know who that script is running as?
<xnox> stgraber: i can double check.
<stgraber> xnox: it should be running as ~package-import
<stgraber> xnox: we removed a bunch of ~ubuntu-branches members a month ago but none of those should be used by scripts (though that'd explain the 401(
<xnox> stgraber: it does ssh into bazaar.launchpad.net as user package-import.
<xnox> stgraber: i wonder if the lp-api token expired.
<hholtmann> What would be a good channel to ask question about specific "dev box environment question" on issue dealing with developing linux programs.. in this case how to develop packages, install and test on my workstations.. without installing my stuff to the "system"...
<hholtmann> in other words.. how can I install my packages and test on my dev box WITHOUT altering my "system"â¦. is what a 'chroot" environment is for?
<cjwatson> chroots or lxc containers are good for that, yes
<hholtmann> not the HOW's. but the strategies.
<cjwatson> also for building packages, something like https://wiki.ubuntu.com/SimpleSbuild is excellent
<hholtmann> cjwatson:  thanks
<seb128> jdstrand, kenvandine, lool, tedg, "push notifications (v0)" session's hangout url: https://plus.google.com/hangouts/_/50858536cc9dc46dce60681e9cd64ed7c3458455?authuser=0
<seb128> the hangout is open but not broadcasting yet
<seb128> going to start that in 3 minutes, you can already join if you want
<lool> thanks
 * tedg should have shaved
<kenvandine> seb128, thanks
<slangasek> fginther, cjohnston, doanac`: you're wanted in the phablet tools roadmap session, are you able to join? https://plus.google.com/hangouts/_/28b3927907ca51848ffbadc659fa11ee50731df0 / #ubuntu-uds-foundations-1
<lool> xnox: BTW have switched to different computer, laptop was maxing its CPU
<lool> hence the lags I guess
<xnox> =)
<Laney> gotta love hangouts
<seb128> lool, do you know who is hosting that one?
<seb128> kenvandine, ^
<kenvandine> seb128, not really... chipaca is on holiday
<lool> seb128: I'd think John Lenton or Lucio
<seb128> shrug
<lool> kenvandine: is lucio around?
<kenvandine> he registered it right before leaving
<kenvandine> not sure
<seb128> lool, John is on holidays from what kenvandine said
<lool> beuno: !
<kenvandine> seb128, i'm pinging people
<seb128> kenvandine, thanks
<beuno> lool, should be lucio
<lool> beuno: can't find him on IRC
<lool> beuno: could you call him?
<beuno> lool, I'm on a session
<lool> seb128: are we broadcasting already?
<seb128> lool, yes, but I can stop it if you want
<lool> seb128: not worth broadcasting this
<lool> calling lucio
<seb128> lool, stopped
<seb128> lool, of course I can't broadcast again after stopping...
<seb128> lool, ted, kenvandine: https://plus.google.com/hangouts/_/be9944c51c1acb76b3ae351abb663eff69f38489?authuser=0
<seb128> now hangout url (in case we manage to get a session going)
<lool> seb128: lucio joined
<seb128> lool, you need to join that new url if we want to broadcast, I can't re-broadcast the old one after stopping
<seb128> (stupid g+)
<slangasek> xnox: when are you changing your /nick to mirnomir?
<xnox> slangasek: I am actually running dual-screen on Mir at the moment =)))))
<xnox> slangasek: mirnetmir
<ESphynx> xnox: What's your take on Mir?
<xnox> ESphynx: works great for me! I finally have mirrored lightdm once again!
<Laney> mirâmir
<ESphynx> cool. Does it come with Saucy?
<ESphynx> Is it X11 compatible?
<xnox> ESphynx: it's in Saucy, but as an optional package, so one has to manually opt-into it. At the moment. Yes, it's X11 compatible.
<ESphynx> xnox: cool. Did you get my hint for an upcoming Ecere package I hope will make it in Saucy? ;) It fixes a bunch of things.
<xnox> ESphynx: no, I didn't get your hint =)
<xnox> ESphynx: feature freeze is on Thursday, what were you hoping to get in?
<ESphynx> oh. I'm hoping you'll be able to help us get it in, yes
<ESphynx> I know the feature freeze is on Thursday, which is why I've been trying to push this release, I was hoping to get it ready on Sunday :(
<xnox> ESphynx: do you have a .dsc or branch already, i haven't seen anything.
<ESphynx> I have nothing yet.
<ESphynx> apart from lots of commits, obviously :P
<ESphynx> I don't think the packaging will require any change apart from a changes entry
<ESphynx> I don't expect to have a .dsc until Thursday evening, there are still some fixes required :S  But I'd argue it's all bug fixes, and some quite needed ones, so hopefully we can still get in...
<ESphynx> gotta go for now, thanks xnox!
<ESphynx> (current commits are on https://code.launchpad.net/~jerstlouis/ecere/master )
<lool> cjwatson: hey, I need to make /var/lib/PackageKit rw in touch images, but can you confirm it's ok to make it temporary data? (seems it's just to prepare transactions, but the contents can be destroyed on reboot)
<cjwatson> lool: I don't really know much about that
<cjwatson> I'm not certain that the scan-desktop-files plugin runs before anything that might use desktop-files.db
<lool> cjwatson: ah does desktop-files.db need to be preserved across reboots?
<cjwatson> The transaction database can be temporary, but for the other, I would err on the side of caution and say it needs to persist
<cjwatson> Just from a quick skim-read of the code
<lool> yeah
<cjwatson> lool: heh, I just ran across the exact same problem with packagekit and system images that I guess you were just fixing ...
<lool> cjwatson: it's uploaded I think
<lool> cjwatson: lxc-android-config 0.82 (saucy-proposed)
<cjwatson> Cool
<lool> cjwatson: you can change /etc/system-image/writable-paths by hand and reboot to get the fix
<lool> (just add PackageKit liek Network-Manager
<cjwatson> I'll just reflash next time there's an update, no rush
<cjwatson> /etc/system-image/writable-paths is sensibly on the RO partition anyway
<sarnold> seb128: how's the health of the retracers? another one with 4+ hours: 1217406
<seb128> sarnold, they are being slow so you have time to review https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061 ;-)
<ubottu> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [High,Confirmed]
<sarnold> seb128 :D
<seb128> sarnold, the amd64 retracer was down, I restarted it
<sarnold> seb128: thanks
<seb128> yw!
<roaksoax> xnox: howdy!!
<roaksoax> xnox: were you able to look into DLM?
<roaksoax> err
<roaksoax> xnox: lvm2?
<dobey> anyone around that can accept something in the saucy NEW queue?
<dobey> i've had a package sitting in NEW for over a month now :(
<infinity> dobey: Which package?
<dobey> infinity: ubuntuone-credentials
<infinity> dobey: Is that destined for main with an MIR and such, or just universe?
<dobey> infinity: just universe in saucy
<dobey> infinity: it will be in the touch image though. not clear if there's a special MIR-like thing that needs to be done for that, but i was told at least that it doesn't have to be in main in the archive
<jdstrand> cjwatson: thoughts on click Recommending click-apparmor? for now I seeded it in supported, but though a recommend might make sense
<jdstrand> s/though/thought/
<infinity> dobey: The eventual plan/hope was for touch stuff to all make it to main, the fact that we're building out of universe right now isn't a feature but a necessary velocity thing while doing tech previews.
<infinity> dobey: If this is detined for default images, I'd like a security review, given the sort of package it is.
<infinity> jdstrand: ^-- Can you get someone to do an in-queue review of ubuntuone-credentials?
<infinity> jdstrand: And have them follow up to https://bugs.launchpad.net/ubuntu/+bug/1199017 so we can refer back to it when an MIR rolls around?
<ubottu> Launchpad bug 1199017 in ubuntuone-credentials "[needs-packaging] ubuntuone-credentials" [Undecided,New]
<cjwatson> jdstrand: makes sense, done for next upload
<jdstrand> cjwatson: thanks! :)
<jdstrand> cjwatson: oh, while I have you. can you comment on https://lists.launchpad.net/ubuntu-appstore-developers/msg00451.html (or parts of the thread that interest you)
<jdstrand> cjwatson: doesn't have to be now or anything. I'd like to use aa-exec-click instead of aa-exec to setup some env vars, and that thread suggested to me you might have some input
<cjwatson> jdstrand: right, uh, that's in my two-week mail backlog
<jdstrand> cjwatson: yeah, I figured. coming back from vacatio is always nice :)
<jdstrand> cjwatson: welcome back btw :)
<cjwatson> jdstrand: I exhausted my thinking power for today on the multiple-unpack-directory thing :)
<cjwatson> ta
<jdstrand> fun
<cjwatson> will need to implement all that soon, but not right now ...
<jdstrand> yeah, no huge rush, just thought I get an extra blip on your radar
<cjwatson> ack
<jdstrand> infinity: what kind of timeframe are you looking for?
<infinity> jdstrand: Well, I'll do the NEW review over the next couple of days, so dobey doesn't strangle me.  But given it's destined for images, I'd like to treat it almost like an MIR, even if it's not being seeded right away.
<infinity> jdstrand: So, uhm.  EOW, maybe?
<jdstrand> sarnold: is that something you could squeeze into that timeframe? ^
<dobey> unfortunately i only just now realized it wasn't in universe yet :(
<sarnold> jdstrand: yes, I can do that, though I'm unlikely to get all the MIRs done this week. :(
<sarnold> jdstrand: but it can be #2 after openjpeg and be done by eow.
<jdstrand> sarnold: sure, that's fine. it is also how it goes at this time in the cycle.
<infinity> sarnold: Early next week is also doable.  I'm happy to grant dobey an FFe based on the archive admins being slack. :P
<dobey> i'll have a new version to upload, tomorrow. it adds a couple more packages, and switches from storing stuff in gnome-keyring over to using online-accounts. but the code that talks to the network is i think unchanged from what's in there now
<jdstrand> sarnold: I appreciate it
<infinity> But I suspect he also wants to link stuff with the library.
<infinity> dobey: If you upload that before sarnold gets to look at it, all the better.
<infinity> dobey: (And I'd prefer to be doing the NEW review on that version too)
<dobey> infinity: i'm guessing pull-lp-source won't grab the existing version eh? and there's no bzr branch of it. and i don't think i can actually upload a new one since it hasn't been accepted yet?
<infinity> dobey: queue fetch <package>
<infinity> dobey: And you can upload as many as you want, I'll just reject all but the newest.
<dobey> infinity: i meant as a matter of permissions
<infinity> Oh, this was sponsored, I guess.  Yeah.  True.  But you can throw source to me and I'll sponsor blind, so I can review without prejudice. :P
<infinity> (Cause that's a sane workflow, right?
<infinity> )
<dobey> it's supposedly added to the ubuntuone package set, but i don't know what that means for things that haven't been accepted into the archive yet
<infinity> More likely, I'll review, then sponsor, but whatever.
<dobey> where does "queue" come from?
<infinity> dobey: Oh, if it's in the packageset, it might let you upload.  Always worth a shot.
<cjwatson> dobey: lp:ubuntu-archive-tools
<infinity> dobey: ubuntu-archive-tools.
<infinity> dobey: You can also just snag from the web UI: https://launchpad.net/ubuntu/saucy/+queue
<dobey> yeah. and -archive-tools is i guess unpackaged according to apt-get
<infinity> Intentionally so.
<Noskcaj> kirkland, FYI, i found a guy who is willing to port testdrive to GTK3
<roaksoax> Noskcaj: there's already a port to GTK3, it just needs fixing
<Noskcaj> roaksoax, i forgot about that, i'll link it to him when he's next online
<roaksoax> Noskcaj: cool! thanks!
<Noskcaj> Also, do you think testdrive is ready for debian? i can upload it if you want
<roaksoax> Noskcaj: yes and no... it would first need native support for debian iso's
<Noskcaj> roaksoax, ok. I'll look into that
<roaksoax> Noskcaj: cool, thanks!
<wgrant> xnox: I think that's because it no longer has privileges to set the branch for obsolete series, maybe. But I'm not sure why it's trying to set the branch for an obsolete series...
<wgrant> Unless it just tries every time it tries to import that series, even if it's already set to the desired value.
<slangasek> wgrant: well, what if the import has been failing for > 6 months?
<wgrant> slangasek: Sure, but I don't think this one has.
<wgrant> It clearly needs to be able to set old series branches for that sort of case, but I don't think this is one of them.
<slangasek> wgrant: well, that particular one maybe is related to an SRU to maverick?  Just speculation on my part, however
<wgrant> It could be, yeah.
<jkitchen> is there a setting for dpkg by chance to prevent package installation from creating a user? I'd rather the installation fail (and not happen) if a user is required but doesn't already exist
<slangasek> jkitchen: no, that's not something we would consider a reasonable configuration setting
<jkitchen> really?
<jkitchen> hrm.
<jkitchen> reason I ask is because, for instance, mongodb, it will set up a user
<jkitchen> but depending on a few other factors, that might not be the same uid/gid as a different system
<slangasek> all kinds of packages set up users.  There's a reserved uid range exactly for this purpose.
<jkitchen> so I'm pre-creating a bunch of users, but it's like playing whack-a-mole
<slangasek> if you need to block this for some reason, you could divert and wrap adduser, which would cause it to bail out
<jkitchen> hrm
<slangasek> however, most of us have long since given up on the idea of having UIDs match across systems
<jkitchen> heh
<jkitchen> I don't need them so much to match across systems
<jkitchen> across reinstalls of the same system, however
<jkitchen> because my root filesystem and my data are different
<jkitchen> my data persists, root does not
<jkitchen> so doing that means I get it across systems for free
#ubuntu-devel 2013-08-28
<pitti> Good morning
<pitti> tyhicks: hey Tylor!
<pitti> tyhicks: sorry, Tyler
<pitti> tyhicks: your new d-bus introduces a stderr message "AppArmor D-Bus mediation is enabled"; that looks like a debugging leftover?
<pitti> tyhicks: it breaks the bluez test (https://jenkins.qa.ubuntu.com/job/saucy-adt-bluez/66/)
<pitti> hm, it's just a DBUS_SYSTEM_LOG_INFO
<jjohansen> pitti: actually logging that the MAC is enabled is standard practice, we have 3 messages in the kernel about apparmor enablement
<jjohansen> its a way of verifying that your mediation is enabled for an audit trail
<pitti> jjohansen: that should go to kmsg though, right?
<pitti> tyhicks: FYI, dbus doesn't currently propagate because britney thinks that the fluidsynth test is still running; once jibel comes online we'll clean that up
<pitti> so it'll land today
<jjohansen> pitti: yeah the kernel one go through kmesg, the dbus message might not be able to go through the audit system, I know there was problems with audit not being available or something like that when dbus came up. I've forgotten the details, tyhicks would know better
<jjohansen> pitti: thanks
<pitti> so I'll look at the bluez test and adjust it for the stderr message
<pitti> meh, it breaks the network-manager, upstart, and ubuntuone-dev-tools tests too
<pitti> ah no, that was the new kernel
<sarnold> pitti,jjohansen: as I understand it, to log through auditd would require dbus daemons to run with CAP_AUDIT_WRITE -- which the user-started ones won't have and probably shouldn't have.
<sarnold> which considering that now log messages will go through two separate logging systems, we may wish to reconsider using fscaps to start dbus with CAP_AUDIT_WRITE so we can return to a single log sink.
<jjohansen> sarnold: yeah that sounds familiar, I remembered their being issues, but just didn't remember what they where
<darkxst> cjwatson, how do we change the syslinux theme on Ubuntu GNOME CD?
<darkxst> cjwatson, as in where does the image builder get the themes from? I couldnt find anything for the other flavours?
<pitti> lifeless: hey Robert, how are you?
<pitti> lifeless: I want to have a go at adding a python3-junitxml binary; a couple of other patches piled up in Debian BTS (dh_python2, unused build dep, etc.); are you interested in an NMU?
<tyhicks> pitti: hello - the "AppArmor D-Bus mediation is enabled" message should be context aware
<tyhicks> pitti: the message from the session bus should go to stdout and the message from the system bus should go to syslog
<pitti> tyhicks: the bluez test runs its own dbus-daemon, I guess it comes from there; but it goes to stderr
<tyhicks> oh, that isn't happening
<lifeless> pitti: hi
<lifeless> pitti: NMU away
<lifeless> pitti: I keep meaning to move that and a number of pythons into the Python packaging team
<lifeless> pitti: I'm good :)
<pitti> tyhicks: but anyway, I guess that's really a problem in the bluez test, but I wondered why debug messages need to go to stderr if anything else goes to stdout
<tyhicks> pitti: well, it is more than a debug message
<tyhicks> pitti: but it should go to stdout
<pitti> lifeless: while I'm at it, would you like me to do some other packaging refreshing, like updating to a non-deprecated dh level, dropping simple-patchsys and move to 3.0(quilt), and so on?
<lifeless> pitti: be my guest
<lifeless> pitti: though, hmm, quilt - eek
<lifeless> pitti: I still have the packaging for that in straight bzr
<lifeless> pitti: and the Python packaging team is svn
<lifeless> pitti: I'm not sure what setup works best there; but whatever it is, thats what I'd want to converge on.
<pitti> lifeless: well, it' doesn't actually have patches; but I'd like to convert it to pybuild which makes things a whole lot easier
<tyhicks> pitti: I created bug #1217710 for the stderr issue
<pitti> i. e. drop teh cdbs bits and just use the current python packaging stuff
<ubottu> bug 1217710 in dbus (Ubuntu) "Message about AppArmor mediation status goes to stderr instead of stdout" [Medium,Confirmed] https://launchpad.net/bugs/1217710
<pitti> tyhicks: thanks, I'll investigate that a bit more and follow up there
<pitti> tyhicks: ah, you can reproduce? good
<tyhicks> pitti: I'll be happy to fix it tomorrow
<pitti> tyhicks: thanks
<lifeless> pitti: that sounds great
<tyhicks> pitti: to be clear, ubuntu4 can land as it is today and then I can prepare an ubuntu5 with the fix tomorrow, correct?
<lifeless> pitti: all I ask is you cross-check with the python packagnig team standard setup and use that
<lifeless> pitti: that *might* be 3.0(quilt), and if so cool.
<lifeless> pitti: I'm sure it's pybuild etc :)
<pitti> tyhicks: yes; in theory britney should hold back dbus because it breaks the bluez test, but it doesn't (I'll ask jibel about that once he comes online)
<tyhicks> pitti: great - thanks! (jibel just came online)
<jibel> pitti, tyhicks good morning. Investigating the bluez case (once X stops crashing :( )
<pitti> jibel: bonjour
<pitti> jibel: we have a handle on the actual failure; I just wondered why it isn't in excuses for holding back dbus
<tyhicks> hi jibel
<pitti> jibel: btw, could you please run your magic script to fix the "fluidsynth 1.1.6-2: RUNNING"? it finished long ago
<pitti> lifeless: first time that I have used pybuild; it's lovely
<jibel> pitti, right, that's the part I'm checking. The result is correct in the history file, I'm looking why it is not reported correctly to britney
<pitti> lifeless: it's quite straightforward now: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/pyjunitxml/saucy/revision/11
 * pitti remembers the time of all these "set -ex; for python in $(shell py3versions -r); do" overrides
<pitti> lifeless: ok, all done; I'll upload to saucy, and (with a consolidated changelog) to Debian
<pitti> jibel: I removed the broken libgtkada from saucy-proposed again; how would I convince britney to stop blocking cairo now? (libgtkada test is green again)
<xnox> wgrant: ~package-import is member of ~ubuntu-branches (which i thought gives the privileges to set the branch for series), but now core-dev is member of ~ubuntu-branches as well.
<xnox> so ~ubuntu-branches doesn't sound that special any more.
<wgrant> xnox: Right, ~ubuntu-branches used to be a celebrity, but now it just owns the branches.
<wgrant> ~package-import's primary permission today is its membership in ~ubuntu-core-dev. The upload privs allow it to set official branches.
<xnox> wgrant: maybe ~package-import shouldn't be direct member of ~ubuntu-branches then, since it's part of ~ubuntu-core-dev anyway.
<wgrant> It shouldn't make any difference now.
<xnox> wgrant: shall i file a bug against udd & launchpad, to figure out what udd is trying to do, why, whether it's needed and how to fix it (in either udd or launchpad)
<wgrant> I think there's a question open atm that I haven't had time to look at yet.
<wgrant> https://answers.launchpad.net/launchpad/+question/234047
<xnox> wgrant: and there is comment from maxb about it as well.
<wgrant> Right
<Laney> infinity: did you shelve libav 9?
 * pitti sobs at lillypilly having a load of 35
<maxb> "The upload privs allow it to set official branches." .... they used to
<pitti> it never fell < 10 in the past week
<maxb> But now, they don't for old series
<wgrant> maxb: Not quite.
<wgrant> maxb: It used to be able to set for obsolete series because ~ubuntu-branches was a celebrity.
<wgrant> Which could set anything anywhere.
<maxb> Oh
<maxb> I thought it had not been a celebrity for a long time, I didn't realise that was a relatively recent change
<wgrant> Though this particular failure may be because of the new obsolete series restrictions, it could occur with the release pocket since we made ~ubuntu-branches a non-celebrity.
<wgrant> In fact, let's see if relaxing the obsolete series restriction works.
<infinity> Laney: It's not Thursday yet!
<infinity> siretart: *nudge*
<Laney> heh
<Laney> well... I'm trying to upgrade to gstreamer 1.1 and gst-libav1.0 1.1.3 requires this version
<Laney> of course, there's always the internal copy of libav :-)
<infinity> Laney: Ew, no.
<infinity> Laney: Bad Laney.
<Laney> see my previous poke
<infinity> Laney: Honestly, I'd probably grant an FFe and try to jam the transition through ANYWAY, just to avoid having to do it in the 14.04 cycle.
<wgrant> xnox, maxb: I've relaxed the obsolete series restriction for the primary archive and requeued cloud-init, so we'll see if this works.
<infinity> siretart: I'll be your best friend if you get me the new libav in saucy before Thursday.
<Laney> OK, I'll upload the rest and leave libav for a bit then
<infinity> Laney: If it had a sane versioned build-dep, you can do it now, and just assume libav9 is on the way.
<Laney> Mmm, yeah it does.
 * infinity debates debugging this eglibc test failure further, doing expense reports, or napping.
<infinity> Note that's "napping in oppressive humidity and heat", so not actually much more fun than the other two activities.
<Laney> Didn't you promise messagingmenu-sharp? :P
<infinity> Laney: Did I?
<seb128> infinity, Laney, cjwatson: current dbus in proposed is creating issues (basically the apparmor integration is buggy on buildds and prevent dbus from starting, which makes tests unhappy and block landing)
<seb128> infinity, Laney, cjwatson: do you have any objection to delete it to reupload once we have the issue fixed?
<pitti> seb128: oh, I just fixed the wrong "RUNNING" in excuses, should I un-fix that to keep it in -proposed?
<pitti> seb128: (IOW, it'll migrate soon)
<seb128> pitti, yes, please
<seb128> or just delete it from proposed
<seb128> I was asking before doing it, in case there is a good reason we shouldn't
<infinity> pitti: You fixed at the jenkins level you mean, or...?
<pitti> infinity: no, jibel said to update the .history file on lillypilly
<infinity> Ick.
<infinity> Please just use britney hints for one-time things like that.
<pitti> something else is wrong there; the failing bluez test ought to hold back dbus
<infinity> Hacking the actual infrastructure doesn't seem helpful unless we're FIXING the infrastructure.
<pitti> infinity: well, jibel is at debugging it
<seb128> ok, I take that as "no objection"
 * seb128 deletes
<pitti> seb128: ack
<infinity> seb128: Yeah, delete away.
<infinity> seb128: I assume a fix is on the horizon, though?
<seb128> infinity, yes, tyhicks is on it
<tyhicks> yep
<tyhicks> infinity: I'll reupload an entirely new dbus that includes the fix
<Laney> infinity: I thought you said so to hyperair
<seb128> pitti, jibel: cairo moved to saucy, thanks!
<Laney> the upstream / Debian guy has been asking us about it with increasing frequency
<pitti> seb128: yw
<infinity> Laney: Oh, I think he asked me about it last week, I told him to poke me later, and he never poked, and I forgot.
<Laney> Doh.
<seb128> tyhicks, https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1217757 might be due to that dbus as well
<Laney> Well, here be a poke.
<ubottu> Launchpad bug 1217757 in gedit (Ubuntu) "Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. " [Undecided,New]
<hyperair> infinity: i did, but i don't think you read your scrollback pings
<hyperair> infinity: at least, you appeared afk all the times i tried
<infinity> hyperair: I normally do.  May have missed some, it's been a weird week.
<hyperair> heh oh well
<infinity> hyperair: So, is this going to Debian as well, or just us?
<hyperair> it's in debian already i think
<hyperair> oh wait
<infinity> It sure isn't.
<hyperair> it'll get into debian when rdeps are done
<hyperair> it's messaging menu stuff after all. the status of packaging all of the indicator stack is rather incomplete in debian iirc
<infinity> hyperair: See, this would have been much less hassle if you got it into Debian and synced, but meh.  I'll review it here quickly.
<Laney> Isn't MessagingMenu  an Ubuntu thing?
<hyperair> infinity: ^ that's the problem.
<infinity> Laney: It is, but there's no reason we can't have it in Debian too, and some of the bits are, AFAIK.
<hyperair> some bits are, but it's horribly incomplete
<infinity> Yeah.  We should fix that.
<infinity> But not today. :P
<hyperair> yeah
 * hyperair thinks zhenech was taking care of that..
<tyhicks> seb128: thanks - I'll look into that some more
<seb128> tyhicks, I commented on the bug
<seb128> tyhicks, the a11y stack uses its own private bus, not the session one
<seb128> tyhicks, so that's sort of a special case, maybe that's not handled well by the confinement?
<tyhicks> seb128: it is a possibility if an app on one end of the dbus connection is confined
<hyperair> infinity: oh yeah, i think i recall why i didn't get involved in packaging indicator stuff for debian. it's all bzr. >:(
<Laney> I'm not sure that pkg-ayatana team is really active any more
<hyperair> bleh
<infinity> It could probably do with a friendly hijack by someone who actually intends to use the stack in Debian.
<hyperair> maybe if it didn't use bzr..
<infinity> You mean upstream?
<infinity> Cause I don't really care what my upstreams use.  Hide it in a get-orig-source debian/rules target and scream "LA LA LA" while you ignore the upstream VCS.
<Laney> gosh
<seb128> yeah for vcs trolling...
<Laney> pitti: you were right about lillypilly
<infinity> If you mean the Debian packaging, as Laney points out, pkg-ayatana is probably dead.
<Laney> even http sucks
<seb128> it's the same commit/diff/push/etc than with most other vcses, that should be good enough for packaging
<hyperair> infinity: no, pkg-ayatana uses bzr.
<hyperair> maybe it deserves a hijack..
<hyperair> seb128: that's if you only use commit/diff/push/etc
<pitti> Laney: too much stuff running on it these days :/
<hyperair> and i was just being grumpy about it, not intentionally trolling. you turned it into trollbait and bit on it.
<Laney> pitti: the archive box should offload some of that
<seb128> hyperair, which, for a packaging vcs, is mostly the case ... (at least if you don't do full source based on upstream style)
<infinity> hyperair: Accepted, built, and accepted again.
<hyperair> infinity: thanks
<hyperair> seb128: which i do.
<hyperair> seb128: while i'm at it, i also use pristine-tar.
<hyperair> and i have a whole bunch of custom scripts built around my workflow on git, and bzr breaks all of that
<hyperair> and i dislike the way the bzr tools work
<hyperair> can we end this here now?
<pitti> well, you started it :)
<infinity> hyperair: Only via a fight to the death with foam swords emblazoned with catchy sayings about your favourite VCS.
<hyperair> pitti: 17:09:17 <hyperair> and i was just being grumpy about it, not intentionally trolling. you turned it into trollbait and bit on it.
<RAOF> infinity: Etched in reverse runes?
 * hyperair sighs
<infinity> RAOF: Etching a foam sword is hard.  I was thinking written in Sharpie.
<hyperair> couldn't a foam cutter thing work?
<RAOF> Lasers.
<RAOF> It's the solution to everything!
<infinity> Lasers solve everything.
<infinity> Jinx.
<hyperair> oh yes, lasers.
<hyperair> to be cheap you could just use a soldering iron as well
<infinity> Well, a nice precision CNC would do the trick.  But a laser CNC would be nicer.  Maybe it's time to upgrade.
<xnox> wgrant: failed due to existing merge-proposal \o/ set it to rejected.
<xnox> wgrant: requeued cloud-init again.
<darkxst> xnox, hi
<xnox> darkxst: hello.
<darkxst> so I got no where trying to setup a pam session, python3-pam seems broken
<darkxst> but anyway can you merge my changes before feature freeze?
<xnox> darkxst: sure. Gnome-shell is not listed as alternative dependency, but I can fix that up.
<darkxst> xnox, and really need to get the sso thing fixed before beta, but I have no idea what is causing it other than presumably some missing dep
<darkxst> xnox, or just disable sso on ubuntu GNOME
<xnox> darkxst: i'll check / fix u1
<cjwatson> darkxst: the syslinux and gfxboot themes (you probably need to change both - just make sure to keep the exact same image formats) are in data/saucy/ in lp:~ubuntu-cdimage/debian-cd/ubuntu
<lifeless> pitti: cool, thank you!
<xnox> roaksoax: seems like everything works now "checking for COROSYNC... yes" will upload lvm2 in a moment.
<darkxst> cjwatson, thanks
<jamespage> doko_, if you are around can you take a look at the build failure for libunwind - I can get things building OK on amd64 but all other archs are failing with a lzma linking error
<xnox> roaksoax: lvm2 uploaded, now it build-dep-waits on dlm to be promoted to main. pinged release team about it.
<jbicha> can we drop the packagekit stuff from the sync-blacklist now?
<cjwatson> jbicha: I just did
<cjwatson> jbicha: I'm working through a sequence of things to sponsor provided by glatzor
<jbicha> cool, thanks
<jbicha> cjwatson: I have gnome-packagekit ready or I can defer to you if you just want to handle it
<cjwatson> jbicha: is it the same as glatzor's work in bug 1200303?
<ubottu> bug 1200303 in gnome-packagekit (Ubuntu) "Sync gnome-packagekit 3.8.2-4 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1200303
<cjwatson> (mistitled, it's not a sync)
<jbicha> yes
<cjwatson> jbicha: feel free then
<jibel> pitti, latest upload of cloud-utils broke the test VMs
<pitti> jibel: yeah, I noticed; but it's not really uninstallable in saucy
<pitti> jibel: is that because it's already pre-installed?
<jibel> pitti, not sure what's wrong. cloud-utils is installed by default on cloud images and 0.27-0ubuntu3 splits cloud-utils into cloud-guest-utils and cloud-image-utils
<jibel> furthermore there is no daily cloud-image for today
<jibel> pitti, ah file conflict during package upgrade http://paste.ubuntu.com/6036233/
<jibel> smoser, ^
<penguin42> when I start soffice on saucy; and select a sheet - it's displaying a ludicrous number of columns/rows that I can hardly see - is that just me or are others seeing it?
<pitti> jibel, smoser: indeed, cloud-*-utils need a C:/B: on cloud-utils (<< 0.27-0ubuntu3)
<pitti> err, C:/R:
<doko_> jamespage, will do
<jamespage> doko_, thanks
<pitti> jibel: annoying, this is breaking even more tests..
<pitti> jibel, smoser: as smoser didn't respond, I'll upload cloud-utils now
<pitti> bug 1217846
<ubottu> bug 1217846 in cloud-utils (Ubuntu) "package cloud-image-utils (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/ubuntu-cloudimg-query', which is also in package cloud-utils 0.27-0ubuntu2" [Undecided,New] https://launchpad.net/bugs/1217846
<jibel> pitti, k, that'll be faster than me fixing all the base VMs manually
<pitti> jibel: done
<jibel> pitti, thanks
<pitti> yay, all i386 builders busy
<cjwatson> shouldn't last that long
<pitti> yeah, compiz is almost done
<wgrant> xnox: That looks like success.
<xnox> wgrant: \o/
<smoser> jibel, i'm sorry. and i told you yesterday i wouldn't break things.
<smoser> thank you pitti  and jibel
<smoser> sorry.
<jibel> smoser, it's okay, I'm running the tests again with the new package. It seems fine now.
<pitti> jibel: ah, you already retried the recent lot, thanks
<pitti> (back from lunch, was about to kick them)
<sil2100> Hi everyone
<sil2100> I would need some core-dev to ACK the following packaging change: http://paste.ubuntu.com/6036553/
<sil2100> ogra_: ^? ;)
<sil2100> kenvandine: !
<ogra_> sil2100, looks fine
<sil2100> kenvandine: morning, as you just joined I guess you have 15 seconds?
<kenvandine> hey sil2100
<sil2100> ogra_: thanks!
<sil2100> kenvandine: nevermind !
<kenvandine> :-D
<sil2100> kenvandine: but while you're still around, maybe you know something from the daily-release bits...
<sil2100> kenvandine: since I'll be switching to manualpublish: True for all stacks (request from asac which got ACKed more-or-less by seb128)
<sil2100> kenvandine: do you know if I have to redeploy a stack after that?
<asac> kenvandine: hi, let me forward the mail./ also to cypher
<kenvandine> i think so
<sil2100> ;/
<sil2100> kenvandine: thanks
<kenvandine> sil2100, but i doubt you need to reconfigure the branches, so use the flag to skip that part
<Ampelbein> Hello everybody. Why does "bzr branch ubuntu:saucy-proposed/blackbox" say "ERROR: Not a branch"? https://launchpad.net/ubuntu/+source/blackbox shows a version in saucy-proposed.
<cjwatson> Because http://package-import.ubuntu.com/status/blackbox.html
<Ampelbein> cjwatson: Thanks.
<roaksoax> xnox: cool thanks!
<pitti> xnox: dh-python fails with real errors now (the cloud-init problem is fixed in saucy now)
<xnox> pitti: looking. it passed here.
<pitti> xnox: it can't ever have, as the nosetest outputs to stderr
<xnox> pitti: and declares that stderr is allowed...
<pitti> xnox: "Restrictions: allow-stderr" or teach it to output to stdout
<pitti> xnox: ah, then I guess it's the dh-python test which errors out with 1
<xnox> pitti: yeah t205 failed.
<xnox> pitti: haha, so python-support must be installed for the dh_python2 tests to work *lol*
 * xnox goes to fix.
<pitti> xnox: uh, how that? not dead enough yet?
<xnox> pitti: dh_python test-suite doesn't use --with python2, instead it was doing "override_dh_pysupport:" to call dh_python2. Well, neither dh_pysupport nor override_dh_pysupport are called any more, if python-support is not installed.
<xnox> so i ported those tests, to not rely on dh_pysupport =)))
<pitti> *applaud*
<slangasek> barry beuno cjwatson dholbach sergiusens ssweeny xnox lool: can I move this session up to be 18:00 today?  tvoss__ needs his session moved to tomorrow. http://summit.ubuntu.com/uds-1308/meeting/21909/foundations-s-touch-download-service/
<sergiusens> slangasek: fine by me, but I am not mandatory
<barry> slangasek: yep.  i see no other conflicts at that slot
<beuno> slangasek, sure
<pitti> xnox: nice, it passed now
<ssweeny> slangasek, sure thing
<xnox> slangasek: sure.
<dholbach> sure
<cjwatson> slangasek: I might need to be in the click/appstore CI session at that time, but I doubt I'm required for all of that, and in any case I already gave xnox my feedback on the rapid start session to pass on in case I couldn't make it
<lool> slangasek: yes
<lool> slangasek: I have some conflicts, but nothing critical
<slangasek> ok, moving - thanks
<tvoss__> slangasek, thanks for the help
<cjwatson> oh, you said the touch download service session anyway, not rapid start ...
<seb128> do we support updates from LTS to newer non versions when they are out of their support period?
<seb128> nonLTS versions
<seb128> to give some context, that's being asked in the libreoffice session
<seb128> e.g if next year precise get a libreoffice newer than quantal, is that an issue?
<seb128> (that would be problematic for precise->quantal updates)
<slangasek> seb128: definitely not supported, we have a hard time even supporting upgrades from EOLed non-LTS versions to a supported LTS
<seb128> slangasek, ok, thanks
<seb128> cjwatson, libunity-webapps hits "autopkgtest for unity-firefox-extension 2.4.7bzr13.04.15-0ubuntu1: FAIL (Jenkins: public, private) "
<seb128> cjwatson, well, we get the rebuild uploaded, but it's blocked by britney on that, seems like those tests were never green, you might want to force it
<cjwatson> yeah, I was just checking that
<cjwatson> if nobody cares about that test, maybe it should be deleted?
<Laney> More always broken tests that nobody cares about :|
<cjwatson> (it looks like it's failing due to trying to go off to pypi, rather than because the package is broken ... i.e. test framework failure)
<cjwatson> seb128: force-badtest'ed, anyway
<seb128> k
<ScottK> Mirv: Debian's already started uploading 5.1.1, so a direct merge ought to be easy enough when the time is right.
<Mirv> ScottK: that's nice, I'd like to sync at least 9 packages directly
<Mirv> we've some package transitions because of raring, and then qtbase+qtdeclarative+qtwebkit additional patches, as approximate summary
<ScottK> Also qtcreator.
<ScottK> It'd be nice to get the Ubuntu SDK stuff into a different source so we could sync that too.
<Mirv> yes, that's the plan of the SDK team, now partially done but the real compiled plugin also needs to move to lp:qtcreator-plugin-ubuntu
<linuxtech> Lamont Jones has uploaded  bind9_9.9.3.dfsg.P2-3 to incoming.debian.org and I know he planned to get it into saucy prior to the FeatureFreeze, but I am not seeing the package in Ubuntu yet.  Ubuntu doesn't have an incoming.ubuntu.com and I checked http://archive.ubuntu.com/ubuntu/pool/main/b/bind9/, where else should I look for it?
<cjwatson> lamont: ^-
<cjwatson> linuxtech: https://launchpad.net/ubuntu/+source/bind9
<cjwatson> if it's not visible there it hasn't been uploaded
<lamont> I was letting it age until this afternoon
<linuxtech> It's not there yet, thanks!
<cjwatson> we don't have an incoming.ubuntu.com because we don't need one :-)
<xnox> barry: os.path.exists is lying to me! It says False, when the right answer is to raise PermissionError
<cjwatson> Not sure I agree
<cjwatson> I think of os.path.exists as something that should parallel test -e
<cjwatson> Anyway it's documented behaviour :-)
<barry> xnox: well, os.path.exists() returns False if os.stat(path) raises an OSError
<barry> does not check what kind of OSError you get
<barry> cjwatson, xnox: correct :) http://docs.python.org/3/library/os.path.html#os.path.exists
<xnox> barry: but "try: found=True; os.stat(path) except OSError: found=False" is ugly!
<barry> xnox: EAFP!
<xnox> barry: European Association of Fish Pathologists ?
 * xnox is confused
<cjwatson> add "python" to your google search terms :)
<xnox> i see. ok
 * xnox goes to apply.
<sarnold> seb128: 1217841 has been six hours without retracing, are they broken again?
<seb128> sarnold, yep, down again
<seb128> I hate those retracers :p
<seb128> the stacktrace doesn't really make sense to me
<seb128> I guess I'm going to untag the bug it fails on so it can keep retracing others
<seb128> then check with pitti tomorrow
<sarnold> seb128: heh, yes, I can imagine :) they're very nearly magical, and when they work, it's impressive, but daily work stoppages is less than ideal. Thanks for re-poking them. :)
<seb128> sarnold, is that your own reported bug you are checking on or do you watch some list of bugs coming from somewhere?
<tkamppeter> anyone has an idea why a package can build on amd64, armhf, and powerpc but not on i386? See https://launchpad.net/ubuntu/+source/ghostscript/9.10~dfsg~rc1-0ubuntu1.
<seb128> tkamppeter, i386 builds the arch all binaries, the other archs not
<tkamppeter> seb128, yes "make" seems to have succeeded, so it seems that it is in the distribution of the built files in the binary packages, but there is no useful error message after the succeeded "make".
<seb128> tkamppeter, that doesn't seem the case here
<seb128> tkamppeter, the error is at the start of the log
<seb128> tkamppeter,
<sarnold> seb128: I just go through the pile of bugs labelled 'security' and try to shove them on their way. When I notice something hasn't been retraced in a handful of hours, I ask if it's been held up. not that I care abou any specific bug, but that it'd be nice to keep things moving for users. :)
<seb128> "cp ./openjpeg/opj_config.h.in.user ./obj/opj_config.h
<seb128> cp: cannot create regular file './obj/opj_config.h': No such file or directory
<seb128> make[1]: *** [obj/opj_config.h] Error 1"
<seb128> sarnold, right ;-)
<sarnold> seb128: since nearly everything with a coredump is labeled a private security problem, I figure they won't get any attention at all from anyone until we can knock that 'private' off of them :)
<seb128> tkamppeter, could be a race bug combined with the -j option
<seb128> tkamppeter, let me retry the build
<seb128> sarnold, any news on the openjpeg mir btw? ;-) (seeing that ghostscript build made me think to it)
<sarnold> seb128: yes, I think I'm about 1/3 of the way through it. it's highly intricate / global-variable heavy code. :/
<seb128> sarnold, I guess there is no hurry, ghostscript went back to use their copy because some fix didn't made upstream yet it seems
<seb128> sarnold, I'm mostly asking because I would like to build poppler with it though
<infinity> sarnold: If other image manipulation libraries are anything to go by, I think we can just count on it being insecure by design and weep quietly as we let it in anyway, right? :P
<sarnold> infinity: haha, yes. :)
<tkamppeter> seb128, sarnold, from the Ghostscript side I will not need openjpeg in this cycle. My attempts to build GS with system openjpeg failed and I returned to Ghostscript's own openjpeg.
<sarnold> cripes that's just as bad :) hehe
<sarnold> it'd be nice to only have one copy of whatevre it is... hehe.
<infinity> Indeed.
<infinity> seb128: You mentioned "some fix didn't make it upstream", surely we could identify that and carry it in our system copy, rather than perpetuating the code duplication of this (apparently hideous) codebase. :P
<seb128> tkamppeter, ^
<seb128> infinity, right, I was mostly reading the changelog from that ghostscript upload from tkamppeter
<seb128> sarnold, infinity: btw I should try to update our version to the current serie (1.5 at least)
<tkamppeter> seb128, it seems that the "make" of GS seems to try to copy a file into obj/ before mkdie obj/, perhaps I have to call mkdir obj before running "make"?
<infinity> tkamppeter: That usually means they're missing a dependency in one of their makefiles.
<qengho> seb128: I know a guy who needs help getting a dependency of his project updated. Who should I point to his (non-Desktop, Universe) bug report to? https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1212481
<seb128> tkamppeter, why did it work on other archs?
<ubottu> Launchpad bug 1212481 in couchdb (Ubuntu) "Saucy: CouchDB 1.4.0 needed to work with Erlang 16.b.1" [Undecided,Confirmed]
<infinity> tkamppeter: Which is exacerbated by building with multiple threads.
<seb128> qengho, tell them to subscribe ubuntu-sponsors I guess?
<qengho> Thx!
<tkamppeter> seb128, why it fails on 1386 and succeeds on all the others I do not understand.
<infinity> tkamppeter: Because i386 calls different rules than other arches.
<infinity> tkamppeter: It can probably be reproduced on amd64 by using "dpkg-buildpackage -b" instead of "dpkg-buildpackages -B".
<infinity> s/buildpackages/buildpackage/
<tkamppeter> infinity, and the build server does "make -j8", my machines at home do not use the -j option when building GS.
<infinity> tkamppeter: They would if you used DEB_BUILD_OPTIONS="parallel=8" :P
<infinity> If your package claims to support that, it will be used.
<tkamppeter> seb128, infinity, should I perhaps make -j on the build servers be suppressed, perhaps by DEB_BUILD_OPTIONS="parallel=1"?
<pitti> seb128: thanks, amd64 is again catching up
<infinity> Anyhow, got the same failure here with -j4.
<infinity> Let me try with 1.
<infinity> Ugh, why is this still CDBS?
<infinity> tkamppeter: I believe the CDBS way is to set DEB_PARALLEL_JOBS to 1.
<infinity> I think.
<infinity> Anyhow, that might not even be the problem.
<slangasek> barry: joining the hangout?
<barry> slangasek: sure :)
<slangasek> barry: https://plus.google.com/hangouts/_/6dd72c850c11015d570e57ed45e02492a2755a11
<tkamppeter> infinity, did it build with 1?
<infinity> tkamppeter: Yes.  Oh, and there's a DEB_BUILD_PARALLEL right there in debian/rules.  Flipping that from 'yes' to 'no' probably fixes it. :P
 * infinity tests.
<slangasek> or fixing the make dependencies properly
<infinity> tkamppeter: Of course, finding the actual dependency bug would be better.
<infinity> slangasek: Jinx.
<xnox> infinity: no, one needs to remove it. or set it to empty, as the test is $(if $(DEB_BUILD_PARALLEL),...)
<infinity> xnox: CDBS is so much fun!
<xnox> infinity: with '0' or 'no' it will still keep parallel build =)
<tkamppeter> infinity, so I will comment out the DEB_BUILD_PARALLEL line and reupload that. Is this OK?
<infinity> tkamppeter: I'm testing now to see if that DTRT.
<infinity> tkamppeter: Yeah, that seems to disable -jX
<infinity> tkamppeter: As mentioned, of course, it would be best to find the actual bug, but this works as a stopgap.
<infinity> But the part where you've just made the build take between 4 and 24 times longer on the buildds kinda sucks. :P
<xnox> stgraber: slangasek: cjwatson: ogra_: not sure who pinged me, but android build does pull stuff from -proposed for embedded components. So as soon as src packages are published in -proposed, one can rebuild the android package.
<ogra_> xnox, awesome !
<tkamppeter> infinity, seb128, thank you very much, new GS without parallel build uploaded.
<slangasek> xnox: it just pulls those as build-dependencies, I hope?
<stgraber> ogra_: can you do the same for ubuntu-touch-generic-initrd?
<ogra_> stgraber, if xnox teaches me :)
<slangasek> ogra_: build-depends
<slangasek> nothing else required (and nothing else is appropriate)
<cjwatson> xnox: great, thanks
<xnox> stgraber: slangasek: ogra_: well.... a couple of debs & src packages.
<slangasek> ah, source packages, boo
<ogra_> slangasek, what about them ?
<slangasek> ogra_: "do the same for ubuntu-touch-generic-initrd" should just need build-dependencies...
<xnox> slangasek: i'd pull them as build-dependencies if I could pull: pkg:armhf on i386 build =)
<slangasek> xnox: hmph, right ;)
<slangasek> ok
<xnox> =)))
 * slangasek steps back into the multiarch shadows
<ogra_> oh, i forgot that this is a cross built thingie
<slangasek> it's built for android, therefore it's always cross-built even if we did it on arm :)
<ogra_> slangasek, its not built for android, its just an initrd
<ogra_> it creates a fakechroot and runs update-initramfs in it
<slangasek> ogra_: I meant the android source package
<ogra_> i just dont get how build-deps can have any influence on the pocket the deps are pulled from
<slangasek> ogra_: because the buildds always pull build-deps from -proposed
<ogra_> ah !
<slangasek> otherwise, library transitions would be difficult ;)
<ogra_> yeah
<slangasek> however, if you're calling debootstrap, that's something else entirely
<ogra_> slangasek, yeah, i think i would have to add proposed to the chroot sources.list
<ogra_> or some such
<infinity> Yeahp.  d-i has to pull similar tricks.
<slangasek> yeah; you can't debootstrap from multiple pockets simultaneously (unless someone's implemented that recently), so it's: debootstrap from saucy, add -proposed, dist-upgrade, etc.
<ogra_> but i dont want everything to come from proposed ... so there it gets tricky or hackish
<infinity> Also, I assume you're using the "use the same mirror as the buildd chroot" trick?
<slangasek> why don't you?
<slangasek> I think you do want everything from -proposed
<ogra_> infinity, indeed
<infinity> ogra_: You absolutely want everything from -proposed, you're not a unique snowflake here.
<slangasek> or you want to build exclusively against *not* -proposed
<infinity> All packages should build against proposed.
<slangasek> but you don't want to cherry-pick from -proposed.
<ogra_> ok
<infinity> Well, rather, all packages should build against the pocket they're in.
<slangasek> why are we doing this as a package, btw?
<infinity> If you want to be properly anal retentive about this.
<ogra_> but that means that i might end up with stuff inside the initrd that never makes it out of proposed
<slangasek> initramfses for distribution are traditionally built on the livefs builders
<infinity> Which also means supporting building in PPAs (for security updates).
<infinity> And security updates don't build against proposed, so that shouldn't be hardcoded, but detected.
<ogra_> slangasek, so the android build can pull it in from LP during build
<ogra_> slangasek, we dont need the initrd per se, we need the boot.img
<ogra_> and that comes from the android package
<slangasek> hmm, hmm
<infinity> ogra_: The answer to the "it might include stuff that migrates out of sync" is to do what I did for d-i with a metapackage with hard deps.
<infinity> (Well, one way to deal with the problem)
<ogra_> so we drop the ubuntu initrd into the tree and the android build scripts pick it up when generating the boot.img
<slangasek> I am unconvinced that it makes sense to do anything that needs the boot.img as part of the package build, as opposed to deferring all of that, and any dependencies on it, out of the android package to the livefs builder
<infinity> So you don't get to migrate until your deps all can.
<ogra_> infinity, well, after all i only want one package
<slangasek> (and I think either you or xnox tried to explain this to me once before, but I didn't manage to internalize it)
<tkamppeter> infinity, seb128, the i386 is succeeding now (currently it is writing the binary packages).
<seb128> tkamppeter, great
<xnox> ?
<ogra_> slangasek, i think rather rsalveti or sergiusens  :)
<tkamppeter> seb128, infinity, now it has completed.
<slangasek> xnox: I'm trying to understand why ubuntu-touch-generic-initrd is a package
<slangasek> though now I wonder if ogra is talking about boot.img from the android source rather than ubuntu-touch-generic-initrd
<ogra_> slangasek, because we need a binary initrd.img
<infinity> slangasek: If the artifacts of ubuntu-touch-generic-initrd are needed for the android build, I imagine that's the sticking point.  Since the android package build can't pull random bits from cdimage.
<ogra_> yes
<infinity> (Can't and shouldn't)
<ogra_> slangasek, the android package pulls in ubuntu-touch-generic-initrd during build (like it does for libhybris, compilers etc)
<slangasek> right, so I'm asking, can't we make the android package not need it
<ogra_> slangasek, our boot.img that we use in the zips is created by the android package
<slangasek> and maybe the answer is "yes, but not right now"
<slangasek> ogra_: telling me "that's how it's done today" doesn't address my point :)
<ogra_> we didnt use it from there until recently
<infinity> ogra_: He might be suggesting that the boot.img shouldn't be produced by a package build.
<slangasek> I might
<ogra_> i used to create the boot.img on the livefs builder before
<ogra_> but if there are changes in android ... i.e. cmdline defaults or some such they wouldnt get picked up
<infinity> I have no fundamental issues, personally, with a package build creating boot images (hi, debian-installer), but you do need to take care of sane dependencies and migration for things that include random binary bits from other packages in their output.
<ogra_> slangasek, all ports need this initrd during their android build ...
<ogra_> thats why we integrated it there instead of on the livefs builder
<ogra_> we could rip that bit out for our own builds, but that means dual maintenance of the same thing
<rsalveti> yeah, iirc this was the main reason why we decided to make it a package
<ogra_> right, took me a bit to remember :)
<slangasek> I don't see how having it in the package instead of on cdimage matters to the ports
<ogra_> slangasek, it needs to be pulled in during build for them ... we already have some lp_pull magic ... that pulls in all the other bits packaged
<rsalveti> avoid duplication
<slangasek> what duplication?
<rsalveti> maintaining a package for porters and our own in cdimage
<ogra_> slangasek, we need the initrd.img in any case... you woulldnt create that on the livefs builder unless you do exactly the same as the package currently does (a dedicated chroot)
<ogra_> since you dont want to taint your livefs build with the initrd stuff
<ogra_> at least the build scripts woould be duplicated and cause dual maintenance
 * ogra_ thinks a package is the most elegant solution we have here 
<slangasek> rsalveti: I'm saying it shouldn't be maintained as a package *at all*
<slangasek> unlike infinity, I do have a fundamental problem with doing this kind of thing in a package if it's not absolutely needed ;)
<ogra_> why ?
<slangasek> because fakechroot, frankly :)
<ogra_> just because we "traditionallz do it on a live builder" ?
<xnox> ogra_: but you can update the .zip on livefsbuilder / cdimage ?!
<slangasek> we traditionally do it on the live builder because that's the sensible architecture we came up with for handling these cases
<ogra_> xnox, update ?
<xnox> ogra_: zip -u
<ogra_> yes
<rsalveti> slangasek: but then we'd need to duplicate the logic somewhere for the porters :-)
<ogra_> xnox, thats what we did until the package was around
<xnox> rsalveti: we'll keep the one in android, but update it on cdimage, just-in-case or to seed up the respin.
<slangasek> rsalveti: I still don't see why.  If we've created the boot.img, we publish it to cdimage, boom we're done?
<xnox> s/seed/speed/
<ogra_> slangasek, and how do ports get the content of boot.img ?
<stgraber> ogra_: wget + abootimg -x ?
<stgraber> ogra_: we could also publish the raw initrd.img somewhere on cdimage.u.c so they don't need the abootimg step
<ogra_> stgraber, great, so we force them to download stuff they absolutely dont need to fish a binary bit out of another binary file ?
<rsalveti> I don't see how much more elegant that would be
<rsalveti> would we fix any issue if we do that?
<ogra_> instead of giving them the bit they need cleranly without extra cruft around
<rsalveti> or would just make it easier to update the boot.img without respining the android package?
<xnox> slangasek: you are trying to have 1 true way to do something =) at the moment I ignored that by providing options ;-)
<rsalveti> which I'm not sure it's an ideal solution either
<xnox> rsalveti: that's what i offered, keep android package as it is, but on cdimage respin rebuild & in-place update the .zip because it's quick.
<xnox> rsalveti: same with kernel, preferably.
 * ogra_ really likes the package way (even though i didnt in the beginning) ... and i havent heard anmything convincing yet that makes me want to roll back to the former model
<slangasek> ogra_: sorry, but I'm really not understanding your arguments.  "How do they get the content of boot.img" - I don't see any boot.img in any of the packages, either
<rsalveti> xnox: right, that would be the only benefit, but not sure if the pain for porters would justify
<ogra_> xnox, right, but we need a setup that works for all of us, including the ports
<xnox> ogra_: do both =) \o/   the respin speed - no need to rebuild android package to update (a) kernel (b) any of initrd.
<ogra_> slangasek, the porters nmeed the initrd
<xnox> ogra_: correct that's why android package will continue to pull initrd the way it is.
<ogra_> slangasek, if the onlz way to get it is from cdimage by ripping it out of the bootimg ....
<slangasek> ogra_: that is not the point of contention - I don't see anywhere you're *CURRENTLY PROVIDING IT*
<slangasek> and I don't see any reason that providing it in a package is in any way superior to providing it on cdimage as a build artifact
 * xnox steps out for a moment before next session.
<stgraber> xnox: we'd need to update both the .zip and the .img (system-image doesn't use the .zip at all)
<ogra_> slangasek, android ships it, cdimage porvides it
<ogra_> slangasek, adnroid as in the package
<ogra_> slangasek, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130822/*boot-armhf+$subarch.img
<slangasek> ogra_: what does that have to do with ports?  those are the per-subarch images for our supported devices
<ogra_> these are the only public files (beyond the package) that provide you the latest initrd.img for touch
<ogra_> slangasek, right, these are results of the android build that the package does (as well as the tree on phablet.u.c)
<ogra_> the only thing thats not coming from the adnroid tree is the rootfs zip in that cdimage place
<rsalveti> we could do whatever hack we want to make the porters to pull that boot.img and extract the initrd, but I don't see why we should do that
<ogra_> yeah, thats extremely ugly
<slangasek> I'm not arguing for forcing porters to extract anything from anywhere
<rsalveti> we're trying to optimize something that already works just to reduce the amount of package uploads
<rsalveti> well, porters would need to get it from somewhere
<rsalveti> the archive seems to be the best place to be
<slangasek> I'm saying that, whatever the deliverable object is that you need to hand off to porters, it should just be built on the livefs builder and distributed from cdimage
<slangasek> rather than shoehorning it into the archive and then having to contend with questions of "how do we pull from -proposed"
<ogra_> slangasek, so we should build hybvtris and the toolchains on the livefs builder too so their android build can pull them from there ?
<slangasek> no
<ogra_> why not just use a consistem way for all the bits we have to pull into the build
<ogra_> *consistent
 * ogra_ neeeds to relocate for a session ... 
<slangasek> because your "consistency" led to the ubuntu-touch-generic-initrd package
<slangasek> which is a second layer of package hackery
<ogra_> slangasek, its a deboostrap, installation of one package and a call to update-initramfs ... its not sexy but fine for the purpose
<slangasek> stgraber: it would be good to have you in the call about 13.10 post-release support, are you available to join? https://plus.google.com/hangouts/_/006bf4a2afd21e219c0b18cbd32a8d53e9dc89bb
<sergiusens> ogra_: I think I have a big backlog to read
<ogra_> haha
<mitya57> Mirv: FYI, I've updated qtwebkit-examples, qtdoc and qtquickcontrols branches in bzr. I
<mitya57> *It would be nice to get at least qtquickcontrols in Saucy
<stgraber> slangasek: messed up my timezone maths and started working on something else... will be there in a sec
<lamont> linuxtech: bind9 1:9.9.3.dfsg.P2-3 synced
<tkamppeter> infinity, seb128, GS 9.10rc1 has made it into Main now.
<ESphynx> Hey guys, so the various compositors that are installed with Ubuntu all suffer from this delayed update bug here on my laptop with nVidia card
<ESphynx> it's a serious useability issue, the only thing that doesn't suffer from it is Gnome Flashback (No effects)
<ESphynx> As described in http://ecere.com/mantis/view.php?id=987 ... People in #nVidia are agreeing with me the compositors are at fault
<sladen> ESphynx: bug number?
<ESphynx> sladen: I'm not sure if there is an Ubuntu bug for it, that's sort of what I'm asking if anyone's aware of one
<ESphynx> Is the compositor for Unity/Gnome classic/flashback all the same? Is it still compiz?
<sladen> ESphynx: there are/have been several differnt compositors (metacity/Compiz/unity-system-compositor).  We would need to know more details, including the Ubuntu release
<sladen> ESphynx: and some high-level context.  Is this something to do with eg. dragging windows around and having the decoration lag?
<ESphynx> sladen: This is the latest Saucy
<ESphynx> no, this is within the application
<ESphynx> I'm rendering to a pixmap with XRender, and then doing an XCopyArea()
<ESphynx> and this happens with Unity, Gnome Classic, even Gnome Flashback if I don't select "No effects"
<ESphynx> and within the application I just go right/left to expand/collapse a tree view, and I end up in a lagged state when I think i'm on one tree view item, but I'm actually on another
<ESphynx> I also get this on our popup menu, where the previously selected item ends up the one being highlighted
<tarpman> nvidia+compositor makes me think of bug 861268 / bug 888666
<ubottu> bug 861268 in nvidia-graphics-drivers (Ubuntu) "text corruption in terminals (xterm, urxvt) and emacs" [Undecided,Confirmed] https://launchpad.net/bugs/861268
<ubottu> bug 888666 in gnome-shell (Ubuntu) "terminal doesn't refresh properly with nvidia-current drivers" [Undecided,Confirmed] https://launchpad.net/bugs/888666
<slangasek> ogra_: so the root problem is that putting this in a package is an extra layer of indirection that requires manual action from a maintainer to trigger an update.  Instead of just "trigger a livefs build against everything that's current in the archive", if you want to change something that affects the initramfs, you now have to do: upload the fix; wait for publication; upload ubuntu-touch-generic-initrd; wait for publication; upload *and
<slangasek> ... for publication; trigger the build
<slangasek> ogra_: that's two extra steps that we could completely avoid by just doing the initramfs handling entirely in the livefs builder
<slangasek> rsalveti: ^^
<sergiusens> slangasek: ogra_ rsalveti xnox sorry for coming in late, but can we strip out boot.img creation from android into it's own package that gets kernel + ramdisk setup for each device?
<slangasek> sergiusens: :-)  I am 100% arguing that assembly of the image should be on the livefs builder, and not in the package at all
<rsalveti> slangasek: we had that before, and ogra_ moved to be package based
<rsalveti> because of the porters
<rsalveti> so we could use one simple and the same solution for everyone
<slangasek> rsalveti: I think that's a false justification
<sergiusens> rsalveti: I don't see the problem with porters
<ESphynx> tarpman / sladen: I've added to http://ecere.com/mantis/view.php?id=987  a discussion with aaronp on #nVidia regarding this issue
<rsalveti> so we could have one generic initrd that was maintained in the archive
<ogra_> slangasek, no
<slangasek> there are generic bits that we have to provide to the porters as build artifacts; those can be provided on cdimage
<sergiusens> slangasek: +1
<sergiusens> rsalveti: exactly, we can just publish the ramdisk on cdimage
<ogra_> slangasek, you have to trigger the binary build of an initrd for the porters in any case ... i wouldnt want to have to roll a full image just for a one line fix that only helps the porters
<rsalveti> sergiusens: why not in the archive?
<rsalveti> yeah
<sergiusens> rsalveti: that goes to my other suggestion above
<rsalveti> it's not ideal either
<ESphynx> Should I file a new bug as well?
<rsalveti> we do get quite a few uploads in the initrd just because of the porters
<slangasek> there are bits that the porters have to do locally as part of the porting; currently they do that using upstream android trees, *not* using our android source package; but our android source package should soon be built from the "official" Ubuntu Touch tree (?)
<rsalveti> connecting that with the image build seems just a waste
<ogra_> it means we kick off the whole infrastructure including asac and a test run
<ogra_> just for a change in the initrd for some porter
<slangasek> ogra_: is that really something that's happening now?  Having to make uploads for one-line fixes to the generic initrd, that only help the porters?
<rsalveti> yes
<rsalveti> quite frequently actually
<ogra_> yeah, all the time
<slangasek> hum
<ogra_> slangasek, i dont mind changing it, but i dont buy the "it's one more layer in the generic-initrd package" give me something convincing, i'll happilky change it ... having to do a full image build for a changed initrd doesnt cut it though
<slangasek> ogra_: *two* more layers
<slangasek> and I seem to remember you were complaining not so long ago about the time it took for changes to land
<ogra_> the android layer is needed in all cases
<slangasek> no, the android source package doesn't have to be a layer on top
<ogra_> true,  long enough it wasnt
<ogra_> as i said, i only moved the boot.img creation recently
<ogra_> but simply to make sure we get git updates for the boot.img configs
<ogra_> i.e. if cmdline options change in android/CM, these are only in the git tree
<ogra_> slangasek, so how about i merge the two initrd packages, would that make you happier since we have one layer less ?
<sladen> ESphynx: so you're (only) seeing this on Saucy + Nvidea hardware and X?  (Could you add the exact package version numbers for Ubuntu/X/drivers)---I hadn't realised you were on Saucy.  Do you have a minimal test-case (ie basically just with the boilerplate and  XRenderFillRectangle()?
<sladen> ESphynx: then it can be filed in Launchpad (and linked to the other mantis tracker), and the relevant graphics people in Ubuntu can have a look
<sladen> ESphynx: +exact compositor version(s), as this is what aaronp is noting
<stgraber> barry, infinity, lool, slangasek: http://paste.ubuntu.com/6037949/
<lool> stgraber: ah right, I wasn't in the support session but in the SDK one; how did it go?
<stgraber> lool: well, I messed up my tz math so I made it 20min late, but besides that I think it was a good chat
<stgraber> lool: the conclusion is that I need to rewrite import-cdimage but I pretty much came to that one on my own before ;)
<barry> stgraber: so we'll have a channels.json entry called "13.04"?
<stgraber> barry: yep, each series will have at least 3 channels, one of which will be hidden
<stgraber> barry: then we'll have a few fake channels like stable and daily which will still be listed in channels.json but contain the same files as their target (except for a re-generated version.tar.xz)
<barry> stgraber: i'll have to make sure we can handle dots in channel names, but now that i fixed daily-proposed it should be easy
<lool> stgraber: notes >> 13.04?  13.10 or 14.04 surely?
<lool> stgraber: what happens at 13.10 release time?  do we keep updating the 13.10 bucket?
<lool> stgraber: otherwise LGTM, there will probably be a customized-proposed too, but that's for later
<lool> barry: it strikes me that we lack channel descriptions
<lool> barry: and .... translations  :-)
<lool> we aboslutely need to translate
<lool> stable
<lool> to stable
<barry> stgraber: so i see these feature/bugs here.  make sure 13.04 can be supported as a channel name, add a --list option to -cli, and handle the 'hidden' field
<lool> and unstable to instable
<barry> lool: ask didrocks about i18n image descriptions :/
<barry> our current approach is apparently not so much fun from a qt dbus perspective
<stgraber> lool: ah yeah, sure, 13.10 :)
<stgraber> barry: we also need support for phased-percentage in the client
<barry> stgraber: how would that work?
<stgraber> barry: same way update-manager does it, though I don't really know the details
<barry> stgraber: then, yay! :)
<stgraber> barry: IIRC you need to hash the version number with something unique to the device, then use that as a fixed seed to get a random number between 0 and 100. If that number is > phased-percentage, you apply the update, if it's not, you ignore it.
<stgraber> the idea being that we get that percent of devices to update to the new stuff but that the list of devices that get it first changes between updates (so we can't just seed with the IMEI only)
<barry> stgraber: but where does the phased-percentage value live?  in the index.json? channel.json?  is it per image, file record, device?
<stgraber> barry: it'll be an extra field of the image in index.json
<stgraber> barry: the last (and only the last) full and delta will have it set (if applicable)
<slangasek> ogra_: what are the two initrd packages?  android + ubuntu-touch-initrd-generic?
<ogra_> slangasek, initramfs-tools-ubuntu-touch and ubuntu-touch-generic-initrd could be one package
<ogra_> that would remove one upload from the chain
<ogra_> and not make us lose git changes to the bootimg creation from android
<barry> stgraber: so, if we have an update candidate path, we look at the last image in that path and check its phased-percentage.  if our randint is > then we can apply that candidate.  what if it's < ?  do we just ignore that as a candidate and try to upgrade to some other path?  or do we calculate the winning path first, then check it's phased-percentage, such that it's < we do no upgrades at all?
<stgraber> lool: update descriptions support translations. Channels don't have descriptions specifically because we didn't want to deal with translations. IIRC we said that those would either simply not be exposed in the UI or would be translated on the client side.
<stgraber> lool: when 13.10 releases we'll keep daily pointing to 13.10 for a while and maybe push a few bugfixes to that release with the mechanism we want to use for 14.04 (monthly bugfixes + security updates whenever they show up)
<stgraber> lool: then once 14.04 is ready for daily testing, we'll change the alias to point to 14.04
<stgraber> lool: and at some point after that, we'll consider the 13.10 stable experiment as over and will stop pushing updates there
<lool> ok
<barry> lool, stgraber we will have to discuss translations with didrocks when he returns.  there are several technical problems that will need to be ironed out (and some probably more global than system-image)
<lool> agreed
<stgraber> barry, lool, slangasek, infinity: so one remaining problem I have to solve in my plan is how to tell the client that it go moved to another channel when we change the target of an alias
<stgraber> barry, lool, slangasek, infinity: because we want the first update after the alias change to necessarily be a full image
<barry> stgraber: will that full image version > the current version of the old channel you're moving from
<stgraber> barry, lool, slangasek, infinity: but we have the problem that the current image from the new target may have a version lower than the one from the previous target
<ScottK> xnox: Did you send your dh-python changes to piotr?
<stgraber> barry: not necessarily, that's my problem :)
<barry> stgraber: yeah, exactly ;)
<barry> xnox: please do that!
<xnox> barry: i presume you are replying to my email, right?
<stgraber> barry: so I think we need an extra flag in channel.ini and in channels.json which tells us what's the target channel for the alias
<stgraber> barry: and if we see that change, then the next update has to be a full to the latest available image
<barry> xnox: to ScottK's request.  i'll let piotr respond to your email
<ScottK> xnox: Different changes.  He made some fixes in the autopkgtests.
<ScottK> err barry
<barry> ah
<xnox> ScottK: not yet, it only took 4 tries to get it working in the end today between vUDS sessions. And I have more urgent FF things to do at the moment.
<ScottK> I'm looking at ubuntu2 -> ubuntu4.
<xnox> ScottK: yes, and?! that's today between vUDS sessions.
<barry> stgraber: we could almost handle it all on the client side, i think.  let's say your on channel X and you give system-image-cli --change-to-channel Y.  we could force the current build number to 0 and select the winning target that gives us a full update, kind of like what --filter=full is going to do
<lool> stgraber: how about we list aliases as such and the client knows the channel it is on before the alias change, then decides to pick a full when the alias changes?
<xnox> ScottK: do you mind forwarding them if you have time now?
<ScottK> I don't have time now and won't before Friday.
<lool> stgraber: so basically target_channel = resolve_alias(configured_channel); if source_channel != target_channel: do a full update; else: look for deltas
<xnox> ScottK: same here =)
<ScottK> Maybe he'll look at the package.
 * cjwatson does a little dance as a non-virtual build abort works on dogfood.
<xnox> ScottK: plus i'd rather send pull-requests, than patches.
<barry> stgraber, lool oh wait, so the device could be on an alias, and there isn't exactly a literal channel change involved.  the alias "symlink" could just change out from under the device?
<cjwatson> (Albeit by way of a python prompt with xmlrpclib, but that'll be sorted soon ...)
<lool> barry: yeah
<stgraber> barry: right
<ScottK> xnox: He says he'll grab the package and look at it this weekend, so it should be fine.
<lool> barry: stable -> 13.10 becomes stable -> 14.04
<xnox> ScottK: cool, thanks.
<stgraber> lool: then we couldn't flash to an alias with phablet-flash because we wouldn't have the alias name anywhere on the flashed device. That's why I didn't go with simple symlinks on the server... we store the channel name in the version tarball
<lool> stgraber: not sure how you propose we write the alias name after a phablet-flash; why wouldn't that be preserved?
<stgraber> barry, lool: but having an extra field in channels.json giving us the target channel name should be reasonable and with that info in device.tar.xz too makes it trivial for system-image to figure out the target changed and then go with version = 0 + update (which will typically grab the latest full)
<barry> lool, stgraber what if channel.ini held both the channel name (e.g. 'stable') and the alias name (e.g. "13.10")?  then we'd know what actual channel we were on, and the channel.json file would tell us if that alias changed.  if they did, then we slam version to 0, --filter=full and do the upgrade
<lool> barry: that's what I had in mind
<lool> but stgraber has a point that this would need to be written by phablet-flash
<lool> since images don't know what channels they belong to
<stgraber> I'm confused, we all seem to agree but not quite, so let me rephrase :)
<stgraber> 1) I create a stable channel on system-image.u.c with an extra field "channel_target" which points to say "13.04"
<stgraber> 2) That channel is identical to its target except for version.tar.xz which contains the alias name as its channel name and also contains channel_target
<stgraber> 3) When switching the alias, channel_target changes to 14.04
<slangasek> stgraber: http://paste.ubuntu.com/6037949/> LGTM!
<stgraber> 4) system-image-cli looks at channels.json, finds the channel but sees channel_target is different than the local value it has, so decides to consider its version to be 0 and run a new update
<lool> oh wow
<lool> I didn't actually think you'd have real version.tgz for the alias channels
<barry> stgraber: that looks reasonable to me
<stgraber> lool: I'd. I already have that logic for the proposed channel anyway
<stgraber> lool: (otherwise everytime you'd update a device in the proposed channel, it'd revert to the daily channel)
<lool> ok
<lool> I thought we'd have cleverness in client to deal with this, but that works too
<lool> and the client is kept dumber, which is good
<barry> lool: indeed :)
<stgraber> so all the important bits (ubuntu, android, customization) are identical and shared between channels but the version tarball is always channel specific and is what tells system-image-cli where the image comes from (server, ports, channel name, ...)
<stgraber> barry: ok, good. I'll add myself a bunch of todo items for that. I unfortunately expect we'll have to change channels.json quite a bit to allow per-channel settings
<stgraber> barry: since we need to add per-channel settings, I'll also be moving the hidden flag there (instad of in the device section of channels.json) since we'll typically want to hide the whole channel and not just hide it for a single device
<barry> stgraber: can you please file bugs for all these new features?  i'm trying to finish up a different new feature before my eod so i can upload a new version today
<stgraber> barry: anyway, expect some spec changes and bug reports from me
<barry> +1
<barry> thanks
<lool> cool
<slangasek> stgraber: version numbers> argh
<stgraber> slangasek: that's solved ;)
<slangasek> oh, ok :)
<stgraber> slangasek: tl&dr: We'll store the target channel name in channels.json and on the device, if they differ, we know the target changed so we assume a version number of 0 and run an update from there
<slangasek> aha, cool
<xnox> infinity: $ bzr branch lp:ubuntu/eglibc
<xnox> Most recent Ubuntu version: 2.17-91ubuntu1
<xnox> Packaging branch status: CURRENT
<slangasek> xnox: ah, so it was you making that noise earlier about ancient eglibc branches suddenly being linked to bugs? ;)
<xnox> slangasek: yes. well, thanks to wgrant fixing permissions =)
<slangasek> \o/
<xnox> slangasek: ifupdown should be up to date as well.
<slangasek> sw33t
<xnox> slangasek: i don't like debian's proposal on d-d to only have dinstall x2 a day, instead of current x4.
<slangasek> xnox: I haven't read it through yet, but at first blush I don't like it either
<ESphynx> sladen: Are you still around? just got back... I could give you all the info, but that was all the latest as of last week or so, and so far yes I've only seen this on nVidia hardware, though aaronp seems to be quite confident the compositor is to blame
<ESphynx> I do not have a 'minimal' test case, but I have an easy enough to reproduce test case with the Ecere IDE
<xnox> stgraber: please merge/sync procenv, jodh wanted 0.26 to land in saucy. =) also he is very responsive to merge proposals on lp:procenv
<ESphynx> (I think it would happen as well with the version already in Saucy, but that suffers from additional bugs we've fixed or we're trying to fix)
<stgraber> xnox: straight sync is fine, the only delta we have is a call to df -h and df -i in autopkgtest because procenv didn't support showing free/total blocks/inodes yet (but 0.26 does)
<stgraber> (and done)
<sladen> ESphynx: don't give myself (only) all the information.  Give all the information to the bug tracker!
<ESphynx> sladen: right, so you suggest I file a new issue?
<ESphynx> I don't want to do a duplicate of that terminal thing though if it's basically the same thing, and I'm not sure what I should file it against? compiz?
<xnox> stgraber: thanks !
<sladen> ESphynx: yes, file a new issue, with the minimal test example to reproduce the issue (ie. a cut-down version of your own code)
<ESphynx> sladen: Can I put using the IDE as a sample?
<sladen> ESphynx: state, clearly, how to reproduce it; exactly on what version of Ubuntu it occurs, and with exactly what hardware/driver
<sladen> ESphynx: earlier you talked about XRenderFillRectangle(), so I'm presumably that you have a piece of code that uses XRenderFillRectangle() and exhibits the issue you're seeing (== the one you're going to detail in the bug report).
<sladen> ESphynx: so attach this piece of code (==minimal test case), instructions on how to compile and run the minimal test case
<sladen> ESphynx: and this will enable somebody more familiar with the code to investigate, debug and now know a solution is found
<ESphynx> sladen: I do not have time to cut down this into a piece of X11 code
<ESphynx> I can detail how to reproduce this by running the Ecere IDE from the Saucy repo, however.
<sladen> ESphynx: well attach what you have
<sladen> ESphynx: okay
<ESphynx> I can also point to the whole X11 driver in Ecere doing it
<ESphynx> k, and against compiz ?
<ESphynx> of course whoever's taking a look at it can contact me if they need any info
<sladen> ESphynx: remember that by filing a bug report, you're asking for the help and assistance of others, in order that we all benefit from finding the solution.  The more pre-debugging that you can do in clearly defining the problem, and test-case the easier and more speedy it is likely to be investigate further
<ESphynx> sladen: I've gathered quite a bit of info already in our own bug tracker @ http://ecere.com/mantis/view.php?id=987
<ESphynx> I'll be filing this bug against compiz and adding the exact version numbers
<sladen> ESphynx: yes, file it against compiz (if this is the compositing Window Manager in use), and make it clearly that you're on saucy
<ESphynx> https://bugs.launchpad.net/compiz/+bug/269904 -- this all looks very similar
<ubottu> Launchpad bug 269904 in Compiz "Screen refresh problems with nvidia on intrepid" [Unknown,In progress]
<ESphynx> there are tons of these bugs on Compiz
<infinity> xnox: Fantastic, now I can ignore it and not have people constantly ask why it's out of date.  Thanks.
<sladen> ESphynx: this is a bug report from several years ago.  As I understand from reading what you've written, you had discovered something that was specific to saucy (?)
<ESphynx> sladen: I didn't say it was. I presume it still hasn't been fixed, or might be back to haunt us (possibly because of a chance in the nVidia driver)
<sladen> ESphynx: it's past midnight for me.  If you get around filing a bug, add 'sladen' as a subscriber and I'll look over it tomorrow
<xnox> infinity: \o/ mission accomplished.
<ESphynx> sladen : thank you. add a good night!
<ESphynx> have*
<ESphynx> I'll file just to make sure people realize there's still an issue.
<ESphynx> hold on, Unity has got its own compositor now?
<ESphynx> ah no I see compiz running now
<xnox> ESphynx: depends =) unity8 will not have compiz
<ESphynx> Is that gonna be default on Suacy?
<ESphynx> Seriously this bug is killing me!
<ESphynx> aaron is saying the compositor's to blame...
<ESphynx> I sincerely hope it gets fixed for Saucy...
<xnox> ESphynx: no, in 14.10 the latest, possibly 14.04
<ESphynx> He said "It's a longstanding issue with GL-based compositors. The tools to fix it were added only fairly recently so I don't think any of them take advantage of them yet. The new fence sync stuff allows you to make GL wait for X rendering inside the GL server (i.e. the GPU) rather than waiting on the CPU."
<RAOF> ESphynx: Ah. I see you've discovered one of the annoyances with X :)
<xnox> ESphynx: well unity8 will work without X, and instead Mir will be used as system level GL compositor. =)
<ESphynx> yeah hopefully it gets along with the nVidia driver.
<ESphynx> RAOF: annoyance with X? more like horribly buggy default User interfaces on what I still wish was a production ready/problem free distro
<RAOF> Yeah, but the reason why it's buggy is because X made it difficult to be not buggy.
<ESphynx> understood ;)
<ESphynx> but thousands of the brightest engineers on the planet are working on this :P
<ESphynx> or is that just in my fantasy world ;)
<ESphynx> despite still not having open specs/open drivers, nVidia still has a good dedicated team working on the drivers right?
<RAOF> Yeah, nvidia have a pretty good proprietary team.
<ESphynx> Here is my bug report ... https://bugs.launchpad.net/compiz/+bug/1218116
<ubottu> Launchpad bug 1218116 in Compiz "nVidia driver/Saucy: Intermittent delayed update running Ecere IDE" [Undecided,New]
<ESphynx> Goto Utility->Workarounds->Force full screen redraws (buffer swap) on repaint -- that's something I could try
<ESphynx> "Force synchronization between X and GLX" in CompizComfig / Utility / Workarounds !
<RAOF> That sounds like a winner!
<ESphynx> doesn't seem to fix it, but sounds like something that should be enabled by default if it really is required :P
<ESphynx> "Goto Utility->Workarounds->Force full screen redraws (buffer swap) on repaint" however, seems to fix it!
<ESphynx> Just like https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861268
<ubottu> Launchpad bug 861268 in nvidia-graphics-drivers (Ubuntu) "text corruption in terminals (xterm, urxvt) and emacs" [Undecided,Confirmed]
#ubuntu-devel 2013-08-29
<ESphynx> Could this be turned on by default if running on nVidia hardware or something?
<RAOF> Maybe.
<RAOF> It's probably a performance drain, though.
<ESphynx> RAOF: I'd rather have my text editor working at 60 frames a second than being unusable at 120 frames / second
<RAOF> Yeah, but this doesn't apply to just your text editor :/
<ESphynx> RAOF: It applies to all programs I run on this sytem.
<ESphynx> i.e. on all systems using nVidia drivers, which is probably at least half of what I consider a usable machine
<ESphynx> I'm all for a proper fix, but until then this ought to be enabled.
<ESphynx> after the last dist-upgrade, I can't login with Gnome Flashback (No effects) anymore :S all black
<ESphynx> or if installing ccsm could do that :S (Saucy)
<jbicha> ESphynx: I believe that's bug 1217991
<ubottu> bug 1217991 in upstart (Ubuntu) "Regression: gnome-flashback* fails to init with latest upstart" [Undecided,Confirmed] https://launchpad.net/bugs/1217991
<ESphynx> thanks jbicha...
<ESphynx> and what I thought was a workaround isn't working half the time for my update bug
<ESphynx> So the only DE that actually was usable for me is now b0rked.
<jbicha> ESphynx: the bug description has an easy workaround but the bug will be fixed soon
<ESphynx> jbicha: k. thanks. I really wish this Compiz bug was fixed though :S
<ESphynx> then I could try to figure out what's up with my other resizing/maximizing bug in Unity :P
<stgraber> jbicha: the fix is wrong, those session names don't exist
<stgraber> jbicha: so I'll need to actually figure out what's wrong with flashback running under upstart before I can get it fixed. I'll try to take a look tomorrow.
<ESphynx> stgraber: The fix works for me.
<ESphynx> renaming the 2 to -flashback rather than -fallback
<stgraber> ESphynx: sure it does, it's just not a fix
<stgraber> ESphynx: renaming the entries is the exact same as removing them
<stgraber> which means, disabling the feature
<stgraber> what we want is for the feature to be enabled and working and for that upstart-xsession is perfectly correct, it's just something else down the line that's failing and needs debugging and fixing
<jbicha> stgraber: thanks
<ESphynx> But Gnome fallback is what seems to start for me?
<stgraber> sure, just not under upstart
<ESphynx> ah ok
<stgraber> jbicha: I know it used to work but I probably tested this before the whole flashback rename. It looks like something is confused by the names not being consistent, but it's not obvious what since it's not hardcoded in any of the places I'd have expected. Anyway, should take me a few minutes to figure out and fix once I reproduce the problem here (won't do that just now but will do it first thing tomorrow).
<ESphynx> thanks stgraber
<Mirv> mitya57: thanks! I agree quickcontrols is needed / very useful to have.
<superm1> Laney: i just noticed that you had done a few uploads to mythtv without pushing the changes upstream or pull requests to the packaging branch so they just got clobbered in my upload, can you please forward the patch upstream and do pull requests if you'll be uploading in the future?
<smoser> anyone know where files listed at the end of https://i148673231.restricted.launchpadlibrarian.net/148673231/asobibi-installer-log-2013.08.29.txt?token=a6a5ce59d6d6f063bd4bf36e1805942a come from ?
<smoser> /usr/lib/finish-install.d/60cleanup
<smoser> /usr/lib/finish-install.d/90base-installer
<smoser> /usr/lib/finish-install.d/10open-iscsi
<infinity> smoser: base-installer and open-iscsi...
<infinity> smoser: And.. Not sure where 60cleanup comes from, off the top of my head.
<infinity> smoser: Oh, finish-install, oddly enough. :P
<smoser> yeah. that was funny. i realized that too
<smoser> thanks infinity . kind of hoped no one would see my question. with the answer so clearly there :)
<pitti> Good morning
<pitti> tyhicks: thanks for fixing the d-bus stderr issue!
<tyhicks> pitti: no problem! :)
<pitti> and bluez et al are happy
<sarnold> \o/
<FourDollars> There is no Patch Pilot now. :(
<infinity> tvoss: Yo, WTF mate.
<tvoss> infinity, ?
<infinity> tvoss: Why is location-service pulling in some ruby doc generation business?
<tvoss> infinity, we can get rid of that :)
<tvoss> infinity, want me to do that?
<infinity> tvoss: That seems like an odd choice for a Canonical project. :P
<tvoss> infinity, heritage, will fix it. hang on
<infinity> tvoss: If you can make with the getting rid of somehow, sure.
<infinity> tvoss: Beats doing MIRs for a few dozen ruby gems.
<tvoss> infinity, indeed ;) sorry for the confusion
<Laney> superm1: I certainly did forward the logind patch
<Laney> might have missed the packaging branch though, sorry
<debfx> Whoopie: I've uploaded a new virtualbox package with your vnc extension patch
<xnox> FourDollars: sup? need sponsoring? =)
<FourDollars> xnox: Yes. https://bugs.launchpad.net/ubuntu/+source/pristine-tar/+bug/1218197
<ubottu> Launchpad bug 1218197 in pristine-tar (Ubuntu) "pristine-tar: command failed when using git-buildpackage on the xz tarball." [Undecided,In progress]
<ESphynx> xnox: can we get 0.44.09 in next week since it's mostly a bugfix release? ;) I'm going to require some sleep at some point :(
<ESphynx> xnox: The big thing about this release is fixing real annoyances/usability issues with Ubuntu & Mint's DEs :P
<asac> ogra_: what happened to the builds? floodgating worked it seems :)
<xnox> FourDollars: you do want to subscribe "~ubuntu-sponsors"  https://wiki.ubuntu.com/SponsorshipProcess such that it gets on the list to sponsor: http://reqorts.qa.ubuntu.com/reports/sponsoring/
<asac> ogra_: err... moving to touch
<FourDollars> xnox: I see. Thank you.
<xnox> FourDollars: alternative to subscribing, you can do merge proposal. But you based on upstream branch, instead of lp:ubuntu/pristine-tar =/ so will not work.
<xnox> FourDollars: and you are after an SRU?
<FourDollars> xnox: I based on lp:ubuntu/precise/pristine-tar/ .
<xnox> FourDollars: oh, ok. You did push branch to upstream project, $ bzr push lp:~/ubuntu/precise/pristine-tar/fix-lp-bug  is better & then one can click to create merge proposal against lp:ubuntu/precise/pristine-tar
<FourDollars> xnox: Like lp:~fourdollars/ubuntu/precise/pristine-tar/fix-lp-bug-1218197 ?
<xnox> FourDollars: yeap =)
<FourDollars> xnox: OK.
<tvoss> infinity, https://code.launchpad.net/~thomas-voss/location-service/remove-dep-on-ruby-ronn/+merge/182844
<FourDollars> xnox: done.
<infinity> tvoss: Looks reasonable to me.
<tvoss> infinity, let's wait for ci to kick in and then top-approve
<xnox> FourDollars: it looks like you didn't use "debcommit", or manually specify on $ bzr commit --fixes lp:NNNNNNN, thus the branch didn't get automatically linked to the bug report. Linked the new branch in.
<xnox> FourDollars: ... and created merge proposal.
<FourDollars> xnox: I do use "debcommit". @_@a
<xnox> hm, strange.
<FourDollars> xnox: It takes some time to sync. :)
<FourDollars> xnox: Refresh the page now. You should see it.
<xnox> maybe ;-)
<xnox> but i did manually add bug report # on the page.
<FourDollars> xnox: OK. Thank you for the guiding.
<tvoss> infinity, jenkins is happy
<tvoss> infinity, https://code.launchpad.net/~thomas-voss/location-service/remove-dep-on-ruby-ronn/+merge/182844
<infinity> tvoss: Do you need an explicit ACK from me there, or are you good to go?
<infinity> Oh, I guess I'm not in a team that was asked for a review anyway. :P
<tvoss> infinity, hang on :)
<tvoss> sil2100, Mirv lp:~thomas-voss/location-service/remove-dep-on-ruby-ronn
<sil2100> tvoss: looking
<Mirv> thanks
<tvoss> infinity, the fix is top-approved
<infinity> tvoss: I'm going to nod and pretend I know what that means, and assume it means "it'll be in the distro soon".
<thotz> Question: Is it possible to add GIMP 2.8.6 to saucy. Could someone do that? It really would fix severial bugs see #1207734
<tvoss> infinity, yup, that's all you need to know
<thotz> https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/1207734
<ubottu> Launchpad bug 1207734 in gimp (Ubuntu) "Update GIMP to version 2.8.6" [Wishlist,Triaged]
<seb128> thotz, I can have a look
<infinity> thotz: You might want to poke jbicha when he's online, should be a trivial merge.
<infinity> ... or seb128 can do it. :)
<seb128> infinity, hey
<seb128> infinity, can you review youker-assistant in saucy NEW for me?
<seb128> infinity, I fixed some copyright issues/sponsored it for the UbuntuKylin guys, but since I did the upload I would prefer for another archive admin to review
<thotz> thank you
<seb128> infinity, they are eager to see it in apparently, it has been taking a while because of review feedback/things to fix
<infinity> seb128: I'm running off to bed to attempt a nap, but if you don't find another victim, I can do it tomorrow.
<seb128> infinity, thanks
<thotz> should i contact jeremy?
<seb128> infinity, have a good nap/night ;-)
<seb128> thotz, no, I'm doing the gimp update
<thotz> seb128: Thank you very much. I don't know if you have seen, I try go through the GIMP bugs.
<seb128> thotz, thanks for helping there!
<thotz> seb128, If I have some time I'm also trying to build development version from git, but I have no packaging experience. I have built yesterday GIMP 2.9 from GIMP... really promising :)
<thotz> seb128, thank you too!
<zyga> hi
<zyga> current daily ubiquity installer seems broken, at least two things that I can see are affected: networking configs don't work (policykit rejects control attempts) and the top panel is sized incorrectly, being approximately 10x larger
<xnox> zyga: both of which are filed bugs on ubiquity. The top panel is caused/assigned by/to larsu. The other one, missing proper logind integration
<xnox> zyga: but maybe policykit policy also need changing.
<rbasak> Is there a magic way to do a no change rebuild for a package that has no Ubuntu delta? Or do I need to do it manually, and then make sure to resync tha package manually again at some future date?
<cjwatson> dch -R
<cjwatson> That'll append build1 which doesn't inhibit autosyncs
<rbasak> Ah, so the version number is special? I understand now. Thanks!
<cjwatson> Yes.  The thing that inhibits autosync is the presence of the "ubuntu" substring in the version.
<zyga> xnox: cool, so I won't go hunting or reporting them, thanks
<ekarlso-> do I need to have my secret key on the machine I use for signing packages ?
<cjwatson> Yes.
<cjwatson> If you like, you can do the signing on a machine other than the one where you build the package, using either "debsign -r" or "debrsign" depending on the direction (see their manual pages).
<rbasak> I use debsign -r to avoid this. But I must trust the machine I'm using, since I guess it could trojan some other thing to sign.
<asac> ogra_: i think a script to show diffs on the packages file for two builds would be nice :)
<asac> -> move touch
<nemo> "You are running the upgrade over a remote ssh connection with a frontend that does not support this. Please try a text mode upgrade with 'do-release-upgrade'.
<nemo> "
<nemo> uh... since when?
<nemo> ssh -Y headless-server  sudo update-manager, click yes on partial upgrade
<nemo> first time I've ever seen that. someone change something?
<zyga> "Warning: fake initctl called, doing nothing", after saucy install, does anyone know what that is?
<nemo> "ERROR:root:upgrade over ssh not alllowed" grrrr why :(
 * nemo greps
<nemo> besides the typo
<cjwatson> zyga: A broken install
<cjwatson> zyga: If the installer finished properly it would have put the real initctl back
<zyga> ah
<zyga> yeah, the installer got stuck later and I just rebooted
<nemo> # check if the frontend supports ssh upgrades (see lp: #322482)
<nemo> hm
<ubottu> Launchpad bug 322482 in update-manager (Ubuntu Jaunty) "distribution upgrade via update-manager fails over remote GDM" [Undecided,Fix released] https://launchpad.net/bugs/322482
<nemo> oh. yeesh.
<nemo> that should just be a warning
<nemo> I can bloody well make my own decision on this based on the stuff being upgraded
<nemo> obv something that is going to screw w/ network will mess me up...
 * nemo sighs and edits DistUpgradeController.py
<nemo> I mean, seriously, for me to do this from a console would require a ridiculous amount of work
<wgrant> xnox: You can't import a non-branch head using the ,branch= syntax.
<nemo> the weird thing is it recommended I use curses UI, when as far as I can tell, the bug could possibly mess you up there too
<wgrant> xnox: It has to be under refs/heads
<xnox> wgrant: ack.
<nemo> but, yeah, setting aside disagreeing w/ solution, logging.error("upgrade over ssh not alllowed")  has a typo in "allowed"
<Mirv> any core-dev up for sponsoring? https://code.launchpad.net/~timo-jyrinki/ubuntu/saucy/qtpim-opensource-src/new_snapshot/+merge/182874 - built & tested
<xnox> wgrant: sucks to be me =(
<wgrant> xnox: Indeed :(
<cjwatson> DistUpgradeViewText is in View.SupportSSH, so the curses UI ought to bypass this check
<cjwatson> I think you can change it in DistUpgrade.cfg though
<cjwatson> Fixed the typo in lp:ubuntu-release-upgrader
<wgrant> ,branch=refs/dgit/sid works.
<wgrant> xnox: Does that look right?
<xnox> wgrant: nope. it imported HEAD.
<xnox> wgrant: 191 should be the last commit on https://code.launchpad.net/~xnox/dgit/sid
<wgrant> Oh, I am stupid.
<nemo> cjwatson: yeah, I didn't want to use the curses UI, and given the launchpad issue, I don't see why the curses UI would help
<nemo> cjwatson: looks like any remote connection would hit probs if eth0 was killed :)
<nemo> cjwatson: setting that line to if false worked fine tho ;)
<nemo> would have preferred it had been a warning
<wgrant> xnox: The slashes need to be escaped as %2F, but somehow refs%2F causes the branch name to appear to be None. Investigated.
<wgrant> s/ed/ing/
<wgrant> xnox: A patch to make it work is trivial, but I need to think a bit about the implications
<xnox> ok.
<nemo> so. there's this script that was causing a rather misleading motd... /usr/lib/update-notifier/update-motd-fsck-at-reboot
<nemo> reason it is misleading is it appears that if the last check was <1h ago, it won't even check the filesystem values
<nemo> so I rebooted several times, thinking there was an issue
<nemo> you'd think the script could also check uptime?
<nemo> jrib: oh. and hi. I see you're here too :)
<jrib> nemo: heh
<jrib> nemo: I'd urge you to debug and file a bug ;)
<nemo> well, I'd say the clear prob is if [ $(($stampt + 3600)) -lt $now ] || [ $stampt -gt $now ]; then
<nemo> where stampt is stat -c %Y of the scary message
<nemo> jrib: admittedly I don't know of a "nice" way to get the boot time...
<nemo> apart from
<nemo> date +%s -d "$(last | head -n 1 | awk '{print $5,$6,$7,$8}')"
<nemo> which I just stitched together and seems pretty ugly
<nemo> you'd thing it would be in sysctl or something...
<nemo> I have no idea if that is even a locale specific format :-/
<nemo> (the date string)
<nemo> but anyway, assuming oh,  boott=$(date +%s -d "$(last | head -n 1 | awk '{print $5,$6,$7,$8}')")
<nemo> then they should recheck if $boott gt $stamptt
<nemo> ah well. whatev
<nemo> hm. that's not even a nice use of last
<nemo> I need a grep for reboot in there, and a skip of generation if it isn't.
<nemo> something in sysctl would definitely be nicer. or maybe if ubuntu just wrote boot time to a file that its own script could check :)
<seb128> mardy, hey, do you have an idea when you are going to have time for that shotwell patch update (asking because FF is today), do you want a bug report to track it?
<pkern> So there's a patches.xml file on patches.ubuntu.com, but it redirects to people.ubntu.com/patches/.
<pkern> Also: Are there patch files for Ubuntu releases as well?
<cjwatson> That's ... huh
<cjwatson> It's a permanent redirect from /patches which is apparently misfiring
<cjwatson> I think I'll just comment it out, it's amazingly stale
<superm1> Laney: hmm, I wonder why upstream missed it then.  Do you remember where you forwarded it?  I just filed a new bug with it (http://code.mythtv.org/trac/ticket/11794) that they set the milestone to before 0.27 releases, so we'll pull it back in the next upload
<Laney> superm1: maybe a github project
<cjwatson> pkern: The broken redirect is fixed now, thanks
<cjwatson> Not sure about your other question
<cjwatson> If you mean per-release patches, we normally only run merge-o-matic against the latest development series, so no
<superm1> Laney: oh yeah i see it now.  They don't track pull requests as much as they should and prefer bugs for tracking stuff like that.  Thanks.
<dobey> infinity: just dput ubuntuone-credentials 13.08-0ubuntu1. we'll see if it makes it to NEW
<dobey> infinity: email i got said it's in new for saucy-proposed
<seb128> cjwatson, slangasek: is somebody from foundation leading https://blueprints.launchpad.net/ubuntu/+spec/client-s-32v64-bit ? (it ended up in the client track but you guys probably have more background/opinions on the topic than us)
<seb128> (that's in 15 minutes in client2)
<cjwatson> I have to be in a different session, sorry
<seb128> xnox, stgraber: ^?
<xnox> seb128: i don't have any rights to start hangout.
<slangasek> seb128: I can be there if I can get someone else to run the camera for the foundations session
<seb128> xnox, the track hosts start the hangouts (e.g me for that one)
<slangasek> seb128: do you want to trade tracks for next hour? :)
<seb128> xnox, but I don't know enough about the topic to lead the session...
<seb128> slangasek, I can host yours, sure
<slangasek> ok, cool
<seb128> slangasek, so I'm hosting the checkbox one and you take on the 32v64 bit, right?
<slangasek> seb128: exactly
<slangasek> thanks :)
<seb128> slangasek, excellent, thank you!
<stgraber> dpkg: error processing /var/cache/apt/archives/unity-webapps-common_2.4.16+13.10.20130829.2-0ubuntu1_all.deb (--unpack):
<stgraber>  trying to overwrite '/usr/share/icons/hicolor/128x128/apps/ubuntuone-music.png', which is also in package unity-asset-pool 0.8.24daily13.06.10-0ubuntu1
<stgraber> it's one of those auto-landed packages so I have no idea who to nag/blame about this...
<ChrisTownsend> stgraber: Here's a start: https://code.launchpad.net/~abreu-alexandre/webapps-applications/add-default-apps/+merge/182646
<stgraber> right, unfortunately robru doesn't appear to be around
<pkern> cjwatson: Well, I solved my problem (where is file X used) by using Debian's codesearch, downloading all Ubuntu patches and grepping. ;)
<cjwatson> Heh
<xnox> pkern: jdstrand can run greps on full ubuntu unpacked trees. they do take some time though.
<jdstrand> I'm not sure that should be advertised as a public resource :P
<xnox> =)))))
<jdstrand> it's all very manual-- I don't mind doing it as a favor, but it isn't something can just do. codesearch for Ubuntu would be nice
<jdstrand> s/can just do/I can just do all the time/
<xnox> jdstrand: Laney has a codesearch instance running in canonistack =) not sure how fully operational it is.
<jdstrand> oh, that would be nice to poke at
<sarnold> oh man, that'd be nice. I love debian's codesearch
<cyphermox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<sarnold> seb128: retracers seem dead again -- any chance of asking IS to monitor the cranky things to auto-restart when they wedge? :)
 * dholbach hugs cyphermox
<cyphermox> dholbach: hey, just trying to read the list is painful, so many pings about other stuff :)
<dholbach> I know
<dholbach> I did quite some sponsoring in the last days to get stuff in before feature freeze
<dholbach> but during UDS it's a bit crazy admittedly
<dholbach> I'll do the rest of my session tomorrow
<pkern> xnox: Before I do that I set up a private instance of codesearch. -_-
<pkern> jdstrand: How large is it?
<jdstrand> pkern: I don't have a private instance of codesearch. I use debmirror to mirror all of lucid-saucy for amd64 and i386
<pkern> jdstrand: I mean the unpacked tree.
<jdstrand> pkern: I use scripts to unpack on the fly and then delete after the package is searched
<jdstrand> pkern: so I don't unpack all the sources
<jdstrand> (at the same time)
<seb128> sarnold, talk to slangasek, he sort of suggested he was wanting to help keeping those running ;-)
<slangasek> hnngh
<slangasek> and no email notification of it hanging, eh
<sarnold> slangasek: hello :) about those retracers...
<slangasek> seb128: I also always forget what machine it's running on, remind me?
<seb128> slangasek, porter-i386.c.c
<seb128> I removed the lock
<seb128> but I think it's hitting a bug it doesn't like
<seb128> bug #1216901
<ubottu> bug 1216901 in linkchecker (Ubuntu) "linkchecker-gui crashes on startup" [Undecided,New] https://launchpad.net/bugs/1216901
<slangasek> ok
<seb128> the bt isn't very useful though :/
<seb128> slangasek, do you want to have a look to the issue or should I just untag the bug so the retracer doesn't keep banging on it?
<seb128> well, I guess we can untag & have a look as well
<slangasek> seb128: I won't have time to look at it very quickly, so please untag it for now anyway
<bdmurray> barry: the tracebacks in https://errors.ubuntu.com/problem/15bc0ab1791f275923e1d66575637a22e2b24b7d look suspcious to me - as in I wonder about the systems
<seb128> doing
<barry> bdmurray: that looks very suspicious.  it looks typical for a 3rd party extension module not checking a set exception somewhere
<stgraber> barry, lool: should we schedule an hangout for after the closing plenary?
<barry> stgraber: i'm available
<lool> stgraber: ok
<ekarlso-> "Source/binary (i.e. mixed) uploads are not allowed." how can I get dput to only select the source ?!
<shadeslayer> ekarlso-: just run debuild -S -sa on the source
<shadeslayer> or -sd if you just want to upload a package which already has the tar on launchpad
<cjwatson> -sd is basically never necessary
<cjwatson> but yeah, -S is the key bit
<shadeslayer> cjwatson: oh, so -sa uploads the tar but launchpad is clever enough to not make a copy?
<cjwatson> you can upload a duplicate orig.tar as long as it's identical
<ekarlso-> I used the dpkg-buildpackage binary
<cjwatson> I usually use debuild -S and only use -sa if needed
<ekarlso-> is that the same thing
<shadeslayer> cjwatson: aha I see
<cjwatson> ekarlso-: Launchpad doesn't accept binary uploads, they have to be source-only.  No it isn't the same
<cjwatson> You can use dpkg-buildpackage -S, though debuild -S is usually easier
<cjwatson> (it's a slightly smarter wrapper)
<ekarlso-> how can I have it not try to sign it ?
<cjwatson> -uc -us
<cjwatson> or just ignore the signing failures
<cjwatson> you still have to sign it before uploading to LP of course
<shadeslayer> ^^
<ekarlso-> debuild -S -uc -us the ?
<cjwatson> yeah
<ekarlso-> what's Standards-Version ?
<ekarlso-> my build fails on that now :p
<cjwatson> see the Debian policy manual
<cjwatson> http://www.debian.org/doc/debian-policy/
<cjwatson> specifically http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Standards-Version
<cjwatson> and http://www.debian.org/doc/debian-policy/ch-source.html#s-standardsversion
<cjwatson> (the latter's a better reference, sorry)
<ekarlso-> should it fail on 3.9.3 ?
<cjwatson> 3.9.3 is fine
<ekarlso-> mine fails telling me it is outdated..
<cjwatson> that's not a failure
<cjwatson> it's quite important to distinguish errors from warnings or informational messages ...
<cjwatson> the current version is 3.9.4 but you should check the policy manual's upgrading checklist before blindly changing the number
<cjwatson> the point is to remind people to check changes in policy
<ekarlso-> cjwatson: how come ? ;)
<cjwatson> because that's the point of standards-version - it's the latest version of the policy manual you've checked your package against
<cjwatson> it isn't supposed to be a paperwork exercise in updating the number :)
<cjwatson> if it's a little out of date, so be it, it's not a failure
<stgraber> lool, barry: I'll invite the two of you to an hangout in the next 5min
<lool> stgraber: ok
<barry> sounds good
<dobey> kenvandine: so where's the rum?
<kenvandine> dobey, i could use some :)
<dobey> heh
<dobey> unfortunately i don't have any soda or ice
<dobey> and a little too early, and air too dry inside, to drink it straight
<ekarlso-> https://launchpadlibrarian.net/148814928/buildlog_ubuntu-precise-i386.cyassl_2.7.0-1_FAILEDTOBUILD.txt.gz < anyone help me on why that is failing ?
<ekarlso-> it works when building locally
<sarnold> ekarlso-: that looks like building an i386 binary on an amd64 host -- have you tried reproducing an i386 build on an amd64 host locally?
<ekarlso-> sarnold: I the package should only be amd64...
<sarnold> ekarlso-: aha. you may need to specify that in the control file..
<ekarlso-> sarnold: how ?
<YokoZar> slangasek: I uploaded all the relevant wine bits today :)
<slangasek> YokoZar: hurrah
<YokoZar> I couldn't find the wiki page about deleting packages, but I presume it's just "file bug, subscribe ubuntu-archive"
<sarnold> ekarlso-: I believe the keyword is 'amd64', in this field: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
<slangasek> YokoZar: yes
#ubuntu-devel 2013-08-30
<smartboyhw> jcastro, congratulations on Discourse:)
<cyphermox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jcastro> smartboyhw: we're just getting started/. :)
<smartboyhw> jcastro, good. Anything I can help with?
<smartboyhw> (The charm only)
<jcastro> yeah, we need some help with the charm, can you join us on #ubuntu-discourse?
<smartboyhw> jcastro, sure
<pitti> Good morning
<ESphynx> 'morning
<ESphynx> I'm still hoping feature freeze day is not over yet in some place in the world :P
* infinity changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> infinity: the PPA build queue got quite long again; I just see that in e. g. https://code.launchpad.net/~autopilot/+archive/experimental/+recipebuild/530762 the builder is still busy with package installation afer 7 mins; could a chroot upgrade help to speed them up?
<infinity> pitti: I'll get the chroots happy again later, sure.  But the real problem was all the PPA machines but two being dead for a while. :P
<pitti> infinity: ah, ok; there seem to be plenty right now
<pitti> infinity: so nevermind, thanks!
<pitti> hm, apport-kde started crashing a few days ago
<pitti> Riddell: I adjusted and investigated bug 1218473 about that, seems KApplication() now immediately crashes
<ubottu> bug 1218473 in python-kde4 (Ubuntu) "KApplication now crashes immediately since last saucy sip and pyqt4 updates" [High,Triaged] https://launchpad.net/bugs/1218473
<pitti> unfortunately new sip/pyqt4/pykde weren't held back by the regression
<ESphynx> Hmm, why are we still stuck with libpng12 on Ubuntu?
<ESphynx> There's a huge list of vulnerabilities/crashes @ http://www.libpng.org/pub/png/libpng.html and I'm hitting one right now ;S
<ESphynx> (or at least I thought I was)
<dholbach> good morning
<Laney> sarnold: jdstrand: http://162.213.35.4/
<Laney> doesn't automatically update yet
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<cjwatson> https://launchpad.net/ubuntu/devel  <- works now
<cjwatson> hopefully we should get publisher symlinks next run
<dholbach> woohoo!
<smartboyhw> cjwatson, when can we start uploading to "devel"?:P
<cjwatson> it should work now
<smartboyhw> cjwatson, oh
<dholbach> does anyone else have a bit of flickering since the newest updates?
 * cjwatson is way ahead of you ;-)
<smartboyhw> cjwatson, heh
<dholbach> particularly stuff involving the cursor
<cjwatson> (There are weird complexities when you start thinking about how this works for PPAs.  https://code.launchpad.net/~cjwatson/launchpad/series-alias/+merge/178103 has details)
 * dholbach asks in #ubuntu-mir
<cjwatson> It's possible that there'll be a mirroring oddity on {archive,ports}.ubuntu.com - I'll keep an eye on it
<darkxst> cjwatson, is it possible to add our syslinux changes now? or does it have to wait until after beta-1 freeze? https://code.launchpad.net/~darkxst/debian-cd/ug-syslinux/+merge/183028
<cjwatson> yeah, I saw that, it should be possible, I'll need to review once I wake up a bit more :)
<darkxst> cjwatson, ok, thanks!
<cjwatson> Looks classy.
<dholbach> Laney, there's a ghc sync in the sponsoring queue - how do you feel about it?
<cjwatson> We'll see how it turns up when debian-cd gets its hands on it :)
<cjwatson> dholbach: HELL NO
<cjwatson> I considered that and decided it was madness :)
<dholbach> cjwatson, I think I recalled something like this having the potential of causing problems :)
<cjwatson> I dunno, maybe Laney disagrees ...
<Laney> I don't think any of the fixes in there really matter for us
 * cjwatson comments on the bug
<cjwatson> darkxst: merged and deployed
<cjwatson> thanks!
<dholbach> one day, somebody needs to explain to me why these uploads always trigger transitions - it sounds like this creates a bit too much work... but maybe explain it to me over a beer :)
<cjwatson> dholbach: they don't always, but ghc is very sensitive to its abi
<dholbach> where is my beer?
 * dholbach hugs cjwatson
<cjwatson> :)
<cjwatson> it might get better with ghc 7.8 and the shift to the system runtime linker
<cjwatson> or it might not, not sure ...
<cjwatson> I don't think anyone actually likes it this way but it's better than creating busted binaries ...
<dholbach> sure
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/devel/ exists, good
<cjwatson> and http://ports.ubuntu.com/ubuntu-ports/dists/devel/
<cjwatson> oddly, not partner
<dholbach> seb128, is https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1051921 something that should go through the sponsoring queue?
<ubottu> Launchpad bug 1051921 in Unity 5.0 "lens-bar-keynavigation periodically writes to /tmp/wut.png" [Medium,In progress]
<seb128> dholbach, sil2100/Mirv said tha SRUs are blocked on the SRU team to get back to them about some XIM changes
<seb128> they are blocked on that for weeks
<seb128> dholbach, if SRU team is happy with the current branch, that fix is going part of the next SRU already
<dholbach> gotcha
<sil2100> dholbach, seb128: right, infinity is in the loop but still didn't have time to verify and ACK the SRU we're proposing for unity and nux
<seb128> otherwise we are going to need to cherrypick and do a SRU
<cjwatson> and possibly somebody should publish something to extras to see if that causes it to create a devel symlink
<cjwatson> pitti: does ddebs.u.c need special nudging to create a devel symlink?
<seb128> infinity, I guess you didn't have slots to review yuker-assistant for the UbuntuKylin guys?
<cjwatson> pitti: by which I mean devel -> saucy, devel-proposed -> saucy-proposed, etc.
<seb128> infinity, I think they wanted that on their beta1, going to be some unhappy people there ... do you think you can review today or should I find another aa/ack my own upload?
<dholbach> cking, here's a merge proposal to update powertop to 2.4 (we have 2.1 in saucy) - any objections or concerns?
<dholbach> I could find release notes for 2.4, 2.3 but not for 2.2 and it looked like bug fixes and support for additional chips, etc
<darkxst> cjwatson, thanks
<cking> dholbach, to be honest, I've not been tracking powertop lately
 * cking has a look
<dholbach> cking, lp:~noskcaj/ubuntu/saucy/powertop/2.4 is the branch I'm looking at
<dholbach> I just wasn't sure if it could have an impact on our testing infrastructure or anything
<cking> dholbach, well, I'm not using it any of the QA PM tests that I've written
<dholbach> ah ok
<dholbach> in that case it looks good to me to upload, I'll just ask Noskcaj to follow up on debian bug 685607 as well
<ubottu> Debian bug 685607 in powertop "Powertop: New version available" [Wishlist,Open] http://bugs.debian.org/685607
<dholbach> thanks
<cking> dholbach, I don't have any objections to 2.4, i've given it a spin and it looks OK
<dholbach> perfect
<Noskcaj> dholbach, will do
<dholbach> thanks!
<seb128> hum
 * seb128 eyes at https://launchpadlibrarian.net/148942504/buildlog_ubuntu-saucy-armhf.qtlocation-opensource-src_5.0~git20130805-0ubuntu3_FAILEDTOBUILD.txt.gz
<seb128> "The following packages have unmet dependencies:
<seb128>  libplatform-api1-dev : Depends: libubuntu-application-api1 but it is not going to be installed or
<seb128>                                  libplatform-api1 but it is not installable"
<seb128> I can't reproduce that on a device or on porter though :/
 * seb128 wonders what's going on
<Laney> component mismatches?
 * seb128 tries a pbuilder
<seb128> Laney, OH
<seb128> hum
<cjwatson> did you remember to enable -proposed on the device?
<cjwatson> porter box probably doesn't have it on
<cjwatson> And yeah, what Laney said
<cjwatson> ubuntu-archive@lillypilly:~$ chdist-mainonly apt-get saucy-proposed-armhf build-dep qtlocation-opensource-src
<cjwatson> reproduces it
<seb128> shrug
<Laney> Yeah, those two things are my go-to these days
<seb128> I wonder why it worked on other archs
<seb128> and why the previous revision built
 * seb128 checks that
<seb128> Laney, cjwatson: thanks
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html shows libplatform-api1-dev as uninstallable in main-only on all arches
<cjwatson> ditto http://people.canonical.com/~ubuntu-archive/testing/saucy_probs.html in fact
<cjwatson> Looks like the problem where location-service had ruby doc-generation build-dependencies has been fixed, so it should be a simpler MIR now
<pitti> cjwatson: re (sorry, long meeting)
<cjwatson> pitti: you might actually want to hold off on my request for now anyway
<cjwatson> W: Conflicting distribution: http://gb.archive.ubuntu.com devel Release (expected devel but got saucy)
<pitti> cjwatson: there's nothing automatic there, but I can just put the symlinks there and we'll add that to the NewReleaseOpeningProcess?
<cjwatson> which was unexpected :-(
<cjwatson> So I need to work out if I need to do something slightly more sophisticated there
<cjwatson> ENOTIME though so not today
<cjwatson> pitti: useful to know that though, thanks
<xnox> cjwatson: i spy chdist-mainonly can you pastebin that? =)
<pitti> cjwatson: I guess I can add the symlinks now to avoid forgetting about it? or would that hurt in any way?
<Laney> xnox: Just make a sources.list appropriately, surely
<cjwatson> xnox: http://paste.ubuntu.com/6043478/
<Laney> haha
<cjwatson> saves having to permanently maintain and separately update another chdist instance - I did this because it was faster
<zyga> hey, I cannot start lightdm (precise + sdk PPAs) after booting this morning, lightdm/x-0.log says: "X: cannot stat /etc/X11/X (No such file or directory), Aborting"
<cjwatson> pitti: well, it's possible that the correct fix will involve devel being a directory instead - I'm not yet sure
<zyga> any ideas what that might be caused by?
<Laney> I think I used to symlink var to do that
<cjwatson> pitti: So probably best to hold off for now, sorry for the noise
<pitti> cjwatson: ah, ack
<cjwatson> (Might also be able to adjust the Release file though)
<smartboyhw> !find /etc/X11/X precise
<ubottu> File /etc/X11/X found in apparmor-notify, appmenu-gtk, appmenu-gtk3, at-spi2-core, awesome, brltty-x11, compiz-gnome, consolekit, dbus-x11, deejayd (and 40 others) http://packages.ubuntu.com/search?searchon=contents&keywords=/etc/X11/X&mode=&suite=precise&arch=any
<smartboyhw> zyga, ^
<smartboyhw> :P
<pitti> cjwatson: anyway, it's "sudo -u ddebs -i" on germanium; you, me, seb128 and vorlon are in that team
<pitti> cjwatson: (just FYI)
<pitti> cjwatson: so I'll wait for your "go" to add the links
<zyga> smartboyhw: I'm not sure how that helps me
<smartboyhw> zyga, at least you can find out which packages you need to install
<cjwatson> pitti: ah, ok, ta
<seb128> cjwatson, Laney: thanks, the issue is indeed that platform api stuff started depending on location-service, but nobody MIRed that, pinging tvoss_&co about it
<smartboyhw> zyga, https://bugs.launchpad.net/ubuntu/+source/xorg-lts-quantal/+bug/1132736
<ubottu> Launchpad bug 1132736 in xorg-lts-quantal (Ubuntu) "Xorg fail to start after installing the hardware enablement stack on precise due to missing symlink" [Undecided,Confirmed]
<zyga> smartboyhw: thanks, it's a bit hard to copy-paste any links from the console
<zyga> smartboyhw: any workaround that I can quickly try?
 * zyga cannot wait for mir to perhaps have less painful transitions 
<zyga> installing -quantal X11 stack removes skype, eh
<smartboyhw> zyga: sudo dpkg-reconfigure -phigh xserver-xorg
<pitti> wow, I didn't know about !find
<smartboyhw> That's one of the solutions listed there
<zyga> thanks
<smartboyhw> pitti, it's the Kubuntu people who taught me that. thank them:
<smartboyhw> :)
<pitti> Kubuntu people: thanks!
<zyga> indeed, beats apt-file
 * zyga wonders how he got a load of :i386 packages
<xnox> skype?
<pitti> firefox plugin container?
<zyga> ah
<zyga> skype probably
<zyga> now that x removed skype those showed up as dangling
<zyga> damn you skype
<xnox> skype installs bucket and a half of ubuntu-desktop:i386
<zyga> starting X freezes my box
<zyga> hmm
<infinity> seb128: If you think you've reviewed it well enough from an AA POV, go nuts.  I don't really see the need to have a second reviewer just because you sponsored it, TBH.
<seb128> infinity, ok
<infinity> seb128: (I mean, if it was a MOTU who uploaded it, and you reviewed and offered the same fixes/advice, you'd still be the only reviewer)
<seb128> infinity, well, some people try to not approve their own uploads
<infinity> seb128: I prefer you not approve your own work, but approving the work you reviewed/fixed is a bit different, if you see what I mean.
<infinity> seb128: Anyhow, it's been a crazy day, sorry I didn't get to it. :/
<seb128> infinity, no worry, crazy days for all of us, I understand
<pitti> Laney, infinity: could you please mark apport 2.12.1-0ubuntu3 as "ignore test failure"? it's going to fail because of bug 1218473
<ubottu> bug 1218473 in python-kde4 (Ubuntu Saucy) "KApplication now crashes immediately since last saucy sip and pyqt4 updates" [High,Triaged] https://launchpad.net/bugs/1218473
<pitti> but I don't want to hide that
<pitti> somehow the new pyqt slipped through without getting blocked by this regression
<pitti> (presumably because we don't do transitive rdepends testing)
<Laney> pitti: want to add a new pyqt test for this? :-)
<Laney> can skip, but it'll get blocked by beta 1 freeze anyway - should it go in to that?
<pitti> Laney: it's a crash in pykde; but yes
<Riddell> ScottK: pykde broken? ^^
<Laney> ah ok
<pitti> Laney: I think it's safe and desirable, but not the end of the world if it doesn't land
<pitti> Riddell: yes, see my ping from this morning
<pitti> Riddell: not sure whether it's in pykde or pyqt, but I left details in the bug
 * pitti -> lunch, bbl
<Laney> I don't think python-kde4 is right anyway ;-)
<ESphynx> xnox -- I'm close to a .dsc!
<ESphynx> xnox: Would an Ubuntu built .dsc be fine? :S
<xnox> ESphynx: from the beginning ScottK, you and I agreed that ecere-sdk is in sync with debian. Please upload updates to mentors.debian.net, i'll sponsor them to debian, and then sync into ubuntu.
<ESphynx> xnox: right I meant to upload to debian
 * dholbach hugs cjwatson and lool
<ESphynx> my silly VM is out of disk space to the pbuilder failed :P
<xnox> ESphynx: why .07, .08 where not uploaded into debian? or nothing linux interesting there?
<pitti> Laney: ah, so you already blocked everything for b1?
<ESphynx> xnox: .08 was a few weeks ago right before FOSSCON... quite rushed
<pitti> Laney: how much would I need to argue to allow apport?
<ESphynx> .07 probably caused more problems than it fixed ;)
<ESphynx> this is the stable one just in time for Saucy :P
<pitti> Laney: if it's "a bit", I'll do; if it's "formal FFE and a lot", I rather leave people with unreportable bugs :)
<ESphynx> be back soon, maybe I was doing this on my Sid vm last time
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ScottK> Riddell: Yes.  I knew it affected building pykde4, but not runtime.  I've been indiscussions with upstream, but no resolution yet (it'll require changes in both sip4 and pykde4).
<Riddell> ScottK: erk, what's up with it?
<Laney> pitti: not everything everything, but everything seeded in the flavours participating
<Laney> I'll let apport through :P
<xnox> pitti: Laney is rather nice, he let new upstream release of upstart through ;-)
<Laney> that was uploaded pre-FF!
<pitti> oh, then cyphermox might get his new network-manager accepted, too
<dobey> hmm
<pitti> we just found out that the wpasupplicant crash in the autopkgtest is a regression with the recent dbus, not from NM itself
<cyphermox> pitti: I've just been mentioning this on -release
<Laney> why don't we want to fix dbus?
<pitti> we certainly do
<pitti> britney should have held back dbus for this
<pitti> but it coincided with the massive "always considers as running" problems we have had last week, so I guess it slipped through
<pitti> kentb: responded to bug 1218433
<ubottu> bug 1218433 in systemd (Ubuntu) "Latest systemd updates break touchpad disable hotkey on Dell laptops" [High,In progress] https://launchpad.net/bugs/1218433
<kentb> pitti: ok. thanks. I'll send that info right  over
<pitti> kentb: hang on, I think I just found out how I can "simulate" your machine with udevadm hwdb --test
<pitti> kentb: and I confirm that the "!" markers (for force-release) are missing
<kentb> pitti: ok. I also just finished posting the latest stuff in case you need it.
<pitti> kentb: ack, thanks
<kentb> sure thing
<pitti> kentb: (sorry, the new hwdb stuff is still fairly new)
<pitti> so I'm still learning how to debug it efficiently
<kentb> pitti: oh, no worries at all
<pitti> kentb: updated file attached
<ScottK> Riddell: Typical sort of fixed something in sip4 and pykde4 had been relying on broken assumptions.  It's probably best to upload a really~lastrversion of  sip4, pyqt4, and pyqt5 if it's causing problems as I don't know when it'll be resolved.
<ScottK> I'll poke upstream again.
<kentb> pitti: ok. thank you. I should have results in just a couple minutes
<jdstrand> pitti: you are able to reproduce the wpasupplicant issue locally?
<pitti> kentb: that pointed out an interesting problem, I need to discuss that with upstream; but this should work for you
<pitti> jdstrand: "run-adt-test network-manager" reproduces it fine, yes
<pitti> jdstrand: and I confirm that downgrading dbus fixes it
<ScottK> Riddell: http://lists.kde.org/?l=kde-bindings&m=137759567504203&w=2
<pitti> jdstrand: I haven't yet tried running the test on my production machine; can do, but I need to go offline for that (shut down NM)
<jdstrand> pitti: are you able to make a change to the apparmor configuration and the run-adt-test? (using the new dbus)
<pitti> jdstrand: can do; let me set up the VM
<kentb> pitti: I think we have a winner :)  Touchpad hotkey working again on Latitude 6430u.  I have an Inspiron in the lab that I'll test sometime later today, but, I expect it'll be OK.  I'll update the bug if it isn't.
<kentb> pitti: thanks, again, for your help
<jdstrand> pitti: thanks. what you'll want to do is adjust /etc/apparmor.d/sbin.dhclient to add "dbus bus=session," to the profile for /usr/lib/NetworkManager/nm-dhcp-client.action
<pitti> kentb: thanks! could you please attach the "for e in /sys/class/input/event*; do udevadm test-builtin keyboard $e; done" with the working file?
<kentb> pitti: will do
<pitti> kentb: I'm interested in how that looks like (the difference with the ! flag)
<pitti> kentb: many thanks for your patience :)
<jdstrand> pitti: this 'sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient' before running the test
<kentb> pitti: no problem at all.
<ESphynx> Unity is bugged beyond all salvation, I give up!!!
<pitti> jdstrand: at a new line at the top or bottom of the block?
<jdstrand> pitti: anywhere in the /usr/lib/NetworkManager/nm-dhcp-client.action { } stanza
<tyhicks> jdstrand: thanks for handling the dbus issue while I was gone
<jdstrand> np
<tyhicks> I agree that nm-dhcp-client.action need session bus access based on the denial
<jdstrand> the question is why is it accessing the session bus, and it that makes wpasupplicant work again
<pitti> jdstrand: running
<pitti> jdstrand: OOI, what does bus=session mean?
<pitti> jdstrand: the session D-BUS? (wpa_supplicant uses the system bus)
<jdstrand> pitti: yes, that is the mystery
<jdstrand> but look at this denial in the jenkins syslog:
<jdstrand> Aug 29 18:17:54 autopkgtest dbus[8876]: apparmor="DENIED" operation="dbus_method_call"  bus="session" name="org.freedesktop.DBus" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" pid=9018 profile="/usr/lib/NetworkManager/nm-dhcp-client.action" peer_profile="unconfined"
<pitti> I saw one denial for some GetProperties, but I think that has always been there
<pitti> ah
<pitti> that's more interesting
<jdstrand> bus="session"
<jdstrand> we already have sub="system" via the dbus abstraction in the profile. but session is weird
<jdstrand> there are a couple of references to DBUS_BUS_SESSION in network-manager source
<tyhicks> the apparmor code added to dbus that generates that denial message takes the bus type right off of the message
<pitti> cyphermox, jdstrand: indeed that fixes it
<jdstrand> but not nm-dhcp-client.action specifically (according to cyphermox)
<jdstrand> man, that is weird
<jdstrand> pitti: are you doing any deep magic to make the tests not use the system bus or something?
<pitti> jdstrand: well, it uses dbus-launch to launch a private bus to do the testing on
<pitti> and pretends it was the system bus
<jdstrand> tyhicks: ah, that would do it I bet
<pitti> so that could be it
<tyhicks> yes, definitely
<tyhicks> dbus-launch launches a session bus
<cyphermox> jdstrand: pitti: I'm absolutely convinced nm-dhcp-client.action doesn't ever use the session bus.. though happy to be proven wrong
<cyphermox> gah
<pitti> cyphermox: well, it does in these tests
<cyphermox> yeah, I guess
<cyphermox> it's still a mystery why this affects wpasupplicant in any way
<pitti> export DBUS_SYSTEM_BUS_ADDRESS=`dbus-launch` (not literally, but in spirit)
<jdstrand> pitti: do you have the ability to update the apparmor profile via the autopkgtests?
<pitti> because everything happens on that bus
<cyphermox> but it seems to me like the wpasupplicant issue is just a coincidence
<pitti> jdstrand: yes, this runs as root, so it can do everything it wants to
<tyhicks> well you can feed a bus config file to dbus-launch
<pitti> jdstrand: can I do that in a separate file somehow, or apply seddery to that profile?
<tyhicks> I wonder what would happen if you gave it a system bus config file
<jdstrand> pitti: you could append "bus=session," to abstractions/dbus
<jdstrand> pitti: but tyhicks suggestion might be more interesting and real world
<pitti> tyhicks: I guess that would be most elegant; not sure whether one can do that as user, but I'll try
<pitti> (that's done by python-dbusmock)
<tyhicks> ah
<jdstrand> cyphermox: it is interesting that wpasupplicant is the grumpy one when nm-dhcp-client.action gets the denial, isn't it?
<jdstrand> pitti: so, at this point is the ball in your court?
<pitti> jdstrand: yes; I'll try tyhicks' suggestion with passing a config to dbus-launch, and if that doesn't work do the profile seddery
<cyphermox> jdstrand: quite
<jdstrand> pitti: cool, thanks! :)
<pitti> tyhicks, jdstrand: thanks for pointing this out! that was quite surprising
<tyhicks> thanks pitti - ping me if you need anything
<cyphermox> especially for some piece of code that shouldn't ever ever be touched, since it's support for new stuff we don't test yet, and almost nobody has support for
<jdstrand> cyphermox: I'll leave that to your curiosity then :)
<cyphermox> jdstrand: heh, I'll debug this on monday
<cyphermox> we're probably just unlucky there, or lucky that it's showing a real bug we'd eventually hit
<pitti> kentb: "keyboard: updating force-release list with '140,158,369-370,140,158'
<pitti> kentb: ah, that's what I was expecting, thanks
<kentb> pitti: ok. cool. I saw that myself.  Glad it helped you out!
<pitti> tyhicks: how does it decide whether it's the system or session bus? does it ask the process "what are you", or does it check uid, etc?
<tyhicks> pitti: what do you mean by "it"? dbus-launch or the apparmor mediation code that I added to dbus?
<diwic> from apt-get:
<diwic>     gstreamer1.0-plugins-good:amd64 conflicts with gstreamer1.0-plugins-bad:amd64
<diwic>     gstreamer1.0-plugins-bad:amd64 conflicts with gstreamer1.0-plugins-good:amd64
<diwic> the eternal fight between good and bad it seems like!
<pitti> tyhicks: nevermind; specifying a config file with  <type>system</type> works fine
<tyhicks> ah, yeah - that's all there is to it
<pitti> tyhicks: splendid, I'll fix that in python-dbusmock and try to squeeze it through the freeze (it's not seeded, so should be fine)
<tyhicks> thanks pitti :)
<pitti> tyhicks: thanks to you, too
<dobey> can anyone reject/delete/whatever ubuntuone-credentials-13.07-0ubuntu1 from the saucy NEW upload queue?
<seb128> dobey, done
<dobey> thanks
<dobey> doh
<dobey> seb128: you rejected the 13.08 upload, not 13.07 :-/
<seb128> dobey, crap
<seb128> dobey, let me fix that
<Laney> now he gets to review from rejected ;-)
<dobey> heh
<Laney> (you can accept from rejected)
<seb128> Laney, yeah :/
<pitti> yeah, just not put back into NEW :/
<Laney> seb128: or get the uploader to reupload :P
<seb128> Laney, that's ok, I just need to find a nitpick to justify the reject
<dobey> what? the package is *perfect* :)
<pitti> "badly worded package description"
<dobey> "package description not in french"
<pitti> tyhicks, jdstrand, cyphermox: ok, new python-dbusmock uploaded with the "pretend harder to be a system bus"; that's certainly the least place I would have expected a dbusmock bug to live :)
<jdstrand> hehe, thanks! :)
<dobey> seb128: do i need to re-upload?
<pitti> "Jenkins Fixed - saucy-adt-mysql-5.5" -- OH MY OH MY OH MY!
<dobey> or you can just accept it :)
<seb128> dobey, Package: qtdeclarative5-ubuntuone-credentials-plugin ... please rename "Package: qtdeclarative5-ubuntuone1.0"
 * pitti hugs jamespage
<jamespage> pitti, just doing my QA catchup
<pitti> jamespage: so you managed to fixed that one in two gazillion tests that was always failing?
<jamespage> pitti, yep
<seb128> dobey, current convention (from kenvandine) is qtdeclarative5-<importname><version> ... it makes different versions co-installable
<dobey> seb128: is that new? i named it based on what existing plugins were named
<jamespage> the test executor was being called with a trailing / on one of the parameters
<pitti> jamespage: OOI, for legitimate stderr (if that cannot be sensibly suppressed), there is now "Restrictions: allow-stderr"
<seb128> dobey, relatively new yes, the recent packages use that
<jamespage> pitti, yeah - I spotted that
<dobey> seb128: but existing ones haven't been updated?
<seb128> dobey, no, we decided it wasn't worth transitioning all the existing one, we try to respect the new convention for new packages though
<seb128> dobey, also copyright
<seb128> "Files: music-login/*
<seb128> Copyright: 2013 Canonical Ltd.
<seb128> License: GPL-3 with OpenSSL Exception"
<seb128> but
<seb128> ./online-accounts-provider/NewAccount.qml: GPL (v3)
<seb128> ./online-accounts-provider/ExistingAccount.qml: GPL (v3)
<seb128> ./online-accounts-provider/Main.qml: GPL (v3)
<seb128> dobey, ^ need to add those to the GPL3 list
<seb128> dobey, out of those, it's fine, if you fix them I and reupload, I can approve
<smoser> can i get an archive admin to nack my upload to precise-proposed of ubuntu-cloudimage-keyring_2013.08.23~12.04.1.dsc
<smoser> the changelog didn't hvae a bug reference.
<seb128> dobey, it's a bit suboptimal that you have /usr/share files in the lib binary as well, it means that if the soname change the versions are not going to be co-installable
<dobey> seb128: infinity was insistent on a security review, that sarnold i think is going to do, as well. i don't know if we want to block on putting it in universe for that or just block having it on the touch image
<seb128> dobey, security reviews don't happen in NEW usually
<seb128> rather before MIR/seeding
<stgraber> smoser: which one?
<seb128> we have plenty of code with unsecure code in the archive I'm sure
<dobey> seb128: yeah, but this was being seeded to touch from universe so infinity thought we should get it done now
<dobey> also since the previous upload had been sitting there for a month with not being accepted into the archive :-/
<seb128> dobey, ok, then just fix the stuff I reupload and we can wait for the security review to happen
<smoser> stgraber, the precise one without a bug in the chagnelog
<stgraber> smoser: done
<smoser> if you want you just delete both precise-prposed and i re-upload the righ tone.
<seb128> dobey, but I'm happy to accept it as well
<smoser> thanks. so there should be one there, right?
<smoser> thanks stgraber
<stgraber> smoser: yep, I kept the one with the bug reference
<dobey> seb128: might be better to just accept it into universe too. i'll be on holiday all next week, and we need to get this into the touch image asap
<seb128> dobey, wfm, let me know when you reupload
<chiluk> dholbach, kenvandine rsalveti can you guys approve the already sponsored uploads for curl and apt in the precise, quantal,raring queues?  also be careful because the change to apt adds a builddep to the newly uploaded version of curl
<dholbach> chiluk, no, not within my powers I'm afraid
<kenvandine> chiluk, me either
<chiluk> both of you are listed on the patch pilot calendar...
<chiluk> what patch piloting are you able to do?
<smartboyhw> chiluk, patch pilots only upload fixes
<kenvandine> that needs to be someone from the sru team
<smartboyhw> For approving queues, that goes to SRU team:)
<chiluk> alright...
<kenvandine> sorry
<chiluk> thanks guys..
<chiluk> nope.. the process here is not always the most straightforward.
<chiluk> I'm still getting used to it.
<chiluk> I thought I had it figured out.
<xnox> cjwatson: doko: any idea why apt-get install libgles2-mesa-dev:armhf fails? http://paste.ubuntu.com/6044494/
<arges> dholbach: kenvandine smartboyhw : btw who is patch piloting now? i have a patch(es) that may need some piloting.
<smartboyhw> arges, nobody
<smartboyhw> ?
* smartboyhw changed the topic of #ubuntu-devel to: shows who is
<smartboyhw> Oh NO
<arges> heh
 * smartboyhw hates this channel:p
* smartboyhw changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smartboyhw> Phew:P
<smartboyhw> Someone lock topic for this channel plz...
<ogra_> just dont edit it :)
<chiluk> infinity, RAOF, SpamapS, cjwatson, slangasek, Daviey, can one of you approve the upload for curl and then later apt *(apt gets a builddep on the new version of curl) that's sitting in the upload queues for p,q,r ? related bug = pad.lv/1179781
<kenvandine> damn... i hadn't noticed i was scheduled for piloting today...
<kenvandine> dholbach, sorry :/
<smartboyhw> ogra_, I was saying that "/topic shows who is"
<smartboyhw> And uh hum, that happened
<smartboyhw> SORRY
<smoser> slangasek, since its your day for SRU, and you're probably not doing anything important at all.... https://bugs.launchpad.net/ubuntu/+source/ubuntu-cloudimage-keyring/+bug/1218963 would be appreciated. it seems particularly low regression potential to me.
<ubottu> Launchpad bug 1218963 in ubuntu-cloudimage-keyring (Ubuntu Raring) "SRU ubuntu-cloudimage-keyring into archive" [Medium,In progress]
<ogra_> smoser, no worries, you restored it :)
<smartboyhw> ogra_, you pinged the wrong guy:P
<ogra_> heh
<arges> kenvandine: when you pilot-in, can you check out bug 1160490. I've got debdiffs ready and packaged tested for an SRU. thanks
<ogra_> happens :)
<ubottu> bug 1160490 in ifupdown (Ubuntu Saucy) "race condition updating statefile" [Medium,In progress] https://launchpad.net/bugs/1160490
<kenvandine> arges, that's why i was saying sorry... i really can't do it today... :/
<arges> ok..
<kenvandine> arges, sorry :(
<doko> xnox, not immediately
<xnox> doko: in minimal chroot, it's even more fun. apt-get install libgles2-mesa-dev:armhf decides: build-essential cpp cpp-4.8 dh-autoreconf g++ g++-4.8 gcc gcc-4.8 libtool sbuild-build-depends-core-dummy
<xnox> should be removed.
 * xnox installs cross-build essential first.
<xnox> works in a chroot.
<xnox> so dunno....
<dobey> seb128: uploaded
<seb128> dobey, NEWed
<dobey> thanks
<arges> Hi. Can anybody with some extra time take a look at bug 1160490, its in need of sponsoring. Thanks
<ubottu> bug 1160490 in ifupdown (Ubuntu Saucy) "race condition updating statefile" [Medium,In progress] https://launchpad.net/bugs/1160490
<danjared> xnox: I thought we were still undecided about combining suspend and hibernate into one
<slangasek> danjared: towards the end of the session, I think we had good consensus that we wouldn't expose hibernate as a separate UI option, it should be handled transparently underneath
<xnox> danjared: well the design from 2007 for ubuntu, finally have the technology to implement it =) and since then people were towards the idea of a single button "suspend" which will "hibernate" after a timeout, which one can twiddle in settings - zero timeout, X minutes, hours, never.
<danjared> slangasek: I'll have to rewatch the session, but I certainly wasn't of that opinion :)
<xnox> danjared: so everyone has suspend, and those with rapid start can have suspend+timeout->hibernate.
<xnox> danjared: our usability tests in the past showed that people have no idea what the difference between the two is =)
<danjared> I think there's still value in being able to put your system into a ~0 power state immediately without having to shutdown (and therefore lose state)
<xnox> danjared: what's your preffered default timout? as per intel 1h, or instant?
<danjared> (alternatively, having to go temporarily change settings)
<xnox> danjared: in practice how much power is used to do 1h of sleep?
<slangasek> danjared: does the firmware even *let* us initiate an irst hibernate from the OS?
<slangasek> and yeah, what xnox said re: usability
<xnox> slangasek: no, you can set timout to zero & sleep. Such that on boot/resume we need to reset the timer back to the default value as far as I can tell from the specs and Windows UI to control this.
<slangasek> ah
<danjared> xnox: unsure, but it lets me do things like hibernate immediately and swap out my battery without plugging in
<xnox> cool.
<danjared> slangasek: right, you get to set the timer to zero but leave iRST on, so right when the system goes into S3, the firmware wakes it back up and hibernates
<xnox> danjared: i wasn't sure how to prevent iRST despite having the partition and et al. The guide suggested to format / remove the iRST partition =/
<xnox> unless I missed that somehow.
<danjared> xnox: I .... actually did a more extreme version of that a couple days ago where I went into iRST hibernate then disassembled my laptop to replace the keyboard (which I had spilled something on and rendered some keys non-functional). once it was back in one piece, I reassembled, thawed, and continued on
<xnox> .................. danjared i'm not sure we user test that scenario, most of the people we get for user-testing do not bring spare keyboards and toolkits to perform laptop surgeries =)
<danjared> xnox: sure, I'm just giving an anecdote there. the "swap out battery" case is the more salient one :)
<xnox> danjared: at one point we had a design where the shutdown dialog has options drop-down to e.g. bypass UEFI fastpath, and that could have had "hibernate" instantly.
<xnox> danjared: i'm still testing normal hibernate here locally & will be formatting my new laptop with iRST partition in a moment. But if it's quick enough, I'd be inclined to have the default timeout zero.
<xnox> danjared: would that be better?
<danjared> xnox: if you want to temporarily disable iRST, you set the first bit of SFFS to 0: http://mjg59.dreamwidth.org/26022.html
<xnox> danjared: =) i wonder if I should package mjg59 blog as manpages.
<danjared> xnox: a drop-down dialog that lets you hibernate immediately seems fine to me.
<danjared> xnox: you could always ask him :)
<danjared> if the difference between sleep and hibernate is confusing, maybe hibernate could be renamed to "power off (save session)" or something similar
<xnox> danjared: i googled for SFFS and google offered me some intel confidential driver specs =)
<xnox> \o/
<danjared> yeah, I noticed that many of their intentionally public documents still say that
<xnox> danjared: no, we removed it =) we have: <list of users to switch to>, log out,  suspend, restart, shut down.
<xnox> and it would not be compelling to re-introduce hibernate, as it was very very unreliable, failed to resume, was confusing with suspend.
<danjared> right, I meant if you are adding a down-down
<xnox> "drop down"
<danjared> that too. it's still early for me :)
<xnox> yeah, that drop down existed before unity OSD type shutdown.
<danjared> so, I thought "hibernate" is still an option for OEM systems
<danjared> (we'd like to keep that)
<xnox> danjared: http://askubuntu.com/questions/94754/how-to-enable-hibernation
<xnox> danjared: so default policikit file in Ubuntu disables hibernate, users can enable it. And/or OEMs may do that as well, if they wish.
<danjared> right, sorry, I should have been clear that I am thinking in the context of OEM installs where we've tested hibernate enough to back using it
<xnox> danjared: once enabled, the UI magically offers hybernate.
<danjared> I mean that, when the hibernate option is made available, it should default to using iRST to immediately hibernate a system instead of using Linux's software hibernate
<xnox> danjared: no, as Linux's software hibernate works with full disk encryption using LUKS, and iRST doesn't.
<danjared> xnox: and you can work around that by reverting to Linux's hibernate if software disk encryption is used
<xnox> danjared: and we care about user privacy & security, especially when they went to lengths to enable full disk LUKS encryption (a single checkbox)
<xnox> danjared: i'm un convinced, but then again I don't drive, ubuntu system user design either. mpt, what do you think - should hibernate option be exposed to the users, if we can guarantee that it's reliable?
<xnox> danjared: Linux's software hibernation will not be exposed as "hibernation" by default (but one can twiddle policy kit to enable it). Exposing zero timout iRST as hibernate is an option which could go in.
<danjared> I mean, you're using disk encryption as a criterium for whether iRST is enabled anyway, and hibernate is exposed to users buying from an OEM
<xnox> danjared: and at oem-config first screen they can tick "encrypt my home directory" on OEM preinstalled machine.
<danjared> correct. if they do that, iRST can be disabled
<xnox> it would be sad, UI wise, that enabling encryption makes hibernate button disappear, unless of course OEM provided big enough swap and validated / enabled Linux's hibernation as well.
<xnox> (with and without user home directory encryption, which does LUKS encryption of swap upon activation)
<danjared> we currently validate Linux's hibernation. it's part of the certification, IIRC
<xnox> danjared: as OEM you certainly have enough toggles to enable everything =) and it would be hard to remove toggles.
<danjared> okay, sure. as long as the toggles are there still
<mpt> xnox, the menu I showed you this morning was like danjared is describing: "Immediately" was sleep=hibernate, "Never" was don't hibernate.
<xnox> mpt: sure, but danjared implies that as a user i want to have: sleep (eventually hibernate) button and hibernate-now button (i want to unplug my lapto battery). Directly in the UI, without changing the default.
<mpt> xnox, but I like the idea that if encryption is on then you get the software hibernate instead.
<xnox> mpt: i doubt we will enable back software hibernation by default across the board, it was disabled because OEMs validated it to be unreliable and not meeting expectations.
<xnox> mpt: but it looks like on danjared's laptops it will be wonderful =)
<mpt> What proportion of OEM installs have working hibernate? 10%? 20%? 80%?
<danjared> kentb: double-checking, we test hibernate as part of OEM validation, right?
<xnox> danjared: http://www.ubuntu.com/certification/hardware/201202-10556/ "Hibernate may not function on this system"
<mpt> So we have {iRSTable, software-hibernatable, software-unhibernatable, software-mysterious} Ã {encrypted, unencrypted with the necessary partition, unencrypted without the necessary partition}?
<mpt> That's 12 combinations
<danjared> xnox: that certification isn't for a factory install. the factory install certifications are a bit different and have a different logo there
<mpt> though probably several of them can be combined
<xnox> danjared: correct.
<danjared> xnox: here's a weird one that demonstrates that: http://www.ubuntu.com/certification/hardware/201208-11536/
<mpt> xnox, could you make a table along those lines, with approximate percentages of each if you know them? That way we'll have a better idea what we're designing for.
<mpt> Then I can come back next week and knock out designs for them.
<xnox> mpt: in practice thought the second portion is {software encryption used, software encryption is not used}.
<mpt> xnox, by "the necessary partition" I meant the necessary partition for either iRST or software hibernation. (They both need an extra partition, right?)
<xnox> mpt: sure, but your way some combinations are impossible combinations. =)
<mpt> good
<sarnold> dobey,seb128, I've started reviewing the 13.08-0ubuntu1 version of ubuntuone-credentials; I'm liking what I'm seeing, I expect to finish it quickly.
<dobey> sarnold: great. thanks!
<sarnold> Laney: ooh cool :)
<kentb> danjared: yes. we do.  It is turned on on the OEM images
<kentb> danjared: not a certification blocker but it is tested and noted in the certification if there are issues with it.
<Whoopie> debfx: yeah, saw it. Thanks a lot!
<Whoopie> debfx: to be honest, the vnc extension is not very stable. but it's good to get more feedback.
<pitti> cyphermox, jdstrand: aah, love green! https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-network-manager/
<jdstrand> \o/
 * pitti waves good night, enjoy the weekend
<jdstrand> pitti: you too :)
<dobey> kenvandine: ping
<kenvandine> dobey, pong
<dobey> kenvandine: i presume it's possible to use online-accounts from vala right? is there a good example of it anywhere?
<kenvandine> yeah, look at unity-lens-friends
<dobey> cool, thanks
<kenvandine> np
 * xnox is not quite sure what's broken
<infinity> tjaalton: Why do my drm lockups not produce crash reports anymore?
<infinity> tjaalton: Did you decide you didn't want all my i915 bugs? :P
<tjaalton> infinity: heh, when was the last time they produced lockups?
<infinity> tjaalton: Today and yesterday.
<tjaalton> erm I mean crash reports
<infinity> tjaalton: Err, not sure.  Back when I had those frequent hangs in... Q?  R? ... I used to reboot and have a ton of apport popups to cope with.
<tjaalton> ah, could be a change in xdiagnose then
<infinity> tjaalton: Not having those is certainly more friendly, but not having anything reported is a bit less handy. :)
<infinity> tjaalton: Anyhow, drm on my sandybridge sucks again.  I blame you.
<tjaalton> well it might just be the same bug all the time
<tjaalton> yeah, upstream was hopeful of a patch fixing it, and it worked for some but then upstream reproduced it again..
<infinity> At least it's different from the Q/R issues I had. :)
<infinity> tjaalton: I assume you're talking about these: http://paste.ubuntu.com/6045137/
<infinity> tjaalton: (Which sometimes recover, like above, and sometimes hard lock and force me to reboot... I assume it's the same bug either way, but a bit hard to tell for sure the cause of the reboot ones)
<tjaalton> the one with i915.semaphores=0 workaround
<tjaalton> but sounds like your bug could be in mesa instead
<infinity> tjaalton: Well, if the one you're talking about is the Q/R lockups, this is definitely different.  And very new.
<infinity> I've never seen this before yesterday.
<infinity> Could be mesa9.2's fault.
<tjaalton> file a new bug against x-x-v-intel and attach i915_error_state
<tjaalton> yeah
<tjaalton> it's been happy on my lappy for a week
<tjaalton> snb
<infinity> My reproduction method has, so far, been to play video in mplayer with the -vo gl renderer.
<tjaalton>   * debian/xdiagnose.udev: Disable gpu apport hook for raring release
<infinity> Haven't tried xv yet.
<tjaalton> so you could hack that to report crashes again
<infinity> It soft locked about 4 times in the course of a 2h movie last night, and had locked once.
<infinity> s/had/hard/
<tjaalton> hmm this is why we haven't been getting any bugs during saucy :P
<tjaalton> other than the usual xserver crashes
<tjaalton> xdiagnose is basically orphaned since bryce left
<tjaalton> mlankhorst: ^ maybe you should adopt that one too ;)
<mlankhorst> tjaalton: ah :P
<tjaalton> maybe enable it until release-ish
<mlankhorst> tjaalton: bit late in the cycle for that, though..
<tjaalton> well, now is the time when people start upgrading en masse
<tjaalton> or after beta
<tjaalton> still nearly two months until release
<mlankhorst> tjaalton: I won't be able to look at it until monday, but I'll add it to my list
<tjaalton> sure, no rush
<slangasek> chiluk: curl accepted.  Now, what happens if someone happens to pull the new version of apt from -updates without explicitly pulling in the new version of curl?  Will that regress existing uses of apt-transport-https?
<slangasek> chiluk: if so, it seems to me that apt should have a hard-coded versioned runtime dependency on the fixed libcurl; and the build-dependency actually looks superfluous to me
<chiluk> slangasek, it will be fine because apt statically links with the curl libs.
<infinity> slangasek: I would hope there's a binary dependency.
<chiluk> afaik
<infinity> Err, it does what now?
<slangasek> chiluk: it does not
<infinity> (base)adconrad@cthulhu:~$ ldd /usr/lib/apt/methods/https | grep curl
<infinity> 	libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f46995e9000)
<slangasek> infinity: there's a binary dependency on libcurl; but not on the new SRUed version of curl, which doesn't change abi and therefore doesn't change shlibs
<chiluk> nuts.. i stand corrected
<infinity> slangasek: Did this introduce a header change?  If not, the build-dep is indeed pointless.
<slangasek> infinity: nopers
<infinity> Yeah, so the build-dep should be a binary dep.
<chiluk> i assumed that since I only found a build-dep that's all that needed updating.
<chiluk> i stand ashamed.
<infinity> Or that curl should have a shlibs bump.
<slangasek> chiluk: so I think these apt uploads in the queue should be rejected, I'll do that now.  Do you understand what you need to change for the reupload?
<chiluk> yeah... add a depends on the new version of curl for apt.
<chiluk> not a builddep
<chiluk> I'll revert the builddep line back to the previous version
<slangasek> for apt-transport-https, specifically (which is probably what you meant, but just to be explicit)
<chiluk> yeah.
<slangasek> chiluk: and the binary package to depend on appears to be libcurl3-gnutls, which the version set to the SRU version of curl in the corresponding pocket - so different for each
<infinity> apt-transport-https is just pulling its curl dep from shlibs currently.
<slangasek> yes
<slangasek> so we want to hard-code an override for that in debian/control
<chiluk> slangasek, right.
<infinity> So, why not just fix this in curl's shlibs?
<slangasek> because it's not a shlib issue
<slangasek> it's an "apt will do broken things if running with a version of curl that has this particular bug" issue
<dobey> i take it a build in -proposed being in depwait on powerpc will block the package being migrated to release?
<infinity> dobey: It will if the binary previously existed on PPC.  Which package?
<dobey> infinity: ubuntuone-credentials
<infinity> Then no.  That's a new package.
<chiluk> I agree that the dependency should be explicit in apt-transport-https and not shlibs... because this is exacerbated by apt
<infinity> dobey: It just needs someone to process the other three arches from binary NEW.  I'll look at 'em now.
<dobey> ubuntu-ui-toolkit isn't built on powerpc, and ubuntuone-credentials has a build-dep on a package from ubuntu-ui-toolkit, so it won't build on powerpc. but i don't see why a) ubuntu-ui-toolkit isn't builting on powerpc or b) why ubuntuone-crednetials is trying to
<dobey> ah ok
<dobey> thanks
<cjwatson> not building on an architecture is only a problem for proposed-migration if there are currently binaries for that architecture in the release pocket.
<infinity> dobey: ubuntu-ui-toolkit probably isn't building on PPC cause it needs qt5declarative, which needs v8, which isn't ported to anything other than x86 and ARM.
<infinity> Because Google are muppets.
<infinity> And Qt upstream are even bigger muppets for choosing a JS engine that only exists on 1.5 architectures. :P
<slangasek> infinity: you coulda had a V8
 * sarnold smacks forehead
<slangasek> infinity: alas, this means that quantal still doesn't have the backported fix for auto-cleaning of stale kernels... so maybe you want to sponsor chiluk's next apt? :)
<infinity> slangasek: I thought we'd decided to only bother backporting that to the LTS.
<infinity> slangasek: But we can certainly do Q too.
<chiluk> man, I didn't expect apt to build into separate binaries like that.... sorry bout that guys... I still think it's retarded instead of linking to libs..
<slangasek> infinity: well, apparently you uploaded 0.9.7.5ubuntu5.3 in January or something to fix it in Q, then it was superseded by a security upload, then bdmurray included the change in his latest sponsored upload
<infinity> slangasek: Oh, hrm.  Sure.  I'll take your word for it.  That was another lifetime ago. :)
<slangasek> chiluk: apt is a low level component of the system, apt-transport-https is an optional component with significant added dependencies; the binary split is necessary to avoid a) bloating the system, b) breaking bootstrapping
<infinity> dobey: Accepted.
<chiluk> slangasek, ah.. thanks.... sometimes knowing the reason makes things less insane.
<chiluk> slangasek infinity does order matter on the Depends: line for precedence ?
<slangasek> nope
<dobey> infinity: thanks again
<slangasek> chiluk: not unless it's an ORed dependency
<slangasek> (which should not be the case here)
<infinity> dpkg-gencontrol should be smart enough to collapse the dep from dpkg-shlibdeps and the manual dep from debian/control into the single higher one anyway.
<slangasek> it is
<infinity> (But even if it's not, you just have two harmless deps that say "foo (>= 1), foo (>= 2)", which obviously reduces to "you need higher than 2")
<slangasek> at least for the releases we're talking about
<slangasek> smoser: bug #1218963> I don't see any packages in the queue for this?
<ubottu> bug 1218963 in ubuntu-cloudimage-keyring (Ubuntu Raring) "SRU ubuntu-cloudimage-keyring into archive" [Medium,In progress] https://launchpad.net/bugs/1218963
<slangasek> oh, they're in NEW
<slangasek> ok
<arges> slangasek: hiya. could you sponsor an SRU for bug 1160490? thanks
<ubottu> bug 1160490 in ifupdown (Ubuntu Saucy) "race condition updating statefile" [Medium,In progress] https://launchpad.net/bugs/1160490
<slangasek> arges: maybe it would be better to have stgraber do the sponsoring?
<slangasek> (though before we do any of that, we ought to get bug #1217263 fixed in saucy :P)
<ubottu> bug 1217263 in ifupdown (Ubuntu) "conffile change prompt on upgrade" [High,Triaged] https://launchpad.net/bugs/1217263
<arges> slangasek: sure. I saw your name all over the changelog, and figured it may be too late for him
<slangasek> arges: he's only eastern time :)
<slangasek> (now)
<arges> ah
<arges> slangasek: why does bug 1217362 need to get fixed first?
<ubottu> bug 1217362 in cups (Ubuntu) "package cups 1.7.0~rc1-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127" [Undecided,New] https://launchpad.net/bugs/1217362
<infinity> arges: Because you're dyslexic.
<arges> hah
<arges> bug 1217263
<ubottu> bug 1217263 in ifupdown (Ubuntu) "conffile change prompt on upgrade" [High,Triaged] https://launchpad.net/bugs/1217263
<arges> there we go
<slangasek> arges: because a) bugs should be fixed in the devel series before being SRUed, b) conffile handling bugs should be fixed ASAP because they get harder to fix properly with each subsequent upload
<chiluk> slangasek, infinity... done... debdiffs attached here  .   https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1179781
<ubottu> Launchpad bug 1179781 in apt (Ubuntu Raring) "If-Modfied-Since undhandled case causes apt lists corruption with https repositories" [Medium,Triaged]
<ESphynx> xnox: Uploading on debian.mentors.net ...
<ESphynx> there is still a bug with this Unity stuff, but I am very late on my weekend vacation schedule :S
<ESphynx> So I will try to fix that when I come back and submit a patch
<ESphynx> xnox: http://mentors.debian.net/package/ecere-sdk
<ESphynx> Sorry to submit it so late, I was really hoping to fix these Unity woes which apparently are not fixed yet
<ESphynx> So either redj this weekend or me when I come back on Monday evening are going to try to resolve that properly and submit a patch...
<Noskcaj> kirkland, what's your reasoning for keeping parallels in testdrive?
<dobey> sarnold: hi. did you finish up the ubuntuone-credentials review already?
<sarnold> dobey: not yet, but please feel free to treat it as an ACK
<dobey> sarnold: ok. thanks!
<smoser> slangasek, is there anything i need different since they're new?
<infinity> dobey: Just make a mental note that that review's already been done when MIR time comes. :)
#ubuntu-devel 2013-08-31
<darkxst> XDG_CURRENT_DESKTOP is no longer available for when gnome-settings-daemon starts up?
<darkxst> stgraber, ^, perhaps this is due to upstart user sessions?
<highvoltage> I received build failure notifications for edubuntu from cdimage, but there's no logs attached. I used to have a URL that I could change to still get it.
<highvoltage> anyone happen to know what that url should look like or how to get that build log?
<smartboyhw> highvoltage, sup, it's at https://people.canonical.com/~ubuntu-archive
<cjwatson> highvolt1ge: I'm not sure why mails didn't get sent.  http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/edubuntu-dvd/latest/
<cjwatson> Or rather why empty mails got sent
* cjwatson changed the topic of #ubuntu-devel to: Launchpad maintenance 2013-08-31 | Ubuntu 13.04 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> Not sure I have topic space for details, but see https://lists.ubuntu.com/archives/launchpad-announce/2013-August/000101.html
<smartboyhw> cjwatson, considering that the maintenance is only 1.5 hours, you should rather write the time down....
<cjwatson> smartboyhw: *shrug*
<cjwatson> better to be overly liberal in these things, people can read the announcement for more detail
<cjwatson> I'll remove it from the topic when the window ends
<smartboyhw> cjwatson, sure;)
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<darkxst> I have uploaded a bunch of patches we would like to get in for ubuntu GNOME beta 1 candidate, Bugs 1212408, 1219148, 1219188
<ubottu> bug 1219188 in gnome-shell (Ubuntu) "Add support for seperate background on lock screen" [Undecided,In progress] https://launchpad.net/bugs/1219188
<ubottu> bug 1219148 in gnome-settings-daemon (Ubuntu) "Fix gdm -> login transition" [Undecided,New] https://launchpad.net/bugs/1219148
<ubottu> bug 1212408 in gdm (Ubuntu) "lightdm/gdm needs to set $XDG_CURRENT_DESKTOP" [Undecided,New] https://launchpad.net/bugs/1212408
<ari-tczew> does list of ubuntu-devel-announce not work?
<slangasek> smoser: nope, being in new just means I need to pay attention to a different queue to find them :)
<mlankhorst> ofc :P
<ekarlso-> https://launchpadlibrarian.net/149043705/buildlog_ubuntu-precise-amd64.gearmand_1.1.9~20130802-2_FAILEDTOBUILD.txt.gz < anyone know why that fails ?
<tsimpson> ekarlso-: you'll just have to retry the build, it's a problem with the LP buildd
<ekarlso-> tsimpson: SIGH
<ekarlso-> that's like 15 hours waiting
<ekarlso-> or just 5 this time..
<tsimpson> you're not the only one a little annoyed with the situation ;)
<ekarlso-> tsimpson: LP has too little build slaves or ?
<ekarlso-> what about using da cloud ? ^
<tsimpson> I don't know the exact reason, but it seems to appear on build servers randomly
<tsimpson> LP seems to have plenty of builders though
#ubuntu-devel 2013-09-01
<cjwatson> ekarlso-: Which builder was that on?
<cjwatson> ekarlso-: (In general, quoting the .../+build/... URL is more helpful than quoting the build log, since that tells us which builder has a problem)
<cjwatson> ekarlso-: It looks as though you've already retried it, but there'll be a Builder: line in the failure mail you got.
<cjwatson> ekarlso-,tsimpson: Regarding the number of build slaves, there is a plan in progress to move them to a private cloud.  In the meantime, some of the problems are due to failing builders for various reasons, which then require manual intervention to fix (hard to come by at the weekend); I'm currently trying to get https://code.launchpad.net/~cjwatson/launchpad/failure-count-reset/+merge/183320 landed which should help.
<cjwatson> And then of course there's all the big packages that people think are appropriate to build frequently from recipes for multiple series ...
<tsimpson> cjwatson: how ironic is it that I got a timeout with that link
<cjwatson> tsimpson: Not very, since appserver timeouts are entirely unrelated to build farm load :)
<cjwatson> It worked again after a try or two
<tsimpson> yeah, I think the LP infrastructure needs some love
<cjwatson> ...
<tsimpson> it seems to be falling over more and more often
<cjwatson> From my POV it's been improving
<cjwatson> There's been maintenance work on the librarian SAN today so it's possible that there are issues left over from that
<tsimpson> well I'm (probably nostalgically) comparing from way back when it was all new and shiny
<cjwatson> I think you're experiencing rose-tinted hindsight.  It's much more useful now than it was then
<tsimpson> oh more useful, certainly
<cjwatson> The occasional timeout is annoying but nearly all the timeouts I see nowadays are solved by a reload
<cjwatson> There are many fewer cases nowadays where it just plain doesn't work
<ari-tczew> have we libav9 transition this cicle?
<ekarlso-> https://launchpadlibrarian.net/149070511/buildlog_ubuntu-precise-amd64.gearmand_1.1.9~20130802-2_FAILEDTOBUILD.txt.gz < anyone help me whi this is failing ?
<Peace-> hi i was trying to create a hotspot but ... wlan0: AP mode support not included in the build
<Peace-> this is the stuff 07:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)
<mitya57_> ekarlso-: conftest.c:58:29: fatal error: hiredis/hiredis.h: No such file or directory â missing BD or -I flag?
<cjwatson> no, this is the actual fatal error
<cjwatson> configure: error: could not find gperf
<cjwatson> this is a rare case where you're better off reading the log from the top
<cjwatson> so that looks like missing Build-Depends: gperf
<cjwatson> (it's possible that the missing hiredis/hiredis.h is a problem too - it's just not the one that caused it to error out)
<ice9> Only apps written by the Ubuntu SDK will run on both Mobile and PC?
<smartboyhw> ice9, yes
<smartboyhw> Well, at least accepted by the store
<ice9> smartboyhw, when Ubuntu mobile OS is release, how all the current apps will be converted to Ubuntu SDK, that's ton of work for all developers
<ice9> Or we will see another alternatives for the current apps
<smartboyhw> ice9, well, the applications that are in the Ubuntu Software Store currently might not be in mobile
<smartboyhw> Some of them really can't be ported
<ldsh> Hello, is it done on purpose that it is not possible to screenshot drop-down menu ?
<micahg> ari-tczew: re libav9, not looking like it
<ari-tczew> micahg: ok
#ubuntu-devel 2014-08-25
<cjwatson> cyphermox: can certainly try a test package if you point me at it
<Mirv> Unit193: hellos
<pitti> Good morning
<pitti> doko__, cjwatson: so perl isn't held by autopkgtest failures now, just by uninstallability
<YokoZar> cjwatson: Would a sync of new libcdio (for multiarch compatibilty) be appropriate?  (Debian includes new upstream version as well)
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1151565
<ubottu> Launchpad bug 1151565 in libcdio (Ubuntu) "Please transition libcdio to multi-arch" [Undecided,Confirmed]
<dholbach> good morning
<jibel> pitti, I've 2 machines running utopic that hang on shutdown or reboot. One hangs on unmountfs, the other I don't know. DO you know how to debug that?
<pitti> jibel: did you already try without "splash quiet"?
<kdeuser56> pitti: have you got my mail about apport?
<jibel> pitti, yes, and it stops at unmounting file systems ...
<pitti> kdeuser56: yes, Harald already answered it
<jibel> pitti, and stays here forever
<kdeuser56> pitti: what does he mean by faking the dr.konqui accept file?
<kdeuser56> pitti: how would I make that automatic at every crash?
<pitti> kdeuser56: not sure -- I don't know drkonqui or Kubuntu's current crash handling at all, I'm afraid
<jibel> (not really forever but I waited like 10min before hard rebooting the machines)
<kdeuser56> pitti: yeah, but why is there not way to always invoke apport?
<pitti> jibel: hmm; can you still switch VTs at that time? maybe there's some error on VT8 or so
<kdeuser56> pitti: does apport simply not detect the crash when drkonqi is invoked?
<pitti> kdeuser56: as apachelogger wrote, it was designed like that
<jibel> pitti, it happens on every shutdown/reboot. I can switch VTs but there is no error
<kdeuser56> pitti: apport or dr.konqi?
<pitti> kdeuser56: yes, if KDE programs themselves intercept the SIGSEGV, then it doesn't go to the kernel and thus apport
<pitti> jibel: hmm, I'm afraid I have no idea at that point :/ perhaps jodh has some trick up his sleeve to make upstart more verbose on the console
<kdeuser56> pitti: oh, that means dr konqi would need to be patched if I wanted that behavior ...
<jibel> pitti, okay, thanks. I'll ask when he is online.
<pitti> kdeuser56: I suppose it's too late in drkonqui; the signal needs to be re-raised after invoking the KDE crash handler and deciding that you also want apport (or a proper core dump)
<apachelogger> class KCrash in kde4libs is the thing that needed patching
<kdeuser56> apachelogger: oh damn, since I think I can't patch that myself, can I workaround that issue with a shell script being invoked?
<kdeuser56> apachelogger: could you explain me how you meant the dr.konqui.accept trick?
<apachelogger> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdelibs/view/head:/debian/patches/kubuntu_raise_after_drkonqi.patch
<apachelogger> our KCrash will raise the signal to the kernel iff a drkonqi-accept file is present
<apachelogger> +    sprintf(filePath, "/var/crash/%s.%d.drkonqi-accept", buf, uid);
<apachelogger> buf being the url of the binary that crashed with / exchanged for _ and uid is, well, the user id
<apachelogger> so what you could do is write a wrapper script around drkonqi that always creates this file
<kdeuser56> apachelogger: ah damn, now I see another problem: I have my custom patched version of apport, where I changed the file format to include a date
<pitti> I hope just the date, not the time
<kdeuser56> pitti: I included hours, thats restrictive enough for me
<apachelogger> in the file name?
<kdeuser56> apachelogger: yeah, otherwise apport would overwrite existing crash reports of the same application
<pitti> only if you already saw the previous one
<kdeuser56> pitti: what do you mean by "saw"?
<kdeuser56> retraced?
<pitti> well, if you got an apport window which told you about the crash and let you decide whether to report it
<pitti> it won't overwrite "unseen" crashes, just increase the "CrashCounter" to avoid flooding with repetitive crashes
<pitti> to limit to 3 crashes per executable and day
<kdeuser56> pitti: ah okay, thats too often the case for me, so I prefer my time patch
<kdeuser56> (that I get the windows, or a cron scripts autoretraces stuff for me)
<kdeuser56> pitti: why does apport-retrace never modify the original file? why do I have to print to stdout or to another file?
<pitti> kdeuser56: you can tell it to update the original file;  in fact, that's the default
<pitti> -s â stdout, -o â other file, -g â gdb session; none of those: update original file
<kdeuser56> pitti: i am afraid it never does for me .... it always tells me to use either s, o or g
<pitti> hm, that could be fallout from a bug fix last week
<pitti> but it at least had worked before
<kdeuser56> pitti: when was before?
<pitti> like, until two weeks (or so) ago
<pitti> anyway, bug report appreciated
<kdeuser56> pitti: are you sure? I can't confirm that
<pitti> should be simple to fix
<kdeuser56> pitti: okay I will investigate and when I am sure it does not work, I'll report a bug, but I am already pretty sure
<kdeuser56> apachelogger: does the diff you linked also apply to the frameworks version?
<kdeuser56> apachelogger: deleting lines 26-30 and 36-38 should do what I want, right?
<apachelogger> kdeuser56: it's not ported to frameworks but generally yes
<kdeuser56> apachelogger: does the yes also apply to the line deleting in the diff?
<kdeuser56> apachelogger: I mean sure the class name "possiblyRaiseForApport" would not make sense any more then for me, but that should not hurt
<apachelogger> dunno
<apachelogger> you really could just replace possiblyRaise with raise(sig)
<kdeuser56> apachelogger: you mean in KCrash::setCrashHandler?
<kdeuser56> apachelogger: what does the "KCrash::setCrashHandler(0);" do then?
<apachelogger> prevents it from looking in on itself
<kdeuser56> apachelogger: so it makes sense to set it before raise(sig), right?
<apachelogger> yeah
<kdeuser56> apachelogger: so what I am expected to get then is both, dr. konqui and apport, right?
<kdeuser56> pitti, apachelogger: thanks for your great help, I'll try it!
 * Mirv hugs pitti for pygobject (virt-manager)
<pitti> Mirv: heh, no worries :)
<pitti> I broke it, I fix it
<pitti> Mirv: ah, you use virt-manager?
<Mirv> pitti: yes nowadays. I felt so outdated on ordinary manually qemu + vnc, that I finally installed it and also started using SPICE. now the lxc folks tell me I'm still totally outdated :(
<pitti> Mirv: ah, I always just use qemu from the command line; I didn't quite like all the extra overhead and daemons of virt-manager; but I suppose it's quite a bit easier to use?
<pitti> Mirv: (FAOD, not saying that virt-manager is bad, I just don't know many people who use it)
<Mirv> pitti: well the same I wasn't sure what benefit setting it up would be, but now running VM:s on remote machine works pretty nice anyhow
<pitti> Mirv: yeah, I guess it's quite a bit better for someone like a server hoster where you have permanent VMs and need to manage them
<Mirv> I think I just saw xnox using it a long time ago or something, and it seemed cool
<pitti> I only have temporary ones or boot images for testing
<Mirv> right. I've permanent 14.04 LTS and Debian VM:s on another machine.
<Mirv> QXL/Spice don't make Mesa+LLVM Unity 7 fast, though, but it's usable
<pitti> Mirv: ah, and now you want to move most of them to LXC containers? :-)
<Mirv> pitti: probably I should do that, yes :)
<pitti> Mirv: depends on what you want to do; for the most part, containers are faster and nicer, but you can't test different kernels or do low-level stuff (graphics etc.) with them
<Mirv> yes, I'd probably want to be able to pass the GPU to the VM eventually too, since I eg. test Qt and others which are nicer with accelerated 3D
<Mirv> not sure thouh which year that's coming to qemu/gallium3d, but probably eventually
<pitti> Mirv: testing newer Qt is easier with schroot or LXC
<pitti> Mirv: as they use the same kernel/hardware as the host; testing fixed kernel drives also doesn't make much sense in QEMU; so it sounds like indeed you want containers or schroots
<apachelogger> (if you manage to setup networking for LXC that is :P)
<pitti> apachelogger: err -- there's exactly zero work involved in that
<apachelogger> pitti: that's improvement then. I tried to replace our neon build infrastructure schroots with LXC in feburary and networking was not working at all ;)
<pitti> odd, that has worked for ages
<mlankhorst> doko__: odd, I do not get the LLVM failure here..
<mlankhorst> maybe it's cpu specific code triggering?
<doko> mlankhorst, welcome to debugging jits generating code for different processors :-P
<mlankhorst> hah
<mlankhorst> can I 'downgrade' the code generation?
<Mirv> pitti: as a baby step I installed lxc on that remote machine and I can now connect to that too via virt-manager.
<pitti> Mirv: hah, cool!
<mlankhorst> oh colored dmesg.. my eyes..
<mlankhorst> ok my crap system can reproduce that error:-)
<Mirv> any core-dev around to ack CI Train debian/ changes? this time libaccounts-glib/qt + online accounts. the three links containing the diffs are at https://ci-train.ubuntu.com/job/ubuntu-landing-015-2-publish/ - two are just version bump changes.
<Mirv> and even the libaccounts-glib just adds one file to be installed
<pitti> Mirv: LGTM, ack
<Mirv> this is the official "thank pitti" day
<mlankhorst> doko: found a testcase
<mlankhorst> piglit with DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 bin/ext_transform_feedback-change-size  range-shrink
<mlankhorst> hm, works with more recent mesa..
<mlankhorst> I'll do a full test to be sure..
<mlankhorst> ok ubuntu-ui-toolkit doesn't seem to fail either..
<mlankhorst> doko: well if I file a FFe for mesa 10.3 I should be able to enable llvm, pending the remaining piglit tests
<cjwatson> YokoZar: I don't know, haven't investigated.  If you want to take responsibility for it don't let me stop you :)  (My Ubuntu change can certainly be synced over now)
<cjwatson> doko: thanks for working on the perl transition; FYI I'm working on libguestfs, it's requiring me to fix up gfs2-utils first
<doko> cjwatson, ahh, I have a libguestfs package
<doko> dropped the libguestfs-gfs2 b-d
<cjwatson> doko: shouldn't be necessary
<cjwatson> I almost have gfs2-utils fixed ...
<doko> cjwatson, what do you propose about the unreadable kernel images?
<cjwatson> doko: that isn't what's blocking it, is it?
<doko> cjwatson, fails later trying to run the tests. disabled for now.
<cjwatson> roaksoax: so Fedora gfs2-utils has dropped the init script entirely, which is broken at the moment because it requires cman in order to start.  Do you think I could just drop that init script from Ubuntu too and rely on mounting being done in other ways?
<roaksoax> cjwatson: +1
<cjwatson> doko: there appears to be a SKIP_TEST_SYSLINUX_PL environment variable available, at least
<cjwatson> hm, maybe it's not that test
<doko> cjwatson, http://people.canonical.com/~doko/tmp/libguestfs.debdiff
<doko> still with the gfs2 disabled
<roaksoax> cjwatson: if they have dropped it, then it would be good for us to do it. Although, are we looking to merge a new version from Debian? Has Fedora dropped it in the same version we have?
<cjwatson> build-depending on grub2?!
<cjwatson> roaksoax: there's no new version from Debian to mereg
<cjwatson> *merge
<doko> that was already in Debian
<cjwatson> still evil :)  should probably be grub-something-bin
<roaksoax> cjwatson: ok. Yeah we should definitely not need cman as a dependency for the initi script, so I think it is safe to drop it
<cjwatson> build-depending on grub2 installs something that will own the system's boot sector
<cjwatson> doko: so if I fix gfs2-utils can you try restoring libguestfs-gfs2?
<doko> sure
<doko> cjwatson, but I'm afk again, so I'll leave the packages on p.c.c
<cjwatson> roaksoax: I guess the alternative is dropping cman and gfs_controld from Required-{Start,Stop} in the init script rather than dropping the whole thing, but I don't know enough about gfs2
<roaksoax> cjwatson: I'll investigate and take care of it. Thanks for point it out!
<cjwatson> roaksoax: Cool, thanks.  Could you start with http://paste.ubuntu.com/8140684/ ?
<mlankhorst> doko: I can't reproduce the crasher with llvm 3.5 and mesa 10.3-rc1, I will try to upload mesa 10.3 before flipping the switch..
<doko> \o/
<roaksoax> cjwatson: will do! thank you!
<mlankhorst> I've ran over half the mesa tests now, and tried the ubuntu-ui-toolkit tests on it
<mlankhorst> both had failures before
<doko> cjwatson, how is your ocaml foo? http://launchpadlibrarian.net/183130799/supermin_5.1.9-1ubuntu1_5.1.9-1ubuntu2.diff.gz  this might require a proper fix in src/kernel.ml
<kdeuser56> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1361242
<ubottu> Launchpad bug 1361242 in apport (Ubuntu) "apport-retrace does not modify the original report as expected with no option specified" [Undecided,New]
<pitti> kdeuser56: thanks
<kdeuser56> is noninteractive boot option still recommended for preseeding?
<hallyn> doko: hi - slof is failing to build in utopic-proposed.  When I build it in a trusty container (using older gcc-defaults-powerpc-cross) it builds fine.  that package (gcc-defaults-powerpc-cross) is a bit of an enigma :)
<doko> hallyn, -> porter-powerpc.canonical.com preprocessed source, and how it is called. the build log may please your eyes, but it doesn't help anybody else
<hallyn> not sure how to parse that.  where on porter-powerpc.canonical.com is it?  I was thinking i'd try building 4.9.2 of gcc-defaults-powerpc-cross
<hallyn> on porter-powerpc.canonical.com am i supposed to use schroot?  (no dchroot htere)
<hallyn> hm, 4.9.2 was mentioned in email ubt don't see it avail
<shadeslayer> anyone know how the autologin setup happens in ubiquity?
<hallyn> doko: hm, I see that porter-powerpc.c.c:/home/doko/gcc/log shows segvs as well
<hallyn> guess that's 100% unrelated
<lullis> Hey guys... I have a quick question regarding how to register new indicators to be displayed on the panel from either unity-greeter or gtk-greeter.
<lullis> I see that the conf files from the greeters have an entry to list which indicators to be active, but how do I add a new one? I was trying to find for .desktop files, but nothing showed up.
<hallyn> doko: shnickities porter-powerpc.canonical.com has the exact same behavior - utopic fails, trusty builds
<hallyn> maybe it's a core gcc bug
<marvin-hh> Why doesn't AppArmor work after installation for Firefox? Alternatively, why is /bin/kmod executed by firefox?
<sarnold> marvin-hh: on-demand loading of a network protocol is most likely; did you compile your kernel with ipv6 support as a module?
<marvin-hh> sarnold: I am using -generic.
<sarnold> marvin-hh: hunh. can you paste your DENIED line?
<gatox> hi, i'm having issues to be able to cross-build ubuntu-system-settings for arm.. could anyone help me?? this is what is happening: http://paste.ubuntu.com/8140373/
<Laney> gatox: it's busted since we added the qt dbus mock thing
<marvin-hh> sarnold: http://paste.kde.org/pxpqrbpse/kogntk
<seb128> Laney, :-(
<gatox> Laney, ahhhhh.... any other way to do it?? i'm not being able to build it on the phone because installing only de u-s-s dependencies i run out of space
<marvin-hh> sarnold: why would on demand loading of modules in -generic be any reason at all for apparmor complaining?
<marvin-hh> sarnold: I mean: this is not something which should ever have ended up in a release.
<Laney> gatox: porter machine or a PPA which builds arm
<sarnold> marvin-hh: there's a reason why the firefox profile isn't turned on by default :)
<Laney> btw AFAICS it comes down to this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755874 which is something I want to work on
<ubottu> Debian bug 755874 in gobject-introspection "gobject-introspection: [patch] use multi-arch pathes for the .typelib files" [Wishlist,Open]
<sarnold> marvin-hh: maybe firefox is trying to load some kernel modules for ati-based glx or gle or similar? could be you're the first to use our firefox profile with an ATI video card
<marvin-hh> sarnold: in that case, I would like to disable the profile.
<sarnold> marvin-hh: aa-disable /usr/bin/firefox  ought to do it
<marvin-hh> sarnold: after an upgrade it was on.
<marvin-hh> sarnold: Profile for /usr/lib/firefox/firefox.sh not found, skipping
<marvin-hh> sarnold: in short, that didn't work.
<sarnold> marvin-hh: hrm, try aa-disable /etc/apparmor.d/usr.bin.firefox   ?
<sarnold> (I can't recall if it happily takes paths right to profiles or not..)
<marvin-hh> sarnold: that seems to have worked.
<sarnold> marvin-hh: nice
<marvin-hh> sarnold: I don't understand how it was ever enabled otherwise.
<sarnold> marvin-hh: me neither.
<marvin-hh> sarnold: are you sure that upgrading from 12.04 to 14.04.1 cannot magically enable it?
<sarnold> marvin-hh: it really should take some effort to turn on firefox..
<marvin-hh> sarnold: it's not important now. Perhaps I turned it on a long time ago and am I only getting the messages in my face now.
<sarnold> marvin-hh: could be that newer X drivers supported features that older releases didn't.. (I'm still guessing it was ATI drivers, though the evidence is pretty circumstantial)
<sarnold> marvin-hh: if you want to investigate some time, try lsmod before running firefox, run firefox, visit whatever website kicked this off, then re-check loaded modules
<sarnold> see what's new
<cjwatson> doko: really pretty minimal, I'm afraid
<doko> cjwatson, ?
<cjwatson> doko: you asked how my ocaml knowledge was
<cjwatson> I don't have much :)
<cjwatson> ML classes from 15 years ago at university
<doko> hallyn, sure, I'll look at it next week. won't get to it before without command line parameters and preprocessed source
<doko> cjwatson, ahh, the supermin thing. yep, they do some string matching in src/kernel.ml, but I don't understand it :-/
<Janusz> Hello. I don't want to code today, but need a good lecture to be better in Linux developing. What could You recommend?
<marvin-hh> Janusz: there is no point in learning details about Linux unless you are optimizing something specially for Linux (which is still a bad idea, unless you are working for a >10B USD company).
<marvin-hh> Janusz: and in that particular case, you wouldn't be asking this.
<marvin-hh> Janusz: just learn the fundamentals.
<Janusz> marvin-hh: Like?
<marvin-hh> Janusz: like the top 5 of books on algorithms on Amazon.
<marvin-hh> Janusz: don't waste your time on 'agile' methods.
<marvin-hh> Janusz:
<marvin-hh> Janusz: you can better also not waste your time with Ubuntu.
<marvin-hh> Janusz: Ubuntu only tolerates newbies.
<marvin-hh> Janusz: Ubuntu's only goal is to make you dependent on their corporate support once you start using it for anything important.
<marvin-hh> Janusz: Ubuntu is not designed to last.
<Janusz> Thank You.
<Kangarooo> how to subscribe to wiki pages? i just want to know is there some place where i can remoe my subscritions? Somehow im subscribed to every wiki page and i want it to stop
<rww> Kangarooo: log in to wiki.ubuntu.com, then go to https://wiki.ubuntu.com/Home?action=userprefs&sub=notification
<Kangarooo> rww: there everything is empty
<Kangarooo> rww: but still i get the emails
<rww> Kangarooo: the "subscribed wiki pages" box is empty?
<Kangarooo> rww: yes
<rww> Do you have any other wiki accounts somehow? (multiple email addresses forwarding over, etc.)?
<Kangarooo> rww: nope
<rww> and they're notifications for wiki.ubuntu.com and not help.ubuntu.com/community ?
 * rww just remembered that both of those exist...
<Kangarooo> rww: theres empty but was ticked some checkboxes on. i removed them.
<Kangarooo> emails still comming
<hallyn> doko: ok, thanks, i don't think there is a rush, but i can point you to exact commands and source in a bit  - thx
<Kangarooo> rww: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1361361
<ubottu> Launchpad bug 1361361 in ubuntu-docs (Ubuntu) "Receiving all Wiki.Ubuntu.com changes bulk mail for 7 years." [Undecided,New]
<roaksoax> cjwatson: http://paste.ubuntu.com/8143984/
<roaksoax> cjwatson: seems that it is safe to remove the init script
<cjwatson> roaksoax: Cool, please do.  Do we need a debian/gfs2-utils.maintscript or something to do rm_conffile?
<cjwatson> (Not sure how that interacts with the other init script stuff, e.g. if you need to imitate /usr/share/debhelper/autoscripts/postrm-init
<cjwatson> )
<roaksoax> cjwatson: I'll look into that!
<roaksoax> cjwatson: and yeah I do not think we need postrm-init logic, as there really no daemon that we are running. The init script was just looking at /etc/fstab to mount/unmount
<roaksoax> cjwatson: but I don't think it would hurt adding it
<cjwatson> ok, whatever's easiest then
<cjwatson> I don't really know gfs2 at all :)
<roaksoax> cjwatson: ok.. this does it... http://paste.ubuntu.com/8144463/ I'll upload
<cjwatson> roaksoax: rock, thanks
<JasonBourne> Hello
#ubuntu-devel 2014-08-26
<pitti> Good morning
<dholbach> good morning
<mlankhorst> morning
<Tribaal> hi all. Quick question -sorry if it's the wrong place to ask, but how can I add my "pin" to the ubuntu memebers map shown on https://wiki.ubuntu.com/Membership (I'm a recent Ubuntu member)
<ogra_> urgh, what added all the GL deps to the touch image ??
<darkxst> Tribaal, many ubuntu members seem to live in the ocean according to that map!
<Tribaal> darkxst: yes, yes, privacy, I know. But I'd like to add mine nonetheless :)
<Tribaal> darkxst: I'm one of the very few Ubuntu members living in Africa - I might as well send the message that we're around :)
<darkxst> Tribaal, there may be better ways to do that than a broken map ;)
<TJ-> Is there a way to force apt to ignore Conflicts|Replaces in order to keep 2 packages installed simultaneously?
<darkxst> TJ Conflicts are not arbitrary, they are there for a reason
<TJ-> darkxst: I know; and in my case the reason is in the way of work. Currently I use a script to manually fix-up the package lists and dpkg status, but I'd rather do it through an apt configuration option
<darkxst> TJ-, if you want help breaking your system, there are probably better channels than this!
<darkxst> TJ-, this channel is really for ubuntu development
<ogra_> Laney, can we drop the x86 build deps on armhf for https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.4.0-1ubuntu1 ? ... it results in http://people.canonical.com/~ogra/touch-image-stats/208.changes
<ogra_> Laney, referring to "- Build-depend on libgl1-mesa-dev and libglu1-mesa-dev."
<TJ-> darkxst: Which is what I am doing
<ogra_> seb128, is Laney at debconf this week ?
<seb128> ogra_, yes
<darkxst> TJ-, ignoring conflicts is a bad idea!
<ogra_> damned
<ogra_> k, thanks
<seb128> yw!
<TJ-> darkxst: Having the option to do so is a good idea. I hoped there'd be  a pre-existing configuration item that is hidden away, but if not, I'll patch apt to have one
<darkxst> TJ-, sure go ahead, but you are playing with fire!
<TJ-> darkxst: Fire is fine, I know what I'm doing, I just want to avoid having to run a hook-script. My case is developing GRUB, and needing grub-pc and grub-efi installed alongside each other
<Mirv> if a core-dev _or_ MOTU (in this case) would be available for reviewing/acking packaging changes for a CI Train upload, please see https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/14/
<Mirv> ok sil2100 is back so he'll check that out
 * sil2100 is in meeting spree
<sil2100> But yeah, I have a moment now :)
<sergiusens> pitti: any idea how to solve this? http://paste.ubuntu.com/8149970/
<sergiusens> it's a chroot
<ogra_> do we now always need policy-rc.d mangling ?
<jamin> has anyone successfully used the text based oem-config in 14.04?
<ogra_> probably someone in #ubuntu-server
<ogra_> (sounds more like the place where you would use it)
<jamin> https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1361595
<ubottu> Launchpad bug 1361595 in oem-config (Ubuntu) "OSError: [Errno 25] Inappropriate ioctl for device" [Undecided,New]
<jamin> I don't think it's possible
<pitti> sergiusens: yes, it's bug 1320534
<ubottu> bug 1320534 in systemd (Debian) "missing /run/shm backwards compat symlink" [Unknown,New] https://launchpad.net/bugs/1320534
<pitti> sergiusens: I did the merge with Debian a month or so ago, but it's blocked on reviewing
<pitti> sergiusens: I guess I could try and upload that in isolation though
<pitti> I already cherry-picked some other bug fixes this morning
<pitti> sergiusens: the update-rc.d warning should be fixed with this morning's sysvinit, I suppose you didn't get that yet?
<ogra_> we didnt have an image build yet
<ogra_> (so he wont)
<pitti> oh, I thought that was from some local/recent deboostrap run
<pitti> err, apt-get install, I mean
<pitti> (see first line)
<pitti> probably missing a dist-upgrade in his schroot
<ogra_> ah, right
<ogra_> (sorry, didnt mean to rip that out of context)
<sergiusens> pitti: yeah
<sergiusens> pitti: wrt ogra_'s comment, it's related to not being able to dpkg -i from a chroot in our recovery image
<Riddell> seb128: do we have the Adwaita gtk theme in utopic?
<seb128> Riddell, it's default since GNOME3, so we have it since precise or something
<seb128> not sure to understand the question
<Riddell> seb128: hmm I'm still seeing the ugly default theme for evince and the gtk-selector in kde doesn't list adwaita
<seb128> Riddell, do you have gnome-themes-standard installed?
 * Riddell installs
<Riddell> seb128: ah yes that does it, thanks
<seb128> Riddell, yw
<pitti> sergiusens: I couldn't reproduce it with my schroots, but xnox got it somehow; where did you see that exactly?
<pitti> sergiusens: reproduction steps would be appreciated in that bug, so I could verify the fix
<sergiusens> pitti: ah, it's a complicated chroot created with crouton for the chromebook
<sergiusens> it's my armhf builder
<pitti> sergiusens: if you have an easy way to check, could you upgrade to the binaries in http://people.canonical.com/~pitti/tmp/sysvinit-merge/ ?
<pitti> sergiusens: it has amd64 and armhf
<sergiusens> pitti: yeah, I can check
<sergiusens> pitti: it gets a bit further, no it doesn't start with invoke.rc.d: initscript ssh, action "start" failed
<sergiusens> pitti: ah, it's the same error
<sergiusens> pitti: this is crouton btw https://github.com/dnschneid/crouton
<pitti> sergiusens: ah, no idea about /var/run/utmp; that might just not work in a chroot; the bug above is about a missing /run/shm/
<sergiusens> pitti: yeah, I manually created the dir and the complaints ended for utmp
<pitti> -rw-rw-r-- 1 root utmp 0 May  7  2013 /run/utmp
<pitti> sergiusens: I have that in my sid chroot
<pitti> sergiusens: and /var/run is a symlink to /run
<pitti> same in utopic
<pitti> sergiusens: so mabe your case isn't about /run/shm/ at all then, and xnox' situation was different
<sergiusens> so it's not that bug :-)
<pitti> sergiusens: for building a chroot you probably want a policy-rc.d?
<sergiusens> pitti: I don't know how that chroot is built; I just use it; but if you say so, I'll look into it
<pitti> sergiusens: which of the two is missing OOI, /var/run symlink, or /run/utmp ?
<sergiusens> pitti: /var/run is not a symlink here
<sergiusens> that may be it
<sergiusens> nah, ls'ed wrong; it's a link to /run
<sergiusens> pitti: /run/utmp is missing though
<pitti> sergiusens: not sure what creates that; perhaps debootstrap itself
<pitti> ah no, apparenlty base-files:
<pitti> base-files.postinst:  if [ ! -f /var/run/utmp ]; then
<pitti> base-files.postinst:    echo -n>/var/run/utmp
<pitti> so perhaps that didn't get configured properly in your schroot?
 * pitti -> bbiab
<caribou> Is it acceptable to have two names listed in the Maintainer field of a package ?
<pitti> caribou: yes, with comma separation as usual
<pitti> caribou: ah sorry, no
<pitti> caribou: that'd be Uploaders:
<pitti> caribou: not that it matters at all in Ubuntu; ubuntu specific packages should usually be owned by Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<caribou> pitti: thanks, that's for a Debian package
<pitti> caribou: so put the primary dev or a team (pkg-*@alioth ML or so) into Maintainer:, and the others into Uploaders:
<caribou> pitti: good idea, thanks for the quick answer
<tedg> stgraber, talking to hallyn he thought that you had the race nailed down.
<stgraber> tedg: oh right, sorry, blurry memory and all. So I think we figured that the race was lightdm spawning the user session before cgmanager was actually started.
<stgraber> tedg: in a perfect world we'd be able to get systemd-shim to depend on cgmanager but since that one is dbus activated, that's not quite possible
<stgraber> tedg: so an ugly way to avoid the race would be to override the dbus start condition to be whatever start condition it currently has + cgmanager-ready
<tedg> stgraber, Does it make sense to start lightdm before cgmanager in general? Or it just works because we're not using cgroups in any system jobs?
<pitti> stgraber, hallyn: could we alternatively make cgmanager dbus activatable?
<hallyn> tedg: the problem is that not everyone running lightdm will have cgmanager installed
<stgraber> pitti: no we can't
<stgraber> pitti: cgmanager doesn't listen on the system bus
<pitti> ah right, ignore me :)
<tedg> hallyn, cgmanager could be start on starting dbus ?
<hallyn> dbus isn't always installed
<tedg> "That's crazy!" says the client guy
<stgraber> tedg: jodh suggested that but that's plain wrong since cgmanager doesn't need the dbus daemon :)
<hallyn> cgmanager does start as early as possible 9afaik)
<tedg> stgraber, Well, it doesn't need it, but it should start before it.
<stgraber> tedg: sure, but there's no way to describe "if service X is around, then wait for it" in upstart jobs :)
<hallyn> i suppose we could have a essentials upstart job that emits "cgmanager-not-needed", which gets overridden by cgmangaer
<stgraber> otherwise the right thing to do would be to have dbus.conf wait until cgmanager is ready if cgmanager is installed
<stgraber> hallyn: that seems rather ugly :)
<hallyn> i thought it elegant :)
<stgraber> if we want a blocking behavior (and we said that maybe we don't want that to avoid hanging the whole system when something goes wrong), systemd-shim ought to be the one blocking requests until the cgmanager socket is available
<tedg> I guess I'm kinda surprised that cgmanager startup is the problem. *a lot* has to start before we run applications, do we know why cgmanager is taking so long?
<hallyn> tedg: oh, it's bc yo uneed the cgproxy i think
<hallyn> if yo uhad a newer kernel yo uwouldn't have this issue
<hallyn> so you run cgproxy, start cgmanager, then run a new cgproxy that talks dbus to cgmanager. then you're finally ready
<tedg> Can we make the session upstart startup block on cgmanager being ready?
<tedg> I think we get an event for that no?
<stgraber> no
<stgraber> you need to block before you switch to the phablet user
<stgraber> cgmanager needs to be started before logind sets up your user session
<tedg> Oh
<tedg> How about having systemd-login dbus activate a shell script that blocks until cgmanager is ready?
<stgraber> if we are going in that direction, I'd rather we just make systemd-shim itself wait for cgmanager, no point in using a wrapper when we can have the real thing do it properly
<stgraber> the obvious problem with that and the reason why it wasn't done that way to begin with is that if cgmanager fails to start, then you won't be able to login
<hallyn> well it could have a sane timeout, 10s
<hallyn> and a config file to override
<popey> Why is mencoder not in utopic? http://packages.ubuntu.com/search?keywords=mencoder
<ogra_> popey, probably fallout of the libav transition
<popey> oh ugh
<ogra_> (just guessing)
<tedg> stgraber, So that works for me, is that something you're going to work on a patch for?
<LocutusOfBorg1> sil2100, please remove lucene++ from mentors
<LocutusOfBorg1> :)
<LocutusOfBorg1> it has been uploaded
<stgraber> tedg: I haven't done any work on systemd-shim, so that's more a pitti or hallyn question
<hallyn> really a q for desrt|pdx - if he's ok with it
<pitti> tedg, hallyn, stgraber: what's so wrong about having lightdm start ".. and started cgmanager"?
<pitti> under upstart we always need it now anyway, and under systemd the upstart job won't be used
<hallyn> on the phablet, probably nothing
<tedg> hallyn, Are you suggesting an override on the phablet then?
<hallyn> tedg: i was, but maybe pitt's right and we can just do it everywhere
<tedg> We'd then need to add a dependency in the binary package, no?
<ogra_> tedg, how much boot time will that cost us ?
<tedg> ogra_, Not sure, perhaps hallyn knows. It should be the same amount of tasks, just change ordering slightly.
<tedg> Depends if it creates a bubble in the boot chart.
<ogra_> it does today
<tedg> What does? CGManager?
<ogra_> (well, i didnt do charts for a while, but cgmanager definitely has its own PID and shows up)
<ogra_> everything with a PID has a bootchart entry
<tedg> Sure, I'm more saying if it blocks things so that CPU/IO isn't used. Overall we should use the same amount of CPU/IO, just ordering could change.
<ogra_> ok
<pitti> ogra_, tedg: well, considering that lightdm starting before cgmanager is currently broken, and it just happens to work most of the time, it hardly is a boot time problem at all?
<tedg> Honestly, from the UTAH testing it gets the right order 95% of the time anyway :-)
<ogra_> tedg, the utah bootchart testing is totally wrong and broken
<ogra_> better use phablet-bootchart locally
<ogra_> (they test on a device that has a ton of test stuff installed before creating the chart)
<tedg> ogra_, I mean the autopilot testing, where we start to see failures when turning on cgroups.
<ogra_> ah
<ogra_> pitti, how does that breakage manifest ?
<tedg> ogra_, Intermittent failures of application startup. They can't create the Upstart jobs for the apps.
<ogra_> lightdm depends on the container being started
<ogra_> and the container depends on cgmanager being started
<sil2100> LocutusOfBorg1: \o/ Thanks!
<pitti> I don't know, I haven't seen it myself; I was just catching on to the discussion here that lightdm needs cgmanager so that it can create cgroups for the user sessions (and its own session)
<ogra_> right, but so does lxc
<sil2100> LocutusOfBorg1: I'm somehow sooo busy recently that I need to find a free time jiffy to do that
<ogra_> and lxc comes far before lightdm in the boot process
<tedg> Hmm, that's interesting. Wonder how cgmanager isn't started.
<ogra_> does cgmanager have semi-ready states it announces via upstart or some such ?
<tedg> Perhaps then it's the cgproxy stuff that's confusing Upstart?
<ogra_> hmm, could be
<hallyn> yes both will send the cgmanage-rready event
<tedg> hallyn, But it seems that cgproxy sends it in pre-start instead of post-start?
<tedg> Oh, wait, both.
<hallyn> yeah, the cgproxy one isn't right
<hallyn> i forget, who wrote that bit?
<ogra_> so you would actually have to wait for cgproxy, not cgmanager
<tedg> Heh, it seems like you should tell Upstart that you exist before everything is signaled ready.
<tedg> ogra_, Seems we should be waiting on cgmanager-ready
<ogra_> well, which is essentially the same, but yeah :)
<hallyn> ogra_: right, cgmanager upstart job shoul dkeep state to know that it started cgproxy and then not send the ready signal
<hallyn> i think jodh wrote those bits, hm
<tedg> ogra_, the lxc-android-config job is waiting on that event.
<ogra_> phablet@ubuntu-phablet:~$ grep cgmanager /etc/init/lxc-android-config.conf
<ogra_> start on cgmanager-ready
<ogra_> phablet@ubuntu-phablet:~$ grep android /etc/init/lightdm.override
<ogra_>            and android)
<ogra_> phablet@ubuntu-phablet:~$
<ogra_> tedg, right and lightdm is waiting for the android event thats fired after the container is 100% up
<hallyn> so who knows where an upstart job could keep that state?  use /var/run?
<hallyn> hm, so you're saying this race isn't really possible bc the container wouldn't start?
<ogra_> tedg, so you should actually already have a big delay between your session and cgmanager
<ogra_> right
<tedg> Hmm, stgraber how were you guys seeing the race?
<ogra_> container wiats for cgmanager-ready and then emits android once the container is ready
<ogra_> and lightdm starts on android
<stgraber> tedg: I never saw the race, we did the debugging solely based on feedback from jodh
<hallyn> it's still possible,
<tedg> stgraber, Do you know what behavior he was looking for to conclude that?
<stgraber> tedg: he made cgmanager start on dbus and that solved it for him which suggested some race between something dbus related and cgmanager, with the obvious candidate being shim+logind
<tedg> So could logind be started before cgmanager-ready by something else?
<tedg> Would it handle cgmanager starting after it already started?
<ogra_> Laney, poke
<pitti> stgraber, tedg: oh, indeed -- appending "or starting dbus" sounds like a nice (and mostly correct) way for cgmanager.conf's start condition, and doesn't introduce new dependencies
<Laney> hi ogra, will look later on
<pitti> and will sort itself before dbus
 * ogra_ hugs Laney 
<tedg> pitti, Apparent hallyn was saying that there are systems with cgmanager but not dbus.
<ogra_> Laney, thanks, just wanted to make sure the ping didnt get lost :)
<pitti> tedg: that's totally fine -- it's an "or" condition
<Laney> nope
<pitti> tedg: that more or less just says "if dbus is there, start it after cgmanager"
<hallyn> right now cgmanager starts on mounted /sys/fs/cgroup or virtual-filesystems
<hallyn> that really should beat dbus
<hallyn> unless mounted /sys/fs/cgroup never happens bc it's mounted in initramfs?
<hallyn> so yeah that sounds fine
<pitti> start on local-filesystems
<ogra_> <ou would notice that on the phone ...
<pitti> that's dbus, so also very early on
<ogra_> the container fully depends on cgmanager-ready
<pitti> local-filessystems is almost always satisfied right after initramfs, if you don't have any extra /usr or similar mounts
<ogra_> without container, no graphics ...
<ogra_> (or lightdm ... or session)
<tedg> K, so hallyn is that a patch you can make/upload?
<hallyn> tedg: stgraber: pitti:  http://paste.ubuntu.com/8151670/ ook ok?
<hallyn> oh is there a bug# for this?
<hallyn> i'll use 1357252
<pitti> hallyn: LGTM (but please give it a boot test; I'm not exactly an upstart expert)
<tedg> hallyn, +1, yeah bug 1357252
<ubottu> bug 1357252 in cgmanager (Ubuntu) "systemd-shim fails to handle cgmanager being unavailable" [Undecided,Confirmed] https://launchpad.net/bugs/1357252
<pitti> right, I think that's the one jodh pointed me to
<hallyn> (building )
<pitti> hallyn: applied that here, rebooting
<hallyn> shared-mime-info triggers be slow
<cjwatson> TJ-: There's no good reason to install grub-pc and grub-efi alongside each other (speaking as a GRUB developer).  The *-bin packages exist so that you can coinstall them and use grub-mkimage etc.  The only purpose of the -bin-less names is to own the system's boot process, and only one package should do that.
<pitti> hallyn: seems happy enough here (amd64 utopic desktop du jour)
<TJ-> cjwatson: So I can remove the non-bin packages without any undo regressions?
<cjwatson> TJ-: I expect you'll want to keep the one you're actually using to boot
<cjwatson> TJ-: But assuming you mean "undue", then yes.  I only have one of those installed.
<TJ-> cjwatson: Using both, that's why I've been using a script to alter the package lists
<cjwatson> But I have both grub-efi-amd64-bin and grub-pc-bin.
<cjwatson> How can you possibly be using both to boot?
<cjwatson> I mean, routinely.
<hallyn> pitti: same here, so pushing
<TJ-> cjwatson: Portable disk; able to boot on either type of firmware
<hallyn> (will have to push to upstream and debian later)
<pitti> hallyn: thanks
<cjwatson> TJ-: You can always arrange to manually run grub-install with whatever special options you need after upgrades.
<tedg> Thanks hallyn!
<cjwatson> TJ-: That will be MUCH easier than messing about with editing package lists.
<hallyn> np, let's hope this actually sorts out the evice
<cjwatson> TJ-: And that's basically all that the surplus non-bin package will be doing for you.
<hallyn> device
<TJ-> cjwatson: Yeah, I was looking at an additional script in /etc/kernel/postinst.d/
<TJ-> cjwatson: Although I've had an enjoyable day learning the internals of apt :)
<flexiondotorg> cjwatson, You might remember that I am working on Ubuntu MATE.
<flexiondotorg> cjwatson, How do I coerce Ubiquity to use Marco as the window manager and the themes I've created for Ubuntu MATE?
<flexiondotorg> cjwatson, Thanks to you and xnox I submitted merge proposals for adding Marco support to Ubiquity.
<flexiondotorg> cjwatson, Which have been accepted and merged for some time now.
<flexiondotorg> cjwatson, I have settings packages that make the appropriate gschema overrides.
<cjwatson> flexiondotorg: I expect that just needs work in ubiquity-dm.  No idea otherwise.
<cjwatson> flexiondotorg: Maybe also in the upstart job file.
<flexiondotorg> cjwatson, I added support to ubiquity-dm. Also merged.
<flexiondotorg> cjwatson, Upstart job?
<cjwatson> flexiondotorg: debian/*.upstart, wherever it is.  (I'm at a conference right now.)
<flexiondotorg> cjwatson, Thanks. That is enough of a pointer.
<cjwatson> Probably debian/ubiquity.ubiquity.upstart.
<cjwatson> But that only really specifies the DM.
<cjwatson> So shouldn't matter here.
<cjwatson> flexiondotorg: What's actually going wrong?
<flexiondotorg> cjwatson, If I select "Try Ubuntu", nothing. Everything is fine.
<flexiondotorg> cjwatson, If I select "Install Ubuntu", then the default them in Ambiance not the themes I've configured using gschema overrides.
<flexiondotorg> cjwatson, Also the live sessions always drags in Metacity which should be required since Marco is now a suitable depend.
<cjwatson> flexiondotorg: I guess that means your overrides are wrong somehow, but I'm afraid I really don't know much about that.
<flexiondotorg> cjwatson, No. The overrides are correct. Sorry to be blunt. I've override mate and gnome.
<cjwatson> flexiondotorg: Do you mean that the live *image* has metacity when it shouldn't?
<flexiondotorg> cjwatson, Yes.
<cjwatson> flexiondotorg: The overrides are your responsibility to debug, I'm afraid.  I'm sorry I can't help.
<cjwatson> flexiondotorg: For the presence of metacity, you probably just need to seed marco.
<flexiondotorg> cjwatson, Also be aware Ubuntu is not being built on Canonical infrastructure right now.
<flexiondotorg> s/Ubuntu/Ubuntu MATE/
<cjwatson> flexiondotorg: I'm well aware, since if it were then I would have set it up.
<flexiondotorg> cjwatson, Come the day I can help setup Ubuntu MATE if you'd like via merge porposals.
<flexiondotorg> cjwatson, I am seeding Marco.
<cjwatson> flexiondotorg: Where is your image build log?
<cjwatson> You're obviously not doing so in the right place :)
<flexiondotorg> cjwatson, I fully prepared to accept I've messed it up somewhere ð
<flexiondotorg> cjwatson, I can make my build logs available a bit later.
 * cjwatson finds the MATE seeds and does a test germinate run
<flexiondotorg> cjwatson, I am seed 'marco' in the live seed.
<flexiondotorg> cjwatson, Which then creates a duplicate in the 'desktop' seed.
<cjwatson> You don't need it in the live seed, and in any case marco isn't in http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.utopic/view/head:/live
<flexiondotorg> cjwatson, So should I leave 'marco' in the 'live' seed and 'desktop' see?
<cjwatson> It's not in the live seed, as far as I can see.
<cjwatson> Unless your seeds are somewhere other than where I'm looking.
<flexiondotorg> cjwatson, You are looking in the right place. marco was in the live and desktop seeds. But I got duplicate warnings so I removed from the desktop seed.
<flexiondotorg> cjwatson, Should I leave marco in both the live and desktop seed?
<cjwatson> But it is not in the live seed there right now.
<cjwatson> It is in the desktop seed, which is where it belongs.
<cjwatson> A test germinate run against your seeds doesn't pull in metacity.
<flexiondotorg> cjwatson, Hence my confusion as to why metacity is in the resulting image and also the default.
<cjwatson> So image builds at least with our code wouldn't pull in metacity, as far as I can see.  I don't know what your code is doing.
<flexiondotorg> cjwatson, OK that sounds encouraging.
<cjwatson> Perhaps you're using a different build process ...
<flexiondotorg> cjwatson, Another issue I can possible chalk up to "if was built officially".
<cjwatson> Is your build code pushed somewhere I can see?
<flexiondotorg> cjwatson, Thanks for you help again. Most appreciated.
<flexiondotorg> cjwatson, Yes. I'll just pushed to current version...
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-iso
<cjwatson> flexiondotorg: You need to drop "LIVE_TASK='ubuntu-live'" from your modified livecd-rootfs in the ubuntu-mate section.  That'll be causing it to pull in the ubuntu-live task, which won't be appropriate for you.
<cjwatson> You're already installing the ubuntu-mate-live metapackage, so the ubuntu-live task is at best redundant and at worst will cause problems like this.
<flexiondotorg> cjwatson, Many thanks. I'll make that change.
<tvoss> mvo, around?
<mvo> tvoss: yes, at a conference so a bit busy, but available
<pitti> stgraber, infinity: I'm uploading calibre 2.0.0 to sid which ports from qt4 to qt5; would you consider that a feature (the UI is actually the same), i. e. needs an FFE?
 * pitti just purged qt4 from his system, yay
<stgraber> pitti: that's a borderline one, I guess just apply for an FFe, I'll confirm it's only depended upon by Edubuntu and then grant you the FFe
<jtaylor> when is trusty unapproved being processed next?
<jtaylor> been 3 weeks now already
<mlankhorst> when you bug sru admins ;-)
<arges> jtaylor: which particular package are you interested in?
<jtaylor> tango
<arges> jtaylor: can you fill in the rest of the SRU template on the bug (regression potential, impact)
<arges> jtaylor: also it may be easier to identify where the patches come from if you use the DEP-3 tag 'Origin'
<jtaylor> I'd have got to ask the debian maintainer about that, he told me when I sponsored but thats long out of my logs ._.
<arges> jtaylor: well its probably ok since the other patchsets seem to be in the same style.
<arges> jtaylor: just let me know when you filled out the rest of teh SRU template on that bug
<kyleN> just did dist-upgrade on utopic and got this:
<kyleN> dpkg: error processing archive /var/cache/apt/archives/unity-schemas_7.3.1+14.10.20140811-0ubuntu1_all.deb (--unpack):
<kyleN>  trying to overwrite '/usr/share/glib-2.0/schemas/org.compiz.unityshell.gschema.xml', which is also in package libunity-core-6.0-9 7.3.0+14.10.20140711-0ubuntu1
<kyleN> workaround?
<seb128> kyleN, try to apt-get -f install it should work
<jtaylor> arges: done
<kyleN> seb128, didn't
<seb128> kyleN, weird, can you paste the log from a -f install?
<kyleN> sure, hang on
<arges> jtaylor: thanks! Ok accepted.
<kyleN> seb128, http://paste.ubuntu.com/8152652/
<seb128> kyleN, try to sudo apt-get install libunity-core-6.0-9
<kyleN> seb128, http://paste.ubuntu.com/8152688/
<seb128> kyleN, try to sudo apt-get install libunity-core-6.0-9 unity-schemas
<kyleN> seb128, http://paste.ubuntu.com/8152695/
<seb128> kyleN, apt-cache policy unity-services
<seb128> kyleN, or try to add unity-services to the install list
<kyleN> seb128, your first suggestion: http://paste.ubuntu.com/8152701/
<kyleN> seb128, your second: http://paste.ubuntu.com/8152704/
<seb128> shrug
<seb128> kyleN, add libunity-protocol-private0 qtdeclarative5-ubuntu-content1 to the list?
<kyleN> seb128, alas: http://paste.ubuntu.com/8152712/
<seb128> kyleN, keep adding the packages in front of the line and see if you manage to unblock it
<seb128> like libunity9 ibunity-dev unity
<seb128> you might get new ones, try iterating
<seb128> did/do you have ppas or weird versions installed?
<kyleN> I seb128 not utopic ppas installed
<seb128> :-/
<seb128> kyleN, adding extra source doesn't help resolving it?
<seb128> source->binaries
<seb128> to the install line
<kyleN> seb128, example command pls?
<seb128> kyleN, well, the install you had, addlibunity9 ibunity-dev unity
<seb128> ups
<seb128> libunity9 libunity-dev unity
<seb128> it might give you extra errors with new package name
<seb128> keep adding those to the install and try again
<seb128> until it gives you one that might work
<kyleN> ok. I'll work on this. thanks for the tips
<seb128> yw
<seb128> well, let me know how it goes
<seb128> try just adding those and pastebin again
<seb128> it's weird that it requires so much forcing though
<seb128> you might try aptitude otherwise, its resolver works better sometimes...
<kyleN> sebs, aptitude to the rescue :)
<kyleN> $ sudo apt-get install -f
<kyleN> Reading package lists... Done
<kyleN> Building dependency tree
<kyleN> Reading state information... Done
<kyleN> The following packages were automatically installed and are no longer required:
<kyleN>   linux-headers-3.15.0-6 linux-headers-3.15.0-6-generic linux-headers-3.16.0-4 linux-headers-3.16.0-4-generic linux-image-3.15.0-6-generic
<kyleN>   linux-image-3.16.0-4-generic linux-image-extra-3.15.0-6-generic linux-image-extra-3.16.0-4-generic
<kyleN> Use 'apt-get autoremove' to remove them.
<kyleN> 0 upgraded, 0 newly installed, 0 to remove and 675 not upgraded.
<kyleN> seb128, ^
<seb128> kyleN, what did aptitude do exactly?
<kyleN> seb128, nver used aptitude before :( . It reported a lot of packages and I used the 'g' option to handle them. they were removed and reinstalled (not sure if they all were reinstalled)
<kyleN> I have the list of pkgs if that interested you (a copy of part of stdout during the operation)
<kyleN> seb128, here are the removals through aptitude: http://paste.ubuntu.com/8152916/
<jtaylor> arges: thanks
<kyleN> seb128, I still have the complete stdout of aptitude here: http://paste.ubuntu.com/8152929/
#ubuntu-devel 2014-08-27
<YokoZar> Is there a dpkg-source --clean type command?
<mwhudson> does anyone have any tips for how to manage distro patches for gcc without going crazy?
<mwhudson> i've tried gbp pq a bit but it fails for reasons i don't understand
<mwhudson> oh, i think i see why it failed for me
<cjwatson> tokolike debuild clean?
<cjwatson> err
<cjwatson> YokoZar: like debuild clean?
<YokoZar> cjwatson: I was more interested in a sort of revert type feature.  Basically a package's clean instructions weren't completely cleaning it so a second binary build was balking about having uncommitted changes to the source.
<cjwatson> YokoZar: oh, well, use a version control system.
<cjwatson> or re-unpack.
<YokoZar> Yeah that's what I thought :p
<YokoZar> Or maybe reverse apply the patch shown in the temp file
<cjwatson> it's a bug if clean doesn't clean, of course.
<YokoZar> Yeah, already filed that one :P
<pitti> Good morning
<pitti> stgraber: ack; I filed bug 1361964
<ubottu> bug 1361964 in calibre (Ubuntu) "FFE: Port to Qt5" [Undecided,New] https://launchpad.net/bugs/1361964
<dholbach> good morning
<LocutusOfBorg1> cjwatson, can you please unblock insighttoolkit4? it should just be three "no change rebuild" away :)
<LocutusOfBorg1> hi dholbach :)
<dholbach> hi LocutusOfBorg1
<LocutusOfBorg1> sil2100, did you ask to remove lucene++ from new queue?
<LocutusOfBorg1> I got a strange mail, I would like to ask you prior to ask more informations ;)
<dholbach> ivoks, happy birthday! :)
<ivoks> dholbach: :) thanks
<cjwatson> LocutusOfBorg1: not after midnight, find another victim :)
<cjwatson> LocutusOfBorg1: err, in any case, insighttoolkit4 isn't blocked
<LocutusOfBorg1> cjwatson, no problem ;)
<LocutusOfBorg1> have a nice day :D
<LocutusOfBorg1> how can I ask something to ubuntu-security people?
<LocutusOfBorg1> I'm wondering about CVE-2014-5119
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5119)
<infinity> LocutusOfBorg1: I'll be uploading to utopic for that tomorrow, and we'll get it sorted in stables soon.
<LocutusOfBorg1> thanks infinity :)
<darkxst> pitti, is it possible to cache packages when using adt-run?
<pitti> darkxst: I just use apt-cacher-ng on my workstation; mk-sbuild, adt-build-lxc, and adt-buildvm-ubuntu-cloud all detect and use that automatically
<pitti> yes, otherwise you'll go crazy
<darkxst> pitti, ok, will try that out
<pitti> darkxst: curious, you are the second person today who asks me about that; perhaps it's time for a blog post :)
<darkxst> pitti, could be ;) I never used to care when I had a 100Mbps internet connection, but now suffering slow adsl
<pitti> darkxst: yeah, I'm just going to blog about it this afternoon, lest I'll explain it n times again :)
<darkxst> and I guess I mostly use pbuilder and sbuild which do cache, but possibly I configured that
<pitti> darkxst: schroot doesn't cache by default
<pitti> (i. e. sbuild)
<darkxst> pitti, it does here, though like I said, probably had to tweak config for that
<pitti> *nod*
<darkxst> and with cached packages and eatmydata, sbuild is incredibly fast
<pitti> darkxst: I put all overlays (schroot, lxc, qemu) on /tmp which is on a tmpfs for me; even faster
 * pitti will include that in the blog post
<pitti> it's a bit ironic that first one buys an expensive 500 MB/s SSD and then puts quite some effort in not touching it by  keeping everything in RAM, but it's still worth it :)
<tjaalton> sure is :)
<tjaalton> my first ssd broke after a year, the warranty replacement has been going for nearly 2y now..
<tjaalton> guess doing builds on tmpfs helps a bit
<pitti> but seeing a schroot with 300 build deps download and unpack in 5 seconds is pretty neat
<jtaylor> pitti: if you are writting a sbuild/pbuilder performance tip post, putting this in fstab /dev/mapper/lvm-chroot /srv/chroots ext4 data=writeback,commit=3600,nobarrier 0   1
<pitti> yeah, /tmp is my cwd most of the time :)
<jtaylor> is useful if you don't have enough ram to build large packages
<jtaylor> (probably less important with ssd)
<pitti> jtaylor: ah, that probably needs some more setup (LVM), though? I guess you should perhaps blog about this too
<pitti> I have 16 GB, thus 8 GB tmpfs, I never ran into trouble so far
<jtaylor> pitti: you can mount any partition you use as BUILDPLACE like that, though don't put important data on it :)
<pitti> I'm not Sweetsha1k or the kernel team, of course :)
<pitti> jtaylor: ah nice, like a bind mount with degraded data integrity guarantees?
<pitti> not a bind mount, a proper mount
<pitti> but one needs to set up the devmapper fist
<pitti> first
<jtaylor> yes its just a workspace partition which will likely get corrupted on stuff like powercuts
<pitti> jtaylor: tell you what, I'll create a wiki page instead of a blog post; probably more useful
<jtaylor> lvm makes it easy to have special purpose partitions, but you could use real partitions too
<pitti> jtaylor, darkxst: I edited https://wiki.ubuntu.com/SimpleSbuild which already has most of the stuff
<pitti> it uses /dev/shm/ which is always a tmpfs, and avoids mangling the symlinks in /var/lib/schroot/
<darkxst> pitti, ok, will take a look tomorrow ;)
<LocutusOfBorg1> sil2100, can you please remove lucene++ from mentors?
<LocutusOfBorg1> I would like to upload again the -1 version
<LocutusOfBorg1> and BTW how do you feel about maintaining under git in collab-maint?
<tedg> stgraber, hallyn, so I ran the uitoolkit tests last night and we're still getting a 8% failure with cgroups enabled.
<tedg> So I don't think the underlying bug is fixed.
<tedg> What should I capture for a debug log?
<ogra_> yeah, why would it be fixed ...
<hallyn> capture the /var/log/upstart/cg{manager,proxy}.log and /proc/pid/cgroup of the login job;  but it also may be worth instrumenting systemd-shim
<hallyn> ogra_: bc cgmanager should now always be running when the login job starts
<ogra_> your change definitely didnt change the phone boot process
<tedg> ogra_, We uploaded a new cgmanager package with a proposed fix.
<ogra_> (as i said yesterday)
<hallyn> can you post some bootcharts?
<tedg> So I don't think this is a boot issue.
<ogra_> not atm, i have non submitted code on all devices i could test on
<tedg> Because in the same user session I'm getting ones that work and ones that don't.
<ogra_> you can use phablet-bootchart from phablet-tools to generate a chart though
<tedg> Specifically, over 288 application instances created about 8% aren't getting cgroups.
<hallyn> tedg: huh.  that's not in keeping with info i'd gotten from jodh
<tedg> hallyn, I think he might have ended up chasing something different.
<tedg> hallyn, The only thing in cgmanger log is: cgmanager:per_ctrl_move_pid_main: Could not determine the requested cgroup
<mapreri> pitti: <3 :)
<pitti> mapreri: yw :)
<tedg> hallyn, And I actually have that as many times as I have failure.
<ogra_> tedg, hallyn, are we sure the old kernels we use on the phone have actually all features and functions in cgroups that we use ?
<ogra_> dont forget we are using BSP kernls
<mapreri> pitti: 7 minutes between the request and the sponsorship. You can mark it as a personal record :)
<hallyn> they don't have all the features which is why both cgmanager and cgproxy have to run
<pitti> mapreri: I think I've been faster with IRC requests, but thanks :)
<mapreri> ^^
<ogra_> hallyn, hmm
<ogra_> i wonder if one steps on the toes of the other then
<tedg> hallyn, So do you know what could cause that error?
<tedg> hallyn, Is there a way to turn on more verbose debugging from cgmanager?
<hallyn> tedg: /etc/default/cgmanager -> "cgmanager_opts="--debug"".  jodh was doing that plus extra debugging with a custom patch
<hallyn> but at this point, i think what we need to know,
<hallyn> is at your 8% failures, (1) what was the cgroup of the upstart job itself,
<hallyn> (2) the upstart job contents, and (3) what was the cgroup of the launched app
<hallyn> in the cases jodh was pursuing, the upstart job wasn't in a cgroup it controlled.  But that was because the whole login session in his cases were not in the right cgroup
<hallyn> if it's 8% not getting the right cgroups, then you're hitting something different
<hallyn> so last night my thinkpad sudenly went dark, wouldn't turn back on, and smelled of burning wire.  this morning it turns on.  but do i want it to....
<tedg> hallyn, So we're creating an cgroup for the upstart job, so I'm not sure what you mean by "what was the cgroup of the upstart job itself" or "it's contents"
<tedg> The app is then put into that created cgroup
<tedg> So there's no other group for the app
<pitti> wgrant: to confirm, RTM langpacks shoudl appear at https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs , right? (once this is set up)
<hallyn> tedg: something forks the task which will become the user upstart job
<ogra_> pitti, btw https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-August/thread.html ... in case you want to subscribe
<pitti> ogra_: ah, thanks; but after many years I actually managed to ween myself off reading -changes
<ogra_> haha
<pitti> (in some desperate attempt to reduce my ginormous email/IRC budget a bit)
<pitti> "wean"
<tedg> hallyn, Yes, upstart does that internally.
<hallyn> tedg: and i want the cgroup at that point
<ogra_> i still use these lists ... but 90% of the mail is just marked read
<tedg> hallyn, Hmm, okay, perhaps stgraber knows how to get that.
<hallyn> tedg: if there is simply a user-owned /sbin/init (and it is the one that will fork) then its cgroup will be fine
<tedg> hallyn, Ah, okay, I can get that.
<tedg> hallyn, http://pastebin.ubuntu.com/8159489/
<wgrant> pitti: Yep, that's the place. Just worked out the last ubuntu<->ubuntu-rtm sharing issue today.
<hallyn> tedg: yeah, but the question is is that somehow different when the 8% failing jobs start.
<pitti> wgrant: awesome!
<hallyn> is it always a different subset of jbos that fail?
<tedg> hallyn, Yes, guessing it's a race of some kind. Specifically the UI Toolkit seems to show it the best which has a bunch of "applications" which are each tested for a couple seconds.
<hallyn> tedg: is that 'Yes, it's always a different set of tasks' ?
<tedg> hallyn, It's always the same job, but a different set of tests. All the applications are under the "application-legacy" job, but have an individual instance. Different sets of those instances fail each time.
<tedg> hallyn, So the "application-legacy" job fails to start (like no logs, no nothing) 8% of the time.
<hallyn> wait, fails to start at all, or fails to start int he right cgroup?
<tedg> Fails to start at all
<hallyn> sorry if we're talking in circles here - but do we know they are failing to start bc of cgroups not being set up?
<tedg> No problem, we know that if we remove the cgroup directive of the Upstart job things work.
<tedg> And we know that we get the error from cgmanager
<tedg> (or I know, others may know more)
<hallyn> ok i think i will add some nih_traces to cgmanager to help us debug there
<hallyn> tedg: pushing a new cgmanager (0.30-1ubuntu2) would like to see the /var/log/upstart/cgmanager.log with that pkg
<tedg> hallyn, Cool, I have a run going with the --debug flag I'll grab that package when it's up.
<tedg> hallyn, Hmm, I must have screwed that up, I got no cgmanager log this time. http://pastebin.ubuntu.com/8159755/
<hallyn> tedg: /var/log/upstart/cgmanager.log doesn't exist?  you've done 'stop cgmanager; start cgmanager' ?
<tedg> hallyn, Well, I rebooted.
<tedg> hallyn, But, yes, no log
<tedg> hallyn, Looking in cgproxy log I see a couple odd messages "cgmanager_create: returning 0; existed is -1"
<tedg> hallyn, Sometimes that's a "1" sometimes "-1"
<hallyn> those are fine.  returning 0 means it worked
<tedg> K
<flexiondotorg> cjwatson, When I run ./update for my meta package I see the following in the logs '! Setting features {no-follow-recommends} for seed required'
<flexiondotorg> What does that mean exactly and what action is required?
<flexiondotorg> I've noticed that the installed system is not installing recommended package by default and suspect this message may trying to tel me something ð
<shadeslayer> flexiondotorg: it means that recommends of recommends are not added
<shadeslayer> flexiondotorg: see man germinate
<flexiondotorg> shadeslayer, Thanks.
 * flexiondotorg goes reading
<shadeslayer> ah hm
<shadeslayer> no, just 1st level is off
<shadeslayer> so recommends of a package in the seed are not added
<shadeslayer> flexiondotorg: yw
<flexiondotorg> shadeslayer, Why is no-follow-recommends being enabled. I have not set it in my seeds.
<shadeslayer> possibly turned on by default?
<shadeslayer> I never bothered investigating tbh
<ubuntu-baltix> Hi devs :)
<ubuntu-baltix> could someone merge usb-modeswitch from Debian unstable - currently usb-modeswitch from Ubuntu 14.10 and 14.04 doesn't work with latest usb-modeswitch-data releases and doesn't support lots of Huawei (and other) modems :(
<Saviq> oSoMoN, I frown at your HTML emails :P
<ubuntu-baltix> See bug #1308895 , bug #1192297 and other bugs at https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch and https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch-data
<ubottu> bug 1308895 in usb-modeswitch (Ubuntu) "Please merge usb-modeswitch from Debian unstable - Huawei E3531 does not automatically switches to modem mode (no udev rules for this modem in Ubuntu's /lib/udev/rules.d)" [Medium,Confirmed] https://launchpad.net/bugs/1308895
<ubottu> bug 1192297 in usb-modeswitch-data (Baltix) "Huawei E3131 mobile modem not recognized" [Medium,Confirmed] https://launchpad.net/bugs/1192297
<oSoMoN> Saviq, my what? since when am I sending HTML emails?
<oSoMoN> that would be a terrible heresy
<Saviq> oSoMoN, I got https://lists.launchpad.net/ubuntu-phone/msg09661.html in HTML
<oSoMoN> Saviq, blame gmail then, I just replied inline using the web interface, as I always do
<Saviq> and couldn't find your reply, because I frown at not cutting the irrelevant parts out ;)
<Saviq> oSoMoN, I blame gmail for a lot of things, yeah :)
<oSoMoN> Saviq, right, my bad for not removing irrelevant context, Iâm in a rushâ¦
<Saviq> oSoMoN, like we all are, no worries :)
<ubuntu-baltix> also for example bug #1328412
<ubottu> bug 1328412 in usb-modeswitch-data (Ubuntu) "Huawei E398 GSM modem configuration data not included" [Undecided,Confirmed] https://launchpad.net/bugs/1328412
<shadeslayer> anyone have a idea how autologin configs get written from ubiquity?
<apachelogger> shadeslayer: casper?
<apachelogger> I'd suppose that casper writes a lightdm autologin conf
<shadeslayer> nope the option from the installer
<shadeslayer> I've already put in sddm support in casper
<apachelogger> yeah, that simply closes ubiquity-dm I suppose
<apachelogger> ubiquity-dm unit stops -> proper DM starts -> find autologin logs in
<shadeslayer> but in ubiquity you can do "Log in automatically"
<apachelogger> ah that one
<shadeslayer> yes
<shadeslayer> that one :p
<apachelogger> surely somewhere in ubiquity :P
<shadeslayer> I found self.preseed_bool('passwd/auto-login', auto_login)
<apachelogger> that's debconf though, isn't it
<shadeslayer> right
<shadeslayer> so what actually writes the config then
<shadeslayer> ( FYI that snippet is from ubiquity )
<apachelogger> user-setup? if that still is a thing
<apachelogger> shadeslayer:
<apachelogger> ./user-setup-apply:autologin-session=lightdm-autologin"
<apachelogger> ./user-setup-apply:                                     sed -i "s/^\(\(str  *\)\?autologin-user\)=.*$/\1=$USER/g;" $ROOT/etc/lightdm/lightdm.conf
<shadeslayer> ah
<shadeslayer> cheerio
<shadeslayer> apachelogger: huh, grepping from bzr doesn't give me anything
<apachelogger> grepped from pkg
<apachelogger> lp:~ubuntu-core-dev/user-setup/ubuntu says the control
<shadeslayer> https://code.launchpad.net/~ubuntu-installer/user-setup/master says git
<apachelogger> the cake is a lie!
<shadeslayer> ^^ :p
<apachelogger> shadeslayer: well, that's the import, since we use lightdm the coredev branch surely is our derivate of it ;)
<shadeslayer> yeah I guess
<shadeslayer> anyway, will fix it tomorrow
<tedg> hallyn, Here's the cgmanager log, don't see anything obvious, looking for which apps failed now: http://paste.ubuntu.com/8161530/
<tedg> hallyn, It looks like the group is getting removed and then someone is looking for it?
<tedg> hallyn, Seems like normally it's "created/moved/removed" but there are cases of "created/removed/invalid path"
<hallyn> tedg: the cgroup will be removed if it becomes completely empty.  could that be happening?
<hallyn> (that is, no tasks in the cgroup and no sub-directories)
<tedg> hallyn, Guessing it must because there's no move.
<tedg> hallyn, So it's created, nothing is moved in, so it's empty.
<hallyn> no, it has to become empty
<hallyn> there has to be a task, which is moved out or exits,
<hallyn> then the cgroup is autoremoved
<hallyn> tedg: but that paste doesn't have any failures
<hallyn> oh there' sone
<tedg> hallyn, It has the "Invalid path"
 * tedg searched for "fail" first too :-)
<tedg> Hmm, looks like it's being removed before anything is moved into it.
<hallyn> tedg: Removed /run/cgmanager/fs/freezer//user.slice/user-32011.slice/session-c1.scope/upstart/application-legacy-tmpa3LBk3-1409158710956199 for 9587 (0:0)
<hallyn> yeah
<hallyn> who's removing it
<hallyn> mind you cgmanager won't actually remove it if tasks are in it,
<tedg> 9587 :-)
<hallyn> heh
<tedg> It strikes me that it is PID+1
<hallyn> suppose cgmanager could spit out /proc/pid/cmdline, but not sure that'd be meaningful
<hallyn> so where/when does upstart remove it
<hallyn> sigh, i'll probably be dropping in about 20 mins - bc my new hotspot's batt life is apparently < 2 hrs.  poc
<hallyn> tedg: you're running stock utopic upstart?
<tedg> Correct
<tedg> 1.13.1-0ubuntu3
<hallyn> upstart never calls cgmanager_remove_sync.
<hallyn> is there a way you can have application-legacy be straced?
<tedg> Uhm, I can strace the binary, but last time it looked like our binary wasn't even getting called.
<tedg> Like it stopped before execing to us.
<tedg> Wait, I'm looking at the one "tmpN5uJfu" and it seems like it's getting created twice.
<tedg> Wondering if we're getting duplication in the tmp file generator.
<tedg> No, because the timestamps are the same.
<tedg> Looks like it gets created 3 times, removed once.
<hallyn> and why is it getting creatd 3 time?
<hallyn> shouldn't each one have a separate tmpnam?
<tedg> In theory, but more so the timestamp should be incrementing.
<hallyn> but my q is - is the pid which is asking for the removal showing up in the strace?  (i.e. is it part of the app somehow, or is it upstart)
<tedg> Huh, so it looks like they're all created 3 times.
<tedg> Guessing job, post-start, post-stop.
<hallyn> heh makes sense
<hallyn> can you pb the upstart job?
<tedg> pb?
<hallyn> pastebin
<tedg> Ah, sure
<hallyn> 12% battery remaining, will be lunchtime soon
<hallyn> maybe time fo ran email to warthogs asking for best hotspot batt life
<tedg> http://paste.ubuntu.com/8161783/
<tedg> So It looks like the last create is the one that doesn't get moved in.
<hallyn> tedg: oh.
<hallyn> the remove is being done on behalf of cgm-release-agent
<hallyn> (I'm assuming)
<hallyn> I'd forgotten it actually goes through dbus to cgmanager as well
<hallyn> so workarounds would include (a) an upstart job which sets notify-on-release to 0 for all mounted cgroups,
<hallyn> (b) an option to cgmanager ot say don't remove on empty,
<hallyn> (c) upstart simply not setting remove-on-empty
<hallyn> having typed that, c seems most reasonable for now
<tedg> Would it be bad if we had a lot of left over cgroups?
<hallyn> so i think upstart should wait until post-stop is run (if any) before setting remove-on-empty, then attempt to remove by hand
<hallyn> over time, yes
<tedg> I mean we expect people to never reboot their phone.
<hallyn> but i'm not saying never remove them
<hallyn> i'm saying wait until we know the job is done before setting automreove
<tedg> Ah, okay. That makes sense to me.
<hallyn> as a short-term workaround, just remove the calls to cgmanager_remove_on_empty_sync()
<hallyn> (in init/cgroup.c)
<hallyn> then we should probably wait for jodh to get back for the proper fix
<tedg> So, *I* can't do that.
<tedg> :-)
<tedg> stgraber, can you? ^
<hallyn> well, we only want it on that phone for now right?
<hallyn> or do we want it in all of utopic?
<tedg> The goal is to not have a special build for phone.
<hallyn> ok, my hotspot is about gone - i'll be back after lunch, sorry.
<tedg> If we have to, I guess that's possible, but would prefer not to.
<hallyn> SO disappointed
<tedg> NP
<hallyn> tedg: let's decide in like an hour
<tedg> +1
<hallyn> (and maybe when i look at the upstart source it'll be obvious how to do the proper fix myself)
<hallyn> seems like just doing it at job_process_terminated() should suffice
<hallyn> hm, upstart is source v 1.0.  that's nerve-wracking
<tedg> hallyn, Does that run when all the job processes are done, or just the main one?
<tedg> hallyn, It seems like in some cases it is the post-stop that's having issues.
<hallyn> tedg: the reason it is having issues is that it runs after the job has exited, meaning the cgroup gets removed :)
<hallyn> and the reason it's a race is that the post-stop *does* create the cgroup,
<hallyn> but sometimes the autoremove happens after the last create, but before the exec
<tedg> Yes, I see that, but I was worried that if you're setting the autoremove after the main job, then it'd be the same.
<hallyn> right
<hallyn> tedg: anothe rpossibility would be to ues a different cgroup name at post-stop
<hallyn> but, lp:ubuntu/utopic/upstart/cgroup-race1 is the first guess
<hallyn> hm, i'll create a tree with my second guess too.  then the ppl who actually know what they're doing can critize both
<hallyn> i haz doubts on upstart init/cgroup.c:439
<hallyn> it checks for cgname->expanded being NULL, but that's after having done a strcmp including it
<hallyn> oh, nm
<tedg> hallyn, So are you by chance at debconf?
<hallyn> so lp:~serge-hallyn/ubuntu/utopic/upstart/cgroup-race2 would be the other way.  What are the odds that would actually work...
<hallyn> tedg: nope
<tedg> Would like to figure out the "final" solution between folks
<tedg> Hmm, okay.
<tedg> I'll put together an e-mail to see if we can grab those folks that are.
<hallyn> tedg: I suspect the right answer will simply be removing for real (including killing any remaining jobs) at FINAL job state
<hallyn> meanwhile though i'm going to build a package with cgroup-race2
<tedg> hallyn, Honestly, that'd be cool as I'm doing that in the job currently "cgroup-reaper" but would love to have Upstart do it for me :-)
<hallyn> tedg: yeah and it really should do that
<hallyn> or, cgmanager should perhaps offer a 'RemoveAndKill' method
<hallyn> and upstart should then use that
<hallyn> tedg: incroyable!  my patch seems to work
<hallyn> pre-start is in /xxx_2, script in /xxx_0, post-stop, well, hasn't started yet
<hallyn> (xxx_4)
<hallyn> and after stop, cgroups are gone
<hallyn> it does multiply the cgroup setup being done, but i think that' sok
<hallyn> tedg: tossed the patch to jodh (in the form of a merge proposal against the wrong tree)
#ubuntu-devel 2014-08-28
<hallyn> so, when i set up my thinkpad on unity 2 weeks ago, contrast and volume buttons brought up the little icons showing the values going up/down.  then i installed lubuntu-desktop just for a test, but those went away.  removed lubuntu-desktop, they stayed away.  anyone know what package i need to get those back?
<hallyn> sorry shouldn't ask that here
<pitti> Good morning
<pitti> wgrant: hm, is message sharing still working between upstream and distro POTs?
<pitti> wgrant: https://translations.launchpad.net/messaging-app/ is fairly complete, but https://translations.launchpad.net/ubuntu/utopic/+source/messaging-app/+pots/messaging-app is very poorly covered
<wgrant> pitti: Message sharing is so hilariously buggy you wouldn't believe.
<pitti> wgrant: hmm, that's a bit of a bummer for touch langpacks
<wgrant> pitti: Changes that were deployed yesterday make it possible to fix most cases, though.
<wgrant> And another that will be deployed this afternoon make it possible for things to actually not be completely inconsistent.
<pitti> wgrant: I have a hack in langpack-o-matic for now; it checks out the upstream bzr trees, and directly copies their po files into the langpacks, short-circuiting LP import/export
<pitti> but I hoped it would be temporary
<pitti> wgrant: that sounds positive :) will that apply to existing pots?
<wgrant> I'll need to inspect the database to work out how messaging-app's are broken.
<wgrant> But, in general, if anyone has ever removed a link between a project and a package things will be woefully broken.
<pitti> e. g. https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app/+pots/dialer-app looks quite a bit better (but still not on par to upstream)
<wgrant> Let's see if I can convince it to remerge them.
<pitti> wgrant: most of the touch projects got an x-ubuntu-use-langpack: a few days ago, and only yesterday I approved all the pots for import
<pitti> so perhaps it's also still just catching up
<wgrant> This has taken a lot longer to sort out than I'd hoped, because I'd been operating under the assumption that message sharing between projects and distros wasn't horribly broken.
<pitti> heh, everyone was, I suppose
<wgrant> pitti: Hm, I think those templates were mostly shared properly, and they're totally shared now. But they're very different.
<wgrant> https://translations.launchpad.net/ubuntu/utopic/+source/messaging-app/+pots/messaging-app/am/+translate 65 strings
<wgrant> https://translations.launchpad.net/messaging-app/trunk/+pots/messaging-app/am/+translate 31 strings
<pitti> how odd
<wgrant> Rather.
<pitti> perhaps the pot gets rebuilt during package build, and messaging-app's pot in trunk is just totally outdated?
 * pitti checks
<wgrant> That could well be the case.
<wgrant> The Ubuntu side looks correct to me.
<pitti> in that case this would even be good
<wgrant> Why?
<pitti> https://translations.launchpad.net/ubuntu/utopic/+source/messaging-app/+pots/messaging-app/de/+translate?show=untranslated looks reasonable indeed
<pitti> wgrant: because it would expose untranslated messages at least on the ubuntu side; upstreams pathologically forget to update their pots :/
<pitti> yep, I see the i18n.tr("Attachment.. stuff in the code
<wgrant> Right, so the upstream side needs to regenerate their POT, I guess.
<pitti> +msgid " "
 * pitti weeps
<pitti> but yes, that helped
<pitti> pushed to lp:messaging-app
<pitti> wgrant: sorry for blaming LP then! thanks for pointing out
<wgrant> pitti: This case turns out to be simple and the merge job only fixed up five strings.
<wgrant> It was slightly LP's fault, but not most of it :)
<pitti> wgrant: hah, and there we go -- https://translations.launchpad.net/ubuntu/utopic/+source/messaging-app/+pots/messaging-app/de/+translate?show=untranslated
<wgrant> pitti: What do you mean?
<pitti> wgrant: the missing strings were imported, and are now shown as "untranslated" (was previously empty)
<wgrant> pitti: But that's the Ubuntu template. Wasn't it always correct
<wgrant> ?
<pitti> err, argh; -ETOOMANYTABS
<pitti> well, I translated a few missing ones; let's see, they ought to get propagated to the upstream one
<pitti> so apparently the new pot wasn't imported yet; I'll check later
<wgrant> pitti: The upstream one is already fully translated.
<wgrant> Because the POT isn't there yet.
<wgrant> Ah, just entered the queue 90 seconds ago
<wgrant> 2014-08-28 05:21:36 INFO    Import requests completed.
<wgrant> 31 untranslated upstream now
<wgrant> Which matches Ubuntu.
<wgrant> There were 46 untranslated in Ubuntu before. Did you translate 15?
<wgrant> Er, no, not 46, wrong language.
<pitti> wgrant: 15 sounds about right
<pitti> https://translations.launchpad.net/messaging-app/trunk/+pots/messaging-app/de/+translate?show=untranslated now has 31 untrasnlated German things
<pitti> Attachment: %1 contact
<pitti> but I did translate those in Ubuntu already
<pitti> seems they were silently eaten
<pitti> it got the second (multiple) case, but not the singular
<wgrant> wat
<pitti> I think there's something wrong: the singular uses %1, the plural uses %s
<wgrant> wat
<wgrant> "(no translation yet) Translated and reviewed by Martin Pitt 3 minutes ago"
<pitti> src/qml/ThreadDelegate.qml:            return i18n.tr("Attachment: %1 image", "Attachments: %s images").arg(imageCount)
<pitti> aaaaaaaaah
<wgrant> That doesn't look right.
<wgrant> It's possible it is, I suppose, but it seems weird.
<wgrant> All the strings with %1 appear translated but untranslated.
<pitti> wgrant: I sent https://code.launchpad.net/~pitti/messaging-app/i18n-fixes/+merge/232507 now
<Bluefoxicy> oh for.
<Bluefoxicy> apt-get update consistently picks the same mirror with a mirrors:// url.  Wonderful.  I'm filing that as a bug because "constantly chooses stupid slow mirror, and killing apt and restarting doesn't get me a different mirror"
<sarnold> Bluefoxicy: are you using a sortlist in resolv.conf?
<Bluefoxicy> sarnold: no.
<Bluefoxicy> sarnold:  apt is constantly picking mirrors.xmission.com.  Constantly.
<Bluefoxicy> oh that's hilarious.
<Bluefoxicy> skype-4.3.0-37 installs ... skype 4.2
<Unit193> skype --version
<Unit193> Skype 4.3.0.37
<Bluefoxicy> john@icebox:~$ skype --version
<Bluefoxicy> Skype 4.3.0.37
<Bluefoxicy> SkypeTM 4.2 for Linux
<Bluefoxicy> (!) Skype can't connect
<Bluefoxicy> Unit193:  does yours give a Skype 4.2 for Linux title?
<Unit193> Mine has no problems connecting, by all signs it is 4.3.  Partner repos.
<Bluefoxicy> mine came from partner
<Bluefoxicy> bthe title bar says Skype 4.2 for Linux
<Unit193> `which skype`
<Bluefoxicy> /usr/bin/skype
<Bluefoxicy> ~$ sudo apt-get remove --purge skype-bin skype
<Bluefoxicy> Removing skype (4.3.0.37-0ubuntu0.12.04.1)
 * Bluefoxicy squints
<Bluefoxicy> bash: /usr/bin/skype: No such file or directory
<Bluefoxicy> dongs: command not found
 * Bluefoxicy squints very hard.
<sarnold> rehash?
<Bluefoxicy> what?
 * Unit193 waves to sarnold.
<sarnold> bash 'hashes' the paths to executables that it looks up via the PATH; if you remove one path, running shells might not see a different location..
<sarnold> evening Unit193 :)
<Bluefoxicy> aha
<Bluefoxicy> I had to killall skype
<sarnold> haha, typical MS..
<sarnold> "of course you want this thing running all the time to shave .5 seconds off the 'startup time'"
<Unit193> It...has problems closing.
<Unit193> sarnold: It's not actually a daemon mode, just kind of fails to exit, like remmina. :P
<Unit193> sarnold: You should see the windows one, so my sister tells me, it really makes sure you want to exit, a few times. :P  (Since when did the X mean minimize?)
<sarnold> Unit193: cripes. hooray for killall :)
<dholbach> good morning
<darkxst> pitti, seems I was already using /dev/shm ;) must be set by default with the launchpad sbuild helpers
<alive4ever> Hello. I'm on trusty. I have a problem with certtool from gnutls-bin package. I cannot generate an ecc privkey using certtool, using command `certtool --generate-privkey --ecc`. Certtool says that ecc is invalid option. Any workaround to enable ecc support for gnutls on trusty?
<alive4ev1> Hello. I'm on trusty. I have a problem with certtool from gnutls-bin package. I cannot generate an ecc privkey using certtool, using command `certtool --generate-privkey --ecc`. Certtool says that ecc is invalid option. Any workaround to enable ecc support for gnutls on trusty?
<alive4ever> Excuse me. Any workaround for trusty gnutls that I explained earlier?
<Saviq> pitti, hum, is there a way to apport-bug from an rtm phone?
<pitti> Saviq: I'm glad you asked -- the base-files fix for that just landed in RTM like 10 mins ago :)
<pitti> bug 1362496
<ubottu> bug 1362496 in base-files (Ubuntu-rtm 14.09) "LSB release and /etc/os-release still say "Utopic", needs to be RTM" [High,Fix released] https://launchpad.net/bugs/1362496
<Saviq> pitti, yay, will upgrade
<pitti> Saviq: might not be published yet, could still take some minutes; but you can of course snatch the deb from LP
<arges> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: "., arges
<Saviq> pitti, the bug was filed against ubuntu (not rtm) anyway, that expected? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1362619
<ubottu> Error: launchpad bug 1362619 not found
<Saviq> (I added the rtm tasks manually)
<sil2100> wgrant: hey! Is there currently a way to create an ubuntu-rtm PPA?
<sil2100> wgrant: through LP, for instance?
<wgrant> sil2100: There's no UI for it, to avoid confusing the rest of the world. but you can say lp.load(lp.me.self_link).createPPA(distribution=lp.distros['ubuntu-rtm'], name='whatever') in lp-shell
<sil2100> wgrant: thanks! Do you know if I can use the same API for creating a PPA for a selected team? Didn't really use the API for PPA creation before ;)
<wgrant> sil2100: Sure. You need to be a team admin, but lp.people['some-team'].createPPA(blah blah blah).
<sil2100> Thanks again :)
<pitti> Saviq: yes; I did a quick strawpoll in #u-touch this morning, and people leaned towards filing them against ubuntu
<Saviq> pitti, ok
<pitti> Saviq: ubuntu-rtm  would be more correct, but it's one more place to check bugs, so some people said it's easier to keep them against one distro and just treat it as a different release
<pitti> Saviq: DistroRelease: Ubuntu RTM 14.09
<pitti> Saviq: but that's good; I set up apport retracers for RTM this morning, let's see what they do about this :)
<pitti> Saviq: oh well -- *did*, it already is retraced :)
<pitti> looks quite reasonable
<Saviq> pitti, yeah, dealt just fine
<Saviq> cyphermox, hey, I tried testing krillin with my car kit, but it will only work in reverse pairing mode (meaning it's the phone that needs to made discoverable and you need select it in the car UI and provide the code on the phone when the kit connects)
<Saviq> cyphermox, and that doesn't seem to be supported by us yet is it?
<Saviq> is there a bug already? should I file one? what data can I provide to be helpful?
<cjwatson> pitti: I've noticed a few publishing entries in ubuntu-rtm where you seem to have copied things into 14.09 directly (e.g. cgmanager).  Could you please remember to copy things into 14.09-proposed instead?  You're an archive admin, so you *can* copy directly to 14.09, but doing so bypasses proposed-migration.
<cyphermox> Saviq: yeah please file one
<cyphermox> Saviq: that said, I would expect that reverse pairing should work too
<cyphermox> for instance, the phone can already be made discoverable, and should be detected by the car, but I do know that it's not exposing itself in the right mode.
<cyphermox> I still need to figure out the best way to ship these different configurations for bluez
<Saviq> cyphermox, so yeah, the part that fails is pairing itself
<Saviq> cyphermox, the car displays a code on the dash
<Saviq> cyphermox, and I'm supposed to type it in
<Saviq> cyphermox, on the phone, but before I see anything, the car goes back saying there was an error
<cyphermox> interesting
<Saviq> cyphermox, btw, it feels wrong if settings is the only thing capable of that... we need a long running service that will handle PIN/connection requests, because those might happen without the need to even open settings
<Saviq> indicator-bluetooth sounds like a valid candidate
<cyphermox> in that case, could you file a bug against bluez, and attach /var/log/syslog?
<Saviq> cyphermox, doing
<cyphermox> I'd think if settings is open you should still be able to get the request to pop up
<cyphermox> but to make sure, we must check whether bluez is actually requesting anything
<Saviq> cyphermox, https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1362694
<ubottu> Error: launchpad bug 1362694 not found
<pitti> cjwatson: ah, good point; yes, will do that
<pitti> cjwatson: today we went via a silo (for base-files), those were the first trials
<pitti> cjwatson: but I think I'll still keep copying langpacsk directly from ubuntu to 14.09-proposed (no need for the silo overhead)
<sergiusens> pitti: you still around? do you have a flo? can you see why UDISK_SYSTEM is ignored by flo in https://launchpad.net/ubuntu/+source/lxc-android-config/0.193 ? ogra_ and myself couldn't figure it out
<sergiusens> it's low priority though
<cjwatson> pitti: right, makes sense
<cjwatson> bdrung: could you please merge gnustep-back?  gnustep-gui is currently mid-transition and that appears to be part of it
 * cjwatson is doing the obvious rebuilds there
<muntiger> how do i get started with ubuntu-sdk?
<roadmr> muntiger: did you read http://developer.ubuntu.com/ ?
<arges> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ".
<ion> Hello, ".
<stgraber> cjwatson, slangasek: can one of you moderate my beta-1 announcement on ubuntu-devel-announce? thanks
* Unit193 changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> stgraber: done
<stgraber> cjwatson: thanks
<Noskcaj> jtaylor, Could you look at my infernal merge?
<jamin> Is there a better place than a Launchpad report, to surface a regression report for an LTS release that has identified the problem, RCA'd it, provided a patch, and located the offending upstream commit
<Noskcaj> jamin, not really. link me the bug?
<jamin> Noskcaj, https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1361595
<ubottu> Launchpad bug 1361595 in oem-config (Ubuntu) "OSError: [Errno 25] Inappropriate ioctl for device" [Undecided,New]
<jamin> Noskcaj, it completely breaks oem-config for server installations
<jamin> ultimately leaving the system with no accounts that have a password for login
<Noskcaj> link the bug in #ubuntu-installer , they maintain it
<Noskcaj> and cjwatson, you're listed as the maintainer of the package, can you take a look
<bdrung> cjwatson: i won't find the time to do it in the next days. so please feel free to do the merge yourself.
<cjwatson> xnox: ^- do you have a minute to look at 1361595 as referenced above, since that says it was your commit? :)
<cjwatson> bdrung: will do, thanks
<cjwatson> bdrung: oh, in fact it's a sync, as 0.20.1-2.1 fixed the root cause of our remaining delta in what looks like a better way
 * cjwatson syncs
<cjwatson> pitti: inspired by a comment at debconf: do you think it might ever be feasible to run autopkgtests as buildd jobs?  anything obvious blocking that?
<cjwatson> pitti: obviously launchpad-buildd would need to gain support for it in the same kind of way that it gained support for livefs builds
<infinity> zyga: What's the story with cert testing for linux/precise (LP: #1355387)?
<ubottu> Launchpad bug 1355387 in Kernel SRU Workflow certification-testing "linux: 3.2.0-68.102 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1355387
<infinity> zyga: Looks like the task has been assigned to you for 9 days.
<infinity> cjwatson: That was my hope when they first built up this parallel infra.  IMO, every one-off build job could/should run through the same cloud, and our build job cloud of choice is lp-buildd.
<infinity> cjwatson: Might be stickier for breaks-testbed jobs, but some thinking between lp-buildd/buildd-manager/scalingstack could probably find an elegant solution.
<cjwatson> infinity: breaks-testbed is a PPA guest :)
<cjwatson> virtualised builder, rather
<ogra_> cjwatson, i need to roll back pittis change of base-files ... how can i upload directly to rtm ?
<cjwatson> ogra_: new dput.cf stanza, s/ubuntu/ubuntu-rtm/
<cjwatson> g
<ogra_> (it breaks CI/smoke testing)
<cjwatson> well, not in fqdn :)
<cjwatson> [ubuntu-rtm]
<cjwatson> fqdn = upload.ubuntu.com
<cjwatson> method = ftp
<cjwatson> incoming = /ubuntu-rtm
<cjwatson> login = anonymous
<infinity> ogra_: Which base-files upload is that?
<ogra_> infinity, to rtm ... https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-August/000212.html
<infinity> Ahh.  Silly me, I was looking in ubuntu.
<ogra_> heh
<ogra_> that was a true rtm upload actually :)
<ogra_> (rare species)
<infinity> He shouldn't have changed codename/release stuff.
<infinity> That way lies madness.
<infinity> The pretty names, sure.
<ogra_> well, he needed it for apport/whoopsie he said
<infinity> Ugh.
<infinity> A lot more tooling (for better or worse) depends on those versions.
<Neo31> hello folks :)
<sergiusens> infinity:  lool- cjwatson ogra_ need something like this: http://paste.ubuntu.com/8173047/
<sergiusens> used the best options I could without breaking backwards
<ogra_> sergiusens, yes, that helps with one tool
<sergiusens> some of the tooling
<sergiusens> yeah
<ogra_> but as infinity said, there might be more stuff that relies on /etc/{os,lsb}-release
<sergiusens> a bunch I bet
<ogra_> and assumes some ubuntuish name
<ogra_> hmpf ... rejected ...
<lool-> sergiusens: it'd seem we shoudl start with updateing distro_info
<xnox> cjwatson: yeap. sorry about that. Will upload after the talk
<ogra_> yay, that worked
<ogra_> base-files (7.2ubuntu6rtm2) 14.09; urgency=medium
<cyphermox> I just noticed a bad translation for the package description of libhybris, in French. Where are these translations if I wanted to fix the strings?
 * ogra_ blames rsalveti's french knowledge 
 * rsalveti has nothing to do with that
<rsalveti> :P
#ubuntu-devel 2014-08-29
<mwhudson> there's nothing in trusty-proposed currently that's going to eat my system, right? :)
<Unit193> Hello, Xubuntu plans to upload a xfce4-power-manager to correctly build a plugin, and it's stuck/waiting on Bug #1361459.
<ubottu> bug 1361459 in lxpanel (Ubuntu) "lxpanel is missing the development files" [Undecided,New] https://launchpad.net/bugs/1361459
<jamin> xnox, there's a second breakage in oem-config
<jamin> I've worked around it, looks like a change with python3 as the code looks the same as what was working in python2, but FDs are too aggressively closed, resulting in the handle to /dev/urandom being closed before a tempfile can be made
<SpamapS> wow.. getting 107kB/s to archive.ubuntu.com from my 30Mbit connection here in Los Angeles..
<SpamapS> where do the archive ops people hang out?
<jamin> https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1362920
<ubottu> Launchpad bug 1362920 in oem-config (Ubuntu) "OSError: [Errno 9] Bad file descriptor" [Undecided,New]
<jamin> xnox, bug 1362920 contains what appears to be the final blocker to getting oem-config to work on server installs again
<ubottu> bug 1362920 in oem-config (Ubuntu) "OSError: [Errno 9] Bad file descriptor" [Undecided,New] https://launchpad.net/bugs/1362920
<pitti> Good morning
<pitti> infinity, ogra_: no, I just need VERSION_ID and NAME in /etc/os-release for apport, nothing else; I changed the rest just for consistency
<pitti> infinity, ogra_: we can change some bits back if necessary; but RELEASE ceratinly should not be 14.10, that'd be a lie?
<pitti> and codename, too; 14.09 != utopic
<pitti> sergiusens: what is a flo?
<pitti> sergiusens: what do you mean with "ignored"? the rule isn't being applied, or udisks still treats it as a removable disk?
<pitti> cjwatson: triggering autopkgtests from buildds is a bit early, as they need to be published and installable
<pitti> cjwatson: running them *on* the buildds only works for tests which are simple enough to work in a chroot
<pitti> cjwatson: while that's true for the majority, a sizable chunk need a container or even a full VM
<pitti> lifeless: thomi is asking about an update of python-testtools to latest upstream; is it ok if I do that in Debian, or want to do that?
<thomi> oh, I just asked in #subunit :D
<thomi> parallel nagging :)
<cjwatson> pitti: I don't mean on the buildds as in during normal package builds
<cjwatson> pitti: I mean as a different job type that happens to be dispatched by launchpad-buildd
<cjwatson> pitti: So it could do anything that can be jammed into launchpad-buildd, though if it needs starting a fresh VM as part of the tests then we'd have to think about whether nested virt is going to work ...
<pitti> cjwatson: I tried nested KVM some six months ago, it was devastating :(
<cjwatson> pitti: (Or run on the non-virtualised builders, but those don't scale well and ultimately we should be planning for them to go away)
<pitti> maybe utopic's kernels and qemu are better, but for now we try to avoid it
<cjwatson> pitti: Does it need to run a VM under control of some other part of the job, or would it be sufficient if the entire job were run in a fresh VM?
<pitti> cjwatson: but actually the direction has been to distribute the jobs through rabbitmq and use a proper cloud (currently HP cloud)
<cjwatson> pitti: Launchpad's virtualised builders are a proper cloud, FWIW, but OK ...
<pitti> cjwatson: a fresh temporary VM is what we need; the control can even happen from a remote machine (although a local machine is more robust and avoids the assumption that ssh works all the time)
<pitti> cjwatson: I mostly know that just running a gazillion jobs on the 4 machines that we currently have doesn't work
<pitti> every gcc upload causes jamming if there's also upgrade and dkms jobs running in the background
<cjwatson> We have three machines running all of Launcompute nodes running all Launchpad's dvirt builders right now, soon to be six
<cjwatson> urgh, let's try that again
<pitti> cjwatson: anyway, if we can/want to use the "LP builder cloud", that seems fine
<cjwatson> We have three compute nodes running all Launchpad's virt builders right now, soon to be six
<cjwatson> Well, if you have a solution already with HP cloud, then maybe there are other more useful things to focus on
<cjwatson> I just thought it might be worth some consideration
<pitti> cjwatson: ah, not yet "have"; the CI airline is using it, and vila has worked on running autopkgtests there
<pitti> but it's not deployed yet
<pitti> cjwatson: will the LP cloud sustain 50 job requests in parallel? it might quickly run into the same scaling problems?
<pitti> cjwatson: I'm not emotionally attached to using one cloud or the other; I'm just eager to get rid of jenkins and manually administrating servers
<cjwatson> pitti: Seems to sustain full parallelism for its number of builders right now; the thing that sucks is lots of parallel resets, but we mostly avoid storms there by cleaning at the end of builds rather than at the start
<cjwatson> Which AIUI tends to spread things out a bit
<pitti> *nod*; good to keep that option in mind
<cjwatson> pitti: The new infra is certainly noticeably higher-performance than what we used to have, which took something like 20x the number of machines
<pitti> cjwatson: ci.debian.net currently doesn't have any parallelism at all; it's a single machine which does everything and just runs amd64
<pitti> cjwatson: but I suppose Debian's buildds couldn't take the load
<pitti> cjwatson: I've been developing this in close coordination with terceiro to have something that works for both D/U
<pitti> cjwatson: (if he's at debconf, say hello :) )
<cjwatson> Debian's buildd network has rather less capacity than ours for the most part, and wanna-build isn't at all set up to be able to dispatch non-package-build jobs
<cjwatson> I stopped into the last bit of his debci talk today, though missed most of it
<cjwatson> Haven't actually spoken to him yet though
<cjwatson> I actually do think doing it from the buildd network would be an even better idea for Debian as it is for Ubuntu, since Debian is often operating under tighter hardware constraints and that's exactly when you need to consolidate your resources
<cjwatson> But I don't have time to implement it in Debian, so it's just talk :)
<pitti> it'd certainly settle the "multiple architectures" aspect, although on most you can probably just get LXC; but that gives you 95% of what we need, and the remaining 5% can then just run on x86 (not a biggie)
<cjwatson> Though for Ubuntu we'd need to have non-x86 working in scalingstack before we get that benefit.
<cjwatson> (Which is on the roadmap, but I don't know when)
<pitti> for armhf/ppc64el we can probalby just continue to use the bunch of "static" machines that we have; we shouldn't lock ourselves into migrating them all at once
<errekerre> wolas
<errekerre> saveis de linux?
<errekerre> primero savies espaÃ±ol?
<errekerre> saveis?
<pitti> errekerre: sorry, this is an English channel
<errekerre> valla por dios
<errekerre> alguna sala ke hablen espaÃ±ol?
<infinity> pitti: It's not really a lie, it's a snapshot of 14.10
<pitti> infinity: it's called 14.09 in Launchpad..
<infinity> pitti: Sure, but whatever.
<pitti> so by not calling it what it is in LP we can't match it to bugs/crashes/etc.
<infinity> pitti: There are build systems that define their behaviour based on version and codename, you're opening a can of worms by suddenly defining a new one.
<pitti> and "Ubuntu RTM" doesn't have a 14.10 or utopic release
<pitti> infinity: well, I didn't start with this -- we defined a wholly new distribution for this (not just a new Ubuntu release)
<pitti> and that wholly new distribution doesn't have "utopic" or "14.10" releases..
<pitti> so it doesn't make sense to talk about Ubuntu RTM utopic
<infinity> pitti: Yeah, I know, but it's a short-lived fork (or bloody well should be), not something we should be adjusting tooling and potentially a bunch of packages for.
<infinity> GCC, for instance (to pick one at random) picks its defaults based on release codenames.
<pitti> infinity: hm, we spent weeks on fixing all our tools (LP, buildds, ddebs, retracers, transaltions, langpacks, etc) for a second distro
<infinity> Possibly bugs in packages that do so, but a lightweight fork for a pre-release freeze isn't the time to find those bugs.
<infinity> pitti: We fixed infrastructure, but are you prepared to find all the packages that will break if rebuilt against a base-files with a weird unknown distro?
<pitti> we already found bugs because it's wrong -- add-apt-ftparchive, apport, etc.
<zyga> infinity: hi
<pitti> infinity: well, perhaps we should have considered that before we put that giant pain of "maintain a parallel distro" upon us?
<pitti> instead of at least just a new ubuntu release
<zyga> infinity: we've finished automatic testing of 3.2 yesterday but we got a few issues that needed to be re-checked
<pitti> infinity: now it's broken either way
<zyga> infinity: I'm just checking if we have the results of that
<infinity> pitti: Really, modulo a few small forks, it *is* utopic/14.10 (though a pre-release), could we not just figure out how to make apport add an extra key only in the rtm version?
<infinity> pitti: ie: patch apport in ubuntu-rtm instead of changing base-files and trying to find all the package bugs?
<pitti> infinity: well, we could -- but like you said, are you prepared to find out everything which is now broken due to that? :-)
<infinity> pitti: apport/whoopsie/daisy seems like a much smaller set of things to twiddle than "every package that we don't know might be broken".
<pitti> e. g. apt thinks its package origin is "Ubuntu RTM"
<pitti> infinity: how do you know that in advance?
<pitti> infinity: if there's lots of packages broken by correcting os-release, then there's at least as many packages potentially broken by not fixing it
<pitti> we can't know
<infinity> pitti: Err, what would be broken by not changing it?
<pitti> infinity: yes, we can certainly hack apport to hardcode "Ubuntu RTM" "14.09" and ignoring /etc/os-release, and do that for other things like add-apt-ftparchive too
<pitti> but we have to find all those
<infinity> How does add-apt-ftparchive relate?
<pitti> infinity: adding a PPA can't add ubuntu/utopic, it has to add ubuntu-rtm/14.09 apt sources
<infinity> And I assume you mean add-apt-repository?
<pitti> err, yes
<pitti> not sure whether aptdaemon looks at this
<infinity> Do we really expect people to build a PPA community around this release whose entire raison d'etre is to not exist very long?
<pitti> infinity: we already do -- they are called Ubuntu RTM silos, and people test them all the time
<infinity> AFAIK, the goal is to drop it like a hot potato and move to utopic as soon as we can.
<pitti> infinity: I certainly hope we can drop it again
<pitti> infinity: but then I don't understand why we spent so many manweeks of making sure that our infrastructure can get along with that separate distro
<pitti> it seems like an awful lot of investment for something which just lasts for a few weeks
<infinity> The silo argument is a developer workflow thing, that's a little less interesting, as I'd hope our developers know how to add apt sources without a magic tool.
<infinity> pitti: It was the lesser of many potential evils.  *shrug*
<pitti> so how do we tell if we are running on RTM/14.09 or Ubuntu/Utopic without os-release/lsb-release?
<infinity> pitti: apport could know by being forked.
<pitti> infinity: you could say the same about gcc..
<infinity> pitti: Yes, but gcc doesn't need to know, does it?
<pitti> or aptdaemon, or add-apt-repository, or what not
<infinity> pitti: You're trying to solve a specific problem here (you want bucketing to be different, though I'm not sure I actually see much value in that).
<pitti> the entire point of having a correct os-release is that all our tools can look at it and not hardcode stuff
<pitti> infinity: you said above that changing os-release breaks it?
<infinity> "it"?
<pitti> gcc
<pitti> infinity | GCC, for instance (to pick one at random) picks its defaults based on release codenames.
<infinity> I said it could potentially do so.  I'd have to look at debian/rules to be sure.
<infinity> It'll break llvm.
<pitti> so we need to grep RTM for usage of /etc/os-release, /etc/lsb-release, and lsb_release, and fix/hardcode stuff to use RTM/14.09 instead where appropriate
<infinity> It might even break llvm at runtime, actually, which is even more fun than breaking gcc at build time.
<infinity> pitti: I'm not sure I have the energy to discuss this tonight, but fundamentally, it feels like a waste of time to patch in support for a release that isn't going to get any ongoing support.
<pitti> infinity: I don't know about the support; it just feels like we have wasted the previous weeks if RTM isn't a longer-lived thing
<infinity> If it's a longer-lived thing, we failed miserably to achieve our goals.
<infinity> The point of the fork was just to give the rtm people a stable base to work against because their release target is a little over a month before Ubuntu's.
<infinity> Once utopic is out, RTM shouldn't be a thing anymore.
<infinity> And, indeed, it should upgrade to released utopic.
<pitti> infinity: so, don't get me wrong -- I'm ok with hardcoding stuff in apport and ignoring os-release if that's the smaller amount of work; the thing that just makes me grumpy is that now RTM is going to go away in a few weeks?
<infinity> pitti: Probably more than a few weeks, I imagine people will iterate on it for a little while, but it should go away shortly after utopic is released unless we're doing something wrong.
<infinity> pitti: Maintaining a long-term fork is something we don't have the resources to do, and we'd be crazy to try.
<pitti> it was so much pain and effort to get that working, and doing an entirely new release seems absolutely pointless then
<pitti> s/release/distro/ I mean
<pitti> a new release would have been right
<infinity> pitti: The other option was snapshot the entire archive and maintain it without the help of our usual tools, either in an external repo or a giant PPA of doom.
<infinity> pitti: The derived distro path was more elegant.
<pitti> but that's what we call a distro release..
<infinity> pitti: A new release causes some issues in that our release model is linear.
<pitti> -updates?
<infinity> Err, how would that help?
<pitti> and 14.09 is before 14.10, so no problem there
<pitti> and if people want to backport fixes from utopic to 14.09, there's 14.09-updates
<pitti> anyway, this is all moot now
<infinity> You mean everything targeted to 14.10 from now until release would go in updates, so as to not break the release pocket?
<infinity> Cause, ew.
<pitti> err, no?
<pitti> utopic wouldn't change, but some fixes we might want in the 14.09 release, and then utopic is the next release after 14.09
<infinity> That would be two open development releases.
<pitti> I don't see how it is any different than trusty/utopic, except that it's not 6 months apart but 5, then 1
<infinity> Which breaks the world.
<infinity> Or opening, forking, and immediately "releasing" 14.09, and then doing everything as SRUs.
<pitti> and 14.09 would be stable now, and can receive SRUs
<infinity> That might have worked.
<infinity> But we didn't do it.
<infinity> So, whatever. :P
<infinity> It also lends even more legitimacy to an illegitimate thing.
<infinity> Like, we wouldn't want it on archive.u.c, etc.
<infinity> pitti: Anyhow, I agree it's all a mess, but it's the best mess we could come up with when pressed for options.
<pitti> so now we have two entirely different distros and releases which both claim to be Ubuntu 14.10
<pitti> I guess an RTM archive grep is in order then
<infinity> pitti: My only advice on the matter is to not put too much effort into trying to make it messier.  The RTM archive should focus mostly on polishing the user experience as much as it can, the rw/apt-ppa/etc experience might not need to be perfect.
<zyga> infinity: 3.2 is good to go
<dholbach> good morning
<infinity> zyga: Ta.
<lifeless> pitti: DPMT ftw
<pitti> lifeless: I'm not officially in that team
<pitti> hence I'd rather ask before
<lifeless> pitti: ah
<lifeless> pitti: so I *think* we moved it into that team
<pitti> lifeless: yes, it is
<lifeless> pitti: so - long as you follow the protocol (commit metadata to svn etc) I'm cool with you doing occasional uploads; I can't speak for the whole team of course
<pitti> lifeless: yes, of course I'd use the svn
<pitti> lifeless: uploaded and committed to svn
<lifeless> pitti: cool
<tjaalton> hrm, sbuild post-build phase triggers some security warning on trusty, started recently..
<tjaalton> "problem with defaults entries"
<tjaalton> maybe messed things up myself, but no idea where
<Riddell> any ppc64el experts able to take a look at sflphone?
<Riddell> https://launchpad.net/ubuntu/+source/sflphone/1.3.0-1ubuntu3/+build/6263494/+files/buildlog_ubuntu-utopic-ppc64el.sflphone_1.3.0-1ubuntu3_FAILEDTOBUILD.txt.gz
<flexiondotorg> cjwatson, May I DM you quickly?
<flexiondotorg> Not a support request.
<mardy> Laney: hi! Can I bug you for bug 1029289?
<ubottu> bug 1029289 in Online Accounts: Account plugins "Need to authorize my google account each time I boot the computer" [Critical,In progress] https://launchpad.net/bugs/1029289
<Riddell> who looks after usb-creator these days? there's a fix just been proposed
<seb128> Riddell, nobody
<Riddell> yes I susected as much
<Riddell> this seems like quite a failing of us all :(
<seb128> Laney said he would be interested to look at some of the issues on it iirc (but I might be wrong), I don't think he's interested to become officially maintainer/reviewer though ... maybe check with slangasek if foundation has somebody would could take over it instead of xnox (might need to wait for them to hire somebody)
<sergiusens_> pitti: flo is the codename for the "nexus 7 2013 wifi" device
<sergiusens_> pitti: the hint is not being applied when looking at the object path for the blocks over udisks2
<Saviq> sergiusens_, hey, ciborium is really moody about failing to add a storage device... that I don't have any in the first place
<ogra_> moody ?
<ogra_> for me it fails all the time on first attempt after reboot
<ogra_> but then pisk up the SD just fine
<ogra_> *picks
<Saviq> ogra_, yeah, I don't have any SD
<Saviq> ogra_, and mako doesn't even *do* SD
<sergiusens_> Saviq: flo?
<Saviq> sergiusens_, mako and krillin
<Saviq> ogra_, it's messing with our autopilot tests
<sergiusens_> Saviq: really? mako?
<sergiusens_> Saviq: image?
<Saviq> sergiusens_, https://docs.google.com/a/canonical.com/file/d/0B32jwBcbaPloRGo5OGd3MmhhQVk/edit
<sergiusens_> Saviq: not supposed to display anything on mako
<Saviq> sergiusens_, latest devel-proposed
<sergiusens_> Saviq: rtm?
<Saviq> sergiusens_, no, devel-proposed, but the same happens on krillin rtm
<Saviq> sergiusens_, r213 mako
<sergiusens_> Saviq: I've been running on mako for a week before this landed
<Saviq> sergiusens_, rtm@r4 on krillin
<Saviq> sergiusens_, run the unity8 ap test, maybe that triggers it (it restarts unity8 repeatedly)
<sergiusens_> Saviq: you can "stop ciborium" to get it out of the way; I'm going to need some logs
<sergiusens_> Saviq: is this on the ci dashboard?
<Saviq> sergiusens_, not *yet*
<Saviq> sergiusens_, local run
<Saviq> sergiusens_, but I've seen it on our ci too
<sergiusens_> Saviq: can you pass me the /home/phablet/.cache/upstart/*ciborium* files in there
<Saviq> sergiusens_, https://drive.google.com/drive/#folders/0B32jwBcbaPloWGVVZmE3dkdlM0k
 * Saviq abuses drive, wonder if it will allow downloading as an archive
<Saviq> nope
<Saviq> sergiusens_, http://people.canonical.com/~msawicz/ciborium/ as well
<Saviq> sergiusens_, looks like it's trying *all* the unmounted mmc partitions
<sergiusens_> Saviq: it's like the udev rule isn't hitting you
<Saviq> sergiusens_, does ciborium ship a rule?
<sergiusens_> Saviq: no, lxc-android-config does
<sergiusens_> Saviq: gdbus introspect --system -p -d org.freedesktop.UDisks2 -o /org/freedesktop/UDisks2/block_devices/mmcblk0 /org/freedesktop/UDisks2/block_devices/mmcblk0p2 | grep System
<sergiusens_> Saviq: that should return true
<sergiusens_> well, not return, be
<Saviq> sergiusens_, false
<Saviq>       readonly b HintSystem = false;
<sergiusens_> Saviq: grep UDISKS_SYSTEM /usr/lib/lxc-android-config/70-mako.rules
<sergiusens_> on mako
<Saviq> sergiusens_, ACTION=="add", KERNEL=="mmcblk0*", ENV{UDISKS_SYSTEM}="1"
<sergiusens_> Saviq: bah; ogra_ is udev racy?
<sergiusens_> Saviq: in all my reboots I haven't seen this problem on mako nor krillin
<Saviq> sergiusens_, lemme reboot then
<sergiusens_> Saviq: still, you shouldn't be getting that
<Saviq> sergiusens_, now it's true
<ogra_> sergiusens_, it shouldnt be ... though note that we shut it down while bringing up the container during boot
<sergiusens_> hmm, so there is a race somewhere; I wonder where...
<Saviq> sergiusens_, let me see if it becomes false during my test run or is it sometimes on reboot
<ogra_> (but you know that)
<Saviq> sergiusens_, it was my first boot after flashing I think, will try that hypothesis too in a moment
<sergiusens_> ogra_: yeah; I might do something hackish and ignore mmcblk0 if this becomes a huge issue and can't figure out that race
<sergiusens_> Saviq: first boot indeed takes longer; was it with a wipe?
<sergiusens_> I'll give that a go
<ogra_> sergiusens_, yeah, i guess it is safe to ignore the rootfs device ... i wouldnt blindly take mmcblk0 though but check where / lives
<Saviq> sergiusens_, no wipe, no
<sergiusens_> click hooks ran though?
<Saviq> sergiusens_, everything else seemed fine
<Saviq> soo... I've my home on SSD{ btrfs{ cryptfs } }, whenever I'm flashing the phone, or doing something with large files, I get iowaits, some apps would go grey for a few seconds... who can get me ideas how to debug this?
<Saviq> sergiusens_, can't get it to be false any more of course
<sergiusens_> Saviq: just when you want things to go wrong, they go right :-P
<Saviq> sergiusens_, story of my life
<Saviq> wait
<Saviq> ;)
<sergiusens_> I'll wait
<sergiusens_> Saviq: even if you can't repro, can you ubuntu-bug ciborium and lxc-android-config with this info?
<Saviq> sergiusens_, will do
<tedg> jodh, Was going to try to build your cgroup fix for upstart, is there an easy way to get a deb for it?
 * tedg is spoiled by bzr bd
<tedg> :-)
<jodh> tedg: autoreconf -fi && ./configure && make. Then tweak /usr/bin/ubuntu-touch-session to run 'exec /path/to/your/init/init --debug --user 1>&2'
<jodh> tedg: note that we still need to fix systemd-shim though.
<tedg> jodh, Ah, cool, I think I got the deb building.
<tedg> jodh, We modified the cgmanager upstart job so that it'll start before the shim.
<jodh> tedg: yeah I know, but see the last sentence in my comment: https://bugs.launchpad.net/ubuntu-app-launch/+bug/1357252/comments/34
<ubottu> Launchpad bug 1357252 in upstart "upstart can race with cgmanager when using remove-on-empty" [Undecided,In progress]
<jodh> tedg: hallyn tells me that desrt|pdx is the guy we need to poke with a stick
<tedg> jodh, I think we're okay in that we clean up the cgroup in the application job today.
<tedg> jodh, We make sure all the processes are gone in post-stop
<jodh> tedg: my understanding from discussing with hallyn yesterday was that systemd-shim is cleaning up the cgroups (via cgmanager) before the overall job has finished with them.
<tedg> jodh, Because they were set as remove-on-empty, but we're not setting that until the job is done now, right?
<jodh> tedg: upstart isn't setting that until the job has completed, correct. However, systemd-shim sets remove-on-empty at the logind session level and the upstart session-init inherits that. It's not something upstart can deal with - it's a bug/limitation/feature of systemd-shim :)
<tedg> jodh, I'm a bit confused, so wouldn't that only effect the overall session cgroup? Or does it mean that every cgroup in that session cgroup has the remove-on-empty property set?
<jodh> tedg: I believe so. hallyn ?
<SonikkuAmerica> Is there an instruction list for what ubiquity does when it installs and then removes itself from the target system? ubiquity installed everything, then crashed installing GRUB 2. I booted the partition by hand, and now I need to know what packages to clean up. (This is Utopic, by the way)
<SonikkuAmerica> (Or is this a support question for #ubuntu+1 ?)
<jodh> tedg: anyway, what you'll find is that my branch works sometimes, but you'll see the occasional "failed to start job" error and if you look in /var/log/upstart/cgmanager.log you'll see entries like: http://paste.ubuntu.com/8179550/
<jodh> tedg: note the uid of the removal requestor - it's not the session init, it's systemd-shim.
<jodh> tedg: well, actually it's cgmanager.
<tedg> Hmm, okay.
<tedg> Let's see how it does on the uitoolkit tests.
<jodh> tedg: I've raised bug 1363134 (unclear if bug 1355966 is supposed to cover the same request?)
<ubottu> bug 1363134 in systemd-shim (Ubuntu) "systemd-shim needs to grow support for abandoncgroup and stopsession " [Undecided,New] https://launchpad.net/bugs/1363134
<ubottu> bug 1355966 in systemd-shim (Ubuntu) "Implement AbandonScope (etc)" [Medium,Triaged] https://launchpad.net/bugs/1355966
<Laney> mardy: there's a new evo/e-d-s 3.12 point release that I want to get in soon-ish
<jodh> tedg: an alternative may be to have cgmanager grow a unset-remove-on-empty verb, but that's just horribly fugly.
<shadeslayer> could someone explain why I can't write /etc/sddm.conf like this : http://paste.kde.org/pmy4cqrdp
<directhex> shadeslayer: because of what you are and aren't sudoing
<shadeslayer> right
<directhex> shadeslayer: you are only sudoing "sudo log-output -t user-setup chroot /mnt $ROOT cat <<EOF" - the "> /etc/sddm.conf" is done by the host shell
<shadeslayer> mhm
<frezix> hi, I'm doing a netinstall and I'm now at this stage - http://imgur.com/ba9qcCc - how do I remove that partitioning scheme and start fresh?
<frezix> I've asked this in #ubuntu also but no one seemed to have an answer
<shadeslayer> directhex: any recommendations on how to fix it
<directhex> use "| sudo tee filename" as your output mechanism for things
<shadeslayer> directhex: yeah tried that, didn't work
<shadeslayer> writes to host machine
<shadeslayer> so I used sh -c
<shadeslayer> but now I'm unsure how to extract the username from the host
<directhex> add speech marks around what you want to sh -c ?
<shadeslayer> s/host/target/
<hallyn> tedg: jodh: remove-on-empty is inherited on mkdir from the parent cgroup
<tedg> hallyn, Can Upstart change that?
<hallyn> tedg: not currently
<hallyn> tedg: I'm not sure whether ti's better to provide an API method for that in cgmanager, or to just fix systemd-shim
<hallyn> i think the latter
<jodh> hallyn: +1.
<tedg> I guess it seems like a reasonable default to me for systemd to set.
<hallyn> i just wish someone more competent would do it :)  but maybe if i can get rharper to look at the qcow2 corruption i can fast-track the systemd fix
<hallyn> tedg: no, i tshouldn't be needd, logind does ask fo cleanup
<hallyn> we just set remove-on-empty bc we ignore the cleanup requests
<hallyn> it's purely a dbus callback issue, *should* be simple
<rharper> hallyn: stop the presses! qcow2 has data corruption issue ?
<tedg> hallyn, Oh, okay.
<hallyn> rharper: holy cow.  yes, since 1.7
<hallyn> rharper: it's killing me!
<rharper> hallyn: that's why we never approved qcow2 use while I was at the LTC for IBM products
<rharper> we pushed in QED as a format because qcow2 had so much trouble;  it's improved significantly, but with all of the features... hard to ensure you've found all of the issues
<hallyn> rharper: sorry, another meeting, if you're willing to look at it i'd *love* to talk to you in a bit about it
<hallyn> rharper: but no, this is regression.  it was fine in 1.5
<hallyn> that's why security team (jdstrand and sarnold) always run the old 1.5 version!!!  crazy
<rharper> if it's  regression I'd think we could lean on kwolf and stefanha in #qemu once we have a proper test case/reproduce
<rharper> hallyn: going to head out in a bit, but post lunch we should chat...
<doko> jibel, pitti: the python2.7 and python3.4 autopkg tests show regressions, versions which suceeded before. any changes in the test setup?
<cjwatson_> flexiondotorg: If you're going to send a private message, just do so.  Don't ask first in a channel and then wait for timezones to match before I can respond.
<hallyn> rharper: so there's a few open bugs on the same issue, but it's basically https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1292234
<ubottu> Launchpad bug 1292234 in qemu (Ubuntu) "qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)" [High,Confirmed]
<hallyn> rharper: i have NOT reproduced it with his testcase msyelf.  what i HAVE had is two (or more) regular uvt-kvm vms go corrupt as i was using htem heavily (in one buildint-testing libvirt many times, in another lxc)
<hallyn> in the latest one, i suddenly found that ~/build3 was actually poinging to the code in ~/build2 (!).  Then I tried to reboot to see if it would fix it, but it wouldn't reboot
<hallyn> so if i could only reliably reproduce then i would bisect.  but i can't reliably reproduce.  only when i'm trying ot get something done, after hours of work :)
<hallyn> i'm going to try just almost-filing the disk right now to see if htat is the trigger.
<hallyn> rharper: when yo uget back we can either chat here or do a hangout.
<sarnold> hallyn: good idea, I seem to recall at least one of my qcow2s was huge
<hallyn> add 3G of /dev/zero, leaving 1.4G free, let's see how that works
<hallyn> hopefully qcow2 doesn't compress it all away :)
<cjwatson> Riddell: sflphone> That looks like it just needs a config.guess/config.sub update in that subdirectory.
<jdstrand> hallyn: you are using snapshots, correct? eg:
<jdstrand> $ qemu-img info ./sec-utopic-amd64.qcow2
<jdstrand> image: ./sec-utopic-amd64.qcow2
<jdstrand> file format: qcow2
<jdstrand> virtual size: 8.0G (8589934592 bytes)
<jdstrand> disk size: 11G
<jdstrand> cluster_size: 65536
<jdstrand> Snapshot list:
<jdstrand> ID        TAG                 VM SIZE                DATE       VM CLOCK
<jdstrand> 1         pristine                  0 2014-08-25 18:15:09   00:00:00.000
<hallyn> jdstrand: i'm using your exact snapshotting recipe, with the forhallyn.img you provided, yes.  tha thasn't worked.  what has resulted in corruption for me is simple vms using qcow2 with a backing file (but no snapshots)
<hallyn> zul: hm, getting a bunc hof failures and test skips, looks like virtinst problem.  i dn't see a python-libvirt 1.2.7, could that be the problem?
<zul> i dont have libvirt-python 1.2.7 yet
<zul> gimme a sec
<jdstrand> hallyn: interesting. I hope there aren't two bugs-- one in bs and one in snap...
<rharper> hallyn: looking at the bug... once I'm up to speed, let's talk
<rharper> jdstrand: hallyn one question on the images -- is it only reproducable using the images created back on 1.5 with newer qemu ?
<hallyn> jdstrand: yeah, it's not impossible.  also i'm back runnign with ksm, so it's possible that my bs bug ends up being a ksm bug
<hallyn> rharper: no i don't thin kthat's the case.  pretty sure jdstrand can ruin any new image he creates
<sarnold> :)
<rharper> ok, that's useful to know;
<rharper> and we're always using the qemu/libvirt defaults for cache mode on the disk image, and the host filesystem ?
<rharper> no ones doing fancy dev stuff like cache=unsafe and disabling barriers on their fs ?
<hallyn> rharper: pretty sure not.  sarnold: uvt doesn't do any o fhtat right?
<rharper> uvt can
<hallyn> hell i'v eonly had failures with the defaults!
<hallyn> when i run kvm by hand i'v enever had a failure, and by hand i always do 'cache=unsafe' :)
<rharper> using uvt or just libvirt ?
<sarnold> rharper: the security team uses marc's uvt, not robie's uvt..
<hallyn> using uvt
<hallyn> no, uvt-kvm
<hallyn> *I* us uvt-kvm, security team uses uvt
<rharper> ok, then someone who knows uvt needs to help specify what cache mode is being selected (or if none at all in qhich case we get cache=writethrough
<sarnold> I don't see any "unsafe" in /etc/libvirt/**
<rharper> as well as file systems in use and any uptes
<hallyn> sarnold: filling up a bunch of disk didn't help yet.  lemme fill it up more and upgrade from t->u
<rharper> sarnold: any cache= values?
<hallyn> sarnold: ^ can you provide that info?
<hallyn> (else i can d/l the script and dig)
<sarnold> rharper: no "cache" in /etc/libvirt/** either
<rharper> if someone has a ps aux output from a vm run by uvt, that'd be best
<sarnold> rharper: my host filesystem is ext3, rw,relatime,data=ordered
<rharper> k
<rharper> can I get the sec team uvt anywhere ?
<sarnold> rharper: command line: http://paste.ubuntu.com/8181058/
<sarnold> rharper: there's a fair amount of other setup work necessary, all documented here: https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#preview
<sarnold> sigh, of course leaving off the #preview :)
<rharper> sarnold: and where do you get your original/pristine images?
<rharper> ah, cd images
<sarnold> rharper: 'uvt new' makes them from downloaded ISOs
<rharper> for the releases
<rharper> right
<rharper> does some sort of auto install ?
<sarnold> yeah
<rharper> k
<rharper> so the forhallyn image is presumable one of those pristine images
<sarnold> it started as one, though I don't know what, if anything, might have been done to it along the way
<sarnold> the two images I gave hallyn started that way but had been apt-get dist-upgraded several times, snapshotted/restored several times..
<tvoss> pitti, you around?
<jdstrand> rharper: see the end of the description-- it doesn't seem related to machine type. I'm not 100% sure I tried on 2.0 to create a machine and try to reproduce, but I think I did
<jdstrand> rharper: here is typical xml: http://paste.ubuntu.com/8181138/
<jdstrand> rharper: so we aren't specifying cache mode. host fs is ext4 for me, along with whatever is the default in the guest (ie, ext4)
<jdstrand> rharper: the forhallyn image was generated using the standard security process with uvt, yes
<rharper> jdstrand: thanks for the info,
<rharper> brb, need to grab the kids
<jdstrand> rharper: oh I had to have tried to create a vm on 2.0, otherwise I wouldn't have been able to test pc-i440fx-1.7 and pc-i440fx-2.0 (duh)
<hallyn> so, 'git log --pretty=oneline v1.5.0..v1.7.0 block/qcow2 | wc -l' says only 69 commits.  i guess i'll actually look at each :)
<hallyn> right and what you gave me was pc-i44fx-2.0
 * jdstrand nods
<jdstrand> I'm highly motivated to have this fix. the trick is that I rely on qemu so heavily I'm not always in a place where I can lose my VMs
<jdstrand> (eg, if I am doing dev work or security work and using vms, I can't really test new versions on that day)
<hallyn> maybe the key here is looking at the type sof things which those 69 commits change, and trying to write testcases for edge cases there
<jdstrand> hallyn: we can do bisects
<hallyn> jdstrand: alternatively, perhaps i can promote the bisecting by pushing a set of binaries (say 10-20/day) with which you can start bisecting :)
<hallyn> jdstrand: *I* can't :(
<hallyn> we need to reliably reproduce.
<jdstrand> well, if you produced binaries that included commit 35 of those 69, sarnold and I could try to repoduce
<hallyn> kinda got my eye on the commit "qcow2: Batch discards"
<jdstrand> it just might be slow going on some of the feedback
<hallyn> jdstrand: yeah, it might be worth doing.  the only bitch of it is that it destroys th eidea of 'bisecting', as we have to build a lot more than log_2(N) binaries :)
<jdstrand> funny thing is, it occurred to my I should really be using precise's qemu instead of saucy, since it is actually security supported :)
<hallyn> heh.
<jdstrand> hallyn: well, could just do bisects relative to those 69 commits
<hallyn> that's what i use on my big server
<hallyn> yeah
<hallyn> ok what the heck i'll build+publish them.  you'll just need a few tweaks to your apparmor policy, but i think you can handle those :)
<hallyn> oh no yo udon't, you'll just install under /usr/bin.  duh
<jdstrand> hallyn: if we get to the point where we know which of the 69 first had it, then we can bisect further on the other commits between the last good of the 69 and the first bad of the 69
<hallyn> yeah.  let me script up the building of those binaries real quick
<hallyn> (haha, what are the odds they'll build easily enough to script)
<jdstrand> yeah, I was wondering how easy that would be
<jdstrand> it is one thing having a plan, it is quite another implementing it :)
<hallyn> jdstrand: trying http://paste.ubuntu.com/8181365/
<hallyn> that *should* let me fix it if there is a build failure.
<hallyn> guess i need a 'git reset --hard HEAD' at top of loop so the git checkout master wlil succeed
<hallyn> (if it fails)
<hallyn> first binary delivered
<hallyn> think i'm gonna go get some coffee and check on this when i get back
<sarnold> no libraries needed?
<rharper> jdstrand: qcow2 corruption is rarely related to machine type, rather it's likely to be one of the many feature flags;  I've not yet found a tool that dumps the flags, but they matter w.r.t behavior, in particular, I'm looking at lazy_refcount which delays metadata updates of qcow2 (which is wehre 99.9999% of corruption comes from)
<hallyn> sarnold: hm.  i don't think so.  i was testing without those yesterday
<rharper> the compat mode determines what features accessible based on which qemu version you'r running with;  pre 1.0, 1.0, 1.1, and on up.
<hallyn> rharper: that suggests that the commit "qcow2-refcount: Repair shared refcount blocks" might be to blame
<rharper> have we tried qemu-img repair on these iamges?
<rharper> ie the non-bootable ones?
<rharper> next I was goign to run the qemu-img check on each one to see if it detected metadata errors
<hallyn> sarnold: you have a corrupted one sitting someplace rharper can get to it right?
 * hallyn REALLY needs some coffee, biab
<rharper> it will be interesting to see what format of level (qemu-img info file) these are, versus what gets created on new systems
<jdstrand> rharper: right-- I was simply saying that I couldn't have created/run a 2.0 machine type on 1.5, that I must've used 2.0 for that, and since I am otherwise using defaults, that info might be helpful to you
<frezix> hi, I'm doing a netinstall and I'm now at this stage - http://imgur.com/ba9qcCc - how do I remove that partitioning scheme and start fresh?
<rharper> jdstrand: ok -- but machine type has nothing to do with the qcow2 image, at best it's machine type could suggest what level of qemu you have
<sarnold> hallyn,rharper, yeah, lillypilly.canonical.com:~sarnold/sec-precise-amd64.qcow2.bz2.sig (and the file without .sig) and sec-trusty-amd64.qcow2.gz.sig (and the file without .sig)
<rharper> but they're independent
<frezix> (Is this the right channel to ask this also?)
<rharper> sarnold: can I get that from chinstrap ?
<sarnold> rharper: I believe so
<sarnold> frezix: try arrow-down to see if the individual partitions can be selected?
<rharper> sarnold: fetching... thanks
<jdstrand> rharper: right, that is all I was trying to suggest to you :)
<rharper> they typical pattern is images created on older qemus tend to show corruption with newer qemus because bugs have been fixed in newer qemu, but their behavior is different.
<rharper> which I think is exactly what was originally seen (older 1.5 images, upgrade to trusty, boom)
<rharper> the more interesting one is if you can create new iamges on the latest qemu, and see the same corruption; which it sounded like, but not clear to me if that's confirmed.
<jdstrand> rharper: that is confirmed
<rharper> one possible answer is that the newer images are created in compat mode, versus the latest
<jdstrand> I am not being clear
<frezix> sarnold: these are the 3 options when I select individual partitions - http://imgur.com/mrObbpD - note that when selecting "Erase data on this partition" it only erases the data instead of converting that partition to unallocated space.
<jdstrand> I cannot create a vm with a -2.0 machine type unless I am running qemu 2.0. since I stated in the description that I specifically tested machine of different machine types, I *must* have used a newer qemu to create/run/corrupt the image
<sarnold> frezix: dang.
<jdstrand> the forhallyn image used 2.0
<frezix> when I'm at that partition choosing menu, choosing "Undo changes to partition" also doesn't seem to have any effect. when I went into the "Configure encrypted volumes" option, this is what I got - http://imgur.com/01GCq8Q - which pretty much explains much of what I'm facing.
<jdstrand> I used whatever defaults virtinst uses
<rharper> jdstrand: ok -- but the last part of your statement matters, do you know if you *created* the image with newer qemu, or only observe the failure on newer qemu.
<sarnold> rharper, off to lunch...
<rharper> sarnold: k
<jdstrand> rharper: I had to *create* on newer qemu otherwise the xml would have a -2.0 machine type
<frezix> I'm now wondering how I can still remove those partitions (I do know the passphrase)
<jdstrand> would not* have
<jdstrand> rharper: see the description
<jdstrand> qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2
<jdstrand> qemu-img info ./forhallyn-trusty-amd64.img
<jdstrand> image: ./forhallyn-trusty-amd64.img
<jdstrand> file format: qcow2
<jdstrand> virtual size: 8.0G (8589934592 bytes)
<jdstrand> disk size: 4.0G
<jdstrand> cluster_size: 65536
<jdstrand> Format specific information:
<jdstrand>     compat: 0.10
<jdstrand> rharper: then see 'Steps to reproduce'
<rharper> jdstrand: ok -- sorry for being obtuse, just trying to understand the failure scenarios w.r.t  image creation;
<rharper> jdstrand: fair enough;
<jdstrand> the step sto reproduce says I created the forhallyn vm with 2.0
<jdstrand> I forgot I wrote that myself, so it didn't help the conversaton
<frezix> damn wifi
<frezix> did I miss anything?
<frezix> so during a netinstall, if it's not possible to remove encrypted LVM partitions (even when passphrase is known), would this be considered a bug?
<Laney> bah
<desrt|pdx> Laney: hm?
<Laney> offlineimap trashed my maildir
<desrt|pdx> :(
<rharper> sarnold: your corrupted image is odd;  none of the qcow2 metadata is corrupt, but the guest OS snapshot (and original) data is hosed;
<rharper> jdstrand: in your original comment, when you say revert to 1.5, you mean for the whole sequence of operations;   (all of the create, snapshot, revert) etc... you can use newer libvirt but need to have older qemu ?
<tedg> bdmurray, Do you know when the next whoopsie release is expected?
<jdstrand> rharper: I just instal the old qemu 1.5 packages. I have to recreate the VMs that are corrupted. for the others, I usually adjust the libvirt xml to use a 1.5 machine type
<rharper> right, ok
<jdstrand> but I don't usually have to recreate them
<jdstrand> I think that all works ok cause we are on compat 0.10
<rharper> jdstrand: and the corrupted images don't boot any better in 1.5, correct ?
<jdstrand> I'm not 100% sure I tested that
<rharper> ok, with this sort of corruption, I would expect them to fail on 1.5 or anywhere
<jdstrand> I think I may have always just recreated them
<jdstrand> cause, like hallyn pointed out, the corruption seems to happen at precisely the time it isn't convenient and you are rushing to get back to a usable state :)
<rharper> jdstrand: your local system does this at will, this recreates with your steps elsewhere ?
<jdstrand> what do you mean by elsewhere?
<jdstrand> another host machine?
<bdmurray> tedg: I uploaded one today. Are you looking for one after that?
<rharper> jdstrand: yes
<rharper> another host machine
<jdstrand> rharper: I have not, but sarnold has the same corruption
<rharper> k
<tedg> bdmurray, Heh, no I don't think so. You're just ahead of me.
<bdmurray> tedg: I try
<tedg> bdmurray, Thanks! Excited for moar data!
<hallyn> jdstrand: sarnold: if you wanna start, the most recent 7 suspect commits are available at http://people.canonical.com/binaries.[0-6]
<hallyn> with suspect being defined as 'a commit which affected block/qcow*"
<jdstrand> hallyn (and sarnold): I guess you mean http://people.canonical.com/~serge/binaries.[0-6]
<hallyn> yeah
<hallyn> sorry
<jdstrand> np :)
<hallyn> i can't believ how smoothly the builds are going, only had to correct 2 so far (after disabling spice at least)
<jdstrand> hallyn: it is because you are awesome
<hallyn> saving that for my i-need-an-uplift days :)
<hallyn> -12 pushed
<rharper> jdstrand: sarnold have you tried virsh resume on those images?
<rharper> instead of virsh start as I see in the instructions ?
<rharper> internal snapshots contain guest ram that's not yet flushed to disk
<sarnold> rharper: no, I almost never interact with 'virsh' directly
<rharper> but the corrupt image you handed me was an internal snapshot
<rharper> which means it holds both guest ram and disk data
<rharper> hrm, but the steps have the guest shutdown...
<rharper> that should be fine, ok
 * rharper keeps moving
<bdmurray> tedg: oh, I was wondering do we need ProcMaps for RecoverableProblems?
<tedg> bdmurray, No, I don't think so.
<sarnold> rharper: we quite often use "uvt stop -rf" to just quickly "yank the power" and revert to the snapshot, so next time we need it, it is 'clean' and ready to go -- I believe that works out to virsh "destroy" followed by virsh snapshot-revert
<sarnold> rharper: probably when those images failed to boot, I just used uvt stop -f on them to kill them quickly but not revert the disk image
<tedg> bdmurray, Can't wait for that to hit, I've got this recoverable error for bad appid, but I don't know which one. Going to be exciting to find out.
<bdmurray> tedg: is there a betting pool?
<tedg> Heh, I don't think that we could make one now because some people have access to the database and could know the results before they trickle through :-)
<bdmurray> Are you calling me a cheater?
<tedg> No, no, I was more worried about ev.
<bdmurray> lol
<rharper> jdstrand: sarnold: in your use-case, do you ever save disk state after the upgrade and shutdown?  as in, do you want to "merge" the updates applied back into the original disk ?
<rharper> or do you always want to throw the delta from pristine away ?
<jdstrand> rharper: that is a use case
<jdstrand> rharper: basically, we do this
<jdstrand> we generate i386 and amd64 vms for all supported releases
<jdstrand> we use uvt to do that and use cd images
<jdstrand> then we create the pristine snapshot
<rharper> right, your base images
<rharper> yep
<jdstrand> yep
<jdstrand> then, we go along and test security updates, etc
<jdstrand> then will revert back to pristine
<jdstrand> however, they get out of date after not too long
<jdstrand> so we have an 'uvt update' command
<rharper> that corresponds to the "boot after pristine snapshot, dist-upgrade;  which includes applying latest security updates"  ?
<jdstrand> that reverts to pristine, starts the vm, apt-get sit-upgrades it, etc
<jdstrand> then shuts it down cleanly
<jdstrand> then does a new snapshot of the same name
<rharper> but each time you want to start at pristine and then apply dist-upgrade latest ?
<jdstrand> rharper: re correspons> yes
<jdstrand> rharper: re each time> that is what our update command does, yes
<rharper> are you ever interested in the state of the VM after dist-upgrade after you have shutdown the VM (but before reverting the image back to pristine) ?
<jdstrand> rharper: but we are free to do vm configuration and then use 'uvt snapshot' to update the pristine image
<jdstrand> rharper: we are interested in that state
<rharper> if you don't actually want to inspect or boot the image after the updates are applied, I'd like mention -snapshot which writes deltas to a temporary file and is removed when the guest process exits, which would avoid any need to run snapshot commands on the image and would avoid touching the original file for writes at all
<rharper> ah, ok
<jdstrand> rharper: it is that state where we may update the pristine snapshot
<jdstrand> rharper: also, sometimes we like to leave a vm in a certain state so we can come back to it later
<rharper> maybe the names confuse me, you update doesn't commit the changes to the base, it removes them
<rharper> by my reading of your steps in the bug...
<jdstrand> for example, now I have a vm that is off but has loads of stuff for our apparmor landing in it
<jdstrand> rharper: ah, well the bug only describes how I was able to trigger this
<rharper> ok, but typically you'd want to keep the update around and merge the updates with the previous pristine, aka commit
<rharper> commit my changes to snapshot called pristine
<jdstrand> (it also wouldn't happen every time iirc; the steps I gave happen to trigger it most often
<jdstrand> our 'update' command will do that
<jdstrand> but we are free to 'uvt snapshot' whenever we want
<jdstrand> let me get you the bzr branch
<jdstrand> rharper: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt
<jdstrand> rharper: you might also be interested in: https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#Snapshotted_virtual_machines
<jdstrand> rharper: that more or less captures how we work
<sarnold> rharper: (the convention for the uvt commands is a function defined like "cmd_snapshot" or "cmd_update")
<rharper> jdstrand: so, update does:  revert to pristine (unless it doesn't exist);  boot vm do upgrade;  stop vm, delete snapshot named "pristine", then create a new one called "pristine" again...  which matches your bug commands
<rharper> heres what I don't know;   you're deleting the current snapshot after applying changes to the image;  it's not clear to me exactly what that does w.r.t internal snapshots;
<rharper> it seems strange to me to remove the previous snapshot before creating a new one and then just renaming.
<jdstrand> I actually didn't right this bit of code, but it does work with 1.5
<jdstrand> write*
<sarnold> was it done that way to placate earlier libvirts?
<xnox> infinity: where are you? =)
<jdstrand> as in, I can't say why it is implemented the way it is. mdeslaur may have had a reason
<jdstrand> sarnold: maybe? :)
<rharper> in the external snapshot world (which IMO is far safer to use than internal snapshots since you never touch your original file)
<infinity> xnox: Hiding.
<rharper> your update would be:  remove the snapshot file; create a new one;  do the update;  shutdown; and then you can commit the snapshot into the base image if you wanted to save it, or just delete it if you want to go back to pristine
<rharper> that would guarantee that you never corrupt your original image as long as you never committed the snapshot to the very base file that was created from the isos.
<jdstrand> rharper: I do know mdeslaur wanted to use pure libvirt commands. I had a shell implemention that would use backing stores underneath libvirt before libvirt had reliable snapshot functionality
<rharper> there's certainly a bug here,  as internal snapshots should be able to handle this;  the order of operations seems odd to me, but I need to look at the qemu implementation to see what happens on snapshot_blkdev_intenral w.r.t qcow2 refcounts
#ubuntu-devel 2014-08-30
<orbisvicis> I've added this ppa, and I'm wondering why I can't see "binutils-2.24-5ubuntu6", which according to launchpad is [1] successfully built [2] published last month [3] for trusty (my version) [4] built on i386 (my arch)
<orbisvicis> ppa:ubuntu-toolchain-r/test
<orbisvicis> according to https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+sourcepub/4281528/+listing-archive-extra
<cjwatson> orbisvicis: ubuntu-toolchain-r/test ~= ubuntu-toolchain-r/ppa
<cjwatson> er !=
<cjwatson> if you added only the former then you aren't going to see packages only published in the latter
<orbisvicis> oh
<orbisvicis> didn't realize they were different ppas
<orbisvicis> cjwatson: these are semi-official repositories. Do you know if it would be ok to mix test/ppa ?
<cjwatson> No idea.  doko might.
<orbisvicis> doko: ping
<orbisvicis> my hunch is probably
<cjwatson> I wouldn't have thought that it was really safe to use ubuntu-toolchain-r/test at all, though.
<cjwatson> You know, test builds and all.  Could be arbitrarily broken.
<orbisvicis> true but ubuntu-toolchain-r/test only updates gcc. afaik gcc is user-only, so it couldn't break the system or any packages
<orbisvicis> maybe dkms ?
<cjwatson> libgcc1 is used by practically every binary on the system.
<orbisvicis> hmm
<cjwatson> And there's no guarantee that the set of packages in a test PPA will remain constant
<cjwatson> Those are generally meant for build tests, not for people not familiar with the test in question to use
<cjwatson> Well, build and does-it-work tests
<orbisvicis> looks like I laready jumped off the deep end / no harm mixing in ppa as well.
<orbisvicis> I need a version of gcc that fixes a bug in 4.8.2 (trusty) and is compiled with cloog/isl support (test)
<orbisvicis> and I need a version of binutils that works with LTO (2.24.5ubuntu6), I think. autoconf is being dumb and ignoring AR=
<orbisvicis> ah well thanks
<orbisvicis> see how it goes after a reboot
<Ghost1227> quick question... in 14.04, the places sidebar was moved from nautilus to gtk, does anyone know what actual package that was moved to?
<Noskcaj> charles, Is there any chance of you porting indicator-power to upower 0.99 this cycle?
<Noskcaj> It's the only thing blocking the transition
<melodie> hi
<melodie> I would like to request a mentor for a remix project (Bento, aka Ubuntu Openbox Remix). I was wondering if an Ubuntu developer would accept this hard task? :D
<melodie> I just had the idea to jump here to ask, while filling a list of packages and default configuration files to be put into packages
<darkxst> melodie, hi
<melodie> the goal is to switch from doing remixes with end user tools such as Ubuntu builder to tools on build server
<darkxst> I suspect you might get more help here, asking about very specific problems that you are stuck on ;)
<melodie> darkxst you here! hello!
<darkxst> melodie, I am everywhere!
<melodie> darkxst will do eventuelly, later, for now I am working on the files which contain the lists
<darkxst> well if ~10 channels counts
<darkxst> melodie, you should be working on your seeds ;)
<melodie> yes it counts :)
<melodie> darkxst the lists come before seeds, I can't do seeds as long as I don't have everything packaged and I need to do packages starting from something: that's the lists
<melodie> the lists are online, I'll just update them now
<melodie> darkxst within a week or so I'll create a new account on the LP for the project and the ppa
<melodie> darkxst can we discuss in private for a few minutes?
<darkxst> melodie, ok, but ping me in 15mins
<melodie> done :D
<JEEB> I guess this is the utopic channel. I wonder if anyone else has a 1st gen macbook (the intel core duo one) around - I'm seeing various issues with the 3.16 kernel with it and I'd like to check if I'm the only one
<JEEB> basically I think it's a single issue (probably related to the intel video driver), and it happens during boot
<melodie> JEEB the Lubuntu team just asked for testers with Mac machines, you might want to check the qa-lubuntu ml
<melodie> ?
<melodie> https://launchpad.net/~lubuntu-qa
<JEEB> melodie, that seems to be PPC
<JEEB> at least looking at the thread name
<JEEB> > *** NEED PPC TESTERS URGENTLY *** (?)
<JEEB> and then there's ppc and amd64+ mac testers call
<JEEB> and I'm neither
<JEEB> core duo is IA32-only
<JEEB> :D
<melodie> possible, though my guess is that all users of machines having MAC are probably very welcome (and here is not specifically Unicorn so, you could also join #lubuntu on freenode)
<JEEB> ok
<JEEB> I just noticed #ubuntu-next was empty
<JEEB> so I looked at the InternetRelayChat wiki article linked @ #ubuntu's topic
<JEEB> so which is the utopic channel?
<JEEB> oh right
<JEEB> ubuntu+1
<JEEB> pardon me for the intrusion :)
<melodie> JEEB I am 100%, no 200% sure that at #lubuntu (and you can also join #phillw) your input will be used
<melodie> and that you will be very welcome
 * darkxst thinks most intel macs do not need a special build anymore
<darkxst> just use the amd64 images
<melodie> bye
<ricotz> cjwatson, hello, i hope you could take a look at https://launchpad.net/ubuntu/utopic/+source/granite/2014.2~b2-0ubuntu1 which is a rouge upload imo and overrides the original granite package
<ricotz> cjwatson, i would appreciate if this proposed package gets removed
<ricotz> zul, hi, please get your granite in utopic/proposed removed
<cjwatson> ricotz: oh goodness, yes.  done
<cjwatson> zul: ^- please use a package name that doesn't hijack something already in the archive
<ricotz> cjwatson, thanks!
<P-NuT> Hey all,
<P-NuT> Is there an article describing how to make status icons in the top bar?
<Sven_vB> i'm installing Ubuntu trusty from Live USB, and near "reticulating splines" i chroot into the target file system in order to adjust grub menu settings. my distribution name is generated by an expression that contains $(hostname -s), which currently yields "ubuntu". is there a way to change my invocation of ubdate-grub so that its lookup will yield the target hostname instead of the live session hostname, or do i absolutely have to chang
<Sven_vB> e the distribution lookup command?
#ubuntu-devel 2014-08-31
<Noskcaj> kirkland, Could you upload a new testdrive release. We probably should be supporting ubuntu at default
<Noskcaj> Maybe merge translations too
#ubuntu-devel 2015-08-24
<pitti> cjwatson: ah, they can all go, we dropped l-p-kde-* ages ago; I'll remove them
<pitti> Riddell: ^ or at least that's what I understood? We haven't built language-pack-kde-* for a long time, do we still need them?
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<Riddell> cjwatson:  pitti: language-pack-kde-foo still exists even if only to bring in the various language meta-packs
* Laney changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<pkern> http://ddebs.ubuntu.com/dists/ doesn't seem to offer -security ddebs. Where have they gone? (attn cjwatson)
<pkern> Ok, solved. Found https://lists.ubuntu.com/archives/ubuntu-devel/2015-March/038739.html
<pitti> pkern: just use -updates, they have everything too
<tseliot> pitti: hi, can you have a look at LP: #1487223 , please? Building the same sources in vivid works, however tests fail in wily
<ubottu> Launchpad bug 1487223 in ubuntu-drivers-common (Ubuntu) "1:0.4.7 FTBFS in wily-proposed" [High,Confirmed] https://launchpad.net/bugs/1487223
<pitti> tseliot: presumably due to new apt/python-apt; not right now, but queueing
<tseliot> pitti: can we disable those tests temporarily or force them to pass?
<pitti> no, we should fix them :)
<pitti> or investigate whether it actually broke something
<pitti> it's not at all clear whether it's the tests or ubuntu-drivers itself which needs adjustment
<tseliot> ok
<tseliot> but yes, we should always fix things
<tseliot> that's why I said temporarily
<pitti> well, there is no "temporarily"
<pitti> the touch tests are in a disastrous state and essentially not existing any more, because someone once temporarily disabled/ignored them
<pitti> "temporarily disabling tests" just doesn't work
<ogra_> well, it is always temporary ... until you drop them ;)
<tseliot> pitti: I'm not saying that we should ship with those tests disabled, and I'm not familiar at all with touch tests. Driver installation tests matter to me
<tseliot> pitti: apw reported that the package is blocking something else in the archive, that's why I suggested that as a temporary solution (and because I'll be off over the next two weeks)
<pitti> that can be done with britney hinting
<pitti> but it's not blocking anything else right now
<tseliot> I'm not familiar with that tool. If it's not blocking anything else, then I suppose it's ok for now
<tseliot> I have a bug fix queued up but that can wait
<robert_ancell> tjaalton, anpok needs some libinput patches for phone work (bug 1488064). Should we release those via Debian or branch the package and re-sync once they hit upstream?
<ubottu> bug 1488064 in libinput (Ubuntu) "add support for touchscreen contact properties" [Medium,Triaged] https://launchpad.net/bugs/1488064
<tjaalton> robert_ancell: 1.0 should be released soon, aren't those there already?
<robert_ancell> tjaalton, no these wont be in 1.0
<robert_ancell> tjaalton, unless you know how to pull some strings :)
<tjaalton> nah I think 1.0 is frozen
<tjaalton> only "technically critical bugfixes" will be added
<tjaalton> so ubuntu branch is fine
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<robert_ancell> tjaalton, there is not a current branch - should I make one?
<robert_ancell> (related question - do the branches get deleted once we go back into sync)
<tjaalton> robert_ancell: create one, old branches remain until the next time
<tjaalton> or forever
<robert_ancell> tjaalton, thanks
<tjaalton> they're cheap anyway
<sil2100> happyaron: ping
<pitti> Riddell: are you on the akonadi test regression? (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/akonadi/20150822_055228@/log.gz)
<pitti> there are several error messages there, but not sure which are expected
<slangasek> why is word highlighting in gnome-terminal in wily broken?
<slangasek> (colons are now treated as a word separator, so highlighting urls doesn't work right)
<kees> infinity: aw, you didn't open a bug for this https://launchpadlibrarian.net/144272351/scantool_1.21%2Bdfsg-4_1.21%2Bdfsg-4ubuntu1.diff.gz
<infinity> kees: I was a different man two years ago.  I've since found the path, and would file that bug in a heartbeat.
<infinity> kees: Praise FSM.
<infinity> kees: (What kind of Debian maintainer doesn't look at the PTS in two years and notice there's a delta? :P)
#ubuntu-devel 2015-08-25
<pitti> Good morning
<pitti> slangasek: this started a few weeks ago with (supposedly) a new vte3; I asked in #u-desktop, and apparently it's a deliberate (mis-)feature; one can configure it back on somehow
<pitti> micahg: FYI, I just committed a transition tracker for taglib
<pitti> micahg: (saw your linux-minidisc upload while going through the remaining rdeps)
<micahg> pitti: thanks, i probably should've done that
<micahg> I think amarok and liquidsoap are it
<pitti> micahg: so I think we're down to ... yes
<micahg> but liquidsoap needs ocaml deps, I think it's only one more, I'm building ocamlnet now
<pitti> micahg: are you already looking at liblastfm-ocaml-dev uninstallabiliyt?
<pitti> cool, thanks!
<micahg> though between the wait times, I don't think I'll get to ocaml-lastfm tonight, I think ocamlnet will be the last one I can do tonight, I can let you know when that's uploaded
<micahg> ok, uploaded, I think you can build ocaml-lastfm once that's published, I didn't get a chance to look into the amarok FTBFS
<pitti> http://people.canonical.com/~ubuntu-archive/transitions/html/html/taglib-g++5.html
<pitti> micahg: ^ FYI
<pitti> micahg: cool, thanks
<micahg> cool, thanks
<pitti> micahg: ocaml-lastfm uploaded
<Mirv> Laney: did you get autopilot team's ack on https://code.launchpad.net/~laney/autopilot-gtk/tests-wait-not-visible/+merge/268928 ? I'm just wondering whether the MP could be top-approved so that the silo would be possible to publish
<pitti> I didn't approve it yet as the tests still fail a lot on these IndexErrors
<Laney> Mirv: Not yet, I'm trying to test the silo first
<Mirv> ok.
<jpds> #cam-ib
<caribou> pitti: I see that you uploaded calibre for debian, would you have time to sponsor an upload for a trusty SRU ?
<caribou> pitti: LP: #1282898
<ubottu> Launchpad bug 1282898 in calibre (Ubuntu Trusty) "Broken Edit Metadata in Bulk commits 1.25.0" [Medium,In progress] https://launchpad.net/bugs/1282898
<pitti> caribou: sure! thanks
<caribou> pitti: this bug has been annoying me during my vacations, thought I'd fix it :-)
<cjwatson> slangasek,pitti: I go back and forward on whether it's more annoying for colon to be a word separator than not; I think I select file names out of grep output a little more often than I select URLs, and the former case works better with colons not being a word separator
<Laney> gnome-terminal has a "Copy Link address" item in its context menu too
<Laney> I got used to using that and I'm fine with the arrangement now
<mgedmin> (iirc there's a hidden gsetting that lets you make : a word-character in gnome-terminal again, but I also got used to the new default)
<mgedmin> https://bugzilla.gnome.org/show_bug.cgi?id=730632#c33 in case you want it
<ubottu> Gnome bug 730632 in general "implement UAX29-like word boundary detection for double-click select-by-word" [Normal,New]
<cjwatson> I normally use pterm anyway which has right-click to extend selection, so selecting too little first time is much less annoying
* Laney changed the topic of #ubuntu-devel to: Archive: beta 1 freeze, feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> happyaron: You around?
<sil2100> pitti: hey! Could you help out with some translations? ;) https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+pots/pulseaudio/de/+translate?batch=10&show=all&search=wants+to <- do you know who could translate and approve?
<pitti> sil2100: done
<seb128> Laney, pitti, jibel, can anyone override the bootest for indicator-bluetooth in wily?
<seb128> I just noticed that the indicator is missing on my wily
<sil2100> pitti: \o/
<seb128> it's because the bluez5 version didn't migrate out of proposed yet
<sil2100> pitti: I see you have teh translation powah, thanks
<pitti> seb128: done
<seb128> pitti, thanks
<Laney> pitti: you need to unblock it too for it to get into wily
<Laney> see -devel@
<pitti> Laney: ah, how do I hint this?
 * pitti hasn't done hints for freeze overrides yet
<infinity> pitti: unblock foo
<Laney> foo/version
<infinity> pitti: But rerunning the boot test (which I just did) would be better than skipping.
<pitti> I just changed the FAIL in results.history
<infinity> pitti: Ew.
<pitti> seb128 sounded like it's not going to work
<pitti> (a re-run)
<infinity> pitti: I see no reason a re-run wouldn't work.
<pitti> bluez5 has never worked
<infinity> Yeah, it seems to explode when the conffiles are upgraded.
<infinity> But a rerun of the indicator test won't install bluez this time.
<infinity> Since it should be in the image now.
<infinity> At least, I would think so.
<cyphermox> good morning!
<seb128> hey cyphermox
<mterry> bdmurray, ~ubuntu-server is going to look after python-mistralclient in main, FYI
<seb128> hum
<seb128> Laney, can we get indicator-bluetooth unblocked from b1 freeze? the current archive version is useless, it tries to use bluez4 apis and just bail out
<Laney> seb128: I thought pitti was going to do it
<seb128> seems he didn't
<pitti> sorry, forgot about it (communication overflow)
<Laney> that was a way of pinging
<Laney> thanks!
 * pitti adds the hint now
<seb128> thanks
<pitti> done
<Laney> happyaron: You might want to tell $kylin_person about that ^^^ since they could want the fix
<Laney> ypwong: or you :)
<mterry> bdmurray, ~ubuntu-server will look after python-automaton in main, FYI
<mterry> bdmurray, ~ubuntu-server will look after python-oslo.reports and python-oslo.cache in main, FYI
<mterry> coreycb, so for python-tornado, switching to pymysql (only one I've looked at so far).  Don't you need to also add a patch to update the 'import MySQLdb' bits?
<coreycb> mterry, let me look
<coreycb> mterry, yes, and that's poorly done on my part.  let me update those packages before you look at any more.
<mterry> coreycb, python-pymysql itself builds fine now though, thanks  :)
<coreycb> mterry, there is a bright side :)
<mterry> pitti, I thought we already had a tiny http server in main (re: libmicrohttpd)
<mterry> pitti, not counting apache2, which is hard to consider tiny  :)
<mterry> I can't recall it's name now though
<pitti> mterry: it's not a standalone server, it's a lib which programs can embed
<pitti> mterry: i. e. much like python's SimpleHTTPServer class
<pitti> but for C
<mterry> pitti, got it
<slangasek> Laney: "copy link address" requires a right click and my laptop's right mouse button has gone all bad >_<
<roadmr> slangasek: does "two-finger tap" emulate a right click maybe?
<roadmr> (mine does and I didn't configure anything special for that)
<slangasek> roadmr: touchpads are evil, two-finger tap doesn't emulate anything when they're disabled
<roadmr> slangasek: ah, that sounds like a thinkpad then heh
<TJ-> slangasek: does the keyboard have a context-menu key to the right of the space? On mine I can hold that down whilst the pointer is over a hyperlink and the content menu is shown
<srjoglekar> Hello
<srjoglekar> Any work for a Python-proficient (worked with Numpy/Scipy/Sklearn/Pandas/Django) guy?
<pitti> smoser, infinity: before I start looking into unknowns, are you aware of any recent changes to wolfe* which could have caused them to OOM-kill my workers all the time?
<pitti> smoser, infinity: like, adding a new VM (and thus overcommitting RAM), installing landscape (as that also gets OOM-killed), or similar?
<smoser> pitti, well, if i consumed memory on the host, that owuldn't make your kernel run out of memory any earlier.
<smoser> it might get your whole kvm OOM-killed
<smoser> but that said, i dont think i idd
<pitti> smoser: right, the VM itself seems fine, aside from processes getting killed
<pitti> smoser: thanks; I'll have a closer look tomorrow, just wanted to quickly check with you
<smoser> well, then that'd seem to be increased memory consumption inside the vm, no ?
<smoser> it is quite possible that some people are using their vms more intensely than before
<smoser> pitti, wolfe /proc/meminfo:
<smoser> http://paste.ubuntu.com/12193685/
<smoser> in summary, its tight on memory, but not full.  from a resource usage perspective, it has 9 guests with 4G each. and total mem on the system is 64G.
<smoser> so we really shouldnt' be hitting memory overly hard.
<teward> this'll sound insane, but is there a way to have debhelper not run `make install`?  (It appears to run it for some odd reason...)
<teward> (during package building i mean)
<dobey> override the install rule?
<teward> doh
<teward> dobey: thanks, i am working too hard, and forgot we could override it xD
 * teward needs rest probably :/
<dobey> :)
<kees> infinity: a maintainer where there are zero bugs and a dead upstream. :)
<kees> anyway, it's fixed in debian.
<infinity> pitti: I've got nothin', I only look at that machine when you complain, otherwise it's all smoser.
<dobey> http://pastebin.ubuntu.com/12195195/ <- so i can't do any coverage reporting of go code now? :(
#ubuntu-devel 2015-08-26
<pitti> Good morning
<ricotz> infinity, doko, hi, I saw there were some new gcc-5 builds, what about fixing the non-stripped binaries like /usr/lib/gcc/x86_64-linux-gnu/5/lto1
<infinity> ricotz: Apparently, that's a feature, not a bug.
<infinity> ricotz: But doko intends to strip them before release.
<ricotz> infinity, I see, thanks for clarifying
<smb> rbasak, In order to move forward with DPDK I updated bug 1487538 with links to source and my PPA. I think the next step is to subscribe sponsors, right?
<ubottu> bug 1487538 in Ubuntu "[needs-packaging] [FFE] Add dpdk to wily universe" [Wishlist,New] https://launchpad.net/bugs/1487538
<seb128> what should packages handle deluser calls in postrm/purge that fail because the user is logged in
<seb128> like lightdm when users try to remove the package from a system when the login manager is in use
<pitti> seb128: TBH I think nothing should ever call deluser automatically
<pitti> if a postrm is trying to, then at least with || true
<seb128> pitti, so purging lightdm should just let a lightdm user around?
<pitti> but the possibility of reusing a previously removed uid for a new account is a security issue
<pitti> seb128: yeah, I think that's the lesser evil
<seb128> pitti, so you would just drop the deluser call?
<seb128> rather than adding || true?
<pitti> lightdm is prone to leaking processes and leftover sessions unfortunately
<pitti> seb128: no strong opinion between || true and drop, but I'd prefer dropping it, yes
<seb128> pitti, thanks
<seb128> robert_ancell, ^
<pitti> seb128: so the problem is:
<pitti> 1. you uninstall package foo with sysuser foo, removing the sysuser foo with uid 123
<pitti> 2. you install a package bar, adding sysuser bar with uid 123 (reusing)
<pitti> 3. now bar's daemons "take over" any running processes of foo, and can meddle with its leftover files, etc.
<robert_ancell> pitti, fair point
<seb128> right
<pitti> in some cases (when foo doesn't write any files, or makes sure to kill its processes), deluser is a nice cleanup, but this should be ascertained before
<pitti> and lightdm in particular writes lots of files and leaks lots of sessions and processes
<pitti> at least while it's running I always have a lightdm session around; not sure whether that's still true after stopping lightdm
<rbasak> pitti: I think I'd put that a different way. A postrm to clean up a user is fine, but only if it first cleans up anything that is still using that uid first.
<pitti> rbasak: yes, that sounds more positive indeed :)
<infinity> pitti: FWIW, I was right.  Just noticed the old open tab.  The rerun of the bluetooth indicator boottest worked.
<infinity> pitti: So, it's just when it's tied to a bluez transition that it breaks, because upgrading bluez breaks.
<infinity> (Yay phone)
<pitti> ah, I see
<ypwong> Laney, re indicator-bluetooth, do they just need to rebuild image?
<ypwong> ... for ubuntu kylin
<Laney> ypwong: if they want the new one yeah
<ypwong> Laney, i'm sure they do, thanks
<Riddell> cyphermox: are you able to take a look at bug 1488838? fails upgrade
<ubottu> bug 1488838 in ubuntu-release-upgrader (Ubuntu) "upgrade failes on modemmanager" [Undecided,New] https://launchpad.net/bugs/1488838
<rbasak> freeradius in Trusty FTBFS with sbuild -j4 (the same as dpkg-buildpackage -j4 AIUI) but succeeds with DEB_BUILD_OPTIONS=parallel sbuild with no -j flag. Looks like debian/rules just calls $(MAKE) (no debhelper). Presumably it won't fail in Launchpad because that sets DEB_BUILD_OPTIONS and not -j/MAKEFLAGS directly? Should I consider this a buggy package? Or is using sbuild -j wrong?
<rbasak> uh, DEB_BUILD_OPTIONS=parallel=4
<rbasak> s/no debhelper/ no dh/
<infinity> rbasak: sbuild -j and dpkg-buildpackage -j are broken by design.
<rbasak> infinity: ah, OK. Thanks. I had always assumed that -j to sbuild just set DEB_BUILD_OPTIONS and used it as a shortcut. Only looked up the definition just now that I got differing behaviour.
<infinity> rbasak: Yeah, dpkg-buidlpackage -j sets MAKEFLAGS, it's pure evil.
<infinity> rbasak: In wily's dpkg, it now has a safe -J that does what -j should have done.  Making sbuild call that is probably the right answer.
<rbasak> That sounds useful. I look forward to getting my shortcut back :)
<infinity> rbasak: Anyhow, totally not a bug IMO that a package that in no way avertises parallel build capability fails to build when you try to force the issue.
<infinity> rbasak: Who needs a shortcut?  It's shortest to not type -j at all!
<infinity> rbasak: I just have this in my .bashrc:
<infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc)"
<infinity> Which means no thought required on my part.
<rbasak> infinity: understood it's not a buggy package - I figured it was either buggy packaging or buggy tooling and was not sure.
<rbasak> infinity: I often build on VMs, so need to adjust my VM-setting-up-script to set a sensible parallel= field, that's all.
<cyphermox> Riddell: looks like it's much more than modemmanager: all of dbus looks messed up
<Riddell> !
<cyphermox> Riddell: what were you upgrading from?
<cyphermox> direct 15.04 to 15.10?
<Riddell> cyphermox: yes, with do-release-upgrade
<Riddell> bdmurray, mvo: I fixed bug 1488843 in ubuntu-release-upgrader, how do I upload, is the packaging somewhere in bzr or do I just get it from the archive?
<ubottu> bug 1488843 in ubuntu-release-upgrader (Ubuntu Wily) "upgrader kde frontend fails to start" [Critical,New] https://launchpad.net/bugs/1488843
<mvo> Riddell: its in lp:ubuntu-release-upgrader
<colonolGron> hi
<colonolGron> is there any requirement when one woulds like a package to be added to ubuntu?
<pitti> colonolGron: it must be free software (or at least freely redistributable, for multiverse), and there needs to be someone looking after it
<pitti> i. e. it's not a "throw it over the fence" thing, but an ongoing commitment
<colonolGron> well i would like to have a program in ubuntu, but i am not a developer
<colonolGron> pitti, this one: https://github.com/jubalh/nudoku/
<colonolGron> there seems to be openSUSE and Gentoo package but not Ubuntu :(
<pitti> license wise that seems fine
<colonolGron> pitti, so i need to find someone who is willing to maintain the deb package and then thats it?
<pitti> colonolGron: pretty much, yes
<colonolGron> maybe someone in here steps up, i dont know any developers :)
<mterry> bdmurray, ~ubuntu-server will look after python-pymsql in main, FYI
<flexiondotorg> didrocks, I'd like to make a small UI change to the Ubiquity Slideshow for Ubuntu MATE. Is lp:ubiquity-slideshow the correct branch to submitted merge proposals against?
<didrocks> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubiquity-slideshow/".
<didrocks> I would say no :p
<didrocks> flexiondotorg: seems the branch is at lp:~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
<didrocks> (from Vcs-Bzr)
<didrocks> but package version 98 is not in, so please import it
<flexiondotorg> didrocks, I branch this - bzr branch lp:ubiquity-slideshow-ubuntu
<flexiondotorg> And yes. It is version 97 only. Which prompted my question.
<flexiondotorg> import it?
<didrocks> IIRC, you did propose a branch with it
<didrocks> I guess people with commit right to the branch didn't push it
<didrocks> let me check, I guess I didn't have commit rights
<didrocks> yeah, core-dev don't
<didrocks> cyphermox: mind pushing flexiondotorg's changes to this branch?
<didrocks> (I guess core-dev should have access to the branches as well, as per Vcs-Bzr)
<cyphermox> Ah, sure
<didrocks> cyphermox: the branch corresponding to latest upload is lp:~didrocks/ubiquity-slideshow-ubuntu/mate-slideshow
<didrocks> so, should be just a matter of pull && push
<cyphermox> Yep
<didrocks> thx ;)
<didrocks> flexiondotorg: meanwhile, branch from my one ^
<flexiondotorg> didrocks, Understood. Thanks.
<didrocks> yw
<vertago1> Hey I was testing 15.10 on one of my systems and ran into a potential issue with dm-raid and systemd's fsck at boot. Any tips on how to get at any log information which would help me out?
<brendand> barry, do you know if the use of \ is mentioned in pep8?
<barry> brendand: there is some mention of it.  essentially, if you can use parens/braces/brackets to continue lines, do that.  but there are a few cases where only backslashes will work (or where using parens are a bit contrived)
<barry> so backslashes aren't prohibited
<degorenko> hello here! Is here anyone around, who can help me? I want to fix this bug: https://bugs.launchpad.net/ubuntu/+source/sahara/+bug/1452698 I found this instruction: http://packaging.ubuntu.com/html/fixing-a-bug.html is it correct? jamespage coreycb can you help? :)
<ubottu> Launchpad bug 1452698 in sahara (Ubuntu) "Issue in sahara-common.postinst.in: sahara-db-manage is executet on fresh install (even without a db-connection)" [High,Confirmed]
<coreycb> degorenko, hello, I can work with you on it but zul will need to sponsor you (james is out)
<coreycb> degorenko, definitely appreciate the helping hand :)
<coreycb> degorenko, this is kilo?
<degorenko> coreycb, yes :)
<coreycb> degorenko, ok you can work from the kilo branch here:  https://code.launchpad.net/~ubuntu-server-dev
<degorenko> and also this bug in official ubuntu repos (vivid, wily)
<coreycb> degorenko, we'll land it in vivid, wily and then backport to the cloud archive
<coreycb> degorenko, for liberty we've switched to git and this is the process we're following:  https://wiki.ubuntu.com/ServerTeam/OpenStackPackaging
<hallyn_> arges: smb: hey, i don't think i'll be in a good place for the bug party today.  Would same time tomorrow work for you guys?
<smb> hallyn_, would be ok with me
<arges> hallyn_: yea works for me
<hallyn_> cool, thx
<rbasak> arges: please could you take another look at bug 1321425? I'm not happy about the whitespace noise in the diff but you already sponsored that to Wily so I don't want to make the submitter run round unnecessarily.
<ubottu> bug 1321425 in irqbalance (Ubuntu Vivid) "irqbalance spams syslog about affinity_hint subset empty" [Undecided,In progress] https://launchpad.net/bugs/1321425
<rbasak> (there also looks to be quilt refresh noise in unrelated patches eg. the trusty debdiff)
<arges> rbasak: iirc the wily upload didn't have those issues
<rbasak> arges: http://launchpadlibrarian.net/211349484/irqbalance_1.0.6-3ubuntu1_1.0.6-3ubuntu2.diff.gz - no quilt patch noise, but the whitespace noise in comments is there
<arges> rbasak: ack, i see it now.
<arges> rbasak: I would at least let jorge know what happened, perhaps its some editor setting he should be aware of in the future. Are you planning on sponsoring the other SRus?
<rbasak> arges: I'd be happy to, but I'd like the noise gone before I do.
<rbasak> arges: if you're OK with that, I'll ask in the bug.
<arges> rbasak: yea lets do it right. i should have caught that
<rbasak> OK, thanks.
<hallyn_> mdeslaur: arges: I'm wondering whether the ubuntu qemu development tree ought to go back to lp now that it supports git (it's at debian right now, would be nice if you guys could have write access)
<hallyn_> (just a thought;  not doing that today)
<hallyn_> well shucks.  in w we moved the qemu initscript func into a common script, and moved the scripts from qemu-system-{x86,ppc} to qemu-system-common.  Now I keep bikeshedding over hwo to do it in v,
<hallyn_> just putting the full functionality into the original scripts seems simplest;  i can't just add the common script in v without moving it to the new pkg or else v-to-w upgrades will balk
<hallyn_> i can move them now into the qemu-system-common pkgs, but htat's not the simplest way, and this is sru...
<hallyn_> it's "just" v so we won't be keeping the duplicated scripts around for long
<hallyn_> guess i'll do that
 * hallyn_ delets the source and starts over
<hallyn_> urgh but that'll be easy to get a little bit wrong
<hallyn_> dannf: test pkgs for the vivid qemu sru you worked on long ago are at ppa:serge-hallyn/kvm-pxe-backport fwiw (bug 1457639)
<ubottu> bug 1457639 in qemu (Ubuntu Vivid) "qemu-img qcow2 conversion hangs on large core systems" [High,Confirmed] https://launchpad.net/bugs/1457639
<hallyn_> well, still building
<hallyn_> hm, yeah, those init scripts aren't right
<hallyn_> eh maybe they are
<mdeslaur> hallyn_: oh, hrm, didn't know we had a tree at debian for that...yeah, lp would be nice
<mdeslaur> hallyn_: you're going to make me learn git, aren't you?
<hallyn_> mdeslaur: :)
<sladen> .
<Unit193> á£ á£ á£   á§ * * * * * *
<Pici> wakka wakka
<dannf> hallyn: ack, i'll test
<hallyn> dannf: i've run the qa-regression-tests, all passed,
<hallyn> so i pushed to -proposed just a min ago
<dannf> hallyn: perfect - i'll wait till it builds there to verify then
<hallyn> cool
<barry> doko: i think we need to merge dh-python from unstable.  is that something you want to look at or should i?
#ubuntu-devel 2015-08-27
<infinity> Odd_Bloke: *poke*
<infinity> pitti: I thought you didn't consider the lxc runners good enough to give accurate results for migration purposes.
<infinity> pitti: Though, I geuss if you're tracking always-failed per-arch, then the lxc ones can just have more failures for now.
<infinity> pitti: I'm mildly concerned about the armhf tests holding up the show just due to speed now, though.
<infinity> pitti: Especially since we used to optimise this by triggering x86 tests while armhf was still building.
<pitti> Good morning
<pitti> infinity: right, with jenkins we just tracked failures/regressions per package, hence ppc/arm (which have a lot more failures) couldn't be used for regression tracking; now we can
<pitti> infinity: the speed is actually fine -- armhf finished the gcc5 triggered tests (~ 350) in about the same time as amd64+i386
<pitti> and ppc64 is even faster, as I run two tests in parallel per VM
<Odd_Bloke> infinity: Hm?
<infinity> Odd_Bloke: Oh, I wanted to chat with you about doing powerpc cloud images, but we can do that when I'm not heading to bed.
<infinity> Odd_Bloke: I figure it'll be 99% "do what ppc64el does", and 1% "ask Adam, cause WTF."
<Odd_Bloke> infinity: :D
<Odd_Bloke> That sounds pretty reasonable.
<infinity> Odd_Bloke: What TZ (ish) are you working in?
<Odd_Bloke> infinity: BST.
<infinity> Odd_Bloke: And if the answer is "I started now, so now plus 8 hours", do you have time to stick around a bit after that to chat when I wake up?
<infinity> Odd_Bloke: If not, we'll catch up another day.
<Odd_Bloke> infinity: Yeah, that should be fine.
<infinity> Odd_Bloke: Kay, cool.  I'll be back in 6 or 7 hours for meetings, but will try to remember to poke you. :P
<Odd_Bloke> infinity: :)
<zzarr> hello! I get this error trying to build an application for my phone (MX4 Ubuntu Edition) "Unknown module(s) in QT: bluetooth"
<zzarr> it compiles fin on my desktop machine
<zzarr> fine*
<pitti> zzarr: missing a qml-module-qtbluetooth or perhaps libqt5bluetooth5 build dep or so? (sorry, no clue about Qt, but usually missing build deps is the reason)
<zzarr> but where are they missing, and how do I install them?
<doko> barry, sure. you touched it last ;)
<pitti> coreycb, jamespage: mind having a look at the wily failure in http://autopkgtest.ubuntu.com/packages/n/neutron/ ?
<pitti> sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:mysql
<pitti> missing dependency or something such?
<pitti> coreycb, jamespage: it coincides with https://launchpad.net/ubuntu/+source/sqlalchemy/1.0.8+ds1-1ubuntu3 , thus britney rightfully held that back: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sqlalchemy
<pitti> neutron itself is also FTBFS
<jtaylor> doko: is there a reason our bash uses its on memory allocator and not the one from glibc?
<tseliot> pitti: is this a known problem with systemd in wily? (it happens in my sbuild chroot) http://pastebin.ubuntu.com/12204790/
<pitti> tseliot: hm, not known to me; but that's in dpkg's unpack stage
<tseliot> pitti: oh, right
<rbasak> pmcgowan: could you comment on bug 1471903 please? ogra_ wanted you to have an opportunity to comment before we go ahead and upload the proposed fix there to Wily, since we want the fix to end up in the vivid-overlay PPA.
<ubottu> bug 1471903 in live-build (Ubuntu) "-updates, -security missing from apt lists" [High,In progress] https://launchpad.net/bugs/1471903
<rbasak> bdmurray: ^^
<rbasak> pmcgowan: my attempt at a summary is in comment #27
<pmcgowan> rbasak, reading
<ogra_> rbasak, ah, thanks, i was about to ping pat :)
<pitti> arges, tjaalton: could I bribe you to look at the SRUs in bug 1489045? trivial thing, but it would unblock some infrastructure work
<ubottu> bug 1489045 in dkms (Ubuntu Trusty) "Backport autopkgtest script to precise/trusty" [Wishlist,Triaged] https://launchpad.net/bugs/1489045
<pitti> caribou: some cleanup to do for bug 1464201; otherwise this looks good, thanks!
<ubottu> bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1464201
<caribou> pitti: anything you want me to do for that cleanup ?
<pmcgowan> rbasak, ogra_ comment added
<ogra_> thanks !
<pitti> caribou: I followed up to the report
<pitti> caribou: shoudl mostly be "put the .init back and correct the merge changelog"
<pitti> caribou: and drop some unnecessary delta if you want (but this is just a suggestion)
<caribou> pitti: sure, just comment in the bug & I'll fix that up
<pitti> caribou: I did already
<caribou> k
<caribou> pitti: looks like the usage of imjournal.so needs some investigation
<caribou> pitti: there are mentions of performance hit when using it instead of imuxsock
<pitti> caribou: yeah, not a blocker for the FFE, just a question
<caribou> pitti: let me look in to it
<pitti> let's first get the new version in and look at this separately
<caribou> pitti: their page says "The journal provides imuxsock with a copy of all âclassicalâ syslog messages, however, it does not provide structured data"
<caribou> pitti: so *maybe* this means that the basic journal data it picked up
<pitti> oh, it is
<pitti> it's just not totally reliable when there's a flood of messages
<coreycb> pitti, neutron autopkgtests should be ok with 1.0.8+ds1-1ubuntu4, uploaded last night.  I'll look into the ftbfs.
<pitti> coreycb: the tests do use sqlalchemy 1.0.8+ds1-1ubuntu4 and fail with that
<coreycb> pitti, oh I thought you said they were using 1ubuntu3
<pitti> coreycb: no, just that they started failing with this version
<coreycb> pitti, ok I'll look
<pitti> coreycb: sorry for the misunderstaning
<pitti> coreycb: thanks!
<coreycb> pitti, np!
<zzarr> hello! if I compile a project based on QtQuick for a Ubuntu kit, where's the executable located (on my Ubuntu Phone in this case)?
<mitya57> zzarr: you probably want #ubuntu-touch or #ubuntu-app-devel
<zzarr> mitya57, thanks
<doko> jibel, online?
<jibel> doko, I am online
<rbasak> pmcgowan: thanks!
<rbasak> sil2100, ogra_, bdmurray: so who's sponsoring this? Is everyone happy with sil2100's debdiff in comment #11?
 * rbasak notes that the changelog entry needs a bug reference
<tjaalton> pitti: done
<sil2100> rbasak: I'm happy with it, and I know bdmurray and infinity were too
<sil2100> Not sure who's ACK would we still need
<pitti> tjaalton: cheers!
<ogra_> sil2100, well, note that pmcgowan asks that the overlay PPA has an override for the change
<ogra_> beyond that, yeah, someone should just upload :)
<sil2100> Wait, why?
<tjaalton> arges: fyi ^, acked the dkms sru's already
<sil2100> The point of it is having that on our stable phones so that we can get proper reports
<ogra_> sil2100, well, effectively we need to re-work apport so we can drop the lists again ... perhaps we can live with the bloat until the next OTA
<ogra_> (and have sommeone fix apport)
<sil2100> pmcgowan: hey! You don't want the change for including apt lists of -updates and -security in the images? Why?
<ogra_> sil2100, seen the mail from john ?
<ogra_> regading image size ...
<ogra_> the rootfs will soon ship the infrastructure for desktop apps ... they are supposed to be executed in a chroot or container ... we will need to ship another 50-100M for that infrastructure (minimal chroot etc)
<sil2100> ogra_: it still should be ok, the difference is small - I understand the point, but holding off this change won't make much difference
<ogra_> we can really not waste space like that
<ogra_> sil2100, the difference is 50-60M
<ogra_> note that we used to wipe these package lists
<ogra_> not sure when or how they were added
<rbasak> I thought that since we're already shipping the lists for the release pocket, the difference for -updates and -security is actually much smaller?
<pmcgowan> sil2100,this pointed out we previously added 66MB we did not expect
<sil2100> ogra_: no it's not
<ogra_> rbasak, that we ship them at all is the main buug
<pmcgowan> right
<sil2100> I checked that it's basically 5 MB more
<sil2100> ogra_: didn't you see my comment?
<ogra_> the original build scripts from the OEM team had code that forcefully removed them
<pmcgowan> sil2100, te issue is the lists should not be installed at all
<ogra_> and all our size measurements we did in malta were based on a rootfs without them
<sil2100> pmcgowan: right, but that's a separate bug anyway
<ogra_> and these size measurements are the base for our parittioning scheme
<sil2100> Since we ship them right now anyway
<mdeslaur> tkamppeter: how can I test ippusbxd?
<rbasak> I don't think anyone disagrees with that. The question is about what we do right now.
<pmcgowan> sil2100, but thats how we want to fix it for next stable update
<ogra_> sil2100, yes, as i said, someone needs to fix apport asap to not require them
<pmcgowan> we dont need to fix it in proposed I'd say
<pmcgowan> we just want the real fix
<ogra_> rbasak, right now we want this fix to land to not hold back other images
<sil2100> ogra_, pmcgowan: is bdmurray working on the fix?
<ogra_> but for the phone we want a plan that makes us go back to a sane size
<pmcgowan> sil2100, no one is yet, I just filed a separate bug
<ogra_> sil2100, no idea, someone has to though
<sil2100> Ok, thanks
<pmcgowan> sil2100, and I added it to ota7 list
<ogra_> pitti, on that note (see backlog above) are there any plans for apport in snappy ?
<ogra_> i guess a fix for the phone could be designed in a way that it also helps running apport on snappy
<pitti> ogra_: we haven't really talked about that yet; i. e. what kind of error reporting do we actually want from snappy? Just for the snappy OS itself, or for any of the apps? the latter surely shouldn't be Ubuntu bugs, but go somewhere else? etc.
<ogra_> pitti, well, snappy on the phone and snappy personal will surely want to use some kind of automatic error reporting ... and there we cant rely on apt lists locally
<pitti> ogra_: if we remove dpkg and /var/lib/dpkg/* we stop being able to associate a binary to a package; so if that's what we conceptually want, we could still file bugs against teh "snappy" project, but we can't associate them to their real packages any more
<pitti> ogra_: hm, we only need the apt lists to determine the origin, no? mapping a path to a package should just require the dpkg db
<ogra_> pitti, and that lists issue already hits us ahrd on the phone today ... so having a plan that can also work on snappy would be good
<ogra_> pitti, well, i'd go even further and say we could us a remote locatiojn for that data where we bind psckage lists to specific image versions
<pitti> ogra_: that doesn't need to be done on the client side, though
<rbasak> Could you just ask Launchpad? It has this information available already via publishing history, right?
<barry> doko: :)
<pitti> ogra_: on the client, specifying the executable path and channel/image number should be sufficient?
<pitti> and resolving that to a package could then even be done in launchpad/on the retracers, etc.
<ogra_> yeah
<pitti> (probably not in LP itself, but the retracers could post-process reports)
<cjwatson> rbasak: soooort of, but that often doesn't quite match up to image building for various reasons; more reliable to keep manifests
<rbasak> OK
<Laney> tyhicks: hi, do you have a bug # to track removing the GetConnectionAppArmorSecurityContext porting?
<Laney> erm, that sentence made more sense before it got through my fingers
<Laney> you know what I mean :)
<pitti> apw: is this uninstallability known? http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#linux-meta
<mdeslaur> slangasek: weren't you going to upload a new edk2?
<apw> pitti, why _it_ that uninstallable, there is a linux-image-virtual-lts-utopic
<pitti> but http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_output.txt says it's not installable
<apw> oh ... its an arch thing
<apw> pitti, ok that is plain wrong and has been plain wrong since it was first released by the looks of it
<pitti> apw: I guess we just never paid attention to britney uninstallables in stables so far?
* Laney changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Laney: \o/ congrats!
<apw> pitti, i guess not, anyhow, i'll get a bug filed and someone to fix 'er up
<Laney> pitti: wily is open for breakage again :)
<pitti> Laney: britney has lots of shiny! :)
<caribou> pitti: Just uploaded changes for LP: #1464201
<ubottu> Launchpad bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1464201
<apw> pitti, bug #1489487
<ubottu> bug 1489487 in linux-meta (Ubuntu) "linux-meta: is uninstallable in trusty-proposed" [Medium,Triaged] https://launchpad.net/bugs/1489487
<tyhicks> Laney: bug #1489489
<ubottu> bug 1489489 in media-hub (Ubuntu) "The org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() method is deprecated" [Medium,Triaged] https://launchpad.net/bugs/1489489
<tyhicks> Laney: I need to add more source packages that are affected and need to provide an example of how to switch over but at least we have a placeholder now
<Laney> tyhicks: ok, it'd be nice if we could do this for 15.10 if possible
<Laney> if it's easy maybe I can help
<tyhicks> Laney: I doubt 15.10 is possible
<Laney> why?
<tyhicks> Laney: I don't have much time to devote to it at the moment
<tyhicks> Laney: if individual project maintainers want to jump in and make the changes based on the examples that I provide, then it may be possible
<tkamppeter> mdeslaur, run "ippusbxd -d -n -N -P 60000" on the command line. This runs ippusbxd without presence of a printer but opening the port.
<tkamppeter> mdeslaur, see "ippusbxd -h", "-N" is the no-printer mode for development and debugging.
<mdeslaur> tkamppeter: ah! great, thanks
<mdeslaur> tkamppeter: ah, my ippusbxd is too old to have those options...it's the vivid cups-filters package
<mdeslaur> tkamppeter: do you have the required hardware to test the update in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages ?
<tkamppeter> mdeslaur, I have the hardware, so tell me whatever steps I have to do (probably with Vivid as Wily uses the new ippusbxd).
<mdeslaur> tkamppeter: install the cups-filters binaries from that ppa on vivid, and see if ippusbxd still works, that would be an enormous help
<pitti> cjwatson: britney itself (at least not britney2-ubuntu) doesn't "do" the copy from -proposed to -release, it just computes the set of packages that it can migrate, right? do you know what does that?
<pitti> sil2100: ^
<cjwatson> pitti: Start from lp_import in britney1-ubuntu (which wraps britney2-ubuntu)
<cjwatson> pitti: promote-to-release is in lp:ubuntu-archive-tools
<pitti> cjwatson: ah, in britney1
<pitti> so britney2 writes HeidiResultData, britney1's ./britney calls promote-to-release
<sil2100> \o/
 * sil2100 looks at that
<sil2100> cjwatson: thanks!
<pitti> cjwatson: cheers
<sil2100> How did I miss that, sometimes I feel like a blind guy
 * pitti hasn't touched britney1 at all yet, didn't know it either
<tkamppeter> mdeslaur, I have tested and the security fix seems to be OK.
<mdeslaur> thanks tkamppeter! very much appreciated
<tkamppeter> mdeslaur, but can you please also apply also this (functional, not security) fix:
<tkamppeter> https://github.com/tillkamppeter/ippusbxd/commit/3facde24a3b74168047dcd564bf609fd9911edcb
<cjwatson> To be fair it is a baroque setup, but I was trying to make it as close to the deployed setup in Debian as possible (and theirs had accreted over time)
<tkamppeter> mdeslaur, it is a simple patch, without it most printers are not able to print but only allow access to their web config interface.
<tkamppeter> mdeslaur, Wily already has this fix as it uses the 1.22 release.
<mdeslaur> tkamppeter: we don't usually include fixes in security updates, but I'll include this one
<mdeslaur> tkamppeter: thanks
<tkamppeter> mdeslaur, thanks.
<slangasek> mdeslaur: yeah, but I wasn't in a hurry :) I have another patch pending from dannf for proper arm64 vm support, but he also tells me that something's funny with the arm64 build when cross-built
<slangasek> dannf: ^^ any progress on that?  and do you happen to have checked that rebuilding the existing package with gcc-5 works?
<mdeslaur> slangasek: ok...I have some updated libosinfo and virt-manager packages...but libvirt needs your edk2 packages to detect the firmware properly
<mdeslaur> slangasek: so I guess we need to publish these all together under the same FFe
<dannf> slangasek: yes, same package rebuilt w/ gcc5 fails. i'm doing a gcc bisect, but having to skip a lot of build failure revs
<dannf> slangasek: one workaround would be to force gcc-4.9 for now
<slangasek> mdeslaur: I don't think the edk2 side needs an FFe fwiw
<mdeslaur> hrm, mine does :P
<slangasek> dannf: that's no workaround, there is no cross gcc-4.9 in Debian ;)
<slangasek> I would have to back out that change
<dannf> slangasek: right - well, bisection continues - hopefully that'll find the root cause
<bdmurray> seb128: While https://errors.ubuntu.com/bucket/?id=failed%3A/usr/lib/i386-linux-gnu/libgtk-3-0/gtk-update-icon-cache-3.0%3A11%3Ai686%3A/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1%2B6d08%3A/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1%2B4b49%3A/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so%2Bff4 has failed to retrace do you have any ideas what the problem may be?
<seb128> bdmurray, no idea no
<tkamppeter> Is there some system facility which "corrects" file ownerships and permissions in Ubuntu, for example out of a cron job?
<dobey> tkamppeter: no
<Odd_Bloke> infinity: I have a hard EOD in about 90 minutes, if you still want to talk powerpc images today.
<dannf> slangasek: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1489560
<ubottu> Launchpad bug 1489560 in edk2 (Ubuntu) "qemu-efi: hangs in kvm mode when built w/ gcc-5" [Undecided,New]
<slangasek> dannf: so as you assigned this to edk2 rather than gcc, does that mean you think it's a bug in edk2?
<dannf> slangasek: i have no idea, though i'd lean towards a gcc regression. marked as impacting both now.
<bdmurray> Riddell: Do you have any plans to fix the ubuntu-release-upgrader test failure? http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/wily/amd64/
<doko> barry, do you have an estimate what still needs to be done for python3.5 as the default? honestly I'd like to see this for 15.10, even if it breaks some stuff, so we have something stable in preparation for the next LTS
<barry> doko: i was just chatting w/ slangasek about that.  i need to do an updated review of main + seeded packages that ftbfs or fail dep-8 w/py35 as default.  my biggest concern frankly is django and its ecosystem.  a safer route is to keep 3.5 as supported for 15.10 and do the switch to default as soon as x opens
<doko> barry, sure, but that won't expose 3.5 that much to users and developers
<doko> ohh, and I should better run python3.5 in the autopkg tests for python3.5, and not 3.4 ...
<barry> doko: that's true, but i think we've done a really good job of getting upstreams on the py35 bandwagon just by doing our transition.  also: what's the plan for 3.5 as support or default in debian?
<doko> barry, finishing GCC 5 first according to the release team ... and I'm not the only python3-defaults maintainer
<barry> doko: right.  perfectly reasonable to finish gcc5 first.  is there an eta for that?
<doko> barry, 1-2 months, that's what the release team things. but how does this relate to making 3.5 the default for 15.10?
<juliank> If somebody wants to try APT 1.1 in wily, the PPA builds that now: https://launchpad.net/~deity/+archive/ubuntu/sid (yes, the name is wrong, sid is tracking HEAD, which is currently experimental)
<doko> juliank, mvo is back from vacation, hint, hint ;-P
<barry> doko: doesn't much, mostly curious.  i think we're probably not in bad shape for debian to go to 3.5.  as for ubuntu, let me see what other main+seeded packages still need love
<juliank> doko: Sure. But APT 1.1 is post-wily stuff, so the PPA allows people to test it anyway
<doko> barry, I can start the next test rebuild with 3.5 as the default, but then you would have to identify the 3.5 related ftbfs
<doko> ahh, ok
<barry> doko: would that be much different from the ~pythoneers/py35asdefault ppa?
<doko> barry, it would be recent, and for all archs
<barry> doko: it would be good data then
<doko> ok, planning for it
<juliank> I'll soon release python-apt 1.0~beta4 though, that one is targeted at wily.
<slangasek> doko: I disagree that it's better to have 3.5 as default in 15.10 when we know it will break packages; especially since we're past FF and barry has already signalled via the mailing list that we're not switching, I think it's more effective to focus on the known issues i.e. build failures) between now and 15.10 release, and get these fixed via Debian
<doko> slangasek, ohh, didn't see that. but I disagree on the breakage thing. sure, there is django, but we don't know about anything else
<slangasek> doko: there are still a large number of build failures in the py35default ppa
<doko> slangasek, afaics the ppa wasn't updated
<barry> i have a script to sync the archive to the ppa
<barry> which i just again ran 15m ago :)
<bdmurray> Riddell: I'll fix ubuntu-release-upgrader
<ochosi> hey everyone
<ochosi> who's currently in charge of ubiquity?
<ochosi> is it cyphermox?
<Unit193> Thought so.
<cyphermox> yo?
<Riddell> bdmurray: I uploaded to vivid-proposed, awaiting ubuntu-sru approval
<Riddell> bdmurray: oh but I've not seen the test failure
<ochosi> cyphermox: just wondering whether another ubiquity release was planned for 15.10 because there is a xubuntu-relevant bugfix in trunk that would be nice to have (aka commit 6307)
<Logan> slangasek: looks like the Debian maintainer renamed the gtkglextmm shared library package for G++ 5 - should we pull that in?
<cyphermox> ochosi: yes, there will be an upload soon :)
<slangasek> Logan: I would say yes
<ochosi> cyphermox: awesome - thanks!
#ubuntu-devel 2015-08-28
<tdaitx> slangasek, ftbfs fixed for bluez-tools in LP: #1489661
<ubottu> Launchpad bug 1489661 in bluez-tools (Ubuntu) "bluez-tools FTBFS on wily-proposed due to AM_LDFLAGS misuse" [Undecided,New] https://launchpad.net/bugs/1489661
<Logan> slangasek: ok, I'll test build and then sync
<Logan> I'll deal with the transition fallout as well
<Logan> doko: regarding https://launchpad.net/ubuntu/+source/gtkmm2.4/1:2.24.4-1.1ubuntu1
<Logan> can we sync over that, even though Debian didn't make the std change?
<infinity> Odd_Bloke: Sorry, I fell ill and disappeared.
<slangasek> Logan: if Debian is not making the package name change for the ABI transition, you should *not* sync over it but instead merge it with conflicts/replaces going the other direction, so that users can still sanely upgrade within wily
<cyphermox> tdaitx: still around? I was looking at your bluez-tools diff
<tdaitx> cyphermox, yeah
<cyphermox> tdaitx: maybe just missing patch tags
<tdaitx> cyphermox, I set it on LP earlier
<tdaitx> cyphermox, or did I miss something else?
<cyphermox> ah, sorry I mean DEP-3 tags on the patch itself: http://dep.debian.net/deps/dep3/
<cyphermox> but it's tiny and pretty obvious it's from you :)
<tdaitx> cyphermox, thanks, I didn't knew about these
<tdaitx> cyphermox, does any of the tools we use help on getting that done?
<tdaitx> otherwise I will just write down a template so I don't forget this =)
<cyphermox> tdaitx: good question, I don't know. I just add them manually; usually mostly just From:, Subject: amd Bug-Ubuntu:
<tdaitx> cyphermox, ok, should I added those to the patch and submit the debdiff to debian again? what about lp?
<cyphermox> I leave that up to you, if you want to submit it just to Debian I'll add them for you when I sponsor
<tdaitx> cyphermox, alright, thanks for your help, please keep bringing those issues forward when you see them, lots to learn ;-)
<tdaitx> cyphermox, found it: quilt header -e --dep3
<cyphermox> oh, cool
<tdaitx> that inserts a template
<cyphermox> thanks, I'll make note of that :)
<cyphermox> figured there might be a way, but it wasn't bugging me enough to just vi it in
<tdaitx> there was a "quilt header -e" citation in deb maintainer manual, when I looked at the man page I noticed that --dep3 param, easy as that
<AwlsomeAlex> Hello?
<cyphermox> good night!
<Luke> how can I set a global prompt for all users?
<hallyn> cyphermox: hey, were you going to push the new golang to wily today?
<pitti> Good morning
<tdaitx> slangasek, opencsg FTBFS on armhf because it cant find libGLES2... that happens because:
<tdaitx> 1. it uses qmake-qt4 to create the Makefile, but qt4-x11 is being compiled with libgles2-mesa-dev in armel/armhf (against libgl1-mesa-dev and libgl1u-mesa-dev in other archs)
<tdaitx> 2. it depends on glew, but glew depends on libgl1-mesa-dev and libgl1u-mesa-dev, thus the libgles2 dependency is not set anywhere
<tdaitx> thus either glew has to be build using libgles2 in armel/armhf or qt4-x11 must use libgl1/libgl1u for armel/armhf
<tdaitx> slangasek, ^
<tdaitx> slangasek, not sure which one is the right way to go (or if there is a third alternative)
<Logan> slangasek: it is making the package name change, whereas we didn't
<lotuspsychje> good morning to all
<lotuspsychje> is it possible to add the broadcom firmware drivers to ubuntu-restricted-extras so users with bc chipsets can install ubuntu more easyly?
<pitti> this is already done by ubuntu-drivers-common and in the installer
<pitti> hardware drivers don't belong into ubuntu-restricted-extras, as these would be useless or even detrimental for users who don't have that hardware
<pitti> lotuspsychje: ^
<lotuspsychje> pitti: does it need to have internet connection for ubuntu-drivers-common?
<pitti> I believe we shipt the driver on the ubuntu images, so the installer grabs it from there
<lotuspsychje> pitti: because many users on 14.04 complain in #ubuntu their broadcom doesnt get recognized
<lotuspsychje> pitti: or has this been fixxed in 14.04.3?
<pitti> not particularly, it was working in 14.04 already for at least some chips
<lotuspsychje> pitti: maybe its the default broadcom driver and not the firmware thats added?
<lotuspsychje> they have to do this sometimes: https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx#STA_-_No_Internet_access
<pitti> but there might have been some changes to replace bcmwl with the one shipped by the upstream kernel
<pitti> (no further idea I'm afraid, it's been many years since I had such a thing)
<lotuspsychje> this user had no internet access on eth0, maybe thats why?
<pitti> the *intention* is that the driver is on the image
<lotuspsychje> pitti: ok tnx for investigating
<pitti> lotuspsychje: and http://releases.ubuntu.com/14.04.3/ubuntu-14.04.3-desktop-amd64.list still does ship it
<pitti> /pool/restricted/b/bcmwl/bcmwl-kernel-source_6.30.223.248+bdcom-0ubuntu0.1_amd64.deb
<pitti> so that's not it
<pitti> you need to enable [ ] Install non-free drivers in the installer for that
<pitti> on the wiki page you cited it also just installs that deb from the cd-rom, so in principle it ships everything that's needed
<lotuspsychje> pitti: didnt ntocie there was such option yet?
<lotuspsychje> pitti: yeah i know the cdrom trick does it, but for most n00b users its a little hard to find
<pitti> last time I installed on a laptop with broadcom, it "just happened", but since then I'm afraid I don't know off-hand what's going wrong
<pitti> a bug report with installer logs would be helpful for that
<lotuspsychje> pitti: if that occurs again on some user, ill push to bug it
<pitti> thanks!
<lotuspsychje> pitti: thank you for lighting things up
<pitti> caribou: hm, I'm adjusting your rsyslog merge to 8.12.0-1; 8.9 is quite old, not even in testing any more
<pitti> caribou: followed up to the bug
<pitti> doko: hmm, I hinted gcc-5, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt says it renders packages uninstallable -- any recent dependency change in that version?
<smb> rbasak, on ffe... have now sponsors and sru team subscribed to bug 1487538. are there specific sponsors I should ask in this special case?
<ubottu> bug 1487538 in Ubuntu "[needs-packaging] [FFE] Add dpdk to wily universe" [Wishlist,New] https://launchpad.net/bugs/1487538
<rbasak> smb: thank you for pushing ahead with DPDK, and sorry I've been tied up. I need to get that email to upstream sorted out. Has the FFe been approved? Need that before sponsoring. Maybe arges can sponsor as he reviewed previously?
<rbasak> smb, arges: can we sync on DPDK status later today, maybe? I'd like to go through my email draft with arges with a focus on getting it done and sent if possible.
<smb> rbasak, can ask him today. somehow thought first upload and then accept it as ffe from the new queue
<rbasak> I've seen a release team member complain about it when done that way round before. So I presume they want to ack first.
<smb> rbasak, we can do that. I am having a dentist appt. soon but something like 1UTC onwards (or as soon as arges becomes concious)
<doko> pitti, yes, it adds some breaks. so maybe I should just "binNMU" these
<rbasak> smb, arges: invite sent. Feel free to move.
<rbasak> (is arges up by then?)
<smb> rbasak, I can live with that and I believe he should
<rbasak> That's 8am for him
<smb> ok, if he was like me, rather not but he might. we will see
<melodie> hi
<Odd_Bloke> infinity: No worries; I'm back around now.
<pitti> Laney: I dumped my brain into https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Deployment FYI
<pitti> Laney: does this sound reasonably comprehensible to you?
<sarnold> pitti: nice
<pitti> sarnold: thanks :)
<sarnold> (i'll give it a Good Read later.. it just looked good on a quick skim :)
<caribou> pitti: I'm fine with redoing the merge for 8.12.0-1 but this won't happen today. Hopefully by EOD monday, is that ok with you ?
<pitti> caribou: sure!
<caribou> pitti: I'll also drop the rsyslog.dmesg.upstart job
<pitti> caribou: no, please don't drop the upstart job
<pitti> caribou: just consider if you need the corresponding (and newly added) .service for this
<caribou> pitti: oh, that's what I meant, sorry
<pitti> caribou: ah, ok :)
<doko> xnox, did you continue to work on boost rebuilds?
<doko> tjaalton, https://launchpad.net/ubuntu/+source/openscad/2015.03-1+dfsg-2build1/+build/7844937  any reason that libgl1-mesa-swx11 is not built in wily?
<tjaalton> doko: it doesn't exist, debian experimental got rid of it too recently
<doko> tjaalton, could you fix openscad then?
<tjaalton> perhaps
<tjaalton> we haven't had swx11 for a few years
<pitti> Laney: I filled in the remaining sections too, now; Please let me know if something is unclear
<tjaalton> doko: can you fix llvm-3.7 to build on i386 ;)
<tjaalton> opengl 4.1 for radeon depends on it, and mesa 11.0-rc migrated to it
<doko> heh, I looked at it, but didn't find anything yet. builds in unstable
<tjaalton> apparently it's caused because we build some i686 optimization
<tjaalton> there's an upstream bug open since february :/
 * tjaalton tries to find it
<tjaalton> https://llvm.org/bugs/show_bug.cgi?id=22661
<ubottu> llvm.org bug 22661 in compiler-rt "No compiler-rt library is built when configured for i686-linux" [Normal,New]
<tjaalton> should be that
<doko> ohh
<doko> ok, even with a patch
<doko> tjaalton, https://launchpad.net/ubuntu/+source/llvm-toolchain-3.7/1:3.7~+rc4-1ubuntu1  and see the Conflicts/Replaces
<tjaalton> doko: I'll worry about the backport closer to the release :)
<jtaylor> doko: do you know why the bash package uses its internal malloc instead of glibc's?
<jtaylor> performance?
<doko> I have to dig around. does something not work?
<jtaylor> yes, something LD_PRELOADS a library using posix_memalign during init, and later it then uses bash's free
<jtaylor> -> crash
<jtaylor> it is a somewhat strange app that can probably be fixed, but I'm curious about the reason for the internal malloc
<jtaylor> it seems fedora bash uses glibc malloc as that is unaffected
<jtaylor> or its because our bash is a pie executable?
<doko> Riddell, looks like you're reverting / overwriting many of the changes I made during the GCC 5 uploads ...
<doko> kde-runtime now b-d on boost1.55 again
<Odd_Bloke> arges: cloud-init has been in {p,t,v}-proposed for 7 days now and the fixes have all been validated; would you mind migrating it?
<mitya57> pitti, I have a question about autopkgtest.ubuntu.com. When I search for "sphinx", it shows me this: http://mitya57.me/tmp/searcharea.png (amd64 marked as failed),
<mitya57> but http://autopkgtest.ubuntu.com/packages/s/sphinx/ indicates that it's ppc64el that fails, not amd64.
<mitya57> I guess it is a bug somewhere?
<mitya57> As I can see amd64 never failed (on the new server), and ppc64el never succeeded.
<pitti> mitya57: ah yes, a funny display bug; mind reporting that against http://bugs.debian.org/src:debci ? then it's at the right place already
<mitya57> Ok, will report now.
<mitya57> pitti: debian #797198
<ubottu> Debian bug 797198 in debci "debci: search page displays wrong architectures as failing" [Normal,Open] http://bugs.debian.org/797198
<pitti> mitya57: thanks! I think I've seen this too
<rbasak> smb, arges: mind if we postpone dpdk sync until a bit later. I'm feeling a bit under the weather.
<smb> rbasak, In my case depends how long that bit is, have not heard of ar ges yet. So it might suit him to get awake
<dobey> pitti: hey, how do we figure out why something in debci is running out of memory?
<pitti> dobey: ah, what package does that affect? I can give it a bigger instance
 * pitti pats his "big_packages" list in worker.conf
<dobey> pitti: ubuntu-system-settings-online-accounts seems to be hitting this issue
<pitti> dobey: really? looks like the autopilot-gtk lib ABI mismatch to me
<pitti> (which breaks a lot of tests indeed)
<dobey> pitti: and that causes ENOMEM?
<pitti> there's a silo that needs to be released, fallout from the g++ 5 transition
<pitti> it causes this "IndexError: list index out of range" for sure
<pitti> I think the ENOMEM is a red herring
<pitti> at least I'll retry all these once the silo lands (/me bats eyelashes towards sil2100), my hope is that they'll all just work again
<pitti> the history on http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/wily/amd64/ suggests that it worked fine before with the 2 GB of RAM that it has
<dobey> and it worked fine at some point since the gcc5 transition too
<hallyn> mwhudson: cyphermox: my laptop would really like to upgrade but won't get past the broken golang.  Wlil the new golang hit wily today, or should i wget the 70 or so debs and dpkg -i them?
<cyphermox> hallyn: oh, whether you'll get golang 1.5 final depends on mwhudson, but let me fix the issue with the package now
<dobey> broken golang?
<hallyn> dobey: yeah, file moved from golang-go.tools to golang-go
<hallyn> broken pkg not golang itself
<hallyn> cyphermox: ok, last i saw the bug it looked like mwhudson was done
<hallyn> feh maybe i'll make a pkg in ppa which does the breaks/replace :)
<dobey> golang-go breaks/replaces golang-golang-x-tools, which golang-go.tools depends on though; so an upgrade should just remove the latter
<dobey> something does still Suggests: golang-go.tools though, and probably shouldn't
<hallyn> not sure whether you're telling me what the pkg should do, or suggesting an easier way fo rme to get past the apt-get dist-upgrade failures
<cyphermox> hallyn: he's just re-doing the analysis I had already done.
<cyphermox> hallyn: though you could just remove golang-go.tools and golang-golang-x-tools
<dobey> hallyn: what i'm saying is that for me, "apt-get dist-upgrade" just removed the golang-go.tools and golang-golang-x-tools packages
<hallyn> dobey: it did?   hm, so it sounds like i have something pinning those then.  interesting
<hallyn> (note i'm not the only one wit hthis failure, someone else opened the bug :)
<hallyn> all right, just removed all the pkgs
<dobey> hallyn: yeah, although i think i have -proposed enabled there too
<dobey> so maybe it's fixed in proposed :)
<dobey> yeah, i do have proposed enabled there
<tsimonq2> Hey, Launchpad is giving me a weird error when I try to change the affected package(+editstatus)...what is the proper way to edit the affected package?
<infinity> tsimonq2: Not enough info really to know what went wrong.
<infinity> tsimonq2: But often it's that you're trying to assign a project bug to an Ubuntu package, instead of an Ubuntu bug.
<infinity> (Which isn't the most intuitive thing to sort out sometimes, but the URL you're on is a hint)
<infinity> tsimonq2: Would help if you defined "weird error".
<tsimonq2> Sorry
<pitti> dobey: armhf/ppc64el are uninstallable, but i386/amd64 succeeded again; autopilot-gtk and xpathselect landed
<tsimonq2> It gives me an error of: There is no package named 'nautilus-columns' published in Ubuntu. when in the selector, it shows up
<dobey> pitti: yeah, unity8-autopilot seems to be uninstalalble on those archs, and is causing lots of "always failed" there
<infinity> tsimonq2: It's not wrong.
<Odd_Bloke> arges: Thanks!
<infinity> tsimonq2: https://launchpad.net/ubuntu/+source/nautilus-columns
<pitti> dobey: lots of valid candidates now \o/
<infinity> tsimonq2: Try assigning to a package that exists.
<dobey> pitti: yeah. mir boottest is failing still though :(
<tsimonq2> infinity: Then why does it show up in the selector?
<infinity> tsimonq2: Because it probably existed at one point in the distant past.
<tsimonq2> infinity: When I click Select...
<tsimonq2> Oh ok
<infinity> tsimonq2: But is no longer in any current releases.
<tsimonq2> infinity: Ok, thank you for your time :)
<cjwatson> tsimonq2: That's https://bugs.launchpad.net/launchpad/+bug/42298
<ubottu> Launchpad bug 42298 in Launchpad itself "package picker lists unpublished (invalid) packages" [High,Triaged]
<tsimonq2> cjwatson: Well that needs to be fixed XD
<tsimonq2> cjwatson: High priority XD
<cjwatson> tsimonq2: I have some work in progress for it, but it's a non-trivial wodge of complicated performance-sensitive SQL
<cjwatson> The last attempt to deal with it crashed and burned, so not going to rush it :-)
<Simounet> Hi there. Do you know how I can assign a bug to one of the webupd8's package? https://bugs.launchpad.net/bugs/1489842
<ubottu> Launchpad bug 1489842 in Ubuntu "Nautilus columns fields not working on grid view" [Undecided,New]
<pitti> dobey: hm, unity8-autopilot uninstallable on armhf? didn't we use to have a phone on arm or something? :-)
<pitti> dobey: I'll retry the mir boottest
<pitti> oh wait, I already did that; last three attempts failed
<dobey> yeah, i'm not sure what's failing exactly though
<dobey> but it's blocking my package from transitioning :(
<leszek> hi
<infinity> cjwatson: Was that fresh in your mind from recently looking at it, or are you turning into wgrant?
<pitti> doko: retrying one more time; I'm quite used to overriding boottests, brittle as they are
<pitti> err, dobey ^
<pitti> dobey: so if you want me to do that, I can
<dobey> well i don't know anything about mir, so i don't know if it's always been failing there or not
<leszek> chrisccoulson: can you please explain me how you solved this issue ? https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1471949  We try to build firefox with kde integration patches on launchpad ppa but the resulting 32bit deb crashes with the same symptoms
<ubottu> Launchpad bug 1471949 in gcc-mozilla (Ubuntu Precise) "Firefox 39 crashes on startup or within a few seconds on Precise/x86" [Critical,Fix committed]
<cjwatson> infinity: Open browser tab :)
<cjwatson> infinity: wgrant does that in real life without mechanical assistance.
<infinity> cjwatson: I've noticed.
<cjwatson> Mere mortals like me have to outsource some of those brain cells.
<infinity> cjwatson: I always assumed rapid computer lookup or firefox history help, until I saw him rattle off bug numbers over beer.
<wgrant> It's not something to aspire to.
<cjwatson> Of course over beer the chances of having one's bluff called are a *bit* less
<wgrant> Heh
<infinity> cjwatson: But call it, we did.
<leszek> chrisccoulson: and one addition. We build for trusty.
<infinity> cjwatson: This is why the smart phone was invented.
<slangasek> tdaitx: glew can't be built with gles2, it's gl only; and qt4-x11 is not going to use gl1 for arm, because that means losing accelerated drivers.  Option 3 is to make opencsg do something smarter than asking qmake for GL library information (because qmake).  I thought robru had looked at one of these earlier, don't remember if it was opencsg or not - you might want to compare notes
<slangasek> Logan: whereas we didn't> the launchpad link you posted clearly shows a package name change for gtkmm2.4
<tdaitx> slangasek, k, thanks
<doko> barry, skipped: enum34 (0 <- 103)
<doko>     got: 249+0: a-68:a-44:a-35:i-36:p-35:p-31
<doko>     * amd64: python3-pykmip, python3-zeroconf
<barry> doko: as soon as zigo's update to experimental's pykmip lands, i'll sync that to wily.  thought i'd already dealt with zeroconf, but i can't find it, so will deal
<barry> oh, looks like git was updated but it wasn't uploaded
<pitti> dobey: \o/ fourth time is the charm (mir boottest)
<chrisccoulson> leszek, if you're building for trusty, don't use the gcc in trusty-updates
<leszek> ok
<flexiondotorg> cjwatson, Does Ubiquity have any support for fcitx?
<cjwatson> flexiondotorg: I don't know
<cjwatson> grep source or ask cyphermox
<dobey> pitti: great. thanks
<Logan> slangasek: sorry, there was a context switch
<Logan> slangasek: the original one I was talking to you about was gtkglextmm, where we didn't make the name change but Debian did
<Logan> but they also bumped a build dependency on gtkmm2.4 to Debian's latest version, which included all of the Ubuntu changes except for changing the std
<Logan> so I was asking doko if we could just pull that in and whether the std change was necessary
<cyphermox> flexiondotorg: it doesn't do anything special about it, that I know. might want to grep the source as cjwatson suggested
<smoser> cyphermox, https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1489959
<ubottu> Launchpad bug 1489959 in multipath-tools (Ubuntu) "power8 scsii disks get blacklisted from multipath / curtin installed system doesnt boot" [Undecided,New]
<smoser> wonder if you have any thougths tehre, or would be able to debug that.
<cyphermox> do you just add multipath-tools in curtin? You'd also probably need sg3-utils
<cyphermox> (if it's udebs you want sg3-udeb)
<smoser> if you need that, should you not depend ?
<smoser> cyphermox, 'apt-get install multipath-tools-boot' is all curtin does.
<smoser> so even a recommends would get pulled in
<cyphermox> at which point is this then? when starting the install or after the system is installed?
<smoser> well, the install detects that it needs multipath (by looking for identical block devices, not by using multipath at all)
<cyphermox> sure
<smoser> and then installs multipath-tools-boot if necessary , configures target and expects boot to work.
<smoser> by configures, i mean :
<smoser>  - writes 'user_friendly_names yes' to /etc/multipath.conf
<cyphermox> ok, so you need to pull in sg3-utils-udev too, and probably check whether /etc/multipath/wwids and /etc/multipath/bindings are copied from the installation into the installed system (and the initramfs is updated)
<smoser>  - writes /etc/multipath/bindings for the boot device
<smoser>  - updates initramfs.
<cyphermox> in the bug there isn't enough information to tell -- if you add all of multipath -v3  I could tell
<cyphermox> ah
<cyphermox> yes, then it's probably the wwids file missing
<smoser> i attached -v3
<smoser> i dont thinks o.
<smoser> even in running environment '-ll' does nothing
<smoser> when it should
<cyphermox> hm, it shouldn't complain about the properties missing
<cyphermox> what does multipath -t say?
<doko> Logan, context?
<smoser> sg3-utilshttp://paste.ubuntu.com/12215510/
<smoser> http://paste.ubuntu.com/12215510/
<Logan> doko: I was wondering if we could sync over the changes in https://launchpad.net/ubuntu/+source/gtkmm2.4/1:2.24.4-1.1ubuntu1
<Logan> or if we need to merge in the std=c++11 change (which wasn't applied in Debian)
<doko> Logan, sync it. I think they reverted back to an older glibmm
<smoser> cyphermox, thats on the wily system that booted without  multipath , then i apt-get install multipath. it did correctly (as you implied) gety sg3-utils. but seems still to not consider those disks as multipath. when in vivid it does.
<cyphermox> check if udevadm info --query=all --name=/dev/sda shows SCSI_IDENT_* properties
<cyphermox> that's pretty much all there is to it -- these properties are used instead of just ID_SERIAL to decide if it should be multipath devices
<smoser> http://paste.ubuntu.com/12215543/
<cyphermox> and you said sg3-utils-udev is installed?
<infinity> multipath-tools depends on it, I don't see how he could be missing it.
<smoser> for reference, same trusty: http://paste.ubuntu.com/12215554/
<smoser> and yes, sg3-utils-udev is installed.
<infinity> But it might need some udev prodding if it's installed post-boot?
<smoser> cyphermox, with vpn... can you get to 10.245.71.133 ?
<cyphermox> well, the initramfs needs to be updated but postinst probably should have done it
<smoser> i can let you poke at a trusty box and a wily box if you can.
<smoser> initramfs is updated.
<infinity> And rebooted since?
<smoser> curtin does that explicitly. making 14 times on average that initramfs gets updated in an install :)
<cyphermox> I think he wants to see the devices first
<cyphermox> but even then, multipath -ll shouldn't say that the devices are blacklisted
<infinity> Well, if we've not rebooted, updating initramfs makes no difference. :P
<infinity> And adding udev rules post-boot also does nothing.
<cyphermox> well, udev would need to be prodded anyway
<cyphermox> smoser: I can get to it but I have no access
<smoser> right. my expectation is that multipath -ll should work
<smoser> cyphermox, ok. i'll let you in then
<infinity> You'd have to re-trigger udev if you want the new rules to kick in.
<cyphermox> yep
<smoser> infinity, well, presumably that would happen on reboot.
<infinity> Probably just 'udevadm trigger -s scsi' or similar.
<smoser> and it does in trusty -> vivid and did in wily up until recently.
<infinity> smoser: Sure, on reboot it would, which was why I was trying to clear up if this was broken after your apt-get, after reboot, or both.
<infinity> smoser: Specifically, the lack of SCSI_IDENT stuff in your paste.
<cyphermox> smoser: you can't compare trusty/vivid to wily when there's been a major update
<smoser> cyphermox, ok. you should be able to ssh into ubuntu@10.245.71.133 (wily) and for reference ubuntu@10.245.71.134 (trusty)
<smoser> both systems be nice and rebooting probably need to ask someone else about.
<smoser> ie, doko is using the wily system right now.
<cyphermox> ran udevadm trigger -s scsi, that's it
<infinity> cyphermox: I win?
<flexiondotorg> cyphermox, Thanks. I did grep the code, no mention of fcitx. I was just checking there wasn't some additional functionality tucked away in the indicators.
<cyphermox> infinity: well, it's still not creating the paths, but if the devices are already loaded it might be hard
<infinity> cyphermox: But that made the extra attributes show up?
<smoser> yeah. it did.
<cyphermox> no multipath-tools-boot installed won't help rebooting on multipath
<infinity> cyphermox: If so, you could retrigger the multipath events afterwads, I suspect.
<cyphermox> infinity: yep
<cyphermox> the properties show up now
<infinity> cyphermox: Alternately, one could manually install s-thing-udev, udevadm trigger, then install multipath-tools, which might get it in the right order to not have to do more triggering.
<infinity> cyphermox: Bonus point, perhaps s-thing-udev could trigger -s scsi in its postinst, and this would Just Work?
<cyphermox> infinity: yeah
<cyphermox> still there are other devices on that system and they should be getting picked up
<smoser> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/commands/curthooks.py#L468
<smoser> thats what curtin does for installation of mutipath
<smoser> we explicitly write multipath.conf and multipath/bindings
<cyphermox> there is definitely no multipath-tools-boot or /etc/multipath/bindings on that system right now
<smoser> right. because i disabled installation
<smoser> because if i enable it, it doesnt boot
<cyphermox> so we're currently looking at two very different issues
<cyphermox> along with writing the bindings file you really should add writing a wwids file
<smoser> where does that go and what would it look like ?
<cyphermox> it's format is pretty much /<SCSI_IDENT_LUN_T10>/  per-device or something like it
<cyphermox> it goes along with bindings in /etc/multipath/
<cyphermox> just running multipath -v0 will write both files for you though
<smoser> but not on diamond ?
<smoser> # multipath -v0 ; echo $?
<smoser> 1
<smoser> or are you saying you need a reboot?
<cyphermox> oh wait
<cyphermox> multipath -W will write the wwids file for you
<cyphermox> for some reason on diamond it's not liking any of the devices
<smoser> :)
<smoser> yes, thats the problem :)
<cyphermox> meh
<cyphermox> it's also not really in the best of state to be debugging this
<smoser> why ?
<smoser> its booted off one device, but it has 5 others that are not used.
<smoser> cyphermox, so why does 'multipath -ll' not work now ?
<cyphermox> Aug 28 17:10:24 | sdf can't store path info
<cyphermox> ^ I don't know
<smoser> ok,thank you for your help.
<smoser> is it ok if i leve you to poke at that, and can you give me some suggestion of how i should install and configure multipath support ? we've not had to write a WWID file in trusty -> vivid.
<smoser> it appears maybe i need to write the wwid in /etc/multipath/wwids ? which personally seems quite silly if i've declared the same id in /etc/multipath/bindings.
<cyphermox> I doubt writing the wwids will help in this case, looks like a legit bug for these devices
<smoser> ok. well i'll leave you to debug, ok ?
<smoser> thank you again for your help.
<slangasek> Logan: ah yes :)
<Logan> doko: Bug 1489980
<ubottu> bug 1489980 in gtkmm2.4 (Ubuntu) "Sync gtkmm2.4 1:2.24.4-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1489980
#ubuntu-devel 2015-08-29
<ricotz> mdeslaur, hi, maybe you could push a no-change rebuild of handbrake for ffmpeg-transition
#ubuntu-devel 2015-08-30
<ari-tczew> doko: could you check please bug 1486878 ? I guess you might be interested
<ubottu> bug 1486878 in llvm-toolchain-3.4 (Ubuntu) "Sync llvm-toolchain-3.4 1:3.4.2-15 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1486878
<doko> ari-tczew, no, better remove it, we already have three newer versions
<doko> infinity, please manually build jruby with the jruby binary from unstable. it's a self dependency (jruby-openssl -> jruby), which I removed for a first build
<cjwatson> doko,infinity: I got http://paste.ubuntu.com/12232239/ when I tried that locally
<doko> cjwatson, hmm, works for me locally. strange
<tdaitx> cjwatson, not sure why it would work on doko's system, but from the message it seems to be missing the libjzlib-java dependency in debian/control
<tdaitx> I tried to build it locally to be sure this is the right fix, but mine is failing with:
<tdaitx> The following packages have unmet dependencies:
<tdaitx>  sbuild-build-depends-jruby-dummy : Depends: locales-all but it is not installable
<doko> tdaitx, I fixed that in my last upload to wily-proposed
<tdaitx> doko, jruby_1.7.21-2ubuntu2, right?
<doko> yes
<tdaitx> I'm running it and still having that locales-all issue
<doko> it had locales-all | language-pack-en
<infinity> tdaitx: You need to ask sbuild to consider alternate build-deps.
<tdaitx> oh
<tdaitx> that!
<infinity> tdaitx: --resolve-alternatives
<tdaitx> infinity, thanks! ;-)
<tdaitx> gosh, I noticed that cjwatson was using it but didn't remember to set it myself
<doko> infinity, one more thing: build antlr3 using the debian binaries for libantlr3-runtime-java_3.5.2-2_all.deb and libstringtemplate4-java_4.0.8-2_all.deb. then stringtemplate4 should be buildable
<tdaitx> doko, cjwatson, confirmed, adding libjzlib-java dependency to jruby fixes it, debdiff @ http://paste.ubuntu.com/12233217/
<tdaitx> let me know if you want me to open a bug report on lp and submit it there
<teward> if I use sbuild to build a package, and I have sbuild keepingi the environments, how can I enter the environment to see the environment
#ubuntu-devel 2016-08-29
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> (whoops, forgot to reset on Friday)
<pitti> Good morning
<jbicha_> pitti: good morning, have you seen bug 1614820 ?
<ubottu> bug 1614820 in apport (Ubuntu) "Respect gsettings org.gnome.desktop.privacy report-technical-problems" [Wishlist,New] https://launchpad.net/bugs/1614820
<pitti> jbicha_: hey, good morning! I saw it fly by, just haven't looked at it yet (ETIME, sorry)
<jbicha> ok, maybe next release cycle then
<pitti> jbicha: it would be really hard to avoid generating the /var/crash/ files, but merely not reporting them should be fairly straightforward in apport-gtk?
<pitti> jbicha: i. e. this is just checking for that gsettings key?
<pitti> org.gnome.desktop.privacy report-technical-problems false
<pitti> jbicha: but why is this off by default?
<pitti> jbicha: we certainly don't want that
<jbicha> we can ship a gsettings override, perhaps in apport itself, for that
<pitti> jbicha: not in apport, that would be rude (changing defaults of some other package)
<jbicha> the package is gsettings-desktop-schemas
<jbicha> we have lots of overrides in ubuntu-default-settings and ubuntu-gnome-default-settings but some people don't have those installed
<jbicha> (ubuntu-settings)
<jbicha> the only thing actually using that key right now I believe is Fedora's abrt so it doesn't hurt anything to set that key how we want it
<pitti> jbicha: another concern is that we already have such a setting somewhere ("Send error reports to Canonical")
<pitti> so that ^ one should move to this new official key
<pitti> I followed up to the bug with a summary
<jbicha> pitti: the gsettings key is from update-notifier so maybe that part of the bug doesn't need any apport changes
<jbicha> but the other part of the bug is that GNOME expects the bug reporting service to run a org.freedesktop.problems.daemon dbus service, what do you think about that?
<pitti> jbicha: apport isn't a daemon, what should this  do?
<pitti> and what happens if it's not there?
<jbicha> if it's not there, GNOME doesn't show the on/off switch to report bugs in Intial Setup and gnome-control-center's Privacy pages
<jbicha> we could run a service that does nothing (that works) or we could patch the 2 apps to skip checking for that service
<jbicha> I guess patching the apps would be better if there's no reason otherwise for apport to listen on dbus
<pitti> rharper, smoser: FYI, netplan 0.10 just landed in y, with support for vlan
<pitti> mwhudson, rharper, smoser: I'm going to look into wifi with networkd first (blocking ogra), is there anything else which is blocking you wrt. netplan?
<cpaelzer> good morning
<mwhudson> pitti: if you could spend 5 mins looking at https://github.com/snapcore/snapd/pull/1765 that'd be great
<mwhudson> pitti: but i am off sick _and_ EOD so no hurry :)
<LocutusOfBorg> jbicha, hi, do you plan to look at kido?
<LocutusOfBorg> I see some upstream activity
<jbicha> LocutusOfBorg: the best I came up with was filing bug 1617835 but if you can do better, go ahead
<ubottu> bug 1617835 in kido (Ubuntu) "Please remove fcl 0.5.0-1 from yakkety-proposed" [High,New] https://launchpad.net/bugs/1617835
<LocutusOfBorg> jbicha, fcl is fixed in Debian I see
<LocutusOfBorg> let me see
<LocutusOfBorg> it might be trivial
<Saviq> pitti, morning, could I ask you to restart the last missing test in https://requests.ci-train.ubuntu.com/static/britney/ticket-1864/landing-067-xenial/excuses.html - it seems to have disappeared - and also https://requests.ci-train.ubuntu.com/static/britney/ticket-1864/landing-067-yakkety/excuses.html - not sure what made it uninstallable there
<pitti> mwhudson: ugh, get well soon!
<pitti> Saviq: sorry, had to kill some running tests due to cloud maintenance, will restart
<Saviq> tx
<ogra_> pitti, nothing else for now ...
<ogra_> (we dont have networkd on the images though)
<ogra_> (and i dont see it in the xenial archive)
<pitti> ogra_: sure you do
<pitti> it's in the systemd package :)
<ogra_> ah, it doesnt have its own binary package ?
 * ogra_ kind of expected that 
<gb_mks> hello
<gb_mks> I found a bug related in the package "click-review". Can anyone help me to solve it? https://bugs.launchpad.net/click-reviewers-tools/+bug/1617288
<ubottu> Launchpad bug 1617288 in Canonical Click Reviewers tools "click-review assumes Ubuntu vendor" [Undecided,New]
<Saviq> pitti, hey, we're trying to get to grips with unity8 failures in britney, we've a bunch of flaky fixes in store, but the most common issue these days seems to be a time out, how long is the timeout on autopkgtests in britney by default? from looking at timestamps, it seems to be 3h - a passing run of unity8 seems to be between 2h and 2h54m (even though http://autopkgtest.ubuntu.com/packages/u/unity8/yakkety/amd64/ says 5h33m, but that seems to be some
<Saviq>  delay outside of the test run itself?)
<pitti> Saviq: right, the default timeout is 10,000s, i. e. roughly 2:50 hours
<pitti> Saviq: right, lcy01 has been very unstable (should be fixed now), so some tests were attempted several times
<Saviq> yup, that sounds about right
<Saviq> pitti, is it possible to increase the time out for unity8?
<pitti> Saviq: but these cloud failures should not appear as test failures, they get auto-retried until it finishes
<Saviq> I can easily imagine it going over the 2:50h mark if the system load is higher, for example
<pitti> Saviq: it is, if they legitimately take that long
<pitti> so if they don't just hang eternally on something
<pitti> Saviq: does that affect all arches?
<Saviq> pitti, we only claim victory on those on amd64 and i386, and both sometimes go over the 2h50m limit
<Saviq> pitti, it would go down considerably if they were run in parallel
<pitti> Saviq: qmluitests.sh seems to need around 1:45 h, well below the 2:50 h limit
<Saviq> because there's at least some time spent in those tests waiting (we're improving that now, too)
<pitti> Saviq: do you actually see such a timeout in http://autopkgtest.ubuntu.com/packages/u/unity8/yakkety/amd64/ ? I don't
<Saviq> pitti, I think it depends a lot on the load, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid-ci-train-ppa-service-landing-092/vivid/i386/u/unity8/20160822_110521@/log.gz
<pitti> the failures there are pretty fast
<Saviq> pitti, I've only seen those on PPA tests, couldn't find any example on proposed migration
<Saviq> lemme have a good look again
<pitti> Saviq: so this might rather be vivid vs. yakkety?
<pitti> Saviq: anyway, I can bump it, but I'd really not do it if these are eternal hangs
<pitti> these are blocking the infra long enough already
<Saviq> pitti, we have one potential example of an eternal hang there, we're working on fixing that now, too - but it's tricky to say it really is if we're getting timeouts for other reasons, too
<Saviq> pitti, about parallel, do the test nodes have more than one core?
<pitti> Saviq: normally not
<pitti> Saviq: we can mark it as "big test" and give it 4 cores and more RAM, if that helps to speed up the test considerably, i. e. if it actually *can* run in parallel
<Saviq> pitti, they do run in parallel in our CI
<pitti> Saviq: the tradeoff is that they are much more likely to fail due to cloud capacity issues
<pitti> Saviq: so if they automatically use more available cores, I can add it to that list
<Saviq> pitti, we rely on DEB_BUILD_OPTIONS=parallel, is that going to be set?
<pitti> yes, that happens automatically
<Saviq> pitti, I'd say let's try that
<pitti> Saviq: oh, is the autopkgtest a package build?
<Saviq> pitti, no
<Saviq> it's 1300 UI tests
<pitti> D_B_O is only set for builds, not for tests
<pitti> as this is a dpkg-buildpackage specific thing
<Saviq> hmm, bug #1399177 ?
<ubottu> bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Wishlist,Fix released] https://launchpad.net/bugs/1399177
<pitti> tests should ask nproc or /proc/cpuinfo etc.
<Saviq> ah ack
<Saviq> so builds but within adt-run
<Saviq> still
<Saviq> we'll fix that then
<pitti> eek, indeed
<Saviq> pitti, let's mark unity8 big, then, and I'll land a fix to the test script to talk nproc
<pitti> Saviq: is it really necessary to build the package for running the tests?
<Saviq> pitti, we're not building the package
<Saviq> we're building a few mocks
<pitti> Saviq: also, the build doesn't happen via "Restrictions: build-needed" by autopkgtest itself, but the test calls dh_auto_configure etc., so it's manually building the package without dpkg-buildpackage
<Saviq> pitti, it's not building the whole thing, only some mocks
<Saviq> but yes, we're doing away with that too
<pitti> ah, ok
<Saviq> we'll package those mocks soon
<pitti> Saviq: so, back to the question: will any of this actually use more than one core if they are available?
<Saviq> pitti, not right now, if adt-run doesn't set D_B_O parallel, I'll have to fix the test to do that from nproc then
<Saviq> so maybe it doesn't make sense to mark it big yet
<Saviq> to not block the infra
<Saviq> pitti, can we increase the time out to 3h30m or so for now, it should give us a bit more info on whether we have a real issue or not
<Saviq> and I'll work on getting nproc in and we'll mark unity8 big after that's done
<pitti> Saviq: I can set it to 40,000 s by adding it to the "long_tests" list (i. e. roughly 12 h)
<Saviq> pitti, right, if I see any time out there then, we'll know it's our fault
<Saviq> that would work
<pitti> Saviq: ok, rolled out that change
<Saviq> pitti, thanks, I'll let you know how we're doing
<pitti> ack
<mardy> pitti: hi! a new version of gnome-control-center-signon has landed in yakkety, so hopefully the version number is now consistent
<mardy> pitti: (talking about bug 1565772)
<ubottu> bug 1565772 in gnome-control-center-signon (Ubuntu Yakkety) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,In progress] https://launchpad.net/bugs/1565772
<LocutusOfBorg> jbicha, kido is good
<LocutusOfBorg> fcl too, assuming somebody removes the armhf binary :)
<pitti> mardy: thanks! I'll mark it as v-needed  (dropping v-failed) once LP comes back (has been down for me in the last 10 mins)
<mardy> pitti: OK, thanks
<smoser> pitti, we do need bonds.
<ogra_> james bonds ?
<pitti> smoser: ok, I have that on the list for early September
<kenvandine> pitti, ping
<kenvandine> pitti, we're about ready to land some work in libertine that makes it build depend on content-hub, which depends on ubuntu-app-launch... which of course depends on upstart :)
<kenvandine> so we need the libertine binaries to be removed for s390x in yakkety
<kenvandine> pitti, can you please help out with that?
<dobey> omg circular deps
<pitti> kenvandine: removed; AFAICS the reverse dependencies of libertine shoudl already be removed
<kenvandine> pitti, thanks!
<kenvandine> ChrisTownsend, ^^
<ChrisTownsend> pitti: kenvandine: Thanks!
<jonathon> Is it possible to get a package update into universe? The SRU wiki page doesn't mention universe (there's a link to an anchor from the MOTU page but it's not there any more).
<pitti> jonathon: there is no difference wrt. the policy, i. e. "yes"
<jonathon> Right-o, thank you. I'll read through the pages a few more times. :)
<rbasak> infinity: are you chairing the DMB meeting in five minutes?
<rbasak> BenC: around?
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<pitti> awe: yay, I read the NM 1.4 announcement yesterday, seems our ofono patches are upstream now? congrats!
<ogra_> woah !
<awe> thanks pitti!
<pitti> awe: Debian already has 1.4, so merge o'clock soon?
<awe> hehe
 * awe hopes there are no dbus interface changes
<pitti> awe: yeah, "Canonical contributed ... ofono support" was a nice read there :)
<ogra_> the result of years of work ....
<awe> indeed
<pitti> awe: allegedly the API has stayed very stable, even 1.2 plugins still work with NM 1.4
<awe> abeato got a nice mention as well for his statistics API
<awe> pitti, yes... that's pretty much true, although the move to gbus had some unexpected side-effects
<awe> also, there's still a bit of code that didn't get merged upstream
<awe> so we'll still need to carry some patches
<awe> but it was a good start
<awe> and hopefully we can continue to push more code to them
<cpaelzer> hi, anybody here knows how/where I should reach out to get s390x enabled in an ppa on LP ?
<attente> hi, i'm getting this debootstrap error: "chroot: cannot change root directory to '/home/william/tmp/root': Operation not permitted"
<attente> this is when running it with fakeroot in my home directory
<attente> is there a reason why debootstrap needs to chroot here?
<attente> is there a better way than using fakeroot?
<jonathon> cpaelzer: #launchpad might worth a look?
<dobey> attente: sudo?
<attente> dobey: trying to do this unprivileged in my home
<ogra_> attente, wont work, deboostrap needs to create device nodes ... you can try fakechroot ... if you actually like cans of worms
<ogra_> (or just download an ubuntu-base tarball ;) instead of building yourself )
<dobey> yeah, download the preinstalled tarball then
<attente> where is the tarball? i'll try that
<ogra_> http://cdimage.ubuntu.com/ubuntu-base/releases/xenial/release/ or http://cdimage.ubuntu.com/ubuntu-base/daily/current/
<ogra_> depending what you want
<elbrus> ginggs_: thanks (unfortunately the autopkg fails on ci.debian.net and I don't know why, as it works on my computer)
<elbrus> here it doesn't ask the password and that is correct. however on ci.d.n it does ask and fails because the isn't a valid answer at all
 * elbrus shakes his head in disbelief and will probably need to upload a package with more debugging output... but doesn't know what output would be good.... mysql -vvv or something
<ginggs_> elbrus: yw and good luck with the autopkg stuff
#ubuntu-devel 2016-08-30
<pitti> Good morning
<pitti> doko: are you okay with dropping python3-ldb again? it has no rdepends, is an Ubuntu specific delta, and needs the NBS python3-talloc to build (see http://people.canonical.com/~ubuntu-archive/nbs.html)
<jbicha> pitti: if you're processing nbs, libwebkit-dev is only an alternate build-depends for those packages
<pitti> jbicha: thanks!
<doko> pitti: sure, we can do that
* dinger-donger changed the topic of #ubuntu-devel to: To find big channels with unlocked topics, use /msg alis list * -min 100 -mode -t    Then you can join them and abuse their /topic for the lulz!
<pitti> !op @ dinger-donger
<ubottu> pitti: I am only a bot, please don't think I'm intelligent :)
<dinger-donger> lol
<pitti> dinger-donger: please leave the topic alone, this is vandalism
<dinger-donger> pitti: fuck that
* pitti changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* dinger-donger changed the topic of #ubuntu-devel to: To find big channels with unlocked topics, use /msg alis list * -min 100 -mode -t    Then you can join them and abuse their /topic for the lulz!  | I think pitti is a filthy homosexual
<pitti> dholbach: what's the magic incantation to ping IRC ops? dinger-donger needs to be kickbanned
* pitti changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Unit193: cheers
<dholbach> thanks Unit193 and pitti
<Unit193> Sure thing.
<dholbach> I don't know of any magic incantations
<dholbach> but I'm sure there are :)
<pitti> I thought we had some kind of !ops or so
<dholbach> yeah, I was about to suggest the same
<pitti> and I'm sure I've seen it before, I just forgot
<pitti> !help
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<pitti> !commands
<ubottu> The linux terminal or command-line interface is very powerful. Open a terminal via Applications -> Accessories -> Terminal (Gnome), K-menu -> System -> Konsole (KDE), or Menu -> Accessories -> LXTerminal (LXDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal
<dholbach> haha
<pitti> !nocookies
<Unit193> pitti: Use it like: !ops | bar is spamming the topic
<pitti> Unit193: ah, so my "!op @ bar" was close :)
<Unit193> Yep.
<pitti> !ops @ dholbach needs a hug
<ubottu> pitti: I am only a bot, please don't think I'm intelligent :)
<pitti> err
<pitti> !ops | dholbach needs a hug
<ubottu> dholbach needs a hug: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
<pitti> sorry, unping -- already sorted out
 * pitti hugs dholbach anyway
<ikonia> pitti: can you stop that please
 * pitti notices that this list of people is *very* outdated
<pitti> Unit193: do you know how to update that list?
<ikonia> it's just a bot factoid
<ikonia> it can be updated pretty easy
<Mirv> 1.5h of waiting publisher run so far, doh.
<pitti> yeah, the entirety of LP and the DC have felt like tar since ~ yesterday :/
<ogra_> someone sitting on a cable ?
 * pitti blames the brexit, apparently lost fast connections to the UK :)
<ogra_> we should temporary redirect to the US then ... at least until trump is elected
<JanC> why not move it to Germany instead?  :)
<ogra_> :)
<pitti> infinity: let there be Testsuite-Triggers: in britney! https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/commit/?id=4d7522ddb8
<pitti> apw: ^ you were interested in this as well
<ogra_> adam is off this week
<apw> pitti, i am interested indeed.  I assume this is going to let me suck some of the random lists out into my packages ?
<pitti> apw: yes
<apw> pitti, like the link between the kernel and lxc ?
<pitti> apw: for example, we should now make lxc or lxd grow a test dependency on linux-libc-dev or linux-generic or similar
<pitti> lxc *and* lxd
<apw> pitti, so lxd would say Test-Triggers: foo in its main debian/control file and that would mean changes to package foo will trigger that package's tests
<apw> s/that package/lxd
<pitti> correct
<pitti> except that you shouldn't really set T-T: manually; if not present it gets computed from debian/tests/control in a reasonable way
<infinity> pitti: Oh, yeah.  I forgot about that part of the implementation.  Did you implement merging of T-T and tests/control?
<infinity> pitti: Cause I disagree.  Setting artificial test deps to get them in T-T is wrong. :P
<infinity> (Even if I just did it in glibc...)
<pitti> infinity: no, that is not yet implemented, it's still the initial debian implementation
<pitti> (also, that's dpkg again, not britney)
<infinity> pitti: Yeah, I meant the dpkg implementation.  I didn't read it.
<infinity> pitti: Definitely should be merging debian/control and debian/tests/control, IMO.
<pitti> infinity: well, linux-generic is not conceptually an artificial test dependency -- so far it's just been an implied one
<infinity> pitti: Feels "dirty" to put manual deps on build-essential packages just to get triggers.
<apw> pitti, and how do i say "all valid kernels"
<infinity> Triggering on all kernels is trickier.
<infinity> Right now, it would just be "list them all".
<pitti> yeah, you can't right now, unless they all build a common binary
<infinity> pitti: Which they can't, for obvious reasons.
<pitti> for linux-* in particular the code in britney is still necessary/easiesr
<pitti> this will mostly help for everything !linux so far
<pitti> we often get regressions which are due to a changed test dep
 * apw goes back to being interested (rather than excited)
<infinity> Heh.
 * infinity goes back to being on vacation.
<pitti> infinity: heh, do that; let's talk about details of merging T-T when you are back
<infinity> pitti: *nod*
<infinity> pitti: It's not urgent by any means.  If people choose to use the feature as it is, it works to put things in test-deps, and they can move them later if they feel the urge.
<infinity> pitti: Mostly, I think it'll be "prettier" for essential and build-essential, basically.  But my taste isn't everyone's.
<pitti> infinity: right now the goal is to trigger on the actual real test deps
<infinity> pitti: Yeahp, but essential are deps of *all* tests, and build-essential is a magic dep.
<pitti> we can *also* use this to reduce the hardcoded trigger lists in britney, but that's more of a side result
<infinity> pitti: And if you want explicit testing when shadow changes, do you list shadow in your deps, or as a trigger in debian/control?
<infinity> pitti: Both work, but the latter seems more "right".
<pitti> infinity: you can set T-T: manually of course; you just (right now) lose the automatic value computed by dpkg
<infinity> pitti: Or, in the glibc case, I have "build-essential, binutils, gcc, linux-libc-dev" (well, a bit more complex, but basically that) which is equally weird. ;)
<pitti> infinity: but yes, if you explicitly test shadow, then adding shadow into d/t/c Depends: would do it
<infinity> pitti: Right, I don't think it makes sense to set it manually until it merges.
<infinity> pitti: But, as I said, people can just use test-deps and ignore T-T in debian/control entirely for now, so the feature works.
<infinity> (Which is what I'm doing)
<infinity> Off to find breakfast to fuel more vacation gaming.
<infinity> Toodles.
<pitti> apw: so to your question: "all linux kernels" isn't declarative, we always need a piece of code to answer that
<pitti> apw: so I think this part will stay in britney for a while
<pitti> (or forever)
<infinity> apw: Yeah, I think the only way to make "all kernels" declarative would be to have an all kernels meta that pulls in all kernels for each platform. :P
<infinity> Which probably isn't what you really want either.
<infinity> Cause what you really want is to test foo-on-raspi2 *running* raspi2 on a raspi2 device.
<infinity> Installing the raspi2 kernel in an lxc on a -generic device tells you nothing about runtime deps.
<infinity> s/deps/tests/
<infinity> Though it works for testing build-time dkms stuff, I guess.
<infinity> apw: Like, ideally, we should sort out a way to run x86 tests twice, once with -generic installed and once with -lowlatency.
<infinity> apw: And it just gets way trickier for ARM, cause we may also need to target kernel foo to worker bar to match hardware.
<infinity> apw: Considerations for a future iteration. :P
<pitti> infinity: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-autopkgtest-test-classes FYI
<pitti> apw and I discussed/designed this a while ago, but it didn't get implemented yet
<infinity> pitti: Fancy.  I will avoid reading it until next Tuesday. ;)
<ddellav> can i get an archive admin to promote python-yaql and python-monascaclient to main please? There were approved MIR's but no promotion: https://bugs.launchpad.net/ubuntu/+source/python-yaql/+bug/1586069 https://bugs.launchpad.net/ubuntu/+source/python-monascaclient/+bug/1590836
<ubottu> Launchpad bug 1586069 in python-yaql (Ubuntu) "[MIR] python-yaql" [Undecided,Fix released]
<ubottu> Launchpad bug 1590836 in python-monascaclient (Ubuntu) "[MIR] python-monascaclient" [Undecided,Fix released]
<kgunn> tjaalton: ping
<kgunn> ug this network
<kgunn> tjaalton: ping
<brendand> is there anything i can do to allow nested vms when using adt-virt-qemu?
<brendand> with autopkgtest
<pitti> brendand: it should mostly Just Workâ¢
<brendand> pitti, the thing is i'm getting 'ERROR    Host does not support any virtualization options' from virt-install
<pitti> brendand: as a convenience there is /dev/baseimage which is the (read-only) block device of the image you passed to autopkgtest-qemu
<pitti> brendand: can you run "-- qemu -d ...]"? there should be some "Detected KVM capable Intel host CPU, enabling nested KVM" or similar for AMD
<rbasak> kvm_intel.ko should be loaded. Or AMD equiv.
<tjaalton> kgunn: pong
<kgunn> tjaalton: hey there, so i'm trying to rebuild mesa on dragonboard
<kgunn> tjaalton: if i use dpkg-buildpackage will gallium be built as a default?
<kgunn> figured you might know
<tjaalton> kgunn: i'm not sure, check rules
<kgunn> k
<tjaalton> or d/control, if it build-depends on it
<tjaalton> uh.. it==llvm
<rcj> pitti, looks like theres a kpartx regression in util-linux for 2.28.1-1ubuntu1 in yakkety bug# 1618525
<kgunn> tjaalton: so from rules...it seems to suggest on arm64 it will build gallium
<tjaalton> kgunn: right, iirc that was a fairly recent change
<tjaalton> can't check atm
<ddellav> Also if possible we need someone on the MIR team to promote designate: https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1543748 It's passed it's security review
<ubottu> Launchpad bug 1543748 in designate (Ubuntu) "[MIR] designate" [High,New]
<kgunn> tjaalton: no worries...thanks for pointers anyhoo
<slangasek> infinity, kees, stgraber: tb meeting?
<doko> seb128, Laney, tjaalton, Mirv: is there anything which should migrate to the release pocket before starting a test rebuild?
<seb128> doko, not that I know of no...
<Mirv> doko: yes http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src has the gold linker disabling for powerpc. there's no actions from Kubuntu side on the KDE autopkgtest issues, they nowadays usually ask to ignore those. I don't see anything terribly worrysome in there in those failures.
<Mirv> while ignoring those, the qtdeclarative-opensource-src below would also migrate to release pocket which has two fixes already in stable phone images
<doko> ok, waiting for these
<Mirv> doko: those are not happening without overriding the autopkgtests though
<Mirv> if any archive admin wouldn't mind ^
<doko> jamespage, rbasak: anything you want to have in the release pocket from the server side before a test rebuild?
<Mirv> so akonadi-calendar bluez-qt kalarmcal kdeclarative kglobalaccel libkdegames modemmanager-qt5 networkmanager-qt5  (and akonadi in the sense its s390x test seems stuck but is required)
<acheronuk> I know yofel said we (kubuntu) simply don't have the resources ATM to address those failures
<doko> Mirv: that's a release-team action, not an archive-team action. please could you ask on #ubuntu-release?
<slangasek> Mirv: akonadi-calendar claims abi compliance checker passes on armhf and s390x but fails on x86 + ppc64el; would like to understand this failure to be sure it's really not an interface regression before overriding those failures
<slangasek> bluez-qt is ok, non-ABI-changing symbol drop
<slangasek> OTOH it's also easily fixed...
<slangasek> Mirv: bluez-qt fix uploaded; the rest are all dh_acc regressions, which I would want to know the truth of before overriding
<Mirv> doko: sorry, right
<jamespage> ddellav, coreycb: hey ping me tomorrow and we'll go through the seed process for designate otherwise it will bounce straight back into universe
<coreycb> jamespage, ok that'd be good to learn about
<doko> slangasek, Mirv: when were these dh_acc regressions run?
<Mirv> slangasek: thanks for the bluez-qt, I also saw that's easy one. I've asked on #kubuntu-devel and associated people were pinged. they are low on people who know about the autopkgtests (which are inherited from Debian) right now though.
<Mirv> doko: I think the relevant time frame might be "after libc update"
<Mirv> compared to the earlier build + autopkgtests which was after GCC6 but before libc6
<doko> Mirv: if these were run with earlier versions than gcc-6 6.1.1-12 then please retry
<Mirv> doko: looks like gcc-6 6.2.0-1ubuntu12 (and gcc 4:6.1.1-1ubuntu2)
<doko> hmm, ok
<Mirv> at least for akonadi-calendar
<Mirv> anyway, I can't stay a moment longer now, see you in 10h
<doko> I love it that dh_acc is soo verbose
<doko> xnox: ^^^ ;-P
<slangasek> doko: several times, as linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<xnox> there was one bug that i filed that dh_acc was failing on qt stuff.
<xnox> i didn't debug the failures again after doko reverted "upstream fix" to unbreak dh_acc
<xnox> there might be gcc leaked symbols in the dh_acc output that need updating....
<slangasek> xnox: do you have a bug # for that?
<doko> that could be too
<xnox> the reverted upstream fix or the guess that there are gcc leaked symbols since that?
<xnox> the latter is just a wild guess, based on previous abi migration
<xnox> (note we don't have an abi migration this time around, apart from some cases when we do)
<xnox> (because upstream "fixed" abi tags in templates resolutions...)
<doko> no, the reversion is just a removed inline attribute. the original issue that such files are not built with GCC 6 is not yet fixed
<slangasek> xnox: a bug # for what you filed about dh_acc failing on qt stuff...
<xnox> doko, ah.
<xnox> it was not the bug that i filed.... let me recall where it was, it was pointed out to me by mirv/doko or some such.
<doko> xnox, slangasek: the upstream issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72813 (and the r198733 commit is now reverted in the packages)
<ubottu> gcc.gnu.org bug 72813 in c++ "[6/7 Regression] atomic header cannot be compiled into translation unit with -fkeep-inline-functions" [Normal,New]
<xnox> and that's dh_acc with qt bug, beacause dh_acc uses that flag & qt things include atomic header eventually which fail to compile
<doko> right, but that is now reverted
<tjaalton> doko: I don't have anything
<acheronuk> LP: #1609273
<ubottu> Launchpad bug 1609273 in kxmlgui (Ubuntu) "kxmlgui fails autopkgtest (abi compliance)" [Undecided,New] https://launchpad.net/bugs/1609273
<doko> tjaalton: ack
<semiosis> bdmurray: adding test instructions to the bugs now
<semiosis> bdmurray: done for bug 1565985
<ubottu> bug 1565985 in livecd-rootfs (Ubuntu Xenial) "vagrant vb ubuntu/xenial64 cannot mount synced folders" [High,In progress] https://launchpad.net/bugs/1565985
<semiosis> bdmurray: bug 1561250 already has a pretty concise description with how to reproduce/test
<ubottu> bug 1561250 in livecd-rootfs (Ubuntu Xenial) "Xenial vagrant image is missing its hostname in /etc/hosts" [High,In progress] https://launchpad.net/bugs/1561250
<bdmurray> semiosis: sudo echo is the testcase for bug 1561250?
<ubottu> bug 1561250 in livecd-rootfs (Ubuntu Xenial) "Xenial vagrant image is missing its hostname in /etc/hosts" [High,In progress] https://launchpad.net/bugs/1561250
<semiosis> sudo anything
<bdmurray> okay, cool
<semiosis> sudo does a localhost lookup, apparently
<sarnold> lol "see the error ^^^^"
<semiosis> s/localhost/current hostname/
<semiosis> and how am I now able to edit the descriptions of those bugs I did not create?  did someone grant me that authority?
<bdmurray> anybody can edit bug descriptions
<semiosis> oh ha!  never noticed that
<tdaitx> what are the usual suspects on a "Build killed with signal TERM after 150 minutes of inactivity"?
<tdaitx> Some context: sometimes openjdk builds fail during the build and while I can see make's message "recipe for target blah/blah failed" + "dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2" on the ppa's build page the build isn't killed right away... While I can reproduce the failure itself, I am unable to reproduce this hang+timeout on a sbuild/chroot build, so I wonder where I should be looking into
<tdaitx> slangasek, infinity, xnox, pitti ^ are you somewhat familiar with this?
<cjwatson> tdaitx: That indicates that your build left a stale process behind that we didn't manage to clean up.
<cjwatson> tdaitx: launchpad-buildd (unfortunately) currently uses sbuild in sudo mode, which isn't quite as good at cleaning up processes as the more usual schroot mode is.
<cjwatson> tdaitx: I'd suggest instrumenting debian/rules to dump a process tree on error, at which point you should be able to see what's going on locally.
<tdaitx> cjwatson, right, I will try that way then, thanks! =)
<robert_ancell> slangasek, hey, who do I need to bribe to let snapd-glib into yakkety?
<slangasek> robert_ancell: I take bribes
<slangasek> robert_ancell: and I've been working through the NEW queue slowly ;)
<robert_ancell> slangasek, it's gone up a bit in priority since we're going to need it to solve bug 1616943 properly
<ubottu> bug 1616943 in gnome-software (Ubuntu Yakkety) "Can't auth against U1 in g-s" [High,Confirmed] https://launchpad.net/bugs/1616943
<robert_ancell> i.e. will need to be SRUd back to Xenial
<slangasek> ok
<robert_ancell> slangasek, thanks
<robert_ancell> slangasek, and a heads up, I'm currently finishing a new binary package for it "snapd-login-service" and once we're happy with the API I'll do a soname bump. Both of which will need archive admin approval right?
<slangasek> yes
<slangasek> binary review tends to be lighter weight though
<robert_ancell> A question about multi-arch. I have a package (snapd-glib) that provides a library and a service. When I build the package the service is installed into /usr/lib/x86_64-linux-gnu/snapd-login-service but I get the lintian warning "E: snapd-login-service: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/snapd-login-service"
<robert_ancell> Should I ignore the warning or should I change something in my packaging?
<robert_ancell> Packaging in lp:~ubuntu-desktop/snapd-glib/ubuntu if anyone is interested
<robert_ancell> (The service is installed into $(libexecdir) via autotools)
<slangasek> robert_ancell: maybe you want to build with --libexecdir=/usr/lib ?  I apologize for getting the default wrong in debhelper when adding multiarch support originally
<robert_ancell> slangasek, that's what I was wondering. I noticed a number of packages seem to not be setting this. But if this is the correct behaviour I'll switch to that.
<slangasek> robert_ancell: please use the current debian/copyright spec, Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
<robert_ancell> slangasek, ok
<robert_ancell> My copy-pasting is caught out again! ;)
<slangasek> robert_ancell: also, what does it mean when you say 'License: LGPL-2 LGPL-3'?
<slangasek> the same code is made available under either license?
<robert_ancell> slangasek, yeah, that's what we ended up doing for liblightdm-gobject for some reason.
<slangasek> robert_ancell: ok.  standard syntax would be 'LGPL-2 or LGPL-3', then
<robert_ancell> And I just copied the same. I couldn't find our licence policy on the Wiki
<robert_ancell> ok
<slangasek> LDFLAGS+=-Wl,--as-needed
<slangasek> not needed in Ubuntu
<Unit193> slangasek: Might want to https that link, or lintian will give a warning.
<slangasek> curiously, lintian didn't care about the http pointing to a wrong url ;)
<robert_ancell> slangasek, has anything changed in the spec or is just the link wrong?
<slangasek> robert_ancell: the spec has likely changed since the svn rev you reference, yes - and lintian will then tell you about it :)
<robert_ancell> slangasek, lintian was only giving me that one warning about the libexec issue here
<slangasek> robert_ancell: yeah, because non-standard debian/copyright is allowed... but if you use the standard it'll do much more analysis
<robert_ancell> ah
<slangasek> robert_ancell: anyway, none of these are blockers, so 0.8-0ubuntu1 source accepted
<robert_ancell> slangasek, thanks! I'm prepping 0.10-0ubuntu1 right now and it will have those fixes.
#ubuntu-devel 2016-08-31
<pitti> Good morning
<pitti> rharper, smoser: https://launchpad.net/ubuntu/+source/nplan/0.12 -- my name is Bond. Net Bond.
<Unit193> BTW, is that going to Debian?
<pitti> Unit193: still a bit early I think
<Unit193> pitti: So that'd seem to indicate the plan is to push it there eventually, still an answer. :)
<Unit193> Thanks.
<pitti> needs upstreaming of some NetworkManager patches first
<ccshell> exec fc-match weight=80:family=å®ä½:lang=zh-cn   => it print:DejaVuSerif.ttf: "DejaVu Serif" "Book"
<ccshell> but fc-match weight=80:family=å®ä½ => uming.ttc: "AR PL UMing CN" "Light"
<ccshell> bug?
<sarnold> $ fc-match weight=80:family=å®ä½:lang=zh-cn
<sarnold> NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular"
<sarnold> $ fc-match weight=80:family=å®ä½:lang=zh_CN
<sarnold> DejaVuSans.ttf: "DejaVu Sans" "Book"
<LocutusOfBorg> jbicha, sorry, wrt refcard we reopened the bug at the same time :D
<tseliot> pitti: hi, are you familiar with this error in u-d-c? I can't build u-d-c in sbuild any more http://pastebin.ubuntu.com/23115343/
<tseliot> pitti: with a yakkety schroot
<tseliot> it builds fine in a xenial schroot
<pitti> tseliot: doesn't happen here, maybe your yakkety schroot has a different profile whose fstab doesn't mount /dev/pts?
<tseliot> pitti: I have this in the fstab: /dev/pts        /dev/pts        none    rw,bind         0       0
<tseliot> in /etc/schroot/sbuild/fstab
<pitti> hm, no idea then, I'm afraid :/
<tseliot> no problem
<caribou> shouldn't the ssh-agent be started automagically when you log in ?
<tseliot> pitti: I have another question. I start the nvidia-persistenced daemon using a udev rule, but the daemon seems to die in Xenial and yakkety. Starting the daemon using systemd (from the udev rule) seems to work though (the only dependency in the systemd job being "Wants=syslog.target"). Is this a reasonable way to do it?
<pitti> tseliot: you can't start long-running processes from a udev rule directly
<tseliot> pitti: ah. So what do you recommend?
<pitti> tseliot: the udev rule can add ENV{SYSTEMD_WANTS}+="some.service"
<pitti> this will then also respect dependencies etc, i. e. just queue it for startup but not block the rule on it
<tseliot> pitti: so that will start the systemd job? That would be awesome
<tseliot> or is it just a dependency?
<pitti> yes; there's a few existing examples in /run/udev/rules.d
<pitti> tseliot: well, it will start the given unit plus all of its dependencies
<pitti> (or in the case of syslog.target, wait unti that is active)
<tseliot> pitti: that's really cool, thanks!
<tseliot> pitti: BTW is there an environment variable for udev rules to stop a systemd service?
<pitti> tseliot: no, there isn't; at most you could run "/bin/systemctl stop --no-block foo.service", but what are you trying to do?
<pitti> tseliot: making this declarative in the .service itself sounds better, like binding it to a particular device
<tseliot> pitti: the udev rule should start and stop the daemon when the nvidia module is loaded/unloaded, and when the relevant acpi device is available (for hybrid graphics)
<tseliot> pitti: are there any examples on how to bind the service to a device?
<pitti> tseliot: you can't bind to a module, only to a device; if you must react to the module unloading itself, use the RUN+="/bin/systemctl stop --no-block .." approach
<pitti> well, maybe you can, haven't tried this
<tseliot> pitti: ok, good. Thanks again
<xnox> my sbuild is b0rked... can anybody help me what is it trying to tell me? http://paste.ubuntu.com/23115674/
<juliank> Hmm
<juliank> I just synced apt 1.3~rc3 some hours ago, and it fails on amd64 in the tagfile tests
<juliank> we did not do any changes in the tagfile handling or the test since ~rc2ubuntu3 however
<juliank> all other architectures work fine, and the test runs successfully on debian unstable and xenial.
<juliank> So, what else changed since last thursday? Compiler maybe?
<juliank> Hmm, I only see 6.2.0-1ubuntu11 => 6.2.0-1ubuntu12 change in the build log
<KurousagiMK2> binutils?
<juliank> that changed too
<juliank> Complete package diff: https://paste.ubuntu.com/23115984/
<juliank> Hmm, the tests also run successfully in my yakkety chroot
<juliank> (via sbuild)
<xnox> juliank, we can hit the retry button, and assume it's kvm cosmic rays
<juliank> xnox: I tried that
<xnox> horum
<juliank> the only real difference my chroot has is that it uses binutils binutils_2.27-2ubuntu2, not 7ubuntu1
<juliank> But I don't really see that affecting parsing of tagfile data embedded string literals
<sil2100> slangasek: hey! Who should I ping related to libc issues? Would that be infinity?
<xnox> sil2100, usually yes.
<seb128> cjwatson, wgrant, dpm, what's the status about opening translations for yakkety? does it need some stakeholder to get it on a priority list so somebody got assigned the cycles to do the launchpad work?
<seb128> willcooke, ^
<cjwatson> seb128: it mostly needs me to not be absolutely flat-out sorting out account-key assertions for snappy GA
<cjwatson> and we need to work out what's going on database-wise with the previous abortive opening
<seb128> is wgrant on vac/busy with other things?
<cjwatson> it was attempted and failed so left some debris
<kgunn> tjaalton: hey, so hitting a weird errorwhen i try to compile mesa on dragonboard... some.lo's "not a valid libtool"
<cjwatson> William is also flat-out with snappy GA stuff AFAIK
<seb128> k
<kgunn> tjaalton: i disabled first nouveau...
<seb128> so it sounds like "let's talk again in a week"?
<kgunn> now it's xa
<cjwatson> which is why not very much LPish has happened lately
<kgunn> just wondering if you knew the root of the issue
<kgunn> googling wasn't much help
<kgunn> ...i'll keep disabling in rules if that's easiest
<cjwatson> seb128: I'll see if we can squeeze it in somewhere, since yakkety translations can't really wait a few weeks for us to be properly out from under this
<cjwatson> seb128: but I need to finish my absolutely critical things first ...
<tjaalton> kgunn: what arch is it?
<kgunn> arm64 tjaalton
<kgunn> AH
<kgunn> oops
<tjaalton> why isn't the distro provided one good enough?
<tjaalton> ie. what are you trying to do?-)
<kgunn> tjaalton: i was just trying to compile the freedreno drivers on the device...
<sil2100> xnox: is infinity on holidays this week, or do I remember that wrong?
<kgunn> but now that you mention it
<kgunn> tjaalton: since someone recently enabled gallium
<kgunn> maybe i don't need to compile
<kgunn> ....altho, it would be nice to know how
<tjaalton> kgunn: freedreno should be available
<juliank> OK, so it's also not binutils fault
<xnox> sil2100, can't remember, but his usual timezone is central/central-west canada...
<Sweet5hark1> ricotz: whats up?
<ricotz> Sweet5hark1, why is moving liblosessioninstalllo.so depending on ENABLE_PACKAGEKIT anyway?
<ricotz> seems broken to do so when its building doesnt depend on it
<ricotz> so better check with rene
<Sweet5hark1> ricotz: I think rene just wanted to kill liblosessionstalllo.so for debian anyway. Maybe he later did, but not at the point were we are based on.
<Sweet5hark1> ricotz: so -- its renes thing, we shouldnt bother.
<ricotz> Sweet5hark1, better don't depend on packagekit
<ricotz> aka dont pass --enable-packagekit
<Sweet5hark1> ricotz: nope, we want packagekit when we can and it isnt a dealbreaker if its missing.
<ricotz> Sweet5hark1, note that I am just assuming since you didnt push your packaging changes
<ricotz> Sweet5hark1, this will be a libreoffice dependency never used before on ubuntu
<Sweet5hark1> ricotz: not pushing yet what I havent at least test build, so if you dont want to waste your time dont read too much into what is happening in -staging. Staging is not final.
<Sweet5hark1> ricotz: we used the lib before and it only does dbus ... so?
<ricotz> Sweet5hark1, you get my point and doing it so it plain confusing
<ricotz> you are saying "--enable-packagekit" was passed before?
<ricotz> I am saying the existence of this library is not depending on packagekit
<ricotz> Sweet5hark1, btw you made me look since I am desperately waiting for those tarballs
<ricotz> seems there is no such thing as --enable-packagekit anymore
<ricotz> g2g
<Sweet5hark1> ricotz: yes, there is no --enable-packagekit -- so it doesnt change anything about the build.
<Sweet5hark1> ricotz: something to cleanup and sync with debian on yakkety+1, I guess. but as is no harm (except some confusion in ./debian/rules but hey ...)
<ricotz> Sweet5hark1, passing invalid confflags might result in an autoconf error
<Sweet5hark1> ricotz: nothing is passed to configure
<slangasek> sil2100: infinity is the one and yes he's out this week; what's the issue re: libc?
<juliank> OK; I now did 3 runs of the APT amd64 build, all failed with the same error
<juliank> I am unable to reproduce this, thoug
<sil2100> slangasek: I see a funny thing happening on yakkety armhf, possibly libc related - related to the mknod syscall
<slangasek> sil2100: mknod seems an unlikely syscall to give problems... what's the context?
<sil2100> slangasek: not exactly with mknod itself - I don't know the internals too much, but there's different behavior between architectures it seems when trying to fetch the the mknod symbol through dlsym()
<sil2100> slangasek: on armhf it just fails to find mknod, on others it's all good
<slangasek> sil2100: ah, let's see
<sil2100> I think looking for __xmknod instead wouldn't be a good idea
<sil2100> Anyway, I have a test-case that works fine on xenial-amd64 (and most probably on yakkety-amd64 as well since there are no problems with the click preload lib there) but fails on armhf
<cjwatson> sil2100,slangasek: I ran into exactly that with click and there's a bileto ticket waiting for QA that switches to __xmknod
<sil2100> Couldn't find any obvious reasons for this, as just using the mknod syscall itself works
<cjwatson> I can't explain why it worked beforehand, since there is AFAICS no mknod symbol in older libcs either
<sil2100> cjwatson: yeah, good question how it worked, there's an inline mknod wrapper around __xmknod
<cjwatson> (I'm assuming it's inlined or something, but that doesn't explain why overriding it apparently worked; maybe it didn't and we just never noticed)
<sil2100> But I didn't know that was resolvable
<cjwatson> sil2100: anyway, click was already using __xstat in a similar way and since click is in theory EOL I don't have a particular problem with switching it to __xmknod
<sil2100> Or that, but if it never worked then we would get the same issue as now
<sil2100> Oh, ok
<cjwatson> sil2100: that's https://requests.ci-train.ubuntu.com/#/ticket/1878
<sil2100> cjwatson: thanks! I was investigating this as our yakkety touch builds were failing because of this
<cjwatson> from all the test suite crap I had to fix I think something has got stricter somewhere
<cjwatson> but I can't really complain because click (especially its tests, but also that preload library) was doing a lot of very weird stuff
<cjwatson> also the assertion that there are no problems with the click preload library on yakkety-amd64 is I'm afraid untrue
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1615757 was reported from amd64 and is reproducible there
<ubottu> Launchpad bug 1615757 in click (Ubuntu) "click install fails on 16.10, causing user install and autopkgtest failures" [High,In progress]
<sil2100> cjwatson: it seemed to be okayish when I last tried, since first I tried to reproduce out click install issues on my yakkety-amd64 chroot but there it just worked
<cjwatson> well, I reproduced it in my yakkety-amd64 chroot and used that to fix i
<cjwatson> t
<sil2100> While on the yakkety-armhf click installed was failing on the preload library dying when trying to fetch mknod
<sil2100> But, well, I might have missed something there
<cjwatson> anyway, just needs QA to confirm I haven't broken anything obvious and then we can land that
<sil2100> slangasek: ok, no issue then, this seems like unexpected behavior that we shouldn't have relied on the first place, cjwatson's fix is good enough for this :)
<juliank> So, the APT tagfile issue also happened sometimes on hurd-i386 @ debian
<juliank> not that we ever managed to reproduce it there either
<sil2100> cjwatson: reviewed changes and approved as well
<cjwatson> sil2100: my entirely unsupported theory is that dlsym was letting us get away with fetching internal unexported libc symbols, but I'm not really sure
<cjwatson> ta
<sil2100> Possible, yes, I was even disassembling some mknod test-apps to see if the actual mknod behavior was changing but it was all the same, so probably dlsym got stricter
<sil2100> (like, if obviously it was inline in one and an external symbol in the other)
<sil2100> Anyway, good to see this in a silo ready already!
<GhostLyrics> how can I determine whether I have a defect RAID controller, a possible kernel bug or a bug in the vendor's proprietary CLI if my online output is that the kernel could not allocate some buffer?
<pkern> cjwatson: I'm looking for a sponsor for https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1604209 which is a broken backport in trusty. Approved by -backports but component restrictions don't let me upload it. :(
<ubottu> Launchpad bug 1604209 in trusty-backports "apache2 in trusty-backports is vulnerable to CVE-2016-5387" [Undecided,New]
<cjwatson> pkern: I'm not going to have time, sorry
<pkern> cjwatson: Do you have any recourse of how I could escalate this? :/
<pkern> -sponsors is subscribed but that doesn't seem to help.
<pkern> Security says we don't care, it's backports.
<pkern> -backports says it's ok, go ahead. And I'm only a MOTU.
<cjwatson> pkern: I don't, but should be plenty of other core-devs around on this channel who can help
<juliank> Ah, that's probably the APT issue: Conditional jump or move depends on uninitialised value(s)
<rbasak> pkern: it seems to me that ~ubuntu-backporters needs more (active) members :-/
<pkern> rbasak: They ack'ed it. So you think they'd also need to upload it?
<pkern> rbasak: Why do we have component restrictions on backports in the first place?
<rbasak> pkern: I'm not sure. This stuff predates me.
<rbasak> pkern: I guess it's somewhere between development release uploads and SRUs in terms of the risk of breaking people, so it does make sense to limit it a little.
<rbasak> I asked and I can spend a little time on helping this kind of thing through on Canonical Server Team time - given that we have people giving us patches, we should take them.
<rbasak> So if it helps and I can join the backporters team on that limited basis, I'd be happy to help.
<xnox> pkern, i think i can sponsor that, if i can remember the right way to do it.
<xnox> however Laney you did upload apache2 backports last =) mind tossing https://launchpadlibrarian.net/275623430/apache2_2.4.10-1ubuntu1.1~ubuntu14.04.1_2.4.10-1ubuntu1.1~ubuntu14.04.2.debdiff there too?
<Laney> TIL doesn't work for backports since only the backporters team uploads there really
<Laney> Someone with more energy for it than me should propose scrapping the current system
<rbasak> What should it be replaced with?
<Laney> Dunno
<Laney> Something where every developer can upload and some team reviews the queue, maybe. Like SRUs.
<Laney> Or something where everyone can upload, like Debian's
<Laney> Normally we would want to re-backport in this situation too
<Laney> Rather than maintain a package in -backports
<pkern> Laney: Thank you!
<Laney> you're welcome
<doko> jamespage: is ubuntu-openstack a team with a canonical affiliation?
<slangasek> doko: are you asking because MIR , in which case http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html#ubuntu-openstack ?
<doko> slangasek: ahh, ok
<pitti> PSA: taking down autopkgtest.ubuntu.com for maintenance and redeploying a new web UI
<tumbleweed> will it have data that isn't a few days old? :)
<tumbleweed> I've been finding it a bit frustrating when trying to get things through proposed, without access to recent test history
<pitti> tumbleweed: yes, that's the point of it
<pitti> tumbleweed: I spent two nightshifts completely rewriting the thing
<pitti> tumbleweed: latency should now be â¤ 10 mins
<pitti> I'll still look at optimizing the swiftâ database upload
<pitti> but there aren't a gazillion small files any more but a proper database, and pages are now generated on the fly instead of statically by cron
<pitti> infinity: ^ FYI
<pitti> plus, the whole thing shrank to 10 or 5 % of the code :)
<pitti> apw: ^ will break your lsadt thingy, as running.json got split and currently isn't available; on the list to fix
<slangasek> pitti: woo currency
<pitti> slangasek: yeah, the latency got annoying and it kept running out of inodes despite adding an extra cinder volume
<pitti> now it's just a single 60 MB sqlite db which is lightning fast to query \o/
<doko> is lp just slow for me?
<slangasek> inodes> haha
<pitti> slangasek: and the whole thing is outright absurdly small now: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/browse.cgi
<pitti> doko: has been slow for a few days for me too
<pitti> loading/updating bugs, publisher, etc.
<pitti> well, https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/templates too, but still small
<apw> pitti, bah ... ok
<pitti> apw: http://autopkgtest.ubuntu.com/running.json is back, but now only contains the actually running tests
<apw> pitti, running.shtml seems to be bust
<pitti> apw: queue information is now not polled every 10 s (as that's quite taxing on the amqp server), but queried on demand by the running html page; I'll build you an URL which generates the queue data in JSON format on demand
<pitti> apw: yep, working on it
<apw> pitti, sounds good, you know me, just let me know what all it looks like after
<pitti> http://autopkgtest.ubuntu.com/browse.cgi/running -> should be back
<pitti> there are still some warts obviously, but the most important functionality is back; I'll announce to u-devel@
<sarnold> pitti: wow that sqlite version feels a lot easier to think about than the older swift version (sorry :)
<pitti> sarnold: it's still swift; that's awesome and won't go away
<pitti> sarnold: but this is too slow for using directly, the result metadata needs to be downloaded
<jbicha> pitti: do the package pages have to be regenerated or something? for instance https://autopkgtest.ubuntu.com/browse.cgi/packages/gjs is out of date
<pitti> jbicha: looking at that ATM
<jbicha> oh it has yakkety now, a moment ago it was only trusty
<pitti> (of course this didn't happen on the previous test instance..)
<jbicha> I think I just need to be more patient
<pitti> I think it's a problem with locking the DB (for swift updates)
<pitti> then the reading part doesn't get the results
<pitti> oops, wait, what
<pitti> jbicha: ok, now everything is back
<jbicha> yes it looks better now, thanks
<semiosis> someone marked bug 1605795 as a duplicate, but it is an SRU bug to backport a fix from yakkety to xenial.
<ubottu> bug 1565985 in cloud-images "duplicate for #1605795 vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985
<semiosis> should it be marked a duplicate of the underlying bug reporting the problem?
<semiosis> wanted to check with the experts here before removing the duplicate marker
<bdmurray> pitti: The pending SRU links to autopkgtest pages like http://autopkgtest.ubuntu.com/browse.cgi/packages/u/ubuntu-release-upgrader/trusty/i386/ notice the "/u/" and ending "/" after the arch.  Does that report need to be updated?
<tumbleweed> pitti: \o/ :)
<bdmurray> pitti: Also the ubuntu-release-upgrader tests for T and Y started failed around 2016-08-25.  X hasn't run since then.
<infinity> pitti: \o/
#ubuntu-devel 2016-09-01
<mwhudson> is someone repeatedly retrying all failed powerpc builds or something?
<slangasek> mwhudson: yes, this is a common post-FF pasttime; it does pick up some legit toolchain fixes from time to time, but I've complained to the LP folks about generating emails to the uploaders instead of to the person clicking the retry button ;)
<mwhudson> heh yes
<mwhudson> retrying in launchpad is mostly "forget that you ever tried to build this"
<pitti> Good morning
<pitti> bdmurray: oh, the problem is not the /u/, I added a backwards compatible @route to accept and ignore that part; the problem is the trailing /
<pitti> bdmurray: I'll update it, thanks for pointing out
<ricotz> chrisccoulson, hey :)
<ricotz> chrisccoulson, please retry the failed amd64 builds of thunderbird -- https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages
<wgrant> seb128: I've mostly fixed yakkety translations today. Everything's copied from xenial (successfully, this time...) and the queue is slowly importing.
<wgrant> They're not publicly visible yet, in case someone wants to check before we open it up.
<seb128> wgrant, hey, ah, great, thanks!
<seb128> what needs to be checked?
<seb128> dpm, ^ you might know what to look at/want to check?
<dpm> seb128, I certainly can, give me a few minutes
<seb128> dpm, thanks!
<dpm> thank you for following up!
<wgrant> Sorry for the delay. The failed initial copy a couple of months ago required some handholding to clean up from.
<seb128> cjwatson, ^ just in case you didn't notice, w_grant did the yakkety translations copy/import
<dpm> seb128, wgrant, the templates look ok to me, I think I'll go ahead and make them visible to translators
<seb128> dpm, great!
<seb128> thanks
<dpm> wgrant, ok, templates are now visible to translators and the translations focus is set to yakkety. Could you help us setting up the cron job in LP to do the exports for language packs?
<wgrant> dpm: We should probably wait for the first round of imports to complete first.
<dpm> ack
<pitti> juliank: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt â apparently the new test hardcodes "amd64"
<pitti> dpkg: error processing archive /tmp/tmp.xtWvRfrzRe/aptarchive/pool/initramfs-tools_1_amd64.deb (--unpack):
<pitti>  package architecture (amd64) does not match system (armhf)
<juliank> pitti: There's a bug in some re-ordering in the test suite, I'm already on it
<pitti> juliank: ah cool, danke
<juliank> pitti: Apparently gpg 2.1.15 also introduces a failure in the apt test suite due to additional output in the apt-cdrom test case.
<pitti> jdstrand: click-apparmor seems unhappy in y, known? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apparmor-easyprof-ubuntu
<juliank> pitti: The new browse.cgi is really awful. It breaks all my bookmarks
<juliank> Which is http://autopkgtest.ubuntu.com/packages/a/apt/
<juliank> and redirects to http://autopkgtest.ubuntu.com/browse.cgi/packages/a/apt/
<juliank> which does not work
<juliank> remove the a/ - still does not work, you also need to remove the trailing slash ...
<juliank> Not to mention that browse.cgi just looks bad in the URL
<juliank> Can this be fixed?
<juliank> (Bookmark is actually the wrong term, it's what chrome suggests in its omnibox, and I can't really change that ...)
<roaksoax> y
<pitti> juliank: drop teh trailing slash
<pitti> juliank: the /a/ is fine
<pitti> juliank: if you tell me how to configure apache to hide the browse.cgi, I'm happy to do that
<Laney> probably via some mod_rewrite fun
<juliank> pitti: Well, the old interface normalized to a trailing slash, so the redirect should preferably handle that :)
<pitti> https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/deployment/charms/trusty/autopkgtest-web/hooks/install#n32
<pitti> that's the current config
<pitti> juliank: I'll look into redirecting the trailing slash, hang on
<juliank> For the trailing slash, maybe having a        RedirectMatch permanent "^/packages(.*)/" "/browse.cgi/packages\$1" before the other one works?
<pitti> yep, something like that
<juliank> I'm not sure, but would using RewriteRule instead of RedirectMatch permanent work, like RewriteRule "^/packages(.*)/" "/browse.cgi/packages\$1" [H=cgi-script]
 * juliank is no apache expert
<juliank> Well could try that with /test instead of /packages on the LHS and see what happens :D
<pitti> juliank: trying in my juju-local deployment
<juliank> pitti: Why is the new thing there anyway?
<pitti> https://lists.ubuntu.com/archives/ubuntu-devel/2016-August/039486.html
<juliank> cool
<juliank> Hmm, apparently I am subscribed to ubuntu-devel but disabled mail delivery.
<juliank> Weird
<pitti> juliank: works now
<juliank> Yay, thanks
<Laney> Rewrite would be nicer, then you can hide the "browse.cgi"
<Laney> AIUI
<Laney> :)
<pitti> Laney: how would Rewrite fix that? this is just cosmetics and aliases, not defining what the canonical path loooks like?
 * pitti is an apache n00b, sorry
<Laney> pitti: I think that rewrites do the rewriting internally
<Laney> this is all bikeshedding on top of your good work though, sorry for that
<pitti> Laney: no, don't be, I'm glad for hints how to hide browse.cgi
<pitti> I tinkered around with that for some 10 mins but couldn't figure it out
<Laney> I'll play if you like
<Laney> (later)
<pitti> Laney: flask has this flask.url_for() thing which knows about it's "base URL", and that includes browse.cgi
<pitti> well, maybe not if the path that the browser reports never contains that
<pitti> Laney: yes, not a biggie; I'll also keep it on the list to try
<juliank> Oh the server should still report the browse.cgi path to the script
<juliank> even if it's not visible in the browser due to a rewrite
<juliank> AFAIUI
<pitti> the issue is that generated URLs by the flask app should then also not contain it
<juliank> Ah
<juliank> yes
<pitti> well, of course I could just manually sed it out, but that feels hackish
<pitti> s/sed/subst/
<Laney> pitti: http://flask.pocoo.org/docs/0.10/deploying/fastcgi/#configuring-apache seems like a good basis
<pitti> I actually tried ScriptAlias / (seemed straightforward), but that didn't work for some reason
<Laney> or s/0.10/latest/
<pitti> but I'll try again
<pitti> Laney: we still need /request.cgi though, so we cannot completely hide that
<Laney> nod
<cjwatson> seb128,wgrant: yep, I saw, thanks, that's a relief :)
<Mirv> mitya57: a person reported transmission-qt crashing on startup with the new qtbase, but works if appmenu-qt5 removed. is this expected behavior with the new patches, and should there be a Conflicts added somewhere instead to force removal of appmenu-qt5?
<Mirv> (mind you, this is talking about a qtbase not in archives yet)
<doko> caribou: https://bugs.launchpad.net/ubuntu/+source/tomsfastmath/+bug/1619239
<ubottu> Launchpad bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,Incomplete]
<chrisccoulson> ricotz, ah, someone else retried them before I got a chance to take a look ;)
<rbasak> caribou: did you notice that your clamav merge is stuck in proposed?
<Mirv> mitya57: not that I could reproduce that though in LXC/yakkety at least. the reported was however on xenial + Qt 5.6 though, would https://launchpad.net/ubuntu/+source/appmenu-qt5/0.3.0+16.10.20160628.1-0ubuntu1 be required too?
<ricotz> chrisccoulson, yeah, I asked colin some moments ago ;)
<caribou> rbasak: no, will look at it
<doko> Laney, seb128, jbicha: anybody looking at the gtk+3.0 autopkg test failures?
<Laney> doko: Afraid not - I didn't upload it - but I think that they were previously analysed and it was decided they were all hintable
<Laney> Looks like that wasn't done, but if someone confirms then I can add that
<doko> I can't, don't know the history about it
<doko> coreycb, jamespage: https://bugs.launchpad.net/ubuntu/+source/python-gnocchiclient/+bug/1536887  now needed for aodh
<ubottu> Launchpad bug 1536887 in python-gnocchiclient (Ubuntu) "[MIR] python-gnocchiclient, python-gnocchi, python-pandas" [Undecided,Incomplete]
<seb128> doko, same as Laney, I think pitti said it was all fine to override but unsure if he did it, jbicha did the upload so maybe check with him otherwise
<caribou> rbasak: the merge introduced a depend on a Universe library :-(
<caribou> rbasak: & I didn't spot it because I didn't upload it myself so I forgot to follow-up
<rbasak> caribou: np, I should have spotted that on review.
<caribou> rbasak: so I guess next step is to MIR tomsfastmath as doko proposed
<rbasak> caribou: ah, sorry I missed that. Yes, or drop the dependency if possible, depending.
<caribou> rbasak: I would opt for MIR as it drops an in-package copy of the code plus a bunch of patches
<caribou> rbasak: I'll look at that once I'm off the hook with my OOM kernel issues
<rbasak> caribou: OK. Thanks!
<coreycb> doko, ok I'll take a look, thanks
<jbicha> I don't even understand the gjs autopkgtest failure
<pitti> seb128: no, not all -- isenkram needs to be looked at
<pitti> just cjs and gjs are "known"
<pitti> (regresssion due to gcc-6)
<seb128> k
<seb128> jbicha, doko, ^ somebody needs to look at that one
<seb128> pitti, tahnks
<seb128> thanks
<doko> seb128: look at what?
<seb128> doko, why p_itti said is a sumarry of the gtk autopkgtest status
<jbicha> gjs didn't start failing until last week though but I can't even find the error in the logs
<pitti> well, teh isenkram failure looks like a bug in isenkram itself
<pitti> so if we want to ignore that, ok
<pitti> jbicha: yeah, I grepped for "not ok", "error", "fail", a nuisance to find what's wrong
<pitti> doko: qt and gtk will land next run
<seb128> pitti, thanks
<jbicha> thank you
<juliank> pitti: The most recent apt:amd64 autopkgtest just reported "code 20" as result
<juliank> (no space left on device during install)
<juliank> Anyway, I have a fix for the apt gpg regression, still nothing for the non-amd64, though; I guess I'll just revert the commits now and fix that properly in the next few days
<pitti> juliank: that's not your fault indeed; somewhere between yakkety, cloud-init and our clouds the root partition of the cloud image doesn't get resized properly (bug 1619285)
<ubottu> bug 1619285 in cloud-init (Ubuntu) "cc_growpart fails on yakkety" [Undecided,New] https://launchpad.net/bugs/1619285
<pitti> doko: python3-stdlib-extensions/3.5.2-1 and binutils/2.27-8ubuntu1 hinted through (ENOSPC problem)
<doko> ahh, ok
<doko> pitti: please hint python3.6 too
<pitti> doko: done
<Laney> pitti: are all autopkgtests going to fail on that bug?
<pitti> Laney: only the bigger ones
<xnox> and only on kvm
<Laney> is bigger well defined?
<pitti> Laney: 2 GB :)
<Mirv> mitya57: ok an addendum I can confirm the crash on yakkety + silo 34 when appmenu-qt5 is installed
<pitti> well, the system itself already takes about 1.1
<pitti> xnox: yes, lxc is fine
<Laney> isenkram works locally :|
<juliank> python-apt test suite failure with gpg 2.1 should be fixed now upstream (just uploaded there), will sync that tomorrow
<doko> jamespage, zul: horizon in Debian has a higher epoch (3) than in Ubuntu (2), and blocking some dependencies, like https://launchpad.net/ubuntu/+source/designate-dashboard/2.0.0-2/+build/10530093
<jamespage> doko, that will get fixed with the b3 updates today
<jamespage> its in the git repo, just not uploaded
<doko> ta
<bdmurray> pitti: Did you see my comment regarding ubuntu-release-upgrader tests starting to fail recently?
<pitti> bdmurray: oh, did they? we've had force-badtest hints for it for a long time
<pitti> committer: Steve Langasek <steve.langasek@canonical.com>
<pitti> branch nick: hints-ubuntu
<pitti> timestamp: Thu 2016-01-28 13:46:20 -0800
<pitti> message:
<pitti>   Force-badtest on ubuntu-release-upgrader, whose tests regressed for reasons unknown
<pitti> oh, seems they worked again for a bit, and have flipped back and forth
<bdmurray> pitti: they stopped working around the 25th
<bdmurray> the xenial ones show pass but they haven't run since then
<tdaitx> it seems the linux powerpc/ppc64el asm/ioctls.h is missing a include for asm-generic/ioctls.h (it's there for the other archs)
<jdstrand> pitti: yes, I am aware. that is bug #1615757. cjwatson has a fix but there was a local build failure that he was trying to figure out
<ubottu> bug 1615757 in click (Ubuntu) "click install fails on 16.10, causing user install and autopkgtest failures" [High,In progress] https://launchpad.net/bugs/1615757
<pitti> jdstrand: ah, thanks
<cjwatson> jdstrand: I figured that out last weekend; it's just waiting for QA approval now
<Saviq> cjwatson, hey, doesn't https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827315 affect LP builders? we've just hit that in our jenkins builders and wondering if we should just get sbuild 0.71 - will you guys backport it to ppa:launchpad/buildd-staging ?
<ubottu> Debian bug 827315 in src:sbuild "sbuild: Does not work with gnupg 2.x installed in the chroot" [Important,Fixed]
<tdaitx> pitti, xnox it seems the linux powerpc/ppc64el asm/ioctls.h is missing a include for asm-generic/ioctls.h (it's there for the other archs), who could know something about it?
<xnox> tdaitx, #ubuntu-kernel and then ping apw or infinity. But both are here too =) so free ping =)
<tdaitx> tks
<xnox> tdaitx, is something parsing those headers in funny ways?
<tdaitx> xnox, the reprapper package includes amf tools and that one uses a type and a macro that is available in asm-generic/ioctls.h, thus it fails to build on powerpc/ppc64el
<Laney> URGH
<Laney> this isenkram failure
<tdaitx> xnox, ops, sorry, reprapper is the one using the type and macro
<tdaitx> amf tools is packed inside it and causes reprapper to FTBFS due to another unrelated issue, I got confused =)
<Laney> https://sources.debian.net/src/isenkram/0.24/isenkram/lookup.py/#L142
<Laney> but it's getting a squid error back
<Laney> and trying to parse that
<Laney> what the :/
<pitti> Laney: those URLs don't work any more I think
<Laney> well I don't know why squid is giving an error
<Laney> but the whole thing is ...
<cjwatson> Saviq: I have a stupid annoying headache and can't currently work out whether that affects us or not.  Could we have a reminder bug against launchpad-buildd?
<pitti> Laney: it's now https://anonscm.debian.org/cgit/collab-maint/isenkram.git
<pitti> Laney: the gitweb? stuff stopped working a few weeks/months ago
<Laney> the URL works
<Laney> try it
<Saviq> cjwatson, ack
<pitti> Laney: "
<pitti> 404 - No such project
 * Laney is looking at a big list of packages and modaliases
<pitti> Laney: hm, these gitweb? things haven't worked for me for a longer time now
<pitti> odd
<Laney> I just copied and pasted it from that file
<pitti> so did I
<Laney> ..
<Laney> laney@nightingale> GET "https://anonscm.debian.org/gitweb/?p=collab-maint/isenkram.git;a=blob_plain;f=modaliases;hb=HEAD" | head -1                              ~/dev/canonical/release/hints-ubuntu
<pitti> wget says the same
<Laney> Package: alsa-firmware-loaders
<Laney> http*s*
<pitti> Laney: oh, that's not what the isenkram source says :)
<Laney> the EFF did it!
<tdaitx> pitti, Laney: that url works just fine for me
<Laney> anyway, this is crazy
<tdaitx> Laney, pitti oh wait, GET worked, but not on the browser (I get a "404 - No such project" page)
<Laney> I think https everywhere is redirecting me
<pitti> Laney: at least one less mystery today..
<Laney> the new one uses appstream as well as this file
 * Laney will sync that tomorrow
<Laney> lies, merge -> this bug still exists
<tdaitx> Laney, pitti alright, if I open the URL in the GET command it works, if I used the one with %3B (which replaces ;) it does not
<Laney> haha
<Laney> tdaitx: it's okay, I got this
<tdaitx> anyway, using httpS is ok, accessing the http redirects to https BUT it replaces ";" with "%3B" and then it does not work
 * Laney has filed a bug upstream
 * Laney will upload a small workaround for now
<seb128> cyphermox, Laney, ubiquity on the yakkety daily doesn't seem to have the nm page, did the fix that landed in xenial did in yakkety?
<Laney> https://launchpad.net/ubuntu/+source/ubiquity/16.10.1
<seb128> hum, it might be normal in a vm, ignore me
<seb128> the slides are missing, bug #1618956 ... wondering if that's a webkitgtk issue?
<ubottu> bug 1618956 in ubiquity (Ubuntu) "Slideshow blank during live install" [High,Confirmed] https://launchpad.net/bugs/1618956
<mitya57> Mirv, replied on the bug; we need a rebuild of appmenu-qt5 or disable one of the patches
<mitya57> whatever you prefer
<mitya57> https://launchpad.net/ubuntu/+source/appmenu-qt5/0.3.0+16.10.20160628.1-0ubuntu1 is unrelated
<hjd> Hi. I'm a bit confused regarding the code branches for recent releases. For instance https://code.launchpad.net/ubuntu/+source/multipath-tools contains up until Wily, and the git part seems to contain parts(?) of the changes for xenial, but I'm unable to find a branch for yakkety?
<sarnold> hjd: https://launchpad.net/ubuntu/+source/multipath-tools
<hjd> sarnold: Unless, I'm missing something obvious that's just the packages. I'm looking for the repos.
<sarnold> hjd: I'm not 100% sure those still exist; there's been multiple atempts to add source control to packaging and I'm not sure which if any are succeeding
<sarnold> hjd: that one -might- be in the server team's latest attempt; look for nacc on #ubuntu-server, perhaps
<hjd> To elaborate a bit: I have a small patch (https://code.launchpad.net/~hjd/ubuntu/trusty/multipath-tools/bug1231182/+merge/192794) which seems like it made its way into trusty, though after it ceased being the development versions. So later releases retain the typo. Therefore I'm looking for a way to open a merge proposal against the current development version or other way...
<sarnold> hjd: ha I don't even see 'avail' in what looks like the current thing https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/tree/debian/control?h=debian/sid
<sarnold> oh of course the important debian/sid bit is way at the end of the url where it can't be seen
<sarnold> https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/+git/multipath-tools
<sarnold> https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/tree/debian/control?h=ubuntu/devel
<hjd> sarnold: It's not in Debian. :) The binary package (and in turn the typo) is part of the Ubuntu delta, try searching on https://launchpad.net/ubuntu/+source/multipath-tools/0.5.0+git1.656f8865-5ubuntu5
<sarnold> hjd: yeah the last link I pasted has the typo included
<sarnold> annoying that it was fixed and then lost again :(
<hjd> Indeed :) So I thought I'd resubmit the patch, but I'm a bit stumped as to where/how...
<sarnold> hjd: try suggesting a merge to that https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/+git/multipath-tools tree
<hjd> sarnold: Ok thanks. Will do :)
<cjwatson> hjd: those imports were more-or-less deliberately not re-enabled after wily because they were hopelessly unreliable; basically they worked as long as nobody committed to them directly.  the hope is that in the not too distant future we'll get a git replacement
<cjwatson> hjd: but you can submit a patch as a straight diff
<cjwatson> (in a bug or whatever)
<hjd> cjwatson: Oh, I wasn't aware they were so unreliable.
<cjwatson> A lot of it can (unfortunately) be traced back to the decision to have explicit file-ids in bzr, I believe
<cjwatson> So there's good reason to believe that a git version will be inherently more reliable
<sarnold> cjwatson: is there a quick summary of that problem?
<cjwatson> Err, pass
<sarnold> I always thought the problem was that some people kept working with the packages directly and the people using the source ontrol systems didn't always import the changes made to the packages before fiddling with them..
<sarnold> heh, alright :)
<cjwatson> It was meant to deal with that
<hjd> Readded a patch at bug 1231182 now. Can
<ubottu> bug 1231182 in Package Descriptions for Ubuntu "kpartx-boot: Typo in package description: "availible"" [Low,Triaged] https://launchpad.net/bugs/1231182
<hjd> 't remember which team to assign, but maybe a bot does that automatically these days?
<hjd> (I tried to make a git branch first, but it didn't find how to submit a merge proposal for the other repo. I may have simply messed up though, because it's the first time I've used the git-parts of LP, https://code.launchpad.net/~hjd/+git/multipath-tools)
<hjd> Thanks for the help and good night everyone :)
<ahoneybun> I know Unity7 is in not getting any big new features but where would I go to add a calculator to the Dash?
<xnox> sil2100, Mirv: i think something is terribly broken in ubuntu-touch seeds/depends on amd64
<xnox> it depends on qml-module-ubuntu-components-gles
<xnox> and it depends on ubuntu-sdk-libs
<xnox> the two eventually conflict as they try to install -gles and non-gles variants of things down the road.
<xnox> ah
<xnox> ubuntu-sdk-libs depends on qml-module-ubuntu-components
<xnox> horum lost again.
<xnox> ubuntu-touch -> qml-module-ubuntu-components
<xnox> got it.
<xnox> ubuntu-touch -> qml-module-ubuntu-components-gles
<xnox> ubuntu-touch -> ubuntu-sdk-libs -> qml-module-ubuntu-components
<xnox> the -gles and non-gles conflict.
<xnox> and many similar.
<doko> all these ci-train builds are really annoying ...
<cjwatson> doko: the ci-train folks find your test rebuilds annoying too :)
#ubuntu-devel 2016-09-02
<Unit193> jbicha: Since you've been doing stuff with webkitgtk, what do you think about sponsoring https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/6849400/+listing-archive-extra ?
<Unit193> (Fedora also builds with this switch, btw.)
<jbicha> Unit193: could you file a bug for it and subscribe ~ubuntu-sponsors when ready?
<Unit193> Meh, perhaps.
<jbicha> Unit193: actually webkitgtk is in sync with Debian so why don't you submit it there instead? and what are you using that's not webkit2gtk yet?
<Unit193> jbicha: Well, it's not in sync and yeah was considering checking in with Debian on it too.
<jbicha> it's in sync with Debian git since the one change we needed I forwarded there :)
<Unit193> Nice. \o/
<jbicha> I wonder if this commit can/should be backported from webkit2gtk to webkitgtk: https://trac.webkit.org/changeset/204250
<Unit193> No idea, all I knew was that just opening the thing would kill it.  Had to poke around webkitgtk to figure out what was up (And lovely 18 hour build times..)
<jbicha> opening what thing?
<Unit193> The browser I was using, that point being unimportant.
<jbicha> I don't build webkit locally; last time I tried the computer I was using couldn't handle it
<Unit193> I used LP to build it, aye.
<Mirv> xnox: hmm, it is suppposed to be "working" set of dependencies for emulator use. maybe it got broken in yakkety at some point then, let's see.
<Mirv> (at least it is working on vivid where the emulator is used with the gles code path)
<Mirv> mitya57: thanks a lot! I think a rebuild should be fine in this case.
<pitti> Good morning
<Mirv> xnox: it should (be possible to) work because that qml-module-ubuntu-components-gles Provides: qml-module-ubuntu-components. and at least on my yakkety it seems to do that right thing http://pastebin.ubuntu.com/23123088/ (ubuntu-sdk-libs already installed). but it could easily be too much for apt depending on the config.
<Mirv> creating emulator images from clean slate of course is easier than switching the whole system from Qt desktop opengl to opengl es
<Mirv> ah I see the bug report, well it's a good thing to do regardless
* racism changed the topic of #ubuntu-devel to: Welcome to the official IRC channel of the Ku Klux Klan | /msg alis list * -min 200 -mode -tÂ Â  and you get a list of large channels on which any user can change /topic!
<pitti> !op | racism
<ubottu> racism: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
<pitti> Unit193: ^
<pitti> well, this <!>op list is fairly useless
<racism> !op | penis
<ubottu> penis: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
<racism> !op | penis
<racism> pitti you dont need a fucking op
<pitti> racism: and you need a life..
<racism> as I am making blatantly obvious anyone can change the topic
<racism> if you care so fucking much YOU can change it too!
<pitti> racism: I need an op to ban you, not to change the topic back
<racism> LOL
<racism> what good does it do to ban me?
<racism> My poiny has been made, I'm not going to engage in a revert war with the topic if you reset it
<pitti> you did yesterday
<racism> lol that was because I was stupid yesterday
<racism> but now I'm smart
<racism> and less of a smartass
<racism> and not even a dumbass
<racism> ara: observe the /topic
<racism> ogra: hi
<racism> ogra here too!
<racism> ogra sucks nigger dicks
<racism> for the lulz
* racism changed the topic of #ubuntu-devel to: Welcome to the official IRC channel of the Ku Klux Klan | /msg alis list * -min 200 -mode -tÂ Â  and you get a list of large channels on which any user can change /topic!
<racism> dholbach: hi
<racism> like the /topic?
<dholbach> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
<dholbach> ^ can you take care of "racism" above?
<pitti> dholbach: already done, Unit193 isn't here today, and cjwatson will still sleep a bit
<pitti> dholbach: those two are the only two active ops I know
* racism changed the topic of #ubuntu-devel to: Welcome to the official IRC channel of the Ku Klux Klan | /msg alis list * -min 200 -mode -tÂ Â  and you get a list of large channels on which any user can change /topic!
<racism> lol
<racism> cunt cunt cunt cunt cunt
<grumble> dholbach: can you tell me what the original topic was?
<dholbach> Topic for #ubuntu-devel is: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> grumble: we can, but don't bother changing it back until that guy who doesn't have a life gets kickbanned
* grumble changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> grumble: oh, you have ops? thanks
<racism> oh fuck
<racism> pitti: grumble is network staff
<racism> but very new at being staff
<pitti> grumble: but +t is impractical here -- a lot of developers regularly need to change the topic
<pitti> (which is the reason why it's free to change)
<dholbach> it's something we should raise with the irc council
<grumble> pitti: it's temporary :)
<racism> hence the delay while grumble sat helplessly trying to google what command to type
<racism> grumble, lol
<k1l> freenode really should rethink blocking open proxy trolls like racism
<pitti> grumble: can you please kickban the guy here? we banned him from other ubuntu channels
<racism> uhm  not all the proxy users are bad
<dholbach> and all that for a bit of attention
<ogra> you surely are
<racism> some of them just need them to anonymize their porn
<k1l> racism: uhm, then stop abusing it.
<racism> lol
<pitti> DFTT
<pitti> dax: thanks
<dax> oh. i assume y'all want -t too?
<pitti> dax: yes, please
<dax> if most devs have ubuntu/* or canonical/* or something, we could add those cloaks to the ops list and set +t, i guess
<dax> but that'd be an IRCC thing, indeed
<pitti> dax: that souds like a good compromise indeed
<pitti> dax: i. e. only authenticated users can change the topic
<pitti> that's what I woudl expect anyway
<dax> Unit193, elky: ^ please consider pondering
<dax> theoretically could give chanserv flag +t instead of +o, but that'd require re-learning commands
<dax> anyways, afk
<pitti> xnox: initial statistics: http://autopkgtest.ubuntu.com/browse.cgi/statistics
<Unit193> pitti: FWIW, I'm not on that ping list because I'm not an OP here.  If you do go for giving +t to ubuntu/member/ and canonical/, they'd either have to  /cs topic #ubuntu-devel TOPIC HERE  or op up first.
<Trevinho> ahoneybun: what you mean, isn't the calculator showing there?
<LocutusOfBorg> pitti, hi
<LocutusOfBorg> autpkgtest failed
<LocutusOfBorg>  cannot copy extracted data for './usr/lib/gcc/powerpc64le-linux-gnu/6/cc1plus' to '/usr/lib/gcc/powerpc64le-linux-gnu/6/cc1plus.dpkg-new': failed to write (No space left on device)
<Laney> LocutusOfBorg: known, will be retried
<LocutusOfBorg> I already retried ocrmypdf
<LocutusOfBorg> I was wondering if you were aware of it :)
<LocutusOfBorg> ok, I'll leave to you
<Laney> thanks for pointing it out anyway :)
<LocutusOfBorg> thanks to you for caring and fixing
<pitti> doko, seb128, Laney, LocutusOfBorg: image rebuilds done, mass retry started
<LocutusOfBorg> <3
<xnox> pitti, nice stats =)
<xnox> ah, wanted to ask about releasing a few packages, but it can wait for mass-retry to get them.
<pitti> xnox: I'm sure we want more stats over time, we can add them on demand
<xnox> pitti, yeah. I imported the dump into postgresql and created the views that I want in pgadmin =)
<xnox> failing amd64 test; failing s390x test; and things that fail on s390x but not on amd64 as a personal hit list =)
<mitya57> Mirv, in my test (local Qt build) the global menu worked fine, I will test the build in your PPA a bit later and see what's wrong here.
<mitya57> (Later today or tomorrow; will reply on the bug after that)
<Mirv> thank you so much mitya57
<rbasak> libnl-3-200 is "Multi-Arch: same" but both i386 and amd64 ship /etc/libnl-3/classid. Is this a bug?
<rbasak> I'm triaging bug 1619481 but it seems to happily co-install in Xenial, which confuses me. I'll try Trusty.
<ubottu> bug 1619481 in libnl3 (Ubuntu) "package libnl-3-200 (not installed) failed to install/upgrade: pokus o prepÃ­sanie zdieÄ¾anÃ©ho sÃºboru â/etc/libnl-3/classidâ, ktorÃ½ sa lÃ­Å¡i od inÃ½ch inÅ¡tanciÃ­ balÃ­ka libnl-3-200:i386" [Undecided,New] https://launchpad.net/bugs/1619481
<rbasak> Ah, https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_files_in_multiarch_packages
 * rbasak reads more
<rbasak> So it looks like it should be fine. No idea why that user hit a bug. Local corruption maybe?
<xnox> pitti, refreshing http://autopkgtest.ubuntu.com/running -> s390x/ppc64el columns disappear from time to time, and reappear on a refresh
<smoser> hm.
<smoser> late last night i looked at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<smoser> and cloud-utils was held due to some failures in lxd and juju
<smoser> now it is not held..
<smoser> how do i
<smoser> a.) see those failures
<smoser> b.) know how it got through .
<smoser> i suspect someone let it thorugh but i want to know why it failed.
<smoser> rbasak, do you now ?
<smoser> i dont want to just hit this same thing again next time i upload
<rbasak> smoser: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-01/23:38:49.log suggests a lxc/s390x failure maybe?
<rbasak> Looks like that always failed though: http://autopkgtest.ubuntu.com/packages/lxc/yakkety/s390x
<smoser> iknow when i saw it yesterday it said 'regression' on lxc and on juju
<smoser> like ceilometer has now
<rbasak> I: [Thu Sep  1 23:41:39 2016] - Checking for new results for failed juju-core-1/amd64 for trigger cloud-utils/0.29-0ubuntu3
<rbasak> That one seems more likely. And http://autopkgtest.ubuntu.com/packages/juju-core-1/yakkety/amd64 suggests that it's still failing.
<rbasak> Did someone let it through despite that failure?
<smoser> thats what i'm asking
<smoser> rbasak, well, they might have
<smoser> that log https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/j/juju-core-1/20160901_221159@/log.gz
<smoser> (no space left on device)
<smoser> is almost certain the isue that this fixed.
<rbasak> smoser: here you are: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1894
<smoser> but juju ran in a cloud image that didn't have the fix to resize and thus it ran out of space
<smoser> is that permenantly disabling ?
<rbasak> AIUI, it's just that version (or perhaps <=version, not sure)
<smoser> rbasak, where did you learn of all these links ?
<smoser> the autopkgtest.ubuntu.com pages are new to me. as is hints-ubuntu
<rbasak> Good question. I don't really know!
<rbasak> IRC I guess.
<smoser> yeah.
<smoser> ok.
<rbasak> pitti did announce the updated autopkgtest.ubuntu.com the other day.
<_hc> hey all, its time again for a request sync of the android-tools packages :-)  its about 10 packages that should all be set to the same upstream version, so I thought it would be less work for all to avoid filing bug reports.  yakkety currently has a mix of upstream versions for these packages (e.g. android-platform-* source packages).  They should all be set to 6.0.1+r55 from Debian/sid.  Or you can wait for them to hit testing if you want.
<_hc> here's one examplle https://launchpad.net/ubuntu/+source/android-platform-build
<_hc> that needs to be synced
<_hc> this one is on the correct upstream version https://launchpad.net/ubuntu/+source/android-platform-system-core
<_hc> they all need to be at the same version, otherwise odd bugs will ensue
<rbasak> _hc: how does that fit with feature freeze? If you don't get it done soon, filing a single bug with a description and adding that to the sponsorship queue might be a good idea.
<jbicha> _hc: yes, I'd been syncing android-tools stuff so that they're on the same version but android-platform-build was broken for the past week (looks like it's fixed today)
<_hc> rbasak: since those packages are all part of yakkety, I can't see any reason to not have them synced.  We did this same process with 16.04.
<_hc> yeah, I was just uploading
<_hc> I'm the main Debian devloper uploading those, feel free to ping me with questions or ask in #debian-android-tools on oftc
 * rbasak leaves it to jbicha 
<xnox> pitti, in adt can i somehow use archive binaries, but run my tests from my source package which i've just written?
 * xnox tries built-tree option
<dobey> xnox: that's how it normally works. built-tree doesn't sound like what you want there (it builds new binaries, but i don't recall which get installed after the build)
<xnox> unbuilt-tree builds new binaries
<xnox> =)
<jbicha> pitti: https://autopkgtest.ubuntu.com/running.shtml (from my browser history) doesn't redirect properly
<xnox> looks like it's using my tests, against archive packages
<dobey> xnox: huh? how can it build new binaries if you aren't specifying to build the tree?
<xnox> ... i don't want new binaries. I'm happy with the binaries in the archive. I just adding new adt tests.
<Laney> sounds like autopkgtest --no-built-binaries might do the right thing too
<xnox> it doesn't build any binaries, nor requires locally built ones, it takes them from the archive. but doesn't take source package from the archive, and instead uses my `pwd`./debian/tests
<dobey> i'm confused
<mterry> sarnold: so regarding Go packages in main...  Now that we don't need Build-Depends in main, we wouldn't normally need the golang-*-dev packages in main.  But is there a special exception for Go, since their code is bundled in?  (tho not sure how we'd enforce it except by maybe a package regex...)
<xnox> mterry, false
<xnox> mterry, Built-Using must be correct, and Built-Using must be in main
<mterry> xnox: ah... built-using triggers the main check?  Perfect
<xnox> mterry, or use go shared libraries, in which case Depends will be generated and result in main inclusion.
<mterry> yeah
<mterry> xnox: is that supported yet in Ubuntu?
<xnox> we went from: build-depends[-indep|-arch], depends, recommends = main
<xnox> to: built-using, depends, recommends = main
<xnox> oh and Pre-Depends too.
<mterry> makes sense yeah
<xnox> mterry, i believe mwhudson_ was working on it and i think it was something like works in yakkety, and he was unwinding all the deps to make it worthwhile.
<mterry> cool
<mterry> xnox: thanks!
<xnox> e.g. one needs at least 2 users of the same lib to make this effort give benefits.
<xnox> goal was to "sharify" juju/snapd/docker or some such.
<xnox> but that may have changed since
<mterry> hm
<mapreri> why isn't stuff like this dealt by ubuntu's debhelper?  https://patches.ubuntu.com/i/inkscape/inkscape_0.91-9ubuntu1.patch
<mapreri> pitti: â  (as you're the one taking care of debhelper in ubuntu, apparently)
<xnox> mapreri, because it cannot know if the package is meant to be in main and translation packs, or not.
<jbicha> mapreri: pkgs that use gnome-pkg-tools (dh --with gnome) pick up dh-translations automatically
<mapreri> jbicha: thanks.  Now, I'm peaking at the sources (and at the manpages), but I can't see where it is doing it :|
<mapreri> there is only some translation-related things (but not calling dh_translations) in the cdbs part
<brendand> getting this error when deploying a yakkety testbed - http://paste.ubuntu.com/23124368/
<seb128> brendand, report a bug on launchpad?
<seb128> looks like juliank removed the replaces in some recent upload
<juliank> Back soon
<juliank> the replaces
<seb128> brendand, ^
<seb128> juliank, thanks
<brendand> juliank, ah. we were about to break our way out with a hammer, but if soon is very soon...
<juliank> I'd say tomorrow with a sync from a Debian upload today, but I can also prioritize this and do a direct ubuntu upload now
<juliank> git cherry-pick commit && gbp dch && ./prepare-release pre-export && debcommit -r -a && gbp buildpackage -S && dput
<brendand> don't rush it on my behalf. we'd just need to regenerate our base image and we should probably do that anyway
<juliank> There are also some other nice undefined behavior / segfault fixes and staged pipelines for updates, so we now fetch files in a more defined order
<juliank> (1) All Release + .diff/Index files, (2) all .pdiff files, (3) the rest
<juliank> Here, (2) is basically irrelevant, but it still fixes progress reporting a lot. Progress reporting only starts once we fetched all stage 1 files, and previously you might have already started fetching large files; and thus see 0% all the time
<smoser> can anyone sverify that grub-reboot works ?
<smoser> http://paste.ubuntu.com/23124599/
<smoser> paste fail
<smoser> http://paste.ubuntu.com/23124602/
<sarnold> mterry: it'd probably be best to discuss with jdstrand when he returns next week (us holiday and all) -- I only ever took a small "is this package sane" view of things
<mterry> sarnold: I figured it out -- Go packages are correctly caught as needing to be in main due to our tools checking the value of Built-Using
<mterry> sarnold: thanks though
<sarnold> mterry: ah :) hooray
<juliank> brendand: Fixed apt uploaded. I accidentally forgot to fix the autopkgtest test suite upstream for non-amd64, so I had to merge it, which means I could directly upload it :)
<juliank> Luckily I just noticed that and did not try syncing it tomorrow...
<Unit193> jbicha: Right then, now will you sync it?
<jbicha> Unit193: webkitgtk you mean? sure, once LP picks it up (there's a delay of several hours after Debian upload before syncpackage works)
<Unit193> Yep, I know.  And great.  Another package in sync. \o/
#ubuntu-devel 2016-09-03
<doko> jbicha: are you running a bot for your syncs?
<jbicha> no
<doko> so why the new upstream versions?
<jbicha> can you point to a particular one?
<doko> sure, eliom
<doko> but I won't track every one of your uploads
<jbicha> that's not a new upstream version, 4.2-2>4.2-3
<jbicha> but it's ocaml so I would have been smarter to stay away from it
<doko> yeah, if you're not interested in progress
<jbicha> the changelog for eliom was deceptively simple :( https://launchpadlibrarian.net/282342301/eliom_4.2-2build1_4.2-3.diff.gz
<Unit193> Yeah but you got the one I wanted, which is all that matters. :---D
<jbicha> well by syncing eliom I ended up creating more work for someone but I do try to make up for those mistakes by helping with ftbfs and transitions
<jbicha> Unit193: I wonder why that change was only done by Fedora on webkitgtk and not webkit2gtk (they named their source package webkitgtk4)
<Unit193> Yeah it's a bit odd.  No idea if it has the same problem.
<jbicha> maybe webkitgtk is just old
<jbicha> gufw uses a very simple webkitgtk widget to show embedded help and it didn't crash for me
<Unit193> midori didn't either.
<jbicha> oh, I was thinking midori might have been the wk1 browser you were using
<Unit193> GTK2 version of Xombrero.
<jbicha> I'm basically doing a no-change rebuild of wk2 to see if that might help with bug 1618956; if it doesn't work I'll try passing that flag to wk2 in a ppa build
<ubottu> bug 1618956 in webkit2gtk (Ubuntu) "Slideshow blank during live install" [High,Triaged] https://launchpad.net/bugs/1618956
<fg01> Hi, I would like to contribute to Ubuntu. I would like to help fixing bugs to get used to the code. Could you guide me on starting? hope I can be helpful
<juliank> Everyone happy with apt 1.3~rc4ubuntu1 so far?
#ubuntu-devel 2017-08-28
<mwhudson> !help
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<mwhudson> !commands
<ubottu> The linux terminal or command-line interface is very powerful. In Unity or GNOME, search the dash for "terminal" and press ENTER. Other desktops: Applications -> System Tools -> Terminal (MATE), K-menu -> System -> Konsole (KDE), or Menu -> Accessories -> LXTerminal (LXDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal
<mwhudson> sigh
<mwhudson> does ubottu support messaging people on join?
<seb128> does anyone has a standard/right way to get the multiarch dir from a standard install set (e.g no dpkg-architecture from dpkg-dev)?
<seb128> bdmurray, hey, do you know if anyone is looking at bug #1697381 (update-notifier not working under wayland)
<ubottu> bug 1697381 in update-notifier (Ubuntu) "update-notifier crashed with SIGSEGV in g_hash_table_lookup_node" [High,Confirmed] https://launchpad.net/bugs/1697381
<bdmurray> seb128: I'm not aware of anybody working on it.
<bdmurray> seb128: Do you know a better way of fixing bug 1637180 than comment #18?
<ubottu> bug 1637180 in update-manager (Ubuntu Artful) ""The computer needs to restart" dialog constantly eats CPU" [High,Confirmed] https://launchpad.net/bugs/1637180
<seb128> bdmurray, could you maybe review the patch on that update-notifier bug? it seems hackish but i'm unsure what would be the right way and it would give us update-notifier back into our default session
<seb128> without it apport doesn't trigger on problem and such
<seb128> bdmurray, oh, I saw your ping on friday but it was eow here, let me have a look now
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<seb128> bdmurray, that comment is not a fix but a workaround, if that code was added I guess it's useful (it's probably to avoid the geometry to change when e.g installing packages since the package name/strings length change and gtk would adapt to the label if not forced
<seb128> bdmurray, that requires some debugging to not avoid the refresh loop, seems like a good bug to put on the backlog for later in the cycle, but too minor to be at the top of my todo at the moment
<bdmurray> seb128: okay, thanks for looking
<seb128> bdmurray, k, I think I understand the issue, I commented on the bug with how to fix it
<seb128> bdmurray, I can have a look to fix it myself after the post-ff backlog if nobody resolved it by then
<bjf> i just dist-upgraded with the changes since last friday and hidpi appears to now be broken ... what do i file a bug against?
<jbicha> bjf: are you using GNOME? that's probably gnome-settings-daemon 3.25.91
<jbicha> we're having trouble with gjs and mozjs52/armhf which is delaying mutter/gnome-shell 3.25.90
<bjf> jbicha, yes, this is default artful desktop
<bjf> jbicha, should i file a bug or you are already fully aware of this problem?
<jbicha> you can file a bug if you like; I think we're generally aware of the problem
<bjf> jbicha, ack
<smoser> cyphermox, ifupdown was *not* in artful image for a few days last week, right?
<smoser> slangasek, ^ ?
<smoser> or did i make that up.
<smoser>  it seems back in
<sarnold> that sounds familiar
<cyphermox> smoser: ifupdown should not be in artful images, so it's quite possible yeah
<cyphermox> smoser: but more to the point, what is the issue you're having, exactly?
<smoser> well, it *was* gone. but now its back.
<cyphermox> well, something must be pulling it back in
<smoser> so that is a problem.
<smoser> apt-get --purge doesnt complain about anything
<smoser> then, the other thing is
<cyphermox> but if you don't have config for ifupdown, ifupdown wouldn't do anything for you
<smoser>  https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1713537
<ubottu> Launchpad bug 1713537 in open-iscsi (Ubuntu) "iscsi-targets don't quit session on shutdown" [Undecided,New]
<smoser> "config for ifupdown"?  cloud-init sees that ifupdown is there and renders network config for it
<smoser> (and that works fine)
<cyphermox> just like that, I don't know why it's showing up again, if it ever finally migrated off
<cyphermox> there's a couple of places that need checking.
<cyphermox> smoser: I see nothing to indicate that it ever migrated off.
<cyphermox> oh, actually, maybe I'm wrong on that
<cyphermox> you're looking at your desktop install?
<cyphermox> smoser: ^
<smoser> cyphermox, cloud image. and .. i'm 90% certain it did disappear.
<smoser> actually. yeah, i'm pretty sure it hasnt gone away.
<smoser> s/hasnt/never/
<smoser> http://cloud-images.ubuntu.com/daily/server/artful/20170819/artful-server-cloudimg-amd64.manifest
<cyphermox> sure
<smoser> looking at that url with 201708{*}
<smoser> that said, why is it not gone now ?
<cyphermox> the thing is, this was blocked for a while on resolvconf, which xnox was working on
<cyphermox> looking quickly, it appears as though it's resolved
<cyphermox> (ie. resolvconf isn't a blocker anymore) but there's a couple of small knobs to tweak to get ifupdown off the image
<cyphermox> smoser: I'm going to upload changes to ifupdown and resolvconf to fix this, so next image after they migrate to -release should be good
<smoser> cyphermox, so resolvconf will be dropped also ?
<cyphermox> I don't need to change it after all. that said, yeah, ideally resolvconf would go too
<smoser> so why did you think it was resolved ?
<smoser> something was changed in the last 2 day s?
<smoser> as the 20170826 image has it
<cyphermox> you showed me 19 earlier, not 26
<smoser> yes, but 26 is the same.
<smoser> as i said, i had thought it went away and came back.
<cyphermox> let's take it one step at a time, I'll tweak ifupdown like should have been done already, and we'll see
<cyphermox> I need to look at resolvconf harder to understand why it's showing up, but I think it's because of ifupdown
<cyphermox> smoser: are you concerned that if there's not resolvconf, things won't work?
<smoser> cyphermox, yes. i'm concerned that if there is no resolvconf things wont work.
<smoser> cyphermox, is there a designed plan for migrating previous users of resolvconf to systemd-resolvd integration ?
<smoser> i know open-iscsi for one used resolvconf
<cyphermox> I don't know, xnox was working on the DNS side, and he's off for now
<cyphermox> slangasek: ^
<cyphermox> I'm a little surprised though, resolvconf is basically just glorified symlinking.
<smoser> https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1713537/comments/1
<ubottu> Launchpad bug 1713537 in open-iscsi (Ubuntu) "iscsi-targets don't quit session on shutdown" [Undecided,New]
<cyphermox> that doesn't mean it's resolvconf.
<slangasek> smoser: yes, the plan is that systemd migrates the symlink on upgrade; this should have already landed in -2ubuntu9; is this not what you're seeing?
<slangasek> otoh the changelog doesn't say that this has landed, so maybe this isn't done yet
<slangasek> cyphermox, smoser: ^^ this isn't landed in systemd -2ubuntu9; xnox and I have discussed what needs to happen but apparently it's not done yet, so we need a systemd upload that migrates /etc/resolv.conf on upgrade (and breaks or conflicts resolvconf or something)
<cyphermox> ack
<smoser> well, *something* will have to take the dns results from the dhcp in the initramfs and make systemd-resolvd aware of them.
<smoser> or systems like maas's ephemeral root will not have dns configured.
<ahasenack> hi, could someone please accept my xenial and zesty nominations for https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1712998 ? Thanks!
<ubottu> Launchpad bug 1712998 in bind9 (Ubuntu) "regression: dig compiled without -DDIG_SIGCHASE!" [Medium,Triaged]
<ahasenack> it's fixed in artful
<smoser> ahasenack, buttons clicked
<ahasenack> thx
<dpb1> anyone running artful with FDE notice the text entry is very dim?
<dpb1> (on the FDE password prompt)
<mwhudson> cpaelzer: congrats!
<Unit193> mwhudson: No, ubottu doesn't have something like that.
<Unit193> cpaelzer: Oh, and congrats!
#ubuntu-devel 2017-08-29
<cpaelzer> Unit193: mwhudson: thank you
<Unit193> Nice: Err:4 http://us.archive.ubuntu.com/ubuntu zesty Release                                                                                                      503  Server overload, try later
<xnox> cyphermox, slangasek: currently, on upgrades, resolved->resolvconf integration is preserved and thus resolved discovered nameservers are fed into resolvconf and everything should work
<xnox> after upgrade to the new resolvconf, and then removing it, it has been changed to hand over the symlink to resolved.
<xnox> this means that e.g. after clean artful install, one should still be able to opt into using resolvconf
<xnox> there was/is debootstrap bug in systemd postinst, which did not account for "resolvconf got configured just before me"
<xnox> and the botch to fixup upgrades/boots needs to be removed from systemd.
<xnox> slangasek, i'm unconvinced for a save removal of resolvconf on upgrades; since the old postrm is used which is unaware of resolved =(
<cpaelzer> Hi, a question about orig tarballs
<cpaelzer> I have an ugly case were due to issues I need to go "backward" on a source - a bit like https://lists.ubuntu.com/archives/xenial-changes/2015-November/000988.html
<cpaelzer> the way to work that out obeying version number linearity is the insertion of +really<oldver>
<cpaelzer> which makes me needing a new (actually the old) orig tarball
<cpaelzer> I thought the orig tarball had to contain the right path name matching the current version, like <pkgname>-<ver>/src...
<xnox> cpaelzer, it doesn't if you extract with dpkg-source which "renames" the prefix inside the tarball.
<cpaelzer> But it seems that I can just rename the old orig tarball to the new fixed up <newver>+really<oldver>
<xnox> yes, do that.
<cpaelzer> I want to cause as less noise and confusion as possible
<cpaelzer> thanks xnox
<xnox> such that it preserves the checksum / can still be validated if there is tarball signature.
<cpaelzer> exactly that was my idea on the file rename
<cpaelzer> rbasak: here the anser on our former discussion in HO ^^
<cpaelzer> for the log here an example confirming that http://paste.ubuntu.com/25424483/
<seb128> hum, "debuild clean" or "debuild binary" stopped working in artful
<seb128> is that a bug or was that an undocumented feature than I happened to use
<seb128> is there an equivalent?
<cjwatson> seb128: it was a deliberate change, though I forget where I read about it.  Use 'debuild -- clean' etc. instead.  https://bugs.debian.org/845566
<ubottu> Debian bug 845566 in devscripts "devscripts: debclean is broken" [Normal,Fixed]
<seb128> cjwatson, thanks!
<niedbalski> RAOF, do you mind to take a look at the xenial task for LP:#1708305? (currently verified)
<ogra_> jdstrand, do you know if bug 1713486 is on the radar of the security team (despite being universe) ...
<ubottu> bug 1713486 in enigmail (Ubuntu) "Incompatibility issues with Thunderbird 52+" [Undecided,New] https://launchpad.net/bugs/1713486
<slangasek> kees, stgraber: I'm around but will be a bit late for the TB meeting; also, seems neither mdtab nor inftab are around today
<jdstrand> ogra_: I don't. chrisccoulson might ^
<stgraber> slangasek: and I'm double booked so will only be kinda there
<stgraber> still waiting for infinity to respond to the doodle so we can figure out a new meeting time
<kees> stgraber, slangasek: we can skip...
<chrisccoulson> ogra_, what's the actual issue? I'm using it fine here
<ogra_> chrisccoulson, one sec ...
<ogra_> chrisccoulson, https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291324.html
<chrisccoulson> hmmm, but what doesn't work?
<ogra_> dunno ... not my bug ... i only saw the discussion on the ML
<chrisccoulson> I update it when required, but it wasn't updated because it appears to be working fine. I don't understand what the issue is
<xnox> chrisccoulson, https://www.enigmail.net/index.php/en/download/changelog looks pretty much as the ML post
<ogra_> in the mail he says TB "just hangs" which is definitely not much info :)
<xnox> 52.... bug... block mail sending
<slangasek> stgraber: do we want to reschedule the next one according to the winner of the doodle poll? https://beta.doodle.com/poll/w2yddwzgw89diicw
<stgraber> slangasek: we have a few potential winners so I was hoping to get infinity to add his availabilities to try to narrow things down
 * slangasek nods
<slangasek> stgraber: OTOH, only 1 of 4 respondents said this current timeslot is ok, so I think I'm going to go ahead and at least move the next meeting 3 hours and then we can refine further if infinity votes
<slangasek> stgraber, kees: in fact, I've changed it for today also, so if you guys want to try again in 3h... :)
<stgraber> slangasek: ok
<ginggs> tsimonq2: up for another nodejs merge? 6.11.2~dfsg-3 has just been uploaded :p
<tjaalton> ugh, the default bug category for ubuntu-bug should be "Other problem", not Display :P
<tjaalton> or "I don't know", which is all most of the bugs also are about
<nacc> heh
<tjaalton> well, that doesn't work, has to be based on a package
<tjaalton> selecting "Other" just says "read --help"
<fossfreedom> hi cyphermox . I'm trying to debug why ubiquity displays no background wallpaper in beta 1 Ubuntu Budgie - I just see a black background with the try/install screen.  Any hints on how to debug this?
<smoser> bdrung, hey. i was just googling for some things and came across
<smoser>  https://lists.debian.org/debian-kernel/2017/06/msg00199.html
<smoser> in ubuntu this is mostly rooturl (cloud-initramfs-rooturl)
<smoser> other than the reason for gogling... dns is not currently functional in the initramfs.
<tsimonq2> ginggs: ack, yep, I can take care of it in a few hours
<Unit193> mwhudson: Congrats on becoming a DD!
<tsimonq2> mwhudson: Congrats :D
<Unit193> sforshee: LP 1711758, as noted, patched and it seems to work.
<ubottu> Launchpad bug 1711758 in nvidia-graphics-drivers-304 (Ubuntu) "artful: nvidia-304 unknown symbol init_mm" [Undecided,New] https://launchpad.net/bugs/1711758
#ubuntu-devel 2017-08-30
<cyphermox> fossfreedom: did you inspect the filesystem to make sure the appropriate binary was included, if it needs feh or something like that?
<mwhudson> Unit193, tsimonq2: thanks!
<Unit193> Now I can harass you for uploads!  (Nah, just kidding.)
<mwhudson> heh heh
<RAOF> niedbalski: Bug 1708305 hasn't had its traditional 7-day aging in xenial-proposed; is there a particular reason to release it early?
<ubottu> bug 1708305 in Ubuntu Cloud Archive ocata "Realtime feature mlockall: Cannot allocate memory" [Medium,In progress] https://launchpad.net/bugs/1708305
<fossfreedom> cyphermox, re ubiquity.  Yes budgie-wm is there and the process list indicates budgie-wm --sm-disable is running. For fun, I commented out gnome-settings-daemon & budgie-wm process start code, installed metacity and feh with a hard-coded background_image and the wallpaper was displayed.  Title bar looks odd though.
<fossfreedom> I do note there is two gnome-settings-daemon binaries listed in ubiquity-dm that no longer exists with the recent gnome-settings-daemon upload but deleting those two from the array doesnt do anything.  more of a tiny code cleanup in that area
<fossfreedom> cyphermox, brain-wave! Ubuntu Budgie has the new per-desktop override for the gsettings background schema so that we don't trample over other desktops overriding that key.  We need now to set the environment variable "XDG_CURRENT_DESKTOP=Budgie".  Would you be ok with a PR for that?
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
<tsimonq2> Patch pilot <3
<sil2100> tsimonq2: you don't need patch pilots that much anymore though! Just for main packages ;)
<tsimonq2> sil2100: I know, I just love the concept ;)
<cpaelzer> I like it as a day to have a reason to ignore all else
<cpaelzer> and actually focus on creating/reviewing/sponsoring fixes
<tsimonq2> cpaelzer: <3
<tsimonq2> I liked it as someone without upload access and I'm guessing I wasn't the only one
<jbicha> fossfreedom: oh
<xnox> cjwatson, thank you for env --chdir. It did occur to me for ages that make -C is amazing, but i never thought of porting it elsewhere.
<cjwatson> yeah, been annoying me for a long time now!
<jbicha> https://code.launchpad.net/~jbicha/ubiquity/adapt-to-gsd325/+merge/329902
<doko> jbicha: libdazzle ftbfs on ppc64el, accepting anyway, new package
<tsimonq2> bdmurray: Can I please be approved to ~ubuntu-reviewers? :)
<jbicha> doko: thanks
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<sil2100> (lunch time)
<rbasak> tsimonq2: around? About bug 1327002. Your uploaded changes file is missing bug references even though the changelog entry has them. Did you use an Ubuntu system to build the changes file? The Ubuntu delta in dpkg-genchanges matters.
<ubottu> bug 1327002 in gthumb (Ubuntu Trusty) "Mint 17/Ubuntu 14.04 - can only launch one instance of gthumb" [Low,Triaged] https://launchpad.net/bugs/1327002
<tsimonq2> rbasak: Hey :)
<tsimonq2> rbasak: That's...weird
<rbasak> It's pretty common when people upload SRUs from Debian.
<tsimonq2> rbasak: I *am* on a Buster system at the moment
<rbasak> (Ubuntu SRUs)
<tsimonq2> So yeah
<rbasak> tsimonq2: can you fix up? If not I can.
<tsimonq2> Sorry, my mistake. I didn't know there was much of a difference and this is the first time I'm using a Buster system for this sort of thing...
<tsimonq2> rbasak: How would I go about fixing it?
<rbasak> tsimonq2: I'm not sure how to do it on Debian. But you can check before upload: the changes files should have a X-Launchpad-Bugs-Fixed (IIRC, similar at least) line if correct.
<rbasak> tsimonq2: on Ubuntu, it happens by magic.
<tsimonq2> rbasak: Alright.
<tsimonq2> rbasak: So should I upload a new upload with that line in changes, or is it easier to do it on your end?
<rbasak> tsimonq2: new upload please. One of us has to do it. You already have the source :-)
<tsimonq2> Ok. :)
<rbasak> I can fetch it from the reject queue and do it myself if it's awkward for you.
<tsimonq2> No, I can try ;)
<cjwatson> On Debian you should be able to make it work by setting DEB_VENDOR=ubuntu in the environment when running debuild.
<tsimonq2> cjwatson: ack, thanks!
<tsimonq2> I run Testing on my laptop (which I use less often but happen to be using today) and Artful on my desktop... weird little quirk you wouldn't expect :)
<rbasak> I've been meaning to write a "so you're now an uploader!" page with a list of quirks for a while :-/
 * rbasak JFDI
<tsimonq2> rbasak: better?
<tsimonq2> rbasak: I have a feeling doomsday and any other package that I uploaded to the SRU queue within the past few hours might have the same problem :(
<rbasak> tsimonq2: do you mind checking for me please? If you click on the entry in the queue you'll see the changes file. If you can give me a list of uploads I need to reject, that's the easiest way.
<tsimonq2> rbasak: libva/xenial libqapt/xenial doomsday/zesty
<tsimonq2> rbasak: I've been busy :P
<rbasak> OK, I'll reject those, thanks.
<rbasak> I've just written an initial revision of https://wiki.ubuntu.com/DeveloperMembershipBoard/NewUploader
<rbasak> Not linked to it from anywhere yet.
<rbasak> Everyone: feel free to contribute and edit.
<rbasak> The DMB could refer successful applicants to this page so they know what to do. I remember that I certainly didn't know how to upload when my application was approved :)
<Laney> rbasak: Have you seen https://wiki.ubuntu.com/MOTU/New ?
<tsimonq2> rbasak: The only reason I knew how to upload when I got approved is because when working with acheronuk on some Kubuntu stuff, he remote signed some packages and I got to dput ubuntu them from the VPS we were working on :P
<tsimonq2> But yeah, I pretty much had to figure out everything on there :)
<rbasak> Laney: ah. Thanks!
<rbasak> Most of that isn't MOTU specific. We should have a single page and make sure the DMB points successful applicants to it.
<tsimonq2> One thing that I had to learn once I got MOTU was how to use the autopkgtest infra from the point of view of someone who has upload permissions to the archive
<tsimonq2> In this specific example, nodejs wouldn't migrate because node-something-or-other failed tests, I uploaded a new version fixing it and it didn't automatically retry... turns out my sponsors have always been smart enough to retry that stuff for me :)
<sforshee> Unit193: tseliot looks after the nvidia drivers, I don't have upload rights for those packages
<acheronuk> tsimonq2: there is: https://wiki.ubuntu.com/UbuntuDevelopment/Uploading
<tsimonq2> Oh
<tsimonq2> Ok
<tsimonq2> Cool
<rbasak> And then there were three :-/
 * tsimonq2 scratches head:
<tsimonq2> E: libqapt source: maintainer-address-causes-mail-loops-or-bounces Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<tsimonq2> Hmmm, is that a bug in Lintian or a Won't Fix? O_o
<rbasak> Does it do that on Ubuntu also?
<rbasak> IIRC, Debian's policy is that maintainer addresses must not be behind a moderation wall.
<tsimonq2> I'll check later on my Artful machine
<tsimonq2> But there doesn't seem to be a relevant delta so my guess is Yes
<rbasak> Perhaps we need to suppress that on Ubuntu as it's acceptable to us.
<tsimonq2> Ok
<tsimonq2> rbasak: All of those packages should be fixed now with a proper header, fwiw
<rbasak> Thanks!
<tsimonq2> Thanks for catching that ;)
<tsimonq2> Wooo, sponsorship queue down to 34
<mitya57> tsimonq2, \o/
<tsimonq2> Oh hey mitya57 :D
<tsimonq2> (a good chunk of the things in the sponsorship queue just needed triage
<tsimonq2> )
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
<tsimonq2> o/ sil2100
<sil2100> o/
<tsimonq2> rbasak: Since it's your SRU day, could I please get this accepted into xenial-proposed? bug 1710993
<ubottu> bug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,In progress] https://launchpad.net/bugs/1710993
<cyphermox> fossfreedom: that doesn't sound like something that ubiquity should do?
<tsimonq2> rbasak: With my Lubuntu Release Manager hat on, I think it's a fairly important update that should be rolled out... what's the process for shortening and/or bypassing the 7 day limit? i.e. do I just justify it to you or do I say something in the bug report?
<rbasak> Looking
<rbasak> tsimonq2: that's a pretty radical change given what Lubuntu is supposed to be.
<rbasak> tsimonq2: I suppose I'd like an ack from the Lubuntu release managers :-P
<tsimonq2> rbasak: I also agree that it's a pretty radical change from upstream Firefox
<rbasak> tsimonq2: so ultimately I guess you can decide, but would it be worth getting some wider discussion first?
<tsimonq2> rbasak: We did have this discussion back in February or March
<rbasak> Oh, OK. Did that include stable release changes?
<tsimonq2> rbasak: Upstream Firefox isn't going to budge, and we already ship with pulse in 16.10 and on
<tsimonq2> Yep
<rbasak> As I say I think it's not really for me to say if that's what you all want to do.
<rbasak> I just want to make sure that you're sure :-)
<tsimonq2> I'm sure :)
<rbasak> <plural>you</plural> :-)
<tsimonq2> We're sure :P
<rbasak> OK :)
<rbasak> Technically, will this dtrt and pull in pulseaudio in all cases?
<rbasak> Is there any case where apt will attempt to remove lubuntu-meta instead?
<tsimonq2> Well, I'd also like a merge on my lubuntu.xenial MP :P
<rbasak> Link?
<tsimonq2> ...why would apt try to remove lubuntu-desktop? :P
<tsimonq2> https://code.launchpad.net/~tsimonq2/ubuntu-seeds/add-pulseaudio-to-lubuntu-xenial/+merge/329783
<rbasak> Well for example something could conflict with pulseaudio.
<tsimonq2> Well like I said, this change is implemented in 16.10 and on
<tsimonq2> While I know that's not 100% justification, the seed hasn't changed that much from 16.04 to 16.10
<rbasak> Yeah but package disruption is expected during release upgrades.
<tsimonq2> Well, it'll just install some new packages.
<tsimonq2> I wouldn't describe it as "disruption"
<rbasak> I'm not sure (technically) about a seed change after release. I suppose it'll affect only future point releases? I don't know, so I'd like to defer to someone who knows for the MP.
<tsimonq2> Ok.
<rbasak> If that's all it does, then I agree it's not disruption.
<rbasak> The risk is that it doesn't do that for some unknown reason.
<tsimonq2> rbasak: We have a daily ISO that runs germinate
<tsimonq2> I see
<rbasak> One reason might be that if I have lubuntu-desktop and something installed that conflicts with pulseaudio for example.
<tsimonq2> ic
<rbasak> I don't know if there are other cases that might cause a problem.
<rbasak> I'm not saying there is a problem. I'm just trying to explore possibilities to try and discover any problems now rather than later.
<tsimonq2> I understand :)
<tsimonq2> Worst case scenario, not saying this *will* happen, but lubuntu-desktop gets removed. It's a metapackage, it shouldn't really matter.
<rbasak> It impacts a future release upgrade.
<tsimonq2> i.e. iirc it *shouldn't* autoremove the deps
<tsimonq2> Oh
<tsimonq2> Well true
<rbasak> This might all be considered acceptable of course.
<rbasak> Another thing is that "apt upgrade" may not want to install pulseaudio; only "apt full-upgrade". What will the GUI do?
<rbasak> This may not be so bad; it's no worse.
<rbasak> Actually kernel upgrades work that way.
<rbasak> So it must be fine.
<tsimonq2> Good point
<tsimonq2> But yeah, we're pretty sure about doing this :)
<rbasak> OK
<rbasak> +1
<rbasak> I'm just writing this up in the bug.
<tsimonq2> Ok :)
<tsimonq2> rbasak: My thoughts on Firefox not sticking to the ESR releases for stable releases because of the regression potential is another issue, but it could have made this easier to deal with
<rbasak> It's difficult. I'm not sure general Ubuntu users want to stick to ESR for the lifetime of Xenial for example.
<tsimonq2> (I'm not a Firefox expert (that's... the point with this...) but I think that's how Debian does it)
<tsimonq2> No I get it
<tsimonq2> But
<rbasak> snaps better suit Firefox's model IMHO.
<tsimonq2> rbasak: For once irt snaps I agree :P
<rbasak> Another way might be to package ESR also (as firefox-esr or something). Then flavours could choose to use that.
<tsimonq2> I wouldn't mind doing that
<rbasak> But as always there's the question of who would provide the developer time.
<tsimonq2> Exactly...
<rbasak> I don't think Ubuntu would object to a firefox-esr being maintained in universe.
<tsimonq2> But, hindsight is 20/20, some users have complained already that they have to install pulse (to Mozilla) and there will be more... but as Chris said in the changelog entry, if nobody will step up to fix it, it goes unfixed.
<tsimonq2> And we have to adapt.
<tsimonq2> Unfortunately...
<tsimonq2> rbasak: Maybe at the start of b-cycle I'll consider bringing that up to the MOTU list
<tsimonq2> But we'll have to see
<rbasak> Any reason to delay the discussion? You can talk about B plans now :)
<tsimonq2> I don't have a good answer :P
<tsimonq2> Sometime between today and B Alpha 1 then :P
<rbasak> Does lubuntu-meta autogenerate its dependencies like ubuntu-meta?
<tsimonq2> Yep.
<tsimonq2> Well, it does the thing with ./update
<rbasak> So for this upload you did that manually against your local change to the seed for which the MP is still outstanding?
<tsimonq2> Yep, then discarded the config change.
<tsimonq2> That's why I think they should land closely timed :P
<rbasak> OK. You have my +1 for both the upload and the MP, but I'd like someone who knows more to confirm that this approach is OK please.
<tsimonq2> Sure.
<tsimonq2> cyphermox: ping :) ^
<rbasak> slangasek perhaps? ^ and https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1710993 and https://code.launchpad.net/~tsimonq2/ubuntu-seeds/add-pulseaudio-to-lubuntu-xenial/+merge/329783
<ubottu> Launchpad bug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,In progress]
<tsimonq2> Fair ;)
<zyga-ubuntu> hey, any network-manager modem-manager experts around? I updated my xenial x250 to zesty and my modem connection can no longer be established. I see the modem (modem-manager-gui) and network-manager sees the modem but any attempts to connect fail with ""No suitable device found for this connection." -- indeed any attempt to create a new 3G connection shows no devices on the "applicable to this
<zyga-ubuntu> device" page
<cyphermox> tsimonq2: rbasak: looks sane to me, but you'll want to test what the effect is of adding pulseaudio in general
<cyphermox> ie is that going to pull in other things too?
<cyphermox> does that work fine with volume controls or is there config to change as well? (I don't think so, but better be safe)
<cyphermox> I think it would be best to further flesh out the test cases even if it looks liek a pretty straightforward change
<cyphermox> zyga-ubuntu: you should check if your modem is listed by 'mmcli -L', and if not, you should check whether usb-modeswitch and usb-modeswitch-data were updated
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
 * sil2100 switches to his SRU hat
<zyga-ubuntu> cyphermox: it is listed by mmcli -L
<zyga-ubuntu> cyphermox: 	/org/freedesktop/ModemManager1/Modem/0 [Sierra] MBIM [1199:A001]
<bjf> jbicha, any guess on when the hidpi scaling issue will get resolved in artful? is there a bug i can track the progress of?
<jbicha> bjf: wait for gnome-shell 3.25.90, we're working on it this week
<bjf> jbicha, ack, thanks
<jbicha> I guess you could subscribe to LP: #1712800
<ubottu> Launchpad bug 1712800 in mutter (Ubuntu) "FFe: gnome-shell 3.26" [Undecided,Confirmed] https://launchpad.net/bugs/1712800
<cyphermox> zyga-ubuntu: do you have ofono installed?
<cyphermox> I think there was a case where it might be pulled in or remain installed when it really shouldn't
<Unit193> sforshee: I did see he uploaded, but for the past several changes you were the one submitting them so figured I'd poke you.
<tsimonq2> cyphermox (cc rbasak): ack, I'll spin up a Lubuntu VM and test it out, report back soon
<zyga-ubuntu> cyphermox: partially
<zyga-ubuntu> libqofono-qt5-0:amd64				install
<zyga-ubuntu> qml-module-ofono:amd64				install
<zyga-ubuntu> cyphermox: ^ just those two
<zyga-ubuntu> should I remove them?
<cyphermox> I don't think that would be it
<cyphermox> you shouldn't just remove random things if unsure ;)
<zyga-ubuntu> ok
<zyga-ubuntu> any more hints on what to try?
<cyphermox> zyga-ubuntu: sorry, I do not know, the best I can offer is that you delete the connection in NM and re-create it after a reboot
<zyga-ubuntu> cyphermox: tried that
<cyphermox> ok
<zyga-ubuntu> cyphermox: when I create the connection I don't see my modem listed as a choice
<zyga-ubuntu> cyphermox: it's a roaming connection, not sure if that's a factor
<cyphermox> if the modem is listed in ModemManager (mmcli), but not found in NM, I don't know what to do with that
<cyphermox> ah, well you should check if the connection allows roaming
<cyphermox> there's a checkbox when you edit it
<sforshee> Unit193: I supplied patches yes, however it sounds like there's a patch already and I'm not able to upload that pacakge
<Unit193> Somewhat, yes.  No idea how the internal Canonical stuff works though.  Thanks.
<zyga-ubuntu> cyphermox: checked that as well, it does
 * zyga-ubuntu moves out of range
<Unit193> tseliot: Have you seen LP 1711758 by chance?
<ubottu> Launchpad bug 1711758 in nvidia-graphics-drivers-304 (Ubuntu) "artful: nvidia-304 unknown symbol init_mm" [Undecided,Confirmed] https://launchpad.net/bugs/1711758
<tseliot> Unit193: not yet, but I'll have a look at it, and I'll fix it. Thanks
<Unit193> Thanks a lot!
<rbasak> cpaelzer: looking at nut in Xenial unapproved. Is it intentional that it has no bug link?
<cpaelzer> cpaelzer: yes and no
<cpaelzer> grr
<cpaelzer> rbasak: ^^
<cpaelzer> rbasak: that is the lack of -v on that build
<cpaelzer> on the bug we talked in regard to the importer
<rbasak> I see. And the latest version bump is supposed to not have a bug link, right?
<cpaelzer> rbasak: the former upload had both buglinks, and the new one is reverting one of them
<cpaelzer> so with -v I'd close "both" which would be also wrong
<rbasak> Could you re-upload with a -v please? Otherwise I think it'll cause issues in the pending-sru report.
<rbasak> Oh.
<rbasak> I see.
<cpaelzer> rbasak: well I can, but then both which is wrong
<cpaelzer> and changing old changelog history isn't good either
<cpaelzer> which is why I uploaded the way it is now
<rbasak> I think we need a bug link for the bug that is still being fixed. Otherwise pending-sru will be broken.
<rbasak> I wonder if we need to hack the changes file to have one bug but not the other.
<cpaelzer> rbasak: TL;DR tell me which way we need it for the process to work and I'll do so
<rbasak> cpaelzer: unless someone says otherwise, I'd rebuild the source with -us -uc -v..., then modify the changes file manually, then debsign on the changes file. Ugly, but I can't think of anything better.
<Unit193> tsimonq2: Also, in regards to your lintian warning.  Yes there isn't delta, but that's because lintian uses profiles.  That specific check is disabled in Ubuntu.
<tsimonq2> Unit193: aha
<Unit193> Try --profile ubuntu
<cpaelzer> rbasak: https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+ref/bug-1540008-1099947-xenial https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+ref/bug-1540008-1099947-trusty
<cpaelzer> rbasak: do you want to do that hacking to fix it up or shall I try and you reject from unapproved so I can re-upload?
<rbasak> cpaelzer: I'd prefer if you could hack it please, then I can independently check. Less chance of a mistake slipping through - especially because it's a hack.
<cpaelzer> rbasak: ok, then reject now and I'll send you something into -unapproved
<cpaelzer> rbasak: will ping you then
<cpaelzer> rbasak: you rejected the xenial one but the case is the same for xenial and trusty
<cpaelzer> rbasak: I have the modified changes file ready
<cpaelzer> rbasak: would you reject the nut in trusty as well so we can halde both at once?
<rbasak> cpaelzer: sorry, done.
<slangasek> rbasak: what part of this approach were you looking for confirmation on?  The mechanics of how to add a package to a seed post-release, or the idea of doing so?
<cpaelzer> rbasak: bot nut uploads are in unapproved again, please take a look if you think the +v+changesmod worked the way
<rbasak> cpaelzer: will do, thanks!
<rbasak> slangasek: mainly the changing of the seed post-release.
<rbasak> slangasek: well, both parts of your question I guess.
<rbasak> slangasek: I don't know what I don't know, so I'm asking :)
<rbasak> slangasek: I don't see what would go wrong with changing both the seed and accepting the upload. But as it's unusual, I'm asking.
<rbasak> cpaelzer: https://launchpadlibrarian.net/335184706/nut_2.7.1-1ubuntu1.2_source.changes
<rbasak> cpaelzer: that's not quite what I was expecting. But I don't particularly mind 99947 ending up auto-closing. That can easily be fixed.
<slangasek> rbasak: yes, we've had to do this sort of thing before, and this is the right mechanism; update-manager will honor new dependencies on upgrade, so if Lubuntu is using that, we're ok
<tsimonq2> rbasak: oh hey, another Lubuntu Release Manager who has access approved my MP ;)
<cpaelzer> rbasak: I tohught the regex is on LP: #<HERE>
<cpaelzer> rbasak: odd
<cpaelzer> rbasak: do you want another new changes file?
<cpaelzer> rbasak: or do you handle the remaining mistake in that?
<zyga> cyphermox: http://paste.ubuntu.com/25432469/
<zyga> cyphermox: n-m crashes, I'm trying to fetch sources to see what's going on there
<zyga> specifically on sie 30 16:59:44 fyke NetworkManager[1442]: ((nm-manager.c:2863)): assertion '<dropped>' failed sie 30 16:59:44 fyke NetworkManager[1442]: ((devices/nm-device.c:8235)): assertion '<dropped>' failed
<tsimonq2> rbasak: Well, he approved it, just didn't actually merge it.
<zyga>     g_return_if_fail (nm_device_get_managed (device, FALSE));                                                                                                                                                                       |>
<zyga> also on     g_return_val_if_fail (nm_device_get_managed (self, FALSE), FALSE);
<zyga> cyphermox: so nmcli gives me this: cdc-wdm0: unmanaged 	gsm (cdc_mbim, cdc_acm), hw
<tsimonq2> cyphermox, rbasak: Ok, to report back, it installs 9 additional dependencies with 7,528 KB taken up. It installs correctly and Firefox can now play audio.
<tsimonq2> Not too many extra things
<tsimonq2> I think it'll be fine.
<rbasak> tsimonq2, slangasek, cyphermox: thanks. I'll process this today. Just otp right now.
<tsimonq2> Ok
<tsimonq2> Sponsorship queue down to 30 \o/
 * zyga updates to artful
<zyga> mvo: fingers crossed :)
<zyga> hmm
<zyga> freenode's web irc is pretty neat
<zyga> if it only did offline / background I'd never look back
<slangasek> tsimonq2: hopefully not as a result of freeze-violating uploads? :)
<tsimonq2> slangasek: Nope
<tsimonq2> slangasek: Most are triaging things, asking for updates on packages, ~ubuntu-sponsors falsely subscribed, etc.
<tsimonq2> slangasek: If anything I've done a lot of SRUs :P
<cjwatson> Mm, not convinced most of lgw01 is going to wake back up trivially ...
<tsimonq2> slangasek: One thing I want to know is how to get things like the top entry (a Bazaar branch) which I already left a comment on out of the queue :P
<slangasek> hmm, good question
<andyrock> bdmurray: hey
<andyrock> seems like that the pep8 tests were failing before too
<andyrock> do you want me to fix them all or just the parts that I edited?
<tsimonq2> slangasek: In general I'm wondering how some of these Bazaar branches are getting on here, take that MP against lp:ubuntu-cve-tracker for example, that's on the MOTU page, not the security one, which is inaccurate because the MOTU page should be things the MOTUs can sponsor, no? :)
<andyrock> bdmurray: nevermind
<andyrock> they're not failing on trunk
<slangasek> tsimonq2: I don't have the url in front of me, can you point me the page you're seeing this on/
<slangasek> tsimonq2: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?
<tsimonq2> slangasek: General overview: http://reqorts.qa.ubuntu.com/reports/sponsoring/ - MOTU page: http://reqorts.qa.ubuntu.com/reports/sponsoring/motu.html - Security page: http://reqorts.qa.ubuntu.com/reports/sponsoring/security.html
<nacc> jbicha: do you have a recommendation of who would be appropriate to help review a SRU for vim? specifically related to gvim on unity and segfaults in xenial? it was done via the git workflow and I can review the code content, but I don't know what is considered 'correct' for desktop
<slangasek> tsimonq2: ok, completely unclear to me as well; UTSL https://launchpad.net/ubuntu-sponsoring
<tsimonq2> Someone needs to indent their CSS ;)
<tsimonq2> (not pointing fingers at anyone :P)
<nacc> heh
<jbicha> nacc: IMO gvim isn't "desktop" so any Ubuntu developer should be fine
<nacc> jbicha: well the question in particular is what to do about some desktop-related hook/variable
<nacc> jbicha: specifically the last comment from the submitter in https://code.launchpad.net/~jbenden/ubuntu/+source/vim/+git/vim/+merge/329613
<jbicha> vim is Foundations
<tsimonq2> slangasek: So is ~ubuntu-branches still relevant?
<nacc> slangasek: --^ :)
<nacc> tsimonq2: we're going to reuse it for git, i think (or something similar, at least). but the bzr branches are generally dead.
<tsimonq2> Ok
<tsimonq2> I'll whip up an MP working with that...
<nacc> tsimonq2: that's my understanding at least. I'd wait to be sure from slangasek :)
<slangasek> yeah the remaining ~ubuntu-branches bzr branches are a bucket of fail
<tsimonq2> Ok
<slangasek> (the fail was left out in the sun too long and melted)
<nacc> heh
<jbicha> nacc: I left a couple drive-by comments, you can ask in #ubuntu-desktop
<nacc> jbicha: thank you
<Unit193> zyga-ubuntu: If you like webchat, perhaps check out 'thelounge'
<zyga-ubuntu> Unit193: thanks, I'll check that out
<Unit193> Can be configured to have scrollback.
<tsimonq2> rbasak: Is git ubuntu something I can install yet?
<tsimonq2> Mhhh, it would be great to have it as just a regular deb package, I don't like having snapd installed as it hogs my disk space :/
<nacc> tsimonq2: it's only a snap
<nacc> tsimonq2: making it a deb is not in our plans
<nacc> tsimonq2: because we depend on functionality from debs only available in artful (or potentially outside of debs, in the case of somethjing i'm hitting now)
<nacc> tsimonq2: and i'm not willing to sign up to backport git, gbp, etc. to older releases :)
<tsimonq2> I guess I'm installing from source :P
<nacc> tsimonq2: what release are you on?
<tsimonq2> Artful :P
<nacc> tsimonq2: ok, that should be fine :)
<nacc> tsimonq2: and 'installing' from source, is just clone and add repo/bin to PATH
<nacc> (for now)
<tsimonq2> Fair ok
<nacc> as it's a degenerate case currently (only used by developers)
<nacc> tsimonq2: if that doesn't work, let me know
<tsimonq2> Ok
<tsimonq2> nacc: Let's just say that I might be hacking on the packaging guide, if I was, is git ubuntu something production ready enough to put there? ;)
<tsimonq2> (probably not, right?)
<tsimonq2> I mean, it can always be edited in the future, but I'd like a working packaging guide...
<nacc> tsimonq2: we're not yet importing the world, so i'd wait
<nacc> tsimonq2: it's on our roadmap for 1.0 to hit that switch
<nacc> but we need to coordinate with LP team, etc.
<tsimonq2> Ok
<nacc> tsimonq2: so yeah, i'd not mention it in the hacking guide (yet). I don't think. But I woudl drop any mention of UDD or bzr :)
<tsimonq2> I'm working on that right now ;)
<nacc> tsimonq2: nice, can check that off my list then :)
<tsimonq2> nacc: That was a major part of my MOTU application, I would have been around and probably had MOTU a year before I did had that thing been up-to-date.
<tsimonq2> I know I'm not the only one who is discouraged by that.
<tsimonq2> So since the sponsorship queue doesn't hurt my eyes as much, this is my next step ;)
<nacc> tsimonq2: nice!
<nacc> tsimonq2: yeah, tbh, the tooling is probably stable enough for most people to use it, but the first thing many will try to do is clone some srcpkg which we haven't imported yet and complain (we have a clear error message to request the import). So rather than throw up that roadblock, my plan was to transition the guide at the same time as we hit the switch to import the world (which is going to take a
<nacc> while anyways)
<tsimonq2> nacc: Ok
<tsimonq2> nacc: Do you generally have an ETA on that?
<tsimonq2> (i.e. days, weeks, months, years?)
<nacc> tsimonq2: heh
<tsimonq2> I guess I'm sort of asking because if it's a matter of a month or two, I might not want to pour my heart and soul into that part of it
<nacc> tsimonq2: we are hopefully going to have a trello board up soon which has the plan laid out (and public)
<tsimonq2> ooooooh ok
<nacc> tsimonq2: we're hopefully going to be at alpha in the next month or two, but that's not a hard requirement
<tsimonq2> Ok
<tsimonq2> Fair
<nacc> tsimonq2: major feature wise, we're mostly done. but we have a bunch of refactoring going on now and a huge testing spike that rbasak is working on
<tsimonq2> nacc: Ok.
<tsimonq2> nacc: Btw, I've been meaning to ask... how will that deal with packages that are already imported in Git?
<tsimonq2> nacc: i.e. the Kubuntu packages use a totally separate Git workflow
<nacc> tsimonq2: i'll make sure to loop you in when we get all that documented out (our plan is to sit down and do that by eow next week, but again, no guarantees :)
<tsimonq2> Will git merge be expected or how will that work?
<tsimonq2> nacc: Ok :)
<nacc> tsimonq2: the importer doesn't really care (currently)
<tsimonq2> Alright
<nacc> tsimonq2: we have discussed telling the importer about some upstream sources of information (where upstream is up to the developer)
<tsimonq2> Ok
<nacc> tsimonq2: the distinction is that the importer only trusts launchpad publishing data
<nacc> tsimonq2: and we want it to always be 'correct' relative to the archive
<tsimonq2> I see
<tsimonq2> Publishing data in respect to what?
<nacc> e.g.: https://launchpad.net/ubuntu/+source/freeradius/+publishinghistory
<nacc> what was published when, and to where and with what contents
<nacc> basically, the git import is a git view of that page for every srcpkg
<tsimonq2> oic
<tsimonq2> nacc: Let's say someone really really hates Git and doesn't want to do their changes in Git, it'll automatically import the changes, right?
<nacc> the other issue we'll run into with adding 'other' sources (if we do it automatically) is that we have to translate version strings correctly (as each git project could do versioning however they want, with namespaces etc.)
<nacc> tsimonq2: yep
<nacc> tsimonq2: as long as they are published
<tsimonq2> And what if there's (unfortunately) build conflicts?
<nacc> tsimonq2: build where?
<tsimonq2> s/build/merge/
<nacc> tsimonq2: algorithmically, there won't be :)
<tsimonq2> Oh, so you'll have an algorithm that'll sort all that out (or try to)?
<nacc> http://www.justgohome.co.uk/blog/2017/08/more-on-the-imported-repositories.html
<nacc> i think talks about it a bit
<nacc> i'm not sure it goes into the detail of how we do parenting yet
<tsimonq2> Ohhhhhhh I get it
<nacc> but a future post will, i think :)
<tsimonq2> So work in Git will be done in $release-devel
<nacc> tsimonq2: we're trying to avoid being too clever, as that's what broke UDD (aiui)
<tsimonq2> And then archive copies will be in the pockets
<nacc> tsimonq2: yeah
<tsimonq2> ic
<nacc> and developer input is provided by these upload tags
<tsimonq2> nacc: SRUs?
<nacc> which is just rich history
<nacc> tsimonq2: there's a devel branch for all active releases
<tsimonq2> How will SRUs and security updates work then?
<tsimonq2> nacc: Ok
<nacc> tsimonq2: in generaly, you start off $release-devel, make some changes, `git ubuntu submit` them for review (in LP) and then a sponsor/reviewer agrees and uploads
<nacc> tsimonq2: in the case that you can upload, we are working on refining that
<tsimonq2> Ah ok
<nacc> so that your MP gets integrated into the history of the import
<nacc> we have an idea of how to do it, just need to implement it and make sure it does what we want :)
<tsimonq2> I see :)
<nacc> tsimonq2: for now, you can always still just dput
<nacc> tsimonq2: the importer will just carry on importing what has been dputted
<tsimonq2> nacc: So I really like Git's hard reset, can I do something like that with the Git repo and will it be smart and correct the changelog for me? That would be awesome :P
<tsimonq2> I can see another case where that function would be use
<tsimonq2> *used
<tsimonq2> Someone forgets an epoch in a Debian merge or something
<tsimonq2> Would it be smart and bump the changelog or just flat out reject it?
<tsimonq2> nacc: I plan on using dput still, yeah ;)
<nacc> so, in principle, `git ubuntu` is only used to get the source code. Once you have it, you can do any git-ish thing with it. We are providing some helpers for ubuntu-merges.
<nacc> (only = currently)
<nacc> git-ubuntu itself doesn't know about dput (yet)
<nacc> so it relies on the archive to still reject bad uploads
<nacc> we have a linter, that tries its best (but is a WIP)
<tsimonq2> Ok
<nacc> we are trying to avoid too much auto-correction
<nacc> as it tends to be hard to get right, and complicated :)
<nacc> (at least for 1.0)
<tsimonq2> I see
<nacc> we want to get the tool out there and usable by most first, then we can improve the UX, add new workflows, etc.
<tsimonq2> Makes sense
<tsimonq2> nacc: Well thanks for letting me pick your brain on it :)
<tsimonq2> I hope this works out :D
<nacc> tsimonq2: thanks -- we did have a studio person do a merge with it, and it worked ok, that was the first real usage outside of the server team
<nacc> tsimonq2: but if there are packages you'd like us to import, so you can play around, just let me know
<tsimonq2> Ok :)
<Unit193> nacc: Waaaait, git-ubuntu isn't going to be packaged?  Is this the expected workflow or optional "You can do this"?
<Unit193> Can one just use gbp with it?
<Unit193> Sounds optional, hrm.  Also sounds like the majority of it will be server side, so I can just ignore it and gbp instead.
<nacc> Unit193: it's not trivial to package it in a way that makes sense -- we are dependent on new upstream functionality from, e.g., gbp itself
<nacc> Unit193: afaict, without owning backporting (and thus maintaining) all the deps we need, it's not possible to pacakge it for older releases
<nacc> Unit193: if one can use gbp with an arbitrary git repository, then use, one can use gbp with our repository :)
<nacc> Unit193: tbh, i've not used gbp, so I don't know what the value-add is (yet)
<Unit193> Is it in the standard format of upstream/master/pristine-tar? (Where master = upstream+debian)
<Unit193> gbp is pretty handy stuff, fwiw.
<nacc> Unit193: we don't track upstream directly
<Unit193> Specifically gbp dch -a is nice.
<nacc> Unit193: we don't have a master branch
<nacc> Unit193: and we have per-distro pristine-tar branches (as debian and ubuntu can differ on tarball contents)
<Unit193> Sounds...Fun.
<nacc> Unit193: in principle, yes, you should be able to use gbp -- it probably needs flags and/or a conf file
<Unit193> nacc: I guess time will tell, thanks for elaborating at least.
<nacc> Unit193: so there are probably two sides to this, which is part of the confusion
<nacc> Unit193: the importer and the developer tools are in the same code
<nacc> Unit193: the importer is what you referred to earlier as server-side
<nacc> Unit193: our 'master' is 'ubuntu/devel' (we could make an actual master, we just intentionally did not yet)
<nacc> Unit193: so for developer side, i think it would be pretty easy (IME gbp has flags for everything :)
<Unit193> Hmm, wondering how imports would work.  Not really messed with single branch git repos, that don't only have debian/ that is.
<nacc> Unit193: see the above blog post -- and future ones that will explain more how the importer algorithm works
<nacc> and/or the source :)
<nacc> imports are imports of Launchpad publishing information (with potentially additional rich history provided by developers)
<Unit193> Right, was just thinking about without 'git ubuntu'.
<nacc> so, e.g, in thinking about tsimonq2's question earlier -- if a developer was to provide the hash of a commit from the kde repo as the upload tag to the importer (process to be clarified/explained later), then the entire history of that commit will get integrated into the import history at that point
<nacc> Unit193: yeah, good luck :)
<nacc> Unit193: dgit is the only other importer-like model I'm aware of
<nacc> Unit193: and we do pretty similar things (intentionally)
<Unit193> So, ignore and use dput for new upstreams, this for other changes. :D
<nacc> Unit193: new upstream versions you mean (where upstream is unrelated to debian/) ?
<Unit193> nacc: Right, new tarball, eg 2.3 â 2.4
<nacc> Unit193: yeah, effectively, we need to provide tooling to wrap that particular workflow (uupdate/uscan) in a clean way -- there is i believe a bug for that already
<Unit193> nacc: As I said, I should just wait and see how you guys do it (well, how you provide ways to do it rather), hopefully will be quite nice. :)
<nacc> yeah, I've done upstream updates for php7.0 in the tooling, just by hand. Then the importer handles the pristine-tar'ing of it all (as it gets the orig tarball from the archive)
<nacc> Unit193: agreed, wait and see :)
<Unit193> Huh, OK.
<nacc> Unit193: we have a slightly different model than UDD did, I think. We don't want developers messing with the branches
<nacc> Unit193: it's too easy to get wrong, parenting, etc.
<nacc> Unit193: so instead, you just give us the upload itself, we figure out where it goes into the imported history
<nacc> Unit193: and that includes, for new upstreams, the pristine-tar branches themselves
<Unit193> In regards to upstream, not...Oh I'll just go look for a repo...
<nacc> Unit193: :)
<nacc> hopefuly I didn't make it more confusing
<Unit193> That's a lot of branches and tags..
<nacc> Unit193: yep :)
<Unit193> nacc: So I make some changes, commit them, push them to the repo.  Did I just do an upload?
<nacc> Unit193: nope :)
<Unit193> \o/
<nacc> Unit193: that's the bit that's currently disconnected
<nacc> Unit193: current: use `git ubuntu submit` to create a MP
<nacc> Unit193: that will get reviewed by one of us that can do upload tagging and we will sponsor it (if appropriate)
<Unit193> Well, staging things is nice too though.  Pushing a tag might be a nice way to indicate it should be an upload (though there's a lot of tags.)
<Unit193> Hrm, so that's the part that's a bit disconnected, I see.
<nacc> Unit193: short-term future: MPs that are in the approved state (thus dependent on approving teams) will get upload-tagged automatically by the importer
<nacc> Unit193: long-term future: `git ubuntu push` replaces `dput`
<Unit193> Right, I'm still thinking of when someone doesn't have 'git ubuntu'
<nacc> Unit193: right, if they don't have git ubuntu, nothing changes for them
<nacc> for now
<nacc> Unit193: the importer proceeds regardless of how the upload occurred
<nacc> Unit193: the only differnce between the above and doing a normal dput is the rich history
<Unit193> Indeed.  I like git managed packaging (clearly: https://git.launchpad.net/~xubuntu-dev/+git/xfdashboard), just figuring out how without git-ubuntu.  Again, thanks for discussing it, I can tell you're excited about it. :)
<nacc> Yeah, I'm not sure how I'd do packaging without git anymore (I can do it by hand, I just tend to make more mistakes that way)
<nacc> in general, one should be able to do `git ubuntu clone <srcpkg>` and then do whatever they want with git
<nacc> everything after that point is workflow(s)
<nacc> Unit193: tsimonq2: thank you both for the discussions. It helps me clarify to myself assumptions we are making.
<Unit193> Eg, "grumpy people not installing snaps".  Sure thing!  Thanks for listening.
<nacc> Unit193: :) I get it. For us, right now, snaps make a ton of sense for getting someone to go from nothing to a fully configured development environment
<rbasak> Unit193, tsimonq2: I think you're both thinking of this from a perspective of using git to maintain packaging for a particular package. You can already do that without our work like some flavor teams do already for example.
<nacc> rbasak: a good point
<rbasak> Just use gbp, etc.
<rbasak> But this of course clashes when someone outside a team uploads to Ubuntu without also pushing to git.
<rbasak> Same as a Debian NMU.
<rbasak> What we're achieving with our work is presenting a git view of the archive regardless of whether uploaders pushed to Ubuntu's git repos or not.
<rbasak> For example most uploads will some as syncs from Debian.
<nacc> rbasak: you're explaining it better than me :)
<rbasak> Then you have a choice. You can base further work on our general git view, or continue using your specific git repositories with your own layout and branching and tagging scheme
<rbasak> You cannot push to our git views directly. Only the importer can do that. This ensures that the git view accurately reflects uploads that actually happened.
<rbasak> If you wish, you can provide (work in progress - manually done by us currently) the importer with your commits before you perform an upload. When the importer imports your upload from Launchpad, if it agrees that your commits match what it sees in the archive, then it'll adopt those commits as history in the appropriate branch.
<rbasak> If you don't provide the commits, then the importer will import anyway - but it'll be as if all your commits have been squashed together. The importer will only present one commit per upload in that case. But that's still very useful.
<Unit193> rbasak: To some extent, except a nmu is supposed to be minimal and generally discouraged, whereas Ubuntu is more like a QA upload.  So one can maintain it in git, but certainly not ideal.  And is it really like a view?  In that case, I'd expect not to interact with it, and it'd not be a replacement for the old bzr interface (which is what I thought the goal was.)
<Unit193> And, somewhat useful as one commit, it's like the diffs now.
<rbasak> It's a view if you don't interact with it.
<Unit193> And I see, it's really not meant to be a replacement for the old bzr interface.
<rbasak> If you do provide rich history, it'll adopt that history and be more than a view.
<nacc> Unit193: what was the old bzr interface that you refer to? UDD?
<rbasak> But it'll still be authoritative in that developers can trust that it represents the archive exactly. The archive remains the single source of truth, as uploaded, rather than what a developer pushed to git.
<rbasak> One day, we could switch over the single source of truth to git. But we'd need to collectively agree to do that, and dput would have to become secondary for everyone.
<rbasak> If this switchover were to happen, then at that point developers would be able to push directly, and the importer would no longer be needed.
<Unit193> Sounds less useful how you explain it, more like a version of sources.debian.net with diffs too.
<rbasak> What do you want instead?
<Unit193> No, just going on what it is.
<rbasak> I mean: you're saying it's less useful; what's the more useful thing you were expecting?
<Unit193> Something part way between dgit (which I've never used), and the older bzr interface.
<Unit193> nacc: I'm not entirely sure the name, could be.
<Unit193> nacc: udd to me is https://udd.debian.org though.:P
<rbasak> Can you be more specific?
<nacc> Unit193: heh
<Unit193> I mean, I don't think there's reason for me to be?  TBH.  Was just thinking the idea was to create another way to upload, like dgit, with pull requests and the like, not a way to view sources and how it changes over time.  I just misunderstood the goal, it seems.
<nacc> Unit193: jumping from A to C isn't possible :)
<Unit193> OK...
<nacc> Unit193: we are going A -> B -> C (I think what you describe is what both rbasak and I described, as a future possibility)
<nacc> Unit193: it won't be 'another way', though, it would have to be "the" way. Because otherwise you get inconsistencies and there isn't a single 'source of truth' to rely on
<Unit193> nacc: Now, don't misunderstand me.  Viewing certainly has advantages, not having to `pull-lp-source` just to look at a patch will be nice.  Right, and that doesn't sound ideal.
<rbasak> It would be trivial to have a git push -> dput wrapper. Though it would need Launchpad to be changed to trust a git signed commit, etc.
<rbasak> But that wrapper might as well be in the client.
<rbasak> You can do that pretty trivially today.
<rbasak> So you can do that if you want. But it's entirely a client thing. And it doesn't solve the use cases we're trying to fix.
<Unit193> (I keep saying dgit as I know *somehow* it interacts with uploads, not in the standard way.  That being said, I have never used that, I only do git/svn/bzr packaging then either request sponsorship or dput and tag.)
<Unit193> rbasak: Exactly, you're seeing what I'm talking about as a request.  While I think certain things would be nice, I'm just figuring it out (and it's already taken up enough time, I'd think. :/ )
<rbasak> Sure, it's tricky to figure out. We've spent months thinking about this area.
<Unit193> Well, perhaps a little less "what it is", and more "what it is and how would I work with it"
<rbasak> I'm confident that if you agree with our use cases, then you won't come to any other solution.
<rbasak> But feel free to prove me wrong :)
<tsimonq2> Side note, am I the only one who thinks it's a bit ironic to, when this gets rolled out for wide usage, have to install a Snap to develop a deb package? :P
<tsimonq2> C'mon, I'll happily help maintain the deb package :P
<rbasak> You'd have to maintain it in backports.
<rbasak> I have no objection if you want to take that on.
<Unit193> rbasak: TBH, I think having a specific branch that LP/etc basically monitor, but you can have changes staged and it'd only treat as an upload when you have a signed tag would be amazing.  But that's something else.
<rbasak> Yeah - what we're doing is orthogonal to that.
<Unit193> (This seems like a bit of extra work as it is.  "Stage your changes in git, push, make a pull request, then upload, and the importer will accept your PR when it sees the upload and merge.")
<rbasak> The wrapper will deal with all that in the end.
<rbasak> "Here's a commit; make it be my upload. Go."
<Unit193> rbasak, nacc: I don't mean to bash what you're doing, as stated having something like sources.debian.net is nice.
<tsimonq2> Oh I didn't even think of that
<tsimonq2> sources.debian.net but with Git
<rbasak> Once we're there, we could look into turning signed git tags into uploads automatically.
<tsimonq2> That would be *nice*
<rbasak> tsimonq2: we're pretty much there now; only it's not searchable and isn't live for all packages yet.
<rbasak> https://code.launchpad.net/~usd-import-team/+git
<Unit193> tsimonq2: "more like a version of sources.debian.net with diffs too." is what I said earlier.
<tsimonq2> Unit193: then the credit goes to you :P :D
<tsimonq2> rbasak: oooooh
<Unit193> Not looking for credit, just how I'd explain it.
<tsimonq2> Unit193: however you want to say it :)
<tsimonq2> But we're on the same page
<tsimonq2> rbasak: Oh, here's a use case for ya... NEW packages
<Unit193> (They're different things.)  Now stupid question: Rather than filing a bug, will this enable me to make a PR to upload?
<tsimonq2> Can I have a package have the initial upload with this, rbasak?
<tsimonq2> Or only existing packages?
<Unit193> tsimonq2: Perhaps we should wait until it's fully baked, then just take a look. :)
<tsimonq2> "existing" meaning "in the archive"
<Unit193> Speaking of, I still have something stuck in NEW. :/
<rbasak> Unit193: I appreciate the conversation now. Happy to influence our plans based on developer opinion!
<rbasak> tsimonq2: I'm not sure I follow your question
<tsimonq2> Unit193: That's fair, just giving a brain dump as to my thoughts :)
<rbasak> tsimonq2: new packages will end up imported once accepted.
<tsimonq2> rbasak: Ok, is there any way to have the Git repo created *before* it's accepted and have *that* do the initial upload?
<tsimonq2> rbasak: Or do they have to already be accepted in the archive?
<tsimonq2> Sure it may be an edge case but I can see it
<rbasak> Uploads must go through dput as usual.
<tsimonq2> Oh, ok.
<rbasak> However, if you want the importer to pick up your existing git tree as history, it can do that.
<rbasak> There's also "git ubuntu queue" which can be used for NEW and Unapproved queue reviews.
<rbasak> So archive admins and SRU team members (or anyone) can get a preview of something before it's accepted.
<rbasak> I use this to diff proposed SRUs against different things, which is really handy.
<rbasak> If it helps, we aren't yet doing anything to Launchpad or any other infrastructure.
<tsimonq2> Ah ok
<rbasak> The importer is a separate tool that has no special privilege over any normal user.
<rbasak> The one thing we have in the immediate roadmap is to make lp:ubuntu/<package> be aliased to the importer's repositories, rather than any other team's repositories.
<rbasak> That's the only privilege we intend to give to this project in the short term.
<tsimonq2> Side note... Creative Commons Attribution 4.0 International License looks to be DFSG-compatible, I'm just wondering what the best way to put it in debian/copyright would be...
<tsimonq2> Ah ok, found an example...
<Unit193> rbasak: Regarding backports, there's really nobody manning that now so even if one does do backports, you won't get anywhere.
<Unit193> rbasak, nacc: FWIW, I think I may have also sounded more harsh than I was.  If so, sorry about that.
<nacc> Unit193: no offense taken here. With (currently) two of us working on it, there's just only so much scope we can really commit to at a time. I think we all agree, at a first pass, having the history/src of every src package in git is a good start. That's our primary 1.0 goal.
<Unit193> I'm not going to disagree with you there!  And cgit is fast enough that it wouldn't be faster to just grab the source.
<nacc> Unit193: i think for teams that already use git (or individual developers) then there is a lot of work to be done just to understand workflows. Tbh, I don't think it's in my interest to try and replace every tool out there. So if gbp is your friend, use it til the end of time. I want to provide a easier path for people that aren't experienced developers to get fixes to Ubuntu.
<nacc> *experienced Ubuntu developers (specifically packaging)
<Unit193> I'm not sure if I count as "experienced", but yeah gbp floats my boat pretty well.  I just don't use it in Ubuntu too much due to the free-for-all nature of the archive.  I understand your point, though.  Makes sense (Still think PRs would be nicer than bugs.)
<Unit193> (It's what I use in Debian, but Debian != Ubuntu.)
<nacc> Unit193: and to be clear, yes, at some point, PRs (well, MPs, as it's Launchpad) will be (are already for our team, e.g.) a way to request sponsorship and uploading
<Unit193> \o/
<Unit193> MP == bzr. :P
<Unit193> nacc: I should really stop bugging you though.
<nacc> Unit193: yeah, it's overloaded in LP
<mwhudson> Laney: the artful autopkgtest base images still seem to have python3.5 installed even though it's been removed from artful
<mwhudson> Laney: how does that get fixed, do you move to a new base image at some point?
<mwhudson> Laney: nm :)
#ubuntu-devel 2017-08-31
<blahdeblah> Any ops around?  I would like to get upcoming mailing lists outage announced in topic.
<valorie> blahdeblah: has the announcement been sent to the MLs themselves?
<blahdeblah> valorie: All the mailing lists?  No.  I can't even imagine how painful that would be to organise.
<Unit193> Any?
<blahdeblah> It's been announced to the community council and the Canonical staff mailing list.
<blahdeblah> And one of the ML moderators said he'd organise an announcement to ubuntu-users; not sure if that happened yet.
<valorie> wow, that's such a tiny subset
<valorie> ubuntu-devel at the very least I would say
<sarnold> it would be nice to not receive fifty emails about it though :)
<valorie> sure
<blahdeblah> valorie: Hence why I'm asking around more than 48 hours in advance... ;-)
<valorie> right -- but IMO the people who care the most are the ML subscribers
<Unit193> sarnold: What if I forward it to you 30 times?
<sarnold> Unit193: well, if _you_ do it.. <3
<valorie> one thing I really do like about gmail is that if you get the same mail multiple times, it only shows up once, with all the other identical copies spread out below
<Unit193> Unfortunate but so far those are private lists.
<ouroumov> seb128, hello. I've had no responses following the mail I sent to -devel about bug 1700930
<ubottu> bug 1700930 in unattended-upgrades (Ubuntu) "Default action policy for "Security Updates" changed between 14.04 and 16.04" [Undecided,Confirmed] https://launchpad.net/bugs/1700930
<cpaelzer> rbasak: on the changes files adapted for SRU processing
<cpaelzer> rbasak: I got no mail, IRC about them but they are still in queue
<cpaelzer> rbasak: was that on trying to fix-up/finding out why the tools mean to close the totally wrong bug?
<cpaelzer> rbasak: or is there anything I can/shall do to unblock?
<tjaalton> doko: looks like the llvm5/gcc7 linking bug is resolved, so I'll bump mesa to use llvm5 in debian and then later also artful?
<doko> tjaalton: could you make sure that we can demote llvm-4 for a?
<tjaalton> doko: yep
<doko> ta
<doko> I'll bump doxygen
<doko> Laney, seb128: please could the desktop team file a MIR for hunspell-dz?
<seb128> k
<doko> jamespage: https://bugs.launchpad.net/ubuntu/+source/defusedxml/+bug/1713264 needs copyright update
<ubottu> Launchpad bug 1713264 in defusedxml (Ubuntu) "[MIR] defusedxml" [Undecided,Incomplete]
<jamespage> doko: working that now
<cjwatson> are the latest LXD images:ubuntu/artful/amd64 images known-broken?  looks like ifupdown is gone from them but they don't have adequate netplan configuration in place
<cjwatson> so 'lxc launch images:ubuntu/artful/amd64 test && lxc exec test apt update' fails
<cjwatson> I'm not sure where the image building logic lives
<Odd_Bloke> cjwatson: I believe that stgraber owns the images: images, and we own the ubuntu: images.
<cjwatson> there are no artful images in ubuntu:
<cjwatson> (I'm trying to build an autopkgtest base image, so specifically need artful)
<Odd_Bloke> "Ah, true, there will be in ubuntu-daily: though", he said, checking.
<cjwatson> aha
<cjwatson> thanks, let me see if those are healthier
<Odd_Bloke> Yep, there they are.
<cjwatson> and looks like the images: build scripts are in https://github.com/lxc/lxc-ci
<blahdeblah> Mailing list & channel ops, please see the email I've just sent to ubuntu-devel-announce/ubuntu-users (or the earlier Canonical staff anouncement) and forward/update topics as necessary.
<cjwatson> Odd_Bloke: ubuntu-daily:artful/amd64 indeed works, though only by virtue of still having ifupdown installed
<cjwatson> still, might do me for now
<zyga> cyphermox: hey, in case you have some more modem insight, on artful, there's no gui for the modem in network-manager anymore, I'm logged into the "ubuntu" session, is that expected?
<Odd_Bloke> cjwatson: Yeah, we're currently wrestling with getting the ifupdown-free image to work in ScalingStack; testing there gates image publication.
<cjwatson> Odd_Bloke: do you have a link to the relevant bits of build scripts?  I'm just working on an update to the lxc-ubuntu template
<Odd_Bloke> cjwatson: https://git.launchpad.net/~cloudware/cloudware/+git/cpc_build_tools/tree/lxd_metadata <-- internal-only unfortunately, for Reasons(TM)
<cjwatson> thanks
<Unit193> slangasek: Thanks for the gifted patch to ruby-rbnacl!
<Laney> ah
<Laney> that'll be why the new autopkgtest lxd runners I tried to create don't work :-)
<xnox> cjwatson, Odd_Bloke, Laney - do you mean https://github.com/lxc/lxc/pull/1770/files ?
<xnox> Odd_Bloke, also that merge of devel into master looks odd; and is missing some of my commits =/
<Odd_Bloke> xnox: "that merge"?
<xnox> Odd_Bloke, hm, maybe i am reading things badly in that lxd_metadata script
<xnox> Odd_Bloke, everything is fine, and i was looking at the wrong branch.
<xnox> somehow thought that https://git.launchpad.net/~cloudware/cloudware/+git/cpc_build_tools/commit/?h=master&id=307b2aacfa744b156be4f76b8275fc1898b649fd went missing, but it is not
<Odd_Bloke> :)
<cjwatson> xnox: Yeah, I just noticed that :)
<cjwatson> (and left a minor review comment to sync up with what I'd already done locally)
<doko> jamespage: for #1713617, do you want to replace xclip by xsel?
<sil2100> jbicha: hey! Could you please add the Regression Potential field to the description of the bug + fill in the Impact part for bug https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1708936 ?
<ubottu> Launchpad bug 1708936 in gnome-software (Ubuntu Xenial) "GNOME Software 3.20.5 doesn't install 3rd party deb's, doesn't prompt for authentication" [Critical,Fix committed]
<jbicha> sil2100: I added a couple lines. I only filed the bug, I didn't fix it :)
<xnox> cjwatson, $ cat /etc/network/if-up.d/openssh-server -> is something similar needed in netplan/networkd world? E.g. a udev rules file that triggers openssh-server reload?
<xnox> or e.g. a unit that binds to something dynamic or some such?
<sil2100> jbicha: thanks ;) Ok, I *guess* this is good enough - since the bug title does say the impact pretty well
<xnox> cjwatson, we can have .path unit monitoring /run/systemd/network stuff and trigger openssh-server reloads.
<jbicha> thanks
<cjwatson> xnox: let's not perpetuate that; there's already talk that it may be sensible just to drop that, although it needs further investigation
<xnox> ack
<doko> cking: your xchat-gnome upload ftbfs
<niedbalski> sil2100, ping re: LP:#1708305 , I did the verification for xenial/zesty, but just the zesty package was moved into -updates. Could you check the xenial one?
<seb128> cking, that xchat-gnome upload is weird btw, you state in the changelog that it fixes a ftbfs like if the package was still in the archive but you are in fact adding it back, would have been nice to explain the rational of why the removal reasons are not valid anymore (it was deleted because it's unmaintained and superseeded by hexchat)
<niedbalski> bdmurray, ^^ please
<sil2100> niedbalski: hey! Let me check that
<xnox> cking, yeah y no hexchat? =)
<xnox> hexchat is awesome
<sil2100> niedbalski: ok, now it's good for release, last time it didn't age long enough yet (was in -proposed for less than 7 days)
<niedbalski> sil2100, aaah i see, ack. thank you.
<slashd> rbasak, I heard the percona ppc64el bug in on your queue (LP: #1657256) ? Is that right ?
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<rbasak> slashd: yeah it's in my queue, but I'd be happy for anyone else to sponsor that too.
<slashd> rbasak, Just for our information ... how far it is in your queue ? ;) Seems difficult to find a sponsor for percona especially for this bug.
<slashd> tinoco, niedbalski ^
<rbasak> Predicting my queue is a little difficult as the items vary in sizing massively. I'll try and get to it this week for you. Feel free to ping to remind me.
<rbasak> As it will hopefully be a pretty quick task too. I'm just reluctant to context switch right now.
<slashd> rbasak, sure thanks we appreciated it.
<slashd> tinoco, niedbalski ^^^
<niedbalski> slashd, rbasak thank you
<ESphynx> hi guys, would there be a reason why 32 bit builds are failing?
<cjwatson> ESphynx: I think you'll have to be a bit more specific
<ESphynx> cjwatson: our i386 and armhf builds are failing and I was wondering why :P just realized it might actually be an endless loop, I didn't really understand the build log
<ESphynx> yeah sorry... figured it out, our fault :P thanks.
<doko> jamespage: fyi, defusedxml autopkg tests fail
<doko> I only promoted the package in -proposed
<jamespage> doko: ack
<jamespage> tomorrow - just dealing with a libvirt issue with cpaelzer atm
<stgraber> cjwatson: we have a pull request from xnox to try to fix that netplan mess, currently being reviewed
<cjwatson> stgraber: yeah, I saw that eventually, thanks
<xnox> stgraber, netplan tools and technology ;-)
<xnox> not mess!
<ogra_> the plan is in the name !
<stgraber> xnox: well, the migration from ifupdown to netplan in artful has been a mess :)
<slangasek> Unit193: ffi >_<
<smoser> hey, anyone interested, i'd apprecate review of
<smoser>  https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/330043
<smoser> apw, ^ you having been last touched there, i'd appreciate your input
#ubuntu-devel 2017-09-01
<Unit193> slangasek: But alas it is needed for Ed25519 keys in net-ssh.  Anywho, you can sync the package now if you'd like.
<slangasek> Unit193: done, thanks
<Unit193> As I said, thank *you*
<doko> xnox: are you aware of anything which needs given back for numpy installability?
<xnox> doko, i was only aware that cython is broken and needs to be rebuilt somehow; the rest should just work
<xnox> doko, and it looks like you are fixing cython
<doko> right
<jamespage> doko: that dep8 failure for defusedxml looks like a similar timeout issue I hit with OVS - resubmitted test jobs will keep an eye on them
<LocutusOfBorg> people, vlc-3 master-daily ppa is FIXED. please use and test, and bother to me in case you are not happy with it
<LocutusOfBorg> https://code.launchpad.net/~videolan/+recipe/master-daily
<LocutusOfBorg> I fixed it some days ago, but today I would like to have some broader feedback if possible
<LargePrime> hello regarding https://packages.ubuntu.com/zesty/libgnutls30 gnutls version is 3.6
<LargePrime> http://gnutls.org/news.html has had updates for almost a year
<LargePrime> how can i help get gnutls updated?
<LargePrime> sorry ubuntu version s 3.5.6.  latest is 3.5.15
<juliank> LargePrime: What's your need for an update?
<LargePrime> bug fixed.  gnutls has a tls bug
<LargePrime> juliank,
<juliank> There are always two options: Backport the bug fix or (if the update is not too invasive and bug fix only) update to a later bug fix release.
<juliank> But the latter needs far more convincing than the former
<juliank> Or well, it might get stuck for months because it's a big update nobody wants to review or something
<LargePrime> do you mind explaining why one would back port a bug fix for a bug fix of the same version
<ogra_> LargePrime, do you have the CVE number for the bug ?
<juliank> LargePrime: The less stuff you change the less stuff you can break.
<LargePrime> um, checking ogra_
<juliank> Also less stuff to review.
<ogra_> (there were definitely quite a bunch of CVE fixes to the package)
<juliank> There was a security update in June corresponding to 3.5.13
<juliank> there were no reported security issues since then
<ogra_> yeah https://usn.ubuntu.com/usn/usn-3318-1/
<juliank> A good first step would be upgrading artful from 3.5.8 to 3.5.15
<LargePrime> https://gitlab.com/gnutls/gnutls/issues/223
<LargePrime> wat do
<juliank> So, pick the relevant commits out of there, put them into patch files, prepare an update with that for artful, and then it can be updated in zesty as well.
<juliank> Or merge 3.5.15 from debian unstable to artful
<juliank> and then cherry-pick the commits into zesty
<juliank> 4 commits, even, https://gitlab.com/gnutls/gnutls/merge_requests/433/commits
<juliank> ehm, https://gitlab.com/gnutls/gnutls/merge_requests/434
<juliank> A first step is to write a bug report in launchpad :)
<juliank> Preferably directly following the template at https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<juliank> I'm not sure if a new 3.5.x release would qualify for zesty, it depends on if you consider "Added support for IDNA2008 for internationalized DNS names." from 3.5.9 a feature or a bug fix I guess.
<Odd_Bloke> artful is in feature freeze now, so you'd also have to determine it there as well.
<juliank> and of course it's a critical piece of software, so cherry-picking individual commits seems like a more sensible choice.
<juliank> Odd_Bloke: true
<juliank> Debian fixed the bug in question in 3.5.8-5+deb9u3
<juliank> https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=gnutls28_09_stretch&id=aebb4e1b78758d6395e17a3137f2c67a2fb7a334
<LargePrime> does that mean i still should file a bug report?
<juliank> LargePrime: Yes, of course, without a bug report, there can be no update to a stable release :)
<juliank> The patches from Debian apply to zesty, so it seems fairly trivial
<juliank> We should also pick the AES GCM breakage on aarch64 as in https://gitlab.com/gnutls/gnutls/commit/228b18dfbf934d8924d3305dc24d7b0162352eba
<juliank> LargePrime: Let me know the bug number then, I might just take care of this
<LargePrime> kk
<LargePrime> Timeout error
<LargePrime> Sorry, something just went wrong in Launchpad.
<LargePrime> Weâve recorded what happened, and weâll fix it as soon as possible. Apologies for the inconvenience.
<LargePrime> Trying again in a couple of minutes might work.
<LargePrime> (Error ID: OOPS-11dfb04dc9e16f2f531d539566a9206c)
<cjwatson> when it says "try again in a couple of minutes", it's correct
<cjwatson> (this is a known occasional issue that generally goes away within 10 minutes or so)
<juliank> launchpad is the only service I know that times out a lot
<juliank> well, a lot is probably below 10%, but still
<juliank> It's more fun if it times out during autopkgtests and breaks them :D
<cjwatson> it's a long way under 10% :)
<juliank> cjwatson: Maybe it's about 1%?
<cjwatson> most other services just let pages take forever to render and degrade service for everyone else; timing out is a deliberate strategy to avoid that (though obviously any timeout is a bug)
<cjwatson> we issue about 800 timeouts a day at the moment
<LargePrime> happened again.  i have to re do the bug each time, right?
<cjwatson> back button doesn't retrieve it?  usually does for me
<juliank> cjwatson: I mostly use Google and Facebook services, so it's not really an accurate representation of normally scaling services :D
<LargePrime> "libgnutls30" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
<LargePrime> um
<juliank> LargePrime: It's gnutls28
<juliank> there's some weird naming going on there
<cjwatson> unless our stats are egregiously lying to me, that's <0.01% of requests timing out
<juliank> 99.99% availability seems OK
<LargePrime> what is the cli ubuntu pastebin ?
<cjwatson> pastebinit -b http://paste.ubuntu.com
<rbasak> LargePrime: pastebinit
<LargePrime> cause i have libgnutls30
<cjwatson> libgnutls30 is a binary package produced by the gnutls28 source package
<cjwatson> bugs are grouped by source package
<cjwatson> LP's search widget next to "in what package did you find this bug?" will find gnutls28 for you, though
<LargePrime> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1714506
<ubottu> Launchpad bug 1714506 in gnutls28 (Ubuntu) "libgnutls30 OCSP verification bug" [Undecided,New]
<LargePrime> juliank,
<cjwatson> http://people.canonical.com/~cjwatson/tmp/gnutls28-search.png
<LargePrime> assuming it gets patched, how soon would it be pushed out?
<juliank> LargePrime: a few weeks
<juliank> at the earliest
<LargePrime> great
<LargePrime> i guess i could build it?
<juliank> LargePrime: I mean, the update goes into -proposed early, you can then install it from there and it needs to be validated to enter the normal -updates thing
<juliank> There's a mandatory period of 7 days from proposed to updates
<juliank> (IIRC)
<juliank> also needs manual review for being accepted into -proposed which probably won't happen this week
<cjwatson> security updates may take a different route though
<juliank> cjwatson: Yes, but that's not security related
<juliank> cjwatson: Well, not a security update
<cjwatson> OK
<juliank> It's a "cannot connect to server" kind of update
<juliank> So, https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1707172 and https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1714506
<ubottu> Launchpad bug 1707172 in gnutls28 (Ubuntu) "AES256-GCM emits all-zeros ciphertext on aarch64 with hardware acceleration" [Undecided,New]
<ubottu> Launchpad bug 1714506 in gnutls28 (Ubuntu) "libgnutls30 OCSP verification bug" [Undecided,New]
<juliank> I'm not happy with the AES256-GCM one the test is to run yes in gnome-terminal and wait for it to crash
<juliank> found the original bug report with a better test case :D
<xnox> doko, infinity: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1714514 is this known?
<ubottu> Launchpad bug 1714514 in glibc (Ubuntu) "math.c broken on i386, when compiling with -O2 -C" [Undecided,New]
<juliank> Hmm is there a way to mark a macro that expands to an attribute as deprecated in gcc?
<juliank> APT_CONST expands to __attribute__((pure)) now, but I'd also like a pragma or something that says "hey, APT_CONST is deprecated, use APT_PURE instead."
<juliank> Maybe __attribute__((pure)) _Pragma("Use APT_PURE")?
<juliank> Ehm, _Pragma("GCC warning \"Use APT pure\"")
<doko> xnox: no, is using -C a real world example?
<xnox> doko, yes, unfortunately.
<xnox>  509      AC_MSG_WARN([Default pre-processing command '$CPP' do not preserve
<xnox>  510                     comments. Please define an appropriate pre-processor
<xnox>  511                   with --with-cpp, or you will only be able to use ACSL
<xnox>  512                   annotations in already pre-processed files])
<xnox> it's this frama-c thing this is analysis tool crazy thing
<doko> juliank: isn't gnome using some depracted thing for functions? maybe have a look at glib or gtk
<xnox> doko, i will try to work around this issue, as i don't think it needs -C whilst building a file that includes math.h
<xnox> doko, but this works on all other arches =/
<juliank> doko: Probably __attrribute__((deprecated)) but I want to mark the macro as deprecated, not the function using the macro :(
<juliank> But the pragma seems to work
<doko> ahh, ok
<doko> jamespage: left a comment in https://bugs.launchpad.net/ubuntu/+source/xclip/+bug/1713617
<ubottu> Launchpad bug 1713617 in xclip (Ubuntu) "[MIR] python-pyperclip, xclip" [High,Incomplete]
<jamespage> doko: ta
<LargePrime> juliank, thanks
<doko> jamespage: pyperclip doesn't run tests for python3
<seb128> bdmurray, I +1ed https://code.launchpad.net/~azzar1/update-notifier/ngettext-livepatch/+merge/329982 but I'm going to let you handle the merge/upload if it's fine?
<seb128> bdmurray, the code is fine, I'm just not going to get to handle the vcs/upload this week
<doko> coreycb, rbasak: highlighing https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/173783  because ubuntu-security-bugs and ubuntu-server are a bug subscriber
<ubottu> Launchpad bug 173783 in libssh2 (Ubuntu) "main inclusion request" [Wishlist,Won't fix]
<doko> nmap has an embedded ssh2 copy anyway
<coreycb> doko: was that meant for me?
<doko> coreycb: if you are ubuntu-server, yes
<nacc> doko: coreycb is not :)
<coreycb> doko: i'm a member. i just wasn't sure if it was meant for security team.
<doko> coreycb, nacc: both teams are subscribed, I just want to at least ONE party involved, not no party
<coreycb> doko: thanks
<rbasak> niedbalski: looking at bug 1657256. Is there a bug filed against Percona with the patches you're applying here please?
<ubottu> bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<rbasak> Percona upstream I mean.
<niedbalski> rbasak, there is no, as power isn't an official architecture supported by percona upstream, they just support intel.
<rbasak> niedbalski: then could you please link instead to their rejection of the patches or some published general rejection policy from them? Then the question will be answered to anyone trying to find the upstream bug link.
<rbasak> niedbalski: also it just FTBFS. Please could you take a look?
<Mmike> rbasak, it's mentioned here: https://www.percona.com/services/support/mysql-support/supported-platforms
<Mmike> rbasak, last line: "All hardware platforms are i686 and x86_64 only."
<Mmike> percona only cares about intel
<rbasak> Mmike: that doesn't say "we will reject patches regarding other architectures" however.
<rbasak> "Enterprise and Premier Percona MySQL Support includes the option for additional operating systems support"
<rbasak> Mmike: that suggests they would be happy to accept patches for other platforms, since some of their customers are paying for support for those.
<Mmike> rbasak, I think we tried that in the past, there are some bugs from pxc-5.5 in trusty, we had similar conversations then...
<Mmike> sec, I can ping someone on #percona to point me to proper documentation about that
<rbasak> In any case, please just leave a public paper trail of their rejection.
<rbasak> If it isn't in a public policy, then just submit the patches publicly and link to that. They can reject as they wish.
<niedbalski> rbasak, OK, i will do that, submit and link a reference to it.
<rbasak> I don't think pre-empting that with "they won't accept them" is acceptable unless there's some publicly available citation in support of that statement.
<rbasak> Thanks!
<rbasak> I'm not trying to create pain for you every time. If they reject once saying they don't support ppc64el, then that's fine. Every future time you need to patch, you could just copy and paste a link to that statement from them.
<niedbalski> rbasak, makes perfect sense to me.
<rbasak> Thanks. To be clearer, I should've said "saying they don't *accept patches for ppc64el-specific bugs*".
<rbasak> Since "support" is quite an overloaded term and doesn't necessarily mean that.
<niedbalski> rbasak, FTBFS seems related to compiler warnings that weren't enabled before (?), doesn't seems related to the patch itself, might be related a recent bump in gcc versions?
<rbasak> niedbalski: yeah. A gcc transition happened I hear :-/
<rbasak> I'm interested to hear what this channel think. In general I think that compiler warnings intended for upstreams and that don't represent real bugs being turned to errors isn't appropriate for distributions.
<niedbalski> rbasak, I am quite sure that this will break the build regardless of the patch, trying a pristine build.
<rbasak> niedbalski: agreed. Seems likely.
<rbasak> I think a minimal distro patch that stops warning->error for non-bugs is OK to fix this. The challenge is to make sure it doesn't overreach such that it accidentally suppresses real problems (now or in the future).
<rbasak> niedbalski: you might find https://launchpad.net/ubuntu/+source/squid3/3.5.23-5ubuntu1 helpful - ahasenack had to fix squid3 for similar reasons.
<niedbalski> rbasak, ok the pristine build of the package also fails , so any subsequent rebuild of percona will break.
<niedbalski> rbasak, what's your suggested approach for this?
<rbasak> niedbalski: sorry I pre-empted your test a bit. The last two lines I just said :)
<rbasak> slangasek: could you accept Xenial NEW certbot-related packages with your AA hat please? Or do you consider my SRU hat acceptable for that? No idea about actual ACLs but Launchpad's UI suggests that I can.
<rbasak> I've just double checked the certbot packages in Xenial's queue (both new and unapproved) and I think they're ready for proposed.
<rbasak> The ones in unapproved should go last.
<rbasak> (not strictly required but that we can back out more easily if the stuff in NEW is rejected)
<rbasak> So python-certbot, python-certbot-nginx and python-certbot-apache from NEW please.
<rbasak> bmw: sorry I've been slow in getting round to this. I need an Ubuntu archive admin to release the packages (as they're technically new due to the project rename). I hadn't requested it as I wanted to double check everything first - now done.
<rbasak> (see above)
<slangasek> rbasak: can you give me a list of the packages by name that are "certbot-related", or a bug # that has all the relevant bug tasks?  I'm fine policy-wise you using your SRU hat to accept new packages that are already in later series; however last I knew the acl didn't actually allow it
<slangasek> rbasak: (that's why folks who process kernel SRUs have an honorary AA bit)
<bmw> rbasak: no problem
<bmw> thanks for the update and moving things along
<kasperi> hi, is that gnome shell theme that was shown in didirocks blog coming to ubuntu 17.10?
<kasperi> https://didrocks.fr/2017/08/25/ubuntu-gnome-shell-in-artful-day-8/
<rbasak> slangasek: bug 1640978, for xenial new, just python-certbot, python-certbot-nginx and python-certbot-apache from NEW please.
<ubottu> bug 1640978 in python-letsencrypt (Ubuntu Xenial) "[SRU] Backport letsencrypt 0.14.2" [Undecided,In progress] https://launchpad.net/bugs/1640978
<niedbalski> rbasak, ok, I will address the build errors via a different LP bug (https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.6/+bug/1714554) , proposing a patch for suppressing the warning->errors inducted by the new gcc version, so you can continue working on bug 1657256 subsequently. is that ok for you?
<ubottu> Launchpad bug 1714554 in percona-xtradb-cluster-5.6 (Ubuntu) "percona-xtradb-cluster: FTBFS with gcc7." [Undecided,New]
<ubottu> bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<rbasak> bmw: BTW, did you mention that you had an amendment to the test script you suggested? Feel free to amend https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript, or alternatively feel free to maintain that somewhere else (eg. in an upstream repo). I intentionally didn't formally make that part of our exception so that it can be tweaked easily.
<rbasak> If you move it we can link to the new location instead.
<slangasek> rbasak: and you've already checked that the delta between later releases and what's uploaded to xenial is sane? (so I can just rubber stamp this?)
<rbasak> slangasek: yes. I scripted the generation of it, and nacc reviewed the generating for me.
<slangasek> rbasak: ok (and surprisingly, sru-review actually gave me a diff).  accepted
<rbasak> Thanks! FTR, the backport generation scripts are at https://anonscm.debian.org/git/letsencrypt/python-certbot.git/tree/?h=rbasak-guest/backport-tools
<bmw> rbasak: apparently I don't have permission to edit the TestScript page
<bmw> if we can land my edits and continue hosting it there that's preferable to me, otherwise, I can host it somewhere
<slangasek> bmw: edit rights should only require you to log in, no special privileges beyond that
<bmw> slangasek: I am logged in but at the top of the page it says "Immutable Page" and if I choose "Load" from the Action dropdown and try to upload a new version, it says I am not allowed
<slangasek> curious
<rbasak> bmw: you may need to belong to some special Launchpad group. I know there have been spam issues in the past.
<rbasak> bmw: would you mind asking in #canonical-sysadmin please? Give them your Launchpad ID, etc. I'll happily lurk there and help out if needed.
<rbasak> "special Launchpad group" -> "I'm not a spammer" group. If so I'm sure we can get you added :)
<bmw> will do!
<niedbalski> rbasak, ^^
<smoser> slangasek, i'd appreciate input on https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/330043
<smoser> theres 2 things there... a.) general support for functional dns in initramfs after dhcp
<smoser> b.) non-tested attempt to write netplan configs from the 'ipconfig' otuput files... thus affecting the real-root network configuration from the initramfs configuration, including dns.
<smoser> or xnox ^
<smoser> i have to run.
#ubuntu-devel 2017-09-02
<LocutusOfBorg> ricotz, hello, please merge poppler from Debian?
<ricotz> LocutusOfBorg, hi, will try to take a look later, although this could be combined with an update to 0.58.0
<LocutusOfBorg> thanks
<ricotz> LocutusOfBorg, https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/8225755/+listing-archive-extra
<LocutusOfBorg> ricotz, ffe needed?
<LocutusOfBorg> btw some patches should go in Debian
<LocutusOfBorg> e.g. CVE stuff, this is why I asked you :)
<ricotz> LocutusOfBorg, I would assume a ffe is required, those cve patches don't apply to debian while they are using openjpeg
<LocutusOfBorg> oh...ok
<xnox> cyphermox, slangasek -> i think one of you need to review https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/330043 as it's beyond me a bit.
<ricotz> LocutusOfBorg, I guess you want to take it from here
<juliank> Hmm launchpad links to https://keyserver.ubuntu.com:11371/, that fails with SSL protocol errors
<Unit193> Shouldn't be linking to https, where does it do that?
<juliank> right, link is http
<juliank> Heh, it's https everywhere i think
<juliank> could link to https on port 443, though, I  guess
#ubuntu-devel 2017-09-03
<LocutusOfBorg> slangasek, FYI I sync'd libfsoframework
<LocutusOfBorg> it still gives the build warnings, but debhelper is now less picky
<LocutusOfBorg> do you think it is worth a delta?
<Unit193> Even though FF is past, wouldn't tint2 be able to get in since it's not in any packageset?
<slangasek> LocutusOfBorg: I don't know anything about libfsoframework, and the changelog doesn't say anything about debhelper?
<LocutusOfBorg> years ago, something was looking at build log and making everything fail with some special warnings
<LocutusOfBorg> now this is not needed anymore, the build doesn't fail
<LocutusOfBorg> anyway, I opened a debian bug
<Unit193> LocutusOfBorg: Could I convince you to sync the tint2 leaf package? :)
<LocutusOfBorg> Unit193, you can't, unless you can convince me that it will build everywhere in Ubuntu
<LocutusOfBorg> since it doesn't build in debian on many archs
<Unit193> Erm, wow.  Yeah.
#ubuntu-devel 2018-08-27
<tsimonq2> slangasek, cjwatson: Is MoM broken? Last update was like 40  hours ago it seems...
<stanford_ai> I'm trying to run tensorflow on GPU, so I followed the instructions on the tensorflow official website, to install it with conda. But I get this error: ImportError: libcuda.so.1: cannot open shared object file: No such file or directory
<teward> stanford_ai: that's less a development issue and more of a support issue, you might wish to take that question to #ubuntu (namely, "how do I install CUDA so that I can use tensorflow on GPU?"_
<cjwatson> tsimonq2: yeah it's on my list
<cjwatson> there are a few things that break MoM and need manual intervention
<cjwatson> tsimonq2: I usually leave it until a weekday to sort out; but I've fixed the first thing that broke so it may work soon.  Failing that it'll keep emailing me until I fix it, so I'm not going to forget
<tsimonq2> cjwatson: ack, thanks.
<TxLiunx> hello anyone on that could respond. I am test my system. I had to reload everything.
<Unit193> TxLiunx: Perhaps you are seeking the support channel, #ubuntu?
<TxLiunx> thanks, just checking if hexchat is working
<smb> stgraber, not that I were wishing I had not (touched fan). But I saw this recently (indirectly while waiting on iproute2 tests), iirc only i386. And the test itself looks to succeed, its just sd_bus_open_system that suddenly comes via stderr
<smb> stgraber, the thing that is done around when the message is produced is a "systemd-resolve --status" call... the second attempt, so I read the log, is then successful
<acheronuk> merges.ubuntu.com has not updated since Saturday morning. who to query about that?
<Unit193> acheronuk: "yeah it's on my list" || "there are a few things that break MoM and need manual intervention" || "I usually leave it until a weekday to sort out; but I've fixed the first thing that broke so it may work soon. Failing that it'll keep emailing me until I fix it, so I'm not going to forget"
<acheronuk> Unit193: ok. thank you :)
<Unit193> (Scrollback here.)
<Unit193> acheronuk: Sure thing.
<acheronuk> Unit193: I thought I had scrolled back, but probably did it in #ubuntu-desktop in error or something
<seb128> hum, I think that's not possible but I'm asking in case. Can we query launchpad for tags using a regexp? e.g bugs tagged "verification-needed*"?
<jbicha> is there anyone besides Laney who can look into http://appstream.ubuntu.com/cosmic/ ? it hasn't updated in a week
<ricotz> seb128, https://bugs.launchpad.net/bugs/+bugs?field.tag=verification-needed
<ahasenack> when a package is known to not work with python 3.7, is this an acceptable change to d/control for us?
<ahasenack> -X-Python3-Version: >= 3.0
<ahasenack> +X-Python3-Version: >= 3.0, <= 3.6
<ahasenack> plus a link to the upstream bug tracking 3.7 progress
<seb128> ricotz, that was an example, I want to use tags like with a "keyword-<idnumber>" and script list those and extract the "idnumber". One way is to have 2 tags, one "keyword" to have a way to query then iterate over the tags from the corresponding bugs and do the split, but I was wondering if I can do without the second tag
<seb128> jbicha, slangasek iirc was mentioning the issue/a service that didn't get restarted after an outage or something
<seb128> jbicha, but I don't know if he/others have a knowledge of the service and how to handle it
<stgraber> smb: I fixed this issue by setting allow_stderr in the fan package
<stgraber> smb: so if systemd feels like being noisy, that won't cause a failure anymore
<smb> stgraber, Yep I saw that after replying. I pulled your change into the related git repo already
<stgraber> smb: thanks!
<slangasek> seb128: sorry, it wasn't me mentioning it, I know nothing about appstream.u.c
<sil2100> oSoMoN: hey!
<sil2100> oSoMoN: remind me - is libreoffice-l10n basically always just a mirror of libreoffice?
<oSoMoN> sil2100, hey
<oSoMoN> sil2100, both packages are built from the same sources
<oSoMoN> they are separate packages because at some point in time LP wasn't able to cope with everything together
<sil2100> oSoMoN: since I'm looking at libreoffice-l10n for xenial in the SRU queue (for the trigger changes) and there's a lot of changes besides the  trigger change, as the uploaded libreoffice-l10n follows what's was in libreoffice
<oSoMoN> not sure if this is still the case
<sil2100> While no libreoffice-l10n uploads have been done for a while there
<sil2100> Ok
<tjaalton> xnox: hi, i'm testing 389-ds on cosmic, and noticed that the configured instance isn't started after a reboot, in fact systemd somehow doesn't even know about it, although everything should be the same as before reboot
<sil2100> oSoMoN: it's a bit tricky since now basically if I accept the trigger changes upload to xenial, I'd have to 'assume' that all the libreoffice security updates that are pulled in with this upload have been successfully tested for the libreoffice-l10n package as well
<oSoMoN> sil2100, yeah, I think IÂ talked to bdmurray_ about it a couple of weeks ago, strictly speaking the libreoffice-l10n update is not needed as there won't be version conflicts with a newer libreoffice, but I uploaded it for consistency, so it's up to you, feel free to reject if you don't want it
<sil2100> oSoMoN: if you don't mind I'd reject it personally, since I have no idea if in some freak accident the -l10n generated binaries will suddenly go crazy on the missed security changes
<sil2100> Certainly not something I'd like to get in without verification
<oSoMoN> sil2100, that's absolutely fine by me
<oSoMoN> better to be on the safe side
<sil2100> (and there are no SRU tracking bugs for those as those are security uploads)
<sil2100> oSoMoN: thanks!
<tjaalton> xnox: correction, it's just not started on boot
<seb128> slangasek, sorry, wrong memory, indeed it was not you https://irclogs.ubuntu.com/2018/08/22/%23ubuntu-release.html#t08:47
<seb128> slangasek, do you know if anyone in foundations has knowledge of that service? nobody does in desktop and Laney is still away for a full week
<slangasek> seb128: no idea, sorry
<seb128> :/
<xnox> tjaalton, fun. i have no idea about 389-ds - can you open a detailed bug report or drop me an email?
<xnox> tjaalton, such that i could help investigating it....
<tjaalton> xnox: sure
<mwhudson> hah er i guess https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1789170 translates to "we use systemd now"?
<ubottu> Launchpad bug 1789170 in console-setup (Ubuntu) "/etc/default/console-setup doesn't affect number of TTY's" [Undecided,New]
#ubuntu-devel 2018-08-28
<abeato> sil2100, hey https://github.com/CanonicalLtd/ubuntu-image/pull/155 still needs another round :)
<jbicha> coreycb: this change got accidentally dropped when you merged imagemagick: https://launchpadlibrarian.net/363532898/imagemagick_8%3A6.9.7.4+dfsg-16ubuntu5_8%3A6.9.7.4+dfsg-16ubuntu6.diff.gz
<coreycb> jbicha: i'll take a look shortly. sorry about that.
<jbicha> coreycb: no problem, I tried to push that change into Debian but I wasn't able to convince the maintainer why we wanted it
<slangasek> kees, stgraber: no TB meeting today?
<kees> slangasek: I'm conferencing in vancouver
<slangasek> ok
<slangasek> seb128: are you as sick of this ding autopkgtest failure as I am?
<seb128> slangasek, yes! looks like you got a sucess in your most recent try though :)
<slangasek> seb128: yeah except that's the baseline test, which fails to confirm that this is an ignorable regression in the release pocket :/
<seb128> :/
<jbicha> slangasek: how about https://autopkgtest.ubuntu.com/packages/u/udisks2/cosmic/s390x ? ð¢
<slangasek> jbicha: good news, that one *did* fail a baseline retest
<infinity> slangasek: I think we might need to talk about an actual policy about flapping tests: that is, they should be either fixed, disabled, or hinted.  Retrying endlessly to sometimes get a thing we think might be a correct result isn't sane QA or CI.
<slangasek> infinity: perhaps you would like to weigh in on my proposal that britney should automatically reset the gate whenever a retest against the release pocket fails
<infinity> (And, worse, ignoring a flapping test, while we hope it means we're ignoring a bad testsuite, often means we're ignoring bad code that the test is rightly finding by accident, due to external fuzz)
<seb128> jbicha, we should probably skip that one again :/
<infinity> That is, retrying until it passes is a false sense of security.
<seb128> the test that was always failed got fixed but the other ones are still flacky
<slangasek> infinity: there is lots of bad code that isn't tested and the bad code that triggers flaky tests is not per se more important to pay attention to than other bad code
<infinity> slangasek: I don't like the "automated" part of that proposal, cause it then implies that no human will give any thought to the how or the why of the regression.
<slangasek> infinity: it only means that humans thinking about the regressions are decoupled from the actual transitioning
<infinity> slangasek: Your thing in theory, mine in practice, I suspect.
<infinity> Without gates, people's carefactor is much lower.  Whether the gate is britney or having to justify themselves to a release member or whatever.
<slangasek> infinity: the carefactor SHOULD BE MUCH LOWER because the regressions have already happened in the release pocket
<slangasek> instead, right now it's a waste of release team time to manually hint
<slangasek> automate that; and deal with questions of adequately resourcing efforts to fix autopkgtests elsewhere
<infinity> slangasek: One could make the exact inverse argument that carefactor should be higher because we somehow screwed up and let a bug slip out of proposed. :P
<infinity> All of proposed can be as buggy as can be, but when thing start regressing in the release pocket, quality is going backward.
<infinity> slangasek: And if it's just about not caring about the devel series until closer to release, s/release/updates/ and make the same arguments.  A regression noticed in updates should be a short stop the line event to investigate the severity and determine a course of action.  It doesn't need to be actioned immediately if it's determined to be not a big deal (hint it and put it on someone's TODO for when-never), but it's worth the 5 minutes of ...
<infinity> ... talking about it.
<slangasek> infinity: except when the test regressed because it was a bad test to begin with (flaky); or when the infrastructure changed in a way that invalidates the test but has not regressed the code; or we are treating as "regressed" the case of a failure in a test that was previously not run (due to testbed restrictions and then we moved the testbed), and now runs and fails; or the test is dumb and
<slangasek> embeds a pre-generated SSL certificate with an expiration date
<infinity> slangasek: I argue that the round-trip with the release (or in the updates case, SRU) team triggers that 5 minutes line stoppage and conversation.
<infinity> slangasek: Yes, there are cases where the investigation immediately goes to "derp, this isn't something we care about", but a computer can't make that call.
<slangasek> infinity: you do understand the geometrically-scaling impact of each of these 5-minute conversations on library transitions, right?
<infinity> slangasek: I much preferred the other proposal to allow a reset-baseline style hint, so we can have that discussion ONCE, but then not have to keep bumping hints for eternity.
<fo0bar> infinity: BTW, you just caused all of IS (and perhaps other groups) to check this channel :)
<fo0bar> do not invoke the holy name of STL in vain
<infinity> fo0bar: You're not the only people in the world who use the term, perhaps you could adjust your filters to only scan #is and #is-outage (which is where I yell it when I want you).
<infinity> fo0bar: Also, insert Nelson "ha ha" clip here?
<fo0bar> infinity: there are a few other channels, but yeah, just giving you grief
<infinity> fo0bar: Yeah, #canonical-sysadmin also came to mind after I hit [enter].
<infinity> fo0bar: Anyhow, grief registered and returned. ;)
<xnox> slangasek, i'd like to see that "this all-release-pocket fail" + "this all-proposed-pocket fail" cause we have things migrating that do pass in all-proposed due to incomplete deps/ordering.
<xnox> for the case where "this" is only published in release pocket for example.
<xnox> slangasek, i do not want this automated, no. that feels wrong.
<xnox> slangasek, i feel it should be "force-always-failed package/version" to set the threshold of where we count as always failed.
<stgraber> slangasek: same as kees
<xnox> (well usual syntax to specify arch/min-ver-barrier
<xnox> )
#ubuntu-devel 2018-08-29
<seb128> is there an equivalent to https://code.launchpad.net/~team/+activereviews (which is bzr) for git?
<cjwatson> seb128: That URL includes both.
<seb128> oh, DOH
<seb128> cjwatson, thanks ;)
<cjwatson> For instance, look at https://code.launchpad.net/~ubuntu-installer/+activereviews
<cjwatson> np
<seb128> cjwatson, since the "summary" page is different I was trying to look for a reference on https://code.launchpad.net/~ubuntu-desktop/+git
<cjwatson> seb128: We've been fixing a few UI bugs like this recently, though I think not that particular one yet - that's https://bugs.launchpad.net/launchpad/+bug/1594772
<ubottu> Launchpad bug 1594772 in Launchpad itself ""Active reviews" link does not appear on git repository page" [Low,Triaged]
<cjwatson> (I think William's comment there is based on a misreading of the bug report, though)
<seb128> cjwatson, thx, that's basically what confused me as well :)
<sil2100> abeato: hey! I'll try to take another look at the PR today
<seb128> cyphermox, hey, did you see my ping the other day about updating modemmanager to 1.8.0?
<cyphermox> seb128: I had not
<cyphermox> feel free to update it?
<seb128> cyphermox, I'm not the maintainer :p I guess it means you are too busy/not interested, I can gtry having a look from our 7.990 to 8.0 it might not be that difficult :) I don't have any hardware to test it though
<cyphermox> seb128: indeed, I don't have time to look at it, but 1.7.990 to 1.8.0 should be "tiny", just about no change given that 990 means a pre-release for 1.8.0.
<seb128> cyphermox, k, well let me have a look and maybe come back to you for sponsoring :)
<cyphermox> sponsoring?
<cyphermox> ok, clearly you're talking about debian now, but I can't upload myself there.
<seb128> cyphermox, well, my idea was to update to Debian first and then merge in Ubuntu
<seb128> cyphermox, https://packages.qa.debian.org/m/modemmanager.html lists you as maintainer which is why I asked you
<cyphermox> yep
<cyphermox> sync please
<cyphermox> ugh
<cyphermox> seb128: I'll do it
<cyphermox> tonight, maybe
<seb128> cyphermox, thx :)
<ginggs> tkamppeter: Hi! I just wanted to check that you were receiving mails about Debian bug #907493
<ubottu> Debian bug 907493 in src:ghostscript, src:cups "ghostscript breaks cups autopkgtest: test times out" [Serious,Open] http://bugs.debian.org/907493
#ubuntu-devel 2018-08-30
 * tsimonq2 is working on a small little project...
<tsimonq2> https://git.launchpad.net/~ubuntu-dev/+git/pm-stats/
<tsimonq2> https://pmstats.lubuntu.me/
<tsimonq2> So far I consider my code "hacky and horrible" because it apparently decides using file storage is a good idea. :P
<xnox> tsimonq2, hmm.... we do have private internal dashboard on that.... it's done with grafana dashboard + prometheus backend.
<xnox> slangasek, can we publish any parts of our dashboard publically?
<xnox> or like mirror/sync it?
<tsimonq2> xnox: Don't worry, this didn't take too long. ;)
<tsimonq2> xnox: If that can be publicised, cool, but if it can't I intend on writing my own clone that is. :P
<xnox> tsimonq2, well, it all lives in a private instance. most things are based on public data which is crapped. but there are also internal-infra stats which are non-public.
<xnox> (ie. monitors health of internal infra, our managed mirrors, etc.)
<xnox> not sure if it can be made public, due to possible data leaks
<xnox> foundations piggy-backed on that infra, cause it was nice and easy.
<Unit193> Sure, but private doesn't really help us, and gives you a slight edge on us. :>
<tsimonq2> xnox: Is there any hope of mirroring on a separate instance?
<tsimonq2> Right, I want to crunch some of my own numbers.
<xnox> no idea.
<tsimonq2> xnox: So who does? :P
<xnox> i mean it has the p-m stats, which is like one graph. nothing else is of use publically i don't think.
<tsimonq2> That's all I care about, the public stuff. ;)
<tsimonq2> xnox: Specifically what I have in mind is statistics similar to http://people.ubuntuwire.org/~stefanor/ubuntu-activity/ but with more -proposed-focused data points like why things are blocked, how quick they're resolved, a per-person breakdown of packages, etc.
<xnox> yeah, that would be nice.
<xnox> we have none of that.
<tsimonq2> So, since the data is public, would you be able to give me/the channel a screenshot or *something* showing only the public data?
<tsimonq2> It would be cool to see what exactly you get to look at. :)
<xnox> omg, i'm such a slacker, i'm not in top 10, i'm #11
<tsimonq2> hehe
<xnox> jamespage has been doing too many uploads =)))))
<tsimonq2> Unfortunately there's two major bugs (well three, if you include the fact that it uses poor web design); people like LocutusOfBorg have "Gianfranco Costamanga" and "LocutusOfBorg" in separate entries, and the "who works for Canonical?" graph is not only not robust, the actual data for that hasn't been updated in years.
<tsimonq2> Last time I did a local run, most uploads are done by Canonical employees, pretty much always.
<xnox> who works for canonical is very hard to track. and that info is not public really.
<xnox> also too much churn in people leaving, rejoining, working on non-work stuff with work emails, and vice versa.
<tsimonq2> How it guesses is based on members of ~not-canonical and people who use canonical.com email addresses in debian/changelog.
<tsimonq2> So I know it can't always be accurate, but "somewhat accurate" is better than nothing.
<tsimonq2> I've separately written at least three scripts to collect some or all of this data individually, for my own curiosity.
<tsimonq2> Here's one that totals uploads per person in -proposed: http://paste.ubuntu.com/p/2rHxrnQSxP/
<tsimonq2> So I have all of this code lying around in different places, I just want to finally consolidate it and make it into something useful. ;)
<slangasek> xnox: I would like those grafana bits to be public but it would involve work
<mwhudson> hey um i'm working on some of the same things currently...
<tsimonq2> mwhudson: Got links to your own scripts?
<tsimonq2> We can probably take the best parts of both of our scripts and merge, or something...
<tsimonq2> I doubt you're the only one who also has scripts...
<abeato> sil2100, thanks, will repush shortly
<mwhudson> tsimonq2: i haven't started working on them at all yet
<tsimonq2> mwhudson: ah
<mwhudson> there is a trello card with my face on it :)
<mwhudson> i see your stuff isn't exactly super sophisticated either :)
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> "It Works"
<mwhudson> well sure
<tsimonq2> mwhudson: I also don't have access to internal Canonical Foundations Trello, so I'm curious to see what you're actually assigned to. :P
<mwhudson> it's making a report that has a per-team view of packages in proposed
<tsimonq2> Oh, that would be cool.
<tsimonq2> Team in terms of Canonical teams, packageset teams...?
<mwhudson> i'm not actually sure :)
<mwhudson> i need to ask someone about that
<tsimonq2> ah :D
<mwhudson> ah actually reading the card the idea is to do it via subscriptions
<tsimonq2> The latter would be useful, and if I do continue writing things from scratch, I could tackle, but I don't know about Canonically things... :P
<tsimonq2> ohhh
<tsimonq2> At first that sounds like bug 1683749 but we're talking adding support to Britney for subscriptions?
<ubottu> bug 1683749 in britney "Please list bugs tagged as "update-excuse" on update_excuses" [Undecided,Confirmed] https://launchpad.net/bugs/1683749
<tsimonq2> That would be *sweet*.
<mwhudson> um no, more like show packages that are in proposed where e.g. ~ubuntu-desktop is subscribed to bugs on the package
<tsimonq2> oh :P
<tsimonq2> So a little less overengineering; got it. :)
<mwhudson> at least that's my reading of it
<mwhudson> touching britney at all is definitely out of scope :)
<tsimonq2> Internal Canonical Trello cards are internal, so I guess I'll have to trust your interpretation. :P
<mwhudson> Have a different page that lists only packages with a team subscribed to them and then it is broken into sections for different teams.
<mwhudson> Minimum details to include for each team:
<mwhudson>  - name of package
<mwhudson>  - age in proposed
<mwhudson>  - is it a candidate
<mwhudson> there you go :)
<tsimonq2> ah :)
<tsimonq2> mwhudson: So something like how the sponsorship queue works, ish?
<mwhudson> yes i guess so
<tsimonq2> I don't want to steal your thunder if that's your obligation working for Canonical, but that's probably doable with Not A Lot Of Python...
<tsimonq2> Anyway, thanks mwhudson, I should probably look at going to bed :)
<mwhudson> yeah it shouldn't be a lot of work really
<mwhudson> tsimonq2: good night
<abeato> sil2100, I have updated https://github.com/CanonicalLtd/ubuntu-image/pull/155
<abeato> tests for xenial passing
<sil2100> abeato: excellent, let me take a look and merge it in in a minute
<sil2100> abeato: thanks o/
<abeato> np, happy to get it merged :)
<sil2100> abeato: (currently bionic and cosmic snap.sh tests are likely to fail due to the nature of classic snaps, glibc mismatch and how we had to build it in the end)
<abeato> sil2100, I have created https://github.com/CanonicalLtd/ubuntu-image/pull/160 to follow-up the discussion on grub/classic
<doko> seb128: did you forward the issues that sarnold pointed out in https://bugs.launchpad.net/ubuntu/+source/libfprint/+bug/1745454 ?
<ubottu> Launchpad bug 1745454 in libfprint (Ubuntu) "[MIR] libfprint" [High,Fix committed]
<doko> and please don't set MIR issues to committed state yourself
<seb128> doko, he did and upstream picked up some others as well, see https://gitlab.freedesktop.org/libfprint/libfprint/issues
<seb128> doko, sorry, I though that security team ack meant it was good to go and that they just forgot to update the status
<seb128> doko, it had been sitting like that untouched for a while I was trying to get things unblocked...
<seb128> doko, we need to sort out the MIR situation at some point, we need more people doing revie. we keep having features missing full cycles because MIR just don't move (e.g https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1770877)
<ubottu> Launchpad bug 1770877 in tracker-miners (Ubuntu) "[MIR] tracker-miners" [Undecided,New]
<doko> coreycb: https://bugs.launchpad.net/ubuntu/+source/zvmcloudconnector/+bug/1787640/comments/1
<ubottu> Launchpad bug 1787640 in zvmcloudconnector (Ubuntu) "[MIR] zvmcloudconnector" [Undecided,New]
<seb128> doko, so what's the status for libfprintf/fprinfd, do you want want to change the status back to something else? they are currentlu on component-msimatch since before ff can we get them promoted and that mismatch resolved?
<doko> I'll look at these today
<seb128> thx
<mwhudson> tsimonq2: http://people.canonical.com/~mwh/team-summary.html
<tjaalton> "canidate"
<seb128> mwhudson, interesting page, how is it generated? do you have the script/source available somewhere?
<mwhudson> seb128: it's generated by a terrible terrible python script that i've been writing in the last hour or so
<mwhudson> tjaalton: heh thanks
<didrocks> mwhudson: output very useful info for a terrible script! (btw s/canidate/candidate/)
<seb128> didrocks, timo pointed that typo a few lines earlier here :)
<seb128> mwhudson, I would still welcome you script if you want to email me? I would like to consolidate similar info on http://people.canonical.com/~platform/desktop/desktop-packages.html which is one of the report desktop is using
<didrocks> ok, I must admit I only backlogged the last few lines, not the paragraph before :)
<seb128> trying to turn into a sort of dashboard
<mwhudson> seb128: of course i've hacked more and broken it again :)
<mwhudson> seb128: i'll push it to lp before i go to bed and send you the url
<mwhudson> (i'm going to be working on it a bit more over the next week)
<seb128> thx
<seb128> would be nice to consolidate those reports/dashboards a bit
<mwhudson> seb128: https://git.launchpad.net/~mwhudson/+git/pm-stats/
<mwhudson> updated http://people.canonical.com/~mwh/team-summary.html too
<seb128> mwhudson, thx
<mwhudson> seb128: dashboard proliferation is a bit of a problem, hope i'm not making this worse!
<jbicha> slashd: are you interesting in backporting https://launchpad.net/ubuntu/+source/gdm3/3.28.2-0ubuntu1.4 to xenial?
<jbicha> have you ever done security updates before?
<coreycb> doko: uploaded a new zvmcloudconnector with your requested change
<bdmurray> didrocks: Hi, did you see this comment? https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1778694/comments/8
<ubottu> Launchpad bug 1778694 in apport (Ubuntu Bionic) "In autoreport mode in whoopsie-preferences API, reports are not sent by whoopsie" [High,Fix committed]
<didrocks> bdmurray: yes, I didn't understand about your question, it's declaring:
<didrocks> [Install]
<didrocks> WantedBy=paths.target
<didrocks> so, it's started on all systems, via systemd
<didrocks> as this target should be always be ran
<didrocks> if it's not, it's a systemd bug I guess
<didrocks> bdmurray: if it's only when you upgrade the package, indeed, I think nothing is starting it until next reboot
<didrocks> which was an issue only during bionic sru upgrade (until next reboot)
<didrocks> or new installs
<didrocks> we can force starting it in cosmic if you feel that being necessary
<didrocks> (in the postinst script)
<didrocks> but I would rather investigate why the systemd debhelper helper doesn't do it by default
<didrocks> sounds like the fix should be there (and so more on systemd debian/ubuntu maintainers)
<didrocks> rather than workaround that around in one package
<bdmurray> My point is that in gnome-control-center when you choose automatic the service should be started so people don't keep getting crash dialogs.
<bdmurray> Isn't that the goal?
<didrocks> no, the .path should be always activated
<didrocks> unconditionnaly
<didrocks> then, the script check for the automated report condition
<didrocks> sounds like the systemd postinst helpers should do that anyway (IMHO)
 * didrocks needs to step out for a bit, bbl
<doko> coreycb: I had it already accepted. but I know we changed the defaults in other packages as well
<coreycb> doko: fwiw we're still defaulting the core openstack packages to py2 in cosmic
<coreycb> doko: we're planning to get function testing done in cosmic and flip them to default to py3 in D.
<doko> coreycb: ugh, because we want to switch to 3.7 when D opens ...
<coreycb> doko: we've just not had the time to function test py3
<coreycb> jamespage: fyi ^
<www2> hi i wand to report that liblilv have problems with multi architect setups (x86/x86-64) a spesial with gstreamer-bad
<nacc> !bug | www2
<ubottu> www2: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<GunnarHj> Hi slangasek, did you receive an email from sil2100 the other day about bug #1778041? You input in the matter would be much appreciated.
<ubottu> bug 1778041 in freshplayerplugin (Ubuntu Xenial) "browser-plugin-freshplayer-pepperflash broken" [High,In progress] https://launchpad.net/bugs/1778041
<slangasek> GunnarHj: I did not
<slangasek> GunnarHj: correction, I found it now
<GunnarHj> slangasek: Ok.
<tsimonq2> mwhudson: ooh
<GunnarHj> slangasek: Thanks for your reply. I think it's sufficient guidance for sil2100 to decide on those pending SRUs.
<scientes> is there a reason gnome xorg doesn't work?
<nacc> scientes: this is not a support channel
<nacc> scientes: you want #ubuntu
<scientes> oh my bad ubuntu+1
<nacc> or that
<bluesabre> Is there any way to blacklist a package from showing on gnome-software? For example, exo-utils (part of Xfce) would never be installed directly and can cripple the desktop when uninstalled (see https://bugzilla.xfce.org/show_bug.cgi?id=14588)
<ubottu> bugzilla.xfce.org bug 14588 in General "Deleting "Mail Reader" or "Web Browser" crashes the computer" [Critical,New]
#ubuntu-devel 2018-08-31
<jbicha> bluesabre: https://wiki.debian.org/AppStream/Guidelines#How_to_exclude_.desktop_files_from_the_metadata
<jbicha> alternatively, you can use https://codesearch.debian.net/search?q=compulsory_for_desktop&perpkg=1 but that won't help if you have users who install other desktops, log in, and then want to remove apps, & then log back in to Xfce
<jbicha> note that appstream.ubuntu.com hasn't been updating its metadata recently so you'll have to wait until that works again for your change to take effect
<bluesabre> jbicha: thanks for the quick and detailed response!
<jibel> wxl, hi, could you have a look at bug 1789879 ?
<ubottu> bug 1789879 in msttcorefonts (Ubuntu) "Installation error with ttf-mscorefonts-installer_3.7ubuntu3_all.deb" [Critical,Confirmed] https://launchpad.net/bugs/1789879
<acheronuk> tsimonq2: ^^
 * acheronuk hides from that merge
<bluesabre> infinity: If you have a moment, can you please take a look at the xubuntu-core debian-cd/livecd-rootfs/ubuntu-cdimage merges, https://code.launchpad.net/~xubuntu-dev/debian-cd/xubuntu-base/+merge/347414 ?
<ginggs> jibel, wxl: Do we really need the ubuntu delta for msttcorefonts? In my experience, it has been broken in Ubuntu for a long time.  I've been installing the binary from Debian (as suggested in one of the LP bug reports).
<seb128> slangasek, hey, who would be the right person to look at the netplan autopkgtest failing with the new network-manager version (and blocking it in cosmic-proposed)
<slangasek> seb128: I have flagged it to cyphermox who has the most context, but he's otherwise busy this week.  I don't want to ignore those failures, netplan autopkgtests have picked up real regressions in other packages (including systemd)
<wxl> ginggs: jibel: Debian has taken portions of the Ubuntu delta but can't take them all as they depend upon update-notifier which they can't guarantee (?) is present in Debian. I attempted to retain those pieces that were relevant to us while merging with upstream changes. I think it might be better, in retrospect, to simply try to start fresh with 3.7 and fix only what's broken with it.
<jibel> wxl, yeah. As it is the postinst and update-ms-fonts in Ubuntu are not compatible
<wxl> jibel: i'll work on overhauling it tonight.
<seb128> slangasek, thx, and yeah I agree on not skipping over the failure
<bdmurray> Anybody have an idea about bug 1743216? The ProcCmdline is rather strange
<ubottu> bug 1743216 in perl (Ubuntu) "perl crashed with SIGABRT in _dbus_abort()" [High,Confirmed] https://launchpad.net/bugs/1743216
<slangasek> bdmurray: impressive, any of those substrings match a grep -r /usr on a default desktop?
<slangasek> bdmurray: maybe only budgie / xubuntu, given the last (and therefore most current, non-prerelease) dupe?
<bdmurray> slangasek: xdg-screensaver
<slangasek> fun
<sarnold> wow
#ubuntu-devel 2018-09-01
<TJ-> Is there a reason rp-pppoe has not been synced from Debian since Utopic 3.11-0 (2014-08-13) ? The current version in Cosmic and the LTSes is way behind upstream, and Debian 3.12-1 (2016-06-22) ?
<ginggs> TJ-: I guess nobody has looked at whether the delta can be dropped. please request a sync with the requestsync tool https://wiki.ubuntu.com/SyncRequestProcess
<TJ-> Who's responsible for the Software Centre database? We've a user reporting the entry titled "Desktop Sharing" isn't that at all, it's actually installing unity-control-center :s
<Unit193> http://paste.openstack.org/show/5dkw1p2K6IcwytUDSC5j would be fantastic to get in, but somehow I don't think it's going to.
#ubuntu-devel 2018-09-02
<Unit193> Also I overtrimmed: http://paste.openstack.org/show/TI79YnBkwTk9dcRyW7SR httplib2 doesn't support SNI in Ubuntu, this is what is used in backportpackage/etc, sooo... The "quick fix" is to use plain text, which isn't a good workaround.  This is far better.
<Unit193> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907278#10 see also.
<ubottu> Debian bug 907278 in python-httplib2 "[python-httplib2] Certificate verification fails without apparent reason for some CAs" [Serious,Open]
<Ulfalizer> will 18.10 have python 3.7? still 3.6 on the development branch.
<juliank> Ulfalizer: 3.7 is a supported version as well
<juliank> Ulfalizer: some packages don't have 3.7 support yet, that's tracked in https://people.canonical.com/~ubuntu-archive/transitions/html/python3.7-add.html
<Ulfalizer> ah, alright. makes sense. thanks.
<mwhudson> yeah not going to make 3.7 the default for cosmic
#ubuntu-devel 2019-08-26
<juliank> I'm super confused by ubuntu-release-upgrader in xenial
<juliank> the tests are passing on autopkgtest.u.v
<juliank> s/v$/c/
<juliank> Yet, when running locally for my SRU, pep8 is failing everywhere
<juliank> pep8 version is the same though, and most code did not change (just s/http/https)
<juliank> I guess I'll just upload it anyway, as something must be going wrong locally
<juliank> oh, hmm there are a lot of symlinks
<ahasenack> hi, I need some help in interpreting update_output.txt for iptables,
<ahasenack> skipped: iptables (86, 158, 16)
<ahasenack>     got: 939+0: a-3:a-2:a-922:i-8:p-2:s-2
<ahasenack> and a huge list of packages
<ahasenack> I checked some packages again, but they all seem to have been built in proposed with the new iptables already
<ahasenack> keepalived, miniupnpd, strongswan*
<ahasenack> systemd too
 * ahasenack checks armhf
<ahasenack> hm, not easily done, I don't have access to armhf
<ahasenack> ah, found it
<ahasenack> iptables-nftables-compat
<ahasenack> no that comes from iptables itself
<ahasenack> ah, was dropped
<ahasenack> it looks line in armhf some of these packages weren't rebuilt at the right time
<kfunk> hey ho. just upgraded to 19.10 and I was wondering what the upgrade path re. settings/etc. regarding the Chromium DEB->Snap switch is? -- problem right now: I managed to copy over my original chromium settings dir from ~/.config to ~/snap. but now my saved passwords are gone. running KDE/Plasma Desktop...
<kfunk> any idea how to fix this?
<kfunk> I guess I'll need to copy over some secret key or sth, but I guess I can't be the only one who got bit by this...
<RikMills> kfunk: did you do this? https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987
<kfunk> RikMills: that's what I did (after digging a bit through my $HOME), but that didn't "import" my passwords.
<kfunk> I guess that Chromium is no longer able to talk to KWallet or sth; as it also mentions a problem with the Plasma Browser Integration host
<RikMills> sadly doesn't look like the chromium uploader (oSoMoN) is in here at the moment
<kfunk> I'm debugging it a bit, but given Chromium's complexity this isn't going to be fun
<kfunk> oh, okay. so a colleague of mine helped. the fix seems to be running: snap connect chromium:password-manager-service :password-manager-service
<kfunk> also now found: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1832786
<ubottu> Launchpad bug 1832786 in chromium-browser (Ubuntu) "[snap] chromium-browser ignores system password store" [Undecided,Incomplete]
<juliank> bdmurray: ^^ about 3 hours ago, I mentioned that I can't get ubuntu-release-upgrader's pep8 check to pass in xenial locally for my SRU
<juliank> bdmurray: I'm confused by that, because it seems passing on autopkgtest.u.c
<juliank> bdmurray: do you happen to have an idea what's going on there? It seems it's failing on files that are symlinks from python-apt and apt-clone
 * juliank could just upload it and then we'll see if it fails there too, but not sure
<juliank> Oh, it seems it's running in a built tree, maybe that's a difference
<juliank> it's always good to just let problems rest for a few hours and get back to them
<juliank> uploaded.
<bdmurray> juliank: great, I'm glad I could help ;-)
<The_LoudSpeaker> just curious, is there any record of how many ubuntu users are present worldwide? I mean something like ____ number of people actively use ubuntu.
<genii> There is no definitive way to establish number of users
<The_LoudSpeaker> atleast no of downloads of latest lts ?
<The_LoudSpeaker> or 19.04 ?
<alkisg> Since 18.10, Ubuntu's initramfs-tools switched to calling dhclient instead of ipconfig. But dhclient-script is broken and generates invalid net-eth0.conf files, calls chown --reference= which isn't supported by busybox etc.
<alkisg> I reported this in https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965; I can send code if someone's going to commit it; or, if there are thoughts to switch back to ipconfig, then everything will work again...
<ubottu> Launchpad bug 1840965 in isc-dhcp (Ubuntu) "dhclient initramfs code writes invalid net-eth0.conf" [Undecided,New]
<vorlon> alkisg: we definitely don't want to revert to ipconfig.  Patches certainly welcome
<rcj> Could I get someone to nominate tracks on a livecd-rootfs SRU? LP: #1837254  I need disco, bionic, and xenial.
<ubottu> Launchpad bug 1837254 in livecd-rootfs (Ubuntu) "ubuntu-cpc parallel builds produce unused files" [Undecided,Fix released] https://launchpad.net/bugs/1837254
<sarnold> rcj: done
<rcj> Thank you sarnold
<vorlon> cjwatson: for your awareness, /usr/sbin/update-initramfs appears to be broken in the cpc-produced launchpad-buildd chroots https://launchpad.net/ubuntu/+source/diffoscope/121/+build/17428383
<mwhudson> oops
#ubuntu-devel 2019-08-27
<mwhudson> mwhudson@ringil:/opt/opensource/deb/golang-github-prometheus-common-0+git20181119.b36ad28$ openssl x509 -enddate -noout -in ./config/testdata/barney.crt
<mwhudson> notAfter=Jul 13 04:02:47 2019 GMT
<mwhudson> "lol"
<mwhudson> also lol https://github.com/prometheus/common/commit/a82f4c12f983cc2649298185f296632953e50d3e
<alkisg> vorlon: thank you, I will send a patch later on today
<mwhudson> i think i convinced myself at the time that the chown --reference thing is harmless in this context
<alkisg> mwhudson: sure, the chmod --reference produces an annoying message but it doesn't hurt much, but the unquoted values do break dns etc
<mwhudson> alkisg: yeah that sucks
<mwhudson> i presume ipconfig handles it by ignoring all but the first provided nameserver...
<alkisg> It supports up to 2
<alkisg> I'll do the same in the patch and discard more than 2
<mwhudson> ah i see you're right
<alkisg> Is apt source from eoan the correct starting point for a diff? Or is there a launchpad tree that I should clone?
<alkisg> https://git.launchpad.net/ubuntu/+source/isc-dhcp => Age: 2019-03-13...
<mwhudson> alkisg: seems right
<alkisg> mwhudson, vorlon, I'm about to propose this in the bug report, unless you see something you don't like: https://termbin.com/w0lf
<alkisg> I removed some "ifs" as ipconfig wrote empty values in these cases, so let's do the same
<mwhudson> alkisg: er can you paste a diff instead?
<alkisg> All the lines have changed, but sure :D
<mwhudson> alkisg: ah haha
<alkisg> I removed the constant >>file
<alkisg> And merged in into a single one
<mwhudson> a git merge proposal in launchpad would be even better
<alkisg> mwhudson: could you help me with a link there?
<alkisg> I can clone and commit to https://git.launchpad.net/ubuntu/+source/isc-dhcp, but where is the merge filed?
 * alkisg reads https://dev.launchpad.net/UsingMergeProposals ...
<alkisg> (hope it applies to git too)
<mwhudson> alkisg: there is also https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow but i think that's mostly focused on merges rather than general bugfixing
<mwhudson> alkisg: a diff is also fine, i can always do the proposal bit :)
 * mwhudson has to run now
 * alkisg doesn't have snapd, can't use git-ubuntu-clone... oh well sending a diff
<oSoMoN> mwhudson, are you around? bug #1841191 is breaking firefox/thunderbird builds on eoan, and it would just be a matter of backporting an upstream commit
<ubottu> bug 1841191 in cargo (Ubuntu) ""error: failed to acquire package cache lock" in sbuild" [Undecided,New] https://launchpad.net/bugs/1841191
<cjwatson> vorlon: Hm, odd.
<seb128> what keyring is syncpackage using? I'm trying to do a sync that give me a "Signature could not be verified" error
<cjwatson> It's buried in python-debian, but I think it's debian-keyring
<rbasak> alkisg: you don't need the tool. Just clone the repo from the URL directly
<alkisg> rbasak: where would I file the merge request? I wasn't able to find the URL for that, in the few minutes I looked for it...
<rbasak> alkisg: https://help.launchpad.net/Code/Git#Repository_URLs
<alkisg> rbasak: thank you
<rbasak> alkisg: once you've pushed, use https://code.launchpad.net/~ to find your branch and file the MP
<LocutusOfBorg> hello vorlon I think a cryptsetup merge might be beneficial for 32bit archs?
<rbasak> Actually it might need to be https://code.launchpad.net/~/+git
 * alkisg tests...
<alkisg> Not sure if I read the docs right, but `git clone https://code.launchpad.net/ubuntu/+source/isc-dhcp` didn't work, so I replaced "code.launchpad..." with "git.launchpad..." there
<seb128> cjwatson, thx, I just updated that but it doesn't resolve the error, I guess I'm just oging to sync --no-lp
<rbasak> alkisg: right - if you go to https://code.launchpad.net/ubuntu/+source/isc-dhcp in your browser, the clone URL is displayed
<alkisg> I'm on 100 mbps optical; but at 22 kbps, this will take hours :D Receiving objects:  77% (9576/12352), 45.47 MiB | 22.00 KiB/s
<cjwatson> seb128: Uh, I would have expected GPG verification *only* to happen in the --no-lp case ...
<seb128> cjwatson, I'm trying to sync iw and it fails, but maybe a bug in the syncpackage code
<cjwatson> seb128: It gets as far as the "Sync this package" prompt for me, at least ...
<seb128> hum, weird
<mwhudson> oSoMoN: it's just needed on eoan?
<seb128> cjwatson, http://paste.debian.net/1097563/ for me on eoan
<oSoMoN> mwhudson, likely not, but that's where I initially observed it
<mwhudson> oSoMoN: well i guess that's where i'll initially fix it :)
<oSoMoN> yeah :)
<cjwatson> seb128: What version of ubuntu-dev-tools?
<seb128> ii  ubuntu-dev-tools 0.171        all          useful tools for Ubuntu developer
<cjwatson> seb128: Hm.  Dunno.  I guess you could hack verify_signature=False into the src_pkg.pull_dsc call at syncpackage:355
<alkisg> rbasak: it didn't allow me to push to "lp:~alkisg/isc-dhcp" (no such project), so I pushed to lp:~alkisg/+git/isc-dhcp; then I go to the bug report and click "link related branch", but search fails, and manually typing the branch isn't accepted either...
<cjwatson> lp:~alkisg/+git/isc-dhcp is wrong and will not work
<cjwatson> You wanted lp:~alkisg/ubuntu/+source/isc-dhcp
<alkisg> I additionally pushed to lp:~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp, and this shows up in "other repositories" in https://code.launchpad.net/ubuntu/+source/isc-dhcp, but this isn't accepted either
<alkisg> *without +git: git+ssh://alkisg@git.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp
<cjwatson> And "link related branch" is not used for git
<alkisg> cjwatson: I'm failing to find the "merge proposal" UI
<cjwatson> You should put "LP: #nnn" (substituting appropriately) in the commit message instead
<alkisg> I did
<cjwatson> Right, then it will be automatically linked once an MP is created
<alkisg> Thank you :)
 * alkisg deletes the wrong +git repository...
<cjwatson> my internet connection is being slow, but you should be able to go to https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp, go to the branch you want to propose, select "Propose for merging"
<mwhudson> oSoMoN: uploaded
<alkisg> cjwatson: aaaah, ok, thanks, I wasn't clicking inside the branch
<oSoMoN> mwhudson, excellent, thanks!
<alkisg> cjwatson: am I supposed to use another branch name? I just committed over ubuntu/devel...
<mwhudson> oSoMoN: i only wanted to stab quilt twice!
<cjwatson> That will work but is bad style since it's unclear
<alkisg> ty
<seb128> cjwatson, thx, that did it, I will poke a bit more at the code later to see if I find the issue
<oSoMoN> mwhudson, why is that?
<mwhudson> oSoMoN: oh just things like running git reset --hard and then quilt being confused because the .pc directory was still there
<oSoMoN> ah, right
<alkisg> cjwatson, rbasak, mwhudson, vorlon, thanks, I think I managed to do it as a merge proposal: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965
<ubottu> Launchpad bug 1840965 in isc-dhcp (Ubuntu Eoan) "dhclient initramfs code writes invalid net-eth0.conf" [High,Triaged]
<alkisg> (using branch name lp1840965)
<mwhudson> alkisg: thanks, can you "request a review" from mwhudson?
<alkisg> will do
<mwhudson> to tired to review tonight :)
<mwhudson> or spell apparently
<cjwatson> vorlon: Ah, I see the problem - initramfs-tools is never installed in buildd chroots, so the conditional deconfiguration of the update-initramfs diversion never happens because update-initramfs.REAL doesn't exist
<cjwatson> vorlon: Will fix
<cjwatson> (by making the deconfiguration more robust)
<rbalint> juliank, things did not fully clear up with bileto, i see unfinished tests in https://bileto.ubuntu.com/excuses/3789/eoan.html but http://autopkgtest.ubuntu.com/running shows empty queues
<rbalint> juliank, could you please take a look again?
<rbalint> juliank, maybe iptables migrating to release made a difference
<juliank> rbalint: Let's take mpd, I see results for amd64 and arm64, but no other archs, and none show up in the page
<juliank> Laney: ^ Do you have an idea what is happening w/ bileto and autopkgtest?
<juliank> Looking at journalctl ADT_PARAMS="{'ppas': ['ci-train-ppa-service/3789'], 'triggers': ['systemd/243~rc1+really241-7ubuntu1~rbalint2']}" ADT_PACKAGE=mpd
<juliank> To see mpd runs triggered for example, I only see the amd64 and arm64 ones
<juliank> and they have results, but the bileto excuses are empty
<juliank> s/empty/in progress/
<juliank> oh I should also look for ADT_PARAMS in the other direction with triggers first
<juliank> ugh, unsorted output
<juliank> I see mpd on amd64, arm64, s390x, i386, ppc64el
<juliank> I think that's all
<juliank> but the bileto excuses page only sees ppc64el
<juliank> sil2100: maybe you have some more input
<juliank> ?
<juliank> Results are uploaded into swift, but the bileto excuses page does not show any
<juliank> no idea how that gets there
<juliank> autopkgtest side looks fine afaict
<Laney> juliank: I have zero visibility into bileto
<juliank> Laney: Yeah, I thought maybe it was an autopkgtest issue you might have heard about, but after figuring out that my PARAMS query was a bit suboptimal, I realized, that autopkgtest seems fine, and it's bileto
<Laney> okey
<juliank> Laney: I probably should split ADT_PARAMS journal field into ADT_PPAS and ADT_TRIGGERS or something, or print out the dict ordered somehow...
<juliank> because right now you have to query both ADT_PARAMS="{'ppas': ['ci-train-ppa-service/3789'], 'triggers': ['systemd/243~rc1+really241-7ubuntu1~rbalint2']}"
<juliank> and ADT_PARAMS="{'triggers': ['systemd/243~rc1+really241-7ubuntu1~rbalint2'], 'ppas': ['ci-train-ppa-service/3789']}"
<juliank> and that sucks a bit
<Laney> writing out that dict isn't great even if it is sorted
<Laney> is there some kind of fancy list support there or is it string equality only?
<juliank> I guess strign equality only, but not sure
<juliank> Laney: Oh I guess the same field can appear multiple times for one entry
<juliank> so you could have ADT_PPA and ADT_TRIGGER fields for each ppa/trigger
<Laney> makes sense if that works like you say
<juliank> should test
<Laney> and not for example the last one winning
<juliank> systemd.journal-fields just says "n some cases, fields may appear more
<juliank>        than once per entry.
<cjwatson> vorlon: Could you review https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/371874 ?
<juliank> Laney: Ah, but the python api allows you to only specify each key once
<juliank> Unless I use sendv I guess
<juliank> so this works journal.sendv("MESSAGE=Hello world", "FIELD=value1", "FIELD=value2")
<juliank> and I can query both FIELD=value1 and FIELD=value2
<juliank> so yeah, this should work
<juliank> send() also just does args = ['MESSAGE=' + MESSAGE]
<juliank> so no special encoding or stuff needed
<xnox> vorlon:  Unit193: xfce4-sensors-plugin => well, there are no sensors on s390x that are meaningful.... even if one is running desktops on them =)
<juliank> So I guess I'll do this
<juliank> but it might need some rework, because we store the fields as a dict right now
<juliank> gotta use a list of tuples instead
<rbalint> juliank, Laney: have you fond something about the bileto issue?
<juliank> rbalint: No, it looks ok from our side AFAICT
<rbalint> juliank, by our side you mean bileto or bileto+autopkgtest are both fine?
<juliank> autopkgtest seems fine
<juliank> as mentioned it uploads the tests for all archs correctly to swift
<juliank> but the results do not appear on bileto
<rbalint> so it is sil2100 who could help?
<sil2100> uh oh!
<vorlon> juliank, rbalint: were the missing bileto test results not the ones where I mentioned they were killing the test runners?
<vorlon> which I flushed from the queue so they would stop eating builders
<juliank> vorlon: Um, he just started them today, they ran successfully, stored result in swift
<juliank> Well, he started them again today
<vorlon> oh ok
<rbalint> vorlon, juliank: I actually started them yesterday and they were probably killing the runners because it ran all tests for systemd https://bileto.ubuntu.com/#/ticket/3789#audit_log
<rbalint> vorlon, so if you flushed the queues yesterday, then it could be the cause for me not seeing the results
<rbalint> vorlon, i'd like to test systemd 241 before landing it in proposed because keeping a failing systemd in proposed affect others
<juliank> Results were put into swift, so they really should be tehere
<rbalint> juliank, all of them are in swift? like do you see results for yder ?
<rbalint> sil2100, juliank, vorlon: i may have hit LP: #160312
<ubottu> Launchpad bug 160312 in conduit (Ubuntu) "Conduit won't do any action" [Undecided,Invalid] https://launchpad.net/bugs/160312
<rbalint>  #1603120
<rbalint> LP: #1603120
<ubottu> Launchpad bug 1603120 in Bileto "britney explodes when there is a version collision between overlay PPA and archive" [Low,Triaged] https://launchpad.net/bugs/1603120
<sil2100> rbalint: let me look at that, but I thought we ripped out the overlay PPA from bileto - might be some place missing tho
<rbalint> i now removed iptables from the ppa, so if the tests are triggered again at least i won't hit this bug
<rbalint> sil2100, i set the destination to the archive, not to an overlay ppa if that matters
<sil2100> rbalint: ok, I guess the overlay PPA needs some more purging, let me get to that tomorrow
<fossfreedom> hi all - anyone familiar with the changes in the gtk 3.34 version of gnome-settings-daemon?  budgie-desktop is crashing because it can't find the Clipboard and Mouse components of GSD.
<LocutusOfBorg> foka, you there?
<LocutusOfBorg> autopkgtest for golang-github-xtaci-smux/1.3.4+ds-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression â» , s390x: Pass
<LocutusOfBorg> autopkgtest for golang-github-xtaci-kcp/5.4.4-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Regression â»
<LocutusOfBorg> do you have any idea for ppc64el and s390x regressions of the two above? ^^
<LocutusOfBorg> https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#golang-github-google-go-cmp
<foka> LocutusOfBorg, Hi!
<foka> I am not familiar with golang-github-xtaci-{kcp,smux}, but I can try playing with them on Debian porterbox and see if I could find some clues.  :-)
<LocutusOfBorg> that would be awesome!
<LocutusOfBorg> it is a regression in new releases
<LocutusOfBorg> btw I might have fixed notary so lots of others golang packages might migrate
<foka> BTW, thank you so much for getting go-cmp and hugo and friends to migrate!
<LocutusOfBorg> :)
<LocutusOfBorg> it has been a pleasure!
<LocutusOfBorg> thanks for the valuable help
<LocutusOfBorg> mwhudson, appreciated it too I guess :) (I syncd your notary upload)
<alkisg> vorlon: hi there; I commented on your comments in https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/371861; not sure if email notifications are generated for these...
<alkisg> I think our differences originate because  I'm thinking "shell sourceable" and you're thinking "yaml or similar"...
<alkisg> E.g. VAR=value1 value2 value3 is completely invalid in shell...
<alkisg> Meh I needed to globally save the inline comments; I just did so
<foka> LocutusOfBorg: The regression of golang-github-xtaci-smux on ppc64el turns out to be an infrequent random error (i.e. a test that is a little bit flaky), that happens about 1 out of 10 times.  I was also able to trigger the same error on my amd64 laptop, but again, very rarely.
<foka> I'm using something like "while go test -vet=off -p 4 github.com/xtaci/smux; do rm -rf ~/.cache/go-build ; done" for testing, i.e. loop till it fails.
<foka> Hmm... this time it took a bit longer to trigger it... like 24 times before the test fails again.
<juliank> rbalint: I only checked mpd, all of which ran, succeeded, and stored the results into swift
<juliank> (and only ppc64el showed up on excuses)
<foka> I suggest taking the easy way out, i.e. just trigger a rebuild on autopkgtest on both golang-github-xtaci-smux and golang-github-xtaci-kcp, and I suspect it will pass this time.  Meanwhile, I'll gather more test results and report this issue to @xtaci the upstream author.
<vorlon> alkisg: I did get the email, yes.  And I understand the question of shell validity.  My point is that adding quotes when it's invalid for the value to ever contain more than one word is unnecessary, and IMHO is unidiomatic
<vorlon> alkisg: if a netmask contains a space, something is buggy elsewhere; quoting it changes how the bug manifests, but I don't think that's valuable in itself
<alkisg> vorlon: the old code wrote 3 dns values in a single variable; that resulted in initramfs errors
<alkisg> (without spaces)
<alkisg> Why would a netmask contain a space?
<vorlon> alkisg: for *that one variable*.  I was commenting on the use of quotes on all the other variables
<vorlon> alkisg: if it wouldn't contain a space, why put single quotes around the value in your output?
<alkisg> That's what ipconfig does
<vorlon> ok
<alkisg> It's normal policy for shell; to quote strings
<alkisg> See the examples in my bug description; I'm trying to replicate the output of ipconfig
<vorlon> it's normal policy to quote strings that may contain embedded spaces
<vorlon> it's not normal policy to quote bare words :)
<alkisg> Debatable, but I was trying to replicate ipconfig,
<alkisg> for $new_routers or other values it's a problem though; what do we want in this case?
<alkisg> *that may contain multiple values
<vorlon> right, in that case I am happy to withdraw my objection to the quoting
<vorlon> I still don't like it but it shouldn't block on me
<alkisg> Does this sound saner?   echo "IPV4GATEWAY='${new_routers%% *}'"
<alkisg> This keeps only the first router, if it's a space separated list
<vorlon> yes, that does sound saner to me
<alkisg> Are there any other variables there that might have multiple space separated values?
<alkisg> new_ip_address => can it ever have 2 addresses? etc
<vorlon> bryce: I find myself having to repeatedly retry autopkgtests for symphony in response to various php uploads, to test against the version of symfony in -proposed.  This satisfies the proposed-migration policy, but symfony itself is stuck in -proposed long-term because it has reverse-dependencies that are incompatible with the new version (php-nesbot-carbon and its revdeps).  Is this something you
<vorlon> could look into?
<vorlon> alkisg: I assume by the name alone that new_ip_address is always a single address :)
<alkisg> vorlon: great, and about ipv6dns3?
<vorlon> alkisg: dns3?
<alkisg> You suggested that 3 dns values would go to 3 variables, but ipconfig only supports 2
<vorlon> right, I think that should apply to both ipv4 and ipv6
<alkisg> vorlon: but scripts that source net-*.conf don't know about those variables, as ipconfig never generated them
<alkisg> Are we "extending" the format or are we trying to imitate ipconfig output at this point?
<vorlon> alkisg: I think the responsibility of this script is to preserve the information received from the dhcp server and pass it on to userspace, regardless of whether any of the scripts in userspace which currently consume it are prepared to handle this particular value
<vorlon> having extra fields that the scripts ignore should be fine
<alkisg> Hopefully they'll ignore unknown variables then
<alkisg> Thanks, I'll push a commit with those changes
<bryce> vorlon, of course, can you point me at more info on the failure?  I'll try to take a look
<vorlon> bryce:  php-nesbot-carbon : Depends: php-symfony-translation (< 4~~) but 4.3.3+dfsg-3ubuntu3 is to be installed
<vorlon> bryce: you can see a complete list of packages that would be uninstallable with the new symfony in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt; I know the php-illuminate-* depend on php-nesbot-carbon, and I haven't looked at the other revdeps
<vorlon> I was surprised to see no bug filed against php-nesbot-carbon in Debian for the uninstallability - that's probably a good start
<alkisg> vorlon: "loop over all dns values" is a bit tricky in shell, it either needs eval or set; hardcoding "up to 4 dns servers" is much more readable; is that ok?
<vorlon> alkisg: why is my pseudocode not sufficient?  "for word in $list; do"
<alkisg> shellcheck complains for unquoted $list; also globs should be unset; but ok I don't mind having shellcheck warnings if you're ok with that
<alkisg> I'll also make sure that IPV4DNS0 and 1 are always in the output, even if empty, like ipconfig does it
<bryce> vorlon, ok will take a look after I'm through this batch of php uploads.
<kees> stgraber, vorlon: tech board meeting! :)
<vorlon> alkisg: I don't know shellcheck or have any reason to trust it over my own understanding of shell syntax :)
<alkisg> vorlon: the idea is that `for in $list` can loop over filenames if it contains * etc etc; np, pushing the new commit...
<alkisg> vorlon: pushed; I guess launchpad supports squashed merges, right?
<vorlon> it doesn't, really
<vorlon> it doesn't support server-side merges at all, only client-side merges, for git
<alkisg> Should I uncommit the 2 last commits and push them as one?
<vorlon> but also, these branches are read-only
<vorlon> --> rbasak, cpaelzer :)
<bdmurray> cpaelzer: I'm going to add the block-proposed tag to bug 1797926 so it can age a bit, remove it when you think its old enough
<ubottu> bug 1797926 in bind9 (Ubuntu Bionic) "host crashed with SIGABRT in isc_assertion_failed()" [Undecided,Fix committed] https://launchpad.net/bugs/1797926
<cpaelzer> thanks bdmurray, I'll give it an extra week I guess
<mwhudson> LocutusOfBorg: yeah, i thing grpc should migrate in next britney run
<mwhudson> foka: oh nice that you fixed the prometheus common thing, i was just going to get britney to ignore the results
<mwhudson> getting go packages to migrate is such a game of whack a mole
<foka> mwhudson: Hoho, I got lucky with golang-github-prometheus-common.  At first I thought it had to do with golang/x/net because that was when the failure began, but at closer look that wasn't it, and I was so lucky to have come across that Pull Request on GitHub.
<foka> mwhudson: Thank you so much for getting other go packages to migrate!
<mwhudson> foka: we're not done yet :)
<mwhudson> hm https://launchpad.net/ubuntu/+source/golang-goprotobuf/1.3.2-2 should migrate with sufficient retrying
<mwhudson> not sure what's up with golang-google-api on arm64
<mwhudson> i think it's just timing out
<foka> LocutusOfBorg: I just tested v1.1.0 (i.e. older version) of golang-github-xtaci-smux and was able to reproduce the same errors on my amd64 laptop.  See https://github.com/xtaci/smux/issues/54 and https://github.com/xtaci/smux/issues/55 for follow up.
<foka> LocutusOfBorg: As for golang-github-xtaci-kcp, I was unable to reproduce the error on s390x.  Perhaps re-run the autopkgtest a few more times and it may automagically work?  (Or, like mwhudson says, get britney to ignore the results?  Hoho!)
<foka> mwhudson: Oh yeah!  golang-google-api on arm64 is still failing autopkgtest.  That reminds me: I was going to experiment on Debian's arm64 porterbox, which I forgot.  I'll get back to it and see if we're lucky again, hoho!
<mwhudson> foka: would be good to hear what you find indeed
<mwhudson> i can test it too but not right now
<foka> Regarding golang-github-xtaci-kcp on s390x, perhaps matching it with the latest 1:0.0+git20190811.74dc4d7+dfsg-1 would help?
<foka> LocutusOfBorg: Regarding golang-github-xtaci-kcp on s390x, perhaps matching it with the latest golang-golang-x-net-dev 1:0.0+git20190811.74dc4d7+dfsg-1 would help?  (sorry for the repetition, the last message was missing the package name)
 * mwhudson looks at why golang-golang-x-net-dev is not migrating and grimaces
<mwhudson> blah syncthing needs a GOCACHE fix?
<mwhudson> oh toddy fixed that 4 minutes ago :)
<mwhudson> (in debian)
<mwhudson> https://launchpad.net/ubuntu/+source/golang-golang-x-sys/0.0~git20190726.fc99dfb-1/+build/17329615 <- i assume this is just the usual "test fails in chroot" thing
<mwhudson> did it build in debian i wonder...
<mwhudson> yes
<mwhudson> hmmm
<mwhudson> Works On My Machine (tm)
#ubuntu-devel 2019-08-28
<LocutusOfBorg> nice work foka mwhudson !
<LocutusOfBorg> wrt x-sys, I think ignoring tests results might be the best thing to do for now
<LocutusOfBorg> it has something to do with the new openMountByID test
<LocutusOfBorg> +       mi, err := os.Open("/proc/self/mountinfo")
<LocutusOfBorg> I don't think its a good idea to try to open such devices inside a chroot...
<s1aden> LocutusOfBorg: if that doesn't work, the chroot illusion sucks
<LocutusOfBorg> s1aden, it works to be honest
<LocutusOfBorg> the test is trying to read some device inside it
<LocutusOfBorg> [09:33:16] <BTS> Opened #935935 in src:golang-golang-x-sys by Gianfranco Costamagna (locutusofborg) Â«golang-golang-x-sys: test failure in chrootsÂ». https://bugs.debian.org/935935
<ubottu> Debian bug 935935 in src:golang-golang-x-sys "golang-golang-x-sys: test failure in chroots" [Important,Open]
<LocutusOfBorg> foka, mwhudson ^^
<LocutusOfBorg> I did some debugging and opened a bug report...
<LocutusOfBorg> (and thanks for fixing smux!
<foka> LocutusOfBorg: You're very welcome!  :)  And thanks for looking into golang-golang-x-sys.
<LocutusOfBorg> I hope I didn't mess too much with the package, I'm not a golang speaking guy!
<LocutusOfBorg> with your help we might get all the golang stack migrate :D
<foka> LocutusOfBorg: When you have time, could you please pull in syncthing/1.1.4~ds1-3 too?  That upload by toddy should solve syncthing's autopkgtest with golang-1.12
<foka> LocutusOfBorg: I'm glad xtaci fixed smux so quickly!
<LocutusOfBorg> done thanks!
<LocutusOfBorg> so, last blocking golang issues:
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/g/golang-google-api/eoan/arm64 <--
<LocutusOfBorg> golang-go.crypto autokpkgtest failures
<LocutusOfBorg> golang-golang-x-tools autopkgtest failures
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/g/golang-github-jbenet-go-context/eoan/armhf
<doko> jamespage: please see the python2 removal thread on u-d. looks like at least some openstack packages need proper merging from debian, or dropping python2 on its own
<jamespage> doko: yeah I just saw that
<jamespage> doko: what do the different 'levels' in the generated report mean?
<LocutusOfBorg> less priority issues: golang-github-rs-zerolog autopkgtest failures on 32 bit, golang-gopkg-ldap.v3 FTBFS
<LocutusOfBorg> golang-golang-x-tools autopkgtest failures
<doko> jamespage: nothing ;p just make sure that you remove leaf packages first
<jamespage> sahid, coreycb ^^
<jamespage> doko - I'm assuming this is an objective for eoan then?
<doko> jamespage: no, that should be for 20.04, so that we can remove the python symlink and the python package
<doko> we may have to keep python2 and using the python2 shebang
<jamespage> doko: can we get nova-lxd rm'ed from eoan please - I raised a bug a while back to cover that
<jamespage> sahid, coreycb: do we have that outstanding issue with completely dropping py2 depends for the backports to the UCA? if so we should work to resolve that if possible
<jamespage> cpaelzer, I've re-opened https://bugs.launchpad.net/ubuntu/+source/intel-ipsec-mb/+bug/1786201 as the latest 2.12 snapshots of OVS are pulling that in for x86_64
<ubottu> Launchpad bug 1786201 in intel-ipsec-mb (Ubuntu Eoan) "MIR for intel-ipsec-mb" [Medium,New]
<cpaelzer> jamespage: interesting
<cpaelzer> jamespage: how can dpdk not pull it in but OVS does
<jamespage> cpaelzer: just looking atm
<jamespage> cpaelzer: 2.11.1 generates the mismatch
<mwhudson> LocutusOfBorg: i guess i'll look at google-api on arm64 tomorrow unless foka beats me to it
<jamespage> just seeing of the 2.12 snapshots I'm producing are doing the same thing
<cpaelzer> jamespage: https://paste.ubuntu.com/p/cdCf9CqpSX/
<cpaelzer> these are the only packages needing it (two PMDs)
<cpaelzer> they are considered not for prime-time yet which is why they are only universe
<mwhudson> LocutusOfBorg: have you looked at the crypto or tools failures?
<cpaelzer> essentially dpdk (is in main) pulls in a list of "better support/mature" PMDs and those are in main
<mwhudson> crypto is some ssh thing iirc
<cpaelzer> jamespage: I'd not really see why OVS would directly create/depend on a list of PMDs
<cpaelzer> need to read build log of OVS in proposed
<jamespage> cpaelzer: one sec - this might have been a transient issue
<mwhudson> tools is just "FAIL	golang.org/x/tools/go/internal/gcimporter	22.980s" which is nice
<jamespage> cpaelzer: I had a build on the 7th august that showed this, and then one on the 8th that did not
<jamespage> odd
<cpaelzer> oO
<cpaelzer> I'm still parsing the buildlog
<jamespage> cpaelzer: those where in PPA's
<jamespage> but the 2.11.1 in the main archive has the same issue
<cpaelzer> whicih don't differ between main/universe
<cpaelzer> IIRC there all is main
<jamespage> cpaelzer: I mean't 'the ubuntu archive' rather than 'a PPA'
<cpaelzer> ok
<cpaelzer> jamespage: it pulls in on build libdpdk-dev which depends on all PMDs indirectly, and they are present at build but since they carry no symbols neede dthey don't end up as dependnecies
<cpaelzer> at least on 2.11.1 at https://launchpadlibrarian.net/433294520/buildlog_ubuntu-eoan-amd64.openvswitch_2.11.1-0ubuntu1_BUILDING.txt.gz
<cpaelzer> can I see your 2.12 where this happens?
<jamespage> might be some sort of linking issue
<cpaelzer> yeah it could overlink
<jamespage> cpaelzer: leave it with me - I'm just testing fresh snapshots which will superceed everything to-date so this might just go away
<jamespage> cpaelzer: don't want you to spend cycles if not required :)
<cpaelzer> the way builds against dpdk are set up usually make all dpdk libs (a lot) available, but then should only link whats needed (with the ususal ubuntu as-needed)
<cpaelzer> ok jamespage, but overlinking could be a thing
<cpaelzer> it happened in the past with DPDK
<cpaelzer> so let me know
<cpaelzer> I'm closing the MIR for now
<cpaelzer> thanks for the ping still jamespage, worth to be aware of
<cpaelzer> jamespage: with 19.08 thre are some ipsec things http://paste.ubuntu.com/p/GRp2kC4sh4/
<cpaelzer> but as you see all experimental (not for consumption) and we don#t have 19.08 in eoan
<LocutusOfBorg> mwhudson, I fixed other stuff, but crypto...
<LocutusOfBorg>         Attempt to write login records by non-root user (aborting)
<LocutusOfBorg> LOL
<LocutusOfBorg> looks like the test is trying to ssh and fails because of ENOPERM?
<LocutusOfBorg> but there is a new x-sys package so, lets wait a couple of hours and retry once more all golang failed tests
<LocutusOfBorg> syncthing has lots of flaky tests... retrying amd64 worked, I'm hitting the i386 retry button hard once again
<cpaelzer> bryce: this symfony thing you asked turns out into a nice digital indiana jones trip
<LocutusOfBorg> cpaelzer, you know what is funny? there is a new symfony release
<cpaelzer> we seem to ahve enough trouble with the old one LocutusOfBorg :-)
<cpaelzer> but most of what I found while anylazing the issues are outdated packages that seem fixable or removable
<cpaelzer> I'll later send a summary to bryce / vorlon who discussed this yesterday
<cpaelzer> LocutusOfBorg: unless you mean the 4.x that is stuck in proposed
<cpaelzer> that is the one that started the discussion
<LocutusOfBorg> what is missing for symfony in proposed, is that some packages breaks the 4.x version
<LocutusOfBorg> so they have to be kicked-out or updated
<cpaelzer> yep and that is what I was analyzing
<cpaelzer> the details of it
<LocutusOfBorg> oh and my symfony merge should be probably uploaded, the "php-7.2.patch" was an hack I did to create missing functions that are available on php-7.3
<LocutusOfBorg> I won't upload now, but if stuff migrates...
<cpaelzer> LocutusOfBorg: I see we both triggered it the same way, so in addition to that trigger it also is flaky ? http://autopkgtest.ubuntu.com/packages/s/symfony/eoan/amd64
<cpaelzer> or did you have some other upload/fix that makes this go well now?
<LocutusOfBorg> not the same way?
<LocutusOfBorg> cpaelzer, without all-proposed, php72 is picked up
<jamespage> cpaelzer: got it again - https://launchpadlibrarian.net/439281290/buildlog_ubuntu-eoan-amd64.openvswitch_2.12.0~git20190828.23acdc07f-0ubuntu1~ubuntu19.10.1~ppa201908281053_BUILDING.txt.gz
<cpaelzer> thanks jamespage, reading te log ...
<cpaelzer> jamespage: my assumption would be that OVS added support for librte-ipsec
<cpaelzer> it is odd that it doesn't show up and only the follow on dependency does
<cpaelzer> which then is libipsec-mb0
<jamespage> cpaelzer: that was my assumption but I can't find anything in the codebase to indicate that is the case
<jamespage> unless there is something implicit in the ipsec support for the dpdk context
<cpaelzer> jamespage: overlinking
<cpaelzer> look in the log for the usual "package could avoid a useless dependency if"
<cpaelzer> it seems like all of DPDKs helper libs creeped in
<cpaelzer> that looks much like the libdpdk-dev dependencies
<cpaelzer> hmm, IÃ'm on something ...
<cpaelzer> jamespage: there is a -Wl,--no-as-needed in the libtool commandline
<cpaelzer> all after that seem to be what was overlinked
<cpaelzer> hmm yeah
<cpaelzer> that is from the pkgconfig of dpdk
<cpaelzer> jamespage: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1841759
<ubottu> Launchpad bug 1841759 in dpdk (Ubuntu) "over-linking due to dpdk pkg-config" [Undecided,Triaged]
<rbasak> Does anyone else get irritated by indentexpr being set by default in vim packaging nowadays?
<rbasak> For me it's almost always wrong and I'm forever unsetting it :-/
<cpaelzer> jamespage: I have a test fix building and will submit it upstream if it succeeds
<cpaelzer> I already ahve an ack for the approach by the Debian co-maintainer
<cpaelzer> rbasak: I guess I'm not new enough
<cpaelzer> rbasak: what is it set to by default nowadays?
 * cpaelzer is reminded of mouse=v in Debian which Ubuntu avoided to get (was also always wrong)
<cpaelzer> rbasak: upstream doc still lists it as default ""
<cpaelzer> rbasak: and it isn't set for me (in eoan conainer)
<cpaelzer> I get "  indentexpr= " by :set indentexpr?
<cpaelzer> other options report their value nicely
<cpaelzer> rbasak: could that be a drop in config from any extra packages on top of what my eoan container has?
<rbasak> I think it gets set automatically depending on what is being edited
<rbasak> I couldn't pin down the exact place in the default init scripts
<rbasak> "vim -u NONE" works around by doing nothing, but then I don't get the other goodness
<rbasak> Example: if I edit a shell script, it uses an tab-based indent level of 8, which is almost always wrong
<cpaelzer> rbasak: what do I need to edit to get the behavior?
<rbasak> cpaelzer: try a bash script maybe?
<cpaelzer> I have opened a shell script and now get
<cpaelzer>   indentexpr=GetShIndent()
<rbasak> What happens to me is that it auto-indents to eight, with tabs, and then backspace unindents the tab too far to fix it, etc.
<rbasak> It's really irritating
<cpaelzer> rbasak: but in Bionic I have the same
<cpaelzer> set when opening a shell file
<rbasak> Maybe it's been doing it longer than I think then
<rbasak> Or perhaps GetShIndent() has changed?
<cpaelzer> yep
<cpaelzer> the option I get in Bionic and eoan
<cpaelzer> but in eoan it is a 8char tab
<cpaelzer> well bionic is probably modified by me, let me try a container there as well
<cpaelzer> rbasak: ok bionic does the same
<cpaelzer> it was just my local config that saved it
<cpaelzer> has the same option set and does a long 8 char wide tab
<rbasak> So perhaps I'm too late to drive any change in Ubuntu
<rbasak> Thank you for looking
<coreycb> jamespage: sahid: if we want to completely drop py2 this cycle then we'd need to remove those couple of remaining BDs that we're keeping for uca backports
<coreycb> jamespage: sahid: i don't know if it's that high of a priority yet but we'll have to do it this cycle or next I'd think
<cpaelzer> jamespage: I have a fixed build to avoid the dependency issue in a PPA, waiting for upstream response on it now
<cpaelzer> jamespage: you can find all you need for now fromt he bug (e.g. if you want to PPA copy my build to yours)
<jamespage> cpaelzer: ok testing
<seb128> LocutusOfBorg, thx for that colord sync by I was about to do it, when an Ubuntu dev do a fake sync or an upload to Debian you can usually assume they are dealing with the update and that is no need to conflict/duplicate work (I'm mentioning it now because it's not the first time you do that)
<sil2100> Laney: hey! Thanks for merging the ADT fixes - I have a small request though, I'd like to investigate the sru_regress_inform_state state file from the latest run
<sil2100> Laney: could you copy it out/pastebinit for me somewhere?
<sil2100> (since I have no access to snakefruit)
<sil2100> Laney: nvm my earlier request!
<mwhudson> foka: did you get to look at the golang-google-api tests on arm64 yet?
<mwhudson> LocutusOfBorg, foka: any ideas on golang-go.crypto?
<mwhudson> if not i'll start poking at that one
<foka> mwhudson: golang-google-api, maybe I am doing it wrong, but I haven't been able to reproduce the test error on amdahl.debian.org.  My test methods were very simplistic, i.e. a simple "debuild -us -uc" run, and running something like "go test -p 4 -vet=off -count=1 google.golang.org/api/..."
<mwhudson> foka: could just be noisy neighbour effects making the tests slow
<mwhudson> foka: in which case i think it would be reasonable to badtest it
<foka> As for golang-go.crypto, I notice the regression, but haven't got time to look at it yet.
<mwhudson> hmm the package _builds_ fine
<mwhudson> why would it then fail in autopkgtest
<blackboxsw> vorlon: or other SRU vanguards: I think we may have talked about this condition on a previous cloud-init SRU.      We've started an SRU already, but found a bug in upstream for a new datasource that is included in the SRU. I'd like to fix that as part of this SRU.  but wanted to add a new debian/changelog stanza and continue to reference the same SRU process bug we have currently open. Since we have an SRU
<blackboxsw> exception for cloud-init, (and have not yet fix-released #1841099. Can I add a 2nd stanza to cloud-init's debian/changelog referencing  example: https://pastebin.ubuntu.com/p/SJW8cDrHm4/
<mwhudson> oh i bet some test is skipped because on the buildds because e.g. openssh-client isn't installed...
<foka> mwhudson: Good thinking about openssh-client; that's probably it!  :-)
<mwhudson> yes
<mwhudson> --- SKIP: TestInvalidTerminalMode (0.01s)
<mwhudson>     test_unix_test.go:188: skipping test: exec: "sshd": executable file not found in $PATH
<mwhudson> what have i done wrong in life to have such good instincts about this sort of thing...
<vorlon> blackboxsw: yes, it's fine to reuse the same SRU process bug
<blackboxsw> ok thanks, I thought you had mentioned that before. wanted to double check
<mwhudson> foka: yeah if i add openssh-server and openssh-client to build-depends the build fails too
<mwhudson> gives me something to debug
<foka> Awesome! ð
<mwhudson> fails in sid as well as debian fwiw
<mwhudson> as well as eoan
<foka> mwhudson: Yes, I just did a similar test build and failed on my Debian sid notebook too with openssh-{server,client} added to Build-Depends.  (My computer is a bit slow though, so it took a while to finish, hoho)
<mwhudson> i suppose it's time to look at what this test is actually doing
<mwhudson> this is a very strange test
<mwhudson> it's essentially testing that the host sshd behaves in a particular way
<mwhudson> and in a way that's not mandated by the RFC, to boot
<mwhudson> "and the server MAY ignore any modes it does not know about."
<mwhudson> er it passes on bionic though
<mwhudson> hm i suspect this is an unintended behaviour change in openssh vwiw
<mwhudson> *fwiw
<mwhudson> foka: going to file an upstream bug to remove this test case and then upload a patch to debian removing it (and adding openssh-server to build-depends)
<foka> mwhudson: Neat!  Thank you so much!
<mwhudson> foka: uploaded to debian
<mwhudson> that's my go package fiddling done until tomorrow i think ...
<foka> mwhudson: You are wonderful!  Thank you very much!
#ubuntu-devel 2019-08-29
<cjwatson> mwhudson: What is the openssh behaviour change here?
<mwhudson> cjwatson: previously openssh closed the connection on the presentation of an invalid terminal mode
<mwhudson> with a log like thisL
<mwhudson> 		debug1: session_pty_req: session 0 alloc /dev/pts/3
<mwhudson> 		debug1: Ignoring unsupported tty mode opcode 255 (0xff)
<mwhudson> 		parse_tty_modes: unknown opcode 255
<mwhudson> 		parse_tty_modes: n_bytes_ptr != n_bytes: 1 1
<mwhudson> 		Packet integrity error (5 bytes remaining) at ../../session.c:1899
<mwhudson> 		Disconnecting user mwhudson UNKNOWN port 65535: Packet integrity error.
<mwhudson> now the log looks like
<mwhudson>         debug1: Ignoring unsupported tty mode opcode 255 (0xff)
<mwhudson>         ssh_tty_parse_modes: unknown opcode 255
<mwhudson>         ssh_tty_parse_modes: 5 bytes left
<mwhudson> and the connection proceeds
<cjwatson> mwhudson: Could be a consequence of the translation of ssh_tty_parse_modes to the sshbuf API
<cjwatson> mwhudson: Not certain whether upstream would be interested, but it might be worth reporting it there if you can come up with a more upstream-friendly test case
<mwhudson> cjwatson: yes, those were the sort of words i saw rummaging around in openssh-portable git
<cjwatson> I think you're right that it's likely unintended
<mwhudson> cjwatson: otoh it looks like the intended behaviour was always to ignore invalid modes
<mwhudson> judging by the older log message
<mwhudson> cjwatson: where do bugs get reported?
<cjwatson> Ignore yes, but in the case of 160-255 sshd doesn't know how long the message is supposed to be
<cjwatson> bugzilla.mindrot.org
<mwhudson> should i be amused or not that openssh bugzilla does not redirect to https?
<cjwatson> The current comment does still say "Opcodes 160 to 255 are undefined and cause parsing to stop"
<mwhudson> ah ok
<mwhudson> does sound like a bug then
<cjwatson> I doubt I ever noticed that since I've had HTTPS Everywhere installed forever :)
<mwhudson> yeah i should probably do that too
<mwhudson> cjwatson: are you up very early, very late, or not at home?
<cjwatson> I'd say it's not precisely a bug, but it would make more sense for the undefined opcode to return an error
<cjwatson> Up in the middle of the night waiting for painkillers+antibiotics to kick in so I can go back to sleep
<valorie> get well soon, cjwatson
<cjwatson> Thanks.  I know what the problem is now so it's just frustrating waiting for treatment to be effective
<mwhudson> cjwatson: i hope you manage to sleep soon then!
<mwhudson> cjwatson: https://bugzilla.mindrot.org/show_bug.cgi?id=3061
<ubottu> bugzilla.mindrot.org bug 3061 in sshd "requesting invalid terminal modes no longer aborts connection" [Minor,New]
<cjwatson> thanks, LGTM
<marcoagpinto> bugs
<marcoagpinto> ops
<mwhudson> marcoagpinto: we have lots of bugs, yes :)
<marcoagpinto> sorry... wronte join text
<marcoagpinto> I was trying to write: /j ubuntu-bugs
<mwhudson> yes, just being silly
<marcoagpinto> >:)
<marcoagpinto> and I had "/j ubuntu-" on the clipboard
<marcoagpinto> :)
<marcoagpinto> I forgot to paste it
 * mwhudson glares at http://autopkgtest.ubuntu.com/packages/g/golang-fsnotify/eoan/arm64
<LocutusOfBorg> mwhudson, do you want to have a look also at golang-golang-x-tools ?
<LocutusOfBorg> this might be the last blocker
<LocutusOfBorg> with fsnotify
<mwhudson> LocutusOfBorg: yea i guess so
<mwhudson> fsnotify will pass if we bounce on retry enough i'm sure but that's also stupid
<mwhudson> golang-gopkg-square-go-jose.v2 is gone from testing
<LocutusOfBorg> syncthing should be probably patched to fail less frequently
<LocutusOfBorg> syncing syncthing
<LocutusOfBorg> I asked to kick it out on release channel
<seb128> juliank, hey, any idea why in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/u/uim/20190824_150559_359b3@/log.gz we get
<seb128> 'Broken uim-el:amd64 Depends on xemacs21-mule:amd64 < none | 21.4.24-8 @un uH >
<seb128>   Considering xemacs21-mule:amd64 1 as a solution to uim-el:amd64 0
<seb128>   Holding Back uim-el:amd64 rather than change xemacs21-mule:amd64'
<juliank> that probably needs like half an hour of investigating
<seb128> k
<mwhudson> ooh fsnotify passed
<LocutusOfBorg> LOVELY
<mwhudson> LocutusOfBorg: so yeah, just tools really
<seb128> juliank, uim-el depends on         emacs24 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
<LocutusOfBorg> seb128, I see lots of emacs stuff has been no change rebuilt in Debian, because of new dh-elpa
<seb128> emacs24 doesn't exist anymore
<LocutusOfBorg> ok but the others exist?
<seb128> but in a chroot I can install the -mule just fine
<seb128> yes
<seb128> dunno why apt prefers to hold on
<seb128> I might just try to change emacs24 for "emacs" which exists and see if that helps
<juliank> seb128: that certainly sounds like a bug in the packaging that it depends on emacs24 first
<seb128> juliank, well, still alternative depends should work...
<juliank> seb128: And they did
<juliank> seb128: The reason it failed is that the sat-dep package was removed before that
<seb128> so something else is probably buggy :/
<juliank> seb128: Like, it did in the autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs part
<seb128>   Removing autopkgtest-satdep:amd64 rather than change uim-el:amd64
<juliank> yeah
<juliank> that happens earlier
<juliank> than it tries to get more info by passing all package names directly to apt install
<juliank> which succeeds
<juliank> We're unfortunately missing debugging output from the mark phase
<seb128> I tried to change the emacs24 to emacs, let's see if that helps
<juliank> It should
<mwhudson> hm i wonder if the golang-golang-x-tools tests are just ooming
<seb128> bah, calligra fails to build in eoan and a rebuild is needed for the poppler transition
<seb128> https://bugs.launchpad.net/ubuntu/+source/calligra/+bug/1841910
<ubottu> Launchpad bug 1841910 in calligra (Ubuntu) "Build is failing on eoan (and rebuild needed for poppler transition)" [Undecided,New]
<seb128> RikMills, ^ is that something you could look at?
<RikMills> seb128: yeah. will do
<LocutusOfBorg> juliank, question: why this works: apt build-dep ./golang-golang-x-tools*.dsc
<LocutusOfBorg> and this fails? apt build-dep golang-golang-x-tools*.dsc
<LocutusOfBorg> E: You must put some 'source' URIs in your sources.list
<juliank> LocutusOfBorg: because it's hard to differentiate the latter from a real package name, while the former is not a valid package name
<seb128> RikMills, thx
<juliank> LocutusOfBorg: APT only accepts filenames starting with / or ./; everything else is not considered a filename
<LocutusOfBorg> juliank, like if it ends with ".dsc" it is probably a filename? or if (access(file))?
<LocutusOfBorg> I got the problem, I was thinking about a possible solution
<juliank> that makes the behavior context-sensitive
<juliank> like foo.dsc is a valid package name
<juliank> Then we end up with the same problem we have now with regex and fnmatch
<LocutusOfBorg> yes, but if the file exists in that directory... meh
<LocutusOfBorg> but I get the issue, thanks
<LocutusOfBorg> there is always some hope to get an answer like "oh, this is a bug, lets fix it" :)
<juliank> If the file exists in the directory means it will install the build-depends of package foo.dsc in another directory, and of your foo.dsc in its directory
<juliank> which makes it suboptimal as you have to make sure you are in the right directory
<juliank> I wonder if we can make autocompletions autocomplete foo.dsc to ./foo.dsc
<juliank> What I want apt to do is say: "No such package found, but a file with that name. Prefix it with ./ if you did mean the file"
<juliank> APT syntax post-20.04 will need 1 lookup character to decide argument type: ? => pattern, .|/ => filename, rest=>package name
<juliank> oh, and I guess ^=>regex
<RikMills> seb128: test building with upstream patch added
<seb128> RikMills, woot, thx
<LocutusOfBorg> seb128, how is poppler going? only calligra and gdcm left?
<LocutusOfBorg> I have some work to do, but I don't want to delay your transition with my stuff :)
<RikMills> LocutusOfBorg: I'm test building fix for calligra
<seb128> LocutusOfBorg, yeah, I think so ... if you want to do gdcm please do, I got other things to handle and I'm on vac tonight :/
<LocutusOfBorg> sure, with pleasure!
<seb128> LocutusOfBorg, thx!
<LocutusOfBorg> RikMills, can you also rebuild kitinerary?
<LocutusOfBorg> and kdepim-addons?
<RikMills> I will try
<LocutusOfBorg> thanks! with your 4 packages we should be good to go
<mwhudson> [  865.965695] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-998.slice/session-c2.scope,task=gcimporter.test,pid=8873,uid=998
<mwhudson> [  865.965711] Out of memory: Killed process 8873 (gcimporter.test) total-vm:870044kB, anon-rss:779692kB, file-rss:0kB, shmem-rss:0kB
<mwhudson> that'd be a yes then
<mwhudson> should probably patch that test to skip in -short mode
<mwhudson> tomorrow!
<RikMills> LocutusOfBorg: kdepim-addons doesn't need a rebuild. poppler build dep is obsolete. the feature went into kitinerary in fact!
<RikMills> I'll drop the bd in git
<seb128> kitinerary might need one then? ;)
<RikMills> seb128: it does. just checking it builds with new poppler
<RikMills> it does :)
<seb128> good! :-)
<LocutusOfBorg> seb128, will you open a bug against debian/uim please?
<LocutusOfBorg> looks like it migrated!
<LocutusOfBorg> RikMills, and an upload without that dependency?
<LocutusOfBorg> oh I see now, I checked the build log and I probably failed to parse the output
<LocutusOfBorg> not needed, yes
<LocutusOfBorg> RikMills, calligra is good
<LocutusOfBorg> gogogo?
<RikMills> LocutusOfBorg: just this second uploaded
<LocutusOfBorg> ð
<LocutusOfBorg> now autopkgtests will take a while... queues are half full
<seb128> LocutusOfBorg, yes, I plan to, I wanted to see if it worked first
<LocutusOfBorg> seb128, thanks, it worked btw :D
<LocutusOfBorg> do you have any news about duplicity on ppc64el?
<LocutusOfBorg> I prod the bug...
<seb128> no, I don't think we can/should could on upstreamm to fix it
<seb128> I opened a RT to get eoan chroots on the builders over a month ago but got ignored
<LocutusOfBorg> :/ remove the binary?
<seb128> it probably needs someone who has access to a debug env to debug
<seb128> that's a big hammer
<LocutusOfBorg> I didn't mention it before because I know how big the hammer is, but meh
<LocutusOfBorg> did you try to lower the optimization level already, right?
<seb128> smaller hammer would be to ignore the test failure in the ppc64el build
<seb128> no
<seb128> I didn't have much time to get back to that
<LocutusOfBorg> if it works with -O2 on ppc64el I upload in the archive
<seb128> it's in my backlog but was not a ff blocker so got ranked lower than other work
<seb128> LocutusOfBorg, thx
<cjwatson> seb128: RT> have you escalated that with your manager?
<cjwatson> it's #1033 in the BVG queue so is going nowhere unless you get it bumped
<cjwatson> (also I'd suggest that saying "it's a low-priority request" in the ticket is not a recipe for getting immediate attention :) )
<seb128> cjwatson, no, I was unsure if was important enough to go the escalation route
<cjwatson> well, if it's blocking investigation ... although don't we have canonistack bos01 now?
<seb128> we do, which is one of the reason I though it was not that important
<seb128> it's probably just me holding to old habits
<seb128> I need to have a look again how to access/use the canonistack instead
<cjwatson> https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01
<seb128> thx
<LocutusOfBorg> cjwatson, how do you feel today?
<LocutusOfBorg> seb128, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17483477
<cjwatson> LocutusOfBorg: so-so; thanks for asking
<LocutusOfBorg> if it works, I'll join the party of people telling to the person who decided to use -O3 on ppc64el that it was a BAD idea
<cjwatson> antibiotics beginning to be useful
<LocutusOfBorg> after some days...
<LocutusOfBorg> have some rest, they will eventually do the trick :)
<seb128> LocutusOfBorg, I don't think comments like 'Hello, ping? this bug is preventing some transition from landing in ubuntu eoan...' are useful on upstream trackers...
<seb128> they probably do care about Ubuntu, but they stated that they have no access about ppc64el nor any clue about it
<LocutusOfBorg> yes, but there was an unanswered question...
<seb128> well, you can try, I doubt they are likely to do anything about it
<LocutusOfBorg> ping is about "hey what do you need to trace it down"? do you have a way to show more logs?
<seb128> out of responding 'we don't care about that arch, none of our users are on it'
<LocutusOfBorg> when I had the src:firewalld issue, I got some debugging information from upstream that I was not aware of
<seb128> ah, I forgot about that one
<seb128> your comment didn't include much context on what the ping was about :)
<LocutusOfBorg> it was just the message above, this is why I didn't add context
<LocutusOfBorg> anyway I hope -O2 does the trick
<cjwatson> seb128: FWIW, after getting bos01 access generally set up and creating a temporary model, "juju deploy --constraints 'arch=ppc64el instance-type=m1.small' --series bionic cs:ubuntu" will deploy a machine you can "juju ssh" to once it's built and then you can play with that at will
<cjwatson> (Maybe different instance-type depending on size requirements)
<seb128> cjwatson, k, thx for the tips, I'm going to try in a bit
<seb128> LocutusOfBorg, build failed :-/
<LocutusOfBorg> :(
<LocutusOfBorg> seb128, I did a test adding some print message to that test and uploaded in my ppa
<seb128> LocutusOfBorg, good luck!
<LocutusOfBorg> I wish you a better luck with real hw, but I just want to print the numbers that are causing that assert
<LocutusOfBorg> just to understand the values
<seb128> it just needs debugging I think, but I've been too busy with feature freeze and travelling to GUADEC and on holidays tonight
<LocutusOfBorg> lower bound: 334464: actual st_size value: 841656 upper bound: 465536
<GunnarHj> Hi jdstrand, can you please take a look at https://github.com/ibus/ibus/issues/2116 . I upstreamed the patch we've carried for a while, but issues due to it have been reported. Your input on that issue would be appreciated.
<RikMills> seb128 LocutusOfBorg: poppler migrated
<seb128> I saw, nice
<LocutusOfBorg> yep, good job seb128 RikMills !
<seb128> thx RikMills LocutusOfBorg!
<LocutusOfBorg> enjoy your vac!
<seb128> LocutusOfBorg, thanks :-)
<marcoceppi> I'm trying to amend some of the rpi images to work with our CM3+ images. I'd like to know how the base images are packed so I could potentially inject our changes in that process but I can't seem to find where. fginther How does CPC pack the rpi preinstalled images?
<fginther> marcoceppi, the images are built by https://launchpad.net/livecd-rootfs. Of particular interest that might help are the helper functions under 'live-build/functions'
<marcoceppi> fginther: is there any documentation on how the rpi steps are run? thanks for the pointer I'll take a look in a min
<fginther> marcoceppi, no there isn't any documentation that I'm aware of
<marcoceppi> fginther: mind if I ping you with questions? Or is there a better person wrt livecd-rootfs
<fginther> marcoceppi, rpi isn't a build I'm particularly familiar with, so there are probably better experts around, but I don't mind trying to answer specific questions
<sunweaver> Laney: hi! Do you think you could take a look at some fancy build result...
<sunweaver> https://jenkins.arctica-project.org/job/libayatana-indicator.deb+nightly/target=eoan/4/console
<sunweaver> it seems that latest GLib 2.0 in Ubuntu eoan is incompatible with its GTK-2. Is that so?
<sunweaver> (I'll be afk now, but will pick up any answer by tomorrow...)
<jdstrand> GunnarHj: done
<GunnarHj> jdstrand: Thanks!
<vorlon> rbasak: mysql-5.7 is now demotable to universe, I haven't looked if it's also removable now or if there are still revdeps
<rbasak> Ah. I forgot all about the deletion. I'll add it to my list, thanks.
<rbasak> Yes there are a bunch of reverse depends. I'll take care of them.
<RAOF> tjaalton: I've got that Kaby Lake G bug for you: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1842009
<ubottu> Launchpad bug 1842009 in gnome-shell (Ubuntu) "[Wayland] Screen blanks for a second whenever discrete GPU is powered up" [Undecided,New]
<RAOF> tjaalton: Or, rather, *not* for you, because it's probably a GNOME Shell bug.
#ubuntu-devel 2019-08-30
<alkisg> vorlon, mwhudson, hi, do I need to do anything more wrt to the isc-dhcp merge request? https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/371861
<mwhudson> alkisg: oops dropped the ball there sorry
<mwhudson> alkisg: will have a look next week
<hallyn> there's a guy with an old meizu 5 running ubuntu phone, wants to update it to ubports, but can't get it recognized by adb or fastboot on the computer, and install e.g. the terminal app because the ubuntu phone app store is gone.  What's the right channel for this?
<hallyn> i can't get into #ubuntu-phone as it's invite-only :)
<RAOF> hallyn: https://t.me/ubports might be sensible.
<hallyn> that's where he is :)  but this question is really about the old ubuntu phone, not the new ubport.
<hallyn> just looking for someone who knows about any usb unlocking that would need to be done, don't want to pollute this chan with it
<RAOF> Ah, right.
 * RAOF sees that conversation now.
<alkisg> mwhudson: np, ty
<Unit193> hallyn: #ubuntu-phone fowards to #ubuntu-touch, which you're already in, so it gives you an 'invite only' message.
<hallyn> I see - thx
<cpaelzer> ahasenack: it seems your fix for ruby2.3 is blocked in xenial blocks on a dep8 test, but from the test history it seems that glibc/2.23-0ubuntu11 has broken it but was released still
<cpaelzer> ahasenack: do you want to debug that or ask for a force badtest, for whatever reason it seems s390x only ?!
<cpaelzer> the related upload is https://launchpad.net/ubuntu/+source/ruby2.3/2.3.1-2~ubuntu16.04.13
<squishedlunch> Hello, I'm new to Ubuntu and would like to start contributing, I've setup my Launchpad account and  read http://packaging.ubuntu.com, https://wiki.ubuntu.com/MOTU, and https://wiki.ubuntu.com/UbuntuDevelopment but not sure which tickets to pick up on https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Fix/Lists%20of%20bugs, is it possible to get a mentor as a new contributor?
<tinoco> morning o/
<rbasak> vorlon`: sysbench isn't migrated and is needed for src:mysql-5.7 removal. I see you filed an armhf FTBFS in Debian; Debian then removed the architecture.
<rbasak> vorlon`: how would you like to proceed in Ubuntu? If you remove the previous armhf build it will migrate I think, and remain in sync with Debian?
<rbasak> It doesn't seem right to me that Debian "resolved" your bug by removing armhf architecture support entirely, but perhaps that needs resolving in Debian. Perhaps another bug "no armhf build" is appropriate.
<rbasak> vorlon`: the remaining reverse dependencies all have alternatives available AFAICT. Please could you take a look at removal? I can file a bug if you wish.
<cjwatson> Does anyone know what's up with the lintian regressions in http://autopkgtest.ubuntu.com/packages/l/lintian/eoan/amd64 (and other arches)?  I don't see how they can possibly have anything to do with man-db, but they're blocking man-db's migration
<cjwatson> "Runner died for ../../autopkgtest_tmp/testsuite/tags/checks/debhelper/debhelper-no-depends: cd ../../autopkgtest_tmp/testsuite/tags/checks/debhelper/debhelper-no-depends; make --trace DEFAULT_DH_COMPAT=9 failed at t/bin/build-test-packages line 375." but no explanation of why
<cjwatson> Ah, probably fixed in lintian 2.19.0 by commit f8fc4b5168073a53d0924c71883cbc0b099b6e94
<cjwatson> So just need to MIR those two perl modules I suppose
<cjwatson> Is anyone sorting that out?
<rafaeldtinoco> ocfs2-tools (1.8.5-7build1) disco; urgency=medium
<rafaeldtinoco> so, why to use build1 instead of ubuntu1 here
<rafaeldtinoco> (it was a rebuild due to soname change in a dependency lib)
<rafaeldtinoco> just curious how a SRU would look like regarding to versioning
<rafaeldtinoco> in this case
<rbasak> rafaeldtinoco: 'ubuntu' in the version string will block autosync
<rafaeldtinoco> build1ubuntu1 ? or ubuntu1 only ?
<rbasak> So we use build for no change rebuilds
<rafaeldtinoco> haaa ok. makes sense tks
<rbasak> No need to use it in an SRU
<rbasak> Though you might for a no change rebuild to make it clear I suppose
<rbasak> I can't think of it ever having come up
<rbasak> It's not common at least
<rafaeldtinoco> i see.. yep I was curious, first time I see an ubuntu only change with build only in the version
<ahasenack> cpaelzer: I can take a look at ruby's sru
<ahasenack> rbasak: did you know you are a maas maintainer? :)
<ahasenack> rbasak: https://launchpad.net/~maas-maintainers/+members
<rbasak> I am :)
<rbasak> However I don't think that team is used any more anyway?
<ahasenack> well
<ahasenack> rbasak: I just came across https://bugs.launchpad.net/ubuntu/+source/django-piston3/+bug/1842043
<ubottu> Launchpad bug 1842043 in django-piston3 (Ubuntu) "The Nonce model needs an index" [Undecided,In progress]
<ahasenack> which will get a git-ubuntu MP shortly
<ahasenack> and was wondering who could review it and sponsor
<ahasenack> ack will change that debdiff to a g-u branch
<ddstreet> Laney in order to test the change from https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/371909 can you add a github secret key for me, so i can push tests from my github repo?  I would keep it turned off all the time, except occasionally to verify changes like this, without upstream systemd having to make changes before we can test them
<paride> smoser, I dumped what I know about the ZFS bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156
<ubottu> Launchpad bug 1779156 in linux (Ubuntu Cosmic) "lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'" [High,Triaged]
<paride> I'm hitting that one a lot too :/
<rafaeldtinoco> paride: can u trace unshare() in the system until it happens ?
<rafaeldtinoco> to get who did it and why ?
<paride> rafaeldtinoco, I think that would apply to the "busy namespace mount" case, which I'm not really seeing a lot at the moment
<paride> rafaeldtinoco, I think that doesn't apply to point (3) of my comment, which is what I see happening most of the time at the moment
<paride> (just added another comment to make it clearer)
 * rafaeldtinoco checks point 3
<smoser> paride: thanks for that.
<smoser> one bit of 'qualitative' info that i have that may be similar to you.
<smoser> I almost *always* use --force and delete running containers
<smoser> almost never bother to stop containers.  start, do something, destroy.
<rbasak> Me too
<rafaeldtinoco> paride: having a zfs holds whenever this happens would be great
<rafaeldtinoco> (making lxd to output what is holding the dataset)
<paride> smoser, yeah stopping and deleting in separate steps almost always works, but most of the time I `delete --force`
<rafaeldtinoco> it could either be something upperlevel (like a snapshot being deleted in bg holding the attempt of removal)
<paride> rafaeldtinoco, I think stgraber's point is that the kernel shouldn't report it's "done" with deleting stuff (e.g. snapshots) when it's actually not
<rafaeldtinoco> paride: well most of those functions in kernel are async and if you want it to be sync you have to explicitly have a flag for it
<rafaeldtinoco> (i mean for mounting/umounting)
<rafaeldtinoco> anyway, tks for explaining it
 * rafaeldtinoco will check zfs snapshot deletion code
<paride> I guess it's what LXD is doing. I didn't look at the LXD code any deeper than looking up what "delete --force" does, which is: the same as "stop" and "delete"
<paride> rafaeldtinoco, looks like `zfs holds` is only for snapshots, while we want to delete a dataset. And I think this is racey, give that `lxd stop ; lxc delete` works
<rafaeldtinoco> gotcha
<paride> but `delete --force` does not, and `delete --force` is just the same, but done faster (IIRC)
<rafaeldtinoco> gotcha
<smoser> paride: you're saying that delete --force is just 'stop, then delete' ?
<smoser> i kind of suspected it was, from other experience. but same as you i never looked.
<paride> smoser, I did look that one and I'm pretty sure it's just a "stop and then delete"
<rafaeldtinoco> i was thinking it was something more like.. a held reference for the filesystem while last sync() is called
<rafaeldtinoco> (got this for XFS in the past, thats why)
<paride> https://github.com/lxc/lxd/blob/master/lxc/delete.go#L102
<paride> here it is: if not (not stopped) and (force) => stop
<paride> and then proceed with the deletion
<smoser> well, i wonder if a sleep(1) after line 125 would fix it
<smoser> "fix"
<ahasenack> rbasak: bryce: if one of you have a spare cycle, this should be a simple review, it's one of the 3 remaining packages blocking the migration of lxml
<ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/soupsieve/+git/soupsieve/+merge/372071
<bryce> ahasenack, I can add this review to my list for today
<ahasenack> thanks!
<rbasak> bryce, I can grab it now - I'm in between things
<rbasak> And make your list shorter
<rbasak> Done
<bryce> rbasak, ah thanks
<rbasak> vorlon: I filed bug 1842097 for you
<ubottu> bug 1842097 in mysql-5.7 (Ubuntu) "Please remove src:mysql-5.7 from the archive" [Undecided,New] https://launchpad.net/bugs/1842097
<squishedlunch> Hello, just wanted to ping the channel again to see if there were any mentorship opportunities new contributors could take advantage of? I looked through a couple tickets in Papercut and they lack context for a new person unfortunately
<bryce> squishedlunch, what are your interests?
<smoser> paride: following your reading pointers brought me http://mywiki.wooledge.org/BashFAQ/105 which has lots of nice examples of why i dont like set -e .
<squishedlunch> bryce: packaging, I havenât seen any groups or teams like cloud or python on the Ubuntu wiki, are there specific areas I can focus on other than packaging and bug fixes in packages?
<bryce> smoser, ah interesting.  I also prefer avoiding set -e, now I have a link to point at for why :-)
<bryce> squishedlunch, there's a ton going on with cloud and python, I suspect the ubuntu wiki is a bit out of date from that perspective
<smoser> bryce: https://hackmd.io/IoVN08RrQV6Hyb6ztY4kwg
<smoser> i wrote that a while ago after losing a day or so chasing some of the 'set -e' madness.
<bryce> smoser, hah nice
<smoser> that is mostly a true story
<bryce> will have to read that one too :-)
<squishedlunch> bryce: any advice on getting involved with the cloud and python stuff? Itâs a bit difficult to just pick up an issue from my perspective
<bryce> squishedlunch, packaging, bug fixing in packages, and writing dep8 tests for packages is pretty descriptive of our day to day work on the server team, so if those areas are of interest I can definitely give pointers there
<bryce> if you're interested more in python development/coding work on cloud packages, there are several teams working on things
<bryce> squishedlunch, my advice would be to do some research into what those Canonical projects are, and what tickles your fancy the most, and then start submitting pull requests / MP's / bug reports; learn what discussion channels those teams use, and frequent them; and identify who are actively working on that project, and ask what's on their todo lists
<bryce> squishedlunch, https://canonical.com/projects/ has a good list of what projects are currently under development
<bryce> "cloud" is a pretty broad category so you may want to think about what aspects are most interesting for you
<bryce> squishedlunch, also fwiw afaik there aren't going to be "formal" mentorship programs ala gsoc, but I believe most of the projects are welcoming to contributors and will give guidance on contributing
<squishedlunch>  bryce what the server team is working on sounds great and is more of what I want to learn about and get involved with, is there an up to date wiki page? Or how do you suggest I get started?
<bryce> squishedlunch, the server team wiki has a GettingInvolved page here - https://wiki.ubuntu.com/ServerTeam/GettingInvolved
<bryce> the page looks kind of dated to me, but would help you narrow down what you're interested in and we can give more up to date advice for what you want to work on once you've decided
<bryce> One task area that requires python coding that the server team needs, is writing Dep8 tests.  I don't think that task is listed on that page, but if that sounds interesting I can give more advice there.
<bryce> a lot of our cloud packages need Dep8 tests written.  These are generally pretty short scripts, usually in python or bash, that are run as part of the package build to do some package level checks (e.g. does the service initialize and run without error, etc.)
<squishedlunch> bryce: okay I will take a look at the wiki and get back to you, what time zone are you in? Iâm in PST
<bryce> I'm in PST too :-)
<bryce> I'm based in Portland
<bryce> smoser, wow that set -e issue with compounds in your blog post is esoteric, good to know.  Btw spotted a typo - disabled the error error handling.  An error in your error handling.  ;-)
<vorlon> rbasak: why are the mysql-client, mysql-server packages still built from mysql-5.7 source instead of mysql-8.0?
<vorlon> rbasak: oh - n/m, somehow there are two versions of mysql-client reported in rmadison
<vorlon> cjwatson: ^^ I wonder if there being two different versions of mysql-client and mysql-server in eoan release pocket, one in universe and one in main, might be related to your recent changes
<cjwatson> vorlon: That does seem peculiar.  Could you file a bug please?
<cjwatson> (It might or might not be - the case of two source packages building the same binary is a bit unusual
<cjwatson> )
<vorlon> cjwatson: LP: #1842121
<ubottu> Launchpad bug 1842121 in Launchpad itself "mysql-client/universe was not superseded by mysql-client/main?" [Undecided,New] https://launchpad.net/bugs/1842121
<cjwatson> vorlon: One reason I'm not totally convinced about it being due to my change is that the copy of 5.7.27-0ubuntu2 into the release pocket appears to have been after the most recent publication of 8.0.16-0ubuntu3, and then both versions would be considered "live" because there are other non-arch-all binaries from the same source that are still live
<cjwatson> That would I think have been the case before my changes too
<cjwatson> But it'll probably be necessary to set up a matching situation in the test suite in order to tell either way
<cjwatson> Anyway it's clearly less bad to have two versions present than none :-)
<vorlon> cjwatson: except I believe the "copy" to the release pocket was actually a change I made in response to component-mismatches
<vorlon> cjwatson: see https://irclogs.ubuntu.com/2019/08/29/%23ubuntu-devel.html#t21:11
<vorlon> the proposed->release copy was 6 days earlier
<cjwatson> vorlon: In which case the hypothesis that 5.7.27-0ubuntu2 would have been superseded before I landed my changes can't be supported
<cjwatson> vorlon: Because 6 days earlier than that was well before I landed my changes
<cjwatson> Indeed I see "Package has 2 live publication(s)" output from the dominator relating to mysql-client from before my most recent deployment
<vorlon> oh weird
<vorlon> ok
<cjwatson> Pretty sure this is a long-standing property of the dominator
<cjwatson> See also e.g. libnvidia-common-418
<vorlon> yeah, I see now that mysql-8.0 migrated even earlier (22Aug)
<cjwatson> Or rdkit-data
<vorlon> huh
<cjwatson> Though rdkit-data is a bit different - that case is because python-rdkit from the old source package is still hanging around and is NBS
<cjwatson> (and not removable because of rdeps)
<cjwatson> In general the dominator takes a conservative approach in such cases - I think it assumes that arch-all binaries from a source which has live non-arch-all binaries still hanging around might well be needed to satisfy dependencies or similar, and so keeps them around until there are no live non-arch-all binaries any more
<vorlon> ah, that makes sense
<vorlon> doesn't make it easier on trying to figure out if it's safe to remove.. but it makes sense :)
<cjwatson> I think I would advise not manually removing arch-all binaries in such cases.  In all possible situations there's a better solution available
<cjwatson> If multiple source packages that share binaries need to remain live, then all but one of them should stop building the overlapping binary/binaries
<cjwatson> While in the NBS-arch-dep-sibling case, the remedy is to chase up NBS
<vorlon> cjwatson: sure.  in this case, it just made it cumbersome to figure out based on reverse-depends output whether or not the mysql-5.7 source package was safely removable
<vorlon> reverse-depends already has the flaw that it doesn't filter out reverse-dependencies of a binary listed in debian/control that is no longer provided by this source package in the archive
<vorlon> having cases where the binary package is actually still provided by the source package in the archive /but not the current version of the binary/ just makes it weirder :)
<cjwatson> Perhaps we should have a report for overlapping binaries?
<cjwatson> (Also, I've just had the horrible realisation that it's beginning to sound like I actually understand the dominator)
<vorlon> if it were strictly a report of overlapping binaries that are currently published, that could be useful
<vorlon> I don't want a list of all the source packages that will fail to upload because they try to build binaries that are older than the version from a different source that has taken it over; that list would be noise
<cjwatson> Those should be identical if people haven't gone removing binaries by hand without correcting the source packages :P
<vorlon> cjwatson: I thought the dominator behavior you described was limited to arch: all though?
<vorlon> which would explain why e.g. process-removals of a package that Debian has removed as "obsolete source" doesn't show us removing any binaries
<cjwatson> I think it is
<cjwatson> FWIW the dominator's current log whinges for eoan{,-proposed} are https://paste.ubuntu.com/p/XrSXtPxK4v/ .  You can probably ignore any cases where the number of items under "Live versions:" is less than the number of live publications reported, as that's likely about to be corrected by domination
<cjwatson> So not really a great basis for a report, but gives you a general idea
<Unit193> If one were to sync squashfs-tools, eoan wouldn't ship with a git snapshot.
#ubuntu-devel 2019-09-01
<maks_piechota> Hi guys, do you know if Ubiquity project has its own irc channel? I have few question regarding building it
#ubuntu-devel 2020-08-24
<moguimar> Hey there, I'm trying to submit a PPA for a backport to focal but I'm struggling to get the steps right.
<moguimar> Is it possible to do it from an ubuntu docker container?
<moguimar> I might be missing some tools or files in place
<moguimar> the bug in question is https://bugs.launchpad.net/ubuntu/+source/memcached/+bug/1887943
<ubottu> Launchpad bug 1887943 in memcached (Ubuntu Focal) "[SRU] TLS is not enabled for memcached>=1.5.13" [Wishlist,Triaged]
<seb128> who maintainers packagtes.ubuntu.com?
<Unit193> Rhonda?
<Unit193> I believe with efforts from Laney, why what's up?
<cjwatson> The_LoudSpeaker: See https://dep-team.pages.debian.net/deps/dep3/, under "Author or From"
<seb128> Unit193, the selectors default to eoan, would be nice to change to focal
<ahasenack> good morning
<ahasenack> I'm starting my +1 maintenance week today
<rafaeldtinoco> ahasenack: morning and g'luck =)
<ahasenack> hi rafaeldtinoco
<LocutusOfBorg> smb, xen merge from debian please?https://launchpad.net/ubuntu/+source/xen/4.11.3+24-g14b62ab3e5-1ubuntu3
<ahasenack> tjaalton: hi, I re-uploaded the two ubuntu-meta packages with the bug in the changelog now
<tjaalton> ahasenack: cool, I removed the old one from the queue earlier today..
<ahasenack> I got the emails, thx
<tjaalton> can't help with main promotions or such
<tjaalton> maybe the new base-files need to go through new first before reviewing -meta..
<ahasenack> right, or else proposed will be more broken than usual
<tjaalton> yep
<ahasenack> vorlon: hi, when you are around, there is that motd-news/ubuntu-meta sru available :) The motd-news-package needs accepting and promoting to main
<ahasenack> hi teward, around? I was away on holidays for a week and didn't get to the nginx merge, I was wondering if you planned to work on it or if I can/should pick it up?
<ahasenack> sil2100: hi, you are my +1maint buddy today?
<ahasenack> only us two I think?
<ahasenack> rbalint: hi, are you working on golang-protobuf wrt proposed migration?
<ahasenack> I'm starting my +1maint shift today
<sil2100> ahasenack: yes! Was working on dnspython right now, trying to drill down to if the autopkgtest IPv6 infra is weird or if it's broken for IPv6 here in overall
<sigv> Not sure if OT, but.. is there any way I can try and push forward a sponsorship/merge request? #1892110
<sigv> Is there anything I can do to ensure that it gets picked up, is what I am asking, I suppose.
<sigv> ubottu does not seem to pick up a # number by itself it seems.. https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/1892110
<ubottu> Launchpad bug 1892110 in debmirror (Ubuntu) "Please merge debmirror 2.33 (universe) from Debian testing (main)" [Wishlist,Confirmed]
<ubottu> sigv: I am only a bot, please don't think I'm intelligent :)
<slashd> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<slashd> !dmb-ping rbasak ddstreet sil2100 tsimonq2 teward
<ubottu> slashd: I am only a bot, please don't think I'm intelligent :)
<LocutusOfBorg> smb, I uploaded a merge, please double check if you can :)
<vorlon> ahasenack: binary NEW done for motd-news-config (and no promotion needed fwiw, the binaries were in main by default based on source package component)
<ahasenack> vorlon: \o/
<ahasenack> vorlon: ubuntu-meta I re-uploaded with the bug number in d/changelog which I had forgotten for x and b, and that tjaalton rejected friday
<vorlon> ahasenack: bionic: changelog says depends, control says recommends.  which is it meant to be?
<ahasenack> oh my
<ahasenack> it was recommends, then we talked and changed to depends
<ahasenack> you say just changelog says depends?
<ahasenack> seed change is depends too
<ahasenack> xenial is depends
<ahasenack> bionic is recommends :/
<ahasenack> focal is depends
<ahasenack> so just b needs fixing
<ahasenack> vorlon: fixed, uploading
<Unit193> rbasak: Got an update for the dmb-ping factoid?
#ubuntu-devel 2020-08-25
<rbasak> Unit193: no the current set is correct, thanks
<Unit193> Ah, OK.  I just saw the message from slashd and wondered.
<rbasak> I think he was trying to ping just the remaining people not at the meeting
<rbasak> But specifying them individually made the dmb-ping part moot :)
<slyon> Hey! Could any core-dev please trigger this test for me? It seems to be flakey and passes reproducibly in a local autopkgtest VM: https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=ranger&trigger=sensible-utils%2F0.0.13 (same for s390x please)
<seb128> slyon, hey, sure, retried
 * RikMills aborts
<RikMills> slyon: ps, as ranger is in universe, a MOTU could have as well
<slyon> thanks seb128!
<seb128> np!
<slyon> Also, thanks RikMills for this hint!
<slyon> RikMills: The ranger/amd64 test passed, but I guess s390x needs another try... Could you trigger that for me? https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=ranger&trigger=sensible-utils/0.0.13
<RikMills> slyon: done
<slyon> RikMills: thank you!
<RikMills> slyon: np, and it passed :)
<slyon> yay \o/
<ahasenack> good morning
<ahasenack> rbalint: hi, did you see my ping yesterday about protobuf?
<cpaelzer> rbalint: do you happen to know about recently livecd-rootfs tests all breaking on
<cpaelzer> Unexpected seeded snap for ubuntu-cpc:minimized build: lxd=4.0/stable/ubuntu-20.04
<cpaelzer> seems quite unrelated to the uploads that it blocks
<cpaelzer> There is a good run "in between" that found the very same snap
<cpaelzer> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/l/livecd-rootfs/20200814_140408_fec2b@/log.gz
<cpaelzer> snap: found lxd=4.0/stable/ubuntu-20.04
<cpaelzer> but did not complain/crash
<cpaelzer> hrm that working one was 2.664.5 and that is in focal-updates - so I was assuming that is used
<cpaelzer> but in the failing test I see
<cpaelzer> Get:34 http://ftpmaster.internal/ubuntu focal-updates/main amd64 livecd-rootfs amd64 2.664.4 [80.6 kB]
<cpaelzer> published yesterday 2020-08-24 19:28:43 CEST
<cpaelzer> yeah should be https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1889470 then
<ubottu> Launchpad bug 1889470 in livecd-rootfs (Ubuntu Focal) "snap seed with channel breaks ubuntu-cpc:minimized builds on focal" [Undecided,Fix released]
<cpaelzer> just need to find why it doesn't use the new package yet
<cpaelzer> ok the test was on proposed of 664.5 and the others before release
<cpaelzer> I'll retrigger all the waiting ones as nothing is in the queue yet
<cpaelzer> That leaves me with systemd-fsckd (on focal this time) and not reproducible locally
<cpaelzer> rbasak: are we in focal still on "retry until success" for those? Or are these also a symptom of https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1892358/comments/1 ?
<ubottu> Launchpad bug 1892358 in qemu (Ubuntu) "autopkgtest success rate dropped inhibiting proposed migration" [Undecided,Confirmed]
<cpaelzer> rbalint: and if so will you mark it there flaky as well or something else?
<seb128> cpaelzer, is systemd-fsckd supposed to be fixed in groovy now? I retried the plymouth tests with the systemd version in proposed yesterday but that ended up still failing
<seb128> rbalint, ^
<cpaelzer> seb128: no not yet, the link I had waits for an upload to systemd AFAIK
<seb128> ah ok, good
<seb128> cpaelzer, since I've a reply here, unsure if you saw I asked you on -desktop about bug #1892358
<ubottu> bug 1892358 in qemu (Ubuntu) "autopkgtest success rate dropped inhibiting proposed migration" [Undecided,Confirmed] https://launchpad.net/bugs/1892358
<seb128> cpaelzer, is there any work expected from e.g glib?
<seb128> or did you just add those for referencing on the by team report?
<cpaelzer> seb128: I add packages I see blocked by the systemd tests
<cpaelzer> seb128: that way the update-excuse tag will be linked in excuses
<seb128> technically those tasks are invalid
<seb128> right
<cpaelzer> and we can avoid everyone spending hours to find the same issue over and over
<seb128> it's slightly annoying because they end up as being targetted but not assigned items which are red flag in our team reviews
<cpaelzer> I tried setting invalid once, then the link in excuses goes away
<seb128> right
<seb128> hum
<seb128> unsure what to do in those cases :/
<cpaelzer> if one ready through the bgu comments I'm clearly saying that we added them for tracking of the actual systemd bug
<cpaelzer> and on that I'm waiting for rbalint to add the mentioned flaky flag for systemd-fsckd
<seb128> right, still they are on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html
<seb128> which add noise to the report
<seb128> and we usually try to drive our section to 0 in our weekly meeting
<cpaelzer> yeah because the underlying issue is release important and got added the tag
<seb128> I've no good idea how to get the referencing without the rls report noise
<seb128> oh well, hopefully rbalint fixes the systemd issue by next week and we can ignore that problem until next time :-)
<cpaelzer> Laney: do you happen to know a state we could set for all but systemd on bug 1892358 that will remove them from other overviews (as they are not really issues), but still get the linking due to the update-excuse tag?
<ubottu> bug 1892358 in qemu (Ubuntu) "autopkgtest success rate dropped inhibiting proposed migration" [Undecided,Confirmed] https://launchpad.net/bugs/1892358
<seb128> cpaelzer, he's off this week
<seb128> and I'm pretty confident we can't do that today, we would need to add some other way to reference on the proposed report
<cpaelzer> seb128: and for plymouth https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1886886
<ubottu> Launchpad bug 1886886 in systemd (Ubuntu) "Plymouth 0.9.5 release" [Undecided,In progress]
<ahasenack> sil2100: hi, I'm getting a 500 error when trying to login on bileto
<cpaelzer> ahasenack: I'm still logged in and things work, can I do anything for you until sorted out?
<cpaelzer> I feel like I had that issue in the past /me tries to remember
<ahasenack> well, I wanted to create a ticket
<cpaelzer> ahasenack: tell me what you need and I'll create it
<ahasenack> cpaelzer: create one for nginx dep8 please
<seb128> cpaelzer, right, I saw that one and rbalint landed a systemd update the same day he commented so I though that was maybe the version including the fix he mentioned
<seb128> sounds like it was not though!
<cpaelzer> ahasenack: https://bileto.ubuntu.com/#/ticket/4227
<ahasenack> 4227, ack
<ahasenack> thanks
<cpaelzer> I see the same error if I try to log in with another browser btw
<ahasenack> hang on to your cookie! :)
<rbalint> seb128, cpaelzer ahasenack sorry, i was out and apparently forgot setting that in my email. the last systemd upload should fix everything except for the livecd-rootfs revert that made fstab in lxd images invalide
<ahasenack> rbalint: hi, I wanted to ask you about the golang-goprotobuf
<rbalint> this hint should help till livecd-rootfs is fixed, too https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/389791
<ahasenack> in the ubuntu-server@ ml thread you said another package needed an update, which means also going ahead of debian there (quite a big ahead, actually).
<ahasenack> is that the plan still?
<ahasenack> and would that be the only package where we would have to do that, or is it just the tip of the iceberg? tbd?
<rbalint> ahasenack, this or vendoring things with is agains policy
<ahasenack> do we need that new protobuf?
<ahasenack> I ask because it's my +1maint week, and that package stuck in proposed caught my attention, as many others depend on it
<rbalint> ahasenack, well, google's cloud agent started the upgrades by having been rewritten in go requiring fairly fresh golang packages and this caused a chain of upgrades to not vendor things
<ahasenack> rbalint: so it's not just about vendoring, but vendoring a different version of an already existing package in the archive
<rbalint> i thing there are 2-3 more packages to upgrade and I'm staging the changes in Debian's packaging repos, too
<rbalint> ahasenack, yes
<ahasenack> rbalint: I checked salsa for that package you mentioned in the ML, I didn't see it in a branch there, is it in your personal repo area?
<rbalint> ahasenack, which package?
<ahasenack> let me get its name
<ahasenack> rbalint: golang-github-grpc-ecosystem-grpc-gateway/1.6.4-2
<rbalint> ahasenack, yes, i have not yet pushed this one because it broke, i'll when the package gets in a good shape, i'm testing it in https://bileto.ubuntu.com/#/ticket/4148
<ahasenack> rbalint: ok, so, are you back and handling this? :)
<rbalint> ahasenack, if you would like to have the wip branch i can push it somewhere
<rbalint> ahasenack, yes, definitely  :-0
<rbalint> :-)
<ahasenack> ok, sorry for the poke then, it's just as I said, I saw it in excuses, the ML thread, it's my +1week, "how bad can it be" and so on
<ahasenack> I'll slowly step back from it :)
<rbalint> ahasenack, no problem, it is in -proposed for wuite some time :-\
<rbalint> quite
<ahasenack> it's not alone there :)
<cpaelzer> rbalint: " the last systemd upload" means groovy I guess, what about focal?
<rbalint> cpaelzer, sru-s are usually prepared by ddstreet, but i guess you mean the flakiness
<rbalint> cpaelzer, as i look at the last runs the latest focal systemd upload got flakier without a change in systemd so it may be an infra issue or needs more investigation
<cpaelzer> rbalint: do you want a new bug about it for you and ddstreet then?
<cpaelzer> to focus the discussion in one place I mean
<rbalint> cpaelzer, LP: #1892358 is not open against focal so i think just adding focal would be enough
<ubottu> Launchpad bug 1892358 in qemu (Ubuntu) "autopkgtest success rate dropped inhibiting proposed migration" [Undecided,Confirmed] https://launchpad.net/bugs/1892358
<cpaelzer> ok
<ijohnson> hmm does anybody know why there is no reply button on https://discourse.ubuntu.com/t/why-is-snapd-both-a-deb-and-a-snap-in-focal/18022 ? I don't think the question is a support request, it is a question about snapd and I can explain the reason why the OP sees what they do, but erm I can't reply to it :-/
<danboid> Been hit by that F^&n GRUB bug :/ Anyone know what date the dodgy GRUB package hit the repos? End of July?
<danboid> I use Landscape for updates so stuff gets updated daily
<danboid> but just tried rebooting our Azure 18.04 web server and ... nope
<danboid> I've just tried using a recovery VM to reinstall GRUB but I obvs don't understand Azure disks and snapshots well enough yet
<danboid> The bug was reported on 30th July but I'd like to know when the dodgy GRUB hit the repos
<danboid> (for 18.04)
<rbasak> danboid: https://launchpad.net/ubuntu/+source/grub2/+publishinghistory
<rbasak> "whent he dodgy GRUB hit the repos" is ambiguous because I think the bug was already there, and the update revealed it?
<rbasak> Anyway, the publishing history there will give you the exact timestamps. The mirrors lag a little behind the publishing timestamps.
<danboid> rbasak, Yeah OK, thats part of what I needed to know, it should help anyway
<danboid> rbasak, What do you mean "the update revealed it?"
<rbasak> danboid: AIUI, the systems that the grub update "broke" were already broken such that a subsequent grub update would fail.
<rbasak> Bug 1889556 has some details I think
<ubottu> bug 1889556 in grub2 (Ubuntu Groovy) "grub-install failure does not fail package upgrade (and does not roll back to matching modules)" [Undecided,Fix released] https://launchpad.net/bugs/1889556
<rbasak> That's why the regression wasn't detected before the update was released - the update itself wasn't buggy. It revealed a problem that had already occurred on some systems that made those systems unbootable.
<danboid> rbasak, So the version to revert before would be 2.02~beta2-36ubuntu3.26
<rbasak> I'm not sure, sorry.
<rbasak> As I say, just reverting isn't necessarily sufficient.
<rbasak> Also see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass#Known_issues
<rbasak> I don't know the details in all of this - I'm just an observer
<rbasak> I think if you follow those steps you don't need to revert
<danboid> rbasak, It should be possible for me to fix this by using an Azure recovery VM to reinstall GRUB on this VM but I've just tried that and I'm having issues getting the correct drive to mount and detaching it afterwards
<danboid> I don't have much experience with Azure
<danboid> Even when my recovery VM is stopped, its not letting me detach the disk etc
<rbasak> danboid: I can't help, sorry. Try #ubuntu for user support
<danboid> rbasak, I'm trying in #azure now. Thanks
<danboid> I've never had any luck in #ubuntu asking anything btw :)
<rbasak> danboid: maybe #ubuntu-server. If the answer isn't widely known then non-realtime places tend to work better, such as askubuntu.com
<ahasenack> hi, is there somebody here who can fix bileto login? I'm getting a 500 error when I try to login
<sil2100> tseliot: hey! I have a question regarding the libnvidia-compute-* packages - so I was trying to resolve why the new nvidia-cuda-toolkit stuff didn't want to migrate
<sil2100> tseliot: and it seems the general problem boils down to pyhst2 not being able to build on ppc64el now, as I think none of the nvidia-graphics-drivers-*-server packages provide a libnvidia-compute-* package for ppc64el (so it can't find libcuda.so anywhere)
<sil2100> tseliot: do you know if there's any ppc64el story for those still?
<mwhudson> good morning
#ubuntu-devel 2020-08-26
<teward> RAOF: I think the removal of those packages for py3.8 lack of support has caused a number of other more... concerning... regressions?
<teward> or is this still the same issue?
<RAOF> "teward" (https://matrix.to/#/@freenode_teward:matrix.org): what do you mean? It shouldn't have resulted in anything being broken that wasn't before?
<teward> unless i can't read right
<teward> RAOF: only seeing the latest messages in the chain because my email server asploded
<teward> so my bad
<RAOF> Good, good.
<teward> ah right you yanked those packages from proposed
<teward> i was looking for the debdiff'd packages 'cause im' bored :p
<teward> i should probably do that in the morning instead of at 00:48 :p
<teward> *goes to pass out in bed*
<RAOF> ð¤
<ginggs> sil2100: pyhst2's ppc64el binaries have already been removed from -release.  pyhyst2 is now blocked by nvidia-graphics-drivers-450, which is blocked by linux restricted modules
<ginggs> I think removing pyhst2's binaries on amd64 will allow nvidia-cuda-toolkit to migrate, and pyhst2 can migrate when n-g-d-450 and l-r-m are sorted
<ginggs> i'll ask in #ubuntu-release
<teward> RAOF: do the autopkgtests for the affected regressed packages need fixed or is it the packages which were yanked from proposed that need fixed, on that py3.8 thing
<teward> s/thing/issue/
<teward> asking because reasons :)
<AsciiWolf> kenvandine, hi, https://bugs.launchpad.net/snap-store-desktop/+bug/1873040 - is there any chance this issue will get fixed? :) and is there any way I could help? I am not a devel, but I can do testing, debugging etc.
<ubottu> Launchpad bug 1873040 in snap-store-desktop "Source for deb apps in dropdown menu is empty" [High,Confirmed]
<AsciiWolf> however, when I tried debugging this issue the last time, there was nothing in verbose logs and I was not able to find anything related to why the deb menu is empty :/ anyway, feel free to ping me if you want any help with this issue... it would be great if this was finally fixed :)
<kenvandine> @AsciiWolf yeah, we plan to fix that.  It's not trivial and we have other priorities ahead of it
<udevbot> Error: "AsciiWolf" is not a valid command.
<kenvandine> AsciiWolf yeah, we plan to fix that.  It's not trivial and we have other priorities ahead of it
<tumbleweed> 7/32
#ubuntu-devel 2020-08-27
<RAOF> teward: The autopkgtests for the affected regressed packages need to be fixed; the packages themselves were (I think) fine.
<RAOF> teward: In other words: pyflakes et al will not be able to be released from -proposed to -updates until any autopkgtest failures they trigger get resolved.
<niub> o/ question: I need dh-virtualenv to build a package for focal but it seems dh-virtualenv isn't available for focal
<niub> is there any alternative package that I can use or that replaces dh-virtualenv in focal?
<juliank> Eickmeyer: Your sync of lsp-plugins broke upgrades, as I stated in bug 1888684, can you fix that?
<ubottu> bug 1888684 in lsp-plugins (Ubuntu) "lsp-plugins-jack: trying to overwrite '/usr/lib/lsp-plugins/lsp-plugins-r3d-glx.so', which is also in package lsp-plugins-common 1.1.22-0ubuntu1" [Critical,Confirmed] https://launchpad.net/bugs/1888684
<juliank> I'm not involved with this package, but this needs to adds Breaks/Replaces at the very least
<juliank> either do this downstream or see if Debian is willing to carry that
<juliank> Perhaps subscribe some ubuntustudio bugs thing to it
<juliank> given that it is seeded in ubuntustudio-audio, some team really should be subscribed to it
<dgadomski> hey sil2100, whenever you have a moment I'd appreacite taking a look at systemd and rpcbind uploads in the xenial upload queue
<sil2100> dgadomski: hey! Sure
<Eickmeyer> juliank: Looks like upstream already has a fix: https://salsa.debian.org/multimedia-team/lsp-plugins/-/commit/82cbd0b0fb76de83cd18bf97ea587785a606f905
#ubuntu-devel 2020-08-28
<paride> xnox, hi!
<paride> the groovy-live-server-amd64 images are failing the static validation because they don't have /EFI
<paride> however they seem still be able to boot in UEFI mode
<paride> /sys/firmware/efi exists, so it's actually UEFI booted
<paride> did anything change in the image layout?
<paride> likely https://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/revision/2078
<xnox> paride:  depends how the .iso is mounted and validated. if one parses it with isofs tools, one should be able to see /EFI dir.
<xnox> hm, i can't seem to list them statically, only interractively
<xnox> i.e.
<xnox> sudo qemu-nbd -c /dev/nbd3 ./groovy-live-server-amd64.iso
<xnox> sudo mount /dev/nbd3p2 /mnt
<xnox> # ls /mnt/efi/boot/bootx64.efi
<xnox> /mnt/efi/boot/bootx64.efi
<xnox> =/
<xnox> mwhudson:  do you know about any commandline switches that allow viewing the "hidden" esp?
<paride> utah does it via `bsdtar -tf file.iso`, while I just loopmounted the iso
<xnox> yeah, /efi/ is not on /dev/nbd3 nor nbd3p1, only in nbd3p2
<ahasenack> rbalint: hi, are you preparing a bionic glibc sru?
<paride> xnox, it's not only the validation on the file list that's failing, it's also the secureboot signature verification on the efi binaries
<paride> which again are normally extracted using bsdtar
<xnox> paride:  note, that having these files three times over, in all three places, instead of just 1, tripples & uses up disk space. I.e. extra copies of grub.
<xnox> paride:  plus the one extracted with bsdtar is not the one seen/used by firmware.
<paride> I'm totally +1 and not asking to revert the change :)
<paride> but I'm trying to figure out an alternative way to extract them
<paride> from the "right" place
<paride> (also I'm missing what's the third place. There's /EFI in the main filesystem which is now gone, a more or less true ESP I suppose, and ... ?)
<rbalint> ahasenack, yes, please check progress at  LP: #1851263 , why?
<ubottu> Launchpad bug 1851263 in glibc (Ubuntu) "Ubuntu 18.04.3 LTS bump Glibc 2.27 to the latest stable" [Undecided,Confirmed] https://launchpad.net/bugs/1851263
<ahasenack> rbalint: it would be cool if https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864 could be included in it. The SRU bug has a good test script, the patch is upstream
<ubottu> Launchpad bug 1864864 in glibc (Ubuntu Bionic) "[SRU] pthread_rwlock_trywrlock results in hang" [Undecided,Triaged]
<ahasenack> I just now saw your sru is about a bump, so looks like it will include that fix
<jibel> ahasenack, Hey, we've been struggling a bit with realm and sssd on Ubuntu Desktop. I filed bug 1893438. Could you have a look and help us with this?
<ubottu> bug 1893438 in sssd (Ubuntu) "Cannot resolve users without an existing /etc/krb5.conf " [Undecided,New] https://launchpad.net/bugs/1893438
<ahasenack> sure
<ahasenack> it's weird you don't have a krb5.conf, that's part of the kerberos libraries
<didrocks999> we looked at a lot of code for it today: adcli, realmd, sssd (ad provider), but we canât spot where it diverges from a working configuration
<rbalint> ahasenack, as i see the fix did not make it the 2.27 branch which i'm backporting :-\
<didrocks999> ahasenack: there are temporary ones which are removed by adcli and realm (but stocked temporarly), they are not supposed to be generating a /etc/krb5.conf
<didrocks999> (and this is indeed the case in other distro like fedora, no /etc/krb5.conf)
<rbalint> ahasenack, could you please refresh the mp and file it against https://code.launchpad.net/~rbalint/ubuntu/+source/glibc/+git/glibc/+ref/ubuntu/bionic-full-backport ?
<ahasenack> didrocks999: I'll check
<didrocks999> thx :)
<ahasenack> rbalint: will do
<rbalint> ahasenack, apparently i missed it when looking for fixes to include :-(
<ahasenack> rbalint: what's your timeline?
<rbalint> ahasenack, the current upload has been tested in bileto and i need to check the failed cases for real regressions, then i'd have uploaded it ~next week
<rbalint> ahasenack, if there are no regressions i'll pick this fix, rebuild glibc again and ask upload the SRU
<ahasenack> rbalint: have you tried already? I'm in a call, then there is another one, then lunch, then I could look at rebasing the mp
<rbalint> ahasenack, so i'll get to that ~next week
<rbalint> ahasenack, i have not tried that fix, just looked at the diff
<rbalint> ahasenack, thanks!
<ahasenack> vorlon: nginx-full seems fixed?
<ahasenack> it was in composed mismatches earlier today, now it's not (the new upload migrated)
<vorlon> ahasenack: huzzah!
<ahasenack> :)
<Eickmeyer> rafaeldtinoco: Are the scripts for the packagesets from seeded packages run manually? I was under the impression they were done weekly. Basicaly, I've been waiting for a week to update a package, have another package that needs to be updated, they're seeded by Ubuntu Studio, but not in the packageset.
<rafaeldtinoco> Eickmeyer: they are supposed to be running weekly but I think I disabled it because I was documenting it (last DMB meeting wise)
<rafaeldtinoco> I can run it for you now
<rafaeldtinoco> and will enable it again
<Eickmeyer> rafaeldtinoco: Ok, thanks. :)
<rafaeldtinoco> of course!
<rafaeldtinoco> Eickmeyer: funny, it does not show me any changes :\
<rafaeldtinoco> which packages are you dealing with ?
<Eickmeyer> rafaeldtinoco: jack-mixer and plasma-wallpaper-dynamic (in the near future).
<rafaeldtinoco> Eickmeyer: alright, there was an issue on my end, if not done automatically in about 1h will do it manually to unblock you
<rafaeldtinoco> feel free to ping me anytime also if you notice sets arent being updated for you
<rafaeldtinoco> ;)
<Eickmeyer> rafaeldtinoco: Ok, thanks. I'll report back in an hour if I'm still unable to update jack-mixer.
<rafaeldtinoco> Eickmeyer: (just because I wanted it tested also, orelse i would do it right away)
<rafaeldtinoco> last commits are
<rafaeldtinoco>     Add redkite to ubuntustudio per request
<rafaeldtinoco>     Add bchoppr and bslizr to ubuntustudio as exceptions
<rafaeldtinoco> i want to make sure what we have works for u
<ahasenack> jibel: I added some notes to the bug. we can setup a shared screen troubleshooting if you want
<ahasenack> or if I could have access to the machine, that would also help
<jibel> ahasenack, thanks, I'm EOD now, we can do that early next week if it's okay with you.
<ahasenack> sure
<ahasenack> rbalint: I cloned your glibc branch/repo, HEAD is 53355d323f2efd8c259836a569c385d5cbbadbb0, and the quilt patches to not all apply, is that expected? Or is the branch out of date?
<Eickmeyer> rafaeldtinoco: Ok, those exceptions should be seeded now, so those exceptions could go away if you want. redkite is in the supported seed and bchoppr and bslizr are now in the audio plugins seed. Hopefully this next run will pick that up?
<ahasenack> oh, wait
<rafaeldtinoco> if I remove them from exceptions, yes
<ahasenack> that branch has no source code in it
<rafaeldtinoco> Eickmeyer: from this process, what takes long time (still doing) is the germinate process
<rafaeldtinoco> calculating all pkg dependencies from all seeds
<Eickmeyer> rafaeldtinoco: Ok, that's fine.
<ahasenack> rbalint: https://code.launchpad.net/~ahasenack/ubuntu/+source/glibc/+git/glibc/+ref/include-fix-for-1864864
<ahasenack> rbalint: sent you an email too
<Eickmeyer> rafaeldtinoco: Yep, still getting rejects for jack-mixer and plasma-wallpaper-dynamic.
<rbalint>  ahasenack thanks, will check it next week!
<ahasenack> rbalint: cool, ping me if needed
<Eickmeyer> rafaeldtinoco: Any progress on this? I now have both packages ready for upload with minor bugfixes.
<rafaeldtinoco> lemme check
<rafaeldtinoco> Eickmeyer:
<rafaeldtinoco> https://www.irccloud.com/pastebin/Bv9tFcW1/
<rafaeldtinoco> Eickmeyer: is this ok
<Eickmeyer> rafaeldtinoco: Yeah, that's perfect.
<rafaeldtinoco> pushing changes
<rafaeldtinoco> Eickmeyer: done
<rafaeldtinoco> sorry for delaying you
<Eickmeyer> rafaeldtinoco: It's all good. Today was the first day I had to work on anything and I was bombarded with a few updates being pushed my way, so i'm glad we got it straightened out. :)
<rafaeldtinoco> just ping if/whenever needed
<Eickmeyer> rafaeldtinoco: Will do. Thanks again!
<rafaeldtinoco> my cell always gets highlights #)
#ubuntu-devel 2020-08-29
<LocutusOfBorg> Adri2000, your ubuntu patch for filezilla didn't apply since some time
<LocutusOfBorg> https://launchpadlibrarian.net/491397627/buildlog_ubuntu-groovy-amd64.filezilla_3.49.1-1_BUILDING.txt.gz
<LocutusOfBorg> but for a packaging bug it was not discovered
<LocutusOfBorg> look for 11_use-decimal-si-by-default.patch in the log
<LocutusOfBorg> I dropped it all, feel free to upload a new version if you still care
#ubuntu-devel 2020-08-30
<mwhudson> xnox, paride: huh did my change to make this more like it used to be get merged?
<mwhudson> vorlon, stgraber, Laney, etc: https://code.launchpad.net/~mwhudson/debian-cd/document-xorriso-options/+merge/387015 and https://code.launchpad.net/~mwhudson/debian-cd/half-the-grubs/+merge/387085 please?
