#ubuntu-devel 2005-01-03
<sivang> just did an upgrade. weather applet is b0rked.
<sivang> and also the window that offers to "delete from panel" the applet.
<sivang> wooo everybody notice the all new rocking weather applet? much more locations per each country!
<sivang> rocking!
<sivang> it also has indications now for day/night time
<sivang> it's not b0rked btw, I just had to remove them and readd them 
<amu> strange d-i ppc has no 2.6 supportC[C[C[C[C[C[C[C[C[C[C[C[C[C[C
<ogra> [C ?
<amu> kapute umlauts :) 
<ogra> hehe
<ogra> mine or yours ?
<amu> mine :) 
<ogra> there were several requests on helping out with kubuntu in #ubuntu last night.... are you the person to point to amu ? or is it haggai ?
<amu> well the liveCd for amd64 was done 2 min. i sit for ppc now 3h :) 
<ogra> heh, 64 bit...
<amu> ..ooo i just spend some time to boost it up :) help if i can, haggai manage it. 
<ogra> ok
<amu> echo "Kernel $(KERNELMAJOR) not supported yet"
<ogra> :(
<amu> ogra: the new live looks cool, yesterday i builded a horay and with d-i X started :) found some problems with mouse sound and net, finally he hole thing looks smart.
<ogra> sounds great ... :)
<ogra> i got my screensaver hack working with xft and half way with utf8 now :) learned a lot the last week ...
<amu> it looks great :) as i said amd64 needs 2 minutes
<ogra> d-i just works ?
<amu> yep
<ogra> wow, kudos to kamion.....tell me if you need tests, got a mac here and plenty of intel machines
<ogra> amu: and kudos to you as well indeed ;)
<amu> hmm utf-8, that could be the reason why the non-latin langs looks worse, guess i've to change it to utf-8 
<ogra> i think its the policy for hoary to switch anything to utf8
<amu> ogra: cool, the problem atm is most people are away :) a automatic xconfigurator is needed, have to wait for danielS
<ogra> amu: xresprobe does it currently... it is called by the postinst script of the xserver package....not sure if this also applies to xorg, but i guess so
<amu> no prob, i use temp. the old mkxf86config 
<sivang> does anybody know how I can patch a .deb pacakge as a whole? I have a patch that spans both the changlog and a file inside the source package
<sivang> is there a "debpatch" ?
<amu> dpkg-repack?
<bob2> no
<bob2> sivang: you want to patch the source package?
<sivang> bob2: yes :)
<sivang> bob2: like in , extracting it, apply the comprehensive patch, repackage.
<bob2> the source, not the binary, right?
<sivang> bob2: is there a possibility to patch the bin pkg also? 
<bob2> er, yeah, but why?
<bob2> you patch the source, build it, install the new binary
<lamont_r> Keybuk: btw, your mum got alsa-driver_1.0.7-2ubuntu1 way wrong, near as I can tell.
<Keybuk> leave my mum out of it
<ogra> heh
<Keybuk> my mum is NOT part of Soyuz
<bob2> cockfosters.
<Keybuk> bob2: I would consider it a personal favour if you could get some new jokes by April
<Keybuk> kthxbye :p
<lamont_r> Keybuk: ok.
<mojo> Can someone migrate the python2.4-mysqldb from libmysqlclient10 to libmysqlclient14?
<mojo> And besides, is librdf supposed to be based on libmysqlclient12? If not, y not make it base on libmysqlclient14?
<wasabi> UGH
<wasabi> UGH GUH GUH i dislike .udebs
<mojo> fabbione: sorry to make u wait, I just fell sleep, is nvidia-glx working well rite now or not? some ppl said to me not, but it did work here, not really sure it's my mistake or still a bug
<Kamion> amu: d-i powerpc *defaults* to 2.6 :-)
<Kamion> amu: it definitely has 2.6 support, I did it and it was the second port after i386 to get it ...
<Kamion> wasabi: udebs are love
<wasabi> buh
<wasabi> d-i should support .debs
<wasabi> for those of us who have upgraded from floppy drives
<wasabi> All I need is curl. That's it.
<wasabi> 2 hours later I still haven't got it.
<Kamion> wasabi: *sigh* no, I read the conversation on #debian-boot and there were a hell of a lot of misunderstandings in there
<Kamion> note EXTRAFILES in the d-i build system for quick hacks like what you're trying to do
<wasabi> gah.
<wasabi> Well, actually, I was hoping it wouldn't be a "quick hack"...
<wasabi> and I could do it right.
<wasabi> For upstream acceptence. There will be a lot of situations (for sitations like mine), where preseeding,a s it is right now, isn't usable.
<wasabi> preseed/url is fairly insecure. ;0
<wasabi> where "lot" is ~= "few"
<Kamion> udebs are really easy to produce. XC-Package-Type: udeb in the control file, build-dep on debhelper (>= 4.2), install stuff into the curl-udeb temporary build tree like you would do for any standard multi-binary package
<wasabi> Kamion, I tried that... dh_* broke because i think it moved hte files, instead of copying them
<Kamion> what's wrong with wget though?
<wasabi> wget doesn't do CA validation
<wasabi> for SSL.
<Kamion> read the relevant dh_* documentation, it goes into this in a lot of detail
<wasabi> Our deployment scenario: for windows.
<Kamion> perhaps you're using dh_movefiles rather than dh_install
<wasabi> We distribute CD's. The CD's have a pub cert on them.
<sivang> Kamion: this is available on debhelpers main docs?
<Kamion> sivang: man pages
<wasabi> Different departments boot the CD, which uses DHCP to find a local isntallation server.
<sivang> Kamion: k,tnx
<wasabi> The installation server is verified against the cert and encrypted, just basic SSL. preseeding file is copied over.
<Kamion> no particular reason why you couldn't convince the d-i build process to accept a .deb though
<wasabi> User is asked for his kerberos username/password.
<Kamion> it would just, well, suck
<wasabi> well it would suck if you were trying to build floppies.
<Kamion> perhaps busybox wget should be enhanced to support SSL then
<wasabi> But, i'd venture to say, nobody that uses ubuntu does that.
<Kamion> *ahem* you don't read my e-mail :P
<wasabi> normal wget doesn't support ca cerification.
<wasabi> heh
<Kamion> I have a lot of requests for floppy support.
<Kamion> with good reasons.
<wasabi> crazy.
<Kamion> the only reason we don't do it is that I haven't persuaded the 2.6 kernel to fit onto a floppy yet
<wasabi> well, MS dropped it, and it works for them. And that's the market I'm in.
<Kamion> ok, but MS drop old hardware much more readily than I'm willing to.
<wasabi> yeah.
<wasabi> no, i follow you, it's great that it is floppiable.
<wasabi> But, for me, I really just want to Get It Done, without concerning myself with that.
<wasabi> Since it has no bearing on my situation at all.
<Kamion> sure.
<Kamion> but it should be a very trivial hack in the build system.
<wasabi> I was just lookingn around d-i for the dpkg stuff to persuade it to do a .deb. And pointers?
<wasabi> s/and/any/
<Kamion> look at build/Makefile and build/get-packages I guess, to start with
<Kamion> I mean, it just uses dpkg to unpack the packages
<wasabi> It seems to rename the .deb's to .udeb.... and then install them
<wasabi> and then promptly try to chroot
<Kamion> do the build as root
<wasabi> did.
<Kamion> fakechroot is a hideous hack and is unlikely to help you
<wasabi> still no go... slightly different error. let me find it.
<Kamion> what target were you building?
<Kamion> rebuild_* is usual
<wasabi> build_netboot
<Kamion> ok
<Kamion> AFAIK the only things that try to chroot are the demo and shell targets
<wasabi> dpkg (subprocess): unable to execute new pre-installation script: No such file or directory
<wasabi> dpkg: error processing udebs/zlib1g.udeb (--unpack):
<wasabi>  subprocess pre-installation script returned error exit status 2
<wasabi> Errors were encountered while processing:
<wasabi>  udebs/zlib1g.udeb
<wasabi> same error, but let me switch zlib1g to -udeb
<wasabi> oh wait, can't do that. Provides doesn't support versioned stuff.
<wasabi> So, zlib1g it is.
<Kamion> provides do in d-i, you were misinformed.
<wasabi> heh.
<Kamion> anna totally ignores versioning on provides
<Kamion> although whether the build system will cope, I'm not sure
<wasabi> well with -udeb it fails because of deps
<wasabi> The following packages have unmet dependencies:
<wasabi>   curl: Depends: zlib1g (>= 1:1.2.1)
<wasabi> blah blah blah
<Kamion> why don't I just put together a curl-udeb for you? it would be far easier
<wasabi> That would be super. As long as it makes it upstream. THe idea of using the .deb was to avoid maintaining my own curl package.
<wasabi> I dont want to maintain anything except a config file. ;)
<wasabi> And I'd like to venture most company's who would like to do this would think the same.
<Kamion> I'm not in the business of making promises about other people's packages; you get to submit it
<wasabi> ayup
<wasabi> will do then
<wasabi> im a bit confused where I went wrong.
<Kamion> I don't really see why EXTRAFILES is unacceptable though
<Kamion> curl will not be accepted into mainstream d-i, I suspect
<wasabi> it probably is, i just didn't know about it.
<Kamion> since it duplicates wget, and busybox wget should just be fixed
<wasabi> well, mainstream wget doesn' do ca validation either.
<wasabi> So, any preseed/url is inherentily insecure.
<Kamion> sure, no reason why that feature could not be added though
<wasabi> true.
<Kamion> apart from space, certainly
<Kamion> but it could be optional in some way
<Kamion> surely a big company doing a big deployment can just use preseed/file and do customised media?
<wasabi> That was where I started.
<wasabi> Then I realized I might have to change the preseed file later.
<wasabi> And redistributing CD's is... a big task.
<wasabi> Well, a bigger task than currently done for windows, at least.
<wasabi> Somehow I'm supposed to shoehorn kerberos into this too... but that's for another day.
<wasabi> This will be really slick when it's done, regardless.
<Kamion> sigh, curl does use dh_movefiles
<Kamion> OTOH there should be a second build for the udeb anyway
<wasabi> i'll try extrawhatever
<Kamion> (gcc -Os etc.)
<Kamion> see build/config/local for that, it has a commented-out example
<wasabi> ahh okay
<wasabi> soon as this works, im making a packages/kerberos-auth or some such.
<Kamion> cool
<mdz> morning
<wasabi> basic procedure will be, user boots, system does auto detection stuff, dhcp. kerberos-auth fires up, auths to realm... stores in a key cache. preseed retreves it's file, authenticating using the ticket, sometime during setup it uses the admin interface to create a new principal on the server...
<wasabi> not sure how I want to go about that one. Running base-config during the first boot would make it more seamless.
<Kamion> what, pre-reboot?
<wasabi> Otherwise... I've gotta hide the ticket away someplace dangerous during the reboot.
<wasabi> Yeah.
<Kamion> hm. be warned, baseconfig-udeb does not work all that smoothly
<Kamion> there are lots of difficult-to-solve problems there
<wasabi> Yeah.
<wasabi> So, just not sure how I wnat to deal with it. A ticket might survive a reboot, just gotta put it someplace other than /tmp.
<wasabi> Basically the user should only be asked for password (or creds... someday smart card) once, and creds should be stored for the duration of the process.
<Kamion> incidentally, how do you know that there isn't a trojan DHCP server on the network?
<wasabi> That's why I have to do CA validation on the preseed file.
<Kamion> fair enough, yeah
<wasabi> The CA is stored on the CD.
* Kamion is half asleep
<Kamion> an alternative might be to use apt's authentication support somehow
<wasabi> yeah, I will have to use that too.
<Kamion> (although of course that isn't implemented in d-i yet)
<wasabi> a rogue package sounds makes the entire thing pointless.
<wasabi> s/sounds/source/
<wasabi> well, guess I'll have ot wait for it then.
<wasabi> or help if I ever get a clue. :)
<Kamion> anna would be the place to start there
<Kamion> you'd have to put the key in the initrd, of course
<wasabi> Yeah, It would be built with the image.
<Kamion> doesn't work for netboot though, fundamentally you have to trust something
<wasabi> cert revocation will have to be considered at some point too
<Kamion> on the CD, you could just ignore the problem, since all the udebs are there anyway
<wasabi> but I don't want to thinka bout that just yet
<Kamion> the udebs are exactly as trustworthy as the initrd
<wasabi> Yeah. I trust the CD.
<wasabi> THe CD extends trust to the network.
<wasabi> And the network only trusts kerberos.
<wasabi> there are nifty commercial apps for windows that do all this with 2 clicks.
<wasabi> that's what im competing with basically.
<Kamion> generate a Windows installer that uses kerberos auth, you mean?
<wasabi> "please insert your windows key" *copying files* "choose your deployment server from the list"
<wasabi> Yeah.
<wasabi> A boot CD for net installs.
<wasabi> That does all the stuff just mentioned.
* Kamion nods
<wasabi> You click a button, and it pops out a CD image.
<wasabi> Hopefully this works out as I envisage it. There isn't a whole lot in the way. d-i provides most of the tools.
<wasabi> Debian provides the rest (if I could just use .debs!)
<Kamion> of course the other option is a gpg-signed preseed file
<Kamion> which would allow you to defer many of the problems to the second stage
<wasabi> preseed file has to be encrypted too.
<wasabi> can't move it across the network in clear text at least.
<Kamion> ok
<Kamion> but still, all you need is gpg
<wasabi> hmm. perhaps.
<Kamion> it might well be worth avoiding the complexity of kerberos in the first stage
<wasabi> Oh definatly. Each peice of this is going to be a seperate d-i module.
<Kamion> also gpg-signed preseed files are much more likely to be officially supported :)
<Kamion> since they're much more generally applicable
<wasabi> Hmm.
<wasabi> That might remove the ssl requirement totally.
<wasabi> just gpg encrypt it and be done
<Kamion> elmo's away at the moment, but I'm sure he'd be amenable to a gnupg-udeb
<wasabi> Hmm... okay. Here's one requirement... im not familiar enough for gpg to know if it's doable.
<wasabi> The preseed file that is retrieved, must only be readable by somebody with a username/password, which is configurable remotely.
<Kamion> not just anyone with the CD?
<wasabi> Somebody can't steal a CD to get the admin passes
<wasabi> correct
<wasabi> That's where the kerberos came in.
<Kamion> so just put a passphrase on the key?
<Kamion> (gpg)
<wasabi> that can change.
<Kamion> that seems pretty straightforward
<wasabi> In the organization, there are many levels of IT... across the country.
<wasabi> Many usere accounts.
<wasabi> Everybody designated by the server should be able to install systems.
<Kamion> you can encrypt something to lots of keys
<wasabi> And that list of people changes frequently.
<wasabi> As people come and go, etc.
<wasabi> Yeah yeah. It does move the preseed encryption to some process on the server, not just a one time thing.
<wasabi> curl lets you use gssapi auth to retrieve from http.
<Kamion> the encrypted blob itself has no value ... it's only valuable with the passphrase, and the "username" could just be used to figure out where to get the blob from
<wasabi> So, simple kerberos auth, combined with ssl, takes care of both the problems... which is why I was heading in that direction.
<Kamion> right, but since it's a more specialised solution it makes it more likely that you'll have to maintain it yourself :-)
<Kamion> I'm trying to think of more generalisable solutions.
<wasabi> The server process could update the preseed file as new people get the ability to use it.
<wasabi> gpg doesn't have any group concept, does it?
<wasabi> like, encrypt something with a "group" key, added to each user's key.
<wasabi> Sounds very ungpg like
<Kamion> um ... that's not meaningful
<wasabi> but I'm not too familiar with it
<Kamion> you can have a keyring, not just a single key
<Kamion> if you want a group key, just add that key to everybody's keyring in the group
<Kamion> or encrypt a secret key with a user's key and send that secret key to them
<wasabi> Protecting the preseed file with apache based on a ldap group membership is fairly straightforward. Not sure how that would work in a gpg situation.
<Kamion> it's orthogonal to gpg.
<wasabi> Doesn't deal with revocation though does it?
<Kamion> don't try to think of access control on downloads in the same context as gpg.
<jamesh> wasabi: how about HTTP basic auth to access the repository?
<wasabi> jamesh, I dont have a clear text password.
<Kamion> if you want to revoke an encrypted blob and you've already given out the key, the only possible answer is to not give out the encrypted blob
<wasabi> Well, I would if I kept it around.
<Kamion> a multi-level key setup could fix that though
<jamesh> wasabi: well, basic auth over SSL is not too bad, and gives you a lot of flexibility at the server end ...
<Kamion> i.e. don't give out the key, just give out the key used to encrypt a session key and decide whether to give out the session key on the fly
<wasabi> jamesh, makes future movement into the realm of smart cards hard too.
<wasabi> in fact, so does gpg. =/
<Kamion> several hardware crypto vendors support gpg
<Kamion> I used to work for one such
<wasabi> I think the samba guys are working on implementing MS's kerberos extensions to support ticket authentication using a smart card... I doubt the same thing would work with gpg.
<Kamion> apples don't work with oranges either :)
<wasabi> and the aim is to displace what exists currently, which means i am a bit limited. ;)
<wasabi> also have to fit into the existing infrastructure as much as possible.
<Kamion> you just need to make it look the same, it surely doesn't matter exactly how it works under the hood
<Kamion> if the Windows GUI is a two-click thing it can't expose much of the implementation
<Kamion> generating a key and sticking it in the right places could be entirely automated
<Kamion> anyway, as it happens, you could certainly put a key on a smart card and have gpg use it, which is equivalent to ticket auth using a smart card, if done right
<wasabi> well, just thinking of my experiences, and the best way to capture the market.
<wasabi> Because that's my goal afterall, to see Ubuntu on every desktop. ;)
<Kamion> it's all crypto. the protocol matters more than the implementation as far as making it work securely is concerned, so you're free to choose an implementation which is easiest to integrate with the software
<Kamion> of course, when multiple different software stacks are concerned, this can get amusing
<wasabi> It's just that the existing software stack on the server side is already decided and unchangable.
<wasabi> and I happen to like it too. ;)
<Kamion> only on *your* server side; other people have totally different server sides which are also decided and unchangeable in exactly the same way
<Kamion> which makes a solution tailored to your server side a poor option for general-purpose implementation
<wasabi> Kamion, well, those who use Windows to do this, all do it the same way. ;)
<Kamion> with respect, I doubt that :)
<wasabi> Well, other than Novell Netware, there is no other player in the market.
<wasabi> Active Directory.
<Kamion> my housemate's a Windows sysadmin for a university, I don't believe he uses Kerberos at all
<wasabi> Does he use Active Directory?
<Kamion> no idea
<wasabi> Because if he doesn't, he uses either Samba or Netware. :0
<Kamion> I'm not an expert in the field, I'm just extremely sceptical that the market is that limited
<wasabi> Welcome to MS-land.
<Kamion> Samba seems more likely
<Kamion> proprietary software is anything but single-player, even in MS-land
<Kamion> and anyway, Ubuntu deployments are not just about Windows replacements
<Kamion> we support Macs too, remember
<wasabi> OpenDirectory
<wasabi> Kerberos and LDAP.
<wasabi> ActiveDirectory, Kerberos and LDAP.
<wasabi> same tune differnet name.
<Kamion> ok, whatever, I need sleep
<wasabi> night. Thanks for your help. :0
<Kamion> I remain unconvinced that that's the right approach for preseeding
<wasabi> Me too. Which is why we had this convo
<Kamion> primarily because it's a huge sledgehammer to crack a very small nut :)
<Kamion> which is ALWAYS a bad idea where secure protocol design is concerned.
<wasabi> Well, that's the thing. The protocols are already in place. I just want to use them.
<wasabi> anyways. im going to get cocoa. mmm
<Kamion> wasabi: (mind you, I realise that doing the download of the preseed blob using SSL gives you protection against replay attacks more or less for free, assuming you believe in SSL. hmm.)
<mojo> I have installed libneon24, but how come all OOo still base on the old version libneon23? Can someone confirm? Or is it my mistake?
<lamont> mojo: Depends: libneon23
<lamont> Kamion: are the 20041222 daily CD's worth testing on ia64 and ppc?
<lamont> s/testing/trying to use/
* lamont sleeps
<fabbione> morning
<pitti> Morning
* pitti yawns
<fabbione> hey pitti
<pitti> Hi fabbione 
<pitti> Had a good night?
<fabbione> pitti: almost
<pitti> I was awake half of the night :-(
<fabbione> jdub: 2155 IS NOT A KERNEL PROBLEM 
<jdub> fabbione: THANKS, LET ME KNOW WHAT WE CAN DO WITH IT
<jdub> WHY ARE WE SHOUTING?
<fabbione> jdub: BECAUSE YOU ARE ON THE OTHER SIDE OF THE WORLD AND I WANT YOU TO HEAR ME!
<kergan> hahahhaha
<kergan> oh you dint hear me HAHAHAHAHHAHAHAHAHHAHAHA
<fabbione> jdub: i need you to check the hotplug / udev events and see why the device is not created.
<fabbione> jdub: the kernel is not is charge to do such task
<enrico> fabbione: #ubuntu-doc mail arrived perfectly, thanks!
<fabbione> enrico: cool
<fabbione> enrico: do you need the backlogs?
<fabbione> enrico: they are on my ~ on people
<enrico> fabbione: you mean the previous days?  No, no need to, thanks
<fabbione> goody
<enrico> fabbione: (for the records, however, I don't have an account on people.ubuntu)
<fabbione> enrico: no need to have on.e
<enrico> ah, ok
<fabbione> ever heard of that protocol that shares info on port 80? ;)
<enrico> fabbione: oh... that subversive protocol invented some time ago by those swiss terrorists that are trying to develop nuclear technology?
<fabbione> no.. i mean that protocol that is sucking all the internet bandwith in place of ftp, slowing down all my porn downloads
<enrico> fabbione: just download port from port 80 :)
<enrico> Who should I talk with to have something like a baz sandbox that we docteam could experiment and play with?
<pitti> mdz: still awake?
<pitti> Keybuk, Kamion, jdub: anybody out there?
<jdub> i am for a moment
<pitti> jdub: I /msg you
<pitti> haggai, amu: ping
<pitti> Moin mvo
<mvo> hi pitti 
<pitti> Hi seb128
<seb128> hey pitti 
<seb128> how is the security stack going ?
<pitti> seb128: today, downwards
<pitti> seb128: yesterday I got two new mails for each processed one
<seb128> :(
<seb128> people spend the chrismast holidays to find security problems or what ? 
<seb128> christmas even
<pitti> seems so
<ajmitch_> pitti: quite a pile to get through then?
<pitti> ajmitch_: yes, still
<pitti> Kamion, Keybuk, jdub: anybody here? I need a native English speaker again...
<Treenaks> I'm not a native speaker, but shout :)
<Kamion> pitti: yep
<pitti> Mithrandir: ping
<pitti> haggai: ping
<sivang> pitti: morning!
<pitti> Hi sivang!
<sivang> pitti: oops, g'afternoon :)
<seb128> mvo: there was a point to sync ncb with debian ? I thought we had all the debian changes ...
<jordi> mvo: duuuude
<jordi> mvo: I am killing you. KILLING YOUUUUUUU.
<mvo> jordi: arrggg 
* jordi sharpens knives.
<mvo> what did I do?
* jordi gets stones.
* pitti gets out of the way
<mvo> jordi: don't kill me!
* Treenaks puts up blood-proof transparent divisions
<pitti> mvo: btw, can you sync packages yourself?
<jordi> mvo: duuuude, you imported synaptic's pot to rosetta, but not the zillion existing translations, so random people are re-translating it now, apparently.
<jordi> mvo: I'm getting a brand new, not-so-good translation in Catalan :)
<mvo> jordi: argggsss ... sorry. I'll fix this
<Treenaks> mvo: same with Dutch
<Treenaks> jordi: also with lots of other programs in rosetta (gconf..)
<mvo> seb128: I think there where some "README.debian" updates in the upload I did
<seb128> mvo: ok
<jordi> Treenaks: yeh :(
<mvo> daf: around?
<Mithrandir> pitti: pong
<pitti> Mithrandir: just sent you a mail, regarding a mailman security issue
<Mithrandir> pitti: ok, will look at it.
<pitti> Mithrandir: thanks
<trulux> pitti, where cracklib looks for dicts in Ubuntu? i'm trying to build PAM with updated sleinux support and it says none found
<trulux> but already there's a one at /etc/dict.../words
<pitti> trulux: you need to install a package that provides 'wordlist'
<pitti> trulux: e. g. wenglish
<trulux> pitti, kay
<pitti> :q
<pitti> oops, wrong window
<pitti> trulux: paths are in /etc/cracklib/cracklib.conf
<trulux> pitti, ok, thanks
<nobse> hi
<nobse> having binaries from one source package in main and universe sucks
<nobse> currently, when I try to upgrade vim, vim-perl needs to get removed
<Kamion> what does that have to do with binaries being in different components?
<Kamion> unless you only have main in sources.list
<nobse> Kamion: because the new vim package comes from the security repository
<Kamion> so include warty-security universe
<Kamion> there was an oversight in warty's base-config that meant that this wasn't present as an example by default
<nobse> ups...
<nobse> indeed
<nobse> ok, forget what I said
<edulix> hey!
<edulix> which is the command to start gnome ?
<edulix> needed here to use freenx
<ross_> startx
<Treenaks> ross_: wrong window!
<ross_> which calls gnome-session at some point 
<edulix> ah ok
<edulix> let's first try to start firefox
<Simira> seb128: know I've asked this before, but how do I delete my personal contacts in evolution? 
<seb128> Simira: rm ~/.evolution/addressbook/local/system/addressbook.db ?
<Treenaks> Ctrl+A, Ctrl+D in the Contacts editor?
<Simira> seb128: I've deleted the whole address book, but it just reappears
<Treenaks> Simira: empty or full?
<Treenaks> Simira: did you kill evolution and evolution-data-server?
<Simira> Treenaks: killed evolution og dataserver, deleted addressbook catalogue, and restarted evolution
<Treenaks> Simira: so now you have the empty Personal Address Book?
<Simira> Treenaks: that the point, I haven't
<Treenaks> strange!
<Simira> yep
<lamont> Kamion: you around?
<mako> jdub: i just cribbed your attribution line.. well sort of (it's definitely jdub inspired)
<sivang> anybody seen smurfix? 
<pitti> Hi
<Keybuk> moin
<zul> hi pitti
* lamont installs a G3.  kinda slow beast, it is.
<Treenaks> coolness.. my gaim segfaults
* Treenaks runs over to bugzilla
<mdz> pitti: I just slept for 14 hours; what's up? :-)
<smurfix> sivang: yes
<pitti> Hi mdz 
<sivang> smurfix: regarding the webssite, do you have a nameserver we can use for the local domains?
<pitti> mdz: oh, now back to life? :-) 14 hours sounds good
<pitti> Keybuk: here?
<sivang> smurfix: Or just use canonical's ? 
<pitti> mdz: lots and lots of security updates today..
<smurfix> sivang: I can set one up, no problem.
<mdz> pitti: unfortunately this is not uncommon around this time of year
<pitti> mdz: but I caught up pretty well; only a php issue and this mailman issue is left
<pitti> mdz: why at this time? Why do people look for holes at Xmas? :-))
<lamont> gnome-pilot ftbfs in debian. sigh.
<pitti> $ LANG=C apt-get source xine-lib
<pitti> Reading Package Lists... Done
<pitti> Building Dependency Tree... Done
<pitti> FATAL -> Failed to fork.
<pitti> ^^^ What the hell...?
<jdub> so
<jdub> we totally need some way of marking (un)supported packages in apt and aptitude when just using the command line
<Keybuk> coloured aptitude? :p
* mvo hides
<Keybuk> mvo: you can hide, but you can't run ... wait ... reverse that
<mdz> pitti: kids with time off from school, I suppose
* pitti laughs
<pitti> Keybuk: any idea about apt-get's fork failure?
<Keybuk> sounds like you ran out of processes?!
<sivang> pitti: what apt-get fork was supposed to do?
<mdz>    pid_t Process = fork();
<mdz>    if (Process < 0)
<mdz>    {
<mdz>       cerr << "FATAL -> Failed to fork." << endl;
<Keybuk> that means fork() returned -1 doesn't it
<Keybuk> that's kinda bad in UNIX terms
<pitti> right
<sivang> lack of mem? :)
<pitti> I meant whether you have encountered this already
<Keybuk> nope
<mdz> I'll fix it to log a useful error in that case
<mdz> but I suspect ulimit or similar
<Keybuk> out of memory, resources, process handles, hit limits, etc.
<pitti> hmm, I don't think it's a resource problem though
<pitti> I can start other processes
<jdub> Keybuk: back-of-an-envelope estimate of boot time savings if /bin/sh -> dash?
<Keybuk> mdz: fork doesn't return useful errno ... mostly just EAGAIN
<Keybuk> jdub: none, didn't help
<Keybuk> (we tried it :p)
<jdub> Keybuk: ta
<pitti> Keybuk: I have five processes running on the machine and 140 MB of free memory
<Keybuk> strace it?
* pitti installs strace
<Keybuk> please tell me strace is in -base
<pitti> Keybuk: http://www.piware.de/apt-get.trace.txt
<mdz> Keybuk: of course it is
<pitti> Keybuk: this is my server and it does not run Ubuntu (yet...)
<mdz> jdub: once bash is in memory, it pretty much stays
<Keybuk> ENOMEM (Cannot allocate memory)
<Keybuk> apt's probably eaten all of that 140MB
<pitti> d'oh
<Keybuk>        ENOMEM fork  failed to allocate the necessary kernel structures because
<Keybuk>               memory is tight.
<mdz> Keybuk: apt doesn't actually allocate a lot of kernel memory :-P
<mdz> and fork uses a tiny amount anyway
<mdz> pitti: what kernel is it running?
<Treenaks> mdz: it just mmaps a lot :)
<pitti> mdz: 2.6.9
<Keybuk> uh, yeah ... fork returns EAGAIN if it's user memory that's short
<pitti> mdz: however, I just saw that I don't have a swap
<mdz> weird
<Keybuk> how odd
<pitti> btw, it works fine as root
<mdz> ulimit
<pitti> mdz: no, it isn't
<pitti> btw, now it works again
<pitti> magically
<pitti> d'uh
<pitti> thanks anyway
<mdz> mvo: are you here?
<mvo> mdz: yes
* lamont watches a dist-upgrade to hoary die a horrible mid-life crisis
<mdz> mvo: would it be a simple matter to move smartpm to python 2.4?
<mvo> mdz: does it not work with python2.4? 
<mdz> lamont: hmm?
<mdz> Depends: python2.3, libc6 (>= 2.3.2.ds1-4), python2.3-pycurl, python2.3-gtk2, python2.3-pexpect
<mdz> lamont: I just upgraded my desktop, which hadn't been touched really since before Mataro, and it was flawless
<mvo> mdz: I'll port and upload a new version
<mdz> mvo: thanks
<lamont> mdz: gimp-data had errors (scrolled off the top), and left everything bust4ed
<lamont>  python-genetic: Depends: python (< 2.4) but 2.4-0ubuntu4 is installed
<lamont>   python-geoip: Depends: python (< 2.4) but 2.4-0ubuntu4 is installed
<lamont>   python-glade2: Depends: python (< 2.4) but 2.4-0ubuntu4 is installed
<mdz> there was a gimp/gimp-data upgrade in my session, and it worked for me
<lamont> among many others...
<lamont> yeah - no real clue why it was annoyed
<mdz> lamont: your mirror is out of date
<mdz> mizar:[~]  apt-cache show python-genetic | grep Depends
<mdz> Depends: python (<< 2.5), python (>= 2.4)
<lamont> yeah - the warty version is still installed
* lamont uses some dpkg -i love on the machine.
<mdz> apt-get -f install didn't fix it?
<lamont> and adds 'install warty and upgrade' to his list of tasks for the day
<lamont> that's always scared the hell out of me.
<lamont> so I never do apt-get -f ...
<lamont> should I not be scared?
<mdz> there is no need to fear
<lamont> ok.
<trulux> ajmitch_, PAM and coreutils updated SELinux code out the box
<trulux> ;-)
<trulux> work done
<zul> dang i was doing that this morning
<mdz> mvo: it looks like the file permissions are wrong in your apt--mvo--0 tree
<mdz> I just merged from it and the permissions were reverted
<mvo> mdz: which ones? of apt-key? or in po/ ?
<mdz> mvo: po/
<pitti> Keybuk: did you deliberately made -22 days of vacation? :-)
<mvo> mdz: should be fixed in patch-10
<mvo> mdz: sorry :/
<mdz> mvo: no problem, I noticed before I committed
<mdz> mvo: please check your other trees also
<Kamion> lamont: pong?
<mxpxpod> fabbione: ping
<lamont> Kamion: I think I managed to answer my question...
<lamont> which was: any known b0rkage with 12/22 daily CD's?
<Kamion> http://cdimage.ubuntu.com/daily/20041222/report.html doesn't list anything
<Kamion> anything else, not that I know of but it's always possible :)
<lamont> cool - seems to be working on the G3, too.
<Kamion> bonus
<lamont> although I expect that X should actually _do_ something besides screen-blanking, eh?
* lamont bbiab
<lamont> hrmpf.  config-file questions from udev
<lamont> and hal
<pitti> lamont: oops? For which file (hal)?
<lamont>  /etc/dbus-1/event.d/20hal
<pitti> lamont: do you still have the old file?
<lamont> and udev was /etc/udev/scripts/{ide,scsi}-devfs.sh and cdsymlinks.sh
<lamont> probably
<pitti> lamont: this is handled by /var/lib/dpkg/info/hal.preinst
<pitti> lamont: part of the file renaming hal -> 20hal
<pitti> lamont: I added an md5sum check into the preinst
<pitti> lamont: if the md5sum does not match, you are asked
<lamont> this is dpkg, not the preinst
<pitti> lamont: I know
<lamont> I never edited any of these files
<pitti> lamont: but the preinst tries to avoid the dpkg question by removing the old file if it is unmodified
<pitti> lamont: if you still have the old version, can you please give me the md5sum of it?
<lamont> sure - waiting for the upgrade to finish
<pitti> lamont: I only check for one md5sum right now, the version from the previous package
<pitti> lamont: probably I have to add some more, for earlier versions of that file
<lamont> ah, this is either warty-release, or shortly before that - pretty sure that the machine has warty-release, but it could be a shade older
<pitti> lamont: I'm at preparing a new hal version anyway
<pitti> lamont: so this is a good time to include this patch
<lamont> ok
<lamont> 6e417ba24c2b7d49006d5dbe82717f8d  /etc/dbus-1/event.d/20hal.dpkg-old
<lamont> not sure what version taht was.
* lamont grumbles at the dvd recorder.
<pitti> lamont: it does not really matter which version that was
<lamont> pitti: ok
<pitti> lamont: it is only importand that you are sure that you did not touch it
<pitti> lamont: okay, I include this md5sum. Thanks
<lamont> 99.999% sure - this is my daughter's machine, and I can't see why or when I would ever have needed to edit that file, since I have NFC what it is, even...
<lamont> s/since/not just because/
<lamont> interestingly, dist-upgrade didn't want to replace xf86 with xorg
<lamont> xserver, that is.
<lamont> Setting up xserver-xorg (6.8.1-1ubuntu8) ...
<lamont> sh: gcc: command not found
<lamont> dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation)
<lamont> WTH??
<pitti> lamont: uploaded new hal. Please beat me up if dpkg still asks next time
<Mithrandir> it uses dpkg-architecture which uses gcc which is not installed
<Mithrandir> lamont: just kill daniels
<ogra> Mithrandir: either the pid or killall
<ogra> :P
<Mithrandir> ogra: not everything is an unix command
<ogra> heh
<seb128> Kamion: the http://cdimage.ubuntulinux.org/releases/hoary/array-2/ iso can resize a ntfs partition ?
<Kamion> seb128: yes, should be able to
<seb128> ok, thanks
<Kamion> cd 1
<Kamion> d'oh, EWIN
<Kamion> anyway, either Array CD 1 or 2 should work for that
<Kamion> probably should've gone in the announcement for 1
<seb128> ok
<RubenV> https://www.ubuntulinux.org/wiki/FrontPage/recentchanges
<RubenV> I'm getting a UnicodeEncodeError here
<RubenV> is this known?
<Kamion> haven't seen anyone else mention it
<RubenV> should i throw it into the bugzilla?
<seb128> carlos had the same problem
<seb128> non-ascii char in his name 
<ogra> me too
<RubenV> I get it also when i'm not logged in
<RubenV> and my name is "ruben vermeersch"
<seb128> hum, that's not that so
<seb128> yep, seems to be broken
<seb128> open a bug in bugzilla
<RubenV> on my way
<RubenV> added as #4948
<sivang> seb128: have you noticed the app bar shwoing the app names all shrinked?
<sivang> seb128: (the buttom panel)
<sivang> seb128: and sometimes it's not showing apps at all 
<seb128> half of the bug is http://bugzilla.ubuntu.com/show_bug.cgi?id=4918
<seb128> second half is unknown
<seb128> open a bug with a screnshoot and some details
<sivang> seb128: ok, let's check this out :)
<sivang> seb128: I don't need to create a screenshot, it's the same as here: https://bugzilla.ubuntu.com/attachment.cgi?id=924
<Treenaks> seb128: what's the bug # for the weird panel/nautilus/gnome-vfs "hangs"
<seb128> sivang: no, this bug is only about the small entries
<sivang> seb128: ah ok :)
<seb128> Treenaks: http://bugzilla.ubuntu.com/show_bug.cgi?id=4576
<sivang> seb128: gottcha
<seb128> sivang: nobody else complained about <sivang> seb128: and sometimes it's not showing apps at all 
<sivang> seb128: yes, now I know what you mean - I'll add it
<seb128> cool
<seb128> you're using a dualhead setup ?
<sivang> seb128: I used to on warty, why?
<seb128> sivang: because dualhead a some issues
<Treenaks> seb128: that bug has been fixed upstream?
<seb128> ie: app should only be on one screen, etc
<seb128> Treenaks: no
<Treenaks> Status:   RESOLVED
<Treenaks> Resolution:   FIXED
<Treenaks> seb128: looks like it http://bugs.gnome.org/show_bug.cgi?id=160955
<sivang> seb128: if I try to use it again, I'll ping you about this :)
<seb128> Treenaks: I've not updated the forward that's all
<seb128> Treenaks: http://bugzilla.gnome.org/show_bug.cgi?id=161997 upstream
<Treenaks> seb128: ah
<sivang> seb128: has people reporting this been using some switching tool or plain configured manually their xorg.conf ?
<sivang> seb128: ie : nvtv etc
<seb128> sivang: no idea. But there dualhead is kind of broken in hoary
<seb128> for GNOME at leastr
<seb128> -r
<sivang> seb128: is there anything internal to gnome that allows for dualhead setups?
<mdz> Kamion: around?
<mdz> Kamion: wondering why ssh-agent is setgid ssh
<mdz> ah, changelog says it's just for the side effects
<Kamion> mdz: yes, to stop ptrace attacks, it drops its group privilege immediately and group ssh has no other privileges anyway
* lamont decides that maybe udev and ftape aren't completely happy with each other..
<mdz> Kamion: I just noticed that ssh-agent doesn't seem to take any precautions against secrets being written to swap
<lamont> Kamion: that's a kewl bit of hackery
<mdz> Kamion: did it ever do so, or did I imagine it?
<Kamion> mdz: I don't remember it being added or removed; what kind of precautions would it need to take?
<mdz> Kamion: mlock
<mdz> Kamion: under most unices, this requires root privileges, but with Linux >=2.6.9 it doesn't anymore
<mdz> so I thought it would be nice to de-privilege-ify ssh-agent, which I genuinely believed was setuid root and used mlock
<mdz> but I discovered that I apparently dreamed this
<Kamion> guess that's why they didn't add it (how does Linux 2.6.9 prevent DoS attacks anyway?)
<mdz> Kamion: it adds an rlimit for it
<Kamion> aha
<mdz> I think there is a better reason why it isn't implemented, though
<mdz> in poking around the source, i found this in sshd.c:
<mdz>  * structure. The idea is that this structure could be locked into memory so
<mdz>  * that the pages do not get written into swap.  However, there are some
<mdz>  * problems. The private key contains BIGNUMs, and we do not (in principle)
<mdz>  * have access to the internals of them, and locking just the structure is
<mdz>  * not very useful.  Currently, memory locking is not implemented.
<Kamion> ach
<Kamion> OpenBSD has encrypted swap support, which could also be why they're less bothered :)
<mdz> is it impossible to read encrypted swap even with root privileges?
<mdz> that sounds hard
<Kamion> surely a root process can just ptrace ssh-agent
<mdz> right, but the idea is that they shouldn't stay around after ssh-agent goes away
<Kamion> sounds like you'd have to be able to invent arbitrary virtual->physical address mappings in order to retrieve stuff like that from swap at will
<Kamion> I don't know what layer encrypted swap is implemented at in OpenBSD though
<Kamion> http://www.usenix.org/publications/library/proceedings/sec2000/full_papers/provos/provos_html/
<Kamion> ah, they use volatile encryption keys
<Kamion> so even if you get the key out of kernel memory, there's an upper bound on the time for which it's useful
<mdz> thom: dude, you stole my stopwatch
<mdz> thom: I expect to see some major improvements in hoary's boot time to compensate me :-)
* Kamion contemplates forcing the mirror questions to be asked for netboot installs
<Kamion> it's incredibly annoying to watch everything being pulled from archive.ubuntu.com when I have a perfectly good local mirror
<pitti> good night, guys and girls!
<pitti> I wish you a happy Christmas
<ogra> same to you pitto
<Kamion> and USING ALL MY BANDWITH
<Kamion> +D
<ogra>  pitti
<Kamion> night pitti :)
<lamont> Kamion: I just added a rule at my firewall that blocks archive.ubuntu.com
<lamont> Kamion: sounds like a simple preeseed to me, no?
<Kamion> oh, there are any number of ways I could make it act differently, but I don't think defaulting to archive.ubuntu.com for a big download without asking is viable in the long term
<lamont> Kamion: yeah, but asking increases the number of questions by something like 20%, no? :-)
<lamont> the issue is that just because you _can_ reach archive.ubuntu.com doesn't mean that you _want_ to
<lamont> it could check and then ask if you want to use it.  get all the info if you say no to 'direct to archive.ubuntu.com'
<lamont> but you do have to get it past the 'no-questions' nazis
<ogra> couldnt that get tied to the lang or TZ  selection ?
<Kamion> lamont: I think the no-question-nazi bit is mostly for CDs
<lamont> ah, this is netinst. doh.
<Kamion> in fact I think the mirror question is *accidentally* not asked
<lamont> ISTR that it was only asked if it couldn't instantiate a connection to archive.ubuntu.com:80
<Kamion> ogra: would have to be country, and that could be used as a hint to select a default, but even then it's far from optimal
<Kamion> lamont: that's base-config post-reboot; this is choose-mirror pre-reboot ...
<Kamion> although I think choose-mirror may have some similar logic now that you mention it
<lamont> ah
<Kamion> ogra: anything that involves going out over my ADSL link is suboptimal :)
<Kamion> lamont: no, I think you're right
<ogra> Kamion: if you hide TZ papersize and mirror behind this one question ? 
<Kamion> ogra: nah, still sucks for me. archive.ubuntu.com is my closest mirror
<ogra> Kamion: ahh, ok
<Kamion> or near enough, anyway
<lamont> Kamion: while you're dinking with defaults... fix #4674, ktnxbye
<Kamion> lamont: heh
<lamont> hrm.. time to rev util-linux from upstream yet again, and then upload to ubuntu as well.
<Kamion> ogra: for some questions you can seed sensible defaults but still have to ask (e.g. the default country is picked depending on your language, but you often still have to select the country); for others you can pick the answer automatically. It's not always easy to tell
<Kamion> ogra: you might think that language and country is enough to figure out the keyboard layout automatically, and we tried that, but it got a lot of complaints ...
<lamont> Kamion: 4674 just needs to have en_US* -> letter, I think...
<lamont> Kamion: yeah - no where near enough for keyboard layout
<Kamion> and for TZ and mirrors it's particularly hairy because you might be travelling
<ogra> Kamion: norsk vs swedish .... i remember
<Kamion> if I'd been doing an install in Mataro that I'd wanted to keep around, I'd have wanted to say English and United Kingdom but have TZ=Europe/Madrid and a mirror in Spain
<lamont> Kamion: use the magic list that rosetta uses?
<ogra> lamont: you are my hero, i am waiting for such a thing since years (#4674)
<Kamion> lamont: geoip scares me
<ogra> and i'm willing to help on that one after my screensaver stuff is done
<Kamion> lamont: anyway, what was our IP in Mataro again? :-)
<Kamion> 192.168.0.*, IIRC ...
<lamont> Kamion: nah - peer IP as seen by the far end of a tcp/udp connection to 'findme.ubuntu.com' :-)
<lamont> ogra: you in US?
<Kamion> lamont: ick :)
<ogra> lamont: nope, in DE but i suffered from letter as default for years now, i know how you feel with ubuntus a4 default ;)
<lamont> ogra: yeah - I understand that A4 is the correct default in 99.9% of locations, and 60%+ of computers, but...
<ogra> lamont: come on, you had 10 years of letter, now its our turn ;)
<lamont> ogra: I just want it to pick based on locale, that's all.
<lamont> and I think en_US* is all that should be letter, but I'm willing to be wrong on that...
<ogra> lamont: yep, the right way imho
<lamont> actually - it should query the default printer and see what size paper it has in it...
<ogra> lamont: hmm, needs some gnome-print improvement i guess
* lamont considers updating the preseed file on his custom install CD's.
<lamont> but that would be, well, wrong.
<ogra> heh, sure
<Kamion> so, does python-minimal want to get Essential: yes in its control file?
<Kamion> noting that, once we do that, changing its name EVER is *really hard*
<calc> also once something is essential it no longer needs to be depended on, right?
<calc> so it will have to be essential forever
<Kamion> in practice that only really applies to the stuff that's been essential for ages, as you still have to support upgrades
<Kamion> I think that's the plan in Ubuntu though
<Kamion> and since it's an Order From On High I'm certainly not going to worry about that part of it
<mxpxpod> is there a way to get the evolution gaim plugin?
<calc> putting python stuff into the bootup?
<Kamion> boot != Essential
<Kamion> those two things are orthogonal
<calc> true, but theres not a lot of other stuff that really needs to be essential other than boot related stuff
<Kamion> no, essential is for the core packaging system
<Kamion> the point of essential is that if you remove it then the packaging system won't work any more
<calc> oh i thought essential was if you remove it the whole os stops working
<Kamion> you ought to be able to boot far enough to run dpkg, sure, but that's a pretty lean requirement :)
<Kamion> no, this seems to be a common misunderstanding
<calc> of course python-minimal will need to be at least as high priority as anything using it
<Kamion> (a) it's required (b) I'm not sure we care in Ubuntu :)
<Kamion> policy or the packaging manual used to talk about what Essential was for, but I can't see the text I remember any more
<calc> ok
<Kamion> the text was something like "the package manager will not let you remove essential packages; if you do, then you might not be able to run dpkg to put them back"
<calc> not sure why e2fsprogs is essential but everything else makes sense
<calc> i guess its left over from when all debian supported was ext2
<Kamion> e2fsprogs is a bit of an anomaly; it does have the generic fsck wrapper though
<calc> oh
<Kamion> I have a bug open about how to split it out smoothly, but it's quite difficult to do right without breaking in upgrade corner cases
<calc> if essential is just for the package manager to run then looks like other things just need to be required as well
<Kamion> mostly, yeah
<calc> like eg login
<Kamion> essential isn't even a closed set
<Kamion> (under dependencies)
<Kamion> it should always be a subset of required though
<calc> yea
* Kamion looks through an enormous *.po diff and does the "speak English" dance ;)
#ubuntu-devel 2005-01-04
<lamont> Kamion: heh
<carlos> Kamion: now it's a good time to start learning Spanish :-P
<mxpxpod> what's wrong with mono on hoary? why is it still in limbo on ppc?
<Kamion> requires manual bootstrapping, I think ...
<lamont> Kamion: btw, no love from ia64 install CD
<Kamion> lamont: what's up with it?
<lamont> loads of missing udebs, --> can't load installer components from CD
<Kamion> yes, I just got a bug about that ...
<lamont> affects other CD's too?
<lamont> easy to fix?
<Kamion> doesn't affect current powerpc
<lamont> do you want a list?
<Kamion> easy to fix when I know what's wrong ... :)
<Kamion> I'd rather have a copy of /var/log/syslog
<lamont> yeah - easier said that done, yes?
<Kamion> you have nc in busybox
<lamont> hrm... how hard to mount a USB pen drive at that point?
<lamont> ah, nc is cool.
<Kamion> #4940, BTW
* lamont goes to bludgeon
<Kamion> ta
<lamont> yeah, there's nc, but no network cards yet. :-(
<lamont> time to take advantage of /dev/ttyS0
<lamont> Kamion: http://people.ubuntu.com/~lamont/ia64.syslog
<lamont> ( sh < /dev/ttyS0 > /dev/ttyS0 2>&1 is a powerful command... :-)
<Kamion> Dec 23 16:37:50 main-menu[2068] : (process:5514): Segmentation fault
<Kamion> whoa?
<lamont> hrm.
<lamont> command line? and I'll go run it with strace or something.
<lamont> strace _is_ on the cd, yes?
<Kamion> yeah, but probably won't work until libc6-udeb is installed
<Kamion> udpkg -i that, then fish out strace. you don't get a command line, you'll have to find the main-menu process and strace -p it
* lamont ponders how complex it would be to give Kamion a login with serial console :-)
<lamont> anyway, back on momentarily
<Kamion> lamont: hm ... you want to strace -f actually, sorry
<Kamion> it's a child of main-menu that's segfaulting
<lamont__> yeah
<lamont__> figured that out.
<lamont__> and I need to do things in the background at least a little, since there's no job control.
<Kamion> definitely anna segfaulting, but why ...
<Kamion> all that code is identical to Debian
<lamont__> stracing shell scripts is _BORING_.
<Kamion> yeah :)
<lamont__> fwiw, there's a really nice tombstone that comes up for hundreds of milliseconds before getting cleared.
<lamont__> otoh, serial console might make that not so bad...
* lamont__ boots agagin
<lamont__> at least, I hope it does....
<lamont__> yep.
<lamont__> serial here we come
<Kamion> beginning to think strace won't help much though, might be more a gdb job
<Kamion> which would mean rebuilding anna with debug symbols ...
<lamont__> I should have the tombstone shortly, at least
<lamont__> just have to remember to boot serial console,  rather than vga.. :-(
<lamont__> Kamion: btw, 12-22 daily ppc installed just fine, thank you.
<lamont__> well, except for X not liking the display at all.
<lamont__> WTH is daniels when I need to beat him, huh?
<Kamion> tombstone?
<lamont__> from the segv
<lamont__> traceback
<Kamion> there must be some weird udeb involved here or something; the code runs fine on amd64, and on alpha/ia64 in Debian, so I don't think there are inherent 64-bit issues
<lamont__> p.u.c/~lamont/boot.out
<lamont__> firecall - should be back in about 30-40 min, I guess.
<Kamion> how do I decode that?
<Kamion> assuming that the call trace is outermost-last, the last thing is a syscall entry ...
<daniels> lamont__: he's on holidays
<Kamion> there are some unlink() calls in install_modules(), mind you
<Kamion> lamont__: strace might actually be useful; it would allow me to see whether there's any debconf interaction following the last log entry
<lamont__> back
<lamont__> daniels: X doesn't start on my ppc box.  (G3)
<lamont__> :-(
<lamont__> Kamion: so you want me to boot it up again and capture strace output?
<lamont__> reipoc.e sound familiar?
<lamont__> (that's what's in r8...)
<lamont__> sorry.
<lamont__> reipoc-e
<lamont__> Loading components of the Ubuntu installer  Unable to handle kernel paging request at virtual address 726569706f632d7d
<lamont__> and that derives directly from that.
<Kamion> lamont__: please
<Kamion> (strace)
<Kamion> never heard of reipoc-e
<lamont__> how about ... e-copier?
<lamont__> damn little endian world.
<lamont__>  /cdrom/pool/main/a/archive-copier/archive-copier_0.0.11_ia64.udeb
<Kamion> shouldn't be an unusual package ...
<lamont__> strace running
<lamont__> "unpacking archive-copier"... hrm.
<Kamion> daniels: you know, we should probably change the Maintainer: of l-r-m ...
<Kamion> lamont__: calling udpkg presumably?
<lamont__> yeah - but really slow because of the strace at 9600 baud :-(
<lamont__> [pid  5753]  execve("/usr/bin/udpkg", ["udpkg", "--print-architecture"] , [/* 17 vars */] ) = 0
<lamont__> working through that one
<Kamion> wouldn't it be better to strace -o /tmp/whatever and then nc that somewhere?
<lamont__> no network
<lamont__> we have to finish loading the installer modules before we load the network modules... :-(
<lamont__> unless you want to tell me how to get a network that early?
<lamont__> then we just have the small issue that I'm using that network cable...
<Kamion> ah, well it's possible with creative use of udpkg but it might perturb the problem
<lamont__> yeah
<lamont__> it doesn't help that I straced a bunch of stuff I didn't need to.. :-(
<lamont__> just grep'ed for Componens in hoary/release
<lamont__> [pid  5817]  execve("/usr/bin/logger", ["logger", "-t", "cdrom-retriever", "warning: Unable to find restrict"...] , [/* 17 vars */] ) = 0
<lamont__> wonder if that matters...
<Kamion> that happens everywhere, will be fixing it soon
<Kamion> you didn't strace -s <lots>?
<lamont__> what's -s do?
<lamont__> ia64.strace2
<lamont__> (and ia64.strace, but that's the boring leadin)
<lamont__> 81% there
<lamont__> '
<lamont__> grumble. crap connectivity
<lamont__> there now
<lamont__> pid 5514 is the child with issues, per syslog
<lamont__> and that's not in the strace output at all.
<Kamion> there's no segv in that trace
<lamont__> which could just mean that it ran fast enough to not get grabbed before it failed.
<Kamion> I think 5514 is just a shell that calls anna
<lamont__> child processes run free until the parent gets the pid back.
<Kamion> so, where's the crash?
<lamont__> not in the trace
<lamont__> it happened at 18:03:41, if there are any times in the strace...
<lamont__> do you want one with -s large?
<lamont__> although I doubt it'll tell you anything
<Kamion> what did you strace?
<Kamion> hm, main-menu from the looks of it
<lamont__> would you like me to set up serial console access for you? (with a spare serial port)..
<lamont__> strace -f -p <pid-of-main-menu>
<Kamion> it looks like the strace is truncated
<Kamion> stops at:
<Kamion> [pid  5818]  --- 
<lamont__> eventually I killed it.
<Kamion> oh, ok
<Kamion> serial access would be good if possible, yeah
<lamont__> but we were already dead by then.
<Kamion> then I can trace to a file and look at the end of it
<lamont__> yeah - is work.  gimme a bit.
<lamont__> you want it tonight, or just ready for you by morning?
<Kamion> no rush
<mojo> daniels: I have this error EVEN though I have soft link the libglx, can u confirm for me whether it is a bug or my mistake?
<mojo> root@ubuntu:/home/mojo # glxgears
<mojo> Xlib:  extension "GLX" missing on display ":0.0".
<mojo> glxgears: Error: couldn't get an RGB, Double-buffered visual.
<mojo> root@ubuntu:/home/mojo #
<lamont__> warty server install is 'server', yes?
<Kamion> no, 'custom'
<lamont__> custom. /me blesses help menusw
<Kamion> hoary's 'server'
<Kamion> (I lost the argument, eventually ...)
<lamont__> yeah - server makes me think it has daemons....
<Kamion> that's what I said to Mark
<Kamion> elmo reckoned that pared-down was fine for servers, though, since you'd want to pick the package set yourself
<Kamion> *shrug*
<mojo> daniels: I fixed it, dun bother
<mojo> there is still libglademm2.4-dev based on old libglade2 that dep on python2.3. It's very annoying b/c I want to use the latest 2.4. Can someone spend a bit of time changing number 3 to number 4 in dep PLS
<ogra> mojo: he is on holiday
<mojo> ogra: k, let him relaz, I can handle some stuff w/o him
<ogra> :) 
<lamont__> after several boot attempts, isolated to a bad CD (diff box,i386 this time...)
<mojo> lamont__:???
<Kamion> not all conversations start when you join the channel ;)
<mojo> lol
<lamont__> Kamion: many of mine start without me... :-)
<mojo> more lol
<ogra> lol
<lamont__> I find myself reminded just how _SLOW_ 233 MHz is.
<lamont__> otoh, 233MHz should keep up with the printer OK.
<Kamion> aj: any thoughts on having debootstrap validate Release sigs?
<anselm_> Hello, could someone possible help me with a problem?
<mojo> dude, if it's related to development, then ask
<mojo> else go to #ubuntu
<anselm_> ok well go over to #ubuntu, thanks
<Kamion> mdz: what's happened to all the debian/changelog entries between 0.5.32 and 0.6.27?
<mdz> Kamion: they were lost during the merge which brought the 0.6 branch up to date
<mdz> the history is still there in arch
<Kamion> I hope they'll be restored
<mdz> most of it isn't particularly relevant in the mainline changelog
<mdz> and it's not entirely clear to me where in the changelog they should go
<mdz> perhaps a separate file would be OK
* Kamion just always puts stuff in versioned order, people seem to cope
<mdz> you mentioned that you had some ideas for branch representation in changelogs
<Kamion> I brought them up in one of the BOFs at Mataro
<Kamion> basically:
<Kamion> {{{ branch to do something
<mdz> yes, but we didn't get to seeing an example
<Kamion>   apt (0.6.0) unstable; urgency=low
<Kamion>   ...
<Kamion> }}}
<mdz> the way 0.6 worked, I was merging everything I did in 0.5.x into it for many versions
<mdz> so they really were parallel
<Kamion> some notation around there to be clear about where you branched from, too
<Kamion> ah
<Kamion> it's just very confusing to the casual skimmer of debian/changelog at the moment
<Kamion> anyway :)
<mdz> yes, the current changelog ended up slightly weird too
<mdz> apt (0.6.26) unstable; urgency=low
<mdz>  -- Matt Zimmerman <mdz@debian.org>  Thu, 25 Nov 2004 10:01:16 -0800
<mdz> apt (0.5.32) unstable; urgency=low
<mdz>  -- Matt Zimmerman <mdz@debian.org>  Sat, 11 Dec 2004 09:05:52 -0800
<Kamion> ugh, mvo left a bunch of arch junk around in the source package
<mdz> ack
<mdz> I thought I told him about debian/rules arch-build
<mdz> I'll send mail
<Kamion> oh wow, didn't realise apt-key was a shell script
<mdz> perhaps I'll rewrite it in python-minimal :-)
<Kamion> I almost had a heart-attack earlier today when I thought we'd ended up putting the Essential flag on python2.4-minimal
<Kamion> then I remembered that python-minimal existed too, and relaxed
<mdz> but python-minimal isn't essential either, yet
<Kamion> indeed
<aj> Kamion: having gpg on the install media was always too big an ask, otherwise sure, should be trivial
<calc> Kamion: so rewriting it all in python and going to get rid of perl-base from essential?
<Kamion> calc: don't expect that any time soon
<Kamion> aj: I suspect we'll end up doing it, whether Debian do or not
<Kamion> for the cdrom gpg can go anywhere really, but for netboot it really has to be in the initrd ...
<Kamion> since you're getting all udebs after that from the network and you need to auth them
<Kamion> and, of course, the netboot initrd needs to be signed with the archive key or something
* Kamion expects elmo will just love doing that on every byhand upload
<Kamion> calc: basically Mark wants to be able to use python more or less anywhere feasible, and doesn't want that to be stopped by trivial little details like the shape of essential ;)
<calc> cool :)
<Kamion> calc: that's a bit different from rewriting a big load of code that works
<lamont__> Kamion: any thought that the kernel could be playing with your head here?
<lamont__> that is, should I drop said kernel on the sarge install that's there, and see what it does?
<Kamion> lamont__: well, a segfault is a segfault; it was pretty clear in the original log
<Kamion> that probably won't work, kernel needs to match module udebs
<lamont__> yeah - and clearly grabbing some text and using it as a pointer...
<Kamion> kernel version needs to match module udeb versions, that is
<Kamion> otherwise anna won't retrieve them
<lamont__> Kamion: nah - I meant dropping linux-image-2.6.9 on the sarge box
<lamont__> it already has sarge installed, you see...
<Kamion> guess so, you could try it
* lamont__ adds that to his list
<lamont__> back in a bit
<lamont__> so who uploaded the b0rked l-r-m?
<pitti> Morning
<Treenaks> hey pitti 
<pitti> Hi Treenaks 
<pitti> Hi sivang 
<mvo> hi pitti 
<mvo> hi all :)
<sivang> hi pitti ! morning
<sivang> morning everybody else
<sivang> :)
<bob2> 'afternoon
<sjoerd> morning 
<Treenaks> bobz0r
<pitti> Hi!
* pitti goes for family breakfast now
<pitti> Happy Christmas everybody!
<sivang> Marry Xmas all :)
<sivang> hey ogra , marry xmas
<sivang> seb128: was the small size bars on the app panel bug closed? I can't see it anymore..
<seb128> sivang: http://bugzilla.ubuntu.com/show_bug.cgi?id=4918
<sivang> seb128: tnx
<Kamion> lamont: which b0rked l-r-m?
<sivang> seb128: and the weather report applet bug number? I added a backtrace :)
<seb128> already fixed
<seb128> I've made a patch yesterday
<sivang> seb128: I just did a dist-upgrade, I can stil reproduce - has it not build yet?
<seb128> have you upgraded gnome-applets ?
<sivang> seb128: I did a dist-upgrade, and it tells me it's the newest version already. what version # should I have?
<seb128> a new one
<bob2> hah
<seb128> if it doesn't update that's the new version is not built yet
<seb128> seems to be logical ...
<sivang> seb128: 2.8.1-0ubuntu2 is what I have
<sivang> seb128: ok :)
<seb128> gnome-applets is 2.9.3
<seb128> you're using warty ?
<sivang> eh ok ;-) I'll wait for it to build..
<seb128> hum
<sivang> seb128: no! hoary ofcourse 
<seb128> warty will not changed ...
<seb128> 2.8.1 is the wartt version
* sivang is checking. maybe apt pinning is to blame?
<seb128> hoary has 2.9 since 1 Nov 2004 for gnome-applets
<seb128> no idea on what you have changed on your box
<sivang> seb128: dang, apt pinning fooled me. it appears that only this package was still warty's version - upgrading now. Sorry for the hassle..
<seb128> np
<Kamion> I: Retrieving debootstrap.invalid_dists_hoary_Release.gpg
<Kamion> I: Validating debootstrap.invalid_dists_hoary_Release.gpg
<Kamion> I: Validating debootstrap.invalid_dists_hoary_Release
<Kamion> gpgv: Signature made Thu Dec 23 02:34:16 2004 GMT using DSA key ID 437D05B5
<Kamion> gpgv: Can't check signature: public key not found
<Kamion> E: Release signed by unknown key (key id 40976EAF437D05B5)
<Kamion> rock
<mvo> Kamion: hey, cool!
<ogra> morning.... merry xmas everybody
<Kamion> still have to deal with getting the error messages right for gpg missing, gpg produced no useful output, etc., but it basically works
<mvo> ogra: happy xmas
<ogra> :)
<Kamion> aj: this version of debootstrap does signature-checking only if you pass a --keyring=/etc/apt/trusted.gpg (etc.) argument; if you don't give it a keyring it doesn't do validation. Is that OK with you?
<sivang> mvo,ogra : marry xmas
<Kamion> I figured that was the least invasive approach considering the wide variety of places where debootstrap is used
<Kamion>  Package: python2.4-minimal
<Kamion>  Conflicts: python2.4 (<= 2.4-2)
<Kamion>  Replaces: python2.4 (<= 2.4-2)
<Kamion> doesn't that versioned conflicts make the upgrade stupendously painful?
* Kamion files a bug
<Kamion> mvo: what happens if a Release file is signed by multiple key ids? (katie's ziyi script supports this, although I don't know if it's used.) At the moment, it looks like a failed signature verification on any one of those signatures will make apt fall over, even if one of the signatures is valid.
<mvo> Kamion: I need to look at the code, don't know now. it's probably usefull to have more than one signature on the Release file
<mvo> I'm leaving to visit my family. see you all in a couple of days 
<mvo> bye
<sivang> does anybody know if we support burning audio cds out of the box?
<sivang> I mean, from mp3/wav files..
<ogra> sivang: nope.....there is no burning app to do that yet
<sivang> ogra: ok, so just go and install something from universe, there are planty though :)
<ogra> sivang: no gnome2/gtk2 ones currently.......
<sivang> ogra: you can always run k3b under gnome :)
<ogra> sivang: rhythmbox will have burn support in the near future
<sivang> ogra: upstream is doing that?
<ogra> yep... i read about it
<cenerentola> sivang: are you a rebel?
<cenerentola> yesterday u supported x86, today k3b... 
<sivang> cenerentola: hehehe
<sivang> cenerentola: not actually, just "use the best tool for the job" 
<sivang> :))
<cenerentola> shut up dude...
<sivang> cenerentola: hey, I dind't say it first, Linus did :)
<cenerentola> that's why you shouldn't use such pure sentences..
<cenerentola> ;)
<sivang> cenerentola: :)
<lamont> Kamion: version not bumped in the makefile too... taht should really get automated.
<Kamion> lamont: aargh
<Kamion> will fix
<Kamion> and I remembered it the last time I uploaded l-r-m, too
<lamont> Kamion: yeah - btw, 'Uploaded' state has been restored to buildLogs/Lists/*
<lamont> things shouldn't stay 'Uploaded' for > 30 minutes unless they're (a) NEW, or (b) l-r-m and busted. :-)
<Keybuk> pitti: no, I typo'd :p
* lamont reuploads gimp/i386 to get a fresh copy of the reject message. :-(
<Kamion> lamont: should be fixed now, sorry about that
<lamont> Kamion: np
* lamont prepares to deploy per-suite directories (to allow better testing), and then do a mass-giveback of failed/depwait packages
<Kamion> I see I'm not the only one taking advantage of the quietness to fix a pile of infrastructure
<lamont> heh
<lamont> yeah - this is also "clean up /etc/fstab" day.
<lamont> du -sk /org/ubuntu/tree/
<lamont> 6121080 /org/ubuntu/tree/
<lamont> ouch.  and that's just i386/hoary
<lamont> well and warty-*
<lamont> and source
<lamont> dropping warty proper freed up 2.9GB
<Kamion> I've managed to do about half of the work required for full d-i Release.gpg-checking support today, so I'm quite pleased
<Kamion> ... and off to do the last couple of pieces of Christmas shopping now
<lamont> Kamion: KEWL!
<sivang> Kamion: merry Xmas :)
<sivang> lamont: you got presents for the kids? :)
<cenerentola> Kamion: merry christmas
<lamont> hrm... I need something to parse perl in python... :-(
<Treenaks> lamont: hmm... libperl wrapped in python
<lamont> Treenaks: just trying to find a variable definition in the perl mess for my python code to use... :)
<Treenaks> lamont: it sounds like a great coding project for 2005-04-01
<lamont> Treenaks: I'm just not sure which camp would be more offended: perl or python
<Treenaks> lamont: exactly
* lamont finishes converting one buildd of each architecture to the new world order, thinks he now has a script to do it (modulo being scared of automatically modifying /etc/fstab...)
* lamont wanders off for a bit
<smurfix> Hmm, parrot is supposed to be able to do that ... eventually.
<sid77> hi
<Treenaks> hey sid
* lamont does a mass-give-back on all 4 architectures, just to hammer on things.
<Kamion> lamont: any joy with that serial console access?
<lamont> Kamion: been hip deep with other things... give me a couple minutes
<lamont> 1245 files missing from my ubuntu mirror (with the addition of ia64).  sigh.
<lamont> Kamion: I'll go hook it up now.
<sid77> anyone: any news on livecd/ppc?
<lamont> Kamion: what IP are you coming from?
<Kamion> lamont: should be 81.153.126.219
<lamont> Kamion: email sent, still arguing with the tty stuff though.
* lamont gives it one more pass, but then will have to run some errands
<lamont> Kamion: and worst case, I'll wind up moving your login to another machine, which might even have _2_ serial ports to abuse.
<Kamion> np
<lamont> Kamion: boot up sequence is to be in minicom after invoking the willy-switch (inside joke), interrupt the auto boot, choose efi-shell, then say:
<lamont> fs0:
<lamont> elilo
<lamont> if you try now, you should get an fs0> prompt when you hit return.
<lamont> (it wants 'elilo'
* Kamion is not having much luck connecting
<lamont> no network plugged in yet
<lamont> ssh to ia timing out?
<lamont> oh. yeah.  that.
<lamont> sec
<Kamion> hasn't actually timed out yet, but is sitting at connect()
<lamont> doh
<lamont> ctl-c and do it again
<Kamion> ah, there it goes
<lamont> EBADRULE
<lamont> fwiw, that's the house web proxy, etc
<lamont> most of your activity from that machine is throttled to about 30kbits, which you're sharing with 2 rsyncs
<lamont> port 22 traffic is not shaped.
<Kamion> what do I do after starting minicom? serial console newbie here ...
<Kamion> ah, never mind, got it
<Kamion> not much happening after the initrd loads though ...
<Kamion> oh, DUH, I selected the VGA option. how do I reboot?
<Kamion> and do arrow keys work, even if I can't see the result?
<amu> lamont: ping, katie is too fast for me :) i'm upping a package with 5k the size of the orig.tar.gz is 5mb :)
<amu> Rejected: kdesdk_3.3.2-1ubuntu1.dsc refers to kdesdk_3.3.2.orig.tar.gz, but I
<amu> +can't find it in the queue or in the pool.
<lamont> that's why you upload the orig.tar.gz, then the diff.gz, then the .dsc, then the .changes
<lamont> or use dput
<lamont> truthfully, as long as the .changes is last, katie should wait for it.
<Kamion> amu: you forgot to use -sa
<lamont> Kamion: well, that would be the other reason
<lamont> :-)
<Kamion> there's no kdesdk_3.3.2.orig.tar.gz in the pool, and it only gets automatically included in the .changes if the revision part of the version is -0 or -1
<Kamion> you should also probably use -0ubuntu1 rather than -1ubuntu1, I suspect
<Kamion> so that 3.3.2-1 is considered newer
<lamont> Kamion: unless he's merging into 3.3.2-1, of course.
<Kamion> well, there's no 3.3.2-1 in Debian, but I guess it depends
<amu> hehe yep now upping with dput and -sa ;) 
<amu> oh my god line is too slow now
<sivang> lamont: I am arguing with my dad, please tell me how much time it takes to travel in a car from Miami to Holywood ?
<lamont> miami to hollywood... hrm... call it ~3000 miles give or take.
<sivang> lamont: also, he has just discovered keyhole :) He thinks they are close like the train station to Mataro :)
<lamont> your average sane person would therefore take about 3 days of solid driving (averaging 50 miles per hour, or 1200 miles per day)  If you're willing to just make it 'stop for gas', you could drop that to around 2 days
<lamont> assuming that you have drivers to switch off.
<lamont> if you have family with you, plan on at least a week, or no sex after that.
<sivang> lamont: hehe
<wasabi_> I assume there has been discussion about whether or not to officially support Mono in Hoary? Trying to find some conversations. ;)
<mdz> wasabi_: yes, there has
<wasabi_> yes, no, maybe so?
<mdz> the consensus, as I recall, was that "mono" was not a first-class thing which should be supported, but that if there were mono applications we should support, they would pull in the mono stuff
<mdz> jdub has details
<wasabi_> Hmm. Sucky. =(
<sivang> mdz: I thknk that's the best approach
<sivang> mdz: this is the state currently right? I do have tomboy running...:)
<mdz> wasabi_: pardon?
<wasabi_> hmm?
<janc> wasabi_ : just write a first-class thing which they need...  ;-)
<wasabi_> I think that sucks.
<wasabi_> I don't think you're going to get any cool apps written until people stop having to go through hell to install it. ;)
<wasabi_> Especially given the less technical aspect of programming useful C# apps.
<mdz> I'm fairly certain there are already useful applications written, and packaged in universe even
<mdz> and it's quite likely that we'll decide to support some of them for Hoary
<wasabi_> well that's cool then.
<mdz> so your attitude is doubly unnecessary
<sivang> wasabi_: what is so good in c# that python don't have?
<wasabi_> im not getting into that.
<mdz> sivang: they're quite different
<sivang> wasabi_: I would suffice for a link to enlighten me :)
<wasabi_> mdz, sorry then... b ut that's a bit how I feel. I sort of see "java support", or ".net support" as something you could support, for hte good of ISVs
<wasabi_> But then, im not on your side of the fence, and have no idea. ;)
<wasabi_> sivang, what does perl offer over python?
* sivang prefer java beans only in coffe :)
<sivang> wasabi_:  huh?
<wasabi_> it's just as valid of a question as yours was, really.
<calc> how are the java clones doing?
<wasabi_> not too good imo
<wasabi_> no way they can keep up
<calc> yea :\
<wasabi_> not enough interest being generated.
<calc> mono seems to be doing much better since clr/etc is standardized
<wasabi_> yeah.
<wasabi_> i might say that it seems like the community is more focused.
<wasabi_> I mean, java is very well understood.
<wasabi_> I guess it probably has to do a lot with all the people who really need java on linux, just use sun's vm.
<wasabi_> ms.net ain't gonna run on linux. ;0
<calc> yea
<wasabi_> I guess im fine with that. I don't mind.
<wasabi_> I wish sun had better redist rights.
<calc> even if it was redistributable couldn't use it for anything in a dist
<wasabi_> very few people actually write linux apps in java.
<calc> since it would still be stuck in non-free as opposed to not even being in there
<wasabi_> they write java apps.
<wasabi_> yeah. Well.. we have enough free stuff to write real dist programs with.
<wasabi_> GCJ is fine, Classpath is Good Enough.
<wasabi_> Java-gnome rounds out the GUI.
<calc> ok
<wasabi_> BUt, the stuff I use it for, it's not adequite for.
<wasabi_> ejb, tomcat, etc.
<wasabi_> i did the mono remoting example yesterday, and almost died. =(
<wasabi_> equivilent of at least 100 lines of java.
<wasabi_> in like, 2.
<ogra> <wasabi_> sivang, what does perl offer over python?
<ogra> wasabi_: its more mature
<wasabi_> ogra, doesn't noticible effect any apps.
<ogra> wasabi_: you find it in smaller environments where py doesnt fit
<wasabi_> noticibly
<ogra> wasabi_: and i think it currently has the wider list  of modules.....
<calc> perl offers obsfucation too :)
<ogra> but that will change eventually
<wasabi_> ogra, then why are ubuntu apps prefered in python? (read that sompleace)
<ogra> wasabi_: python is great... i dont say perl is better...but has some advantages....
<ogra> as py has :)
<wasabi_> well, you just renforce my C# thing.
<wasabi_> it's good for some things python isn't, but they can all pretty much get the same jobs done
<ogra> yep.... you can do it also in C or assembler ....
<wasabi_> im a fan of presenting people with the widest array of tools. Differnet tools for different people.
<wasabi_> And if all those people develop for your platform, you're better than if only a subset did.
<ogra> or code it in 1 and 0 if aou are _really_ smart
<ogra> oh, another one for perl.... loads of debian is perl based as perl was the traditional script lang for years there
<ogra> even this will change slowly in ubuntu i guess
<lamont> mdz: what did we decide on 2113?
* lamont files an upgrade bug against udev.
#ubuntu-devel 2005-01-05
<mdz> lamont: http://lists.ubuntu.com/archives/ubuntu-devel/2004-November/001690.html
<lamont> I believe it's the latter.  That is, you need both packages
<lamont> cupsys-driver-gimpprint delivers files into the foomatic-db infrastructure
* lamont goes to the other room for a bit
<mdz> lamont: but cupsys reads the rest of the foomatic drivers without cupsys-driver-gimpprint
<mdz> lamont: please take a look at it and find out how it's supposed to work
<lamont> mdz: will do
<lamont> mdz: upstream version freeze is the 28th?
<sid77> merry xmas
<usual> merry christmas
<bob2> woo, ubuntu-desktop is unupgradable
<Kamion> ?
<bob2> hm, no, aptitude just wasn't smart enough to remove python2.3-pyorbit (with which the 2.4 version conflicts)
<Kamion> I seem to have an upgrade problem on this system too, wonder what it is
<Kamion> something to do with gimp
<Kamion> ah, no, false alarm, local mirror out of date
<lamont> Kamion: I had the same issue yesterday
<lamont> but I expect that the local mirror was out of date
<calc> from what i recall gimp has been broken on archive.u.c for a while now
<calc> looks like it was fixed earlier today finally
<bob2> which script is supposed to ramp up the disk-cache-flush times?
<bob2> seb128 broke my gnome-panel!
<bob2> oh, and then his advice fixed it, so it evens out
<GotD0t> i have a strong urge to play yahtzee
<janc> GotD0t : this is not #ubuntu-games   :-p
<mojo> Daniel: nvidia-glx no longer dep on linux-restricted-kernel??
<mojo> Daniel: I just reinstall Hoary, and it no longer require restricted image kernel
* Kamion fixes the l-r-m problem mojo reported, although it'll be tomorrow before I upload it
<Kamion> merry Christmas!
* Mithrandir waves to Kamion
<mdz> gah, why is my right Alt key no longer Alt, and rather ISO_Level3_Shift?
* mdz prods daniels
<Treenaks> same with my compose.. which became 9~
<sivang> mdz: has the firewall proposal been bountized ?
<mdz> sivang: there is no proposal; we're just looking for a tool which should already exist in the community
<mdz> we don't intend to fund the development of a firewall app from scratch
<sivang> mdz: ah cool, I bet there is somethign which can be integrated.
<mdz> one would think so
<mdz> but we haven't found one yet which is truly workable
<sivang> mdz: then this can be some small hack in python to exec iptables with block all besides HTTP/FTP/SSH/SMTP and when someonce requires anything more, he can install watchdog or firestarter.
<sivang> mdz: although the HIG stuff can have some tricky bits..
<mdz> running iptables is not the problem; what is lacking is a firewall configuration tool
<sivang> mdz: watchdog seems nice, if only it had less bugs..but I don't think it's written in perl.
<sivang> sorry, python
<sivang> mdz: correction, guarddog
<herzi_lap> can someone please fix meld by rebuilding it against python 2.4?
<herzi_lap> meld still blocks my python updates
<sid77> hi
<RubenV> is python2.4-musicbrainz broken?
<bob2> it's installable at least
<RubenV> yeah, but it won't even run the example scripts from the musicbrainz.org cvs
<RubenV> hmmm
<RubenV> why does ubuntu ship different examples?
<sivang> smurfix: smurfix hi
<tim1> hello
<sivang> hey tim1 
<tim1> i have errors here hen compiling mono apps about a missing gtk-sharp-2.0.pc
<tim1> i don't know what to do because i think i have the needed packages ...
<sivang> tim1: is it installed? can you see it when you do dpkg -l | grep <pkgname> ?
<sivang> tim1: you can also ask over in ubuntu-users someone there might have the answer.
<tim1> there is no gtk-sharp package, but the bindings should be in libgtk-cil, which is installed
<tim1> oh, ok
<bob2> jdub: your gnome-bluetooth crack was broken by the python2.4 change
#ubuntu-devel 2005-01-06
<lamont> Kamion: I just need to go buy a boatload of DB9F connectors, and you'll have serial
* lamont figured out the config for his 32-port cyclades today. :-)
<sivang> Kamion: do you know where is the official ubuntu isntallation manual? :)
<ogra> sivang: http://archive.ubuntulinux.org/ubuntu/dists/warty/main/installer-i386/current/doc/manual/en/index.html
<sivang> ogra: thanks! I am trying to set up lvm on the laptop..I thought of installing over it this time :)
<ogra> sivang: not sure if it covers lvm
<sivang> ogra: it appears this gets really low coverage ..
<ogra> but its a gret system.... i first used it on one if my servers this year (not for / though) and its great
<ogra> you can just shrink or grow as you like...
<sivang> yes, but how you set it up at first?? :)
<sivang> it
<sivang> nothing I try at d-i seems to be accepted wrt to the LVM
<ogra> dunno, but i guess there is some debian documentation fro that anywhere..... debianplanet.org could be a start
<sivang> ogra: I managed to install both / and /home in it :)
<sivang> ogra: warty d-i is _superb_
<ogra> great:)
<lamont> night all
<mdz> night
<melazyboy> New version of Mplayer released today
<__danie1> how can i (in a nice way) make gcc-3.4 default?
<__daniel> hmm, is there no other way but changing the symlinks manually?
<x4m> Is there any plan to use syslog-ng instead of sysklog/syslogd ?
<cenerentola> kamion: "Error 6: Mismatched or corrupt version of stage1/stage2" any idea?
<cenerentola> Kamion: ... ;) good evening
<Kamion> cenerentola: not offhand, check the grub info file
<cenerentola> mmm.. how can i..
<cenerentola> no live-cd with me..
<cenerentola> s/can/could
<mdz> you can find a few dozen copies of it with google
<cenerentola> yeah.. sorry.
<tseng> would it make sense to anyone to do a dual package of muine for gst/xine like totem does
<cenerentola> kamion:  sorry i just misunderstood what you meant... the manual says "6 : Mismatched or corrupt version of stage1/stage2 This error is returned if the install command points to incompatible or corrupt versions of the stage1 or stage2. It can't detect corruption in general, but this is a sanity check on the version numbers, which should be correct. 
<Kamion> in that case I have no idea, sorry
<cenerentola> what's stage1/stage2..
* Kamion is not a bootloader expert, I just occasionally have to play one on TV
<ogra> heh
<Kamion> now that the grub documentation really *does* explain!
<cenerentola> Kamion: oki dokie..
<cenerentola> ogra: ... i actually didnt get it.. can you explain :)
<ogra> what ? my laughing....was about Kamions joke ;)
<cenerentola> yep.. that's what i didnt get.. kamion's joke..
<Kamion> it's not important
<cenerentola> Kamion: ;)
<Kamion> it's a misquote more than a joke
<Kamion> why is this grub thing on #ubuntu-devel anyway?
<cenerentola> Kamion: because im kinda desperate... 
<cenerentola> and i say The Light in you
<cenerentola> s/say/saw
<Kamion> well it should be on #ubuntu instead
<Kamion> anyway, grub is weird sometimes, try lilo and see if that behaves better
<cenerentola> ok.. thanks
<Kamion> mdz: should we put ubuntu-keyring in main?
<Kamion> ideally on the CD
* sivang realized today that some of the language related stuff should be also put and out of the box available in the live cd.
<sivang> (when trying to show off ubuntu for some newbie, win users buddies)
<sivang> Kamion: grub has given much better results then lilo , and I am not using both / and /home under lvm. coool.
<Kamion> it varies from system to system.
<ogra> sivang: you are not using both under lvm ? i thought you did ?
<sivang> ogra: I am
<ogra> sivang: ah, because you wrote something else above
<Kamion> "not" -> "now" I'm guessing
<ogra> yep
<ogra> i was just wondering because sivang told me yesterday he made it....
* Kamion thwaps doko, python2.4-minimal is still broken
<sivang> Kamiom, ogra : yes I did it :) sorry for my horroble spelling mistakes.
<ogra> sivang: its ok.... dont worry :)
<sivang> Anybody know why locale configuration fails on last hoary upgrade?  dpkg fails eventually because of it and I cannot install CLISP.
<sivang> ?
<sivang> has anything changed over the last day wrt to it? :)
<ogra> sivang: just confused me....i was better in guessing on other days :)
<sivang> ogra: have you ran into the "locales not set" error from dpkg? (or any other stuff that uses perl)
<ogra> nope, not yet... 
<lamont> Kamion: you around?
#ubuntu-devel 2005-01-07
<usual> is gparted not in hoary because it isn't in debian unstable?
<lamont> usual: that would be one reason
<usual> ok
<lamont> generally speaking,  things come from debian unstable
<lamont> unless they're feature goals (like gnome)
<usual> I see
<usual> lamont, ubuntu hoary should release with the icon in the menu in this ss
<usual> http://files.subpop.net/daily-ss.jpg
<sivang> Kamion: ping
<Riddell> Can anyone say what went wrong with this build?  it's got a build dep of automake1.7 but it's trying to find automake1.  http://people.ubuntu.com/~lamont/buildLogs/k/kdesdk/4:3.3.2-1ubuntu1/kdesdk_4:3.3.2-1ubuntu1_20041226-0237-i386-failed
* lamont looks
<lamont> Riddell: heh.  whoever uploaded it needs to fix the Build-Depends line
<lamont> (there is no 'automake1.' package...)
<Riddell> lamont: I protest, the Build-Deps line definatly says Build-Depends: automake1.7
<lamont> ** Using build dependencies supplied by package:
<lamont> Build-Depends: automake1. , binutils-dev, bison, debhelper (>> 4.0.0), flex, kdelibs4-dev (>= 4:3.3.2), kdepim-dev (>= 4:3.3.2), libdb4.2-dev, libkcal2-dev (>= 4:3.3.2)
<Kamion> lamont: pong
<Kamion> sivang: pong
<lamont> Kamion: installing an hppa box with debian, was trying to bludgeon my way past the missing pieces of my local mirror...
<lamont> but finally just pointed it off-site to get the d-i its.
<lamont> bits
<Kamion> fair enough
<Kamion> sivang: compare /etc/environment with /etc/locale.gen
<Riddell> lamont: who can I ask about getting access to be able to upload packages?
<lamont> Kamion: but it's so slow it hurts. :-(
<lamont> Riddell: tell me which package it should build-dep on, and I'll upload it
<Kamion> Riddell: get Chris Halls to recommend you
<lamont> Riddell: and what Kamion said.
<Kamion> $ zgrep Build-Depends kdesdk_3.3.2-1ubuntu1.diff.gz
<Kamion> -Build-Depends: automake1.7, binutils-dev, bison, debhelper (>> 4.0.0), flex, kdelibs4-dev (>= 4:3.3.0), libdb4.2-dev, libkcal2-dev (>= 4:3.3.0)
<Kamion> +Build-Depends: automake1. , binutils-dev, bison, debhelper (>> 4.0.0), flex, kdelibs4-dev (>= 4:3.3.2), kdepim-dev (>= 4:3.3.2), libdb4.2-dev, libkcal2-dev (>= 4:3.3.2)
<lamont> Riddell: how many other pieces are having issues...
<sivang> Kamion: when do you think a ubuntu installer POT files would be available in rosetta?
* lamont grumbles at 5MB source balls
<Riddell> Kamion: very strange, that's not what I have in my kdesdk_3.3.2-1ubuntu1.diff.gz I gave to amu 
<lamont> Riddell: 1.7, yes?>
<Riddell> Kamion: who do I get Chris Halls to recommend me to?
<lamont> Riddell: but definitely in the archive as automake1.
<bob2> is there a good reason for it to be bulid-dep'ing on automake at all?
<lamont> Riddell: eventually to the technical board
<Kamion> sivang: good question, it's somewhat on my to-do list. In the meantime there's http://people.ubuntu.com/~cjwatson/installer-po/, which has most of the first-stage interesting bits
<Riddell> lamont: actually 1.9 may be better
<lamont> bob2: many things are debatable.
<Kamion> sivang: (that URL's regenerating at the moment)
<lamont> Riddell: pick one.  I won't be able to build before I toss it at the archive...
<Kamion> Riddell: as lamont says, community council and tech board; note that our sysadmins are 1.5-out-of-2 on holiday at the moment
<sivang> Kamion: can country teams use this url to upload into rosetta?
<Kamion> sivang: please don't do so until I give the OK
<Kamion> I don't want random translations floating about without anything coherent being done about them
<sivang> Kamion: Ok, no prob, so in the meanwhile I don't see much point in taking them at all :) I will just wait for it to be put there by you. 
<Kamion> at the moment the only semi-official reason that URL exists is because a third-party translation company is getting up to speed
<Kamion> I'll probably get it polished up after New Year
<Kamion> Rosetta's definitely a goal for it once I'm sure it's all accurate source
<lamont> Kamion: just on the off chance you didn't know (duh) d-i at 9600-serial _SUCKS_
<sivang> Kamion: what languages are they  going to be doing? I've talked with the pro-translation cordinator on Mataro..:)
<Kamion> sivang: dunno actually, I guess I'll find out
<Kamion> Xhosa was mentioned but I think she wasn't entirely sure herself yet
<lamont> Riddell:  you want 1.9 or 1.7?
<sivang> Kamion: Xhosa = Adi ?
<Riddell> lamont: automake1.9 please
<Riddell> lamont: what's wrong with 5meg sources?
<lamont> they're large
<sivang> anyway, I'm out. Night all.
<lamont> night sivang 
<sivang> Night lamnot
<ogra> night sivang
<sivang> night ogra 
<Kamion> sivang: right
<sivang> Kamion: k:) night
<lamont> Riddell: uploaded
<lamont> sadly, it'll be 30 minutes before the buildds take it
<Riddell> lamont: thanks
<lamont> np
<lamont> Kamion: and for the record, tftp booting the business card ISO doesn't work. :-)
<lamont> Kamion: well, it works.  But it doesn't do what I wanted. :(
<Kamion> can't you tftp-boot the vmlinu[xz] /initrd.gz?
<lamont> Kamion: yeah - actually went with 'boot.img' :)
<lamont> sadly, that lacks all the pretty installer pieces, as does the local mirror. :(
<lamont> what I really could have used was a way to tell d-i that /cdrom was populated, and to just get on with life.
<lamont> (netcat and tar are your friend, you see...)
<Kamion> that's more the job of hd-media image types
<Kamion> and iso-scan
<lamont> I find that the hppa port is making a wonderful harness for testing my per-suite changes in the buildd's...
<lamont> Kamion: well, yes... it was just an idea I had before I punted.
<lamont> Kamion: ok.  now how do I change the mirror location before istalling the base system?
<Kamion> you didn't get choose-mirror presented to you by default?
<lamont> yeah.  I need to change the answer
<lamont> or the install will take until next weke
<Kamion> go back to the main menu and select that item
<lamont> week, even
<lamont> doh
<lamont> and it automagically jumps back into installing the base system.  I guess that's cool
<Kamion> dependency-driven menu :)
<lamont> ah
<lamont> of course, the downside was that the only way I had to get back to the main menu was to yank the rug out from under the download....
<lamont> Kamion: tomorrow I'll get the connectors I need, and get my cyclades box installe.d
<Kamion> debian-kernel seems to be moving towards the one-source-for-all-architectures model fairly rapidly now
<Kamion> (of course, they always wanted to)
<calc> cool so they are helping upstream get the archs more in sync?
<Kamion> I think they always have been, just coordinating better now
<Kamion> but also just putting all the patches in one source package; it's not as if it's hard to #ifdef them for one architecture if necessary
<calc> yea
<calc> putting it all in one source will lead them to wanting to push as much as possible upstream though ;)
<calc> which is a good thing
<fabbione> morning
<bob2> http://ubuntu-bp.sourceforge.net/
<fabbione> bp?
<bob2> "
<bob2> The Ubuntu Backports project's goal is to provide a stable AND up-to-date Ubuntu Linux system by backporting desktop applications from Ubuntu's Development branches and Debian Sid."
<fabbione> amen
<calc> hahahaha
<calc> backports are evil
<bob2> and they want donations to support their "apt-get source -b firefox" work
<calc> hehe
<Treenaks> *sigh*
<enrico> Hello.  Is someone messing with the wiki?  I'm now allowed to log in anymore :(
<fabbione> hey ogra
<sid77> hi
<stuNNed> mozilla-thunderbird has been out for a few weeks now, any idea when it will make it into ubuntu unstable?
<stuNNed> n/m sorry about that, it's not in sid yet
<ogra> hey fabbione
<fabbione> hola
<ogra> wow thats latency now
<ogra> had a nice christmas ?
<sivang> ogra: low latency patches to the stock kenrel? where?:)
<fabbione> i hate xmas
<fabbione> no
* sivang would love to switch to doing midi/multi track recording in linux.
<ogra> me too, so i stayed at home and set up the imac i broght from the company to check my ubuntu builds of the screensaver.....GF is at her mother 400km away....
<ogra> sivang: i heard thats possible with the right HW
<ogra> sivang: but dont rely on me , i'm just waking up
<ogra> sivang: ...and i'm very slow in this :)
<sivang> ogra: ok heh :)
<sivang> fabbione: why you hate christmas? 
<fabbione> sivang: several reasons.. too long to explain here
<sivang> fabbione: k :)
<ogra> fabbione: just see it as some free days :)
<fabbione> ogra: i can't really... my gf loves xmas and she pushed me around all the 3/4 days in real pain
<ogra> argh
<ogra> ok....
<fabbione> http://www.fabbione.net/cgi-bin/blog.cgi
<fabbione> ogra: that might give you an idea ;)
* ogra reads
<fabbione> it's interesting to see how many people read URL's that are not for them :-)
<ogra> fabbione: looks like i got the opposite here.....my GF is gone and i can finally do my ubuntu stuff that i cant else bacause of work
* sivang LOLs to fabbione pleasure of people breaking up their X :)
<ogra> tahts sad....
<fabbione> anyway
<sivang> well, whoever uses a development branch should know what his doing.
<fabbione> gotta do dishes and a bit of shopping
<fabbione> bbl
<sivang> fabbione: c'ya
<ogra> ciao
<fabbione> re
* JD looks for a pmount/gvm/utopia guru
* sjoerd hides
* JD chases after sjoerd 
<JD> sjoerd: I now have a working mounting usb storage device
<Riddell> JD: use media:/ ioslave with hal backend
<JD> one small issue is that I have a loopback device on it
<JD> Riddell: pfft. not using KDE
* Treenaks is looking for the person who did NOT insert the Dutch translation for anything into rosetta.. even when they're available already (nl.po)
<sjoerd> JD: what kind of loopback device ?
<JD> sjoerd: so I put a small script on the device to mount it
<JD> sjoerd: just a ext2 filesystem "mount -oloop /media/usbkey/secrets.loop /media/usbkeys/secrets"
<JD> sjoerd: gvm says "do you want to run .autorun" and I say yes
<sivang> for writing complaints blogs like thius :   <revnumber>&userguide-rev;</revnumber>
<sivang>                                           ^
<sivang> /home/pooh/devel/docteam/faq/faq/trunk/usersguide.xml:20: parser error : Entity 'userguide-rev' not defined
<sivang>                 <revnumber>&userguide-rev;</revnumber>
<JD> only problem is that the device is mounted noexec :S
<Treenaks> JD: why is that a problem?
<JD> Treenaks: because gvm can't exec the autorun script it just asked me if I wanted to run
<sjoerd> Treenaks: because he wants to run something on it and gvm can't execute it :)
<sjoerd> JD: file a bug against gvm.. and we'll probably remove the autorun ability :)
* sjoerd doesn't think that the autorun stuff was a good idea anyway
<fabbione> hey jbailey 
<JD> sjoerd: hmmm having something in ~/.gvm would be better
<jbailey> Heya fabbione!  Happy whatever-winter-holiday-you-happen-to-celebrate! =)
<fabbione> ehheeh
<sjoerd> JD: any reason why your using a loop device btw ?
<fabbione> thanks! same there
<JD> sjoerd: because windows likes to format non-fat devices?
<JD> sjoerd: and at somepoint I might use an encrypted loopback
<sjoerd> ah
<sjoerd> we should start supporting encrypted filesystems on removable storage nicely rsn now
<JD> sjoerd: so the device is fat, but it has a ext2 filesystem on it for my gpg keys and stuff
<JD> sjoerd: that would be so lovely
<sjoerd> so you'll get a better solution for that
<JD> I want to plug my key in it get mounted and possibly for gnome-keyring to decrypt it for me
<JD> all wthout me doing anything (except giving a passphrase)
<Treenaks> JD: that'd be great :)
* Treenaks wants that too 8)
<JD> sjoerd: it can still make sarge :P
<Treenaks> Ubuntu SargE?
<Treenaks> :P
<sjoerd> JD: It is gonna depend on hal 0.6.x so probably not
<JD> sjoerd: oh well
<JD> how come?
<sjoerd> JD: see http://www.ubuntulinux.org/wiki/EncryptedStorage
<sjoerd> some notes about what we want to support
<sjoerd> JD: and http://lists.freedesktop.org/pipermail/hal/2004-December/001423.html
<Kamion> hmph, Mac Open Firmware has an interesting notion of "disassembly"
<Kamion> h# ff852e77 dis
<Kamion> ff852e77: 00967eff
<Kamion> ff852e7b: fc7e6802
<Kamion> THANKS, APPLE
<Treenaks> Kamion: get the PowerPC manual to decode the opcodes 8)
<fabbione> hey Kamion !
<Kamion> Treenaks: that's the plan ...
<sjoerd> fabbione: do you know if a ultra5 has temperature sensors ? (probably not, but you can never be too sure)
<Kamion> unfortunately the manual I had is on the powerbook's disk, which is currently running OF :)
<Treenaks> Kamion: 8)
<fabbione> sjoerd: not that i know.. sorry
<sjoerd> fabbione: k, thanks
<fabbione> HMMMM
<fabbione> huston this is apollo13
<fabbione> we have a problem
<fabbione> http://www.smcc.demon.nl/webcam/ <-
* ogra is writing a lengthy ranting mail to the ubuntuguide author......(upcoming next in the -users ML for everyone who likes to get scared)
<fabbione> Kamion: are you replacing mdz during these days?
<Treenaks> fabbione: we're shipping another version of that driver already
<fabbione> Treenaks: dude... they are the same
<fabbione> i did the merfe
<fabbione> merge
<fabbione> the version we have, has been taken a few days before this mess
<fabbione> and since upstream is dead
<ogra> fabbione: thats more than 2 months old.... i thought there was a new maintainer
<Treenaks> fabbione: http://www.saillard.org/linux/pwc/
<fabbione> ogra: we have 10.0.6-unofficial...
<fabbione> AHHH
<fabbione> thanks guys
<Treenaks> fabbione: no, the saillard version is the demon version + patches
<fabbione> Treenaks: i think the url was wrong in the patch...
<fabbione> now i reco the website
<ogra> ufff.... mail sent....
* fabbione needs some sugar
<Treenaks> ogra: the long one? about the brokenness of the Guide? :)
<ogra> yep
<fabbione> ogra: do you know anything about misdn?
<ogra> was necessary... i and bob2 had soo much support the last days, caused by broken systems of ppl following the guide
<ogra> fabbione: i'm just starting with it....important is that all the old isdn modules are blacklisted, they interfere
<fabbione> hmm i only need to update the kernel module...
<fabbione> i was trying to figure out how old is the one in our kernel and the one in their CVS repo
<ogra> ah, ok.... i didnt look at it for some time....
<fabbione> another one to update :-)
<ogra> fabbione: mvo is currently in there....
<Treenaks> fabbione: another nice set of drivers (not) is the quickcam set... it's 1 driver.. and 3 patched versions of the same driver with the same module name.. each of which works for a different set of cams
<Treenaks> fabbione: and the main driver author is on crack
<fabbione> aahah no no.. it's the same
<fabbione> Treenaks: hold on... talking about pwc?
<fabbione> i am way down a LOOOONG list of drivers to review...
<Treenaks> fabbione: no, quickcam (logitech)
<Treenaks> fabbione: not in ubuntu kernels yet
<Treenaks> fabbione: and in the current state, it probably won't be for a loooong time
<Treenaks> http://qce-ga.sourceforge.net/ and http://home.mag.cx/messenger/ etc.
<fabbione> Treenaks: please don't give me drivers that requires a patching level of 20 deps.
<Treenaks> fabbione: OK :)
<ogra> heh
* Treenaks will kick the upstram
<fabbione> like foo predeps on bar that predeps on baz but it has 3 f00 variant that are ....
<fabbione> Treenaks: that will simply increase my insanity level
<fabbione> and we do NOT want that.. do we?
<Treenaks> fabbione: oh no, it's just 4 patches (1 for each type of cam).. but the problem they're mutually exclusive
<Treenaks> fabbione: so I'll kick upstream into merging
<fabbione> exactly..
<fabbione> so it's no go
<Treenaks> fabbione: .. for now 
<Kamion> fabbione: mdz> not that I've been told; mdz's been sort of around ...
<Kamion> cool. if you telnet to openfirmware and then do 'boot hd:9,\\yaboot' or whatever, you get the yaboot prompt over telnet
<Treenaks> cool
<fabbione> ah
<fabbione> neat
<Kamion> presumably this is how you actually debug yaboot
<ogra> Kamion: is debootstrap error 132 == no target disk found ? 
<fabbione> can anybody connect to http://prism54.org/firmware/ ?
<jbailey> fabbione: It's not coming up, but I have one of those cards.
<jbailey> fabbione: Want me to fire up the laptop and get you the firmware? =)
<[Clint] > I have 1.0.4.3 handy
<fabbione> jbailey: i need to see if there is a firmware update :-)
<[Clint] > jbailey: plus it's illegal for you to give it to him
<fabbione>  1.0.4.3
<fabbione> that's what i have
<jbailey> http://www.google.ca/search?q=cache:9_Je_ADPHH4J:prism54.org/~mcgrof/firmware/+&hl=en
<fabbione> is there anything newer than that?
<fabbione> no
<fabbione> so that's good.. less work for me :-)
<Riddell> lamont: your upload of kdesdk does not seem to have been built
<fabbione> Riddell: http://people.ubuntulinux.org/~lamont/buildLogs/k/kdesdk/4:3.3.2-1ubuntu1/kdesdk_4:3.3.2-1ubuntu1_20041226-0237-i386-failed
<fabbione> i think it's a plain typo
<Riddell> fabbione: that's the old build which lamont fixed
<fabbione> i doubt....
<fabbione> there are no new versions at all
<fabbione> hmm
<fabbione> it has been accepted a ubuntu2
<Riddell> he said he'd uploaded it
<fabbione>    * Fix typo in Build-Depends.
<fabbione> yeah
<fabbione> probably he forgot to kick it back...
<Riddell> what does that mean?
<fabbione> Riddell: he needs to tell the systems to build the package
<fabbione> (in few very simple words)
<Riddell> doesn't they do that automatically when a package is uploaded?
<fabbione> in some cases no
<fabbione> and this is one of them
<lamont> fabbione: it should have... checking
<lamont> sigh.
<lamont> for a in ia64 i386 powerpc amd64; do wanna-build -b$a/build-db -dhoary --pretend-avail automake1._1;done
<lamont> all better
<lamont> fabbione: 260 Installed, 205 Needs-Build
<lamont> hppa, partial debian mirror locally, so lots of d-w's
<lamont> once it gets done with sweep one, then I'll add the stage1 archive in and see what happens from there.
<fabbione> lamont: hey...
<lamont> Riddell: because it was dep-wait 'automake1.', and that package hasn't arrived in the archive (duh), it won't auto-try a new kdesdk upload.  sorry about that.
<lamont> and fixed.
<lamont> fabbione: yo
<fabbione> lamont: when can i get an hppa chroot?
* lamont is about to get dragged out the door for a fun filled day
<fabbione> it doesn't need to be hoary
<fabbione> debian is fine
<fabbione> i only need our kernel-wedge
<Riddell> lamont: fair enough
<lamont> fabbione: let me get the cyclades set up first, eh?
<fabbione> lamont: sure
<fabbione> since i am going to release 2.6.10 tomorrow.. i could start giving it a spin on hppa
<amu> lamont: hold on, the md5 didnt matched, with ubuntu2, i builded ubuntu1 on another maschine
<lamont> amu: ??
<amu> kdeskd
<lamont> md5sum matched at upload for kdesdk ubuntu2
<lamont> I just unblocked the buildd's
<amu> i got a rejected mail from katie 
<amu> dpkg-source -x failed for kdesdk_3.3.2-1ubuntu2.dsc ( return code 6400 ) 
<lamont> grumble
<lamont> amu: it's building on all of them....
<lamont> did you upload a -1ubuntu2?
<amu> lamont: thx
<amu> lamont: yep
<lamont> that would explain it... my -1ubuntu2 was in the archive, so your's bounced.
<lamont> delta was to build-dep automake1.9, instead of automake1., per Riddell 
<lamont> but wanna-build still had the automake1. dep-wait, and needed a boot to the head.
<lamont> er, needed to be awoken.
<amu> lamont: yep, saw it in the buildlogs, Riddell told me this also ... so i uploaded 1ubuntu2 :) 
<lamont> heh
<lamont> anyway, off for another fun day of vacationing.
<amu> .. have fun 
<tklauser> Hi
<Kamion> ogra: 132 is signal 4, whatever that is on your system ('kill -l')
* Kamion finally manages to disassemble the bit of OF that governs what kinds of Mac partitions are bootable
<ogra> Kamion: already done, was a prob in -users with virtual pc
<Kamion> so, it *has* to be on an Apple_Boot* or Apple_HFS* partition
<Kamion> ogra: ok
* fabbione HATES DPATCH AND CAST A BLACK MAGIC SPELL ON THE AUTHOR TO MAKE HIM DIE FASTER
<fabbione> GROAR
<[Clint] > I hope you're going after dbs too.
<fabbione> ehehe
<Kamion> *snork* *quote*
* Riddell protests, my package definatly did not have that automake1. typo in it
* pinhead INFLICTS ENDLESS PAIN TO DPATCH AUTHOR
<Kamion> Riddell: must have been introduced by accident by the uploader
<fabbione> Kamion: you also copied the typo ;)
<fabbione> CAST -> CASTS :P
<Kamion> I figured that was just Itaglish
<Kamion> feel free to fix :)
<fabbione> ehehe
<Kamion> woohoo, working powerpc USB boot. we'll have that in Ubuntu by hoary release
* ogra applauds
<Kamion> it'd be nice to get ofpath to recognise USB sticks, but that may be harder
<JD> Kamion: does OF deal with usb serial devices?
<Kamion> you mean like a USB serial console?
<JD> yeah
<Kamion> you could almost certainly write a driver for it, but I suspect it isn't there by default
<JD> ;2
<JD> argh
* smurfix does that quite often, too :-/
<Treenaks> ogra: do you have some weird email<->brain interface?
<ogra> hehe, why ?
<Treenaks> ogra: you reply do -user mail before the original mail reaches my inbox :)
<Treenaks> give us a chance! :)
<ogra> just a fast server *g* (still a woody box)
<Treenaks> I'm on a sarge box which takes ages to deliver mail (spamcheck, viruscheck, [you-name-it] -checl)
<ogra> ok, i try to hold it back some mins in the future :)
<ogra> the trick is to run all checks at the client side :)
<Treenaks> ogra: ah! :P
<Treenaks> but my server is my client ;
<Treenaks> :)
<ogra> heh
<mjg59> Hrm. There's a couple of chunks in the latest acpi patch that we probably want in 2.6.10
<Treenaks> also, inotify seems to be absent in 2.6.10-vanilla
<sivang> I already said that over the rosetta channel, and as it seems important I would ask here again -
<sivang> Maybe it's worth while to announce a message to hold uploading of stuff into rosetta by translator until the official braches are merged in?
<sivang> I have already some peopel over my country team that want to start trasnlating, some of them I think even attempted uploading some templates..
<sivang> this could result in the random arbitrary translations floating problem..
<Treenaks> sivang: uh.. most stuff in Rosetta has been RE-translated into Dutch because the Rosetta people didn't upload the already-translated .po's
<sivang> Treenaks: this will happen also for hebrew I think, I don't know how long I can stop people from uploading :) although I asked really nicely.
<Keybuk> mjg59: oh?
<mjg59> Keybuk: Nothing likely to help you, I'm afraid
<Keybuk> aww
<mjg59> Tell tbm to get his docking station fixed and I'll see what I can do
<Keybuk> is the parallel port you need, right?
<mjg59> Yeah
<sivang> mjg59: the acpi-support pkg in hoary is outdated in a way? suspend to ram seem to not work on the inspiron 8200..
<mjg59> sivang: In what way?
<sivang> mjg59: well, the fans keep on going, network is up, disk access continues..
<mjg59> How are you trying to suspend it?
<mjg59> sivang: Try running /etc/acpi/sleep.sh and then send me the dmesg
* mjg59 goes for food
<HcE> hmm
<HcE> should I have a daemon to be able to go to sleep with acpi?
<HcE> sleepd or something?
<sivang> mjg59: will do :)
<sivang> mjg59: I don't even have this script..
* jordi summons mjg59 to #gnome-debian.
<mako> smurfix: hey
<mako> smurfix: you around? i want to know what the ideal email address for country team stuff should be? 
<smurfix> mako: around
<smurfix> mako: country-team@canonical?
<mako> smurfix: that would be ideal :)
<mako> smurfix: i just mentioned the email yu'd be using to email me about this so far in the CC summaries
<mako> that i just sent to news
<mako> -news even
<mako> smurfix: we can look into getting a role account set up but that will (cleary) have to wait for elmo to return
<smurfix> mako: Otherwise, to get me personally, using smurf@debian would make sense.
<mako> i think using @debian addresses for ubuntu thing may be not that great an idea
<smurfix> mako: Hmmm
<smurfix> mako: OK, then hire me and give me a @canonical address.    1/2 :-)
<ogra> hey, me too !!
<smurfix> mako: The one you used is the next best choice though, so OK.
<mako> there are people in debian who are a little annoyed at unbuntu/canonical.. we don't need to invite "You are abusing debian resources" on top of everything :)
<ogra> *g*
<smurfix> mako: true ...
<mako> smurfix: i looked and saw what you emailed me about country teams from most recently
<mako> my lbdb picks up emails from you at like 10 different addresses :)
<smurfix> mako: Ten's a lot. Probably includes all the @noris.* addresses I still carry around in my gpg keyring.
<calc> heh
<calc> give away @canonical so people can use them for their debian packages ;)
<calc> appear to slowly take over debian, muhaha ;)
<kylem> slowly?
<mako> calc: people will see it whether we "appear" to be doing it or not :)
<calc> heh
<kylem> anybody who pays attention already knows who works for canonical.
<Keybuk> everyone thinks we're taking over debian *anyway*
<smurfix> Keybuk: ... for some more-or-less fuzzy meaning of "we" and "take over", that's actually true ...
<ogra> heh
<sid77> hi
<calc> there's nothing to take over, everyone has already converted to using ubuntu ;)
<ogra> not the mpis ppl though
<ogra> mips
<ogra> or sparc
<ogra> etc
<smurfix> not to forget http://wiki.debian.net/index.cgi?LetUbuntuReleaseForUs
<kylem> i actually don't mind that plan, but my favorite con is "What about the rest of the toys in Toy Story? They want to be released as well!" :)
<ogra> woo, the cons list is a lot longer
<smurfix> ogra: doesn't mean it carries more weight though
<ogra> i know , quality matters, not quantitiy
<calc> "What about the rest of the toys in Toy Story? They want to be released as well!" best argument to keep releasing ;)
<calc> kylem: ah didn't see your comment :P
<kylem> :P
<smurfix> One might argue that LetUbuntuReleaseForUs already *is* the current release strategy, as opposed to ReleaseWhenReady :-/
<mdz> fabbione: I'm going to be around most of the time
<Keybuk> trying to get Debian Developers to release sarge is like trying to get them all to go to dinner
<seb128> mdz: when a guy ask if -devel is the right place to mail when a package does build, include something saying that's not when you reply :p
<seb128> s/does/doesn't/
<mdz> Kamion: yes, absolutely we should put ubuntu-keyring in main
<mdz> Kamion: in fact it probably ought to go in base
<mdz> seb128: but it is, until (and unless) we have a separate mailing list for MOTU
<seb128> grumpf
<mdz> it's certainly better than filing bugs
<seb128> the list is about the development, isn't it ?
<seb128> bugzilla is the right place
<mdz> seb128: these are universe packages
<mdz> if they're filed in bugzilla, they are ignored
<mxpxpod> fabbione: ping
<mdz> on -devel, there is the hope that someone will see it and care to fix it
<mdz> the reason I didn't say anything on the matter is that I don't have a good answer yet as to the correct place to send those reports
<mdz> the MOTU stuff needs some organization
<sivang> mdz: if ubuntu universe comes from sid, maybe just use this as a call to give even more support to sid's pkgs through ubuntu?
<mdz> sivang: what do you mean?
<sivang> mdz: thuse utilizing sid's already existant infrastructre
<sivang> mdz: that it, debian BTS etc..
<mdz> that would require that people wanting to do maintenance in universe become Debian developers, and we absolutely will not do that
<mdz> we will empower users to do work in universe directly through Ubuntu
<sivang> mdz: but if you let people upload and contrib, and ubuntu staffer sync it to sid, then they don't need to become dds
<sivang> mdz: they will be like "sponsered" from debian's point of view.
<mdz> I guess I don't understand what you're proposing, then
<sivang> mdz: probably :) I will try to rephrase and say again...
<mdz> the problem is that Ubuntu users don't have a clear place to go for problems in universe
<mdz> the solution proposed by the community council is the formation of an Ubuntu team to do that maintenance
<mdz> Debian cannot be a solution to this problem, because it has its own social and organizational requirements which are separate from Ubuntu's
<mdz> that team will, of course, be encouraged to feed their changes upstream to Debian in the usual ways
<mdz> but they will not upload packages to Debian, unless they happen to be Debian developers and can do so according to Debian's methodology
<mdz> they will upload to Ubuntu
<sivang> yes, and DD which are also ubuntu maintainers could "sponser" this uploads back to debian ? or is this colliding with debian strucutre again?
<sivang> *DDS
<mdz> in Debian, it is only acceptable to upload packages that are maintained by someone else, under specific circumstances
<sivang> I see.
<mdz> so it would be in extremely bad taste to push those packages to Debian as a matter of course
<sivang> then an infrastructre must be set up...
<sivang> for the MOTU people.
<seb128> mdz: if people start using -devel as a bug tracker for universe the list will be flooded with that and most of the devels will not keep reading it because of the bad SNR
<mdz> sivang: yes, that is the plan
<sivang> this could maybe take the from of debian forge....then ubuntu would build those pacakges, and a proper note would be made to tell peopel who enaable universe that their system may break...but a bug system must be set up.
<mdz> seb128: if that happens, we will absolutely create a new list
<sivang> (by saying debian forge I meant alioth)
<seb128> mdz: ok ...
<mdz> I am concerned about prematurely splitting lists; it divides the community's attention
<lamont> creating new lists should only be done to address traffic overload, not because of perceived possible traffic issues.
<seb128> I already find we have too many bug with user questions or bug reports on -devel
<seb128> s/bug/mail/
<seb128> but perhaps that's only me ...
<mako> wow.. #ubuntu-devel lives!
<lamont> mako: yeah, but we're all on vacation, I think.
<sivang> maybe a seperate bug reporting system should be set up for universe...
<mako> lamont: i'm not :)
<lamont> mako: ah, ok.  I am.
<ogra> sivang: launchpad 
<mako> lamont: i'm FREEZING in an nyc apartment with broken heat wish i was back in spain
<sivang> ogra: yes :)
<mako> :)
<sivang> mako: me too :)
* mako makes like an eskimo and *chills*
<mdz> seb128: there are some, but compared to, say, debian-devel the SNR is great
* ogra hands a blanket to mako
<seb128> mdz: that's a start. If we don't stop it now .... 
<mdz> seb128: ideally, we will eventually have a proper support tracker and bug tracker for everything, and that should help a lot
<seb128> people will start thinking that's the right list for this sort of stuff and then we are stucked
<mako> ogra: dude, i'm been learning to type from under a down blanket  all day :)
<mdz> until that time, it doesn't seem right to tell people to just go away
<mdz> they need someplace to go
<lamont> mako: hit -6F last week here.
<seb128> bugzilla for bugs, -user for user questions
<sivang> mdz: a temporary list until malone is up and running FOSS wide?
<mdz> support stuff should definitely go to -user
<mako> or any of the support channels
<ogra> mako: i know how that feels lived 2 years in an old factory without heating ;)
<smurfix> lamont: ***brrr***
<mdz> but we cannot have every bug report about a universe package go into bugzilla; it is already very difficult to work with
<mako> paid support, etc
<mdz> they need to be separate
<seb128> mdz: and we can get every bug report about universe on -devel so ?
<mdz> seb128: they require much less resources to process on -devel than in bugzilla
<seb128> because few people use it atm
<mdz> and more people see them, so they are more likely to get fixed
<seb128> I would rather use -users
<mako> seb128: only a few developers read -users
<mdz> I'm happy to leave this up to whoever drives the MOTU
<mdz> I think it will probably become a separate list
<seb128> mako: I now, but if we keep it in this way, only a few developers will read -devel
<seb128> s/now/know 
<sivang> mdz: probably, it's not exactly suited for -users, and -devel we want to keep as low in traffic as possible.
<mako> why not a seperate bugzilla?
* sivang is really glad to read about 60-80 mails per day in -devel.
<seb128> you guys don't read the gnome list ? 
<mako> seb128: i don't
<sivang> seb128: I read gnome-love...
<seb128> desktop-devel is a good example of list with very few RSN
<mdz> mako: malone
<mako> mdz: well, if we had malone doing what we wanted this wouldn't be an issue at all, right?
<seb128> I mean, they do this because devels are busy and tend to unsubscribe really quickly when a list start to deal with user threads and bug reports
<mdz> mako: well, there is more to universe than bug reports
<sivang> IIRC, malone is supposed to be the FOSS Universal bug tracker right?
<mako> mdz: heh, clearly :)
<mdz> personally I think that bugzilla is not very workable for this
<mdz> whether a separate instance, a separate product, whatever
<lamont> hrm.. mysql-dfsg unhappy x4
<mdz> it would be confusing
<mdz> users would need to know ahead of time where to go
* mako nods
<mako> i guess a seperate mailing list is the sanest course when things out of hand
<seb128> just add a list universe so ...
<sivang> mailing list for the meanwhile, malone in the future.
<mdz> I don't want to create a mailing list when there is no one to subscribe to it
<lamont> my bad
<mdz> I think this will all become a non-issue when MOTU happens, which should be RSN
<sivang> RSN, is this something I missed from the last CC meeting? :)
<mdz> I think getting that set up is community council territory
* mdz coughs in mako's direction
* mako was happily off in another window swamped by something else
<mako> if somebody has an idea of what it should look like, we can get a proposal and we can push it forward
<mako> i am currently writing up to *other* proposals for the next CC meeting so i would be thrilled if it could be someoen else :)
<mako> two other proposals :)
<mako> mdz: is there someone that wanted to drive it?
<mako> i'm happy to work with them toward a proposal
<mdz> mako: not sure; I missed the last meeting due to being deathly ill
<mdz> I think the only must-have is someone to take point
<mdz> MOTMOTU so to speak
<mdz> someone to coordinate and drive the thing
* lamont wonders off to do more family stuff.
<sivang> yet another mako task? :)
<mako> sivang: i can't do it
<mako> doing mako+lu's job is *killing me*
<mako> :)
<sivang> mako: notice the smile sign...:)
<mako> well, i'm not doing lu's job nearly as well as she was i'm sure :)
<ogra> oh, so my wiki bugs go to mako :)
<mako> ogra: absoultely not
<mako> ogra:  :)
<ogra> *g*
<mako> ogra: enrico is helping out with the wiki stuff.. 
<ogra> ah, ok
<sivang> ogra: enrico has done a great deal of wiki fix works..report it to him
<ogra> i already have...
<ogra> yesterday
<ogra> was just wondering, because bugzilla reports it to lu i seems
<ogra> it
<sivang> ogra: you can file a bugzilla report on the documentation component, this is assined to enrico
<ogra> ok, next time i do ....
<mdz> sivang: the person leading the MOTU stuff should not be an existing Ubuntu developer, but someone from the community with the skills and interest to do it
<jdub> pants off
<jdub> 33.6k mdem connection, 100 of 2775 emails downloaded ;)
<ogra> lol
<ogra> compress....harder
<mako> jdub: *AWESOME*
<sivang> mdz: true, so he'll have all the time for that. he should be probably also a very skilled in the way of packaging..
<mako> if we talk a lot on IRC, we could have a noticeable slowdown affect on jdub's mail download
<jdub> also, i have ubuntu disease
<sivang> mako: hehehehe
<jdub> thanks to marianne and mdz
<jdub> gar! :)
<sivang> jdub: what are the symptoms? 
<mdz> jdub: if you're only sick now, you didn't get it from me :-P
<mako> jdub: i thought you said marijuana and mdz at first
<ogra> dripping nose ?
<ogra> hehe
<mdz> mako: a formidable combination
<jdub> nose, throat, walking dead, etc.
<mako> if i had a nickle for ever time i've heard that one
<mdz> SteveA was carrying the torch last
<jdub> mdz: i'd like to shift UVF back to jan 5th
<mako> mdz: i think jordi had it
<mdz> jdub: rather than doing it in the middle of everyone's vacation?  I agree
<jdub> mdz: but am in mail hell atm, so haven't been able to send, etc.
<sivang> jdub: what is the UVF?
<mako> sivang: upstream version freeze
<jdub> upstream version vfreeze
<jdub> mdz: particularly elmo's ;)
<mako> or "unprecented viral fuckage" in jdub's case at the moment
<mako> seriously, i think the cold in this apartment might KILL ME
<mako> i'm going to make a pilgramage to the WARM CLOTHES STORE
<sivang> mako: isn't there a place more hot that you can escape to? what about your neighbors? :)
<jdub> mdz: could you mail on my behalf?
<sivang> jdub: so the 5th it is?
<ogra> mako: a hairdryer under the blanket is great  .....
<mako> ogra: no hair dryer :(
<ogra> ah...doomed
<ogra> 500 candles ?
<mako> ogra: i have a lot of candles.. and an oven
<sivang> mako: fire the oven up and close all the windows :)
<ogra> ah, so make a fire then....
<mako> dude, i would *insane* if i had any windows open
<sivang> mako: but be aware, it may consume all the oxygen inside.
<Mithrandir> mako: take a few bottles, fill them up with hot (or boiling) water, put bottles in bed.  If you go to bed at the same time, put socks around them to avoid burning yourself.
<mdz> jdub: ok
<sivang> mako: I Know, GWeather applet says  -4C in central park
<mako> 10 points for a good idea on staying warm from the norweigan!
<sivang> mako: I'll send you some fluffy furry warm bottles from here :)
<sivang> mako: they have shapes like bears, bunnies etc..
<daniels_> (and in the place where it's actually summer, it's 18degC, and bucketing down hail.  whoo hoo.)
<jdub> new vim packages... "Most important change is the usage of alternatives instead of diversions."
<sivang> jdub: isn't GNOME 2.10 to be released on the 9th? and it is a hoary goal..
<sivang> jdub: march , that is.
#ubuntu-devel 2005-01-08
<Josephus> hey
<daniels_> jdub: fwiw, wouldn't mind an xorg exemption from uvf, especially since we're already totally up-to-date on 6.8.x branch anyway
<jdub> sivang: uvf doesn't affect gnome
<jdub> daniels_: xorg is a feature goal, and packaged by us - just a matter of having upgrades confirmed, etc.
<sivang> jdub: ah ok, so gnome freatures can be still added..ok
<daniels_> jdub: cool
<mako> ooh, titbread@hotmail wants 100600 ubuntu CDs
<mako> *titbread*
<sivang> mako: what with my mere 200 cds pack? will I ever get it? :)
<mako> sivang: dude, i can't track individual orders.. you can order more if you'd like
<sivang> mako: pitty is, I've checked with shipit and it says my shipment has already been sent. that mean the cds are lost..:(
<Josephus> so titbread gets what he wants? :)
<mako> or they will ge there
<mako> Josephus: i *highly* doubt it
<mako> Josephus: i just emailed him
<Josephus> :))
<Josephus> what was the largest order you processed?
<mako> Josephus: like actually sent
<mako> ?
<Josephus> yes
<mako> Josephus: 5000 to the shuttleworth foundation
<mako> but we'll be sending 5000 to another group that is organizing huge events and want to promote ubuntu
<mako> those are special cases though
<mdz> gah
<mdz> ubuntu-devel: "maybe some [X]  detection and autoconfiguration would be fine"
<mdz> in the same message "please include the ipw2100 driver" :-)
<Josephus> that'd be me
<lamont> hehe - kernel-source-2.6.9 is ftbfs. :-)
<mako> ok.. dinner time fo rme
<mdz> lamont: we ought to remove it from the archive
<lamont> mdz: but that violates the spirit of universe, no? :-)
<Josephus> i know that autodetection stuff sounds lame, but i don't know how to phrase it...
<mdz> lamont: yes, but in this case it's terribly confusing for users
<Josephus> mdz: and yes, i was wrong about ipw2100
<mdz> Josephus: you pretty much implied that we didn't do autoconfiguration of X, which is a bit disparaging toward the people who put a huge amount of time and effort into doing exactly that
<ogra> Josephus: for 99% of the users the autodetection of X works out of the box ;)
<lamont> mdz: we could create a 'stuff-we-dont-believe-in' suite that is just past the multiverse, and is source only.... :-)
<sivang> Josephus: especially on crappy dell laptops :)
<ogra> sivang: thats the missing percent ;)
<mdz> Josephus: at any rate, I followed up with instructions for how you can help get it working on your hardware
<sivang> ogra: we shoudl have a "ubuntu is rocking" site for good testimonials 
<mdz> Josephus: but in the future, it generates more good will to look first, before saying that something is missing :-)
<Josephus> sorry i didn't wanted to be sound like i despise your work, i just haven't looked into that such thing really exists :/
<lamont> mdz: if we do, it should be kernel-patch* kernel-image-* and kernel-source-*
<mdz> Josephus: if the probe fails, it asks you questions instead
<mdz> Josephus: so in your case, it sounds like your hardware was probed successfully, but for some reason the resulting config wasn't correct
<mdz> could be buggy hardware, or something else
<ogra> mdz: do you think its ok to put a link in the java wiki page pointing to davyds java package ? (http://wiki.arslinux.com/Ubuntu#Java_1.5)
<mdz> ogra: anything and everything having to do with Ubuntu is OK for the wiki
<ogra> ok, i was fearing the legal stuff...then i'll do it now :)
<sivang> ogra: very good package, gave it a test drive and the 3 steps remedy works quite well.
<ogra> sivang: its just created by the java-package package for universe....but doesnt scare the users as much.... :)
<ogra> multiverse, sorry
<lamont> seb128 about?
<mdz> he was a short time ago
<lamont> mdz: did we ever file the FTBFS bug on baz?  I know they know about it, but figured I'd get it in the bts.
<lamont> along with the rest of the 13 FTBFS's that I have hanging around.
<lamont> 13 FTBFS, 7 of them ia64.
<mdz> lamont: last I knew, baz was building
<lamont> 1.0.1-2 has 64-bit issues
<lamont> and is current hoary.
<mdz> ok, yes, please file a bug
<mdz> 1.0.1-1 was FTBFS everywhere, but that was fixed with -2
<mdz> I wouldn't assume that they know; I think they all use i386 or powerpc
<amu> Windowlike - random crashes http://www.kde-apps.org/content/show.php?content=19198
<amu> :-) 
<ogra> lol
<amu> "After starting this tool, it will go into daemon mode and starts to kill randomly random processes...This will give you real-windows-feeling!" 
<ogra> amu: i got an additional imac here (additional to the grey g4), if you got anything to test (livecd wise) tell me :)
<amu> ogra: cool! 
<lamont> mdz: I know lifeless and I discussed it in mataro
<mdz> ah
<lamont> "fixed in 1.1, but we're not gonna upload that for a month"
<sivang> lamont: hehe
<mdz> lamont: it remains to be seen how baz and UVF will interact
<mdz> probably depends largely on how 1.1 turns out when they've blessed it :-)
<mdz> amu: what does it print the first time?
<lamont> UVF?
<sivang> upstream version freeze
<mdz> lamont: upstream version freeze
<lamont> ah, ok
<sivang> :)
<amu> mdz: /dev/cloop0 no such device
<mdz> amu: /dev/cloop0 needs to exist before the script is run
<mdz> amu: so probably you need to load cloop, and wait for it to be created by udev
<amu> mdz: yeah i load it before calling the create_snapshot 
<mdz> amu: and wait for it to be created by udev
<mdz> it can take several seconds
<amu> hmm atm i put a sleep 3 before loading it .. 
<mdz> while sleep 1; do if test -b /dev/cloop0; then break; fi; done
<amu> hehe, thx 
<mdz> amu: we need a name for the new live stuff
<amu> liveCD NG :) 
<mdz> it should not be specific to the type of media, or to Ubuntu
<ogra> hmm, regarding all the illnes in mataro, flubuntu ?
* lamont files some bugs
<amu> mdz: Ubunt{u}nix *ducks* 
<lamont> the lack of lock-stepping in udev is quite annoying sometimes...
<calc> sounds like gpdf might be useful enough to get rid of xpdf by hoary release
<amu> mdz: oh my god, with qemu it needs 6sec. before coop was C[C[Cup :( 
<Riddell> calc: kpdf experimental branch is fantastic
<amu> lamont: any reason why kde-18n didnt reached archive? 
<mdz> calc: cool
<lamont> amu: ISTR it was new.
* lamont chekcs
<amu> lamont: yep :)  
<calc> mdz: did you see the blog entry about redhat's hacking of gpdf?
<mdz> calc: no
<calc> http://webwynk.net/jrb/#1103781637
<calc> hopefully they can get that into shape soon
<mdz> speaking of qemu, does qemu-fast work for anyone?
<mdz> it hasn't worked for me on any hardware I've tried
<lamont> amu: almost certain
<mdz> zsh: illegal hardware instruction  qemu-fast [...] 
<lamont> so that'd be an elmo thing
<sivang> mdz: I think it's still in _heavy_ development..
<amu> lamont: okido, thx, was surprised why orig.tar.gz is in, buildlog say all ok, but deb's are missing.
<sivang> mdz: I just can't wait for this to get stable :)
<lamont> amu: fwiw, new uploads that wind up in new will get wedged in 'Uploaded' instead of 'Building'
<mdz> calc: that sounds like they are writing a replacement for gpdf, rather than working on gpdf
<lamont> mdz: bz #4530 - should we leave that open until it's actually fixed in hoary, or let it remain resolved?
<lamont> (because it's not...)
<calc> mdz: hmm yea
* lamont wonders exactly when UVF is, goes looking
<lamont> ah, this week.  right.
<ogra> i love our users: <winipegm> sumthing in the thing wasnt enabled
* lamont tries to remember whether we decided on isakmpd or racoon (both of which are currently in universe)
<mdz> lamont: we didn't, and that's why they're both still in universe
<lamont> ah, ok
* lamont is thinking he may take a run at configuring ipsec this week, after he hooks up the cyclades
* lamont wonders if there's a trivial line to add to apt.conf to turn off archive validation with 0.6...
<lamont> or rather, what that obviously-present option would be.
<lamont> alternatively, I guess I could start signing my archive.
<mdz> lamont: yes, there is, it's in the man page, and yes, you should start signing your archive
<lamont> mdz: yeah
<lamont> it's on the list, but not quite above the cutline yet.
<lamont> it's right after getting apt-ftparchive generate happy, and such/.
<mdz> apt-ftparchive generate needs support for Release files, too
<mdz> I'd very much welcome a patch for that
<lamont> I thought it creates those...
<lamont> ah, that's apt-ftparchive release
<lamont> heh
<mdz> right
<mdz> generate is supposed to let you do everything with a config file, but it doesn't do Release yet
<mdz> primarily because I don't use generate
<lamont> ok.  once I figure out generate enough, I'll work on a generate/release patch
<lamont> but actually, I think I should probably work on postfix soon, maybe even this week...
<jdub> mdz: yes, evince uses code from all the gnome viewers and replaces them
<jdub> mdz: it's the amalgamated 'Preview'-like viewer than martink was going to work on, but done by different people
<jdub> (gar, over-the-cude development, gar)
<jdub> s/cude/cube/
* jdub so wants to upgrade but can't on this shitty connection ;)
<lamont> jdub: I thought I was the only one with the  crap connection
<jdub> lamont: at pipka's parent's house
<lamont> ah, ok
<lamont> hi pipka
<edomat> lamont: nop, you should come to argentina, most people use dial-up still and i'm fortunately to share a 256 kb dsl connection with my roommate
<edomat> i'm in the process of making a ubuntu repository at my university
<jdub> edomat: rock!
* jdub wants to go to argentina
* lamont would like to get to argentina as well.
<lamont> edomat: I live at the end of an 802.11 link that is 28km long, rate shaped to 256kbps
<edomat> well, come whenever you want, i think that there's space at home :D
<lamont> and any time I use > 56kbps agregate over a 5 minute period, it costs me.
<lamont> well, the first 3.2GB is free.  after that it hurts.
<edomat> wow... i see
<lamont> edomat: the really tragic thing is that I live ~300 meters beyond the limit for the local DSL RT.
<edomat> lamont: ops
<calc> lamont: setup a wifi connection
<jdub> later dudes
<edomat> bye dudes
<mdz> calc: er, that's what he's done
<lamont> calc: that's what I'm using... sadly, the topography isn't very conducive to a local link in the right direction
<calc> lamont: oh :\
<calc> mdz: i meant to someone that has dsl ;)
<lamont> calc: yeah.
<edomat> well, i have to reboot my ubuntu to see if my new linux-restricted-modules-2.6.9 package works with the 6111 nvidia driver for my tnt2 card :P
<edomat> i was the one of the mail :)
<lamont> fabbione: you around?
<fabbione> morning
<fabbione> lamont: now :-)
<fabbione> mjg59: ping
<mjg59> fabbione: Yo
<fabbione> yo
<fabbione> ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.10/acpi-20041210-2.6.10-rc3.diff.gz
<fabbione> any good?
<fabbione> i am preparing 2.6.10 and i heard rumors that aCPI is crack
<fabbione> and that patch fixes the shit
<mjg59> Primary acpi crackness in 2.6.10 is the alsa brokenness, which ought to be fixed in -final
<mjg59> Len posted an acpi patch for -final yesterday, though. There's at least a couple of hunks we want from it
<fabbione> there is .10 final already.. that's what i am working on
<mjg59> Probably safe to go with the entire thing, though
<fabbione> yeah that's the one i am talking about
<fabbione> ok
<fabbione> since 2.6.10 isn't default kernel we can pull all of it in
<mjg59> There's another patch we want, which I can push to you later on
<fabbione> mjg59: if you have it handy i would much rather like to have it now
<fabbione> i am going to flush the queue of patches today and fix the configs
<fabbione> so that i might be able to upload at the end of the day
<mjg59> Ok, give me a second
<mjg59> (Need to go and catch a plane in 5 minutes or so :) )
<fabbione> mjg59: ah ok.. don't worry than
<fabbione> if it doesn't require CONFIG_ changes i can push it in the last minute
<mjg59> Yeah, no CONFIG_ changes
<fabbione> ok.. go catch the plane
<mjg59> http://www.codon.org.uk/~mjg59/tmp/resume-finish-split.patch
<mjg59> Fixes PCI resume on various machines
* mjg59 leaves
<zeratha> I tried to ask on the #ubuntu channel, but got no reply, so I'm sorry to bother you all. I just did an upgrade and now the sound won't work. It can't seem to find the mixer or sound device. Can someone help please.
<abelli> smurfix: ping
<smurfix> abelli: 
<Treenaks> smurfix: wide unicode character, not available in "fixed"?
<smurfix> It's Chinese. "pong". As in "ping pong". 
<Treenaks> ah
<smurfix> Now I need to find a font with U#2323 in it...
* fabbione starts a build orgy
<smurfix> U#x2323 even (smiley)
<Treenaks> fixed has that one :)
* smurfix wonders why that isn't in his font list
<Treenaks> smurfix: because it's an "old style" X font (in xterm)
<Treenaks> smurfix: not one of the new ones
<fabbione> not TOO bad...
<fabbione> 2.6.10 FTBFS on 5 arches over 5
<Treenaks> nice
<fabbione> BINGO!
<Treenaks> fabbione: sounds like you're going to have a nice day ;)
<fabbione> hell yeah
<fabbione> they all fail in different ways
<olivier> Greetings. I tried to get vanilla woody debian on my hoary to compile a .deb on it (via pbuilder that use debootstrap) and debootstrap failed complaining about mounting /sys in the chroot. AFAIK, /sys is in Ubuntu/* and not in Woody. I had to get get an Unstable(from Debian rather Ubuntu) debootstrap to generate my chroot env. Should the Ubuntu version of debootstrap have Ubuntu suite (like hoary) in addition of Debian suite (woody, etc.) and han
<maswan> olivier: /sys is a 2.6 thingie, IIRC. and woody is ancient enough to not mix well with 2.6 kernels.
<olivier> maswan: ok, thanks for the answer
<fabbione> Kamion: ping
* fabbione needs ppc guru
<smurfix> fabbione: ppc, or Mac?
<fabbione> smurfix: it doesn't really matter
<fabbione> something that uses a _powerpc.deb
<fabbione> would do...
* fabbione warns smurfix that the problem is gcc/kernel related
<mjg59> fabbione: Did that patch apply ok?
<fabbione> mjg59: yup
<mjg59> Rocking
<fabbione> compiled already
<fabbione> mjg59: i might upload today if i can at least fix the FTBFS on ppc
<fabbione> ia64 can die a slow death
<smurfix> fabbione: unfortunately, right now I don't have a ppc box here, so ...
<fabbione> all the others are GO
<fabbione> smurfix: thanks anyway
<mjg59> fabbione: Ha
* fabbione pinhead
<mjg59> fabbione: Oh, damn. I meant to ask about a CONFIG change
<mjg59> No problem if it's too late, though
* pinhead INFLICTS INFITE PAIN TO PPC KERNEL PEOPLE FOR NOT TAKING CARING OF THEIR OWN SHIT
<fabbione> mjg59: such as?
<fabbione> i am still in time to change configs around
<mjg59> The one that makes USB have power management support
<mjg59> With big EXPERIMENTAL flags
<fabbione> that also reminds me that i forgot to add the reiserfs love...
<fabbione> mjg59: hmmmmmmmmmmmmmmmmm
<fabbione> what the heck.. it's a new kernel
<fabbione> LET'S BRAKE IT TO HELL!!!!!!!!1
<mjg59> I guess you've thrown in the intelfb, ACPI video and ibm-acpi stuff?
<fabbione> they are already on iirc
<mjg59> Yeah, I think they default to M
<fabbione> 386:CONFIG_ACPI_VIDEO=m
<mjg59> Excellent
<fabbione> k7-smp:CONFIG_ACPI_IBM=m
<mjg59> It doesn't work on a single machine I've tried it on, but still
<mjg59> It's kind of neat
<fabbione> k7-smp:CONFIG_FB_INTEL=m
<fabbione> do i miss something?
<mjg59> fabbione: Nope, that's it
<fabbione> this kernel will break the shit
<fabbione> i am sure
<mjg59> Hrm. Some time, I should send you the Panasonic ACPI stuff
<fabbione> mjg59: you are in good time if you want :-)
<mjg59> http://www.da-cha.org/letsnote/
* Treenaks senses kernel addiction :)
<fabbione> Treenaks: i still stick with my blog
<Treenaks> fabbione: you have a blog?
<fabbione> Treenaks: yes.. i need to get it hooked up to planet.*
<Treenaks> ah :)
<fabbione> and i am not even sure how the rss feed works...
<fabbione> someone will have to check it for me
<Treenaks> url? :)
<fabbione> http://www.fabbione.net/cgi-bin/blog.cgi
<fabbione> started like... 2 entries ago
<Treenaks> fabbione: ah, sounds great already :)
* fabbione dedicates "The unnamed feeling" to the dpatch maintainer
<fabbione> "AND DIE.... AND DIE A LITTLE MOREEEEE"
* Treenaks had to drive to his colocated server in Amsterdam on christmas day, because 2.6.9 refused to notice that really, the ipv6 tunnel was DOWN
<Treenaks> so I had to alt+sysrq+SSSSUUUB
<fabbione> Treenaks: eh?
<fabbione> enter in ipv4...
<Treenaks> fabbione: no that's the trick.. 
<fabbione> a tunnel down... doesn't take the machine to that state
<Treenaks> fabbione: I upgraded to 2.6.10, and did a 'shutdown -r now'
<fabbione> ah clever
<fabbione> i don't understand why people keep using shutdown directly
<fabbione> there are:
<fabbione> reboot
<Treenaks> fabbione: but it refused to bring down my ipv6 tunnel ("use_count 1" or something?)
<fabbione> poweroff
<fabbione> halt
<Treenaks> fabbione: try those on an AIX machine
<Treenaks> fabbione: or even Solaris I think
<fabbione> ehhehe
<fabbione> but damn.. it's linux :-)
<fabbione> or make the aliases
<mjg59> fabbione: We should sort you out with more recent ipw2100 drivers and stuff at some point too, really
<Treenaks> fabbione: but anyway -- all network interfaces, daemons etc. were down.. except for my sixxs.net tunnel
<Treenaks> fabbione: so it wouldn't reboot
<fabbione> mjg59: done already
<Treenaks> fabbione: so I had to GO THERE AND DO IT MYSELF.
<mjg59> fabbione: Dude, you rock
<Treenaks> ON CHRISTMAS DAY.
<fabbione> Treenaks: ehehe
* Treenaks hates Linus now
<fabbione> mjg59: http://people.ubuntulinux.org/~fabbione/external-drivers
<fabbione> that's the update i am taking in with 2.6.10
<Treenaks> new atmel firmware?
<fabbione> mjg59: except for the fact that i smoke and that brings up your humor to a level close to -10000
<Treenaks> wow..
<fabbione> ;)
<fabbione> mjg59: i added that file to the kernel source package...
<fabbione> so that i don't have to get amazingly stupid again to track the hell out of the kernel
<mjg59> fabbione: The Panasonic one?
<fabbione> mjg59: can you just tell me which patches to apply out of that mess?
<fabbione> Driver package
<fabbione>     * kernel 2.6.x series : pcc-acpi-0.8.2.tar.gz
<fabbione> and ?
<mjg59> Yeah
<mjg59> That should be it
<fabbione> anything else?
<mjg59> The rest is userspace
<fabbione> hotkey drivers
<fabbione>     * Kernel 2.6.8.1: pcc-acpi-0.8.1.all.patch
<fabbione> ?
<mjg59> Wargh.
<mjg59> Hang on a second.
<fabbione> ok
<mjg59> fabbione: Ok, it's the pcc-acpi-0.8.1.all.patch one you need. But looking at it, I'm not sure it'll apply cleanly
<mjg59> There's going to be fuzz in the Kconfig and Makefiles
<fabbione> fuzz is not an issue :-)
<mjg59> The driver itself should be fine, it's just that the surrounding stuff in the configs is going to have been changed by ibm-acpi being added
<fabbione> that's not an issue :-)
<Treenaks> fabbione: how about http://hem.bredband.net/ekmlar/vt1211.html (the patch has some makefile rejects, but easy to solve)
<Treenaks> fabbione: or should I mail upstream about that, too
<mjg59> fabbione: Hm. I have a sony_acpi driver, too
<fabbione> Treenaks: mail upstream please
<fabbione> mjg59: ok.. let's queue up the 2 patches (panasonic and sony) for -2
<fabbione> and you can give me directly the dpatches that way :)
<mjg59> Sure, no problem
<fabbione> ok.. amd64, sparc64 and i386 look good
<fabbione> actually...
<fabbione> it's useless to upload
<fabbione> nobody can process NEW atm...
<mjg59> Bwahahaha
<Treenaks> they should have mailed their private key before they left then
<fabbione> Treenaks: nah that's thom...
<mjg59> If you throw up a source package somewhere, I can do dpatches for the laptop stuff
<fabbione> how process the queue is elmo :-)
<fabbione> mjg59: sure...
<fabbione> my home dir on people
<fabbione> remember that the pkgs are not final.. so i don't suggest to install them yet
<mjg59> Haha
<fabbione> mjg59: the warning wasn't for you
<fabbione> but for all the punks in here that grabs all the url that people past
<fabbione> paste
<fabbione> 275 lines of changelog.. and growing
<mjg59> fabbione: http://www.codon.org.uk/~mjg59/tmp/panasonic_acpi.dpatch and sony_acpi.dpatch
<mjg59> panasonic_acpi needs to be applied first
<mjg59> Both need to be enabled in the config
<fabbione>   * ATTENTION/WARNING/SOS/IF YOU OPEN A BUG ON THIS YOU WILL BURN ALIVE:
<fabbione>     ->>>>>> Disable emu10k1 build on ppc because it is broken <<<<<<-
<fabbione> do you think they will read it?
<Treenaks> no
<ogra> fabbione: will read what ? 
<ogra> ;)
<Lathiat> haha
<fabbione> mjg59: they are only for i386 and amd64?
* fabbione stickes the configs all over... 
<mjg59> fabbione: Probably only i386, actually
<fabbione> mjg59: well.. the kernel is clever enough not to build if x86 isn't defined (hopefully)
<fabbione> drivers/acpi/pcc_acpi.c:92:26: seq_template.h: No such file or directory
<fabbione> mjg59: ^^^
<mjg59> Arse.
<fabbione> (bte x86 is defined also on amd64)
<mjg59> fabbione: http://www.codon.org.uk/~mjg59/tmp/seq_template.h
<mjg59> Are you able to just smash that on the end of the patch?
<fabbione> sure...
<fabbione> in what dir should be added?
<mjg59> drivers/acpi
<fabbione> oky
<fabbione> linux-source-2.6.10-2.6.10/drivers/acpi/seq_template.h
<fabbione> there :-)
<sivang> mjg59: hello
<fabbione> i wonder if that rumor i heard a long time ago about a katie bug is true or not....
<fabbione> that would make me bypass the NEW queue in one shot ;)
<fabbione> mjg59: the 2 modules compile without any problem (amd64 and i386)
<fabbione> i still need to check ia64 given that i fix the other FTBFS
<fabbione>   LD      .tmp_vmlinux1
<fabbione> arch/ia64/sn/built-in.o(.text+0x2102): In function `sn_set_affinity_irq':
<fabbione> : undefined reference to `set_irq_affinity_info'
<fabbione> make[2] : *** [.tmp_vmlinux1]  Error 1
<fabbione> do you have any idea on how to fix it?
<fabbione> i know for sure that set_irq_affinity_info exists in arch/ia64/kernel/irq.c that is compiled....
<fabbione> so i am a bit puzzled
<fabbione> AHHHHHHHHHHH
<fabbione> IT'S A PIECE OF DEAD CODE!
<fabbione> GROOOAAARRRRRR
<mako> ciao fabbione
<fabbione> ciao mako
<fabbione> what's up man?
<mako> hopefuly, they just fixed the heat in my apartment.. it's *cold*.. but i'm ok
* fabbione wins again... 5/5 arches are building now
<mako> fabbione: you working this week?
<fabbione> mako: yup
* mako too
<fabbione> i don't have any holidays left until feb
<mako> i'm (a) hopelessly behind  ina  few thigns after the conf and (b) wanting to conserve holidays :)
<fabbione> mako: well i need to preserve holidays for the honeymoon
<fabbione> but i will laugh in feb.
<fabbione> when i will be at the galapagos...
* mako goes and finds the galapagos on the map
<mako> wow, that's far away
<fabbione> yup :)
<fabbione> i will be flying via madrid -> quito (ecuador)
<fabbione> 10 days on a boat
<fabbione> it's going to be cool
* fabbione wants to play with sealions
<mako> sealions are *so* cute
<fabbione> ehhe yeah
<sivang> fabbione: they are also very powerful
<fabbione> yes i know
<fabbione> i am not going there to fight with them :-)
<fabbione> and they are pretty social if not disturbed
<fabbione> they usually come there alone...
<fabbione> etting up libgtk2.0-bin (2.6.0-0ubuntu1) ...
<fabbione> Updating the IM modules list for GTK+-2.4.0...done.
<fabbione> Updating the gdk-pixbuf loaders list for GTK+-2.4.0...done.
<fabbione> Failed to write cache file: No such file or directory
<fabbione> dpkg: error processing libgtk2.0-bin (--configure):
<fabbione> interesting...
<mvo> is elmo the only one who can sync packages?
<fabbione> mvo: yes
<mvo> :/
<fabbione> when i did ask for a backup i was told that there was no need 
<fabbione> so....
<mvo> ok
<mvo> thanks
<fabbione> anyway
<fabbione> i am off
<fabbione> 10 hours of kernel are way too many
<mvo> byebye
<mvo> :)
<sivang> mjg59: ping
<mjg59> sivang: Hi
<sivang> mjg59: hey again, returning to you on our last convo, I cannot find not script by the name of sleep.sh under /etc/acpi.
<sivang> mjg59: would like very much to try and achive suspend on this machine :)
<mjg59> sivang: Uh. Can you dpkg -L acpi-support ?
<zul> can someone have  a look at 5052 pls in bugzilla thx
<sivang> mjg59: and when we're past that, I would love to give the hibernate option a try :)
<mjg59> sivang: By the sounds of it, you don't have acpi-support installed properly
<sivang> mjg59: ok, I got a list of files that acpi-support has probably insitalled.
<mjg59> sivang: Does that include /etc/acpi/sleep.sh?
<sivang> mjg59: it seems that it's not htere
<mjg59> sivang: What version of acpi-support do you have installed?
<sivang> mjg59: 0.9
<mjg59> sivang: Is that the entire version string?
<sivang> mjg59: this is what dpkg -l scpi-support tells...
<mjg59> sivang: Make sure that you have the acpi-support package from http://www.srcf.ucam.org/~mjg59/laptops/ installed
<sivang> mjg59: ok, I am installing the one tagged 12th Dec.
<sivang> mjg59:  trying to overwrite `/etc/acpi/events/powerbtn', which is also in package acpid
<sivang> mjg59: rmeove acpid?
<mjg59> Overwrite it
<sivang> mjg59: ok
<sivang> mjg59: how can I tell it to overwrite it?
<sivang> mjg59: -f ?
<mjg59> --force-overwrite
<sivang> mjg59: ok, i have a bunch of failing dependencies..I'll install them now.
<sivang> mjg59: dpms and freinds..
<sladen> sivang: do you have mjg59's archive in your /etc/apt/sources.list?
<sivang> sladen: #deb http://www.srcf.ucam.org/~mjg59/laptops/ ./
<sivang> sladen: ?
<sivang> sladen: I will now :)
<sladen> sivang: think so
<sladen> sivang: remove the '#' comment from the front
<sivang> sladen: :) thanks
<sivang> mjg59: all installed
<sivang> mjg59: :) now try /etc/acpi/sleep.sh ?
<mjg59> sivang: Yes
<sivang> mjg59: ok, it _did_ suspend, but when I opened the lid (how do I wake him up otherwise?) it only show the cursor at first, and then it also disappeared and nothing happend.
<sivang> mjg59: but it suspended very nicely and quickly! :)
<sivang> mjg59: I have both my / and /home under LVM in this machine, could it cause problems for the sleep script?
* sivang is off to get some food. be back later.
<mjg59> It shouldn't
<sivang> mjg59: shouldn't ?
<sivang> mjg59: ah ok, LVM shouldn't cause in problem. k
<Josephus> mine does not resume either
<Josephus> but i think it's a framebuffer or nvidia issue
<mdz> mjg59: any reason not to upload that stuff to hoary?
<mjg59> mdz: I need to finish combining the tools into one app
<mjg59> Should be done by the end of the week
<sivang> Josephus: I also have nvidia on that machine.
<Josephus> sivang: what about framebuffer?
<sivang> Josephus: you mean if I am using it?
<Josephus> yes
<sivang> Josephus: I enabled it in my Xorg setup
<Josephus> well for me it's console framebuffer (+gensplash) and i guess that's why resume is not working
<Riddell> is there any way of finding out if a package has been accepted or rejected given that my e-mail address probably isn't on the whitelist yet
<amu> if you upload now something, it's just beeing deleted 
<Riddell> how can we get it so that it won't just be deleted?
<amu> Riddell: http://www.ubuntulinux.org/wiki/NewDevelopersAndMaintainers
<amu> Riddell: If you would like to become an Ubuntu maintainer, please add your name here. http://www.ubuntulinux.org/wiki/MaintainerCandidates/
<ogra> Riddell: yeah, join us !!
<sivang> Riddell: after you work a bit with a mentor if you need one, you can be considered to be a maintainer and possibly voted to be such by the technical board
<ogra> sivang: first he must become a ubuntite ;)
<sivang> ogra: right, so that means to first be considered by the community council.
<ogra> sivang: nope, ubuntites are self nominated...(you and i are)
<ogra> sivang: next step is member.....
<sivang> ogra: Are you sure? I was approved by the last CC meeting :)
<sivang> so guess I am a memebr now :)
<ogra> sivang: then developer iirc and then maintainer
<ogra> sivang: oh, when was it ? in mataro ?
<sivang> ogra: last tuesday
<sivang> btw, did we have a tb meeting today?
<abelli> sivang: wasn't that for country teams?
<ogra> huh, i thought next meeting is in jan ....
<amu> sivang: 4.1. 16.00 
<ogra> amu: ah, thanks.... thats what i thought
<abelli> ogra: yes..
<amu> http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda
<abelli> amu: how is the 2nd gen live-cd
<amu> abelli: nice, i fight with the mouse atm :) 
<sivang> amu: hehe
<sid77> hi
* lamont grumbles at python2.4 thread tests
<teuf> hi
<Riddell> is there a way to find out which package has a certain file?  (specificly X11/extensions/xf86vmode.h )
<smurfix> Riddell: dpkg -S
<Riddell> smurfix: I don't have the file installed, that's why I want to find out which package provides it
<smurfix> ah. In that case, install apt-file
<smurfix> apt-file update; apt-file search NAME
<smurfix> In other words, xlibs-dev
<Riddell> smurfix: great, thanks
<Riddell> hmm, it lies, it says that file is in xlibs-static-dev but it's not
<smurfix> That usually means that the archive people haven't rebuilt the contents files recently
<sladen> Riddell: the long awaited packages.ubuntulinux.org
<Riddell> sladen: ...isn't much use at the moment :(
* Riddell hunts down the bugger in libxxf86vm-dev
<sivang> sladen: I havn't heared anything about it, has there been planning about p.u.o ?
#ubuntu-devel 2005-01-09
<Riddell> oh fooey, now I can't find libXxf86vm_pic.a
<amu> libxxf86vm1 ?
<daniels> Riddell: that's because it doesn't exist
<daniels> Riddell: link with -lXxf86vm and get the shared library, not -lXxf86vm_pic, which was a hack to work around the fact it was only shipped static
<Riddell> daniels: right, thanks
<ogra> guys i want to file a bug against fstab, is base-files the right package ?
<sivang> ogra: what is the bug? :)
<Riddell> ogra: it's not a base-file, it's contents are probably created by debian-installer
<ogra> sivang: floppy uses auto as filesystem.....what makes it impossible to mount vfat floppies through nautilus....havent tested ext2 but i suspect the same there
<sivang> ogra: eh
<ogra> Riddell: that would be base-config then i thin
<ogra> k
<ogra> sivang: you can mount them via -t vfat though.... but not in anutilus
<ogra> nautilus
<sivang> ogra: I think iv'e seen soemthing similar with ntfs..
<ogra> sivang: ntfs floppies ?
<ogra> 5060 filed :)
<Kamion> fstab is spat out by various bits of partman.
<Kamion> not base-config; that runs after the reboot and therefore after fstab is used
<ogra> argh... i was to fast... sorry
<mdz> also, 'auto' is the correct value
<ogra> so next time i know...partman
<Kamion> I agree, and was about to say that in the bug
<ogra> bu tit doesnt work
<mdz> it works for me, so the problem must lie elsewhere
<mdz> I have seen that behaviour before, though
<ogra> it works on none of my machines....
<daniels> mdz: btw, per your XorgAutoDetection mail, I think there's a regression in that I can't find the way to actually force re-xresprobe'ing.  other than that, should just be s/foo/bar/.
<ogra> and not on the lots of users machines i have supported until today.....
<daniels> mdz: will sort it on monday
<Kamion> ogra: auto is also the ideal value, so I'd rather see whatever bug it is that makes it not work be fixed
<ogra> Kamion: either way will be ok, but its a common bug in #ubuntu just ask in the cannel, you will get multiple response :)
<Kamion> I'm sure
<Kamion> I have a policy of not being pressured by that sort of thing though
<Kamion> in order to keep myself sane
<ogra> but if you think its located anywhere else i will try to track it... :)
<mdz> daniels: thanks
<daniels> mdz: no worries
<Kamion> it is not, fundamentally, an installer bug. A change there would only be a workaround. My best guess would be either mount itself or the kernel.
<mdz> ogra: I just installed a fresh Warty system a couple of days ago, and it worked there
<ogra> yep, i thought of the floppy module....
<mdz> I believe 'auto' is passed straight through to the kernel
<Kamion> might start with util-linux/mount/mount.c:guess_fstype_and_mount()
<ogra> mdz: i will try to find it.....
<Kamion> and for that matter mount_guess_fstype.c
<ogra> ok
<ogra> :)
<daniels> getting images of disks which are vfat but not detected as such online would doubtless be helpful
<Kamion> if you have trouble, please take a sample floppy and dd the whole thing
<Kamion> ... what daniels said :)
<Kamion> I'm certainly willing to look at such an image
<ogra> ok i will follow up in the bug then :)
<lamont> moo
<Kamion> mdz: yeah, I'd go with base for ubuntu-keyring. Anything particular blocking that?
<mdz> Kamion: not to my knowledge
<Kamion> (noticed you added it to supported last week)
<mdz> it will depend on gnupg, which is already in base
<Kamion> ok, I'll do it then
<mdz> as long as you're there, we should be able to remove libpcap0.7
<Kamion> oh yes, can I add silo to base for sparc? seems obviously correct
<mdz> I uploaded a ppp which builds with libpcap0.8
<mdz> thumbs up for silo/sparc
<Kamion> (ubuntu-keyring's under "Not quite ready for the default install yet", guess that's just transitional)
<Kamion> lamont: should I add python-minimal and python2.4-minimal to hoary.buildd, since they'll be becoming essential?
<mdz> Kamion: yeah, I  just didn't want to add it to base until we had talked about it
<mdz> but it certainly should have gone into main
<mdz> of course, it ended up in universe anyway
<mdz> I imagine that'll cause problems for debootstrap
<Kamion> nah, my update script will ignore it until it's in main
<Kamion> (or restricted)
<lamont> Kamion: certainly
<Kamion> well, moved it to base anyway :)
<lamont> .buildd == essential + build-essential
<Kamion> lamont: I like to ask you before touching .buildd :)
<lamont> Kamion: I'd rather it just kept working.. :-)  thanks though.
<Kamion> mdz: I'll skip the debootstrap upload until ubuntu-keyring's in main then, removing libpcap0.7 shouldn't be urgent
<lamont> mdz: UVF is today, or when?
<Kamion> lamont: see ubuntu-devel@
<lamont> doh
<lamont> kewl.  I can work on postfix in debian this week then. :-0
<Kamion> wow, svn 1.1 and the fsfs repository type totally wipe the floor with svn 1.0 and bdb
<Kamion> mdz: what should be responsible for adding the Ubuntu archive key to apt-key? Is that an installer job?
* lamont watches hppa-stage1 slog forward.
<mdz> Kamion: ubuntu-keyring should do that when it's configured
<mdz> that's the plan anyway
<lamont> mdz: btw, glibc -20 builds on ia64 finally
<mdz> yay
<Kamion> mdz: good-oh, less work for me
* lamont files a bug so he can close it.
<lamont> hrm... is python2.4 backwards compatible enough that I can just s/2.3/2.4/, or should I explicily build-dep on python2.3...
* lamont tries 2.4
<mdz> lamont: context?
<lamont> ispell-lt Build-Depends: python, and hardcodes python2.3 in it's scripts
<lamont> 5061
<mdz> ewww
<mdz> s/python2.3/python/g
<lamont> I bet it works just fine to build-dep python (>=2.3) and use 'python'
<mdz> and build-depend on python (>= 2.3)
<lamont> great minds, and all that
<lamont> and hppa finds it's first hoary bug. :-)
<lamont> python 2.4 isn't the default in debian yet, though, is it...
<Kamion> nope
* lamont files a bug against the debian package, pointing at the patchg
<mdz> lamont: and it isn't likely to be, if we want to release sarge
<lamont> mdz: right
<lamont> that was kind of the assumption
<lamont> mdz: 5039 - color me clueless, but what package are they talking about>
<lamont> ?
* lamont will be back in a while
<mdz> lamont: eric
<lamont> let me guess.  arch all
<mdz> universe, but we broke it
<lamont> binNMU time, eh?  or should I create 3ubuntu1?
* lamont thinks the latter.
<mdz> it needs source changes
<lamont> ah, ok
<lamont> so it's more than 'needs rebuild".  got it.
<lamont> yeah.  needs  a few changes.  I'll deal with it later tonight, probably
<lamont> 17 files (other than control) have the string 'python2.3' in them.
<lifeless> is gnome-python meant to have a python 2.4 version ?
* lamont bbiab
<Kamion> lifeless: it does
<Kamion> python2.4-gnome2
<lifeless> Kamion: hmm, missed that.
* daniels watches the entire Ubuntu archive rsync, bwlimited to 30kb/sec.
<Kamion> it's in a different source package from the 2.3 package
<daniels> it started yesterday, I'm not at pool/main/g, AFAICT.
<lifeless> does it upgraqde replace the other? All I noticed was aptitude bitching about python-gnome being removed
<Kamion> really python-gnome, not python-gnome2?
<Kamion> there's still a python-gnome2 package; try installing that and see what happens
<lifeless> python-gnome2 will be automatically removed because of dependency errors:                                                                                                        #
<lifeless>                                                                                                                                                                                  #
<lifeless>                                                                                                                                                                                  #
<lifeless>   * python-gnome2 depends on python (< 2.4)                                                                                                                                      #
<lifeless>   * python-gnome2 depends on python2.3-gnome2 [universe]                                                                                                                          #
<lifeless>   * python-gnome2 recommends python-gnome2-extras [universe]                                                                                                                      well that came out like crap.
<lifeless> python-gnome2-extras will be automatically removed because of dependency errors:
<lifeless> python-gnome2-extras depends on python (< 2.4)
<Kamion> that's strange, because that's not what the package in the archive looks like
<Kamion>  Package: python-gnome2
<Kamion>  Version: 2.9.1-0ubuntu3
<Kamion>  Depends: python (<< 2.5), python2.4-gnome2, python (>= 2.4)
<Kamion> was that the log from trying to install the current version?
<lifeless> also python-numeric, python-nuermic-ext, python-configlet
<Kamion> sounds like synaptic is generally confused about which way to resolve the upgrade
<lifeless> Kamion: thats aptitude up in front of me, having done an update ad hour or so ago.
<Kamion> all those packages have been updated to python2.4, so there must be something worse that's causing it to decide not to upgrade them
<Kamion> ok, either way
<lifeless> ok, I'll fiddle.
<lifeless> what about gnome-blog ?
<Kamion>  Package: gnome-blog
<Kamion>  Version: 0.7-4ubuntu1
<Kamion>  Depends: gconf2 (>= 2.6.2-1), python (<< 2.5), python (>= 2.4), python-gnome2
<lifeless> deb http://archive.ubuntu.com/ubuntu hoary main restricted universe
<lifeless> deb http://security.ubuntu.com/ubuntu hoary-security main restricted
<lifeless> look ok as sources ?
<Kamion> you should have hoary-security for universe too, but otherwise yes
<Kamion> (not that that will make any difference at the moment)
<lifeless> I have a pin to hoary as teh default distro
<lifeless> just doing another update.
<lifeless> ok, python-gnome2 is happy now.
<lifeless> python-configlet still doesn't want to play
<lifeless> (gnome-blog is copacetic as well)
<Kamion> universe
<Kamion> python-configlet hasn't been updated
<lifeless> K.
* lamont files bug #5063, giggles
<lamont> is that one I can get away with filing against debian, I wonder....
<lamont> anybody with access to update the chroot on halley around?
<fabbione> morning guys
<fabbione> lamont: unfortunatly not..
<lamont> fabbione: yeah - I decided to let the buildd's do the testing for me and uploaded it
<lamont> I do feel a little guilty, of course.
<fabbione> lamont: yeah right :)
<lamont> it's universe... :-0
<fabbione> lamont: do you have a ppc chroot with the latest gcc?
<lamont> not personally, I expect.
<fabbione> ok
<lamont> I actually installed a G3 the other day, but it's currently powered off.
<fabbione> i was wondering if you could do a test build of 2.6.10 on ppc
<fabbione> it fails on me on a driver on davis
<fabbione> but it's an old gcc
<fabbione> and the error looks really strange
<lamont> SIGILL?
<fabbione> no
<fabbione> in a switch() case FOO
* lamont is actually getting ready to fall over into bed.
<fabbione> it tells me that FOO can't be reduced to an integer
<fabbione> when it perfectly does on 4 arches
<fabbione> other than ppc
<lamont> wonder if it's because ppc defaults to unsigned types...
<lamont> (for at least char)
<lamont> ppc is unique that way
<fabbione> yeah and it uniquely breaks my packages
<fabbione> i will ask on lkml
<fabbione> perhaps they know
<lamont> 508 packages done for hppa/stage1, fwiw
<fabbione> cool
<fabbione> when do you plan to gimme access?
* lamont bought connectors for the cyclades, just needs to make time to create cables and wire up the world
<fabbione> and how are you building now without net access?
<lamont> they all live on a 192.168 network in the house, with access to the local mirror
<fabbione> ssh port forward works fine :-)
<lamont> plan is to create an ssh hop-box to let folks in, and use the cyclades for console access to same.
<lamont> but my vacation activities have kept me out of the house quite a bit this week..
<lamont> I'm finding it very difficult to get any work done. :-)
<fabbione> good idea.. but in the beginning i only need ssh access (and be able to copy files around easily)
<fabbione> ehehhe
<fabbione> i would love to be in holidays :-)
<lamont> I'm really wanting Wietse to relase postfix 2.2 this week, so that I can just turn on the ipv6/tls code that he has in 2.2, rather than porting the patch back to my 2.1.x pile yet again.
<fabbione> that would be cool :-)
<lamont> yeah - it's close, I think
<fabbione> local root exploit confirmed in 2.6.10: Linux 2.6 KernelCapability LSM Module Local Privilege Elevation
<fabbione> YEAHHHH
<fabbione> and i still have to release IT!
<lamont> fabbione: well, release it the fix then... :)
<fabbione> lamont: i need to find pitti
<fabbione> http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0390.html
<fabbione> YEAH YEAH YEAHHHHHHH
<fabbione> RIDE THE KERNEL
<fabbione> actually...
<fabbione> we are not that exposed
<fabbione> because we load capabilities before the login prompt
<lamont> well, that's good
<lamont> sadly, python2.4 and db4.3 both seem to be annoying hppa's 2.6.8-1 kernel, smp even more than UP.
<lamont> rather, building those seems to be.
<fabbione> ehhe
<lamont> dropping python2.1 is going to take a few source changes.
<fabbione> Errors were encountered while processing:
<fabbione>  libgtk2.0-bin
<fabbione> lamont: do you have that problem too?
<lamont> where?
<fabbione> in the chroots
<fabbione> building evolution and others
<fabbione> Setting up libgtk2.0-bin (2.6.0-0ubuntu1) ...
<fabbione> Updating the IM modules list for GTK+-2.4.0...done.
<fabbione> Updating the gdk-pixbuf loaders list for GTK+-2.4.0...done.
<fabbione> Failed to write cache file: No such file or directory
<fabbione> dpkg: error processing libgtk2.0-bin (--configure):
<fabbione>  subprocess post-installation script returned error exit status 1
<fabbione> ah no.. you didn't see it yet because you are still missing libcamel1.2-dev
<fabbione> http://people.ubuntulinux.org/~lamont/buildLogs/x/ximian-connector/2.1.2-0ubuntu1/
<lamont> ah, ok
<fabbione> and btw.. libcamel is there now...
<fabbione> but hell.. you are in holidays!
<fabbione> you are not supposed to be here talking about work :-)
<fabbione> Mithrandir: ping
<fabbione> never mind :-)
<Treenaks> morning abelli
<fabbione> hey Treenaks 
<Treenaks> hey fabbione
<fabbione> we need a kernel task force
<crimsun> to deal with all the security advisories?
<fabbione> no to deal with all the configuration and build issues
<crimsun> hmm, ok.
<crimsun> where do we start?
<fabbione> crimsun: what arches do you have?
<crimsun> only i386
<fabbione> i have that :)
<crimsun> :)
<calc> i got two amd64 and i386 systems :)
<calc> and a m68k doorstop
<fabbione> amd64 would be good
<calc> ok
<pitti> Hi
<abelli> pitti: ciao
<fabbione> hey pitti
<fabbione> pitti: are you having nice holidays?
<pitti> fabbione: yes, so far
<fabbione> pitti: ok.. so i can ruin them
<pitti> fabbione: I want to work today, my mailbox explodes and there are a bunch of security issues...
<fabbione> local root exploit on all the 2.6 serie
<pitti> yay
<pitti> I just started looking into my mailbox
<fabbione> and it's public
<pitti> I will probably need about two hours to catch up with the most important stuff
<fabbione> it was funny this morning to edit /etc/shadow as normal user :-)
<pitti> d'oh
<fabbione> i don't understand why it takes 2 hours each day to run updatedb
<fabbione> is it a known problem?
<Treenaks> is the bug even in 2.6.10?
<fabbione> all of the 2.6 kernels
<Treenaks> great
<fabbione> starting from 2.5.7x something
<Treenaks> there have been a LOT of holes in 2.6.x lately
<Treenaks> or is everyone just looking harder?
<fabbione> ot
<fabbione> it
<fabbione> it's Xmas
<fabbione> it must be xmas
<Treenaks> fabbione: it's the capability one?
<fabbione> yeps
<Treenaks> so if you have it "built-in" instead of loaded as a module it isn't a problem? *reading bugtraq archive*
<calc> btw ati is looking for testers of their new drivers including amd64 support
<fabbione> Treenaks: yes. i have been thinking about it too
<daniels> and pcie
<fabbione> who broke apt?
<fabbione> 5492 -rw-r--r--  1 sparcbuildd sparcbuildd 5608995 2004-12-29 11:02 apt_0.6.29_20041229-0720
<fabbione> configure loop endless
<mvo> fabbione: usually I break it and matt uploads it 
<mvo> fabbione: can I see a build-log?
<fabbione> mvo: sure
<fabbione> mvo: email address?
<mvo> michael.vogt@canonical.com
<fabbione> ah no
<fabbione> i think it is something else
<fabbione> hmm
<mvo> ah, ok
<mvo> I was wondering what it might be. the changes from 0.6.28->29 are pretty harmless
<fabbione> cd build && CXXFLAGS="" ../configure --build sparc-linux
<fabbione> ../configure: line 21: /dev/null: Permission denied
<fabbione> this IS WEIRD!
<mvo> hehe
<mvo> /dev/null is full :P
<daniels> sparc obviously sucks
<fabbione> daniels: actually.. sparc was the only one building 2.6.10 ;)
<fabbione> mvo: udev was at fault
<mvo> fabbione: thanks
<fabbione> the new version did started automatically
<fabbione> mangling all the permissions in /dev
<mvo> uhhh, that sucks
<daniels> ok, people with up-to-date hoary: does /usr/bin/python point to /etc/alternatives/python, or python2.4?
<mvo> daniels: /usr/bin/python -> python2.4
<mvo> updated yesterday
<daniels> mvo: ok, thanks
<fabbione> i guess pitti rooted himself
<Treenaks> fabbione: the Australian way?
<fabbione> Treenaks: the goatse way
<pef> hello
<fabbione> pitti: http://people.ubuntulinux.org/~fabbione/pasta/linguine_ai_frutti_di_mare/
<lamont> daniels: python does not use alternatives.
<fabbione> pitti: you will hate me for that
<fabbione> hey lamont 
<fabbione> lamont: did you update any of the chroot on the buildd recently?
<pitti> fabbione: as soon as my modem link downloaded the pics, I will :-)
<fabbione> lamont: if so be very careful about udev
<fabbione> lamont: for some reasons the new udev started the daemon (correctly), but it killed all the permissions on the devices
<lamont> fabbione: the chroots autoupdate every morning.
<fabbione> including /dev/null
<pitti> fabbione: bah, I doubt that I would eat that stuff. But enjoy! :-)
<lamont> fabbione: but then, udev isn't in a proper chroot.
<lamont> s/proper/proper buildd
<fabbione> lamont: iirc it was pulled in a dist-upgrade
<fabbione> pitti: you don't like seafood?
<pitti> fabbione: not at all
<fabbione> pitti: oh god..
<fabbione> it must suck to be you
<fabbione> :P
<pitti> fabbione: I like fish, but not the other stuff (with many legs and so on)
* ogra would take one or two plates of this yummy stuff
<lamont> fabbione: most recent dist-upgrade (as of 15 seconds ago) pulled in apt 0.6.29.  that is all.  no udev
<mdz> a buildd wouldn't get it
<fabbione> hmmm
<mdz> it's depended upon by things like ubuntu-base, hal, etc.
* fabbione thinks of a polluted chroot...
<lamont> fabbione: that's what I'm thinking you have too..
<fabbione> oh well
<fabbione> i will bootstrap another one
<lamont> well, off to denver for the day - back later
<sjoerd> fabbione: did you have a chance to try 2.6.10 on sparc?
<fabbione> not yet
<fabbione> it compiles.. that's all i know
<mjg59> fabbione: Do you have debs of the 2.6.10 build yet?
<sjoerd> fabbione: my machine hangs when switching from openprom to the framebuffer.. can you let me know if it works for you :)
<fabbione> mjg59: i am going to upload in a hour or so
<fabbione> sjoerd: it might as well boot fine for me because i only have serial console
<fabbione> so fb would fail to load
<sjoerd> that would be also interesting to know
<pitti> Mithrandir: ping
<fabbione> pitti:
<fabbione> cd debian/config
<fabbione> for i in `find . -type f`; do cat $i | sed -e 's/SECURITY_CAPABILITIES=m/SECURITY_CAPABILITIES=y/g' > $i.new && mv $i.new $i; done
<fabbione> this will change all the config files to get capability inside the kernel
<pitti> fabbione: sounds like a quick and safe fix
<fabbione> i just uploaded 2.6.9-11 with that and the ip-conntrack ftp fix
<fabbione> pitti: yes.
<fabbione> there was another message on the lkml
<pitti> fabbione: I think the worst that could happen to warty is that you get an error message at bootup if /etc/modules contains capability
<pitti> ?
<fabbione> but nothing more than: It is difficult to exploit
<fabbione> pitti: i think so... yes
<fabbione> pitti: i would still ask Herbert and mdz to be 10000% sure
<pitti> fabbione: do we need to fix Warty for this ip_conntrack issue?
<fabbione> pitti: well.. it's a memory leak when using fxp
* pitti wonders how one can be more "sure" than 100% :-)
<fabbione> it's not urgent but if you are doing a USN, just stick it in
<pitti> fabbione: can you please mail me and Herbert the patch?
<fabbione> pitti: you add a 100% for each arch and for each flavour of the kernel you are going to upload :-)
<pitti> fabbione: ah, ok :-)
<fabbione> pitti: the patch for for the ftp?
<pitti> yes
<fabbione> i think i gave it to you already
<fabbione> otherwise -11 will hit the archive in a few minutes
<fabbione> it's called fix-ip-conn*
<pitti> fabbione: I don't have it yet, but I can just take it from the archive then
<fabbione> pitti: ok.. ok.. you lazy bastard :)
<pitti> fabbione: ?
<fabbione> i will mail it
<fabbione> pitti: mail on the way
<pitti> fabbione: thanks
<fabbione> sorry i didn't find Herbert mail on the fly
<pitti> I forward it, np
<mako> "Believe me or not, the Ubuntu Linux is wanted like hot bread here in Romania. :)"
<ogra> yay
<ogra> i belive
* mako loves hot bread
<ogra> how is the heating situation ?
<mako> the super fixed it yesterday :)
<mako> *so* much better
<ogra> yay
<ogra> congrats :)
<fabbione> goody
<fabbione> 2.6.10 uploaded
<HcE> =)
<fabbione> elmo_away: linux-source-2.6.10_2.6.10-1_source.changes is NEW
<pitti> fabbione: oh, what did you add?
<fabbione> nothing.. it's a NEW package...
<fabbione> source linux-source-2.6.10
<fabbione> that is not in the archive yet
<fabbione> it is simply new :-)
<fabbione> ok.. that's enough for today
<fabbione> cya tommorrow
<pitti> oh
<fabbione> seb128: hey
<pitti> fabbione: see you
<pitti> Hi seb128 
<fabbione>  libgtk2.0-bin is broken
<seb128> hey
<seb128> fabbione: since when ?
<fabbione> Setting up libgtk2.0-bin (2.6.0-0ubuntu1) ...
<fabbione> Updating the IM modules list for GTK+-2.4.0...done.
<fabbione> Updating the gdk-pixbuf loaders list for GTK+-2.4.0...done.
<fabbione> Failed to write cache file: No such file or directory
<fabbione> dpkg: error processing libgtk2.0-bin (--configure):
<fabbione>  subprocess post-installation script returned error exit status 1
<fabbione> on a fresh chroot
<fabbione> not sure...
<fabbione> i noticed today on the sparc buildd logs
<fabbione> probably is something else that broke
<fabbione> not sure..
<fabbione> hadn't have the time to check
<seb128> hum ok
* fabbione goes off
<mako> Kamion (or anyone else): where is the source for the installer documentation?
<ogra> sivang ?
<ogra> sivang: in #ubuntu is a guy who wants to help on hebrew localization .... nick: nakee
<Kamion> mako: debian-installer
<mvo__> Kamion: can you please put ubuntu-keyring into the base seed?
<Kamion> mvo__: already done
<Kamion> last night
<mvo__> Kamion: great, thanks!
<Kamion> mvo__: it's still in universe though, can't add it to debootstrap until elmo gets back
<mako> Kamion: thanks
<mako> Kamion: the doc team is talking about the installation manual in #ubuntu-doc
<mvo__> I'm off to buy some food, will be back in ~1h
<kylem> wow. somebody is annoying.
<fabbione> nah
<fabbione> i know him personally.. it must have been some crack on the client
<fabbione> note that he was killing himself
<kylem> heh.
<Kamion> daniels: is there any equivalent of http://www.xfree86.org/current/mouse.html for X.Org?
<sivang> ogra: here
<ogra> sivang: in #ubuntu was a guy who wants to help on hebrew localization .... nick: nakee
<ogra> dunno if he is still there
<sivang> ogra: let's see
<ogra> :)
<sivang> ogra: thanks :)
<ogra> :)
<mako> sivang: were you the one talking about a central place for pictures of the ubuntu conference?
<ogra> mako: i was asking for that (probably sivang as well)
<ogra> mako: for ppl that dont have the bandwith or server place
<mako> ogra: well, i'm setting a wiki page to link to them
<ogra> great :)
<mako> and perhaps some general soul will offer some server space
<sivang> mako: also, why? 
<ogra> i would, but i pay the bandwith :(
<mako> ogra: i might have a place..
<ogra> ah, oj....i'm fine with my pcis on my server....just for others....
<sivang> mako: I can ask ChrisH also about the webspace
<ogra> pics
<mako> http://www.ubuntulinux.org/wiki/MataroPictures
<mako> Treenaks: you have pictures, right
<mako> Treenaks: you should link them up here: http://www.ubuntulinux.org/wiki/MataroPictures
<ogra> mako: they are all here: http://www.ubuntulinux.org/wiki/ConferenceGalleries
<mako> ogra: ah, you are correct
<ogra> mako: i thought you added a upload capable page to the wiki.....
<ogra> mako: but that would be redundant....
<mako> ogra: i can change the other one
<ogra> yep, i think that would be cool, or move the links over (i like youre title more ) ;)
<mako> Treenaks: sorry, disregards me
<smurfix> So who broke the Wiki's "page not found" dialog?
<ogra> smurfix: doesnt look broken here
<ogra> smurfix: http://www.ubuntulinux.org/search?SearchableText=blah
<smurfix> Umm, just go to http://www.ubuntulinux.org/wiki/FooBarBazWhatever -- that looked better last week.
* smurfix just added Amaya's gallery to ConferenceGalleries
<ogra> smurfix: uuuh ugly
<ogra> smurfix: (not amayas gallery....)
<smurfix> ogra: I kindof understood what you were referring to. ;-)
<ogra> :)
<sivang> smurfix: Israeli team page done.
<sivang> smurfix: what about new moin, any nwes?
<smurfix> sivang: Just watch Debian bug #287006, or subscribe to moin in the PTS...
<smurfix> I'll install it as soon as it's available.
<sivang> smurfix: thanks.
<sm> smurfix: that was me, see ubuntu-user
<sm> the old error page was pretty but useless, I thought
<smurfix> sm: The new error page looks like it belongs to a wholly different website, though
<sm> ok, I'll work on that
<sm> if you think it should be reverted until then, bring it up on the list and I'll obey consensus
<sm> oh, I'm on -devel here aren't I.. we *make* consensus.. :)
<zul> beat heads in :)
<smurfix> sm: IMHO it makes sense to revert that change until your new page is ready, but it's your call.
<sm> smurfix: ok
<sm> it would help if I could get in to the ZMI root folder.. does anyone know why :8002 no longer responds ?
<mxpxpod> fabbione: ping
* lamont looks around for daniels
<lamont> or fabbione 
<sm> smurfix: I've reinstated a simplified version with the plone skin
<ogra> sm: looks very good now
<sm> thx
<sm> do you think it should do a search automatically ?
<ogra> what would it search if you type: http://www.ubuntulinux.org/wiki/FooBarBazWhatever
<sm> probably the wiki
<sm> I don't do that by default because of robots
<sm> but  http://www.ubuntulinux.org/whatever seems to do a full site search already
<sm> so why not
<ogra> yep, then do it...
<sm> ok done
<daniels> Kamion: http://xorg.freedesktop.org/X11R6.8.1/doc/mouse.html
<daniels> lamont: yeah, he fiddled the symlink himself, hence why it's normal.  should be more robust. ;)
<ogra> daniels: great to see you.... 
<ogra> daniels: i have a user question.....(will ask in #ubuntu) if you got a sec....
<daniels> ogra: yo
<daniels> ogra: not really, sorry.  just quickly checking everything before i run off.  but put 'daniels:' at the start of the line and I'll check it when I get back later.
<ogra> daniels: upgraded my flowerpower imac yesterday xorg doesnt work but gdm starts fine with a blyck screen....any hints ? no errors so far....
<ogra> daniels: there is no hurry for an answer, its one of my many  "play around" boxes....could even wait till next year...
<Kamion> daniels: thanks, updated for the next release
<TD> any launchpad gurus here?
* mako is moderating and it's apprently been a while.. incoming older messages
<lamont> daniels: I have a MANIFEST for hppa for you...
<lamont> what files did you need again, and where do should they go in the source ball?
<daniels> lamont: MANIFEST.hppa.new, just throw it over, unless you've constructed a MANIFEST.hppa.in, xserver-xorg.{docs,install}.hppa, and xlibmesa-dri.install.hppa :)
<daniels> Kamion: no worries
<daniels> ogra: ah, looks like a HorizSync/VertRefresh thing.  file a bug with the output of sudo ddcprobe, lspci -v and /var/log/Xorg.0.log
<ogra> daniels: fine, thanks...
<lamont> daniels: people.ubuntu.com/~lamont/MANIFEST.hppa.new
<lamont> daniels: what is the minimum that I need to do to construct a -ubuntu8.1 locally?
<lamont> stage1 is kinda wedged waiting for xorg, you see.
<Kamion> daniels: is http://xorg.freedesktop.org/ a better URL to point to from the installation manual for X.Org in general than http://www.x.org/?
<lamont> well, and gcc-3.3 and db4.3, but almost nothing cares about db4.3 yet
<Clint> grr
<daniels> lamont: look at the diff between *.i386 between xfree86 and xorg, use that to construct *.hppa.  bear in mind that MANIFEST is split between MANIFEST.all.in and MANIFEST.hppa.in
<daniels> lamont: so yeah, basically just work from XFree86 and look at the diffs between the i386 stuff between xfree86 and xorg, and also the diff between the MANIFEST.hppa{,.in}
<daniels> Kamion: shit yes.  www.x.org is an abysmal website, and nothing should ever point there.
<Kamion> alrighty
<daniels> Kamion: cheers
<lamont> daniels: and if you do it, when will it be available? :-)
<daniels> Kamion: oh btw, /current/doc/ will be longer-lived
<daniels> lamont: i don't start work again until the 3rd :)
<Kamion> daniels: ahead of you :)
<daniels> Kamion: heh
#ubuntu-devel 2006-01-02
<floam> looks like libsdl-ruby in dapper is uninstallable
<crimsun> it needs to be rebuilt against transitioned libsmpeg0c2, that's all
<crimsun> floam: should be installable in 35 minutes.
<Burglaptop> attention all: please help Scott make Ubuntu boot faster by contributing to https://wiki.ubuntu.com/BootCharting
<jsgotangco> yes sire
<Burglaptop> I said please!
<floam> crimsun: cool
<floam> Burglaptop: are bootcharts not allowed if the person has non-vanilla services or things they don't use disabled?
<Burglaptop> floam: just note that in the notes
<Burglaptop> but in general, default is better
<floam> ok
<floam> added
<crimsun> elmo: please sync qca, quickplot, snacc, sigcperl, rubyfilter, rapidsvn, and mercator from Sid (ok to override Ubuntu changes), thanks.
<floam> wow, I guess my 0:30 boot is fast compared to others on that page
<floam> I still feel like it sits doing not much often
<floam> anyone notice in Dapper's epiphany you can see the actual "&" signs in all the dialogs where they want to have an underlined accelerator?
<floam> s/all/some/
<tseng> Burglaptop: sorry, why am i nuking someone elses laptop page?
<tseng> Burglaptop: from what we've seen so far different submodels behave radically different, esp different available video options
<tseng> Burglaptop: like ubuntu bug 14497
<whiprush> floam: yep.
<whiprush> hi tseng, merry xmas.
<whiprush> etc.
<tseng> whiprush: hi, same to you
<floam> BenC: I've reported the ATAPI thing to k.o bugzilla, and added a URL to the ubuntu post
<floam> I hope something happens ;)
<jsgotangco> whiprush, FRIDGE JR
<whiprush> heh
<whiprush> my waistline is getting more fridge'd after these holidays.
<jsgotangco> gahh cut on the jerky and coldcuts dude
* #ubuntu-devel  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
<sivang> whiprush: really? :) wow!
<sivang> whiprush: you have photos ?
<mdke> floam, on that epiphany bug, it is reported upstream
<mdke> mozilla bug #319901
<Moeen> When I make a Package, is it possible to Maintainer Name Email comes with a Anti-Spam address ? for example in debian/control have something like this : Maintainer: Mat Watson <mat @!@ ubuntu.com>
<mvo> Moeen: see #debian-devel :)
<\sh> I wonder why "cppunit" landed in the "NEW" queue now....
<lucasvo> I have problems with my dapper dependencies
<lucasvo> The following packages have unmet dependencies:
<lucasvo>   linux-image-386: Depends: linux-image-2.6.15-10-386 but it is not installable
<lucasvo>   linux-restricted-modules-386: Depends: linux-restricted-modules-2.6.15-10-386 but it is not installable
<HiddenWolf> lucasvo, this is not a support channel. 
<HiddenWolf> wait a few hours, then update & upgrade again
<lucasvo> HiddenWolf: yes, but it is not the problem of the user...
<HiddenWolf> if it's not gone tonight, file a bug. 
<HiddenWolf> lucasvo, this kind of thing is common, since the archive is moving all the time
<lucasvo> so I can't do anything except tell dev's about it
<lucasvo> HiddenWolf: ok
<HiddenWolf> lucasvo, should be gone in a few hours
<HiddenWolf> lucasvo, you updated at a time where the one new version is in, but the depends is not yet. Probably still being built.
<ogra_ibook> nope
<lucasvo> I am waiting for already about 12h
<ogra_ibook> the package has a new name (it carries the version number)
<HiddenWolf> hm, does it?
<ogra_ibook> so its sitting in the NEW queue, waiting for someone to unleash it
<ogra_ibook> sure: linux-image-2.6.15-10-386
<ogra_ibook> the 10 is the revision from the version number ...
<HiddenWolf> Ok, i'm stupid. ;)
<ogra_ibook> nah
<HiddenWolf> How do you know. ;)
<ogra_ibook> lucasvo, its nothing tragic, just wait
<lucasvo> http://releases.ubuntu.com/edubuntu < has wrong title, ogra
<lucasvo> Kubuntu :D
<HiddenWolf> ogra_ibook, of course it's tragic, he's being denied the latest and greatest! ;)
<lucasvo> exactly :P
<ogra_ibook> heh, true ... the title reads kubuntu ... 
<ogra_ibook> i'll see this as tribute to their kdeedu apps we use in gnome :) 
<HiddenWolf> well, as long as it's a buntu. ;)
<lucasvo> let's put a SuSE image there :)
<ogra_ibook> it should be changed, but i dont have access ... so it will have to wait ...
<lucasvo> ok
<hunger> Yahoo! My box finally boots again!
<hunger> Sorry, wrong channel...
<hunger> Could someone please fix malone #6216? It is a one line change and I explained what needs to be done.
<pitti> Hi
<hunger> pitti: Hi!
<ogra_ibook> moin pitti 
<pitti> hi ogra_ibook, hi hunger 
<pitti> ogra_ibook: ooh, you got an ibook?
<ogra_ibook> yup
<ogra_ibook> edubuntu ppc is near :)
<hunger> pitti: You introduced LUKS, didn't you? Could you please apply the fix in malone #6216 to mount.crypt?
<hunger> pitti: It does not work with LUKS volumes as is.
<hunger> pitti: You still remember the cryptdisk start/stop script I mailed you a while back? Could you please consider using it (malone #563).
<pitti> hunger: sure, I'll look at it
<hunger> pitti: Please look into malone #6216 first. It is a trivial change I think and fixes LUKS partitions in pam_mount.
<pitti> I assigned #6216 to me
<hunger> pitti: I'll run into this on my next upgrade of pam_mount;-)
<hunger> pitti: Thanks!
<sivang> hi all!
<sivang> I didn't know there were anybody online working today :)
* ogra_ibook is not working
<HiddenWolf> ogra_ibook, playing with OSX? :P
<ogra_ibook> pfft
<ogra_ibook> the playing phase is already done :)
<sivang> ogra_ibook: hehe 
<ogra_ibook> got this baby before christmas already ...
<sivang> ogra_ibook: congrets
<ogra_ibook> thanks
<sivang> pitti: I managed to work with dbus/hal from python, basing on hal-device-manager code. it's very nice :)
<ogra_ibook> apart from being totally broken in dapper you mean ? :)
<sivang> ogra_ibook: don't know about it, it's working fine for me :-D, what's broken with it?
<ogra_ibook> your device manager works ? 
<ogra_ibook> with dbus 0.60 ?
<Moeen> is there any GUI for dbus ?!
<ogra_ibook> to see the messages rushing by ?
<sivang> ogra_ibook: yes
<Moeen> sometimes I see some messages in Text mode
<Moeen> for example: You CPU temprature is high ... how can I see them in Graphical mode ?!
<Moeen> s/You/Your
<sivang> Moeen: there are other tools for that, that's not related to "dbus gui" IMHO
<Moeen> sivang, like ?!
<Moeen> sivang, tell me the name of them (at least one of them :P ) ?!?!?!?
<sivang> hrm
<Moeen> !hrm
<sivang> they should be something like the cpu freq indicator, I don't know any specific names. sorry. but IIRC linux has support for sensors so such info can be exposed by some GUI. (anybody care to correct me on that)
<Moeen> I'm speaking about the dbus messages
<Moeen> it was an example
<Moeen> another could be when a device connected, It will tell us that is connected
<sivang> Moeen: you can use hal-device-manager for that, it will let you know if device was connected or dis etc. Do you specifically need to see the dbus messages?
<Moeen> sivang, I don't need a specific thing
<ogra_ibook> how about:  dbus-monitor| zenity --text-info --width 700 --height 400 --title 'dbus Messages' 
<Moeen> sivang, something that show me all the dbus messages
<ogra_ibook> ;)
<ogra_ibook> and have a look at man dbus-monitor about the filters and switches:)
<Moeen> ogra_ibook, interesting :P but I don't have dbus-monitor
<Moeen> ogra_ibook, ok, found the package ;)
<ogra_ibook> its in dbus-utils i think
<ogra_ibook> you could also do it with a 20 line pygtk script and a glade file if you want it more beautyful
<Moeen> ogra_ibook, yes, I may write it :)
<ogra_ibook> :)
<Lathiat> ogra_ibook: new ibook?
<ogra_ibook> yup
<Lathiat> nifty
<ogra_ibook> yes, its fun :)
<Lathiat> wonder if that extreme driver has gotten anywhere 
<ogra_ibook> its running here
<Lathiat> it works
<Lathiat> ?
<ogra_ibook> partially ...#
<Lathiat> the airport extreme in linux with that bcm43xx driver?
<Lathiat> how partially?
<ogra_ibook> it offrers no wireless extensions to the system... so wavemon and other stuff doesnt work ... it works only reliable at low speed
<Lathiat> well thats a start i guess
<ogra_ibook> its enough
<Moeen> how Shutdown warning message works ? it uses dbus, too ?!
<Moeen> for example when I use : shutdown -k -h now 
<Moeen> how it broadcast the message for shutdown to all the users ?
<Robot101> it writes to all the TTY's
<ogra_ibook> nope, thats done differently
<Robot101> its nothing to do with dbus
<Moeen> how can I monitor them in Graphical mode ? is there something like dbus-monitor there ?
<Robot101> no, just run dbus-monitor in a terminal.
<Moeen> Robot101, something like dbus-monitor for monitoring the TTY's ...
<Robot101> what?! no
<Robot101> a tty is a console in linux
<Robot101> it's got absolutely nothing to do with dbus
<Robot101> there is no dbus message that tells you when the system is shutting down
<ogra_ibook> you could add one :)
<Moeen> ok, now how can I monitor the TTYs messages ? :(
<ogra_ibook> but since you'll see X closing anyway a second or two after the message is sent, you will get small problems to display it in time :)
<Moeen> In one of the Window Managers (I don't remember, maybe fluxbox), it will show the tty messages. I want to emulate it in Gnome
<Robot101> are you talking about syslog?!
<Robot101> open a console and tail -f /var/log/syslog
<ogra_ibook> or run gnome-system-log
<Moeen> Robot101, I need to it will run when a new message come
<Robot101> I really have no idea what you're talking about. where are these messages? find a screenshot or something.
<\sh> Moeen: you mean tty messages as if you "write" to another user on another console?
<\sh> or talk requests?
<ogra_ibook> no he means notification bubbles from syslog 
<sivang> ogra_ibook: dbus-utils is the packages?
<\sh> ogra_ibook: and that is what? xtail -f /var/log/syslog ?
<Moeen> Let me give an example. You are in gnome. when another person try to shutdown my computer by ssh, one new window shows that something like this : Broadcast message from root (pts/3) (Wed Dec 28 16:58:53 2005):The system is going down for system halt NOW
<sivang> he wants something like system messages from managment console in windows :)
<ogra_ibook> Moeen, the Robot101 gave you the right command, just have a terminal open with this command
<ogra_ibook> s/the/then/
<\sh> ogra_ibook: no it's not :)
<\sh> ogra_ibook: it
<ogra_ibook> sure
<\sh> ogra_ibook: no....man write :)
<ogra_ibook> the shutdown message should show up in syslog
<\sh> ogra_ibook: yes
<sivang> hmm, dpkg -S dbus-monitor didn't return anything. 
<\sh> ogra_ibook: but he means the "popup message on the console" 
<ogra_ibook> \sh, i know
<\sh> ogra_ibook: hint on "write" :)
<Moeen> sivang, dkpg -S dbus-utils
<sivang> Moeen: I tried to search for the executable file itself , as dpkg -S should return it as well
<Moeen> \sh, yes, popup message on the Graphical mode :)
<Mez> fecking internet
<Mez> been down for 3 days cause pipexclosed tech support
<sivang> what I said - window ssystem broadcasted messages :)
<Moeen> sivang, oh, right :P excuse me
<sivang> Moeen: np :)
<sivang> but it doesn't find any of those on my system.
<sivang> Moeen: dbus-1-utils
<Moeen> I can't see the (shutdown) broadcasts in syslog !
<Moeen> so tail 0f /var/log/syslog not works
<Moeen> s/0f/-f
<ogra_ibook> then its in /var/log/messages
<ogra_ibook> Dec 24 21:13:07 localhost shutdown[3579] : shutting down for system reboot
<ogra_ibook> thats in my messages
<\sh> Moeen: what you want is a syslog notifier for special messages
<\sh> Moeen: the "broadcasted messages" of `shutdown` are done via tty write, which has nothing to do with any GUI mode...
<Moeen> \sh, yes, but there isn't any application what show me these messages in graphical mode ?
<Moeen> ogra_ibook, it doesn't show the broadcast messages :( (/var/log/messages)
<\sh> Moeen: what graphical mode? 
<Moeen> \sh, X (I use Gnome)
<ogra_ibook> tail -f -c1 /var/log/messages|grep 'shutting down' && zenity --warning --text "shutdown"
<ogra_ibook> ;)
<\sh> Moeen: yes yes...but "what graphical mode" should the text line be displayed? as cake or as candle? there is no other way of representing a text line only as text line...so "gnome-terminal" -> tail -f /var/log/messages :)
<Moeen> ogra_ibook, it will not show broadcast messages. you can try it : shutdown -k -h now 
<Mez> \sh - did you see my /query ?
<Moeen> ogra_ibook, then tail /var/log/messages
<ogra_ibook> yes, that shows the above command for me
<ogra_ibook> Dec 24 21:13:07 localhost shutdown[3579] : shutting down for system reboot 
<ogra_ibook> was a direct paste from my messages file
<\sh> Moeen: the "broadcast message" is special generated from shutdown and written to all opened tty devices via tty write...it has nothing to do with syslog or gui mode or what ever...what you see as broadcast message is just a nifty trick
<ogra_ibook> its sent in parallel with the entry in the messages file ...
<ogra_ibook> so if this one shows up, you can grep it in the messages file and show a zenity popup
<Moeen> \sh, yes, you are completely right !
<Moeen> \sh, but of course there is some way to see them in graphical mode
<\sh> Moeen: ogra gave you the answer :)
<sivang> Moeen: the zenity hacks seems to the point here :)
<Moeen> /var/log/messages not shows the broadcast messages, it will log shutdown when init changes
<\sh> Moeen: or you write something like a tty emulator for gnome-terminal, which is catching then the tty writes as well...there was a tool in kde somewhere
* sivang notes KDE has a tool for everything.
<sivang> :)
<sivang> my workmates made em install them an kubuntu with amarok in, to be able to do DJing from web interface :)
<Moeen> sivang, do you know the KDE tool name for this reason ?
<sivang> Moeen: no, I'm just mumbeling , sorry
<Mez> sivang: except for making your food for you
<sivang> Mez: soemthing liek that, yeah. I now realize how important is to have Kubuntu.
<\sh> sivang: i think it's not existing anymore...
<Mez> sivang - cool
<ogra_ibook> sivang, bah, take edubuntu, it unites the desktops ;)
<sivang> ogra_ibook: it does? I didn't know that :)
<ogra_ibook> only in the edu sector ;)
<sivang> ogra_ibook: you use both KDE and GNOME , that is different tools from both to do the job?
<ogra_ibook> but it has the advantag that you dont need to DL all the libs and language packs
<sivang> \sh: the logger tool or amarok? :)
<\sh> sivang: the logger tool
<sivang> \sh: ah
<\sh> sivang: well...amarok will disappear as well..when we don't need any digital music anymore...
<sivang> \sh: when is this going to happen? when we have brain wave trasmitted music? :-D
<Lathiat> pitti: about?
<\sh> sivang: sure thing :) so it means in 3-5 years ,)
<Moeen> resize_reiserfs is safe to use ?
<Lathiat>  subprocess pre-installation script returned error exit status 1
<Lathiat> from apt
<Lathiat> does that mean the preinst script
<Lathiat> or something else?
<Lathiat> cus i cant see anywhere the locales preinst script could return !0
<Lathiat> ah, sh -e, exits with error if a simple shell command fails
<siretart> \sh_away: the new gajim is nice! :)
<Lathiat> gah this is annoying
<Lathiat> anyone else have a problem upgrading locales?
<sivang> Lathiat: just overwrite, it will go away :)
<sivang> (that's what I've done)
<Lathiat> overwrite what?
<sivang> Lathiat: I got a problem with upgrading locales, about a file that was needed to replaced/overwrote. --force did the job
<Lathiat> nah thats not my problem
<Lathiat> Unpacking locales (from locales_2.3.7-1_all.deb) ...
<Lathiat> dpkg: error processing locales_2.3.7-1_all.deb (--install): subprocess pre-installation script returned error exit status 1
<Lathiat> preinst runs fine if i do it 
<Lathiat> so i dunno wtf is failing
<pitti> Lathiat, sivang: http://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-December/000043.html
<Lathiat> pitti: so.. how do i solve that?
<sivang> pitti: I didn't file any bugs about it :) I already read it :)
<Lathiat> so i have to install the new lang packs first?
<pitti> Lathiat: easiest in your situation: sudo dpkg -i --force-overwrite /var/cache/apt/archives/locales_2.3.7*.deb
<pitti> Lathiat: yes, that helps, too
<Lathiat> pitti: thats not helping
<Lathiat> pitti: as i said, its not an overwrite problem
<pitti> oh, I see
<pitti> https://bugzilla.ubuntu.com/show_bug.cgi?id=21436 maybe?
<sivang> pitti: I touched a dummy file, and it helped. Was it ok to solve this that way?
<pitti> sure, yes
<sivang> pitti: (and created the needed dir-tree)
<sivang> pitti: ah, cool :)
<Lathiat> pitti: yes, looks like that bug
<Lathiat> interestingly running the preinst manually works
<Lathiat> hrm, except the directory does exist here, weird
<Lathiat> ok im at a loss i have absolutely no idea why this is failing
<Lathiat> i extract the archive, the preinst script works fine, why would apt get me a sub-process pre-install script failed?
<Sepheebear> Lathiat: the only solution that worked for me was to patch the script and install the new deb
<Lathiat> hrm indeed
<Lathiat> interesting
<Lathiat> i just removed the preinst script
<Lathiat> the weird part is that the preinst script works fine before i go to install the package
<Lathiat> oh well
<Sepheebear> yeah i stuck a debdiff up on bugzilla but it doesnt seem to work in every case
<Lathiat> i saw that
<Sepheebear> there's got to be another solution though
<sivang> Lathiat: you had that dir alerady and it still faild?
<Lathiat> sivang: yes
<Lathiat> which makes no sense to me, even running the preinst manually worked fine
<sivang> weird. btw the bug report talks about breezy -> dapper, it also happen on hoary -> dapper
<slomo> elmo: please sync passepartout from debian/unstable... ubuntu changes can be dropped... thanks :)
<Mez> who has access to bugzilla to change the default assignee for a package ?
<mvo> Mez: I can do this, what package?
<Mez> katapult :d
<Mez> Assignee set to mez@ubuntu.com QA to kubuntu-bugs@lists.ubuntu.com
<psusi> people are allways asking how to mount their windows partition... shouldn't hal and gnome-volume-manager automount them for you?  if so, why don't they for so many people?  if not, is there a reason, or has it just not been done?
<tseng> man pmount
<tseng> read the POLICY section
<mvo> Mez: done
<thesaltydog> psusi I would never want to have my win partition automounted!
<Mez> mvo : cheers
<tseng> the hal/g-v-m/pmount stack is intended entirely for removable media
<psusi> thesaltydog: why not?
<mvo> Mez: please test for typos etc :)
<tseng> you can override the behaviour by putting user mountable entries in fstab
<Mez> ...?
<psusi> yea... but that question and answer comes up every day on the forums
<thesaltydog> because I need it only when there is some file to share, and for that I created a VFAT partition (automounted by fstab).
<psusi> seems like it would be nice to just have them automount
<Mez> mvo : :D http://bugzilla.ubuntu.com/post_bug.cgi
<psusi> so I'm wondering... is there a good reason NOT to have them automount?
<thesaltydog> psusi are you meaning the NTFS partition?
<psusi> thesaltydog: generally... yea... but really any partition
<thesaltydog> if you have a removable media, it IS automounted. Fixed partitions can be automounted with fstab entry. So just edit your fstab.
<psusi> I know this... but average users don't want to do that, and ask and are told that answer every single day
<tseng> so make it an FAQ or something.
<psusi> you should also be able to get them to be auto mounted by gnome-volume-manager by adding them to /etc/pmount.allow
<thesaltydog> tseng, +1
<tseng> ... or by adding them to fstab
<thesaltydog> psusi, g-v-m is for removable devices
<psusi> tseng: it's in several FAQs, people still ask ;)
<tseng> psusi: then that is their problem, I think
<psusi> thesaltydog: why ONLY removable devices?  It is perfectly capable of auto mounting hard drives too... so why shouldn't it?
<tseng> why would i want to mount /var from another os
<thesaltydog> read the policy section in man pmount. I haven't wrote it.
<tseng> and where would it go?
<psusi> if you have a seperate /var partition in another os and boot into ubuntu, it would go somewhere like /media/hda7
<tseng> because the users who cant google for mounting windows know what hda7 maps too
<psusi> thesaltydog: I understand that... my question is WHY?  it is easy enough to override that policy and allow the hard disks to be auto mounted... this seems like it would be a good thing to me... so I am asking, why isn't it?
<tseng> seriously, this doesnt seem like a problem if its already widely documented
<psusi> tseng: when they open it and see all their windows files... they are happy
<tseng> yes
<tseng> highly discoverable
* tseng makes a face and goes away
<psusi> iirc, when I installed ubuntu on a system with two drives, the setup process did configure the second drive in /etc/fstab automatically so it showed up on the desktop... but if you add the drive later, it doesn't "just work"
<thesaltydog> psusi, and when they write their first file on the NTFS partition they will be MORE happy :-)
<psusi> thesaltydog: then they will be told it is read only... and when they ask why, there's a good answer... but at least they can read...
<thesaltydog> if theu can read, it's easy to copy and paste an fstab entry!
<psusi> no, they can read their files I meant
<thesaltydog> from the FAQ
<psusi> they still seem to have a hard time reading the FAQ ;)
<thesaltydog> I believe it is not safe.
<psusi> hrm... under what circumstances could be be unsafe?
<thesaltydog> writing on the NTFS partition
<psusi> you can't write to NTFS partitions, the driver is read only
<thesaltydog> you have to make it read-onlu into the fstab
<psusi> no.. the driver only supports read only mode
<psusi> you can compile it with limited write support, which is actually safe, but of very little functionality, but the ones ubuntu distributes are compiled read only
<psusi> and if auto mounting might not be safe, maybe g-v-m could prompt the user when a new disk is installed?  then they could decide if they want to mount it, format it, etc... and it would "just work"
<shackan> hi, maybe it's not the right place, but what would I need in order to do a full recompile of ubuntu ?
<shackan> a friend of mine wants to compile it for amd64, I do know there are binaries available already, but he has got his reasons
<hyperactivecrond> err... I can login to launchpad but I can't login to the wiki... it says my password is wrong...
<jsgotangco> >
<jsgotangco> hmmm? we have an amd64 CD!
<hyperactivecrond> i just created my account today 
<shackan> jsgotangco, I said I know
<jsgotangco> ahh he's hardcore then
<zul> er...i think you want gentoo then
<hyperactivecrond> eek! gentoo
<shackan> I repeat, it is not for me, anyway, is it just possible to compile ubuntu from scratch ?
<mjg59> shackan: Not trivially, no
<zul> not really
<shackan> let's keep gentooisms away, please
<shackan> mjg59, why not ?
<mjg59> shackan: Because (a) there's no infrastructure to do so, and (b) there are circular build depends
<jsgotangco> shackan, you're better off doing it from scratch
<hyperactivecrond> linux from scratch, or sourcemage, or *shudder* gentoo
<jsgotangco> gentoo's not so bad really, you get to learn a lot
<mjg59> shackan: With (a) and (b) being due to (c) (there's no real point in doing so)
<shackan> mjg59, so how do your buildservers work ?
<robertj> wowzers, the pastebin script is the best thing since sliced bread
<mjg59> shackan: Ubuntu was bootstrapped from Debian
<hunger> jsgotangco: But only since gentoo usually fails in some place or another.
<jsgotangco> true
<hunger> jsgotangco: You do not learn more by sitting through endless compiler sessions (if everything works).
<mjg59> shackan: As for the initial Debian port - it was done by hand (since it only had to be done once)
<jsgotangco> hunger, yes let's skip that part tee hee
<dilinger> jsgotangco: slackware's where it's at, if it's learning you're after
<hunger> jsgotangco: Agreed:-) Let's not waste energy on gentoo when not using it;-)
<psusi> can't you just apt-get source all the packages and build them, then install them with dpkg?  very time consuming, but possible no?
<mjg59> psusi: Yes, but that's not "from scratch"
<dilinger> there's nothing like the feeling of recovering a system after a (by-hand) botched glibc upgrade
<robertj> dilinger: also known as "restore from backups"
<dilinger> pfft.  backups are for weenies!
<jsgotangco> lol
<psusi> I guess it depends on how you define "from scratch"... I'd say formatting a hard drive, starting with debootstrap, then compiling all the packages is prety "from scratch" ;)
<mjg59> Heh
<psusi> dilinger: is it something like recovering a system by hand after an MBR gets botched up?
<psusi> ;)
<shackan> mjg59: let's suppose I want to compile ubuntu for a not-supported arch (I DO know there's debian for that and that you do not support other archs, it is just an *example*) so, how would one do ?
<psusi> dd + emacs hexl-mode == fun times
<mjg59> shackan: You build stuff by hand until the circular build depends are satisfied
<dilinger> psusi: it's a bit more difficult; imagine if your MBR had config files scattered around /usr and /etc, and tied in with your compiler
<mjg59> Then you start feeding things into pbuilder
<psusi> dilinger: outch....
<mjg59> But since there's not really any architectures that Linux usefully runs on and Debian doesn't...
<shackan> yap, I said it was an example, thanks
<mjg59> But that's /why/ there's no infrastructure to do it.
<shackan> well, there has to be an infrastructure to do it :D you wouldn't be able to build ubuntu in the first place otherwise
<dilinger> psusi: you get libc fixed, but then your compiler no longer works.  you fix your compiler, but everything c++ based is suddenly broken..
<dilinger> psusi: it's lots of fun :)
<mjg59> shackan: Uh. No. We started from Debian.
<hyperactivecrond> is it true that we have a new installer?
<shackan> mjg59: ok, but now you have some sort of infrastructure on you own :D
<dilinger> ok, so it would appear that openswan decides whether to use klips or netkey based upon the existence of /proc/net/ipsec_version and /proc/net/pfkey, respectively
<dilinger> er, ECHAN
<mjg59> shackan: Not really, no
<mjg59> Individual packages are built whenever a new source package is uploaded
<mjg59> But there's no requirement to be able to start from scratch
<hyperactivecrond> err i can't login to the wiki but i can login to launchpad
<hyperactivecrond> any ideas?
<hyperactivecrond> why i cant? it says wrong password
<thesaltydog> hyperactivecrond, wiki account is not the same as launchpad's one.
<hyperactivecrond> thesaltydog: *sigh* where do i sign up for the wiki then
<thesaltydog> mmhh maybe I'm wrong. To register to the wiki you should register to launchpad. I was wrong because I have registered to the wiki before launchpad was up.
<hyperactivecrond> if i login with my launchpad account in the wiki it says 'wrong password'
<hyperactivecrond> i just created my new account today
<thesaltydog> your cookies are enabled, right?
<hyperactivecrond> thesaltydog: yes...
<thesaltydog> once logged on launchpad, are you not able to edit a wiki page?
<thesaltydog> maybe you should let the systems synchronized. Wait untile tomorrow..
<hyperactivecrond> It says 'edit' but it doesn't say logged in as Christophercmolik
<thesaltydog> but if you press on edit, the system lets you get in?
<hyperactivecrond> yew
<hyperactivecrond> ys
<hyperactivecrond> yes*
<thesaltydog> click on UserPreferences on right-top and fill it.
<hyperactivecrond> it's not here
<hyperactivecrond> there*
<Mez> mjg59, you're tech board right ?
<hyperactivecrond> it says my wikiname in the userpreferences page but if i type in my launchpad pass it wont work
<thesaltydog> try waiting at least 24 hourse from registration..
<hyperactivecrond> ok... i'll do that
<mjg59> Mez: Yeah
<Mez> mjg59, do you remember the whole fiasco about iFolder ?
<mjg59> Mez: I remember the iFolder discussion, yes
<Mez> well, I dont know if theres been any update since then on this side of thigns - but IFolder's now free, open source and GPL (all of it)
<Mez> is it ok for me to proceed with packaging it and shoving it in universe?
<mjg59> If nobody else is working on it, then of course
<Mez> mjg59, I dont know of anyone else is :D and well - It's been an agreement between the iFolder devs and I for a long time for me to do it
<mjg59> Well, sure - go ahead
<Mez> cool :D
<HiddenWolf> heh. Half the team is on vacation, and yet the -changes list is buzzing. :)
<\sh> HiddenWolf: cleaning up the rest
* hunger finds it surprising how many people want to compile stuff yet have no clue about how to install the stuff they require to do so.
<zul> hunger: its the thought i can do it better than you can but i dont know where to start
<hunger> zul: Yes, it must be something like that.
* hunger wonders why people claim linux is hard to install (trying to install winXP at the moment).
<hunger> Ubuntu is *WAY* easier to install and way faster, too.
<psusi> I realized that when I installed it on my cousin's computer... he kept asking me things like "don't we need to download the network drivers?" and "don't we need to download the video drivers?"
<psusi> nope... ubuntu just works... he thought that was cool...
<hunger> psusi: Yeap... it never took me that long to install anything. Any I even have paid for that provoledge:-(
<psusi> I nearly smashed my grandma's computer last week I got so pissed at XP home edition... I had set up her account to be non administrative so she couldn't virus up the whole machine...
<psusi> she couldn't use the recycle bin... ok, no problem I thought... need to give her write access to the recycler directory... YOU COULDN'T DO IT!~
<hunger> psusi: I am trying to install the XP that came with my computer without ruining my linux.
<psusi> XP home hides the security tab in explorer... an XP pro machine at work hid it by default too but the GPO snapin let me reanble it... XP home has no GPO snapin
<psusi> so not only did they hide what I needed that used to work just fine, they even hid the way to unhide it
<hunger> psusi: So far I have ruined 6 CD-RWs trying to build the install CD that was ommited in favour of some stupid recovery CDs that clean up the whole HD.
<psusi> hell, I ended up attempting to use the cacls program from the command line to set the permissions... it doesn't have a quarter of the functionality it should, and for some reason when I asked it to change perms on "." from inside the recycler directory, it instead changed them on c:\windows... oh boy was I pissed
<hunger> psusi: I feel your pain!
<psusi> how do you ruin a cdrw?  you can just erase it?
<hunger> psusi: Aehm... not RW, the other kind.
<psusi> yea... these days dell doesn't ship the cds... they jsut have a ghost image on another partition on the drive that you can use to restore the system to it's factory default state
<psusi> ohh... just cdr?  life is easier when you use a cdrw ;)
<hyperactivecrond> in 2day's dapper installation iso, the timer doesn't work for teh bootsplash screen
<Burgwork> hyperactivecrond, it may have been disabled
<hyperactivecrond> poss/probably
<tseng> jdub: you're my osnews hero!
<hunger> dylan_:  Most linux distris are more secure by default then windows is by default.
<hunger> dylan_: Having said that: You can make linux insecure just as you can make windows secure.
<hunger> dylan_: Mostly because linux encorages "limited users" for everyday work more thouroughly then windows does.
<Treenaks> hunger: still.. if you download malware which knows about (gk)sudo
<Treenaks> hunger: how many "idiot users" will blindly enter their password?
<hunger> Treenaks: Sure. But that is more then viri normally have to tackle in windows.
<Treenaks> hunger: still something to think about
<hunger> Treenaks: Of course viri for linux are possible, it is just a little harder to write them.
<hunger> DAMN. I am talking on the wrong channel again! Sorry for that.
<hyperactivecrond> is OEM mode done as of 2day's cd?
<hyperactivecrond> dapper
<Burgwork> hyperactivecrond, yes
<hyperactivecrond> ... how does one use it? 
<marcin> hello sorry to bother - because it's propably #ubuntu question - unfortunately no help from #ubuntu and my question is related to development
<marcin> I compiled gnome with jhbuild
<marcin> and I wanted to run my two desktop simultaneously
<marcin> gnome-desktop from dapper on 7-th console and cvs/jhbuild gnome on 8-th
<marcin> I uncommented line in [servers]  section in /etc/gdm/gdm.conf
<marcin> but unfortunately it didn't work
<marcin> has something changed in dapper or can it be a bug?
<\sh> doko: hope you have a nice christmas :)
<\sh> s/have/had/
<hyperactivecrond> how does one use oem mode for dapper/
<HiddenWolf> hm, it should be on the install cd as an option
<hyperactivecrond> HiddenWolf: yes it is but it is configured in the preseed dir, yes?
<HiddenWolf> I haven't used it myself
<hyperactivecrond> ...
<HiddenWolf> I'll have to pead no clue on this one.
<HiddenWolf> plead
<hyperactivecrond> ...
* hyperactivecrond goes testing
<hyperactivecrond> is this used the way the debian installer does things/
<HiddenWolf> https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/OEMInstaller?highlight=%28OEM%29
<HiddenWolf> hyperactivecrond, that's the specification
<hyperactivecrond> thx HiddenWolf 
<hunger> pitti: I hope you do not mind me assigning another trival pam-mount bug to you.
<hunger> pitti: Another one line change to allow the use of /dev/disk/by-whatever.
<sistpoty> lamont: could you please clear vice from dep-wait? should be fixed now
#ubuntu-devel 2006-01-03
* lamont grumbles at pitti/mjg59
<lamont> on my machine, the hfs+ filesystem is autodetected and mounted.  On my daughter's machine, it isn't.  But I can manually mount it.  Why is that, huh?
<lamont> 2.6.12-10-amd64-generic vs 2.6.12-10-686
<lamont> her's a upgraded-over-time-from warty machine, mine is a virgin breezy install.
<mjg59> Christ knows
<mjg59> Almost certainly not my fault :)
<lamont> mjg59: do you know the official sequence?
<mjg59> Nope
<lamont> mjg59: true, but ENOPITTI
<lamont> and you know all, so, um, ....
<Burgwork> mjg59, should my laptop be automounting  my NTFS partition?
<mjg59> Are you in the same groups?
<lamont> well, I'm in the same groups on both machines, and it doesn't mount for me there either
<lamont> I freely admit that I did jack around a few groups on her machine at one point... that could be what I'm actually fighting
<lamont> hrm.. no seb128 either
<Burgwork> lamont, they are all on vacation
<zul> lamont: you're screwed ahahah...er...
* lamont whacks zul
<lamont> I suppose I could boot a livecd and see if that works...
<ds> does anyone know why cups needs it's own authentication domain?
<hunger> HurricaneJ: Install debfoster and do sudo debfoster.
<hunger> HurricaneJ: That will ask about all installed apps and remove anything not needed anymore as well.
<robertj> wow...xchat-gnome is...different
<apokryphos> oh?
<Amaranth> xchat-gnome > *
<Amaranth> takes a day or so to get used to, but i don't want to go back
<robertj> there are two features I am missing and I think either way I would need to write my own plugin
<robertj> first is a channel grep and the second is a last x lines from nick
<robertj> much changed since .8?
<Amaranth> dunno, think the last i used was .7
<Amaranth> i'm stuck on OS X right now
<robertj> Amaranth: I get stuck there alot too
<FireRabbit> anyone around farmiliar with setting up APT repositories?
<Amaranth> robertj: haha, not like that
<robertj> what is sad is that I often end up running ubuntu in VirtualPC
<Amaranth> robertj: Airport Extreme
<robertj> oh
<Amaranth> and the open source driver still sucks
<robertj> I have to baby sit some OS X apps at work occasionally
<robertj> VirtualPC aint bad if you are patient, playing minesweeper, and have a dual machine with 2 gigs of ram
<Amaranth> haha
<Amaranth> G4 1.42Ghz 512MB
<robertj> Forget about it
<robertj> painful
<robertj> took me 2 days to install Windows and Office + patches
<ds> er, why would a package depend on libc6-amd64?  (on i386)
<crimsun> I only know of alsa-driver b-ding on it?
<FireRabbit> ah nevermind, figured it out
<robertj>  Aramanth: does Ubuntu have any sort of policy on "Special" folders. I've noticed that gnome-screensaver looks in ~/Pictures by default and DCC downloads default to a Downloads folder in xchat-gnome
<robertj> I guess if you were going to be really all "integrated" and stuff it would be nice to have a gnome-chat option "Add to Address Book" and "Show joins/parts for only users in my address book in channels with more than X people."
<Amaranth> robertj: Yeah, let's bloat the preferences with things most people don't care about (join/part thing). ;)
<robertj> for the most part, I care about join/parts on 10 user channels but not on 100
<robertj> but if they were in my address book I would always want to see them
<robertj> but you don't need an option for that last part, it would just be a "don't show parts for strangers on channels with less than X people"
<lifeless> Amaranth: bah, thats not a reason not to do it. 
<lifeless> Amaranth: thats the 'if enough people dont want it, dont to it' meme, which is nonsense.
<robertj> Effects gets my vote for the preference to vote off the island ;)
<lifeless> Amaranth: ask instead 'how can we add this without harming new users'.
<Amaranth> lifeless: No X users would be good.
<Amaranth> lifeless: I can see "Show join/part messages for people in my address book."
<robertj> Amaranth: I think its kinda stupid
<robertj> of course you want to see those
<robertj> and if you don't, too bad control freak
<lifeless> Amaranth: what about just a right mouse click on a channel, then click 'off' on show join/part
<lifeless> per channel, saved in the background, not part of massive preference chaos.
<Amaranth> lifeless: But should it turn them all off or only unknown people?
<robertj> that'd be fine too, do you still show the people known in your address book without asking?
<lifeless> Amaranth: I'm not a ui designer, but thats a good question.
<robertj> what about people on ldap sources...etc
<lifeless> Amaranth: I'm simply saying 'not implementing because its hard is nuts'
<lifeless> not implementing because its a 'bad idea' is ok.
<Amaranth> lifeless: If only 3 people want it is it worth implementing, no matter how hard it is?
<Amaranth> I could see hiding it in gconf if one of those 3 submitted a patch.
<lifeless> Amaranth: if one of them does it, or is sponsoring it, and it wont harm anyone else, sure.
<lifeless> hiding it in gconf makes it non discoverable, which just means more education and rants.
<Amaranth> lifeless: If it's only in gconf people who want it know where to find it and people who don't don't have clutter in the preferences dialog.
<marcin> Amaranth: what are you guys talking about?
<Amaranth> marcin: Imaginary program, imaginary feature.
<marcin> Amaranth: eog?
<Amaranth> I wish colloquy and iTunes would stop spiking to 40% CPU each
<robertj> no real program imaginary features
<Amaranth> marcin: No...
<Amaranth> why the fsck does an irc client need 10-40% CPU constantly?
<marcin> Amaranth: switch to erc ;)
<Amaranth> marcin: I already have a buggy OS, I don't need two.
<marcin> erc is irc client in emacs
<Amaranth> I know.
<Amaranth> emacs is the second buggy OS
<marcin> Amaranth: it needs maybe 1% CPU
<marcin> Amaranth: I agree that it's buggy ;)
<marcin> Amaranth: but it's nice that you call emacs - OS :)
<Amaranth> not really
<robertj> the notification on message in xchat-gnome is great too, but it doesn't have an option to show you the message as well
<Amaranth> it's a polite way of saying it's bloated
<robertj> I recommend XChat Aqua
<marcin> Amaranth: :)
<marcin> Amaranth: night
* psusi is using Xchat... but also likes chatzilla
<lifeless> Amaranth: what are you smoking ? gconf is -not- a place that people -know to look- to find features. 
<lifeless> Amaranth: if gconf was so useful, no program would need preference dialogs at all.
<jdub> gconf is just scaffolding
<jdub> it is rarely the answer to anything usability or user interface design related
<robertj> lifeless: gconf is ok for "I want this feature, and somewhere there may be one other person who does too" type stuff
<psusi> gconf is like windows' ini file apis or registry... it provides a nice way for a program to save settings without having to reinvent the wheel
<jdub> robertj: no, gconf is where (almost) *all* gnome configuration information is stored
<robertj> jdub: I meant as a primary method for setting and unsetting options
<jdub> robertj: it's not that, either
<robertj> jdub: fine, gconf-editor is a suitable interface for setting some very eccentric settings intended exclusively for a small number of highly-technical individuals?
<lifeless> robertj: I disagree
<psusi> like windows' registry editor, it is not meant to be a primary method for users to change configuration options... the tool is only there to provide A way to do so... for power users and system administrators
<lifeless> robertj: gconf-editor is a debugging tool for when preference setting mechanisms go wrong, it should never be the 'way' to enable or disable something.
<robertj> Iifeless: some features are so unusual that either they don't go in or they are exposed exclusively through gconf because implementation time for a better gui exceeds the utility of actually putting them in
<robertj> not to mention that user time is a resource that gets consumed looking through options
<psusi> aye.... but that should only be for the most esoteric and technical options
<robertj> psusi: which is what I just said no?
<psusi> yes... I'm agreeing...
<robertj> but really there are alot of features noone needs that we want to still provide access to because it doesn't really hurt anyone to expose them through the editor
<robertj> "and that's about all I got to say about that"
<psusi> is there anyone else I could have a talk with about gnome-volume-manager and pmount besides pitti? I've not seen him around lately
<jdub> psusi: he's having a break - will be back soon enough
<psusi> ahh... when will that be, and I guess that means the answer to my first question is no? ;)
<zul> oh hey jdub 
<jdub> psusi: not sure; you can always ask your question though
<psusi> well... I'm trying to modify the hal information so that g-v-m and pmount will auto mount a read/write udf formatted cdrw in read/write mode via the packet writing interface... I have managed to get that to happen, only it doesn't show up on the desktop
<psusi> it does get auto mounted correctly in /media though, and I can access it from the command line
<psusi> so why would it not show up on the desktop?
<tseng> the desktop only shows things that are user mountable
<tseng> assuming you have show_volumes
<psusi> it is user mountable... I modified the hal policy rules to change the block.device from /dev/hda to /dev/pktcdvd/pktcdvd0 so when I insert the disk, it does get auto mounted correctly... just doesn't show up
<robertj> psusi: does it have the .created_by_pmount file?
<psusi> in /media/cdrecorder?
<robertj> yeah
<psusi> when I umount it, yes
<psusi> the really strange thing is... if I mount it by hand read only, it shows up
<psusi> mount it read/write via the packet writing device, and it doesn't show up
<stub> Launchpad going down in 15 mins for the regular updates, which will put the wikis into read only mode. Downtime estimated at 40 mins.
<psusi> where's the code that notices stuff in /media and shows it on the desktop?  It looks like it doesn't like devices that aren't in /dev ( and not a subdir of it )
<psusi> weird... moved /dev/pktcdvd/pktcdvd0 to /dev and now when I mount it, it shows up on the desktop... but under the name "cdrecorder" instead of the volume label of LinuxUDF... and the icon does not go away when I umount it
<psusi> mount it again with /dev/hda insteaed of /dev/pktcdvd0 and LinuxUDF shows up on the desktop... so there's two icons for the same thing... only with different labels
<zul> hey jeff
<jbailey> Zooool.
<jbailey> I'm playing with my new openwrtized linksys.
<tseng> there is only zul
<jbailey> Fitting Ubuntu on this is going to be a bitch.
<tseng> jbailey: good luck with the kernel
<jbailey> tseng: Yeah. =(
<jbailey> tseng: Although ISTR someone was reverse engineering the wireless broadcom driver.
<jbailey> So perhaps it will actually be possible soon.
<jdub> jbailey: netboot, netboot ;)
<SEJeff> tseng, Get with the times. There is only xul :)
<jdub> totally acceptable configuration for a firewall! ;-)
<jbailey> jdub: That's actually half the reason I wanted the openwrt.  My old gnet was interfering with netbooting my ltsp box. =)
<jbailey> That and I want pure IPv6 on my local lan, but hey... =)
<SEJeff> And I thought I had a lot of machines on my lan
<SEJeff> How likely would vSecurity have of making it into universe (possibly main) for dapper?
<jbailey> SEJeff: Things can still make it into universe no problem for another couple of weeks
<jbailey> SEJeff: It needs that first, then a main inclusion report done.
<SEJeff> jbailey, Would it be possible to make it into main though? Theoraticlly?
<SEJeff> This is from ubuntu-hardened project
<jbailey> SEJeff: Sure, no reason why note.  Things can be promoted to main even after version freeze.
<SEJeff> jbailey, Excellent
<SEJeff> I *really* want Ubuntu to have something like vSecurity and thats why I've been helping trulux test vSecurity
<jbailey> I don't know anything about it.
<SEJeff> jbailey, Do you want a quick rundown of what it can do?
<jbailey> SEJeff: I think I'm a bit sleepy right now.  I might ask you tomorrow though. =)
<SEJeff> jbailey: Please do. It's quite impressive once you see it work and nothing breaks
<SEJeff> jbailey: I've been trying to break it the past few days without much luck
<jbailey> Nothing breaks is always good advertising. =)
* psusi would like to get his initramfs scripts added to the dmraid package and have it moved to main in time for dapper so it can support hardware fakeraid out of the box
<jbailey> I tried looking the other day to see if there was someway of setting capabilities from the filesystem rather than just using SUID/SGID, but it looks like it's still not possible.
<SEJeff> jbailey, vsecurity includes cap_over
<jbailey> psusi: Why is main important for that?
<SEJeff> A way to add something like NET_RAW to /bin/ping
<SEJeff> That way, you can remove suid root from ping and it still runs perfectly
<psusi> jbailey, isn't there a wrapper program like sudo that you can use?
<jbailey> SEJeff: Ah nice.  Does that just use extended attributes in ext3?
<psusi> jbailey, well, main AND added to a seed like ubuntu-base... right now it's just in universe
<SEJeff> jbailey, Extended attributes won't support that
<jbailey> psusi: I can do it with a wrapper, but why?  CAP_NET_RAW for /bin/ping is an excellent example.
<SEJeff> http://www.randombit.net/projects/cap_over/ This is the code it uses
<jbailey> There's no real reason why you need a wrapper program that's SUID just to drop privs for ping.  It would be a bit excessive.
<psusi> true
<SEJeff> we work with the developer of cap_over
<SEJeff> And the trusted path execution code written by IBM also works flawlessly
<SEJeff> That would out of the box kill thinks like the lapper worm
<jbailey> Ah, I hadn't seen cap_over before.
<psusi> jbailey, untill it is in ubuntu-base or otherwise installed by default, hardware fakeraid won't be supported out of the box
<psusi> and I'll have to debootstrap my system from a livecd again ;)
<jbailey> Is that just using the same mechanisms that selinux uses?  I remember they integrated a bunch of them.
<SEJeff> jbailey: Yes, lsm
<SEJeff> vsecurity uses lsm extensively
<jbailey> Cool.  Looks like something to add to my reading list.
<robertj> ooh yummy nautilus patch for D&D on the places bar
<SEJeff> there will be a new release out soon and trulux has been going crazy lately on polishing it up / fixing some things
<psusi> does adam conrad hang out in here?
<Amaranth> i'd need an irc nick ;)
<Amaranth> sounds familiar...
<psusi> Amaranth, you're Adam Conrad?
<Amaranth> no
<Amaranth> <--Travis Watkins
<psusi> ohh... I don't know his nick.. that's why I'm asking ;)
<dilinger> psusi: infinity
<Amaranth> *facepalm*
<zul> i think he is on vacation as well
<zul> or asleep
<jbailey> SEJeff: My only problem with these policy files is that it means that the metadata is separate from the file.  So I can't tar it up and untar it elsewhere and have it Just Work.
<psusi> doh... that would explain why he hasn't responded to my dmraid bug
<jbailey> SEJeff: Or mv the file or whatnot.  Do you know if someone is addressing that at all?
<psusi> does tar understand extended attributes?
<jbailey> Yes.
<psusi> cool
<jbailey> It can tar them up using the posix interfaces.
<SEJeff> jbailey, I thought gnu tar didn't do extended attributes and that is what star was written for
<SEJeff> jbailey, Think about how much of a PITA having to look at every file for attributes is
<Amaranth> perhaps they merged?
<SEJeff> vs using grep -r though /etc/cap.d/ or something like that
<SEJeff> not sure
<jbailey> SEJeff: Right, but star doesn't do anything that tar doesn't do anymore.
<jbailey> SEJeff: tar was inactive for a long time.  It's now actively maintained.
<SEJeff> jbailey, News to me
<SEJeff> Very good to hear. I learn something new every day
<psusi> I like tar's new incremental backup feature with a snapshot file... you can build tiered dumps with that
<jbailey> SEJeff: I'm theoretically one of gnutar's co maintainers. =)
<psusi> so you can do things like a full backup only once a month, then do smaller weekly backups, and even smaller daily backups... but to restore you only need to untar 3 files... the last monthly, the last weekly, the last daily... not every single daily since the last full backup
<SEJeff> Good to know
<psusi> and it supposedly notices things like deleted files in newer backups and won't restore them from older backups
<zul> right night..
<SEJeff> night
<SEJeff> It's that time for me also. Another day converting hp-ux servers --> linux servers woohoo
<jdub> SEJeff: a righteous mission
<jbailey> SEJeff: On ia64 or hppa? =)
<whiprush> howdy jeff.
<whiprush> and jeff.
<jbailey> whiprush: =)
<jdub> name stealing bastardos!
<SEJeff> jeff is a good name
<zul> jbailey: troll
<SEJeff> I hear that people named jeff are born brilliant
<SEJeff> It's just what I hear
<jbailey> zul: For which comment? =)
<zul> either or
<SEJeff> jbailey, PA-Risc, hppa stuff
<SEJeff> Night guys
<zul> 3/exit
<jbailey> g'n SEJeff, Chuck.
<whiprush> jdub: I got a cool email from someone that's totally jdub-esque. The process is still in its early inception, but I just have to send it to you because it rocks.
<jdub> whiprush: none of what you said follows, but it sounds cool anyway... ;)
<whiprush> jeff.waugh@ubuntu.com? (sorry, I am away from my normal machine)
<jdub> yeah
<whiprush> you've got mail!
<jdub> yay mail
* jdub is mucking with his mailserver atm too ;)
<whiprush> jdub: Somehow I kind of feel that we should let you guys know some LoCo team stuff like that and get an "attaboy". Otherwise we end up just going to bars and drinking instead of doing real advocacy work. :)
<jdub> haha
<jdub> haven't got it yet
<jdub> turning off sender address verification has resulted in 400 mails in the last 10 minutes
<psusi> rofl
<whiprush> So a few months back newforge ran this story about a jesuit school in detroit running ubuntu and ltsp.
<whiprush> The mail I sent you is from a dude that works for Ford and wants to form a non-profit building ubuntu computers for disadvantaged youths and stuff.
<jdub> awesome
<whiprush> apparently he's meeting with the COO of Ford and working on getting sponsorship.
<whiprush> so he goes onto the ubuntu wiki, and finds us local people.
<whiprush> jdub: So this ties into "Getting jdub to come to the midwest US." plan ...
<whiprush> so we're gonna help the guy out, etc. etc.
<jdub> whiprush: did you see the latest poll?
<psusi> do any of you guys have a microsoft optical intellimouse?  I can't believe I've only seen one other person besides me complain that xorg 7 has reassigned buttons 6 and 7 to 8 and 9 ( wtf? it's only a 7 button mouse! ) so back and forward don't work in firefox anymore
<whiprush> no, I've been tied up in family business until today.
<whiprush> need to catch up on fridge businesss.
<psusi> isn't Ford broke right now? ;)
<whiprush> no, that's GM.
<whiprush> well, they're not as broke as GM anyway. :)
<psusi> hehe
<whiprush> jdub: ugh, north america isn't doing so hot in that poll.
<jdub> whiprush: given that you've already had a go... ;-)
<jdub> whiprush: mind you, look at my page on the wiki
<whiprush> heh
<whiprush> yeah, but you end up at the summit and 2 linuxworlds /anyway/ ...
<whiprush> so maybe we can sneak in. :)
<whiprush> jdub: Had you come to detroit, no one would have stolen your laptops. They would have just taken your wallet. :p
<jdub> haha
<jdub> whiprush: you should definitely look into the freegeek project in portland (and new ones that have popped up elsewhere in the USA)
<jdub> whiprush: they're *extremely* well organised
<jdub> whiprush: sounds like a natural fit for this idea in some ways
<jdub> (just reading the email now)
<whiprush> ah, mako was into that wasn't he?
<whiprush> I recall the idea
<jdub> don't think so
<jdub> freegeek is a co-op refurbishing group
<whiprush> I will look into that
<whiprush> I'll send them a mail. At the least they probably know best-practices or something, which we know 0 about.
<psusi> anyone here read "Understanding the Linux kernel" published by Oreilly?  picked it up the other day and it seems nice
<dilinger> psusi: it's decent for writing drivers
<dilinger> psusi: not really all that useful for core stuff.  robert love's book is much more thorough (well, the old edition; haven't read hte new one)
<psusi> hrm... what's the title?
<whiprush> rml's book is funny to boot. :)
<psusi> this book seems to talk about the whole thing rather than just how to write drivers to me
* psusi wishes his local bookstore had half as many books on the linux kernel as he has on his desk about NT's kernel
<mako> whiprush, jdub: i've spent some time at freegeek.. i know a few of the people there
<whiprush> mako: do they have chapters outside of portland?
<whiprush> I'm kind of in that situation, but it's probably best if I mail you about it when I get better details.
<mako> whiprush: yes
<mako> whiprush: one in PA and one in WI IIRC
<whiprush> mako: cool and the gang. Someone locally wants to do ubuntu prebuilds. I'll mail you when I get more info.
<mako> whiprush: please do, that sounds great
<whiprush> mako: I'll send you the note the guy mailed me now.
<jdub> whiprush: i visited there when i was in portland - it's really amazingly good. best model to use for something like this.
<whiprush> this sounds excellent.
<jdub> whiprush: (to the point where, with funding, it would be worth going there or shipping out a couple of the principals as a learning expedition)
<whiprush> jdub: much to early to be thinking that. But yeah, long term that would be great.
<shadeofgrey> hi everybody
<shadeofgrey> im here because i dfound a very blatant bug in dapper
<shadeofgrey> the option to make your mouse left handed - the checkbox will fill in properly and the icon will change and indicate that the buttons have been properly swapped, but it doesnt actually change the button assignments
<jdub> elmo, Znarl: ping
<seth_k|lappy> shadeofgrey, http://bugzilla.ubuntu.com
<Amaranth> wow, people actually use left-handed mice?
<seth_k|lappy> dunno, my brother is left-handed and doesn't
<Amaranth> i'm left-handed and i don't
<shadeofgrey> what do i assign as the "component" for the above bug?
<nofear> hey gotta stupid question..
<nofear> I am on a satilite connection and i got a idiot for a brother who downloads alot.. and I want to set up a box using ubuntu to shair internet connections but I want to cap downloads to a certain speed. 
<nofear> is that Possible to do in ubuntu?
<Amaranth> yeah, i think iptables can do that
<Amaranth> it can do everything else :P
<shadeofgrey> would oneof you kind people care to take a minute and file a bug report on my behalf if im very specific about the symtops/problems etc.? the interface online for filing bugs is very complicated and i dont know the answers to most of the fill in the blank spaces
<crimsun> what prevents you from filing it?
<shadeofgrey> a lot of fill in the blanks that i dont know the answer to like components and such
<shadeofgrey> its not a bug with a specific program. its a big problem with the mouse applet under system --> preferences
<crimsun> just fill in as much as you can
<shadeofgrey> well
<shadeofgrey> thats proving to be a problem as well...  because i cant make the buttons on my mouse left handed I cant even navigate the form well.  im very physically handicapped
<shadeofgrey> i tried using the tabb key on my keyboard but the experimental version of firefox on dapper races through them when u use keyboard to skip forward and back in forms
<crimsun> so is the Mouse preference dialog itself limiting you? If so, in what way?
<shadeofgrey> the mouse pref3erence dialog is accepting the checkbox "make left handed mouse" which is immediately supposed to swap the buttons - but when you click okay and the applet closes the changes are never applied
<crimsun> are you running current Dapper? I had that problem as well up until last week.
<shadeofgrey> im using flight 2
<shadeofgrey> thats the newest is it not?
<crimsun> it's the latest snapshot, but your issue has been resolved in current Dapper
<shadeofgrey> should i be downloading the latest nightly?
<jdub> shadeofgrey: those are CD releases - latest dapper is always in the archive
<crimsun> you just need to update and dist-upgrade
<shadeofgrey> okay.. lemme boot into dapper and ill try
<shadeofgrey> brb 5 mins
<crimsun> either via Applications> Accessories> Terminal, or System> Administration> Synaptic Manager (choose Smart Upgrade)
<jdub> slomo_: ping
<jdub> slomo_: n/m
<zakame> elmo: Please sync gpdf, libcurses-perl, libevocosm, libfwbuilder, libgnome2-wnck-perl, libpanelappletmm2.6, and nufw from Debian Sid, ok to override Ubuntu changes.  Thanks :-)
<hunger> mojo: XP can do bridging just fine.
<Mez> hunger: depends what you call fine
<hunger> Mez: So "fine" that it used to do bridging by default, causing me trouble without end when I booted win up and suddenly I was bridging some WLAN into the management network at a customer's site:-(
<hunger> Damn! I am on the wrong channel *AGAIN*. Sorry.
<hunger> Someday I will figure out how this client displays channels.
* hunger is so sorry.
<zul> morning
<zakame> wb Seveas 
<zwnj> apt-get doesn't send NO-CACHE in HTTP request.  it causes that i have to force our cache to get Release and Release.gpg files with "wget --no-cache".  for security updates, it's a big mistake.
<Treenaks> zwnj: you want apt to cache packages
<Robot101> Treenaks: yes, but not package files
<Treenaks> Robot101: those too
<Treenaks> Robot101:  the caches should at LEAST do an If-Modified-Since: / ETag match on the originating server
<Robot101> no, you really do want the proxy to talk to the server and find what the latest file is
<Robot101> doing a HEAD with no-proxy is fine
<Robot101> er, no-cache
<zwnj> Robot101: yes
<mojo_> gosh, are there any work around to fix locales problem? I want to fix the locales now so I can go on with other testing, ( I recieve err perl: warning: Setting locale failed.
<mojo_> perl: warning: Please check that your locale settings:
<mojo_>         LANGUAGE = "C",
<mojo_>         LC_ALL = (unset),
<mojo_>         LANG = "C.UTF-8"
<mojo_> )
<mvo> zwnj, Robot101: have you tried runing with "apt-get update -o Acquire::http::No-Cache=true" ?
<Treenaks> mvo: that's not default?!
<zwnj> mvo: no, i didn't know about this option at all!
<zwnj> btw, i should try it later, when some Release files get update
<mvo> Treenaks: no, default is sending a I-M-S 
<Treenaks> mvo: sounds reasonable.. so the proxy/cache is broken then?
<Treenaks> mvo: or the remote server
<mvo> Treenaks: I don't know about cache used, if zwnj send me the output of "apt-get update -o Debug::Acquire::http=true 2> debug.log" I can have a closer look
<mvo> it seems that quite a few cache are problematic :/
<zwnj> mvo: sure, but it works fine now
<mvo> zwnj: with No-Cache=true?
<zwnj> mvo: i did wget --no-cache for all Release files with a bash script, so there's no problem now
<zwnj> mvo: but before that, i had Release file for about two weeks ago
<mvo> zwnj: what proxy/cache do you use?
<mvo> or your provider?
<zwnj> mvo: we have a global web cache in university
<zwnj> we had the same problem with yup last year, and svidal patched yum to solve this
<zwnj> ^yup^yum
<mvo> zwnj: I would be interessted if the No-Cache=true switch helps. you can just make it default then. I still would be interessted in looking at the ouput of Debug::Acquire::http=true when you have the problem the next time
<zwnj> mvo: sure, thanks btw
<mvo> cheers
<zwnj> mvo: but how i can set it as default just for Release/Release.gpg files?
<mvo> *ick* right. that's a problem :/
<verwilst> hellow!
<Pygi> ho
<verwilst> i seem to have a problem on a few servers running dapper
<verwilst> with locales_2.3.7-2_all.deb
<verwilst> that's being silly ;)
<Robot101> verwilst: don't run your servers on dapper, you utter crack fiend
<Robot101> verwilst: and, /topic
<sivang> hey Pygi 
<Pygi> I suggest you head over to #ubuntu-server
<Pygi> hello sivang
<Pygi> what's up? how holidays passed? :)
<verwilst> oh
<verwilst> :d
<sivang> verwilst: you need to touch a dir, and they will set up cleanly. It's all due to locales transitiont as noted in Martin Pitt's email
<verwilst> aah yes, Martin Pitt's email, how could i forget.. :d
<verwilst> who's martin? ;) and on ubuntu-devel list i presume?
<sivang> verwilst: well, dapper is under heavy development
<verwilst> sivang: yeah i know :)
<sivang> verwilst: if you want to use it, you would most probably need to read ubuntu-devel mailing list to be able to keep up
<Pygi> verwilst: and still not ready for prime time :)
<verwilst> Pygi: oh, but those servers will be in testing for some weeks ;)
<verwilst> it'll probably be settled down a bit by then ;)
<pitti> verwilst: what is 'a problem'?
<pitti> sivang: the directory existence issue was fixed in -2 yesterday
<hunger> Hey pitti.
* pitti ducks
<pitti> :)
<pitti> hi hunger
<Pygi> hi pitti
<hunger> pitti: Yeah, I'd duck and cover, too if I were in your place;-)
<zakame> heya pitti 
<hunger> pitti: I assigned another wishlist bug about mount.crypt to you yesterday. I hope that is OK... it is a oneliner and you need to touch that file anyway when taking care of the other one.
* hunger wonders whether he is the only one paranoid enough to actually use all this crypto stuff.
<ogra_ibook> hey pitti 
<sivang> pitti: Cool :) Howdy ? 
<ogra_ibook> pitti, there were locale problems in dapper, did you already hear about them ? :P
<sivang> ogra_ibook: hehe
<hunger> strange... one problem I managed not to run into;-)
<verwilst> pitti: hm, it's -2, lemme check the exact error
<hunger> ls -alF
<verwilst> Preparing to replace locales 2.3.6-3 (using .../locales_2.3.7-2_all.deb) ...
<verwilst> dpkg: error processing /var/cache/apt/archives/locales_2.3.7-2_all.deb (--unpack):
<verwilst> is all it says
<zwnj> mvo: Acquire::http::No-Cache=true works, thanks
<psusi> pitti: are you around?  I have some questions about pmount, g-v-m, and gnome-vfs if you have a second
<pitti> psusi: at the phone now, will ping you back
<psusi> sweet
<verwilst> oh well,i filed a bugreport
<pitti> psusi: sorry, I got disconnected; what's up?
<psusi> pitti: ok... first a bit of background info... I've been messing with the udftools package to set up a cdrw for full read/write mounting
<psusi> I got it working and it is nice, only when you insert the disk, it is auto mounted read only... so I decided to modify the hal policies to fix that
<psusi> the problem is that to mount it read/write you have to mount it via /dev/pktcdvd/pktcdvd0 instead of /dev/hda
<pitti> right
<psusi> so I fixed the hal policy xml files to override block.device for cdrw media in that drive that has a udf filesystem on it
<psusi> so now it does correctly get automounted read/write... only it does not show up on the desktop... I'm thinking there's something wrong with gnome-vfs?
<pitti> how did you get pmount to mount /dev/pktcdvd/pktcdvd0 ?
<psusi> I used the hal policy xml files to change block.device on that hal object for the media to /dev/pktcdvd/pktcdvd0 instead of /dev/hda
<pitti> ah, heh, I see
<psusi> if I manually mount /dev/hda in /media/cdrecorder, it shows up on the desktop using the voluem lame as the name of the icon "LinuxUDF"
<psusi> if I use /dev/pktcdvd/pktcdvd0 instead, then it won't show up
<psusi> then I think before I went to bed last night, I found that if I manually mounted it with a certain combination of mount options via the packet interface, it DID show up on the desktop, but as "cdrecorder" instead of "LinuxUDF" and the icon would not go away when I manually unmounted the volume
<psusi> so it looks like something wonkey is going on in gnome-vfs right?  if so... can you sugest what code I should take a look at?
<pitti> hm, not off the top of my head
<pitti> I'd have to look into the drives exported by hal
<pitti> the pktcdvd devices appear automatically?
<psusi> I installed udftools and had to dpkg-reconfigure udftools and it set up /dev/pktcdvd/0 to connect to /dev/hda
<pitti> ah, I see
<pitti> so this mapping needs to be taken into account
<psusi> and it seems that udev creates /dev/pktcdvd/pktcdvd0 with cdrom as the owning gid
<pitti> that sounds fine
<psusi> taken into account in what way that I did not already?
<pitti> I think the main reason for not showing up is that hal does not have support for /dev/pktcdvd devices
<pitti> i. e. it does not export a 'block' device for them
<pitti> doing that would be the cleanest way IMHO
<pitti> there is certainly a way (ioctl) to find out to which actual device a pktcdvd device is attached to
<psusi> that sounds like it would be cleaner... but shouldn't my method work too?
<pitti> g-vfs relies on hal
<pitti> so, no
<psusi> hrm....
<pitti> instead of changing the /dev/hda entry, your fdi should create a new device
<pitti> not sure whether that is possible, though
<pitti> but figuring out the mapping is probably impossible in an fdi
<pitti> so hal needs proper support for them
<psusi> well, figuring out the mapping is easy, if a bit nieve...
<psusi> hal detects /dev/hda... and so it tries to mount it... the only thing that needs to change is when mounting, it needs to use the other block device in place of hda
<jbailey> SEJeff: ping
<pitti> psusi: I'm still surprised that your hack works at all - I didn't expect pmount to mount pktcdvd devices
<psusi> you don't really want to have a whole new hal device for the packet device
<psusi> pitti: ohh, I also had to add it to /etc/pmount.allow I think
<pitti> aah
<pitti> that makes sense then :)
<psusi> so it seems simple enough to me that the configure process for udftools could add the device to /etc/pmount.allow, and fix up the hal fdi to override block.device... and this does seem to correctly auto mount... except that gnome-vfs doesn't like it
<psusi> does this seem like a simple and sane way to go about modifying the udftools package to support automount?
<pitti> psusi: I'm a bit hesitant about changing /etc/pmount.allow automatically
<pitti> psusi: I'd rather add proper support for packet writing to pmount
<psusi> hrm... I can't remember now why that file even needed to be changed...
<psusi> ohh, I think it is because pmount could not find the sysfs node for pktcdvd0
<psusi> how do you think that pmount should go about properly supporting packet writing?
<pitti> allow to mount pktcdvd without a pmount.allow entry
<psusi> hrm....
<psusi> well, I guess yuo could make pmount somehow understand that when it is asked to mount /dev/hda, that it should instead use /dev/pktcdvd/pktcdvd0, is that what you mean?  rather than change hal so g-v-m tells pmount to mount /dev/pktcdvd/pktcdvd0?
<pitti> well, initially I just thougt about allowing to mount /dev/pktcdvd/
<psusi> you mean hard coding /dev/pktcdvd/* in the whitelist?
<pitti> not automatically figuring out the reverse mapping
<pitti> something like that
<pitti> these devices need to have some properties that make then unique
<pitti> s/then/them/
<psusi> what do you mean?
<ogra_ibook> and you'll need a very good worked out policy for hal to handle the dual usage of the device as well i guess
<ogra_ibook> cdrecord wont write an audiocd with a dev like /dev/pktcdvd/pktcdvd0
<pitti> for g-v-m you mean
<pitti> yep
<ogra_ibook> nope, for hal itself ...to report both usages ...
<pitti> this pktcdvd thingy is pretty hackish...
<ogra_ibook> yup
<pitti> yes, that's why I would prefer two devices
<pitti> in hal
<ogra_ibook> yup, sounds better ....
<ogra_ibook> but anyway, you need to do some decision what to do with an empty cd/dvd
<pitti> right
<pitti> hm, this is so ugly, don't expect it to happen in the next two weeks anyway :)
<ogra_ibook> heh
<psusi> hrm... but two devices in hal doesn't make sense because there aren't really two devices... there is only one... you don't want to try to mount both
<pitti> hm, but they are two different device nodes
<ogra_ibook> from a system POV they are different
<psusi> right... but one is purely virtual
<psusi> and should only be used when mounting read/write... entirely in place of the real device
* psusi steps out for lunch
<Lathiat> anywhere here actually use EVMS?
<Treenaks> Lathiat: I would, if I knew how to actually manage it without the ncurses tool puking at me
<erich^^> Can I setup a sarge pbuilder on an ubuntu system easily?
<Lathiat> Treenaks: well, the gtk gui is useless
<Lathiat> but i mean im about to setup a server im gonna be doing raid1 + lvm
<Lathiat> traditonaly i would do it myself but im wondering if EVMS is worth touching
<Lathiat> or if i want to avoid it :)
<Lathiat> erich^^: sure
<Lathiat> erich^^: just point it at the appropriate mirrors etc
<erich^^> okay. I wasn't expecting much trouble, and I would just have copied over a base.tgz from a sarge box otherwise. thanks.
<Lathiat> also does anyone have a nice solution for booting off a sw-raid1 where if the first disk dies you can still boot, short of rsyncing a /boot partition and keeping separate grub partitions on each one, like can i give grub a list of devices to try or something?
<erich^^> Lathiat: if grub will actually be able to detect the failed disc properly...
<tseng> a general rule of thumb is "dont put crazy software dependent layers on top of /boot"
<Lathiat> brb
<erich^^> Lathiat: I'd put two entries in the menu, and in the case of a failure have someone choose the other one...
<pitti> Lathiat: do you depend on grub?
<pitti> Lathiat: on my server with raid-1 I use lilo which does the job perfectly
<erich^^> One feature I'm really missing in grub though is a try-once option. Lilo can do that, try once to boot a certain kernel, then go back to the old default.
<pitti> Lathiat: I boot from the RAID, and keep both discs perfectly symmetrical
<pitti> Lathiat: i. e. I don't have a separate /boot
<erich^^> You could probably use that - make the secondary disk the default; boot once from the primary disk and make it set the primary as try-one on each boot.
<pitti> Lathiat: but even if you want to keep apart /boot, why not put it onto a raid partition as well?
<erich^^> pitti: he has it in raid-1
<pitti> oh, so where's the problem?
<erich^^> pitti: the question is how to make grub actually access the second disk.
<pitti> ah, I see
<erich^^> because your config will probably list (hd0,x), too...
<erich^^> But given the nature of bad disks, I don't think grub would be able to detect a bad disk automatically anyway...
<pitti> no idea then, I don't want to use grub on my server, and that's the only raid-1 machine I have
<erich^^> pitti: what are you using instead? did you try unplugging your primary disk to see if the system comes up okay?
<pitti> erich^^: I use lilo because of lilo -R
<pitti> erich^^: hda died twice on that system; I asked the guys in the DC to put hdc as hda, and insert a new hdc, that worked fine
<pitti> since /etc/lilo.conf and fstab only mention /dev/mdN, the discs are symmetic
<pitti> erich^^: I didn't try to *boot* from /dev/hdc; I don't have physical access to my server, it probably requires a BIOS setting
<erich^^> pitti: yeah, that is about as far as I got, too. that removing the bad drive and making the good one hda will work.
<pitti> booting from hdc is certainly a BIOS issue?
<pitti> I don't see what grub could do about it
<Lathiat> the bios could fall back
<Lathiat> the problem si if you just have a standard grub config pointing at sda
<Lathiat> it wont boot sd that doesnt exist
<pitti> well, lilo/grub should always be pointed to raid devices
<Lathiat> hrm ok i thought the way it worked
<Lathiat> it just read the 'raid1' by reading 1 disk
<Lathiat> hence not being able to read raid0 due to striping
<Lathiat> pitti: so, if you unplug your first disk, and the bios boots from it
<Lathiat> pitti: does lilo boot from it?
<pitti> Lathiat: I hope, but I don't know; as I said, this server is 800 km away from me in a DC
<pitti> so I can't try
<Lathiat> right
<Lathiat> well, mines sitting next to me, so i might try that with lilo & grub
<pitti> given that the BIOS boots from hdc, it should just work
<Lathiat> pitti: assuming lilo actually looks at hdc and not hda for the kernel image
<pitti> ideally it should look at all physical devices of the raid
<pitti> and maybe try all in succession
<Lathiat> ideally
<pitti> but I don't know that
<Lathiat> i'll try and let you know
<pitti> would be interesting, thank you
<Lathiat> atm on a box we have an ugly hack of a /boot being individual partitions on both drives
<Lathiat> and we rsync the kernel images accross and have different lilo configs on each
<pitti> that sucks, right
<Lathiat> (i didnt set that up)
<erich^^> pitti: I don't think grub can actually read raid. But it will be able to ignore the raid superblock and just access it as if it were a regular disk, I think. In raid1 that is.
<erich^^> But basically when you have a hardware failure and need to reboot, just replace the broken disk and swap them... it's not much more work...
<sivang> rehi all
<sivang> pitti: still here ? :)
<pitti> erich^^: no raid support in grub? that's a severe shortcoming, Id' say
<Lathiat> erich^^: its mroe work when you have to physically get to the machine
<Lathiat> erich^^: and yeh thats what i thought
<erich^^> pitti: well, given that you have 512 bytes...
<pitti> erich^^: grub has way more :)
<Lathiat> pitti: which.. it loads off the disk? :)
<erich^^> pitti: these 512 bytes need to contain enough code to find the rest of grub - if you put that data on a non-linear storage, good luck
<Lathiat> which... would need raid? :)
<pitti> Lathiat: *brown paperbag*
<Lathiat> on my head or yours? ;p
<pitti> mine of course :)
<Lathiat> but yeh, i guess thats why hardware raid is still usefull :)
<erich^^> grub could probably have raid support to load kernels and such, as long as you give it some extra k of storage to find its data... thats why it's not uncommon to have a non-raid partition on the disks then.
<erich^^> Lathiat: well, just having a 16k solid-state-disk (like the flash chip of a hardware raid card) would probably do the trick just fine...
<psusi> yea... you should just mirror the entire drive... normally the bios and grub will only use the first one, but that's ok... if the first one fails, unplug it and the second one should boot fine
<Lathiat> psusi: youd have to put the second one onto the same slot as the first, tho
<erich^^> But using raid-1 for /boot isn't really a problem, is it?
<erich^^> you could probably modify grub to fail back to the secondary drive...
<Lathiat> erich^^: its a problem in that, if the first disk dies, it wont boot because the grub/lilo config points at the first disk being hd(0,0) nto hd(0,1), which isnt there 
<erich^^> but it won't help when the primary drive is completely dead unless your bios is smart enough...
<Lathiat> yeh i suspect you may be able to squeeze that into the first part of grub... maybe.
<Lathiat> erich^^: yeh
<psusi> grub will access whichever disk it is on... if it is on both because they are mirroed, then it's up to the bios which disk it boots
<Q-FUNK> elmo: could you sync rus-ispell with unstable, please? thanks!
<erich^^> psusi: yeah, but what if the first sector of the first drive is fine, the rest is trashed?
<psusi> then you would need to yank it out :)
<psusi> or configure the bios to boot from the other drive
<Lathiat> what drive you boot from is not the problem
<erich^^> yeah, or have a grub in the first sector that will fail over.
<erich^^> still, hard to do in 512 bytes I guess.
<erich^^> But this basically applies to any stage of grub... stage_1 can be readable when stage_2 is broken...
<erich^^> but it gets less helpful with each...
<psusi> I'd say impossible... you don't even have 512 bytes for code... some of that is the partition table...
<psusi> I've modified boot sector code before... it is TIGHT
<erich^^> I'm not sure it's worth the hassle.
<psusi> basically if parts of the disk that contain any part of grub are broke, you're going to need to yank the disk and rely on the other one
<Lathiat> erich^^: probably not :)
<Lathiat> psusi: that still brings up the issue of grub then looking at the second disk and not the first can it do that now?
<Lathiat> (without having a second separate config)
<psusi> you just configure grub to load from the first disk... if the first disk fails, yank it out and the second becomes the first
<Lathiat> no it doesnt
<Lathiat> well, depends what kind of drives they are
<dilinger> bypass the problem entirely.  boot from a usb memory stick :p
<Lathiat> dilinger: :)
<psusi> if you remove whatever drive is bios disk 80, then bios disk 81 should become bios disk 80
<Lathiat> psusi: mm well i'll have to try it
<psusi> or in modern bioses you can usually tell them to boot a drive other than 80
<psusi> though I'm not sure if they just load the mbr from the other drive, or if they remap the other drive to 80
<psusi> if it does not remap... then the MBR would still try to load the stage 1.5/2 loader from the bad disk
<Lathiat> heres a Q, why is there a stage 1.5 and then 2?
<psusi> stage 1.5 is optional... stage2 can be built to understand several filesystems... that can make it too large to fit in the 62 sectors that are usually free between the MBR and the first partition
<psusi> so you can use a stage 1.5 loader that fits there because it only udnerstands the one filesystem that holds the stage 2 loader
<Lathiat> ah
<Treenaks> OpenFirmware yay :)
<Lathiat> i toyed with a xeon server at work with this cracky EFI thing
<Lathiat> which is terribly slow
<Lathiat> and apparently not very usefull
<erich^^> psusi: still, the bios needs to detect the drive being broken. and you currently might need different grub config files on both disks for grub to access the right one (I mean, you could install grub on the first drive, and have your kernel on the second; but you don't want that in this case...) - so you'll need different /boot dirs on both disks. Which then makes renumbering them bad... :-(
<erich^^> anyway. see ya
<Lathiat> bye, thanks for the talk :)
<Lathiat> sounds like what im doing now might be the way to go :)
<psusi> erich^^: you don't want a seperate /boot on each drive is the point
<Lathiat> psusi: but you might have to, being the point :)
<Lathiat> as sucky as that is
<psusi> I don't see what that actually buys you
<erich^^> psusi: yeah, but that will only work if you plug the good drive back in as primary; not if you replace the broken primary and keep the second second.
<Lathiat> being able to get a gimp to reset a machine and get it up with a disk dead without shuffling disks around inside a case without hotswap bays
<psusi> erich^^: if the bios can only boot from the primary, then it won't work even if you have a seperate /boot
<psusi> if it can boot from the secondary, then it should work without a seperate /boot
<erich^^> psusi: on scsi it probably can boot from the secondary; and with a IP-KVM you might even be able to do that remotely.
<psusi> erich^^: exactly... and once it boots from the secondary drive, you don't need it to have a seperate /boot because the secondary drive BECOMES bios disk 80, which is where grub will load the kernel from
<Lathiat> psusi: mm, i have to try that
<Lathiat> will do soon
<psusi> grub is configured to access bios disk 80... if you boot from the primary drive, that is disk 80.. if you boot from the secondary, that becomes disk 80... so either way, the same grub config will read the kernel from whichever disk you boot from
<psusi> in fact... if you do use two seperate grub configs, it WON'T work if the primary fails
<psusi> because when you install grub, if you configure the one on the second disk to load the kernel from /dev/sdb, grub will think that is bios disk 81
<psusi> but if you try to have the bios boot from the second disk, grub will be trying disk 81 but it won't be there, it will be disk 80 instead
<robertj> i've been thinking about the best way to handle mounting an smb share as /home and from what I can tell setting smbmount and smbumount suid root and writing ~/.pam_mount.conf before loading pam_mount seems to be the best way, any other ideas?
<robertj> I can
<robertj> er I can't think of a way that could be done without having an upgrade trounce all over it
<psusi> what's wrong with just adding the mounts to /etc/fstab?
<robertj> psusi: I want to manage it at login time through a directory
<psusi> what do you mean?  manage it through a directory?
<robertj> psusi: I want to specify per-user & per-group mounts
<robertj> so those could be written to ~/.pam_mount.conf after checking with ldap
<psusi> ohh... you mean like mount differntly dependong on who logs in?
<robertj> yup
<psusi> add them all to fstab with the noauto and user options... then when the user logs in, then can mount it
<robertj> and also it's just not good to have 900 users in /home on a desktop IMO
<psusi> the one that they want that is... 
<psusi> ohh, you want users to be able to have their home directories on the network?
<robertj> yes
<psusi> hrm... why not use nfs and mount all of /home on a server then?
<robertj> psusi: well smb is the destination of choice for me and like I said, I don't like users navigating through 900 entries in /home
<tseng> psusi: because windows doesnt speak nfs
<robertj> but with pam_mount the sky is the limit and you can even use fuse mounts
<robertj> so it's just a more granular way of controlling things
<psusi> well, usually users don't look in /home, they just worry about their own home dir...  but yea... that's a problem with smb since the entire mount uses the same credentials
<robertj> psusi: which means also that you have to mount it as root
<psusi> though actually, windows does support NFS I believe... MS has a package called services for unix
<robertj> which means if you get rooted...
<psusi> ohh... yea... there is a facility in pam to mount isn't there?  so what's the problem then?
<robertj> psusi: yeah, MS even supports hosting an Appletalk printer on NT4, they have all kinds of things no one knows about
<robertj> psusi: well all the mounting programs used would need to be suid root
<robertj> or use fuse which I haven't used alot
<psusi> why would they need suid root?  the login program invoking pam is running as root
<robertj> ahh
<robertj> lemme try that then
<psusi> so pam should be able to invoke mount as root... and mount is already suid root anyhow ;)
<robertj> psusi: hrmmm
<robertj> http://paste.ubuntu-nl.org/6337
<robertj> apparently its not
<robertj> or...
<psusi> well login definately runs as root, so unless pam drops root privs before getting to the stuff you're adding, you should be root ;)
<robertj> apparently it is
<robertj> ls
<robertj> doh ;)
<a_monkey> I got some problem booting the install of ubuntu on my laptop
<a_monkey> ive been told the bootcommand is "linux apic=off noacpi"
<a_monkey> but, still it wont detect my CD-ROM after langage-settings 
<Burgwork> a_monkey, please use #ubuntu, as this is not a support channel
<a_monkey> arright
<a_monkey> this was listed as the "laptop team" so... sorry
<Burgwork> a_monkey, #ubuntu-laptop
<a_monkey> thank you
<ryanpg> pitti, hi bug 20564 is marked RESOLVED but I'm still experiencing it, should I reopen?
<pitti> ryanpg: yes, sure
<ryanpg> k
<pitti> ryanpg: so your device permissions are still wrong?
<ryanpg> pitti, sorry I forgot the details but they're currently brw-r----- 1 root plugdev 8, 3 2005-12-29 16:09 /dev/sda3
<ryanpg> pitti, does permission still appear to be the issue? (I'm not sure what they should be) should I click "commit" ;)
<pitti> ryanpg: wait
<ryanpg> k
<pitti> ryanpg: ok, the permissions seem fine now
<pitti> ryanpg: well, just commit your current comment
<pitti> ryanpg: can you please do the https://wiki.ubuntu.com/DebuggingRemovableDevices steps again?
<ryanpg> pitti, sure should I attach output in a single file or seperate?
<pitti> ryanpg: the big ones in separate files, please
<ryanpg> doing so now
<pitti> the small stuff (mount output, etc.) just as a paste
<pitti> thank you
<ryanpg> and only the relevant end part of dmesg needed yes?
<pitti> right
<pitti> good night everybody
<tseng> bye pitti 
#ubuntu-devel 2006-01-04
<robertj> hrmm, well I have ended up having a degree of success with pam-script + pam-mount
<robertj> net result is user foo can log in and have their directory mounted on the fly on a per-user basis
<Viper550> Hello! Guess what, I have an idea for StreamlinedBoot!
<mjg59> Viper550: Shoot
* robertj commences the drum-roll
<Viper550> Okay, you want Usplash to display the bootup tasks by groups right?
* robertj thought all the non-error text was going to go away
<Viper550> I've done some additions to the wiki page /StreamlinedBoot detailing my idea. I'm a end user kinda, but I think I know the way to do this!
* psusi just wishes he could find a way to make readahead-list work better... as in be able to read from the disk with more than 10-25% of it's maximum throughput
<Burgwork> Viper550, can I move https://wiki.ubuntu.com/gfxboot-theme-ubuntu to https://wiki.ubuntu.com/GfxbootTheme ?
<mjg59> Viper550: Hmm. The flashing thing?
<Viper550> yes
<Viper550> yes for both!
<mjg59> Viper550: Interesting
<Viper550> Also, look under Implementation
<Burgwork> Viper550, and can we move all these things under Artwork?
<mjg59> Viper550: I've no idea what the plan is, but it's easy to implement that in uslash :)
<Viper550> yes!
<Viper550> Oh yeah, I'm yalking Streamlined Boot here, artwork related requests for me should me in ubuntu-meeting
<mjg59> Scott will be back from holday next week, so I'll chat to him then?
<Viper550> Ojay!
<Viper550> I meant Okay
<Burgwork> Viper550, https://wiki.ubuntu.com/Artwork/MetacityTheme
<Burgwork> Viper550, https://wiki.ubuntu.com/Artwork/GfxbootTheme
<Viper550> T and Y!
<Viper550> p.s. Happy New Year in 2 days...
<Burgwork> Viper550, can you make certain you create any more artwork pages under Artwork?
<Viper550> Okay, I already pledged that in meeting
<Burgwork> Viper550, thanks
<Viper550> You are welcome, now on StreamlinedBoot, check out my idea Burgwork!
<jdub> Burgwork: ber, unnecessary structure in a wiki
<Viper550> So, is my idea feasable or doable?
<jdub> Viper550: keep in mind that canonical is sponsoring the default desktop artwork in dapper again
<Viper550> Oh great, but the Universe idea is a good idea
<tseng> jdub: does it have naked hunnies?
<Viper550> No, they discontinued ubuntu-calendar
<Burgwork> jdub, which page?
<Burgwork> jdub, you talking the specs moving the artwork stuff?
<jdub> Burgwork: always putting everything in subpages
<Burgwork> jdub, not always, just for things that should be logically grouped together, such as artwork discussion or testing
<jdub> Burgwork: "logically grouped" doesn't always imply "requires a separate namespace"
<Burgwork> jdub, yes, I agree with you. we are just disagreeing about when
<Burgwork> jdub, recent changes is getting hard to parse quickly. Namespaces allow that
<Viper550> So, does anyone still like my StreamlinedBoot idea?
<Burgwork> Viper550, I like the idea, but am not certain about blinking the words or the number of words
<Burgwork> jdub, on happier notes: https://wiki.ubuntu.com/EasyWaysToHelpUbuntu
<Viper550> But, that's what the KDE splash does!
<Viper550> Also, the GIF was an example only!
<Burgwork> Viper550, yes, it was a cool first mockup
<Viper550> Yep, but it's the coding ideas that are the stars here!
* Viper550 begins trying to compile Openbox
<Viper550> Come on configure.........
<Viper550> YEAH! Lets make a make!
<Viper550> never mind, failed already (goes to packages.ubuntu.com
<Viper550> Reading Database...
<Viper550> Unpacking, setting up
<Viper550> There, done!
<crimsun_> elmo: please sync qtparted, mysql++, nss-mdns, and mplayerplug-in from Sid (ok to override Ubuntu changes), thanks.
<mjg59> crimsun_: He's not back from holiday yet, so it might be an idea to mail him
<psusi> damn... I'm so confused... I did apt-get source gnome-volume-manager... now let's say I fix the source... what do I want to do to build it into a package I can install and test?  dpkg-buildpkg?  and then assuming it works, how do I get the changes into dapper?
<psusi> I'm used to just ./configure, make, make install... then when it works, diff and email... but I"m trying to figure out the "right" way
<crimsun_> psusi: generate a debdiff and attach it to the bugzilla bug report
<crimsun_> mjg59: right, thanks.
<psusi> how do you do that? 
<crimsun_> psusi: /j -motu
<psusi> ahh... ok...
<psusi> anyone know what sets the is_mounted hal attribute?  is it g-v-m, pmount, or hald itself?
<crimsun_> I would hope the last.
<crimsun_> (presuming of course that hald has any concept of mounted devices)
<psusi> how would it know when mounts change, and so it should take a look at mtmp again?
<crimsun_> have you asked in #freedesktop ?
<psusi> hrm... good idea...
<FireRabbit> hey folks, is there an (up to date) doc somewhere that explains the entire hardware detection process (all the way to where it actually loads the module)?
<Amaranth> FireRabbit: you'd want to look into udev and hal
<FireRabbit> hmm, any suggestions of files/directoies i should poke around in?
<desrt> FireRabbit; new device gets plugged in
<desrt> FireRabbit; kernel generates an event on a netlink socket
<desrt> FireRabbit; udevd is listening
<desrt> FireRabbit; udevd invokes modprobe (possibly indirectly)
<desrt> FireRabbit; modprobe looks at its config in /etc/modprobe.d/ to resolve aliases and figure out options
<desrt> FireRabbit; modprobe calls insmod with the appropriate info
<desrt> FireRabbit; insmod loads the module
<Amaranth> does it modprobe every driver possible until it finds one that wants the device?
<desrt> Amaranth; no.  there is a list of which module belongs to which USB(for example) vendor/product codes
<FireRabbit> desrt, where is this list?
<Amaranth> i thought the list was in the driver
<desrt> it is
<desrt> it gets pulled out by modutils
<desrt> and stored in /lib/modules/`uname -r`
<Amaranth> ah
<desrt> see modules.___map
<FireRabbit> those modules.* files?
<desrt> yes
<FireRabbit> okay... good to know .. thanks... so does udev read these map files or modprobe?
<desrt> i don't know
<FireRabbit> hmm
<desrt> i suspect it's modprobe though
<FireRabbit> i would think udevd, since 'modprobe' wants the name of the module
<desrt> no.  modprobe has a reasonably sophisticated alias-resolution system
<desrt> you can probably say something like modprobe usb-id-1234-5678
<desrt> and it will DTRT
<FireRabbit> oh
<desrt> i don't know the exact syntax
<FireRabbit> DTRT=?
<desrt> 'do the right thing'
<Amaranth> do the right thing
<FireRabbit> oh
<FireRabbit> anyone else know the answer.... ?
<desrt> FireRabbit; do some investigation on your own.  you have the source to the entire operating system.  absolutely nothing is stopping you
<desrt> FireRabbit; you also have google
<FireRabbit> heh.. yeah, alright i'll poke around
<FireRabbit> it's confusing because i know that a lot of hotplug stuff changed in dapper.. dunno what is current and what isn't
<spstarr_home> is bugzilla broken? i cant submit a bug missing fields, but page doesnt render to show me the fields(?)
<sivang> morning al
<Treenaks> sabdfl made cnn again: http://www.cnn.com/2005/TECH/space/12/29/space.travel.ap/index.html
<Treenaks> (or at least, a picture of him)
<zakame> w00t
<sivang> Yep, that's our Mark - always on the news :)
<teuf> hi
<siretart> is someone else encountering problems with archive.ubuntu.com? the mysterious 'file not found' errors vanished when switching to my country mirror
<janimo> elmo, please sync/override xfce4-battery-plugin xfce4-fsguard-plugin. thank you
<janimo> elmo, also, canonical RT issue #1215, thank you. And a happy new year.
<HiddenWolf> janimo, lol
<HiddenWolf> "elmo, fix my problems, then you can have new year" ;)
<janimo> they're orthogonal :)
<janimo> happy new year all even if you don;t fix any of my probs.
<janimo> bye
<slomo> elmo: please sync pygame, meta-gnome2, gazpacho from debian/unstable... ubuntu changes can be dropped
<zakame> elmo: please sync libfwbuilder from Debian Sid, overriding Ubuntu changes ok.  Thanks :D
<elmo> libfwbuilder |  2.0.9-3.1 | dapper/universe | source
<zakame> ooh, it was already there since the 6th, my bad :( sorry then
<fabbione> siretart: i am getting rsync to hang on one of the archive.u.c so it might be a problem with one of them
<fabbione> siretart: btw.. igor has a bad memory module.
<fabbione> siretart: dmesg is full of ECC correction
<siretart> fabbione: thanks for notice, I'll see what I can do
<fabbione> siretart: and it makes a bunch of pkgs to fail to build when they suck up all mem
<fabbione> siretart: let me know when and if you are taking it down
<siretart> will do
<fabbione> so that i can stop the buildd in time
<siretart> the thing is that I will be skiing next week
<Simira> fabbione :) Merry Christmas and all that stuff
<fabbione> Simira: same to you :)
<fabbione> siretart: no problem.. it might have been doing for a while.
<siretart> fabbione: I have to ask Joerg what kind of memory it needs and look for a replacement
<siretart> but up to now I think it has been doing a quite good job, the poor old igor :)
<fabbione> siretart: ok, no rush :)
<fabbione> siretart: oh i agree :)
<siretart> fabbione: will be igor any good when soyuz goes life? do you have any news on that topic?
<fabbione> siretart: i hope that when soyuz will go online, there will be sparc buildd at the datacenter
<fabbione> siretart: and we can turn igor into a test install bitch^Wmachine
<siretart> fabbione: sounds good!
<psusi> fabbione: hey... have you had a chance ( or will you sometime in the near future ) to look at the initramfs scripts I added to the dmraid bug?  Think they might get moved into the dmraid package and the package mvoed to main in time for dapper?
<jbailey> Simira: I had a crazy dream last night that you told Tollef to phone me up and yell at me.
<jbailey> Simira: And he phoned me and asked for something to make him angry so that he could yell at me - you hadn't given him a reason.
<Treenaks> LOL
<Simira> jbailey : what did you do now?
<Simira> jbailey : and what's your phone number?
<mjg59> jbailey: Dude, I can't install 2.4 kernels because mkinitramfs bitches and doesn't fall back
<jbailey> Simira: No idea. =)
<jbailey> mjg59: In Ubuntu?
<mjg59> jbailey: Yeah
* Mez gets scared at jbailey
<Mez> jbailey, you're name isnt John is it ?
<jbailey> mjg59: On all arches aside from i386, glibc is tweaked to to die if it tries to run on a pre-2.6 kernel.  i386 will get the same love post dapper.
<mjg59> jbailey: Uhm. So we're not 2.4 compatible?
<jbailey> mjg59: Nope.  2.4 has never been a supported target for Ubuntu since Warty.
<mjg59> jbailey: The packages should possibly be pulled from the archive, then :)
<jbailey> Although until Breezy, it would generally work.  In breezy I think it generally wouldn't work and in dapper +1 I promise that it won't. =)
<jbailey> *lol*  Yeah probably. =0
<jbailey> All of Dapper's hotplug/udev/initramfs-tools love needs at least 2.6.12, too.
<mjg59> Mm.
<robertj> what's the background info on pam management & authconfig? I imagine authconfig was rejected for not being complete enough and not using gst?
<Simira> jbailey : about your phone number?
<mjg59> Well, let's see what happens when I reboot now...
<jbailey> Simira: Eh?  =)
<Simira> 0:)
<jbailey> Simira: Your beau already has it..  Perhaps he can take a look at your evil grin and decide if it's safe to give it to you or not.. =)
<psusi> dapper is due out in feb right?
<psusi> err...
<psusi> no...
<psusi> did the math wrong... april
<Simira> jbailey : hehe, yeah. I'll just wish you happy new year or something.
<Mez> Hmm - anyone here able to help me find out why I'm not getting katie output
<fabbione> psusi: no, i didn't look at dmraid in a while, didn't see new upstream releaes and it seems to be broken in dapper (at least it is for me)
<fabbione> psusi: given how fast it breaks i doubt i am going to push it in main for now
* fabbione heads offline
<psusi> fabbione: it breaks?
<psusi> works great for me and about 3 other people who have emailed me
<Mez> jdub: ping
<thesaltydog> any chance to get baobab and/or bum in main?
* Mithrandir ruffles jbailey
<jbailey> Mithrandir: =)
<Robot101> wtf, gajim in dapper depends on dnspython which is gone
<fabbione> psusi: it breaks for me. i didn't say your scripts are broken. it's a devmapper issue in my case
<psusi> hrm... maybe I can help you figure out what's wrong?
<fabbione> psusi: dmraid doesn't see the disks anymore. a dmraid scan reports no disks available.
<fabbione> can be anything.. 
<fabbione> from the kernel to udev
<psusi> what are the symptoms?
<fabbione> psusi: dmraid doesn't see the disks anymore. a dmraid scan reports no disks available.
<fabbione> so it can't activate disks that it can't see
<psusi> hrm... do you actually have the disks set up for dmraid?  i.e. configured in the bios?  or did you just partition the disks with mdraid?
<psusi> I assume the former, but thought I'd make sure
<psusi> hrm... which controller do you have again?  via?
<fabbione> psusi: yes, .12 sees them. it's a via.
<fabbione> anyway time for dinner and shower
<fabbione> it's a low priority problem for me anyway
<fabbione> there are no data on those disks
<psusi> weird... changing kernel is what breaks it?
<fabbione> yes i told you, but there can be different reasons for that
<fabbione> the driver doesn't see the disks
<fabbione> udev doesn't create the devices
<fabbione> etc.
<fabbione> now.. i am off for real :)
<Mez> hmm
<fabbione> it's my last day of vac
* fabbione &
<Mez> how annoying would it be if someone accidentally managed to upload a package to the buidds which just kept calling itself :D
<Mez> lol
* Mez just made one of those packages by accident
<Mez> luckily it's nothing I plan to upload anywhere
<psusi> udev doesn't create the devices for the underlying physical disks?  that would be a problem outside the scope of dmraid ;)
<bddebian> Hello
<ryanpg> hi again pitti, do you need anything else for bug 20564? it's the last day of my vacation so I'm willing to help if I can :)
<pitti> ryanpg: I'm a bit puzzled
<pitti> ryanpg: what does 'id hal' say?
<pitti> oh, forget that if usb mounting works
<pitti> ryanpg: I just replied to the bug, I need a ful hal debug output
<pitti> ryanpg: as described on DebuggingRemovableDevices
<ryanpg> pitti, hrm... I didn't think I truncated the hal ouput
<pitti> ryanpg: I didn't suspect you to :)
<ryanpg> pitti, well I'll do it again right now :)
<pitti> somehow hal does not see the firewire device partitions; it sees the device itself, though
<pitti> ryanpg: 'again'?
<ryanpg> I thought above you were asking for me to redo DebuggingRemovableDevices to provide " a ful hal debug output"
<pitti> ryanpg: no, it's described on the second half of the page
<ryanpg> oh oh ok... yeah I get it sorry
<pitti> ryanpg: hald --verbose=yes --daemon=no etc.
<ryanpg> right doing so now
<ryanpg> I guess I should follow the breezy part in step 3
<ryanpg> pitti, ok it's attached
<ryanpg> this line seems to say a lot "13:27:53.578 [I]  blockdev.c:602: Ignoring hotplug event - no parent"
<pitti> ryanpg: hm, it doesn't look too bad, odd
<pitti> ryanpg: thanks for the log
<ryanpg> pitti, np
<ryanpg> hope there's not much more testing to do, I just tripped over the cable and threw the firewire drive on the floor! :P
<pitti> ryanpg: there is no such warning for sda
<dooglus> "locate" is dumping core for me.  how would I go about building a debuggable version?
<pitti> ryanpg: do you get an lshal entry for sda now?
<ryanpg>  lshal | grep sda returns nothing
<ryanpg> ok after another disconnect and reconnect I get   linux.device_file = '/dev/sda1'  (string)
<ryanpg> pitti, sorry I also did pmount /dev/sda3
<pitti> ok, the 'Ignoring hotplug event - no parent' causes the device not to be added to the db
<mjg59> Did anyone download the Debs of those conexant drivers?
<pitti> ryanpg: I'm puzzled about that; I'll ask upstream about it
<ryanpg> pitti, ok... I also wonder what's unique about my setup... no one else has commented on the bug
<pitti> ryanpg: did it work in breezy?
<ryanpg> pitti, yes
<ryanpg> a general question: what's the average lag-time between a package appearing on dapper-changes list and ending up in the repos?
<pitti> ryanpg: that depends on how fast it is built
<pitti> or if it is built at all
<ryanpg> pitti, ic
<ryanpg> I had assumed it was automated and everything on dapper-changes was built in order
<ryanpg> pitti, thanks for working on this udev issue, I'm sure you'll update the bug if you need more info
<pitti> yes, I will
<pitti> it's a hal issue now :)
<ryanpg> uh oh :)
<lucasvo> http://pastebin.com/483986 < my nautilus isn't working anymore
<lucasvo> anyone know what's wrong?
<lucasvo> it doesn't seem to be a problem of the user
<ryanpg> lucasvo, you may want to try #ubuntu this isn't a support channel
<lucasvo> ryanpg: as I said, it doesn't seem to be a problem of the user... 
<kikidonk> hello ! is it normal that eclipse in dapper/universe is broken ?
<kikidonk> eclipse-jdt and eclipse-jdt-common depend on each other
<kikidonk> making impossible to install anything depending on these two (eclipse-sdk and co)
<Robot101> why does ubuntu turn on per-tty tickets for sudo?
#ubuntu-devel 2006-01-05
<pkern> How's living on the bleeding edge currently? Is Dapper broken or at least barely usable?
<Burgwork> pkern, not bad
<Pygi> pkern: rather barely usable, then completely broken :)
<pkern> Hm. Why isn't linux-image-2.6.15-10-k7 installable. Was that uploaded today?
<Burgwork> pkern, file a bug on it. this is not a support channel
<pkern> Burgwork: Sorry.
<tepsipakki> not built yet, i believe
<pkern> tepsipakki: Oki. The package lists are already updated, though. So linux-image-k7 refers to it. ;) I'll just wait.
<jdthood> Anyone have any clue as to why /proc/1/environ contains no PATH setting?
<zul> environment variables?
<mjr> because it hasn't inherited any?
<rob1> does anyone know why the glade-gnome package is missing dependencies?
<rob1> in breezy
<dereks_> who do i talk to about sbackup?
<jdthood> zul, mjr: I think that the reason is that the init program in the initrd doesn't set PATH.
<Burgwork> dereks_, sivang 
<dereks_> Burgwork: thanks
<dereks_> sivang: ping
<Burgwork> dereks_, he lives in Israel, so it is early early morning there
<dereks_> Burgwork: ok 
<dereks_> thanks
<Bonzodog> Hi guys, anyone awake
<Bonzodog> ?
<Bonzodog> have a querie about 64 bit build
<Bonzodog> was talking to devels in gnustep, and they have said that the sid64 tree has been altered to remove /lib32
<Bonzodog> so has that alteration made it into dapper?
<pef> hello
<desrt> good morning
* Mez pokes desrt 
<pef> mm flight-2 installer neither find my cd-rom nor my first hard drive, what should I provide in my bgu report ? dmesg output ? /var/log/syslog ?
<Lathiat> pef: did it work in breezy or flight 1?
<pef> Lathiat: yes, I installed breezy without problems
<Lathiat> pef: if so please find the driver its missing then include relevant lspci output and see if a manual modprobe gets it goign to see if its a detection or driver support issue
<pef> Lathiat: when I got prompt to enter drive path, I put /dev/hdfoo and it works
<Lathiat> like the device comes up
<Lathiat> flight2 just doesnt see it
<Lathiat> ?
<pef> after "uncompressing the kernel..." I got "hde: ERROR , PORTS ALREADY IN USE"
<pef> Lathiat: yes
<Lathiat> mm interesting
<Lathiat> just include as much info then like lspci/dmesg and that info
<Lathiat> also cat /proc/partitions
<pef> should I have to test with flight 1 too ?
<Lathiat> may be usefull to include relevant dmesg parts from flight1, tho i dunno
<Lathiat> i'd file all above info
<Lathiat> may get asked more?
<pef> I will try with flight1 too
<pef> Lathiat: I can send you dmesg right now, I had to download isos and this can get a few minutes :)
<Lathiat> pef: dont bother sending it to me :)
<Lathiat> i wouldnt be much good with it :P)
<Lathiat> just file a bugzilla report?
<pef> of course :)
<pef> in dmesg output I have a "ide2: i/o ressource not free", arg
<sivang> dereks_: pong
* Mez writes a script that makes a new window for "ping"s
<sivang> dereks_: I think you already tried to ping me, please email me so we won't miss each other next time , I'm sivan __AT__ ubuntu DOT com
<sivang> Burgwork: ping
<Mez> hmm - does anyone here use scott's signkey.pl?
<sivang> Mez: I use Kinnison's scripts.
<Mez> sivang as long as you dont use dsilvers :D
<Mez> lol
<sivang> hehe
* Mez has no idea what was going on with them
<sivang> Mez: well, I guess having him around me when I installed and configured them helped :)
<Mez> lol
* Mez woulda had no idea what to do
<pef> Lathiat: http://bugzilla.ubuntu.com/show_bug.cgi?id=21707 I hope I haven't missed something
<Lathiat> pef: looks good
<thesaltydog> I can't find any clear documentation to help myself in understanding how "launchpad-integration" works on Help Menus...
<tseng> sivang: ^ can you give him a hint? :)
<thesaltydog> tseng,  found. liblaunchpad-integration!
<tseng> heh yes
<slomo_> elmo: please sync pygame, meta-gnome2, gazpacho from debian/unstable, service-discovery-applet, gnome-user-share, ipod-sharp, libipoddevice from debian/experimental... ubuntu changes can be dropped
<tseng> elmo: will lighttpd be pulled into ubuntu automatically? new in debian unstable
<Lathiat> gah locales is screwing up again
<BrianB04> Heylo all
<fabbione> elmo: if you have time and you are working, network-console source is in main/Sources.gz, but the files are still in universe = FTBFS
<thesaltydog> Could anyone  make an evaluation of baobab and bum for a possible inclusion in main?
<Bonzodog> Is there anyone here dealing with the 64 bit version of Dapper?
<sivang> TheMuso: hi, are you sorted with LPI ?
<mjg59> pitti: My mmc card (appears as /dev/mmcblk0p1) doesn't appear to automount
<Treenaks> why does it appear as that?
<mjg59> Because it's an mmc card
<Treenaks> mjg59: my MMC cards show up as /dev/sd[a-z] 
<Treenaks> or is this a special controller?
<Lathiat> depends on the driver i guezz
<Bonzodog> i'm curious...anyone here running Dapper 64?
<Treenaks> Bonzodog: I am, at work
<Lathiat> not i
<Bonzodog> doe sit have a /lib32 dir?
<Treenaks> Bonzodog: I can't reach my work machine from here :)
<Lathiat> Treenaks: heh i vpned my work machine to home over port 443 with openvpn :)
<Treenaks> Lathiat: oh I could do some tricks (it's running sshd, I can reach a server from which I can ssh to it)
<Treenaks> but I can't be arsed :)
<Lathiat> heh
<Bonzodog> hrm..acording to a debian devel I spoke to the sid 64 lib setup has changed
<Bonzodog> currently, breezy has 3 lib dirs
<mjg59> Treenaks: That's because yours are appearing as usb mass storage
<Bonzodog> /usr/lib, /usr/lib32, /usr/lib64
<Treenaks> mjg59: yeah, and my crappy TI slots don't work
<Bonzodog> but apparantley, the /lib32 dir is no longer in the sid tree, so debian now conforms to the standard
<mjg59> Treenaks: Should do soon
<mjg59> (The SD/MMC, at least)
<Bonzodog> all 32 bit libs go in /usr/lib
<Bonzodog> and all 64 bit libs go in /usr/lib64
<jsgotangco> happy new year guys
<Treenaks> mjg59: wow.. I was told it wouldn't be possible for the forseeable future
<Bonzodog> but would it be possible to alter dapper like that at this stage?
<mjg59> Treenaks: Hmm. Actually, that depends. As long as it's a *21 part rather than a *20
<Treenaks> mjg59: lspci will tell me?
<mjg59> Bonzodog: Ubuntu is working closely with Debian on making amd64 sane
<mjg59> Treenaks: Yeah
<Treenaks> 0000:02:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
<Bonzodog> yeah, cause I'm working on GNUStep development
<Bonzodog> and ubuntu 64's current setup is causing big problems
<mjg59> Bonzodog: Mithrandir is probably the person to talk to about this, but he's still on holiday
<Bonzodog> hrm..will ask again soon
<Bonzodog> when he's back
<\sh> moins gentlemen
<mjg59> Next week, probably
<Mithrandir> Bonzodog: hmm?
<mjg59> Oh, right
<Bonzodog> look above
<Bonzodog> dapper64; has it removed /lib32?
<Mithrandir> Bonzodog: no, not if you install ia32-libs.
<Bonzodog> hrm
<Bonzodog> see, that is causing probs trying to build sane gnustep appas
<Bonzodog> in 64 bit
<Mithrandir> Bonzodog: why do you care about 32 bit stuff if you're on amd64 and working on gnustep?  That's free software, so just use lib.
<Bonzodog> beacuse there is quite a bit of work to be done in gnustep-core
<Bonzodog> to make it 64 bit usable
<Mithrandir> Bonzodog: debian uses /emul/ia32-linux, iirc.
<Bonzodog> so it still relies on seeing 32 bit libs in /usr/lib
<mjg59> Gnustep isn't 64-bit clean?
<Bonzodog> not yet
<mjg59> That's, uhm, neat.
<Bonzodog> it's being worked on
<mjg59> I don't think it's reasonable for software to assume that /usr/lib contains 32-bit libraries
<Mithrandir> Bonzodog: anyway, Debian has 64 bit stuff in /usr/lib on amd64.
<mjg59> It's untrue for several architectures
<Mithrandir> Bonzodog: why do you care where libraries are, btw?
<Bonzodog> someone in gnustep I was talking to yesterday reckoned the sid tree had been changed to so that it met 'standards'
<Bonzodog> where by there is only 2 lib dirs
<Bonzodog> I need the lib dirs in the correct place to build the gnustep core
<Mithrandir> Bonzodog: there's no standard for what goes into which library directory, apart from /lib/ld-linux.so.2 containing the 32 bit dynamic linker and /lib64/ld-linux-x86-64.so.2 being the 64 bit one.
<Mithrandir> why?
<Mithrandir> just use the dynamic linker.
<zul> hey BenC 
<Bonzodog> see, at current, /lib64 is symlink of /lib
<Mithrandir> Bonzodog: yes
<Bonzodog> the thing is I need to run a script that automatically looks in lib for ia-32 bit libs
<Bonzodog> I could alter the script
<Mithrandir> Bonzodog: again, why do you care?
<Bonzodog> because gnustep core will not build
<Mithrandir> fix the build rules to not care, then.
<mjg59> Bonzodog: If you're building a 32-bit application, the linker will automatically look in the right place
<mjg59> If the software is trying to be smarter than the linker, then the software is probably wrong
<Mithrandir> Bonzodog: note that libraries will start to move to another directory in not too long, so any fixes you do now will have to be redone later.
<Bonzodog> thats what I want to know - is there going to be an alteration before dapper final in april?
<mjg59> Bonzodog: /Why/ does the build system want to know this?
<Bonzodog> hold on...gnustep is complicasted..it has it's own build tools
<Mithrandir> Bonzodog: it uses gcc, doesn't it? :-)
<Mithrandir> Bonzodog: yes, quite likely.
<Bonzodog> http://mediawiki.gnustep.org/index.php/Installation_of_32bit_GNUstep_on_64bit_Linux
<Bonzodog> there is a script you have to run there to install the core env
<Bonzodog> it has it's own make tools
<Bonzodog> for it's own apps
<Mithrandir> we don't support building random 32 bit applications on amd64.
<Mithrandir> there's no development libraries, for, say, libX11.
<Bonzodog> so it won't be possible to install gnustep under ubuntu 64 at the moment
<Bonzodog> ?
<Bonzodog> I know there is a 64 bit version in the repos, but i'm not sure where it's come from
<Mithrandir> from the source packages available alongside the .debs.  I hope so, at least. ;-)
<BenC> zul: hey
<Mithrandir> sure, it's probably possibly to install it on ubuntu amd64, just not compile it there.
<Bonzodog> because i would like to build a more recent version of gnustep from the nightly build
<mjg59> Bonzodog: I'm afraid the answer is probably "Fix Gnustep"
<mjg59> We've had Linux on 64-bit platforms (and with 64-bit libraries in /usr/lib...) for over 10 years
<Bonzodog> yeah, theres a lot of work to be done on getting gnustep sorted for 64 bit
<Bonzodog> unforunately, i'm not a coder
<Bonzodog> just trying to build the env from current code
<Mithrandir> neither Debian nor Ubuntu provides the 32 bit libraries, so you might have more luck just using a 32 bit chroot.
<Bonzodog> hrm...
<Bonzodog> I have got the ia32 libs
<Mithrandir> yes, but that doesn't include the header files, etc.
<Bonzodog> i have FF1.5 working using 'linux32' 
<Bonzodog> with flash
<Bonzodog> but not in a chroot
<Mithrandir> I guess you didn't compile it yourself?
<Bonzodog> no, it's the pre-built version off the site
<Bonzodog> installed in a programs dir in my home dir
<Bonzodog> RAOF on the forums came up with it
<Bonzodog> as he runs 64 bit
<Bonzodog> but it does work
<Bonzodog> the only other alteration you have to make is to install a non-standard theme for FF1.5
<Bonzodog> http://www.ubuntuforums.org/showthread.php?t=90106
<Bonzodog> interesting way of doing it, but it works
<Mithrandir> Bonzodog: sure, that works, but we can't support random hacks people come up with.
<Bonzodog> I know that
<Mithrandir> Bonzodog: also, compiling and running programs are two different matters, you seem to want to compile gnustep, and the easiest way to do that is with a 32 bit chroot.
<Bonzodog> it would be nice to see the devels in the forums a bit more often :)
<Bonzodog> yeah, i know what you mena
<Bonzodog> mean
<Bonzodog> to compile will need a 32bit chroot
<Mithrandir> I can't spend my time browsing the forums, I'm far too busy already.
<Bonzodog> hrm...best off seeing what kind of timeline we are looking at to get gnustep 64 bit compatible
<sistpoty> elmo: please sync log4cxx from unstable, ubuntu override ok, thx.
<Riddell> elmo: please move metabar to morgue, it's now included in konq-plugins
<\sh> well..gentlemen...will see you all in 2006 :) now it's time to shutdown the pbuilders and I wish you all a happy new year 2006 :) have fun, party all the time :) 
<Q-FUNK> who maintains ubuntu-sounds nowadays?
<Q-FUNK> the current person listed as Maintainer is a non-existant user at canonical.  e-mail bounced.
<Mithrandir> Q-FUNK: unsure, infinity (adam conrad) was going to do something about it, but I guess you could just mail ubuntu-devel
<Mithrandir> Q-FUNK: please do allow a couple of days for people to catch up on email after the holidays, though
<Q-FUNK> Mithrandir: aye.  that's standard procedure.  nothing new there :)
<sivang> \sh_away: happy new year Stephan
<Q-FUNK> ah.  awaiting moderation.
<Q-FUNK> another question:
<Q-FUNK> could someone please sync rus-ispell from unstable?  ;)
<sivang> Q-FUNK, Mithrandir : happy new year guys
<sivang> Q-FUNK: you're a canonical employee ?
<Q-FUNK> happy new year!
<Q-FUNK> sivang: nope
<Q-FUNK> would be nice if I were, though :)
<sivang> thanks :) same goes to you guys. Mithrandir : have you and Simira planned anything for new year's ?
<sivang> Q-FUNK: same here, or for all of us , hehe :)
<Mithrandir> sivang: we're heading up to a friend of mine who lives up the street in two-ish hours.
<Mithrandir> sivang: so a bit of partying, but none of us are really in the party modd tonight, so.. :-)
<Q-FUNK> Mithrandir: why not?  new year has no particular menaing in your neck of the wood or?
<Mithrandir> Q-FUNK: it's a new year, but we're kinda tired of parties, having gone to such for the last week and a half or so
<Q-FUNK> or already too exausted from the x-mas ones?  oh... hehe :)
* Q-FUNK proceeds with testing cups-pdf 2.0.0 in a breezy chroot...
<Robot101> Q-FUNK: new year has no particular meaning in any neck of the woods :P
<Q-FUNK> ;)
<Q-FUNK> low and behold.  it seems that cups-pdf might finally work with the low-priviledge cupsys of ubuntu.  nice.
<mjg59> What would be great would be if:
<mjg59> The service discovery applet knew which protocols you could handle by looking at installed applications, rather than having a bunch of checkboxes with opaque names
<mjg59> And if applications could register their ability to support protocols when installed
<mjg59> Lathiat: I'm looking at you
<tseng> mjg59: rock on.
<mjg59> daf is just writing a plugin that adds a menu to Epiphany that lists local websites
<FireRabbit> mjg59, arent protocols part of the mime stuff?
<FireRabbit> if so, the applet could use that
<psusi> woohoo!
<psusi> I got hal/g-v-m/gvs to automount and unmount a packet write mode cdrw just by modifying the hal fdi policies
<Bonzodog> if a package you pull from the repos is 'NOT AUTHENTICATED' and the maintainer is listed as someone at debian, does that mean it doesn't actually have an ubuntu maintainer?
<Bonzodog> i.e wmaker
<Bonzodog> the packages work and install, buit they often require small hacks to get them working properly.
#ubuntu-devel 2006-01-06
<sorush20> hi
<sorush20> where is the link to downloading the beta ubuntu?
<Lathiat> mjg59: thats something sebest was working on
<Pygi> Happy New year to everyone :)
<SEJeff> Pygi, I still have 4 hours :)
<Pygi> ok, then happy "early" New year :)
<Bonzodog> Happy new year from Ireland (GMT)
<Bonzodog> anyone having probs with repos?
<Pygi> Bonzodog: same to you :)
<Pygi> Best wishes to everyone :P
<Bonzodog> I 've heard a couple of sporadic reports tonight about the repos being down possibly
<Bonzodog> and now posts are appearing on the forums....much confusion all round
<Pygi> wb Ben
<mjg59> Lathiat: Rock
<jdub> morning BenC 
<jdub> BenC: so there's no printk output about switching SMP to UP?
<jdub> BenC: and/or perhaps a way to make uname -a output correct, based on that?
<BenC> jdub: there is a printk
<BenC> just that the kernel printk buffer isn't long enough to hold everything after the boot finishes
<BenC> but something in /proc would be nice
<jdub> BenC: ahr. i didn't notice anything in dmesg. is there another way i can tell if it's switched correctly?
<bmonty> elmo: please sync gnuift from unstable, ok to drop ubuntu changes
<BenC> jdub: not really
<jdub> boh :)
<bmonty> elmo: please sync libterralib from unstable, ok to drop ubuntu changes
<crimsun> elmo: please sync xfce4-battery-plugin and soap-lite from Sid, overriding Ubuntu changes, thanks.
<Robi-> has anyone had postfix/procmail go haywire with the recent upgrades?
<pitti> Hi
<sivang> pitti: happy 2006 Martin!
<pitti> Hi sivang 
<pitti> sivang: Happy new year for you, too!
<sivang> pitti: thank you , how did you celerate?
<pitti> sivang: we invited a couple of friends and celebrated in my home; around midnight we went out for some fireworks
<sivang> pitti: cool, I wish we had fireworks here. Was it cold?
<pitti> sivang: -2C
<ajmitch> hey pitti 
<pitti> hi ajmitch, how are you?
<ajmitch> good, yourself?
<pitti> still a bit dizzy, but fine :)
<sivang> ajmitch:  how are you Andrew? 
<ajmitch> sivang: alive & kicking still :)
<sivang> ajmitch: that's good to hear. 
<ajmitch> and ready to get back to work on dapper
<sivang> ajmitch: hehe, already free from your job? 
<ajmitch> yes
<sivang> ajmitch: I wish you find a new one soon, actually, I'm sure you will.
<sivang> ajmitch: at least you don't have to touch anymore php code ;-) right?
<ajmitch> maybe
<ajmitch> yeah, no more php for awhile (I hope)
<sivang> bah, I need to do something. I can't open anymore terminals in dapper
<sivang> ah, fixed. I had to close the IRSSI window and then everything went back to normal.
<sivang> ajmitch: I'm dying for some free time to work on my spec, before release it get's so stressed here...
<ajmitch> which spec?
<sivang> ajmitch: it's advancing, but slowly. However my situation might become similar to you in the following days, so it may get a boost in the right timing. it's HomeUserBackup
<sivang> ajmitch: I'm enjoying the ways of the python on the way with it :)
<sivang> ajmitch: what stack of tools do you usually use when you code pygtk applications?
<ajmitch> emacs, python, pygtk, glade, etc
<sivang> ajmitch: you're not using any code sketchers/generators right? 
<ajmitch> nope
<ajmitch> what sort do you mean?
<sivang> ajmitch: python-glade, http://tigrux.nipl.net/python-glade/ 
<winkle> s/glade/gazpacho/ ;)
<ajmitch> I said I used glade :)
<ajmitch> and I haven't tried out gazpacho
<sivang> I haven't been able to find current packages for that though, and when I try to downoad the source distribution I get an infinite http redirection 
<sivang> (for tigrux's python-glade)
<ajmitch> python-glade2?
<sivang> eh, I already got it installed. interesting
<sivang> I reckon it doesn't patch glade though
<ajmitch> yes, because things in the desktop seed use it
<sivang> right, like mvo's stuff
<sivang> hmm, according the the changlog - python-glade2 seems the pygtk package, is that correct?
<ajmitch> yes
<ajmitch> and this is getting more towards #ubuntu stuff
<sivang> ajmitch: that's not the package for python-glade I was talking about, mvo seems to ship SimpleGladeApp.py (which is one of the modules in that "framework" stack) in each packages he uses it, and python-glade2 package does not seem to contain it.
<nowlin> anybody here who knows whats wrong with the newest dapper firefox?
<Treenaks> nowlin: what's the problem?
<nowlin> when im trying to start it i only got a small pop containing <window id="main-window"
<nowlin> ^    <menu id="helpMenu"
<nowlin> ----^
<nowlin> i tried deleting the .mozilla dir without luck
<jdub> Fetched 4384kB in 2m11s (33.4kB/s)
<jdub> wow, updates are big these days
<nowlin> anybody else with the firefox problem?
<mahangu> nowlin, did you try apt-get remove mozilla-firefox
<mahangu> and then apt-get install mozilla-firefox?
<nowlin> noap i will try that
<jdub> mozilla-firefox is just a meta package
<jdub> nowlin: make sure there are no firefox processes running, then start it again
<jdub> s#meta#meta/transitional#
<jdub> reinstalling packages generally doesn't help with runtime issues, unless your disk is buggered
<nowlin> hmm okay. no luck. could it be because its an upgraded brezzy
<jdub> that shouldn't be a cause at all
<nowlin> it seem im forced to use epiphany
<mahangu> nowlin, or galleon
<pitti> nowlin: do you have mozilla language packs installed?
<pitti> nowlin: sounds like the same issue as with mozilla-firefox-locale-de-de
<nowlin> pitti: yeah i have mozilla-firefox-locale-da-dk installed
<pitti> nowlin: please try to uninstall it
<pitti> nowlin: there seems to be a recent breakage
* sivang wonders when irssi+gnome-terminal screen corruption problem will be fixed. it keeps popping.
<nowlin> pitti: thx it fixed MY problem
<pitti> nowlin: I'll look at this breakage soon
<nowlin> nice :-)
<tuhl> any idea when we will see an actual banshee packahe with dbus 0.6?
<ajmitch> tuhl: why, is there a problem with the current one?
<tuhl> ajmitch: does not support dbus 0.6
<tuhl> when I installed dbus 6.0 synaptic deinstalled banshee
<Treenaks> 6.0 !?
<ajmitch> tuhl: works for me
<tuhl> 0.6
<tuhl> banshee:
<tuhl>  Depends: libdbus-1-1 (>=0.36.2) but it is not installable
<tuhl>  Depends: libdbus-glib-1-1 (>=0.36.2) but it is not installable
<tuhl>  Depends: libnautilus-burn2  but it is not installable
<tuhl>  Depends: libipod-cil but it is not going to be installed
<tuhl>  Depends: libipod-cil but it is not going to be installed
<ajmitch> please, don't paste it in here, use something like pastebin
<ajmitch> you must be mixing packages or something, since the latest banshee in dapper doesn't depend on those versions
<tuhl> ajmitch: what is the latest version of banshee?
<tuhl> in dapper?
<ajmitch> 0.10.2-0ubuntu2
<tuhl> ajmitch: obviously my multiverse entry was not dapper - thanks
* Pygi is away: http://fama.sf.net
* Pygi is back (gone 00:00:08)
<HiddenWolf> Pygi, please turn off that away-message
<Pygi> huh, I did...
<Pygi> sorry :p
<thinkle> Hello -- I've just written a script to scrape ubuntu laptop data from the laptop testing team wiki and dump it into a csv file and into a sqlite DB for easy querying. This makes it easy to e.g. get a list of all laptops with working Sleep support in dapper. Can anyone tell me where would be a good place for me to post this script so others can make use of it?
<Kamion> elmo: (urgent-ish) please sync prebaseconfig and base-config, overwriting Ubuntu changes (yes, really!)
<zyga> thinkle: I think ogra could be interested
<thinkle> ogra?
<zyga> thinkle: he's not around ATM
<thinkle> ah.
<mdke> thinkle, rock, ping mjg59 (laptop guy) about that
<mdke> posting it on the LaptopTesting page would be cool too
<thinkle> mkde: There's not a way to attach files to the wiki is there?
<thinkle> s/mkde/mdke/
<desrt> happy ABI bump!
<desrt> er.  i mean new year
<greenpenguin13> lol
* desrt adds infinity to the hit list
* greenpenguin13 sets fire to desrt to make things more interesting
<desrt> IF YOU WANT TO DESTROY MY SWEATER
<desrt> hold this thread as i walk away
<desrt> (don't light me on fire!)
* greenpenguin13 gets the matches out
<greenpenguin13> where is everyone today anyway?
<desrt> out, like me!
* desrt disappears
<lucas> elmo: can you sync libgtk-trayicon-ruby ? (only change is a 1-line diff that the ubuntu patched version already has)
#ubuntu-devel 2006-01-07
<Robi-> how does one check if a pipe died ?
<Robi-> live ones?
<psusi> what do you mean died?
<psusi> if the other process closes the pipe, you get a SIGPIPE
<psusi> and the default handler exits
<Robi-> that's all i got psusi 
<psusi> huh?
<Robi-> postfix wont deliver mail with an error that procmail does with an error
<Robi-> ... status=bounced (can't create user output file. Command output: procmail: Error while writing to "/var/mail/robi" )
<Robi-> procmail docs say it's 1 of 4 things
<Robi-> 3 i can verify is not the case, 4th is pipe died.
<psusi> that looks to me like a permissions problem... it can't write to /var/mail/robi
<Robi-> not that simple
<Robi-> -rw-rw----   1 robi     mail 51199596 Jan  1 14:12 robi
<psusi> chmod u+rw robi
<psusi> maybe postfix isn't in the mail group?
<Robi-> ya checking that too
<Robi-> psusi , it wasn't..
<Robi-> psusi , still no cigar, same error
<Robi-> no mail delivery
<Robi-> weird thing is it removed the msg out of the queue right away too
<Robi-> immediately tries to reply with a failure error, and since it can't [sent from local acct]  it nukes it
<Robi-> any other ideas?
<Robi-> psusi, just checking, it can deliver to other accounts
<Robi-> so strange
<Robi-> it's not my .procmailrc either
<Robi-> just renamed it
<psusi> hrm... no idea
<Robi-> psusi, ok here's some more interesting things
<Robi-> if i rename my spool file it delivers fine to a new one of the same name
<Robi-> if i putit back, it errors
<Robi-> it delivers to other accoutns fine
<psusi> well, there's something wrong with your spool file then ;)
<Robi-> psusi , ya like what ;]  ti's size is teh only thing radically diff from the others
<Robi-> -rw-rw----   1 robi     mail 51199596 Jan  1 15:43 robi
<psusi> Ummm.... you need to get the mail out of there ;)
<psusi> the spools in /var/mail are only supposed to hold new messages
<psusi> mail clients usually move messages to your home directory as far as I know
<psusi> in theory, it should be ok I guess...
<psusi> but it looks like something doesn't like that big of a spool
<Robi-> psusi , i've always kept mail in inbox, since it's local
<Robi-> any folders get saved locally
<psusi> either that or maybe the file doesn't have a correct ending
<Robi-> psusi , tried that too, cat small new email to end of big spool , moved spool into place, no delivery, same error
<Robi-> psusi , next i'll try manually shaving some msgs to bring teh size down
<psusi> I went through the other day and found I had 300 megs of email
<psusi> compressed it with 7zip in ppmd mode and it shrank down to like 25 megs
<Robi-> ppmd ?
<psusi> it's a statistical compression algorithm that works very well for text
<Robi-> ya but you can't do that on a mail spool and have it stay ;] 
<Robi-> so 7z is better than zip/arj/rar
<psusi> sometimes you can do better with lzma, but only if you use a dictionary size at least as large as the file you are compressing, which requires a TON of ram and cpu time
<psusi> WAY better
<psusi> I took a working directory at work full of source and object code... it was 25 megs iirc
<psusi> winzip got it down to 2.5 megs, winrar got it down to 2.1 megs
<psusi> 7zip got it down to 720 KB
<psusi> it's lzma mode also is faster at decompressing than bzip2, and usually gets about 30% smaller archives
<psusi> compressing is very slow though... and needs tons of ram
<Robi-> psusi , cool
<Robi-> psusi, it's totaly size it appears
<Robi-> and i don't know why
<Robi-> 50 mb lmit on mailboxes
<Robi-> how is that possible
<HrdwrBoB> because the compression/decompress would be hell on the CPU
<HrdwrBoB> I can tell you that running a decent mailserver setup is hard enough
<Kamion> This doesn't seem very relevant to Ubuntu development; perhaps you guys could find a different channel?
<HrdwrBoB> yes
<HrdwrBoB> it's offtopic
<psusi> I've been playing with cdrw packet writing mode and read/write udf filesystems lately... I wonder, should I write up a proposal to add support for it to ubuntu?
<Robi-> ya i agree, thanks for helping get to the bottom of the problem
<psusi> and if so, how would I go about doing that and would anyone else be interested?
<Kamion> elmo: please sync preseed, overwriting Ubuntu changes
<wftl> Does anybody want to stick their neck out and express an opinion as to the status of the live/graphical installer for Dapper?
<wftl> [ insert appropriate smiley here ] 
<raphink> :)
<raphink> do you have screenshots?
<HiddenWolf> wftl, at this point, not started yet.
<HiddenWolf> raphink, as a result, no
<raphink> oki
<raphink> it'll be a surprise then
<wftl> Thanks, HiddenWolf.  Do you think it's going to happen for Dapper? 
<raphink> :)
<HiddenWolf> wftl, it will
<Kamion> wftl: HiddenWolf isn't quite accurate that it's not started yet; but it's not far enough along yet to give you shiny screenshots
<wftl> Thanks, I appreciate it.  I'm hoping I can write it up by the end of this month. Wish me luck.
<HiddenWolf> Kamion, I'm only qouting dapper-dev-status 22dec. :)
<HiddenWolf> "to be started in jan"
<Kamion> HiddenWolf: *shrug*, I'm only the developer responsible for it, ignore me if you like ...
<HiddenWolf> Kamion, I know. ;) 
<Kamion> and that's not really an accurate summary of what I said in the relevant meeting
<HiddenWolf> hm.
<HiddenWolf> "specs to be focussed in jan"
<Kamion> whatever
<psusi> how is unionfs + squashfs looking to replace cloop?
<HiddenWolf> Anyway, I can't wait. :)
<HiddenWolf> Kamion, when do you think an ue daily can be put together?
<whiprush> jdub: ping
<psusi> does anyone know of somewhere you can download the linux kernel mailing list archives from?
<SEJeff> psusi, wget -r lkml.org ;-)
<psusi> rofl
<psusi> I am about to snap
<psusi> I've spent an hour searching the web and there are dozens of sites that have web portholes to browse the archives
<psusi> but not one lets you just download them
<psusi> searching the archives on the web drives me insane... no good search engines for it, they just use google, which comes up with all kinds of duplicate and false hits
<SEJeff> Imagine how much bandwidth that would be
<psusi> not that much when compressed ;)
<SEJeff> even with boolean searches?
<psusi> why can't someone just have a nice mbox.bz2 for each month or something?
<SEJeff> Good question actually
<psusi> I simply can't believe nobody does
<psusi> hey, as long as you're around, maybe I'll ask this... I'm hacking on cdrw packet write mode support... should I write a spec on it on the wiki and register it on launchpad?
<SEJeff> psusi, Does it work? Thats great. If you have the time, yes please do
<psusi> got any advice/pointers/reference docs on how to do that exactly?
<SEJeff> nope
<psusi> I made a custom hal fdi policy that allows the system to auto mount the disc... needs a bit more polish so it doesn't try that on non packet mode discs though
<SEJeff> Sorry, I'm multitasking right now. I'm writing policies for vSecurity to allow some suid root binaries to no longer be suid root in dapper
<psusi> and it seems that the pktvdcd driver in the kernel is hard coded to use a 64 kb packet size, which wastes a lot of space to packet headers and slows down throughput... that's going to need fixed to use the packet size the disc specifies, and preferably use a larger size by default
<SEJeff> psusi, Hopefully you submit that upstream once it is working
<SEJeff> psusi, You might want to contact upstream for sure about that
<psusi> well, the hal fdi policy I think should be generated by the debconf in the udftools package
<psusi> when you configure that package, it sets up the pktcdvd device... it just needs to also add the hal fdi policy at the same time
<psusi> since the policy has to point the system to the pktcdvd instead of /dev/hda
<teprrr> hello there, someone mentioned something about ati breakage in dapper on meeting logs.. what's that all about?
<teprrr> X crashes when trying to do gl stuff?
<jdub> whiprush: pong
<jdub> whiprush: hrm, i'll be back in a minute
<Tm_T> teprrr: :)
<whiprush> jdub: just wanted to point out that the <ul> bullets don't look as cool on the fridge as they do on planet.
<teprrr> Tm_T, o_O
<Tm_T> teprrr: still got that problem?
<teprrr> Tm_T, yup..
<Tm_T> fun
<teprrr> quite, yes.. odd that no one on ubuntuforums.org is having the same problem..
<fabbione> morning guys
<ajmitch> morning fabbione 
<jsgotangco> hey ajmitch fabbione happy new year =)
<Burgundavia> indeed
<Burgundavia> fabbione, do you know if the HP custom stuff was merged into Breezy?
<fabbione> Burgundavia: i am not 100% sure, but i assume so
<whiprush> hey has anyone else seen total lockups with the last 2 kernels on thinkpads?
<Burgundavia> fabbione, whom else should I ask about that?
<fabbione> Burgundavia: probably Kamion or mjg59 
<Burgundavia> ok
<fabbione> i wasn't involved directly into the project, so i am really not sure
<crimsun> whiprush: 2.6.15-9.14 and 2.6.15-10.15?
<whiprush> crimsun: both.
<whiprush> -8 works fine.
<crimsun> whiprush: both work fine on this X41-2527. What issues?
<crimsun> oh, the lockups
<whiprush> just randomly freezes 
<whiprush> hard. can't ssh in or anything, just freezes right up.
<crimsun> hmm, can't say I have, but I'm known to push stuff into being OOMkilled
<whiprush> k, I will look into it further.
<mjg59> whiprush: T series?
<Burgundavia> mjg59, since your here:  do you know if the HP custom stuff was merged into Breezy?
<mjg59> Also: woo, my SD reader works properly now (well, "properly" - it's still about 50 times slower than it should be)
<mjg59> Burgundavia: Yes
<Burgundavia> mjg59, and is this a bug that needs to be fixed? https://wiki.ubuntu.com/e02a
<mjg59> It's a bug that is fixed
<Burgundavia> mjg59, hmm, thought I saw it on my laptop yesterday. Will check
<mjg59> Burgundavia: Oh, it may not have made it into Ubuntu yet
<Burgundavia> mjg59, ah, ok
<mjg59> elmo: Can you sync hotkey-setup, overwriting Ubuntu changes?
<whiprush> mjg59: X series, X40
<doko> good morning
<zakame> hi doko :)
<zakame> elmo: please sync eris from Sid, overriding Ubuntu ok :)
<mjg59> whiprush: What wireless?
<whiprush> madwifi
<mjg59> Hm
<mjg59> I haven't seen it here, but I'm using intel wireless
<whiprush> I'll try all-wired tomorrow, see if it's the problem.
<sivang> Morning all
<zakame> heya sivang :)
<sivang> Burgundavia: do you know what he wanted?
<sivang> hey zakame , how are you this new year?
<zakame> sivang: very much ok :) still having some merges to do, and all hopeful for what's in store :)
<sivang> zakame: cool, I wish I could also join the joy of mergers.
<zakame> sivang: it's not too late yet :)
<zakame> elmo: please sync ncmpc from Sid, overriding Ubuntu ok :)
<dholbach> good morning and happy new year! :-)
<jsgotangco> dholbach: happy new year
<dholbach> hey jerome! :)
<sivang> dholbach: morning, happy new year to you too :)
<dholbach> hey sivang :-)
<Mithrandir> hmm, remind me, what's the target for uploads to breezy-updates?  breezy-updates?
<fabbione> yup
<dholbach> http://lists.ubuntu.com/archives/breezy-changes/2005-December/012858.html  has breezy-updates too
<Mithrandir> and version number should just be -1ubuntu2, since previous one was -1ubuntu1, I guess.
<Mithrandir> or 1.1?
<dholbach> which version do we have in dapper?
<Mithrandir> newer upstream version
<Mithrandir> it's evms
<dholbach> if we have a new upstream version it doesn't really matter, how you call it, imho :)
<pitti> hi everybody, happy new year!
<Robi-> is there an easy way to remove all x-related packages?
<Robi-> and libs
<zakame> Robi-: hm, `apt-get remove libx11-6` perhaps?
<Robi-> zakame, what about xterm, gnome stuff, etc
<zakame> Robi-: Just did that here, it removes all that ;)
<Robi-> wow it does, how'd you figure all that out ?
<zakame> Robi-: er `apt-get --simulate --purge remove libx11-6`
<Robi-> zakame , no no, how did you know to use libx11-6
<zakame> Robi-: ah, well libx11-6 used to be xlibs
<Robi-> zakame , sweet, so it's a meta pkg ?
<zakame> so back then it should be `... remove xlibs`, and perhaps xlibs-dev
<Robi-> where's a list of all of these, makes it much easier to install a set of stuff and get rid of it too
<Robi-> over the years there's so much cruft when trying stuff out
<Robi-> then upgrades take forever for stuff you dont even use, like most of the docs
<zakame> hm good question, I myself found that out the hard way (looking at the /usr/share/doc one rainy morning ;)
<zakame> jdub: ping, can you add me to Planet Ubuntu? :)
<Robi-> heh, well thanks a bunch for the tip
<zakame> no prob Robi- :)
<Robi-> saved me hours
<dholbach> zakame: probably best to write him a mail with rss feed and link to hackergotchi :)
<zakame> dholbach: ah, will do that then :)
<Robi-> now if i can only figure out why procmail has around a 50MB limit on mailbox size it will deliver to
<zakame> hm? why would that be so? my procmail here has been putting mails into mboxes way bigger than that :/
<Robi-> i have no idea, i just spent 2 days troubleshooting why i wasn't getting mail and that's the case
<zakame> hm indeed :(
<Robi-> once i deleted some mails and gotten below 50mb it delivers w/o a problem otherwise i have a weird error:
<Robi-> ... status=bounced (can't create user output file. Command output: procmail: Error while writing to "/var/mail/robi" )
<zakame> perhaps there's a quota on /var/mail
<Treenaks> Robi-: this is why I prefer maildir :)
<Robi-> which then deletes the email from the queue and sends an error back right away
<Robi-> zakame, quota not installed
<Treenaks> there could also be a config option in procmail?
<zakame> hm, stumped :(
<Robi-> Treenaks , can't find procmail in etc
<Robi-> ditto
<Treenaks> switch to maildir ;)
<Robi-> that's not a fix
<Treenaks> it is :)
<Robi-> i've always had it this way
<Robi-> yea it's very odd
<tepsipakki> lamont: how do you feel about patching util-linux/mount to support NFSv4? The patches are a year old, so I'd say they are stable...
<tepsipakki> afaik debian/ubuntu is the only major distro not supporting NFSv4 on userland
<ajmitch> elmo: please sync: php4-sqlite, python-biopython, pype, python-iplib, bzrtools from debian, dropping ubuntu changes thanks
<pitti> jamesh: ping
<jamesh> pitti: hi
<pitti> jamesh: bzr is using your openssh push now, right?
<jamesh> yeah (it has been improved a bit since then by the bzr developers)
<pitti> jamesh: this ' WARNING: Unable to update the working tree...' error is pretty annoying; do you know whether this is the fault of the current openssh push plugin or a more generic one?
<pitti> jamesh: so far I always have to ssh to the remote target and do 'bzr revert' to update the working tree (and this even fails if there are subdirs)
<jamesh> pitti: the sftp push creates a branch without a working tree, so the second bit is normal
<jamesh> pitti: if you want an updated working tree, the rsync push is probably the right option
<pitti> uh, that's pretty ugly
<pitti> jamesh: right, but that removes files in the remote tree, so it's suboptimal for me, too
<pitti> jamesh: e. g. in my remote ubuntu-cve tree I have 400 MB worth of cached files which are precious
<jamesh> pitti: none of the working tree files are used when you pull from the remote location
<pitti> I know, but the remote tree is actually used in cron scripts
<jamesh> pitti: if you create a working tree on the server with "bzr branch", you could get your cron script to use that
<pitti> jamesh: ok, so I'll just modify my cron script to remove the working tree and do bzr revert; that should work
<jamesh> pitti: a simple "bzr pull" should be enough to pull in new changes
<pitti> ah, or what you proposed
<pitti> no, pull doesn't work for that, I tried
<pitti> I did that yesterday and was pretty surprised why my working tree was out of date
<jamesh> maybe do a "bzr pull --remember ~/public_html/branch-dir" once would do
<pitti> oh, pull on the remote server, you mean? could be
<jamesh> yeah
<pitti> I'll play around with that; thanks
<pitti> I did push on my desktop to people.u.c, and pull on my laptop, and this didn't update the working tree
<jamesh> that should update the working copy on your laptop
<pitti> (I use sftp:// pull)
<jamesh> that might be a bug
* jamesh doesn't do sftp pulls for Launchpad stuff because it is too slow
<pitti> it is awfully slow, right
<pitti> but avoids problems with my ISP's http proxy
<jamesh> I keep an rsync'd copy of the branch locally, and merge from that
<pitti> hm, all these workarounds...
<jamesh> and use the rsync push
<jamesh> pitti: the solution they're looking at is a smart server
<pitti> hm, rsync is much easier...
<pitti> Kamion: happy new year!
<pitti> Kamion: is it known that both the amd64 and ppc live CDs do not boot?
<hunger>  Happy new year to all of you!
<pitti> hunger: happy new year for you, too
<mvo> Kamion: around? 
<dholbach> mvo: he did some uploads until 2:30 in the morning
<mvo> dholbach: thanks
<Mithrandir> it's also a bank holiday in the UK today
<mvo> aha, thanks (and happy new year :)
<Mithrandir> the same to you
<sebest> dholbach: hello
<Mithrandir> Kamion: if I could have "splash" on the live kernel command line, I'd be happy.
<dholbach> hey sebest - how are you doing? happy new year! :)
<sebest> dholbach: i'm really fine, happy new year too! :)
<dholbach> thanks :)
<sebest> dholbach: i answered to your bug report on avahi
<dholbach> i didn't write a bug report :)
<dholbach> but i subscribed the avahi team to all avahi bugs i encountered, so i hope they'll follow up
<Kamion> pitti: nope, feel free to investigate
<Kamion> mvo: hi
<Kamion> (sort of around, just checking in)
<sebest> dholbach: https://launchpad.net/malone/bugs/6088
<sebest> maybe you just assigned it :)
<Kamion> Mithrandir: ok, will do
<Mithrandir> Kamion: cheers
<Kamion> Mithrandir: all arches?
<Mithrandir> Kamion: yes, please.  It's just so usplash gets started, it should be harmless if there's no usplash on an arch
<Mithrandir> hi Simira 
<Simira> morning
<mvo> Kamion: happy new year! I was toying with the idea of a libcurl based download method for apt, would this be a problem for the installer?
<Kamion> Mithrandir: done
<Kamion> mvo: as long as you depend on whatever you need it's fine
<mvo> cool, thanks
<Kamion> Mithrandir: you get to investigate live CD boot failures today :)
<Mithrandir> Kamion: oh?  They work for me. :-)
<Mithrandir> Kamion: also, any reason why user-setup isn't a deb and part of the live seed?
<hile> Mithrandir, btw I was just checking _why_ there is bank holiday in UK today, seems to be a scottish tradition (Hogmanay), not britihs
<Kamion> Mithrandir: what pitti said ...
<Kamion> Mithrandir: support for building a .deb is checked in upstream already, just not uploaded yet I think
<hile> funny things you learn...
<Kamion> hile: the 2 January bank holiday this year is a substitute for the New Year's Day bank holiday
<hile> ok
<hile> it's also a bank holiday in scotland anyway ;)
<Mithrandir> Kamion: hmm, ok.
<Mithrandir> pitti: what kind of problem do you see wrt booting?
<Kamion> hile: the Hogmanay bank holiday in Scotland is moved to 3 January this year due to the way weekends fall
<Kamion> hile: er, hmm, maybe the other way round actually
<Kamion> yeah, the New Year's Day bank holiday is 3 January; go figure
<hile> simple ;)
<hile> in finland we don't have such luxury - if the bank holiday is during a weekend, well, tough luck
<Kamion> BTW folks, it will entirely not surprise me in any way if there's install CD breakage due to the death of base-config, but I'd like to know about it
<Kamion> Mithrandir: is the live CD meant to be defaulting the locale to aa_DJ.UTF-8?
<Kamion> :)
<Mithrandir> Kamion: already fixed.
<Kamion> ok, thanks
<Mithrandir> en_US.UTF-8 is what it'll default to now
<Kamion> Mithrandir: is the locale stuff from gfxboot not working?
<pitti> Mithrandir: on ppc: after yaboot, I see two (initramfs?) messages, then booting freezes
<Mithrandir> Kamion: it's working, but you don't pass lang if you don't choose anything from the menu.
<stockholm> where is mark?
<pitti> Mithrandir: on amd64, boot complains about being unable to write a kernel modules .temp file, then it drops into a shell
<Mithrandir> stockholm: not here?
<stockholm> or rather: when is he here?
<Kamion> Mithrandir: I can change that if you like ...
<stockholm> Mithrandir: thanks. (c:
<Mithrandir> stockholm: occasionally. :-)
<Mithrandir> stockholm: it's usually easier to reach him by mail
<Mithrandir> pitti: I don't have a ppc, so I'm afraid I can't really help debug that..
<stockholm> Mithrandir: ok, will do
<Mithrandir> pitti: hmm, how far has it gotten by then?
<Kamion> pitti: how long did you wait on powerpc? it takes a while
<pitti> Mithrandir: I'll do it again and do a photo screenshot
<pitti> Kamion: I'll try it again
<pitti> I tried both during breakfast and did not pay much attention
<Mithrandir> pitti: thanks.
<ogra> pitti, i have one machine here where it takes 20-30 min to boot the livecd (powerpc) but it boots ...
<pitti> but I never saw just these two lines with such a long delay; usually usplash works fine
<pitti> anyway, I'll try it again with screenshots
<fabbione> there is a udev bug on ppc
<fabbione> that makes the machine SLOOOOOOOOOOOOOOOW to boot
<Mithrandir> fabbione: so I can blame powerpc, then? :-)
<fabbione> up to 3/4 minutes just to pass init-premount in initramfs
<fabbione> Mithrandir: no.. blame udev :)
<fabbione> i can't figure where the problem is
<fabbione> or better.. i know the problem
<fabbione> i dunno how to fix it
<fabbione> and i was waiting Scott to appear tomorrow *grin*
* pitti sees 'PCI: Cannot allocate resource region of device...' twice and waits
<fabbione> pitti: that message is harmless
<pitti> I know
<pitti> I saw it everytime
<pitti> but after that, I usually got usplash a couple of seconds later
<Mithrandir> pitti: if you add "splash" to the boot line, you should see usplash
<pitti> Mithrandir: I shuold have it, unless it was automatically removed
<Kamion> pitti: I only just added it this morning
<pitti> anyway, I try amd64 now, brb
<pitti> oh, ok
<ogra> Kamion, happy new year ... i'd like an opinion to #20328 if you dont mind ... 
<ogra> seems critical to ppc ltsp ...
<Kamion> ogra: tomorrow, sorry
<ogra> oki
<ogra> its not urgent ...
<Kamion> ogra: besides, you want infinity for an opinion on initramfs-tools, not me
<Kamion> ogra: TBH I'd prefer if you filed your issue as a separate bug, since it's really pretty disconnected
<mdke> Riddell, Kamion, ogra, was any progress made on that ubuntu-docs update?
<ogra> Kamion, i was wondering if it couldnt be also used for the installer, since it loads the blockdevice drivers later anyway 
<ogra> Kamion, but anyway ... tomorrow :)
<Kamion> ogra: no
<Kamion> initramfs-tools != installer, completely
<Mithrandir> Kamion: would you mind if I uploaded 0.04 of user-setup (at least to Ubuntu?)
<pitti> fabbione: ok, ppc boots after a couple of minutes of delay, so it seems that's the bug you saw
<pitti> Mithrandir, Kamion: on amd64 it stops with busybox after:
<pitti> WARNING: Could't open directory /lib/modules/2.6.15-9-amd64-generic: No such file or directory
<pitti> FATAL: Could not open /lib/modules/2.6.15-9-amd64/generic/modules.tep.temp for writing: No such file or directory
<pitti> no record for '/block/ram0' in database
<pitti> [message repeats for ram1 to ram15 ] 
<pitti> Kamion: might this be due to the kernel transition to 10?
<Mithrandir> pitti: yes
<Mithrandir> old kernel on the cd.
<pitti> ok, that should sort out itself then, thanks
<Mithrandir> yes, AIUI, it should
<pitti> BenC: ping
<BenC> pitti: pong
<pitti> BenC: the current ppc live CD does not load snd_powermac automatically; is that known?
<BenC> that's a udev isue
<pitti> BenC: ok, I'll file a bug
<BenC> snd_powermac is one of those drivers that doesn't have hotplug, so it just needs to be always loaded (and is for installs)
<pitti> I see
<pitti> #21772
<BenC> pitti: I got a powerpook 17" over christmas
<pitti> shiny :)
<fabbione> pitti: yes, it's the same i am sure
<BenC> fabbione: did you see that bcm43xx is working now?
<fabbione> BenC: yes, i read it, but didn't try it yet
<BenC> I've been running it for several days with wep
<fabbione> cool
<fabbione> do i need a special fw or the one from MacOS is good?
<BenC> I can put the firmware up for you somewhere
<fabbione> BenC: i used the fw extractor something on the AirPort2 MacOS file...
<BenC> the one for macosx is good, but the one on my system was too new for the fwcutter program to parse out
<fabbione> ah ok
<fabbione> well just mail it :) or put it somewhere
<BenC> if the cutter worked, it will work
<fabbione> ok
<BenC> just mv *.fw /lib/firmware
<BenC> and be sure to do "iwconfig eth1 rate 11M" before ifup
<fabbione> yes i did that a while ago with the old driver
<fabbione> ok
<BenC> adding the wireless-rate to interfaces isn't enough
<fabbione> you can do it in pre-up
<BenC> yeah, that would probably work, but I haven't tried it
<fabbione> the touchpad default is not sensible enough btw
<fabbione> it takes 2/3 full movements to cross the screen
<BenC> mine only takes 2
<BenC> but up and down is a bit slow
<fabbione> yeah
<fabbione> hmm
<fabbione> i guess i need the latest git to get the driver working
* fabbione updates and builds
<jdub> whiprush: yeah. btw - remember to choose a category! :)
<slomo_> elmo: please sync pygame, meta-gnome2, gazpacho from debian/unstable, service-discovery-applet, gnome-user-share, ipod-sharp, libipoddevice from debian/experimental... ubuntu changes can be dropped
<pitti> Kamion, Mithrandir: do you have a minute for a sudo patch review? It's for a 'special sabdfl feature request'
<Mithrandir> pitti: sure
<pitti> http://people.ubuntu.com/~pitti/patches/sudo.adminstamp.diff
<pitti> the idea is that sudo creates a stamp file if it was executed successfully, and a future /etc/profile checks it and writes something like 'To execute commands as root, use 'sudo <command'
<pitti> of course that should only happen for %admin
<pitti> not for arbitrary sudoers (information disclosure)
<sivang> pitti: nice
<pitti> well, I don't really like it
<sivang> pitti: well, it would make all those sad faces go when we tell them "no root in ubuntu"
<pitti> but Mark doesn't like patching su to check whether root is enabled
<pitti> right, that was the idea
<fabbione> hmmmm
<fabbione> pitti: why do you need to do all of these in sudo?
<pitti> fabbione: how else do you want to check whether the user successfully called sudo?
<pitti> patch all of our shells?
<Mithrandir> pitti: the patch is good enough.  I think the idea is wrong, though.
<fabbione> +  * sudo.c: If the user successfully authenticated and he is in the 'admin'
<fabbione> +    group, then create a stamp ~/.sudo_as_admin_successful. A future
<fabbione> +    /etc/bashrc will evaluate this flag to display a short help about how to
<fabbione> +    execute things as root.
<zul> gday
<fabbione> pitti: once you need a new bashrc
<pitti> hi zul 
<fabbione> you need to patch all the shells anyway
<pitti> fabbione: we need a new /etc/profile
<fabbione> hi zul
<zul> hey fabbione, pitti
* fabbione ponders..
<pitti> Mithrandir: wrong idea> I agree, but hey, Mark pays my lunch :/
<pitti> well, it's not totally wrong
<pitti> but I don't like the exposure of a stamp file
<pitti> it would again mean an information disclosure on corner-case configurations
<Mithrandir> pitti: I think having magic flag files like that is wrong and not something we would want at all.
<segfault> will it be used to check if the admin menus in gnome will be shown?
<jdub> pitti: what's bad about patching su?
<sivang> pitti: someone might try to fake one 
<Mithrandir> pitti: there's no way on earth it'll ever go upstream.
<pitti> jdub: no idea, mdz told me that Mark doesn't like it
<pitti> sivang: that's not too scary
<fabbione> i don't like the idea
<pitti> Mithrandir: right, it's not supposed to; it's an ubuntu specific special case hack
<fabbione> what do we gain?
<fabbione> a message?
<pitti> yes
* fabbione sighs
<Mithrandir> pitti: it's wrong because of shared homedirs, for instance.
<sivang> maybe we can trade this to some "welcome to Ubuntu" dialog and note highlights like "no root user" there...
<fabbione> pitti: make sudo a shell wrapper :)
<pitti> fabbione: heh :)
<jdub> pitti: isn't a message like that of most benefit when trying to run su? how is it useful documentation in sudo (which the user doesn't know to use yet)?
<pitti> fabbione: well, we could make it an alias in /etc/profile
<fabbione> pitti: it would be safer and nicer probably )
<pitti> jdub: the message won't come from sudo
<tseng> jdub: its not documented in sudo, its on the shell
<Mithrandir> is there any reason why bashrc can't just echo the message if you're in the admin group?
<pitti> jdub: it comes from /etc/profile if the user opens a shell
<jdub> whoa
<sivang> Mithrandir: I thought about that, but didn't dare to say :)
<pitti> Mithrandir: Mark wants the message to go away if the user ran sudo successfully
<sivang> eh
<sivang> :)
<jdub> what, like, open a shell and get a message every time until you use sudo?
<jdub> oof
<Pygi> huh :/
* Mithrandir shakes his head.
<fabbione> EH?
<fabbione> that's nuts
<jdub> it's so not worth it to be doing this kind of ugly hackery for shell use cases
<pitti> jdub: my favourite solution would be to patch su to check whether root has a password
<pitti> and print a meaningful message that points to sudo
<Mithrandir> pitti: that's slightly less crackful, at least.
<pitti> no idea why mark doesn't like it
<jdub> yeah, that's the most helpful and close-to-home way of doing it
<Mithrandir> pitti: we can do it with a pam module.
<jdub> pitti: perhaps that question needs to be asked :)
<Mithrandir> pam-su-pointtosudo
<sivang> jdub: what do you think about the "short introduction dialog" or better yet, we could mention those on the web page the opens after first install?
<jdub> Mithrandir: heh. that would be nice.
<Mithrandir> seriously, we could.  No patching.
<segfault> why not create something under /var/run/sudo/user?
<jdub> sivang: first-run intro thingies suck.
<sivang> jdub: ok :)
<pitti> segfault: /var/run might be on a tmpfs
<segfault> hum, right
<fabbione> pitti: /home can be on NFS
<pitti> fabbione: so what?
<fabbione> so basically only the first time ever i will see that message
<Mithrandir> pitti: /var/lib/sudo, then.  But seriously, can you ask him what he thinks of a pam module for su?
<fabbione> or is that supposed to be per host base?
<pitti> fabbione: isn't that a feature?
<fabbione> pitti: it depends how you want to see it
<pitti> fabbione: once $USER knows how to run sudo, he doesn't need the lecture on other hosts
<fabbione> in theory
<pitti> Mithrandir: once he's back online, sure
<pitti> Mithrandir: if pam can be hooked into su, can it be hooked into sudo?
* pitti has little clue about pam
<Mithrandir> pitti: yes and yes.
<Mithrandir> pitti: basically, what we'd do is the "if root account is not enabled and user runs su, tell user about sudo".  (Possibly with the "if user is in admin group too")
<Pygi> pitti: you can read something about PAM here if you want...http://www.kernel.org/pub/linux/libs/pam/
<segfault> or maybe here: http://www.linux.com/article.pl?sid=04/02/07/1857219
<Pygi> doesn't enabling root breaks some things in ubuntu? maybe also suggest the use of "gksudo" and/or "kdesu"
<pitti> Pygi: thanks
<Mithrandir> pitti: a problem with the flag file approach is, what if the user forgets the name of sudo and finds docs about "su", which then doesn't work.
<Pygi> pitti: np
<Pygi> Mithrandir: huh, forget the name of "sudo" :/ That is higly unlikely to happen, but it is possible tho :/
<Mithrandir> Pygi: why is that unlikely?  If the user only followed a howto, then didn't use the terminal for a month (just gui admin tools, which uses gksudo), he wouldn't get a message and it's quite likely the user would be confused.
<Pygi> hm, yes, but people use sudo rather then "gksudo" or "kdesu"... some never heard of those commands, but use sudo for any task, even when they don't need it...
* pitti ponders about inviting sabdfl to a TB meeting
<pitti> Mithrandir: do you have any hard argument against the approach other than our gut feeling?
* sivang also reads the PAM documentation. yummy.
<Mithrandir> pitti: it's confusing, why would a message go away just because the user ran sudo once?  It feels so much like a hack.
<Pygi> sivang: hehe :)
<Mithrandir> pitti: I would like some rationale for the change, since I believe it's the wrong place to do it.
<Pygi> Mithrandir: huh, actually, why would you need message every time? it will become irritating :/
<Mithrandir> Pygi: every time you run su without having an enabled root account?
<Mithrandir> Pygi: it shouldn't tell the user about sudo unless the user tries to do something which requires the user to use it, like, run su - root
<segfault> so, we should hide /etc/motd (if not changed) every time a user logs in
<Mithrandir> segfault: you shouldn't see /etc/motd in all your terminals, no.
<pitti> also, only admins should see that text
<Mithrandir> do it when the user tries to do something he can't, not at an unrelated place.
<Mithrandir> there's little chance the user will remember it at that time anyway.
<jdub> Mithrandir: aye!
<Mithrandir> pitti: else, you could do it in d-i and assumed the admin would still remember it at the end of the install when he first fired up a terminal..
<Mithrandir> ;-)
<pitti> Mithrandir: hm, that doesn't help the other admins
<pitti> Mithrandir: I almost feel the necessity to discuss this in TB
* Pygi agrees with pitti
<Mithrandir> pitti: it wasn't a serious suggestion, it was just drawing the "notify the admin at unrelated point in time" to an extreme.
<Mithrandir> sure, TB would work.
<Pygi> pitti: when is that TB and can only member's join?
<dholbach> Pygi: the meeting is public, so anybody can join
<sivang> Pygi: everybody can watch, only TB makes decision. everybody can give feedback I think
<pitti> Pygi: it's open to anybody as long as the audience sticks to the schedule
<Pygi> huh, 3 answers :) k, then please inform me when TB is
<Mithrandir> it doesn't say on the fridge, at least.
<Pygi> I should try to become member also :P
<sivang> Pygi: you mean, an Ubuntu member?
<pitti> jdub: btw, the fridge's calendar has a wrong time for Thursday's distro meeting
<Mithrandir> in those meetings, people are generally listened to if they have sensible things to say, not on whether they are non-members, members or other values.
<pitti> jdub: it'll be at 0200, not at 2000
<Pygi> sivang: yesh, yesh, ubuntu member :)
<jdub> pitti: ok, can fix
<pitti> jdub: thanks
<Mithrandir> pitti: ugh, yet another middle-of-the-night meeting?
<Mithrandir> didn't we just have one?
<pitti> Mithrandir: I feel like it :/
<pitti> I would have liked 2000 much more
<Pygi> sivang: it's about time to become a member :)
<jdub> pitti: 0200 UTC on the fifth, right?
<sivang> Pygi: go for it :)
<pitti> jdub: yep
<Mithrandir> pitti: you shouldn't have told jdub, then. :-)
* Pygi thinks I need to find few people who will vote for him.... :)
<pitti> Mithrandir: JaneW already told us
<Mithrandir> pitti: she did?  Where?
<pitti> Mithrandir: there was an annoucement email
<pitti> Mithrandir: hmm, I'm sure that I read a mail, lemme dig it out
<Kamion> Mithrandir: I'll upload user-setup 0.04 to Debian and merge to Ubuntu; that's substantially less confusing :)
<Mithrandir> Kamion: great, thanks.
<pitti> Mithrandir: ah, it was in '23.12.05 09:42 Jane Weideman     Dapper Development Status 22 Dec 2005'
<Pygi> Kamion: how's the Ubuntu Express thingy goin'?
<Kamion> Pygi: it's going
<Pygi> k, good :) 
<Pygi> Kamion: need any help ? :)
<mdke> Kamion, ogra, Riddell, no reply on the ubuntu-docs breezy update?
<Kamion> Pygi: at the moment, I think too many cooks still spoil the broth, but thans
<Kamion> thanks
<Pygi> hoh, k
<Kamion> mdke: no idea, sorry
<mdke> Kamion, ok, thanks
<Riddell> mdke: that was still infinity doing that
<mdke> oh rly
<mdke> Riddell, thanks
<Riddell> and he's just realised he has a holiday today and tomorrow
<mdke> right
<mdke> maybe I should open a bug on edubuntu-docs or something, to keep track
<mdke> oh, there is no such package
<mdke> ogra, was it edubuntu-artwork that is stopping us from uploading the ubuntu-docs update? I'm just gonna file a bug so I can keep track of any developments
<ogra> mdke, it was that all three of them need the aletrnatves patch 
<ogra> mdke, the patch to edubuntu artwork is a trivial two line change, identical with the kubuntu one, i was waiting for inifinity to give his "go" on the patch ...
<mdke> ok, i'll file the bug and cc him
<ogra> great
<mdke> ogra, #21773, thanks
<ogra> thanks as well :)
<mdke> infinity is adconrad yeah?
<Kamion> mdke: yes
<mdke> cool
<HiddenWolf> ehm, seb128 ?
<seb128> HiddenWolf: pong
<HiddenWolf> seb128, gnome-system-monitor has a curious changelog. It says -gksu-support (ok it's broken) ;) 
<HiddenWolf> seb128, but you drop the libgksu.patch
<seb128> HiddenWolf: right, upstream use gksu, why should we keep the patch? :)
<slomo_> lamont: please give-back njb-sharp on amd64 and ia64, thanks :)
<seb128> the patch was to use gksu because upstream used gnomesu before
<HiddenWolf> Hm.
<HiddenWolf> I read that as "we have a working patch, but dropping for upstreams' broken code"
<seb128> no, that's "the patch is used by upstream but upstream doesn't consider it perfect"
<HiddenWolf> ok, ok. :)
* mvo reboots 
<HiddenWolf> seb128, oh, and cheers for the rhythmbox package. :)
<mdz> pitti: the issue with patching su is that users give up before they even try, because they realize that they didn't set a password
<Mithrandir> mdz: what do you think of moving to squashfs for the live cd?
<pitti> mdz: hi
<pitti> mdz: that's an argument, yes
<zyga> pitti: hi, were the desktop patches uploaded to dapper?
<pitti> zyga: yes, maybe a month ago
<zyga> k, thanks
<mdz> pitti: replied to your email
<mdz> Mithrandir: if unionfs works well, then I think we should try it
<Mithrandir> mdz: there's an oops when booting, but it _seems_ to work fine for me, and it gives us really large savings.  PPC is very buggy with unionfs, though.
<mdz> Mithrandir: a unionfs oops or a squashfs oops?
<Mithrandir> mdz: unionfs oops
<Mithrandir> mdz: I see it with cloop as well as squashfs.
<mdz> Mithrandir: either send it to the unionfs list, or talk to carstenh, he has helped debug such problems in the past
<Mithrandir> carstenh@ ?
<mdz> @#ubuntu-devel
<Mithrandir> ah :-)
<Mithrandir> carstenh: hiya, around?
<Mithrandir> carstenh: any chance you could help out with finding out why unionfs oopses on the live cd?  You should see it on x86/amd64 by just booting the live cd.
<mdz> Mithrandir: so long as we stay with ext2+cloop, we can trivially use either of unionfs or dm, right?
<Mithrandir> mdz: yes.
<mdz> my only hesitation with squashfs is that we have to commit to unionfs
<Mithrandir> mdz: casper also autodetects squash or cloop automatically.
<Mithrandir> correct.
<Mithrandir> though, it comes with a fairly nice space saving, as you probably saw?
<Mithrandir> as well as being awesomely much faster.
<carstenh> Mithrandir: mdz: ENICK?
<Mithrandir> carstenh: possibly, if you don't know anything about unionfs stuff, ENICK, certainly. :-)
<ogra> i think s/carstenh/CarlFK
<ogra> (not 100% certain though)
<carstenh> hmm, shut down the wrong box... :/ but I got the answer to "ENICK?"
<janimo> carstenh, are you working on the firewal spec?
<lamont> yelp is ftbfs (bad depends)
<carstenh> janimo: yes. i promised to be finished end of this week :)
<mdz> Mithrandir,carstenh: sorry, confused
<mdz> Mithrandir: it was shaya potter I was thinking of
<dholbach> mdke: i did an ubuntu-docs update to dapper, just fyi
* lamont files a few bugs
<zul> yay!
<jdub> BenC: ping
<BenC> jdub: pong
<jdub> BenC: have you received any bug reports about nfs issues with the latest kernels?
<BenC> no
<fabbione> jdub: what kind of issues?
<BenC> just one nfs-root with bridging ethernet problem
<jdub> fabbione: appears to be file open hangs
<BenC> v3 or v4?
<fabbione> jdub: ?
<jdub> fabbione: totally screws gnome on my desktop (which has /home on nfs)
<jdub> BenC: v3
<fabbione> jdub: works here.. /home on NFS
<fabbione> jdub: are you running dapper on server or client?
<jdub> fabbione: ok, ta
<jdub> fabbione: dapper on client, breezy on server
<ogra> i still see timeouts of the nfs server on fresh rebooted systems with ltsp
<fabbione> jdub: same here.. breezy server/dapper client.
<Kamion> Mithrandir: ok, user-setup 0.04ubuntu1 uploaded
<jdub> hrm
<stratus> ogra, after restarting nfs server the thin clients works well?
<jdub> are there still weird interactions between the nvidia drivers and the i686 tls bits?
<ogra> stratus, after rebooting the first client
<stratus> ogra, i think it's a old weird bug, maybe claviola has more details than me
<jbailey> jdub: AFAIK there hasn't been for 7 or 8 months.
<ogra> stratus, the second boot attempt is always successfull
<stratus> ogra, i work with him on that cdd, i guess he talked with you already.
<ogra> yup
<ogra> i'll ask him ...
<stratus> ogra, yes, i think it's nothing new but enough random to trace atm.
<stratus> the point is that has nothing to do with a new kernel
<ogra> stratus, i'll focus heavily on this stuff post feature freezy if i'm not allowed to develop new suff ;) 
<stratus> ogra, sounds great we were in a short vacation but we will work hard until april when we plan to release the second version of that cdd.
<ogra> sounds good and as if we could throw our ressources together then :)
<stratus> ogra, ltsp is of course on top of our priority list with the device stuff and fuse for $HOME
<Mithrandir> Kamion: 'k, thanks. :-)
<stratus> ogra, of course we can, i think that claviola already branched from your or pere's tree and he'll be publishing his tree online.
<ogra> oh, has pere his bzr ready finally ?
<stratus> it's up to you merge the stuff you want and discuss with us about that stuff
<stratus> ogra, i dunno
<mjg59> When's Scott back?
<stratus> ogra, i just uploaded bzrtools to debian, wasn't pere just a baz2bzr from that?
<ogra> the sad thing for me with peres patches is that 90% of them dont work at all in ubuntu
<stratus> ogra, oh
<stratus> ogra, do you know what's up with the "unknown" return from video detect stuff? We applied a patch into pere' package to use vesa in these corner cases.
<stratus> ogra, there were two or three more that should be merged back into Debian and probably Ubuntu too.
<ogra> our X doesnt accept a lot of values he sets i.e. X_MODE or the serial mouse stuff as well as most of the other X setting patches
<stratus> ogra, we of course need a better solution for serial mouse, imho.
<ogra> stratus, claviola didnt give me a bzr source yet ...
<stratus> ogra, i'm unsure about the rest but i'll take a look at.
<jdub> seb128: at 1920x1200, i still get visible rendering of the gdm background
<stratus> ogra, he will do it soon, we've already a svn repo but we were in a short vacation (two weeks) due to holidays. I worked only on Debian specific stuff.
<ogra> thats fine ... i'd just like to know about it if something is there to merge :)
<ogra> i was lazy as well the last weeks, only finished the powerpc ltsp implementation :)
<stratus> ogra, i asked claviola to see if pere agree in setup a project at alioth to share the workload with ltsp co-maintainers.
<stratus> ppc, cool. Is there any ppc thin client or you're talking about the server side ?
<ogra> hmm, would be a good reason to finally apply for DD :)
<ogra> both
<stratus> great
<ogra> i'm having a ppc<->ppc setup running fine here and a ppc-server<-> x86 client
<stratus> yes, but i don't talk with pere and you (usually), i've a lot of things to do, but since it's my first day back i'm trying to do some of the claviola' work for him
<stratus> he's busy right now fighting against his desktop
<ogra> but you have to bootstarp the chroot via a rw nfs mounted share
<stratus> Is it a ppc thin client or you're using a full ppc machine?
<ogra> both
<stratus> oh, i see.
<ogra> i have an ibook as server and a old grey g4 as client
<stratus> we don't have so cool gadgets here. :(
<jdub> BenC: i seem to be getting hangs in lockf/fcntl (at least that's what backtraces seem to indicate)
<jdub> fabbione: ^
<stratus> ogra, interesting setup.
<ogra> stratus, i'm not allowed to install on the g4 :)
<stratus> ogra, if someday you show up in Brazil, let me know. I'll show you what we're doing with these things here.
<jdub> on the hung processes, i always have
<fabbione> jdub: nothing like that... 
<ogra> else it'd be the other way around
<jdub> #0 __kernel_vsyscall
<ogra> stratus, i'd sooo love to :)
<jdub> #1 fcntl 
<jdub> #2 lockf
<fabbione> jdub: are you running lockd on the server?
<Riddell> lamont: where is that qt buildkey error from?
* Kamion watches pkgsel Just Work
<Kamion> this makes me very happy
<stratus> ogra, there are many projects but two really cool, and one of them we're managing right now. There's even 'roaming authentication' between what we call telecentres ('kiosks'), more than 15000 users in just 6 or 7. We will reach 50 in a year and more 90 in two or three.
<jdub> fabbione: yeah - i'll restat those and see what happens
<BenC> jdub: is the server userspace or kernel?
<jdub> BenC: kernel
<BenC> jdub: on the server, where is lockd? is it hung?
<lamont> Riddell: that's the most recent attempt to build kdeedu on hppa
<stratus> ogra, these telecentres are installed in poor comunities where they are inserted into technology, internet and free software (of course).
<ogra> stratus, wow, impressive numbers
<BenC> cat /proc/<pid>/wchan
<lamont> http://buildd.mmjgroup.com/buildLogs/k/kdeedu/
<jdub> BenC: _stext
<stratus> ogra, yes we worked in a project that reached 500.000 users in Sao Paulo, the bigger city in Brazil. Unfortunately the project isn't going so well at this moment, but in the great days there were a lot of poor guys that turned out to be programmers and not only soccer players. =)
<jdub> ha ha
<Riddell> lamont: I don't see it in the latest failed build, it's an error on ../../../kig/modes/../objects/../misc/object_hierarchy.h
<ogra> stratus, cool ... 
<lamont> hrm.
<jdub> stratus: i am looking forward to visiting brazil for fisl, if i get to go :-)
<jdub> BenC: that's after a restart
<stratus> ogra, yes really cool that's the reason behind my and claviola' work on ltsp and all that.
<jdub> BenC: (of nfs-kernel-server and nfs-common)
<stratus> jdub, we plan to release the second version of our CDD there, i look forward to see you there.
<lamont> buildLogs/k/kdeedu/4:3.5.0-0ubuntu1/kdeedu_4:3.5.0-0ubuntu1_20060102-0312-hppa-failed.gz
<lamont> Riddell: http://buildd.mmjgroup.com/buildLogs/k/kdeedu/4:3.5.0-0ubuntu1/kdeedu_4:3.5.0-0ubuntu1_20060102-0312-hppa-failed.gz
<jdub> BenC: whoa - suddenly after restarting that, all the hung processes were happy
<stratus> ogra, we have a distributed authentication scheme with pgsql to run the 'roaming auth' stuff, i think mark' saw the prerelease of the php frontend running on a telecentre in Sao Paulo, maybe in the middle of the last year.
<ogra> sounds cool, why did you choose php `
<ogra> ?
<stratus> ogra, it isn't localized yet, but the source code is available through our svn. I plan to package it for Debian in April.
<ogra> great, i'll have a look for edubuntu ...
<jdub> BenC: hrm, i'll keep watching this...
<stratus> just because we have a php dev team, and it works well
<stratus> the pgsql was needed because mysql 4 wasn't enough
<ogra> BenC, the broadcom driver works flawless for you ? as in *totally* flawless without system lockups ? 
<stratus> ogra, i think it will be useful for edubuntu, at this time it just works but in April we will have more interesting features like "user X can or can't print".
<stratus> ogra, i'm working in two PAM modules to ship together with the CDD, one of them is already on the first version.
<ogra> stratus, yup, pgsql is the way to go ... but i'd rather see a python based frontend ... the security update frequency for php stuff is just to high
<stratus> ogra, the first does the authentication stuff using pgsql as backend but is smart enough to do roaming (the pam-pgsql isn't), the second one will create/remove users into the server as needed or just link the $HOME from a remote server.
<stratus> We're planning to avoid nfs and use "some"fs over fuse
<stratus> It'll bring us into the "profile roaming" business early or late. But we're not dreaming with it for April, but November.
<janimo> elmo, please sync/override xfce4-terminal from sid. thank you
<stratus> ogra, i don't see a python frontend as a impossible thing, maybe write a product for zope to consult the current database will be trivial.
<ogra> stratus, that'd be cool ... (at least for edubuntu, where we already have schooltool)
<bmonty> lamont: ping
<stratus> ogra, good we are a step or two from more funding to prepare a larger lab here to install everything related with the subject. e.g: We don't have a edubuntu setup around,
<lamont> bmonty: si?
* lamont has about 2 minutes before he must run
<seb128> jdub: dapper? since today?
<bmonty> lamont: can you please check if grass is in depwait and clear it if it is?
* lamont notes that http://people.ubuntu.com/~lamont/buildLogs/Lists/dapper.all.$ARCH is a good place to check that... and checks
<jdub> seb128: hadn't tried earlier on my desktop
<jdub> seb128: first time i've used it for a long while :)
<seb128> jdub: what libgnomecanvas2-0 version do you have?
<jdub> seb128: but yeah, fully up-to-date dapper
<jdub> sec
<lamont> bmonty: and kicked.
<lamont> back later
<bmonty> lamont: thanks
<jdub> seb128: 2.13.0-0ubuntu1
<jdub> seb128: using nvidia prop drivers
<seb128> jdub: could you try with the previous deb?
<seb128> they changed the interpolation method again, to know if that makes a difference
<jdub> hrm, ok
<seb128> this version of libgnomecanvas is from today
<jdub> is there one on a server somewhere
<jdub> ?
<seb128> jdub: http://archive.ubuntu.com/ubuntu/pool/main/libg/libgnomecanvas/
<janimo> anybody besides elmo who can activate a key in the main uploader ring?
<Kamion> janimo: just elmo
<BenC> ogra: I haven't had any lockups since I started using it
<mdz> BenC: I get hard hangs with 2.6.15-10 on my desktop
<mdz> during the boot process, not always at the same spot either
<slomo_> lamont: please remove gnunet from dep-wait... the version i uploaded 5 minute ago builds fine now... thanks :)  (and please take a look again at njb-sharp... the same error happenend again and it needs imho again a give-back)
<ogra_ibook> BenC, for me it hardlocks from time to time, also the signal drops if i'm more than 10m away from the AP
<slomo_> hm, do we only get automatic syncs from debian/unstable or also from debian/experimental when the package in question was synced from experimental before?
<seb128> no
<seb128> no autosync from experimental
<BenC> ogra: I'm not running an SMP kernel, so that may be part of it
<ogra_ibook> me neither ...
<ogra_ibook> at least not that i'm aware of ...
<janimo> is it possible that two hours pass between a build being successful as shown in lamont/buildlogs and showing up in archive.u.c/pool ?
<janimo> or even more time?
<Kamion> janimo: it could easily be in NEW, for example
<Kamion> janimo: what package?
<janimo> it's not
<janimo> exo
<Kamion> janimo: is too
<janimo> http://people.ubuntu.com/~lamont/buildLogs/e/exo/0.3.1.1svn+r18845-0ubuntu2/
<janimo> a NEW binaries
<Kamion> NEW
<Kamion> ---
<janimo> aha
<Kamion> exo           | 0.3.1.1svn+r18845-0ubuntu2 | amd64 i386 ia64 powerpc | 1 hour old
<janimo> the source is the same, but new binaries
<Kamion> needs manual processing due to new binaries
<janimo> forgot that
<janimo> I did not get mail about it being in NEW as usual
<janimo> thanks
<Kamion> no, you don't when it's new binaries
<Kamion> because the Maintainer: listed in the .changes file is the buildd in that case
<Kamion> so the new ack mail goes to the buildd admin
<janimo> and at that point it can no longer figure out the uploade and send a mail?
<Kamion> by design, mail only goes to the Maintainer of the .changes
<janimo> ok, will remember fro next time
<Kamion> once we switch to launchpad, the status should be visible on a web page somewhere, I guess
<Kamion> it's not worth fiddling with now
<janimo> will that happen before dapper?
<Kamion> it was supposed to happen at the start of dapper, but got delayed because it didn't quite work yet. I don't know.
<michael_> is there an archive of this channel?
<pitti> elmo: can you please sync tetex-bin?
<ogra_ibook> michael_, http://people.ubuntu.com/~fabbione/irclogs/
<michael_> thanks
<ryanpg> is there a page on the wiki describing the sync process? i.e. how a source upload gets built, by who and what schedule?
<ogra_ibook> yes
<ryanpg> ogra_ibook, hrm... guess I've not found the correct search terms yet ;)
<ogra_ibook> https://wiki.ubuntu.com/BuildDaemons
<ryanpg> thanks ogra_ibook https://wiki.ubuntu.com/DeveloperResources explains a bit too
<ogra_ibook> yup
<bmonty> ryanpg: also check out https://wiki.ubuntu.com/MOTUToMerge
<ogra_ibook> note that only devs can actually ask for syncs ...
<mdke> dholbach, cool, thanks
<mdke> elmo, Znarl, website is down (in case no one has poked you yet)
<mdke> argh, now it loads
<sivang> mdke: I thought it was as well a couple of minutes ago, but after some waiting it wen back up
<mdke> yah
<jordi> hey
<jordi> ogra_ibook: ping
<ogra_ibook> jordi, pong
<jordi> ogra_ibook: do you know when Flight 3 is due, more or less?
<ogra_ibook> nope
<ogra_ibook> but it should happen before UVF 
<ogra_ibook> or around this date
<jordi> ogra_ibook: the Catalan GNOME team is interested in having easy to get Live CDs to test the Catalan translation of G 2.13
<jordi> so in like 1/2 weeks
<ogra_ibook> sounds reasonable... but dont quote me on it :)
<jordi> k :)
<mez_> ogra_ibook, i noticed you didnt sign my key - did you lose the fingerprint ?
<jordi> Kamion: what languages are included in the live cd?
<ogra_ibook> mez_, nope, its on the stack with the other signs i still have to make... sorry
<mez_> lol - fair enough :D np - lol
<mez_> just looking at my key stats and noticed a couple of ppl hadnt signed :D thought it mighta been due to lost fingerprints :D
<mez_> I know i lost one :D
<ogra_ibook> elmo, please sync libgtk-trayicon-ruby from unstable, override ok ...
<mez_> which is why i did all of them as soon as i got the fingerprint after that
<mez_> elmo, please sync python-feedparser from unstable - no ubuntu package (needed for newly synced version of ipodder)
<Kamion> jordi: http://people.ubuntu.com/~cjwatson/seeds/dapper/live
<jordi> Kamion: thanks
<jordi> coolio
<jordi> so we can use flight cds to test our translation
<Robot101> how likely is installing this stuff from dapper on a breezy system to break stuff:
<Robot101>   cpp-4.0 g++-4.0 gcc-4.0 gcc-4.0-base gij-4.0 libfribidi0 libgcc1 libgcj6
<Robot101>   libstdc++6 libstdc++6-4.0-dev
<Robot101> :)
<pvanhoof> E: Package notify-daemon has no installation candidate
<jordi> Kamion: hmm, that means only on ppc?
<Kamion> jordi: right, at present
<pvanhoof> And is fglrx going to get really fixed soon? (dapper)_
<Kamion> jordi: check with pitti when he's going to upload language packs, too
<jordi> nod
<ogra_ibook> pvanhoof, ask ati ...
<Kilohertz> 30-50
<Kilohertz> opz :>
<pvanhoof> ogra_ibook, is there a problem with ati?
<ogra_ibook> pvanhoof, no fglrx for X7 yet
<ogra_ibook> afaik
<pvanhoof> aha, ic
<pvanhoof> also, my mouse cursor isn't the Human one anymore .. 
<elmo> wiki is going down for 3-4 minutes
<ogra_ibook> here neither ... just select it in the cursor preferences until its fixed
* Kamion tries to decide how to adapt oem-config for the base-config removal
<pvanhoof> ah, okay
<sivang> does anybody recall what command should I give bzr if I Want o publish a bracnh to a remote location?
<sivang> (e.g. , that's the first time I publish it there, so 'pull' gives me "no branch" error)
<sivang> s/pull/push/
<Kamion> pitti: uploaded langpack-locales including validlocale, FYI
<Kamion> needed for killing base-config
<sivang> coudl someone take a look at http://bugzilla.ubuntu.com/show_bug.cgi?id=21525 ? any idea why I get "stack empty" when gdb'ing on it?
<mdke> sivang, is the backtrace on bug #21617 not good enough?
<sivang> mdke: ah, it's seem goodenough. I just wondered why I can't get a bt as well
<sivang> mdke: although something is missing there, I think
<mdke> sivang, not sure I'm afraid. The other bug is a backtrace on locate I think
<sivang> mdke: yes , well maybe I am doing something wrong
<sivang> mdke: it seems to not segfault when I run it under gdb, so maybe this is a libc problem. weird
<zyga> sivang: it does crash under gdb for me
<zyga> sivang: more less got the cause
<zyga> bah, what a mess
<zyga> whoever wrote that should ... no not die
<sivang> zyga: how are you able to reproduce the crash under gdb?
<zyga> sivang: sudo -s ... then continue as normal
<zyga> sivang: the problem is that search_db gets mess instead of search_str (the third arg)
<zyga> the mess comes from command parser
<zyga> I'll investigate the source
<sivang> zyga: why sudo -s ? slocate should be easy to execute without it no?
<zyga> I don't know really ;-)
<zyga> it does some checks on real and effective id's
<zyga> so I guess that might be the cause
<mdz> Kamion: gfxboot is looking pretty good; just tested the daily amd64 live
<mdz> casper ends up with a locale of aa_DJ or such though
<zyga> okay I got it not to crash
<zyga> hmm
<sivang> zyga: what did you do?
<zyga> sivang: no, my mistake... wait a sec
<zyga> I'll rebuild the database to be sure
<sivang> zyga: I see the problem was fixed in slocate upgraded just now, sorry for the fuss probbly got fixed in debian ...I should have checked there before
<zyga> ok :)
<zyga> what was the problem?
<Kamion> mdz: Mithrandir says he's fixed the default, although I'll make a small gfxboot-theme-ubuntu tweak too probably
<Kamion> mdz: test today's install CD for some fun
<mdz> Kamion: "fun"?
<marcin`> hello developers...
<marcin`> I got a question
<marcin`> could someone tell me if is it possible to write book about ubuntu linux and put fragments of ubuntu documentation in it?
<zyga> marcin`: probably
<zyga> marcin`: you'd have to look at idividual licenses (to check if they are compatible with one another)
<marcin`> zyga: I'm not sure if it is legal...
<zyga> or explicitly ask permission from doc authors for a special license for a fragment
<mvo> ping ogra
<ogra_ibook> mvo, pong
<marcin`> zyga: hmm I would like to write book about entire ubuntu-desktop... it's on gpl and lgpl (afaik)
<zyga> marcin`: doc is often written with different licenses
<lifeless> morning
<zyga> marcin`: would your book be freely available?
<marcin`> zyga: another thing is that I would like to write some documentation in my native language and upload it to gnome.pl team
<marcin`> zyga: but then I would like to use these parts of documentation as part of my book
<zyga> marcin`: hmm... it depends on what the whole book be licences like
<marcin`> zyga: can I use different license for documentation than license for application that I want to describe?
<zyga> only if the license allows such 'derived work', you should read each license and check
<marcin`> zyga: well the thing is that I would like to write book - and describe various parts of ubuntu desktop
<mdz> documentation isn't a derived work of the work it's documenting
<tsume> does ubuntu have a special development team for ruby like debian, or does ubuntu use the debian-ruby teams packages?
<marcin`> zyga: and then publish my text in book form and sell something 
<marcin`> zyga: (well I just would like to earn some money)
<mdz> tsume: occasionally someone patches ruby, but currently (in dapper) it's identical to the package in unstable
<marcin`> zyga: but then I would like to contribute my work to open source community
<tsume> theres a serious problem with the ruby libraries which come with ubuntu. The libraries seem to be a compeltely different version.
<dholbach> tsume: both, you maybe should talk to lucas
<zyga> mdz: but docs written that include existing docs could be derived work
<tsume> mdz: its like the ruby libs for the stdlib base in ruby come from 1.8.2.
<marcin`> zyga: after let's say - 1-2 month after printed documentation
<dholbach> tsume: and i doubt they are "completely" different
<mdz> tsume: can you explain what you mean in terms of packages in the archive?
<zyga> tsume: tell lucas about that, he will be most interested
<tsume> mdz: I was just debugging someones problem, and noticed time.rb is not the version distributed with ruby 1.8.3
<mdz> zyga: yes, that would be modifying documentation; marcin` seemed to say he would write it from scratch
<tsume> mdz: the parse method for Time is completely different, which indicates it was modified, or an older version.
<zyga> mdz: yes but he also noted that he'd use parts of existing docs
<mdz> tsume: that's because the current stable release (5.10) contains ruby 1.8.2, not 1.8.3
<marcin`> zyga: that's right
<marcin`> zyga: I would like to write a lot from scratch
<marcin`> zyga: but also I would like to use parts for example gnome-guide...
<zyga> IMHO you'd have to ask individual authors for permission to include their text and not to release the book as free as in speech
<zyga> but please read the relevant licenses to be sure
<tsume> wtf
<Kamion> mdz: base-config go bye-bye
<Kamion> (it's good fun)
<marcin`> zyga: ok - but last question then - if I'll write everyting from scratch
<tsume> mdz: its a big wtf here then :)
<mdz> Kamion: does it work?
<marcin`> zyga: do I need any permission then?
<tsume> mdz: somehow a rogue ruby seemed to sneek on my system :)
<Kamion> mdz: the i386 CD worked in qemu for me
<zyga> marcin`: no
<zyga> then it's all your copyrighted text
<Kamion> still a few glitches, but apparently nothing major
<mdz> ok, will give it a shot
<marcin`> zyga: and it doesn't matter then that this text is about some gpl software?
<marcin`> zyga: just my words - my license - right?
<mdz> marcin`: correct
<mdz> marcin`: the license of the software is only applicable to copying it, not talking about it
<marcin`> mdz: ok - thanks
<zyga> mdz: not really... check the license for .NET crap
<zyga> :-)
<marcin`> mdz: but then I can for example format my text to docbook and upload this as for example - gnome user guide in polish lang - on gpl or lgpl license?
<marcin`> mdz: am I right?
<teprrr> hum, have daniels used to hang out here? or someone else who knows about xorg things?
<tsume> hrm.
<tsume> I know I didn't install it. Is there a way to verify package files?
<mdz> debsums
<mdz> marcin`: you can do whatever you like as long as you wrote it
<marcin`> mdz: ok
<marcin`> mdz: so I'll start my book :)
<sivang> zyga: I Was wrong before, I checked again and it still there
<sivang> zyga: it just segfaults after you sudo -s "cmd"
<marcin`> mdz: and after few months on market I'll contribute this book to open source community :)
<tsume> mdz: what if I tell you debsum said ruby1.8 was OK for a checksum? :)
<tsume> mdz: I know I didn't build it on my machine, since the runtime says its 486-linux
<mdz> tsume: I'd tell you that you probably have it installed in /usr/local, and that this is a matter for #ubuntu rather than #ubuntu-devel
<tsume> mdz: its in /usr/ ;)
<zyga> sivang: darn I rm -rf'd my code :)
<zyga> sivang: contact the upstream, it's an app bug IMHO
<tsume> mdz: there needs to be a #ubuntu-technical, since usually home channels are filled with kids and chat.
<tsume> or a #ubuntu-tech
<zyga> tsume: #ubuntu-pro ;-)
<tsume> oh, that was a joke :)
<sivang> zyga: I'm sorry then, you were probably close :-/
<zyga> sivang: the code that managed search_str in search_db is fishy, I'd add a couple of asserts and recompile but I'm not going to work on this ... no time to start YET another thing
<mdz> Kamion: hwdetect is nice and snappy now
<sivang> zyga: right,I might give it a look when I'm done with what I'm douing :)
<Kamion> mdz: <3 udev
<trulux> anyone with experience working on pygtk-based stuff?
* trulux is working on the ubuntu security center
* tsume smiles
<tsume> mdz: I'm curious why someone would use the CVS version of ruby
<Robot101> slomo: mplayer seems to be missing a libmp4v2-dev build dep
<mdz> Kamion: would be interesting to benchmark against breezy, given that we also do DMA now
<zyga> trulux: what do you need?
<Robot101> slomo: although I am building the dapper package on breezy
<slomo> Robot101: hm no... libfaac-dev misses a dependency on libmp4v2-dev in breezy but not in dapper... where are you building it?
<trulux> zyga: I don't know how to add more than one widget (a chekc button) to a frame
<slomo> Robot101: ok, you answered your own question ;)
<Robot101> slomo: on breezy, it fails building ad_mpc too, but I don't care about that so I'll disable it :)
<tsume> mdz: I guess I'll just hang around in #debian-ruby and beat lucas senseless when I see him. :)
<mdz> I'll try to remember to do that when doing upgrade testing, since I'll need to install breezy anyway
<Robot101> slomo: upstream really love these packages it seems... :)
<slomo> Robot101: you mean mplayer upstream? yes... they don't like packages in general it seems ;)
<zyga> trulux: read the glade tutorial and pygtk tutorial
<zyga> trulux: basically you need a container but that is all abstracted away by glade :)
<trulux> zyga: I'm on it, but I'm not using glade at all
<zyga> trulux: check update-manager or language-selector for a small (relatively) codebase that is using glade 
<mdz> Kamion: "select and install software" is very nice looking, apart from the non-functional estimate of time remaining
<trulux> zyga: I've already checked the tutorial and the reference
<zyga> trulux: you should try glade, it will make your problem go away
<trulux> well, I'll give it a look now
<zyga> trulux: unless you are building a really weir app glade can do 99.9% of your GUI creation work
<zyga> trulux: and if it's desktop oriented feel free to join #u-desktop
<trulux> zyga: OK, I'm going to join the channel and comment about the project
<sivang> tr	ffddd
<Robot101> spot the irssi user :)
<sivang> heh
<sivang> lost network for a while
<psusi> well, I just wrote my first space... anyone want to critique it?  https://wiki.ubuntu.com/PacketCD
<psusi> s/space/spec
<Pygi> psusi: I'll go take a look 
<rraphink> psusi: very interesting
<sivang> psusi: now I know we do not support packet mode by default :) I was sure this was supported..
<rraphink> correct me if i'm wrong
<rraphink> but CDRWs lose in thickness when they are erased
<psusi> well, it didn't take a whole lot to get it working ;)
<rraphink> so this would mean that using this kind of technology could end up having CDRWs that are not really flat 
<psusi> rraphink, they don't physically get smaller, but yea, they can only withstand about 1000 write cycles
<rraphink> ok
<rraphink> I mean
<rraphink> with the current technology erasing the CD entirely 
<Amaranth> 1000?
<rraphink> you don't get much difference in thickness when burning data on a CDRW
<Amaranth> i wiped one 10 times and all my burner apps (OS X) tell me it can't be written to anymore
<mdz> Kamion: amd64 daily install was successful, though eth0 wasn't configured at boot
<rraphink> really Amaranth ?
<Amaranth> yeah
<psusi> rraphink, I don't know what you're talking about thickness... the disc physically doesn't change...
<rraphink> hmm
<Amaranth> i'm thinking if i could find an app that ignores what the disc tells it maybe it would work
<rraphink> psusi: physically some layers of the disc are removed
<Amaranth> but i don't want to put anymore important on that disc anymore
<psusi> Amaranth, I have written to and formatted this one in my drive now at least 30 times
<rraphink> when erasing a CD
<rraphink> no?
<sivang> Amaranth: weird. I have various ones , written over 10> times, and they still work
<psusi> Amaranth, and everything I have read says it can take about 1000 write/erase cycles
<rraphink> wb ogra 
<psusi> rraphink, I'm fairly certain that is incorrect
<sivang> psusi: bascially, the session mode is applicable to non RW discs as well right? 
<rraphink> psusi: that can be :)
<rraphink> (incorretc i mean)
<psusi> the media is heated and when it cools, the lattice structure is a bit different, so it is more or less reflective
<psusi> I believe
<psusi> sivang, yes... you can burn cdr media in the current session mode... packet mode is more for rewritable media
<psusi> in theory you could use it on cdr media... but it's main benefit is easy reuse of deleted space, which can't be done on cdr media anyhow
<psusi> so it wouldn't make much sense
<sivang> psusi: noted, thanks.
<Pygi> pitti: ping
<psusi> with the current growisofs method, each session you add can only use up more space... and the more sessions you have on the disc the slower it gets
<sivang> psusi: is there a definite way to know when a disc is going to make his last write cycle?
<psusi> sivang, not that I know of
<Pygi> sivang: but we can predict that based on the *some* factors
<rraphink> this is very interesting anyway
<rraphink> I think I''ll use more CDRW if i can use them this way
<rraphink> :)
<sivang> psusi, Pygi : I'm asking in realtion to HomeUserBackup. My interested is clear, I think :)
<psusi> I have also found out that there is some windows software that enables packet mode... I have seen one called "incd" before.. only it uses variable length packets... each file gets an entire packet... currently linux only supports fixed length packets
<sivang> (I might fall as another use case as well)
<psusi> variable packets waste less space, and can be read by older systems it seems
<Pygi> sivang: hehe :)
<Pygi> psusi: huh, can't we somehow "enable" it?
<psusi> sivang, I think it's like how you used to use floppies for the purpose: if you write to it every day, after maybe 3-6 months, it's time to replace it ;)
<sivang> psusi: seems fair, yes.
<psusi> Pygi, yes... install and dpkg-reconfigure the udftools package
<psusi> then use the included cwrwtool program to format the disc... then you need to hack the hal fdi policies a bit for it to auto mount
<psusi> I'd like to get the udftools package modified so that it 1) auto configures on install and 2) automatically sets up the hal fdi policy for auto mount
<psusi> but I'm not quite sure how to do that yet ;)
<Pygi> huh, shell script or python one?
<psusi> huh?
<Pygi> nothin' :)
<Pygi> can't you use shell or python scripts to make that?
<psusi> not sure... I haven't yet learned about how debconf works
<psusi> I just know that dpkg-reconfigure udftools asks you some simple questions then sets up the pktcdvd device... it should also create an appropriate hal fdi policy file
<psusi> I'm also still trying to figure out if there is anyone maintaining the pktcdvd kernel driver upstream
<psusi> the project page on sourceforge has not had any cvs changes or active mail on the mailing list in over a year
<psusi> if it is not maintained I just might end up fixing it myself... it needs to get rid of the hard coded packet length... the default packet length stinks, larger is better
<Pygi> k, good luck :)
<Kamion> mdz: the time estimate is an aptitude bug, I presume
<Kamion> or perhaps apt
<Kamion> mdz: network plugging is a known problem with current udev
<Kamion> mdz: yes, benchmarking would be good, especially for sabdfl's "fastest installer in the west" kick ;-)
<mdz> Kamion: hmm, don't we have timestamps somewhere already? maybe in the typescript?
<mdz> modulo user input
<Kamion> /var/log/installer/syslog does have timestamps; not sure there's anything for base-config
<Kamion> you might be able to work it out from the timestamp of /var/log/base-config.log?
<Kamion> i.e. mtime
<mdz> yeah, maybe
<dholbach> good night
<Kamion> yeah, that should work, that's the typescript
<jdong> hey, what does buildd mean when builds are given-back?
<jdong> quite a few GNOME/GTK related backports aren't compiling because of it
<Kamion> jdong: transient failure, leave to the buildd admin
<Kamion> usually that it tried to build at a bad time when the master archive was busy doing maintenance on itself
<jdong> Kaloz: do I need to take any action then? (i.e. request a rebuild, etc)
<jdong> Kamion: rather
<jdong> stupid tab completion :)
<Kamion> jdong: no
<Kamion> if it drags on *too* long, ping lamont/infinity about it, but in the short term just let them do their jobs :)
<jdong> Kamion: alrighty then, thanks for your time
<janimo> elmo, when you have time please add jani@u.c to the main upload whitelist. thank you
<crimsun> janimo: we'll still have to merge xfce4-terminal due to the .desktop calling the wrong binary
<janimo> crimsun, I'll merge it as soon as exo leaves NEW
<crimsun> janimo: right, thanks.
<janimo> right now since our exo is ahead in version numbering, I jut take the debian/ dir and merged it into our package
<janimo> so we're in sync short of the actual version number
<janimo> but thanks for the terminal .desktop reminder
<Kamion> janimo: *@ubuntu.com is already whitelisted
<janimo> Kamion, then the GPG key need special treatment?
<janimo> I uploaded to main today and got rejected
<Kamion> yes, that's about the GPG key, not about the *-changes whitelist
<zyga> jdub: ping
<Kamion> (*@ubuntu.com> at least I think so ...)
<janimo> I have a RT ticket opened two weeks ago on that
<janimo> yes, it was whitelisted for universe till now, and I am using that address in uploads
<janimo> ok I'll ask the right thing then
<Kamion> RT ticket as in rt@admin? that's for general sysadmin requests; the GPG keyring is an ftpmaster admin task
<Kamion> AFAIK
<Kamion> anyway, just leave it for now
<janimo> I was told not to bug elmo, but file a ticket in RT.canonical
<Kamion> told by elmo?
<janimo> I thought I can ask again since some time has passed
<janimo> yes, he told me that
<Kamion> ok, fair enough
<Kamion> try waiting until he comes back from holiday
<Kamion> today's a UK bank holiday; it's not fair to assume that UK employees will be around :)
<janimo> he has just synced today :) .Maybe he does that on holiday too
* mvo goes to bed
<jdub> zyga: pong
<zyga> jdub: is the planet back to being functional?
<zyga> jdub: I'd like my blog to be included in the feed someday
<jdub> zyga: not entirely, if you want to be added, send me an email with your member reference
<jdub> hopefully it'll be sorted out soon
<zyga> jdub: member reference?
<zyga> launchpad profile?
<jdub> zyga: yeah, whatever lets me know you're a member :)
<ogra_ibook> zyga, your membership in the ubuntumembers launchpad team 
<zyga> I was approved as a member but nobody have updated my profile :/
<sivang> good night all
<zyga> sivang: night :)
<sivang> night zyga  , rock on
<ogra_ibook> zyga, then you should talk to one of the CC members why you are no member of the tem yet, normally it gets updateted right away
<zyga> ogra_ibook: trying to locate the list 
<ogra_ibook> https://launchpad.net/people/ubuntumembers/+members
<zyga> I'm a proposed member on that list
<ogra_ibook> yes, but not approved
<zyga> ogra_ibook: I was approved on the last CC meeting, the logs and wiki can confirm this
<zyga> (as well as memory of the people who were there)
<lucas> zyga: same for me. let's just wait or ping Kamion ;)
<ogra_ibook> zyga, so ping the CC that it gets updated ... this list is the master we use everywhere now
<zyga> lucas: I'll try the latter :)
<zyga> Kamion: ping
<lucas> Irvin Piraman is in the same case too
<zyga> lucas: seems like a massive overlook
<lucas> 3 doesn't make it massive ;)
<zyga> lucas: if self in list: massive = True # ;-)
* jdong wonders if driving and talking on IRC is a bad idea...
<lucas> you want to write it massive = list.include?(self) ;)
<zyga> lucas: that's ruby? :)
<zyga> massive = self in some_list
<Riddell> Kamion: do you know if the dapper installer will use sources.list.d by default or just sources.list?
<mdz> seb128: is it only me, or is gconftool-2 very slow now during upgrades?
<mdz> it seems to take several seconds each time it is invoked
<seb128> I've noticed some slowness when configuring some GNOME package but not tried to figure what causes it
<seb128> I'll have a look to know if that's due to gconf
<mdz> when I notice the slowness, it is always gconftool-2 running
<seb128> maybe a side effect of using one merged file
<seb128> I'll have a look on that tomorrow
<mdz> seb128: if it's a tradeoff of slow upgrades for faster runtime, that's OK with me
<seb128> that's probably that but I'll have some look to be sure
<Kamion> zyga: tomorrow, if you could, or mail me; I'm about to go to bed
<Kamion> Riddell: just sources.list unless somebody gives me a good reason otherwise beyond "it's there" :-)
#ubuntu-devel 2006-01-08
<Kamion> I prefer to leave sources.list.d for other packages and admin customisation
<Kamion> zyga: oh, membership? yeah, I'll catch up tomorrow
<Riddell> Kamion: great, thanks
<Kamion> sorry I didn't do it over Christmas, but, well, I've been on holiday :)
<zyga> Kamion: yes about membership, I'll mail you :)
<Kamion> zyga: nah, don't bother, I've already got mail from someone (Lucas I think?) about it
<zyga> :)
<Kamion> if anyone knows "Keyes", please tell him/her that integration of "EasyUbuntu" in Dapper is not an appropriate topic for the community council
<seth_k|lappy> I'll have robotgeek tell him, Kamion 
<lucas> I'll ask him to consider going through REVU for easyubuntu
<Burgundavia> jdub, you have any comments on  https://wiki.ubuntu.com/HelpingUbuntu
<jdub> Burgundavia: can you mail me a ping? :)
<Burgundavia> jdub, sure
<jdub> thanks
<jdub> i liked the easy page
<jdub> and doc project news == very good
<Burgundavia> that is mostly mdke and jerome. I can't claim any credit for that
<Burgundavia> jdub, sent
<Burgundavia> hmm http://www.nubuntu.org/
<tseng> Burgundavia: "copyright 2005 canonical ltd"?
<Burgundavia> is this an official subproject then?
<tseng> unlikely
<tseng> Tech Email:ownthebox.net@gmail.com
<Burgundavia> http://en.wikipedia.org/wiki/NUbuntu
<tseng> also notice the references to some off the wall irc network
<tseng> he just ripped off the copyright notice for some reason
<Burgundavia> it doesn't appear to be plone
<tseng> he could have joined ubuntu hardened..
<Burgundavia> people have this cathedral like view of distros sometimes
<tseng> some people like to derive things unessecarily for some reason
<Burgundavia> observe doc.gwos.org
<slomo> tseng: maybe because they want to do something on their own? ;)
<FireRabbit> tseng, its so they can change the graphics
<FireRabbit> because you arent a hacker unless you use a dark theme
<tseng> hah well i made a livecd of ubuntu with ethereal on it
<tseng> i forgot to make my own website about it :(
<FireRabbit> :(
* tseng kids
<tseng> dinner time, take care
<FireRabbit> ttyl
<FireRabbit> people sure waste no time putting stuff on wikipedia
<FireRabbit> we dont need websites, we just need a wikipedia page
<CarlFK> where is the right place to point out that the "list of files" on http://mirror.mcs.anl.gov/pub/ubuntu-iso/5.10/ is "worthless" (they are all truncated such that you can only tell install from live)
<CarlFK> other mirrors are ok: http://mirror.yousendit.com/ubuntu/5.10/
<HrdwrBoB> I would say the admin for the mirror.mcs.anl.gov site?
<FireRabbit> what is the "opposite" of the "dput" command? - to remove a package from the repository
<Riddell> ogra: do you know dsaa  Dino Solon A. Agcambot?
<akurashy> is xorg 7 in dapper yet? :o
<crimsun> no.
<daniels> crimsun: well, basically yes
<crimsun> daniels: aside from doc changes, correct?
<lamont> jdong/Kamion: given-back packages are automatically retried.
<psusi> SEJeff, are you around?  weren't you the one that had a page about "make it pretty I say!"?
<SEJeff> psusi, ping
<psusi> hey, sup?
<SEJeff> psusi, You wanted that script I wrote to set up ubuntu?
<SEJeff> psusi, Or did you just want the gconftool-2 commands to set up gnome to be a bit more sane?
<psusi> didn't you have a page explaining the various ways to tweak things and make things look pretty?  I'd like to improve my fonts a bit I think
<SEJeff> psusi, No, I wrote a script to set up a default ubuntu install and set things like ctrl alt del to gnome-system-monitor etc
<SEJeff> psusi, It also stops and removes unneeded services, does some speed tweaks and whatnot
<psusi> yea, I remember looking at it... I just thought I saw something about making fonts look nicer
<psusi> now why the hell would this end up being zero?
<psusi> pd->settings.size = be32_to_cpu(ti.fixed_packet_size) << 2;
<psusi> when ti.fixed_packet_size is 0x80000000
<SEJeff> exactly what I was thinking all along :)
<SEJeff> I'm too tired to play hex. I just ran about 9 miles
* psusi is debugging the kernel and user utilities to correctly support cdrw packet mode with packets of sizes other than 32 sectors
<psusi> lol
<psusi> BAH! pd->settings.size is only an 8 bit type!
<psusi> this is a load of gnarly code... how did it make it into the kernel?  sheesh.. and why do I get the feeling that I'm going to end up becoming it's maintainer?
<SEJeff> psusi: And thats a bad thing?
<psusi> I don't need that kind of responsibility ;)
<psusi> bingo!  changed to a u32, and raised the compile time maximum packet size, and it appears to be correctly accessing this disc using 128 sector packets
<SEJeff> psusi, Dump the patch on lkml and pretend you don't know anything about it after that. Be like the maintainer of ncpfs that never responds to emails about bugs
<psusi> lol
<psusi> that's what is going on here... the original developers of this stuff appear to have vanished
<SEJeff> Do you have it working with the project utopia magic / black voodoo?
<psusi> no new developments in over a year that I can see, and the mailing list is basically dead
<psusi> project utopia?
<SEJeff> Project Utopia is an umbrella project started by robert love. It includes things like the 2.6 kernel based hotplug infrastructure, gnome-volume-manager, hal, dbus, etc
<SEJeff> It is the project that coordinates making hardware "just work TM" in linux
<psusi> oh, yea... I made a hal fdi policy file to get it to auto mount
<psusi> right now though, it tries to do this for all discs, not just ones formatted for packet mode... I need to fix it to detect that and act accordingly
<SEJeff> psusi: rlove description of project utopia use cases http://kerneltrap.org/node/3450
<SEJeff> psusi, Yes thats a problem. And does it impose any penalty on normal cdroms?
<psusi> SEJeff, once it notices the difference, it won't change the operation of normal discs at all
<jbailey> daniels: Around?
<daniels> jbailey: represent
<jbailey> =)
<jbailey> daniels: re: 21779, it's likely not cdbs rebuilding configure, but that you have some patch that's left configure.ac with a more recent timestamp than configure.
<jbailey> automake will then attempt to rebuild the whole mess.
<daniels> jbailey: my 'why the christ would you do that' sentiment remains :)
<jbailey> My usual solution to this when I'm patching configure.{ac,in} is to ALSO add AM_MAINTAINER_MODE so that unless --enable-maintainer-mode is added to the ./configure line, it will never regenerate the tools.
<jbailey> daniels: Because the expectation is that if you've modified configure.{ac,in} more recently than configure, that you probably want it updated.
<jbailey> Not cdbs, but usual autotools magic.
<daniels> hm, I thought dbus already had AM_MAINTAINER_MODE in
<daniels> i'll check it out anyway, though; thanks
<jbailey> daniels: Np.  I'm around for 5-10m, if you want I can look at it now {for,with} you.
<daniels> jbailey: ah, it's okay, thanks.  i think pitti and mvo are nominally the dus maintainers anyway ;)
<daniels> i'm the first on the debian maintainer list -- i.e., least active
<jbailey> =)
<jdong> lamont: can you help me look at why some backports still don't have binaries then? comix is one example, 2.1-1~breezy1
<jbailey> In other news, I haven't had a hang in a while on my X (r300, ppc64).  However, it now cmpletely fubar's the video after a while.
<jbailey> Makes it look like an analog TV when you try watching the VCR on channel 4 instead of channel 3.
<daniels> using xvideo, I assume
<jbailey> The funny part is that I can tell when it's getting close to that time because the nautilus corruption stops.
<daniels> if you could get a photo, that would be neat
<daniels> heh!
<jbailey> xvideo?
<jbailey> No, just regular IRC session or whatever.
<jbailey> But I can take a picture with my digital camera next time.
<daniels> oh, so it screws up your whole thing
<jsgotangco> good morning
<daniels> sorry, I thought you meant when watching actual videos
<jbailey> Even when I flip to a text console.
<jbailey> Nonono
<jbailey> The whole screen.
<jbailey> But at least I can close x-chat and my email gracefully. =)
<daniels> i get some interesting corruption every now and then on my r480 whereby you get random black lines roughly once every 380 scanlines, then they start multiplying, offset by a couple of lines each time
<jbailey> Nothing like that, so far.
<daniels> that's only with videos, though
<daniels> so I just blame the video engine
<jbailey> But the nautilus corruption that I usually see is that it likes to shift things one pixel or two up randomly.
<daniels> hrm
<jbailey> Like the text under an icon will shift up 1 or 2 pixels everytime I move my mouse over it.
<jbailey> However, about 30-60 minutes before X pukes on me, all that corruption goes away.
<jbailey> And Nautilus looks fine.
<jbailey> Creepy eh? =)
<daniels> do you have any effects on icons? like, underlining text or anything
<daniels> i only have the folder sort of lighting up when I move over it
<jbailey> No, it just lights up on hover.
<daniels> intriguing
<jbailey> A ghost of the text under the icon slowly crawls up with each highlight, though.
<jbailey> I think I can get a screenshot if you want.
<daniels> that would be pretty rad
<daniels> this is on the powerpc, yeah?
<jbailey> Yup
<daniels> i think texture uploads there are just utterly screwed
<jbailey> http://people.ubuntu.com/~jbailey/Capture.png
<infinity> jdong: That didn't get auto-given-back due to a bug in sbuild that I've since fixed.
<infinity> jdong: I'll do a mass-give-back in breezy-backports for you.
<jbailey> daniels: Interesting things here are that everytime I exit or leave the icon, a new text is created.  So one for insert, one for removal.
<jbailey> Also that you can see from the gnome panel at the bottom that the whole thing is already offset some.
<lamont> jdong:   Section             : unknown
<jbailey> And if you look at that Capture-2.png icon near the bottom, you can see that the corruption gets quite extreme after a while.
<jbailey> And then suddenly it will all behave correctly.  No offsets, no corruption or anything.
<lamont> jdong: --> comix needs to be added to the breezy-backports overrides file before it will successfully build (since it's not in main...)
<jbailey> And a crash will happen soon after.
<lamont> unknown gets lumped into main, knowing that it's probably wrong.
* jbailey does a quick double check of the icons on that page to make sure there's nothing too horrible on there.
<infinity> jbailey: Can it really be much worse than your usual screenshots?
<jbailey> infinity: It was more the "make sure I don't actually have customer data on there this time"
<daniels> jbailey: hm
<daniels> jbailey: i've got a pretty decent idea what this is, but fixing it is non-trivial
<daniels> jbailey: (as in, not going to happen without me shaking benh, which I'll do)
<jbailey> daniels: Okay.  Is there anything I can do aside from shut up, sit down, and wait? =)
<daniels> jbailey: try Option "XaaNoOffscreenPixmaps", maybe?
<jbailey> daniels: Is that under         Identifier      "ATI Technologies, Inc. Radeon 9600 XT (RV350 AR)"
<jbailey>  ?
<daniels> yeah
<daniels> sorry
<jbailey> Bounce to check that
<jbailey> daniels: Yes, that does it.
<daniels> jbailey: bingo
<daniels> jbailey: it won't be blazingly fast, but eh
<jbailey> daniels: Cool.  If there's anythign you need me to test, just fire me an email.  I'll try to come online before I head to bed.
<psusi> great... now it looks like the udf filesystem driver has problems...
<daniels> jbailey: will do; don't expect anything very soon at all though -- i haven't got a powerpc with r3xx, and benh has been banging his head against various issues related to this for ages
<psusi> it does not honor the uid,gid,umask params...
* psusi dives back into the kernel sources
<stratus> daniels, wasn't XaaNoOffscreenPixmaps block some optimizations? Isn't sidepanel option a better attempt?
<daniels> stratus: well, it disables part of the acceleration, yes.  and what's 'sidepanel'?
<daniels> jbailey: (also, exa might be differently broken for you; your call as to which is more tolerable.)
<stratus> daniels, panelsize, sorry
<stratus> daniels, i think  you already see but: https://bugs.freedesktop.org/show_bug.cgi?id=4294
<jbailey> daniels: I'm not particularily worried about tollerable right now, this has been broken for sometime.  Mostly I want to help you get the most correct solution possible for release.
<daniels> stratus: we never manually specify PanelSize
<daniels> jbailey: cheers :) i'll ping you if I have anything more useful
<jbailey> daniels: Thanks.  g'night!
<daniels> jbailey: basically the swappers are pretty hopelessly fucked on r3xx
<stratus> daniels, weird maybe Roger hit a different combination of options there
<stratus> daniels, he's a DD so the packages aren't that different and i informed you a bug forwarded from debian bts
<stratus> daniels, #318812 if you want to take a look
<daniels> stratus: yeah, I've perused the bug
<stratus> daniels, np thanks
<psusi> boy, this is retarded... chown only accepts 16 bit uids?  but the kernel uses 32bits?
<psusi> no.. looks like it does take 32 bit numbers... just won't accept 2^32-1
<psusi> wtf?
<lifeless> 0 is a valid uid, so what number represents an invalid one
<desrt> no such thing
<lifeless> well, twas a thought
<desrt> well, maybe you're right :p
<psusi> -1
<psusi> chown(2) won't take -1 as a uid
<psusi> very annoying
<lifeless> desrt: an in 2's complement, -1 is ... :)
<desrt> 0x[lots of fs] 
<desrt> :)
<lifeless> desrt: 2^bitwidth - 1
<lifeless> i.e. yes :)
<psusi> because it looks like the udf filesystem will not use the uid= mount option unless the file on disk is owned by -1... it's owned by root right now for some reason, and I can't chown it to -1 to get udf to use the mount option for the owning uid
<jdub> apt-get CLI fat-finger usability issue: u and y are right next to each other on the keyboard ;-)
<daniels> dist-upgrade?
<daniels> er, dist-ypgrade
<jdub> when using -u
<jdub> -uy == eek!
<SEJeff> jdub, *cough* dvorak
<fabbione> morning guys
<FireRabbit> hey
<FireRabbit> i am maintaining my own apt repository .. and I use dput/debarchiver to add new packages to it... anyone know how to *remove* packages?
<seth_k|lappy> FireRabbit, I just remove the files and then call dpkg-scanpackages, not sure if that will work for your setup
<FireRabbit> hmm.. well dput is configured to run debarchiver with -x.. according to the man page that runs apt-ftparchiver not dpkg-scanpackages?
<FireRabbit> i wonder if maybe i can just remove the files and call debarchiver
<lifeless> I hate evo
<lifeless> hung on a futex.
<FireRabbit> seth_k|lappy, so there is no tool that will actually do the deleting for me?
<seth_k|lappy> I'm unsure, FireRabbit.
<FireRabbit> is there a debian devel channel i could ask in?
<lifeless> #debian-devel
<FireRabbit> oh.. didnt show up in the channel list
<FireRabbit> thanks :)
<psusi> YES!
<psusi> I patched mkudffs and cdrwtool to set the uid and gid for the root to -1 and rebuilt the package
<psusi> and it works... hehe
<jdub> mdz: ping
<ajmitch> elmo: please sync pngwriter, positron, albatross and vblade, dropping changes.
<jdub> mighty vblade~
<jdub> !
<daniels> man
<daniels> irssi CLI usability issue: ~ and ! are too close together
<jdub> heh
<jdub> lordy, xmltv is perl-a-go-go
<fabbione> ajmitch: are you sure about vblade?
<fabbione> ajmitch: it was on my todo list of pkgs to check for today
<jdub> daniels: do you know anything about rage128 tv out support on ibooks?
<daniels> jdub: 'not'
<jdub> heh
<ajmitch> fabbione: I was requesting the sync for stevenk, it wasn't an indepth look
<fabbione> ajmitch: ok
<daniels> jdub: i never really got atitvout to do anything useful for me
<fabbione> i got tvout working
<fabbione> but that was on i386
<fabbione> i could test ppc tho
<daniels> with r128, and ibook?
<fabbione> daniels: is there any reason why we don't ship the theater modules from the ati driver?
<daniels> fabbione: 'i forgot'
<fabbione> daniels: ehehhe
<jdub> theater?
<daniels> i've got that fixed locally, when I bump to 1.0.0
<fabbione> jdong: tvin/out
<daniels> or whatever
<daniels> jdub: yeah
<jdub> oh :)
<daniels> jdub: except it doesn't really work on anything except the aiws that no-one has, because gatos are, um, gatos
<jdub> did gatos change names, or is this something else?
<daniels> gatos merged into xorg
<fabbione> not even all of it
<fabbione> only a portion
<daniels> which caused all sorts of havoc when we realised that it locked up most non-aiw cards, because obviously the only people who tested gatos were people with aiws
<daniels> fabbione: well, all their ati.2 stuff, no?
<fabbione> daniels: not sure 100%, the gatos site still reports some features as not merged/not working
<fabbione> like tvout on some cards
<fabbione> or tvin
<fabbione> can't remember
<fabbione> the only way i managed to get tvout was removing all the other monitors from the machine
<fabbione> at that point tv was the only one
<fabbione> detected and configured
<fabbione> and that is working fin
<fabbione> fine
<fabbione> other setups are hitchy
<fabbione> but right now i can only test ppc
<fabbione> the i386 card is slammed in the hppa (by mistake) that's located underneath 3 layers of computers
<daniels> afaict they only merged tv in because tv out is still really really sketchy
<daniels> i used to care about such things, but I'd be lying if I said I did anymore
<fabbione> actually... 4 layers
<StevenK> fabbione: vblade looks like it can be synced - the package in Debian is based on what you did for Ubuntu.
<jdub> StevenK: you still at ursys?
<fabbione> StevenK: ok, i was only wondering if there are new upstream releases
<StevenK> Yup.
<StevenK> jdub: Still working there, and still at work actually.
<jdub> how's it going there these days?
<StevenK> Busy.
<fabbione> StevenK: so did you check for new upstream?
<StevenK> fabbione: I haven't. I will when I get home.
<fabbione> StevenK: ok thanks
* StevenK runs out the door.
<dholbach> good morning
<jdub> i bet mythtv-common doesn't actually need pwgen and ttf-freefont
<jdub> Keybuk!
<jdub> dholbach!
<dholbach> hellas jdub
<jdub> Keybuk: usability note for init scripts and usplash -> lack of "ok" on any line makes neophyte users anxious
* dholbach hugs Keybuk
<Keybuk> morning
<Keybuk> jdub: yes, I would expect it would
* Keybuk hugs dholbach back
<Keybuk> good crimbo and new year?
<Keybuk> jdub: if you're referring to the missing one in the udev scripts, I don't know why it doesn't print the ok ... there's the right call for it.  I suspect usplash bug
<Keybuk> it doesn't print a fail either
<infinity> Keybuk: usplash has a bit of a race, where if your init script is blindingly fast, you won't get your output.
<infinity> Keybuk: Whether or not that's your issue, I dunno.
<Keybuk> it's the opposite, that bit takes a few seconds
<Keybuk> ~15s
<infinity> In that case, it's not a usplash issue...
<infinity> You're not backgrounding or something, and expecting to print the OK after other scripts have run? :)
<jdub> Keybuk: doesn't it fork and return very quickly though?
<Keybuk> nope
<infinity> (If so, you should just "OK" on fork)
<Keybuk> the point of that call is it's the program that waits for the backgrounded stuff to complete
<infinity> (Are we all talking about the same script, by the way?)
<Keybuk> I assume so
<Keybuk> the udev startup script usually doesn't print an "ok" for the "Detecting and activating hardware" bit
<Keybuk> never has
<infinity> I'd have to reboot to see which one I don't get an OK on, but it'd bean a longstanding bug.
<Keybuk> I've not bothered about it because it's cosmetic at best
<Keybuk> funny thing is it does print it if you don't use usplash
<Keybuk> so somewhere the log_end_msg bit doesn't reach usplash
<Keybuk> but appears fine on the console
<infinity> Hrm, that script is buggy in other ways.
<jdub> networking does the same thing
<Keybuk> it is?
<Keybuk> jdub: networking doesn't anyway atm, gonna do that stuff at the sprint in Jan
<infinity>  /etc/init.d/udev start shouldn't "fail" if udev is already started (say, on my running system)
<jdub> Keybuk: yay
<Keybuk> infinity: damn well should
<Keybuk> you shouldn't try to start udev on a running system :p
<infinity> Not according to both policy and the LSB.
<Keybuk> I disagree with both
<Keybuk> it does that by design
<Keybuk> it's an rcS script, not a daemon
<infinity> Then print "* udev already running... [ ok ] " and exit 0.
<Keybuk> no ;)
<Keybuk> that bit of policy only applies to rc2
<Keybuk> it's fine exiting 1, in fact, it's better; it tells people they shouldn't have done that
<Keybuk> "udev already running" could persuade people to do "udev stop" which will utterly fuck their system
<infinity> But they can do anyway.
<infinity> And they may do, right after the "failed" start.
<Keybuk> sure, but there's absolutely no reason for the fully message
<Keybuk> and those "use log_* for fluffy messages" are bugs too, imo
<Keybuk> "echo" is sufficient if you want it printed on the console
<infinity> If you consider it fluff, then exit with no text if it's running already. :)
<infinity> I was just suggesting changing the text if it's running, not adding more.
<Keybuk> if you can find an actual bug or problem with it behaving like it does, I'll consider it ;)  but I think it's fine as it is
<Keybuk> it's a startup script, not a daemon start/stop init script
<infinity> (Then why does it have a restart target that appears to do something useful)?
<Keybuk> because I was trying to put useful things in there :p
<Keybuk> amusing, that restart target has a bug
<Mez> bit early for you isnt it Keybuk ?
<Mez> or are you in a random country again ?
<dholbach> "the early bird..."
<Keybuk> heh, nope; I like waking up before sunrise
<Keybuk> and gonna try and do a split day this year; up early so I can catch the aussies, have a long lunch at the gym, then start again in the afternoon to catch the yanks :)
<Mez> Keybuk - lol - fair enoug h :D btw - did you see my patch to signkey.pl (and we still have to meet up for a beer at some point!)
* Keybuk cries at daniels
<Keybuk> and he said we'd still be friends, and that it wouldn't be awkward
<jdub> haw haw haw
<Mez> wow - people are actually here :D
<Mez> oh, and jdub: unping :P
<Keybuk> Mez: I can see it in my INBOX.  I haven't read e-mail for a few weeks now, so I have a *lot* of it to go through today
<Keybuk> in fact, expect me not to finish dealing with e-mail until the end of the week
<Mez> lol - basically I patched your script to clean signed keys :D tis shiny :D lol :D
<Keybuk> fair enough, publish away
<Keybuk> that script's MIT I think
<Mez> yeah it is - lol - I just sent you a copy of the patch (though I've modified since then0
<Mez> lol :D 
<Mez> so 1) it doesnt export all the sigs accidentally and 2) so it checks for pgp-clean :D lol - I'm only publishing the patch anyways
<Keybuk> I had objections to the whole idea of sending "clean" PGP signatures, but I can't remember what they are
<Mez> lol - fair enough - I think that was your excuse at UBZ too :D
<Mez> lol
<Mez> so - you up for grabbing a beer at some point seeing as you're in england now ?
<Keybuk> sure
<Keybuk> I might actually try and get to a WolvesLUG again this month
* Mez doesnt get a chance to goto lug meetings
<Mez> lol
<Keybuk> you should, it's fine; there's lots of beer, curry and aq
<Mez> Keybuk - well - I have this weekend off :D lol
<jdub> AQ ATTAQ!
<Mez> but if you ever fancy bringing the LUG to a casino - head to dudley :D and you can see me at work
<Mez> and Aq... is... hmm - sorta scary :D lol
<Mez> I'm assuming you'll be at LRL this year ?
<Mez> brb
<Treenaks> I will be :)
<Mez> have to go kill the *********** that's downloading crap over the network and blocking everyones net connection :D
<Mez> Treenaks, I know :D lol
<Treenaks> Jono asked me to describe the crack that will be going into dapper+1 ;)
<jdub> ( | )
<jdub>   ^ dapper+1 crack
<Keybuk> yeah, most likely; if it isn't at a time I'm out of the country
<jdub> Treenaks: MULTIARCH!
<Keybuk> dholbach: oh, I came up with a motto for you guys btw ... "Magister mundi sum" :p
<dholbach> Keybuk: you think we're that elite? :-p
<Keybuk> you guys rock the world
<ajmitch> 'you guys'?
<Keybuk> motu
<ajmitch> ah
<jdub> ajmitch: the german football team.
<jdub> *cough*
<dholbach> hahahaha
<Keybuk> jdub: dude, not at this time in the morning ;)
<Mez> Keybuk: when's hct planning on being released for public usage
<Keybuk> not for a while
<jdub> really?
<Keybuk> it needs bzr to be stable first
<Keybuk> yeah, too many moving pieces, and people keep getting the fingers caught in the cogs
<Keybuk> the last decision was that we'd stall it until dapper+1 when bzr and lp are a more stable base for it
<Mez> :(
<jdub> ahr
<Mez> I was looking forward to it too :D
<Mez> lol
<Keybuk> there's not a huge amount of hct development work left, just lots of dot joining 
<Keybuk> but we're gonna wait for the dots to be in the right places first :)
<jdub> at least the dots aren't being shot by fully automatic revolving shotgun turrets
<jdub> now
<Mez> jdub: why not - that'd be cool
<Keybuk> Mez: it depends where you're standing
<Burgundavia> what is is about ubuntu-devel that screams "Please take my bug report now!"
<Mez> Keybuk, behind the guns - of course - or in the targeting seat *winds the cogs*
<jamesh> Burgundavia: it is a support escalation service, right?
<ajmitch> jamesh: no, it's somewhere to complain about how thinly spread we all are
<Burgundavia> jamesh, I am talking about the random community members who tell us about problems
<ajmitch> Burgundavia: in excruciating detail, at times :)
<Burgundavia> yes
<Burgundavia> I appreciate their enthusiasm, just not how it is directed
<Burgundavia> I noticed that on Fedora-devel they don't shut those people down and it seems that is more like -support
<jdub> that's because there's nothing else to do there ;-)
<Burgundavia> ouch
<dholbach> what happened to the amd64 buildd?
<ajmitch> some of those threads will have to stop soon if -devel will be readable
<jdub> we should make sure our responses always include "this might be more appropriate on ... list"
<jamesh> Burgundavia: I realise that it isn't ubuntu-support, but the developers read ubuntu-devel, so they are more likely to see and respond to my problem if I ask on that list
<jamesh> Burgundavia: (and naturally, my problem is more important than the other problems reported through the standard channels)
<Burgundavia> jamesh, indeed
<jdub> it's *okay* to say "we have a legitimate difference of opinion - we appreciate your feedback and contribution"
<infinity> dholbach: More detail than "what happened" would be nice. :)
<infinity> dholbach: If you're referring to that crazy glibc error, a mass give-back will be happening later today to retry everything, once some dust has settled.
<dholbach> infinity: ok, in the evolution build log, python2.4 doesn't seem to be installable because of some "inconsistency detected by ld.so"
* dholbach hopes it settles :)
<infinity> dholbach: Yeah, that's fixed.  FWIW, all the other arches would have the same problem right now, if they weren't all shut down. :)
<dholbach> i'll do the package updates on i386 then ;)
<infinity> amd64 is the only arch building, while I sort some holiday fallout.
<Mez> infinity - any idea why I'm not getting email from katie? (and are you the person to talk to ?)
<infinity> Mez: No and no.  But which mail are you expecting to see?
<Keybuk> I _almost_ have all three architectures now \o/
<Mez> infinity - anything - NEW REJECTED, ACCEPTEd
<Mez> not getting ANYTHING from katie :D havent done since september
<infinity> Mez: For sources or binaries?
<Mez> Sources
<infinity> Mez: You won't get mail for binaries ever.
<Mez> inifinty - I've never uploaded binaries :d
<infinity> Mez: If it's for sources, then you're probably uploading with an email address that isn't in the whitelist.
<Mez> infinity, - mez@ubuntu.com
<dholbach> Mez: elmo will know who's in the whitelist
<infinity> Mez: Oh.  *@ubuntu.com is whitelisted, AFAIK.
<Mez> which should be auto-whitelisted - should it not?
<ajmitch> Mez: overaggressive spamfilters somewhere along the line, perhaps
<Mez> ajmitch: hmm - i'll chekc i have spamassasin off - but - hmm .... it worked before :P lol - in septemerb and i havent changed anything
<Mez> though if spamassasins on - I can guess the rules were auto-updated
<Mez> Spam Assassin is currently: disabled 
<Mez> hmm
<ajmitch> not just on your local box, I mean
<Mez> ajmitch, no, it should goto the junk folder
<Mez> but theres nothing from katie in the junk folder
<Mez> nor in any other folder
<Mez> it's very annoying
<Mez> specially when i dont get rejects :D so i dont know if it's been rejected or NEW'd
<Mez> I have emailed elmo - but i guess he's in the same situation as Keybuk regarding email
<infinity> Most of us are, yes.
<Keybuk> I shouldn't expect elmo is up yet either ;)
<Keybuk> it's about 7 hours too early for him
<Mez> I emailed him 3 days ago :D
<Keybuk> this is the first year I've had so much e-mail
<Keybuk> I've taken a new policy of not going near computers when I'm not "at work"
<Keybuk> so they've all been turned off all holiday
<infinity> Yeah, I did the same.  I'm now regretting it.
<Mez> lol
<Keybuk> I'm rather happy with it, I feel like I've actually had a holiday
* ajmitch was happy to be away from computers altogether for a week
<infinity> Well, yes, that bit was nice.  The consequence this morning was not.
<jsgotangco> lol
<Keybuk> heh, I once decided on returning from a 3-week holiday to delete all my e-mail on the basis that anything important would get nagged again :p
<infinity> It's like some sort of horrible electronic hangover.
<Keybuk> this didn't work so well
<jdub> infinity: i find that makes it really hard to feel rested - as soon as you get back, you have the stress of so much in one hit
<Keybuk> jdub: yeah, I'm going to do a folder a day or something, so it's not one hit
<Mez> I forgot to suspend my mailing lsits while I was away - came back to 10,000 new emails
<jsgotangco> i still like taking small doses everyday
<Mez> :()
<Mez> :( *
<Keybuk> fortunately there isn't actually a huge amount anyway, certainly a lot less than any other two weeks in the year
<pitti> Good morning
<ajmitch> morning pitti 
<Keybuk> morning pitti
<pitti> hi ajmitch 
<Mez> morning pitti :D
<Mez> (everyone else was doing it - I just wanted to be popular)
<pitti> hi Mez 
* Mez feels poular
<Keybuk> you can get a cream for that
<Mez> Keybuk - where from - I've been looking for ages ... cant find any
<ajmitch> Keybuk: do you have the MoM source somewhere?
<Keybuk> yes, I do
<ajmitch> somewhere publically available & published, that is
<Keybuk> no
<Keybuk> I'll prod Mark again, I mailed him a while back asking for permission to open it
<Keybuk> it probably vanished in the million-mails-a-day of his INBOX
<Burgundavia> Keybuk, email Claire. It probably has a higher chance of actually getting to him
<jdub> Burgundavia: you just sent a reply to ubuntu-users and ubuntu-users-owner
<Burgundavia> jdub, hmm, ouch
<Burgundavia> jdub, I just sent to -owner
<Mez> jdub- btw - were you getting bounces from my email address for dapper-changes ?
<sivang> morning everybody!
<jdub> sorry, meant s/and/to/
<jdub> Mez: no idea
<Mez> lol - fair enough :
<Keybuk> probably the main problem is that the code isn't really "releasable" quality
<Keybuk> it's one huge uncommented python script
<Burgundavia> jdub, it came in through -owner and I responded to both him and -owner
<jdub> Burgundavia: oh
<Keybuk> with dependencies on hacky scraps of python written for other purposes and culted in
<Mez> Keybuk: uncommented huge scripts are always the most fun to break though
<Burgundavia> jdub, to prevent all of us responding with the same thing
<ajmitch> Keybuk: I don't mind, I just wanted to look at it & pick out anything useful
<Keybuk> though I guess that didn't stop us releasing Germinate, which was in much the same style <g>
<ajmitch> others might mind though
<jdub> Keybuk: at least Kamion writes good shitty code ;)
<tepsipakki> is my dapper the only one which is having interactivity problems.. the system feels quite sluggish, even though the hardware isn't (2.2GHz celeron, 512MB)?
<Mez> tepsipakki, -> support = #ubunut
<Mez> s/ubunut/ubuntu/
<jdub> UBUNUT!
<jdub> we own that domain
<Keybuk> jdub: heh, it was still largely my code for the first release
<jdub> we should do something rad with it
<jdub> LIES!
<Keybuk> jdub: Ubuntu fan page?  Let people post details of themselves and how they use Ubuntu and why they love it so much?
<tepsipakki> mez: just noticed last night that someone of you devels had some problems too.. but anyway
<Keybuk> you can have badges, "I'm an Ubunut!"
<jdub> Keybuk: yeah, was thinking along those lines
<Mez> Keybuk - I was thinking along those lines-  but I think we might get scary people
<jdub> Keybuk: maybe a blog service ;-)
<Keybuk> scary people are the most fun
<Mez> Keybuk - you'd know ;)
* Keybuk is scary, apparently
<Mez> yeah you ae
<Mez> specially with a microphone in your hand :d
<Mez> :-"
<Keybuk> a friend accused my new hair cut of being terrifying :-/
<jdub> SSHOT!
<jdub> SSHOT!
<Mez> Keybuk, been cut since UBZ ?
<sivang> Keybuk: yeah, any changes to it since the hair color ? :)
<Keybuk> yeh, I have a mohawk now :p  (I was drunk, it seemed like a good idea, and now I kinda like it :p)
<sivang> hehe
<Mez> mohawks are cool :D
* sivang googles for mohawks. (notices the word hawk part of it)
<jdub> is there a useful CLI tool for changing hostname post-install?
<Keybuk> jdub: vi /etc/hostname? :p
<jdub> other instances of hostname though
<jdub> though i guess we use localhost.localdomain
<jdub> man, under vmware, breezy installs lilo
<jsgotangco> huh?
<jdub> don't cry, baby jesus!
<Keybuk> where else would we embed the hostname?
<Keybuk> we don't ship an MTA anymore, which is the usual suspect
<Keybuk> /etc/hostname and /etc/hosts look like the only two places
<Mithrandir> hi Scott
<infinity> Tollef!
<Mithrandir> good morning, Adam :-)
<Mithrandir> 'sup?
<infinity> Not much, just rejoicing.  No computer for a week meant no Tollef for a week, which is clearly a bad thing.
<infinity> Or something.
<infinity> Or, I'm buttering you up, so I can reassign some bugs to you.
<infinity> YOU DECIDE.
<pitti> hi infinity, happy new year
<Mithrandir> yeah, I've been meaning to ask you when we can get squashfs builds going and such.
<Mithrandir> oh, what kind of bugs?
<infinity> Oh, I'll surprise you. :)
<infinity> And yes, squashfs sounds like fun.  Should we make a date to attack that Fridayish?  (post-meeting, post-holiday-catchup)
<Mithrandir> sounds fine with me.
<infinity> pitti: You too.
<Mithrandir> hopefully, jbailey will have the squashfs stuff in klibc by then as well, so we don't just end up breaking the CD.
<infinity> No one's stopping you from uploading with your patch.
<infinity> (hint, hint)
<Mithrandir> I thought jbailey did, and it FTBFS-ed on ppc due to lkh breakage?
<infinity> I have an odd feeling any distro time jbailey has to spend will be spent tracking glibc 2.3.6 bugs for the next 2 weeks.
<infinity> Oh, that's right.  Headers jumping around randomly, world confused.  I remember now.
<Keybuk> hey Tollef!  Happy new year, etc.
<sivang> happy new year infinity 
<dholbach> hellas mvo!
<Mithrandir> Keybuk: what do you think a sensible way to set up the network on the live cd would be, now that we don't do it in the initramfs any more?
<Keybuk> we don't?
<mvo> hey dholbach 
<Mithrandir> Keybuk: no, the initramfs just does the minimal stuff needed to boot the system now.  simplifiedlivecd.
<Keybuk> can we rewind a bit, I've missed the context of this :)
<Keybuk> go gently with me
<Mithrandir> currently, the network interfaces on the live cd are completely unconfigured.  Including lo not being upped.
<infinity> The old initrd was a cut down d-i instance that did most everything d-i does.
<infinity> Now it's just a regular old initramfs.
<Keybuk> Mithrandir: you're not running S40networking?
<infinity> I'm sure he is.  Of course, it doesn't work currently.
<Mithrandir> Keybuk: yes, but that doesn't do anything if you don't put anything in /etc/network/interfaces, does it?
* infinity still has to ifup eth0 over here.
<Keybuk> Mithrandir: true :p
<infinity> I've intentionally not fixed my interfaces(5) file to track when that bug gets fixed. :)
<Keybuk> infinity: yeah, that's deliberate; I'm going to work on that at the sprint
<infinity> Mithrandir: You could write an interfaces file if you're booting live... No reason why casper can't have an init script.
<infinity> But that breaks for people who want a static setup.
<Keybuk> in theeeeory, "ifup lo" will be handled by a separate early init script without relying on /etc/network/interfaces
<infinity> The real answer is "Gee, wasn't NetworkManager supposed to fix all of this?", but I still don't know if anyone has the round tuits to solve the "NM hates our way of doing things, and we hate it" issues.
<infinity> (where "all of this" doesn't include "lo", obviously)
<Keybuk> infinity: NetworkManager hates my Atheros
<Keybuk> I had some keen guy looking into it, but haven't heard back from him
<Keybuk> I suspect he hit the "oh gods, this is HARD" problem
<Mez> Keybuk, NM decided to cease to exist for me :D
<infinity> Keybuk: Well, I still have other fundamental issues with it.  Like, it needs a way to configure the "on boot" network settings, for instance (if you can become root).
<StevenK> fabbione: Yes, vblade 10 is out upstream.
<Mithrandir> it also needs to stop writing invalid resolv.conf files.
<infinity> So you don't log in, configure the network, log out, have Mom log in, and Mom can't get to the internet, cause her NM isn't configured the same as yours (or at all)
<Keybuk> infinity: agree
<fabbione> StevenK: ok, do you want to take care of it or should i?
<fabbione> StevenK: both ways i don't mind.. it's a small package
<StevenK> fabbione: I was just going to copy the debian dir from 5-0ubuntu2 and update the changelog.
<fabbione> ok whatever :)
<StevenK> fabbione: Does this mean you'll upload it for me? :-)
<fabbione> StevenK: whatever.. 
<Kamion> Keybuk: at least the installer no longer breaks messily due to no network plugging on reboot ...
<Kamion> so I can stop going "argh" about that one
<Keybuk> Kamion: morning!
<Keybuk> happy new year
<Keybuk> good crimbo, etc.
<Keybuk> ?
<Keybuk> Kamion: in theeeory, we probably want netcfg to write auto lines again, not whatever mess is popular this week; and that'd solve the problem temporarily
<StevenK> fabbione: http://wedontsleep.org/~steven/vblade
<fabbione> StevenK: ok thanks
<fabbione> StevenK: don't you have universe upload privileges?
<fabbione> i thought you went trough the process
<StevenK> fabbione: Nope.
<StevenK> I'm a member, but I haven't attended a TC meeting yet.
<Kamion> Keybuk: hmm, just want to make sure that the transition from all the various different things netcfg has ever written out will have a chance of working
<Kamion> will introducing another one be a problem? :)
<fabbione> StevenK: ah ok
<Keybuk> this is why I haven't done it yet;  gonna sort networking out at the sprint when we're all together
<infinity> Do you really want to be in hitting distance when this is sorted out?
<Keybuk> yes, I'm into that kind of thing
<Keybuk> I'll even bring the restraints if you like ;)
<infinity> It's more fun to watch you run and trip.
<infinity> Restraints are for lazy people.
<Keybuk> hmm, "I'm not a bottom, I'm just lazy" ... that's exactly what a friend of mine says
<jdub> Keybuk: hosts, motd (which is regenned though)
<Mithrandir> Keybuk: are the restraints to prevent you from running away or us killing you completely?
<Keybuk> yes :)
<fabbione> StevenK: uploaded
<fabbione> StevenK: did you also check aoetools?
<Keybuk> \o/ only 10,000 e-mails to go
<Keybuk> and damn, I _wish_ that number was an exaggeration :'(
<maswan> Keybuk: been on vacation?
<pitti> Keybuk: a tiny modification to your .procmailrc before holidays would have cured that :)
<Keybuk> maswan: xmas, new year, etc.
<Keybuk> pitti: heh, I don't have such a thing ... and people get upset if you /dev/null their mail
<pitti> Keybuk: what do you use instead?
<pitti> Keybuk: I know, procmail is kind of old skool, but I was grown up with it...
<Keybuk> subscribe to mailing lists as different addresses
<maswan> Keybuk: just skip on those pesky mailing lists? :)
<Keybuk> and then just have that address delivery straight into the right folder
<pitti> hmm
<Keybuk> ie. scott-canonical-ubuntu-devel@netsplit.com -> ./Maildir/.Lists.canonical.ubuntu.devel/
<pitti> Keybuk: I have such fancy things like 'only show me new unassigned bugs', that's certainly not possible just with addresses
<pitti> or filtering out MS office attachments
<Keybuk> right, I have a Python filter program to do that kind of thing in the mail delivery rules
<sivang> pitti: care to discuss those procmail improvements over a cup of tea? I think I need some of this cure :-)
<pitti> sivang: feel free to spy on /home/martin/.procmailrc on my server ;)
<sivang> pitti: will do , thanks
<Treenaks> pitti: Is mozilla-firefox-locale-nl-nl known broken?
<Treenaks> pitti: or should I file a bug?
<pitti> Treenaks: all m-locale packages seem to be ATM
<Treenaks> pitti: ok, so it's known :)
<pitti> Treenaks: yes, there are a lot of bugs already
<Treenaks> (also, firefox itself seems to be at 1.5rc3 while 1.5-final has been out for ages, but that might be on purpose)
<jsgotangco> heya sabdfl happy new year
<sabdfl> happy 2006 to you too!
<pitti> Hi sabdfl, how are you? happy new year
<sabdfl> managed to survive the slopes
<dholbach> happy new year, sabdfl :)
<sabdfl> 57 inches of snow in 7 days, it was a playground of note
<pitti> sabdfl: downhill skiing?
<sabdfl> snowboarding
<sabdfl> how's everyone here?
<pitti> ah, cool; I always enjoyed that
<jordi> sabdfl: hey
<jsgotangco> colorado
<jordi> sabdfl: so you're back in one piece: )
<sivang> happy new year sabdfl !
<sabdfl> jordi: no amputations this season
<seb128> Happe new year sabdfl !
<ajmitch> hi sabdfl 
<sabdfl> hey seb128, ajmitch
<jordi> sabdfl: good!
<fabbione> hey sabdfl !
<mdke> is there a Community Council meet today, or TB, or nothing?
<Keybuk> TB will be next week
<Keybuk> I updated the agenda not 5 minutes ago
<mdke> ah, sorry yeah just saw that
<mdke> so CC today then I suppose
<doko> seb128: hmm, bad upgrade time? dist-upgrade wants to remove gnome-panel ...
<seb128> doko: what else does it want to remove? what arch?
<doko> seb128: amd64, others to remove:   base-config evolution evolution-exchange evolution-plugins gnome-applets
<doko>   gnome-applets-data gnome-panel libcamel1.2-6
<seb128> that's amd64 lagging behind, yeah just wait for a buildd retry
<mdke> Kamion, is CC today?
<Kamion> mdke: think we're postponing it but I'm honestly too behind to know
<Kamion> it's my first day officially back, give me a break :)
<jsgotangco> lol
<mdke> Kamion, sure thing, didn't mean to bother ya
<Kamion> ah, sabdfl says in mail it's on the 10th, and to postpone TB by a week
<Kamion> Keybuk: ^--
<zyga> monring :--)
<doko> infinity: what is the plan with db4.x? stick with 4.3 or go to 4.4?
<zyga> Kamion: should I ping you about the three missing members later?
<Kamion> zyga: no
<Kamion> leave me alone and I'll do it :)
<zyga> great :-)
<Keybuk> Kamion: heh, confusing ;)  but fair enough, will update the TB time
<Keybuk> done
<mdke> Kamion, what time on the 10th? (I'll update the wiki page)
<Kamion> mdke: no idea
<Kamion> oh, yes I do, 1500 UTC I think, but Seveas has mail about that and has been asked to update the agenda already, so just leave it :)
<mdke> alright, thanks
<Kamion> zyga: I have no record of you being approved; mako didn't say yes
<Kamion> we had two +1s out of a required three
<Kamion> sabdfl: ok with zyga for membership? we had an incomplete discussion in http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2005-12-06.html that had elmo and I both saying yes
<sabdfl> +1 on zyga
<sabdfl> welcome aboard :-)
<Kamion> thanks
<jdub> morning sabdfl, good break?
<zyga> sabdfl: thank you :-)
<sabdfl> jdub: yes thanks. you and the missus get some r&r time in?
<ajmitch> zyga: well done :)
<zyga> :-)
* zyga feels happy
<sivang> welcome aboard zyga 
<Seveas> lol, very short ad hoc CC meeting :)
<ajmitch> elmo: please sync python-setuptools from sid, dropping changes thanks
<mjg59> Keybuk: Around?
<jdub> sabdfl: yep, hot and sweaty it was.
<infinity> doko: I wouldn't mind a switch to 4.4, but it needs some thinking.  Maybe we should talk about it at the sprint.  That'd an ideal time to discuss mass uploading to switch, if we want to.
<ogra_ibook> infinity !
<ogra_ibook> happy new year 
<infinity> To you too.
<Mithrandir> infinity: any chance I could get a new livefs build with user-setup added to the image?
<Mithrandir> infinity: or should I just do it myself?
<ogra_ibook> infinity, i have a small attack waiting for the initramfs maintainer ... could you have a look at http://bugzilla.ubuntu.com/attachment.cgi?id=5494 if thats ok ? i need it to have images small enough to netboot ppc
<ogra_ibook> (for ltsp that is)
<infinity> ogra_ibook: Why add the raid and i2o_block modules if it's for booting without block devices?
<infinity> Or usb_storage..
<ajmitch> elmo: please sync pyxmms-remote from sid, dropping changes.
<ogra_ibook> infinity, thats what i wanted to hear :) i wasnt sure if we'd need them for local device support at some point, but udev should care anyway
<fabbione> ogra_ibook: that patch is no good.. the problem is not initramfs
<fabbione> ogra_ibook: the problems are ppc kernel udebs too big
<ogra_ibook> fabbione, i dont need any block device support in initramfs for netbooting
<StevenK> fabbione: aoetools 8-0ubuntu1 building.
<ogra_ibook> fabbione, its not only the yaboot restriction
<fabbione> that's something has been discussed already with Kamion and we need to solve it in a more general way
<fabbione> StevenK: cool
<ogra_ibook> fabbione, i still need a smaller initramfs for 32MB clients
<fabbione> ogra_ibook: meh ok
<ogra_ibook> so dropping cblockdev support is the best imho
<ogra_ibook> since udev will load whats needed post boot ...
<infinity> fabbione: Regardless of the other PPC/yaboot issues, a "noblock" mode for initramfs makes sense to me.
<infinity> (as does a "no network" mode, for local-only booting)
<ogra_ibook> we could also call it "netboot" 
<ogra_ibook> i'm not sure about the "noblock" name
<infinity> Meh, it'll get a good name when I integrate it.
<fabbione> infinity: i am not 100% sure you can kill everything... 
<fabbione> but well
<infinity> Don't worry about that.
<ogra_ibook> oki :-D
<infinity> fabbione: initramfs doesn't do anything that the boot process doesn't duplicate again later.  If all we need to boot from a network is a NIC (which is generally true, give or take), then we can leave the rest for runlevel S.
<fabbione> infinity: right
<fabbione> make sense
<StevenK> fabbione: http://wedontsleep.org/~steven/aoetools
<Mithrandir> infinity: also, any thoughts on usplash-in-initramfs?
<fabbione> StevenK: i am on it, thanks
<fabbione> StevenK: uploading
<fabbione> Successfully uploaded packages.
* Mithrandir throws a lump of rock at infinity to catch his attention.
<infinity> Mithrandir: Doesn't require much thought to do the dirty hack I originally spec'd... If you have designs for something more elegant, I'm all ears.
<Mithrandir> infinity: what's your dirty hack?
<infinity> Mithrandir: If you don't already know, you don't want to.
<infinity> Mithrandir: Suffice it to say, it'll work fine, I just need to upload it.
<infinity> Mithrandir: Perhaps around the same time we have that squashfs date, if I don't get to it tomorrow.
<infinity> (Playing catch-up with buildd headaches could monopolize tomorrow)
<Mithrandir> infinity: 'k..
<Mithrandir> infinity: bah, silly buildds.
<Mithrandir> whack them with a hammer. 
<maswan> Mithrandir: you mean like FlerpIT.com Security Solutions? http://www.acc.umu.se/images/archive/20010821-FlerpIT.com-Security/
<Mithrandir> maswan: yeah, sometihng like that
<Kamion> fabbione: the stuff that's been discussed with me is entirely separate
<Kamion> fabbione: we've talked about d-i; ogra's talking about the LTSP initramfs, which has nothing to do with udebs. It should never have been in the same bug in the first place
<fabbione> Kamion: ok
<ogra_ibook> fabbione, thats why i only posted the link to the attachment, not to the bug ;)
<zyga> what's with current dapper kernels, why cpu frequency scaling is not active?
<Nafallo> zyga: is here
<zyga> Nafallo: hmm, doesn't work on k7
<Nafallo> I have k8 :-)
<mjg59> zyga: Will be fixed in the next release
<zyga> mjg59: thank you :)
<mjg59> It was disabled in SMP kernels, even if there was only one processor
<mjg59> And we only ship SMP kernels now
<zyga> oh, so will there be smp kernel with cpu freq scaling or non-smp kernels too?
<infinity> Erm, frequency scaling is still working for me.  It just doesn't show up correctly in /proc/cpuinfo.
<infinity> The /sys tree still shows the cur_freq going up and down with load.
<zyga> infinity: I'll check
<infinity> sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
<zyga> infinity: I have no cpufreq in my sys
<zyga> so it seems disabled
<infinity> Shows at 800MHz right now.  If I pump my load up, it jumps up to 2.0 GHz.  Then scales back down slowly to 800 over time.
<Lathiat> zyga: is powernowd running?
<zyga> no
<infinity> Yeah, it won't be if the /sys tree isn't there (ie: If there's no kernel support)
<zyga> it said: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory
<infinity> So maybe the k7 kernel is wonky, compared to the 686 kernel (which I'm using)
<mjg59> infinity: On a K7?
<mjg59> The issue is K7 specific
<mjg59> All other cpufreq should be working
<infinity> mjg59: Ahh, check.  I'm on a Pentium-M.
<slomo> elmo: please sync ipod-sharp from debian/experimental, thanks :)
<slomo> infinity, lamont: please give-back njb-sharp on ia64/amd64 and remove gnunet from dep-wait... thanks :)
<infinity> slomo: There will be a mass give-back in about 12 hours to deal with holiday fallout.  Your still will end up in that batch. :)
<slomo> infinity: ok, thanks... btw, did you already read tseng's mail about the mono breakage on ppc? any ideas on this?
<jbailey> mjg59: Does cpufreq not go into SMP kernels because it's two hard to keep the two CPUs in sync?
<mjg59> jbailey: "too"? :)
<lamont> slomo: please fix njb-sharp and re-upload
<jdub> haw haw
<jbailey> mjg59: Right.  Sucks to be an audio thinker sometimes. =)
<lamont> it Build-Depends: cdbs (and probably others), not build-depends-indep.
<mjg59> jbailey: Not all SMP architectures handle CPUs with different clock speeds
<mjg59> I think K8 and P4 can manage it
<jbailey> Ah, cool.
<Mithrandir> mjg59: sparc too, but not under linux.
<jbailey> I was wondering a bit last week if there was any way of having my boxes consume less power.  Part of why I was playing with suspend on my desktop machines.
<slomo> lamont: uh, sorry... uploaded fixed version
<lamont> that would be the source of the "mysterious" build failure
<Mithrandir> infinity: any reason why you're not on #d-apache?
<lamont> depwaits on libmysqlclient15-dev cleared, although I don't see it anywhere in the archive at a quick glance....
<lamont> jbailey: smaller pixels. :-)
<jbailey> lamont: Well, white on black text *must* consume less power, right?
<lamont> red on black would only use 33% as many pixels, I'd think.....
<pitti> jbailey: depends on whether an enabled or disabled crystal consumes more, but I think an enabled one uses more
<mjg59> Black on white ought to take less power on a TFT
<lamont> winona suggests removing files to make the laptop lighter, too. :-)
<pitti> jbailey: so, surprisingly, black on white should be more efficient
<jbailey> Hah, funny. =)
<jdub> mjg59: and better contrast
<mjg59> pitti: Any chance you can take a quick look at libpam-foregound for security purposes?
<pitti> lamont: right, mysql-dfsg-5.0 is still not synced to Ubuntu (which builds mysqlclient15)
<mjg59> jdub: Hush
<pitti> mjg59: could you please mail me a link to the diff? I'd like to do it today, but not right now
<lamont> pitti: is it going to be soon-ish?  (like before uvf?)
<pitti> lamont: I seriously hope so - we actually planned to have 5.0 as default and only version in dapper main
<pitti> I just wonder why it doesn't autosync
* lamont bets "NEW"
<pitti> lamont: but it is in Debian for months...
<slomo> lamont: it depends on libmysqlclient14-dev now until we get 15... the same was already done for a few other packages
<ogra_ibook> hi
<ogra_ibook> oops, ECHAN
<pitti> ogra_ibook: it's not entirely OT to say 'hi' here (at least I hope so :) )
<ogra_ibook> heh
<ogra_ibook> hi pitti :)
<infinity> pitti : I'll be sorting out MySQL 5.0 early next week, I believe.
<infinity> Mithrandir: Not on a lot of channels until I get home from the tropics.  Right now, I'm just in the minimum required channels to work.
<Mithrandir> infinity: ah, ok, I didn't know you were still on a beach.
<seb128> ogra: do you know about http://bugzilla.ubuntu.com/show_bug.cgi?id=21795 ?
<seb128> ogra: the guy mailed me, he wants to switch 60 school computer to Ubuntu but is blocked because of that
<tepsipakki> hm, /proc/meminfo output is incomplete, which is probably why "top" doesn't show memory usage
<ogra_ibook> seb128, we dont support ltsp 4.1 at all
<ogra_ibook> seb128, our supported ltsp implementation doesnt use xdmcp ...
<seb128> ogra_ibook: could you reply on the bug please?
<ogra_ibook> yup, will do
<seb128> I don't know much about ltsp
<seb128> thanks
<ogra_ibook> i'll also reassign it if you dont mind loosing a bug :)
<Mithrandir> uhm, how do I rename a page on the wiki=
<Mithrandir> s/=/?/
<maswan> What's the correct way of pointing out meta-bugs in the wiki? ("Otherwise, if "Rename to" is left blank, the original filename will be used." but it is "save as", not "rename to")
<ogra_ibook> Mithrandir, look at the pulldown menu
<Mithrandir> ogra_ibook: thx
<seb128> ogra_ibook: not at all, thanks :)
<tepsipakki> disregard my top-problem, the problem was in my head
<maswan> Keybuk: there you go, while I had flight2 installed for a daniels-bug, I gave you a bootchart too
<jdub> BenC: hrm, now i remember what i really wanted to ask you about
<jdub> BenC: i noticed on my MIL's IBM T42 that the new -10 ABI breezy kernel (security update) was hanging in difficult to accurately reproduce ways, while -9 wasn't.
<BenC> jdub: 20771
<BenC> jdub: CC yourself and join the testing effort :)
<jdub> oh
<jdub> weird thing is, pia has the same machine, is running -10, and afaik hasn't had any crashies
<BenC> it's a very odd problem...fabbione even went back and recompiled -9.23, and people were still seeing problems with that
<BenC> it's like breezy suddenly went broke for no reason, and very randomly
<fabbione> i blame binutils
<BenC> yeah, I think binutils will take the rap for this one too
<jdub> hrm
<fabbione> i need to ask elmo to dig the old binary package for me
<fabbione> and try to build with that one
<jdub> i'll find out if pipka's had problems wiht hers
<jdub> then i'll have a machine toplay with locally
<Mithrandir> elmo: please sync ttf-unfonts, overriding ubuntu changes is ok.
<zul> fabbione: i blame <deity>
<fabbione> zul: heheh
<zul> hi fabbione btw :)
<fabbione> yo
<zakame> evening devs :)
<rob^^^> howdy
<mjg59> pitti: Any idea how to deal with the MMC card problem? pmount (and, presumably, hal) seem to want the removable flag to be set in order to automount stuff, but the kernel people disagree
<pitti> mjg59: hm, a device must either be hotpluggable, or removable for that
<pitti> but MMC cards being removable sounds right to me? because they actually are
<pitti> and the reader itself isn't hotpluggable
<mjg59> pitti: The reader is a PCI device
<pitti> yes, internal readers are quite common
<pitti> but e. g. cdroms are 'removable', so we can pmount them
<pitti> why don't the kernel folks treat MMC cards as removable?
<elmo> Kamion: ?
<Kamion> elmo: hi
<mjg59> pitti: "GENHD_FL_REMOVABLE should be unset for removable block devices with permanent media"
<mjg59> pitti: In the CD-ROM case, the block device is always there but media appears and goes away
<mjg59> pitti: But in the MMC case, the block device only appears when the card is inserted
<pitti> hm, I see
<pitti> is there anything else in sysfs that tells apart a MMC device from a normal HD?
<elmo> Kamion: what's a good dapper CD to use?  I've got a laptop where I need wireless and breezy isn't giving me no love
<elmo> ISTR you said latest would be "fun"
<Kamion> elmo: fun in a good way
<Kamion> yesterday's was fine when I tested it
<elmo> ok
<Kamion> today's should be OK too, I think
<mjg59> pitti: Not that I can see
<Kamion> er, apart from being uninstallable
<Kamion> yeah, try yesterday's
<pitti> mjg59: *scratching head*
<mjg59> pitti: This may have to be something that's dealt with upstream
<pitti> mjg59: maybe they can add another attribute then; 'hotpluggable' would be nice
<pitti> mjg59: right now, pmount defines hotpluggable as 'is attached to an USB or FireWire bus'
<mjg59> pitti: Fancy taking this up with the kernel people, then? :)
<pitti> yes
<mjg59> What's the easiest way to give you the sysfs contents?
<elmo> also, anyone know what I have to do to get an i915 to use the external monitor?
<mjg59> elmo: Video switch doesn't work?
<elmo> mjg59: wassat?
<pitti> mjg59: looking in /sys/block/sda should be fine
<mjg59> elmo: Is there no hotkey on the keyboard to trigger switching?
<mjg59> pitti: Uh, it's not a SCSI device
<pitti> yes, /sys/block/hdc/, or whatever
<mjg59> pitti: Tarred up?
<pitti> mjg59: if there is anything interesting in it, sure :)
<mjg59> pitti: Ok, tar works really badly on sysfs
<mjg59> pitti: Right, sorted. Shall I just attach this to the bug?
<pitti> mjg59: that would be nice; which bug is it in particular/
<pitti> ?
<mjg59> #21767
<elmo> mjg59: hmm, nope, doesn't seem to
<mjg59> elmo: Right. Hm.
<mjg59> elmo: i810switch might do it
<elmo> ah, right, that's the name, I'll try that, thanks
<mjg59> elmo: Alternatively, there's a patch to add support to 1855crt at http://sourceforge.net/tracker/?atid=647739&group_id=107484&func=browse
<janimo> elmo, any news on the xubuntu-docs still in NEW vs GPL licensing issue?
<janimo> do NEW (source) packages in debian require explicit sync requests or they come in automatically
<Keybuk> mjg59: you ping'd?
<mjg59> Keybuk: Can we chat briefly about NetworkManager at some point?
<Keybuk> sure
<jsgotangco> yay!
<zakame> janimo: hm seems they do come in automatically
<janimo> zakame, ok thanks
<mjg59> Keybuk: Am I right in thinking that the major sticking point now is what it does on startup?
<Keybuk> no
<mjg59> Keybuk: Ah. What was the issue, then?
<Keybuk> the major sticking point is that it doesn't support or work with one of the most common wifi cards
<elmo> mjg59: oh, wow, shiny
<mjg59> Keybuk: That being?
<Keybuk> Atheros
<mjg59> Uhm. It's bloody well meant to.
<Keybuk> nope
<elmo> mjg59: i810switch "works" in as much as it turns the monitor on, but all that's displayed is an ever-brithening blue blob
<Keybuk> long flamewars about it
<Keybuk> basically it comes down to an interpretation of the standard
<Keybuk> there's a "scan for new networks" ioctl that nm issues every 30s
<Keybuk> the ipws take this to just mean "update your table of nearby networks and tell me when done"
<Keybuk> the atheros takes it to mean "Bored of this network, deconfigure the card and find me a better one"
<mjg59> Keybuk: I'm aware that that /has/ been the case, but I didn't believe it was currently the case
<mjg59> Given that Novell are using it, and a lot of Novell people have Atheros hardware...
<Keybuk> was the case last time I checked (at UBZ)
<Keybuk> there may be a new fixed version, Christian is going to upload that to universe and I'll play with it and see what happens
<Keybuk> the symptom is quite obvious, every 30s your network connection drops
<Keybuk> and if you (like me at home) have a stronger network that's not yours, your laptop jumps to that one instead
<mjg59> Right. Give me a second and I'll test it here.
<elmo> janimo: sec
<whiprush> I don't see that here. nm and atheros.
<Keybuk> run wavemon, every 30s or so the signal will drop out totally
<mjg59> elmo: Ok, that sounds like it's powering up the crtc but not changing the display pipes
<mjg59> elmo: Try i855crt with that patch?
<elmo> mjg59: yeah, already compiling it
<Mithrandir> would adding "auto %s\niface %s inet dhcp" for each network interface found be considered rude?  (In the live CD, that is)
<mjg59> Mithrandir: Given that it'll block, yes
<elmo> mjg59: meh, doesn't work (same problem with rawpipe as with i810switch, and SNAFU screen with a specific res), oh well - thanks anyway
<Keybuk> mjg59: not for too much longer
<Mithrandir> mjg59: I can blame Scott for that and he'll have an incentive to fix it. :-)
<mjg59> elmo: Only other real option is to set up mirroring at all times in xorg.conf
<elmo> mjg59: if I do that, does it work without the monitor?
<mjg59> elmo: Yes
<mjg59> Power consumption will be slightly higher, though
<elmo> ah, ok, I guess I can try that
<Keybuk> mjg59: just tried nm 0.5.1-0ubuntu6 (current dapper) and it does exactly the same thing
<Keybuk> leaps off my network and joins my neighbour's whenever told to scan
<mdz> jdub: pong
<Keybuk> mjg59: in fact, it's every 13s now
<mjg59> Hlaghlkjlkjafhalgh
<pitti> mjg59: bless you
<lucas> hi
<lucas> I've a problem with the ubuntu wiki
<lucas> I can login correctly using my LP id
<lucas> but when I want to update my preferences on https://wiki.ubuntu.com/UserPreferences
<lucas> it says "Passwords don't match"
<lucas> can somebody confirm the problem ?
<elmo> aww, crap it's a bcm4318
<elmo> is the reverse engineered driver usable/useful in dapper yet?
<tseng> i think mjg59 got it to associate but not transmit
<elmo> what's the fallback, beyond a wireless PCMCIA card?  ndis?
<Keybuk> ndis is reasonably well supported at the moment, if you do the voodoo it should work with udev
<Keybuk> of course, your machine will crash an hour or so later, but hey, that's ndis for you :p
<mjg59> elmo: Latest kernel should just about drive it
<mjg59> Though "latest kernel" may be what's in git rather than what's in the archive
<mjg59> Keybuk: We might want to look at switching to the madwifi-ng crap
<Keybuk> Linus may have been too busy flaming people to put it in the last rc? ;)
<Keybuk> mjg59: that allegedly fixes it, because it works the same way the ipws do
<mjg59> Keybuk: Uh, our kernel. It's not in 2.6.15 stock.
<Keybuk> oh, sorry
<Keybuk> wrong git
<hno73> lucas: It seems to work if you blank the password
<seb128> Kamion: could you promote the new evolution-data-server binaries (soname changes): libcamel1.2-7 libexchange-storage1.2-1? evolution needs them to build
<hno73> (though there is clearly a usability issue there)
<mjg59> Argh christ the madwifi HAL comes from their Windows drivers
<lucas> hno73: oh true, thanks
<Keybuk> you didn't know that?
<Keybuk> madwifi-ng is not the solution you're looking for, anyway
<Keybuk> that's just version 2 of the existing crap
<mjg59> Keybuk: I knew it was closed, I didn't know it was Windows derived
<Keybuk> ath-driver is the one that "works"
<Keybuk> http://www.ath-driver.org/
<mjg59> Well, except for not working
<mjg59> (so far)
<Keybuk> I got it to associate to my network
<mjg59> Ooh
<Keybuk> not much else, but that's a start ;)
<mjg59> Heh
<mjg59> I'd be surprised if it's good enough for Dapper
<mjg59> Whereas madwifi-ng is realistic
<Keybuk> afaik madwifi-ng has exactly the same problem
<mjg59> Keybuk: It has support for background scanning
<Keybuk> oh, it does?  in the same way as the ipw implements it?
<mjg59> No idea
<mjg59> http://www.madwifi.org/wiki/ChipsetFeatures/BackgroundScanning
<mjg59> "A cool feature whereby the driver scans available channels without interrupting a current AP association.
<mjg59> Not at all an issue
<Keybuk> right
<mjg59> (cough)
<Keybuk> wonder if they've bothered to implement Ad-Hoc yet
<mjg59> Nngh and it still has its own 80211 stack
<Keybuk> yeah, it has a port of the FreeBSD one, iirc
<Lathiat> mm, sata_sil24, cooler ntfs write and ivp6 stateful connection tracking in 2.6.15
<Keybuk> because what the kernel needs is yet another 802.11 stack
<Keybuk> didn't I read somewhere about YET ANOTHER one being written (in addition to the madwifi and ipw ones?)
<zyga> hmmm
<zyga> why are they all duplicating work
<Kamion> seb128: done
<Keybuk> zyga: the "standard" 802.11 stack was written by the Intel guys for the IPW cards; and they're very resistant to changing it to accomodate other models afaiui
<zyga> Keybuk: eh, the power of egos
<jdub> 80211 stacks are the new irc client
<mjg59> Keybuk: The ipw one doesn't have terribly complete support for managing softmac type stuff
<zyga> Keybuk: are they all GPL'd?
<Keybuk> ah, it was the free broadcom one
<Keybuk> zyga: they're all GPL-compatible
<zyga> at least that's good
<zyga> I hope that in 5 years wifi will just work...
<mjg59> The broadcom driver has been ported to two stacks (softmac, which is built on top of the ipw one, and dscape, which is complete but not terribly well integrated into the kernel yet)
<Keybuk> *sigh*, etc.
<seb128> Kamion: thanks
<mjg59> Keybuk: The new madwifi stuff claims to support adhoc
<elmo> Kamion: hum, I think the network stuff has regressed
<elmo> Kamion: I'm trying to install today's i386 install, and I selected 'don't configure network at this time', and now I'm stuckk in a loop at the "http proxy" prompt ("choose a mirror of the Ubuntu archive")
<Keybuk> mjg59: the old stuff claims to support it too, and then in very small letters adds "but it doesn't work, so you should just use hostap mode instead"
<Keybuk> maybe they've fixed it in -ng, but I didn't see it on the NgFeatures page
<Kamion> elmo: yeah, known, I mentioned it in the Flight 2 release notes
<mjg59> I don't think that's a complete changelog
<elmo> Kamion: ah, ok
<elmo> Kamion: sorry
* Keybuk hates wifi
<Kamion> no problem, I need to fix it RSN
<Keybuk> I think we should all go back to 10base-2
<dilinger> * Add a new command "play" to play an audio file on PC.
<dilinger> grub2 scares me
<jdub> you mean, we can have the ubuntu beat at grub now? elite!
<jbailey> dilinger: Someone was joking the other day about porting glibc to the grub2 OS. =)
<Mithrandir> jbailey: what about emacs?
<dilinger> jbailey: and you haven't gotten on that yet? ;p
* Keybuk fondly remembers building terminators out of LEDs and stuff
<Mithrandir> a bootloader just needs a mail reader in the same way a fish needs a bike.
<jbailey> dilinger: Grub 2 won't load an elf64 kernel yet.
<jsgotangco> good night
<jbailey> dilinger: So I can't test it on my main machine. =)
<jbailey> Mithrandir: I'm not an emacs lover.  But I wouldn't be surprised if someone hadn't done it already. =)
<tenco> hi
<dilinger> http://lists.gnu.org/archive/html/grub-devel/2005-11/msg00032.html
<tenco> iam currently trying to make breezy boot faster on an old 400mhz desktop
<tenco> and i just looked at /etc/modprobe.d
<jbailey> dilinger: Oh, that's just the generic speaker.
<jbailey> dilinger: I helped Marcus write that code in the Hurd. =)
<tenco> IMHO thats pretty evil bruteforce
<Keybuk> tenco: hmm?
<jdub> dilinger: um. 'mod'. holy crap.
<Keybuk> tenco: what about /etc/modprobe.d concerned you?
<tenco> especially alsa-base
<mjg59> Hmm. Actually, the openhal code looks like it possibly supports a sensible amount of hardware now
<dilinger> jbailey: yea, i noticed the comment that it was stolen from hurd
<tenco> Keybuk: in alsa-base e.g. are lots of "install <module>" lines
<Keybuk> tenco: do you know what the "install" keyword in a modprobe configuration file does?
<tenco> Keybuk: so "Calculating module dependencies..." takes a lot of time
<Keybuk> *blink*
<Keybuk> no, that isn't why
<tenco> trying to install that module?
<Keybuk> no, that's not what it does
<tenco> what else?
<Keybuk> I suggest you and the module-init-tools documentation become friends :)
<tenco> jup :-)
<tenco> anyway, calc the mod deps takes a lot of time
<Keybuk> yes, it does
<Keybuk> which filesystem are you using?
<mjg59> Keybuk: If you've got a chance, can you take a look at http://pdos.csail.mit.edu/~jbicket/openhal/ at some stage?
<tenco> ext3
<Keybuk> tenco: ok, that's interesting; usually it's the more ricer ones that tend to be slow
<Keybuk> basically it's just taking that long to stat a directory tree of 2,000 nodes
<Keybuk> (/lib/modules/$ver)
<tenco> o_O
<Keybuk> this is rather irrelevant though
<Keybuk> we don't do that during boot in dapper
<tenco> a simple file would be faster to parse...
<tenco> text file
<Keybuk> uh
<Keybuk> dude, seriously, go read documentation
<Keybuk> all that step is doing is creating the "simple text file" you want
<tenco> every boot?
<Keybuk> yes
<Keybuk> like I said, we don't do that in dapper anymore
<tenco> ok
<mdz> Keybuk: what's behind the issue of network interfaces not being brought up at boot?  I saw this in a test install yesterday
<Keybuk> mdz: I've not written anything to bring them up at boot yet
<Keybuk> mostly
<mdz> I see
<Keybuk> need to port over the old hotplug net.agent to udev, use the ifrename support built-in to udev, and sort out the mess with n-m too
<Keybuk> is my plan for the sprint when everyone's together
<mdz> we should do something about it before then, though
<Keybuk> yeah, the answer is add an "auto" line to /etc/network/interfaces
<Kamion> should the allow-hotplug line stay?
<Keybuk> I have no idea what "allow-hotplug" is
<Keybuk> that turned up recently
<mdz> me either
<Keybuk> it seems like aj-crack to me
<Kamion> no
<Kamion> Thomas Hood suggested it
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340935
<Keybuk> if all hardware is brought up by hotplug, then either it or the "auto" line are meaningless
<mdz> doko: have you had a chance to look at this patch from Martin?
<tenco> Keybuk: do you think its easy to transfer the dapper mechanism to breezy?
<Kamion> 15:44:08 [I]  Log message: configuring ssh after installation
<Kamion> 15:44:08 [I]  /home/cjwatson/src/ubuntu/espresso/tailor $ svn update --revision 1480 .
<Kamion> I'm so glad I've branched from that code and am not obliged to follow it
<Kamion> (that change does 'dpkg-reconfigure ssh' after installation. What's the point?)
<mdz> isn't ssh just a metapackage now?
<Kamion> yes
<Kamion> reconfiguring it does nothing
<Kamion> oh, great, and they've cloned-and-hacked grub-installer straight in
* Kamion runs
<Keybuk> Kamion: was the log message "merry christmas *hic*" ?
<Kamion> Keybuk: I've made that change in netcfg for now, although I'm still not convinced I really understand what's going on
<jdub> mdz: from your past experience, how grotesquely conflated are mythtv's backend and frontends? do you think it would be feasible/easyish to develop an alternative frontend without a huge amount of work?
<tseng> jdub: they are totally seperate in theory
<tseng> they can happily live on seperate systems
<Keybuk> Kamion: me neither, I'm not entirely sure where we're going either
<jdub> yeah, that's different to conflated codebases though :-)
<Keybuk> my new-world-order-tom-tom is stuck in john cleese and making random comments about its mother
<jdub> the 'protocol' ends up being the database, which is a saving grace to a certain extent
<tseng> thats true, but there is more than just the db
<jdub> nfs? :)
<tseng> no
<jdub> and all the xml bits
<mdz> jdub: with or without basing it on the existing code?
<Kamion> Keybuk: yes, dear
<jdub> mdz: without
<tseng> you need to connect to the server to stream the ring buffer frmo live tv capture
<jdub> tseng: ahr
<tseng> i think it also wants to stream saved captures over the client/server, even though you can do nfs
<mdz> jdub: it would be a lot of work to forego the library, but the protocol would support it
<tenco> Keybuk: depmod --quick is taking that long?
<Kamion> BenC: I've checked in image[macrisc4]  stuff to debian-cd now; it'll be in tomorrow's daily builds
<fabbione> hey mdz
<Keybuk> tenco: yes
<Keybuk> about 12-15s if memory serves
<Keybuk> of course, the second time you do it, it takes nanoseconds
<mdz> fabbione: good morning
<Keybuk> which all the clever kids know is a clue that it's a filesystem issue
<mdz> Keybuk: if we don't know where we're going with this yet, now is the time to talk it out and decide ;-)
<Keybuk> mdz: perhaps
<tenco> Keybuk: thanks. turning that off should be save if either dpkg/apt handles an initial depmod on installing a kernel-package or i do that manually myself, i guess
<Keybuk> tenco: I think we had to add those
<tenco> Keybuk: thanks so far :-)
<Keybuk> so there's a bunch of "network-like" things we have to bring up during boot
<mdz> how do we get away with not running depmod for l-r-m?
<mdz> or is it broken and nobody's noticed yet?
<Keybuk> mdz: we depmod when we install the package, and expect the dependencies to not change <g>
<mdz> Keybuk: the modules for l-r-m don't exist until boot time
<Keybuk> they exist at install time too
<mdz> hmmm
<Keybuk> the postinst runs lrm-manager, which calls depmod
<mdz> I guess it's ok unless someone unmounts the tmpfs and installs a new kernel
<Keybuk> why would that matter?
<Keybuk> different tmpfs per kernel version
<mdz> because that would remove the entries from modules.dep
<mdz> and upgrading the kernel would run depmod
<Keybuk> and there are a whole gangbang of problems about removing or upgrading your running kernel anyway
<BenC> Kamion: sweet, thanks
<mdz> Keybuk: so about these network-like things
<Keybuk> if someone installs kernel A-1, and the appropriate lrm for it, then unmounts the tmpfs, and then upgrades to A-2 ...
<Keybuk> then yes, it wouldn't work
<Keybuk> but I think that comes under a severe case of "don't put your gun at your feet"
<Keybuk> right, networking
<Keybuk> so we have to bring up:
<Keybuk> 1) lo
<Keybuk> 2) devices for which we find the hardware, load modules, etc.
<Keybuk> 3) static magic devices like ppp, tunnels, etc.
<mdz> for 2), do we need to make any distinction between whether the user is using a modular kernel or an elmo kernel?
<Keybuk> mdz: no, fortunately we don't; they look the same to us
<mdz> cool
<Keybuk> 2) can be summed up as "everything the kernel has hardware for"
<Keybuk> if the kernel doesn't know about it, you clearly have a Square One issue
<Keybuk> except for the stuff in 
<Keybuk> 3) which is the stuff there's no hardware for
<mdz> for 1), we currently have an init script which configures it based on /etc/network/interfaces.  any reason to change that?
<Kamion> you sure about listing ppp under 3)?
<Keybuk> I'd rather like to fix the "eth0:2 isn't brought up when eth0 is plugged" bugs too
<Keybuk> mdz: we do?  when did that show up?
<Kamion> I suppose it's there sometimes, e.g. for serial modems
<mdz> Keybuk: we do 'auto lo' and 'ifup -a' still, no?
<Keybuk> Kamion: dunno, I've seen people with ppp listed in eni
<Keybuk> mdz: currently, yes ... but that's far too late
<Keybuk> we need to "ifup lo" before we do just about everything, including starting uedv
<Keybuk> which means the "auto lo" won't mean a thing, because there's (currently) no "ifup --auto-only lo" type syntax
<mdz> Keybuk: so how about we configure lo sanely in early userspace, and if the user does something custom via /etc/network/interfaces, that takes effect later in the boot/
<Keybuk> mdz: ifupdown doesn't like reconfiguring interfaces :-/
<hyperactivecrond> what does dapper use for the menu on boot from the install cd?
<Keybuk> we'd have to ifdown it
<Keybuk> my idea was to do something like:
<Keybuk> - add the --auto-only flag to ifup
<tseng> hyperactivecrond: gfxboot.
<mdz> Keybuk: s/configure lo sanely/& without ifupdown/
<Keybuk> - "ifup --auto-only lo" early in userspace
<hyperactivecrond> thx tseng
<mdz> ifconfig lo inet 127.0.0.1 # TYVM HAND
<Keybuk> - call "ifup --auto-only $DEVNAME" in udev when network hardware is detected
<Keybuk> and then deal with 3) somehow
<mdz> if the user wants to add additional IP addresses to lo or something, it's fine for that to take effect later on
<Keybuk> probably just with "ifup -a"
<Keybuk> as that takes into account anything already up
<Keybuk> afaict
<doko> mdz: test build done, uploaded, waiting for the buildd (approx. 20h)
<fabbione> doko: does the new OOo2 fix ppc build?
<mdz> Keybuk: why bother with ifup in early userspace just for configuring loopback?
<Mithrandir> mdz: would we want an integrity check of the live cd as well as of the install cd?
<mdz> Mithrandir: yes; it'd be implemented identically
<doko> fabbione: no, not yet. it looks like a gij/gcj issue, which does not occurr in breezy. I'll come to it again after a gcj-4.0 update
<Keybuk> mdz: tbh, I never understood why lo is even in /etc/network/interfaces
<fabbione> doko: ok. do you want me to build on sparc or should i wait?
<Mithrandir> mdz: no, it wouldn't, unless you want a full d-i on the live cd as well?
<Keybuk> we could always drop it from there, don't write it in netcfg, and just bring it up as you suggest
<Keybuk> no sane person changes its details, after all
<mdz> Mithrandir: the udeb boils down to md5sum -c
<fabbione> Keybuk: remember that lo can be something different than 127.0.0.1/8 and that the network is routable...
<mdz> I guess we'd need a separate progress bar
<Kamion> we don't have any of the d-i infrastructure on the live CD any more
<doko> fabbione: I think it can wait
<fabbione> doko: ok
<Kamion> I suppose I can resurrect it if I have to
<mdz> Mithrandir: speaking of which, make sure re-adding usplash support is on your list for casper
<Kamion> but it was a significant space saving
<mdz> Keybuk: it seems reasonable to have it there so that users can add custom configuration to it
<mdz> Kamion: I think it's better to leave it out
<Keybuk> mdz: but then that wouldn't work
<Keybuk> cf.
<Keybuk> # ifdown lo
<Keybuk> # ifconfig lo down
<Keybuk> # ifconfig lo up 10.0.0.1
<Keybuk> # ifup lo
<Keybuk> SIOCSIFADDR: File exists
<Keybuk> Failed to bring up lo.
<mdz> ugh
<Keybuk> THE SKY IS FALLING.
<Keybuk> type thing
<mdz> that's surely a bug
<Kamion> mdz: I agree - but that does mean we can't reuse the integrity check
<Kamion> perhaps we can have a simple switch in casper that does md5sum -c /cdrom/md5sum.txt or whatever it is
<Mithrandir> mdz: it's already there.  Or should be, at least.
<Keybuk> mdz: perhaps, but I get scared whenever I look at the ifupdown source code
<Keybuk> it makes me want to cry
<mdz> Kamion: yes, I meant more that the guts would be the same
<Kamion> ah, ok
<mdz> Keybuk: from what I see it should just be doing "ifconfig <iface> 127.0.0.1 up"
<mdz> mizar:[/tmp/ifupdown-0.6.7ubuntu2]  sudo ifdown lo
<mdz> mizar:[/tmp/ifupdown-0.6.7ubuntu2]  sudo ifconfig lo down
<mdz> mizar:[/tmp/ifupdown-0.6.7ubuntu2]  sudo ifconfig lo 127.0.0.2 up
<mdz> mizar:[/tmp/ifupdown-0.6.7ubuntu2]  sudo ifup lo
<mdz> wfm
<Keybuk> mdz: ifconfig it to something outside of the range ifup wants for it
<Mithrandir> Kamion: ENOMD5SUM.TXT, but yeah, we would.  I'm pondering what we should do about the huge filesystem.cloop file.. I might end up writing something which reads chunks of it and talks to usplash as a progress bar-style thing.
<mdz> Kamion: did you already add the integrity check option to the isolinux menu?  I didn't look
<Keybuk> mdz: ie. not 127/7
<mdz> Mithrandir: eh?  we've had md5sum.txt on the live CD for ages
<Keybuk> uh /8
<Kamion> mdz: no, was waiting for instructions from Mithrandir on that
<sabdfl> Kamion: does ubuntu-ppc support resizing existing partitions? i have a new apple desktop...
<mdz> sabdfl: welcome back
<hyperactivecrond> for gfxboot for dapper... does one have to get a patched grub?
<hyperactivecrond> never mind.
<Mithrandir> Kamion: I was planning on giving you those tomorrow.
<Keybuk> sabdfl: Apple stores are damned hard to walk past, aren't they; I swear they use extra-special glass that makes things look shinier
<fabbione> sabdfl: depends from the partition
<Kamion> sabdfl: there's nothing special about powerpc in that regard, although if it has new Mac OS X on it you'll need to use dapper in order for parted to understand the new partition types
<Kamion> hyperactivecrond: we won't be doing graphical grub in dapper
<sabdfl> Kamion: ok, cool, dapper it is then :-)
<Kamion> syslinux only
<mdz> Keybuk: it fails, but the interface ends up configured correctly
<Keybuk> mdz: yeah, I'm not really sure what that's all about
<Kamion> Mithrandir: cool, thanks
<sabdfl> will try a dapper live-cd to see if it will even boot on a dual dual-core
<mdz> Keybuk: maybe it's the ipv6 bit, which uses add/del
<Mithrandir> mdz: we'd probably want to use something which did have a more useful progress bar than what you'd get with the naive approach when you have a single file which is 5/7 of all you're checking.
<Keybuk> SIOCSIFADDR is "set interface address"
<Kamion> sabdfl: you'll have to use 'live-powerpc64', unless you have a time machine to get tomorrow's live CD which'll make that unnecessary. :)
<mdz> Mithrandir: usplash wolud be reasonable
<pitti> BenC: the eject issue should be fixed in -10, right?
<fabbione> sabdfl: if it doesn't work. please let us know. I know benh is working on his SMP dual core to fix some stuff and not all of it is in the kenrel yet
<sabdfl> Kamion: i have patience, no need for time machine :-)
<Keybuk> pitti: fixed which way?
<BenC> pitti: should be
<pitti> Keybuk: properly :)
<Keybuk> devices still get ejected properly?
<pitti> Keybuk: the kernel should now be able to eject all usb devices
<Keybuk> and vanish off the system?
<pitti> Keybuk: 'still'?
<pitti> Keybuk: they didn't for many devices, see #5049
<Keybuk> well, my laptop when I unmount a usb device ejects it properly
<Keybuk> ah, as long as you didn't turn off ejecting :p
<BenC> it's very random
<Keybuk> some people have been moaning about the fact it ejects at all, and doesn't just unmount
* BenC remotely disable ejecting on Keybuk's machine
<BenC> Keybuk: oh, I found out something: eject -t will get a USB device back in most cases, after an eject
<Keybuk> that's kinda cute
<mdz> Keybuk: anyway, I don't think we need to try to support ridiculous configurations like that; the defaults will work and users will be able to add additional addresses to loopback, which is about the only reasonable thing to do to it
<Keybuk> in a totally sick, "get your own ioctls and stop abusing them" kind of way
<mdz> Keybuk: so for 1), "add an ifconfig/ip call to initramfs" seems like the right way to go
<BenC> keybuk: fact is that some USB devices do the right thing, and "eject" the memory card (or whatever) virtually
<Keybuk> mdz: right; we still need a way of bringing up interfaces for hardware though
<BenC> it's a hardware thing more than a driver issue
<mdz> Keybuk: right, on to 2)
<Keybuk> mdz: allow-hotplug seems ... wrong; it brings us back yet again to having two options which mean the same thing in different ways
<Keybuk> mdz: just having "auto eth0" seems best, that way if udev doesn't bring it up, S40networking will
<Keybuk> BenC: my video camera switches back to ordinary camera mode, instead of dumb USB mode; I'm reasonably glad it doesn't eject its own hard disk <g>
<mdz> lemme read the bug about allow-hotplug
<mdz> hmm
<mdz> so it sounds like allow-hotplug is meant to mean "run ifup when the hardware is detected"
<mdz> while "auto" continues to mean "run ifup from S40networking"
<Keybuk> right
<Keybuk> which is crackful
<Keybuk> imo
<mdz> I agree that the distinction doesn't seem particularly useful
<mdz> either it should be brought up at boot, or not
<Keybuk> if the hardware hasn't be detected, trying to bring it up in S40networking isn't going to work
<mdz> your --auto-only approach sounds sane
<mdz> except for the fact that it involves touching ifupdown code, but c'est la vie
<Nafallo> Keybuk: isn't that network-manager's job to cover 2)? :-)
<mdz> the magic 8-ball says network-manager's future is unclear
<mdz> in the dapper timeframe
<Keybuk> network-manager would be great, if it did what it says on its tin
<Nafallo> well, wfm ;-)
<jsgotangco> :(
<mdz> whether or not we're able to integrate it for desktop purposes, I think we need a more trustworthy fallback for server configurations anyway
<Keybuk> mdz: do I have to resist the urge to write incredibly sarcastic documentation alongside the change? :p
<mdz> Keybuk: I think the literate programming syntax requires that you do so
<Kamion> this is starting to remind me of Intercal's politeness rules
<mjg59> Keybuk: What are the dates for the distro sprint? It's the week after LCA?
<Keybuk> mjg59: yes
<mjg59> Keybuk: Ok. I may be able to be there for some of it, if you're planning on covering network stuff
<elmo> whine, X segfaults on this stupid laptop
<Keybuk> cool; I'm not doing LCA this year after all, I just can't spare the time homewise, let alone anything else
<mjg59> elmo: Nngh. You're sure it's Intel?
<mdz> mjg59: it seems pretty likely that we'll have things to talk about in that area
<fabbione> elmo: dapper/ppc ?
<elmo> mjg59: oh, sorry, I'm confusing you, I'm working on two different laptops here
<elmo> mjg59: the i915 thing was on a sony vaio, X is fine there
<mdz> mjg59: the basic agenda is going to be outstanding dapper issues
<Keybuk> the depressing thing about literate programming is that the only way I've ever been able to understand the code is to generate it, read the resulting code, change it, then use grep to work out how to change the literate version
<elmo> mjg59: X segfaulting, and the BCM4318 is on a random amd64 turion laptop I'm trying to setup for someone else
<elmo> fabbione: breezy/amd64
<fabbione> elmo: ok.
<mjg59> elmo: Oh. ATI chipset?
<Keybuk> of course, I COULD WRITE THE UBUNTU CODE IN A DIFFERENT COLOUR! :D
<elmo> mjg59: yeah
<mjg59> elmo: Option "NoAccel" "tru"
<elmo> oh, right, that molarky
<elmo> will it work in x86 mode?
<mjg59> Except "true", not "tru"
<mjg59> No
<elmo> okay, so I'll not needlessly reinstall then
<mjg59> Our X is broken on a small number of ATIs
<elmo> mjg59: thanks :)
<janimo> mjg59, there's a patch in bugzilla for that brokage though
<mdz> Keybuk: 3) seems a bit tricky
<mdz> Keybuk: since those abstract interfaces sometimes  have implicit dependencies on hardware-oriented interfaces
<OpsVentus> Good day, I have started to develop a GUI for wireless networking for Ubuntu because I felt this was missing from Ubuntu, an first glimp of what it should look like and what it can do can be found at http://www.opsventus.com/wifigui
<Robot101> Keybuk: I have weirdness with udev 077-0ubuntu5 and dvb devices, it successfully made the /dev/dvb/adapterX/fooY stuff once, but hasn't since
<Robot101> Keybuk: how do I debug this?
<OpsVentus> can some people please give me an opinion on whether I should invest more time to make it work properly or just give up?
<mdz> OpsVentus: what is it meant to do specifically?
<OpsVentus> give an easy graphic solution to connect to wireless networks
<Keybuk> Robot101: does it make the wrong names for them now?
<HiddenWolf> OpsVentus, networkmanager seems to do what you want... 
<Treenaks> network-manager
<OpsVentus> not for wireless networks
<Keybuk> mdz: true, but if we use ifup + auto for 2), and keep the S40networking script, then the ifup -a call there will "sort out" all of those interfaces
<Robot101> Keybuk: it makes /dev/dvb0.dvr0 etc
<Keybuk> and it'll work the same as it does in breezy
<OpsVentus> with my program you can select the wireless network you want
<Keybuk> Robot101: can you run "udevmonitor -e" and plug in the device?
<seb128> is /dev/fd0 supposed to be 660 or 640?
<Keybuk> seb128: yes :)
<mdz> Keybuk: assuming all the important bits have finished executing by the time S40networking runs, no?
<Keybuk> seb128: theoretically 660
<seb128> Keybuk: it was a "or" but I will take that as a "660" :)
<mdz> OpsVentus: network-manager does in fact do that for wireless networks
<seb128> Keybuk: udev bog? Should I bugzilla it?
<Mithrandir> seb128: 640 | 660 is 660, so that sounds sane. :-)
<Keybuk> seb128: not that I'm aware of, why, what do you think the permissions should be; and why?
<seb128> I think it should be 660 because with the current 640 gfloppy complains that you don't have any right on the device when you are a member of the floppy group
<Keybuk> seb128: if it's 640, it means that the kernel is now advertising floppy block devices as "removable"
<Keybuk> and that sounds like a bug in gfloppy, no?
<Keybuk> what does write permission on the device give you?
<seb128> do you need to write to format it?
<Keybuk> we need pitti for this, he explicitly asked for removable devices to NOT have write permissions
<Robot101> Keybuk: http://rafb.net/paste/results/TnX4TL77.html
<Keybuk> the only exception is CD drives, which need write for eject
<elmo> somone hit me with build-depends heavy packages I can prime porter chroots with, things like evolution, firefox and openoffice
<Robot101> elmo: gnucash :)
<Kamion> elmo: debian-installer
<mdz> Keybuk: weird, I wonder why he would want that
<mdz> writing directly to a floppy or USB key is a reasonable use case
<jordi> elmo: nautilus
<Keybuk> we'll have to ask him when he comes back
<seb128> k
<jordi> elmo: some kde package... kdemultimedia I guess
<Mithrandir> elmo: mplayer
<mdz> Diziet: around?
<Nafallo> gaah. I hilight network-manager :-P
<Nafallo> anyway, see ya :-)
<elmo> Robot101, Kamion, jordi, Mithrandir: thanks
<Mithrandir> elmo: ant, possibly, to get some java stuff in
<mdz> seb128: is there any new information about the disappearing applications menu?  is it fixed in newer kernels?
<mdz> the latest kernels hang during boot on my machine, so I can't quite test
<mjg59> mdz: Hm. Fun.
<seb128> mdz: it's a gam_server bug, and it triggers by /var/lib/menu-xdg/menus/debian-menu.menu beeing missing
<Keybuk> Robot101: I guess somebody in kernelland changed things, or I mucked up the device name script
<seb128> s/it triggers/it's triggered/
<fabbione> mdz: does that machine have a PCI I/O controller?
<mdz> seb128: ah, above the kernel then
<Robot101> Keybuk: I tested the device name script and it seemed to dtrt, which is why I'm so confused
<seb128> mdz: /etc/xdg/menus/debian-menu.menu points to /var/lib/menu-xdg/menus/debian-menu.menu, when the second is not here gam_server has some issue
<mdz> fabbione: I'm not sure what that is.  do SCSI and IDE controllers count?
<seb128> mdz: will be fixed soon, there is some patching pending review upstream
<elmo> Mithrandir: good plan
<fabbione> mdz: yes they do count
<Keybuk> Robot101: you have nothing there that would cause it to be run
<mdz> fabbione: then yes
<Robot101> $ ./dvb_device_name -e dvb0.dvr0
<Robot101> 0.0
<fabbione> mdz: ok
<seb128> mdz: workaround: run update-menus
<Keybuk> you just have SUBSYSTEM==dvb things, not SUBSYSTEM==dvb_device
<Robot101> Keybuk: aha
<mdz> seb128: s/run/install menu and &/ ;-)
<mdz> hmm, update-menus fails here with no output
<Keybuk> that's wrong anyway
<Keybuk> it should output 0 net0 or something
<dholbach> menu has update-menus in its postinst
<Robot101> Keybuk: ah right
<dholbach> installing it should suffice
<Keybuk> cool, thanks for that; I can fix that now
<Robot101> Keybuk: np
<seb128> dholbach: seems that it's bugged, some people get no /var/lib/menu-xdg/menus/debian-menu.menu after running it
<elmo> doko: grr, why doesn't apt-get build-dep  work for gcc-4.0 ?
<mdz> that does seem to fix it, thanks
<dholbach> seb128: strange :(
<Robot101> Keybuk: can I get a pointer to how I might make some persistent names for usb serial devices, regardless of what order they probe in?
<seb128> mdz: np
<Keybuk> yes, easy
<Keybuk> use udevmonitor -e, and plug the device in
<Keybuk> the [UEVENT]  will tell you the useful information for the device
<OpsVentus> mdz: I have to take a deeper look into network-manager then, I'm still on Warty, maybe in Breeze this has been updated
<Keybuk> do udevinfo -a -p $DEVPATH  (from the [UEVENT]  bit) to see everything in sysfs you can use
<Keybuk> and build up a description of it, probably something like:
<Keybuk> SUBSYSTEM=="usb", SYSFS{product}=="iAUDIO M3 Digital Audio Player", ...
<Keybuk> and then add a persistent name using SYMLINK+="iaudio"
<doko> elmo: which architecture?
<elmo> doko: amd64
<elmo> something about libc6-686-dev not available
<doko> yes, but the alternative is available (ia32-libs-dev)
<doko> anyway, jbailey's next upload should fix that and introduce this package
<elmo> yeah, it kind of sucks that apt-get build-dep bombs tho
<elmo> ah, ok, cool
<Keybuk> Robot101: try to void BUS== or anything referring to physical devices, et. al. otherwise your head will explode
<Robot101> Keybuk: mm, ok, cool. thanks.
<Keybuk> SUBSYSTEM guarantees SYSFS attributes, so use that for custom matches
<poningru> what kernel version is planned for dapper?
<Keybuk> 2.6.15
<poningru> oh
<poningru> wait isnt that a in development version?
<Keybuk> so is dapper
<HiddenWolf> poningru, it's final since yesterday
<poningru> ok nm thought that wasnt going to be ready till next year
<poningru> err this year
<Burgwork> poningru, got released today
<poningru> later this year*
<poningru> thanks guys
<Keybuk> kernels are on roughly a 2-3 month release cycle, I believe
<Keybuk> so 2.6.16 will be out before dapper, but too close to dapper's release for us to be confident in it
<poningru> hmm ic
<Keybuk> we've been packaging 2.6.15 since the first rc
<Keybuk> thus already have a lot of testing on it
<poningru> cool
<poningru> geez the changelog is down it seems
<jordi> Keybuk: is the ubuntu kernel team working with Debian's?
<poningru> nm
<jordi> (I ask because debian has also been packaging the rcs)
<Keybuk> jordi: I suspect the Debian kernel team take from the Ubuntu kernel team's git repository as they see fit; it's published on kernel.org
<jordi> nod
<jordi> Keybuk: ie, no real cooperation
<Keybuk> would you really want to go near the Debian kernel team? :p
<jordi> well. Not ALL of them no :)
<jordi> I know where you're going :p
<Keybuk> where am I going? O:-)
<jordi> let's be friendly and say no more :)
<poningru> how come the debian kernel team doesnt real
<poningru> ly like ubuntu?
<Robot101> spoons vs forks...? :)
<HiddenWolf> poningru, part pride, part real issues, part imagined issues
<poningru> ic
<Keybuk> various bits of Debian still don't like Ubuntu for particular reasons
<HiddenWolf> poningru, both debian and ubuntu have trolls in their ranks, and those like bashing eachother.
<jordi> I haven't said the Debian kernel team doesn't like Ubuntu's
<Keybuk> it's rather deeper than that
<jordi> I just owndered what the situation is
<Keybuk> a few Debian maintainers have fairly large problems with, for a lack of a better description, "being patched"
* ogra looks for the ubuntu trolls
<Keybuk> there's not much inter-developer trolling
<Keybuk> that kind of thing (as with KDE/GNOME) tends to just take place in the user ranks
<poningru> I think its due to the coc
<ogra> thats what i meant
<HiddenWolf> Keybuk, and having their system of work disrupted by ubuntu developers, by not having a designated maintainer to talk to in ubuntu, and loads of other reasons. :)
<poningru> well even within dev for gnome and kde they have other subject trolls
<poningru> like the recent israel bout
<Keybuk> jordi: I suspect the situation is really just that we don't have a kernel team, we have a BenC; who sends patches directly upstream
<jordi> Keybuk: ah I see
<Riddell> poningru: where was that?
<Keybuk> HiddenWolf: curiously, I've noticed that the Debian developers who complain the most about Ubuntu tend to have the worst relationships with their upstream too; it's not a hard/fast rule, but it's a pattern
<poningru> gnome irc dev channel
<Keybuk> make of that what you would
<poningru> channels*
<Riddell> poningru: comedy, I was blogging only yesterday about the exact same thing happening in #kde-devel
<Keybuk> jordi: and it's better for us for BenC to do that, and spend his time fixing bugs, etc. than spoon-feeding patches to Debian, or anyone else, for that matter
<poningru> rofl
<janimo> elmo, xubuntu-docs/NEW/GPL ping :)
<HiddenWolf> Keybuk, it takes a certain attitude to work openly. If you like to take pride in and out of _your_ work, the debian system tends to give you more credit and possibly "power" and "protection"  than ubuntu and upstream
<Riddell> janimo: did your key get added to the ring?
<janimo> elmo, also jani@ubuntu.com GPG key in main
<Keybuk> HiddenWolf: you're aware that I'm a Debian developer too, right?
<elmo> janimo: right, sorry. you said you were going to contact the {k,}ubuntu doc authors, what happened about that?
<janimo> heh, trying too ;)
<HiddenWolf> Keybuk, I know that many people here are. :)
<HiddenWolf> Keybuk, and that wasn't ment personally, but as a possible explanation
<janimo> elmo, I did not say I would contact them, just said that the docs in xubuntu are based on their work
<HiddenWolf> Keybuk, s/you/one
<janimo> but here's Riddell so we can talk it out no
<janimo> now
<Keybuk> HiddenWolf: I actually find that hypocritical; because Debian is supposed to be all about open-ness and sharing, not about power or protection
<janimo> Riddell, elmo raised the issue that the xubuntu-docs license is GPL
<Keybuk> when you get a maintainer complaining that somebody has patched their package, I start to wonder why they so freely patch their upstream without taking the same consideration
<janimo> I based it on ubuntu/kubuntu docs so followed their license
<HiddenWolf> Keybuk, but the maintainer has the final word about a package. thus the maintainer has "power"
<ogra> janimo, that should be cc-sa 2.5 
<janimo> ogra, since when?
<dilinger> Keybuk: some people just like to complain.  that's what i have a blog for, for example.  ;p
<janimo> not two weeks ago for sure
<Keybuk> dilinger: ah yes, the "b" in "blog" stands for "bitch" :p
<ogra> janimo, see edubuntu-artwork (whih contains the docs in edubuntu dapper)
<Keybuk> (old jwz-related joke)
<janimo> ogra, I am talking about ubuntu-docs :)
<janimo> I know artwork is CC
<Keybuk> HiddenWolf: it's not final though, because the package is freely licenced, anyone (Ubuntu, DCC, users, etc.) can change it again
<Keybuk> and that seems to upset some people
<Keybuk> *shrug*
<dholbach> janimo: i test-installed xubuntu on an old 350mhz box - it runs nicely :)
<Keybuk> personally I think those people have somewhat misfired priorities
<janimo> ogra, which btw if you based on ubuntu-docs you're a GPL violator ;) 
<ogra> janimo, i never touched ubuntu-docs, but generally all packages that are originated in ubuntu and can contain artwork or screenshots should be under this license
<janimo> dholbach, cool! the one in the corner of your room ?
<dholbach> janimo: yeah
<HiddenWolf> Keybuk, like I said, it takes a certain attitude to be truly open. :)
<janimo> ogra, should vs are not :)
<Keybuk> but then I guess I'm politically at the other end of the scale ;)  I don't even maintain my own software, and let other people do it :p
<dilinger> jordi: the debian and ubuntu kernel team have slightly different goals, as well
<ogra> janimo, i based on ubuntu-artwork ... since my only doc in dapper is the firefox homepage
<janimo> ogra, xubuntu-docs only contains the text of the ff start page
<dilinger> jordi: which make enough of a difference that sharing the codebase probably won't happen anytime soon
<janimo> that is in ubntu and kubuntu-docs under GPL
<Kamion> Keybuk: speaking of, bubulle's been trying to hunt you down to do a dpkg release
<Keybuk> Kamion: yeah, most people are hunting me down for that :p
<ogra> janimo, i can only talk aboutthe rules ;) i didnt break them, ask the ubuntu-doc package maintainer why his is having a sourcecode license :)
<Burgwork> janimo, ubuntu and kubuntu docs are GFDL and CC-by-sa
<janimo> ogra, yeah I am just doing that :)
<janimo> Burgwork, since when? I looked in their changelogs and saw only GPL
<Burgwork> janimo, since Dec 2004
<Burgwork> janimo, that is a mistake in packaging. can you file a bug on it?
<janimo> Burgwork, oh nice.So the debian/copyright file is wrong
<janimo> Riddell, ^^ do you take care of kubuntu-docs or should I file a bug on that too?
<jbailey> doko: Errm should be libc6-i386-dev, I think, shouldn't it?
<Pygi> pitti: ping
<janimo> elmo, it seems it's a packaging oversight, do I upload another version to NEW?
<janimo> alternately you allow it in and I upload the fix to debian/copyright
<elmo> janimo: sure
<elmo> no, it's been rejected, a new upload is needed
<janimo> ok
<janimo> elmo, also the main upload priv if you please ;)
<elmo> gstreamer0.8 is scheduled for kitten-pulping, right?
<Riddell> janimo: I'll take care of it
<sabdfl> seb128: is there any easy way to test the new gstreamer 0.10 capabilities?
<sabdfl> mdz: ^^^ re xine vs gstreamer
<Riddell> elmo: gstreamer0.8 is still used by kaffeine and amarok
* Keybuk puts down his tea carefully
* Keybuk swallos
<Keybuk> "kitten-pulping" ?!
* ogra grumbles evlish in direction of VIA and ASUS
<janimo> Burgwork, so I file a bug on ubuntu-docs and one of the uploaders fixes it then I copy the same license to xu-docs. Sounds ok?
<elmo> Riddell: is that going to be fixed before dapper?
<elmo> Keybuk: "removal" is such a cliche
<Riddell> elmo: the gstreamer thing?  I certainly hope so but can't 100% guarantee
<elmo> Riddell: if it's not, I'll set infinity on you
<Burgwork> janimo, yes
<elmo> Riddell: (seriously, carrying two versions of such a big package would suck, it'd be Really Nice if we could get rid of 0.8)
<seb128> sabdfl: what do you mean by "capabilities"?
<seb128> elmo: the plan was to get 0
<seb128> 0.8 moved to universe if possible
<jordi> dilinger: nod
<seb128> but seems that KDE guys are slow :p
<jordi> seb128: don't expect any other human to be like you mkay
<dholbach> seb128: there are quite some other rdepends still, no? :)
<seb128> dholbach: from main/GNOME? gnome-media/sound-juicer, we don't really care about the first and the second has a patch upstream I've just not updated yet
<Riddell> elmo: totally agree, we don't want to support an obsolete gstreamer for 3 years, I'm doing what I can to make sure we have gstreamer0.10 versions in time
<dholbach> seb128: i just had a quick look at the rdepends of libgstreamer0.8-0
<seb128> dholbach: that includes universe :)
<dholbach> yeah
<janimo> dholbach, does the gdm package still patch gdm.conf?is it expected it will used gdm-custom or is that left for admins?
<dholbach> janimo: it patches config/gdm.conf.in
<janimo> I am thinking about how to integrate xubu gdm settings as non-intrusively as possible
<dholbach> janimo: yeah, i installed wdm for the fun of it :)
<janimo> and?
<janimo> I did too befor ebreezy but it's ugly and needs config love too
<janimo> gdm is more suitable
<dholbach> yeah, i think so
<janimo> btw did you notice faster startup with 2.13.04 by any chance?
<janimo> did the degnomification have any visible effect?
<dholbach> maybe a bit
<dholbach> the bootchart might know :)
<mdz> sabdfl: I'd start with playing a video and seeing if the sound is in sync
<mdz> sabdfl: totem-gstreamer seems to be using 0.10 now
<Burgwork> sabdfl, https://wiki.ubuntu.com/Media/Testing
<Keybuk> . o O { the plinky music is synchronised with the video? }
<janimo> would it be a bad idea to include the common doc licenses too in /usr/share/common-licenses? 
<janimo> pasting many pages in debian/copyright is not much fun :)
<Burgwork> janimo, seems sensible
<janimo> should I file a bug in ubuntu bugzilla or debian BTS?
<Burgwork> janimo, ubuntu
<janimo> ok
<janimo> much nicer
<janimo> pitti, can you estimate when you have time to review xfce related packages for main inclusion? thanks
<Diziet> Joy.  `firefox invalid to show in thai language'.  Kudos to the reporter for managing to be vaguely coherent in the report but what a nice one to try to fix.
<mdz> Diziet: are you on top of the firefox certificate breakage?
<mdz> Diziet: thai language -> sounds like one for upstream
<Diziet> mdz: cert breakage> I'm going to fix it tomorrow.  I hope that's soon enough.
<Diziet> I knew that it was too good to be true when no-one reported any problems with the nspr rearrangements for a whole day after I uploaded.
<jbailey> Diziet: Right, reminds me that I have to file a bug on FF not working without LANG=C for me.  I had totally forgotten about that. =)
<Diziet> jbailey: Yes, please, all I need is more bugs :-).
<jbailey> Diziet: I take the simpler solution and I generally use epiphany-browser instead. =)
<jbailey> Diziet: That way I don't feel compelled.
<jbailey> *seb128* gets my bugs instead. ;)
<pvanhoof> for when is a new version of firefox expected in dapper? The current version is extremely unstable :-\
<Diziet> pvanh: Tomorrow, and there'll probably be another one shortly after that.
<Diziet> In what way(s) is it unstable ?
<Diziet> (There are some known bugs, but I would like to be sure yours are those ...)
<pvanhoof> The downloads don't showup in the download manager
<pvanhoof> and it very often crashes
<pvanhoof> I've already tried installing a different theme, for the download manager problem. Didn't solve the issue
<Diziet> The download manager is a known problem.  I investigated it for a day or so before Christmas but I need to work on it some more.
<Diziet> `Very often crashes'.  Hrm.
<pvanhoof> Yeah :), "very often"
<pvanhoof> Like: most pages
<Diziet> After you do anything in particular ?  What architecture ?  Do you have extensions/plugings/etc. ?
<pvanhoof> well, not most pages. Just a lot websites and webpages
<pvanhoof> i386 with 686 kernel, no additional plugins installed
<Diziet> One example where it always crashes with a fresh profile would be ideal.
<pvanhoof> fresh hoary (with not a single change) to dapper upgrade
<Diziet> As in, file a bug with `steps to reproduce: mv .mozilla .mozilla-aside; firefox&; visit http://....'.
<Diziet> Or is it not that reproduceable ?
<pvanhoof> The problem is that the problems look like races. Often I can after firefox restart load the crashing page perfectly
<Diziet> Oh.
<pvanhoof> I know that sucks
<pvanhoof> :)
<pvanhoof> Oh wait, I do have Java(TM) Plug-in 1.5.0_06-b05 and Flash Movie player Version 0.4.12 as plugins
<Diziet> Can you find a recipe that makes it nearly-always crash for you ?  As in, `start it, visit this url and then this one and hit reload a lot' or some such.
<pvanhoof> I'll try
<Diziet> Oh.  Can you take those out and see if it still does it ?  Easiest is to move your .mozilla aside.
<Diziet> If you  mv .mozilla .mozilla-aside  it will come up fresh.
<Diziet> When you're done testing you can  rm -rf .mozilla  and  mv .mozilla-aside .mozilla  to put everything back.
<Diziet> Um, assuming you installed them via ffox rather than synaptic.
<pvanhoof> this one is reproducable
<pvanhoof> www.vw.be, choose "Dealer Locator"
<pvanhoof> Check bock checkboxes in the new window, fill in .. for example "Sint Nicklaas"
<Diziet> Excellent.  Can you file a bug ?  My testbed isn't booted atm; I'm just wading through hundreds of emails.
<pvanhoof> go back to the parent window: it doesn't respond to keys on your keyboard
<pvanhoof> bugzilla on ubuntu or mozilla?
<Diziet> Ubuntu.
<Diziet> Oh dear.  `New: downloading by firefox display exceptionally'
<Diziet> Ah, screenshots.
<sivang> rehi all
<salsan> hi
<pvanhoof> http://bugzilla.ubuntu.com/show_bug.cgi?id=21836
<Diziet> pvanhoof: Thanks.  I'll try to look into that soon.
<pvanhoof> ok
<pvanhoof>  update-notifier: Depends: notify-daemon but it is not installable
<pvanhoof> is somebody going to fix that one? :)
<pvanhoof> E: Couldn't find package update-daemon
<sivang> pvanhoof: that was fixed for me this afternoon
<sivang> weird
<pvanhoof> perhaps are the mirrors out of sync?
<pvanhoof> which one are you using?
<sivang> pvanhoof: UK one, a.u.c
<sivang> mvo told me to use those when I had problems with update-* as well
<pvanhoof> that one does give me a new gnome-session ;)
<pvanhoof> but update-notifier stays broken
<pvanhoof> Package notify-daemon is not available, but is referred to by another package.
<pvanhoof> This may mean that the package is missing, has been obsoleted, or
<pvanhoof> is only available from another source
<pvanhoof> that's another error that the first one
<Diziet> Right, off for dinner now.  TTFN
<pvanhoof> s/that/than
<Kamion> pvanhoof: just needs to be promoted to main, that's all; doing now
<pvanhoof> http://uk.archive.ubuntu.com/ubuntu/pool/main/u/ doesn't contain a update-daemon
<pvanhoof> ok, thanks
<Kamion> oh, hmm, I'm not sure that this is a continuation of notification-daemon
<Kamion> somebody will need to do up a main inclusion report for it, then
<Kamion> sivang: it's fixed for you because you have universe in your sources.list; pvanhoof doesn't
<pvanhoof> *adding universe*
<Kamion> in the meantime, just ignore it
<pvanhoof> wieerd, I have this one: deb http://be.archive.ubuntu.com/ubuntu dapper universe
<pvanhoof> aha, be's universe isn't synced
<Kamion> be.archive.ubuntu.com isn't the master archive
<pvanhoof> getting lots of new updates ... the be mirror guys should fix their stuff :)
<Kamion> and from the looks of it it hasn't updated much at all since November
<Kamion> Znarl: ^-- be.archive hopelessly out of date
<Kamion> though I suppose it's still OK for breezy
<pvanhoof> mplayer-586: Depends: libjack0.80.0-0 (>= 0.99.0) but it is not going to be installed
<pvanhoof> new problem :)
<Kamion> you know where the bug tracking system is, and it's not here ...
<pvanhoof> :p, sorry
<pvanhoof> Using unstable distro's is fun. Just don't break development stuff AND the stuff VMWare needs .. doing a new project at newtec for which I need at least vim, gmake and g++ :p
<sivang> Kamion: ah , right. thanks for the note
<sivang> pvanhoof: you better have a breezy installation next to you, trust me
<pvanhoof> sivang, yeah .. that's why you guys shouldn't break VMWare :)
<pitti> pvanhoof: we need to do that to count the dapper user base :)
<sivang> ROTFL
<pvanhoof> :p
<pvanhoof> by the way, Xen would be nice
<pvanhoof> I tried it on a dapper .. it does work a little bit :)
<pvanhoof> after building an initrd of course
<pvanhoof> Mainly issues with the mouse. But for example X11 works
<pvanhoof> of course not fglrx and stuff like that
<pvanhoof> and I would like to use the video card on a guest, rather than the monitor (for that I assume I'd have to assign the pci device of my ati card to the guest)
<pvanhoof> Using ubuntu mainly for development .. I can assure virtual machines are used a lot for a lot projects and testing
<pvanhoof> Until that day, I'll pay vmware :)
<elmo> Kamion: what's that feature in ssh called where you can have one machine explicitly trust another machine, and let bob ssh from foo to bar as bob without creds?
<pvanhoof> private and public keys?
<Kamion> elmo: HostbasedAuthentication in protocol 2
<pvanhoof> ah
<elmo> Kamion: right, thanks
<elmo> Kamion: how insane is that, do you think?
<Kamion> elmo: it's fine if you trust DNS
<Kamion> hostbased auth still checks the host keys (unlike old .rhosts)
<elmo> ok
<Mez> elmo: can you sync python-feedparser from debina please-  no ubuntu package :D
<elmo> feedparser | 3.3+cvs20051220-1 | dapper/universe | source
<elmo> mez: nothing to sync
<Mez> oh :D lol - It wasnt there yesterday :D
<elmo> yes it was
<elmo> it's been there since 30 Dec
<Mez> well whenever i tried to install ipodder :P
<Mez> lol
<Mez> musta not update'd
<Mez> :D
<Mez> lol
<Mez> sorry :D
<Mez> elmo - any ideas why I'm not getting katie emails to my mez@ubuntu.com email ? It's starting to annoy me now
<Mez> oh, and cheers for the backports :D
<elmo> mez: no idea, no, I'll look a bit later
<Mez> elmo: cheers :D
<jdahlin> what's the state of dapper, is it somewhat usable/stable yet?
<seth_k|lappy> I've been using it since day 1, jdahlin 
<seth_k|lappy> I've never had showstopper problems (similar to the ones encountered during Breezy cycle)
<zyga> did anyone notice that restart seriously hangs and requires hard reboot / remote reboot 
<zyga> even doing ps aux hangs at that point
<zyga> how to force dpkg to extract configuration files again
<zyga> nn
<BenC> --force-confmiss
* BenC remembers implementing that feature
<zyga> dpkg could use a smaller, more helpfull --help message 
<zyga> I don't really understand what's the purpose of --license in the default help screen ....
<zyga> BenC: thanks :-)
<zyga> (as if gnu/linux systems had insufficient amount of copies of GPL around)
<Amaranth> zyga: there should only be one copy
<zyga> Amaranth: yeah right common-licenses 
<Kamion> zyga: dpkg --license almost certainly predates /usr/share/common-licenses/
<zyga> Kamion: If I ever hack dpkg I'll sure to patch that and the help screen :)
<Kamion> dpkg's --help is helpful, when you need it
<Kamion> if you have problems with it, you probably shouldn't be using dpkg directly anyway ...
<zyga> Kamion: it's not organized right IMHO; I could compare it to tla --help and bzr help
<zyga> s/tla --help/tla help/
<zyga> the former spits out gobs of text, the latter spits out just enough
<Kamion> when I'm reaching for dpkg --help, it's because I need the obscure stuff *shrug*
<zyga> Kamion: I wouldn't touch it if the tool of choice, apt, had 'fix this package for me, I'm dumb' command (aka full-reinstall)
<zyga> :-)
<Kamion> so add it to apt?
<Kamion> you can do it in apt with ultra-weird options, but it would be nice to have an easier way to get at --force-conf{miss,def} at least
<zyga> Kamion: I always wanted apt-get reinstall instead of install --reinstall
<zyga> I might look at it some day
<Kamion> I'm sure a wrapper script would be trivial anyway
<Kamion> there's wajig if you want that sort of wrapper ...
<zyga> wajig?
<zyga> oh :)
<Kamion> (don't particularly care for it myself, but hey)
<stratus> mvo, new gdebi revision (the most important error handling needed atm, i think - console only)
<mvo> stratus: merging now
<stratus> mvo, is there gdebi somewhere in launchpad? i was trying to start translating it there, just to see how it works
<mvo> stratus: https://launchpad.net/distros/ubuntu/dapper/+sources/gdebi/+translate
<mvo> but it seems to be not yet ready for translation in rosetta, may carlos knows what to do
<carlos> mvo, dapper translations are not yet imported
<mvo> aha, thanks carlos 
<carlos> some of them appear because a script was run before it should
<jordi> carlos: oh
<hyperactivecrond> does the current ubuntu grub support gfxboot?
<stratus> mvo, no problem i'll follow the old way
<Burgwork> hyperactivecrond, in dapper yes
<hyperactivecrond> Burgwork: so no in breezy then...
<Burgwork> hyperactivecrond, oh wait, I am tired. I have no idea
<Kamion> hyperactivecrond: no, and it won't
<Kamion> as I said to you earlier
<Kamion> not in dapper, anyway
<hyperactivecrond> i'm asking this b/c i planned on making a customization of ubuntu, to run on a dvd, that has ubuntu, kubuntu, and xubuntu-desktop's instlaled. ok thx Kamion
<janimo> jordi, which is the largest project that uses rosetta for translations
<Kamion> if you need it, you'll have to fish out the patches from SuSE
<shaya> seb128: evolution bug: evolution: symbol lookup error: /usr/lib/evolution/2.6/components/libevolution-mail.so: undefined symbol: mail_tool_get_local_movemail_path
<hyperactivecrond> Kamion: so the ubuntu cd uses syslinux for booting,then?
<Kamion> hyperactivecrond: yes, we always have
<hyperactivecrond> ah. thanks.
<mvo> stratus: thanks for the diff :) merged 
<Kamion> I'd wait until gfxboot-theme-ubuntu matures a bit more, though, if I were you
<seb128> shaya: does it crash?
<shaya> yes
<shaya> 2.5.4-0ubuntu3
<seb128> shaya: evolution --force-shutdown && evolution?
<hyperactivecrond> Kamion: ok... 
<shaya> tried
<shaya> try again I will
<stratus> mvo, i think it cover the most common mistakes that the user will do after install the package
<jordi> janimo: well, some language teams are successfully using Rosetta to translate OpenOffice (Esperanto and Kurdish)
<mvo> definitely!
<shaya> same crash
<shaya> actually, less of a crash, then an exit
<stratus> mvo, the only one left out is when user try to run gdebi manually against a non-deb package, it stills spits out a backtrace on him
<shaya> yes, no crash, exit
<Kamion> hyperactivecrond: (i.e. I'd suggest just using the old syslinux in breezy for now and documenting the boot parameters)
<shaya> gdb says Program exited with code 0177
<janimo> jordi, I am wondering if rosetta is mature enough to propose it being used exclusively by a project
<Kamion> but obviously it's up to you
<hyperactivecrond> Kamion: planned on
<janimo> are gnome/kde not playing with it yet?
<jordi> janimo: many smaller projects are using it already.
<janimo> jordi, is there a current status/feature roadmap for rosetta somewhere?
<jordi> janimo: KDE and GNOME have their own translation infrastructure. We're working on a few things that will make it possible to transalte GNOME/KDE via Rsoetta without conflicting with their infrastructure though.
<Burgwork> janimo, you thinking of moving all of xfce onto it?
<janimo> what are the main hurdles you see right now before it could suit most projects needs
<jordi> janimo: for future plans, just look at the specs registered for http://launchpad.net/products/rosetta
<jordi> th
<jordi> that's our roadmap
<janimo> Burgwork, exactly, but before proposing this to xfce I need to see if it;s feasible :)
<stratus> mvo, i'll translate it to pt_BR and see if there's something more that i can bring into the code (probably not, i'll be short in time) in two or three hours. It's up to you when a new version could be released then. =)
<janimo> jordi, thanks. As Burgwork noted I am thinking what it would take to try convincing xfce to try using it
<jordi> janimo: xfce, as a project with multiple products under the same umbrella, would currently find some problems with the permission handling of product groups
<shaya> seb: nothing seems to have "mail_tool_get_local_movemail_path"
<mvo> stratus: your changes justify a release already, feel free to upload it :)
<seb128> shaya: move on #ubuntu-desktop please, it's way too noisy here
<janimo> jordi, ah so maybe a bit further on?
<shaya> downloading source package, to see where its used
<stratus> mvo, great i'll do.
<jordi> it basically depends on your needs. Do you need that only some designated people by xfce admins are able to work on those translations, or would you allow anyone to contribute to, say, the French translation?
<Burgwork> jordi, janimo shall we move to #launchpad?
<mvo> stratus: thanks
<janimo> ok
<janimo> moved over
<jordi> Burgwork: sure
<hyperactivecrond> how did we get syslinux to support gfxboot? is it in a deb?
<hyperactivecrond> never mind.
<wftl> Is there a list of major packages to be included in the final Dapper? I'm not looking for individual debs, but specific applications. For example, under the Sound & Video menu, will the basic CD player app still be there (it's not in Flight 2)
<tseng> some desktop items are hidden
<Burgwork> wftl, dapper is not final yet. And there has been some programs hidden. See https://wiki.ubuntu.com/MenusRevisited
<tseng> the menus were too crowded
<mdke> wftl, put an audio cd in, it should open automatically
<sivang> night all
(mdz/#ubuntu-devel) especially given that it's a regression from breezy
<Mithrandir> you think the new livecd is a regression from breezy?
<mdz> no, the usplash support has regressed though
<Mithrandir> but that'll be fixed with the initramfs-usplash patches and we'll all in all end up with a lot smoother live than before
<mdz> yes, that's the plan, but I'm saying that there's a little more to it than waiting for usplash-initramfs to land
<Mithrandir> sure
<mdz> usplash support was a part of the summary for the simplified-livecd spec; the text of the spec delegates that concern to usplash-initramfs, but that spec doesn't cover the livecd-specific aspect that I see
<Mithrandir> I'll make sure that we have usplash working, even if it falls between the crack between the specs.
<mdz> I appreciate it
<Mithrandir> I'm more worried about how it looks as a whole than whether it's my responsibility or not to fix it from fine-reading the spec. :-)
<mdz> functionally it's looking good
<mdz> have you talked with lamont or infinity about getting livefs images in squashfs format in addition to the existing ones?
<mdz> it should be pretty easy for them to arrange
<Mithrandir> yes, or rather, infinity said "we'll talk about it on friday"
<mdz> good
<Mithrandir> it's not a hard thing at all.  I want to play with squashfs-lzma as well, since that saves us even more.
<lamont> mdz: you're making me cry
<mdz> Mithrandir: you mentioned a figure of ~100M?
<mdz> that's fairly astonishing
<mdz> lamont: am I?
<lamont> du -s public_html/LiveCD/
<lamont> 20131140        public_html/LiveCD/
<Amaranth> squashfs-lzma saves ~100M?
<lamont> but hey, disk is cheap
<mdz> lamont: how much per build?
<Mithrandir> 15:34 < Mithrandir> -r--r--r--  1 root root 520M 2005-12-19 12:34 /home0/filesystem.cloop
<Mithrandir> 15:34 < Mithrandir> -rwx------  1 root root 495M 2005-12-19 13:52 /home0/filesystem.squashfs
<Mithrandir> 15:34 < Mithrandir> -rwx------  1 root root 436M 2005-12-19 15:33 /home0/filesystem.squashfs-lzma
<lamont> that's on the order of 4 builds
<Amaranth> Mithrandir: holy shit
<lamont> and has both the cloop and fsimage for each
<mdz> lamont: we can scrap the uncompressed version when the build is done
<mdz> lamont: oh, you need it for the next one
<lamont> mdz: not if you want rsync-love
<lamont> yeah
<Amaranth> hey, you could fit more languages and/or mono on there with the extra room ;)
<lamont> well, we could uncompress it at the start, but sigh.
<mdz> only the N-1th build though
<Mithrandir> mdz: yeah, and squashfs (both lzma and regular) are rsyncable.
<mdz> but unless the machine is out of disk space...;-)
<mdz> Mithrandir: is decompression performance significantly different?
<lamont> mdz: that 20 is 2 each * 4 at ~2.3GB/build
<mdz> lamont: 2 each?
<lamont> yeah, the other 1 or 2 failed...
<lamont> the prune script just nukes things > 3 days old
<Amaranth> i remember lzma being slightly slower than gzip and a lot faster than bz2
<Amaranth> dunno what cloop is/uses though
<lamont> unless it's the latest or current (last successful), in which case, it's timeless
<mdz> cloop uses gzip mostly
<lamont> Amaranth: gzip
<Amaranth> ok then
<lamont> our images are almost entirely gzip -9, according to the log
<Amaranth> this is probably one of those things where the small size makes it faster to get off disc so it ends up being a tie or win
<lamont> hrm... istr maybe we just forced that, instead of letting it try -1 through -9 before deciding that -9 was best.
<mdz> it supports gzip and 7zip
<lamont> mdz: it wouldn't be to much of a tweak to have the prune script nuke everything _except_ latest&current
<Amaranth> 7zip's "native" format is lzma
<mdz> hmm, we could try cloop+7zip
<mdz> I doubt it'll be as good as squashfs-lzma though
<Mithrandir> mdz: devmapper+cloop: ~367s till disk activity is settled, unionfs+cloop: ~326s, unionfs+squashfs: ~231s
<mdz> Mithrandir: !
<Mithrandir> mdz: basically, since you're pulling stuff off the CD, it's the cd which is the bottleneck
<daniels> Kamion: ping
<Amaranth> it's faster than cloop _and_ 100M smaller?
<daniels> Kamion: have you seen the xkb-on-console-keymap work?
<Mithrandir> yeah, and squashfs gives us the ability to sort the filesystem however we want
<Amaranth> Mithrandir: yeah, that's what i was guessing
<mdz> Amaranth: not entirely surprising, given that cloop knows nothing about the filesystem
<Amaranth> Mithrandir: you can use the same argument for using lzma for packages too :)
<mdz> every metadata block has to be decompressed too
<Mithrandir> so we can do some cool readahead-based magic and probably just grab the first 100M or so off the CD in one long read.
<Amaranth> it'd be nice to have a livecd that didn't take 3 minutes to start
<Mithrandir> that'd be fairly sweet.
<Amaranth> or longer
<Amaranth> i stopped counting at 3 :P
<Mithrandir> Amaranth: http://people.ubuntu.com/~tfheen/live-bootcharts/unionfs-squashfs-dapper-20051216-1.png is from my machine (which is fast and has plenty of ram, but still.)
<mdz> Mithrandir: when we do data collection to create the readahead list, we can use that same data to sort the filesystem
<Mithrandir> mdz: exactly what I was thinking.
<mdz> is squashfs going upstream?
<lucas> do members of ubuntu-dev have the right to upload multiverse packages ? or does it have to be an ubuntu-core-dev ?
<Mithrandir> mdz: hmm, we could do something like bootchart=upload.  readahead=upload, so we could collect usage stats and see what apps people actually started in the first couple of minutes after boot and put those early (and readahead them too, if possible)..
<mdz> lucas: ubuntu-dev can upload to multiverse
<lucas> ok, thx
<Mithrandir> mdz: I don't know; it seems to be nice and stable, so it could, at least.
<mdz> more likely than cloop, certainly
<Amaranth> Mithrandir: that dang "init" thing seems to be running the whole time, you should try to kill it ;)
<Mithrandir> Amaranth: ;-P
<mdz> Mithrandir: someone suggested using inotify to track file access during boot; that sounded like the right idea
<Mithrandir> mdz: I have suggested it multiple times, I just haven't had time to actually write the code. :-)
<mdz> I didn't realize inotify could detect read access
<dholbach> have a nice evening
<Mithrandir> it can do everything, including summoning dragons and making pigs fly.
<Mithrandir> but, I'm off to bed now.  See you around.
<Amaranth> night
<mdz> good night
<psusi> wait a second
<psusi> lzma for the squashfs saved 100M?  using the same block size?
<psusi> 7zip can save a LOT of space but it seems to do so mostly through use of extreamly large dictionaries... which only apply to data blocks that are larger
<psusi> cramfs/squashfs/cloop all use small block sizes to allow random access
<Mithrandir> psusi: it works, at least, so yes.
<Mithrandir> psusi: that is, I haven't actually booted squashfs-lzma, but it should work.
<Mithrandir> it works for the openwrt people.
<Mithrandir> but, night, for real.
<doko> Kamion: do you have a schedule for the next live CD?
<doko> mdz: would it make sense to name packages/package sets in UpstreamVersionFreeze, for which we want make an exception or propose an exception?
#ubuntu-devel 2007-01-01
<davyd> hey guys
<davyd> I went to Feisty to get my fix
<davyd> and it's not booting
<davyd> something about waiting for root filesystem
<davyd> which leaves me at a loss to debug it
<realist> davyd: please read the topic :-)
<davyd> which bit?
<bddebian> Happy New Year!
<pitti> hello everyone
<pitti> happy new year!
<bddebian> And to you pitti
<pitti> bddebian: greetings
<bhale> happy new year pitti 
<Chipzz> happy new year! :)
<pitti> Chipzz, bhale: happy 2007
<Chipzz> thx pitti :)
<lifeless> morning
<_ion> Evening.
<LarstiQ> Who should I talk to for getting a newer version of bzr into dapper?
<_ion> Probably the backports people.
<LarstiQ> _ion: how do I reach them?
<_ion> http://www.google.com/search?q=ubuntu+backports
<mdke_> LarstiQ: since it's bzr, it would be a special case for a backport I reckon and you could talk to a core developer. jbailey maybe?
<mdke_> or "Etienne Goyer" who seems to be the Ubuntu maintainer
<LarstiQ> ooh, would that work?
* LarstiQ is not very familiar with ubuntu, just knows the bzr side of things :)
<LarstiQ> mdke_: thanks, I'll talk to both of them
<mdke_> it's worth a shot
<fdoving> there is also a wiki explaining how to request a backport, if that's what you're looking for.. 
<fdoving> https://help.ubuntu.com/community/UbuntuBackports
<LarstiQ> fdoving: I was looking for a medium to (interactively) talk with people who have a say in the matter
<mdke_> I reckon you might get it in -updates through a core dev, give those two an email
<LarstiQ> mdke_: aye, thanks to your earlier suggestion I've now mailed them
<LarstiQ> ciao! :)
#ubuntu-devel 2007-01-02
<panpan> bonjour et bonne annee !
<tsmithe> et vous aussi!
<panpan> merci
<tsmithe> ca va bien?
<panpan> oui et toi ?
<tsmithe> super!
<panpan> pourai tu m'aider car je suis debutan sous ubuntu et jai beaucou de mal 
<tsmithe> pas en #ubuntu-devel, je crois
<panpan> je sort tou juste de windows donc sa change :)
<panpan> pardon ?
<tsmithe> il faut parler anglais aussi, ici
<tsmithe> ;)
<panpan> a bon ? oulala
<panpan> moi et l'angais
<tsmithe> !fr
<tsmithe> ...
<tsmithe> allez en #ubuntu-fr ;)
<panpan> ok merci :)
<panpan> aurevoire
<tsmithe> au voir
<panpan> et bonne soir
<tyme-> Does anyone know what library is used for on screen notifications? ie: battery charged, time left etc
<Amaranth> libnotify
<Amaranth> notification-daemon
<Amaranth> tyme-: ^
<tyme-> <3
<tyme-> where is the dbus services located?
<somerville32> Does anyone want to take a look at my really awful python code? :)
<PuMpErNiCkEl> What does it do?
<somerville32> It is the Ubuntu Weekly Newsletter Fesity Changes Mail Spool Parser
<somerville32> UWNFCMSP for sort <g>
<somerville32> *short
<PuMpErNiCkEl> :o
<somerville32> Yes, and code is even more gross :)
<PuMpErNiCkEl> Hm... it sounds strangely interesting.
<somerville32> Offering via DCC
<tyme-> why not paste the code somewhere
<somerville32> Interesting idea
<tyme-> !halp .... -> checking for DBUS... no ; anyone have any idea why it's not finding DBUS? I have all the packages installed.. libdbus, dbus etcetc
<tyme-> pastebin.com somerville32
<lifeless> or rafb.net/paste which is about 10x faster
<somerville32> http://paste.ubuntu-nl.org/207/
<somerville32> It took about 20 minutes to code and test - it works so I guess I'm happy
<pitti> Good morning
<somerville32> Morning Pitti
<lifeless> hey pitti
<pitti> hey guys, had a nice celebration?
<somerville32> I stayed at home and coded :/
<lifeless> I had a gastro-virus :(
<tyme-> !halp .... -> checking for DBUS... no ; anyone have any idea why it's not finding DBUS? I have all the packages installed.. libdbus, dbus etcetc
<lifeless> tyme-: are you doing development ?
<somerville32> I bought some rootbeer, cream soda, and cheezies - that was my excitement of the day.
<tyme-> yea
<lifeless> tyme-: what is that message coming from ?
<tyme-> lifeless:  from ./configure
<lifeless> is this a new package, or an existing package you are rebuilding ?
<tyme-> existing package. I have all the libdbus/dbus packages updated 
<lifeless> wdo you have libdbus-1-dev ?
<tyme-> yes
<lifeless> configure should output a log file showing what it ran
<lifeless> have a look at that
<tyme-> sec..
<tyme-> seems it cant find it because it's not in pkg-config search path
* mneptok stirs
<somerville32> Is Feisty still dead?
<lifeless> dead?
<somerville32> Totally fubar?
<pitti> somerville32: WFM...
* pitti thought you refered to the relative upload silence over the holidays
<somerville32> I was ambiguous, wasn't I.
<Amaranth> somerville32: apparently if you use SATA you are fine, PATA has problems for some people
<cjwatson> morning
<cjwatson> pitti: have you ever security-reviewed putty? I finished porting it to gtk2 yesterday at last, and have been thinking of proposing it for main ...
<Fujitsu> :O
<pitti> cjwatson: hello, and happy new year!
<pitti> cjwatson: no, I never took a look at it
<Fujitsu> GTK2 PuTTY! It might look sane now :)
<pitti> cjwatson: I'd be particularly interested in whether it properly mlock()s passphrases and such
<cjwatson> font selection is broken since putty is expecting to use server-side fonts but gtk2's font selector only offers client-side fonts; aside from that it seems to be working ok
<cjwatson> Fujitsu: http://www.chiark.greenend.org.uk/~cjwatson/tmp/putty-gtk1.png versus http://www.chiark.greenend.org.uk/~cjwatson/tmp/putty-gtk2.png
<cjwatson> pitti: no use of mlock() in the source ...
<Fujitsu> Looks much better, cjwatson :)
<cjwatson> pitti: openssh doesn't mlock passphrases either
<cjwatson> it's an interesting question for an ssh implementation; you should clearly mlock keys as well as passphrases. What about session state?
<cjwatson> one would hope it's not possible to derive the key from the session state, of course
<doko> is the upload queue currently working?
<cjwatson> doko: yes, you just hit a known fails-sometimes-for-no-reason case with gcc-3.3
<cjwatson> doko: the current workaround is just to upload it again :(
<cjwatson> http://librarian.launchpad.net/5576777/elasrd0hlwGdtKrSAudllG0sjjp.txt
<doko> ok, trying again
<cjwatson> strange that it bit two successive uploads though
<Fujitsu> cjwatson, it's been happening a /lot/ lately.
<Fujitsu> A large percentage of uploads are dropped.
<cjwatson> it seems to be a couple a day
<crimsun> cjwatson, it hit four of mine in a row a couple days ago.
<cjwatson> I'm not in a position to fix it, although I will raise it as a Soyuz priority
<doko> cjwatson: can I watch the upload processing myself (if it fails or succeeds)? 
* Fujitsu hopes we get bugmail back soon...
<cjwatson> doko: afraid not; I can watch it for you
<doko> uploaded again
<cjwatson> but of course if it succeeds you will be mailed
<cjwatson> non-security uploads are processed every five minutes (*/5 * * * *); if you aren't getting mailed in that time plus usual mail delays, you can generally assume that there is some kind of problem
<Mithrandir> cjwatson: putty/pterm in main> shiny!
<iwj> Hello again everyone.
<Mithrandir> iwj: regarding the discussion about domU kernels for Xen we had in MTV, have you looked into pygrub in the xen source tree?
<iwj> Yes, I did look at it a bit.
<Mithrandir> ok, I didn't know if you were aware of it or not, but if you are, good. :-)
<iwj> It uses an interface that our Xen didn't have at that point.
<Mithrandir> cjwatson: are you fixing vim to be installable again or should I?  It fails in postinst when it tries to do some alternatives mangling
<jdub> Mithrandir: any purpose for putty/pterm in main other than supportability?
<Mithrandir> jdub: I'd like my terminal emulator to be security supported.
<Mithrandir> and I believe cjwatson does too. :-)
<Mithrandir> so no, no other reason
<cjwatson> jdub: nicer interface to opening ssh sessions than I believe exists elsewhere
<cjwatson> I remember the lack of such an interface came up way back in hoary or so, but putty wasn't suitable then due to gtk1-ness
<jdub> cjwatson: oh, ported! nice.
<cjwatson> Mithrandir: it's tricky and weirder than you might expect - there's a Debian bug about it
<jdub> how is it with utf-8 and so on?
<cjwatson> Mithrandir: repeat dpkg --configure -a a few times and it'll work
<cjwatson> jdub: it's had support for ages
<jdub> hrm, ucrrnetly built for 1.2 though
<cjwatson> jdub: yes, I finished the port yesterday
<jdub> rock on
<cjwatson> it has its own Unicode layer, so doesn't need pango for that
<jdub> using pango? oh
<cjwatson> making it use pango would be very difficult; since it's a cross-platform application, it needs to have lots of that code itself anyway
<jdub> might be helpful for text rendering tho
<cjwatson> it already has that :)
<cjwatson> it has to know how to do stuff like bidi and arabic shaping for other platforms anyway
<jdub> thai? arabic? indian? ... ? :)
<Mithrandir> cjwatson: uh, ok.
<cjwatson> thai, arabic both work, not sure about indic
<cjwatson> I think it's fine if you have the fonts
<Mithrandir> jdub: having it not use pango is a feature, antialiased terminal fonts is a nightmare.
<Keybuk> heh, I *like* anti-aliased terminal fonts
<Mithrandir> but they look like somebody ran over them with a truck
<jdub> Mithrandir: pango doesn't necessarily imply antialiased
<cjwatson> Mithrandir: Debian bug #399024
<Ubugtu> Debian bug 399024 in vim "Upgrade fails because of missing man page directory" [Important,Open]  http://bugs.debian.org/399024
<cjwatson> (subject is wrong)
<cjwatson> (well, sort of)
<Mithrandir> jdub: can you tell me what colour of stick I need to beat g-t with to make it give me proper fonts, then? :-)
<cjwatson> I think it might be possible to make putty use pango optionally in some kind of limited way to get at client-side fonts, but I don't think there's any point in replacing putty's cross-platform rendering code with it
<Keybuk> Mithrandir: hmm?  are your fontconfig settings right?
<cjwatson> putty needs to know enough about how text is laid out that moving to pango for rendering would represent a complete architectural reshuffling
<Mithrandir> Keybuk: I haven't touched them, apart from with clicky tools, so I believe so.
<tepsipakki> Mithrandir: I use "Fixed 10", you need to reconfigure fontconfig to enable bitmap-fonts though
<tepsipakki> (Fixed SemiCondensed 10 actually)
<Mithrandir> tepsipakki: hmm, I could try that
<nn> where can i get all the 'stuff' used to automate release builds? I'm working on a fork of ubuntu on top of FreeBSD (and eventually Open and Net too)
<tepsipakki> it's the same font that xterm uses by default, I think..
<nn> wanting to set up automated builds whenever something changes in either the ubuntu or {free,net,open}bsd upstreams
<nn> i really <3 ubuntu, but i really </3 linux kernel
<cjwatson> doko: I trust you noticed the openoffice.org-l10n FTBFS?
<doko> cjwatson: currently building on ronne
<cjwatson> doko: thanks
<Chipzz> nn: you're aware there already is a debian/fbsd port? :)
<pitti> hey rodarvus, happy new year!
<rodarvus> good morning!
<rodarvus> hey pitti!
<rodarvus> same for you :)
<doko> rodarvus: good morning
<doko> rodarvus: is the /usr/X11R6/bin -> ../bin symlink still needed?
<rodarvus> doko, hi there!
<rodarvus> doko, not for ubuntu itself, but for compatibility reasons, I guess
<doko> rodarvus: see bug 64726
<doko> rodarvus: see bug #64726
<doko> Ubugtu: ?
<rodarvus> let me check
<cjwatson> doko: dropping the symlink just for that bug seems like a rather nuclear approach, considering that there's an easy workaroun
<cjwatson> workaround
<Hobbsee> hey cjwatson!
<cjwatson> morning
<doko> cjwatson: well, first I would like to understand why the link is needed, after the transition to /usr/bin (for example, if there are binaries hardcoding paths to /usr/X11R6/bin)
<cjwatson> doko: "for example"> correct
<cjwatson> such instances are bugs (they should use /usr/bin/X11/ at the very least), but I'd like to keep the link around for as long as humanly possible
<doko> so our transition isn't yet finished =)
<cjwatson> even if it is, there will always be third-party binaries
<doko> ok, I'll summarize in the report
<cjwatson> doko: why doesn't our gcc just hardcode the paths it needs itself?
<cjwatson> it seems pretty weird for it to work them out from argv[0]  when in packaged form
<doko> yeah, you can argue that. the benefit is that you can unpack the installation in every place and it finds the correct binaries/headers etc. very useful to install the package multiple times and search for bugs between versions
<cjwatson> doko: fair enough; maybe a fallback to the standard location if the guessed one is wrong would be appropriate
<cjwatson> or even a specific exclusion for this case, hacky though that is
<doko> cjwatson: maybe a special hack to detect the /usr/X11R6/bin situation could be done. not sure if it's worth the effort.
* pitti sings 'where have all my uploads gone -- where're they ever?'
<pitti> Keybuk, cjwatson: any idea why my uploads (avahi, two times nss-mdns) got eaten?
* Hobbsee hugs pitti 
* Hobbsee ate them, she was hungry
<pitti> Hobbsee: spit it out!
<cjwatson> pitti: uploaded when?
<pitti> cjwatson: some hours ago, and just now
<Hobbsee> nope!
* Mithrandir tickles Hobbsee 
* Hobbsee tickles Mithrandir back, and stomps on his feet
<Mithrandir> Hobbsee: my feet are on my desk. :-P
<Hobbsee> who said i cant climb onto a desk?  or i could just tip your chair over :P
<cjwatson> process-upload seems to be stuck ...
<pitti> Hobbsee: yay tabledancing :)
<Keybuk> cjwatson: could it be failing to contact the ubuntu.com mail server?
<Keybuk> that seems to be down
<cjwatson> I'm stracing to find out
<elmo> Keybuk: eh?
<elmo> it is not
<Hobbsee> pitti: *grin*
<Keybuk> elmo: I'm not getting mail from it
<cjwatson> I don't think it's a mail problem, despite appearances
<elmo> Keybuk: Jan  2 12:13:37 fiordland postfix/smtp[32076] : 101C7B680B7: to=<scott-canonical@netsplit.com>, orig_to=<scott@ubuntu.com>, rela
<elmo> y=paperboy.netsplit.com[82.108.80.242] , delay=0, status=sent (250 ok 1167740017 qp 1709)
<cjwatson> lp takes about a week to start up inside strace
<cjwatson> insane numbers of imports
<Keybuk> elmo: the last bug mail I had was Friday ...
<Fujitsu> Keybuk, that's bug mail. It's stuffed.
<geser> Mithrandir: can you please give-back libzrtpcpp? thanks
<elmo> Keybuk: bug mail for LP is down, that's an entirely separate problem and is an LP code issue, nothing to do with mail servers
<cjwatson> it appears to hang doing an INSERT INTO SourcePackageRelease
<Hobbsee> oh well.  no bug mail means we cant fix any bugs, surely....
<Keybuk> elmo: ah, ok; I combined that with the lack of anything in my ubuntu folder (no spam!) and assumed that it was just down
<Hobbsee> speaking of bugs and mail....guess i'd better go figure out if i have to file a MIR.
* Fujitsu doesn't see any bugs on the bug mail issue.
<Mithrandir> geser: done
<elmo> Fujitsu: feel free to file one on launchpad, if there really isn't one, and let me know what it is, and I'll bump it to critical
<Fujitsu> I've checked the malone and launchpad products... anywhere else I should be looking?
<Hobbsee> Keybuk: no spam???  *gasps and dies*
* Hobbsee concludes that kmail is just crap.
<elmo> Fujitsu: no, that's it
<Seveas> well,bug mail isn't entirely down
<geser> where should a bug about out-of-date of Contents-$arch.gz files on http://archive.ubuntu.com/ubuntu/dists/feisty/ be filed?
<Seveas> I've received a few in the last week
<Seveas> geser, nowhere. Feisty is too much in flux to have an up to date Contents-$arch.gz all the time
<geser> this means apt-file is of no use on feisty now
<Mithrandir> geser: they shouldn't be, we generate them by hand once in a while.
<elmo> Seveas: I'd be surprised - the bug mail code has been disabled
<elmo> Seveas/Mithrandir: that's crack
<elmo> Contents files should be auto-generated
<elmo> but there's a bug open already, somewhere against the soyuz product, I'd imagine
<Seveas> elmo, 2:54 today i got one and one on thu, 17:29 and fri 10:43 (UTC)
<Mithrandir> I think we might have cronned it to happen weekly or so.
<geser> the current Contents files are from 25 Oct 2006
<Seveas> err, the friday mail is a false positive, sorry
<elmo> Mithrandir: then it's not working very well...
<Seveas> elmo, on another note: are you available tue 9th at 21:00 for a CC meeting?
<Mithrandir> elmo: it doesn't appear in lp_publish's crontab either, which would explain why. :-P
<elmo> Seveas: sure
<Seveas> great :)
<Keybuk> training fingers to learn a new passphrase is painful :(
<Hobbsee> haha
* Hobbsee wonders if it's better to fix kmail, or just remove install thunderbird by default in kubuntu :P
<doko> cjwatson: was the gcc-defaults upload rejected?
<elmo> smurf_: ping
<cjwatson> doko: stalled due to Soyuz bug being investigated
<cjwatson> doko: at least that's what's happening to all uploads right now
<doko> ok, collecting then for mass upload
<Hobbsee> Mithrandir: you're an archive admin right?  any chance you could push mailody through feisty NEW for me please?
<Mithrandir> Hobbsee: I did it half an hour ago
<Hobbsee> Mithrandir: way cool, thanks!
<cjwatson> doko: just upload them, they'll be processed when it's fixed
<cjwatson> doko: should be working again now, thanks to elmo, cprov, et al
<pitti> yay, thanks guys!
<zul> morning
<pitti> hi zul, happy new year!
<zul> hey pitti, you too
<Hobbsee> can someone tell me why tuxguitar 0.8-3 was REJECTED.?
<Hobbsee> (sync from debian)
<Mithrandir> Hobbsee: it has licence problems.
<Hobbsee> right
<Mithrandir> ships some binaries in the .orig.tar.gz without source
<Mithrandir> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405295
<Ubugtu> Debian bug 405295 in tuxguitar "tuxguitar: files without source in tarball" [Serious,Open]  
<Mithrandir> Hobbsee: sorry that I forgot to Cc you on the rejection mail, but I didn't remember it was a requested sync.
<Hobbsee> Mithrandir: OK
<Hobbsee> ahhh
<zul>  Mithrandir: i should have xen-3.0.4 by the end of the week so you can play with it
<xerxas> Hey all ! 
<xerxas> Happy new year 
<Mithrandir> zul: yay
<bddebian> Heya
<giskard> ciao
<smurf_> elmo: ?
<doko> cjwatson, Mithrandir, Keybuk: please could you process the subversion binaries in NEW?
<Mithrandir> doko: I'll do it
<Welsh_Dwarf> Hi everyone, I've got a question about customising debian-installer (ubuntu alternate), whiwh is: what is a udeb? is it the same format as a deb?
<Welsh_Dwarf> which is, sorry :)
<Mithrandir> doko: or somebody did it before me; there are none there now.
<Welsh_Dwarf> Oh, and happy new year to all!
<evand> Welsh_Dwarf: http://people.debian.org/~fjp/talks/debconf6/paper/index.html#id2535182
<Welsh_Dwarf> Brilliant, thanks :)
<elmo> umm, how do you start ubiquity in expert mode?
<elmo> cjwatson: ^- ?
<ogra> there is an expert mode ?
<elmo> no there isn't, I'm actually being a retard
<elmo> don't mind me
<cjwatson> what ogra implied
<cjwatson> what are you actually trying to do? :)
<elmo> cjwatson: mac pro install - was following your instructions from our conversation a couple of weeks ago while half asleep
<elmo> ubiquity could do with learning about --help tho ;-)
<cjwatson> elmo: it has so learnt, in feisty
<cjwatson> but yeah, you want d-i
<elmo> cjwatson: ok - has it learnt how to  bail if screen res is < what it actually supports? ;-)
<cjwatson> elmo: no
<elmo> cjwatson: reasonable request/wishlist bug report?
<cjwatson> elmo: you could tack it on as an alternate suggestion in bug 38442
<Ubugtu> Malone bug 38442 in ubiquity "Doesn't support 640x480 resolution" [Medium,Confirmed]  http://launchpad.net/bugs/38442
<elmo> cjwatson: done, thanks
<cjwatson> Mithrandir: did you get time to try to nail down that console-setup problem at any point?
<doko> cjwatson, Keybuk: please could you promote libjaxp1.3-java (needed by current libxalan2-java and libxerces2-java builds)
<Mithrandir> cjwatson: no, sorry, I've entirely forgotten.
<Mithrandir> cjwatson: I can try to get it done tomorrow.
<pitti> Mithrandir: can I ask you again about postgresql-8.2, so that we'll get enough time for the transition?
<cjwatson> doko: done; please direct routine archive admin requests to Mithrandir from now on
<doko> cjwatson: ok, thanks
<BenC> cjwatson: I have a question...what's the purpose of building ia64 stuff if it isn't going to be published?
<BenC> none of my kernels ever show up on ports for ia64
<cjwatson> BenC: that's a sysadmin question ... ports.ubuntu.com mirroring is probably a bit broken
<cjwatson> BenC: http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-source-2.6.19/ has some stuff, but I think is outdated, so maybe it was only broken recently
<cjwatson> elmo: ?
<BenC> cjwatson: It's interesting that no one else has complained :)
<elmo> ah, excellent
<kylem> it's ia64... ;-)
<BenC> for a community port, it definitely is missing the community aspect
<elmo> fixed
<BenC> unless lamont == community :)
<elmo> it hadn't synced in like, uh, a month
<BenC> elmo: thanks
<elmo> I'll file a bug on soyuz for hiding the errors
<BenC> elmo: should I see stuff on ports.u.c now?
<BenC> I see an empty linux-source-2.6.20 directory
<elmo> BenC: give it 2-3 minutes
<BenC> ok
<elmo> BenC: it's syncing over Gb, but it still takes time to catch up over a month
<BenC> so what's the deal with hppa, while we're on the subject of ports?
<BenC> I thought feisty was supposed to be parisc's come-back release
<doko> away for the evening ...
<Mithrandir> pitti: can you remind me about what you was asking again?  It's been a few days.
<pitti> Mithrandir: to sync/NEW the package from Debian to Ubuntu main
<pitti> bug 75114
<Ubugtu> Malone bug 75114 in Ubuntu "Please sync postgresql-8.2 from Debian experimental" [Undecided,Confirmed]  http://launchpad.net/bugs/75114
<Mithrandir> pitti: oh, sure.
<pitti> Mithrandir: sorry for the urge, but the earlier we do it, the less work we'll have for the universe transition
<Mithrandir> pitti: sure, no problem, I'll just have to find my laptop
* pitti hugs Mithrandir 
<pitti> Mithrandir: happy new year!
<Mithrandir> pitti: same to you :-)
<Mithrandir> pitti: to main or universe?
<pitti> Mithrandir: straight to main would be best
<Mithrandir> pitti: ok, willdo
<pitti> Mithrandir: after we'll have it there, I'll care for obsoleting 8.1 in main
<Mithrandir> I figured that much. :-)
<Mithrandir> sync-source seems to fail to generate a .changes file since libecpg-dev is in main, but the new source isn't.
<Mithrandir> even with -f to force it.
<Mithrandir> Keybuk: ^^ do you know of a workaround for this?
<Keybuk> -F
<Keybuk> -f -F
<Mithrandir> ah, thanks.
<wasabi> heh. somehow I don't have pmount installed.
<pitti> wasabi: nothing in standard ubuntu desktop needs it any more
<wasabi> oh?
<wasabi> I was wondering hwy  my drives weren't automounting. ;0
<pitti> they should
<pitti> wasabi: https://wiki.ubuntu.com/DebuggingRemovableDevices, please
<Mithrandir> pitti: there you go, it'll require source new; I'll try to get to that tomorrow.
<pitti> Mithrandir: great, thanks!
<troy_s> Hey guys... what package has the gtk-engines development package in it?
<troy_s> in particular cairo-support.h
<Chipzz> troy_s: this is not a support channel; and try http://packages.ubuntu.com/
<troy_s> thanks chipzz.
<troy_s> but i tried that.  i figured i was missing something obvious.
<somerville32> pitti: ping
<pitti> somerville32: hello
<somerville32> Have you seen https://launchpad.net/distros/ubuntu/+source/vnc4/+bug/77383 ?
<Ubugtu> Malone bug 77383 in vnc4 "vnc4 authentication bypass" [Critical,Unconfirmed]  
<somerville32> towsonu2003 set it to critical
<pitti> somerville32: yes, I saw it, but it's universe and thus we cannot prioritize it; we are currently busy with main stuff like firefox
<somerville32> Should it be marked critical?
<pitti> somerville32: it already is
<somerville32> I know.
<pitti> BenC: do you think the apport kernel changes are something for the sprint? shall I put it onto the agenda?
<Mithrandir> pitti: we want libx86 in main for usplash; it's a librarification of source already in usplash, you're fine with just putting it directly in main, right?
<pitti> Mithrandir: of course
<BenC> pitti: Probably so, I need to get the driver-manager changes in, and that's going to take most of my time
<siretart> Keybuk: TB meeting now?
<Keybuk> siretart: yup
<siretart> excellent :)
<mjg59> What's on the agenda?
<Keybuk> mjg59: ffmpeg
<mjg59> Didn't we cover this last time?
* ogra thought that as well
<Keybuk> mjg59: #ubuntu-meeting
<siretart> ogra: the resolution was me to file a MIR. I made an request for xine-lib as interim solution, which I'd like to be discussed
<siretart> ogra: in paralell, I wrote an email about ffmpeg to the tb mailing list
<ogra> Riddell, ping
<Riddell> hi ogra 
<ogra> Riddell, could you merge the openbsd-inetd seedchange please, so netkit-inetd can get demoted ?
<ogra> i pinged during your holidays already but without expecting success indeed :)
<Riddell> I'm still on holiday :)
<ogra> oh, ok
<Riddell> but you're in luck, I have merge seeds coming right up on my todo list
<ogra> yay
<Riddell> ogra: done
<lmanul> Keybuk: ping?
<somerville32> Is there anyone here that is subscribed to feisty-changes AND can mass fwd them to an address for me (for legit reasons, of course)?
<gnomefreak> initramfs-tools is whos package?
<Keybuk> lmanul: hi
<Keybuk> somerville32: use the web archive?
<lifeless> morin Keybuk 
<lifeless> erm
<lifeless> 'moin'
<lmanul> Keybuk: Hi :)
<Keybuk> lifeless: hey, how goes it?
<lmanul> Keybuk: I'd love a piece of advice
<lifeless> mostly good, little virus going round sydney thats unpleasant though :(
<lmanul> Keybuk: I'm thinking about service management for that spec: https://wiki.ubuntu.com/ServicesAdminRedesign
<Keybuk> lifeless: hope it's gone by the time I get there <g>
<lmanul> Keybuk: There's a dirty-but-seems-efficient solution to know whether a service is running or not, but I thought it might be easier/cleaner with upstart?
<Keybuk> much cleaner with upstart
<lifeless> Keybuk: its the same one struck down dunedin LCA AIUI
<lmanul> Keybuk: Great, can you point me somewhere I can learn how to use it? Some man page? Web page?
<Keybuk> lmanul: man initctl
<Keybuk> e,g,
<Keybuk> quest scott% sudo initctl status tty1
<Keybuk> tty1 (start) running, process 4820 active
<Keybuk> lifeless: less than two weeks to go!! *excited*
<lifeless> whoot
<lmanul> Keybuk: great! Perfect, exactly what I need. You rock :)
<Keybuk> and I bought a brand new laptop, just for the flight <g>
<Keybuk> (battery sucks on syndicate)
<Keybuk> lmanul: a Python interface to that is in the works; not sure what the API would look like yet
<Keybuk> >>> import upstart
<Keybuk> >>> upstart.job_status("tty1")
<Keybuk> ("start", "running", "active", 4820)
<Keybuk> is the current thingy
<lmanul> Keybuk: well, I guess using initctl directly should be fine for now...
<lasindi> Hi all, not sure if this is the right channel, but here goes: I'm trying to create an Ubuntu package for a Python application I've recently written; I have no experience in packaging. I've been reading through this tutorial (http://women.debian.org/wiki/English/PackagingTutorial) I was directed to from the Ubuntu website, and when I ran dh_make, I chose CDBS as I have no binaries (because of Python). Is this the right choice (I get an error saying it
<lasindi> can't find a .orig.tar.gz file)?
<Fujitsu> lasindi, #ubuntu-motu is your best bet.
<Keybuk> lmanul: I guess it would just run "initctl list" first -- that gives you a status of every job upstart knows about
<neuralis> Keybuk: speaking of upstart, can you toss your original python poc code somewhere?
<lasindi> Fujitsu: okay, the reason I came here is because I don't intend to put my app in Universe (as it's fairly customized), but I'll try there. Thanks
<lmanul> Keybuk: hmm, does "knows about" imply the service is active?
<Keybuk> lmanul: no, upstart knows about disabled services
<Keybuk> neuralis: haven't had a clearance from on-high to release that yet
<Keybuk> lmanul: note that all this is talking about things in /etc/event.d -- which for feisty should be all of the default install
<Keybuk> it doesn't help you for things still in /etc/init.d
<neuralis> Keybuk: any timeline on that? i'm happy to mail mark to see if we can expedite things, if need be.
<lmanul> Keybuk: Ah, ok, then I'll still be needed start-stop-daemon I guess
<Keybuk> neuralis: mail mark
<Keybuk> lmanul: of course, start-stop-daemon won't work for anything in /etc/event.d
<Keybuk> (yay, transition)
<neuralis> Keybuk: okay.
<lmanul> Keybuk: Ok, I should have all the info I want with both upstart and start-stop-daemon. Good
<Keybuk> neuralis: I'm totally unconvinced you even want to do it in Python
<Keybuk> the signal handling just isn't sufficient
<lmanul> neuralis: hi :)
<Keybuk> (for an example of why init is special, compile the following code and run it with init= on the kernel command-line
<Keybuk>   for (;;) {
<Keybuk>       int *a = 0;
<Keybuk>       *a = 1;
<Keybuk>   }
<Keybuk> and marvel at the lack of segv'ing :p
<mjg59> Aiee 
<mjg59> trying to kill init
<Keybuk> mjg59: it won't kill it <g>
<neuralis> Keybuk: i'm not hell-bent on using python for this, but we do need a forking launcher for python programs (which will obviously be in python), and i wanted to see if it'd make sense to graft what trivial init functionality we need onto that launcher.
<neuralis> lmanul: hi there.
<neuralis> Keybuk: in all likelihood, we'll be starting just a few things at boot, with a stupidly simple depgraph
<tepsipakki> which ml should be the target for a "join my pkg team" kind of a (devel-centric) post? u-d, sounder?
<Keybuk> neuralis: starting isn't the problem ... dealing with the things the kernel needs init to do, that's the problem :)
<Keybuk> tepsipakki: sounder
<tepsipakki> Keybuk: ok, thanks
<jdub>     + debian/avahi-daemon.default:
<jdub>       - Don't start the daemon by default
<jdub> ^ horror!
<Keybuk> jdub: we're starting it by default in feisty
<Keybuk>   * debian/avahi-daemon.default: Start avahi by default. Our new
<Keybuk>     https://wiki.ubuntu.com/DefaultNetworkServices policy allows this now, and
<Keybuk>     ZeroConfNetworking specifies enabling by default.
<jdub> so this is just a merge thing
<jdub> ?
<Keybuk> "merge thing" ?
<Keybuk> reference?
<jdub> avahi (0.6.16-1ubuntu1) feisty; urgency=low
<jdub>   * Merge from debian unstable, remaining changes:
<jdub> ...
<jdub>     + debian/avahi-daemon.default:
<jdub>       - Don't start the daemon by default
<Keybuk> no idea
<neuralis> Keybuk: well, we're not exactly going to have a lot of dynamic hardware changes. are there other things that are particularly ugly?
<Keybuk> neuralis: yes, init has totally different signal handling than any other process
<Keybuk> it's the parent of all processes without a parent, and has to reap them
<Keybuk> etc.
<Keybuk> jdub: my only guess is that pitti was asleep when he did that merge
<neuralis> Keybuk: so, does this work in your prototype?
<neuralis> Keybuk: i'd be happier with "works but is somewhat uglyish" in python, than "works and isn't ugly" in C, in this instance.
<Keybuk> neuralis: no
<Keybuk> jdub: the debian/avahi-daemon.default in the merged source certainly starts it
<Keybuk> anyhoo, bed
<lifeless> wheee, spliteee
<siretart> Riddell: xine-lib 1.1.3-0ubuntu1 ACCEPTED :)
* somerville32 just parsed it in TUWNUDBCNMSP
<Riddell> siretart: does debian also have the split ffmpeg package?
<siretart> Riddell: not yet. I'm waiting for a) to release etch, or b) elmo create my debian account, at which point I'll upload it to experimental
<Riddell> siretart: so does your upload to ubuntu have the split ffmpeg binary package?  it doesn't say so in the merge changelog
#ubuntu-devel 2007-01-03
<lifeless> wtf
<lifeless> bash.preinst is binary ?!
<mjg59> lifeless: Uh. How else are you going to guarantee you can execute it?
<mjg59> (In the common /bin/sh is bash case)
<lifeless> mjg59: yeah, it was just surprise
<lifeless> hmm, now wtf does it do.
<bddebian> Heya
<wasabi_> Heh. A fun massive initramfs-tools update.
<wasabi_> This should be entertaining.
<jdong> wasabi_: oh come on, it's not like such an update has ever caused an issue before ;-)
<bddebian> heh
<Lathiat> EMBRACE THE CHANGES!
<wasabi_> feisty hasn't had many changes pushed in in the last few days...
<wasabi_> wonder if a buildd is stuck. ;)
<mjg59> soyuz has been broken
<mjg59> Also, holidays
<wasabi_> Yeah. There's going to be quite the flood when that's turned back on.
<superm1> cjwatson, ping
<siretart> elmo: many many thanks! :)
<siretart> Riddell: xine-lib 1.1.3 reached feisty and has built on all archs. will upload to debian/experimental tonight.
<stub> Launchpad will be going down in 15 minutes time for a code update. Estimated downtime is under 10 minutes.
<jdub> jono: ping
<jono> jdub: pong!
<jdub> jono: caps warning
<jdub> jono: REPLY TO LINDSAY'S EMAILS ABOUT LCA
<jdub> thanks
<jono> jdub: hmmm, thought I had, will check
<auxesis> jono, i just sent through another one, just reply to that :-)
<jono> auxesis: thanks, sorry, I thought I had replied
<jono> will get to it in a sec :)
<auxesis> jono, no worries :-)
<cjwatson> superm1_: yes?
<lifeless> cjwatson: is it fair to assume that all dpkg-diversion and undiversion in maintainer scripts will occur in preinst and postrm ?
<cjwatson> lifeless: does not seem to be empirically true
<lifeless> cjwatson: hmm
<cjwatson> dpkg-divert is sometimes used in the postinst to clean up old diversions
<lifeless> ah
<lifeless> I dont care about that :)
<cjwatson> dash uses dpkg-divert in interesting debconf-dependent ways in its postinst
<lifeless> I'm putting the finishing touches on the missing conflict finder
<cjwatson> (and its prerm)
<lifeless> so diversion use that doesn't impact the ability to unpack the package is really what I should have restricted my statement to
<cjwatson> or rather diversion use that does (positively) affect the ability to unpack the package
<lifeless> touche
<cjwatson> "wisdom teeth are impacted, people are affected by the effects of events" as the .signature of a correspondent at a previous job used to say
<cjwatson> a piece of grammar pedantry that was somewhat tarnished by its use of a run-on sentence ...
<cjwatson> I wonder if anyone plays with dpkg-divert in prerm deconfigure; that would hurt my brain
<cjwatson> lifeless: aside from that probably-irrelevant detail I think your analysis is correct
<lifeless> cjwatson: cool. I'm cooking up a hopefully 'good enough' parser to allow heuristic elimination of conflicts
<lifeless> http://people.ubuntu.com/~robertc/possible-conflicts.txt is the current output, running from cron
<Mithrandir> Adri2000: please do actually list the remaining changes when merging packages, don't just refer to another version.
<giskard> ciao
<gicmo> hmm where is seb128 and dholbach
<mneptok> gicmo: seb is still on leave
<gicmo> ahh, and I still have this strange cant-upgrade problem ...
<mneptok> what problem is that?
<lifeless> gnight all. 
<gicmo> like dist-upgrade doesnt work since weeks (I was on vacation for two weeks though) .. something with the package resolve
<gicmo> feisty that is
<mneptok> gicmo: did you properly edit /etc/apt/sources.lst?
<gicmo> I didnt  touch that at all for a long time, and apt-get update works 
<mvo> gicmo: please install the latest apt manually
<mvo> gicmo: that will fix the problem
* gicmo hugs mvo
<mvo> gicmo: apt-get install apt that is
<gicmo> yeah, I know how to do that ;-)
<gicmo> I am not *that* stupid ;-)
<gicmo> ahh solved it, nice!
<mneptok> mvo + mneptok > seb + dholbach
<mneptok> >:)
<gicmo> hahah
<mvo> gicmo: I know that you are not :-D 
* mneptok doesn't ;)
<mvo> just wanted to make clear what manual means (not wget apt; dpkg -i apt) 
* mneptok beeps gicmo's nose
<gicmo> *autsch*
<gicmo> ;-)
* mvo hugs mneptok
<gicmo> mvo: how were your holidays? ;-)
* mneptok purrs comtentedly
<mneptok> s/m/n/
<mvo> gicmo: great! very relaxing. I'm back with a lot of energy :)
* mvo should take vacation more often
<mneptok> uhhhh ... no
* gicmo nods
<mvo> gicmo: what about you? did you enjoy christmas?
<mneptok> no vacation for you!
<mvo> mneptok: I take you with me on vac, ok?
<mneptok> ooo!
<mneptok> OOOO!
<gicmo> pretty good, actually!
* mneptok starts packing
<mvo> HAHA
* mvo thinks that mneptok was hired for the morale of the team
<mneptok> *muah*
* Keybuk wonders why metacity doesn't start when he logs in
<mneptok> Keybuk: maybe you've been a vewwy, vewwy baaaaad puppy, and m-city knows ...
<cjwatson> Riddell: I'm attempting to merge ubiquity/experimental-qt4-port now
<cjwatson> it's, uh, a slightly complicated megre
<cjwatson> merge
<StevenK> mvo: Do you have a few seconds to look at apt?
<mvo> StevenK: what bit/bug in particular?
<ogra_> could someone let edsadmin out of the NEW queue ?
<Riddell> cjwatson: has much changed since I started it?  there shouldn't be any conflicts
<ogra_> Keybuk, cjwatson ^^^ ?
<cjwatson> Riddell: yes, enormous change :-)
<cjwatson> Riddell: it's ok, I've resolved it all
<cjwatson> ogra_: -> Mithrandir
<ogra_> ah, k
<Mithrandir> ogra_: I'll take a look at it.
<ogra_> thanks
<cjwatson> Riddell: I merged the new-partitioner branch, and over the last day or two I've been doing bits of UI rearrangement in preparation for other things
<Riddell> cjwatson: ah, that will affect it right enough
<StevenK> mvo: I'm looking at the libept build failure.
<Mithrandir> ogra: or, I could if stuff wasn't broken; I can't access the queue right now.  I'll poke the relevant people.
<cjwatson> Riddell: I'm reverting the prints you added to gtkui.py in your branch, and I think I'll go through and clean up spurious str("...") as well
<ogra> Mithrandir, thanks, there is no hurry as long as someone cares for it ...
<Mithrandir> ogra: it's in a queue, I'll get to it eventually. :-P  Source NEW just takes quite a bit of time.
<ogra> yep
<ogra> understood :)
<ogra> whom do i poke for promotion/demotion now ? Mithrandir is that you as well now ?
<cjwatson> Mithrandir can do it, or I'm happy to if it's properly anastacia'd in advance
<ogra> netkit-inetd -> openbsd-inetd shows up on anastacia now
<cjwatson> I'll have a look
<Keybuk> ogra: the archive admin team hasn't changed, though for obvious reasons, cjwatson and I have a little less time for it than Mithrandir
<ogra> thanks
<Keybuk> so if you have urgent things, it's usually easier to ping him
<ogra> Keybuk, i never asked Mithrandir for pro/demotions yet :)
<cjwatson> netkit-inetd/openbsd-inetd done
<Mithrandir> ogra: pinging me is generally fine
<ogra> oki, noted :)
<ogra> cjwatson, thanks, that will make my CDs more happy again :)
<Riddell> talking about promotions, will gwenview-i18n need a main inclusion report?  it's just the .po files from gwenview which is already in main
<ogra> do they build from the same source ?
<ogra> MIRs are for sources usually ...
<mvo> StevenK: this is still http://librarian.launchpad.net/5346111/buildlog_ubuntu-feisty-i386.libept_0.4.7_FAILEDTOBUILD.txt.gz?
<StevenK> Yup.
<Riddell> ogra: not any more, it's recently been separated
<ogra> ah
<StevenK> mvo: If I edit apt-pkg/packagemanager.h, at around line 107 and comment out the Cache.writeStateFile(NULL); call, the build is sucessful.
<Mithrandir> Riddell: if it used to be the same source, promoting without a MIR is fine.
<Mithrandir> ogra: the copyright file for edsadmin is talking about "countdown timer" which seems to be something entirely else?
<ogra> hrm
<ogra> i missed that 
<ogra> crap ...
<Mithrandir> ok, I'll reject it, please fix and reupload.
<mvo> StevenK: I would rather like to have that feature enabled, writeStateFile() writes out e.g. auto-install information. is pkgDepCache a class that does not come from libapt? I suspect something fishy going on, let me check
<ogra> Mithrandir, will do ...
<Mithrandir> ogra: and it seems to be forcing the use of python 2.3?
<Mithrandir> without depending on it.
<StevenK> mvo: Sure, I was just seeing if that was the cause.
<StevenK> mvo: Actually, I think I know why.
<StevenK> bool pkgDepCache::writeStateFile(OpProgress *prog, bool InstalledOnly)
<StevenK> And yet, it's being called with (NULL)...
<ogra> Mithrandir, urgh ... i see it ... i'll patch it and mail upstream ...
<Mithrandir> ogra: ok, I'll just reject it for now and you can retry later.
<ogra> yep
<mvo> StevenK: ok, so the problem is that pkgDepCache is copied from libapt and heavily modified in libept.  the only course of action is probably to  copy the writeStateFile() into the libept implementation (yeah for duplication of code)
<ogra> funnily the automake setup he uses checks for python2.4 ... i didnt even bother to look at the shebang lines ....
<StevenK> Ew.
<StevenK> mvo: I could make it a no-op in libept, though, right?
<mvo> StevenK: that would lose the auto-install information. but given that it is a reimplementation anyway auto-inst is probably not supported (I haven't checked that)
<StevenK> mvo: But only in libept?
<mvo> StevenK: yes. what is using this version of libept?
<StevenK> packagesearch of the top of my head
<mvo> ok, that is harmless as it does not installs anything
<StevenK> mvo: Just checking for anything else in a sid chroot.
<mvo> anything that uses it for installing packages would loose the auto-install information. this is not fatal, just a regression from standard apt using tools
<gicmo> ok, of course now the nvidia drivers broke and I dont have X
<gicmo> *sigh*
<StevenK> mvo: debtags, debtags-edit and packagesearch
<StevenK> mvo: None of which install stuff.
<mvo> StevenK: ok, in this case a no-op should be fine
<mvo> StevenK: thanks for working on this!
<StevenK> mvo: No problem!
<cjwatson> Riddell: merged
<Riddell> cjwatson: all very exciting.  does it need changes to keep up with the new-partitioner branch and your other UI changes?
<StevenK> Hum. If debtags is in main, then libept needs to be promoted.
<StevenK> (It's now a build-dep of debtags and debtags-edit)
<cjwatson> Riddell: new-partitioner isn't ready for porting to other UIs yet; still too much in flux
<cjwatson> Riddell: I've dealt with the other UI changes
<cjwatson> totally untested, mind :)
<cjwatson> Riddell: you can probably start looking at new-partitioner now, but I wouldn't advise putting in serious resources yet
<StevenK> cjwatson: I'd be curious about a screenshot or two for the new partitioner, but only if you have some handy.
<cjwatson> StevenK: I don't, unfortunately; I posted directions for trying it out on ubuntu-devel@ just before Christmas
<cjwatson> StevenK: it's lacking the disk bar still which would really be the screenshot-worthy bit; it's just a crude list of partitions at the moment
<Hobbsee> hooray, feisty still boots!
<StevenK> cjwatson: The disk bar, a'la gparted?
<cjwatson> er, sort of
<cjwatson> StevenK: http://wiki.ubuntu.com/Ubiquity/AdvancedPartitionerRewrite
<cjwatson> that's probably more useful
<cjwatson> Riddell: Depends: ${misc:Depends}, ${python:Depends}, ubiquity, python-kde3, qtparted
<cjwatson> Riddell: is that Depends line still right for ubiquity-frontend-kde? looks like it could do with an update
<Riddell> cjwatson: it'll need python-qt4 now not -kde3
<cjwatson> Riddell: fixed
<cjwatson> thanks
<cjwatson> Riddell: sorry, one more thing, is there a way to produce a hyperlink widget in Qt4 in some way other than a QLabel whose text is the URL? I don't actually want to display the URL - this is for ubiquity-release-notes
<StevenK> Just a reality check here, do I need a MIR to get libept promoted given debtags Build-Depends on it? And if not, should I file a bug and subscribe ubuntu-archive asking for it?
<Mithrandir> StevenK: yes, it needs a MIR if it's not just split out from something already in main.
<cjwatson> StevenK: yes, you do, unless it's code that was moved from somewhere else; no, you shouldn't file a bug
<cjwatson> we have http://people.ubuntu.com/~cjwatson/anastacia.txt to track promotions and demotions
<gicmo> ok, got the X back but lost SMP support for now ;-)
<gicmo> *sigh*
<gicmo> binary drivers shit
<Riddell> cjwatson: QLabel accepts HTML, so you can do <a href="foo">text</a>
<Riddell> although it'll need the same stuff done to it as the label in the crash dialogue to make it do anything
<cjwatson> aha, ok
<cjwatson> yeah, that's fine
<cjwatson> I missed the <a href> already in crashdialog.ui - whoops
<StevenK> Right. libept looks to be a rename of libapt-front, which is in main.
<StevenK> But if it gets promoted, I can't fix it, since I can't upload to main. :-)
<Riddell> StevenK: I'm happy to upload
<StevenK> Riddell: Let's see if my fix or the promotion happen first. :-)
<Riddell> StevenK: seems like we still need libapt-front though, adept hasn't been ported to the new (libept) version
<StevenK> libapt-front still exists.
<Riddell> StevenK: have you asked for a promotion?
<StevenK> Probably not, I'm not sure if dicussing here counts. :-)
<StevenK> Based on what Mithrandir and cjwatson said earlier, it doesn't need an MIR.
<Riddell> no, it won't, being just a rename
<Riddell> Mithrandir: able to do some propotions?
<Mithrandir> Riddell: do they show up in the anastacia output?
<Riddell> not libept, StevenK does debtags not depend on that yet?
<Riddell> Mithrandir: but gwenview-i18n source and binary does
<Riddell> Mithrandir: and kplato binary from koffice needs it too
<StevenK> Riddell: debtags does Build-Depend on it, and is in depwait.
<Mithrandir> Riddell: just let me finish this source review I'm doing and I'll take a look at those.
<Riddell> StevenK: yes, so I'm not sure why it doesn't show up in anastacia
<Mithrandir> Riddell: and gwenview-i18n was just split from gwenview?
<Riddell> Mithrandir: yes
<Mithrandir> Riddell: ok, promoted.
<Riddell> thanks Mithrandir 
<Mithrandir> Riddell: you want kplato promoted too?
<Riddell> Mithrandir: yes please
<Mithrandir> done
<Riddell> yay
<Riddell> Mithrandir: any idea why libept doesn't show up in anastacia since debtags is dep-wait on it?
<Mithrandir> Riddell: not yet, I'll investigate.
<cjwatson> I'd done kplato not that long ago, but doing it twice won't hurt ;)
<StevenK> Hah
<Mithrandir> sneaky Colin. ;-)
<imbrandon_> Mithrandir , thanks for the note, i ment to ask you to reject those anyhow as the mesa isnt needed ( among other things ) with the new version, I just hadent got arround to uploading the packages yet
<Mithrandir> imbrandon_: ok, good to hear.
<imbrandon_> heya Riddell
<Mithrandir> imbrandon_: the licence problems in -plugins seem a bit more serious, though.
<imbrandon_> ahh yea , that is one thats still ummmm questionable at best
<imbrandon_> i need to grab them again about it
<Mithrandir> Riddell: libept ftbfs, that'd explain it
<StevenK> Which I almost have a patch for.
<Riddell> ah, so StevenK needs to upload his fix first
<Mithrandir> yeah, there's no libept-dev yet, so no package to promote.
<Riddell> Mithrandir: one other anastacia question, kdeaddons won't install because knewsticker-scripts isn't in main, but it's not in anastacia either
<StevenK>  -lapt-pkg -lwibble -ltagcoll2 -lz -lwibble -lz
<StevenK> Yay for specifying libraries twice!
<StevenK> Just in case ld wasn't listening.
<ogra> Riddell, its in main here
<Riddell> oh, it has another depends that isn't
<Riddell> ok, ignore me Mithrandir 
<Mithrandir> sure. ;-)
<ogra> hmm, pulse doesnt like the ugly esd patch of the flashplugin package :(
<Mithrandir> it has good taste?
<ogra> well
<ogra> indeed
<ogra> but that brings me in a dilemma ... do i break flash or do i break pulse now to fix the issue ?
* ogra goes for coffee to think about it ...
<Riddell> flash uses esd?
<ogra> no
<Riddell> phew
<ogra> libflash only plays sound if /tmp/.esd/socket exists
<Hobbsee> ogra: you break flash, then blame it on someone else.
<ogra> which we touch from an initscript, since our esd is patched to use rather /tmp/.esd-$UID/socket
<ogra> apart from that socket file isnt used at all
<ogra> but pulse doesnt start the esd compat mode if the file exists
<ogra> Hobbsee, cool idea, i could just blame adobe and be done with it :P
<StevenK> libept uploaded.
<Hobbsee> ogra: *grin*
<StevenK> Hrm. /distros doesn't appear the in Launchpad URL anymore.
<highvoltage> do most ubuntu developers use aptitude, or apt-get when installing from a terminal?
<StevenK> Can someone give-back libapache2-mod-fcgid on all arches, it FTBFS, but should build fine now.
<Hobbsee> highvoltage: i use apt-get - clearer output
<Hobbsee> Mithrandir: @ StevenK's request
<thom> apt-get - i've been burnt by aptitude's problem resolution once too many times
<StevenK> highvoltage: Either.
<mneptok> highvoltage: make
<mneptok> ;)
<Mithrandir> Hobbsee: thanks dudette. :-)
<highvoltage> mneptok: heh!
<Mithrandir> StevenK: given-back
<Hobbsee> Mithrandir: :)
<StevenK> Mithrandir: Thanks!
* mneptok larts Hobbsee with a larger Hobbsee 
* Hobbsee stomps on mneptok's fingers
<StevenK> And it's already building on three arches. Neat.
<mneptok> feel the love.
<Mithrandir> StevenK: probably time to give back all our failed builds, then. :-P
<StevenK> Heh
<Hobbsee> mneptok: indeed.
* mneptok polishes his halo
<mneptok> morgen boggle :)
* Hobbsee snatches the halo and runs away with it
<boggle> moin mneptok 
* mneptok polishes his goat horns and running shoes
<Hobbsee> hehe
<Hobbsee> Mithrandir: when's the next archive admin day, and will we see a mass of syncs, presumably?
* Hobbsee is trying to get this buglist back down again
<Mithrandir> Hobbsee: I've done more or less nothing but archive stuff yesterday and today; there's a fairly big backlog of stuff from christmas.
<Mithrandir> Hobbsee: some of the source NEW I've been doing has been around for a month, so it's about time.  I'll see if I manage to get to syncs today as well, though I doubt it.
<Hobbsee> Mithrandir: OK, that's fine.  had expected that :)
<Hobbsee> Mithrandir: cool :)
<StevenK> The syncs ought to sort out MoM neatly, too.
<mneptok> StevenK: you keep your hot VCS porn away from my mom, ok?
<cjwatson> Mithrandir: bug 77438 makes sense to me. Any objections to me applying that?
<Mithrandir> cjwatson: makes sense; please apply.
<cjwatson> Mithrandir: donoe
<cjwatson> done
<Mithrandir> danke
<yellowbee> www.myspace.com/doggerdan <---- New myspace XSS exploit PoC (proff of concept)
<Keybuk> that's a new one on me
<Keybuk> gfxboot on edgy i386 release got corrupted by grub messages
<yellowbee> :O
<Mithrandir> Keybuk: that'd be.. special, given that gfxboot is on CDs and those don't use grub.
<Mithrandir> yellowbee: that's hardly relevant to Ubuntu development, isn't it?
<Keybuk> well, the "Loading" and dots type messages
<Keybuk> I thought it was very odd
<Keybuk> they appeared in greenish text at the top
<Amaranth> Mithrandir: the website itself probably totally fscks up a system when you look at it with IE
<ogra> Keybuk, isnt that the kernel itself ?
<ogra> (instead of grub)
<Amaranth> that reminds me, is it possible to make the kernel shut up about those pci errors at bootup?
<Keybuk> ogra: why would the kernel be "Loading casper/vmlinuz" ?
<Mithrandir> then it's not grub, it's isolinux
<ogra> Keybuk, well i thought you meant the uncompressing of the kernel image ...
<ogra> i thought that part comes from the kernel directly
<zul> ogra: nope
<cjwatson> Keybuk: has been happening for ages
<cjwatson> I've never worked out the x86 assembly necessary to avoid that
<cjwatson> in fact, as far as I know that's been happening since we introduced gfxboot
<Mithrandir> it's only on some gfx cards, iirc
<Keybuk> weird, had a usplash timeout too
<ogra> pitti, did you see anything significant in pulse that prevents it from entering main (apart from the fact that it breaks with flash)
<ogra> else i'll write the MIR now
<pitti> ogra: no, it works fine, apart from some issues; let's talk later (phone call with Scott)
<ogra> yep
<ogra> i'll prepare the MIR
<ogra> argh, the syntax of /etc/exports has changed ? damned ...
<ogra> BenC, how is the status of the bcm43xx driver ? does it make sense to test the latest 2.6.20 for me ? seems it doesnt work on my ppc
<ogra> (so i'm a bit scared to test it on my main work machine)
<lritter> hi there
<lritter> i'm trying to build a package, and i added libjack0.100.0-dev as dependency, but pbuilder can't find it... what's my mistake?
<Hobbsee> lritter: please dont cross-post.  see -motu
<Keybuk> cjwatson: I have a weird thing; the debconf database doesn't match my xorg.conf
<ogra> btw, werent we supposed to see a lot of X uploads recently ?
<Keybuk> (or the running X)
<cjwatson> Keybuk: in what way?
<Keybuk> cjwatson: xorg.conf says i810, 1280x800 .. but debconf says and X appears to be running as vesa at 1024x768
<cjwatson> um, buggeredifIknow, maybe some desktop tool edited xorg.conf directly?
<cjwatson> dunno why X would be in sync with debconf and not xorg.conf, since xorg.conf is canonical, unless you haven't restarted X recently
<bddebian> Morning
<sroecker> hi
<sroecker> did feisty change something with the initramfs?
<_ion> Yes.
<sroecker> my newer kernels crash with: libgcc.so not found, pthread_cancel not working
<sroecker> or something like that
<Keybuk> cjwatson: fresh install
<cjwatson> Keybuk: iz xserver-xorg.postinst's fault probably
<cjwatson> Keybuk: somebody would have to trace through that and make sure to keep a gingerbread trail
<Keybuk> cjwatson: ah, apparently I need to install 915resolution
<geser> or xserver-xorg-video-i810-modesetting
<cjwatson> Keybuk: fun
<tepsipakki> are sounder subscriptions moderated?
<Hobbsee> Keybuk: welcome to widescreen laptops - is that the first time you've needed that?
<Keybuk> Hobbsee: yes, my previous laptop had an ATI Radeon and no widescreen display
<Hobbsee> Keybuk: ahh
<pitti> ogra: I'll try the new powerpc kernel on my laptop now (with bcm43xx)
<sladen> Keybuk: or use the mode-setting branch of video-driver-intel
<sladen> Keybuk: which is in universe IIRC
<geser> yes it is in universe, package xserver-xorg-video-i810-modesetting in feisty
<jdub> ha ha fisty in 80MB RAM
<zul> eh?
<Nafallo> fisty? :-)
<Nafallo> sounds kinky ;-)
<sladen> jdub: oh, just the kernel, right :)
<_ion> jdub: I don't see why that would be a problem, unless you happen to be running stuff that requires more memory.
<pitti> mvo_: ping
<Keybuk> hmm, language-support-en problem?
<cjwatson> Keybuk: openoffice.org-l10n build failure, last I traced it
<Keybuk> ah, yes
<Keybuk> and no LRM?
<Mithrandir> lrm is in NEW
<BenC> ogra: It should be working now
<doko> cjwatson: openoffice.org-l10n sucessfully built
<Keybuk> hmm, why does the hostname have a bogus IP in /etc/hosts?
* Keybuk finds the Debian bug
<cjwatson> doko: yay
<cjwatson> Keybuk: what IP?
<Keybuk> cjwatson: 127.0.1.1
<cjwatson> that's not bogus; anything in 127.* identifies the local host
<Robot101> that's not bogus, it's also localhost. I always assumed it was for round-trippable forward/reverse DNS lookups of both localhost and hostname.
<Robot101> hm :)
<cjwatson> Robot101: I think it's something along those lines, although I forget the details of the long drawn-out thread that led to that conclusion
<Keybuk> cjwatson: only on  Linux, no?
<cjwatson> Keybuk: (a) I can't say I care (b) cite?
<Keybuk> from reading the bug and thread, I can see the reasoning for it
<cjwatson> RFC1060 says that anything in network 127 is "Internal host loopback address"
<_ion> At least one thing comes to mind: let's say a box in DMZ has a local IPv4 address which is different from its public address. boxname.mydomain points to the public address. When a program at the box tries to connect to boxname.mydomain, the packets go out to the router, which may or may not route them back to the box, and if it does, the box may block them as spoofed.
<Keybuk> I thought the fact that the lo device replied to all IPs in its configured range was a Linux-specific thing
<Keybuk> and more to do with its implementation in the kernel
<Keybuk> I'm sure I've seen an OS that needed multiple los configured if you wanted multiple IPs in that range
<_ion> PING 127.42.42.42 (127.42.42.42): 56 data bytes
<_ion> ping: sendto: Network is unreachable
<_ion> says an OpenBSD box
<Keybuk> (and arguably, lo is configured wrong ... it should be 127.0.0.0/255.0.0.0 not 127.0.0.1 <g>)
<iwj> We need dpkg triggers so badly.  This slightly stale feisty install is taking an age to update.
<Robot101> lo        Link encap:Local Loopback   inet addr:127.0.0.1  Mask:255.0.0.0
<Robot101> it has the mask right :)
<Keybuk> Robot101: the mask is right, but the addr isn't
<Keybuk> technically
<Keybuk> but I'm digressing into meaningless pedantry
<_ion> iwj: Perhaps someone should just say "this is how it should work, screw the other opinions" and implement it. ;-)
<pitti> ogra: btw, 2.6.20-3 still crashes with bcm43xx
<iwj> _ion: I need to actually write down the design first though.
<ogra> pitti, yeah i noticed after the upgrade 
<ogra> (thats why i was offline the last hour :P )
<Keybuk> Robot101: as I understand the implementation, Local devices merely route all traffic into a special "device" that happens to reply to any traffic routed to it
<Keybuk> which means that they actually reply to any traffic within their configured netmask
<Keybuk> based on that, there's no real IP for that device, so it should only have the network configured -- which is 127.0.0.0 not 127.0.0.1
<Keybuk> but that'd shock people 
<Keybuk> :p
<_ion> A virtual (in some sense) package for each trigger script that goes unconfigured if the script fails seems like a good way, but someone probably points out why it won't work.
<iwj> Keybuk: Yes, but packets destined for 127.0.1.1 ought to be rejected at the next layer up.
<ogra> bah, FF doesnt recover the contents of half filled forms after a crash ...
<Keybuk> iwj: on linux, there isn't a next layer
<iwj> Keybuk: Yes, there is, it's routing.
<_ion> orga: IIRC it should do that.
<Robot101> Keybuk: that sounds bogus, because 127.0.0.0 is still the network address isn't it?
<Keybuk> iwj: ?
<ogra> _ion, well .. should ... 
<Robot101> $ ping 127.0.0.0
<Robot101> Do you want to ping broadcast? Then -b
<Keybuk> Robot101: you're missing the point
<iwj> Keybuk: Or are you saying that if I send to box-a's ethernet MAC address a packet with a destination IP address on the same segment but not box-a's, then box-a's TCP stack will answer it ?
<Keybuk> the implementation of lo in Linux means that it doesn't need an IP address
<Keybuk> iwj: no, I'm only talking about link encap: Local -- not Ether
<Keybuk> a device with Link encap: Local will treat any package routed to it as something to reply to
<iwj> You do seem to be right.
<iwj> This is, however, clearly bogus.
<Keybuk> indeed
<Keybuk> and our default install relies on this bogus behaviour <g>
<iwj> Checking the IP address for local/remote is a routing function and should be done by the IP layer and not by some crazy code in the network device!
<cjwatson> http://bugs.debian.org/316099 is the relevant reference
<iwj> I'm going to go and do something more useful now :-).
<cjwatson> (executive summary: it was to stop 'hostname --fqdn' from returning 'localhost.localdomain' if the system doesn't have a permanent IP address known to the installer)
<cjwatson> IIRC localhost.localdomain is bogus too but that's a different argument ...
<cjwatson> ah, and localhost.localdomain is gone now, good; but the canonical hostname would just have been localhost instead without the 127.0.1.1 change
<Keybuk> "gone now" ?
<cjwatson> http://lists.debian.org/debian-devel/2005/10/msg00559.html
<_ion> ogra: Workedforme
<_ion> ogra: That's not to say that it couldn't be buggy, of course.
<ogra> _ion, hmm, might be a moin problem
<cjwatson> and netcfg 1.17 changelog
<Keybuk> so it is
<Keybuk> \o/
<iwj> Why not set uname to something not in /etc/hosts and let hostname -f just print the nodename ?
<Keybuk> the argument appears to be that some apps may look up the hostname with DNS to find its IP
<Keybuk> and thus if its not in /etc/hosts, it won't work
<iwj> To find what IP address ?
<iwj> I mean, what are they going to do next ?  Something bogus, obviously.
<cjwatson> listen on it is my only guess
<cjwatson> the whole thread made my head hurt and I confess I zoned out about halfway through
<cjwatson> maybe it's to make sure stuff like tcp-wrappers' reverse DNS check doesn't get upset?
<iwj> I'm playing Chinese Whispers with ignoramuses at the far end, I think.  Time to give up.
<Keybuk> hmm
<Keybuk> I can't seem to install xserver-xorg-i810-modesetting
<thom> xserver-xorg-video-i810-modesetting
<Keybuk> thom: conflicts with the i810 driver
<Keybuk> which is a dependency of ubuntu-desktop
<thom> well, yes
* Keybuk adds Provides: xserver-xorg-video-i810
<geser> Keybuk: where exactly does ubuntu-desktop depend on xserver-xorg-video-i810?
<Keybuk> geser: depends on xorg depends on xserver-xorg depends on xserver-xorg-video-all depends on xserver-xorg-video-i810
<geser> xserver-xorg depends alternatively on xserver-xorg-video which is provided by xserver-xorg-video-i810-modesetting
<geser> so this dependency should be satisfied by xserver-xorg-video-i810-modesetting (once xserver-xorg-video-i810 and xserver-xorg-video-all are removed)
<Keybuk> weird, why didn't aptitude let me do that then?
<Keybuk> ah
<Keybuk> I have a later version than what's in feisty
<Keybuk> there's a 6.2 from edgy updates installed
<mbiebl> Is there an easy way to reopen a bug in launchpad?
<_ion> I haven't reopened one, but i'd expect it to happen the same way a bug's status is changed to any other value.
<mbiebl> I'm the original bug reporter, but I can't change the status (which is "Fix Released")
<mbiebl> At least I don't know how.
<cjwatson> only people in ubuntu-qa can do that; otherwise, post a comment explaining the situation and asking the person who made the change to revert it
<mbiebl> cjwatson: that would be you ;-)
<mbiebl> https://launchpad.net/ubuntu/+source/console-setup/+bug/60483
<cjwatson> mbiebl: there's already a different bug about that, so that one can happily stay closed, I think
<Keybuk> cjwatson: hmm, all of a sudden I'm getting very strange messages from ssh
<Keybuk> buffer_get_ret: trying to get more bytes 257 than in buffer 39
<mbiebl> cjwatson: ok
<cjwatson> mbiebl: bug 73955
<cjwatson> Seveas: 17:46 [Freenode]  -Ubugtu(n=bugbot@ubuntu/bot/ubugtu)- Error: Error getting Malone bug #73955: Bug does not exist
<cjwatson> it lies
<cjwatson> Keybuk: I have no idea - try with -vvv and/or search upstream bug?
<cjwatson> s
<Keybuk> cjwatson: ah, corrupted .pub file
<cjwatson> Keybuk: fun error. I think there may be a Debian bug about that ...
<cjwatson> Keybuk: I thought I'd seen this before, but I can't find a bug, so feel free to file one
<Keybuk> the only real bug to my mind is that it doesn't tell you what file caused the error
<Keybuk> "error parsing .ssh/id_dsa.pub" needed
<cjwatson> right, it's using the generic buffer-handling code which basically fatal()s out of library code, iirc
<Keybuk> "Why abort() is not an exception handler"
<Seveas> cjwatson, will check asap
<ogra> lifeless, around ? 
<Zomb> hi. Who can change the cdrkit packages? mvo accidentaly a "gg" into the md5sum list in wodim.preinst file. Just search for gg.
<somerville32> Keybuk, ping
<Zomb> s,a ,added ,
<Keybuk> somerville32: yo
<somerville32> keybuk: Could I get you to sponsor my upload to main? I see you're a member of ubuntu-main-sponsors
<somerville32> keybuk: It is an SRU approved by cjwatson
<somerville32> please :)
<Keybuk> somerville32: ask me tomorrow
<somerville32> keybuk: Alrighty. If I can't find anyone by tomorrow, I'll ping you :] 
<cjwatson> Zomb: I'll fix it now; thanks for the report
<mdke_> cjwatson: hiya. Happy new year. What is the general time for feedback on SRU bug reports?
<Seveas> cjwatson, ubugtu is fied again. Launchpad devs broke him
<cjwatson> mdke_: "depends"
<mdke_> cjwatson: :)
<cjwatson> mdke_: holidays have obviously left me well behind
<cjwatson> I try to get to them in days; earlier if explicitly asked
<cjwatson> Seveas: thanks!
<mdke_> cjwatson: it's not that urgent, so I won't explicitly ask you. Just curious
<cjwatson> Zomb: fixed
<LaserJock> do edgy-proposed uploads show up in the edgy queue on LP?
<cjwatson> LaserJock: yes, from the point of view of the web interface; c.f. https://launchpad.net/ubuntu/edgy/+queue which shows a backports upload
<LaserJock> cjwatson: do uploads have to be approved by ubuntu-archive first?
<cjwatson> LaserJock: "first" => before what?
<LaserJock> cjwatson: I'm pretty sure I uploaded rpy to edgy-proposed last month
<LaserJock> but I couldn't find it on the queue
<cjwatson> LaserJock: it's the unapproved queue, not the new queue
<LaserJock> cjwatson: can us mortals see that. I don't think we can if I remember right
<cjwatson> LaserJock: https://launchpad.net/ubuntu/edgy/+queue?queue_state=1&queue_text= (you may or may not have access to that)
<cjwatson> LaserJock: it's there
<LaserJock> cjwatson: forbidden for me, and thanks
<LaserJock> I just wanted to make sure I wasn't loosing my mind
<cjwatson> LaserJock: it appears to be in ubuntu-archive's queue as normal; Mithrandir should process it at some point if the SRU is well-formed
<LaserJock> excellent, thanks
<ttoine> cjwatson: ??
<ttoine> cjwatson: ping ?
<cjwatson> ttoine: yes?
<ttoine> cjwatson: ah, cool
<ttoine> cjwatson: i am one of the dev of ubuntu studio
<ttoine> and to enable real time for applications, we need of course a real time kernel with pre-empt. BenC is working on that
<ttoine> but looking for how to set up and tweak....
<ttoine> we need to have a specific version of PAM
<ttoine> and as you are one of the current maintener/uploader i would like to know if the version 0.8 of PAM is scheduled for ubuntu feisty or not ?
<cjwatson> ttoine: you mean beyond the nice and rtprio extensions that already went into pam_limits?
<ttoine> cjwatson: https://wiki.ubuntu.com/MultimediaProductionKernel#preview
<ttoine> cjwatson: yes, that's it
<cjwatson> ttoine: those are in our pam all the way back to dapper
<tsmithe> yay!
<cjwatson> ttoine: as for new upstream versions in general, see my comment in https://launchpad.net/ubuntu/+source/pam/+bug/43169
<Ubugtu> Malone bug 43169 in pam "RFE: Update pam to 0.99 or greater" [Unknown,Unconfirmed]  
<ttoine> cjwatson: so wa can tweak even if it is not the 0.80 version ?
<cjwatson> ttoine: yes, that change was backported
<ttoine> so it is in edgy...
<cjwatson> yes
<ttoine> ok
<ttoine> thanks
<ttoine> and of course will be in feisty
<cubicool> heno: ping
<ttoine> so, as i just know at the moment wich file should be edited for the 0.8 version, can you tell me what it the file to edit with the current version ?
<heno> cubicool: Hi
<cubicool> heno: Mind if I send you a /msg? :)
<heno> cubicool: go ahead
<cjwatson> ttoine: the instructions you already have should work fine
<cjwatson> ttoine: why don't you try them first? :-)
<ttoine> cjwatson : i can't try everything on my laptop, i use it for work
<ttoine> so i if crashed.... it is not good for me
<ttoine> cjwatson: i think that do you know where i can find what packages are in the backports ?
<cjwatson> ttoine: no, that sort of thing is pretty unlikely to cause a crash; what you do is try the change, keep the file open in your editor running as root, log in e.g. from the console on Ctrl-Alt-F1 and run 'ulimit -a' to see what it says
<cjwatson> then if it seems to be going wrong you can always undo the change in the running editor and save again
<cjwatson> ttoine: it's in regular dapper/edgy; you already have it installed
<cjwatson> assuming you have dapper/edgy installed at all
<cjwatson> by backport I mean that the individual change was backported from upstream before dapper was released, not that it was uploaded to dapper-backports or edgy-backports
<ttoine> ok, i am running edgy or dapper, it depends
<ttoine> oh, ok, sorry
<ttoine> so it is in
<ttoine> so the only thing i miss on edgy is pre-empt
<ttoine> i will need to test with dapper or dist-upgrade to feisty, to test
<ttoine> edgy's kernell is not good for real time
<_MMA_> ttoine: If I remember right BenC said you could use the -lowlatency kernels on Edgy.
<_MMA_> I dont know if thats changed.
<_MMA_> I did it a while ago.
<crimsun> you still can.
<_MMA_> cool
<BenC> it should work, but I suggest updating module-init-tools and initramfs-tools aswell
<ttoine> well, men, just, these are not in the standards ubuntu edgy repo, no ?
<_MMA_> No. You would have to chang to the feisty repos than change back.
<_MMA_> *change
<ttoine> ok, will try that
<ttoine> thanks for answers, cjwatson and BenC
<_ion> ...or use pinning to get updates.
<ttoine> what is pinning ?
<BenC> complex apt stuff
<ttoine> so not for me
<LaserJock> why not just download the packages, it's not that many really
<ttoine> could be a good simple way, yes
<_ion> apt_preferences(5) for horrible documentation, but there are some examples.
<BenC> LaserJock: Because you don't get dependencies
<ttoine> so i need the -lowlatency kernell, module-init-tools and initramfs-tools
<ttoine> right ?
<LaserJock> BenC: bah ;-)
<LaserJock> there for a sec I thought we were talking about rpms :p
<Nafallo> just run feisty. it's not that broken :-)
<_ion> At least when it happens to boot. ;-)
<Nafallo> I'm glad DMA is back though :-P
<ttoine> actually, i am waiting a lot for bluez-gnome too for my mobile internet connection
<ttoine> so feisty will be soon on my laptop
<Nafallo> :-)
<pitti> cjwatson: I fixed the regression from bug 59946 and added the new g-s-t debdiff; eyeballing and approval appreciated
<Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,Fix committed]  https://launchpad.net/bugs/59946
<pitti> good night everyone!
<sistpoty> lamont | Mithrandir: can one of you please give back kdesvn? (builds fine now). Thanks.
<lifeless> moining
<bddebian> Heya lifeless
<Nafallo> hi lifeless :-)
<Keybuk> that's weird, why has X-Chat lost the tabs and gained a list box instead?
<Keybuk> oh, I see
<Keybuk> it's a menu option
<Nafallo> Keybuk: :-)
* Keybuk can't get the fonts to look right yet
<Keybuk> Monospace looks too tall :-/
<Nafallo> Keybuk: what have you done to the poor system? :-)
<Keybuk> Nafallo: installed it
<Nafallo> Keybuk: how mean ;-)
<Keybuk> I seem to be, as usual, getting the best looking results by setting everything *exactly* wrong!
<Nafallo> lol
<Keybuk> enabling the Autohinter for Vera
<keescook> say, in python, what's the best way to test that an array contains a specific value?
<Keybuk> ok, think that's best
<Keybuk> the wrong DPI setting, and auto-hinter enabled ;)
<Nafallo> :-P
<sistpoty> keescook: how about yourarray.count(needle) > 0?
<keescook> sistpoty: yeah, cool, I was about to use .index, but .count works too.  thanks!
<sistpoty> np
<sistpoty> keescook: bah, I'm dumb... x in yourarray should be the simplest
<keescook> ack!  ah, yeah, I think that's the syntax I'd seen before but couldn't find.  :)
<Riddell> Keybuk: do you know what the status of digikamimageplugins is?  when I upload a new version it disappears without notice
<Keybuk> Riddell: no, I haven't arranged ssh access with the key on this laptop yet either
#ubuntu-devel 2007-01-04
<Riddell> ok
<__keybuk> hmm, interested
<__keybuk> failed to resume from hibernate; I guess that's an initramfs bug because it seemed to suspend ok
<Keybuk> suspend-to-ram worked, but the ipw3495 needed rmmod/modprobe on resume
<Keybuk> mjg59: any clue to the first?
<mjg59> Define "failed"
<Keybuk> mjg59: it (new laptop) appeared to hibernate just fine (other than a few USB messages)
<Keybuk> when power button pushed to resume, booted, GRUB, then just continued the usual boot sequence but leaving the suspended image in the swap partition rather than resuming from it
<mjg59> Check /etc/initramfs-tools/conf.d/resume
<Keybuk> that had RESUME=UUID=$(uuid of swap partition)
<mjg59> Ok. So that should really have worked.
<Keybuk> yeah
<mjg59> What does dmesg say?
<wasabi> So.. Ubuntu philosophy question. What do we all agree to mean by "Just Works".
<wasabi> Just Works, under specific circumstances?
<wasabi> Just Works, for home users?
<HrdwrBoB> Just Works for as many people as possible
<Keybuk> mjg59: nothing obvious, any particular string to grep for?
<mjg59> Keybuk: There should be an "Attempting manual resume"
<Keybuk> mjg59: no string like that in dmesg
<wasabi> Just Works, if you edit 3 environmental variables?
<mjg59> Keybuk: Is this feisty or edgy?
<Keybuk> mjg59: feisty
<mjg59> Hm
<fadey> hi
<mjg59> What kernel version?
<Keybuk> mjg59: 2.6.20-3
<mjg59> Right.
<mdke> wasabi: just works, all the time.
<mjg59> There's been some changes in 2.6.20 upstream that may have broken things.
<Keybuk> dunno if it's related, but I saw some kinit resume messages when I wasn't trying to resume
<mjg59> Can you try a 2.6.19 kernel?
<wasabi> mdke: Does twisting environmental variables fall under Just Works?
<Keybuk> but those messages weren't shown when I was
<wasabi> Just Works, for admins adept at editing login scripts, maybe.
<mjg59> wasabi: No
<mdke> wasabi: no, the nature of having a philosophy is that you can't achieve it all the time
<mdke> it's an ideal
<Keybuk> mjg59: I'll debug a bit more tomorrow and get back to you
<mdke> my philosophy is to go to bed early, but I never do
<wasabi> https://launchpad.net/ubuntu/+source/beagle/+bug/77768
<Ubugtu> Malone bug 77768 in beagle "should not store indexes in ~" [Unknown,Rejected]  
<mjg59> There are situations where it's impossible to Just Work. There are other situations where Just Working would comprimse the Just Working of some other situation
<Keybuk> jdub claims it works fine on this machine in edgy, so I'm guessing it's just a feisty bug
<mdke> Ubuntu is much better than I am at that
* wasabi formulating argumnet.
<mdke> mjg59: well put! :)
<mjg59> wasabi: I disagree with the assertion that the Beagle data is system specific. In the common case, it isn't.
<wasabi> It makes no distinction about indexed files in ~ or /foo
<mjg59> The default setup is that Beagle indexes the home directory.
<wasabi> So, unfortunatly, it sort of is.
<mjg59> Not /whatever
<wasabi> Hmm. That's true.
<mjg59> Therefore, with the default setup it makes sense that Beagle's information be stored there
<wasabi> I'd still argue that it doesn't belong in ~ for transiate cache reasons.
<mjg59> It's not a transient cache
<wasabi> Sure it is. It can be regenerated.
<jdub> bah, keybuk left
<wasabi> 100%.
<mjg59> And the application won't work until it has been regenerated, which may take a long time
<wasabi> Hmm. The application will "work". It will say the cache needs to be built, please wait.
<wasabi> Okay, let me just bring up my actual real world circumstance.
<wasabi> My ~'s are AFS mounted.
<mjg59> An argument that I /would/ agree with is that if directories outside ~ are indexed, they should be tagged with the hostname
<wasabi> Pssh. I completely disagree. No other platform does it that way, for good reason.
<mjg59> So beagle can determine whether the result is relevant on the current host
<mjg59> ?
<mjg59> No, beagle should do it
<wasabi> a) I cannot store sockets in ~. As sockets are used to connect to LOCAL processes, they have no place in a directory which is designed to be sharable between multiple hosts.
<wasabi> b) Access to the files isn't safe over AFS or NFS. No locking.
<mjg59> It's entirely possible to implement safe locking over AFS or NFS
<mjg59> And, uh, you can't store sockets in ~? What sort of toy filesystem is this?
<wasabi> AFS.
<wasabi> ...
<wasabi> I'm also not sure if searching 400MB of index data over AFS is going to be very entertaining.
<mjg59> It's not like it does a linear search
<wasabi> Sure.
<wasabi> Anyways, Windows doesn't do it. Index data there is per-host... stored in a special per-host-per-user dir... for a very good reason anyways.
<mjg59> But anyway. The argument that it should be put in /var would break another Just Works situation, where /var is not configured to be large enough for a large number of users to have large files there
<wasabi> ...
<mjg59> If home directories are shared, it's reasonable for user-specific information to be stored there. See gconf, for example.
<wasabi> I don't think I can really accept that argument.
<wasabi> You make /var big enough to hold what it needs to hold. heh.
<wasabi> Or the installer does.
<mjg59> Well, no, that's not the case on thin clients
<wasabi> gconf does it because host-specific settings aren't in gconf.
<mjg59> They so are
<wasabi> Except for a few cases like powermanagement and friends.
<mjg59> Screen resolution, for instance
<wasabi> *sigh* I think that's wrong too.
<mjg59> Tough.
<mjg59> The Unix Way(tm) is for user-specific information to be in ~
<wasabi> I guess my only defense left is to pull the Windows card. They didn't do it. For good reason.
<wasabi> heh.
<wasabi> =(
<wasabi> mjg59: You mean like crontabs?
<mjg59> You keep saying "for good reason", but you haven't said what that reason is
<wasabi> I've listed a number of them.
<wasabi> I think I can give a pretty good argument that the number of office workstations with a small /var is lower than the number with a network mounted ~
<mjg59> You've said that AFS is broken, that doing locking on AFS is hard and that performance may be reduced
<wasabi> And again, we desire Just Works in the majoirty of cases.
<bhale> i havent said anything, but i am in agreement with mjg59 
<bhale> if that matters.
<wasabi> It's disappointing. I just know it's not going to be acceptable in most of hte network environments where I am trying to replace windows.
<wasabi> For the reasons I listed.
<wasabi> It's huge massive data. It doesn't need to be network mounted, it shouldn't.
<_ion> bhale: My left brain hemisphere agrees, but the right one disageres.
<bhale> do you need to use beagle in this environment?
<mjg59> Now, in counterargument, I'm going to say that if I run beagle on one machine in a cluster, I don't want to have to wait for an extended period of time for Beagle to reindex my files just because I've moved to another machine.
<wasabi> bhale: Seeking to replace windows, I do.
<mjg59> That isn't Just Working. It's stupid.
<wasabi> Since we use their indexing service.
<mjg59> It results in massive duplication of data, lower performance and  beagle having to look for new and altered files every time I log in
<wasabi> mjg59: I agree. I think then perhaps with that argument /var/cache isn't the best place for it, or that perhaps a cluster should deal with sharing some known location of per-user/per-host data.
<wasabi> But I don't any more agree that ~ is the best place for it.
<wasabi> Nor do I think the number of people running clusters in that situation is greater than the number of office desktops.
<bhale> dave_largo works on beagle for a thin client type network
<bhale> a few central servers
<bhale> lots of workstations/users
<mjg59> If AFS can't handle sockets in ~, that's an argument for keeping sockets in /tmp
<bhale> he might have some interesting parallels
<wasabi> I guess maybe this is a market we haven't really gotten traction in much.
<wasabi> WHich is why it's not yet a problem.
<wasabi> I deal with large office environments. Desktops, with central user management policies. AD, Windows.
<mjg59> If beagle isn't handling file locking over network mounted filesystems, then that's a bug in beagle
<mjg59> Those are both valid technical concerns, and if they cause problems then they should (and can) be fixed
<wasabi> Well, I sort of have a real feeling that sockets on a network mounted file system are stupid sounding.
<mjg59> Why?
<mjg59> You encode the hostname into them, and they work fine
<wasabi> Bah. SIllyness.
* wasabi renames hosts all the time.
<mjg59> While they're running?
<mjg59> I suggest not doing that
<wasabi> No. Windows makes me reboot. =)
<mjg59> That's fine. You recreate the socket on boot
<mjg59> Or login, or whatever
<wasabi> And that isn't odd that you're going all the way across the network to facilitate two local programs talking to each other?
<mjg59> Uh. Dude.
<mjg59> That's really not how sockets work.
<wasabi> I know. The data doesn't move across the network.
<wasabi> I know that stuff.
<wasabi> But it's silly that you have to create a file over there, to talk over here.
<mjg59> Why? It's an atomic operation.
<mjg59> It'll be one round trip to the server
<wasabi> This is a completely tangent minor technical complaint/argument.
<wasabi> I don't particularily care if you do in fact make a file on a remote system to talk to the same system... but it's technically silly.
<mjg59> Yes, but it's the strongest technical argument you've brought up
<wasabi> =(
<mjg59> I'm sorry, but "Windows doesn't work like that" isn't a compelling argument
<wasabi> Yes, i know.
<mjg59> We're different from Windows in a large number of ways, and that's something that has to be factored into conversion costs
<wasabi> I didn't mean to use it as a compelling argument.
<wasabi> This argument isn't worth having right now. I will give it another try when more people are using Linux in circumstances like that.
<mjg59> There are millions of people using Linux in circumstances like that
<mjg59> I used to admin a network of ~100 of them
<wasabi> I must live in a cave then. Heh.
<mjg59> NFS ~, local /
<mjg59> Everything went in ~, since it was the only stuff we backed up
<wasabi> See, I would be pretty unhappy if I ran my backup program and it snarfed up 10GB of indexes.
<mjg59> Well, that's a trivial exclusion in the backup options
<wasabi> Not for the people who set up the networks I work on.
<mjg59> You probably don't want to backup the Firefox cache either...
<wasabi> Yup. You're right.
<wasabi> Which is why IE does not store it's cache in the roaming portion of a user's profile.
<wasabi> It goes nicely in Local Settings.
<wasabi> .evolution is another example.
<Nafallo> hmm
<wasabi> Luckily outlook puts it's client side cache in Local Settings too.
<mjg59> Evolution stores your mail there. That's very much per user, not per system
<wasabi> It's cached data in any networked environment I've been in.
<wasabi> Nobody uses POP anymore.
<Nafallo> my parents use POP ;-)
<wasabi> Ahh. Good point. Home users do.
<lifeless> wasabi: people use POP
<lifeless> wasabi: even corporate folk choose to
<wasabi> And I agree, POP goes in ~.
<wasabi> IMAP doesn't...
<Nafallo> but my parents are stupid so... ;-)
<HrdwrBoB> we mandated that people don't use POP
<HrdwrBoB> because they are generally useless and lose their mail
<mjg59> Unix and Unix-type operating systems have never guaranteed any significant user-specific storage outside ~, and large quantities of software are built around that assumption
<wasabi> mjg59: Curiously, why is crontab an exception?
<wasabi> crontab imo is a great one.
<wasabi> It does it perfectly. :0
<wasabi> per-user/per-host.
<mjg59> Because cron jos are executed even when the user isn't logged in
<mjg59> Which means you can't guarantee access to their home directory
<wasabi> I'm also not particularly interested in obeying any definition of "Unix and Unix-type" that mandates such things if those things don't in fact line up with what I need them to do to get the job done.
<wasabi> Just as good as relying on "But windows does it!"
<mjg59> "Unix does it like this" is not a compelling argument for changing the behaviour of a Windows app. But it /is/ a compelling argument for deciding the behaviour of a Unix app.
<mjg59> If your argument is "Linux doesn't behave like Windows, and therefore we face increased migration costs", then you're right.
<wasabi> No, that's not my argument.
<wasabi> My argument is I have some jobs that need to be done, jobs which I believe Ubuntu does in fact claim to function properly with.
<wasabi> That is, a non-thin client desktop, connected to a central server for a user's ~ data.
<mjg59> How does Beagle placing its indexes in ~ prevent any jobs?
<wasabi> it makes the Just Workyness of a configuration like that less Just Worky.
<mjg59> How?
<wasabi> a) indexes generate Really Really slow, access to them is also sluggish. They are huge amounts of data after all, they index people's email full text.
<wasabi> b) They are huge. They take up server space which doesn't in fact need to be consumed.
<lifeless> wasabi: meh, those are not the issue
<wasabi> c) sockets don't work, this isn't a primary concern of mine, because I do agree AFS has a problem.
<wasabi> What's the issue then? That I'm not deploying thin clients?
<wasabi> Or that I'm network mounting ~?
<wasabi> Or that I chose AFS?
<mjg59> (a) - no. The rate of index generation is not limited by write speed.
<lifeless> mjg59: if beagle places indexes in ~, and it indexes the machine I'm logged in on, then with a NFS mounted homedir, the beagle index needs to represent two separate machines in one physical index
<wasabi> Dude. My index files are 500MB.
<wasabi> Just for me.
<lifeless> mjg59: or be split per host in the users homedir.
<mjg59> lifeless: Please refer to the beginning of the conversation
<wasabi> You're telling me it magiked 500MB across a 100MBs network?
<lifeless> mjg59: I thought I had ;).
<mjg59> wasabi: On startup, beagle indexes very slowly.
<mjg59> At no point will it be i/o bound.
<wasabi> Sure, but it also kills the network.
<mjg59> No, it doesn;t.
<mjg59> The data is trickled across.
<wasabi> ...
<wasabi> Well, I have experiences that say otherwise. Are you suggesting it's a beagle bug that it doesn't attempt to write slower than possible?
<mjg59> I'm saying that Beagle does not generate 500MB of indexes in the first 5 minutes, yes
<wasabi> Takes longer than 5 minutes. =)
<wasabi> Now, curiously, how does beagle actually implement a search that doesn't require reading a large portion of the 500MB over the network?
<mjg59> (c) is clearly nothing to do with the indexes
<wasabi> Oh, hey, I take that back.
<wasabi> 3.4G    .beagle/
<wasabi> Hadn't actually checked in a few days. ;)
<shackan> ugh
<shackan> that's just your home?
<wasabi> I have a lot of email.
<wasabi> Also, it's network shares.
<wasabi> Some...
<wasabi> actually, probably not. I don't think I ever got it to index those.
* wasabi digs.
<mjg59> wasabi: Given that it's able to fully answer my queries in much less time than it would take to read 500MB off the disk, it clearly can
<wasabi> mjg59: Local ~?
<mjg59> I am, sadly, not an expert on the state of the art in the sort of data structures used in indexing
<mjg59> Yes, local ~
<wasabi> It's probably mmaped and pretty warm.
<mjg59> No
<shackan> well, it surely is not a linear search so it's never going to have to slurp the whole half gig from disk
<mjg59> But what I'd assume at the very least is that it's a tree
<wasabi> argh. it uses absolute symlinks too.
<mjg59> For logfiles - that's hardly an issue...
<Nafallo> hi jono :-)
<jono> hey
<wasabi> Well. I can't argue this anymore. I have work to do. If nothing else I really think it's silly to store 3.2GB of non-critical data in something which is generally considered critical: ~
<wasabi> night
<maxb> What is the proper thing to do when a severe bug (package totally unusable) is filed in Launchpad, but no maintainer responds, even after 3 months have passed?
<crimsun> which bug?
<maxb> 62748
<crimsun> bug 62748
<Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]  https://launchpad.net/bugs/62748
<crimsun> maxb: if you feel inclined, please follow https://wiki.ubuntu.com/StableReleaseUpdates
<maxb> crimsun: That wiki page seems to be instructions for package maintainers, no?
<crimsun> maxb: it's not limited to maintainers, no.
<maxb> Anyone can upload to <release>-proposed ?
<crimsun> no, in this case, only ubuntu-core-dev
<LaserJock> maxb: not actually upload, but prepare an upload sure
<crimsun> anyone may prepare an SRU debdiff, however, as LaserJock mentioned
<maxb> I've added a debdiff to the bug. The rest of the SRU procedure really looks like it needs participation from maintainer, even if I can help it along in places. I guess I'll hang around on IRC and try to initiate communication that way.
<crimsun> which bug #?
<crimsun> (it helps immensely when you provide this information up front so we don't have to ping-pong)
<crimsun> btw, file a new bug for an SRU
<maxb> Same bug number as before
<maxb> bug 62748
<Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]  https://launchpad.net/bugs/62748
<crimsun> it'll help the SRU team if you collapse only the relevant info into a new bug report
<bddebian> Heya
<crimsun> maxb: use the SRU versioning, please: 2.0.55-4ubuntu4.1~proposed1; the distro is "edgy-proposed"; please state the rationale in debian/changelog for filing an SRU debdiff in the first place; attach the actual debdiff (not just inline)
<sistpoty> crimsun: btw.: what would be the version for the actual upload actually? ~distribution1 (which would score lower than ~proposed1)?
<sistpoty> upload to -updates actually
<crimsun> sistpoty: 2.0.55-4ubuntu4.1
<sistpoty> crimsun: ah, makes sense :)
<keescook> g'night folks
<sistpoty> gn8 keescook
<Nafallo> oh. I thought .X was for -security only :-)
<okaratas> hello
<somerville32> hi
* Hobbsee waves to okaratas and somerville32 
* somerville32 hugs Hobbsee.
* Hobbsee hugs somerville32 
* Hobbsee looks for a core dev
<tonyyarusso> cjwatson, any others: We're going to spotlight the process for Main Inclusion Requestions for the Ubuntu Weekly Newsletter, so if you'd like to talk to me about that, give any guidance on the article, or throw out some great quotes I can attribute, join #tonyyarusso and let me know.
<tonyyarusso> Any core devs actually (his name was on the wiki as last editor is all)
<tonyyarusso> Any time in the next couple of days.  We plan to release this edition on the 8th.
<tonyyarusso> (If I'm not there, but tonyyserver is, you can leave a message and it will be logged)
<StevenK> mpt: Too slow. I have done but not commited or pushed a first stab at Debian packaging.
<StevenK> mpt: (For About window). I've spent a grand total of 30 minutes on it, so if you've done it, I'm happy to bin it.
<mpt> StevenK, thank you
<StevenK> mpt: Also some changes to AboutWindow.py that allow it to work both ways, either running from . or installed from a package
<StevenK> mpt: I was planning on adding a menu file stuffing an entry into the System menu, and then commiting and pushing
<mpt> StevenK, does that replace the existing "About Ubuntu" item?
<mpt> (it should)
<StevenK> Which is harder.
<mpt> ah :-)
<StevenK> Yes it should, I wasn't planning on enforcing that.
<StevenK> gnome-panel-data: /usr/share/applications/ubuntu-about.desktop
<StevenK> Oh, icky.
<StevenK> mpt: I'm also going to kill the icons that aren't *ubuntu.
<StevenK> Since they have been unceremoniously killed from the glade file.
<mpt> Hey, I was very ceremonious
<mpt> I lit a candle and everything
<StevenK> :-P
<StevenK> mpt: Hrm. My .desktop file doesn't work.
<Hobbsee> StevenK: try lighting a candle for it :P
<StevenK> Hah
* StevenK is trying to determine what makes the System menu.
<StevenK> Hrm. I don't get it.
<fabbione> who broke locales?
<StevenK> mpt: Commited and pushed.
<StevenK> mpt: The .desktop file needs sorting out, and I'd like to see it run on a PowerPC
<crimsun> cjwatson: please reject murrine_0.40.1-0ubuntu1 from NEW; a ship-shape source package with proper pedigree (from clearlooks, etc., in a CREDITS file) will be uploaded
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> The following packages have unmet dependencies:
<fabbione>   evolution-data-server: Breaks: evolution-exchange (< 2.9.4) but 2.8.2-0ubuntu1 is to be installed
<fabbione> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
<fabbione> E: Internal error, problem resolver broke stuff
<fabbione> mvo: ^^^?
<mvo> fabbione: please install the latest apt directly and then do a dist-upgrade
<mvo> (a bug in the breaks field implementation)
<fabbione> apt-get install apt
<mvo> yes
<fabbione> apt is already the newest version.
<fabbione> Version: 0.6.46.4ubuntu6
<fabbione>  ?
<mvo> oh. that is a new problem then. strange enough, it looks exactly like the old problem :)
<fabbione> mvo: this is ok sparc
<fabbione> the machine was not updated for a couple of weeks
<fabbione> mvo: dist-upgrade seems to work... the error was when invoking with dselect
<mvo> fabbione: ok. so when pressing [Install]  in dselect it bombed out?
<fabbione> mvo: yes..
<mvo> fabbione: had someone teached the dselect resolver about breaks yet?
<mvo> s/had/has/ 
<fabbione> mvo: i thought that dselect/dpkg already knew about Breaks
<fabbione> at least i recall using dselect in edgy when we had breaks enabled
<fabbione> but does Breaks: support ABS ? :P
* mvo looks at iwj to see if dselects resolver support breaks 
<mvo> fabbione: HAHA
<fabbione> time for a shower
<fabbione> brb
<mvo> fabbione: I'm testing it in a chroot now
<fabbione> mvo: ok..
<Mithrandir> crimsun: rejected
<crimsun> Mithrandir: thanks
<gnomefreak> is it just me or is feisty main repo down
<Mithrandir> siretart: does libxine1-console => universe sound ok with you?  -gnome and -kde to main? (And -ffmpeg to main?)
<Keybuk> Mithrandir: you know a little about xkb?
<Keybuk> why is the Windows key now suddenly <Mod4><Hyper> ?! :)
<Mithrandir> it is?  For me it's Super.
<Keybuk> it's Super for me on edgy
<Keybuk> but on feisty, it appears to be weird
<Keybuk> both machines running feisty exhibit it
<fabbione> something is broken in locale too
<Mithrandir> somebody said something this morning about locales being broken, I'm not sure how and such, though
<fabbione> this smells of libx11-6 borkage
<fabbione> no.. not even
<Keybuk> hmm
<Keybuk> my edgy machine has it too
<Keybuk> weird
<fabbione> hmm it looks like something didn't run locale-gen
<fabbione> oh well i am hungry :)
<Keybuk> mjg59: I'm assuming you never fixed GNOME Power Manager to not override the ondemand governor?
<mjg59> No, upstream were meant to be fixing it
<ogra> i think upstream agreed on it on the ML already
<ogra> should be fixed in the next package
<Keybuk> ok, cool
<ogra> i wonder if we really need that power hostory tool in the system tools menu ... 
<ogra> *history
<siretart> Mithrandir: I'm okay with that, whereas I don't see quite the point. in previous versions of ubuntu, everything was in main
<siretart> Mithrandir: why do you want -ffmpeg in universe?
<siretart> Mithrandir: in the TB meeting, we agreed that -ffmpeg may enter main, but MUST NOT be in the ship seed, so that it doesn't go near a live cd
<Mithrandir> siretart: if everything used to be in main, I'm fine with keeping it that way; it's mostly a "try to keep main as small as possible" reflex.
<siretart> Mithrandir: yes, with the split we indeed have that oppurtunity. I split the package mainly to get more sane depend lines
<Mithrandir> siretart: if you'd like it all in main, I'm fine with that.  At least until it shows up as "unused" in the anastacia output.
<siretart> Mithrandir: okay, then lets put them all in main for now, and reconsider later about what output plugins we want to support for feisty
<siretart> (I'm of course for all ;)
<Mithrandir> siretart: ok.
<elmo> is network manager meant to get along with madwifi/atheros chipsets?
<fabbione> elmo: did you get my /msg about the sparc kernel?
<elmo> fabbione: err, not sure - which one/when?
<elmo> artigas is running that debug kernel you gave me las tyear
<fabbione> elmo: the one to test on the buildd
<fabbione> perfect
<fabbione> thanks
<siretart> elmo: depends on what madwifi. it is known to make problems with madwifi-old, and there are successful reports with madwifi-ng
<elmo> siretart: what does edgy default to ?
<siretart> details: -old did not support 'background' scanning
<Ng> edgy uess madwifi-ng
<Ng> network managet should work with it (does on my laptop and desktop)
<siretart> dapper was with madwifi-old
<elmo> hmm, ok - so what's the magic to turn network manager on?
<elmo> I thought it was disabling the auto lines in /etc/n/i
<mjg59> edgy only uses madwifi-ng under certain circumstances
<mjg59> Oh. Maybe not.
<Ng> elmo: removing the device entirely from interfaces seems to work
<mjg59> Actually, I can't remember
<siretart> elmo: do you have both a  'wifi0' and an 'ath0' device, or just an 'ath0'?
<siretart> with wifi0 you are on madwifi-ng
<elmo> siretart: I think both
<Keybuk> elmo: comment both the auto and iface lines in /e/n/i
<elmo> Keybuk: ah, ok
<Keybuk> then give network manager a kick (/etc/dbus/event.d/25NetworkManager restart)
<elmo> Keybuk: rock, thanks, that worked
<elmo> btw, what's still blocking network manager by default?
<Keybuk> lack of easy static configuration
<Keybuk> tollef has a spec about it
<siretart> elmo: and reliability. my gf is complaining that nm works only sometimes. then she uses ifup ath0=home to get her interface up
<siretart> using ipw2100/edgy
<siretart> how is unattended triggered after installing?
<Nafallo> siretart: /etc/cron.daily/apt IIRC
<Riddell> today's daily CD boots with a kernel panic saying "no init found"
<elmo> BenC: stupid question - but something does remove /var/run/do-not-supsend, right? ;-)
<BenC> elmo: /var/run is cleaned on reboot, right?
<BenC> update-notifier also writes a file there for when a reboot is needed
<BenC> err, the reboot notifier I mean
<BenC>  /usr/share/update-notifier/notify-reboot-required
<elmo> BenC: ah, ok, I guess it does
<elmo> tho, interestingly I can't see where in edgy, offhand
<siretart> Nafallo: ah, but only after enabling it by reading that file, and setting the config variable
<elmo> /etc/init.d/bootclean only seems to clean /tmp
<siretart> Nafallo: if you know it, good, but I think it is quite unobvious. hmm
<Mithrandir> BenC: /var/run is a tmpfs.
<BenC> that's right
<Mithrandir> so, well, nothing "clears" it per se, but it's not persistent.
<elmo> ah, then the comments in the init.d files should be fixed
<elmo> mountall-bootclean.sh:  # Clean /tmp, /var/lock, /var/run
<Nafallo> siretart: sure. but standard is to use unattended if installed, isn't it? :-) and there is something in some GUI somewhere :-)
<siretart> Nafallo: no, I just installed it on dapper, and it was NOT used by default
<siretart> Nafallo: and I didn't see any gui to enable it yet 
<Nafallo> oh. how mean.
<Nafallo> siretart: software-properties have a tickbox for it in feisty anyway :-)
<siretart> Nafallo: ah, I think I found it. okay
<iwj> Keybuk: Do you want be CC'd on mails between me and Tim Mueller about this gstreamer codec stuff ?
<iwj> mdz is currently on the CC list.
<Keybuk> iwj: sure, if there's something you want me to be aware of or just want it tracked
<iwj> Oh, and is there a distro meeting today and if so (a) when and (b) it seems not to have been announced anywhere ...
<iwj> Keybuk: I think it might be helpful.  I'll forward you the last two and CC you from now on.
<Keybuk> ok
<Hobbsee> iwj: by not announcing, it keeps you on your toes :P
<iwj> Hobbsee: It might keep us on our toes tomorrow when we discover we've missed it ...
<Mithrandir> pitti: just the man I was looking for.
<Mithrandir> pitti: I have trouble getting hot-plugged encrypted devices to be mounted automatically.
<Mithrandir> it sets up the dm-crypt target, but then stops.
<pitti> Mithrandir: did you comment out the udev rule that disables the dev nodes?
<Mithrandir> pitti: no?
<pitti> /etc/udev/rules.d/20-names.rules, #KERNEL=="dm-[0-9] *",                   NAME=""
<pitti> Mithrandir: ^ disable this
<pitti> Mithrandir: it's currently disabled due to the race condition, udev-device-mapper spec will fix this
<Mithrandir> pitti: yay, that fixed it.
<Mithrandir> thanks.
<iwj> So the most obvious way of automatically grabbing the gstreamer plugin metadata and dumping it into an appropriate file is a new dh_ command.  Is there anything I should watch out for when augmenting debhelper ?
<iwj> cjwatson: ^
<cjwatson> urgh, does it have to be a debhelper extension?
<iwj> No, it doesn't.  Is that bad ?
<iwj> But it will help because it really wants to write some files into the debian/<package> tree.
<cjwatson> it's just that joeyh has been antsy about Ubuntu-specific debhelper extensions for a long time
<cjwatson> can it go in a development package that all the relevant packages already build-depend on, rather than into debhelper core?
<iwj> I could make it a random shell command in gst-foobar.
<cjwatson> it could still use the debhelper libraries for uniformity; there are other programs that already do that I think
<iwj> But you'd end up having to specify more boilerplate in the rules file.
<iwj> Oh, really ?
<cjwatson> (phone call, I'll get back to you)
<Keybuk> why can't we put it into Debhelper, but name it uh_* ?
<iwj> OK.
<cjwatson> dh_consoledata IIRC
<iwj> cjwatson: Will look, thanks.
<pitti> ogra: so 2.6.20-4.5 should make us happy again \o/
<ogra> YAY !!
<ogra> i havent read the changelog, i'm reviewing ltsp patches the whole day already ... thanks for notifying
<iwj> cjwatson: dh_consoledata is very helpful, thanks.
<Hobbsee> Mithrandir: question: if a source is in main, do we have to file a MIR to get one of the binaries in main too?
<Mithrandir> Hobbsee: no
<Hobbsee> Mithrandir: cool.  didnt think so
<siretart> YAY. xine-lib_1.1.3 reached the mirrors! :)
<pitti> siretart: is that an unified source package again?
* hunger would be awfully happy if somebody would find the time to sort out this language-support mess we currently got.
<siretart> pitti: as discussed with the technical board, it comes with the pristine upstream tarball, read: with included ffmpeg
<pitti> hunger: ?
<siretart> pitti: that ffmpeg copy does only decode, however. 
<siretart> pitti: I'll link against external ffmpeg as soon as it enters main (if it does, of course)
<hunger> pitti: since the new OOo is in the archives (before xmas) I can not upgrade since language-support-en and language-support-de have broken dependencies.
<pitti> hunger: ah, these are broken deps of the oo-help/l10n packages against ooo-core/common
<pitti> doko: ^
<doko> pitti, Mithrandir: still in NEW?
<pitti> ah, might be
<Mithrandir> doko: nope
<hunger> pitti: IIRC gimp-help-de is not satisfyable in language-pack-de as well... I'll check again once aptitude is done downloading kernels:-)
<pitti> doko: I don't see anything OO related in NEW
<doko> pitti: then it's in feisty.
<hunger> doko: I definitly am having the dependency problems in feisty even now:-(
<giskard> ciao
* hunger wonders why aptitde installs linux-image-...-generic and linux-image-...-server all of a sudden.
<Mithrandir> doko: openoffice.org-l10n-sv for instance has a Conflicts: openoffice.org-core (<< 2.0.4), openoffice.org-core (>= 2.0.4.1), this doesn't really look right?
<doko> looking ...
<pitti> doko: openoffice.org-l10n-de depends on openoffice.org-common (< 2.0.5), but common is 2.1.something
<hunger> ... and -server-bigiron as well!
<mneptok> hunger: the all-perceiving aptitude forsees new hardware purchases *handwave*
<hunger> mneptok: Damn... I knew I shouldn't have installed the sylvester edition of aptitude;-)
<mneptok> :)
<bddebian> Heya
<Mithrandir> doko: debian/rules first sets BASE_VERSION:=$(UPSTREAM_VERSION), then it's later overridden to be 2.0.4
<Mithrandir> doko: I suspect this is the problem.
<hunger> New feisty kernel postinst scripts fail here.
<cjwatson> iwj: excellent
<cjwatson> iwj: using the library should help get DH_COMPAT handling right for the most part, which is the main subtlety
<iwj> cjwatson: Right.
<pitti> cjwatson: the recent Australian timezone change (bug 72125) bumped the urgency of timezone-upgrades spec a bit; of course this very bug can be fixed without problems, but I think we should find a more generic solution to put the latest TZ data into all stable releases
<Ubugtu> Malone bug 72125 in tzdata "Daylight Saving changes in Western Australia" [High,In progress]  https://launchpad.net/bugs/72125
<pitti> cjwatson: the thing we need to do is to offer TZ reconfiguration if a TZ is removed/merged/split
<pitti> cjwatson: the postinst currently uses tzconfig in the postinst, which is ugly and violates DP
<cjwatson> pitti: removals are very rare, aren't they?
<pitti> cjwatson: is there something debconf'ish (d-i like) we could use?
<cjwatson> and merges normally leave the old one around
<pitti> cjwatson: certainly removals are rare, but I saw TZ merges
<pitti> and splits
<cjwatson> but the old TZ usually remains valid
<cjwatson> for splits, people can reconfigure from the desktop if they find that their timezone is wrong, can't they?
<pitti> cjwatson: right
<cjwatson> I'd be inclined not to overcomplicate the upgrade process - people notice if their computer's time is wrong
<cjwatson> and the problems are in pretty rare cases
<pitti> cjwatson: my feeling is that this is a rare enough special case to justify the usage of tzconfig if the current TZ doesn't exist any more
<iwj> cjwatson: notice> But they generally try to fix it by adjusting it or reckon it's too hard.
<pitti> cjwatson: we can detect if the set of available TZs for the user's continent has changed and ask him again, but I wouldn't do that with tzconfig
<cjwatson> pitti: as long as the upgrade tool will do something reasonably sensible (i.e. pop up a terminal window rather than break), I'd be happy with that
<cjwatson> pitti: d-i has tzsetup, but I don't think it's suitable for use outside d-i yet
<pitti> cjwatson: u-mgr currently opens the terminal if the package installation doesn't proceed for 30 seconds
<pitti> i. e. when it asks a question on the command line and expects input
<cjwatson> I would like it to be, but it has fiddly dependencies
<pitti> cjwatson: ok, then d-i tzsetup doesn't sound appropriate at least for stable release upgrades
<cjwatson> not yet at least
<pitti> cjwatson: ok, then my other idea is the following:
<cjwatson> maybe at some point in the future
<iwj> pitti: Couldn't you use cleverness with process groups and SIGTTIN for this ?
<pitti> cjwatson: I write some diff magic that checks for removed TZs of two versions, prints them out, and we handle those as special cases in the postinst
<cjwatson> I'm still inclined to ignore merges. Removals we obviously have to deal with, if they actually happen (I think they would constitute a mistake in tzdata, though). Can we detect whether splits really affect the user's timezone on a finer granularity than continent?
<cjwatson> perhaps this is rare enough that we can just special-case everything
<cjwatson> that might be easier than overengineering autodetection
<iwj> cjwatson: detect> No, because the user might have selected a nearby place in the installer knowing that the timezone was the same.
<pitti> I didn't see those splits/merges in the recent updates, but I did see them in 2006l or 2006m
<cjwatson> iwj: seems like the sort of thing that's a lot easier to special-case when it happens (we can probably guess "nearby" closely enough)
<cjwatson> or we could pop up a notification suggesting that people use the city chooser in g-s-t, which is pretty similar to the one in ubiquity
<pitti> cjwatson: for feisty we might implement some more niceness, like detecting for changed TZs on your continent and adding a notification bubble that points to the Gnome TZ setup tool
<iwj> If we knew the set of places they were offered we might be able to second-guess them since they ought to have picked somewhere close to their real location but I think this depends too much on the user having considered that the timezone might split.  That's not the kind of foresight that we should be expecting.
<cjwatson> (in fact ubiquity's code is descended from evolution via g-s-t)
<cjwatson> how about changing time-admin to say "if your time is wrong by some number of hours, consider making sure that your time zone is right <button>"
<iwj> In general if any substantial bit of the territory covered by a timezone is to be split off, we should probably just ask.
<iwj> Well, time-admin should find out whether ntp is working.  If it is then the user shouldn't be adjusting the time at all.
<pitti> cjwatson: sounds good
<cjwatson> iwj: yes, I just don't want to have to ask folks who chose Los Angeles time when some bit of Indiana gets split
<cjwatson> so I think continental granularity is too coarse
<iwj> cjwatson: Do we record that they said LA or do we reduce it to PST ?
<pitti> cjwatson: ok, we seem to agree that handling the rare special cases in the postinst is the right thing for stable-updates
<cjwatson> iwj: it's recorded as America/Los_Angeles
<iwj> And indeed this is rare.
<iwj> cjwatson: Oh, good.
<cjwatson> oh, hang on, that might not be true for the US
<cjwatson> for most countries we use the city zones, anyway
<cjwatson> I forget the precise details
<cjwatson> no, having checked, ubiquity will always record the city name. In d-i you don't have the city selector and in the case of the US we only prompt for Eastern, Central, Mountain, Pacific, Alaska, Hawaii, Arizona, East Indiana, Samoa
<cjwatson> there are special cases for 21 countries in d-i to produce more useful timezone choices than you can get from just grepping zone.tab
<cjwatson> (since a lot of the entries in zone.tab are only of historical interest)
<cjwatson> pitti: yes, I think that's the easiest to audit for correctness
<pitti> cjwatson: and as a fallback I would use the already existing tzconfig call, just to have something better than a dangling tz symlink
<cjwatson> I'm still very surprised that tzdata would actually delete a timezone
<cjwatson> surely they realise how much of a pain migration is (and Paul Eggert is normally pretty sensible)
<pitti> cjwatson: ok, I checked, since breezy there actually was only one removal (America/Coral_Harbour)
<pitti> cjwatson: so I'll just add postinst code to automatically transition this to whatever replaced it and we should be good
<pitti> ah, merged to America/Atikokan, so this is easy
<ph8> anyone here got #ubuntu ops? spammers ahoy
<tkamppeter> Someone around who can introduce packages from the NEW queue into the distro? SpliX, the driver for Samsung lasers is still did not make it into the distro.
<cjwatson> Riddell: I've moved the grub configuration stuff in ubiquity to an Advanced... dialog - I *think* the KDE frontend changes I made are pretty close, and I'll try to test them before upload if you can't, but I'd appreciate a second look
<Riddell> cjwatson: I tried to test a daily CD this morning but it kernel paniced, I'll take a look at the bzr version now
<twb> Mithrand1r: nag, nag
<BenC> Keybuk: ping
<Keybuk> BenC: yo
<BenC> Keybuk: I have a kernel patch that implements /sys/bus/disable_auto_probe, do you want a kernel patch, or a kernel image deb to start testing udev?
<Keybuk> image deb would be perfect
<siretart> Riddell: do you know of anything (amarok or other stuff) which could/would be blocked for xine-lib 1.1.4?
<Riddell> siretart: shouldn't think so, might be an idea to check that kaffeine keeps working but I see no reason why not
<BenC> Keybuk: Ok, I'll have one on rookery for you by your morning
<siretart> Riddell: I'm asking because I've heared that there might be an 1.1.4 release this month, in which case I'd consider it for feisty
<BenC> Keybuk: i386 or amd64?
<Riddell> Mithrandir: fancy doing an archive change?  libopenobex1.0 and binaries needs moved out of main and libopenobex and binaries moved in
<Riddell> siretart: let me know when you have packages and I'll give them a test
<Keybuk> BenC: i386
<fbenites> hi!
<fbenites> how does ubuntu create menu.lst?
<fbenites> i wanted to use these routine...
<fbenites> i want
<BenC> fbenites: It tells you in the file :) update-grub is the program
<siretart> Riddell: okay.
<fbenites> BenC: where can i get the sources?
<fbenites> i would like to build a menu, like grub does... would be it hard?
<BenC> fbenites: The program is shell, so the source is right there
<Riddell> Mithrandir: see my archive request?
<pitti> is there anyone on i386 who could apport-retrace a crash report from bug 73104 for me? I only have powerpc available ATM
<Ubugtu> Malone bug 73104 in apport "apport-checkreports crashes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73104
<BenC> pitti: Is it possible that this was the gdb/kernel bug?
<BenC> Oh wait, that's on edgy/2.6.17
<pitti> BenC: in edgy?
<BenC> not the same bug
<pitti> ah
<pitti> I get a lot of bugs about sigsegvs of python in apport-gtk
<jdong> that should be on the list of things that only happen in really bad dreams ;-)
<jdong> segfaulting python
<BenC> pitti: I ran apport-retrace on it and it just returned with no messages
<pitti> BenC: oh, in particular I need it run with -d
<pitti> BenC: that will regenerate the stack trace with debug symbols
<pitti> BenC: and perhaps with -c to remove the core dump after retracing
<pitti> BenC: or, instead of -c, just -s for stdout output
<BenC>   File "/usr/bin/apport-retrace", line 129, in prepare_debugdir
<BenC>     assert ldd.returncode == 0
<BenC> do I need to run it as root?
<pitti> BenC: argh, that's a bug in the edgy version of apport-retrace
<pitti> BenC: fixed in the feisty version
<BenC> heh
<somerville32> jdong: update-manager segfaults if you try to run it with no x environment :P
<jdong> wow
<pitti> BenC: ah, I just found a i386 box where I'm root, so I'll do it in pbuilder; thanks anyway
<BenC> pitti: Ok
<elmo> pitti: what's the magic to make a user's foreign-os partition auto-visible on the desktop?
<pitti> elmo: mount it to /media
<elmo> hmm, doesn't seem to do anything
<pitti> elmo: in edgy?
<elmo> yah
<elmo> it's an intel mac and a hfsplus disk on a sata drive, if it makes a difference
<pitti> elmo: ah, right, this requires a hal and a session restart because hal doesn't notice manual mounts
<elmo> pitti: ok, tryting that, thanks
<elmo> BenC/kylem: while I'm here, do you know off hand of bug reports about the edgy kernel panicing on boot irregularly (maybe 1/10) on intel macpro's?
<elmo> whining about IO-APIC
<BenC> elmo: Something about the timer?
<kylem> i don'tbelieve i've seen a bug report offhand, but i seem to recall hearing about it before.
<elmo> BenC: yeah
<BenC> elmo: Yeah, it's a kernel bug that should be fixed in feisty
<BenC> quiet the quirk, not sure we can safely backport a fix without possible regressions for other x86's
<elmo> BenC: cool, thanks
<BenC> Keybuk: Did you notice in 2.6.20 there's now a /sys/module/*/drivers/ sub-directory for each module?
<BenC> with symlinks to the actual drivers for the module
<Keybuk> yes
<Keybuk> but that's not the most useful bit
<Keybuk> UEVENT[1167866647.245114]  add@/bus/pci/drivers/ipw3945
<Keybuk> ^ that's MUCH more useful <g>
<Keybuk> (from SUBSYSTEM=="drivers")
<BenC> sweet, it works
<BenC> manually binded a PCI device to the ohci1394 driver with auto probe disabled
<elmo> we had ~ support in breezy, right?
<elmo> in version numbers
<jdong> BenC: whoa, you can do that?
<jdong> elmo: IIRC that worked in Warty fine too
<jdong> elmo: so your answer is a definite yes :)
<BenC> Keybuk: Kernel is uploading to rookery now. If you can provide me with a working udev to go with it when you get it ready, I'd appreciate it
<BenC> jdong: Technically you can bind/unbind right now, but the auto-probe disabling is new
<jdong> like if I have a UMS device that doesn't get detected as usb-storage, I can force-bind it?
<BenC> no, that wont work
<jdong> aww :(
<BenC> you can with PCI devices, but I don't think you can do it with USB
<jdong> BenC: is it easy to force a usb-id to be a usb-storage device @ the source level?
<jdong> I'd like to be able to rip some firmware off a DAP in flash-mode
<BenC> jdong: Should be a simple line or two
<jdong> cool
<jdong> I'll have to do that in a sec
<BenC> Keybuk: p.u.c/~bcollins/kernels/for-keybuk/
<somerville32> I'd like to propose demoting xchat-gnome and promoting xchat back to main because: 1) I'd like to promote an irc client (and xchat > xchat-gnome now that the usability issues have been resolved) to the xubuntu-desktop seeds 2) xchat-gnome isn't in ubuntu-desktp anymore
<Keybuk> BenC: does the auto-probe disable probing for all subsystems, or just pci?
<hunger> I keep getting dangling symlinks in /usr/share/man. Is there some trick to stop that? Maybe to even make sure that none end up in packages?
<BenC> Keybuk: everything
<BenC> Keybuk: It stops it in {driver,device}_attach
<Keybuk> BenC: so it should be possible to bind jdong's usb device to the usb-storage driver, no?
<BenC> Keybuk: Ah, true, it should be
<Keybuk> it'll behave as if its probe function found that device, and carry on from there
<jdong> cool
<Keybuk> of course, it may fall over some check in the driver for device ids, or even hit an assert_not_reached or something <g>
<jdong> :D
<BenC> I wonder if bind enforces bus<->driver sanity
<jdong> that's the fun part, Keybuk :)
<BenC> I suspect it has to
* jdong has a sneaky suspicion that his cheap Chinese DAP runs Linux of some sort
<BenC> Yeah, it only searches for device on the bus the driver is registered to
<Keybuk> BenC: if you poke into bind, does it check against the driver tables ?
<Keybuk> right, you can't bind a pci device to a usb driver
<BenC> good, I was worried about that :)
<Keybuk> jdong: find the usb storage device in /sys/bus/usb/devices
<somerville32> cjwatson, ping
<Keybuk> it'll have a name something like 1-2:2.0 and be one of the top-level symlinks
<BenC> That's helpful too for the UI, because if someone wants to force bind a driver, I just need to check the bus, and iterate the drivers registered to it
<jdong> Keybuk: will this require a feisty kernel? am currently not on feisty... :(
<Keybuk> jdong: no, this will work on edgy
<jdong>  cool
<BenC> jdong: bind works back to dapper I believe
<BenC> maybe even breezy
<jdong> Keybuk: k, I'm in
<Keybuk> jdong: does it have a product file in it that matches the device?
<jdong> Keybuk: what kind of file am I looking for?
<BenC> jdong: Might be easier if you identified the device from lsusb and matched it in sysfs
<jdong> I got am in the devices folder for the correct device...
<Keybuk> ok
<jdong> jdong-laptop:/sys/bus/usb/devices/5-3
<Keybuk> jdong: cat product
<Keybuk> what does that say?
<jdong> doesn't exist
<Keybuk> do bInterface* files exist?
<jdong> yes
<Keybuk> what's the name of the directory you're in?  (pwd)
<Keybuk> just the last bit
<jdong>  /sys/bus/usb/devices/5-3/5-3:1.0
<Keybuk> ok
<BenC> Keybuk: /sys/bus/disable-auto-probe accepts [YyNnFfTt01] .* for turning it on/off
<Keybuk> load the usb-storage module by hand (modprobe)
<Keybuk> then (as root) echo -n 5-3:1.0 > /sys/bus/usb/drivers/usb-storage/bind
<BenC> Keybuk: catting it will show either "true" or "false"
<Keybuk> BenC: sweet
<jdong> bash: echo: write error: No such device
<BenC> check dmesg and see if the probe failed
<jdong> no new entries in dmesg
<BenC> I think you just use the 5-3
<jdong> tried that too
<jdong> same error
<BenC> you might need to escape the :
<jdong> ah
<jdong> let's try :)
<jdong> aww still no luck
<Keybuk> BenC: reading driver_bind (at least the comment), it still checks the device's table
<BenC> Keybuk: new_id
<Keybuk> usb doesn't have a new_id
<Keybuk> or does it now?
<BenC> does for me
<jdong> I think it does
<jdong>  /sys/bus/usb/drivers/usb-storage/new_id
<BenC> jdong: Try echo'ing your vendor/device id's into that file
<BenC> you can get that easily from lsusb
<Keybuk> BenC: I'd be really tempted to make bind a forced thing :p
<jdong> what's the syntax for the ID?
<jdong>  echo -n '071b:3202' > /sys/bus/usb/drivers/usb-storage/new_id
<jdong> bash: echo: write error: Invalid argument
<Keybuk> 071b/3202
<jdong> oh
<Keybuk> uh
<Keybuk> 071b 3203
<Keybuk> sorry
<Keybuk> " " not "/" or ":" :p
<jdong> yay, kernel oops!
<BenC> sweet
<jdong> [17202142.412000]  BUG: unable to handle kernel paging request at virtual address 773c83a8
<jdong> whoo!
<BenC> don't report it, I'll reject it and assign it to elmo
<jdong> ha!
<jdong> "kernel oops when forcing a device to bind to usb-storage" :D
<Keybuk> Rejected: DDTT
<BenC> technically, I think it is a bug, but it may be unavoidable
<jdong> lol
<jdong> I bet it's not a standard usb-storage device
<jdong> oh well, time to get the firmware from their FTP server then
<jdong> at a whopping 0.2KB/s
<jdong> btw, related note...
<jdong> is there any way in software to force an unbound USB port to pump out more current than 100mA?
<jdong> Rockbox/iPod just leeches from the USB voltage pins without being a device
<jdong> so it can only get 100mA of current
<jdong> which needless to say isn't even enough to power the hard drive :D
<iwj> Keybuk, cjwatson: Am I to take it that there is no meeting later either ?  There didn't seem to be one at 1600 and I still haven't seen any announcement anywhere.
<Keybuk> iwj: distro-team
<Keybuk> (no meeting this week)
<iwj> Hmm, when was that mail sent ?
<Riddell> cjwatson: some fixes for KDE ubiquity http://kubuntu.org/~jriddell/tmp/ubiquity.diff
<Keybuk> ~1400
<iwj> It's possible that I mistook it for spam.  I had many thousands ...
<Keybuk> there seemed little point having a meeting since the general paste would be "DONE: Holiday" and we're speaking to everyone individually anyway
<iwj> Right, that's fair enough.  I just didn't want to be AWOL :-).
<iwj> Any time we can do without those meetings I'm in favour.
<Riddell> cjwatson: laying out the advanced partitioner nicer, need to translate later for the URL label, couple of variable names corrected, layout fixes to last page
<Riddell> cjwatson: let me know if I'm ok to commit
<iwj> Ooops.  SAUCE is upset with fiordland.
<vdepizzol> http://br.archive.ubuntu.com mirror seems not working correcly
<vdepizzol> a lot of package are corrupted
<mdke> vdepizzol: you can report it to mirrors@ubuntu.com
* iwj fixes mail again.  *sigh*
<iwj> Ohhhh, in _this_ package I'm supposed to run automake by hand.  I'm a fool.
<lifeless> morning
<Nafallo> lifeless: evening :-)
<doko> keescook: I updated the pie-support patch for gdb-6.6, seeing about 50 more test failures, however I do see these with gdb-6.5 as well ...
<keescook> doko: I saw you did the update, thanks.  do mean the same tests failed between 6.5 and 6.6?
<keescook> When looking at the tests from the pie update I did, it was hard to compare due to all the broken tests from the earlier lack of gnuhash support.
<doko> keescook: I just checked the number of failures and compared the build log.
<doko> gnuhash support should be fixed now upstream
<keescook> right, I meant, when I tried to compare the edgy builds to the _good_ feisty builds, it was about the same.
<keescook> did you see more failures building 6.6-0ubuntu1 than were in 6.5.dfsg-2ubuntu3 ?
<doko> no
<lifeless> are there any tools for determining memory use of a program effectively ?
<neuralis> lifeless: define 'effectively'
<doko> but with 6.6 without the pie patches, I only had 50 failures, 6.5 had at least 100
<jdong> lifeless: oh god.... there's a kernel patch that does a better job of comparing memory usage
<jdong> it was used in that kde vs gnome vs xfce vs fluxbox memory usage comparison blogpost
<neuralis> lifeless: depending on what you're after, take a look at exmap (kernel module)
<jdong> yes, exmap, that's the name
<lifeless> neuralis: able to run around the program (to get short lived programs), and return ... lets see
<jdong> but it seems like gauging memory usage is always a really touchy subject :)
<lifeless> oh it is
<keescook> doko: ah, I see what you mean, the pie support may be breaking stuff.  Yeah, that's what I meant early.  I couldn't compare non-pie vs pie on feisty because the feisty gdb didn't work at all due to the gnuhash stuff.
<lifeless> but the folk here have spent considerable time on it
<lifeless> ;)
<neuralis> lifeless: alternatively, there's a visually unappealing python app that parses smaps from /proc/ to monitor memory use that a SoC student wrote for olpc
<neuralis> lifeless: http://dev.laptop.org/git.do?p=projects/soc-memphis
<hunger> neuralis: Would be nice to have in feisty:-)
<somerville32> I'd like to propose demoting xchat-gnome and promoting xchat back to main because I'd like to promote an irc client (and xchat > xchat-gnome now that the usability issues have been resolved) to the xubuntu-desktop seeds
<neuralis> hunger: well, it'd be useful if someone packaged it, yes. i don't think he knows debian packaging.
<cassidy> somerville32: what's your problem with xchat-gnome ?
<jdong> somerville32: first make xchat use libnotify like xchat-gnome does, and I'll comply too :D
<mdke> somerville32: can't you have both in main?
<somerville32> mdke: xchat was dropped because xchat-gnome was promoted but I don't see why not
<somerville32> Crimsun said it would likely require the coordination of the promotion of xchat and the demotion of xchat-gnome to have the MIR approved for xchat
<cassidy> xchat-gnome is a better choice for most users
<Amaranth> woo xchat-gnome :)
<mdke> most Gnome users, presumably
<somerville32> xchat-gnome pulls in gnome libs
* Nafallo hugs his xchat
<somerville32> Obviously that would be unacceptable in Xubuntu
<srbaker> hey, anyone here getting impressive battery life with thinkpads?
<srbaker> like, 6hrs +?
<somerville32> Do you think it would be possible for them both to be in main?
<jdong> srbaker: I have a dell P3 with dual new batteries getting 8hrs or so on average, 6 hrs when compiling
<lifeless> cjwatson: around ?
<lifeless> or for the floor: when two packages [e.g. binutils and binutils-multiarch]  have the same file, should both packages know about the diversion, or is it sufficient for only one to know. If only one needs to know, what about when there is no unpacking order guaranteed, do both need to know then ?
<elmo> lifeless: it's sufficent for one to know
<elmo> unpacking order doesn't matter
<elmo> if b-m is unpacked first, it'll still (pre-emptively) register the diversions.  if b is unpacked first, it'll just work
<elmo> at least, that's how I understand it to work based on observation over the years, I've not actually read the code
<lifeless> elmo: ok, sweet. thanks. that means I can check reflexively in the analysis
<Keybuk> hmm
<Keybuk> how do I make the X-Chat notification icon only visible when there's a new message?
<Nafallo> Keybuk: make a patch I would guess :-P
<Keybuk> Nafallo: heh
<Keybuk> I've had my fill of contributing patches to X-Chat
<Nafallo> hmm. it doesn't blink :-P
<Nafallo> either...
<dthacker> hello, a few members of our LoCo team are going to do some Feisty testing tonight using the wiki testing procedures.  Is there any value in testing the latest daily build, or should we just work with the 20061025(.1) builds?
<hunger> dthacker: I would personaly not use daily since the language support packages do not work for me (OOo seems to have some broken depends).
<hunger> dthacker: But I am just a user. Let's see whether you get some feedback from one of the devs.
<mdke> dthacker: the sort of people who might be able to answer your question are sfllaw, Mithrandir, cjwatson (just hilighting them in case they are around)
<dthacker> mdke: tnx.  I'll be here for another hour or so.   
<dthacker> hunger: it's just for testing.  We're supposed to find bugs. :)
<sfllaw> dthacker: Reporting the latest builds are probably best.
<sfllaw> You'll catch a lot of early breakage that way.
<mdke> if you're looking for installer bugs, surely the latest build
<sfllaw> Of course, you aren't putting this on production systems!
<sfllaw> :)
<hunger> dthacker: Well, it is hard to find bugs if the stuff does not install properly:-|
<dthacker> sfllaw: no production machines.  should we add results to the matrix here?https://wiki.ubuntu.com/Testing/Current
<sfllaw> dthacker: That would be a good place.
<sfllaw> dthacker: Also, file bugs for the faults you find.
<dthacker> can do.  Thank you for helping us. 
<sfllaw> No no, thank you!
<sfllaw> Without you guys, we'd be nothing.
<mdke> hugs all round
<dthacker> yay hugs!
* sfllaw hugs mdke and dthacker.
* dthacker hugs sfllaw and mdke
* mdke hugs back
<sistpoty> did dapper have /var/run as tmpfs already, or was this introduced in edgy?
<sfllaw> sistpoty: I'm pretty sure it was a tmpfs, but I can go back and look.
<sfllaw> sistpoty: Is this important?
<lifeless> the universe will end
<sistpoty> sfllaw: for a universe sru request
<lifeless> sfllaw: http://people.ubuntu.com/~robertc/possible-conflicts.txt
<sfllaw> sistpoty: Lemme fire it up.
<sistpoty> thx
<sfllaw> lifeless: Urgh.
<sfllaw> lifeless: (That is the sound of an aneurism.)
<lifeless> sfllaw: packaging defects
<sfllaw> This is cross-package?
<lifeless> yah
<sfllaw> Ah, that's why lintian/linda didn't catch them.
<lifeless> yah
<Mithrandir> Riddell: no, sorry.
<lifeless> sfllaw: it takes 7 minutes to do an analysis run currently :).
<lifeless> sfllaw: I'm happy with that:)
<twb> Mithrandir: nag, nag
<lifeless> random question, whats the smallest package anyone has seen that has diversions ?
<doko> lifeless: dash?
<lifeless> doko: oh, in preinst I mean
<lifeless> where the package cant unpack unless it diverts
<lifeless> slocate will do
<lifeless> thanks :)
<doko> binutils is another prominent one, creating diversions in a loop
<lifeless> yah, I cant parse that
<lifeless> in the not-worth-it-yet-bin
<Mithrandir> twb: try nagging me again in nine-ten hours?
<twb> Mithrandir: no worries
<Mithrandir> thanks
#ubuntu-devel 2007-01-05
<hunger> during early boot (feisty) I get messages about PHYSDEV getting removed in future kernels. Any idea what might case that? Looks like madwifi, but that is not part of my initrd!
<hunger> What can I do to get enough data for a decent bugreport?
<bddebian> Heya
<evand> Anyone know who I'd have to talk to about getting the address my @ubuntu.com forward points to changed?
<nekohayo> is there a channel for ubuntu's security updates?
<Nafallo> evand: change the email on launchpad.
<nekohayo> I think the 4 dbus updates for edgy break gnome's settings daemon
<Nafallo> nekohayo: don't think so. this one maybe? :-)
<crimsun> nekohayo: the security team is active in this channel during EU business hours (and sometimes other)
<nekohayo> hmm so this place is correct for checking with them if those updates break stuff indeed?
<evand> Nafallo, I did, it still goes to the original email account I set my launchpad account up with.
<Nafallo> evand: ask #launchpad if they can trigger an update or something :-)
<Nafallo> evand: IIRC a cronjob does that :-P
<evand> Nafallo, will do, thanks
<Nafallo> np
<somerville32> nekohayo, Please file a bug
<lifeless> I'm off for the weekend, have fun!
* somerville32 waves.
<fabbione> morning
<evand> morning
<somerville32> @now atlantic
<Ubugtu> Current time in Canada/Atlantic: January 05 2007, 02:43:56 - Next meeting: LoCo Team in 4 days
<somerville32> Morning :)
<Amaranth> sorry, setting something up
<somerville32> It's ok Amaranth
<somerville32> I ignored you a long time ago
* somerville32 grins.
<Amaranth> heh
* somerville32 hugs Amaranth.
<Amaranth> ironically enough i was setting up an irc proxy so i don't disconnect anymore :)
<Amaranth> damn server is RHEL3 though
<Amaranth> couldn't use ssl, glib, etc
<Fujitsu> Why do you have a RHEL3 server!?
<Fujitsu> (although I do administer one, the company that makes the hospital-management software mandates it :-/)
<Amaranth> Fujitsu: not mine :)
<Fujitsu> Good :)
* somerville32 mandates that Fujitsu rub his tummy and pat his head at the same time.
<Fujitsu> :O
* Mithrandir bounces around Hobbsee 
* Hobbsee huggles Mithrandir 
<Hobbsee> heya :)
<Hobbsee> Mithrandir: why are you bouncing?
<Mithrandir> Hobbsee: general happiness.
<Hobbsee> Mithrandir: :D
<Mithrandir> also, simira and I have been married for five months today, which is nice.
<Hobbsee> yay :D
* Hobbsee thought it was longer
<Mithrandir> _and_ I managed to get ssh auth with my smart card working yesterday.
<Lathiat> oh nice
<Lathiat> i've got a smartcard reader in my laptop, wonder if theres a dirver for it
<Hobbsee> :)
<Mithrandir> now I just need to get a pile of smart card readers so I don't have to lug that or my laptop around.
<Mithrandir> doko: did you see my initial analysis of the ooo-l10n uninstallability problem?
<doko> Mithrandir: fixed in 2.1-1ubuntu4
<Mithrandir> doko: great.  Now I just wonder why ooo-help and ooo-l10n still shows up on on p.u.c/~cjwatson/testing/feisty_probs.html ..
<doko> strange
<Mithrandir> fabbione: you're aware that your glibc upload FTBFS?
<fabbione> Mithrandir: yes. we are discussing it in -toolchain
<pitti> Good morning
<mvo> hey pitti!
* pitti hugs mvo
<fabbione> hi pitti
<pitti> O sole mio, Padre!
<fabbione> ahahha
<fabbione> Javul her general
<psusi> hey fabio, martin
<Fujitsu> Has there been any standard set for security updates to the same version of a package in multiple releases?
<Fujitsu> (ie. what versioning should I use?)
<fabbione> fabbione@gordian:~$ gthumb
<fabbione> end from FAM server connection
<fabbione> end from FAM server connection
<fabbione> is inotify broken again?
<Amaranth> i hope not, gnome without inotify eats CPU like crazy
<fabbione> Amaranth: it looks like is broken somehow..
<fabbione> at least 
<Amaranth> seems to work here but now i'm afraid to reboot
<Amaranth> i'm using the -3 kernel
<Mithrandir> doko: any idea why ooo ftbfs on amd64?  http://librarian.launchpad.net/5511527/buildlog_ubuntu-feisty-amd64.openoffice.org_2.1-1ubuntu1_FAILEDTOBUILD.txt.gz
<doko> ohh crap, no idea ... will have to look
<Mithrandir> thanks
<Mithrandir> that should fix the uninstallability problems as well, it's amd64 only.
<Hobbsee> Mithrandir: can you tell me if my upload of texfam worked?
<Adri2000> I guess this package https://launchpad.net/ubuntu/+source/dvd-slideshow comes from debian multimedia, right?
<Mithrandir> Hobbsee: hmm, can't see it.  When did you upload it?
<Hobbsee> Mithrandir: abotu 5 min ago, then 2 min..
<Mithrandir> it's there at least.
<Hobbsee> Mithrandir: oh wait, reject it anyway please
* Hobbsee is an idiot
* Hobbsee tells self to PUT *DOWN* the crack pipe...
<Mithrandir> I'm unsure how I reject stuff out of incoming.. let's see.
* mneptok extends a palm towards Hobbsee 
<doko> Mithrandir: do you see a binutils upload from today?
<Hobbsee> Mithrandir: or i'll reupload with the same version, presumably
<Mithrandir> Hobbsee: reupload with a higher version rather.  It's not like we're running out of integers just yet.
<Mithrandir> doko: yes.
<Hobbsee> hehe
<Hobbsee> OK
<Fujitsu> doko: (re. azureus) I thought my meaning of `fixes' in the changelog was fairly clear, but apparently not. It was referring to jdong's fixes; he hadn't incremented the upstream version number.
<doko> Fujitsu: ok
<pitti> Fujitsu: yes, there is
<Hobbsee> Mithrandir: done :)
<pitti> Fujitsu: see https://wiki.ubuntu.com/SecurityUpdateProcedures
* Hobbsee hands the crack pipe to mneptok 
* pitti reboots to 2.6.20, brb
<Adri2000> can I request a sync from debian multimedia?
<Hobbsee> Adri2000: i believe so
<Hobbsee> Mithrandir: do you know if accepted mails are occuring, or has soyuz broke with that too?
<Mithrandir> Hobbsee: afaik, they work.
<Fujitsu> Hobbsee, I got one a couple of hours back.
<Mithrandir> Adri2000: you can request a sync from anything with a Sources file.
<Hobbsee> hrm.  i appear to have missed 2.
<Adri2000> ok
<doko> Mithrandir: is main already frozen, or is mail to -changes not working?
<Mithrandir> doko: we're not frozen, so something funky is up, I think.
<fabbione> oh great
<Fujitsu> Has soyuz done its nice little hangy-thing again?
<fabbione> that's exactly what i need today
<fabbione> extra fuzz 
<Mithrandir> Fujitsu: looks like there's something weird on drescher, I've asked a sysadmin to investigate.
<Hobbsee> Mithrandir: weird, OK.  either my filter is filtering them (veyr unlikely, it hasnt before), or i'm not getting sent them
<Fujitsu> I wonder if it's the same issue as last time... (ie. all uploads hanging on an INSERT)
<Mithrandir> Hobbsee: we have hanging sendmail processes from the last hour or so of uploads, so that might be why.
<Fujitsu> Hobbsee, we've just established that soyuz is stuffed, I believe.
<Fujitsu> Mithrandir: sounds like fun.
<Hobbsee> Mithrandir: right.
<Hobbsee> Fujitsu: haha, we knew that.  
<Mithrandir> so, "we're working on it", sorry I don't know more than that so I can't tell you more than that either. :-P
<Hobbsee> hehe
<Hobbsee> Mithrandir: but you're supposed to know everything!
* mneptok flips a penny at Hobbsee 
<mneptok> catch!
* Hobbsee runs away from it
<davmor2> query on gossip-telephany:  I want to be able to use gossip in place of gaim but I can't use jabber to log onto google talk like I can with gaim should I report it as a bug or am I just not inputting the log in data correctly?
<Hobbsee> mneptok: i dont deal in pennies :P
<Robot101> davmor2: possibly not inputting the data correctly
<Robot101> davmor2: let me read off how my settings look... server talk.google.com, port 5223, use encryption?
<Hobbsee> Mithrandir: woot!  got the accepted mail, just late
<mneptok> Hobbsee: yeah, not anymore you don't ;)
<Hobbsee> mneptok: we dont have pennies here anyway :P
<Fujitsu> Why did I get 7 of the same apport acceptance mail>?
<Fujitsu> Ooh, and they're still coming.
<Hobbsee> there was stuff at the bottom
<Fujitsu> And yet more...
<Fujitsu> Hobbsee: Nice changelog entry for texfam 1.2.1-9ubuntu2 :P
<Hobbsee> Fujitsu: haha, yeah
<Seveas> pitti, having fun uploading apport? :)
<pitti> Seveas: much so :)
<pitti> Seveas: oh, argh, I see what you mean; /me curses at Soyuz
<Seveas> hehe
<Fujitsu> I think I managed to get 15 of them...
<pitti> that's what I got, too
<Fujitsu> 17, in fact.
* Fujitsu applauds Soyuz.
<Seveas> 17 here as well
<Mithrandir> pitti: apport is only 17/21 entries in the accepted queue. :-P
<Fujitsu> The 17 are spread over ~4 minutes as well, which is a little odd.
<Mithrandir> no, they're spread over more than an hour
<pitti> I swear I only uploaded it exactly once
<Seveas> lies :)
<Fujitsu> Mithrandir, the emails are only over 4 minutes.
<cjwatson> Riddell: please go ahead and commit, but preferably one commit per change rather than one commit for the several unrelated changes in that diff
<cjwatson> Riddell: unfortunately I made several UI changes to the advanced dialog this morning before seeing your patch, and I have no idea how to resolve the conflict
<cjwatson> Riddell: I guess you need to throw away your changes and do whatever you did to it again
<cjwatson> Riddell: I wish I knew how to stop Designer creating the wrong kind of layout widgets
<cjwatson> Riddell: in general I'm happy with you committing directly to ubiquity trunk on bazaar.launchpad.net, or creating a branch there if the changes are large; much easier than passing diffs around
<Adri2000> archive admins: libept 0.4.7ubuntu2 is built since wednesday but there is still no .debs at http://archive.ubuntu.com/ubuntu/pool/universe/libe/libept/
<Adri2000> https://launchpad.net/ubuntu/+source/libept/0.4.7ubuntu2
<Mithrandir> Adri2000: that is correct, it's in NEW.
<Adri2000> ahhh, ok
<Mithrandir> accepted now
<Adri2000> thanks
<bSON> hi
<bSON> i have problems adding any other items than Preferences and Administration to the System menu; this may be needed if users want to havea link the new control center shell in gnome 2.17 there. the source of the problem probably is a patch in Ubuntu, "05_submenus.patch", whose purpose is to swap the Preferences and the Adminstration menus. could this source patch be replaced by a patch for settings.menu? the same effect can easily be acc
<Chipzz> bSON: your line was truncated
<Chipzz>               a patch for settings.menu? the same effect can easily be acc
<bSON> Chippz: ... accomplished with the <Layout> tag of the freedesktop menu specification, which is supported by gnome
<cjwatson> Mithrandir: any progress with bug 73955?
<Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [High,Confirmed]  https://launchpad.net/bugs/73955
<bSON> Chippz: is there anybody I can ask regarding this issue?
<bSON> Chipzz i meant..
<cjwatson> bSON: seb128, when he gets back from holiday next week
<bSON> cjwatson: ok, thanks
<Mithrandir> cjwatson: gnr, I forgot to look at it today, sorry. :-/
<Mithrandir> cjwatson: how is ubiquity/d-i looking for herd 2?
<cjwatson> Mithrandir: I don't know of major issues other than 73955, although I haven't looked much at d-i
<Mithrandir> cjwatson: ok, sounds good.
<fabbione> Mithrandir: so next week is Hurd 2
<fabbione> Mithrandir: we will start testing the new link to certification...
* Keybuk wonders whether you can return a va_args from a function...
<Mithrandir> you shouldn't be able to.
<Riddell> cjwatson: tidied up advanced dialogue committed
<cjwatson> Riddell: ta
<ogra> do we plan to get mbr to main or do we drop lilo to universe ? 
<ogra> doko, whats up with schooltool and schoolbell, do you think just updating the deps of python2.4-schoolbell to zope3 (>= 3.3) is enough ?
<ogra> (its currently zope3 (<= 3.3))
<doko> ogra: no, requires port to zope3.3, not yet done by upstream
<ogra> hmm, likely to hapen before hurd2 ?
<ogra> s/hurd/herd/
<doko> we ship fur hurd? ;-P
<ogra> heh :)
<ogra> for the herds 
<doko> unlikely for feisty, maybe ask upstream
<ogra> ouch 
<ogra> that means we cant ship it at all ? do we have a fallback ? 
<ogra> (older zope etc)
<TeknoMatik> Hi all, i am beginer
<jdong> doko: regarding Azureus repack, if you md5sum the two orig.tar.gz's you'll see that quite some PNG's are corrupt in the original packaging
<jdong> doko: that was the cause for the tray icon not showing up
<doko> jdong: yes, seen that
<TeknoMatik> Please tell me, what i must know for join in development community?
<jdong> ok, cool :)
<doko> ogra: include zope3.2 into the schoolbell package and ship that one?
<ogra> doko, the whole of 3.2 ? that sounds evil ... and lie a lot of work
<ogra> *like
<TeknoMatik>  Please tell me, what i must know for join in development community?
<ogra> TeknoMatik, go to #ubuntu-motu 
<TeknoMatik> ok, thank's
<davmor2> sorry for lack of response got called away it was the 5223 that was wrong and why I couldn't log on thank to who ever pointed it out.
<davmor2> to gmail with gossip
<elmo> so, uhm, if you have to take stuff out of /etc/n/i to get n-m to love you, how is one meant to configure your network when X is broken, JOOI?
<azeem> elmo: you edit /etc/n/i back :)
<elmo> well, that's what I did, but seriously?
<azeem> AFAIK, nobody's implemented CLI support for n-m yet
<Nafallo> elmo: auto + dhcp works aswell :-)
<Nafallo> makes n-m happy etc... ;-)
<Hobbsee> Nafallo: as long as /e/n/i is there...
<Nafallo> Hobbsee: ehrm... is there cases when it isn't?
<Hobbsee> Nafallo: see elmo's first line, with it all commented out
<Hobbsee> that being said, apparently NM loves me even with the lines in /e/n/i
<elmo> Nafallo: I've never seen n-m work when the interface was in /etc/n/i and been told several times that that's how you get n-m to 'own' the interface *shrug*
<Hobbsee> elmo: depends what phase the moon is in, and on wind direction, i'm afraid...
<Nafallo> lol
<Nafallo> n-m is still not up for the job if you ask me :-)
<Hobbsee> on that note, it's bedtime - night all!
<Nafallo> Hobbsee: gnight :-)
<Hobbsee> bah.  it's better than running a manual wpasupplicant :P
<Nafallo> Hobbsee: ifup ftw :-)
<Nafallo> and $essid.sh ;-)
<ogra> hmm, why is ntp uninstallable ... i dont see a reason ...
<zul> hi
<ogra> fabbione, is it ok with you to drop ntp-server from ship/server-ship ? seems ntp now replaces it ... (at least according to the deps)
<ogra> oh ntp-simple as well indeed
<Nafallo> ogra: right. better to have real packages instead of transitional things :-).
<ogra> well, there seems to be no transitional thing ... ntp just replaces everything ... but the seeds still want the old package names ...
<Nafallo> oh. right.
<Nafallo> ntp-simple is transitional though
<ogra> well, why are we using bzr for the seeds if not for rollbackability ... (nice word :) )
* ogra changes the seeds 
<Nafallo> hehe. indeed :-)
<itsme> hi
<bddebian> Heya
<jdong> hey bddebian
<bddebian> Hi jdong
<Nafallo> hi bddebian :-)
<bddebian> Gah :)
<Nafallo> hehe
<Nafallo> redundant "hi" ftw! :-)
<bddebian> heh
<jdong> is there a way to script a hi to everyone in a channel?
<jdong> (kidding, please don't empower me with that kind of knowledge)
<Nafallo> jdong: lol
* Nafallo wonders if someone want gajim backported :-P
<jdong> Nafallo: out of curiousity, can we import a newer x264 snapshot than debian-marillat?
<jdong> I'm interested in 20061216's threading improvements
<jdong> requires a minor sed to the few packages that build against x264 though
<jdong> Nafallo: and I'm looking at gajim right now, poke me in a day if I get forgetful
<Nafallo> jdong: nice. thanks :-)
<Nafallo> jdong: I apt-get source x264 :-)
<jdong> heh :)
<jdong> Nafallo: you're motu-media, right?
<Nafallo> yepp. but I haven't touched this one before :-)
<jdong> ah, ok
<jdong> if I file a launchpad bug asking for a newer x264 snapshot than marillat, detailing the patch(es) necessary to build ffmpeg and friends... what's the chance of acceptance?
<Nafallo> ah. noone has :-P
<Nafallo> I will atleast look at it :-)
<jdong> it seems like we've always just followed marillat, I'm not sure if it's taboo to be newer than it :D
* jdong checks marillat again for newer snapshots
<jdong> nope, still on 1210 :(
<Nafallo> we have 0928 :-P
<jdong> Nafallo: I KNOW :)
<Nafallo> jdong: maybe it's easier to have him doing the work ;-)
<jdong> Nafallo: I shall prepare some source packages
<Nafallo> nice :-)
<jdong> I notice that when all that's needed is a dput, it tends to happen better :)
<Nafallo> indeed :-)
<Nafallo> and a review and build... ;-)
<jdong> ok, heading out to restock my fridge now, will work on x264 goodness afterwards
<Nafallo> nice :-)
<Riddell> cjwatson: are you able to look into what's happened to digikamimageplugins?  uploads for it disappear
<cjwatson> Riddell: roughly when was the last upload?
<Riddell> cjwatson: about christmas
<cjwatson> Riddell: http://librarian.launchpad.net/5548495/A5fthh1B20Azq01vNRec2PkDRqa.txt - it's not entirely clear what happened, but I think it's transient so I'll reprocess it
<cjwatson> Riddell: ok, that worked
<Riddell> cjwatson: great, thanks
<Riddell> cjwatson: fancy doing some promotion/demotion too?
<Riddell> cjwatson: libopenobex1.0 and binaries needs demoted to universe with libopenobex and binaries promoted
<ogra> mbr too so lilo is installable again ... i did the MIR for it already ....
<cjwatson> Riddell: libopenobex1.0 isn't on the schedule for demotion; can you hunt down what's still using it?
<Riddell> cjwatson: kdebluetooth and libbtctl will still be using it, until their version with the new libopenobex are compiled
<cjwatson> ogra: not until the MIR's been reviewed and approved
<Riddell> cjwatson: so just do the promotion and wait for the demotion if that's easier
<ogra> well, it has to go in anyway ... but right, ets wait for the bureocracy to be done :)
<ogra> *lets
<cjwatson> Riddell: done
<Riddell> ogra: MIRs seems like a perfectly worthwhile beurocracy
<Riddell> ogra: but if you're poking pitti to do that MIR, poke him to do gsmlib for me too :)
<cjwatson> we can set ogra and jbailey up in a deathmatch if everyone really wants :)
<Riddell> thanks cjwatson 
<cjwatson> it's for the support team's sanity as much as anything else
<ogra> Riddell, well, not for packages where debian introduced dependencies that are forced upon us anyway ... we could save te bytes to write one in that case imho
<cjwatson> I disagree
<Nafallo> cjwatson: sounds fun :-). might be a revenuestream as well as any ;-)
<cjwatson> in some cases we would want to revert the new dependency instead
<cjwatson> that's part of what the MIR review process is for
<ogra> cjwatson, well, indeed ... but there are some cases where we couldnt do that without breaking everything ... indeed you cant predict which packages that applies to ...
<cjwatson> ogra: that's what the review process is for
<ogra> yeah, understood
<cjwatson> and is why I said "in some cases". We aren't automatons
<Riddell> cjwatson: could you also promote libept: libept-dev, it's the new name for the new version of libapt-front
<ogra> if we were we would be called launchpad ;)
<cjwatson> Riddell: is it descended from the same code, or a rewrite?
<Riddell> cjwatson: it's the same coade
<Riddell> code
<cjwatson> Riddell: ok, promoted
<Riddell> thanks cjwatson 
<keescook> doko: looks like we've got some OOo security backporting to do for the WMF vuln
<doko> keescook: yeah ... please forward me your information, I think I have a patch for one of those
<keescook> doko: all I've got so far are the posts to full-disclosure; I haven't gone digging yet.
<doko> but I won't mind if you do want to get familiar with OOo =)
* keescook just recovered from the firefox 2.0.0.1 "familiarity"
<Nafallo> haha
<cjwatson> In Soviet Russia, Firefox gets familiar with YOU!
<keescook> hehehe
<Nafallo> :-=
<Nafallo> :-)
<bluefoxicy> FUCK.
<bluefoxicy> kernel panic.
<bluefoxicy> and gnome decides that anything stored in gconf2 is suddenly nuked.
<bluefoxicy> this is worse than the windows registry, this is like the fifth time this has happened.
<zul> language
* bluefoxicy rm -rf /home/zul/.gconf*
<LaserJock> bluefoxicy: still better to say to yourself then on IRC :-)
<bluefoxicy> LaserJock:  if I say it on IRC maybe someone will explain to me why it happens :|
<Nafallo> bluefoxicy: try #ubuntu-desktop when people are back from holidays in that case ;-)
<bluefoxicy> argh
<bluefoxicy> dpkg --configure -a causes it
<bluefoxicy> while it's updating tcl or tk or something.
<bluefoxicy> when it gets there the machine just dies.  :|
<bluefoxicy> part of my panel gets stretched across my entire screen, and then it just goes limp.  magic sysrq does nothing
<bluefoxicy> xchat-gnome prefs, gone.  Rhythmbox prefs, gone (playlists in tact, they're in another directory).
<LaserJock> bluefoxicy: this is on Feisty?
<bluefoxicy> panel applets, all gone
<bluefoxicy> yes.  It's happened on dapper too, but very rarely
<bluefoxicy> and not triggered the same way
<LaserJock> odd, good reason to have backups of ~/ :/
<bluefoxicy> dpkg dying trying to configure... whatever's in the queue right now (it died while synaptic was running the first time), on 2.6.20 (latest) generic or lowlatency (tried both)
<bluefoxicy> dapper/edgy had issues where I crashed it other ways and once or twice I lost anything stored in gconf2
<Nafallo> bluefoxicy: /+addbug :-)
<bluefoxicy> Nafallo:  /+addpissedoff is more like it :|  this is hella annoying.
<bluefoxicy> it's one thing to lose config for your panel
<bluefoxicy> but for every gnome-integrated application?
<Nafallo> bluefoxicy: hmm, /+filebug then? :-)
<bluefoxicy> heh
<ernstp> I searched for debian on ubuntu wiki and couldn't find anything about how to suggest an import from debian to ubuntu
<ernstp> Should be something with motu perhaps?
<bluefoxicy> filed.
<cjwatson> ernstp: http://wiki.ubuntu.com/DeveloperResources#syncs
<cjwatson> ernstp: if you aren't in the relevant development team you should ask somebody who is to help, so yes #ubuntu-motu
<cjwatson> in general we only accept sync requests from people who would ordinarily have been able to make the same upload by handd
<cjwatson> hand
<cjwatson> Mithrandir: please give back libcairo after this publisher run
<Mithrandir> cjwatson: ack.
<cjwatson> unfortunate sync timing, that; it broke the ubiquity build as well
<cjwatson> (sync> libcairo)
<LaserJock> cjwatson: I'm looking into ernstp's sync requests
<cjwatson> thanks
<LaserJock> cjwatson: one of the packages, linuxdcpp, seems to have been in Debian for over a year. He thought that it was perhaps in Dapper but removed
<LaserJock> cjwatson: is there a way you can check if it *was* in Ubuntu at some point?
<cypher1> LaserJock, will packages.ubuntu.com help
<LaserJock> cypher1: indeed it is
<cypher1> LaserJock, :)
<LaserJock> well, stink. packages.ubuntu.com has it in dapper, edgy, and fiesty
<LaserJock> ok, well that looks like a bad bug
<LaserJock> it's in Ubuntu
<ernstp> LaserJock: it looks like it's in but it's not?
<ogra> its ftbfs apparently
<ogra> or waiting for a dep or something ... sources are there but no binary
<ernstp> LaserJock: oh right, it needs a version sync with debian then perhaps?
<ogra> ogra@edubuntu:~$ apt-cache madison linuxdcpp
<ogra>  linuxdcpp | 0.0.1.cvs20061208-1 | http://archive.ubuntu.com feisty/universe Sources
<ogra> whats in debian ... cvs2006120 doesnt seem to old
<Nafallo> oh
<Nafallo> I can confirm
<ogra> err cvs20061208
<Nafallo> the damn thing uses scones :-)
<ernstp> Checking for pkg-config... no
<ernstp> 	pkg-config not found.
<ernstp> so it's deps are wrong..
<LaserJock> ernstp: can you update the bug report with what you've found?
<ernstp> LaserJock: done
<LaserJock> ernstp: thanks
<kylem> mmm scones.
<doko> Mithrandir: please could you requeue openoffice.org on amd64?
<Nafallo> Mithrandir: and please retry linuxdcpp. built fine in my pbuilder just now.
<Nafallo> :-)
<hunger> Any ETA for the restricted modules matching the new linux-image?
<LaserJock> hehe, "when it builds" maybe?
<gnomefreak> LaserJock: l-r-m-generic is built just waiting for l-r-m-kernel i bellive along with the nvidia package for that l-r-m and stuff like that
<LaserJock> mhm
* gnomefreak thinks that should have been for hunger not LaserJock  :(
<LaserJock> gnomefreak: np ;-)
<cjwatson> hunger: I accepted them three quarters of an hour or so before you asked that
<cjwatson> hunger: so they should be visible now
<KinGBin> slomo: do you have a sec to help me compile mpeg4ip?
<mdke> cjwatson: can you have a look at my sru bug next week some time maybe? I'll dig out the bug number
<cjwatson> mdke: yes
<cjwatson> can't now, though
<mdke> well, it's 10 o clock on a friday night
<mdke> I wouldn't have expected now
<mdke> cjwatson: it's bug 74555, for your reference
<Ubugtu> Malone bug 74555 in ubuntu-docs "Stable release update" [Medium,Confirmed]  https://launchpad.net/bugs/74555
<cjwatson> mdke: please just subscribe ubuntu-sru and assign to nobody - if you assign to ubuntu-sru it doesn't show up in +subscribedbugs for us
<cjwatson> (or at least it didn't use to - which is/was a Malone bug I guess)
<cjwatson> shouldn't be assigned to us anyway since we're just approving not implementing
<mdke> cjwatson: I guess it would be in +assignedbugs :) My bad, I must have misread the page
<cjwatson> yeah, it would be in +assignedbugs but I don't check that
<cjwatson> well, not usually
<mdke> assigned bugs is the default on the bugs page 
<mdke> at least for people
<mdke> maybe it's different for groups
* mdke changes the bug, anyhow
<cjwatson> might be the default but it's not useful for ubuntu-sru generally and so is not my finger macro
<cjwatson> I don't navigate to that page, I type in the url
<cjwatson> same as for ubuntu-archive
<mdke> I didn't mean to challenge what you said, I was going to change the bug immediately
* cjwatson nods
<cjwatson> just explaining why the default on the bugs page isn't relevant :)
<cjwatson> anyway, bedtime
<mdke> good night
<Nafallo> !seen jono
<Nafallo> hmm
<KinGBin> I know this isn't the right channel so dont' blast me, but... I'm trying to compile faac without the mp4 support, I can't find any switches to use to have it compile without mp4 support, anybody know? I'm using the latest faac pulled from the repository
<hunger> cjwatson: Not visible yet:-(
<LaserJock> hunger: I got it
<Lure> hunger: maybe your mirror is not up-to-date yet - I got it too
<hunger> Ah... now it is visible for me as well!
<_ion> It would be nice if mirrors communicated between each other using a P2P protocol, using which new stuff would be *pushed* to mirrors. Mirrors (all of them) would have the new stuff almost immediately, and the bandwidth used to synchronize mirrors would be shared evenly between all of them.
<doko> Mithrandir: please requeue OOo on powerpc and sparc as well
<Mithrandir> doko: ooo given-back
<Mithrandir> Nafallo: linuxdcpp given-back
<_ion> "Aha, console-setup was configured". Ctrl-Alt-F1, Alt-F7. I'm getting used to the screen getting corrupted. ;-)
<Nafallo> Mithrandir: thanks mate :-)
<LaserJock> we'll see if that works
<Nafallo> LaserJock: since it worked locally it should. otherwise we can set infinity on it again ;-)
<Mithrandir> cjwatson: libcairo given-back on sparc and ia64; built fine otherwise.
<LaserJock> Nafallo: yeah, I just have my doubts since it was tried at least 2-3 times and failed
<Nafallo> LaserJock: we'll see :-)
<hunger> wsw3ma
<hunger> sorry...  wrong window:-(
<Nafallo> lol
<Nafallo> no shit :-P
<hunger> and "too many fingers on keyboard error".
<_ion> How can there be too many fingers on a keyboard? Your friend is trying to type at the same time?
<hunger> Nah... eagle typing... circling over the keyboard and then suddenly striking.
<mdke> does anyone know if the desktop cd still has WinFOSS on it?
<mdke> I haven't had a windows system for a while
#ubuntu-devel 2007-01-06
<Nafallo> mdke: I think it's added on the rc and final
<mdke> Nafallo: so it is still intended to be present in 7.04?
<mdke> is henrik still the right person to ask about that sort of thing?
<Nafallo> mdke: AFAIK
<Nafallo> on both questions ;-)
<mdke> thanks
<Nafallo> or rather. sabdfl takes that decision, no? :-)
* Nafallo ain't sure
<hunger> What is the status of upstart in feisty? Were there changes compared to edgy yet?
<Nafallo> Keybuk: hilight for hunger ^ :-)
<mdke> hunger: zcat /usr/share/doc/upstart/changelogTABCOMPLETE | less
<crimsun> err, not zless?
* hunger would like to integrate his cryptsetup stuff into it.
* mdke doesn't know about these technical things
<Nafallo> less and make bash handle it :-P
<hunger> mdke: That lists technical glibberish only;-|
<_ion> With zsh, /u/s/d/ups/cha<tab>
<mdke> hunger: it shows changes since the release of Edgy
<Nafallo> LaserJock: FTBFS ;-)
<LaserJock> darn
<Nafallo> LaserJock: I think it's the same error infinity have tried to solve last time I looked at it months ago :-P
<LaserJock> doh
<bddebian> Heya
<jdong> does wodim/cdrkit write DVD ISO's?
<nixternal> jdub: please don't kill me over my latest blog post
<jdub> nixternal: heh, just a kick in the arse for me to blog about why it's there
<nixternal> hehe
<nixternal> i had a good chuckle for sure
<nixternal> jdub: i think that would make a great intro to an "Influential People in Open Source" presentation :)
<jdub> nixternal: published :-)
<nixternal> uh oh :)
<jdub> nixternal: oh, i understand one aspect of your blog entry now
<nixternal> which is?
<jdub> nixternal: those are just del.icio.us formatted link posting entries
<nixternal> ahhh
<fabbione> cjwatson: when you have time i would love if you could take a look at #78161. thanks
<cjwatson> Mithrandir: please give-back ubiquity where it failed
<cjwatson> fabbione: queued up for Monday
<fabbione> cjwatson: thanks a lot.
<cypher1> hi all.. i have a source package which needs a dependency on sysvinit.. is it correct ?
<cypher1> if we put a dependency then people who want to build the source may then have to remove upstart, correct ?
<Mithrandir> cjwatson: given-back
<cjwatson> Mithrandir: thanks
<cjwatson> cypher1: what exactly does it need sysvinit for?
<cjwatson> cypher1: you may find that that build-dependency can be replaced with some other related package
<cypher1> cjwatson, /usr/include/initreq.h
<cypher1> cjwatson, the source package needs that
<cjwatson> cypher1: oh, ugh. Yes, for now it will probably only work with sysvinit then. I suggest you talk with Scott about what would be needed to port that to upstart's interface.
<Fujitsu> What package, cypher1?
<Mithrandir> you could just include that file in your package, though that's evil..
<cjwatson> is it really not possible to use the command-line interfaces?
<cypher1> Fujitsu, genpower
<cypher1> i gotta run.. thanks all.. i wll talk to scott
<sacater> hellos, is there any1 here i can talk to about reccomending a change in the menu
<sacater> change TO the menus
<mdke> sacater: what sort of change is it?
<sacater> well, when ive givin out CD's ive been told that the most annoying thing is when you hover youre mouse over an app in the menu, say gaim, the description covers up the app below it
<sacater> people want to get a description of the app but also be able to see the next in the list
<mdke> ok, it's #ubuntu-desktop for that, or if no one answers, the ubuntu-desktop mailing list
<sacater> ive had 6 complaints about that
<sacater> kk
<sacater> ty
<matteo> hi all
<matteo> i have debian running on my desktop and ubuntu on my laptop, now i want to create a pbuilder in my desktop that makes ubuntu packages, should I just replace mirrors in pbuilderrc before creating the pbuilder chroot?
<jaalto> Is anyone here who has experience in building kernel dependent debian packages
<mucker> hi
<bddebian> Heya
<alex-weej> has anybody ever discussed namespacing package names in Ubuntu?
<alex-weej> e.g. org.gnome.Epiphany
<alex-weej> instead of epiphany-browser
<jelmer> alex-weej: there are sections
<alex-weej> i'm not sure that works as expected
<alex-weej> example
<alex-weej> every time i get a new ubuntu system
<alex-weej> i always install "epiphany" thinking i'm getting the browser
<alex-weej> turns out i get some kind of 2d game
<jelmer> that's more a matter of name clashing
<jelmer> what if the epiphany game would become available for GNOME?
<alex-weej> then it would have its name changed
<alex-weej> there would be more of an issue than its names in an APT repository
<alex-weej> think bugzilla, www, etc. :P
<Mithrandir> alex-weej: so you want to rework the whole naming structure because you install a package with a similar name to the one you want?
<bhale> either you will reinstall very rarely like normal people and not have a problem
<jelmer> It wouldn't necessarily have to live in GNOME CVS
<bhale> or figure it out eventually, and also not have a problem remember 'epiphany-browser'
<bhale> shrug
<jelmer> I guess my point is: it's a bad idea in any case to have the same name for two applications.
<alex-weej> just to make it more consistent
<jelmer> I've been bitten by this particular case myself too
<alex-weej> i dunno :[
<_ion> I don't have a problem with how it works now, but AFAIK gentoo has something like 'games-blah/epiphany' and 'www-browser/epiphany'
<alex-weej> yep
<alex-weej> and if you try "emerge epiphany" it says its ambigious
<alex-weej> ser
<alex-weej> ambiguous
<alex-weej> lol
<jelmer> why not simply rename the existing 'epiphany' package to 'epiphany-game' so that there's epiphany-browser and epiphany-game?
<alex-weej> i thought the namespacing was good for other stuff
<Nafallo> jelmer: yes. and then a transitional package to the next LTS ;-)
<alex-weej> like if you search for gtk you get lots of apps for gtk
<Nafallo> jelmer: in that case I want debian in on that :-)
<alex-weej> but not necessarily what you want
<alex-weej> a search for org.gtk would probably be more useful
<Mithrandir> you are aware of debtags?
<jelmer> Tags are more useful for that
<alex-weej> no
<Nafallo> hej Mithrandir :-)
<jelmer> what if there's a Samba frontend in GTK, what would its namespace be?
<alex-weej> whatever the vendor's namespace is
<Mithrandir> hiya Nafallo 
<alex-weej> org.samba.GtkSambaFrontend
<jelmer> alex-weej: so you'd need to know the vendor in order to install a particular package?
<alex-weej> no, 'cause the string search still works
<alex-weej> samba matches org.myco.MySambaFrontend :P
<jelmer> But "apt-get install gtk-samba" wouldn't, I'd have to do a search first
<Mithrandir> alex-weej: so apt-get install samba wouldn't DTRT any more?
<alex-weej> hmm
<alex-weej> i guess certain very well known packages could have dummy packages that just depend on the FQPN
<alex-weej> :P
<jelmer> debtags is very nice in that you can see for packages that have protocol::smb and ui::interface::gtk
<alex-weej> is there any UI for this in Synaptic?
<alex-weej> i do recall seeing that in Aptitude
<Mithrandir> it's in aptitude and the KDE thingy, but not synaptic, afaik.
<finalbeta> I've created a Java 6 program under ubuntu. Some parts of it feel sluggish, even after much tweaking. Now when I move the app to windows. It's superfast. Seems native. GUI actually builds faster on a 1.8Ghz laptop in windows then running it on a 3Ghz desktop running ubuntu. I notice an amazing windows <> linux difference in speed on dual boot systems. Anyone has any idea what to blame this on? I'm using native look and feel. I know
<finalbeta>  this is not really the place, but where is...
<cat> #java perhaps?
<finalbeta> The say, #ubuntu perhaps.
<finalbeta> they*, fine, nobody knows :p
<BenC> anyone around that can process linux-source-2.6.20 5-7 through NEW?
<BenC> Mithrandir: ping
<Mithrandir> BenC: sure, just let me find my laptop
<BenC> Mithrandir: k, thanks
<BenC> Mithrandir: I'll upload lrm and linux-meta now then, so within an hour or two lrm will need NEW love too
<mdke> finalbeta: I've seen Windows XP working quite a bit faster than Ubuntu on lower specification computers, I think it's just a bit snappier in general at the moment. But yeah, probably #ubuntu or #ubuntu-offtopic is better
<Nafallo> Mithrandir: lol. find you laptop? ;-)
<Nafallo> Mithrandir: you should get a darkelf. they are not so easy to hide :-P
<Mithrandir> it's only that it tends to stay in my backpack when I'm at home.
<Nafallo> hehe
* jdong suddenly recalls he means to do some media work
<Nafallo> jdong: and gajim :-)
<jdong> Nafallo: gajim looks fine to me; if you open up a launchpad.net/dapper-backports ticket I'll immediately approve it
<Nafallo> nice.
<jdong> and then it totally depends on Mithrandir and friends when Backports will be processed next ;-)
<Nafallo> jdong: ehrm. where? :-)
<jdong> Nafallo: product dapper-backports
<Nafallo> jdong: and then "Support"? :-)
<jdong> file bug
<Nafallo> ah :-)
<Nafallo> not a ticket then ;-)
<Nafallo> jdong: oh. you meant edgy btw :-)
<ScottK> Is this the correct place to ask about getting a package for Feisty through NEW?  I have another Universe package that depends on this one that I'm trying to get into Feisty.
<jdong> hehe I knew that :)
<ScottK> https://launchpad.net/ubuntu/feisty/+source/libnet-dns-resolver-programmable-perl
<jdong> ScottK: they don't like to be poked about doing their regular duties, IIRC
<jdong> but yes :)
<ScottK> OK.
<Nafallo> jdong: 78215 :-)
<ScottK> This is my first time with a new package and I'm trying to figure out the process.  Thanks.
<Nafallo> bug 78215
<Ubugtu> Malone bug 78215 in edgy-backports "gajim_0.11-0ubuntu1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78215
<jdong> Nafallo: approved; welcome to the wait-on-backports-queue club!
<Nafallo> Mithrandir: care to let that backport through? :-)
<Nafallo> jdong: thanks :-)
<Mithrandir> Nafallo: I try not to work too much outside work hours, so no, not really.
<Nafallo> Mithrandir: sounds like a good idea :-)
<Nafallo> Mithrandir: I nag you again if you forget it on monday then *smiles* ;-)
<glatzor_> Hello Seveas, you set up a web page that could render a custom sources.list?
<Seveas> yes
<Seveas> glatzor_, www.ubuntu-nl.org/source-o-matic
<glatzor> Seveas: hm. the site is quite conservative :) do you know some widely used third party repositories?
<Seveas> glatzor, the ones listed there
<Seveas> I tend to be conservative with that site
<glatzor> I think about providing nice descriptions for the them in software-properties
<Seveas> ah, you want to keep working around the wrong design that is sources.list =)
<glatzor> I looked at a sources.list that was attached to a bug report and holds a lot of repositories, but I never heard of them yet
<glatzor> Seveas: backwards compatibility is a key feature :)
<Seveas> if it was trevios sourcs.list: it contains mostly crap
<glatzor> Seveas: ms has got a harder job to keep compatible with win95 :)
<Seveas> glatzor, being a nice platform for 3rd party vendors is more important imho
<glatzor> wait, I will upload it
<glatzor_> Seveas:  http://files.glatzor.de/sources.list
<glatzor> Seveas: oh, most of them seem to be down :)
<Seveas> glatzor, or crap
<Seveas> plf is dead, the compiz one is horrible, the mlind ones are okay-ish
<Nafallo> repo.nafallo.info should be okey :-)
<glatzor> Seveas: thanks
<Seveas> glatzor, another thing about the source-o-matic is that is does nightly checks of the listed repos ;)
<Seveas> Nafallo, what's in it?
<Nafallo> Seveas: my repo ;-)
<Seveas> hehe, of course, but what;s in there?
<glatzor> Nafallo: what modifications have you done to the xen packages?
<Nafallo> glatzor: made a server flavour on amd64 :-)
<glatzor> Nafallo: Oh, some evil stuff inside :)
<Nafallo> glatzor: not in sweden ;-)
<Nafallo> some necessary stuff though :-)
<glatzor> Nafallo: The Scandinavians, where the world is still ok :)
<Nafallo> some of those things are outdated aswell :-)
<Nafallo> foo is a random place for people to test bugfixes before upload, the rest should be rather straightforward what it is :-)
<_ion> glatzor: The world is still ok you say?
<Nafallo> _ion: isn't it in .fi? :-)
* Nafallo has NFC how much he's repos are being used though :-P
<_ion> The .fi equivalent of MAFIAA has successfully lobbied evil laws in here, too.
<Nafallo> lol
<Nafallo> MAFIAA :-)
<_ion> Now e.g. "organized discussion" about breaking copy protection is illegal.
<Nafallo> _ion: ouch. come here :-)
<glatzor> _ion: here in Germany all people and politicians stare at Sweden when decisions about reforming the society have to be made
<Nafallo> glatzor: that's a good sign, right? :-)
<glatzor> depends on :)
<glatzor> _ion: here you can get even into jail for breaking copy protections
<Nafallo> but then again. we have a law against downloading. and one against uploading. still everyone you talk to does it :-)
<glatzor> _ion: and supporting it
<glatzor> Nafallo: they cannot prevent the use, but they can establish a monopole on comfortable use.
<Nafallo> the latest "non-official" is btw that all ISPs are installing hardware to log EVERYTHING
<Nafallo> and decrypt encrypted stuff as well :-P
<Nafallo> there is reason I most often encrypt x3 ;-)
<glatzor> Nafallo: x3?
<Nafallo> glatzor: yepp :-). SSL, IPSec and GnuPG most often :-)
<Nafallo> s/SSL/SSL\/TLS/
<Nafallo> gdebi is translated to use j instead of y in Swedish, but j seems to count as n :-P
<glatzor> Nafallo: oh, three times. In the first run I thought that this was the acronym of secret technique :)
<Nafallo> glatzor: hehe. oki :-), x == times :-)
<Nafallo> or multiplied ;-)
<Nafallo> in this case :-)
<exobuzz> the gb.archive.ubuntu.com mirror hasn't updated since 2 days ago. are you aware of this, and if not, who should be contacted ?
<_ion> mirrors@ubuntu.com perhaps
<exobuzz> ok
<exobuzz> i cant privmsg you. im not registered btw. but yes perhaps on #amigascne :)
<_ion> Ok, cool. :-)
<exobuzz> thanks. i mailed them
<ernstp> seems se.archive.ubuntu.com hasn't been updated in a couple of days
<AstralJava> I dunno, yesterday I got Firefox and Thunderbird updates thru it.
<AstralJava> No, sorry, only Thunderbird.
<AstralJava> $ ll /var/cache/apt/archives/ | grep thunderbird
<AstralJava> -rw-r--r-- 1 root root 10756290 2007-01-05 02:03 mozilla-thunderbird_1.5.0.9-0ubuntu0.6.10_i386.deb
<AstralJava> Avahi updates came last night.
<Nafallo> ernstp: beard!
<ernstp> Nafallo: huh?
<Nafallo> ernstp: that's probably a lie :-)
<Nafallo> ernstp: easy enough to check though :-)
<ernstp> well I have
<ernstp> and the se. mirror is still at 04-Jan-2007 05:12
<ernstp> it's usually quite quick. ah well, they'll probably will fix it on monday
<AstralJava> Ahh... you're talking about feisty, aren't you? Sorry I mixed up things.
<Nafallo> maswan: can you check the logs. ernstp says se.a.u.c isn't up-to-date :-)
<ernstp> yeah, this for example: http://se.archive.ubuntu.com/ubuntu/dists/feisty/main/binary-i386/
<Nafallo> ernstp: actually. I just apt-cache madison different stuff from feisty-changes, and you seem to be right :-). nice catch.
<ernstp> aight!
<maswan> Nafallo: seems like the last sync on the 4th went just fine, we haven't gotten triggered since then
<Nafallo> maswan: ah. so error from the DC? :-)
<maswan> Nafallo: dunno, possibly. I can do a manual sync now and see if it catches any updates
<Nafallo> maswan: you be nice :-). thanks.
<Nafallo> ehh
<Nafallo> s/you/that\ would/
* maswan is nice \o/
<Nafallo> maswan: hehe, that to :-)
<Nafallo> maswan: but it you haven't been triggered that must be a bug :-)
<Nafallo> elmo, Znarl: ^ :-)
<maswan> Nafallo: I took it up over at the appropriate forum already. :)
<Nafallo> maswan: ah. you have one of those as well. kewl :-).
<maswan> Nafallo: there is a #u-mirrors, where all the cool guys hang out. ;)
* Nafallo joins ;-)
#ubuntu-devel 2007-01-07
<Nafallo> hmm
<Ingar> HEI!
<jdong> s
<jdong> sorry, didn't mean to do that, lost focus...
<ozgurk> hello
<ozgurk> good nights.
<glick> hi
<glick> hey has a decision going to be made if feisty is going to include the 3d desktop by default?
<glick> or whats going on with that?
<somerville32> There are a lot of kernel packages that haven't be recompiled. Why isn't the old binary package left in the repository until the new version is ready?
<Nafallo> somerville32: huh?
<somerville32> *been
<Nafallo> 17-10, 19-7, 20-1, 20-2, 20-3, 20-4, 20-5 is in feisty :-)
<somerville32> Most of the linux-restricted-modules aren't
<somerville32> When I upgraded I had to use the gb mirror because it is broken and still had the old packages
<Nafallo> how bad :-)
<Nafallo> I don't use restricted myself
<johanbr> somerville32: There's no guarantee that the development repository is in a 100% consistent state at all times.
<somerville32> johanbr, Thats to be expected.
<somerville32> But it has less to do with it being the dev repository and more to do with how repositories work
<somerville32> (my question that is)
<Nafallo> somerville32: that's why I answered that we have lots of old packages lying around :-)
<Nafallo> laying
<johanbr> lying
<johanbr> Pet peeve of mine. :)
<somerville32> How do you spell lieing?
<johanbr> lie, lies, lain, lying.
<jdub> "lain"?
<johanbr> Has lain.
<jdub> in the case of telling a lie, it's "lied"
<jdub> in the case of a funeral "laid to rest"
<jdub> "lain" is pretty old school
<_ion> Thou think so?
<johanbr> If you're looking for a past tense of "lie" meaning "be situated on", I don't know what else you'd use.
<somerville32> lied?
<somerville32> lol
<johanbr> If you're telling an untruth, yes.
<somerville32> If lying and lying are the same - why not lied and lied?
<_ion> Since when is English supposed to be logical?
<somerville32> gp
<sistpoty> haha, with your discussions about english I just found (and filed) bug #78271
<Ubugtu> Malone bug 78271 in tk8.4 "usr/lib/libtk8.4.so.0 has no SONAME" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78271
<jdong> jdub: I've gotten a 5 point grammar deduction on a paper for using slain, so I doubt lain would fly so smoothly :D
<Nafallo> sistpoty: go to bed! :-)
<sistpoty> Nafallo: only this small security fix for gallery2, then *g*
<_ion> Let's all switch to Lojban.
<jdub> jdong: slain is more regularly used than lain
<jdong> jdub: yeah, IMO slain is still usable :)
<Nafallo> sistpoty: I am in bed myself. had to patch together two cat5e :-)
<jdong> but obviously my english teacher thought that 'slayed' should be used instead :D
<sistpoty> Nafallo: :)
<_ion> I'm in bed, too.
<Nafallo> _ion: so you actually mean you're in bed with me? ;-)
<somerville32> I had a prof tell me that spelled should be used instead of spelt - but I argued with him until he let me use the word spelt :] 
<johanbr> For what it's worth, Merriam-Webster seems to agree with me about "lie".
<_ion> nafallo: Well, there probably is an alternative universe where you reside in this bed and i reside in that bed.
<somerville32> ;] 
<Nafallo> haha
<Nafallo> _ion: would probably be good for you. I got a large bed :-)
<jdub> johanbr: that is not a real dictionary.
<johanbr> jdub: Are you going to go Crocodile Dundee on me and pull out the complete OED?
<Nafallo> lol
<jdub> johanbr: quite!
<jdub> johanbr: though it'd have to be some bizaaro version of croc dundee with a snotty english accent
<elkbuntu> jdub, what's the best email address to harrass you at?
<macd> whats the deal with kernel-patch-grsecurity2 ?
<macd> has grsec been merged in edgy?
<macd> whats the deal with kernel-patch-grsecurity2 ?
<macd> has grsec been merged in edgy?
<mdke> Mithrandir: just tried your contentless ping script, doesn't seem to work. Anything I need to do except for loading it?
<Mithrandir> mdke: sure?
<Mithrandir> mdke: ping
<Mithrandir> hmm, true, at least if your current client has it loaded.
<mdke> Mithrandir: yes
<mdke> 10:08:44 -!- Irssi: Loaded script contentless_ping
<Mithrandir> it seems to be buggy, I'll take a poke at it.
<mdke> Mithrandir: wow, thanks. Lemme know if I can test
<Mithrandir> mdke: ok, download the script again, it's fixed now and has rate-limiting applied.
<mdke> Mithrandir: that's awesome. Will check later and let you know!
<Mithrandir> mdke: thanks for telling me that it was buggy. :-)
<glick> hey so is feisty fawn gonna be uncool and try to make the 3d desktop default?
<Hobbsee> Mithrandir!!!
<Hobbsee> ...
<Mithrandir> Hobbsee! :-)
<Hobbsee> :)
* Hobbsee hugs Mithrandir 
* Mithrandir hugs Hobbsee back.
<Mithrandir> how's .au today?
<Fujitsu> Mithrandir, a lot colder than the past few days, which is good :)
<glick> ?
<glick> shuttleworth! are you in here?
<Mithrandir> glick: sabdfl isn't here now, no.
<glick> dont make 3d desktop default
<Hobbsee> Mithrandir: dunno, i've been inside working most of the day.  it's been raining and sunny, alternating
<mdke> glick: powerful reasoning
<mdke> glick: you might wanna try the usual means of discussion though, via commenting on the relevant specification, etc
<Keybuk> jdub: damn boy, you've managed to find an ancient version of mailman, there!
<glick> mdke, but many people dont have fancy video hardware
<glick> what are they gonna do?
<Keybuk> glick: not to mention providing an argument
<jdub> Keybuk: LA mail infra sucks. i've offered to revamp the whole lot post-lca.
<Keybuk> glick: default doesn't mean "mandatory", we already enable AIGLX by default if you have the hardware -- those without the hardware simply don't have it enabled
<stgraber> Anyone knows if the current daily build of Feisty is installable ?
<Keybuk> stgr: http://cdimage.ubuntu.com/daily/current/report.html
<Keybuk> stgraber: http://cdimage.ubuntu.com/daily/current/report.html
<Keybuk> that's pretty installable
<glick> what is the reasoning for default 3d desktop?
<stgraber> oh, didn't know of that file, thank you
<Keybuk> glick: see the spec
* pitti waves to the devs who spend their Sundays at their computer
<StevenK> I spent my Sunday at the airport.
<StevenK> I would have prefered to be at my computer, to be honest.
<Hobbsee> heya pitti 
* Hobbsee spends sunday at work, it seems
* Hobbsee prods pitti into doing some work
<pitti> Hobbsee: I spent my entire Saturday refactorizing the apport UI and writing test suites
<pitti> Hobbsee: long train rides are excellent for that :)
* pitti hugs https://code.launchpad.net/~ubuntu-core-dev/+branch/apport/cloakroom
<StevenK> Cloakroom?
<pitti> StevenK: see crash-reporting spec
<pitti> bbl
<Hobbsee> pitti: woot :)
<pitti> StevenK: bottom line is that reports can be uploaded automatically and Malone integrates the data in the report filed
<pitti> StevenK: no more 'please attach this clumsy file name to the bug' dialog
<StevenK> Whee
<Hobbsee> yay :)
<pitti> on the distro sprint I'll work with Bjorn to actually get Malone working for that :)
<pitti> thus I develop it in a branch for now
<Hobbsee> ah :)
<pitti> argh, feisty's gnome-terminal reeeally sucks *grumpy*
<StevenK> pitti: How so?
<pitti> StevenK: it freezes pretty often, I can only close the tab and open a new one
<Fujitsu> Works fine for me.
<pitti> i. e. it reacts to ^C (write new command prompt), but doesn't do anything else
<StevenK> pitti: I suggest the fix is to belt seb128 until he fixes it. :-P
<pitti> StevenK: great idea!
* StevenK grins
<Hobbsee> hehe
* Hobbsee belts StevenK until he fixes all of universe
* StevenK ignores the belting
* Fujitsu belts Hobbsee until SHE fixes all of universe.
* PuMpErNiCkLe joins in on the belting
<Hobbsee> Fujitsu: now it's not good manners to belt females...
<StevenK> Indeed.
<Fujitsu> Damn.
* mneptok appears in a cloud of green vapor, belt in hand, pants at ankles
* pitti jumps back
* Hobbsee covers her eyes
<mneptok> HI!
* pitti stumbles while the earth shatters
<pitti> hey Kurt!
<mneptok> morgen pitti 
<ogra> moin
<mneptok> i need to lock myself in a text editor with e-mail text i don't want to write
<mneptok> *grmbl*
<Hobbsee> mneptok: you could just avoid it
<Hobbsee> hey ogra 
<ogra> hi Hobbsee 
<mneptok> Hobbsee: it's ... it's ... *like you've been sitting next to me for 36 hours*  ;)
<Hobbsee> mneptok: haha. "why put off till tomorrow what you can put off till next week?"
<mneptok> as a Buddhist, my procrastination can extend across incarnations
<StevenK> Ahhh, so babies aren't just lying around doing nothing, they're procrastinating from previous lives. Brilliant!
<mneptok> StevenK: exactly. "i'll finish buisding that deck when this crap is out of my pants."
<mneptok> *building
<StevenK> "And when I can lift the hammer."
<mdke> Mithrandir: link to your script on your latest blog post seems to still point at 0.2
<mdke> Mithrandir: or maybe you didn't bump up the version number
<geser> mdke:  http://err.no/src/contentless_ping.pl has 'my $VERSION = "0.3";'
<Mithrandir> mdke: I believe you are the victim of a proxy. :-P
<mdke> Mithrandir: hmm. my isp?
<Mithrandir> 7f11ac3fb552f0efefbbe4ecebd9e214  contentless_ping.pl
<Mithrandir> does that match your local md5sum?
<mdke> Mithrandir: lemme download it again
<mdke> Mithrandir: no
<Mithrandir> try getting http://err.no/src/contentless_ping2.pl, then?
<Mithrandir> (same file, just a copy)
<mdke> Mithrandir: I got the original file after clearing firefox cache, all is now well
* mdke blames firefox
<Mithrandir> oh, ok
<mdke> is it supposed to do that?
<Mithrandir> I don't think I'm sending out expires headers, so yeah, except it should have been picked up by if-modified-since or something like it.
<mdke> Mithrandir: see if the script works?
<Mithrandir> mdke: ping
<mdke> Mithrandir: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<Mithrandir> yeah, works fine.
<mdke> \o/
* mdke hugs Mithrandir 
<Mithrandir> you can /set contentless_ping_action to change the text, etc if you want to.
* mdke nods
<Mithrandir> similarly /set contentless_ping_regexp to change the regex it uses to pick up pings.
<mdke> Mithrandir: sure. does it pick up pings prefaced by $nick, (comma instead of colon)?
<Mithrandir> nope, but I could fix that.
<mdke> Mithrandir: only if you fancy it
<Mithrandir> (done)
<Mithrandir> set contentless_ping_regexp to $own_nick[,:]  (ping|around|ayt|((are )?you )?there)[!?.] ?$
<mdke> very cool
<Hobbsee> Mithrandir$ ping
<Hobbsee> :P
* Hobbsee ducks
<Mithrandir> Hobbsee: sure, you can work around it; the idea isn't to play some kind of escalation war game, but rather to get people to provide useful information when they ping you.
<Hobbsee> Mithrandir: yeah, i know :)
<mdke> escalation war games can be fun too though
<Hobbsee> mdke: they are!
<Mithrandir> so I'm not going to add workarounds for everything people can think of to work around it.
<Hobbsee> Mithrandir: hehe, i know :)  
* Hobbsee has been fighting the uni servers
<Mithrandir> mdke: sure, they can be, but they can very easily turn pointless and annoying to the rest of the world. :-)
<mdke> indeed
* poningru hugs mako for the blog
<fgo496> Hello2all
<In-love-with-TUX> i've upgrade my ubuntu to feisty but i have a problem with the acpid  it gave a message that i should do dpkg-reconfigure acpi but it still show me that acpi not configured will what should i do ?
<In-love-with-TUX> sorry i just finnished reading the topic 
<In-love-with-TUX> :(
<hunger> Is there a linux-image-2.6.20-5-generic already?
* hunger was asked to use that, but can not find it anywhere.
<Mithrandir> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-image-2.6.20-5-generic_2.6.20-5.7_amd64.deb for instance?
<lifeless> morning
<somerville32> Morning
<mdke> Mithrandir: I notice that you've built in Jedi powers to that script: http://paste.ubuntu-nl.org/776/
<mdke> it sees things before they happen
<hunger> Mithrandir: Damit.... why doesn't aptitude pick that up here?
<Mithrandir> mdke: oh, that's just because of how the internal irssi timing works out.  If it's annoying, add a sleep 0.1 before the response.
<mdke> Mithrandir: no, I thought it was cool
<Treenaks> "You will ping me without content... please don't"
<mdke> lol
<Treenaks> sounds like a Jedi mind trick
<mdke> this is not the contentless ping you are looking for
<Treenaks> mdke: *handwave* a contentless ping will do fine
<mdke> haha
<_ion> mithrandir: sleep? :-)
<mdke> your tricks do not work on irc
<_ion> mithrandir: How about Irssi::signal_add_last?
<Mithrandir> _ion: oh, sure, that should work too, I guess.  I've never pretended to know my way around irssi programming. :-P
<Mithrandir> _ion: patches accepted. 
<Treenaks> Mithrandir: ah, true Perl style: 'Patches welcome' :)
<Mithrandir> Treenaks: heh. :-)  I'm just lazy.
<Treenaks> Three great virtues of programming are laziness, impatience, and hubris. - Larry Wall
<Treenaks> anyway, gone :)
<jc-denton> hi all
<jc-denton> where is the .config of the offical ubuntu kernel?
<jc-denton> i thought that the config is also somewhere accessible through proc
<jc-denton> but forgot how
<_ion> ls /boot/config*
<jc-denton> [17183300.392000]  ipw2100: eth1: No response from Symbol - hw not alive
<jc-denton> [17183300.396000]  ipw2100: eth1: Error loading microcode: -5
<jc-denton> [17183300.396000]  ipw2100: eth1: Failed to power on the adapter.
<jc-denton> [17183300.396000]  ipw2100: eth1: Failed to start the firmware.
<jc-denton> woops
<jc-denton> sry
<jc-denton> /boot/config-2.6.17-10-generic
<jc-denton> ok that looks good thank you
<shawarma> jc-denton: It's true that the linux kernel makes this possible (through CONFIG_IKCONFIG), but as we always ship the config in /boot, there's really no need to bloat the kernel image with it.
* hunger sighs. kernel 2.6.20 sucks for me:-( No sound, no WLAN, gets stuck during boot.
#ubuntu-devel 2007-12-31
<imbrandon> Riddell: killer
<psusi> anyone here working on the UdevEvmsLvmAgainSpec?
<psusi> anyone here working on the UdevEvmsLvmAgainSpec?
<lamont> dear rhythmbox, why do you insist on grabbing focus instead of letting the windowmanager do that for you?
<Amaranth> dear rhythmbox, i've left your database and cache in the trash can out front, i'm using banshee now
<persia> Ubulette: You didn't address either of my comments in the new upload, and the new changelog is less acceptable than the last.  Please revise again.
<Ubulette> yep, i read then too late, updating
<Ubulette> changelog ? what about it ?
<lamont> Amaranth: heh.
<lamont> Amaranth: mind you, my window manager has been told that it's never to take focus away from the current window.  which makes rhythm box's behavior even worse.
<imbrandon> crimsun: arround ?
<superm1> imbrandon, you got a little bit to look over something in main that i need sponsorship on?
<imbrandon> sure
<superm1> okay its a new lirc version: bzr branch bzr+ssh://user@bazaar.launchpad.net/~mythbuntu/lirc/ubuntu/
<imbrandon> k
 * imbrandon grabs it
<superm1> the debian directory is on that branch
<superm1> just apt-get source the old revision in hardy to get the rest of the stuff (its an incremental ubuntuX revision)
<imbrandon> kk
<imbrandon> wow, i think you wrote a book in the changelog
<imbrandon> heh
<superm1> haha
<superm1> it took a long time to implement all the changes
<imbrandon> looks good though, need it uploaded ?
<superm1> yeah
<imbrandon> k
<superm1> thanks
<imbrandon> give me about 5 more minutes to finish up another upload i got going then i'll push it
<superm1> k
<persia> Happy New Year
<hellboy195> persia: thx you. You too :)
<brettalton> so, does anyone think there is still a need for Automatix/EasyUbuntu?
<persia> brettalton: There oughtn't be.  EasyUbuntu was merged in Edgy, and I believe most of Automatix was merged in Gutsy (although there are still a few apps in the Automatix repos that can't be in multiverse)
<thekillerplague1> can anyone help?
<psusi> how do you use that new trigger feature to trigger an update-initramfs?
<tritium> ///win13
<nixternal> one to many /'s there :p
 * XSource_ Accept/Balls To The Wall - global german radio network - Various (xÂ«amarok)
#ubuntu-devel 2008-01-01
<ion_> Sigh
<sladen> Ubuntu, now in it's 5th year.  sortof
<AlinuxOS> Happy New Year - C Ð½Ð¾Ð²ÑÐ¼ Ð³Ð¾Ð´Ð¾Ð¼ - áááááªááá áá®áá á¬ááá¡ - Felice Anno Nuovo
<ramvi> Hi, I'm working on optimizing Ubuntu for the small asus eee. What package or file is it that contains the default gnome user setup? Like "one panel on top. one at bottom. Font size 10 " etc?
<ion_> summon Keybuk
<psusi> are we planning on moving to kpartx or some other user mode partition detection scheme at some point?
<JanC> hm, I was just talking to someone who didn't know that one of the Belgian Ubuntu mirrors has been down (well, up & mostly down, they seem to have some troubles) for some time
<JanC> shouldn't the update checker warn the user if it can't check for updates for more than a certain time?
#ubuntu-devel 2008-01-02
<JanC> https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/179767
<ubotu> Launchpad bug 179767 in update-notifier "update-notifier doesn't report unreachable mirror" [Undecided,New]
<pitti> Good morning
<Hobbsee> pitti!
 * pitti hugs Hobbsee, happy new year!
 * Hobbsee hugs pitti back!  Happy New Year to you too!
<Hobbsee> grumble.  i refuse to blackout, dammit!
 * pitti dist-upgrades and gets "E: Internal Error, Could not perform immediate configuration (2) on libstdc++6"
<StevenK> Just like the buildds!
<minghua> pitti: Leave all gcc stuff alone, upgrade libc6 and tzdata first.
<minghua> (at least that works for me, both the real system and the pbuilder)
 * persia advocates aptitude which has not exposed this error on live systems or chroots
 * minghua think that's an error message from APT.
<pitti> minghua: ah, thanks, that work
<pitti> s
<pitti> minghua: yes, it is
<minghua> pitti: Glad to help. :-)
<StevenK> pitti: http://launchpadlibrarian.net/11059338/buildlog_ubuntu-hardy-powerpc.libsdl1.2_1.2.12-1ubuntu2_CHROOTWAIT.txt.gz
<StevenK> pitti: So, it's not just you
<minghua> StevenK: So there are still buildds broken by that upgrade bug?
<StevenK> powerpc and sparc, it looks like.
<StevenK> i386 and amd64 were busted, but they were fixed
<minghua> Yeah, I remember hearing someone fixed the buildds during the holiday, wasn't sure if all are fixed.
<Fujitsu> We're waiting on infinity to do sparc/powerpc, but elmo consented to doing i386/amd64.
<stgraber> moin
<pitti> hey stgraber, happy new year!
<stgraber> hi pitti, an happy new year to you too !!!
<pitti> infinity: did the new pkg-create-dbgsym -proposed packages work? if so, I'd like to move them to -updates
<geser> pitti: Hi, please give back: cheops-ng. Thanks.
 * Hobbsee waves
 * Hobbsee sighs at $work
<geser> Hi Hobbsee
 * Hobbsee is glad for the good relationship $employees at $work have with the local police.
<Hobbsee> australian emergency number really does work!
<geser> Hobbsee: what happened?
<Hobbsee> geser: drunken idiots, theiving.
<Hobbsee> unfortunately, no one could really go near them terribly much, as they were carrying glass bottles.
<Hobbsee> they'd learnt from last time, it appears, where they only managed to look suspicious, and call me a bitch.  *shrug*
<Spads> http://nobodyscores.loosenutstudio.com/index.php?id=318 <-- Hobbsee
<geser> mvo: Hi, we have libcompizconfig-backend-{gconf,kconfig} and compizconfig-backend-{gconf,kconfig} (imported from Debian). Do we need both?
<Hobbsee> Spads: heh
<joejoe> hello, can anyone help me with dependency problem in debian package?
<joejoe> https://launchpad.net/~xmlich02/+archive/+builds?build_text=&build_state=all
<Fujitsu> joejoe: That's not a package from Debian.
<geser> joejoe: is that a l (ell) instead of a | (pipe) before autotools-dev?
<Fujitsu> This is also not a support channel, for PPA or otherwise.
<joejoe> oh i'm sorry, can you tell me where is right place to ask?
 * Fujitsu suggests that #launchpad would be the correct place, but is likely entirely useless.
<Keybuk> looks like a package problem to be
<Keybuk> "lautotools-dev" => no such package
<Fujitsu> It is.
<Hobbsee> Fujitsu: it's #launchpad in the hope that someone takes action, and answers
<Hobbsee> Fujitsu: which usually ends up being you.
<joejoe> okay, thank you, i'm just newbie
<Fujitsu> joejoe: Anyway, drop the l from the start of lautotools-dev, and things might work.
<Fujitsu> Assuming somebody hasn't uploaded broken fixes to buildd-killing bugs, or has fluked impressively and broken the known-broken brokenness fix.
<Hobbsee> Fujitsu: well, assuming they don't do that until...what is it...let me check - has it been delayed again?  oh, until 2.2 now, yes.
<Hobbsee> Fujitsu: what's the known-broken brokenness fix?
<Fujitsu> Some people apparently feel it a good idea to upload fixes that they know are broken to PPA.
<Hobbsee> oh, right, so that's what you meant.
<Hobbsee> Fujitsu: bring on mid-jan, that's all i have to say.
<Hobbsee> Fujitsu: and if mid-jan doesn't bring anything interesting, bring on the ritual burnings of the end of jan!
<Fujitsu> Haha.
 * Hobbsee checks over her collection of flaming torches and pitchforks, and sees them all in good working order.
<Hobbsee> Fujitsu: did you call jono, then?
<Fujitsu> Hah, I was thinking of commenting on the timing.
<mvo> geser: no, the one from debian looks like a duplicate with a different name
<Trigger7> imbrandon: could you come around in #debian-qt-kde to talk about the kde4 bindings?
<infinity> pitti: They seem to be working well.
<infinity> pitti: I may quickly go through some PPA logs when I'm "at work" (in about 4 hours) and make sure before I give you a green light.
<Kmos> infinity: the problem is the chroot waiting ones in buildd
 * Hobbsee preemptively offers infinity the link to the Kmos Report.
 * persia notes that Google now has that, as a lucky guess for "KmosReport"
<Hobbsee> hah
 * Hobbsee wonders how high that comes up in a "kmos" search.
<Hobbsee> nope, not very high.  aww
<Hobbsee> Kmos: oh, and seeing as you now *aren't* externally scheduled now, and are clearly here, would you care to continue the discussion?
<Hobbsee> but in -motu
<Kmos> Hobbsee: what are you talking about ?
<Hobbsee> Kmos: https://wiki.ubuntu.com/MOTU/Council/KmosReport - 4th from the bottom
 * Hobbsee forgot that you're probably not subscribed to that page, so didn't see the wording
<Kmos> Hobbsee: No, I'm not. are you talking about persia?
<Hobbsee> Kmos: about persia's entry, yes.
<Kmos> Hobbsee: I think I should not discuss that things with you..
<Kmos> only by the ones from MOTU Council.
<Fujitsu> I believe the discussion was ongoing in #ubuntu-motu until you had to attend to something else.
<Hobbsee> Kmos: actually, you should probably discuss it with those who you were previously discussing it with, before you went to lunch, in #ubuntu-motu, which was where the previous discussion was.
<Kmos> Hobbsee: it's lunch time here.. but let's go for another one.
<roydog> hi folks
<roydog> anyone around?
<Hobbsee> no
<roydog> well that sucks
<ogra> most of us are on holiday ...
<roydog> I see...
<roydog> If I have questions say regarding Gtkmm, would this be a good place to ask?
<Hobbsee> ogra: holiday?  you get holidays?
<CheGuevara> !ask
<ubotu> Please don't ask to ask a question, ask the question -- All On One Line, so others can read it and follow it easily --. and if anyone knows the answer they will most likely answer. :-)
<ogra> Hobbsee, we pretend to
<roydog> CheGuevara: I didn't ask to as a question
<roydog> CheGuevara: I'm trying to find a channel where I can discuss Gtk
<ogra> probably #gtk ?
<minghua> roydog: If it's not specific to Ubuntu's gtkmm package, then it's not a good place to ask.
<roydog> well I am using ubuntu's Gtkmm package
<roydog> and I'm trying to develop software for gnu/linux/ubuntu
<roydog> I kinda figured this place might apply since it's design to help folks develop ubuntu no?
<ogra> then this is clearly the wrong channel (see topic)
<roydog> ah yeah
<roydog> I see hehe
<roydog> :(
<roydog> tx
<pitti> Keybuk: not sure whether you saw the wiki diff for policykit-integration: considering sudoers as 'admins' is highly non-trivial
<pitti> Keybuk: ATM PK considers members of group 'admin' as admins
<pitti> ideally we would have admins == set of people who can run arbitrary sudo commands, but determining this set of people is hard
<Keybuk> pitti: this doesn't surprise me :-/
<Keybuk> it's probably easier to have sudo talk to PK than PK talk to sudo
<Keybuk> (ie. sudo uses PK instead of sudoers)
<pitti> Keybuk: so, the spec needs some more discussion now which I hoped to do in tomorrow's meeting (but that was cancelled now)
<pitti> Keybuk: well, 'sudo uses PK' would mean to have %admin ALL=(ALL) ALL in /etc/sudoers AFAICS
<pitti> Keybuk: anyway, just to inform you about the changing of an approved spec; not sure ATM what the best solution is
<Keybuk> discussion is probably best for ubuntu-devel ML
<pitti> right
<pitti> doko: do you happen to have merged sane-backends already?
<pitti> doko: I need to change the package, and I can merge it along the way if not
<doko> pitti: no, please go ahead
<pitti> doko: libsane-doc> it would be significantly easier, and AFAICS not less correct to install the documentation into libsane-dev; WDYT?
<doko> pitti: np, as long as it doesn't land on the CD
<pitti> yes, we don't install -dev on CDs
<geser> pitti: Could you give back: cheops-ng. Or should I wait with give-back till the ppc and sparc buildds are also fixed?
<pitti> geser: might be better, since they'll fail; I hope infinity can fix the buildd chroots once he wakes up (or mvo fix apt :) )
<geser> mvo: so it's ok to request the removal of compizconfig-backend-{gconf,kconfig} (the imported one) from hardy?
<mvo> geser: that may be best for now, also I would like to resolve this in a way that we are package name compatible again (I wonder why the debian ones are named differently)
<mvo> pitti: what is broken with apt ?
<pitti> http://launchpadlibrarian.net/11116411/buildlog_ubuntu-hardy-powerpc.sudo_1.6.9p10-1ubuntu1_CHROOTWAIT.txt.gz
<pitti> mvo: ^ this happened in all buildd chroots, and I got it on my laptop this morning, too
<pitti> E: Internal Error, Could not perform immediate configuration (2) on libstdc++6
<persia> mvo: pitti: elmo explained that this was because some things were treated differently for Essential packages
<mvo> *ick*
<Hobbsee> infinity: was looking into that, too
<elmo> persia/mvo/pitti: (FWIW) that was only part of the problem, even taking that out of the equation didn't seem to help
 * mvo checks if he can reproduce it
<pitti> mvo: this morning I was advised to first upgrade libc6 and tzdata, and then the rest; this worked
<elmo> mvo: I have a backup of the chroot I can make available to you, if you can't easily reproduce
 * pitti sighs at the mess in sane-backends
<ogra> oh no !
 * ogra curses consolekit ... *nothing* works in LTSP anymore
<pitti> ogra: ?
<ogra> pitti, i cant do *any* administrative stuff at all
<ogra> not even time-admin
<pitti> ogra: you don't get a console on the thin clients?
<ogra> ldm runs client side .... and starts ssh -X
<ogra> consolekit doesnt know about ssh connections it seems
<pitti> ah, I guess we need to teach CK about those kind of sessions then
<ogra> even worse the unencrypted mode connects diretly to the clients X server by setting DISPLAY while doing everything else via ssh
<ogra> (no XDMCP involved)
<ogra> phew ...
<psusi> Keybuk: got time to discuss UdevLvmMdadmEvmsAgain?
<ogra> that'll be a good amount of work i guess ...
<pitti> doko: "Link using -Bsymbolic-functions." in sane-backends did not have a rationale; what does it do?
<pitti> or, rather, why?
<doko> pitti: -Bsymbolic-functions does resolve intra-library symbols at link time, not at load time, reducing startup time, (run time, and shlib size)
<Keybuk> psusi: sure, what's up?
<pitti> doko: ah, ok; so it's purely optimization? or something to do with newer compiler?
<psusi> Keybuk: well, I've spent the last few days working on the dmraid package and trying to make some headway in that area
<doko> optimization (and newer linker)
<pitti> doko: thanks
<psusi> Keybuk: one thing that I noticed is that vol_id has code built into it to regognize a dmraid siganture on a disk
<Keybuk> right, that's not surprising
<Keybuk> it has code to recognise most formats
<psusi> Keybuk: this strikes me as a bad duplication of code... would it not be better to have udev call dmraid and ask IT if it sees a signature, and if so, set the variables appropriately?
<ogra> psusi, well, that code3 is also in mdadm afaik ...
<ogra> so you already have duplication
<ogra> -3
<psusi> ogra: mdadm doesn't have anything to do with dmraid ;)
<Keybuk> psusi: udev would have to then call about 500 helpers
<Keybuk> one to detect lvm, one to detect dmraid, one to detect dm, one to detect ext3, one to detect ext2, etc.
<Keybuk> far better to have one single library to do it all
<psusi> right...
<psusi> is it?
<Keybuk> given the above, yes
<psusi> is it really better if vol_id is out of date and fails to recognize a signature?
<Keybuk> don't let vol_id get out of date?
<geser> mvo: request to remove compizconfig-backend-{gconf,kconfig} filed as bug #179876
<ubotu> Launchpad bug 179876 in compizconfig-backend-kconfig "[Remove] Please remove compizconfig-backend-{gconf,kconfig} from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/179876
<psusi> difficult to do when you have to duplicate the code by hand
<Keybuk> it's better than running 500 programs every single time a block device is dected
<psusi> is it really that slow?
<Keybuk> and what do you do when several programs both believe they have the block device?
<ogra> psusi, oh, sorry for the unqualified statement then :) (/me is old mdadm user, was always enough for my raid0 setups)
<Keybuk> if the block device has both ext3, lvm and dmraid signatures
<psusi> udev needs to arbitrate... have some priority and once one claims it, the others can't have it
<Keybuk> that's what vol_id does
<psusi> yea... it's just with out dated duplicate code
<Keybuk> update the code :)
<Keybuk> all we use vol_id for largely is to detect the signature
<psusi> ;)
<Keybuk> (it's also used by HAL, etc.)
<psusi> another issue I noticed is that it correctly identifies my disks as raid members, but then udev asks it to id the partitions on sda, of which, only the first is actually accessible since the others are beyond the end of the device
<Keybuk> ?
<psusi> so it identified my windows partition as a usable fs, which resulted in a UUID link being created to it, which is in fact, broken
<Keybuk> ?
<psusi> the raw disk is a raid member
<ogra> why ?
<Keybuk> ? = I don't understand
<psusi> but the kernel still sees the partition table on it and tries to create the partitions
<psusi> sda and sdb are in a raid0
<psusi> but the kernel still sees the partition table on sda, even though it applies to the raid as a whole, not just to sda
<psusi> so it goes ahead and creates an sda1 for my windows partition
<Keybuk> sounds like a kernel issue
<psusi> and vol_id is run on sda1, which says it's a usable fs
<psusi> in a way, it is... it would be easily solvable if we relied on udev to worry about the partitions instead of the kernel
<Keybuk> we don't
<Keybuk> we rely on the kernel
<psusi> is there any movement towards doing that?  with kpartx or somesuch?
<psusi> right, but is there any plan to change that?
<Keybuk> no
<Keybuk> no plans
<psusi> damn
<psusi> well then, another possible solution is that if vol_id has tagged the entire disk as a raid member, then any partitions on it should be ignored
<Keybuk> ignored by what?
<Keybuk> (that's possible, btw)
<psusi> vol_id
<Keybuk> IMPORT{parent}=="IS_RAID", ENV{IS_RAID}=="YES", OPTIONS+="ignore_device"
<psusi> and well, everything really
<Keybuk> that would make udev ignore partitions on entire-disk raids
<Keybuk> and wouldn't even tell HAL about them
<Keybuk> (assuming the disk has IS_RAID=YES of course)
<psusi> hrm.... I don't think it's IS_RAID, I think it's ID_FS_USAGE=raid_member or something
<psusi> but yea, that's the idea
<psusi> ok... that would take care of that part... now I have removed the initramfs scripts for dmraid to run it during boot, and am working on a udev rule now to ask it to probe a block device to see what raid set it is a member of
<psusi> and store that information as a variable, then invoke dmraid and ask it to assemble that raid set
<Keybuk> normally you'd have two sets of udev rules
<psusi> I was thinking of keying on the ID_FS info vol_id pulls... it identifies the disk as an "nvidia_raid_member" for instance
<Keybuk> first set to check whether it is a raid device, and then activate dmraid
<Keybuk> and a second set to run vol_id on the filesystem inside the assembled raid device
<psusi> so when that variable is set, it should know it should run dmraid, and not other stuff
<psusi> right
<psusi> well, that comes into the next problem
<psusi> how to mark the assembled device as published
<Zero> Hi, i wanna know why warsow-0.32 was only published in Ubuntu Hardy, and Ubuntu Gutsy still have warsow-0.31
<psusi> as it is udev ignores dm* devices
<Keybuk> see mdadm, devmapper, etc.
<Keybuk> they have a second 85-* rules file that runs vol_id again
<psusi> aye
<Keybuk> this time on the raid itself
<psusi> ohh
<psusi> I thought that was not done currently due to race conditions?
<psusi> need a way for the tool to mark the device as published?
<Keybuk> no
<Keybuk> it might be 65-*
<Keybuk> I forget
<psusi> I thought that was the whole point of that spec... it was saying that udev sees the md device as soon as it is created, before it is actually usable
<Keybuk> right
<psusi> so there has to be a method for the tools to inform udev that it is now ok to diddle with the device
<Keybuk> and then we ask mdadm whether it's usable
<Keybuk> it says no, so we ignore iot
<Keybuk> and we get a change event later when it is available
<psusi> ohh
<Keybuk> as long as dmraid follows the same pattern, you're fine
<psusi> but that doesn't cover the case of snapshot volumes and such that should never be published
<Keybuk> why shouldn't they?
<psusi> because they would be tagged with the same UUID?
<Keybuk> OPTIONS="link_priority=-100"
<Keybuk> ENV{DM_TARGET_TYPES}=="*snapshot-origin*", OPTIONS="link_priority=-90"
<mvo> elmo: thanks, but I can reproduce it now
<Keybuk> we adjust the link priority
<psusi> and other dm devices are created by the tools internally that should NEVER be opened
<Keybuk> so the UUID we want wins
<psusi> ahhh
<psusi> though actually.... the thing is... when using a snapshot, you have an original device which starts out as just a linear mapping
<psusi> that's the device you mount the filesystem on
<Keybuk> right, the snapshot-origin one
<Zero>  Hi, i wanna know why warsow-0.32 was only published in Ubuntu Hardy, and Ubuntu Gutsy still have warsow-0.31
<psusi> then when you make the snapshot, that linear mapping is replaced with a snapshot-origin
<Keybuk> it goes from being linear to snapshot-origin
<psusi> yea
<Keybuk> so we give that one a higher link priority
<Keybuk> so it wins the /dev/disk/by-uuid thingy
<Keybuk> -90 > -100
<Zero> https://edge.launchpad.net/ubuntu/+source/warsow/
<psusi> but that's still where the uuid should point
<Keybuk> that's what happens
<persia> Zero: You might want #ubuntu-backports
<Zero> =/
<Zero> ok
<psusi> well, that might not be correct thoguh, because you can also do it the other way around, where the mounted device is the snapshot, not the origin
<Keybuk> *shrug*
<Keybuk> at that point, I cease caring :)
<psusi> heh
<Keybuk> if you want to do it the other way around, you can use the /dev/mapper names :-)
<psusi> well, that's kind of why that spec was written...
<Keybuk> no
<psusi> well the problem is that certain things that udev does automatically can cause breakage
<psusi> yea... the whole published flag bit
<Keybuk> udev doesn't do anything harmful automatically
<psusi> auto mounting? ;)
<Keybuk> udev doesn't mount anything
<psusi> it might not... but things higher up do
<Keybuk> *shrug*
<psusi> based on what udev has done and found
<Keybuk> it doesn't matter that it does the right thing or not
<Keybuk> it just matters that it's consistent
<Keybuk> and predictable
<Keybuk> if you want to do something other than the default, there are changes you make to do that
<psusi> the whole point of that spec was that there needs to be a way for the tools to explicitly let udev know it's ok to do all of its probulating and such, or not... it just can't decide reliably on its own
<Keybuk> right, and we have that mostly ;)
<psusi> hrm... though I suppose that in dmraid's case... as long as the synthetic devices get link priority that will fix that UUID problem
<psusi> AND lock out lvm from claiming the devices
<psusi> there's one bug I saw where a guy was trying to use lvm on top of dmraid and the lvm tools were trying to bypass dmraid and act directly on the underlying disk partitions
<psusi> we do?
<psusi> ohh, you were refering to the UUID part?
<nemo> hey folks.  Is there any reason /etc/init.d/rc.local does not have a stop section? 'cause is getting a little tedious to add a do_stop on my ubuntu machines and symlink it to the appropriate runlevels
<nemo> not to mention presumably will be a hassle in future updates at some point
<nemo> ... also not sure it is quite correct to symlink it to K00rc.local in 0,1,6
<Keybuk> nemo: why do you need one?
<nemo> Keybuk: well, for local stuff that needs cleaning up
<nemo> Keybuk: that's what that runlevel is for :)
<nemo> Keybuk: in this case, killing non-ubuntu handled services
<nemo> like my test servers
<Keybuk> nemo: why not just write your own init script?
<nemo> and unmounting CIFS shares
<Keybuk> why does the service need killing?
<nemo> Keybuk: because that's the appropriate place to put it?
<Keybuk> no
<Keybuk> rc.local is not appropriate for anything
<nemo> ok. let me rephrase.
<nemo> why does ubuntu not have a shutdown script section
<nemo> if that is not rc.local
<Keybuk> because that's not what rc.local is for
<Keybuk> it does
<nemo> which is...
<Keybuk> /etc/rc0.d and /etc/rc6.d
<Keybuk> put files in there
<nemo> *sigh* I mean a generic one similar to /etc/rc.local
<nemo> a convenient place for adding various user-specific shutdown commands
<Keybuk> because that would be silly
<nemo> no more silly than having an /etc/rc.local
<Keybuk> if you need to shut things down, you need more complicated care than "drop it here"
<Robot101> adding scripts to /etc/init.d *is* convenient :)
<Keybuk> we only have rc.local because some standards body says we should :-/
<Keybuk> most services don't need shutting down
<Keybuk> they get shut down automatically when the power goes away ;)
<nemo> Keybuk: the mounts are the big thing. vboxfs and CIFS in particular
<nemo> since otherwise they !@#$ up ubuntu on shutdown
<Keybuk> they're unmounted if they're in fstab anyway
<nemo> the application server, I like to do it a bit more tidily
<nemo> Keybuk: they get done in wrong order
<nemo> after the kernel unload
<nemo> thus fails.
<Keybuk> tidy => write an init script of your own and symlink it into the appropriate runlevels
<Keybuk> tidy != rc.local
<nemo> Keybuk: bah. whatever.  not going to write 3 scripts for just a few lines of cleanup.  I like rc.local, clearly you guys do not. question answered
<Keybuk> wherever we put the shutdown equivalent, it would not be in the right place for you
<Keybuk> the only logical place is right at the *start* of shutdown
<Keybuk> at that point, all the daemons are still running
<Keybuk> even X is still running
<nemo> absolutely
<Keybuk> so you inherently *CANNOT* unmount filesystems there
<nemo> perfect place for it
<nemo> that's why I have K00 there
<Keybuk> since the filesystems are still in use
<nemo> Keybuk: right. nice place for local shutdowns :)
<Keybuk> except it isn't
<Keybuk> what can you shut down from there?
<nemo> the 3 things I just mentioned.
<nemo> they all work fine
<Keybuk> no, you can't
<Keybuk> sorry, but I seriously doubt they work fine
<Keybuk> and if they do happen to, for some bizarre circumstance, work fine for you
<Keybuk> they would not work fine for everybody
<nemo> they work better than ubuntu freezing on shutdown, which is well covered in forums
<Keybuk> filesystems can not be unmounted reliably until all processes are killed
<Keybuk> ubuntu freezes on shutdown in its default configuration?
<nemo> well, yes, that's where a little common sense occurs
<Keybuk> do you have bug#s for that?
<nemo> Keybuk: if using CIFS mounts, yes
<Keybuk> how are you using the CIFS mounts?
<Keybuk> how come they aren't unmounted by S40umountfs ?
<nemo> ... userspace mounts. I have no control over 'em except  to clean 'em up
<nemo> Keybuk: perhaps because umountfs only checks fstab?
<nemo> instead of scanning mount table?
<Keybuk> how do you mount something not in fstab?
<nemo> haven't checked
<Keybuk> BZZZT
<Keybuk> umountfs scans /proc/mounts
<nemo> alrighty. well. it is missing 'em somehow
<nemo> or wrong order, or something.
<Keybuk> so that's a "bug" :-)
<nemo> anyway, plenty of others have run into it in forums
<Keybuk> not a reason to complicate the process even more
<Keybuk> have any of them filed bug reports?
<nemo> well. good to know, anyway, for me, rc.local works well :)  the vbox thing, no good workaround for that
<nemo> dunno. my issue was not about fixing that.  :-p
<Keybuk> vbox?
<nemo> that is only one of the things I use an initial shutdown script for
<Keybuk> why does vbox need to be shut down?
<nemo> Keybuk: you do the vboxfs kernel module load prior to loading fstab, and prior to unloading fstab
<nemo> so, any vbox mounts fail on startup/shutdown
<nemo> I have those in rc.local as a workaround
<nemo> and rc.local.stop :-p
<pitti> calc: can you please build the next OO.o against libneon27-dev instead of libneon26-dev?
<Keybuk> yes, but why do you need to do anything on shutdown?
<Keybuk> what are you doing there?
<nemo> Keybuk: 'cause otherwise the kernel module fails to unload cleanly?
<nemo> 'cause it complains about still being in use?
<nemo> Keybuk: anyway, those are two of 'em the third is issuing app server shutdowns.
<Keybuk> why is the kernel module being unloaded at all?
<Keybuk> why do app servers need to be shut down?
<nemo> having a local shutdown script section is not that unusual frankly
<nemo> not everything warrants an init.d entry
<nemo> Keybuk: dude. I've stopped caring long ago. there are reasons for it, clearly you don't feel they are legit, fine, that's why you don't have an rc.local shutdown section
<Keybuk> no
<Keybuk> they aren't reasons for it ;-)
<nemo> I appreciate you investing the time
<nemo> but. whatever.  if you fix the CIFS bug, I'll remove that section
<Keybuk> 95% of the things people try and do on shutdown are bogus
<Keybuk> the power is about to go away
<nemo> if you fix the vboxfs kernel module thing, great
<Keybuk> I have never seen any daemon continue to serve requests once the power has failed
<Keybuk> you don't need to stop them
<Keybuk> you don't need to unload kernel modules
<nemo> Keybuk: it is cleaner to issue a shutdown command then terminate the process - and I do like to give it a little bit more time
<Keybuk> you certainly don't need to free up memory
<ion_> That would probably be the first invention worthy of a software patent ever.
<Keybuk> no, it's not cleaner; it's a sign of an application bug
<Keybuk> if the app doesn't respond cleanly to SIGTERM, it's a bug
<nemo> but you know what. whatever. I feel I have a slightly better familiarity with layout here, but if you don't think it is appropriate, that explains why it isn't there nicely.
<nemo> not going to stress
<nemo> *sigh*
<nemo> bye. need to get back to work. thanks for taking initial time to respond
<nemo> the rest... meh
<Keybuk> read the "Teardown" spec for more detail
<Mithrandir> Keybuk: in some cases, you might want to shut down cleanly, think a database in the middle of a (long) transaction, but in the general case I agree with you.
<ion_> A database should have been implemented so in the first place that even if it segfaulted or power failed in the middle of a transaction, the cleanup on the next startup takes care of rollbacking it.
<Keybuk> yeah, but that slows down the next startup
<Chipzz> Keybuk: but typical database actions like inserting or updating a row take such a short time that it's better to let that operation finnish than to risk losing work
<Keybuk> Chipzz: I'm not disagreeing here ;)
<Mithrandir> ion_: they often do, but shutting down cleanly is better due to what Keybuk says.
<Keybuk> in fact, I'm agreeing
<bascule> having (minimally)searched launchpad I see no mention of a request for coloured output in apt(itude) for the shell, I think it would lend a great deal of readability and useful feedback to have coloured output text in apt-get/aptitude, any takers?
<calc> pitti: sure
<calc> pitti: i think the one in dep-wait is already against 27
<infinity> pitti: I'm satisfied with the debugsyms/mangler stuff in -proposed, now that I've eyeballed some logs.
<i00_000i> how to stop daemons from starting up automatically during booting
<pitti> infinity: ah, thanks
<mvo> elmo: I think  I have tracked down the problem with apt and libstdc++6 and the immediate configuration. it a missing propagation of the immediate configuration flag inside apts ordering code, I have a fix locally here that needs cleanup and testing (hopefully ready tomorrow)
<infinity> mvo: Thanks for that.  I've just finished manually upgrading all the chroots as a workaround, but it obviously needs sorting for users dist-upgrading.
<pitti> infinity: ah, cool; that means we can give-back failed packages now?
<mvo> infinity: thanks for that!
<infinity> pitti: I'm going to do a mass-give-back in about 2 mins (just shoving the new chroots into the librarian)
<pitti> infinity: ah, great, thanks
<infinity> pitti: Mass give-back done.
<pitti> infinity: that means I can kill all the FTBFS emails on sparc/powerpc?
<infinity> pitti: Yup, you'll get new ones.
<stgraber> scary, I was looking at the amd64 "needs building" queue, saw it empty and the second after it's >100 packages large :)
<pitti> infinity: hopefully not :)
<pitti> the ones I kept were all chroot problems due to that apt bug
<infinity> pitti: Ahh, well, you might get new ones with DIFFERENT failures! ;)
<pitti> :)
<mvo> more apt bugs!
 * mvo runs
 * pitti hugs mvo
<stgraber> asac: yeah, I was waiting for that Firefox3 upload (playing with very old computers and thin clients), thanks :)
<asac> stgraber: good ;) ... nss was stuck in NEW for some time :)
<ion_> stgraber: Beta2? Yeah, it would be nice.
<stgraber> according to hardy-changes it's pre-b3 release
<stgraber> (cvs snapshot)
<ion_> Ok
#ubuntu-devel 2008-01-03
<stgraber> asac: FF3 rocks, I just have some weird font size on LP (on +builds especially), everything else seems to work
<pitti> Good morning
<StevenK> Morning pitti
<LaserJock> morning pitti
<warp10> hi pitti, good morning!
 * pitti hugs the crowd
<YokoZar> what is the reason the old, unsupported repositories are deleted?  If I have a hoary installation now I can't even dist-upgrade it to breezy then dapper
<YokoZar> Or did they just get moved?
<LaserJock> I think they were moved
<YokoZar> LaserJock: know where are they moved to?
<YokoZar> ahh, old-releases.ubuntu.com
<soren> Over the last few days, I've gotten e-mails about failed builds of open-vm-tools on powerpc, ia64, and lpia. However, p-a-s says only to build them on i386 and amd64.. What gives?
<thegodfather> soren: that you should have mention this to #launchpad where it belongs?
<thegodfather> :)
<soren> Smart arse.
<soren> :)
<thegodfather> ahha
<soren> cjwatson_: I just stumbled upon a note saying that I should pester you about the debconf bug we worked out about a month ago.. It would probably be good to get it in in time for alpha 3. My note says the fix is in r2249, but I may have just noted that for SRU purposes.
<pitti> mvo: if you upload a new apt soon, can you please build it against libdb-dev instead of libdb4.4-dev along the way?
<mvo> pitti: sure, I fix this in bzr now
<pitti> mvo: *hug*, thanks
 * Fujitsu hopes for a new apt which fixes that libc6 issue.
 * pitti blinks -- php5 build-depends against libdb4.4 and depends against libdb4.5??
<Fujitsu> php5 and apache2 do evil things together, IIRC.
<soren> pitti: Erm.... That's a bit unfortunate. I received a patch that ought to have fixed that, but apparantly it didn't.
<pitti> soren: I'll clean it up
 * soren hugs pitti
<soren> pitti: Thanks!
<pitti> soren: I just uploaded apr-utils to link against db4.6, and preparing subversion to do the same
<pitti> (since they need to go in lockstep)
<pitti> once these are built, we can build php5 against db4.6, too
<soren> php5 /needs/ to follow suit as well.
<pitti> soren: patch> anything complicated, or just the usual 'switch version numbers' build stuff?
<pitti> soren: right, at it; but apr-utils needs to build first before we can upload svn and php
<soren> pitti: The latter.
<soren> pitti: Sure, sure.
<pitti> right
<soren> pitti: debian/patches/use-specific-libdb-version.patch
<pitti> soren: that's applied in hardy
<soren> pitti: Yes?
<soren> pitti: ...and that's the one you probably want to remove.
<soren> pitti: We're not talking hardy stuff here?
<pitti> soren: I think I need to keep the patch and make it check for 4.6 (it only checks up to 4.5 upstream)
<soren> pitti: Ah, yes. That sounds right.
<mvo> Fujitsu: I'm working on a fix for this currently, would you like to help and test it once its ready?
<Fujitsu> mvo: Sure, I've got a test environment in schroot here from when I was debugging it in the first place.
<mvo> Fujitsu: cool! thanks
<Fujitsu> I'm glad it turned out to be an apt bug and that I wasn't missing something simple.
<persia> archive-admins: I've been reviewing Debian changes, and pushing sync bugs, and notice that the holiday backlog is becoming large.  Is this expected, or would it be helpful for me to process syncs rather than just pushing bugs?
<pitti> persia: we'll get to it; what do you mean with 'process syncs'? using my script?
<persia> pitti: precisely
<pitti> persia: if there are urgent ones which block work, feel free to do so, but the bulk should be done with the soyuz tool IMHO
 * Fujitsu wishes for a `sync' button.
<persia> pitti: It's the opinion I sought.  Nothing urgent, I just saw the U-A queue was over 100 bugs, and didn't want to be causing lots of extra work.  Thanks.
<pitti> carlos: btw, any idea when we can get hardy langpacks?
<Fujitsu> Or universe langpacks?
 * Fujitsu hides quickly.
<pitti> persia: hm, since my box is currently building three huge packages in parallel and can't do much more, I'll do some syncs now :)
<persia> pitti: Thanks.  There's a heap of apache (1) related removals in queue as well.
<Fujitsu> Yay! Kill kill kill!
 * persia thanks awen for aggressive research to hunt them down and explain why they must die (including updating those that could be rescued)
<pitti> persia: yummy
<StevenK> Yay! Die, apache 1!
<Fujitsu> Apache 1 is long dead.
<StevenK>           rescued)
<StevenK> Ooops
<mvo> Fujitsu: do you prefer a patch or a package to test my fix? (if package, what arch?)
<Fujitsu> Nice job.
<carlos> pitti: I don't know. Seems like the initial Hardy opening failed
<StevenK> steven@liquified:~% HEAD http://wedontsleep.org/ | grep Server
<StevenK> Server: Apache/2.2.6 (Ubuntu) mod_ssl/2.2.6 OpenSSL/0.9.8a
<carlos> pitti: I'm not working in Translations this month, let me check with jtv...
<StevenK> That was my pain to do last night ^
<pitti> carlos: ah, I see
<Fujitsu> mvo: It only takes a couple of minutes to build, but a binary is always nice, if you can do i386.
<mvo> Fujitsu: please give http://paste.ubuntu.com/3244/plain/ a try, works on my test-case
<Fujitsu> mvo: Looking;
<carlos> pitti: jtv tells me that the copy from Gutsy is already done, he's going to do some extra testing today and start importing Hardy's files
<carlos> pitti: it would take around a week to get everything imported (at least the basic parts)
<pitti> hm, that sounds like the status we had one week after opening hardy
<carlos> pitti: do you want a language pack export with the translations from Gutsy or wait until we catch up with all translated files from Gutsy?
<carlos> pitti: yeah, although seems like he detected an error and he had to revert the opening
<pitti> carlos: no, we only need a current hardy one
<pitti> we already have the ones from gutsy
<carlos> pitti: I mean to generate a Hardy one with gutsy data
<pitti> carlos: right, I understand; however, we already have that
<carlos> ok
<carlos> so you prefer to wait until Hardy translations are mostly imported
<Fujitsu> mvo: Works fine on the two broken setups I had here.
<mvo> Fujitsu: nice! thanks for testing
<Fujitsu> mvo: Thanks for fixing it.
<Fujitsu> Do we know why this only appeared last week?
<mvo> Fujitsu: not in detail, something in the dependencies must have changed to trigger it. but it seems like this is a old bug.
<mvo> Fujitsu: it seems like it was pure chance that we did not hit it earlier
<Fujitsu> Ah.
<mvo> but its only triggered when essential=yes packages are involved and there are not that many of those
<persia> pitti: Why do my sync bugs need an ack from a MOTU?
<pitti> persia: they don't?
 * persia hunts down the source of the confusin
<pitti> persia: I subscribed ubuntu-universe-sponsors to three sync bugs from non-MOTUs
<pitti> you might have gotten the bug mail
 * TheMuso saw those.,
<persia> pitti: Actually, I apparently forgot to include "ACK" when updating those decriptions.  Fixing now (after solidly thwacking self)
<Tonio_> hello everyone and happy new year
<pitti> hi Tonio_! and to you!
<Tonio_> hey pitti :)
<Hobbsee> wow, something's borken
<Hobbsee> asac: erm, does thunderbird need to be built for the new libnss stuff?
<asac> Hobbsee: hmm ... in a perfect world this wouldn't be needed
<asac> i think i tested it
<asac> what happens?
<Hobbsee> asac: the 2 libnss versions have file conflicts.
<Hobbsee> so by force overwriting with the firefox-3.0 version, i get a message in thunderbird about teh security components being disabled (there is more to that message, but that's the gist)
<asac> if installed it works for me
<asac> which version do you have installed?
<Hobbsee> ahhh
<asac> Hobbsee: 3.12.0~1.9b2+nobinonly-0ubuntu1 thats what i have
<asac> libnss-0d + libnss-1d
<Hobbsee> asac: sorry, it's Ubulette's version, from when i was using those firefox packages
<Hobbsee> as beta 2 hadn't hit the repos yet
<asac> ah right ... the versioning is borked in his archive
<Hobbsee> well, even so
<asac> just --reinstall with the official sources
<Hobbsee> but downgrading to the one in the archive brings it back correctly
<asac> yep
<asac> ok thanks
<Hobbsee> asac: sorry for the wrong poke :(
<asac> welcome
<StevenK> asac: Mind looking at the libtinymail 0.0.6 FTBFS? It built for me locally.
<asac> StevenK: thought you didn't use xulrunner for now? (but gtkhtml) ?
<asac> ripping out 99.9% of the gtkmozembed patch? you have an interdiff for that?
<StevenK> I ripped out 99.9% because I thought it was applied upstream
<StevenK> asac: http://wedontsleep.org/~steven/xul-005-006-inter.diff
<StevenK> Although, that thought did occur while updating to 0.0.6
<StevenK> asac: Never mind about it now, I'll dump that patch and fix it to use gtkhtml.
<StevenK> asac: Thanks, I'm now remembering what happened in the dim dark recesses the last time I touched this thig.
<pitti> Riddell: soprano> can you please use Xbuild1 versions for these 'fake' syncs?
<asac> StevenK: all this XPCOM_GLUE code was needed ... otherwise it won't really work.
<StevenK> libtool, I am going get you. And then I'm going to eat your liver.
<Riddell> pitti: would that not be in danger of having broken syncs in future if it tried to sync but the .orig didn't match?
<StevenK> libtool: link: cannot find the library `/usr/lib/libdirectfb.la' or unhandled a
<StevenK> rgument `/usr/lib/libdirectfb.la'
<pitti> Riddell: right, but it gets autosynced as soon as Debian has a new upstream version
 * pitti hugs StevenK
<StevenK> Right, libdirectfb doesn't provide a .la anymore
<StevenK> directfb (1.0.1-1) experimental; urgency=low
<StevenK> ...
<StevenK>   * Do not ship the .la files in libdirectfb-dev.
<StevenK> ARGH!
 * StevenK adds Guillem Jover to his liver-gram list, and looks at slangasek.
<StevenK> pitti: So, do we add back the .la file and clean it, or what?
<asac> pitti: will there be a PK privilege for "can user install package" ?
<pitti> StevenK: or rebuild all dependencies?
<pitti> asac: nope, we don't have packagekit yet
<StevenK> pitti: I've had to any way -- NBS. But one of them wants the .la
<pitti> asac: for that you should call synaptics or gnome-app-isntall (the latter already has the gksu stuff)
<asac> ok ... but if we had it, would there be an easy why to query if current user would have that privilege?
<pitti> asac: you can ask PK to grant it, yes (dbus call)
<asac> well ... i need to decide on whether to provide users with a "install package" feature (e.g. plugin finder dialog in firefox)
<pitti> asac: it'll either answer YES (you got it), NO (you can't get it), or NO_AUTH (you don't have it, but can enter your password to get it)
<asac> ah good
<asac> so NO_AUTH would be it
<pitti> asac: but don't count on this for hardy
<pitti> asac: for that I'd just check if the user is in group admin
<asac> yeah ... i think we just look for admin group for now
<pitti> and if so, call gksu synaptic or so
<asac> ok great ... i won't implement it right away anyway. just was curious if there is a real solution on the radar :)
<pitti> yes, there is; depending on when/whether packagekit ever gets ready
<asac> ;)
<afflux> apport doesn't generate crash reports anymore on my hardy system, but I have some cases where I'd like to see one. Can you give me a hint on how to re-enable apport?
<pitti> afflux: are you running the 2.6.24 kernel?
<afflux> no
<pitti> afflux: current apport needs it
<afflux> ah
<pitti> afflux: 2.6.24 finally adopted some patches which are needed for apport, but implements them slightly differently
<afflux> I see... I didn't switch because it was so slow :(
<pitti> so it won't change again in the future at least
<pitti> yeah, I noticed some slowdown, too, but it was mostly subjective; a hard timing on boot speed didn't reveal any difference
<afflux> Most applications, especially firefox or even gnome were starting really slow.
<afflux> anyway, I'll have a try again
<afflux> thanks
<TheMuso> Can I safely assume that fontforge having a dependency wait on a package in universe, libspiro-dev is known, and that someone plans to either MIR libspiro-dev, or upload a fixed fontforge? If not, I'll file a bug
<Hobbsee> TheMuso: oh, grrr.  i relinquish my TIL responsibility, as i did not cause that bug.
<TheMuso> TIL?
<Hobbsee> touched it last
 * Hobbsee just uploaded a rebuild of it
<TheMuso> oh
<Hobbsee> asac: exaile's broken :(
 * TheMuso thinks we need a script to check that a source package's build-deps are all in main, if we don't have that already.
<Hobbsee> TheMuso: there is one
<TheMuso> Oh ok.
<TheMuso> Hobbsee: What is it?
<StevenK> http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<Hobbsee> TheMuso: i think it's in ubuntu dev tools
<Hobbsee> StevenK: no, not that
<StevenK> Surely that tells most of the story?
<Hobbsee> StevenK: only after it's been uploaded, yes.
<TheMuso> StevenK: Preferably something to check before one uploads.
<TheMuso> Ah yes, 404main
<Hobbsee> that's the one.
<mvo> a new apt is uploaded that should fix the issue with the libstdc++6 configure problem - please let me know if there are still issues or if it has unintended side-effects
<asac> Hobbsee: exaile? universe? already ported to xul?
<Hobbsee> asac: unsure on porting status.
<Hobbsee> asac: but yes, the one in universe
<Hobbsee>   File "/usr/share/exaile/xl/mozembed.py", line 29, in <module>
<Hobbsee>     import gtkmozembed
<Hobbsee> SystemError: dynamic module not initialized properly
<StevenK> Mmm, yummy.
<Hobbsee> location: /usr/lib/xulrunner-1.9b3pre/libxpcom.so
<Hobbsee> before 3
<asac> Hobbsee: which version of python-gnome2-extrase?
<Hobbsee> asac:
<Hobbsee> python-gnome2-extras:
<Hobbsee>   Installed: 2.19.1-0ubuntu6
<asac> damn ... i forgot to add a the version to the build-depends
<asac> Hobbsee: anyway, pitti uploaded ubuntu7 ... which should be built agains the right xul (because its already avail)
<asac> try to upgrade to that
 * Hobbsee updates, again
<pitti> asac: btw, great ffox-3.0 upgrade! feels much better now, although it still doesn't support adblock and flash :/
<ion_> Adblock Plus works for me.
<ion_> It probably should be used instead of the old Adblock anyway.
<asac> flash is updated as well pitti
<Hobbsee> pitti: why no flash?  no gnash?
<pitti> ion_: oh, wasn't aware of that
<stgraber> hmm, I have Adblock plus and flash9 working here
 * Hobbsee hasn't played with flash.  it just works
<stgraber> Only problem I see with FF3 is broken LP layout on some pages ...
<pitti> asac, Hobbsee: I'm using the non-free plugin with nspluginwrapper (amd64)
<ion_> Flash didnât work for me out of the box either, but i havenât cared about it enough to investigate yet.
<ion_> (32-bit)
<pitti> gnash crashes way too often for me
<pitti> I should try it again, though
<stgraber> running flash9 + nspluginwrapper on ff3 here and works fine
<pitti> asac: but anyway, when I open a page with flash, the ffox plugin search does not offer me anything, neither macromedia's nor gnash
<pitti> in ffox 2 it works fine
<ion_> I take it the Flash plugin should go to /usr/lib/firefox-addons/plugins to work with FF3? The dirâs empty.
<asac> pitti: ah :)
<asac> pitti: ffox 3 doesn't have ubufox yet ... just install flashplugin-nonfree
<asac> i updated it today to install links to xul 1.9
<pitti> ah, ubufox
<stgraber> ah yes, I had to copy some symlinks IIRC to have my plugins to work with FF3
<pitti> asac: I have that installed already (for ffox 2)
<ion_> asac: Ok, the update probably just hasnât reached my mirror yet.
<asac> pitti: then wait for upgrade
<asac> most likely
<asac> the upgrade should install the flashplayer-alternative.so in /usr/lib/xulrunner-addons/plugins/
<asac> https://edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/9.0.115.0ubuntu3
<seb128> asac: does that mean all the plugins packages should be transitionned?
<stgraber> asac: what about totem and vlc plugins ? I have those two in FF2 but I had to copy the symlinks by hand to have them working with FF3
<asac> seb128: well ... totem not yet .. it uses some parts of xul api, so we can build either/or ... the other plugins should be upgraded now
<asac> stgraber: most likely vlc can be migrated ... maybe the current .so just works when linked to the plugins dir?
<asac> stgraber: old totem works for you?
<asac> (in new ffox)?
<stgraber> nope, just gave it a try and FF3 crashed
<asac> yes
<asac> vlc?
<stgraber> trying vlc now
<stgraber> I have a "no video" text appearing but it's probably a video codec issue as audio is ok
<stgraber> trying mplayerplugin now
<asac> stgraber: the no video text is rendered by the vlc plugin ig guess?
<stgraber> asac: yes
<stgraber> mplayer works fine
<stgraber> so both can be migrated
<asac> good ... they should be built against xul 1.9 though
 * mvo wonders if anyone else got a "primaty superblock features different from backup, checked forced" recently
<geser> mvo: I've seen it too when I upgraded from gutsy to hardy
<afflux> mjg59: a number of people (I know some in the german forum.ubuntuusers.de) complain about not having s2ram in the uswsusp package and having no real statement of developers in bug #134238. They think that actually having s2ram is not more confusing than hiding it in uswsusp. Maybe you can have a look at the bug and give your statement. :)
<ubotu> Launchpad bug 134238 in uswsusp "Please re-enable build of s2ram binary" [Wishlist,Confirmed] https://launchpad.net/bugs/134238
<mvo> geser: thanks, found the report about it now
<bluekuja> pitti, up for a question?
<pitti> bluekuja: please don't ask to ask, just ask :)
<bluekuja> pitti, Debian's gmsh is missing 2.0.7-1.1 changelog's entry (maybe the maintainer did not acknowledge the NMU) but Ubuntu got it (2.0.7-1.1ubuntu1)
<ion_> bluekuja: Up for an answer to your question regarding whether pitti is up for a question?
<bluekuja> pitti, should I keep it as valid?
<bluekuja> ion_, lol
<pitti> bluekuja: 'keep' -> you mean when merging it and writing the changelog? sure, can't hurt
<bluekuja> ion_, just wanted to know if he was around, don't get angry now
<bluekuja> pitti, yep, I mean adding that entry each time (e.g with other ubuntu entries)
<bluekuja> pitti, thanks for the hint
<pitti> bluekuja: 'each time' -> 'once', i.e. right now?
<bluekuja> pitti, why once? if the debian package arrives to ubuntu without that entry, I should add it every time
<bluekuja> pitti, as a remaining change then
<pitti> bluekuja: right; well, if it causes any trouble, just drop it
<bluekuja> pitti, so I drop it, but I keep the ubuntu entry derived from that one, right?
<bluekuja> pitti, e.g I remove 2.0.7-1.1 but I keep 2.0.7-1.1ubuntu1
<pitti> bluekuja: yes, please keep all ubuntu changelogs which were ever uploaded
<pitti> yes
<bluekuja> pitti, great, thanks
<mvo> soren: meh, kvm does no longer work for me (on amd64), do you know anything about this? unahndled vm exit: 0x0 vcpu_id 0 (I can report a proper bug if you want)
<soren> mvo: After today's update?
<soren> mvo: Is your kernel up-to-date?
<mvo> soren: kvm is 1:59+dfg-0ubuntu1 and kernel is 2.6.24-2.4 (upgraded a couple of minutes ago)
<mvo> kvm -no-kvm works ok
<soren> mvo: A bug report would be nice. I'll look into it *real* soon, there' just something else I need to get out of the way first.
<mvo> soren: sure, thanks
 * soren takes a quick break
<mvo> soren: LP 180105
<ubotu> Launchpad bug 180105 in kvm "unhandled vm exit" [Undecided,New] https://launchpad.net/bugs/180105
<mvo> (just FYI)
<wasabi> apt question using a recent example:   new mono package 1.2.6, it apparently no longer provides the package 'mono'. So, my system refuses to upgrade to 1.2.6 safely because doing so would cause a conflict with 'mono' 1.2.4.  Should this be bypassed because a given package should declare it Replaces 'mono'?
<rpereira> Hey everybody. Does someone knows why epiphany-webkit isn't on hardy repository?
<soren> mvo: Could you try using the modules from the kvm package? Just "sudo m-a a-i kvm; sudo rmmod kvm-intel; rmmod kvm ; sudo depmod -a ; sudo modprobe kvm-intel" ought to do it.
<mvo> soren: sure, I will do that once my current vm session has ended
<soren> mvo: Cool.
<soren> mvo: Are you on intel hardware?
<mvo> soren: no, amd64
<soren> mvo: Well, that's what we call 64 bit Intel as well :)
<mvo> eheh
<mvo> its a amd-v
<soren> I run the amd64 version on Intel Core 2 Duo.
<soren> mvo: I see.
<soren> mvo: This happens with all images?
<geser> I looked at the fakeroot FTBFS and tracked it down to the configure check if shell understands "+=" but I fail to understand why the check succeeds and how to fix it.
<soren> Oh, if it's amd, you of course rmmod kvm-amd, but you probably guessed :)
<mvo> soren: I tested only two images that are very similar (one is the other a bit later in time) - I can test more
<soren> mvo: Can you boot an iso at all?
<soren> mvo: Fantastic. That's broken, too.
<mvo> soren: rebuilding the kvm module seems to have done the trick
<soren> mvo: eh? That worked.
<soren> mvo: I mean: What worked?
<soren> fsck... Typing is hard.
<soren> I'm trying to express my confusion that m-a managed to build the modules. It's failing to build here.
<mvo> soren: it looks like everything is back to normal with it, booting my test-image works, booting a iso works too
<soren> mvo: I know there was an issue in 58, but I thought it had been fixed in 59, but you seem to be right.
<mvo> soren: so 59 is ok for me now (after rebuilding the modules)
<soren> mvo: Noted.
<mvo> thanks for your help soren
<soren> mvo: Thanks for pointing it out. I'm a bit confused how that slipped through.
<soren> mvo: I've got a fix that I need to test. I'll have it uploaded so that there's a fresh, working version for you tomorrow morning.
 * soren has to run for a few minutes.
<mvo> soren: woah, that was quick! thanks a lot
<geser> pitti: have you an idea what happened to the libsaxon-java binaries you moved from multiverse to universe in december ? they are gone
<geser> it looks like soyuz ate all arch:all packages from the packages moved in bug #176139 :(
<ubotu> Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Fix released] https://launchpad.net/bugs/176139
<tjaalton> humm, the flac security update on November seems to have broken xmms-flac (bug 162704)
<ubotu> Launchpad bug 162704 in flac "[Feisty] update of xmms-flac disables plugin" [Medium,Confirmed] https://launchpad.net/bugs/162704
<Mez> tjaalton, I read that as "xmas-flac" - was thinking that it should have be reported in December ;)
<tjaalton> Mez: hehe :)
<geser> is the libstdc++6 upgrade error back in the powerpc buildd chroot?
<slangasek> StevenK: um... but directfb stopped shipping that .la file a month ago in unstable, and it doesn't seem to have caused problems (presumably due to an accompanying soname change?)
<pitti> geser: boggle
<pitti> cprov: any idea where the libsaxon-java binary went to in hardy? I just moved it from multiverse to universe a while ago
<cprov> pitti: no, let me check
<cprov> pitti: both superseded ? https://edge.launchpad.net/ubuntu/hardy/i386/libsaxon-java/+index
<pitti> cprov: it hasn't changed since edgy, might that be the reason?
<cprov> pitti: no, the superseded message doesn't make sense
<pitti> cprov: yeah, it's superseded by its own version
<pitti> argh, subspace will implode!
<geser> pitti: didn't get the powerpc chroot fixed or is it broken again?
<pitti> geser: it was fixed; might be broken again
<pitti> infinity: ^ any idea? mvo uploaded a fixed apt today, but I guess it requires manual intervention to get that one into the broken chroot
<geser> the last build logs for powerpc have "E: Internal Error, Could not perform immediate configuration (2) on libstdc++6" again
<infinity> Ungh, broken again?
<infinity> geser: Example log?
<geser> infinity: http://launchpadlibrarian.net/11137476/buildlog_ubuntu-hardy-powerpc.peercast_0.1218%2Bsvn20071220%2B2-1_CHROOTWAIT.txt.gz
<infinity> Oh, hahha.
<infinity> There was both a new GCC and a new glibc (the precise thing required to trigger the bug) between when I fixed the chroots and when mvo fixed apt.
<infinity> \o/
<infinity> I'll re-fix them shortly.
<cprov> pitti: there might be something wrong in the domination procedure, triggered by the override you've done on 21th Dec. Please, file a bug I will investigate it tomorrow
<geser> cprov: is bug #178102 the same problem?
<ubotu> Launchpad bug 178102 in soyuz "(Quick) promotion and demotion can lose binaries" [Undecided,New] https://launchpad.net/bugs/178102
<cprov> geser: yes, it's a problem in the arch-indep domination procedure
<dBera> Hi. debian unstable has beagle-0.3.2 while ubuntu (hardy) still has 0.2.18
<dBera> isnt there some automatic way to sync from debian packages ?
<pitti> dBera: there is, but our version has Ubuntu changes which need to be merged
<dBera> pitti: ok. is there any public website where i can glance at the changes ?
<pitti> dBera: there's patches.ubuntu.com which has all our changes relative to Debian
<pitti> dBera: merges.ubuntu.com should have it, too
<dBera> pitti: this one ? http://patches.ubuntu.com/b/beagle/beagle_0.2.18-0ubuntu3.patch
<pitti> dBera: probably quite messy, since we had a new upstream version earlier
<pitti> dBera: so some filterdiff -i '*/debian/*' is in order, I think
<dBera> pitti: the earlier patch is weird! it contains who new files which were present earlier. a few of the changes are probably ubuntu specific, can't tell for sure
<dBera> did UVF already happen ?
<pitti> dBera: this does not exist any more; feature freeze is in Feburary, see HardyReleaseSchedule
 * dBera checks
<dBera> pitti: ok thanks. the earlier 0.3.2 gets into hardy the better. we can then get some feedback from hardy testers and make at least one bugfix release before hardy ships.
<pitti> dBera: it's still on the 'must do' todo list on http://merges.ubuntu.com/main.html
<pitti> bryce: hm, is it just me or a ffox 3.0 bug or is http://people.ubuntu.com/~bryce/Plots/ just empty and brown?
<bryce> hi pitti; could be a bug... it works ok on ff 2.0
<pitti> hm, so it does
<bryce> is ff3 on hardy?  I could give it a spin on my other machine
<pitti> rad
<pitti> bryce: yes, I'm using the hardy packages (as I understand it they'll become the default soon)
<\sh> pitti: it works with konqueror...;)
<brettalton> how do you get around using 'sudo' with Python?
<\sh> brettalton: check out update-manager :) it's python and using sudo (gnome version)
<brettalton> \sh: http://archive.ubuntu.com/ubuntu/pool/main/u/update-manager/update-manager_0.81.tar.gz ???
<calc> any java packaging people around, i need to fixup a package to get it into main
<calc> and i am running into a weird error message
<\sh> brettalton: yepp
<brettalton> \sh_away: they use gksu
<brettalton> thanks
<geser> calc: try asking man-di, he's in #ubuntu-motu and #ubuntu-java
<calc> geser: ok
<alex-weej> are we using upstart to its full potential yet?
<Mithrandir> no, I would not say so.
<alex-weej> is it just a matter of manpower to write scripts?
<TheMuso> I don't think upstart has all the originally planned features yet.
<ion_> benc: Sigh, nvidia_supported seems to be incompatible with the current nvidia-glx-new. Iâll take a look at it today.
<ion_> tepsipakki: â
<ion_> Oh, heâs not around.
#ubuntu-devel 2008-01-04
 * lamont2 grumbles at this stupid computer
<StevenK> [13:41] -!- lamont2 is Jennifer
<ion_> If it were intelligent, it might grumble at you.
<lamont2> StevenK, yeah - I'm helping my wife's friend
<StevenK> Ahh
<lamont2> stupid thing is refusing to read DVDs - throws I/O errors left, right, and sideways
<lamont2> 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-756 [Viper] IDE (rev 03)
<lamont2> I think I'll boot back up into -14.47 and (1) see if that makes a diff, and (2) actually look at the boot log
<lamont2> back in a few
<vlowther> quick question:  when did Hardy switch from the old /etc/acpi power management scripts to using hal/pm-suspend and friends?
<mjg59> When hal 0.5.10 got uploaded
<vlowther> ... a couple of days ago, I assume?  I need to tell pm-suspend to stop messing with the video adaptor (nvidia on a laptop does not appreciate something else posting it or messing with VBE) -- where are those conf files?
<mjg59> No, a couple of months ago
<mjg59> Using the non-free driver?
<vlowther> of course.  It does not work at all with nv. :/
<mjg59> It's likely that we should just leave things up to the nvidia kernel module if it's loaded
<mjg59> I'll look into handling that
<vlowther> ya -- in the mean time, though, config files/gconf keys?
<lamont2> Jan  3 19:53:25 jennifer-desktop kernel: [  142.189950] ide: failed opcode was: unknown
<lamont2> le huh?
<mjg59> /usr/share//usr/share/hal/fdi/information/10freedesktop/
<mjg59> Erm.
<mjg59> /usr/share/hal/fdi/information/10freedesktop/
<vlowther> ok
<vlowther> danke
 * lamont2 considers the option of replacing the computer with something newer than a k7-600 and bringing this one home to debug
 * lamont2 tries checking the UI^)^ strapping on the drives. :-)
 * lamont2 tickles Hobbsee 
 * Hobbsee tickles lamont back
<vlowther> mjg59: how about a bug with a patch that works around the issue for now?
<vlowther> mjg59: bug #180250 filed against hal.  The attached patch Works For Me (tm).
<ubotu> Launchpad bug 180250 in hal "system fails to resume in Hardy with non-free nvidia driver" [Undecided,New] https://launchpad.net/bugs/180250
<mjg59> vlowther: Hm. I'd rather put that in pm-utils itself, I think
<mjg59> vlowther: Very similar code, but in pm/hooks/99video
<vlowther> mjg59: sorry, where?
<Hobbsee> heh, pitti got hit by a lp bug last night.  same as the one found at christmas
<somerville32> for a second I read bus...
 * lamont arrives home
<lamont> hi Hobbsee
<LaserJock> somerville32: hmm, I did too
<StevenK> PONIES
 * StevenK works on LaserJock's complex
<LaserJock> StevenK: for goodness sakes ;-)
<lamont> StevenK: PONIES????  kewl!
<Hobbsee> LaserJock: yes, ponies!
<ScottK> Did someone say Ponies?
 * LaserJock hides
<CarlFK> send host-name "<hostname>"; is no longer in dhclient.conf - is there somewhere I can see why?
<pitti> Good morning
<StevenK> pitti: Hi! Could I convince you to sync bug 180274?
<ubotu> Launchpad bug 180274 in bluez-libs "Please sync bluez-libs (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/180274
 * pitti NEWs the kerrnel
<pitti> StevenK: sure
<StevenK> pitti: Thanks
<pitti> StevenK: I'll process all syncs today anyway, but let me do this one first if it's urgent
<StevenK> pitti: Nah, not urgent, just want it done
<StevenK> pitti: I'm about to go out to the movies. If it's published and built when I get back, I'll be happy. :-)
<pitti> enjoy!
<StevenK> pitti: Thanks :-)
<tjaalton> pitti: good morning, would you consider doing some promotions to main (xserver-xorg-video-openchrome, considered to replace -via as default, and xserver-xorg-input-vmmouse)?
<pitti> tjaalton: please file a main promotion bug to leave some paper trail, I'll have a look at them
<pitti> tjaalton: they sound fine, I don't expect that a MIR wiki page will be necessary
<tjaalton> pitti: bug 69780 for vmmouse
<ubotu> Launchpad bug 69780 in xserver-xorg-input-vmmouse "Vmmouse package should be in main instead of universe" [Wishlist,Confirmed] https://launchpad.net/bugs/69780
<tjaalton> I'll file one for openchrome, thanks!
 * Fujitsu hopes they don't have arch-indep bits.
<tjaalton> Fujitsu: what do you mean?
<tjaalton> pitti: bug 180277 for openchrome
<ubotu> Launchpad bug 180277 in xserver-xorg-video-openchrome "Please promote openchrome to main" [Undecided,New] https://launchpad.net/bugs/180277
<Fujitsu> tjaalton: Well, there's this nice Soyuz bug #178102.
<ubotu> Launchpad bug 178102 in soyuz "(Pro|De)motion loses arch: all binaries" [Critical,In progress] https://launchpad.net/bugs/178102
<tjaalton> Fujitsu: ah, no they all should be arch: any
<tjaalton> well, vmmouse is arch: i386 amd64, but anyway :)
<tjaalton> (which I think openchrome should be as well)
<tjaalton> pitti: I'm out for the most of the day, so I hope that's all you need :)
<tjaalton> gone ->
<slangasek> pitti: congrats on the db4.3,db4.4 demotions; but do you know why db4.2 and db4.3 packages are seeded in server-ship?
<pitti> slangasek: hysterical raisins; I'm just at fixing that
<slangasek> ok :)
<pitti> so we'll soon have just 4.2 and 4.6
<slangasek> \o/
<pitti> we might ignore the performance issue on openldap and just convert that to 4.6, too, but I'd rather have Debian's consent for that
<slangasek> pitti: I think that's a pretty poor trade-off in an LTS, given how much attention there was on LDAP at UDS
<pitti> right
<slangasek> we've more or less decided in Debian to postpone the switch to db4.6 for OpenLDAP until there's a resolution of the performance issue, which I'm told is pretty severe
<pitti> I read it in the bug, yeah (factor 2 on some operations)
<slangasek> hmm, should get around to uploading that one of these days though so we can knock libldap2 off the todo list :)
<pitti> slangasek: I just wonder why the client lib needs libdb, too
<pitti> both openldap2{,.3} b-dep  on libdb4.2-dev
<slangasek> oh, I'm pretty sure the client lib doesn't need it
<slangasek> but the openldap2 package is abandonware :P
<slangasek> and was only minimally stripped down to build the client lib without the rest of the binaries when slapd was moved
<pitti> ok, seeds updated to drop db4.[23]
 * slangasek nods
<slangasek> hmm, you've switched cyrus-sasl2?  does that mean the compatibility issues have been resolved?
<pitti> slangasek: which issues? it doesn't use transactions?
<pitti> s/?$//
<pitti> doko_: what does expect-tcl8.3 [!none !hurd-i386] mean? (gcj-4.2 b-dep); can we drop expect-tcl8.3 now?
<pitti> slangasek: in the Debian bug, the DDs didn't generally object to switching
<pitti> slangasek: Russ just confirmed that db4.6 should perform better for cyrus than 4.2
<doko_> pitti: yes, we can
<pitti> doko_: anastacia wants it to come back due to that b-dep
<doko_> fix anastacia ;-)
<pitti> well, !none looks like 'true' to me :)
<doko_> anyway, I'll upload gcj-4.2 as well
<pitti> ah, ok; I thought you did already
<pitti> doko_: thanks muchly
<slangasek> pitti: there were some concerns specific to compatibility with cyrus-sasl2 raised by folks involved with cyrus-sasl2 maintenance; I'm trying to find a reference
<slangasek> I don't know why there wasn't an open bug report against cyrus-sasl2 requesting the switch
<slangasek> (other than people being sloppy because they hate me)
<slangasek> pitti: heh, yes, anastacia is parsing [!none] correctly...
<pitti> slangasek: maybe it does, I just personally don't know what !none is good for :)
<Mithrandir> pitti: probably just as useful as !fish or !fowl
<pitti> ah, so it's not magic
<Mithrandir> doesn't look like it, no.
<doko_> pitti: [] is a parse error, but [!none] did still work
<slangasek> pitti: infuriatingly, I'm not finding anything about sasl/db as far back as 2005 in the mail archive; so I guess we may as well go with it and watch for any bug reports
<slangasek> doko: it "works", but it means expect-tcl8.3 is a build-dep on all archs; which is the behavior you suggested should be "fixed" in anastacia...?
<doko> slangasek: yes, that was the meaning I intended; anyway, we don't run the testsuites on hppa anymore, and therefore it's dropped (until lamont fixes expect on hppa)
<Arelis> Hi all. I made a script in bash that downloads stuff from youtube, pulling all the files from a list, and then gives you the option to convert it to OGG or MP3. Can anybody turn that into a full-fledged, graphical program? This is the script: http://paste.ubuntu-nl.org/50688/
<doko> pitti: should we address libgif/libungif in ReducingDuplication as well?
<pitti> doko: there's an ubuntu-archive bug about this transition; yes, I plan to get rid of ungif
<Chipzz> Arelis: 1) this channel is about development of ubuntu, not with (see topic); not 100% sure, but #ubuntu-motu may be a little more appropriate; 2) mplayer has synchronisation issues with .flv files, not sure if you care about that; 3) no offence meant, but your script looks like a real hack to me (launching nautilus??)
<Arelis> Chipzz: it still is hacky. That's why i want someone else to turn it into a full-fledged program. And sorry, somebody in #ubuntu-offtopic pointed me here.
<dan_> it's not so much 'turn into' as 'why not write a youtube downloader' :)
<soren> mvo: Any luck with the new kvm?
<soren> mvo: Remember that kvm-modules puts in diversions and such, so you need to remove kvm-modules-`uname -r`, do the depmod-rmmod-modprobe thing again.
<mvo> soren: testing now
<mvo> soren: yeah, works fine again, thanks
<soren> mvo: Excellent.
<nenolod> pitti, you about?
<pitti> nenolod: yes, I'm just closing all your sync requests :)
<nenolod> pitti, could you look at the ia32-libs thing too? i CC'd you because you were last uploader
<pitti> nenolod: please define 'ia32-libs thing'?
<nenolod> one moment
<nenolod> pitti, #179031
<pitti> bug 179031
<ubotu> Launchpad bug 179031 in ia32-libs "lib32/libSDL depends on old libraries and needs to be rebuilt, add libao2 (for zsnes in amd64)" [Undecided,New] https://launchpad.net/bugs/179031
<nenolod> i made a debdiff to add libao2, but that's all i can do there
<pitti> nenolod: "as such, libSDL needs to be rebuilt" -> you mean ia32-libs needs rebuilding?
<pitti> nenolod: yes, I can do that
<nenolod> pitti, yeah. also add libao2 at the same time if you could. :)
<pitti> of course
<nenolod> thanks
<StevenK> pitti: Thank you for the sync
<pitti> StevenK: np; how was the movie?
<StevenK> pitti: It was great.
<StevenK> The Golden Compass; I'd read the book about a month ago
<pitti> (and which one did you watch? don't say Alien vs. Predator!)
<pitti> aah
<StevenK> Oh no, Aliens vs Predator is getting a wide berth
<nenolod> pitti, also if you could do something about bug 179471, it'd be appreciated :P
<ubotu> Launchpad bug 179471 in audacious-plugins "Merge audacious 1.4.5-1 and audacious-plugins 1.4.4-1 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/179471
<Mithrandir> TGC is a fun movie, albeit a bit too short.
<StevenK> Mithrandir: Agreed
<nenolod> i haven't seen the golden compass
<nenolod> please provide spoilers
<nenolod> :P
<StevenK> And they missed the last two chapters of the book
<Mithrandir> they could have made it ~50% longer and two films instead of three.
<thom> did they butcher the plot as badly as most reviews have suggested?
<pitti> nenolod: is it just a sponsoring request or real work to do?
<nenolod> pitti, it's just a sponsor request
<Mithrandir> ah, ok.  I'm pondering grabbing the books once I'm through my current pile and have some new shelves up.
<pitti> . o O { random remark: it's just great to have a common Debian/Ubuntu games maintainer team }
<StevenK> thom: Not by my eyes.
<nenolod> pitti, we're trying to create a common debian/ubuntu irc packages maintainer team too
<pitti> nenolod: awesome
<Company> pitti: having common maintainers between distros is always awesome
<Company> pitti: even having them talk to each others is a great thing
<Company> pitti: way too uncommon unfortunately :(
 * nenolod turned the audacious package around in ubuntu
<Company> (this is from my upstream pov btw)
<nenolod> and i'm sure the debian maintainer finds it useful that i bump the package there too when no changes are needed ;)
<nenolod> (he added me to uploaders: :))
<nenolod> Company, ubuntu is an important platform to me, because i am working on a very cheap computer (kind of like gPC, but much better) that will be based on ubuntu (+ custom artwork and maybe some additional stuff preinstalled)
<nenolod> Company, so making sure my software works in ubuntu is rather important, as i intend to preinstall it ;)
<lucas> when did Ubuntu switch to /bin/dash as /bin/sh on the buildds?
<lucas> infinity: ^^
<pitti> lucas: around edgy IIRC
<lucas> ok, thank you
<pitti> geser, mvo_: about bug 179876, wouldn't it be better to remove the Ubuntu specific source packages, use Debian's names, and merge?
<ubotu> Launchpad bug 179876 in compizconfig-backend-kconfig "[Remove] Please remove compizconfig-backend-{gconf,kconfig} from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/179876
<pitti> Riddell: do you plan an upload of kdesdk soon? it needs a rebuild for dropping the spurious libdb4.4 dependency
<pitti> Riddell: I tried building it with -Wl,--as-needed, but that fails
<Riddell> pitti: nothing planned but I can take a look
<Riddell> pitti: is that dependency a problem?
<pitti> Riddell: ok; if not I can trigger a no-change rebuild, too, but it's quite a large set of b-deps and download
<pitti> Riddell: 4.4 is in universe now; so if kbabel is on the CDs that'll render them uninstallable
<pitti> if kbabel isn't, then it can wait
<Riddell> pitti: it isn't
<Kmos> pitti: do we need debian-maintainers package ?
<Kmos> it's only in hardy
<mvo_> pitti: maybe, I need to investigate how similar/different it is
<pitti> Kmos: not really
<Kmos> pitti: can you add it to some filter in auto-sync? :)
<Kmos> and remove it from hardy
<pitti> Kmos: I can; please file a removal bug, to have a paper trail
<Kmos> pitti: one, i will do
<Kmos> ups
<Kmos> pitti: ok, i will do
<Kmos> :)
 * Hobbsee waves
 * Hobbsee hopes for l-u-m soon
<thom> pitti: cheers!
<pitti> hey Hobbsee
<Hobbsee> BenC: ping.  can i ask a silly question?
<Hobbsee> pitti!
 * Hobbsee hugs pitti
<pitti> hi thom, happy new year! what's up?
<thom> pitti: happy new year mate. was just saying thank you for the puppet sync :)
<pitti> thom: ah, no problem
<soren> lamont: Am I imagining things or did you not mention recently that you were working on bug 173868?
<ubotu> Launchpad bug 173868 in postfix "postfix-doc unremovable if postfix not installed" [Low,Confirmed] https://launchpad.net/bugs/173868
<lamont> soren: hrm... I was working/fixed the uninstallable if not installed version
<lamont> I'll have to peek at it again. :(
<lamont> but for the moment, I'm going to go back to bed for a bit
<soren> lamont: Ah, ok.
<soren> lamont: Fair enough.
<soren> lamont: Can I assign it to you?
<lamont> soren: sure
<lamont> postfix-doc cannot use postconf without checking for existance.
<lamont> Addresses-Ubuntu-Bug: 173868
<lamont> Signed-off-by: LaMont Jones <lamont@debian.org>
<lamont> soren: I do love it when the bugs are trivial.
<lamont> OTOH, I hate it when I miss something so obvious
<lamont> is it a known feature that (d-i) install on a 1.8 TB partition has issues (while 1.6TB works)?
<lamont> s/feature/issue/
<lamont> "looked like it was fine, then crashed loading the boot loader"
<ScottK> Good morning pitti.  Thanks for all the syncs and backports today.
<ScottK> pitti: It seems I made a mistake with the clamav backport to feisty and neglected to actually put in the bug which version I was thinking should be backported (entirely my fault).
<pitti> ScottK: yw; was quite a batch today, holiday lag
<pitti> ScottK: oh, uh
<ScottK> pitti: As a result, I just introduced a library transition (libclamav2 -> 3).
<ScottK> Yeah.
<pitti> ScottK: well, then it'll just get stuck in NEW and I can reject the binaries
<ScottK> It affects roughly two handfulls of packages.
<ScottK> Ah.. Cool.
<lamont> ScottK: re: QMQP_README --> wietse still delivers it in README_FILES, and I deliver everything in that directory
<lamont> should I specifically drop that file?
<lamont> (bug 172925 comment of yours)
<ubotu> Launchpad bug 172925 in postfix "postfix upgrade does not add 'retry' service" [Medium,In progress] https://launchpad.net/bugs/172925
<ScottK> pitti: After that can the version in gutsy-security be backported?
<pitti> ScottK: it'll have a lower version number, but since that affects only the source package that should be fine (I can remove the current backport
<pitti> ScottK: which bug# was it?
<ScottK> pitti: Bug #177537
<ubotu> Launchpad bug 177537 in clamav "Remote Code Execution" [Undecided,Fix released] https://launchpad.net/bugs/177537
<ScottK> pitti: Thanks.  This is what I get for trying to do stuff while on the road for Christmas vacation.
<ScottK> lamont: Sounds like an upstream issue with either README_FILES or the upgrade script.
<ScottK> I'm really not sure.
<lamont> ScottK: OK.  it'll magically disappear when Wietse stops delivering it. :-)
<lamont> I'm tempted to close bug 59268 as fixed in 2.4 as well
<ubotu> Launchpad bug 59268 in postfix "dpkg postinst failed, because it tries to start postfix twice (and does not catch running state)" [Undecided,Confirmed] https://launchpad.net/bugs/59268
<lamont> stopping twice is, um, a feature.
<Mithrandir> lamont: is that a feature-feature or a lamont-feature?
<Mithrandir> :-P
<ScottK> lamont: Great feature (the stopping twice).  The postinst should support the feature then ;-)
<lamont> it clubs it over the head twice to make sure it really stopped. :-P
<Mithrandir> lamont: sure you shouldn't remove the rc2.d links and reboot the machine while you're at it?
<lamont> and no, I'm not sure why it feels the need.
<lamont> Mithrandir: I suspect that'd get me a grave bug. :-)
<Mithrandir> (and then run the postinst as an @reboot cron entry)
<lamont> LOL
 * Mithrandir goes to take his pills
 * lamont goes to turn off the alarm so his wife doesn't notice that he forgot to come back to bed.
<elmo> Mithrandir:  I think you've had quite enough of those
<StevenK> elmo: Or not enough
<Mithrandir> elmo: but they're nice!  blue and red and green and all.
<Hobbsee> or nowhere near enough, yes
<lamont> Mithrandir: it's possible that they're affecting your work performance though...
<Hobbsee> adversely, though?
<ogra> lamont, do you have any hint for bug 179130 ? (good to see you back btw :))
<ubotu> Launchpad bug 179130 in livecd-rootfs "Typo in argument parsing and unknown sanitize command" [Undecided,New] https://launchpad.net/bugs/179130
<ScottK> pitti: Do you want a comment in the clamav bug from me on the version needed for Feisty or is this conversation good enough?
<pitti> ScottK: just updated the bug
<pitti> s/:/: I/
<ScottK> pitti: Perfect.  Thanks for fixing and sorry for the trouble.
<pitti> np
<pitti> nenolod: hm, not sure what you mean with libdirectfb and ia32-libs
<pitti> nenolod: oh, ignore me, I know what you mean; should be all good now
<Hobbsee> Kmos: please do not file crap bugs in debian, and admit to being an ubuntu user.  thankyou.
<Kmos> Hobbsee: which ones are you talking about ?
<Hobbsee> Kmos: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459107
<ubotu> Debian bug 459107 in telepathy-qt "New upstream version 0.14.1" [Wishlist,Open]
<Kmos> what's the problem with that one?
<Hobbsee> Kmos: the maintainers want to talk to you about it, on oftc, in #debian-qt-kde
<Kmos> 0.0.2064-1 is more recent ?
<Hobbsee> Kmos: do you know the address?
<Kmos> Hobbsee: yes..
<Hobbsee> cool
<Hobbsee> they're waiting
<dcotruta> hello all
<dcotruta> anyone care to lend a hand with a driver problem (i want to extend an existing driver)
<soren> doko: Should the new icedtea-java7 upload have any effect on bug 152362 ?
<ubotu> Launchpad bug 152362 in icedtea-java7 "icedtea-java7-plugin always crashes firefox" [High,Confirmed] https://launchpad.net/bugs/152362
<doko> soren: I don't know
<soren> doko: Heh :)
<soren> doko: I'll wait for it to build and let you know, then .
<pitti> ScottK: clamav> ok, I think I got it now
<tkamppeter> anyone of the OOo guys around?
<pitti> hi tkamppeter, happy new year!
<tkamppeter> pitt, thanks, also happy new year!
<tkamppeter> OOo seems not to have been updated for Alpha 2, a full updatre of Hardy still wants to remove it.
<pitti> known problem
<_MMA_> tkamppeter: calc was working on some issues when I talked to him last.
<tkamppeter> calc? Are you here?
<tkamppeter> is anyone of you using an up-to-date Hardy with OOo? How did youy proceed to set it up?
<stgraber> tkamppeter: execute soffice, then open your document
<tkamppeter> So I do the "apt-get dist-upgrade" and after it has removed the two OOo packages "soffice" is still there?
<stgraber> tkamppeter: IIRC, yes :)
<stgraber> tkamppeter: I remember of a dist-upgrade removing tons of OpenOffice packages but soffice still working after that
<stgraber> tkamppeter: but I did that dist-upgrade at least a week ago (probably two)
<tkamppeter> stgraber thank you, I have set up a new laptop by installing a Gutsy live CD and now I am upgrading it to Hardy, to use it for the Ubuntu development.
<tkamppeter> Does this also mean that the OOo packages in question were not present on Alpha 2?
<stgraber> well, ubuntu-desktop depends on -writer, -calc, -gnome and -impress
<stgraber> those are installed so everything is fine
<stgraber> what isn't is openoffice.org itself as it depends on openoffice.org-base which causes a conflict (libhsqldb-java)
<tkamppeter> And what are openoffice.org and openoffice.org-base good for then?
<stgraber> looks like openoffice.org-base is broken (or libhsqldb-java), so ones this one is fixed you should be able to install openoffice.org and all its depends
<tkamppeter> stgraber, do you know which functionality of OOo is in the packages openoffice.org-base and openoffice.org?
<stgraber> it's the base interface IIRC (sort of Access-like module)
<tkamppeter> So it is only for databases?
<stgraber> I think so (never played with that part of OOo)
<calc> tkamppeter: yes
<calc> tkamppeter: base is just for database stuff, openoffice.org is just a metapackage
<tkamppeter> Thank you calc
<pitti> calc: libcommons-lang-java FTBFSed, can you please have a look? I need to leave now
<pitti> You must specify a valid ANT_HOME directory!
<pitti> calc: ^ yay for Debian doing binary uploads :/
<pitti> calc: seems trivial to fix
<ion_> Re: the hassle with flashplugin-nonfree every time a new upstream version is released (LP #173890), has anyone tried to convince Adobe/Macromedia to release the separate versions at separate URLs?
<ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [Undecided,Confirmed] https://launchpad.net/bugs/173890
<ScottK> ion_: Even if they released different versions, if you don't run the latest, you're stuck with multiple unfixed security bugs.
<ion_> scottk: The Ubuntu package isnât going to be able to download the latest package *anyway* until it gets updated as well. That leaves a period of time when flashplugin-nonfree is not installable.
<ion_> (Since it gets the âwrongâ tarball from the site)
<ScottK> True.
<ScottK> I suppose that it one good reason.
<ScottK> If course not installable makes the SRU justification easier ;-)
<persia> ScottK: Well, yes, except for regression risks (like the current konqueror breakage)
<ScottK> Yes, but given the security issues, I think we'd have no choice but to update anyway.
<persia> Scylla and Charybdis
<ScottK> Pretty much.
<ScottK> persia: Do you know if bzip .debs are OK in Ubuntu yet?
<Ubulette> persia, fyi, i'm done with prism-webapps. problem is, i don't know what to do with icon licenses
<Ubulette> oops, wrong channel
<persia> ScottK: dpkg changelog says lzma is fine (since 1.14.12ubuntu3) and .bzip2 as well (since 1.10.24).
<dmb_> i think the best solution would be to work out the problem with adobe, and have them create versioned tars
 * \sh 's doomed...same error running debootstrap on hardy as last time
<\sh>  /usr/sbin/debootstrap: 317: cannot create /home/shermann/hardy_chroot/test-dev-null: No such device or address
<Chipzz> what version of python will hardy ship with? 2.5?
<persia> Chipzz: At least 2.4 and 2.5 will be included.
<\sh> yay for bug #180157
<ubotu> Launchpad bug 180157 in debian-installer "XFS root filesystem - install fails with "noexec or nodev" error" [Undecided,New] https://launchpad.net/bugs/180157
<\sh> every partition of my system is xfs, but not /boot so I'm fcked
<persia> Um.  Shouldn't the install fail when trying to push to noexec?  I'd think nodev also.
<slangasek> clearly, the install does fail? :)
<\sh> slangasek: the install does fail....check the bugreport...I added now debootstrap to it...
<\sh> root@home-emt64:/home/shermann# debootstrap hardy hardy_chroot/
<\sh> /usr/sbin/debootstrap: 317: cannot create /home/shermann/hardy_chroot/test-dev-null: No such device or address
<\sh> E: Cannot install into target '/home/shermann/hardy_chroot' mounted with noexec or nodev
<\sh> /dev/sda6 on /home type xfs (rw)
<\sh> /dev/sda5 on /var type xfs (rw)
<\sh> is my home partition...mounted without noexec, nodev...so it should work...but it's xfs
<\sh> or do I understand this errormsg not correctly...and it needs noexec, nodev? ,-)
<slangasek> if you try to run "mknod /home/shermann/test-dev-null c 1 3" directly, you get that same error I guess?
<\sh> no
<slangasek> it needs to not have either of noexec and nodev
<slangasek> if the xfs filesystem defaults have changed, that's nutty, but in that case you could try mounting it with "exec,dev"
<slangasek> \sh: you /don't/ get that error?
 * persia is confused, and suspects xfs trickery
<\sh> slangasek: doing the mknod I don't get any error...but I think I need to check the $?
<slangasek> so do you get a different error, or a successful device creation?
<\sh> slangasek: there is no device created..so I think it returns $?=1 (me needs to check)
<slangasek> you should get an error message if it fails, AFAIK
<\sh> slangasek: no..the error message comes from debootstrap...mknod failes silently it seems
<slangasek> for that matter, if I remount my ext3 /home with "nodev", I can still create devices, I just can't use them :)
<\sh> slangasek: well, fact is, /home or /var are not mounted with noexec,nodev, so when I do a -o remount,exec,dev I only see in my mount output "(rw)" ... now trying the other way around
<\sh> yuck...una momenta
<\sh> ok...
<\sh> now...mknod works
<\sh> device is created
<persia> \sh: patch XFS to have sane defaults :)
<\sh> but /usr/share/debootstrap/functions: check_sane_mounts() doesn't work
<slangasek> what did you have to change to get the device created?
<\sh> slangasek: mount /home/ -o remount,exec,dev
<\sh> but by default it's already exec,dev
<slangasek> and yet somehow not? :)
<\sh> slangasek: mknod /home/shermann/hardy_chroot/test-dev-null c 1 3 works as expected...(the first time I checked in the wrong dir)
<slangasek> ah
<\sh> slangasek: but inside debootstrap it doesn't work somehow...I have to check why not...trying to play with the code in check_sane_mounts manually
<slangasek> so what happens if you run 'echo test > /home/shermann/hardy_chroot/test-dev-null; echo $?' after that?
<\sh> root@home-emt64:~# echo "test" > /home/shermann/hardy_chroot/test-dev-null ; echo $?
<\sh> -su: /home/shermann/hardy_chroot/test-dev-null: No such device or address
<\sh> 1
<slangasek> well, there you go
<\sh> crw-r--r--  1 root     root     1, 3 2008-01-04 23:02 test-dev-null
<slangasek> so xfs appears to have a problem with devices
<slangasek> not an installer or debootstrap bug then, but an xfs bug
<\sh> slangasek: so a kernel problem
<slangasek> yes
<\sh> ok..I'll add our kernel package to bug #180157 and mark the other packages as invalid and adding our testcase
<ubotu> Launchpad bug 180157 in debootstrap "XFS root filesystem - install fails with "noexec or nodev" error" [Undecided,Confirmed] https://launchpad.net/bugs/180157
<\sh> what is the source package name for our linux image?
<\sh> linux-source-2.6.24?
<ScottK> \sh: No source.  Just linux-
<LaserJock> ?
<Lure> can somebody give-back kdepimlibs (now that kde4libs built)?
<ScottK> Riddell can do it, can't he?
<Lure> ScottK: I think not, he is not on launchpad-buildd-admins team
<Lure> ScottK: ENOHOBBSEE ;-)
<ScottK> Ah.  Right.  Need a buildd admin, not an archive admin.
<\sh> so bug #180157 should be corrected now..assigned the kernel team
<ubotu> Launchpad bug 180157 in linux "XFS root filesystem - install fails with "noexec or nodev" error" [Undecided,Confirmed] https://launchpad.net/bugs/180157
<\sh> time for some nicotine
<\sh> slangasek: thx for tracking this down :)
 * slangasek nods
<\sh> now for a quick solution of this problem
<\sh> what's a good and fast fs for a 500GB drive?
<Lure> \sh: raw disk ;-)
<slangasek> ext3 is the only fs I use
<slangasek> I've used xfs in the past, but got tired of seeing files full of zeroes
<sladen> my tmpfs is faster than your xfs
<Lure> slangasek: same here :-(
<sladen> (and has the same affect on files post-boot)
<\sh> slangasek: well, playing with storage sizes like >5TB ext3 is a pain..and xfs is fast for this...
<Lure> you just cannot trade reliablity for performance if you care about your data
<slangasek> \sh: 500GB <= 5TB
<\sh> slangasek: yeah...but my 500GB drives are coming out of a system with 5TB ;)
<\sh> writing inode-tables: xxx/3727
<\sh> there is still one drive which I need to send to imbrandon
<\sh> ok..with ext3 it works now
<imbrandon> :)
<smarter> Hi
<smarter> are the scripts to generate the http://archive.ubuntu.com/ubuntu/dists/gutsy/main/i18n/Translation-xx files from the .po files available?
#ubuntu-devel 2008-01-05
<SirBob1701> maybe i'm just too tired but its hard to figure out what needs to be done in ubuntu.  I wanna start to help out but everything seems spread all over
<zul> SirBob1701: you can start on #-motu
<SirBob1701> zul: ok thanks
<emgent> ping *
<LaserJock> emgent: ?
<emgent> done.
<emgent> i was found a security bug in ubuntu.com website
<emgent> https://bugs.edge.launchpad.net/ubuntu-website/+bug/180468
<keescook> emgent: can you subscribe "ubuntu-security" to that bug?
<emgent> sure
<keescook> thx
<emgent> heya keescook :*
<keescook> hiya :)  just stepping out for dinner
<nuxil> whats the release date for hardy? aprl may ?
<LaserJock> nuxil: wiki.ubuntu.com/HardyReleaseSchedule
<nuxil> thank you
 * lamont plays with his new laptop
<LaserJock> nifty, what kind?
<lamont> Dell Inspiron 1520
<StevenK> LaserJock: PONIES
<StevenK> LaserJock: In all seriousness, Gutsy was out two months ago
<LaserJock> yeah ...  I know  :/
<persia> Umm..  It's January.  That's three months
<lamont> persia: 2.5
<gQuig1> anyone know if hardy alpha 3 will ship with firefox 3?
<ScottK> Considering Gutsy was released with a version of it, I'd say yes.
<TheMuso> But shipping is different to it being in the archives IMO.
<gQuig1> yea.. I know it'll be in the archives I am currently using it
<minghua> I doubt firefox 3 will be out early enough to be shipped on hardy CD.
<minghua> Hardy, being LTS and all, probably won't use a beta version for default browser.
<gQuig1> does it have to be fully out to make it to an alpha cd?
<minghua> And I don't see it shipping both firefox 2 and 3 either.
<TheMuso> Even if 3 is out, I don't see it being shipped for an LTS.
<Fujitsu> TheMuso: Why not? 2 won't be supportable.
<Fujitsu> Well, it will be even less supportable.
<TheMuso> Fujitsu: Oh...
<Fujitsu> Mozilla kills off old series very quickly.
<ScottK> I do believe there is already a commitment to use xulrunner in the final release, so I think it'll be FF3.
<gQuig1> yea.. I assumed it would ship final with 3
<minghua> gQuig1: You are still not clear with your question though, what is the "ship" you mean?  Default browser?  Installed by default?  In main?
<gQuig1> I was asking about the alpha 3
<gQuig1> on default cd
<Fujitsu> Alpha 3 will ship with Firefox 2 on the CD.
<minghua> ScottK: Does the firefox-3.0 currently in archive already using xulrunner?
<gQuig1> yup
<minghua> Everything on the desktop CD will be installed, right?
<Fujitsu> minghua: It depends on it.
<Fujitsu> minghua: Except for a couple of live-specific things which are removed after it's installed.
<gQuig1> what's the reason we can't go to firefox 3 for an alpha?
<minghua> Nice, probably I should try it, instead of using the binary downloaded from mozilla.com.
<minghua> s/com/org/, I think.
<ScottK> minghua: I think so.
<Fujitsu> I find Firefox 3 to be much, much nicer than Firefox 2. It's actually usable!
<minghua> Fujitsu, ScottK: Thanks for the info.
<minghua> Firefox 3 beta1 was terrible on my Debian.
<Fujitsu> What was wrong with it?
<gQuig1> I find some of the features slow without video acceleration
<gQuig1> but I'm currently running nouveau so...
<Fujitsu> The scrolling tab bar is infuriating.
<Fujitsu> Arrrrrgh!
<Fujitsu> It's turning into Windows XP!
<Fujitsu> I don't want to be questioned when going into about:config, TYVM.
<gQuig1> ....Firefox 3 is turning into XP?
<ScottK> Considering we already need permission to patch it.
<minghua> Fujitsu: What's wrong with beta1?  The font rendering was completely unbearable.  It was much better in beta2 though.
<Fujitsu> gQuig1: It gives me a page warning not to do bad things when I go to about:config. XP does similar when opening up C:, Program Files, etc.
<gQuig1> eh.. I liked it
<gQuig1> Be careful, this gun is loaded!
<Fujitsu> Heh.
<minghua> Fujitsu: That can be disabled in about:config, IIRC.
<Fujitsu> minghua: Or by unchecking the `show this every time' checkbox.
<Fujitsu> Looks like it's general.warnOnAboutConfig.
<Fujitsu> ... why is there a key named general.config.obscure_value?
<gQuig1> don't know why but I want to say for compatibility
 * gQuig1 would like to see firefox 3 in alpha 3 if possible to get better testing coverage and wishes all a good night
<peterjtech> I've got a question about defualt settings for hardy. I work over on the ubuntu forums in the absolute beginners fourms answering questions, lately I've seen a bunch of problems from people with fresh installs that have all of thier repositories disabled because they installed gutsy while not connected to the internet. Is there a bug report for, or discussion, of removing the repository check during the install? It seems like a good i
<nenolod> #ubuntu+1
<evand> peterjtech: https://blueprints.launchpad.net/ubuntu/+spec/networkless-installation-fixes
<evand> It's targeted for Hardy: https://blueprints.launchpad.net/ubuntu/hardy/
<peterjtech> evand: that's good to know
<peterjtech> I was looking around in launchpad but couldn't think of good search terms to find what I was looking for, seems rather obvious now
 * Fujitsu would like that, particularly with smaller timeouts, as he installed yesterday when au.a.u.c was down, which caused much waiting and brokenness.
<tuntun> how do i disable the login window after resuming from suspend?
<Fujitsu> tuntun: This channel isn't for support. Use #ubuntu.
<Lure> can somebody give-back kdeedu-kde4 (kde4libs is built now)
<superm1> imbrandon, you still around?
<Fujitsu> superm1: It's getting to the time when people in his part of the world /should/ be up. Thus, you can fairly safely say he's not.
<superm1> Fujitsu, he does work odd hours for central time though on a regular basis
<superm1> so i figured it'd be worth a shot
<superm1> well if any other core-devs would have a few moments to look over the patch i was going to show imbrandon, i'd appreciate it: http://pastebin.ubuntu.com/3300/
 * persia gets reminded, and goes digging for rarely used hardware
<superm1> persia, i was thinking more about what you said the other day, and realized there was a corner case that caused it to reconfigure itself without user asking
<superm1> persia, hence was pre-empted this patch
<persia> superm1: The changelog looks to hit all the points I had referenced, but I really should test with my hardware and get back to you.  I'll wait for the new rev to send feedback (but make sure I have my HW handy first).
<tjaalton> hmh, what broke gdbm?
<tjaalton> bug 180368 for instance
<ubotu> Launchpad bug 180368 in command-not-found "gdbm fatal: lseek error" [Undecided,Confirmed] https://launchpad.net/bugs/180368
<tjaalton> oh, seems that the error message is from c-n-f after all.. I just didn't have the command installed that I tried to run :)
<belsebubb> is ntop broken in gutsy ?
<belsebubb> i dont know. but it seems to broken. buggy
<nixternal> any archive admins hanging out today? I need a give back on kaider-kde4 that I just uploaded...thanks
<pitti_> nixternal: this package doesn't seem to exist?
<jpatrick> nixternal: hasn't got past NEW
<pitti_> nixternal: then you don't need a giveback (that's necessary for a previously failed build which should work now)
<nixternal> pitti: thanks
<nixternal> pitti: if I upload new will it overwrite, or should I bump the revision to ensure it?
<pitti> nixternal: you mean upload the same version again?
<nixternal> ya
<pitti> nixternal: you can do that, both will be in NEW
<nixternal> groovy
<pitti> nixternal: but I'd prefer rejecting the previous one first to avoid confusion which is the good one
<nixternal> k, how do I reject or request that?
<nixternal> haven't had to do that ever
<pitti> nixternal: so, shall I kill kaider-kde4 from NEW?
<nixternal> yes please
<nixternal> and I owe you a cookie, or a drink of your choice :)
<pitti> killed; NP :)
<nixternal> you rock! thanks again
<nixternal> I cd'd into the wrong directory and dput the wrong one
<geser> pitti: do you have a suggestion what to do with a package which uses ${source:Version} to depend on an package from an other source? In Debian the versions are kept in sync but in Ubuntu one package has changes which breaks this dependency
<pitti> geser: hm, that sounds pretty fragile to begin with
<pitti> why can't we keep those in sync, too?
<pitti> if the strict dependency is actually justified, we have to do that anyway
<pitti> and if not, we should file a Debian bug to relax it
<geser> we could, but then I would need to upload an cyrus-sasl2-heimdal 2.1.22.dfsg1-16ubuntu2 as a rebuild
<geser> the strict dependency is from cyrus-sasl2-heimdal-dbg to cyrus-sasl2-dbg
<pitti> hm; in this case I think a rebuild is justified (new compiler, toolchain, etc.)
<geser> it looks odd to use ubuntu2 as a rebuild and skipping ubuntu1
<pitti> oh, right, it's unmodified ATM
<pitti> would be unfortunate to break it indeed
<pitti> so, I wouldn't mind fixing cyrus-sasl's dependency either
<geser> I see now that uploading cyrus-sasl2-heimdal with ubuntu2 would also fix the unmet deps for libsasl2-modules-gssapi-heimdal
<geser> so I don't get hurt when I do this strange upload? :)
<geser> or is there a better solution?
<dfiloni> DktrKranz: ./configure && make && debuild binary giusto?
<blueyed> Is nobody interested in sponsoring the fix for bug 177032? :)
<ubotu> Launchpad bug 177032 in dash "Regression with filename glob expanding" [High,Triaged] https://launchpad.net/bugs/177032
<geser> blueyed: I guess now is not a good moment to search for a main sponsor :)
<blueyed> geser: are you refering to weekdays/weekend?
<geser> blueyed: yes, and that it's evening in europe
<LaserJock> there are some core devs not in europe ;-)
<geser> LaserJock: true, but the chance to find a non-european core-dev on a weekend here aren't much better (in particular one who is willing to do some sponsoring)
<ScottK> LaserJock: Are you up for some Main sponsoring?
<LaserJock> actually depends on the patch/package
<LaserJock> I generally don't like being the guy who breaks core apps ;-)
<ScottK> I've got two small ones.
<ScottK> Both should be safe.
<ScottK> Bug 17169 is one
<ubotu> Launchpad bug 17169 in dput "Avoid warning when uploading packages with -0ubuntu1 revision" [Medium,Fix committed] https://launchpad.net/bugs/17169
<ScottK> Bug #178203 is the other.
<ubotu> Launchpad bug 178203 in pinentry "Please merge pinentry (0.7.4-2) from Debian Unstable (Main)" [Wishlist,Fix committed] https://launchpad.net/bugs/178203
<LaserJock> ScottK: k
<ScottK> LaserJock: Thanks.
<LaserJock> ScottK: was there a rationale for adding in debian-mentors to dput.cf other than it's nice to have?
<ScottK> LaserJock: My rationale is that it does no harm and makes it easier to contribute back to Debian (one less barrier) and that's a good thing.
<LaserJock> right, I just wondered if there was a bug
<ScottK> No.  I didn't see value in filing a bug for that.
<ScottK> I wouldn't have done it if I wasn't actually fixing something at the same time.
<ScottK> I did recently set up a new laptop and it was slightly annoying to have to add it by hand.
<LaserJock> sure, I think it's a good idea
<LaserJock> we have revu in there
<ScottK> Exactly.
<LaserJock> ScottK: hmm, actually there is a new Debian version that has a number of fixes, perhaps a merge would be good?
<ScottK> LaserJock: I'll have a look at it.
<LaserJock> I'll look at the other one while you're doing that
<ScottK> Sounds good.
<ScottK> LaserJock: Merge debdiff attached to the bug.
<LaserJock> ScottK: pinentry done
<ScottK> LaserJock: Thanks.
<ScottK> I have to run out for a while to drop one of my kids off for a church function.  I'll be back in about 45 minutes or so.
<LaserJock> ScottK: dput done as well, thanks for the merge
<ion_> It would be nice if /etc/dput.cf had an entry for ppa by default. That would require ppa to be changed a bit, though.
<LaserJock> ion_: I don't know how you could do that. How would you determine what PPA to upload to?
<ion_> By the signing key
<LaserJock> that's not enough
<LaserJock> that might work for personal PPAs I guess, but wouldn't for teams
<ion_> If you want to upload to a team PPA, then youâd need to add your own ppa entry.
<LaserJock> I guess the common use case would be for personal ppas
<ScottK> LaserJock: Thanks.
#ubuntu-devel 2008-01-06
<geser> cjwatson_: Hi, when you have time could you review bug #180669? It includes also a fix for the fakeroot FTBFS problem in hardy.
<ubotu> Launchpad bug 180669 in fakeroot "[Merge] fakeroot 1.9 from Debian unstable (includes also a fix for the FTBFS)" [Undecided,New] https://launchpad.net/bugs/180669
<t0mLe> hi, have a question - any one know what my be causing "gdbm fatal: lseek error" - happens every time i try using svn
<geser> t0mLe: bug #180368
<ubotu> Launchpad bug 180368 in command-not-found "gdbm fatal: lseek error" [Undecided,Confirmed] https://launchpad.net/bugs/180368
<t0mLe> thank you geser; only did a quick search and did not find any thing..
<t0mLe> no know now of any temp fixes?
<Fujitsu> t0mLe: Are you sure it's svn giving that error, and not command-not-found? Try installing svn.
<t0mLe> Fujitsu, i will try..
<t0mLe> ok, it probably was command-not-found
<t0mLe> since installing SVN worked...
<t0mLe> it did fix it..
<emgent> keescook, ping
<supersako> im a software developer currently running archlinux on my laptop but sick of it.. going to switch to ubuntu  but dont know if i should get ubuntu or kubuntu what are you guys running?
<Chipzz> supersako: -> #ubuntu pls
<Hobbsee> ubuntu in here
<Chipzz> and also ubuntu
<Chipzz> Hobbsee: so what's up with you not running kubuntu anyway? ;)
<Hobbsee> Chipzz: wanted a change.  *shrug*
<Chipzz> Hobbsee: yeah but I though you maintained quite a few kde packages?
<Hobbsee> kde is group-maintained
<Hobbsee> but yes, i made some fo the uplaods to them
<wasabi> Hmm. Epiphany somehow lost NTLM support in hardy recently.
<x15_> anybody in here?
<ion_> metaquestions + impatience = win
<stdin> if I have a patch for devscripts, I should just post a bug and upload the debdiff right?
<stdin> done that anyway: bug 180748
<ubotu> Launchpad bug 180748 in devscripts "debchange should increment ~ppa revisions" [Undecided,New] https://launchpad.net/bugs/180748
<hunger> Any chance of getting valgrind merged into hardy? It is a dev-only tool, so it shouldn't break things for users and it had some mayor updates.
<stdin> Hobbsee: bug 180748 :)
<ubotu> Launchpad bug 180748 in devscripts "debchange should increment ~ppa revisions" [Undecided,New] https://launchpad.net/bugs/180748
 * Hobbsee marks a critical bug.
<pabs3> how does one get a sync request acted on? https://bugs.launchpad.net/ubuntu/+source/warzone2100/+bug/180357
<ubotu> Launchpad bug 180357 in warzone2100 "Please sync warzone2100 version 2.1.0~0.svn3260-2 from Debian unstable (main)" [Medium,Confirmed]
<Fujitsu> pabs3: One waits. Particularly as it is a weekend.
<persia> pabs3: It will likely get hit on Monday.
<pabs3> cool. what about removing packages from gutsy? is that possible?
<persia> pabs3: Only in cases of extreme legal need.  Better to remove from hardy.
<pabs3> not even for really really buggy stuff? a buggy SVN revision of warzone2100 was imported from Debian. it either needs to be removed from gutsy or synced from sid into gutsy
<Giel> yes, the current warzone2100 version is _very_ much outdated, and we seem to be getting bugreports for that package on our bugtracker
<minghua> pabs3: Not going to happen.  The sensible solution is to backport the hardy version (once it's sync'ed) to gutsy.
<persia> pabs3: If it's really, really, really buggy (as in RC buggy), it might be eligible for an SRU.
<Giel> even though we know that some of those bugs are fixed in later SVN versions...
<Giel> persia: it isn't a release candidate it's a snapshot from a very unstable development trunk
<persia> Giel: I realise that, and had I known three months ago, I'd have tried to find a way to not include it.  As it stands now, it's hard to fix unless it causes data loss, is a severe regression from a previous release, FTBFS, cannot be installed, or segfault on startup.
<Riddell> hunger: valgrind merged
<Giel> persia: it _will_ cause incompatibility of several config files and savegames made with the version currently in gutsy _will_ break
<Giel> which is something I think users should be made aware of when they upgrade their warzone2100
<persia> Giel: That might be data loss, but it might be a candidate for a NEWS.Debian entry or richer maintainer scripts.  I'm not one of the people who can confirm something is SRU worthy, but if you think there is a patch that would make the transition less painful, and wouldn't cause transition breakage by application, it might be worth submitting it.
<Giel> persia: the savegame format that's used by 1436 is broken I think, so converting it to a workable savegame format might not even be possible
<persia> Giel: Hrm.  In that case it sounds like a bug that can't be fixed, so NEWS.Debian would be the way to go.  Pushing to backports soon, should help, as many gamers prefer to grab the latest version anyway.
<Giel> also lately we have been working on moving the savegames to a new format, until that's finished we'll have some intermediate formats that will break for sure
<Giel> as long as users are aware of that I think it shouldn't be much of a problem
<persia> Giel: OK.  Best thing to do is to get the fixes into alioth SVN before 10th February or so in order to be sure they can be included for hardy.
<kaaloo> Hi it seems that udev rules are missing in latest libsane for hardy
<minghua> kaaloo: Please report a bug, thanks.
<kaaloo> minghua:Ok will do
<kaaloo> mmm, seems its been done on purpose : "Do not install the udev rules, since hal now provides dynamic ACLs on     device nodes. (See hardy-hardware-detection spec.)"
<tuxice> hi
<tuxice> how do i work on ubuntu drivers and themes on launchpad
<tuxice> HELLLLLLLLLLLLLLLLLLLLO
<mjj29> tuxice: hi, I imagine everyone is busy atm
<mjj29> it's only been two minutes
<soren> tuxice: Also, your question doesn't make sense.
<mjj29> (also, I'm afraid I can't help, I'm not an ubuntu dev, just a DD who occasionally needs to ask about ubuntu's versions of your packages)
<mjj29> s/your/my/
<tuxice> ok :) srry for messing up this thread
<hunger> Riddell: Thanks for merging valgrind!
 * hunger grumbles. aptitude keeps crashing here.
<articpenguin3800> whats it mean when kubuntu and ubuntu share the ubuntu codebase but kubuntu dosent have automatic printer setup
<Riddell> articpenguin3800: they have different desktop apps, one of those apps is system-config-printer which I'm currently porting to KDE
<articpenguin3800> so that means its a gnome app that does that
<Riddell> articpenguin3800: yes
<articpenguin3800> k thanks
<EvanCarroll> anyone happen to know where unicode annotations are? I need to file a bug report
<EvanCarroll> would seem like libuninameslist0 but that isn't installed on my system
<soren> While working on libvirt, I've come across a rather odd problem. The core of it is that on Fedora, the following works, but on Ubuntu, I get an -EINVAL: "brctl addbr foobr ; ifconfig foobr up". On Ubuntu, ifconfig up fails until the first interface has been added to the bridge. AFAICS, the kernel is the same and the differences in the bridge-utils packages are cosmetical..  Any guesses?
<ScottK> soren: How are you on perl module dependencies and sbuild getting confused?  I've got a problem I'm trying to sort out and am looking for help.
<soren> ScottK: Not sure. What's the issue?
<ScottK> http://launchpadlibrarian.net/11178540/buildlog_ubuntu-hardy-i386.mime-tools_5.425-0ubuntu1_FAILEDTOBUILD.txt.gz
<ScottK> libfile-temp-perl is already installed with insufficient version, so the newer one doesn't get pulled in and then later this is discovered and sbuild gives up.
<ScottK> Builds fine in my local pbuilder, of course.
<soren> ScottK: Looks quite odd.
<elmo> ScottK: err
<elmo> ScottK: I doubt that's actually installed in the chroot
<elmo> scottk: are you sure it isn't provided by the perl package itself?
<elmo> ScottK: sbuild and pbuilder handle build-depends on virtual packages very differently
<ScottK> elmo: I think an older version is provided by perl-modules
<ScottK> elmo: Any suggestions?
<elmo> ScottK: if you really depend on that new a version of libfile-temp-perl?  get perl to stop providing the package...
<ScottK> elmo: It does.
<soren> elmo: but... It's a versioned dependency?
<elmo> soren: so?  sbuild doesn't have the "smarts" to figure this out.  it doesn't in Debian either
<soren> elmo: I see.
<elmo> and how does the versioned dependency matter anyway?  it's not exactly a clearly defined area
<elmo> perl-modules just says "I provde libfile-temp-perl", it doesn't mention versions explicitly
<ScottK> Sbuild shouldn't think it's already satisfied the dependency when it hasn't
<soren> elmo: Well, if it's a versioned dependency, it can't be fulfilled by a Provides: blah?
<soren> elmo: ..or so I thought.
<elmo> in fact it C/R/P libfile-temp-perl, which is a big hint to the packaging system of 'replace this package with me instead'
<elmo> soren: I don't think that's defined/a given, esp. given the C/R/P
<ScottK> Looks like I need to 'fix' perl-modules then.
<soren> elmo: True. I didn't notice the C/R/P, though.
<Kmos> why this happen ?
<Kmos> http://launchpadlibrarian.net/11121825/buildlog_ubuntu-hardy-i386.win32-loader_0.6.0%7Epre3_MANUALDEPWAIT.txt.gz
<Kmos> locales-all is a virtual package and isn't satisfied
<soren> buid-depending on virtual packages is asking for trouble.
<Kmos> there are a lot of ones like that on the FTBFS list
<Kmos> depending on locales-all
<elmo> err, locales-all doesn't even exist in hardy, AFAICS?
<Kmos> hmm..
<Kmos> it should build against libc6-dev?
<Kmos> elmo: thanks for the tip =)
<geser> ScottK: your perl build problem is bug #111800 filed by you :)
<ubotu> Launchpad bug 111800 in sbuild "sbuild attempts to satisfy versioned depencies and fails - causes packages to FTBFS" [Unknown,Confirmed] https://launchpad.net/bugs/111800
<ScottK> geser: Thanks.  I thought that sounded familiar.
<ScottK> It looks like there's a real problem between perl-modules and libfile-temp-perl that has to be sorted out.
<geser> I should try to get infinity's attention to this bug
<ScottK> Since perl-modules conflicts
<ScottK> Please do.
<ScottK> In the meantime, I'm going to figure out how to rip libfile-temp-perl out of perl-modules so we can use the newer one instead.
<ScottK> Kmos: Duping a bug that is assigned to someone to work on (particularly someone like inifinity) may not have been the best thing to do.
<ScottK> Bug #178536
<ubotu> Launchpad bug 178536 in sbuild "Preinstalled Build-Depends not properly detected (dup-of: 111800)" [Undecided,New] https://launchpad.net/bugs/178536
<ubotu> Launchpad bug 111800 in sbuild "sbuild attempts to satisfy versioned depencies and fails - causes packages to FTBFS" [Unknown,Confirmed] https://launchpad.net/bugs/111800
<Kmos> ups
<Kmos> i should dupe the oldest one ?
<ScottK> I think you should leave it alone.
<ScottK> i.e. put it back the way you found it.
<Kmos> ok
<somerville32> Why would you ever duplicate a bug?
<Kmos> ScottK: done
<Fujitsu> Thankyou Kmos.
<ScottK> somerville32: Dupe = mark as duplicate
<Kmos> Fujitsu: no problem
<Fujitsu> I didn't think I noticed it being duped - seems I looked at it a couple of minutes after it was duped, so I hadn't got a mail.
<somerville32> Ahhh, that makes more sense now
<slangasek> soren: build-depending on virtual packages is sometimes a very reasonable thing to do
<slangasek> soren: the issue is that you don't want to do it if there's more than one real package providing it at a time; but some yokels like to change -dev package names like they change their underwear, and the virtual package name is the only thing persistent that you can build-depend on
<ScottK> slangasek: Any suggestions on how to deal with build-deps on perl-modules that are both in 'perl-modules' (but in insufficent version) and have newer ones packaged separately?
<Mithrandir> ScottK: add versioned build-deps?
<ScottK> Mithrandir: sbuild doesn't understand those.
<ScottK> I've got that already.
<elmo> err, context
<Mithrandir> ScottK: uh, yes it does.
<elmo> sbuild doesn't understand them against virtual packages
<elmo> scottk: I think you have to update the code in perl-modules
<elmo> scottk: if you rip it out of perl-modules, you risk breaking stuff which depends on it being present in perl-modules (-> no explicit Depends)
<ScottK> elmo: I hope you're wrong, but am afraid you aren't.
<ScottK> My plan was to make perl-modules depend on whatever I ripped out.
<elmo> oh, well that'd work too
<ScottK> So it could still be relied on to be there.
<ScottK> But could continue to be updated without having to update perl-modules every time.
<elmo> the only other alternative (and I'd strongly unrecommend this) is changing the pkg name
<ScottK> I'm not even thinking about going down that path.
<slangasek> I don't understand why the flip-flop between shipping it in perl-modules and shipping it as a separate package, fwiw
<soren> slangasek: True, but that's kind of a special case, IMO.
<ScottK> Well I don't exactly either, but a newer version that some packages need is now packaged separately.
<slangasek> soren: it's common enough that "build-depending on virtual packages is asking for trouble" is misleading. :)
<IceKiller> any ubuntu dev'rs here wondering about this: http://ubuntuforums.org/showthread.php?t=633068
<IceKiller> srry if i'm not allowed to ask this here..
<sladen> IceKiller: might be useful to give a quick one-line overview of what $this is
<thom> IceKiller: try #ubuntu-x, more likely to be useful
<IceKiller> the Intel driver + MESA 7.01 shipped with Gutsy is quite buggy with Intel GM965, there are new 'drivers' and was wondering if it was going to be included in the mainstream
<IceKiller> http://www.mesa3d.org/relnotes-7.0.2.html where it mentions among other things that: "Fixed an assortment of i965 driver bugs" && a new Intel driver, version 2.2.0: http://xorg.freedesktop.org/archive/...l-2.2.0.tar.gz
<sladen> IceKiller: okay, so re-paste your 1st, 3rd and 4th lines to #ubuntu-x as noted by thom
<IceKiller> just did ;)
<IceKiller> ty :p
<ScottK2> Fujitsu: Looks to me like libfile-temp-perl and libtest-harness-perl are the only perl-modules affected.
 * ScottK2 runs off again.
#ubuntu-devel 2008-12-29
<vadi2> Hi, I'm not sure who to tell this, but www.opensource.mirrors.org is a ubuntu mirror and the domain is expired. For example http://www.opensourcemirrors.org/ubuntu/pool/universe/b/bogosec/bogosec_2.3-0ubuntu1_amd64.deb will not work
<cjwatson> vadi2: #ubuntu-mirrors or mirrors@ubuntu.com would be better
<vadi2> alrighty, thank you.
<Hobbsee> cjwatson: are there any plans to sanitise the ubuntu-devel@ moderation queue?
<cjwatson> Hobbsee: what's up with it? I haven't looked since before Christmas
<Hobbsee> cjwatson: mark's mail has generated a lot of response - directly to that list
<cjwatson> Hobbsee: I'll sort it out at some point, already talked about it with Mark
<Hobbsee> cjwatson: OK
 * Hobbsee does a bit of cherrypickingon it
<cjwatson> feel free to reject such mails and ask them to respond to Mark directly (though apparently he's already got several hundred responses ...)
<Hobbsee> i did...
<Hobbsee> and then i hit ctrl+c by accident on my listadmin
<Hobbsee> cursed loudly, and decided not to do that again
<cjwatson> I'm happy to deal with it when I get that far
<Hobbsee> cool :)
 * Hobbsee is just cherrypicking by subject line, at thisp oint
<cjwatson> Hobbsee: I posted a followup and am rejecting with this message: "Thanks for your response, but could you please send it to Mark directly, rather than to ubuntu-devel? See https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027088.html for more information."
<Hobbsee> cjwatson: sounds good to me
<directhex> oh my... mark started a "desktop thread" on the mailing list? no wonder the mod queues are clogged
<cjwatson> Hobbsee: queue cleared
<Nafallo> \o/
<Hobbsee> \o/
<lamalex> Does anyone know if there is a channel for the ubuntu netbook remix devs?
<lamalex> their LP page doesn't make it obvious
<calc> cjwatson: noticed the post about most common laptop screen resolution being 1024x768? (wrt sabdfl) can you even get a 4:3 aspect panel anymore, i would think 1280x800 is the most common for the past several years at least
 * calc thinks the only 1024x768 laptop still being made (that he knows of) is the X61 which is due to be EOL any day now
<persia> calc, 1400x1050 and 1600x1200 remain available in 4:3
<calc> persia: oh ok
<persia> Also, the Panasonic Let's Note series for R, and W are still 1024x768, although I have to agree they are less common these days.
<calc> ok
<fargiolas> did anyone from SRU team already look at bug #308890 ?
<ubottu> Launchpad bug 308890 in libv4l "SRU for libv4l 0.5.7" [Undecided,New] https://launchpad.net/bugs/308890
<directhex> how much RAM do the buildds have?
<Nafallo> differs
<directhex> to build something like, say, openjdk
<persia> directhex, Some have in excess of 4GB available.
<directhex> persia, somehow that doesn't surprise me
<directhex> persia, i thought there was a problem with building ikvm, some kind of memory leak
<directhex> persia, the memory leak is called "javac". the "-J-Xmx1536M" doesn't help much. lowering that value leads to an OOM error
<persia> I thought ikvm was compiled against the CLI, rather than a JVM
<directhex> persia, ikvm is the bastard child of both.
<directhex> persia, IKVM.GNU.Classpath.dll has to come from somewhere
<directhex> well, IKVM.Opensomethingorother these days. updating the package in a sane way is the problem
<directhex> i only have 2 gig of ram on here
<directhex> (only! Â¬_Â¬)
<persia> Right.  I remember looking at that a few months ago, and realising I didn't have any idea how to update it properly.
<directhex> it's the package nobody wants to touch. with good reason.
<persia> You could try PPA builds to see if they work: I've heard of people building OOo in PPAs, so it can't be that restricted.
<persia> What's the rationale for it again?
<directhex> rationale for what? ikvm?
<persia> Rather, ikvm in the repos.
<directhex> it's technically highly interesting. for one, it allows you to use any .class, unmodified, in a CLI app, e.g. where a java lib exists but a CLI one doesn't
<directhex> i wonder if it's on debian popcon
<persia> 149 / 39 / 88 / 22 / 0
<persia> No maintainer either, and removed from testing.
<directhex> the maintainer dumped it for sanity reasons
<directhex> i could probably massage it back into life if i had enough ram to actually test build it
<directhex> right now i just want to make sure the latest version compiles & works
<persia> Use a PPA for the test build.  It ought either be made to work or dropped, as it's currently mostly a curiosity.
<directhex> need a shell right now. sigh, i could build a chroot in a machine at work, in theory
<directhex> i wonder if it works on itanium. a terabyte of ram ought to be enough, even for java...
<cjwatson> calc: all I did was moderate the mailing list discussion - I have no involvement in the screenshot gathering itself
<directhex> -rwxr-xr-x 1 root root  30M Dec 29 11:54 IKVM.OpenJDK.ClassLibrary.dll
<directhex> well, it's less chunky than "real" openjdk ;)
<LordMetroid> ahh here we go
<LordMetroid> I see that 9.04 will merely focus on getting the boot to become quicker
<LordMetroid> However ever since I started using Ubuntu around 2005 I have experienced it to become slower and slower in general
<LordMetroid> Anyone know where I should turn to try to fix this?
<LordMetroid> I mean community wise, where am I suppose to starr
<LordMetroid> *start
<persia> LordMetroid, profile the applications you use most.  Determine what's slow.  Try to optimise those things.
<LordMetroid> persia, ok... I've been looking through the wiki and featyre/bug list, is that where I shall post my findings?
<persia> You might organise our findings on the wiki.  The bug tracker would be the place to file the optimisation solutions.
<Company> site note: debugging perceived slowness is _hard_
<LordMetroid> Indeed
<Company> (and it's "side", not "site")
<LordMetroid> It is not merely percieved, using Ubuntu on the 5 year old laptop that I do have, it is a human measurable relative slowness
<Company> yeah, but that is to be expected
<Company> people add features so code runs "fast enough" on current models
<Company> s/so/as long as/
<LordMetroid> I know, that is why I have to look out for the little man in the cottage still using their 5 year old laptops
<LordMetroid> :)
<persia> LordMetroid, One thing to consider is that there may be more services running in the background: try reviewing the process list and see what happens if you make them the same.
<persia> Then, of course, you want to get the services back :)
<cjwatson> this may be politically incorrect but it is not clear to me that the community can do a whole lot to help with optimisation. Performance work is generally hard development graft
<cjwatson> once some of that work is done we'll need help to ensure that we haven't broken anything, of course
<LordMetroid> Why is sun-java packages non-free? I thought Sun had revised their licenses and made Java GNU?
<persia> cjwatson, It's hard, but is there any reason that any given person can't do it, assuming they have the time and expertise?
<persia> LordMetroid, You're looking for OpenJDK for the open one.  The sun-java packages are legacy.
<LordMetroid> Is OpenJDK the default package being installed?
<LordMetroid> I noticed GCJ's speed is terrible comparatively to Sun-java
<cjwatson> persia: such expertise is sufficient to make you a developer IMO
<persia> Ah.  I guess we're just looking at separate semantics.  I'd agree that anyone with that expertise ought self-identify as a developer.
<maxb> Hi. If there's anyone who knows how Packages-arch-specific is supposed to work, would they care to check I'm not talking nonsense in bug 311952?
<ubottu> Launchpad bug 311952 in soyuz "Packages-arch-specific blocking of a single binary blocks the entire source package" [Undecided,Incomplete] https://launchpad.net/bugs/311952
<maxb> And also tell me whether I should be reporting that to some Ubuntu entity as disctinct from Soyuz itself
<persia> maxb, Soyuz would be the right place to report it.  I can't say whether it is a bug or not, in part because I don't know how one might trigger a build of just some binary packages.
<maxb> It's the source package's responsibility to build the subset of binary packages for the architecture it's being built on/for
<maxb> and in the specific case of my example, it does do that, if only Soyuz would actually attempt the build at all
<bbs> http://dpaste.com/103409/
<bbs> :(
<tseliot> bbs: follow only point 1 of Tutorial 1: https://wiki.ubuntu.com/PackagingGuide/HandsOn
<tseliot> it will help you remove the error about your key
<bbs> thx
<calc> cjwatson: ok
<NCommander> Where's the package where the installability information of te archive is posted?
<CarlFK> before I consult an attorney (which may happen, but the more I can give him the better) I am wondering what the licensing issues are for modifying and redistributing one of the stock fonts?
<CarlFK> namely   http://packages.ubuntu.com/intrepid/all/gsfonts/filelist  /usr/share/fonts/type1/gsfonts/n019004l.afm
<Laney> CarlFK: If you apt-get source gsfonts, it should tell you the license
<CarlFK> looking at the header carl@asus17:~$ grep Copyright /usr/share/fonts/type1/gsfonts/n019004l.afm; Notice (Copyright (URW)++,Copyright 1999 by (URW)++ Design & Development; Cyrillic glyphs added by Valek Filippov (C) 2001-2005)
<CarlFK> looking...
<Laney> try debian/copyright or COPYING in the root
<LaserJock> it says it's GPL
<Laney> rock on
<CarlFK> awesome.  thanks
<LaserJock> looks like GPLv2 although it points to /usr/share/common-licenses/GPL which now points to GPLv3
<LaserJock> but it looks like GPLv2 just looking at /usr/share/docs/gsfonts/copyright
<CarlFK> I'll let someone else worry about that level of detail.
<fta> pitti, thanks for calibre. I wanted to do it (i own a PRS-700) but you beat me to it. I fixed the deps and added desktop files a few days ago in my branch but I saw you did it today, so all is fine.
<CarlFK> now I am on to figuring out how to make it 140% wider.
<fta> pitti, just a thought though... i would have created a packaging branch with just the debian/ dir. easier to keep the upstream branch clean.
<avb> hey guy
<avb> guys
<avb> http://www.gnome.org/~lcolitti/gnome-startup/analysis/
<avb> does somebody already have seen this article?
<avb> look like gnome startup can be improved a lot, with gconf tunning
<LaserJock> anybody know if gnome-system-tools is sort of dead upstream?
<james_w> LaserJock: yeah
<Laney> bryce: Do you have your merge_changelog script still?
<LaserJock> james_w: yeah as in you know or yeah as in it's sort of dead? :-)
<james_w> Laney: I've got a copy if it's not on people.ubuntu.com anymore
<Laney> james_w: It 404s. Can you upload, or better shove it in u-d-t?
<james_w> http://jameswestby.net/scratch/merge_changelog
<Laney> thanks muchly
<james_w> I'll see about getting it in to devscripts
<ebroder> Hmm...I wonder if you could make that simpler using python-debian...
<james_w> probably
<james_w> I might well do that as well :-)
<ebroder> Hmm...this should actually be really easy. You get a debian_bundle.changelog.Version object for each element in both changelogs, throw them into a set, then sort, right?
<james_w> not sure a set is correct, as there may be duplicates, but yeah, sounds about right
<james_w> the issue is that calling cl.versions throws exceptions on too many occasions currently
<ebroder> But you'd want to eliminate duplicates as part of the merge, wouldn't you?
<ebroder> As long as both the Ubuntu package and the Debian package stuck to their respective policies, how could you have any overlap?
<james_w> yeah, but not if an entry was duplicated on one side I believe.
<sebner> james_w: is there any GNU document which tells you which files you have to have in your source tarball e.g AUTHORS; COPYING, ...
<Laney> sebner: http://www.gnu.org/licenses/gpl-howto.html
<ion_> AFAIU, to use GPL, you only need to distribute COPYING and have the appropriate comment block in the source files.
<sebner> Laney: more +1's from me :P
<Laney> heh
<james_w> sebner: the GNU coding standards guide may say something about AUTHORS etc.
<james_w> I believe AUTHORS, README, ChangeLog, NEWS are standard for GNU
<sebner> james_w: but standard != must have?
<james_w> not sure
<Laney> sebner: http://www.cs.nott.ac.uk/~ial/sysinfo-fakemerge.debdiff
<Laney> you don't need a bug, do you? :(
<Laney> erm, that was meant for debian-mono
 * Laney runs
<james_w> "Only apply Ubuntu patches when building on Ubuntu" <- interesting
<sebner> heh
<Laney> so that we could have the same thing in debian and ubuntu
<sebner> james_w: how is bzr accepted these days by developers? :)
<james_w> Laney: yeah, it's sensible, I just find it odd that Debian wouldn't apply patches for known bugs
<james_w> sebner: with a sample size of one, me, it's deemed to be the best thing since silicone egg poachers
<Laney> james_w: Well that patch depends on our lsb-release behaviour, so it doesn't make sense for them
<Laney> I should rewrite that bit to do the right thing
<james_w> I was looking at the one that I uploaded, which applies to Debian as I understand
<sebner> james_w: heh, sounds cool. though Debian folks say it's worse than svn
<james_w> sebner: not all of them
<Laney> james_w: The mono-cairo FTBFS doesn't happen there if that's what you mean
<sebner> james_w: but many =)
<james_w> Laney: 04-fix_usb_pci_limit.patch
<Laney> shit, I applied that one didn't I?
<james_w> oh
<james_w> no, I see how it works now, sorry
<james_w> I didn't realise series-ubuntu was a super-set of series
<james_w> apologies for slighting your skills
<Laney> yeah, I couldn't immediately see how to append series-ubuntu to series nicealy
<Laney> -a
<sebner> Laney: it builds \o/. uploading
<james_w> I've seen it done somewhere I think, but maybe it wasn't quilt
<Laney> sebner: Please test it a bit
<Laney> if you have jaunty
 * sebner upgrades to jaunty xD
<sebner> james_w: btw, you are a canonical guy. Do you know something about the MoM -> DaD progress/process?
<james_w> no idea, sorry
<sebner> np np
<Adri2000> sebner: ask Scott ;)
<sebner> Adri2000: with K? ^^
<ScottK-palm> About?
<Lutin> sebner: no, with 'james remnant'
<sebner> Lutin: thx )
<sebner> =)
<Adri2000> yep :)
<sebner> ScottK: false alarm =)
<ScottK-palm> Ah.
 * stgraber is playing with hardy on ia64
#ubuntu-devel 2008-12-30
<puchatek> Hi
<batman76> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<ion_> Huginissa on mielenkiintoinen, taiteellinen uusi projektio erittÃ¤in laajakulmaisille kuville: http://www.flickr.com/groups/vedutismo/
<ion_> Sorry, wrong channel.
<Juntai> Sup
<Fri13> Hi, is this correct maintenance schedule for 8.04 LTS
<Fri13> 33
<Fri13> June 5th
<Fri13> https://wiki.ubuntu.com/HardyReleaseSchedule
<Hobbsee> Fri13: those dates look to be tentative, for that schedule
<Fri13> Hobbsee: I am trying to find information about point releases, are those really planned so tight or will those be rolled out when needed?
<ogra> planned
<Fri13> ogra: So the real reason for the 8.04.1 was not actually the OpenSSL bug what I have heard?
<ogra> at least the ones without TBC
<ogra> the ssl bug was a security fix that was rooled out way earlier on security.u.c
<ogra> *rolled
<Fri13> ogra: What does that TBC mean?
<ogra> unless the world ends or all ubuntu devs die due to a magic online spreading desease the confirmed dates count
<ogra> TBC == to be confirmed
<Fri13> Ah...
<Fri13> ogra: So they ain't so exact yet... untill closer time they will be confirmed?
<Fri13> Is it possible that those would'nt even get released?
<ogra> right, .2 is confirmed
<Hobbsee> ogra: the UDS plague, IRC version?
<ogra> the others are likely but not written in stone yet
<Hobbsee> could be a worry...
<ogra> Hobbsee, heh, yeah, something like that :)
<StevenK> Hah
<StevenK> I've heard of a text virus, but that's just terrible
<DktrKranz> Any sponsor for main willing to review and sponsor bug 293807? Thanks!
<ubottu> Launchpad bug 293807 in gccxml "gccxml regression: fails to parse stdio.h" [Undecided,Confirmed] https://launchpad.net/bugs/293807
<LaserJock> does adding users via users-admin really not work on Intrepid? :(
<LaserJock> I ran into that a while ago and it still seems to be around
<pschorf> is anyone here familiar with update-manager's code?
<cjwatson> bryce,tjaalton: I'd really appreciate some help on bug 310857, when you can; it's really getting in the way of me using my laptop
<ubottu> Launchpad bug 310857 in xserver-xorg-video-intel "[i965] intel driver seems to get stuck in an EDID-fetching loop" [Undecided,New] https://launchpad.net/bugs/310857
<tjaalton> cjwatson: sounds like the same bug that wgrant suffered, downgrading libdrm apparently helped him
<tjaalton> +from
<plipp> Hi guys & gals. Could I get some pointers on module-building?  I've downloaded the source through 'sudo apt-get build-dep linux-image-$(uname -r); apt-get source linux-image-$(uname -r).
<plipp> Copied the config from /boot and built with "make modules"
<plipp> However, I get versioning issues when running them "no symbol version for struct_module"
<ScottK> You'd probably have more luck in #ubuntu-kernel.
<plipp> ah
<plipp> *tries*
<directhex> and unless you have a DAMN good reason (e.g. want to modify the kernel), that's not the way to compile extra modules against your existing kernel
<directhex> for that, just use linux-headers-$(uname -r)
<plipp> directhex: The reason is to modify an existing module
<plipp> crap.. maybe it's "easier" to build the whole kernel..
<glatzor> pschorf, yes.
<pschorf> bug 151011 | glatzor
<ubottu> Launchpad bug 151011 in update-manager "do-release-upgrade does not provide guidance after view details" [Medium,In progress] https://launchpad.net/bugs/151011
<pschorf> glatzor, as far as I can tell the code in bug 151011 appears to be fixed in the code, but I can't see a way to fix it
<ScottK> Maybe the bug just never got marked fixed?
<pschorf> that's what I think
<pschorf> I didn't want to mark it, though
<ScottK> Make an Intrepid pbuilder, login, and then upgrade to Jaunty.  Test if the problem still happens.
<glatzor> thanks for notcing
<glatzor> thanks for noticing
<JordiGH> Is this official policy? http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.txt
<ScottK> JordiGH: Yes.
<JordiGH> Ah, ok. It looks almost the same as Debian's. I thought you guys (I work more with Debian) had widely differing policy.
<LaserJock> JordiGH: it was based on Debian policy and there aren't very many significant differences, policy-wise
<JordiGH> Right, the only difference I see at a glance is that you guys just organise the archive differently.
<JordiGH> Nice.
<LaserJock> we don't do binary uploads and there a some small licensing differences
<nemesis> hi, how can i revert the change to pm-utils?
<JordiGH> Thanks for the info.
<nemesis> under hardy
<nemesis> does pm-utils support ACPI S1 standby or only S3 and S4?
<emgent> nhandler: ping
<emgent> sebner: ping
<nemesis> .
<cjwatson> tjaalton: thanks for the reference, I'll chase that up
<cjwatson> tjaalton: do you know if he filed it?
<tjaalton> cjwatson: I've marked yours as a dupe of the original one. it's reported upstream as well
<tjaalton> both pitti and wgrant got bit by it
<howa> rate my new site !! http://www.hardstylersunited.dk/
<jpds> howa: No spam please.
<tjaalton> cjwatson: marked as a blocker for xorg-server 1.6
<emgent> bye howa
<cjwatson> tjaalton: ok, so I just downgrade libxrandr2 then? thanks
<tjaalton> cjwatson: yes, that should help
<cjwatson> hmm, bugger, world depends on that
 * cjwatson downgrades bits of world
<tjaalton> what bits?
<tjaalton> that could get ugly, if xserver depended on it..
<cjwatson> compiz-core compiz-fusion-plugins-main gnome-settings-daemon libgcj9-0-awt libgnome-desktop-2-11 libqtgui4 totem-gstreamer Depends: libxrandr2 (>= 2:1.2.99.2)
<cjwatson> current shlibs I assume
<tjaalton> oh
<mluser-work> Anyone know if atheros wifi support has been dropped in jaunty?
<crimsun> mluser-work: no, that would constitute an enormous regression.
<mluser-work> crimsun: Its probably a problem with the 2.6.28 kernel then.. I just rebooted into my 2.6.27 kernel and all works fine now
<mluser-work> If anyone is interested, this is the lspci entry for my wifi card which is not working with the 2.6.28-4 kernel, but working  fine with the 2.6.27-9 kernel from intrepid
<mluser-work> 02:02.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
<mluser-work> 02:02.0 0200: 168c:0013 (rev 01)
<wgrant> cjwatson: I'm running fully updated everything except xserver and libxrandr2 - I just reupgrade libxrandr2 before I install updates and then downgrade it again afterwards; nothing uses the new symbols, so it still works fine.
<cjwatson> wgrant: ah, maybe I'll just copy the old library into place then to avoid apt pain
<cjwatson> wgrant: why the old xserver?
<wgrant> cjwatson: Because I ran into another bug with it.
<wgrant> I think it was crashing on some xrandr calls.
<wgrant> I think it has been fixed upstream, and I was waiting for the post-alpha2 server-1.6-branch pull to try again.
<tjaalton> wgrant: there hasn't been one :)
<tjaalton> not much happening upstream either
<wgrant> tjaalton: I know, that's why I haven't tried again yet.
<wgrant> There are a few changes upstream that we don't have.
<wgrant> I might pull them in locally and see if things improve.
<tjaalton> good
<cjwatson> forcing XRRGetCrtcTransform to think it's talking to a pre-1.3 server seems to help so far ...
<cjwatson> so I guess it's the RRGetCrtcTransform request?
#ubuntu-devel 2008-12-31
<jetole> hey guys, don't know if this is the right chan to ask but I will ask and you can let me know. I have to PC's each with a macintosh slim keyboard. The keyboard worked fine on both with 8.04. The one where I did a fresh install of 8.10 works fine however the one I did an upgrade to 8.10, the ctrl+alt keys don't seem to work
<jetole> this 8.10 x86_64 on both and they are not mac computers. I just like the keyboard so I bought it for both PC
<jetole> ctrl+alt was tested with virtual term (ctrl+alt+f1, f2, etc), X zap (ctrl+alt+backspace) and now with compiz cube rotate ctrl+alt+mouse
<jetole> the xorg.conf shows the macintosh keyboard driver and the xev application shows Control_L, Alt_L, Control_R and Alt_R
<jetole> any suggestions?
<kolby> What is the normal way to get source and store code for an ubuntero?
<kolby> this is a problem I have not solved.
<kolby> is there a standard method?
<kolby> I could use bazaar, apt-get, sourceforge, freshmeat... etc.
<cjwatson> bazaar (either hosted on bazaar.launchpad.net, or a mirrored branch registered there) is about as standard as we've got
<cjwatson> it is not universal
<cjwatson> but it is integrated with launchpad for bug tracking and some other things already, and is likely to get more so
<kolby> cjwatson, that bothers me...  the filesystem has many standards yet the development method is left to be foggy.
<cjwatson> we're working on improving standardisation of this in Ubuntu by way of Bazaar
<cjwatson> but you asked for the current state
<kolby> cjwatson, thank you.
<cjwatson> in any case, standardisation of the filesystem is much more important than standardisation of source control
<cjwatson> and therefore it makes perfect sense that it was done first
<kolby> I see
<kolby> cjwatson, so... I have a directory called ~/Code that I use for storing my branches.  Is there a better way?
<ebroder> kolby: Don't look for the Right And Only Way to do development - find what works for you
<cjwatson> local names vary and the details are not important
<cjwatson> I use ~/src but who cares what it's called
<kolby> ebroder, Shouldn't there at least be a marked and titled "good way"
<cjwatson> there are more important things
<ebroder> kolby: For where you check out your source code? That's totally a personal preference thing
<kolby> thank you both.
<cjwatson> the layout of your local source code is likely to depend on the types of projects you contribute to
<cjwatson> for example, I think of things largely in terms of distributions and so my local source code is organised in terms of the distribution source package names
<cjwatson> somebody who spent more time maintaining upstream code would not think of things that way and it would make no sense to encourage them to do so
<cjwatson> e.g. I would generally keep the upstream for an Ubuntu package foobar in ~/src/ubuntu/foobar/upstream/trunk/ or similar
<cjwatson> but the upstream developer would find that bizarre and ~/src/foobar/trunk/ might be more natural
<kolby> I want to contribute to Debian...  and learn how to build rpms... and possibly more exotic packages.  I'll do all that once I've mastered ubuntu packaging.
<kolby> cjwatson, right.
<cjwatson> I don't think it's particularly useful for us to spend time trying to standardise this; standardisation is valuable in terms of remote code access (e.g. bazaar.launchpad.net), but for local code layout it would be like fighting a blizzard uphill and wouldn't gain us anything
<kolby> My discomfort originated by having a cluttered source code directory.
<kolby> I would use "apt-get source" and get four similarly named package files that have different suffixes.
<cjwatson> my trivial recommendation would be to organise it by source package
<ebroder> Yeah, I agree
<cjwatson> mkdir whatever; cd whatever before you apt-get source
<kolby> cjwatson, that's what I've been doing.
<kolby> I think enough people do this to the point where that should be what "apt-get source" does by default.
<cjwatson> kolby: maybe if it had started that way, but at this point it would be a hideous pain to change it
 * kolby grumbles
<kolby> well... I'll fork.  lol.  jk
<ebroder> Hmm...aptitude hasn't grown a source command yet, right? :)
<kolby> ebroder, nice thinking.
<cjwatson> I don't think fiddling about with your directory structure belongs in either apt-get or aptitude. It feels more like the sort of thing that something like wajig would like to do.
<cjwatson> (not that I use wajig)
<kolby> ebroder, I'll whine and complain until someone else does the work... ;)
<kolby> (kidding)
 * kolby googles wajig...
<cjwatson> you could apt-cache show it instead
<kolby> cjwatson, i see *nods*
<cjwatson> (I have no information on whether it needs to be updated in some way to work with Ubuntu!)
<kolby> hmm...
<kolby> another problem I've had is finding functions in header files.  Stop;  Don't laugh at me.
<cjwatson> but honestly, creating directories is hardly rocket science. People who download lots of files and then never do any file management have the same problem, and I don't think it's something the OS needs to solve in that case either.
<cjwatson> ctags may be your friend
<kolby> I want a utility to spit them out "ls" style
<kolby> okay
<kolby> alright.
 * kolby wastes yet another precious irc line in agreement
<cjwatson> also w3mman is rather good at browsing back and forth between manual pages and header files
<kolby> ^^ that sounds cool.
<cjwatson> and of course you have things like apropos since functions tend to match a pattern for each library
<kolby> is it in the repository?
<cjwatson> assuming the library ships manual pages
<cjwatson> yes, w3m package. packages.ubuntu.com can answer this class of question
<kolby> okay.
<kolby> does it come preinstalled then?  I think Ubuntu ships with w3m
<cjwatson> yes, w3m is in ubuntu-standard
<cjwatson> though this has been controversial and might not remain the case forever (if I lose the argument)
<kolby> I'm learning how to become more organized.  I'm going to make a tar.gz for all my preferences kept in dot-files.
<cjwatson> check them into revision control instead
<kolby> cjwatson, I see...
<kolby> cjwatson, good plan...
<kolby> since I've had so many questions answered today.  I may as well ask another.
<kolby> would it be a good idea to have all my media files revision controlled?
<cjwatson> I wouldn't; just back up anything you care about losing
<ebroder> kolby: What's the point? They don't actually change - they're just big binary blobs
<kolby> ebroder, maybe for playlists that change.
<cjwatson> big binary files are not usually a case that revision control systems spend much time optimising for, so while it might work it would probably not be very comfortable
<ebroder> kolby: Playlists would make sense
<kolby> cjwatson, until I build the ultimate git extension...  nah... nvm
<kolby> ebroder, alright.  *writes another line on todo list*
<ebroder> kolby: I think git is currently the worst 4th gen DVCS for large binary files
<kolby> ebroder, there are 4 gens?
<ebroder> Err, of VCS, rather
<kolby> CVS, SVN, git...  (well, bit-something-or-other if you want to count it)
<ebroder> I think I count the RCS generation, the CVS generation, the SVN generation, and the DVCS generation
<kolby> D for distributed.
<ebroder> Right
<ebroder> git, Bazaar, Mercurial...
<cjwatson> DVCS is generally divided into arch-era and the modern stuff
<kolby> is that really a next generation?  Maybe it's just a design choice.
<cjwatson> where most of the modern stuff has a sensible UI except for git
<ebroder> git, Bazaar, and Mercurial are definitely a generation after svn
<kolby> alright.
<kolby> I use bzr.
<ebroder> Eh. git is very usable, once you get used to it
<cjwatson> kolby: yes, it requires a significantly different underlying architecture
<cjwatson> it's a UI you have to adapt to rather than the other way round. I'm not likely to be persuadable on this :)
<kolby> cjwatson, this shoots down my idea for game-networking that leverages server-client and p2p traffic.
<ebroder> cjwatson: Not here to get into a flamewar :)
 * kolby secretly devises the ultimate opinion.
<cjwatson> (I object to the apparently popular notion that git might be usable if only I spent time learning to love it. Actually I have spent time with it; my opinion hasn't changed in the slightest. Anyway.)
<kolby> cjwatson, I retaliate to your completely reasonable conclusions with a very incite-full objection that brings you to question your existence as a whole.
<kolby> ...soo... umm...  burn.  :)
<kolby> well, I had fun with that.  Moving on.
<ScottK-desktop> We just had a go 'round on this in Debian Python Modules Team and the conclusion was stick with svn for now.
<kolby> If only there were a wikipedia article listing all the flame wars.  Gnome vs KDE vs fluxbox, etc... vs using a gui at all
<ion_> Vim is better than Grub.
<kolby> ion_, no firefox is better. ;)
<kolby> is there a way to make a package for user's dot-files?  (ex.  .bash_aliases)
<kolby> how _should_ I go about doing this if I wanted to?
<kolby> I couldn't find anything on it in packaging articles.
<RAOF> There isn't really.  You _could_ do something in a postinst maintainer script, but I'd be amazed if that was accepted into the archive.
<kolby> RAOF, this is more for _very_ preference based things (I think the *!#@$* bike shed should be blue)
<RAOF> kolby: Why aren't there system-wide configuration?
<kolby> he meant "/etc/foobar-rc" stuff right?
<Hobbsee> yes
<terli> are there any gnome developers in here?
<kolby> terli, I'm using gnome's libxml2.  Does that count?
<terli> um
<kolby> :) okay
<terli> I need to know about gnome-shell/Clutter and if that is going to effect my future dreams of running killall gnome-panel.
<shingen> can anyone help me out with an initramfs issue with dmraid not running before a call to /dev/mapper is made?
<shingen> I'd like to modify the initramfs scripts to perform a dmraid -ay before it looks for the /dev/mapper assignment, and if possible, some assistance would be nice... or bumping me to the right channel would be helpful too, as #ubuntu helpers aren't quite at this level...
<shingen> for some reason, the dmraid script in /scripts/local-top in the initramfs doesn't get run on time, so my fakeraid partitions aren't detected, thus halting the boot process... while in the initramfs busybox session, after running dmraid -ay on /dev/mapper shows my partitions just fine
<ScottK> shingen: Is this a server or desktop install?
<shingen> ScottK: desktop, used 8.10 64 bit alternate
<ScottK> OK.  Well if it was a server you could ask in #ubuntu-server, but it's still a support question and not what this channel is for.
<shingen> ok, I'll try ubuntu-server and tell a white lie, hopefully they're sharper in there :)
<shingen> thanks
<nhandler> emgent: pong
<lool> Does someone happen to know why Ubuntu backports don't have NotAutomatic in their Release files?
<persia> lool, Wouldn't that block upgrades within backports?  I know the backporters do security updates for some of the backports.
<lool> persia: It would, but it would also prevent upgrades to all backported packages by default
<persia> Hrm.  I thought there was another way to reduce the priority, but yes, I can see that.
<lool> persia: In both cases, one needs to configure apt; if you fail to configure it in the current case, you get security supported packages but you might get new upstream versions at random times
<lool> If however we would switch to NotAutomatic, then you might end up with a vulnerable package which isn't auto upgraded
<lool> (if you didn't setup apt preferences correctly)
<lool> There's a new package which landed recently and allows tracking packages from other repos IIRC
<lool> Oh well /me goes configuring apt
<persia> I think the long-term plan is to integrate with that new package, although I'm not sure.
<lool> Well it could be an apt feature IMO; or we could setup apt preferences for backports before shipping
<lool> (and dist upgrade them along sources.list)
 * lool should probably discuss this with Michael
<persia> That makes sense.  Perhaps it's just that not so many people pay much attention to backports.
<lool> I had to use them for ... unison   :-/
<persia> Or with jdong or ScottK or Mez or ...
 * persia hides
<lool> We inherit unison from Debian, and the versions in all stable releases were incompatible to each others; we're just fortunate that we have less versions across Ubuntu releases
<lool> unison 2.9 in sarge, 2.13 in etch, 2.27 in lenny/sid...
<persia> Well, unison is incompatible across most unison releases.  Part of the nature of how upstream does things.
<lool> I think it's quite useful to be able to sync between say a desktop running intrepid and a server running hardy
<persia> That we inherit from Debian is a good thing, although it hasn't always been that way, and between Breezy and Hardy, we had someone watching it.
<persia> Actually, the decision to not upgrade unison for hardy was to support a number of users who wanted to be able to sync to older releases: maybe we chose the wrong way, but it seemed right at the time.
<lool> What I wanted to point out is that Debian doesn't keep a source package per protocol version, that we inherit, and that is a problem in Debian in Ubuntu -- mind you would Debian have a source per protocol version in a Debian stable release we'd still have a problem in Ubuntu
<lool> +and
<persia> Well, I suppose we could do it that way, although I'm not terribly excited about it.
<lool> It would obviously be easier if upstream would simply support a protocol forever or arrange to support multiple versions of the procol  :)
<persia> Yes, but upstream is exceedingly unlikely to do that: it's a succession of research projects at a university, each release with a new author overseen by the principal investigator.
<persia> I suppose it could be recommended, but it requires catching one of the researchers active, and convincing them to put more effort in than their advisor requires, which may be tricky.
<lool> Yeah it didn't seem very likely to me upstream would change in this regard
 * lool needs to riun
<lool> *run
<persia> Have fun :)
<Baby> pitti: ping!
<tjaalton> how come the adobe-flashplugin isn't built on amd64?
<tjaalton> better ask adobe I guess..
<gnomefreak> tjaalton: i thought adobe made a amd64 build
<tjaalton> gnomefreak: yeah, but apparently it's still beta
<gnomefreak> ah
<tjaalton> the flashplugin-nonfree mess in hardy is pretty bad.. backports has the newest release, which in fact is an older, vulnerable one
<tjaalton> ("newest" meaning the package version)
<gnomefreak> tjaalton: we backported it way too soon we found out afterwards so name was changed to 10.X.X to 10.x.x-really9.X.X
<tjaalton> gnomefreak: but it should be updated now to -really9.0.152.0..
<tjaalton> since if you have backports enabled you have a broken flash
<tjaalton> security wise
<gnomefreak> now that 10 is final we should try it but testing 32 bit worked when i did it to begin with but 64bit failed most of time
<tjaalton> best to just track -updates
<gnomefreak> tjaalton: our script grabs *tar.gz and adobe names every new version the same name
<gnomefreak> last i heard they havent changed it but i heard ubuntu packages were being worked on from adobe
<gnomefreak> that might be a rumor
<tjaalton> gnomefreak: so you're saying that if I reinstalled flashplugin-nonfree, it would pull the correct, current version?
<tjaalton> gnomefreak: no, it's the adobe-flashplugin -package I asked about
<gnomefreak> no we need to update md5sums to match new upstream tarball
<tjaalton> ok, so I'll do it locally then
<gnomefreak> thats most likely why its failing (without seeing errors
<tjaalton> probably, but I'm talking about security issues ;)
<tjaalton> lunch->
<tjaalton> right, no flash9 available anymore
<pitti> fta_: Miriam Ruiz contacted me, she also packaged it; we merged our packaging, and it's now standard debian/-only packaging branch with cdbs+quilt; I'm just uploading it to my PPA
<pitti> Baby: pong
<Baby> :)
<pitti> Baby: oh, Miriam! nice nick :-)
<Baby> thanks! :)
<bardyr> wtf
<sebner> hello to the Debian games lady :)
<ScottK> lool: https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support is our attempt to address the problem
<Baby> :)
<Baby> hi sebner!
<Baby> I'm having a look at those ttf replacements I wanna make in calibre :)
<pitti> Baby: great
<pitti> Baby: did you get along with the bzr stuff? anything major I missed in the packaging merging?
<Baby> to be honest, I haven't downloaded it yet, I'm making local experiments :)
<Baby> I added a logo to the Team though :)
<pitti> yay logos
<Baby> yup!
<Baby> making software in fact is just an excuse for making logos ;)
<pitti> I'll be online for another hour or so, so catch me if you need help with the bzr stuff
 * pitti is utterly bad at graphics design
<Baby> oki :) thanks!
<Baby> anyway if I don't solve that ttf stuff soon, I'll upload it to NEW anyway with that quick replacement
<pitti> Baby: you are trying to get rid of the "Pythonized ttf" stuff and just load the TTFs during runtime, as they are?
<pitti> that would make most sense to me
<Baby> yup
<Baby> exactly that
<pitti> the package would get smaller, and many people have those fonts already installed anywa
<pitti> awesome
<pitti> Baby: what kind of e-book reader do you have, BTW?
<Baby> 505
<Baby> :)
<pitti> ok, so do I
<pitti> Baby: then you'll enjoy working hal rules :)
<Baby> there was someone in linuxchix asking for calibre for ubuntu for an older reader
<Baby> so I might get feedback from her
<pitti> the 500?
<pitti> Baby: in the meantime, do you want me to work on an improved get-orig-source which throws out the TTFs and produces a cleaned orig.tar.gz?
<Baby> yup, that is also needed
<pitti> (we'll need that in either case)
 * pitti starts fiddling
<Baby> you can generate it by just making the suggested replacement by upstream
<Baby> and then we patch it in the packaging
<pitti> Baby: I think the orig.tar.gz should just have it thrown out
<pitti> Baby: symlinking/copying should be done in debian/rules IMHO
<pitti> no need to carry duplicate bits into the orig
<Baby> I'd go for symlinking
<Baby> hmm ok
<Baby> I'd go for symlinking in orig anyway
<pitti> roger
<pitti> Baby: (I'm just thinking it's more flexible to do it in debian/rules, then we don't need new orig.tar.gzs when we change the patches/approach)
<Baby> if we replace it with symlinks the orig can still stand for itself
<pitti> back in 5
<Baby> but it's OK any way for me :)
<pitti> Baby: stand for itself> good point; let's do that then
<barefoot> anyone know if/when python3-tk is gonna be created/released ?
<lool> ScottK: Aha, thanks
<slytherin> What is the username/password to be used for using email interface of requestsync?
<rjune_> anybody know how I get a project out of the trash bin on source forge?
<Uuu> Developers! Developers! Developers!
<Uuu> Happy new year! :)
#ubuntu-devel 2009-01-01
<_nemesis_> hallo, i found a bug, uptime: 02:04:31 up 8588 days, 23:09,  4 users,  load average: 0.41, 0.42, 0.35
<_nemesis_> uname -a: Linux 8101 2.6.24-22-generic #1 SMP Mon Nov 24 18:32:42 UTC 2008 i686 GNU/Linux
<_nemesis_> what can i also search for, to prove that this uptime is real ;)
<phix> hey
<phix> installing on an encrypted volume, LVM, on dual boot system, when defining  /boot partition grub is setup to boot off hd0,0 instead of hd0,1 and kernel for /boot/$kernel_version instead of /$kernel_version
<phix> bug, some one file it, I CBF, my day off :P Lol
<ScottK> lool: If you have any ideas about how to get that spec approved, I'm all ears.
<phix> ScottK: what specs?
 * Hobbsee scratches head at kees
<NCommander> hey ScottK
<karthik_>  hey i need to switch netween workspaces.. how does it happen internally in the code?
<teddyb> hi
<teddyb> http://packages.ubuntu.com/search?keywords=spice&searchon=names&suite=intrepid&section=all : doesn't have spice
<teddyb> ubuntu has gnucap, but no spice, which is practically the basis for all circuit simulations
<teddyb> gentoo pulls from: http://www.ibiblio.org/pub/Linux/apps/circuits/spice3f5sfix.tar.gz and creates a package. it'd be nice if a similar package was created for ubuntu
<teddyb> my only worry is that the spice on that link is from 1999. not to say that old is bad, but if there hasn't been _any_ activity since, it's a bit concerning
<teddyb> also gnucap isn't really fully compatible with spice. there are lots of annoying little fixes that have to be introduced to patch the differences
<persia> karthik_, Look at libwnck
<teddyb> this might help http://osmirrors.cerias.purdue.edu/pub/gentoo/portage/sci-electronics/spice/spice-3.5.5.ebuild : the ebuild has a few good tips to clean
<teddyb> for example, spice doesn't like any more optimization than -O1
<teddyb> also, this patch: http://osmirrors.cerias.purdue.edu/pub/gentoo/portage/sci-electronics/spice/files/spice-3.5.5-gcc-4.1.patch seems to be relevant
<teddyb> i don't have ubuntu on me right now (i use ubuntu at uni, and my current computer is my old gentoo box). i'll see if i can get a vm running soon of ubuntu and i'll try to crank out a spice package
<teddyb> that is if someone else isn't working on something similar
<persia> teddyb, spice isn't very free: you might look at easyspice with ngspice or gEDA.  Alternately, if I'm wrong, you're welcome to submit a package.
<teddyb> the other package i'd been longing for on ubuntu (and even on gentoo it's pretty unstable) is ngspice
<teddyb> i checked out gEDA, but it needs a spice backend
<persia> teddyb, See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<teddyb> easyspice is a gui as well i believe
<teddyb> will do. i have a slow connection, so it'll take a while :(
<persia> teddyb, Actually, as it turns out, there are license issues even with ngspice: see Debian bug #299748
<ubottu> Debian bug 299748 in ngspice "ngspice: legal issue" [Normal,Closed] http://bugs.debian.org/299748
<teddyb> i'm also not an expert by any means. i'm just a student who's trying to learn this on the side, but are you sure about the spice isn't very free line?
<teddyb> hmm, well gentoo has a sci-electronics/ng-spice-rework ... i wonder what that is.
<pwnguin> wha'ts wrong with ngspice?
<teddyb> yeah, it's bsd and gpl-2?
<teddyb> http://ngspice.sourceforge.net
<persia> pwnguin, Dunno: the bug cites license issues, and it was removed.
<teddyb> i'm still looking through the debian bug (downloading an ubuntu cd takes a lot of bandwidth, so pages load slowly :( )
<persia> teddyb, Looking at http://embedded.eecs.berkeley.edu/pubs/downloads/spice/index.htm, it looks like it should have become free in 2007 (which is more recent than the 2005 date for the removal).  If you'd like to investigate, and get it back in, that wouldn't be bad, but be sure to only use the post-free sources.
<teddyb> check this gentoo ebuild as well btw: http://osmirrors.cerias.purdue.edu/pub/gentoo/portage/sci-electronics/ng-spice-rework/ng-spice-rework-15.ebuild
<teddyb> sure, i wouldn't mind.
<pwnguin> odd. the guy who filed the legal issue bug had an ieee email
<pwnguin> do they hand those out to all members?
<teddyb> i guess it's good to keep on multiple distros. keeps everyone on their toes :)
<teddyb> i think so
<teddyb> have yet to get a membership (can't justify the cost yet)
<persia> All full members, yes.]
<pwnguin> have you seen oregano?
<persia> Hrm.  The 1994 Berkeley "Research Software license Agreement" doesn't look all that free: it permits redistribution, but only gratis (or with charge for supporting materials), and has the advertising clause.
<teddyb> oregano needs spice backend
<teddyb> they are all frontends in ubuntu's repositories. the only exception is gnucap
<teddyb> and it's good, but i've been running into a lot of problems rectifying the differences between what the ibiblio circuits books say to use for circuit simulations on spice and what gnucap will work with
<persia> Well, it looks like spice got free in 2007, so with a bit of work, and some license review, it ought be suitable for inclusion.
<teddyb> wonderful
<pwnguin> "got free"
<persia> pwnguin, Well, it was made more free.  See the homepage.
<pwnguin> fyi, the guy who does the fedora electronics lab spin also pays attention to ubuntu
<teddyb> lab spin?
<pwnguin> a remix
<pwnguin> comes with a bunch of things installed by default like gEDA
<teddyb> oh, i thought you were being negative or something
<teddyb> oh yeah, there's a fatty DVD of electronic programs available through gEDA iirc. ngspice is one of the things found on it
<persia> Are Fedora remixes conventionally called "spin"s?
<pwnguin> persia: i think so.
<pwnguin> they only recently tried the idea
<pwnguin> http://spins.fedoraproject.org/
<teddyb> so it seems as though the spice3f5sfix is antiquated. would it make more sense to package ngspice then?
<teddyb> especially considering ngspice is based on the berkeley spice3f5?
<persia> teddyb, If ngspice inherited the freeness of spice, yes, but you'll want to check the licenses carefully.
<teddyb> i don't know if i'm qualified to do that
<emgent> HNY people.
<teddyb> i'm not a lawyer and i don't want to taint ubuntu with legally dubious packages
<teddyb> does ubuntu have any sort of legal consulation for package maintainers?
<persia> teddyb, You can ask for input on the freeness of a license in #ubuntu-motu
<persia> The ultimate decision lies with the archive admins, but they don't tend to have time to speculatively consult.
<persia> If you can get a couple of the MOTU to agree that the license is probably free, the archive admins will review and check.
<pwnguin> teddyb: you could always just ask debian about it ;)
<persia> And you could always package it for Debian, and let Ubuntu inherit it :)
<teddyb> oh true
<teddyb> it'll hit main by 2035 ;)
<pwnguin> in fact, i bet there's a rocket enthusiast who might appreciate ng-spice
<persia> heh
<teddyb> oh, just googling for ngspice debian gets a few packages already made
<pwnguin> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768
<ubottu> Debian bug 489768 in wnpp "ITP: ngspice -- A Spice circuit simulator" [Wishlist,Open]
<teddyb> particularly annoying: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768#15
<ubottu> Debian bug 489768 in wnpp "ITP: ngspice -- A Spice circuit simulator" [Wishlist,Open]
<persia> Why is that annoying?
<teddyb> that was more than a month ago, but then again, i guess thanksgiving, winter break, etc.
<pwnguin> they may have forgotten to follow up
<persia> Also, it means that someone else is chasing the licensing situation, which can only be a good thing :)
<teddyb> well, i remember being tangentially interested in this in the summer and not getting much feedback from anyone related to ubuntu, so i quickly gave up and got back to other stuff
<teddyb> but i really have nothing better to do, so might as well make it worth my while. i'll see if i can send an email out to either "Gudjon I. Gudjonsson" <gudjon@gudjon.org>
<teddyb> or to the ngspice people
<pwnguin> get some debian people interested in it ;)
<persia> I'd recommend sending a follow-up to the bug first, asking about the status, just so nobody else does that: those working on it only need to be poked once.
<teddyb> you keep ;)... but i'm not too sure why. are they difficult people to work with or something?
<pwnguin> i donno
<pwnguin> too lazy to use : i guess
<teddyb> i know a lot of ubuntu people (developers especially) are extremely friendly and willing to help. colin watson definitely springs to mind
<teddyb> and these two people i met on irc.. persia and pwnguin :)
<pwnguin> well, if ngspice is good enough for ubuntu, its usually good enough for debian
<pwnguin> in which case, you'd want someone in debian to take up debian's end of the deal
<teddyb> what's ubuntu's policy with old packages that are no longer getting support by the way?
<teddyb> like spice3f5
<teddyb> is it better to have crufty old packages in the repositories just in case someone wants them?
<pwnguin> well, if it's a case of "never works" it's probably a waste of compile time and just a gordian knot
<persia> teddyb, Opinion is split.  There are several folk who argue they are potentially useful, and others that argue they should be gone.
<pwnguin> if it's old and functional, I don't see the pain
<teddyb> gordian knot.. hmm, wiki'ing. also, it works. i just compiled it earlier today and it works
<pwnguin> i mean, by that criteria we would probably lose our only font editor
<persia> Practical result is that packages typically get removed when either 1) they get removed from Debian, or 2) there are persistent unfixable compilation, runtime, or legal issues that attract the attention of a developer
<teddyb> although, it was gentoo patched, which could mean the original source was a dog and i ended up with a stallion
<pwnguin> well, upstream is active
<pwnguin> in the case of ngspice
<persia> teddyb, If the patches are good, there's no reason not to use them :)
<pwnguin> so as persia says, no reason they can't be pushed upstream or sideways
<persia> Generally, I prefer both :)
<teddyb> yeah, but spice3f5 isn't. i'll definitely look more into ngspice, but since spice works as well... why not?
<teddyb> anyway, i'm really tired, should head to bed. it's been a pleasure discussing this with the two of you. thanks for all your input
<teddyb> goodnight
<pwnguin> im super confused about where the tarball for ngspice-rework018 is
<pwnguin> oh, apparently they don't know how to seperate packages correctly =/
<pwnguin> so the mingw version supercedes -18
<veloc1ty> moin
<crid> Hi all. And happy new year!
<crid> If I have some project I would like to see in repsitories of Ubuntu. What I should do?
<crid> Project which I'm talking about is here: http://ait.berlios.de
<sebner> !revu | crid
<ubottu> crid: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<crid> thanks
<anilg> Hi.. is there a bounty system at launchpad?
<persia> anilg, There used to be, but it was mostly delinked or removed because it didn't turn out to work so well.
<persia> anilg, For more detail, you might ask in #launchpad next week.
<anilg> Thanks. Why next week?..
<persia> Because it seems that most of the #launchpad folk are on vacation this week.
<savvas> what's a bounty system? :p forgive my ignorance
<persia> savvas, A place where one posts work one wants done, and remuneration on offer for the work.
<persia> Others can add to the remuneration, or volunteer for the work.
<savvas> like revu for packagers?
<savvas> looks interesting, thanks
<persia> Not really.  It's about money.
<savvas> ah :P
<savvas> now it makes sense :) rent-a-coder hehe
<anilg> savvas: yes.
<anilg> A bounty system makes sense on a palce like launchpad.. I wonder what didnt work out
<savvas> anilg: What would happen if people place money on something they want done that doesn't get implemented? Would they allow team cooperation or single-person updates when using such a system and how would the team share the money, by length of bytes?
<anilg> I would assume folks would collaborate, and start off with what everyone would do and how they would share the bounty
<anilg> usually bounties are small tasks that individuals can take up
<anilg> so its more of a do this and get this
<savvas> then there's the possibility of abuse, a lot of people taking up a lot of tasks and never doing anything :p I hope that's not the case in the real world though
<Mithrandir> not all bounty systems allow you to lock a bounty, it's just a race to completion.
<savvas> and quality :)
<savvas> but then people with money would actually run the development with "do this and do that" tasks
<Mithrandir> savvas: yes, and?  It's not like you can't effectively do that today, if you have enough money.
<Mithrandir> usually, bounties have been tiny compared to how much it'd cost to hire somebody to do the work
<savvas> hm.. you mean making custom versions of programs?
<savvas> without actually touching the official releases? if it wouldn't be dependant to the projects' trunk, then I'm all for it!
<savvas> er.. * if the projects' trunk wouldn't be dependant to the tasks
<Mithrandir> integration into mainline is usually a condition on most bounties.
<savvas> yes, that :)
<bbechdol> Hello everyone
<bbechdol> Happy New Year :)
<pwnguin> Mithrandir: i dont think the problem with the lp bounties was in the race to finish part; it's probably a function of a) tiny bounties funded by individuals and b) failure to aggregate bounty across individuals
<pwnguin> so one guy says "i'll pay 20 dollars for this"
<pwnguin> and another guy says "i'll pay 40"
<pwnguin> lp didnt add up those bids; and nobody will work for a 20 dollar project
<rootard> Hi all (and hny), I'm having a strange issue with dpkg unpacking a symlink that overwrites a file (in the same package)
<rootard> This is on Nexenta (OpenSolaris) so it's not strictly an Ubuntu issue but I'm looking for some pointers on where to dive into
<rootard> there is a file "/usr/bin/tcsh" and a link "/bin/tcsh -> /usr/bin/tcsh"  and when the package is unpacked (via dpkg -X tcsh_*deb /) then /usr/bin/tcsh becomes a link to /usr/bin/tcsh
<rootard> however, if I unpack to another directory (dpkg -X tcsh_*deb tmp) then the directory structure is fine
<andersk> Is there a reason you are unpacking the package to / rather than installing it (dpkg -i tcsh_*.deb)?
<rootard> to try and debug the issue
<rootard> dpkg -i   does the same thing
<andersk> This sounds like what might happen if you somehow had /bin a symlink to /usr/bin (or vice versa), though that would be really weird.
 * rootard smacks self
<rootard> crap
<pwnguin> heh
<pwnguin> why would you do that?
<rootard> good question... I don't know what that is done but it seems to be a Solaris'ism
<rootard> :-/
<rootard> *why
<rootard> well, thanks. The patch to the package is simple then.
<rootard> Hmm, if I were to make the patch a little more robust than just commenting out the "ln -s" in debian/rules, how might I approach this? I think hurd (last time I used it...) had some kind of crazy /usr -> /  setup.
<rootard> so just detecting /bin to be a symlink isn't enough.
<rootard> is there some (simple/portable) way to see if /usr/bin is the same as /bin ?
<andersk> Checking whether /bin is a symlink with [ -L /bin ] is probably close enough.
<andersk> It's dangerous for a package to install anything into a symlinked directory.
<pwnguin> if the symlink is usually there in nexenta
<pwnguin> it's probably the case that the nexenta developers have solved this before
<rootard> I think it will always be there. I just checked a Solaris 10 host and it's the same
<andersk> You could try checking whether [ "$(stat -Lc %D%i /usr/bin)" = "$(stat -Lc %D%i /bin)" ], I guess.
<rootard> bash seems to support if [ /bin/ -ef /usr/bin/ ]
<andersk> Oh, cool.  (So does dash.)
<kolby_> are any developers here paid by canonical?
<Hobbsee> a fair few of them
<Hobbsee> likely not here right now, though
<kolby_> I don't think I have a good enough resume to apply.
#ubuntu-devel 2009-01-02
<kolby_> There's not really any college classes to take for open source developers are there?
<Laney> kolby_: Well it's more about getting stuck in than taking classes I suppose
<directhex> Laney, IMHO that's the case with free software work generally
<Laney> right, that's what I meant
<directhex> Laney, i didn't get my cushy linux sysadmin job, with root on a couple of million quid of kit, on the basis of stuff i learnt in classes. i got it on the basis of the linux mucking about i did instead of revising for exams! :)
<Laney> theory != practice
<directhex> well, yes. and so much of computing is a mix of both
<Laney> mhm
<Laney> kolby_: Pick a project, get your hands dirty :)
<directhex> purely practice and, well, you get the mess of people who answer linuxquestions or ubuntuforums posts with things involving --prefix=/
<directhex> purely theory, and you go nowhere fast either
 * Laney only knows theory ;)
<Laney> silly academia
<Laney> "When was the last time you ran one of your programs?" is a joke in our lab :S
<kolby_> what classes do you take?
<Laney> none - I'm doing a PhD ;)
<kolby_> amazing.
<directhex> pfft, bloody students
<Laney> quite
<directhex> bane of my sodding life, the lot of you
<kolby_> I have about... 1/2 a bachelor
 * Laney files a support request with directhex
 * directhex disparages Laney on rt-comment@
<Laney> DATA PROTECTION REQUEST
<kolby_> is socket programming necessary for network programming?
<kolby_> or is it going too deep for simple game programming?
<directhex> Laney, certainWHOOPS, i got my SELECT and DROP the wrong way round in postgres
<directhex> kolby_, what kind of game? and i think we've deviated into #ubuntu-motu territory here
<Laney> it's OK, you have highly redundant backups... right?!?!?
<directhex> Laney, they were redundant, so i binned them!
<Laney> foiled again
<kolby_> directhex: so what is this channel for?
<Laney> I'd say it's something like Development of Ubuntu (not support, not app development on Ubuntu)
<kolby_> okay
<Laney> #ubuntu or a general programming channel
<directhex> better fit than here, albeit not ideal either
<directhex> this is the lair of scary people like jono. he can devour you in one bite!
<kolby_> maybe ##c
<kolby_> jono sounds like a cool enough guy.
<directhex> yeah, sure. but you'll go there without me. i don't do c.
<kolby_> I still haven't heard jono's metal.
<Laney> #haskell is where all the rock stars go to code
<directoct> directhex: mwahahaha.
<jono> directhex, shame on you :P
 * directhex tosses a bacon cookie @ jono 
<jono> :)
<directhex> chocolatey AND meaty!
<directoct> Laney: haskell != game programmer friendly
<Laney> not necessarily
<directhex> c != friendly ;)
<directhex> all depends on what you're doing, and where your bottlenecks are, of course
<Laney> I wrote sudoku in it!
<directoct> directhex: that's about as unhealthy as these "deep fried chocolate covered twinkies" I saw at the state fair.
<directhex> bacon! http://www2.apebox.org/wordpress/wp-content/gallery/00-single/normal_IMG_0551.JPG
<directoct> sudoku... has the _potential_ to be resource intensive.
<directhex> pro-grade games are written in multiple languages
<directhex> usually
<kolby_> pro-grade = something like wow?
<directhex> graphics engine in something like c, and all the game logic in something easier like lua, python, or a custom language (like unrealscript)
<kolby_> directhex: ohhhhh...
<kolby_> I should boiler-plate my code.
<kolby_> I suppose it has been a trend.
<directhex> as an example, Sid Meier's Civilization 4 uses Python 2.4 for all the game logic
<kolby_> directhex: you lie beautiful lies.
<directhex> /media/disk/Program Files (x86)/Firaxis Games/Sid Meier's Civilization 4/python24.dll: MS-DOS executable PE  for MS Windows (DLL) (GUI) Intel 80386 32-bit
<savvas> (Literal reply: take that!)
<kolby_> I have to tell you directhex, that's great news.
<savvas> :)
<directhex> many games use some Free Software somewhere
<kolby_> directhex: ...so where's the credit?
<directhex> kolby_, erm... hiding!
<directhex> kolby_, in the back of the manual, generally
<kolby_> why wasn't I informed about my nice open source dlls?
<savvas> the python license doesn't expect credit I think, right?
<directhex> dunno. i don't do python
<directhex> vorbis.dll is a common one to find - all unreal tournament games since 2003, and some others (e.g. grand theft auto san andreas) use vorbis
<kolby_> well...  they credit their stupid middleware.
<directhex> as well as sony's singstar karaoke games for playstation
<kolby_> directhex: I'm sure neversoft used it for their games.
<directhex> possibly
<directhex> generally, game developers have obscene deadlines & budget limits. they just go for the easiest route - best balance of cost & time
<kolby_> directhex: nice wordpress site btw.
<directhex> sometimes they opt for vorbis, sometimes they pay for mp3. sometimes they use python or lua, sometimes they pay devs to write something in-house
<kolby_> strange cookies...
<directhex> a few devs are using mono now for console development
<directhex> and iphone
<kolby_> at least C# has mono developer's respect
<kolby_> C# always seemed like M$'s answer to Sun's Java.
<directhex> to an extent, it is
<directhex> they got into trouble for making their "own" modified java, back in the early days of XP, so they took their ball & started their own game
<kolby_> learning new launguages can be fun.  Python was fun to learn.
<directhex> i disagree on principle with whitespace sensitivity
<kolby_> I like that idea.
<kolby_> don't think of it as forced style.  Think of it as time well spent without "; punctuation"
<kolby_> plus the code does look pretty.
<directhex> hmm, i find python ugly
<directhex> i like my {}!
<kolby_> then again, I use underscores and full words in variabl names.
<kolby_> dont me this:  strange_function(crazy_array[x][y][z][r]);
<kolby_> s/me/mind
<bbechdol> Evening all
<Laney> Can someone unsubscribe u-m-s from bug #310349, please?
<ubottu> Launchpad bug 310349 in eog "eog does not handle nonadobe CMYK JPEGs correctly" [Undecided,New] https://launchpad.net/bugs/310349
<Laney> erm, bug #313049 even
<ubottu> Launchpad bug 313049 in smstools "Please merge smstools 3.1.3-1 from Debian experimental (main)" [Undecided,Confirmed] https://launchpad.net/bugs/313049
<ScottK-desktop> Laney: Done.
<superm1> tjaalton, the "upstream installer" for fglrx builds the same debs that you would get from the archive.  (things that get uploaded to the archive are built with --buildpkg Ubuntu/source, while if you run it locally then --buildpkg Ubuntu/intrepid etc)
<android60> are there plans to add support for atheros 5007eg cards in jaunty via the madwifi hal 10.5.6
<android60> ?
<atester> what packages do I need to install in order to get the binary nvidia drivers in Jaunty?
<tjaalton> superm1: ok, you may reopen those if you like :)
<DktrKranz> StevenK, regarding bug 311706, TechBoard granted me upload privileges for SCons, is that sufficient to process the sync?
<ubottu> Launchpad bug 311706 in scons "Please sync scons 1.2.0-1 (main) from Debian experimental (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/311706
<StevenK> DktrKranz: I guess so. I'll add it to the processing list
<DktrKranz> I don't know where uploads privileges are stored (no UI yet, IIRC)
<DktrKranz> StevenK, if you have some spare time, mind NEWing amule-adunanza backport for intrepid and hardy (binary packages)?
<StevenK> DktrKranz: Still dealing with the eleventy million syncs
<superm1> tjaalton, well the ones i saw fly by were actually issues from jockey that are fixed by a jockey in -proposed, so it shouldn't be a big deal
<tjaalton> superm1: oh, excellent
<jardi> hi all
<jardi> I want to submit a patch to launchpad, but I can't remember the right diff options to make a "good" patch
<Riddell> jardi: diff -urN
<Riddell> the -u is the important bit
<jardi> thanls Riddell
<jardi> -l+k
<NCommander> cjwatson_, ping
<stgraber> tjaalton: hey, I just upgraded to the ati/readon driver you uploaded today (?), did you see bug 311867 ?
<ubottu> Launchpad bug 311867 in xserver-xorg-video-ati "[M76 Mobility HD 2600] X fails to start - undefined symbol: exaDriverAlloc" [Undecided,New] https://launchpad.net/bugs/311867
<tjaalton> stgraber: looks like another dupe of 311748
<tjaalton> stgraber: or maybe not, but might be related
<stgraber> tjaalton: hmm, in 311748 X doesn't seem to crash
<tjaalton> stgraber: so in your case it returns to the console?
<stgraber> tjaalton: yes
<stgraber> tjaalton: well, it gets stuck half-initialized so I have to start X from ssh but starting it shows that undefined symbol: exaDriverAlloc and exit
<tjaalton> stgraber: ok, sound odd since I can't see any dupes :)
<stgraber> tjaalton: well, the error message sounds like a linking issue (that's why I then mentioned that I'm on amd64) but it's clearly the switch to EXA that introduced the bug
<tjaalton> stgraber: ok, try building the driver without patch 104 and see if it helps
<stgraber> building it now
<stgraber> tjaalton: X starts just fine without 104
<tjaalton> stgraber: ok then.. what if you force EXA from the conffile?
<stgraber> started just fine
<stgraber> (I added "Option" "AccelMethod" "EXA" to the Device section)
<tjaalton> so the patch is broken.. let's wait until bryce get's back :)
<stgraber> root@castiana:~/tmp1# grep EXA /var/log/Xorg.0.log
<stgraber> (**) RADEON(0): Option "AccelMethod" "EXA"
<stgraber> that's weird, I'd have thought it'd be more verbose and mention EXA more than one time
<Nafallo> Baby!!! \o/
<Baby> hi Nafallo :)))
<tjaalton> bryce: stgraber confirmed that without ati patch 104 his X can start (bug 311867
<ubottu> Launchpad bug 311867 in xserver-xorg-video-ati "[M76 Mobility HD 2600] X fails to start - undefined symbol: exaDriverAlloc" [Undecided,New] https://launchpad.net/bugs/311867
<tjaalton> bryce: but forcing EXA by using AccelMethod in xorg.conf worked fine
<tjaalton> (huh, thought I was on #ubuntu-x)
<tjaalton> afk, BSG ->
<YokoZar> Popcon says Wine has more installs than sun java6 now
<YokoZar> (~39%)
<YokoZar> Is the new Gecko backwards compatible?
<YokoZar> oops wrong channel
<directhex> YokoZar, the number doesn't take into account the number of people using sin java for windows with wine!
<YokoZar> directhex: fair enough ;)
<directhex> hm. "sin java". typo or freudian slip?
<YokoZar> directhex: also doesn't count people using wine/firefox for windows flash
<directhex> cool kids use wine/msie for windows silverlight!
<NCommander> o_o;
<NCommander> directhex, IT BURNS
 * NCommander has WINE installed for the Windows version of firefox ...
 * directhex burns NCommander 
<directhex> NCommander, progress with ikvm! it compiles! and runs!
<fta> stgraber, http://paste.ubuntu.com/98620/
<stgraber> fta: thanks, applied. I don't really know why I changed it to parseString in commit 48 but it can't be a good reason (otherwise it'd be in the commit message) :)
<fta> stgraber, thanks. i read you wanted to release 0.11 about a month ago, i can't see it in jaunty. am i missing something?
<stgraber> fta: well, it's released. I'm just waiting on Debian to package it, then request the sync.
<stgraber> fta: if it's not soon, I'll just upload the new upstream myself.
<ebroder> Any core devs wiling to sponsor an upload for LP #216761 ?
<ubottu> Launchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761
<stgraber> fta: or do a 0.11.1 with the few patches I received and then upload it :)
<fta> stgraber, and chance you can add a default action instead of showing usage ? i'm sick of adding "-i -"
<fta> stgraber, especially that it's not consistent... you can add "-i -" or "-f text" to work around the test. imho, it's useless.
<fta> (s/and/any)
#ubuntu-devel 2009-01-03
<Mez> stgraber: pastebinit ?
<Mez> stgraber: 0.11 is in experimental :D
<Mez> stgraber: cant you add paste.debian.net and german translation to upstream?
<Mez> make the DD's life easier :D
<fta> Mez, http://bazaar.launchpad.net/~pastebinit-developers/pastebinit/trunk/revision/52
<fta> Mez, well, it's just the example, not the default.
<Mez> is that in 0.11 ?
<fta> Mez, if i read correctly, 0.11 is bzr rev 59 so yes
<Mez> weirdness for the changelog then
<fta> http://bazaar.launchpad.net/~pastebinit-developers/pastebinit/trunk/changes
<Mez> ah, in the changelog to close the bug
<Mez> changelog made it look as if it was a debian change
<fta> and german po: http://bazaar.launchpad.net/~pastebinit-developers/pastebinit/trunk/changes?start_revid=47&filter_file_id=de.po-20080810155459-jcjal0uxl8jlqyqk-1
<fta> stgraber, something like this: http://paste.ubuntu.com/98646/
<stgraber> fta: looks good, I'll just need to check what happens when reading some weird content from stdin, we had something like what you did in you diff but failed when for example reading from bzr diff ...
<fta> stgraber, yep, when the command takes too long.. i know. but i don't see the difference with my patch and "-i -", both should react in the same way
<fta> stgraber, indeed.. http://paste.ubuntu.com/98651/
<stgraber> fta: Nope, I guess the issue was that previously I was trying to detect if I was receiving something on stdin and if not show the usage
<stgraber> if you just always read stdin, it should be fine
<fta> apparently not
<stgraber> stgraber@sahal:~/pastebinit$ bzr diff | pastebinit -
<stgraber> KeyboardInterrupt caught.
<stgraber> that was the problem with 0.10
<stgraber> with your change it seems to work fine here (using pastebin.com)
<Laney> does the patch remove the need for the -?
<stgraber> yes
<Laney> :D
<stgraber> with fta's patch you can just: something | pastebinit
<Laney> win^win
<stgraber> thought when starting pastebinit without piping something it won't give you the usage
<fta> that's why i introduced -h
<Laney> well that's what e.g. cat does
<Laney> so it's not that alien imo
<stgraber> right
<fta> but bzr diff seems to fail the sys.stdin.read() :(
<stgraber> fta: when it does it should give youu a KeyboardInterrupt
<stgraber> fta: if it doesn't and just give you a wrong url, it's probably because bzr diff just returns nothing
<stgraber> (I should check the content from stdin and not let the user send nothing)
<fta> ix:~/bzr/firefox-3.2.head$ bzr diff -r 386 | pastebinit
<fta> http://paste.ubuntu.com/98664/
<fta> right :)
<stgraber> stgraber@sahal:~/pastebinit$ bzr diff pastebinit.xml | ./pastebinit
<stgraber> Didn't receive anything from stdin, exitting.
<fta> good
<stgraber> well, I should just check every input actually as the same would happen with an empty file
<stgraber> new code pushed
<fta> stgraber, excellent! you should really bzr whoami yourself on sahal :)
<stgraber> fta: argh, I thought I had :)
<stgraber> it's my eee, I don't usually work on it ...
<stgraber> fixed (for next time ...(
<mikestaszel> hey, quick, n00b question - what is run when ubuntu's firefox installs the flashplayer plugin, or totem installs gstreamer - is that a synaptic starting?
<The_Kid123> Hello All
<The_Kid123> Well, for the log bots, I'm looking to somehow get involved in helping with Ubuntu development. I've used ubuntu heavily since 7.10, but I intermittently used snce 6.06. I don't really know where specificly I'd like to help, but I'm interested in OS components from the command-line down, be it init scripting, installers, or wherever I could be of help. I'm willing to learn what I don't yet know. I'll start being on here more, so hopefully the appropr
<ScottK> The_Kid123: #ubuntu-motu is a better channel for just getting started in development.
<The_Kid123> ok, thanks much... think anyone will be on @ this hour?
<ScottK> Maybe a few.
<The_Kid123> alright, peace to all
<shankhs> hi
<Yoe> ogra: you may want to have a look at the diff for nbd_1:2.9.11-2
<Yoe> ogra: especially the third bullet point in the changelog
<Yoe> ogra: since I understand that ubuntu has no /lib/init/rw, and that sendsigs does things differently there
<Yoe> ogra: I couldn't exactly test that, though, having no ubuntu and all; but if you send me a patch that doesn't break my version, I'll take that into Debian
<ogra> Yoe, thanks for the info, i'll take a look next week (still on vacation atm :) ) ... happy new year btw
<Yoe> ogra: you too :-)
<Yoe> ogra: and you're welcome
<ogra> :)
<seria-mau> hi
<seria-mau> i heard that the ifup/ifdown framework will be discarded in jaunty jackalope and networkmanager used instead. is this true?
<directhex> seria-mau, n-m has been the default for years
<seria-mau> not on my system
<directhex> then you've been doing nonstandard things.
<Hobbsee> i thought that jaunty was supposed to take things in /etc/network/interfaces, and use them properly, thus ifup/ifdown would be deprecated (or hidden away)
<seria-mau> well. if ifup/ifdown leaves ubuntu, i will leave, too. sadly. i like it. and i dont think n-m is ready, yet.
<seria-mau> (no offense itended)
<Chipzz> directhex: you were not answering his question though
<Chipzz> directhex: he did not ask wether NM was the default; that's totally irrelevant
<Chipzz> he DID ask wether the OTHER option would be discarded
<Mithrandir> I'd be quite surprised if NM became mandatory for servers and such
<Chipzz> y
<directhex> is there actually a command-line nm yet? nm-tool is report-only in intrepid
<Chipzz> if it ever does I'll immediately wipe ubuntu from every single one of my boxes it's installed on
<Mithrandir> directhex: dbus-send? :-)
<directhex> Mithrandir, don't make me stab you
<directhex> Mithrandir, technically though, some bash scripting around dbus-send could replace ifup/down ;)
 * Chipzz considers NM broken by design
 * Chipzz takes out his shotgun and shoots directhex :P
 * directhex considers nm a farking necessity on a laptop
<Mithrandir> I started writing a blog post about what a proper network configuration tool should handle.
<Chipzz> directhex: there are other ways of achieving the same
<Mithrandir> working as a consulant where you have to set up static routes, tunnels and such to reach into other systems have shown me that NM really doesn't handle my needs, but then, nothing else does either.
<Chipzz> directhex: even without installing any additional software except ifup and wpa-supplicant
<Chipzz> directhex: have you read all the docs that ship with the wpa-supplicant package?
<directhex> "just edit this conf file" is never, never ever ever, a solution for anything on a desktop system. it's a cheap hack
<Chipzz> and having a *user*-program handle a *system* property is broken by design, period
<directhex> Chipzz, ever heard of FUSE?
<Chipzz> yes, and I also consider that broken
<Chipzz> it has its uses, but gets abused to work around a lot of crap, instead of fixing that crap properly
<seria-mau> to be fair, i use n-m on laptops, too. but on my workstation here i have 3 net interfaces: one which receives dhcp from a cable modem and the other two handing out dhcp with the use of dnsmasq to guests etc.pp.
<seria-mau> i really dont know how to do this with n-m
<Mithrandir> Chipzz: user, as in nm-applet or NM itself?
<Chipzz> nm-applet
 * directhex demands cdrecord only run as root, just as god^Wschilly^Wgod intended
<Chipzz> what I meant is basically that you control a system property (something that is inherent to the system, and can affect not just you, but other people too on a multi-user system) via a user
<Mithrandir> there's no principal difference between having it as an applet and having the ability to edit a config file.
<Chipzz> imo the difference is the approach of changing things
<Mithrandir> I disagree, it's just a different UI
<Chipzz> there are a lot of other tools which you can manage config files too; they require the proper privileges though, like going through sudo; ie basically changing to root
<ogra> NM uses polkit .... which is the sudo of the future :P
<Mithrandir> well, we're moving towards a more fine-grained security model where you can actually give somebody the ability to, say, add users, set the system clock or similar tasks without giving them complete control of the system.
 * Chipzz notes that this is much like how things tend to get done on other *NIX'y systems
<Chipzz> errr
<Chipzz> +not
<directhex> other NIXes don't have fine-grained ACLs for things?
<Chipzz> they do; but don't require you to have several daemons running to do so
<ogra> they also have the beauty of CDE
<Chipzz> ogra: most CDE shipping UNIX'es have switched to GNOME instead ;)
<ogra> so they will start using polkit at some point ... since the apps demand it
<Chipzz> solaris for example also ships gnome; HPUX iirc was also doing that I recall hearing several years ago
<Chipzz> ogra: I disagree; if they don't like policykit, they'll just not ship those apps
<ogra> hard to do ...
<Chipzz> I may be mistaken on this one, but iirc solaris in fact does that
<Chipzz> some things are managed through their java apps
<ogra> the gnome clock applet massively uses time-admin from gnome-system-tools for example ... time-admin relies fully on polkit ... you add a massive maintenance overhead fi you replace such stuff
<ogra> indeed nobody keeps you from patching the defaults ... but the more apps rely on poltik functionallity the harder that gets ... and in the end you end up with a completely forked desktop
<ogra> same goes for NM ... apps start to rely on the fact to have its dbus interface available to query the online status
<maxb> I want to start a discussion on how usb-creator should react to usb sticks without a partition table. Where should I do it? In a launchpad bug? on ubuntu-devel(-discuss)@ ?
<amjed> hello
<amjed> guys girl
<amjed> help me
<yao_ziyuan> it seems startup items management becomes a mess if both ubuntu-desktop and kubuntu-desktop are installed.
<yao_ziyuan> for example, if you enable chinese input methods in ubuntu and then in kubuntu,
<yao_ziyuan> then when you enter kubuntu, you will find there are two 'scim-launcher's in the task manager.
<yao_ziyuan> if you disable input methods in either ubuntu or kubuntu, there will remain one 'scim-launcher'.
<yao_ziyuan> also, things like network-manager-gnome, network-manager-kde
<yao_ziyuan> i suspect many services/programs are started twice
<imachine> tseliot, hey
<imachine> tseliot, any improvements on the new nvidia drivers for 8.10 ?
<imachine> are they getting ported soon?
<imachine> the title-bar mess-up is really annoying ;)
<str33tcat> you can try the lastest beta version of nvidia driver
<imachine> yeah, but I wan't a .deb file.
<imachine> ubuntu-style.
<imachine> I've seen some work done on it by tseliot .
<str33tcat> learn to do some hard word
<imachine> and it seemed nice.
<str33tcat> work
<imachine>  bzr branch lp:~albertomilone/nvidia-drivers-ubuntu/180-intrepid <- I've done this.
<imachine> but I don't know how to build it ;]
<imachine> I've asked tseliot a while ago, but he said it wasn't finished.
<imachine> that's why I'm asking now, maybe he sorted it out :-)
<tseliot> imachine: I'm working on a different project right now but I'll update the packages as soon as I'm done with this project
<imachine> tseliot, great news. can't wait ! :-)
<imachine> cheers
<TomaszD> asac, hey, sorry to bother you, could you please build networkmanager final in the network-manager PPA for Hardy as well? There's only an SVN snapshot available :(
<asac> TomaszD: soon ... i need hardy PPA to get more testing the the next intrepid-proposed upload ... but once thats in i will bump that too
<TomaszD> more testing of what asac ? of the SVN snapshot? I don't understand.
<asac> TomaszD: of the next intrepid-proposed upload, yes.
<asac> just stay tuned ;) ... will happen soonish. there are just two important bugs i want to get fixed before moving to final everywhere
<TomaszD> asac, so intrepid-proposed got the SVN snapshot? Why not test the stable, final version ?
<TomaszD> alright, thanks :]
<asac> TomaszD: its not possible
<asac> to put stable into intrepid because it breaks ABI/API
<TomaszD> oh
<asac> so we have to fix a few more things in -updates by backporting patches
<asac> and then provide final in -backports
<TomaszD> ok
<TomaszD> that makes sense.
<asac> sorry for the delay though
<asac> PPA will get latest asap
<TomaszD> I've been doing quite popular remasters of both 8.04 and 8.10 for the Polish community and one of the nm snapshots behaved weirdly during installation, it connected and reconnected several times
<TomaszD> without actually breaking anything, but that looked worrying
<TomaszD> *during ubuntu installation
<asac> TomaszD: there are not many changes that bring more stability ... except for some wpa variants
<asac> TomaszD: what net/chipset was that?
<TomaszD> asac, it's fine, I just don't want to scare users who actually use 8.04 (stability) to use "unstable" software (svn snapshots)
<TomaszD> asac, that was VirtualBox
<asac> TomaszD: ah ... well. it more or less matches what we ship in intrepid ;)
<asac> so its a vedded snapshot (though not perfect. but even final isnt perfect)
<ebroder> If I'm filing a sync request now, am I expected to justify it past what's in the changelog? (The changelog makes it fairly clear why the sync is important)
<TomaszD> I'm currently running a test install and it does that weird reconnect dance
<asac> TomaszD: do you have anything in /etc/network/interfaces?`
<asac> TomaszD: otherwise paste your complete syslog somewhere
<TomaszD> standard stuff, auto lo and the loopback device
<asac> k
<asac> TomaszD: please paste your syslog after reproducing then
<TomaszD> hmm it seems as though it only reconnected once, it settled down now, I called it too early
<TomaszD> asac, ok reconnected again when trying to reach ntp, will try to get the syslog, but it's a corner case
<TomaszD> how many people remaster 8.04 and add nm 0.7 to it?
<pochu> hello asac. so you don't have any plans for hardy-proposed/updates as of now, do you?
<pochu> (others than try to move the package in -proposed to -updates :)
<asac> pochu: no ... i am talking about intrepid right now
<asac> pochu: intrepid will get one more -updates/-proposed round (should be in sync right now)
<pochu> asac: cool, thanks
<asac> there is an update in -proposed for hardy, yes. i want to get that in. but thats not really what this was about
<pochu> asac: sure, it was an unrelated question to your conversation with TomaszD :)
<pochu> I was interested on hardy's state
<asac> asked another time in bug 203016 whether someone can at least verify that its fixed now ;)
<ubottu> Launchpad bug 203016 in network-manager "Memory Leak in NetworkManager" [Medium,Fix committed] https://launchpad.net/bugs/203016
<TomaszD> asac, http://pastebin.com/m36ef1770
<asac> pochu: yeah. so hardy will stay the same ... ~network-manager PPA will eventually move to final 0.7
<asac> for hardy that is
<pochu> as long as it's not the official archive, I'll sleep like a log ;)
<asac> TomaszD: strange ... your system seems to time-warp?
<asac> 20:02:31
<TomaszD> asac, yes I've noticed
<asac> next line
<asac> 19:02:35
<TomaszD> oh that
<TomaszD> that's just ntp
<TomaszD> RTC time versus GMT+1
<TomaszD> I think...
<asac> TomaszD: does that reconnecting settle at some point or continues forever?`
<TomaszD> no it just happens during installation of ubuntu
<TomaszD> happened two times this time
<TomaszD> or maybe three, I didn't have the vbox window open all the time
<TomaszD> otherwise, during normal operation, it's stable
<TomaszD> this never happens with intrepid btw
<asac> TomaszD: ok. so this i hardy with the PPA NM?
<TomaszD> indeed.
<TomaszD> that's why I was asking if you could build the stable version and maybe this behaviour would go away
<TomaszD> but it's nothing to worry about I guess
<asac> TomaszD: really unlikely that it goes away with stable version. wouldnt know why
<TomaszD> ok
<svu> I just uploaded smth to my ppa - why don't I see it on the web interface?
<Adri2000> svu: off-topic. you want #launchpad instead
<kagou> is it possible to have a persistent partition (ubuntu on usb stick) using fat32 ?
<PovAddict> when I report a bug through apport, why is the bug marked as "This bug doesn't affect me" by default?
<PovAddict> of course it affects me! :P
<svu> Adri2000: thanks!
<svu> (and already resolved)
<beuno> PovAddict, it's a bug in Launchpad
<beuno> it will be fixed soon-ish
<LuXor> hey can someone help?
<PovAddict> Just Ask Your Questin
<maxb> LuXor: The first rule of getting help on IRC is to be as specific as possible
* kssls changed the topic of #ubuntu-devel to: SLANGASEK GET LAID  VORLON MOTHERFUCKER! SERIOUSLY STOP BEING AN UBUNTU/DEBIAN WHORE AND GET A FUCKING LIFE! GET LAID
<LaserJock> uh ... wow
* PovAddict changed the topic of #ubuntu-devel to: UDS: done, alpha-2 released, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* LEOLVFLE changed the topic of #ubuntu-devel to: DO NOT CHANGE THE  topic motherfuckers! vorlon aka slangasek is a fat ass european dipshit who has no life but for ubuntu and debian. as for the rest of you geeklings. please fucking get laid and stop thinking every bitch on the planet loves your sorry ass
* thom changed the topic of #ubuntu-devel to:  UDS: done, alpha-2 released, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * thom wonders idly what brought that on
<Nafallo> thekorn: +t until it passes? :-)
<Nafallo> s/thekorn/thom/
<thom> if it happens again, yeh
<Mithrandir> banning cpe-76-87-77-169.socal.res.rr.com might be a good idea too.
* vikek changed the topic of #ubuntu-devel to: i said dont change the topic you geek half assed pizza eating in front of the cvomputer, shitting in front of the computer motherfuckers! go offline
<Adri2000> hmm
* Adri2000 changed the topic of #ubuntu-devel to: UDS: done, alpha-2 released, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<PovAddict> thom
<PovAddict> +t
<Adri2000> and ban the whole host
<PovAddict> he used a completely different host this time
* VKEKEWKWRW changed the topic of #ubuntu-devel to: hahahahaha fuck +t get with the program! /quit make love to your wife/gfs! question is if you have any! BUT TRYYYYYYYYYYYYY
<Adri2000> ah, right
<Adri2000> ...
<PovAddict> here we go again
* Adri2000 changed the topic of #ubuntu-devel to: UDS: done, alpha-2 released, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Adri2000> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<PovAddict> "fuck +t get with the program!" means he's here right now, his evil nicknames weren't here when we mentioned +t
<thom> sheesh
<emgent> O_o
<emgent> thom: ?
<thom> topic inanity previously
#ubuntu-devel 2009-01-04
<NCommander> cjwatson_, ping?
<ion_> http://zakalwe.fi/pic/ubuntu-scooter.jpg
<ebroder> I want to request a backport for cython into Hardy. Should I request a backport of the Intrepid version (which is universe), or the Jaunty version (which is in main)?
<ScottK> doko__: I just ran across my first module that also ships code to support Python 3.  Is there any guidance on packaging modules to work with Python 3?
 * Hobbsee wonders if the ops call needs anything else done
<cjwatson> ebroder: whichever works best; the universe->main promotion is probably not directly relevant to backporting in itself
<Chipzz> cjwatson: ot, but Keybuk seems to be on vacation; do you know when he'll be back?
<NCommander> hey cjwatson
<cjwatson> Chipzz: everyone in Canonical is on vacation until at least Monday
<cjwatson> (i.e. Monday is the first general day back)
<NCommander> cjwatson, w.r.t. to Xubuntu, universe itself seems to be missing from the LiveCD image itself (as in squashfs)
<cjwatson> NCommander: I looked at the live filesystem build log and it definitely fetches packages from universe
<cjwatson> you can look for yourself, it's in http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
<cjwatson> NCommander: so perhaps you could answer the specific question I posed in the bug?
<NCommander> Oh, ok
<NCommander> Yes, reading now, I think its a red hearing
 * NCommander doesn't pretend to be any expert in liveCDs
<cjwatson> NCommander: what exactly do you mean by universe being missing from the squashfs?
<NCommander> running apt-cache search *stuff* doesn't reveal anything for universe however when running off the CD.
<cjwatson> please be as precise as you can
<NCommander> s/for/from/g
<cjwatson> is that the exact problem, or is there something else too?
<NCommander> Well
<NCommander> It's a sympton of the problem
<cjwatson> I'm trying to get you to be precise
<NCommander> None of the Xfce packages are there, running the liveCD gets you to a fvwm session
<cjwatson> ok, there are two problems here
<cjwatson> the first is that livecd-rootfs doesn't construct the final sources.list correctly; I'll fix this tomorrow
<NCommander> and the second?
<cjwatson> the second is that the archive isn't correctly set up to include Task fields for packages in universe, which I've just fixed
<cjwatson> patience, it's hard to type while carrying a baby :P
<NCommander> Tasks fields?
<cjwatson> just take my word for it, too fiddly to explain now
<cjwatson> lp_archive@cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-misc$ sudo -u lp_publish ln -s more-extra.override.jaunty.main more-extra.override.jaunty.restricted
<cjwatson> lp_archive@cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-misc$ sudo -u lp_publish ln -s more-extra.override.jaunty.main more-extra.override.jaunty.universe
<Hobbsee> cjwatson: this means that the new archive reorg has started?
<cjwatson> no
<cjwatson> absolutely nothing whatsoever to do with that
<Hobbsee> oh, i thought Task fields would indicate it was.  My bad :)
 * cjwatson -> gone for the day
<Hobbsee> enjoy
<comradekingu> * Booting jaunty from usb does not work on my eee 1000. Tried both unetbootin and "Create a USB startup disk"
<Xteven> hi, should I get the same package if I build a sourcepackage without any modifications ?
<Xteven> and if I don't get the same thing, should I consider that a bug ?
<broonie> Xteven: Depends on what the differences are.
<Xteven> it crashes with a buffer overflow if I build it myself
<Xteven> root@guest-laptop:/usr/src# *** buffer overflow detected ***: /usr/sbin/ircd-ratbox terminated
<broonie> Xteven: that's a definite bug, then.
<cjwatson> Xteven: at a guess, it could mean that the binary package in the archive was built with an older version of gcc and that a newer version miscompiles it; or that newer library headers break something; or ...
<Xteven> cjwatson: quite possible
<Xteven> I reported it as a bug :) sooner or later the packager will run into the same problem if he upgrades to a later gcc version
<TheMuso> Greetings. How have your holidays been?
<TheMuso> woops wrong window
 * TheMuso is not obviously back entirely, at least mentally. :p
<LaserJock> my holidays have been fine, how about you? :-)
<TheMuso> LaserJock: Very nice thanks. Its actually good to be back.
<mdke> does anyone know whether the "unzoo" package was intentionally removed from intrepid? It appears to have been present in hardy
<mdke> hiya LaserJock
<james_w> mdke: "Reason: (From Debian) RoM: obsolete, superseded by zoo"
<LaserJock> mdke: hi! long time, no see
<mdke> james_w: just found that page, thanks
<mdke> LaserJock: yeah :)
<james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497775
<ubottu> Debian bug 497775 in wnpp "O: unzoo -- zoo archive extractor" [Normal,Closed]
<Baby> pitti: hi! :)
<crimsun> Xteven: it's an off-by-one
<ion_> I wonder if smb will ever come back online? :-)
<Xteven> crimsun: interesting
<crimsun> i'm sending the patch to BTS with attribution to F10
<Xteven> ?
<crimsun> Xteven: all relevant info is in the debian & ubuntu bugs.
<crimsun> Xteven: (presuming you filed #313820)
<Xteven> aaaaaaah
<Xteven> F10 -> fedora 10 ?
<crimsun> yes
<Xteven> I think I did file that one
<Xteven> yup
<Xteven> ok
<Xteven> well, I'm kindof glad its a bug :)
<Xteven> every discovered bug makes software more secure
<Xteven> well, not really
<Xteven> but I like to think so
<crimsun> if you want to rebuild your own, grab that patch and add it to debian/patches/ in the extracted source, and make sure to add the filename of the patch to debian/patches/series, too
<Xteven> I'll try it out
<Xteven> compiling
<Xteven> crimsun: patch worked, it doesn't crash anymore
<Xteven> thx
<crimsun> Xteven: yw
<seek_therapy> Hi, I just upgraded my cousins computer and she no longer has sound. I have asked several Ubuntu channels and no one seems to have the answer
<TheMuso> seek_therapy: #ubuntu for support.
<seek_therapy> No one there could help me
<seek_therapy> apparently allot of people are dealing with the same problem
<seek_therapy> So.. i am downloading Ubuntu again and am gonna burn the iso and try to reinstall
<Xteven> seek_therapy: I had a problem like that, it had to do with pulse audio
<seek_therapy> do you have a link?
<seek_therapy> or can you tell me what you did to fix it
<seek_therapy> when i turn her system on .. i hear the drum roll , then when i login ...no sound
<Xteven> hmm
<Xteven> not really :(
<Xteven> but maybe you can find some help on the forums
<seek_therapy> and it was pulse audio ?
<Xteven> I just killed my pulseaudio daemon
<Xteven> I'm runing without it now, everything works ok
<Xteven> ubuntu intrepidd
<seek_therapy> Xteven: sorry i am new to all this
<Xteven> np
<Xteven> I think its best to ask in #ubuntu
<Xteven> http://ubuntuforums.org/showthread.php?t=964516
<seek_therapy> sure, if they can help.. Sadly, I talked her and her child into using Ubuntu and she was actually starting to like .then this happens
<Xteven> :(
<Xteven> might want to look through some logs or so
#ubuntu-devel 2010-01-04
<directhex> MenZa, sod it. http://retro.apebox.org/grub-ubuntu3.tar.bz2. shove it in /boot/grub/themes/. the grub.cfg is just an example - the vital parts to extract from it are the gfxmode 1024x768 (the theme is hard-coded, apparently grub bzr supports percentage-based numbers tho), the insmod png, the insmod gfxmenu, and the menuviewer= and theme= lines.
<directhex> theme.txt is my work entirely and under WTFPL 2.0. background image is canonical's and i think it's CC-BY-SA 3.0 or somesuch. other images are based on your work, so licensing is yours to dictate.
<MenZa> directhex: good choice of licence
 * MenZa approves
<directhex> MenZa, forgot to mention, there's an out-by-one error in my boot_menu. i didn't get around to working out which value to tweak to make it fit just right. there are a few out-by-one errors really. oh, and i didn't do your scrollbar (the theme format supports it though, so good news there) as i kinda only had 6 items on my list ^_^
<MenZa> :D
<directhex> i didn't want to break a real pc by messing with real grub Â¬_Â¬
<MenZa> of course not
<directhex> and kvm reboots like lightning
<MenZa> that would be silly
<MenZa> directhex: alright, I added a README and a license text to the txt file
<MenZa> directhex: now uploading
<MenZa> directhex: sent to ayatana@lists.lp
<MenZa> most of the README file is just copy/paste from irssi :D
<TheMuso> c
<joshua___> Well I decided equivs was just too painful for blocking packages (I did it wrong 3 times) that I made a dpkg-block that does it easily.
<ion> Huh? Creating a dummy package with equivs is trivial.
<joshua___> making it replace the existing one so apt-get won't install it is not
<ion> Just use a greater version number, e.g. 42:1dummy or whatever.
<joshua___> oh I see
<joshua___> I ended up making a single package that both Provides and Conflicts all packages by name
<chrisccoulson> superm1 - i've just pushed a gnome-system-tools update to bzr which fixes bug 484559 and bug 497441
<ubottu> Launchpad bug 484559 in gnome-system-tools "Xubuntu: Cannot change own password because users-admin needs gnome-about-me" [Low,Triaged] https://launchpad.net/bugs/484559
<ubottu> Launchpad bug 497441 in mythbuntu "gnome-system-tools 2.29.1-0ubuntu1 is causing all of gnome in Mythbuntu builds" [Critical,Confirmed] https://launchpad.net/bugs/497441
<superm1> chrisccoulson, great thanks.
<chrisccoulson> i can't upload g-s-t though, so feel free to sponosr it if you get the chance :)
<chrisccoulson> s/sponosr/sponsor
<superm1> chrisccoulson, sure i can sponsor later tonight probably.  just need to throw a lucid pbuilder together to test build her
<chrisccoulson> superm1 - thanks
<chrisccoulson> superm1 - the update is here: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-system-tools/ubuntu/revision/21
<joshua___> ugh now I really feel glad I made that tool
<joshua___> I just upgraded my chroot jail to karmic and it installed a bunch of junk (kernel images etc) that needs to be gone
<joshua___> ping
<pitti> Good morning! Happy new year everyone
<Hobbsee> hey pitti!
<ScottK> pitti: Happy New Year.
<dholbach> good morning and happy new year! :-)
<RAOF> dholbach: Good morning!  Hope Christmas & New Years has treated you well :)
<dholbach> hey RAOF - it did! :-)
<dholbach> RAOF: how about you? how's life?
<RAOF> Sweet!
<RAOF> Pretty cool.  It's fun being married :)
<dholbach> oh nice... when did it happen?
<RAOF> October.
<RAOF> But it's still fun :)
<dholbach> cool :-)
<RAOF> There are some photos on facebook, actually.  I should put some of the new ones up, too.
<RAOF> It was awesome :).
<pitti> hey dholbach, gesundes Neues! *hug*
<dholbach> RAOF: nice - I'll have a look in a bit!
<dholbach> hey pitti! and the same to you! :-)
<RAOF> Hugs all around!
<dholbach> SPONSORING! Have a look at http://overbenny.wordpress.com/2010/01/04/empty-ubuntu-universe-sponsors-queue/
 * nixternal crosses finger on distributed development merge
<dholbach> hey seb128
<seb128> hey dholbach
<seb128> happy new year!
<seb128> how are you?
<dholbach> and the same to you :)
<dholbach> good good - how 'bout you?
<seb128> good too thanks
<seb128> I had relaxing holidays and didn't touch the computer much during those
<dholbach> nice :)
<seb128> how was Istanbul?
<dholbach> Ä°stanbul was fantastic - I had a great time :)
<seb128> great ;-)
 * RAOF is unable to see the name âIstanbul" without hearing the They Might Be Giants song :)
<ion> Relaxing time; not touching computer? Thatâs contradictory.
<tseliot> pitti: what's your take on this thread? We need the opinion of the udev guys (and I seem to remember that you're one of them): http://lists.x.org/archives/xorg-devel/2010-January/004497.html
<pitti> hey tseliot, happy new year! looking
<tseliot> pitti: thanks, happy new year to you :-)
<pitti> I have noticed that "the ability to set the Xorg driver, or arbitrary driver
<pitti> options, directly through udev has been removed".
<pitti> tseliot: ^ oh?
<tseliot> yep
<pitti> tseliot: was the udev backend accepted upstream now?
<tseliot> yes
<tseliot> but only xkb options can be passed
<tseliot> pitti: which is why I proposed that new feature
<tseliot> pitti: if you have never heard of xorg.conf.d: http://who-t.blogspot.com/2010/01/new-configuration-world-order.html
<pitti> tseliot: I heard about it, but no details yet; ok, let me digest the thread and the blog post
<tseliot> ok, thanks
<pitti> ah, so http://cgit.freedesktop.org/xorg/xserver/commit/?id=435f27667f84269768efecde34de4af2b2d43376 was the upstream commit
<dpm> good morning and a happy new year to everyone!
<pitti> tseliot: do you know how this can set the driver in the first place?
<pitti> hey dpm, good morning and happy new year!
<tseliot> pitti: the udev backend (see config/udev.c) in the xserver already passes options and flags to X: http://cgit.freedesktop.org/xorg/xserver/commit/?id=435f27667f84269768efecde34de4af2b2d43376
<pitti> tseliot: so drivers get assigned in xorg.conf.d/driver.conf as well now?
<tseliot> pitti: yes, but /etc/xorg.conf has the highest priority
<tseliot> in general we can put quirks and other stuff in xorg.conf.d so as to make things work better out of the box without touching the main xorg.conf
<tseliot> (or even without having one)
<pitti> MatchIsTouchpad "on"
<pitti> ah, clever
<tseliot> yep
<pitti> so that will replace the udev rules like ENV{ID_INPUT_TOUCHPAD}=="1", ENV{x11_driver}="synaptics"
<tseliot> pitti: yes, exactly
<tseliot> pitti: that and the other options that we currently use for touchpads
<pitti> tseliot, bryce_: do you think we can get this xserver into lucid, so that we avoid asking people to migrate their fdis to udev rules, just to migrate them again to xorg.conf.d in lucid+1?
<tseliot> pitti: I think we can just backport the patch from the new X
<pitti> tseliot: the udev backend yes, but we also need the xorg.conf.d support
<tseliot> tjaalton was already planning on pulling the patches for both things
<pitti> and the new Match* stuff and InputClass
<pitti> ok, cool
<tseliot> pitti: yes, of course
<pitti> once that's in, I'll make sure to update the docs and migration guide
<tseliot> pitti: so this is an example of how my new feature should work: http://lists.x.org/archives/xorg-devel/2010-January/004534.html
<tseliot> (the quoted text contains an explanation about the design)
<pitti> tseliot: http://lists.x.org/archives/xorg-devel/2010-January/004534.html sounds good to me
<pitti> i. e. adding tags
<pitti> tseliot: I'd just ask you to not name it ENV{TAG}
<pitti> perhaps ID_INPUT_TAG ?
<tseliot> pitti: yes, that was just an example ;)
<tseliot> pitti: sounds good to me
<pitti> other than that, it's not really udev related, udev is just the database here
<pitti> but your example with ID_INPUT_TAG sounds perfect to me
<tseliot> pitti: here Peter wanted to hear from you guys about namespacing the tags: http://lists.x.org/archives/xorg-devel/2010-January/004545.html
<tseliot> shall I forward the email to you so that you can reply?
<pitti> tseliot: I can't post to xorg-devel@
<hyperair> crimsun: codec#0 and codec#1 respectively, re powerdown powersave changes for hda-intel:
<hyperair> http://pastebin.com/f4257e508
<hyperair> http://pastebin.com/f5f922cb8
<pitti> tseliot: what do you mean with namespacing? ID_INPUT_XORG.TAGS ?
<tseliot> pitti: it's a free mailing list
<pitti> it doesn't really matter much
<pitti> tseliot: oh, nice; could you bounce the mail then?
<pitti> (not forward, that'd lose the msgid)
<tseliot> pitti: in the sense that subscription is free and the list is not moderated
<tseliot> pitti: sure
<pitti> tseliot: right, but you need to be subscribed to post, I figure?
<tseliot> note: I don't know exactly what Peter meant by "namespacing"
<tseliot> pitti: yep
<tseliot> but you can reply directly to Peter if you prefer
<pitti> right, and keep my ML post in the moderation queue
<tseliot> pitti: ok, sent
<tjaalton> pitti, tseliot: seems that debian will not pull the xorg.conf.d stuff unless the display driver fallbacks are fixed to work (when there is an xorg.conf)
<tseliot> tjaalton: what happens exactly with the driver fallbacks?
<geser> what's the current process regarding bzr based merges? is opening a merge proposal enough or should a merge bug be opened too?
<tjaalton> tseliot: the server builds an internal copy of xorg.conf where there are multiple driver sections ($foo, vesa, fbdev)
<tjaalton> and then tries them one at a time
<tjaalton> the one that works will be used
<tseliot> right
<tjaalton> so if the native driver doesn't support the id, the init will fail and the next one is tried
<tjaalton> but if there is an xorg.conf (even just an empty one) it'll only use the first one
<tjaalton> because it's a completely different code path
<tseliot> tjaalton: and this happens also when no xorg.conf is there but there's something in xorg.conf.d/, right?
<tjaalton> tseliot: pretty sure
<tseliot> tjaalton: is there a bug report about this on freedesktop? I think I can work on it
<tjaalton> not that I know of
<tseliot> ok
<tjaalton> best to throw the idea on the upstream list and discuss it there too
<tjaalton> dan or someone else might have ideas
<tseliot> sure, I don't want to waste my time on something that won't be accepted or that someone else has already fixed
<tjaalton> jcristau already said to me that "every time i looked at that i ended up running away screaming" :)
<tseliot> hehe
<tjaalton> don't know how hard it would be to use the udev backend for output as well..
<tjaalton> not that it would directly solve this problem though
 * tseliot nods
<pitti> tseliot: sorry, lost your replies after "pitti | tseliot: does your mail client support bounce?"
<pitti> tseliot: anyway, I replied to your forwarded mail
<tseliot> pitti: perfect, thanks
<tseliot> cjwatson: I can't log in (in gdm/kdm) when using Lucid livecd on amd64. I can't even see my username listed (same problem if I use startx and install the system). Is it a known issue?
<cjwatson> tseliot: you know as much as I
<tseliot> oh
<tseliot> i386 works fine
<joaopinto> tseliot, I experience the same problem with a desktop install, but it only fails to start ramdomly
<alkisg> tseliot: I've been seeing that (in i386) for a week now, both on the ubuntu live and the edubuntu live
<alkisg> I had to create a new user to login & install
<joaopinto> a manual service gdm start works
<tseliot> oh, so it doesn't affect only amd64
<alkisg> joaopinto: but gdm starts; just autologon doesn't work for the ubuntu user....
<tseliot> joaopinto: restarting gdm didn't help here as gdm didn't show my username in the list and didn't accept my username either
<tseliot> joaopinto: I think you're experiencing a different problem (X.org failure?)
<joaopinto> hum, I am using autologin
<joaopinto> tseliot, X.org failing to start randomly from upstart only ?
<alkisg> joaopinto: we're talking about the *live* cd...
<pitti> I filed bug 502838 this morning, but for me it happens on the installed system, not live cd
<alkisg> Autologin there is only for the premade `ubuntu` user
<ubottu> Launchpad bug 502838 in gdm "gdm starts too early, races with KMS, X.org/VTs fail" [High,New] https://launchpad.net/bugs/502838
<joaopinto> ok, so I have a different issue, sorry
<tseliot> ok
<tseliot> joaopinto: that must be the problem you mentioned ^^
<joaopinto> yup
<joaopinto> pitti where you able to use the "low graphics dialog" at all ?
<pitti> joaopinto: no, it just keeps reappearing
<joaopinto> I did also get it randomly, but on the second step (which I don't remember right now), it did nothing
<joaopinto> something like "Create new config"
 * alkisg had to use xforcevesa for the live cd to boot at all...
<pitti> right, today's amd64 live login is busted here, too (kvm)
<cjwatson> I've been getting livefs build failure mails for a while, whining about initramfs-tools versioning; I didn't look into them since I was on holiday, but maybe that's it
<alkisg> cjwatson: sorry, an unrelated question: in gfxboot, "Try edubuntu without any change to your computer" is untranslated in *all* languages, while it is translated in launchpad. Any clues?
<pitti> gdm-simple-slave and xorg just segfault, that's it
<cjwatson> alkisg: I need to import the translations semi-manually
<alkisg> cjwatson: ok, thank you :)
<cjwatson> anyway, it's "Try Edubuntu without installing" in lucid
<cjwatson> but before that change there were definitely some translations in gfxboot-theme-ubuntu
 * alkisg is using the 23-12 daily build of edubuntu
<cjwatson> alkisg: are you talking about karmic or lucid or what?
<alkisg> 2009-12-23
<cjwatson> alkisg: have a look at the gfxboot-theme-ubuntu 0.9.0 changelog then
<cjwatson> you shouldn't be seeing the string "Try Edubuntu without any change to your computer" at all, in any language ...
<cjwatson> oh, blast, I need to change debian-cd too
<alkisg> Hmmm I'll try with a more current version
<cjwatson> nah
<cjwatson> it's a bug, I'll fix it now, thanks. but the translations still need to be imported anyway
<alkisg> Thank you :)
<pitti> cjwatson: happy new year! enjoyed the holidays?
<cjwatson> pitti: not bad, thanks
<geser> what's the current process regarding bzr based merges? is opening a merge proposal enough or should a merge bug be opened too?
<sebner> geser: I just wanted to merge pbuilder and what do I see? Actual debian branch on LP is the same version as lucid :P
<sebner> pitti: happy new year migthy pitti :)
<pitti> hey sebner, gesundes Neues!
<ogra> pitti, frohes neues ! :)
<pitti> ogra: thanks, you too! *hug*
<ogra> :)
<sebner> pitti: :), aber du hast versagt. Ich und der geser waren hardcore auf in der Nacht um packaging work zu tun :P
<pitti> I tried not to do too much work during the holidays :) (just some apport hacking and lots of postgresql-common bug fixing, the Debian type of stuff)
<DktrKranz> sebner: ... and for sud sud-tirolers like me, what's that all about? :)
<sebner> DktrKranz: you too of course! :P
 * DktrKranz has to understand that statement first
<ev1> pitti: it's because of the 15autologin change.  I've been looking into it, but sed's handling of variables with embedded newlines is creating some difficulty for me."
 * DktrKranz is not good in sebnerish
<pitti> ah, that
<ev1> pitti: this is what I have so far, but the sed a command breaks: http://pastebin.ubuntu.com/351186/
<pitti> ev: perhaps this should be radically simplified by just writing the file from scratch if it doesn't exist yet (normal live system), and not touching it at all if it does exist?
<sebner> DktrKranz: as sud sud-tiroler you should understand :P
<ev> pitti: that works for me, provided it doesn't break any use case you're aware of.  I'm not sufficiently familiar with the bug that spurred this change in the first place.
<pitti> ev: it was introduced only recently; before we just always wrote the file from scratch
<pitti> I'm not aware of an use case with a preexisting file and no configured autologin where it's desirable to enable autologin again
<pitti> that could only happen if you explicitly disable it from the live system and use persistency
<pitti> in which case I think it makes sense to respect this
<geser> sebner: I've already prepared a merge for pbuilder (bug #502135). it just awaits sponsoring.
<ubottu> Launchpad bug 502135 in pbuilder "Merge pbuilder 0.196 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/502135
<ev> pitti: okay, so does this look okay to you: http://pastebin.ubuntu.com/351189/ (revert to previous method and make sure custom.conf doesn't exist)
<pitti> ev: looks fine to me; and much easier to maintain/understand than the multiline seddery IMHO
<ev> lovely, I'll commit and upload that
<ev> thanks
<pitti> thanks to you!
<sebner> geser: uhh, great. thanks
<sebner> geser: but the oldstyle way I suppose? without bzr
<verb_> Progress with Fribidi: Daniel asks for a .diff.gz
<verb_> https://bugs.launchpad.net/ubuntu/+source/fribidi/+bug/191241
<ubottu> Ubuntu bug 191241 in fribidi "New upstream version 0.19.1" [Wishlist,Confirmed]
<Rovanion> What package am I missing when I get a compiler error about 'snd_session'? Here is the full compiler log: http://pastebin.org/70981
<amikrop> Places->Connect to server->Secure WebDAV does not work. it says Could not open location, not a WebDAV enabled share, but it is (I can connect from other computers)
<amik> mvo: hi there! are you the maintainer of software-properties?
<mvo> amik: yes
<amichair> mvo: I've been working on it from the kde side, closed all kde related bugs and some backend ones
<amichair> do you intend on fixing things up in gtk/backend for this LTS?
<mvo> amichair: I noticed that you work on the kde side, many thanks for that! I'm very short on time unfortunately, but if you have specific suggestions I will try to get them in - if you want to work on the gtk side too, that is more than welcome too of course :)
<amichair> mvo: I've got limited time as well, so I try to help out in the kubuntu regions for now (that's what I use)
<amichair> mvo: another thing, regarding add-apt-repository
<amichair> it looks like a bit of a quick hack, just a few lines of code
<amichair> but once out there, people expect it to be more
<mvo> amichair: right, well. it was meant as a quick command-line version of the "add" button. what in particular do you think is missing?
<amichair> there are a bunch of bugs/wishlist items open on it, going as far as 'make a software-properties-text frontend', for which a-a-r is a start, I guess. On the other hand, it doesn't seem like anyone has time (or intention?) to support it that far...
<mvo> yeah, it seems like time is the big problem, I'm would be happy to merge a newt based frontend, just like we have one for update-manager
<mvo> but  it requires someone with a bit of time to work on it (should not be very hard)
<amichair> so the vision is indeed to go in that direction?
<mvo> well, ideally the frontend code is abstract enough to make that easy, but that will only work if someone devotes time on it
<mvo> its currently not quite there IIRC, the seperation is not that great, but it could be a good time to do cleanup there too
<mvo> so in summary, I would not call it "vision", but I will not oppose it
<amichair> that's the problem with introducing quick new features - you become responsible for everything you *didn't* do, which is the other 99% of the work :-)
<mvo> lol
<mvo> indeed :)
<mvo> the old 80/20 rule
<mvo> amichair: I will try to do some cleanup this week on the buglist and see what I can squeeze in for lucid
<amichair> btw does ubuntu have some policy regarding closing bugs for an LTS, or is it just 'when we get to it' as usual?
<mvo> amichair: no policy, but if you have specific (anoying) bugs in it please let me know about them
<amichair> mvo: no, nothing in particular. I was just hoping you'd be able to take the opportunity (15-20 recently squashed bugs) to clean the slate on 'your' side, or at least dust it off a bit :-)
<mvo> amichair: ok, thanks for that! I check it out :)
<amichair> mvo: cool, great :-)
<amichair> mvo: wish I had more free time as well...
 * mvo agrees so much
<cjwatson> kees: I synced hardening-wrapper from unstable in order to be able to merge new openssh
<cjwatson> kees: P.S. if you're changing openssh in future please note that it's in bzr now; I merged your change in there
<JamieBennett> lool: MIR for embryo https://wiki.ubuntu.com/MainInclusionReportEmbryo and concerns over "another virtual machine" - https://wiki.ubuntu.com/MainInclusionReportEmbryo
<lool> JamieBennett: I'm not surprized
<lool> JamieBennett: I actually noted that down in my concerns since I started reviewing it  ;-)
<pitti> I thought it was obsolete now?
<lool> pitti: Currently, edje build-deps on it
<lool> JamieBennett: So I guess you should talk to upstream or the Debian maintainer and ask whether we really need embryo?
<pitti> we already discussed that some weeks ago, and I wasn't happy about it; JamieBennett(?) told me that newer builds wouldn't need embryo any more?
<lool> Gustavo Barbieri might be able to comment too
<JamieBennett> pitti: I was mistaken
<lool> JamieBennett: So is it a strict requirement according to upstream?
<JamieBennett> lool: I'll check with upstream for the details of exactly why its needed.
<lool> pitti: I personally reviewed the package quickly, it seems it's ok (no build time warning / error on this one!); perhaps we could ask kees for a security review?
<lool> my notes http://paste.ubuntu.com/351252/
<lool> Ah there's a bug too
<pitti> lool: my concern is that it is the n+1st and obscure VM, while we already have well-known and well-supported ones (like lua)
<lool> pitti: Just reading the bug now, didn't understand it had been discussed already
<pitti> lool: and my biggest concern is the total lack of a test suite
<lool> Ack, saw that in the bug
<lool> Commented in the bug
<cjwatson> ttx: I've uploaded openssh 1:5.2p1-1ubuntu1, including conversion to upstart; you can start relying on that in eucalyptus if you like, though you probably ought to have a versioned dependency on openssh-server if you do
<ttx> cjwatson: sure thing, thanks. Haven't had time to test it as requested, sorry about that
<james_w> dear archive admins: You may like to look at https://code.edge.launchpad.net/~james-w/ubuntu-archive-tools/improved-sync-helper/+merge/16779 for improved CLI driven processing of the sync queue. Feedback welcome.
<cjwatson> that's ok, just means it blows up for more lucid users ;-)
<lool> pitti: There even was a CVE against embryo!
<lool> actually might be another software
<JamieBennett> just talking to raster about embryo, it seems its absolutely essential but isn't designed for anything other than edje really
<lool> JamieBennett: do they intend to provide a testsuite?
<mpt> How can I list the packages that are marked as "Enhances:" for a particular package X? I've muddled my way as far as 'apt-cache dumpavail | grep "Enhances: X"', but obviously the output doesn't include any package names. (mvo?)
<lool> mpt: grep-dctrl might help you
<lool> or aptitude, not sure it lists enhances though
<ion> Yeah, grep-dctrl indeed.
<mpt> Ah, wonderful, thanks lool
<lool> mpt: Actually aptitude allows that, so you can browse to the package in aptitude and look at the reverse deps from the ncurses gui
<mpt> whoa, aptitude has a gui
<ion> grep-aptavail -sPackage -FEnhances -r '\<screen\>'
<lool> It has an experimental gtk+ gui too
<mvo> mpt: debian/unstable has a gtk gui too
<JamieBennett> lool: no testsuite plans
<JamieBennett> raster took the lib from compuphase and assumes that all testing was done there
<lool> JamieBennett: I'll let pitti comment as he did most of the review and had the strongest opinion; I personally would be fine running it through kees
<mpt> brillian
<mpt> t
<lool> I'm not overall happy that we end up with another toolkit and vm in main, but then if it's maintained by
<lool> mobile team + Debian, it should be ok
<mpt> thanks ion!
<lool> JamieBennett: Oh it's a fork?
<JamieBennett> pitti: the consensus from upstream is that embryo should be rolled into edje but at the moment its just separate, i.e. we should treat them as the same package
<ion> mpt: If you only want the value from a single field (say, Package), you might also want -n
<mvo> mpt: please note that enhances are curerntly not well supported in apt/python-apt, we need to do some ground work first. if you want them in s-c I will have to add some support code first to the lower levels
<JamieBennett> lool: Not that I'm aware of, raster took the lib, streamlined it and released it as embryo
<JamieBennett> lool: but it was based on something else historically
 * tedg wants 'enhances' support :)
 * ogra wonders why everybody talks about VM here, i thought its a toolkit lib
<mpt> mvo, this is for <https://wiki.ubuntu.com/SoftwareCenter#add-ons>, which is in the "Yet-to-be-specified features" section, not scheduled for 2.0 :-)
<pitti> embryo is a VM, similar to lua
<ogra> bah
<mvo> mpt: ok, I have a look anyway at the code, it should be trivial to add (just some leg-work) :)
 * mpt looks for a package that has an interesting set of Enhances but that isn't Firefox
<davidw> given the latest comment here: https://bugs.launchpad.net/ubuntu/+source/barry/+bug/426716 - would it be ok if I changed the status of this bug?  I'm not really sure what standard practice is in these cases.
<ubottu> Ubuntu bug 426716 in barry "Merge barry 0.15-1 (universe) from Debian testing (main)" [Wishlist,Fix released]
 * barry unpings; nice project name :/
 * jussi01 hugs barry
 * barry feels better, thanks jussi01! :)
<davidw> barry, ahahaa :-)
<beuno> mpt, hi. Do you have moderating powers on ayatana?
<beuno> mpt, I think there's a few messages stuck in the queue
<zul> doko: ping
<mpt_> beuno, no, I didn't know ayatana@ existed until a couple of months ago :-)
<beuno> mpt_, ha!
<smoser> Keybuk, http://paste.ubuntu.com/351288/ shows me failing boot on my ec2-images, is there something I need to do to get plymouth? or is that just red-herring error?
<smoser> any clues?
<LaserJock> pitti: quick question on your MIR proposal: will there still be some template for people to know what information should go into a report? For people who don't do it often it is a helpful guide to what they need to think about
<pitti> LaserJock: the UbuntuMainInclusionRequirements page provides the whole checklist
<LaserJock> so that will remain
<pitti> (part of the reason why I want an explicit "I checked the UbuntuMainInclusionRequirements and all was okay)
<pitti> LaserJock: right, that's the essential part of it now
<LaserJock> I was unsure if what you were saying was "you don't need to look at the wiki at all anymore" or if it was just that you don't  have to fill out the wiki form
<Keybuk> smoser: it's just a warning
<pitti> the latter rather
<LaserJock> so that answers my question :-)
<Keybuk> smoser: the SEGV is far more like a bug :p
<LaserJock> pitti: sounds good, thanks for working on that
<pitti> you're welcome
<pitti> seems an unanimous "agree" so far, so I'll move it over soon and write to u-d-a@
<smoser> Keybuk, you want me to open a bug ?
<Keybuk> smoser: only if you have a core dump
<smoser> well, no, but i can likely trace it back and see a set of package changes that cause it.
<Keybuk> smoser: that won't help
<Keybuk> since it doesn't do it to me, or anyone else
<Keybuk> really need core dump
<Keybuk> init=/bin/sh
<Keybuk> mount a tmpfs over /var/crash
<Keybuk> start apport
<Keybuk> exec /sbin/init
<Keybuk> then when it crashes, apport should still have worked
<pitti> with the current lucid kernel that also requires an "ulimit -c unlimited", I believe
<pitti> (bug 498525)
<ubottu> Launchpad bug 498525 in linux "[lucid] breaks apport: core dumps get aborted even if core_pattern is a pipe" [High,In progress] https://launchpad.net/bugs/498525
<Keybuk> ah right
<Keybuk> yes, and do that before init, and it gets passed down to everything ;)
<pitti> Keybuk: happy new year
<ebroder> udev/lvm2 question: Hardy's LVM has a udev rule that does vgchange -a y when new volume groups are found, but there's no such rule in Karmic. Hardy also has an initramfs script that activates the root VG, and Karmic doesn't. What brings up VGs on Karmic?
<Keybuk> pitti: happy new year to you too
<Keybuk> ebroder: your second statement is incorrect
<ebroder> Keybuk: Wait, really? All I see is an init-premount script that does a vgscan in mountroot_fail, at which point presumably it's too late to recover, right?
<Keybuk> ebroder: your second statement being that "there's no such rule in Karmic"
 * ebroder looks
<barry> i'm using virt-manager with bridged networking to do development on a lucid vm, however every time i reboot the karmic host, the bridged network doesn't come up until i /etc/init.d/networking restart.  any ideas why that is?
<ebroder> ...huh. Oh right - it's Debian that doesn't have that rule
<Keybuk> ebroder: important difference ;-)
<ebroder> Keybuk: Sorry, I forgot that my Karmic VM isn't using LVM :)
<Keybuk> ebroder: yeah, LVM doesn't work if you're not using LVM
<ebroder> Keybuk: I'll keep that in mind :-P - let me try again, though. Why does /Debian/ not need something to activate volumes?
<Keybuk> ebroder: because Debian has all sorts of initramfs and init scripts to try and activate volumes over and over again
<ebroder> Keybuk: Makes sense. Thanks. (I spent a while last night trying to get a Hardy machine to boot using Debian's LVM package, and it didn't work until I copied over the original Hardy udev rule)
<Keybuk> why didn't you use Ubuntu's LVM package?
<ebroder> Too old
<ebroder> I actually was using Debian's packaging against a 2.0.56 upstream tarball, because I wanted some of the very recent updates to clvm
<Keybuk> anything at that level isn't going to work
<Keybuk> we have fundamentally different core pieces of our boot and plumbing
<ebroder> Well, I eventually got it to work - it just took a very big hammer :)
<Keybuk> Ubuntu's plumbing layer is closer to Fedora or SuSE than Debian
<Keybuk> you could probably wedge Fedora's lvm RPM in and have more chance of it working
<Keybuk> (quite seriously)
<ebroder> Really, it wasn't that bad. Since I was backporting to Hardy, I had to deal with the {/etc => /lib}/udev/rules.d change, I had to drop in Ubuntu's lvm2 udev rule, and I had to correct for copy_exec requiring two arguments in initramfs hooks (which I think was also a backporting issue). Once I did that, the package worked
<ebroder> Of course, it doesn't really seem to have fixed the fact that corosync and openais and pacemaker and clvm and really the whole Linux clustering stack are a steaming pile of worthless, undocumented crap...but that's not a Debian vs. Ubuntu problem :-P
<ebroder> distributed development question - if somebody's done a package merge by proposing a bzr merge, I can't just approve the bzr merge, right? I still dput the resulting package as well?
<jelmer> ebroder: yes, at the moment you still need to manually dput
<ebroder> jelmer: Ok - what if I want to make a modification? Should I approve the merge and then dput something different? Reject and dput?
<james_w`> ebroder: if you grab the lp:ubuntu/<package> branch, do a bzr merge-package of their proposed branch, then modify and commit
<james_w`> you can push the result to lp:ubuntu/<package> and dput what "bzr bd -S" spits out
 * ebroder nods. Let's see if I can wrap my head around making this all work...
<ebroder> Does bzr bd automatically choose the right gpg key to use?
<cjwatson> I normally branch to a temporary location, merge, commit further changes, and then merge *that* into the trunk
<cjwatson> seems to fit my mental model of what's going on better - "don't merge to trunk until I'm happy"
<ogra> colins code arboretum ? :)
<james_w`> ebroder: it's just running dpkg-buildpackage, so that's what decides what to use
<ebroder> james_w`: Hmm...but it's using my key even when the changelog entry lists somebody else..that's unusual
<james_w`> do you have a ~/.devscripts ?
<ebroder> Huh - apparently I do. I had forgotten about that
<DktrKranz> james_w`: some package branches are not up-to-date, even if they're not listed in those which failed to update. Is there a workaround for that?
<james_w`> DktrKranz: we have some operational problems that I am trying to fix
<james_w`> you could run it locally, but that might be a bit more than you want to try
<james_w`> are you on the ubuntu-distributed-devel list? there were some pointers on there
<DktrKranz> no, I can see archives though
<ttx> pitti, cjwatson: could one of you trigger a server CD respin please ?
<pitti> ttx, cjwatson: will do
<pitti> running
<pitti> ETA 10 mins
<ttx> pitti: thx
<sbalneav> mvo: ping on bug #501559 , I beleive you're the maintainer for gksu?
<ubottu> Launchpad bug 501559 in libgksu "libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL" [High,Confirmed] https://launchpad.net/bugs/501559
<mvo> sbalneav: let me have a look, I'm not the maintainer as such, but often work on it
<sbalneav> mvo: It just needs another config option
<sbalneav> it used to do the forkpty by default, but then it got extrapolated out into a set of #ifdef's
<sbalneav> with a corresponding config option.
<mvo> sbalneav: thanks, I assgined it to me
<DktrKranz> jelmer: any plans to have latest bzr-builddeb in Lucid to experimental too?
<DktrKranz> I find it very useful
<dholbach> kirkland: did I already ask you about giving a session about kvm stuff at UDW? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep has a slot open for you :)
<jelmer> DktrKranz: yes, it's great
<dholbach> DktrKranz: could you imagine giving the same python packaging session twice? :)
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep would have a slot for you :)
<jelmer> DktrKranz: or perhaps even sid, I think the version in Lucid works better than the one in unstable
<jelmer> james_w`: ^
<kirkland> dholbach: hmm, maybe you did?  :-)
<dholbach> kirkland: I forgot what you said so I thought I'd ask again :)
<james_w`> jelmer, DktrKranz: yeah, it should go to sid
<kirkland> dholbach: i'll do it, but it will have to be Thursday or Friday, as I'm traveling back from LCA that week
<james_w`> I've just been lax in getting it packaged up
<james_w`> any help welcome
<james_w`> I need to upload to lucid and pursue an SRU as well
<DktrKranz> jelmer: even better
<DktrKranz> dholbach: having the same session just a week later?
<dholbach> DktrKranz: yeah :)
<dholbach> kirkland: I'll see with whom you could maybe swap :)
<dholbach> jelmer: do you think you could run your session also on wednesday at 19 UTC? if not, I'll ask somebody else :)
<DktrKranz> dholbach: I've no problem, perhaps RainCT is interested too
<dholbach> DktrKranz: that'd be very fantastic
 * RainCT reads the log
<kirkland> dholbach: let's shoot for Thursday, if possible
<jelmer> dholbach: I think we should be able to get some people on IRC around that time, I'll be at a bzr sprint during the open week :-)
<kirkland> dholbach: can i swap with you and jcastro ?
<DktrKranz> dholbach: keep the one at 20 UTC, because I'm not home before
<dholbach> jelmer: oh... so you can't give that session?
<dholbach> DktrKranz: wednesday 20 utc?
<RainCT> DktrKranz: sure, I have plenty of time after the 18th January
<dholbach> kirkland: swap which slot with that one?
<DktrKranz> dholbach: isn't 27th?
<dholbach> DktrKranz: yep
<DktrKranz> I've one on 21st, fine on 27th too
<dholbach> ROCK
<DktrKranz> I'll try to differentiate it a bit
<dholbach> DktrKranz: let me know if you find somebody else to give the session with you and I'll update the page and everything
 * dholbach hugs DktrKranz
<highvoltage> *hugs* #ubuntu-devel
<DktrKranz> just not to bore people with boring simple testing packages I prepared :)
<ScottK> dholbach: Did someone volunteer to do a session on merging with bzr?
<highvoltage> (man I need bigger arms)
<jelmer> dholbach: No, it's not a problem. I should be around, and I'll try to bring some other bzr devs as well.
<dholbach> ScottK: there's a session about merging and one about bazaar
<dholbach> jelmer: that's awesome!
<ScottK> dholbach: Is the merging one using bzr to do it?
<dholbach> thanks a bunch jelmer!
<dholbach> ScottK: I don't know
<dholbach> I'm not giving the session
<ScottK> dholbach: OK.  I think a lot of people could use one like that (me included)
 * sebner proves ScottK right
<DktrKranz> mvo: some days ago, I submitted a gdebi merge proposal with some candidate fixes, did you have time to look at that?
<mvo> DktrKranz: not yet, I was on holiday, I have a look now. I wonder why I have not goten a mail from LP about it :/
<dholbach> kirkland: swap which session with jcastro and me? if you mean wed 19 utc, I have to decline I'll be at a french course at the time :)
<DktrKranz> thanks
<mvo> thank you!
<ebroder> Ugh...I should get a lintian backport so that Karmic stops yelling at me about putting lucid in changelogs
<kees> cjwatson: cool; I just read your changelog and noted the bzr location.
<jdong> yes jdong, smart move, let's just restart openssh over ssh, that'll work.
<Keybuk> it should work
<jdong> not on FreeBSD
<jdong> if Linux is smarter than that, then A+ :)
<jdong> right now I'm just staring at the stopping sshd message that taunts me
<cwillu_at_work> jdong, well, it'll still restart your session, but it shouldn't crap out preventing it from starting back up
<kees> cjwatson: btw, what do you think of debian bug 562048 as a solution to the stack of bugs that are merged to debian bug 139505 ?
<ubottu> Debian bug 562048 in openssh "allow for the package-specific version banner to be suppressed" [Wishlist,Open] http://bugs.debian.org/562048
<ebroder> Restarting ssh over ssh has worked for as long as I've been using Linux, modulo other issues
<ubottu> Debian bug 139505 in ssh "ssh announces 'Debian' and package version in its banner." [Wishlist,Open] http://bugs.debian.org/139505
<geser> kees: Hi, if you want to get exim4 off your merge list: bug #501657
<ubottu> Launchpad bug 501657 in exim4 "Merge exim4 4.71-2 from Debian testing or exim4 4.71-3 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/501657
<ebroder> Including not breaking your current ssh session - the old sshd sticks around for as long as it has sessions open
<kees> geser: go for it!  :)
<jdong> hmm shockingly it is accepting new SSH requests
<jdong> ooh :)
<geser> kees: I need a sponsor for it
<cwillu_at_work> jdong, "shockingly" as in "somebody sane wrote this"?
<jdong> but somehow my existing session died
<jdong> cwillu_at_work: something like that :)
<jdong> I did change the binding address for the daemon
<cwillu_at_work> jdong, it killed sshd and restarted, what did you expect would happen? :p
<cjwatson> kees: TBH I hadn't got round to thinking about it yet - 5.2p1 and the bzr import was a *huge* pile of stuff to swallow at once, and all I really did was polish off a bunch of easy/non-controversial stuff on top of that
<jdong> cwillu_at_work: I expected SIGHUP on the lost controlling terminal to cause the rc script to stop executing
<cjwatson> sshd forks when you open a new session, and the child sshds are the ones that keep the sessions going
<cjwatson> they don't need the parent to still be alive
<kees> cjwatson: ok, sure.  I'm only asking after it because it's one of the workitems for the security team.  ;)
<cjwatson> kees: the main thing that stood out at first glance was that I wondered if the configuration option name should be explicitly Debian-specific
<cjwatson> i.e. prefixed with the string "Debian"
<kees> cjwatson: right, we'd talked about it a bit at some UDS or sprint a while back and you'd mentioned something similar.  I figured I'd go for generic first, and work the patch from there.
<kees> I don't care what it's called.  :)
<kees> DebianVersion off    or something
<kees> geser: I'd be happy to sponsor
<mathiaz> cjwatson: hi!
<cjwatson> kees: ok, at any rate it's near the top of my list for openssh
<mathiaz> cjwatson: re  lilo in main
<mathiaz> cjwatson: you suggested to drop it from the -server iso
<mathiaz> cjwatson: I see that lilo is also in ship
<mathiaz> cjwatson: should it be dropped from there as well (and then seeded somewhere else to keep it in main)?
<kees> cjwatson: cool; no real rush from me -- I was just fishing for a relative ETA.  thanks for taking the hardening-includes changes, btw.  what did you think of that approach?
<cjwatson> mathiaz: yeah
<cjwatson> kees: it seemed ok, although I imagine backporters will hate me
<kees> hah
<mathiaz> cjwatson: the comment in ship say: # MattZimmerman wants this for server admins; needed for LVM installs
<mathiaz> cjwatson: I guess that LVM installs don't require lilo anymore?
<cjwatson> mathiaz: correct
<mathiaz> cjwatson: ok - so I'll move lilo to the supported seed
<cjwatson> mathiaz: I think maybe supported-installer-common
<mathiaz> cjwatson: ok
 * soren calls it a day
<free> mvo: hi, and happy new year :)
<mvo> hey free! happy new year
<free> mvo: hey!
<free> mvo: quick question
<free> mvo: is there a way to run the do-release-upgrade script and have third-party-repos kept and not commented out?
<mvo> free: yes, give me a sec
<free> mvo: I think the RELEASE_UPRADER_ALLOW_THIRD_PARTY env var didn't work with do-release-upgrade, but I might have overlooked something
<free> mvo: thanks
<ebroder> free, mvo: Ooh, ooh - I know this one. Drop a .conf into /etc/update-manager/release-upgrades.d with "[Sources]\nAllowThirdParty=yes"
<free> ebroder: sounds awesome, mvo you confirm? ^^^
<mvo> free: yeah, that will work
<free> mvo, ebroder: cool, thanks!
<mvo> free: the env var should work too, but sudo will clean it
<mvo> free: sudo cleans every env var it does not know about and has in its whitelist
<free> mvo: yeah
<mvo> free: I need to leave for dinner now, but I will read scrollback
<free> mvo: it's fine, have a nice one!
 * mvo waves
<mvo> thanks ebroder btw :)
<free> mvo: it looks that even the config doesn't work as well, so probably it's because I'm trying it on intrepid, it looks that the allow-third-party feature is newer
<ebroder> free: No, that feature worked for Intrepid -> Jaunty upgrades
<free> ebroder: weird
<ebroder> free: Are you sure you dropped in a file with a .conf extension?
<ebroder> Oh! Sorry - it's a .cfg extension
<free> ebroder: oh
<ebroder> (I'm not entirely sure if that actually matters, but it is what my configuration has)
<free> ebroder: I just checked the source of update-manager, and the feature is present from jaunty onwards, so I guess intrepid->jaunty should work, because the tool from jaunty gets downloaded
<free> ebroder: .cfg made the trick :) thanks!
<free> ebroder: I wonder if there is way to achiave the same on dapper and hardy
<ebroder> free: I don't have any way. Although I bet it'll work for Hardy -> Lucid upgrades
<free> ebroder: yeah, that would do it
<james_w`> <james_w`> can anyone tell me how to find out whether LaserJock has upload permission to qcad?
<james_w`> <james_w`> I know he doesn't have either component upload rights or package upload rights for it
<james_w`> <james_w`> I'm not sure how to determine package set rights
<pitti> mvo: I noticed a work item "create static shell package" -- what's wrong with bash-static?
<pitti> (I'm just curious)
<cjwatson> james_w`: lp:ubuntu-archive-tools, ./edit_acl.py -p <launchpad id> query
<james_w`> thanks cjwatson
<cr3> is there a quick way to determine when any packages have last been installed? I don't need to know for specific packages, just any package, so perhaps there's a file timestamp I could look at
<cjwatson> cr3: /var/log/dpkg.log
<cr3> cjwatson: thanks!
<ebroder> Ugh. I was hoping to finish clearing out the u-u-s queue, but this last package is horrendously abandoned by upstream
<cjwatson> ArneGoetje: are you aware of the problem at the end of (e.g.) http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/edubuntu-dvd/20100104/livecd-20100104-i386.out? looks like language-support-zh-han[st] are outdated
<geser> james_w`: do you know if opening a merge proposal is enough to get something sponsored or should a matching bug be opened too? (I don't know if the sponsor teams also look at their pending reviews)
<james_w`> geser: the LP API isn't complete enough yet for us to put the merge proposals on dholbach's overview page, so it's easy to
<james_w`> miss them. Opening a bug could be good in that case.
<NCommander> cjwatson, ping, if you have a moment, can you help me look at the crontab on antimony? ports/daily doesn't seem to be properly run (and the log http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/lucid/ports_daily-20100104.log doesn't have anything useful in it)
<geser> james_w`: thanks, will open matching bugs and update my merge proposals (so they don't get lost and other don't repeat the work as they didn't look at open merge proposals just only bugs)
<danage> fta: you're maintainer of the ubuntu songbird ppa - can i kindly request your intervention? the svn hasn't built for four weeks. or maybe you could put the 1.4.2 final?
<cjwatson> NCommander: debugging
<kees> what does "(delayed)" mean in the emails to -changes ?
<kees> e.g. https://lists.ubuntu.com/archives/hardy-changes/2010-January/012360.html
<cjwatson> NCommander: fixed and rebuilding; it was trying to build lpia and getting confused that it wasn't there any more, and the error handling sucked
<fta> danage, i gave up on maintaining it, not enough upstream cooperation, and almost no luck to get it into the archives.
<fta> danage, i passed the hand to micahg, but he's been busy with other stuff, and the package is unbuildable since upstream landed a patch that needs a private copy of sqlite
<fta> danage, it's fixable with some work, but i'm busy myself with work/life/other projects :P
<micahg> danage: I plan on looking at that after I finish with TB3
<NCommander> cjwatson, thanks
<ebroder> Can I configure dput such that `dput ppa:foo/bar` works, but `dput ppa` defaults to my PPA?
<danage> fta: micahg: thanks for your answers. i keep wondering why the songbird people don't maintain their own repository for ubuntu, like a lot of other projects do (ex. pidgin, virtualbox). it's almost as if they don't _want_ to get their product out of the door...
<ebroder> Ugh. Somebody just uploaded openoffice or something to their PPA, didn't they. *sigh*
<ebroder> Whoo! u-u-s queue is empty!
<kitallis> does ubuntu plan on partcipating for GSoC'10?
<ebroder> Is there anybody that should know that doesn't know that one of the powerpc buildds is hilariously unhappy? <https://launchpad.net/ubuntu/+source/mypasswordsafe/0.0.20061216-0ubuntu1/+build/1427243>
<kitallis> that's because iirc, that backed out last time.
<kitallis> s/that/they
<mvo> pitti: nothing, its probably the one that is going to be used :)
<mvo> pitti: the item is just misleading
<kitallis> does notify-osd depend on libnotify?
<deviad> May I ask for help in here about jackd and qjacktcl. Someone wrote a guide in the official ubunt wiki website but I can't get it to work. The author even forgot to say that a real time kernel was needed.
<ScottK> deviad: You''re probably better off to ask in #ubuntu-studio
<deviad> OK, thx
<deviad> ScottK, I'm getting no answer in ubuntustudio. :\
<deviad> it's kind of a quiet channel
<ScottK> That's where the experts would mostly likely be found and user support is off topic here.
<bdrung> james_w`: a fakesync are done by replacing only the source file or should it be stated somewhere?
<james_w`> bdrung: grab the debian package, dch -i and state that you are doing a fake-sync, replace the .orig.tar.gz with the Ubuntu one and then upload the built source package
<highvoltage> fp
<james_w> "not ubuntu: debian"
<james_w> thanks, that's a very cutting error message
#ubuntu-devel 2010-01-05
<doko__> broken eglibc on powerpc :-(
<ArneGoetje> cjwatson: new packages uploaded, thanks for the heads up.
<cjwatson> ArneGoetje: great, thank you
<kirkland> slangasek: hiya, around?
<slangasek> kirkland: hi
<kirkland> slangasek: hi there, i just uploaded eucalyptus_1.6.2~bzr1120-0ubuntu2_source.changes
<kirkland> slangasek: when does the next ISO build trigger?
<slangasek> kirkland: in 8h
<kirkland> slangasek: okay, could i schedule a server build in about 4 hours?
<kirkland> slangasek: ttx asked that i make sure a new ISO is built with my changes before his morning
<slangasek> kirkland: schedule one, or have me schedule one?
<kirkland> slangasek: i don't think i can
<kirkland> slangasek: i suppose i'm asking you to do so, on my behalf :-)
<slangasek> ok
<kirkland> slangasek: is that something you can do for me?
<slangasek> yeah, I can make sure that happens
<kirkland> slangasek: thanks
<crimsun> TheMuso: PA patches of doom pushed upstream
<crimsun> hyperair: FWIW, 1.0.22.1 (which contains my powerdown work) is slated to be merged into linux-backports-modules-2.6.31, so you'll be able to get it linux-backports-modules-alsa-$(uname -r), too
<crimsun> bah, missing preposition
<crimsun> ScottK: what was the surrounding context for slicer FTBFS that you mentioned a couple days ago?
<crimsun> some invalid const char * conversion, I think?
<ScottK> crimsun: Nothing major, just I saw you'd uploaded a new vtk and started checking what might be buildable.  Yes.
<crimsun> drat, -ECHANNEL
<ScottK> I retried it on i386 after your last vtk upload and it failed again.
<crimsun> ok, I look
<TheMuso> crimsun: Just saw that thanks, will do that myself in the future.
<TheMuso> /c/c
<hyperair> crimsun: i see. but i use a custom kernel so i guess i won't be seeing it for some time
<persia> hyperair: Well, you could pull the -sru source and recustomise :)
<hyperair> heh
<hyperair> it's actually a kernel from git
<hyperair> the zen kernel
<hyperair> got a bunch of cool stuff like phc, tuxonice, and bfs =)
<crimsun> you could just use alsa-source from Lucid and m-a
<hyperair> modules-assistant?
<crimsun> in any case, it isn't enabled for your codec (I don't think, let me check)
<hyperair> ah
<hyperair> say, we still use m-a? i thought everything was dkms nowadays.
<crimsun> if we is Debian pkg-alsa, yes
<hyperair> O_o
<crimsun> no one has committed the dkms bits yet
<hyperair> i see
<crimsun> hyperair: is your ssid 0x1744384e? (see lspci -nv|grep -A1 0403)
<crimsun> sorry, 0x17aa384e
<hyperair> 00:1b.0 0403: 8086:284b (rev 03) Subsystem: 17aa:384e
<hyperair> what's this ssid?
<Claviceps> you will probably get a Unknown device error
<Claviceps> rev02
<hyperair> huh?
<Claviceps> you are trying to point and get PCI bus information arent you?
<crimsun> hyperair: http://pastebin.com/d179ba213
<crimsun> hyperair: you'll need to apply that on top of 1.0.22.1
<crimsun> I'm turning on the powersavings for Realtek codecs quirk by quirk
<Claviceps> try executing pciconf -l
<Claviceps> or dmesg
<Claviceps> to get the kernal message
<hyperair> Claviceps: er
<crimsun> hyperair: ssid is given in the "Subsystem" section
<hyperair> ah
<Claviceps> ohhh HELL nooo
<hyperair> Claviceps: no i don't get any unknown device error or anything.
<Claviceps> wikipedia.en
<Claviceps> did you check the libpci ?
<Claviceps> make sure all devices are listed therwe
<crimsun> Claviceps: what are you on about?
<Claviceps> I dont EVEN LIKE COMPUTERS
<Claviceps> but fishing is a dying industry
<Claviceps> you have an answer to that NIGGA
<Claviceps> check all the pcids
<Claviceps> pciids
<hyperair> looks like we've an annoying new bot
<joshua___> Any way to convince sulogin to not ever ask for a password
<persia> joshua___: That sort of question is better asked on #ubuntu (and the answer is available by running `man sulogin` )
<joshua___> I read the man page. Why do you think I'm in devel?
<persia> Well, it's in the fourth paragraph :)
<joshua___> Look guys after trying sudo for one year I gave it up.
<superm1> glatzor, ping re the gtk python-aptdaemon stuff.  is there no way to make a blocking run() call anymore?
<superm1> or if there is, I think i'm just missing the proper way to do it
<lifeless> how should debug autosyncs not happening?
<lifeless> s/should/should one/
<persia> lifeless: You've confirmed that something was present in Debian testing (main) at the time of the autosync, that it's not NEW, and that there's no Ubuntu package with that name that might block it?
<Claviceps> I HAVE BEEN FIGHTING THIS BULLSHIT MY ENTIRE LIFE
<Claviceps> with worse odds than me vs ali in a boxing ring
<glatzor> superm1, hello. you are right. currently the wait statement in the aptdaemon.client.AptClient isn't supported
<glatzor> superm1, if you are writing a GTK application I would encourage connecting to the signal
<glatzor> superm1, to the finished signal of the transaction
<lifeless> persia: well, I'm not sure where to find the autosync run time
<superm1> glatzor, unfortunately i'm getting weird behaviors when I connect to that signal versus running the function directly from the application
<lifeless> persia: I have a package (testresources) that is out of date in Ubuntu, current in testing
<glatzor> superm1, see http://bazaar.launchpad.net/%7Eglatzor/update-manager/ubuntu-glatzor/annotate/head%3A/UpdateManager/backend/InstallBackendAptdaemon.py
<superm1> glatzor, i'm doing some stuff with a policykit check that i'm suspecting isn't working when invoked that way
<glatzor> superm1, could you point me to your code?
<StevenK> lifeless: The autosyncer is run manually. I can kick one off now, if you wish
<lifeless> StevenK: sure
<superm1> glatzor, sure give me a sec to push up my latest iterations of trying to sort it out
<maco> StevenK: "auto... run manually" *blink*
<persia> lifeless: I usually scan through https://launchpad.net/ubuntu/lucid/+queue?queue_state=2 to find a batch of packages with Debian revisions uploaded near the same time (in this case about 2 hours ago).
<glatzor> superm1, you should not have to care about policykit on the client side (except e.g. that you want to disable buttons)
<StevenK> maco: It's auto in the way that it will automatically pull in everything that doesn't have Ubuntu changes.
<superm1> glatzor, so if you take a look at lp:~mythbuntu/mythbuntu/mythbuntu-control-centre and the file ./mythbuntu-control-centre, summaryApply is what invoke's the commit.  if you have a set of changes that require more beyond that commit, summaryApply is called again as the handler to run those other changes.  it works when called with no commit changes, but fails when it's invoked through the signal handler
<Hobbsee> Claviceps: please put your offtopic discussions to somewhere like #defocus, not here
<Claviceps> okay..
<Claviceps> i GUESS you DIDNT get the POINT??
<lifeless> Claviceps: you are being disruptive, are talking about things not relevant for this channel. Please stop - as Hobbsee says #defocus would be a better channel.
<Claviceps> alright..
<Claviceps> yes you are right. this is off topic..
<maco> <hyperair> what's this ssid? <-- for reference, the ssid is the " Subsystem: 17aa:384e" part of that output
<maco> hyperair: oh. crimsun said that already. i should read further before answering questions i think werent answered. oops
 * maco shuts it
<glatzor> superm1, does it segfault? do you have got a traceback?
<superm1> glatzor, unfortunately it just hangs and won't respond to ctrl-c anymore in the terminal
<superm1> traceback would be nice, i'd have a bug to directly file :)
<superm1> but it does get as far as using the dbus activation to open up mcc-backend
<glatzor> superm1, line 299 does not work this way. If commit_packages is called async it will not return the transaction instance
<superm1> glatzor, ah yeah, that's the next thing i was going to try to sort out (but that used to work when things were called synchronously)
<glatzor> superm1, you can still make sync dbus calls
<glatzor> superm1, just skip the reply_handler and error_handler
<glatzor> superm1, sorry. I just see that this is not documented in the module.
<glatzor> superm1, if you using async dbus calls adds to much complexity to your application you can use sync calls
<superm1> glatzor, yeah i certainly wasn't aware of that. if i skip using reply_handler and error_handler (i'm guessing it's just providing None as an argument), how do I handle errors that are raised in those scenarios?
<glatzor> superm1, the method call will just raise an exception
<superm1> works for me
<glatzor> superm1, you can catch it using a try|except pair
<superm1> glatzor, that's much more ideal for my usage anyway. thanks, i'll run with that and see if I can get things back in working order then
<dholbach> good morning
<StevenK> lifeless: All done.
<lifeless> StevenK: did it pick up testresources?
<StevenK> lifeless: Sure did, it'll build in a few hours.
<lifeless> cool, thanks.
<lifeless> [and I just uploaded a new release to debian :P]
<StevenK> So we're going to have the same discussion tomorrow? :-)
<hyperair> maco: :-)
<pitti> Good morning
<siretart> hi pitti
<alkisg> Would anyone care to sponsor a MIR for libsdl1.2debian-pulseaudio? It would be the first step in solving LP #203158 (the second one being, changing the seeds)
<ubottu> Launchpad bug 203158 in libsdl1.2 "libsdl1.2debian-pulseaudio must be installed as default by libsdl1.2debian" [Medium,Triaged] https://launchpad.net/bugs/203158
<pitti> hey siretart, gesundes Neues!
<siretart> pitti: danke! dir ebenfalls! ;-)
<siretart> pitti: is there anything left to do with the yasm MIR? you set the status to fix committed before christmas, but it is still in universe
<pitti> siretart: oh, it's on component-mismatches now
<pitti> siretart: promoted
<siretart> yes, I've uploaded a ffmpeg (main) that build depends on it
<siretart> thanks! :-)
<siretart> this means I can start the symbol versioning transition now :-)
<siretart> although I feel a bit uncomfortable that upstream hasn't applied my patch yet, and I first need to fix my car today...
<DktrKranz> mvo: thanks for merging the fixes! I have some minor ones too, I'll prepare a branch for them later.
<twb> I'm using pbuilder the roll some private packages for Hardy, but I'd like to be able to use debhelper >= 7~ from hardy-updates.
<twb> How do I tell pbuilder to include hardy-updates ?
 * twb tries --othermirror
<DktrKranz> mvo: I also saw Debian version overwrote Lucid one, main difference is it no longer passes --always-ask-pass to gksu, I asked to blacklist it, in order to avoid such inconvenieces in the future.
<mvo> DktrKranz: thanks, let me know when the branch is ready
<mvo> DktrKranz: maybe we can make the --ask-pass a runtime detection, it would be nice to have the same source in debian and ubuntu
<mvo> DktrKranz: or I need to nag kov to take the patch for it :)
<DktrKranz> mvo: oh, nice idea. I'll try to address that too
<mvo> many thanks
<lool> geser, dholbach: Thanks for the pbuilder mere
<lool> merge
<dholbach> heya lool - I just reviewed and uploaded it :)
<lool> Well thanks for reviewing and uploading it  :-)
<dholbach> :)
 * dholbach hugs lool
 * lool hugs dholbach 
 * mneptok takes photos for his later "personal use"
<maco> mneptok: you know there's a video of like 20people+dholbach hugging on youtube, right?
<mneptok> maco: dependning on its vintage, i may well be one of those 20
<mneptok> maco: and i haven't showered since.
<maco> mneptok: the surprise group hug a few udses ago
<maco> ah that explains the smell at uds dallas
<mneptok> Prague, i think
 * mneptok tootles off to bed.
<mneptok> early confcall. bleh.
<ScottK> pitti: Would you please rescore kdeadmin on amd64.  It's the last package I need to declare KDE 4.2.4 done in karmic-backports and we're holding an announcement for it.  At the rate the queue is going, it may be days before it gets a try ....
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<asac> cjwatson: what would be the best way to check for what packages (in main) have not yet been rebuild in lucid?
<seb128> asac, compare karmic and lucid versions?
<seb128> should be a few python-apt line
<seb128> lines
<asac> yeah. could have been we already have something for that ;)
<seb128> could be, I don't know though
<cjwatson> asac: lp:~cjwatson/+junk/suite-diff
<asac> cool ... checking
<CAiRO> hi
<CAiRO> i'm just trying to compile a package from source and it fails with the error "tail: cannot open `debian/changelog' for reading: No such file or directory"
<CAiRO> i can see there's only a changelog.in file
<CAiRO> the real changelog file probably has to be generated from the changelog.in file, but how do i generate it?
<cjwatson> changelog is traditionally written by hand, not generated. if you have a changelog.in then your package is Weird and we would need to see a concrete example rather than guessing
<CAiRO> cjwatson: the package is sawfish http://sourceforge.net/projects/sawmill/files/sawfish/1.6.0/sawfish-1.6.0.tar.bz2/download
<cjwatson> CAiRO: wait a sec, you're relying on debian/* files in the upstream source?
<CAiRO> cjwatson: yes, i am
<CAiRO> cjwatson: worked fine so far with the other 2 libs
<cjwatson> CAiRO: I wouldn't bother. Pretend it didn't have any debian/* files and compile it in the usual upstreamish way
<CAiRO> cjwatson: well, then i'd rather make up the changelog file myself
<CAiRO> its always better to have a deb package with dependencies etc.
<cjwatson> CAiRO: it's clearly intended for daily builds or some such, it's not a proper changelog
<cjwatson> CAiRO: you could attempt to merge the .diff.gz from the Ubuntu archive
<CAiRO> cjwatson: well, it says the package is the latest stable version.. and there is some debian unstable package for it
<CAiRO> anyway, i managed to copy and extend the changelog file from the original sawfish 1.3.1 ubuntu package
<CAiRO> so now its working
<CAiRO> great thing, this update fixes all my problems with sawfish, yeah :)
<CAiRO> the coolest thing is that you can bind mouse buttons to things like "move window interactively".. its the same as in metacity with alt + middle mouse button.. except that i can use my mouse button 8
<CAiRO> without any keys..
<CAiRO> same goes for resize etc./
<zul> doko: ping
<zul> james_w: it looks like samba failed the bzr import can you have a look?
<james_w> yep
<happyaron> anybody can help on coverting docbook to pdf?
<ttx> cjwatson: please have a look at https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/503339
<ubottu> Ubuntu bug 503339 in eucalyptus "UEC lucid installer: CC fails to register when separated from CLC" [Medium,Triaged]
<ttx> cjwatson: it's due to a failure to fetch the CLC preseed file at install time
<ttx> wget.gnu: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory
<cjwatson> ttx: ok, will investigate once I've finished upgrading to lucid
<ttx> cjwatson: I guess adding libcrypto0.9.8-udeb to eucalyptus-udeb "Depends" would not provide the right file...
<ttx> cjwatson: sure :)
<cjwatson> eucalyptus-udeb is the wrong place to fix this
<cjwatson> it does not have a direct dependency on libssl itself
<ttx> I'll assign the bug to you then, feel free to look at it when you have some time.
<dholbach> did anybody else have spontaneous reboots on lucid?
<ttx> dholbach: I had spontaneous reboots on karmic.
<dholbach> it might be just my hardware that's unhappy, but I'm wondering
<pitti> not so far
<dholbach> http://paste.ubuntu.com/351799/ is the last things that happened afaics
<dholbach> but it doesn't really say much, does it?
<joaopinto> dholbach, is that mountall-shell expected to be running at that time ?
<dholbach> joaopinto: I have no idea
<dholbach> I certainly didn't run it myself :)
<ev> bryce_, Riddell: are you aware of any plans to implement BulletProofX for KDE, or plans to refactor the existing code so it's not so tied to GDM?  I'm investigating support for it in oem-config and only-ubiquity mode on the live CD.
<Riddell> ev: in theory that got implemented ages ago but I havn't tested it recently and I don't know if it still works
<ev> I just tried creating a broken xorg.conf on the kubuntu live CD (in the initramfs) and I ended up at a shell.
<ev> so I'd wager not ;)
<Riddell> guess not then
<joaopinto> dholbach, looking from mountall-shell.conf, mountall-shell was expected to be started only if manual recovery was required
<dholbach> joaopinto: I ran it in the boot before because I a filesystem was dirty after a previous "spontaneous reboot"
<joaopinto> ah ok, so is not a cause, it's a result :P
<dholbach> joaopinto: I rebooted after the recovery boot
<sbalneav> mvo: Thanks for #501559
<mvo> sbalneav: no problem :)
<jetsaredim> what is the easiest way to update a deb to adjust the makefile options?  obviously not for merging into ubuntu, but for my own personal use
<cjwatson> get the source package, edit debian/rules which typically calls make somewhere
<dholbach> GAR, it rebooted again :-/
<dholbach> http://paste.ubuntu.com/351822/ this time
<dholbach> can somebody enlighten me about mountall-shell?
<pitti> dholbach: probably only Keybuk
<dholbach> pitti: I see
<dholbach> it's a bit unpleasant if the machine just restarts like that :/
<joaopinto> dholbach, assuming mountall-shell is the cause, tere is a reboot call on the post-stop script
<joaopinto> don't trust me, but I c
<dholbach> joaopinto: hum... what does that mean?
<joaopinto> I guess you could mv /etc/init.d/mountall-shell.conf /etc/init.d/mountall-shell.conf.disable
<joaopinto> but make sure your filesystems are clean first :P
<joaopinto> well, better wait for KeyBuck, I am just wondering
<cwillu_at_work> dholbach, I believe the intent is to handle the rebooting after an automatic fsck, what's the context?
<pitti> aaah
<pitti> dholbach: perhaps there's a long-running fsck in the background, and once that finishes, it reboots?
<pitti> perhaps for a /media partition or so (which the booting doesn't wait on)
<cwillu_at_work> pitti, hmm, that's sound like a possibility
<cwillu_at_work> /etc/init/mountall-reboot fires on stopped mountall EXIT_STATUS=4
<cwillu_at_work> (tell me to shut up if I'm not being at all relevant :p)
<joaopinto> isn't the mainteance shell supposed to be interactive ?
<dholbach> there's no fsck running right now
<pitti> seems that everyone contributes a piece to a puzzle, so just keep going :)
<dholbach> and there's only sda1, so that'd surprise me :)
<cwillu_at_work> dholbach, can you repeat yourself for me?  what are you seeing?
<pitti> joaopinto: yes, but if X.org and getty are running, it probably doesn't even have a console to work on?
<pitti> dholbach: ok, so that's not it
<joaopinto> dholbach, is mountall-shell running ?
<dholbach> cwillu_at_work: my machine was restarting a couple of times without me doing anything
<pitti> brb
<dholbach> http://paste.ubuntu.com/351822/ is the last part of the syslog before restarting
<joaopinto> I mean, after a clean reboot
<dholbach> http://paste.ubuntu.com/351799/ is what happened before
<dholbach> joaopinto: let me restart again and check
<cwillu_at_work> mountall-shell -> start on (stopped mountall EXIT_STATUS=[!4] or stopped mountall EXIT_SIGNAL=?*)
<cwillu_at_work> the post-stop script would fire the reboot
<joaopinto> the mountall-shell should be running only if there was a failed mount
<joaopinto> cwillu_at_work, that is were I was looking at :)
<dholbach> joaopinto: not running right now after the reboot
<dholbach> let's see when the machine is going to restart itself again :)
<joaopinto> dholbach, is mountall running ?
<dholbach> joaopinto: nope
<cwillu_at_work> dholbach, pastebin initctl list
<joaopinto> ok, so I don't see how the recovery shell could be triggered at this time
<dholbach> http://paste.ubuntu.com/351836/
<cwillu_at_work> joaopinto, wait for the paste :p
<cwillu_at_work> mountall-shell start/running, process 1505
<joaopinto> that looks bad :P
<cwillu_at_work> dholbach, does it immediately reboot if you "stop mountall-shell"?
<dholbach> but "ps afxvw" does not show mountall-shell
<cwillu_at_work> dholbach, you wouldn't, it's upstart running a shell
<cwillu_at_work> dholbach, look for sh's
<dholbach> ahhh
<dholbach> /bin/sh -e /dev/fd/8
<cwillu_at_work> specificially process 1505 15051505:p
<cwillu_at_work> bah, too many 1505's
<dholbach> yes it does immediately restart
<cwillu_at_work> I think I want you to do something with initctl log-priority, but I don't know what :p
<dholbach> hm
<dholbach> that sucks :/
<cwillu_at_work> dholbach, add "initctl log-priority debug || true" in /etc/init/mountall.conf's script
<ion> dholbach: mountall-shell is started in the first place because mountall fails for some reason. Please change /etc/init/mountall.conf to exec mountall --debug --daemon $force_fsck $fsck_fix >/dev/mountall.log 2>&1
<dholbach> ion: http://paste.ubuntu.com/351841/
<ion> dholbach: Dunno then... It seems /dev/mapper/cryptswap1 never appears, but that shouldnât be related to this problem.
<dholbach> thanks a lot for helping out, ion
<joaopinto> even if there is a mountall failure there is another issue with mountall-shell which should be running on a VT
<ion> Ah, now that i took a better look at mountall-shell.conf, mountall failure doesnât seem probable after all.
<ion> dholbach: Try adding âexec >/dev/mountall-shell.log 2>&1; set -xâ in front of the script part in mountall-shell.conf
<dholbach> ion: where? the line before "script"?
<ion> dholbach: A new line just after âscriptâ
<dholbach> ah ok
<joaopinto> I am not familiar with upstart, but isn't mountall-shell being started on exit status 0 ?
<ion> Sorry for being ambiguous
<dholbach> ion: after "end script"?
<ion> dholbach: Might as well add âecho "EXIT_STATUS: $EXIT_STATUS, EXIT_SIGNAL: $EXIT_SIGNAL"â after the exec and set -x. I mean, add these as new lines between the âscriptâ line and the â    case "$EXIT_STATUS" inâ lines.
<dholbach> ion: I don't have that case EXIT_STATUS line
<cwillu_at_work> dholbach, it starts in the cases where mountall-reboot doesn't
<ion> dholbach: In mountall-shell.conf?
<cwillu_at_work> but my understanding is incomplete because I don't see why one of those isn't always true
<dholbach> ion: yes
<ion> dholbach: Please pastebin your mountall-shell.conf. Which version of the mountall package do you have?
<dholbach> 2.3
<dholbach> http://paste.ubuntu.com/351846/
<ion> Thatâs mountall.conf :-)
<dholbach> urgh
<dholbach> excusez-moi
<ion> dholbach: Oh, i just realized redirecting stdout and stderr might contaminate the analysis, since sulogin might behave differently in that case.
<ion> dholbach: This should run sulogin with the original file descriptors, but if youâre already taking a log, letâs take a look at it first. http://pastebin.com/f11f6a2e5
<dholbach> http://paste.ubuntu.com/351853/ is what I got now
<ion> How about /dev/mountall-shell.log?
<dholbach> http://paste.ubuntu.com/351854/
<ion> Huh. it seems mountall died with SIGABRT but didnât print an error message.
<cwillu_at_work> update_mount: /sys/kernel/debug: /sys/kernel/debug none debugfs optionmountall:mountall.c:1296: Not reached assertion failed in mountedall
<ion> cwillu: Good catch!
<cwillu_at_work> ion, it's the longest line in the log :p
<ion> Yeah, i just looked at the very end blindly to the rest, not realizing the flushing of stdout and stderr or something like that might cause that.
<ion> dholbach: Ok, i think i see the problem in mountall.c
<dholbach> ion: is there anything I can do for now?
<cwillu_at_work> dholbach, just disable the shell script will work, or comment out the umount -a ; exec reboot -f lines
<dholbach> thanks ion and cwillu_at_work
<dholbach> ion: will you talk to Keybuk about that problem or propose a fix for it or something?
<dholbach> ion: I don't know what to do about it nos
<dholbach> now
<ion> dholbach: Yeah, i will.
<dholbach> thanks a bunch ion
<ion> np
<cjwatson> superm1,pitti,ev: please note for future commits that casper is in lp:ubuntu/casper now rather than lp:caspper
<cjwatson> lp:casper that is
<pitti> ah, thanks; me updates his branch
 * ev does the same
<superm1> cjwatson, what is lp:casper then?
<cjwatson> superm1: it has in big letters on it "use lp:ubuntu/casper instead" so I assume it's just hard to delete or something
<cjwatson> we can always try to keep them in sync somehow I suppose, but we definitely want to get to the invariant where lp:ubuntu/<package> works for all packages in Ubuntu so please try to avoid writing to lp:casper
<robbiew> james_w: should we have kerneloops enabled by default during Alpha/Beta releases?
<pitti> IMHO we should enable apport and kernelopps for alpha-2
<pitti> (and perhaps we can get a kernel fix to unbreak signal crashes as well again)
<james_w> robbiew: aha! we discussed that this morning
<robbiew> :)
<james_w> I'll renable when apport is, unless the kernel team want something different?
 * robbiew had an oops when messing with his bluetooth headset sound settings ;)
<robbiew> james_w: I'll check with pgraner
<james_w> thanks
<pitti> seb128: I'd like to enable apport now, so that we can get at least python and kernel crashes (won't work yet for sigsegv due to kernel bug); ok for you?
<seb128> pitti, it's early to my taste but if you think it's useful...
<robbiew> james_w: actually...their weekly meeting is going on now
<robbiew> so I'll try to ask there ;)
<superm1> cjwatson, i thought there was a way to mark a branch as pointing to something at lp:<PROJECT> ?  Is it maybe the project driver at launchpad.net/casper needs to set the development focus to the right branch?
<cjwatson> superm1: I don't think project and distribution branches get to meet
<cjwatson> unfortunately
<pitti> seb128: you don't want it for alpha2?
<superm1> oh shame :(
<robbiew> james_w: got a response..."(11:20:16 AM) pgraner: robbiew: yep, should go off for rc"
<seb128> pitti, I'm not sure, starting early means adding thousand of crash bugs that we will never look at
<seb128> because that will be too many of those, new versions coming, etc
<pitti> that's fine
<seb128> well it adds to the "not able to work on our bug lists anymore"
<pitti> we should only look at the ones with many dupes anyway (at least initially)
<james_w> cjwatson: we can point lp:ubuntu/casper at lp:casper, it will just cause some fun when we branch for manic
<pitti> seb128: ok, so when do you think is a better time? beta-1?
<seb128> if only we had a good way to get notified about those...
<ion> dholbach: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid should contain a fix. Iâll mention it to Keybuk when heâs around.
<seb128> pitti, hum, alpha3?
<pitti> seb128: ^ I'm working on that
<james_w> robbiew: I'm now sure what that means?
<pitti> seb128: bug 487900
<ubottu> Launchpad bug 487900 in apport "retracer should subscribe ubuntu-bugcontrol team to bugs w/ lots of dups" [Medium,In progress] https://launchpad.net/bugs/487900
<seb128> pitti, well I'm not opposed to enable it now if some people find those useful
<seb128> or have time to look at those bugs
<seb128> if we start only to look at bugs in one month because we are too busy with work items, etc now
<cjwatson> james_w: ok, if that's possible, please do. the branches are currently identical
<seb128> they will be outdated by then and only noise
<robbiew> james_w: should be enabled for Alphas and Betas...then off for the Release Candidate
<robbiew> sorry :/
<james_w> robbiew: ok, makes sense
<robbiew> james_w: does it make sense to note this as part of our process for when we open the next release
<seb128> pitti, could you subscribe the package maintainer also to those or something which would made people watching the package to be notified by email?
<james_w> I'll fix that mega-bug before I enable it, I'd rather not taunt the baying hordes once again
<james_w> robbiew: if they would like it on as soon as the release opens then yes, it would make sense there
<pitti> seb128: that's a good idea
<pitti> I'd certainly appreciate this for my packages
<robbiew> james_w: agreed...could you let slangasek know to add this to the process?
<dholbach> ion: awesome! :)
<pitti> seb128: OTOH, the bug already calls for tagging it "bugpattern-needed"
<james_w> robbiew: I think it's just a wiki page
<seb128> pitti, maybe do it only if the maintainer is in bugcontrol though
<pitti> seb128: we could just set up filter rules to look for those, too
<robbiew> james_w: heh...isn't it always
<pitti> seb128: but as I said, even if I enable apport now, it's only for python and kernel oopses
<robbiew> james_w: well then could you add it to the wiki page?
<seb128> pitti, do it then
<seb128> we need to find a better way to deal with bugs anyway
<seb128> it's going to add some extra noise but very noisy or very very noisy...
<seb128> we don't read all bugs in any case
<pitti> right
<james_w> robbiew: done: https://wiki.ubuntu.com/NewReleaseCycleProcess?action=diff&rev2=48&rev1=47
<pitti> but we can get them collected and duplicated
<pitti> seb128: I don't get bug mail for crashes, do you?
<robbiew> james_w: thank you kind sir!
<seb128> pitti, not until somebody makes those public
<pitti> right
<seb128> but as asac is saying for cycle bugs should not go to bug tracker
<seb128> they should go to crash collector and only selected ones should be moved to bugs
<seb128> but that's out of the scope of this discussion
<seb128> launchpad is turning to a noise tracker
<asac> ++
<seb128> and we are building a new bug tracking system on it
<seb128> ie trying to build lists of useful bugs
<asac> maybe we could file crash bugs against a launchpad project != ubuntu and then regularly sort them by duplicates and add ubuntu tasks for those that are important?
<seb128> well the noise issue is not specific to crashes nowadays
<Riddell> who broke fontconfig in the builddds?
<seb128> we just need a way to build custom bug lists from things we pick up in the noise
<asac> what other automated filing happens now?
<asac> or just saying there are too many bugs filed?
<seb128> too many bad quality bugs
<seb128> or non useful user rants
<asac> yeah. thats true
<asac> Riddell: fontconfig wasnt uploaded for 10 weeks
<asac> even longer ;)
<Riddell> right enough but "/var/lib/dpkg/info/fontconfig.postinst: 13: defoma-subst: not found" something broke it
<seb128> defoma got uploaded
<seb128> it's a sync from Debian though
<james_w> we probably want to sync fontconfig too
<asac> so fontconfig needs a merge?
<asac> sync would be fun ;)
<Riddell> ArneGoetje: about?
<Riddell> actually it was TheMuso who asked for the sync
<pitti> seb128: oh, Debian has fontconfig 2.8 now as well
<seb128> rock on
<asac> as well?
<pitti> I put 2.8 into the ubuntu-desktop PPA a while ago
<asac> ok so you can just upload that?
<pitti> well, we have patches, it needs a merge
<pitti> that was just a quick update to test whether it impacts boot speed
<pitti> ArneGoetje: do you have some time to merge fontconfig and review what our remaining delta is?
<asac> ok thoguth you already did that
<asac> the merge will take a bit
<asac> http://pastebin.com/f1cae287f
<asac> i think just that might work
<asac> at lesat it says its about:
<asac>  emergency band-aid fix to avoid messing setup on install/remove when
<asac> +    defoma is not installed, Closes: #559136, #560252, #559348
<asac> someone wants to test before i upload?
<asac> seb128: Riddell: pitti: http://pastebin.com/f30d6922   thats from upstream NMU http://pastebin.com/f1cae287f
<asac> i have no system to test that atm. but since its broken and i wont have time to do full merge, i will just upload
<Riddell> asac: rock
<asac> uploaded. lets hope ;)
<kees> python-unit pulls in X now?  odd.
<DktrKranz> jdstrand: when you have time, mind looking at bug 485973? It seems a regression in php5.
<ubottu> Launchpad bug 485973 in php5 "php5-cgi: IMAP toolkit crash" [High,Confirmed] https://launchpad.net/bugs/485973
<jdstrand> DktrKranz: ok
<DktrKranz> thanks
<pitti> asac: thanks!
<pitti> ev: sorry for the casper mess, seems I was wrong yesterday
<pitti> ev: derivatives have an existing gdm custom.conf for setting the default session
<pitti> ev: I'll sort it out, just FYI
<seb128> pitti, new gdm tarball has that in the news
<seb128> "- make --with-custom-conf work"
<seb128> pitti, ^ not sure if that has anything to do with what you discuss there though
<pitti> seb128: actually not, this is about enabling autologin in casper
<seb128> I just mention it because I was reading the news of things which are to update some minutes ago
<pitti> but good to know
<seb128> ok
<DktrKranz> mvo: my gdebi merge proposal is ready for review. wrt detecting presence of --always-ask-pass, it's not so easy to detect it at runtime because it's undocumented. The only workaround I can think about is checking with lsb_release, or so.
<simple> selam
<simple> ilk once sansimizi turkce olarak deniyelim
<simple> sonra engilisceye vururuz kendimizi
<simple> ubiye ntfs formatlÃ½ bi hdd takÃ½yorum ama gormuyor
<simple> mount etmiyor
<highvoltage> hi simple, sorry this channel isn't for support and I doubt many people here would understand that
<simple> saol dayi
<Zorry> doko_: ping
<cody-somerville> Is HAL completely deprecated in lucid yet?
<ion> Dunno, but neither of the two desktop boxes i have have hal installed.
<pitti> cody-somerville: it's not in the default install any more, but of course there are still tons of packages depending on it
 * cody-somerville nods.
<pitti> cody-somerville: it won't get removed from the archive anytime soon, if you mean that
<cody-somerville> pitti, Do you mind if I add packages affecting Xubuntu to the Halsectomy wikipage?
<pitti> cody-somerville: to the contrary, the more complete that page is, the better
<mvo> DktrKranz: thanks, I have a look at the gdebi merge now
<cody-somerville> pitti, Removing hal from the archive would be bad for Xubuntu.
<cody-somerville> pitti, Xfce isn't as far along with the migration as gnome seems to be.
<pitti> cody-somerville: right, nobody is proposing to remove it entirely
<pitti> we just wanted to get rid of it from a default install
<cody-somerville> keybuk is ;)
<pitti> $ apt-cache rdepends libhal1|wc -l
<pitti> 74
<pitti> have fun..
<charlie-tca> appears Xubuntu needs it on the desktop cd
<charlie-tca> no
<charlie-tca> needed it after updates when installing from the alternate cd
<ev> pitti: ah, ouch.  Thanks for the heads up.
<pitti> ev: uploaded already; I'll test tomorrow's daily
<charlie-tca> What's the user name to use the desktop cd? trying to run todays version, I get a gdm login screen wanting a user name
<pitti> charlie-tca: hm, today's works for me (but it's "ubuntu")
<pitti> charlie-tca: yesterday's was broken
<mvo> DktrKranz: merged, many thanks. I think the only reliable way is to use lsb-release. or we just remove this feature (or make it optional or something)
<charlie-tca> yesterday's worked for me, today's won't
<charlie-tca> but it is xubuntu
<pitti> ah
<charlie-tca> I'll try it again tomorrow, we might be a day behind on updates, then. Thanks
<pitti> I guess the xubuntu livefs builds earlier
<pitti> and didn't catch the casper fix yet
<charlie-tca> I see. No problem then, as long as it is known.
<charlie-tca> Our images are about three hours before ubuntu images, on the server
<pitti> charlie-tca: oh, wait
<pitti> charlie-tca: yes, I know what happened
<pitti> charlie-tca: the casper that got uploaded an hour ago should fix it for both
<pitti> charlie-tca: I'd appreciate if you could test tomorrow's image and verify?
<charlie-tca> Will do that. Thanks for your time.
<DktrKranz> mvo: I agree, I'll patch to use lsb_release now
<mvo> many thanks DktrKranz!
<Lure> is something wrong with i386 chroot and/or fontconfig package: I get this failure http://launchpadlibrarian.net/37455955/buildlog_ubuntu-lucid-i386.kphotoalbum_4.1.1-1ubuntu2_FAILEDTOBUILD.txt.gz
<chrisccoulson> asac^^^
<chrisccoulson> (not sure if you know about that) :)
<chrisccoulson> ah
<chrisccoulson> Lure - that issue is fixed in the latest fontconfig it seems
<chrisccoulson> 2.6.0-1ubuntu13
<chrisccoulson> so you will just need to try again shortly
<Lure> chrisccoulson: thanks, will retry...
<DktrKranz> mvo: lsb_release changes committed
<asac> Lure: chrisccoulson: let me know if it really fixsed it. i made kind of a blind upload in the hope that this will helop ;)
<chrisccoulson> asac - Lure's build log shows it was still using the old version i think
<asac> kk
<asac> lets hope
<Lure> asac: fixed for me - retried build succeeded
<asac> cool
<asac> thx
<Lure> asac: thank you
<asac> np
<ScottK> pitti, lamont, NCommander: Would one of you please rescore kdepim-runtime (karmic-backports).  It's lack on amd64 is breaking installs.
<ScottK> (or any other buildd admin who happens to be reading ...
<lamont> ScottK: on it
<ScottK> lamont: THanks.
<ScottK> Thanks even.
<lamont> though fwiw, the URL for the build record is a total win... not much work to get to, but jus tsayin
<ScottK> https://launchpad.net/ubuntu/+source/kdepim-runtime/4:4.3.4-0ubuntu1~karmic3/+build/1428284
<ScottK> lamont: ^^
<lamont> I see we are both equally fast :-)
<lamont> rescored.
<kirkland> slangasek: hi, i just manually wrote an upstart script based on an existing init script
<kirkland> slangasek: it's in /etc/init/libvirt-bin.conf
<kirkland> slangasek: i'd like to test it out
<kirkland> slangasek: what else do i need to do to "register" the script, besides write it to that dir?
<kirkland> slangasek: is there a sysctl or something?
<kirkland> slangasek: start: Unknown job: libvirt-bin
<kirkland> slangasek: s/sysctl/initctl/
 * kirkland tried sudo initctl reload-configuration, to no avail
<slangasek> kirkland: mmm, inotify is supposed to pick it up automatically
<slangasek> kirkland: maybe it thinks your job syntax is wrong?
<kirkland> slangasek: is there a log that would tell me that?
<kirkland> slangasek: and can the init.d script remain there (stopped) for the time being, while I'm testing?
<slangasek> log> probably not by default, you could bump the log priority (initctl log-priority info?), touch the job file again, and check
<slangasek> kirkland: I can't imagine it hurts anything to have the init.d script there
#ubuntu-devel 2010-01-06
<kirkland> slangasek: http://pastebin.ubuntu.com/352031/
<slangasek> kirkland: line 7 is invalid
<slangasek> you can't have random shell syntax outside of a 'script' block :)
<kirkland> slangasek: if i put that in pre-start, will the result of that shell script sourcing (variables/values) be available to the exec?
<slangasek> nope
<kirkland> slangasek: bing
<slangasek> (not AFAIK) - so you'd have to duplicate the line
<slangasek> OTOH, I don't think your pre-start script depends on the contents of that file :)
<slangasek> so what you want is:
<slangasek> script
<slangasek>     [ -f /etc/default/libvirt-bin ] && . /etc/default/libvirt-bin || true
<slangasek>     exec /usr/sbin/libvirtd $libvirtd_opts
<slangasek> end script
<kirkland> slangasek: bingo!
<kirkland> slangasek: works like a champ
<kirkland> slangasek: thanks, as usual ;-)
<kirkland> slangasek: one last question
<kirkland> slangasek: i'm trying to figure out the correct "start on" req's
<slangasek> ok
<kirkland> slangasek: the init script says: http://pastebin.ubuntu.com/352034/
<kirkland> slangasek: i'd like to learn the translation between those two pieces
<slangasek> I think 'start on runlevel [2345]' is simplest
<slangasek> and 'stop on runlevel [!2345]'
<kirkland> slangasek: so i don't need to account for required-start $network $local_fs ?
<slangasek> (c.f atd, dmesg, apport...)
<slangasek> no, those are guaranteed to be up before the runlevel is declared
<kirkland> slangasek: is the stop on explicitly required?
<kirkland> slangasek: and why the "45"?  we haven't been putting those in our other upstart jobs
<kirkland> slangasek: usually we've been doing start on [23]
<slangasek> the 'stop on' prevents the job from continuing to respawn after killall5 has been called on shutdown
<kirkland> slangasek: hmm, okay
<slangasek> "why the 45" - because that's always been the default, and maps precisely to your existing 'Default-Start' line
<kirkland> slangasek: again, the eucalyptus ones lack that currently; would it be nice to add them?
<slangasek> I don't know why anyone would be creating jobs that only start in runlevels 2 and 3; yes, eucalyptus ought to have that added
<kirkland> slangasek: okay, i'll fix
<slangasek> strange, /etc/init/tty[23456].conf are 'start on runlevel [23]'
<kirkland> slangasek: yeah, i'm grepping the others right now
 * kirkland mulls an "alias" for 2345 ...
<crimsun> does anything need to be done to promote libtdb-dev to main?
<crimsun> (i.e., currently causing pulseaudio to FTBFS)
<TheMuso> crimsun: I thought tdb was in main?
<wgrant> libtdb-dev is a new binary package that has landed in universe.
<TheMuso> If it belongs to a source package in main, then its just a matter for an archive admin to promote the binary afaik.
<james_w> it needs someone to process http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<kirkland> slangasek: would it be possible to permanently reschedule the server ISO builds for about 4 hours from now?
<kirkland> slangasek: thats just about the perfect time to pick up western US changes
<kirkland> slangasek: and build them in time for our earliest Euro team members
<kirkland> cjwatson: I suspect you might be able to answer that too ^
<slangasek> I don't see any reason we could'nt
<slangasek> couldn't
<cjwatson> fine by me
<sbalneav> Sigh, Bug #501559 is still kicking my butt.
<ubottu> Launchpad bug 501559 in libgksu "libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL" [High,Confirmed] https://launchpad.net/bugs/501559
<sbalneav> There's so many differences between the older behaviour with forkpty, and the newer behavior.
<TheMuso> /c/c
<crimsun> are we still no-go on source v3.0 uploads?
<RAOF> I thought we were go for 3.0 as of a couple of days before Christmas?
<pitti> Good morning
<ttx> pitti: Good morning
<ttx> pitti: I could use a server CD respin, the one that spinned two hours ago unfortunately didn't catch eucalyptus 1.6.2~bzr1120-0ubuntu3
<ttx> kirkland: I guess we need a larger safety margin between upload and respin at the end of your day
<pitti> ttx: triggered
<ttx> pitti: thx
<pitti> cody-somerville: btw, yesterday I changed hal to get dbus activated instead of launched by upstart; if hal doesn't work with Xubuntu any more, I'm to blame (please ping me)
<dholbach> good morning
<ttx> pitti: beh, the new respin still hasn't caught the latest. Investigating
<ttx> pitti: is there a lag between publication and cd-builder archive sync ?
<pitti> shouldn't be much
<pitti> if it's on archive.u.c., antimony should see it, too
<ttx> 1.6.2~bzr1120-0ubuntu3 has been published an hour ago.
 * ttx checks up archive
<pitti> (antimony uses ftpmaster.internal)
<ttx> archive has it since 0704 UTC
<ttx> you triggered at 0721
<pitti> weird
<pitti> ttx: what's that package?
<ttx> pitti: eucalyptus -- http://archive.ubuntu.com/ubuntu/pool/main/e/eucalyptus/
<ttx> I need 1.6.2~bzr1120-0ubuntu3 for testing
<pitti> ttx: hm, indeed cdimage@antimony:/srv/cdimage.ubuntu.com/ftp/pool/main/e/eucalyptus only has ubuntu2
<pitti> 2010-01-06 07:13 Packages.gz
<pitti> (it's 08:10 on antimony)
<pitti> ttx: I'll watch this, and when the next sync happens in 2 mins, I'll verify euca again and retrigger
<superm1> pitti, it certainly broke launching ubiquity in an xfce env (lack of hal), but i think http://pastebin.com/f473910b2 will handle this
<ttx> pitti: hm, the lag makes asking for a CD respin a little guesswork :)
<ttx> pitti: cool, thanks
<pitti> superm1: oh, it doesn't get dbus launched for you?
<superm1> pitti, not when hal-lock is ran
<pitti> superm1: ah, I see; for some reason "lshal" doesn't trigger it either
<pitti> lshal and hal-device (and I suppose hal-lock) has an extra check if it's running
<ttx> pitti: scripting the famous "trigger on antimony-publication slangasek magic" could help here. Somethign like "trigger-cd-on-publication server eucalyptus_1.6.2~bzr1120-0ubuntu3" would make your life easier :)
<superm1> pitti, well up to you whether you want to patch that behavior out, or if just a pgrep for hald is sufficient (i mean hal-lock shouldn't need to be ran if hal isn't running in the first place!)
<pitti> superm1: not sure; if you are okay with the pgrep, that works for me
<superm1> pitti, yeah i think that's the easiest solution for now, will commit it to ubiquity bzr then
<superm1> something else weird is going on with that gtk+ upload from yesterday though
<superm1> ubiquity uses setattr to make widgets callable at the top level, and that appears to have broken for some reason
<paykoob> hi. when is the calm hours of Launchpad build farm for PPAs? I dont want to wait an hour!
<pitti> ttx: hm, I don't know what's going on; it didn't update at all now
<ttx> pitti: hm
<pitti> didrocks, StevenK: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-une has one remaining work item "Rename ubuntu-netbook-remix{,-default-settings}" which is marked "in progress"; who is working on this? do you need any help with NEW, etc.?
<StevenK> pitti: Right, so the only thing remaining is removal of u-n-r-d-s, which I'm still thinking about.
<pitti> StevenK: oh, I don't see a replacement u-n-d-s?
<pitti> or is that entirely obsolete now with didier's gdm changes to support an extra gconf tree?
<StevenK> ubuntu-netbook-default-settings |      0.7.0 |         lucid | source, all
<StevenK> pitti: ^ ?
<pitti> *cough*
<StevenK> Haha :-)
<pitti> StevenK: note that I said "I don't see", not "it's not there" :)
<StevenK> pitti: Yes, so I brought it closer so you could see it.
<persia> Winning on purely semantic terms only gets half-credit
<StevenK> Awwww
 * StevenK goes to cook dinner
<pitti> sweet, thanks
<pitti> StevenK: enjoy!
<persia> StevenK: Why not drop u-n-r-d-s, and have u-n-d-s provide a dummy for transition?  Shouldn't that improve the experience of karmic upgraders?
<pitti> persia: that already happens
<joaopinto> I had 2 system freezes with lucid in the last 2 weeks :(
<persia> pitti: Erm, does it?  My lucid apt-cache doesn't show a dummy u-n-r-d-s from the u-n-d-s source, just a Replace/Conflict against u-n-r-d-s by u-n-d-s.  I also still see in lucid a u-n-r package depending on u-n-r-d-s, and a separate u-n package dependsing on u-n-d-s.
<pitti> persia: right, u-n-d-s should build a transition package
<persia> That was the suggestion :)
<pitti> right, misunderstood you; sorry
<persia> Might make sense for netbook-meta to do so as well.
<pitti> same with u-n-r vs. u-n
<persia> Right
<seb128> superm1, hey
<seb128> superm1, could you open this gtk bug upstream too?
<superm1> hi seb128
<superm1> seb128, i think we have to adjust our code actually
<superm1> it looks like a fundamental change upstream
<seb128> I'm just reading it
<superm1> it should be a one line fix for ubiquity it looks like
<seb128> but if you read the bug referenced in the commit they say some software are using buggy assumptions
<dholbach> which bug is that?
<seb128> right, what I was starting to think too
<seb128> dholbach, bug #503710
<dholbach> is it the reason why gtg crashes on startup? :)
<ubottu> Launchpad bug 503710 in mythbuntu-control-centre "updated gtk+2.0 package has problems referring to the name of widgets loaded from a builder UI file" [Undecided,Fix released] https://launchpad.net/bugs/503710
<seb128> dholbach, dunno, gtg could be buggy
<seb128> I don't use it
<dholbach> I guess it's something different:
<dholbach> **
<dholbach> Gtk:ERROR:/build/buildd/gtk+2.0-2.19.2/gtk/gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: (tree)
<dholbach> Aborted
<seb128> seems a different issue from the assertion
<dholbach> ok ok
<superm1> seb128, http://pastebin.com/f206651ca appears to fix it for ubiquity from what i just tested
<seb128> superm1, good
<seb128> thanks for looking into that one
<superm1> so i'll do a ubiquity upload with thatso that live disks can be working again
<dholbach> seb128: the bug I had is bug 503576 (bug 503630 seems to be a dup)
<ubottu> Launchpad bug 503576 in seahorse "Seahorse fails to start with error Gtk:ERROR:/build/buildd/gtk+2.0-2.19.2/gtk/gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: (tree) ) = 113 in Lucid" [Undecided,New] https://launchpad.net/bugs/503576
<ubottu> Launchpad bug 503630 in synaptic "synaptic will not load" [Undecided,New] https://launchpad.net/bugs/503630
<seb128> ok
<dholbach> I don't know if it's a red herring, but in the case of gtg the last file to be opened is one of the DMZ cursors too (like in the seahorse bug I mentioned)
<seb128> dunno
<seb128> I will look at that in a bit I'm busy with a cairo fix right now
<dholbach> sure sure, no worries
<seb128> jdstrand, kees: is apparmor_parser using cpu for ages on evince install in lucid a known issue?
<seb128> we get some users ctrl-C-ing the install because they think it's stucked
<tseliot> james_w: why does bzr-builddeb -S require the build dependencies of a package? Can I override this with -d ?
<james_w> tseliot: yes, but it's spelt "-- -d" currently
<tseliot> james_w: aah, ok, it makes sense. I'm about to make my 1st upload as a core-dev and I'm following the instructions from the DistributedDevelopment wiki page. Excellent work BTW.
<james_w> thanks, let me know if there are any problems
<tseliot> sure
<james_w> and feel free to improve the documentation if you find any areas that are lacking
<cjwatson> could somebody process the new libssl0.9.8-udeb in NEW? it should end up in main
<cjwatson> it's for a bug that the server guys wanted fixed
<pitti> apw: I'm currently working on reorganizing the work items tracker and DB, so that I don't need a million cron jobs and to parse each spec three times (it'll get more hairy once we get to alpha-3)
<pitti> apw: right now, your wiki-status.py directly parses the original data again
<pitti> apw: would you mind taking a look at http://paste.ubuntu.com/352238/ and check if this structure has everything you need?
<pitti> apw: then wiki-status.py could get the data from the db, and we'd have a clear separation of data collection and report generation (I plan to split the thing into "collect", "html-report", "wiki-report", and "burndown-chart"
<pitti> cjwatson: looking
<apw> pitti, can i tell what is current with that form?  or would you assume i am dropping the db each time for my use case
<pitti> apw: yes, the HTML report generator already does that
<apw> cirtainly have no objection to the underlying desire
<pitti> apw: SELECT max(date) FROM work_items
<pitti> apw: and then SELECT ... WHERE date == (result from above)
<apw> ok, fair enough.  one assumes in the furture this thing will come inhouse, and start generating all the wiki pages for us
<pitti> apw: the idea is to reduce the millions of DBs that I have (foundations-lucid-a2-workitems.db, global-lucid-workitems.db, etc.)
<pitti> apw: into one "lucid.db" which knows about teams and milestones, and everything else that we need
<pitti> my server would then regenerate this every hour (which is then doable; parsing the stuff ten times for all teams is too much for hourly processing)
<pitti> and since the .db is publicly available, you can then also run scripts locally on it
<pitti> apw: in fact,  this data collection doesn't need all the pychart stuff, etc., so this could run on rookery
<pitti> apw: (another reason why I want to split the programs)
<pitti> then everyone could configure the collection on rookery
<pitti> and I'd just need to run the burndown chart generation on my server
<apw> pitti, yep all sounds reasonable.   one thing to consider (and i think this is a global wrongness) is that rather than assuming that a group owns just the specs which are in its team
<seb128> dholbach, gtk fix uploaded, I verfied it fixes gtg and seahorse
<apw> is that actually a team owns all the work for its members, i fake that by adding items from other teams specs which are assigned to 'my' team people
<apw> but it would be nice to be able to do that in generally
<pitti> apw: in http://paste.ubuntu.com/352238/ the concept is that a spec is owned by a team, but a work item is owned by a person (or a team), which is not necessarily the same team as the spec
<pitti> apw: ah, that's a good point
<apw> yeah i think the data allows it, and if we want to do that generally it should be easy in all reports if we have a team to people mapping
<pitti> apw: it's next to impossible right now with split DBs; but if it's all in one DB, this is much easier indeed
<pitti> apw: but in fact I think you are right
<apw> but i think the format as it is does not preclude the change as a step 2
<pitti> apw: instead of having a "team" entry in the spec_info table, I think we should rather have a "teams" table which maps people to a team
<pitti> then a report for the "desktop" team would collect all work items which are assigned to all people which are part of that team
<pitti> instead of filtering the blueprints by team first and then by assignee (which is what we currently do)
<apw> there are two mental views, work for desktop, and work being done by desktop, i think our reports are the later indeed
<apw> (should be)
<apw> yeah i believe so
<pitti> apw: well, I think I'll keep the "team" entry in spec_info, even if we don't want to use it; if we ever want to create such a report "by us, for us", it can come in handy
<pitti> apw: so, does wiki-report.py collect any extra information which isn't represented in those two tables?
<apw> pitti, thinking
<apw> pitti, the only generic thing i have to invent over the data there, is a milestone ordering
<apw> pitti, oh we do use the description of the spec as a fallback for the status, but i guess you'd call that status in both cases
<pitti> apw: yeah, I think that should be a matter of data collection
<pitti> i. e. if there's no status we could just fill in the description as value for "status"
<apw> yeah, thats what i do, put 'Description: ' on the ftont and ram it in the same hole
<apw> so no i can't see anything on my page which isn't in there
<dholbach> seb128: you are a hero!
<pitti> apw: http://paste.ubuntu.com/352248/
<pitti> apw: that provides milestone ordering, too
 * seb128 hugs dholbach
 * dholbach hugs seb128 back
<apw> pitti, should priority have a sortable numeric value, its main use it converted to a number for sorting as far as i can see
<pitti> apw: (with the obvious omission in the work_items table fixed)
<pitti> apw: hm, we get it as a string value only, and map it to a color
<apw> +def priority_value(name):
<apw> +    if name == "Essential":
<apw> +        return 99
<pitti> def priority_value(name):
<pitti> ah
<apw> can this db do a function?  then that would be fine represented as a function in the schema
<pitti> apw: sqlite doesn't have a CREATE FUNCTION unfortunately
<pitti> so priority -> value and priority->color mapping would need to be done in the report generator code
<apw> we can live with that
<apw> pitti, before you get hacking on it there are a couple of improveents sitting in my branch
<apw> they all look pretty self contained
<apw> mostly the stuff to fix the escaping to be correct
<pitti> $ bzr merge lp:~apw/launchpad-work-items-tracker/wiki-status
<apw> yeah
<pitti> "Nothing to do."
<apw> how long does LP take to update a branch once its pushed
<pitti> on the webui, two or three minutes
<pitti> but no delay at all if I use bzr+ssh:// to pull
<apw> pitti, i think i am being dumb, looks to be in ther
<apw> pitti, so let me know if there is anything i need to do in this conversion
<pitti> apw: once I get the "collect" script rewritten, it's by and large to change wiki-status.py to use the DB instead of parsing the data again
<pitti> however, that doesn't need to happen in lockstep
<apw> yeah
<pitti> apw: I probably need to break the API slightly, though, due to the DB reorg
<pitti> apw: but I'll develop it in a branch and only merge it once everything works again
<tseliot> james_w: it doesn't seem to be my lucky day: http://pastebin.ubuntu.com/352256/
<tseliot> :-/
<pitti> tjaalton: "The topic for #launchpad is: LP DB security updates, possible intermittent outages 11:00-11:30 UTC"
<pitti> sorry, tseliot ^
<tseliot> pitti: oh, are you trying to say that launchpad doesn't hate me today :-P ?
<james_w> tseliot: erg
<pitti> tseliot: well, it hates everyone equally rather
<james_w> ah
<tseliot> :-D
<james_w> might warrant a launchpad bug anyway
<apw> pitti, seems reasonable, i can work against the other branch once its there
<james_w> might be nice to say "LP is out for lunch, please come back later"
 * tseliot nods
<james_w> I want to lock a file from a python process, I would like the lock to be exclusive and only exist as long as the process does, which type of lock has those semantics?
<soren> james_w: fcntl.flock(fd, fcntl.LOCK_EX), I think.
<james_w> yeah, just found buried in the manpage the statement that they survive as long as the process, thanks
<ttx> pitti: the daily server CD wasn't produced at 1030 UTC as usual... what's the status ? Was antimony archive synced ?
<pitti> 2010-01-06 10:18 Packages.gz
<pitti> it's 12:31 on antimony
<pitti> it seems to lag badly today for some reason
<ttx> I think 10:18 should be alright... let me doublecheck
<pitti> anyway, it does have ubuntu3 now
<pitti> (just checked Packages.gz)
 * pitti respins
<pitti> ETA 10 mins
<ttx> pitti: cool, thx
<cjwatson> jiboumans,ttx: for RT#36737, can't you just boot the netboot installer with anna/choose_modules=eucalyptus-udeb? that should have much the same effect as the CD boot option
<ttx> cjwatson: hmm, yes, that could take care of the "installed from UEC installer" feature testing... as we would test the ISO release deliverables as part of regular ISO testing anyway
<ttx> cjwatson: iiuc that could also be used instead of triggering CD respins just to test new eucalyptus uploads ?
<cjwatson> ttx: sure
<ttx> interesting. /me tests
<amikrop> Nautilus, and the whole system/desktop/CPU gets eaten/stuck/froze when you browse a WebDAV directory. You should really do something.
<amikrop> Another serious thing: You cannot copy to a WebDAV directory. Copying... hangs forever.
<amikrop> WebDAV does not work at all.
<amikrop> with Nautilus
<tjaalton> blame gvfs-backends
<tjaalton> (the package)
<hyperair> and file a bug
<tjaalton> that too
<tjaalton> preferably upstream, or both
<amikrop> excuse me, I won't
<amikrop> I have already filed a bug or two about WebDAV and I got ignored
<amikrop> so I don't think it has much point
<amikrop> It is a bug in your Distro
<amikrop> I want to help, so I report a problem
<amikrop> if you want to make your distro usable, fix the bug
<tjaalton> eh no, it's an upstream bug
<persia> Um, it's a bug in *both* places.
<tjaalton> they don't care about webdav enough
<persia> (or it's not a bug)
<hyperair> amikrop: erm yes, you report a problem by filing a bug. is that really so hard?
<tjaalton> persia: well, true
<hyperair> amikrop: bug reports are fixed by people who have interest in the problem. you're more likely to find people interested in fixing webdav support in the upstream (because even if ubuntu people fix it, the fix is going back upstream as well)
<amikrop> hyperair: how do I report an upstream bug?
<amikrop> because the whole system hangs and nothing works about webdav
<hyperair> amikrop: you have to identify the upstream bug tracker, and then file a bug there.
<amikrop> and I am forced to mount it via command line
<amikrop> mount.davfs
<amikrop> and not Connect server...
<hyperair> since as tjaalton mentioned, the problem lies in gvfs-backend, the bug tracker would be bugzilla.gnome.org
<hyperair> after that, if you can't fix the bug yourself, your only option is to be patient.
<amikrop> I want to say, it is not a favor made to the users
<amikrop> it is a favor made by the users
<amikrop> to report problems
<cjwatson> it's both
<amikrop> I will report it there
<dholbach> seb128: gtk fix fixes it
<seb128> dholbach, great
<dholbach> seb128: the reason for the breakage was very amusing :)
<seb128> dholbach, ;-)
<seb128> "ups"
<dholbach> yeah :)
<jdstrand> seb128: re apparmor_parser> basically, yes. jjohansen is working on it and can give you the most up to date info
<seb128> jdstrand, thanks
<seb128> jjohansen, hey, is there any bug about apparmor_parser being sloooow?
<seb128> we got users stopping the evince install because they think it's stucked
<seb128> it seems to be apparmor eating cpu
<jjohansen> yeah it can be, its in the dfa generation
<jjohansen> I am working on some optimizations
<seb128> do you have a bug about that or want one?
<seb128> or you are working on it anyway and the bug is of no use?
<jjohansen> seb128: no bug open yet, feel free to open one
<seb128> I might just reassing the next evince bug we get about installation stucked ;-)
<jjohansen> seb128: well it overlaps with a work item, but they are different
<statik> hey zul, do you mind if i merge rabbitmq-server from debian today? would you be available to review/upload the merge proposal?
<zul> statik: sure just ping me
<statik> awesome thanks
<kirkland> does anyone have a sample package that builds/installs upstarts scripts using a DEB_PYTHON_SYSTEM=pycentral stylely rules file?
<pitti> kirkland: apport does
<pitti> (the two have nothing in common, though)
<pitti> python stuff is handled by dh_pycentral, while upstart scripts are handled by dh_installinit
<kirkland> pitti: cheers
<kirkland> pitti: okay, so i just need a dh_installinit line then in the build?
<pitti> by and large, yes
<pitti> there are some caveats, like you need to specify --upstart-only if there is _also_ a debian/foo.init
<pitti> (which is likely when a package is also in Debian and we don't want to remove the init script to reduce delta)
<kirkland> pitti: got it, thanks!
<tweakt> How does Ubuntu build install CDs? I'm looking for the process used by Ubuntu devs to build official CDs.
<tweakt> As a first step, I've found and learned how to use germinate which I beleive is part of the process to determine the packages needed
<tweakt> Re: http://forum.soft32.com/linux/Ubuntu-CD-Image-Build-System-ftopict502887.html
<ArneGoetje> pitti: I can try to deal with fontconfig, yes
<tweakt> http://ubuntuforums.org/showthread.php?p=8563488
<tweakt> etc...
<tweakt> Searches turn up little to nothing :-(
<cjwatson> tweakt: 'bzr get lp:ubuntu-cdimage' and also check out the submodules in configs/devel
<cjwatson> tweakt: then start with etc/crontab and follow references from there
<cjwatson> tweakt: for live CDs, the livecd-rootfs package is also involved
<tweakt> thanks a bunch!
<tweakt> excuse my ignorance, the 'lp:' prefix is an automatic shortut for ubuntu servers, right?
<sbalneav> mvo: Hey, still no love on Bug #501559.  I dug into the code, and the non-forkpty way of doing things doesn't appear to handle stderr handling at all, and sabayon generates a lot of stderr output.
<ubottu> Launchpad bug 501559 in libgksu "libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL" [High,Confirmed] https://launchpad.net/bugs/501559
<tweakt> launchpad... n/m
<cjwatson> tweakt: it's implemented by bzr's launchpad plugin
<cjwatson> see https://code.launchpad.net/ubuntu-cdimage for the equivalent in a web browser
<sbalneav> the fix certainly works, and the BEST way to fix it would be to hack proper stderr handling into gksu for non forkpty
<tweakt> ahh, so it's debian-cd with ubuntu specific configs, excellent!
<sbalneav> however, that's going to be some fairly major code work.
<sbalneav> So, the $50 question of the day is: should we make some major changes to the code, but NOT have to have an extra --enable in rules, or do the --enable
<sbalneav> I'm not sure from a policy perspective what cordev's want.
<mvo> sbalneav: hm, the non-forkpty way is/was default in the past, I wonder why this is now becoming a problem? or is there something else that changed?
<mvo> sbalneav: ie. does this work on karmic?
<sbalneav> yeah, works fine on karmic
<stgraber> mvo: did your patch implement the same thing as the patch we used to have in karmic ?
<mvo> sbalneav: oh, in this case please reopen the bug (or open a new one) with a example, I have a look then. what we have should behave the same as in karmic
<mvo> sbalneav: sorry for that
<sbalneav> mvo: that's the laughable part.  I've spent 6 months beating sabayon into a useable state as a managment tool, going sofar as to become gnome upsteam on the project, and now at the last minute, I'm stalled by gksu :)
<sbalneav> mvo: Not your fault, but when I looked at the code from the -12 version and the new -13 verson, my first (admittedly quick) impression was that forkpty's WERE being done by default.  But I could be wrong. :(
<mvo> sbalneav: I put a bit of background into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535544 - I may misrember, its was ~6 month ago that I worked on this particular bit
<ubottu> Debian bug 535544 in libgksu "libgksu 2.0.12 & tty_tickets does not match" [Normal,Fixed]
<sbalneav> thanks, I'll look into that.
<ttx> upstart question: any reason why this job (http://pastebin.ubuntu.com/352361/) would get stopped when ssh is stopped (right) but not get restarted when ssh is respawned (wrong) ?
<ttx> i.e. I end up with a system where ssh and avahi-daemon are started, but this job isn't
<sbalneav> mvo: here's the question: is it more desirable to actually make the code change, as a patch, than enable the option?  Is this a "syncing from debian" thing?
<sbalneav> ah, I see.
 * sbalneav read 535544
<sbalneav> ok, well, if you'd like, I could dig into how to fix the stderr handling tonight.
 * soren hugs mvo for tracking down a fix for bug 494627
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress] https://launchpad.net/bugs/494627
<mvo> sbalneav: that would be nice, it should be not too hard given that it worked fine in karmic. I will try to check it out later today when i find some time and if I find something interessting I will let you know on irc
<mvo> soren: cheers! which fix do you use? the xserver-xorg-video-nv patch or one against the xserver itself?
<soren> mvo: I haven't actually tried any of them yet :)
<sbalneav> mvo: ok, will do, I'll dig into it tonight.  If you beat me to it, NP.  Start your engines
<soren> I'll take the nv one for a spin in a few minutes (in the middle of a meeting).
 * sbalneav makes vroom vroom sounds
<mvo> soren: ok :) the nv one gave me funny colors (but only after a cold reboot), I believe the second one (comment #18) is the correct one, I'm currently waiting for upstream to comment
<soren> mvo: Sounds like fun. I've installed the package, I just need to find a good time to restart X.
<ttx> slangasek: any clue for my upstart question from 30 minutes ago ?
<soren> mvo: *chuckle* Um, yeah, I see what you mean about the colours being slightly off :)
<joaopinto> mvo, any idea why does "LANG=C software-center" produces mixed translated and english strings ?
<mvo> joaopinto: no, what is your default locale
<joaopinto> pt_PT.UTF-8, my locale does show properly by default, I just wanted to check some original strings in english
<mvo> soren: I can create packages in my PPA, basicly the patch for -nv needs to be reverted and http://launchpadlibrarian.net/37478080/crash_fix.patch added to xserver-xorg-core. that works for me
<mvo> joaopinto: maybe its some oddness with webkit
<seb128> joaopinto, use LANGUAGE=C software-center
<joaopinto> seb128, same result, the menu is english, other piceses of the gui are random, english or native
<joaopinto> ConfigParser.NoSectionError: No section: 'general'
<seb128> what pieces?
<joaopinto> argh, this is not fixed yet :P ?
<joaopinto> software center crashes on exit
<soren> mvo: Don't waste time on it for me, if you're going to do things differently for Ubuntu proper. I can build those packages myself.
<joaopinto> seb128, menu is english, on the right side bar, the "Get Software" tree is english, the "Installed Software" is portuguese
<joaopinto> The "Categories" word is pt_pt, the category names are en_us
<seb128> ok, dunno then
<seb128> could be that some strings are coming from aptdaemon
<joaopinto> buttons text is pt
<seb128> and it's running on whatever local your session is
<seb128> mvo, ^
<seb128> ?
<joaopinto> yes
<slangasek> ttx: because of The Upstart Bug
<ttx> slangasek: the TUB ?
<slangasek> ttx: you would have to also restart avahi-daemon in order for upstart to see again that the second half of the condition is satisfied
<ttx> slangasek: ah. uh. eh.
<slangasek> oh, perhaps that's not The Upstart Bug; that might just be An Upstart Oddity
<joaopinto> seb128, is very unlikely that the "Get Free Software" translated text come from aptdaemon ;)
<ttx> slangasek: my issue seems to match the TUB quite well
<ttx> slangasek: i'm trying to see how I can workaround it in the less ugly way[tm]
<seb128> joaopinto, using LANGUAGE=C makes this one english there...
<ion> slangasek: It will get fixed in a future version of Upstart.
<ttx> slangasek: sounds like some combination of respawn might be the less ugly
<slangasek> ttx: I don't think there is a non-ugly way to work around that
<joaopinto> seb128, I am refering to the button on the right panel, on the left panel it does show in english
<slangasek> ion: I'm aware; AFAIK that won't happen for lucid
<seb128> joaopinto, ok, I don't know about this one
<ttx> slangasek: is the TUB a feature or an acknowledged, lucid-targeted bug ?
<seb128> joaopinto, the right panel one is translated correctly there
<seb128> using LANGUAGE=C or LANGUAGE=de_DE.UTF-8
<seb128> it's in english in first case and german in the second one
<cwillu_at_work> slangasek, (ttx) would "(started ssh or started avahi-daemon) or (started avahi-daemon or started ssh)" work? :p
<joaopinto> seb128, it does show properly now, I am sure it didn't, there must be caching involved somehow
<joaopinto> well, I can't reproduce it's fixed :P
<seb128> good ;-)
<slangasek> ttx: it's neither
<slangasek> cwillu_at_work: it would "work", but you've turned an AND into an OR
<joaopinto> hum, is there a manpage describing LANG vs LANGUAGE ?
<ttx> slangasek: it's a bug that is not fixable in lucid ?
<slangasek> ttx: correct
<ttx> hm.
<cjwatson> joaopinto: locale(7)
<kees> seb128: the parser being slow for evince loading is known, but it only happens when the profile isn't already cached (i.e. new kernel).  On new installs, this is supposed to be fixed in the installer (i.e. generate the cache during install instead of first-boot)
<kees> seb128: though I saw "ages" being 4 seconds, Keybuk saw it take _27_ once, which I haven't reproduced.
<seb128> kees, could be, I noticed it on daily upgrade
<seb128> it takes over a minute there
<kees> was a kernel upgrade involved?
<seb128> I guess so
<kees> seb128: lucid or karmic?
<seb128> lucid
<kees> well, >5 seconds is very odd, and I would considered a bug and regression.  that said, it should be loading in parallel with everything else.
<joaopinto> man locale mentions LANGUAGE, man setlocale only mentions LANG
<seb128> kees, it's over 30 seconds for sure
<seb128> the box being a mini10v
<seb128> cpu sucks there
<seb128> top showed that the apparmor_parser was using 100% cpu
<cjwatson> joaopinto: that's correct
<kees> that's really odd for it to run so long.  can you tar up your /etc/apparmor.d directory for me and open a bug for it?
<cjwatson> LANGUAGE is basically a weird override for LC_MESSAGES, in practice
<seb128> kees, ok, any way to trigger the same command manually to see how long it takes?
<cjwatson> 'info gettext' has more detail
<kees> I will try again to reproduce it on my super-slow laptop.
<cjwatson> actually I think LANGUAGE might be an override for everything, beyond LC_ALL
<kees> seb128: yeah, "sudo service apparmor reload" should be a "worst case".
<cjwatson> but LANGUAGE has a different syntax
<cjwatson> the point of LANGUAGE is that it can be colon-separated
<joaopinto> from the manpage it looks to override only LC_MESSAGES
<cjwatson> I suspect info gettext is more correct
<joaopinto> ok, next time I will use: LANG=C LANGUAGE=C :)
<cjwatson> LC_ALL=C LANGUAGE= is what I usually use if I want to hit things over the head
<joaopinto> it is odd that LANG does not override LC_MESSAGES in specific cases
<cjwatson> joaopinto: LANG is explicitly lowest-priority
<seb128> kees, that command is supposed to take ages or in the a few second magnitude you mentioned before too?
<kees> seb128: so, with a lot of non-default profiles, etc, my system takes 15s on a reload.  A default karmic should take maybe 5s
<seb128> kees, the mini10v is stock lucid
<seb128> that's the box I use for bootcharting
<kees> right.  how long did it take?
<seb128> still running...
<kees> !!
<kees> please send /etc/apparmor.d when it finishes...
<seb128> ok
<seb128> but it's stock lucid installed for an usb key
<seb128> I don't touch the box out of bootcharting
<seb128> for -> from rather
<slangasek> ahhhhh
<seb128> still running...
<slangasek> what just ate my color pallette for half my gnome terminals in a lucid upgrade?
<seb128> oh
<seb128> 176 seconds
<kees> *gape*
<seb128> kees, ^
<Zorry> doko__: ping
<kees> kees: let me know when you've got the bug open, and I'll download the apparmor.d tarball.  that's pretty insane.
<jdstrand> 176 seconds
<seb128> kees, talking to yourself?
<highvoltage> sekunde
<jdstrand> that has got to be some sort of record
<jdstrand> seb128: you win!
<seb128> what do I win? ;-)
<jdstrand> seb128: a slow boot process?
<kees> seb128: yeah, I hate that kind of typo.  ;)
<seb128> kees, http://people.canonical.com/~seb128/apparmor.d.tar.gz
<seb128> jdstrand, boot is fast, upgrade is slow
<kees> seb128: thx
<jdstrand> ah
<seb128> jdstrand, this box boot in 16 seconds
<seb128> grub to desktop loaded
<jdstrand> sweet
<kees> seb128: can you examine your dpkg log and find out what was upgraded that triggered it to throw away the cache?
<seb128> kees, how can I figure that from the dpkg.log?
<seb128> it only show what got upgraded
<seb128> which on daily lucid is a lot
<kees> seb128: well, really I want to answer the question "what was upgraded between the time you booted quickly and the first boot of the parser being slow?" :P
<seb128> it's not boot being slow
<seb128> it's the upgrade
<seb128> synaptic sitting on "configuring evince" for 3 minutes
<kees> Oh!
<doko__> Zorry: contentless pong (just write what you want)
<seb128> users do ctrl-C their upgrade thinking it's stucked
<kees> seb128: okay.  that makes more sense.  (not the 3 minutes, but the issue)
<seb128> and we get apport bugs
<seb128> did I say boot when I'm pinged? I'm sorry
<seb128> it's an evince postinst issue
<kees> no, I thought you meant system upgrade, not evince upgrade.  :)
<seb128> I do
<seb128> daily update-manager dist-upgrade
<seb128> evince was in the batch
<seb128> do you want a bug with the tarball still?
<kees> right.  I thought it was getting stuck at boot time after an upgrade (which was an earlier complaint)
<Zorry> doko__: can you test this patch on binutils-2.20 http://pax.grsecurity.net/binutils-2.19-pt-pax-flags-200811041810.patch  for me ld segfault
<kees> seb128: yes, please.  I can't reproduce it yet, but it's clearly an issue.
<Zorry> doko__: http://pastebin.com/d2b0e1a77
<doko__> Zorry: well, it's not applied in the ubuntu package, isn't it?
<kees> seb128: how much memory does the mini10v have?
<Zorry> doko__: is not
<seb128> kees, 1G
<seb128> kees, i've 639M free right now
<seb128> +1.6G of swap
<kees> seb128: okay, thanks.
<Zorry> doko__: only adding unsigned int pax_flags; make ld segfault
<Zorry> doko__: just working on proof-of-concept with PaX and PIE
<doko__> Zorry: sorry didn't test this combination, and don't plan to. maybe ask kees aboutit?
<Zorry> doko__: okey np kees did't have the time
<jjohansen> seb128: want to run an apparmor test for me on your mini10v
<kees> Zorry: why do you need PaX, btw?
<seb128> jjohansen, sure
<Zorry> kees: full support for pax kernels
<apw> cjwatson, would i be right in assuming the installer knows when to invoke compcache ?  and can you point me at which of those bits do that?
<jjohansen> seb128: as root can you do  time apparmor_parser -S /etc/apparmor.d/usr.bin.evince >foo
<zul> doko_: when you get a chance can you review python-pastescript and ptyhon-pastedeploy
<seb128> jjohansen, ok
<jjohansen> seb128: then apparmor_parser -Br foo
<seb128> kees, jjohansen: bug #503869
<ubottu> Launchpad bug 503869 in apparmor "reload takes ages in lucid" [Undecided,New] https://launchpad.net/bugs/503869
<jjohansen> seb128: ah thanks
<jjohansen> seb128: make that     time apparmor_parser -Br foo
<seb128> jjohansen, the first command exit immediatly with a 234 error
<geser> I've seen this on my dell mini10v too (upgrading evince took "ages")
<kees> seb128: try it again with -T -S
<kees> (I will fix -S to imply -T)
<seb128> running
<seb128> takes ages
<cjwatson> apw: not really the installer, it's the live CD boot process
<cjwatson> apw: it's hooked up in casper
<apw> i wanted to confirm how it invokes it, so apt-get source casper is my firend?
<jjohansen> hrmm we should turn off caching when -S is used
<kees> seb128: we're trying to verify that it's a userspace issue (parsing) not a kernel issue (loading)
<kees> jjohansen: yup, already on it.
<seb128> still running...
<smoser> cjwatson, Keybuk is out?
<cjwatson> apw: casper/conf.d/compcache, and /usr/share/initramfs-tools/hooks/compcache in initramfs-tools (you'll already have this installed)
<cjwatson> smoser: don't know, sorry
<apw> cjwatson, thanks ... thats what i needed to know.  it copes with both compcache and ramzswap as the module name
<smoser> anyone? i'm hoping for a some info about bug 503212 .
<ubottu> Launchpad bug 503212 in mountall "mountall crashed with SIGSEGV in main() without initramfs" [High,New] https://launchpad.net/bugs/503212
<smoser> if its not going to be fixed by alpha2, then i need to turn on ramdisks in our ec2 images.
<seb128> jjohansen, kees: done
<apw> smoser, you can be sure its has not been tested without innitramfs
<seb128> I forgot to re-add the >log when fixing the syntax
<seb128> but it was around 3 minutes
<smoser> apw, i know it *is* tested. i tested it :)
<smoser> it doesn't work
<seb128> I'm running it again now
<apw> smoser, indeed so ... i'd wonder if its not yet fully converted to the new devtmpfs thingy
<kees> seb128: ok, so it's seems that -T -S takes 3 minutes, and the -Br takes very little?
<seb128> -Br exit immediatly on signal 9
<seb128> "time apparmor_parser -Br foo"
<seb128> is that >foo
<kees> the -S is writing out the binary profile to "foo", and -Br foo is loading it into the kernel.
<jjohansen> ah, no you really want foo, you are loading the compiled profile generated in the -S command
<seb128> oh ok sorry
<seb128> one minute it's running again now
<ion> smoser: I think i see the problem. Iâll fix it.
<seb128> kees, jjohansen: -T -S = 170s
<seb128> kees, jjohansen: -Br = 0.06s
<jjohansen> seb128: thanks, what are the configs on that machine of yours?
<jjohansen> ie. ssd, hd, memory
<smoser> ion, that would rock, thank you.
<seb128> jjohansen, it's a mini10v with 1G of ram, it's an atom cpu, quite slow
<seb128> jjohansen, ssd disk
<seb128> jjohansen, io is very fast, there is plenty of ram and swap but cpu sucks
<jjohansen> seb128: right, new the atom part just wondering the other parts of the config that can very
<jjohansen> seb128: can you run top while doing the -S command and see what kind of memory/swap its hitting
<seb128> time said that 100%cpu was used during those 170 seconds for the -T -S command
<seb128> apparmor_parser is 100%cpu all the time
<seb128> memory usage is low
<seb128> 602meg free + 1.6gig swap, not changing there
<jjohansen> seb128: okay thanks
<seb128> not moving, whatever apparmor_parser does it eats all cpu for 170 seconds
<seb128> jjohansen, you're welcome
<jjohansen> seb128: I know what the problem is, we'll see if I can't fix it at least partially for alpha2
<seb128> ok thanks
<seb128> should I comment on the bug to add details or will you do that?
<jjohansen> if you can add the results of your testing that would be great
<seb128> jjohansen, done
<seb128> jjohansen, bug #503869
<ubottu> Launchpad bug 503869 in apparmor "reload takes ages in lucid" [Undecided,New] https://launchpad.net/bugs/503869
<seb128> let me know if you need extra details
<seb128> kees, ^
<jjohansen> seb128: will do, thanks
<seb128> thank you
<ion> It seems bug #458299 may have reappeared.
<ubottu> Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Fix released] https://launchpad.net/bugs/458299
<statik> hi zul, Just following up from earlier: I reviewed the rabbitmq-server merge and the ubuntu changes are already upstream, so it should be a sync instead. I filed a sync request here https://bugs.edge.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/503875
<ubottu> Ubuntu bug 503875 in rabbitmq-server "Sync rabbitmq-server 1.7.0-3 (main) from Debian testing (main)" [Wishlist,New]
<zul> statik: sounds good to me
<davmor2> asac: when FF opens in live desktop you are getting the pop up about add-ons again like in karmic
<kees> seb128: so, while jjohansen digs further, do you think if I added a "Reloading evince AppArmor profile (this can take a long time) ..." message to the postinst it would be better?
<kees> well, s/better/more understandable and people wouldn't report as many bugs/
<seb128> kees, don't bother, it's lucid and and people tend to use update-manager which doesn't display the command line by default
<seb128> kees, just make it better before lucid turn stable ;-)
<kees> seb128: that's what jjohansen is up to.  sounds like it's hitting what the atom is really bad at, though.  :(
<jdong> *sigh* atom :-/
<jdong> really hit-or-miss performance wise
<geser> kees, jjohansen: as I see this problem on my netbook too, does it help when I attach a strace log (with timestamps) to the bug?
<jjohansen> geser: in this case it won't help much, the computational part makes very few syscalls
<nixternal> wtf is going on with -devel ml?
<geser> -devel or -devel-discuss?
<nixternal> one of them, they both go to the same place for me
<cr3> is there a way to configure xorg to not prompt when asking to fall back to safe mode?
<tweakt> I'm trying to use ubuntu-cdimage, getting an error about lockfile not found (I've made all the expected directories so far)
<tweakt> ahh, nevermind. not a missing lockfile, but missing the program 'lockfile
<kees> so, if I leave evince running, gnome-screensaver crashes.  :)
<chrisccoulson> kees - more gnome-screensaver crashes? :(
<kees> chrisccoulson: yup.  100% reproducible too
<chrisccoulson> kees - have you managed to debug it at all?
<kees> chrisccoulson: just made it crash with --sync now, sending apport crash in a moment, one sec
<chrisccoulson> cool, thanks. so it's another X error related crash is it?
<kees> chrisccoulson: evince & sleep 1; gnome-screensaver-command -a  boom.
<chrisccoulson> kees - i can't make it crash here. this is on lucid isn't it?
<kees> chrisccoulson: yup
<kees> chrisccoulson: oh, evince not needed.  lucid's g-ss just crashes immediately on activation.  :P
<chrisccoulson> that's very strange :-/
<kees> indeed.
<kees> chrisccoulson: what is responsible for spawning g-ss originally, and can it respawn it?
<kees> chrisccoulson: LP: #503961
 * kees stares at ubottu
<kees> bug 503961
<ubottu> Launchpad bug 503961 in gnome-screensaver "gnome-screensaver crashed with signal 5 in _XError()" [Undecided,New] https://launchpad.net/bugs/503961
<chrisccoulson> kees - gnome-session spawns it. i was thinking about adding proper session integration in gnome-screensaver, so that it can get respawned (and locked) in the event of it crashing
<kees> chrisccoulson: that would be very nice.  :)
<chrisccoulson> i don't know if upstream would accept a patch for it
<chrisccoulson> and then, if it keeps crashing, it could just nuke the session (i'm not sure if that's an acceptable fallback in extreme situations)
<chrisccoulson> i'll have a look at that bug once the retracer has done it's magic anyway
<chrisccoulson> thanks
<ccheney> how do i make preformatted text on wiki.u.c ?
<ccheney> or should i just put things into a list to force it to look preformatted
<kees> chrisccoulson: nuking the session is probably worse.  i.e. minor risk of physical security compromise vs 100% certainty of data loss
<james_w> ccheney: {{{ <multiline text> }}}
<ccheney> james_w: thanks
<mdz> does anyone know how to check that a gpg key generated via http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ does in fact use SHA256?
<DktrKranz> mdz: I "manually" checked signing a little file
<DktrKranz> at the top, you'll see HASH: SHA256
<DktrKranz> or SHA1, if things went wrong
<seb128_> jjohansen, kees: the apparmor_parser -S -T run takes 65 seconds on my laptop dell 630 config
<kirkland> okay, i think it's time to block "patrick freundt" as an abusive user to ubuntu-devel-discuss
<kirkland> robbiew: do you have admin privs on that list?
<seb128_> jjohansen, kees: not really specific to the atom, that box has a T7700 duo cpu
<seb128_> ie 2.4Ghz
<highvoltage> kirkland: yes please :(
<seb128_> jjohansen, kees: weird that you guys don't get slow run on your boxes
<robbiew> kirkland: I don't, sorry
<seb128_> jjohansen, kees: do you have a special "be fast" flag you use? ;-)
 * kirkland checks who does ...
<kirkland> robbiew: list owned by evand
<highvoltage> kirkland: evand does according to https://lists.ubuntu.com/mailman/listinfo/Ubuntu-devel-discuss
<kirkland> robbiew: who appears to be out ...
<kirkland> robbiew: i'll check with elmo
<jjohansen> seb128_: nope
<kirkland> elmo: anyone else besides evand have admin privs on ubuntu-devel-discuss@ ML ?
<jjohansen> seb128_: once the profile is generated the 1st time it should pull it from the cache
<jjohansen> so it should be fast then
<elmo> kirkland: no
<seb128_> jjohansen, that doesn't seem to work
<seb128_> jjohansen, running the command again doesn't make it faster
<jjohansen> seb128: are you using the -T flag?
<seb128> yes
<seb128> sudo time apparmor_parser -S -T /etc/apparmor.d/usr.bin.evince > log
<seb128> I'm testing with that
<jjohansen> ah, drop the -T flag
<jjohansen> it means skip cache
<seb128> it exits with status 234
<seb128> when I don't use -T
<jjohansen> oh right that is because the is a bug, with -S atm
<jjohansen> try apparmor_parser -r apparmor.d/usr.bin.evince
<seb128> ok that's fast
<seb128> thanks
<jjohansen> erc /etc/apparmor.d/usr.bin.evince
<seb128> I will stop bothering you about that now
<seb128> I was just testing on my laptop to see the difference
<jjohansen> that is actually loading the profile from cache
<seb128> it's 65 seconds on full cpu use there
<seb128> which seems still a lot of a duo 2.4Ghz
<seb128> of -> for
<jjohansen> 65s for loading?
<seb128> centrino that's it
<sebner> seb128: wondering, here it took 20% on the first cpu and 100% on the second one. Around 1-2 minutes
<seb128> "sudo time apparmor_parser -S -T /etc/apparmor.d/usr.bin.evince > log"
<seb128> jjohansen, I noticed because update-manager sit on "updating evince" for over a minute again
<jjohansen> oh, okay that is recompiling the policy
<jjohansen> but it should not take that long on a duo
<jjohansen> eg my laptop takes about 12s
<seb128> on lucid?
<seb128> I never has the issue on karmic
<seb128> had
<jjohansen> yes on lucid
<seb128> ok so I don't know why I've the issue on my boxes and not you
<jjohansen> well actually on karmic but in a lucid vm
<jjohansen> it is strange
<jjohansen> where they clean installs or updates
<seb128> updates
<seb128> I update those boxes daily
<seb128> the mini is a test box for bootcharting
<seb128> and the laptop is my work config
<jjohansen> would you be able to try a clean install to a usb stick
<seb128> yes
<seb128> I will do that tomorrow though
<sbeattie> seb128: are you running amd64 or i386 on your duo?
<seb128> i386
<kees> ah, that's a difference, I'm running amd64...
<kees> but still, on my duo it takes 8 seconds.
<seb128> well my laptop is not that new
<seb128> it's 2 years old now
<seb128> but it's a duo centrino 2.4G
<seb128> which is usually decent enough...
<sbeattie> I think it's something specifically with the i386 toolchain in lucid.
<seb128> you noticed the issue too?
<jjohansen> mine is core2duo at 1.6G so yours should be fine
<jjohansen> though I was using 64bit lucid vm to test
<sbeattie> seb128: Yeah, I just reproduced on lucid/i386 with an atom.
<sbeattie> 169.14user 0.25system 2:50.08elapsed 99PU
<jjohansen> I have a native 32 bit install on a now atom machine (older original core cpu) I'll try testing there
<jjohansen> s/now/none
<TheMuso> kirkland: Thanks for the heads up, I just skip his mails now. :)
<kirkland> TheMuso: ;-)
<jjohansen> seb128, sbeattie: replicated: on a 1.73 GHz core cpu, 32 bit lucid install 114.429s real, 106.367s user
<jjohansen> something is really broken on the 32 bit tool chain
<jjohansen> kees: ^
<kees> yiiikes
<sbeattie> jjohansen: no, something in lucid's evince profile's includes is triggering bad behavior, but it only shows up on i386. using karmic's parser booted in karmic against lucid's apparmor.d results in similar times, whereas it's almost an order of magnitude faster on karmic's evince profile.
<jjohansen> hrmm
<jjohansen> okay, I will continue to poke
<sbeattie> jjohansen: i.e. ' sudo time apparmor_parser -I /mnt/etc/apparmor.d/ -S -T /mnt/etc/apparmor.d/usr.bin.evince' where /mnt is my fresh lucid installation results in an elapsed time of 2:54.45
<jjohansen> ugh, but only on i386
<sbeattie> yeah
<mdz> DktrKranz, thanks
<douglasawh-work> how difficult would it be to put full disk encryption on the live CD?  I can't image that taking up a lot of space, as the launchpad download is just 501.7 KB
<douglasawh-work> but maybe I'm missing something
<joaopinto> douglasawh-work, that has been brainstormed http://brainstorm.ubuntu.com/idea/14574/, however it was incorrectly set to duplicate :\
<douglasawh-work> joaopinto: thanks for pointing that out to me!
<cjwatson> douglasawh-work: the problem isn't space, it's making it be supported by the live CD partitioner which involves some genuine actual hard code
<cjwatson> douglasawh-work: we may make some progress towards that this cycle but LVM and RAID are higher priority for the moment
<cjwatson> however fortunately those involve solving most of the same problems
<douglasawh-work> cjwatson: thanks for the info. One additional related question which I've not researched.  the switch from grub1 to grub2 made using dd for full disk encryption impossible (at least not without re-installing grub).  How easy is it to install grub1 in Lucid and/or is that problem with grub2 fixed?
<cjwatson> douglasawh-work: I'm not sure I understand the problem. Can you describe what's failing with grub2 in more detail? Is there a bug report or something?
<joaopinto> argh, I am unable to boot without removing splash now :\
<joaopinto> I don't remember getting any updates related to boot recently
<kees> gah, hitting mystery when building.
<kees> dpkg-source: error: gunzip gave error exit status 1
<douglasawh-work> cjwatson: no bug report. The problem is that grub can't see the encrypted partition for some reason when dd is used. works fine in Jaunty.  We were (kinda still are) under a bit of a time crunch to figure it out (time crunch is now to deploy)
<cjwatson> douglasawh-work: so firstly, it's still straightforward to install grub legacy in karmic/lucid
<cjwatson> but I'd like to figure this out anyway
<cjwatson> "when dd is used" - could you elaborate? dd is a pretty generic tool :-)
<cjwatson> I wouldn't have expected grub, either legacy or 2, to be able to see encrypted partitions in general
<cjwatson> neither of them contains decryption code, to my knowledge
<cjwatson> so I think I'd need to understand how you're setting things up
<douglasawh-work> cjwatson: well, it works with Jaunty and Fedora, just using the default. I'll did out the exact dd command I'm using here in just a second
<tweakt> what's the easiest way to include a custom preseed file when using the ubuntu-cdimage build process?
<tweakt> I see them in debian-cd, I also need to customize the boot menu to use it
<douglasawh-work> cjwatson: other than grub-common looking like it's still 1.97, the uninstall/re-install seemed to be super-easy. now I've got to test on an encrypted disk...I didn't have the new dd stuff documented where I usually do (like I said, we had a pretty tight deadline), but I'm pretty sure I know where it's at
<douglasawh-work> to pull down - dd if=/dev/sda | ssh username@backupserver.fqdn "dd of=/directory_of_backups_on_ssh_server/backupfile.iso"
<kirkland> slangasek: what does it mean if "status libvirt" returns a pid that's close, but not exactly the libvirtd process that I want?  I suspect it's due to forking
<slangasek> kirkland: probably means the job declaration is wrong for the service in question.  Is the pid a process that's running, or one that's extinct?
<kirkland> slangasek: status points to a dead process
<kirkland> slangasek: i see "expect fork" in a bunch of these upstart scripts
#ubuntu-devel 2010-01-07
<cjwatson> kirkland: probably means that the script does some other things in shell before forking the main process, and upstart follows the first fork
<cjwatson> even 'if [ ... ]' can cause that
<ion> Yeah, itâs very easy to break current Upstartâs fork following code. 0.10 will fix that issue.
<kirkland> cjwatson: http://pastebin.ubuntu.com/352593/
<kirkland> cjwatson: modeled off of ssh.conf
<cjwatson> well, that looks ok, maybe libvirt forks twice?
<cjwatson> libvirtd that is
<kirkland> cjwatson: must be
<cjwatson> if so, 'expect daemon'
 * slangasek nods
<kirkland> cjwatson: would that be causing my problems stopping the job?
<slangasek> certainly
<cjwatson> yes, there's a bug where you can completely bugger upstart to the point where you have to reboot
<kirkland> fwiw, libvirtd does write its own pid file
<slangasek> upstart doesn't have any secret ways to stop jobs, it uses the same PID information that it reports to you with 'status' :)
<cjwatson> I don't believe upstart cares about pid files
<slangasek> indeed not
<cjwatson> indeed the general philosophy of upstart is that pid files are obsolete
<kirkland> slangasek: okey doke
<ion> cjwatson: How *does* one get Upstart to a state you need a reboot to fix? :-)
<douglasawh-work> cjwatson: this is the pull command: ssh target_address dd if=remotefile | dd of=localfile
<kirkland> slangasek: cjwatson: \o/
<cjwatson> ion: I forget, but I did it while writing ssh.conf and Keybuk said "oh, yeah, known bug"
<kirkland> "expect daemon" worked like a champ
<cjwatson> douglasawh-work: well, grub2 doesn't store anything anywhere magic, it just puts it on the disk with everything else ...
<kirkland> cjwatson: so your comment in ssh.conf, about editing the exec line, rather than /etc/default/* ... i mimic'd that.... is that correct, or lazy?
<cjwatson> douglasawh-work: I don't understand how your *encryption* is laid out, though. when you get time, could you please file a bug with full details of what you're trying to make work?
<cjwatson> kirkland: it's following strong preference from Keybuk
<douglasawh-work> cjwatson: yeah, that's what I thought, but it doesn't work.  I'm just using the alternate cd full disk encryption
<cjwatson> kirkland: besides, after starting to use upstart's oom feature, there really wasn't that much left in /etc/default/ssh
<kirkland> cjwatson: yeah, there's nothing of value (except for "-d" == deamonize") in /etc/default/libvirt-bin
<kirkland> cjwatson: i'm on board ;-)
<cjwatson> douglasawh-work: (I'm partly asking for a bug because unfortunately I don't really have time to look into this right now)
<douglasawh-work> cjwatson: I'll file a bug. I just mainly wanted to make sure it wasn't already fixed in lucid before submitting
<cjwatson> douglasawh-work: not to my knowledge, but then I didn't know it was broken :)
<cjwatson> so it's always possible I missed something
<kirkland> cjwatson: slangasek: what do I need to do to get the server ISO build cronjob changed?  File an RT?
<cjwatson> ion: bug 406397
<ubottu> Launchpad bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Low,Triaged] https://launchpad.net/bugs/406397
<cjwatson> kirkland: RT is no use at all
<cjwatson> (for this!)
<kirkland> cjwatson: heh
<cjwatson> kirkland: if you want to file a bug, file it on the ubuntu-cdimage project, but it's probably quicker to just ask somebody in the ubuntu-cdimage team ...
<kirkland> cjwatson: send you chocolate, then?
<slangasek> kirkland: close your eyes, click your heels three times, and 'bzr update' to reveal that it's already been done
<kirkland> slangasek: ah, send slangasek chocolate :-)
<slangasek> assuming you mean 'run ubuntu-server earlier' :)
<kirkland> slangasek: yeah, thanks
<ion> cjwatson: Ah, that. I managed to get out of it without needing a reboot (as a reboot would have been inconvenient with users on the box in question). :-)
<Shiran> hi anyone know how can i get involved with ubuntu developmenting?
<cjwatson> Shiran: http://wiki.ubuntu.com/ContributeToUbuntu, http://wiki.ubuntu.com/UbuntuDevelopment
<Shiran> yea yea i don't get it
<Shiran> i registered myself in launchpad
<Shiran> and i dont get how to find stuff to work on in there
<cjwatson> Shiran: you won't find that an effective way to get started, no. It's much more effective to find something that you actually want to work on (e.g. a bug that's annoying you personally) and work on that
<cjwatson> Launchpad has *everything*, it's a bit like wandering into a field and looking for an interesting blade of grass
<cjwatson> you can try https://bugs.launchpad.net/ubuntu but it will still be overload :)
<Shiran> i wanna get involved with programming
<Shiran> isn't there a way to find teams that work on stuff that need more people?
<cjwatson> it is much more effective to decide what you want to work on and then look for a relevant team
<cjwatson> "programming" is a bit too vague for this purpose, try to narrow it down :)
<Shiran> how can i narrow it down?
<cjwatson> based on your interests
<Shiran> my interest is writing code
<cjwatson> yes, try to be a bit more specific :)
<Shiran> im not sure i can :P
<Shiran> c++
<Shiran> is that more specific?
<cjwatson> not really, but it may help you to find (for example) some programs already installed on your system that are written in that language that you might like to help with
<cjwatson> distributions, by their nature, are rather more involved in integrating existing code from elsewhere than they are in writing lots of new code, although of course some of the latter does happen
<cjwatson> so if you want to work in the context of a distribution, you're generally talking about either maintaining existing code (bug-fixes, feature enhancements, etc.) or finding one of the areas where the distribution is trying to distinguish itself
<Shiran> isn't there a way to find teams of programmers?
<Shiran> say i wanna work on KDE
<cjwatson> http://wiki.ubuntu.com/Teams
<Riddell> Shiran: Kubuntu developers are in #kubuntu-devel, we do occational bits of c++ but mostly its working with upstream KDE code.  KDE developers are in #kde-devel
<ikthus> hi :)
<douglasawh-work> cjwatson: installed grub1 and the problem is resolved, so thanks for that suggestion.  At some point I'll test whether the problem exists in Lucid at all...I just know it's a problem in karmic. after I test that, I'll file a bug
<lunatic> hey could anyone help a newbie apply a patch? http://www.mail-archive.com/hydrogen-devel@lists.sourceforge.net/msg00083.html this one particularly
<lunatic> <lunatic> i eed it for the hydrogen source code to compile
<alkisg> TheMuso: Hi, Ubuntu doesn't work with libsdl1.2debian-alsa, but it does work with the pulseaudio variants. The same is true for LTSP (thin clients). Could we make it so that either libsdl1.2debian-pulseaudio or libsdl1.2debian-all are installed when an Ubuntu user installs an SDL-using app?
<alkisg> For libsdl1.2debian-all to work with pulse, SDL_AUDIODRIVER=pulse needs to be in the environment, but than can be taken care of by e.g. LTSP.
<persia> alkisg: The simple way to do that is to just adjust the relative dependencies of apps.  My memory is that we spent a lot of time changing to use -alsa some time back, and those changes can probably be reverted.
<alkisg> persia: then those apps wouldn't work in kubuntu...
<alkisg> (and also, they're 387 on them using sdl in my current installation)
<persia> I thought the phonon pulse backend was first-class now.
<persia> Is the vlc backend still default?
<alkisg> I don't use Kubuntu or Xubuntu, but I was told that those still need -alsa
<persia> I haven't looked at it for lucid, but I believe the blocker for Xubuntu was xfce4-mixer running into bugs with gstreamer0.10-pulseaudio, which I thought were fixed.
<persia> For Kubuntu, the issue is all about having a fully-featured pulse backend for phonon so that users don't end up without sound.  I don't know the status on that.
<alkisg> OK, so the plan is to switch all derivatives to using pulseaudio? That's fine, but why then do we have libsdl1.2debian depend on libsdl1.2debian-alsa first? Shouldn't we switch that to -pulseaudio?
<persia> But I don't know of any way (other than including in the default install) of preferring alternate libsdl implementations based on flavour, especially for people who use subsets of flavours.
<persia> My personal opinion is that everything should use pulse, and we should make that switch.  I don't imply that this is an official plan.
<persia> It's just the easiest way to get out of the mess.
<alkisg> persia: the packaging problem can be solved with libsdl1.2debian-all, as this contains support for all backends
<persia> I know there was discussion about it at UDS Karmic, but I don't remember follow-up discussion at UDS Lucid.
<persia> alkisg: Well, except that then each flavour has to somehow handle setting SDL_AUDIODRIVER in some way.
<persia> Unless you want to change libsdl1.2debian-all to be smart enough to use pulse if it is available and fall back to alsa if it isn't.
<alkisg> Right
<alkisg> I think that's the best plan, it would work out of the box in all cases, and it would still enable some extreme user to select his own output
<persia> Right.
<alkisg> ...and it's already in main, while libsdl1.2debian-pulseaudio isn't.
<persia> Well, I think that if we're going to default to pulse if it's available, it's worth putting together an MIR for libsdl1.2debian-pulseaudio.
<persia> Actually, looking at it, it doesn't even need an MIR.  It just needs to get pulled with a dependency.  The source is already in main.
<alkisg> I was going to write one, but I don't think that's needed, -all is still the best plan even if we want the default output to pulse, as it enables users to select their own output
<persia> Well, except we need -all to recommend -pulseaudio if we want the default to be pulse
<alkisg> No - it conflicts with -pulseaudio
<persia> Ah, and it already includes the pulse bits.
<alkisg> Right
 * persia hasn't actually looked at libSDL for far too long
 * alkisg is a teacher and unfortunately he gets complains for all sdl-based edu* apps :(
<persia> Well, that's a good thing.  Helps highlight the issue.
<persia> Of course, it quickly becomes a bad thing if we can't fix it.
<alkisg> Also, crimsun has said that -alsa with be patched to work even when pulseaudio is installed (I don't know the details). In that case, all workstation users will be satisfied, as SDL apps will work out of the box. But LTSP users wouldn't be satisfied because they'd require pulseaudio output as the sound goes through the network. In that case, LTSP could set SDL_AUDIODRIVER=pulse, and everyone is satisfied again.
<persia> Well, except it's a bit of a hack doing it that way.
<persia> Yes, ALSA can route clients into pulse which then routes back into ALSA which then routes to ears.
<persia> But it'd be cleaner if the apps talked to pulse directly.
<alkisg> Right, the correct way would be for Ubuntu to use libsdl1.2debian-all, and for -all to use pulse if it's available, else fall back to alsa.
<alkisg> So, 2 things need to be done: a small change in libsdl1.2debian dependencies, and a code fix in -all.
<persia> Well, that's the least invasive way to do it.  I still think everything should use pulse :)
<alkisg> In that case, libsdl1.2debian should me modified to depend on -pulseaudio first. But we proposed that already, and it looked like it wasn't going to happen (because of K|Xubuntu), at least in the Lucid time frame...
<alkisg> https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/203158
<persia> Right, but that requires testing/changes to phonon and xfce4-mixer
<persia> If that work is done, then the bug can proceed.
<persia> The detection code in libsdl1.2debian-all is just a workaround
<alkisg> There were also complains from people not wanting to use pulseaudio at all... wouldn't libsdl1.2debian-all give them a way to do that?
<persia> Well, yeah, but most of those complaints come from people who ran into bugs and blame pulse (even when pulse wasn't the cause)
<persia> Mind you, I have a number of use cases where I *really* don't want pulse, but in those cases, I'm not using SDL audio anyway.
<alkisg> I'm a pulseaudio fan myself, as I use LTSP a lot, but "preferring" pulse instead of "forcing" it seems better imo...
<persia> I guess I see both as expressions of preference, but I agree forcing is wrong.
<alkisg> Anyway, both of them would solve my problem. So I'll stop nagging people and wait for K|Xubuntu to be fixed so they are able to use pulseaudio before I start nagging again :D
<alkisg> Thanks a lot persia for your time & advice :)
<persia> alkisg: Well, if you're up for trying to do autodetection, that gives us a nice workaround.
<persia> Alternately, if you're up for testing the xfce4-mixer pulse interaction, that should be in good shape, and strong feedback that it is (or bugs that the devs can fix) would probably sway Xubuntu.
<persia> I know that upstream xfce4-mixer devs would like it to work properly, but don't have many user reports.
<persia> I'm less knowledgeable about the situation with phonon: I think that is still a bit of a mess, because there's just so much needed to make a working backend.
<persia> But I'd be glad to be wrong about that.
<mneptok> ISP has been up and down all day. Reddit is down. just ate the last Kasugai gummy. life bites.
<alkisg> I could give the autodetection thing a try. But for xfce4-mixer testing, as I never use Xubuntu, I wouldn't like to go ahead and report that "it works OK when ran from the live cd"... :)
<dholbach> good morning
<alkisg> Ah, a last argument for -all just came to me, that it would enable users with different needs to use different outputs even *on the same pc*
<alkisg> (e.g. on a multiuser workstation or on some kind of a server where they don't have administrative rights)
<alkisg> So user A logs on and wants pulse => OK, user b logs on and wants alsa => he just sets an environment variable.
<persia> Well, OK, but let's analyse that.  esound and arts are deprecated.  pulse supplies many of the core nas features.  alsa was breaking stuff, and the latest OSS drivers aren't shipped by default.
<ScottK> arts isn't just deprecated.  It's dead.
<ScottK> We've removed it from the archive and upstream has closed the bug tracker.
<persia> ScottK: I thought there was still support for KDE3 for some time (maintenance mode)
<persia> Ah, then it's very dead.
<ScottK> persia: There is, but not with arts.
<persia> ScottK: Do you happen to know the current state of phonon & pulse?
<ScottK> There were patches done to integrate them somewhat in KDE 4.4.  We have them in Lucid.
<ScottK> I don't know the details.
<persia> So it's just a matter of testing at this point, or should be?
<ScottK> Should be.
<ScottK> Kmix needs some work too and that's not complete.
<ScottK> There is currently some back and forth about breaking feature freeze to squeeze that in.
<ScottK> Mandriva (where the work is being done) will ship it as a distro patch if it doesn't go upstream for 4.4.
<ScottK> We didn't consider it yet.
<ScottK> Regardless, Kubuntu will not ship pulse in Lucid.
<persia> That's colin guthrie's work?
<ScottK> I don't recall.
<ScottK> persia: Yes.
<alkisg> ScottK: Kubuntu will work fine with libsdl1.2debian-all with no modifications, right?
<ScottK> Current state of play: http://colin.guthr.ie/2010/01/mix-it-up/
<alkisg> *would
<ScottK> alkisg: I don't know.
<ScottK> It's also 2:30 AM here, so anything I pretend to know, unless i give references, be skeptical.
<alkisg> So, if Kubuntu won't ship pulse in Lucid, and if I test all derivatives to see if they work with -all, could we make the dependency switch?
<persia> ScottK: Thanks for the references: this is looking promising (albeit for Lucid+1)
<ScottK> alkisg: Didn't crimsun say that was just a workaround and the wrong way to go about it?
<persia> alkisg: From -alsa to -all?  That should be easy enough, so long as -all is configured to be sane about which backend it chooses.
<alkisg> ScottK: he said that for workstations, but when I mentioned that LTSP *needs* pulseaudio, I got the feeling that he accepted that.
<alkisg> persia: yes.
<ScottK> alkisg: When it comes to stuff like this, I'm personally going to go with what crimsun says.
<ScottK> So get him to agree and I'm all for it then.
<alkisg> OK, so /me writes down the steps he needs to make: (1) verify that all derivatives work with -all, (2) talk to crimsun about it, (3) [if everyone seems to agree] nag until the dependency is changed to -all first. :)
<alkisg> Ah and (4) try to get -all to use pulse by default when it's available
<ScottK> If you get 1 and 2 done, 3 will be easy.
<persia> Well, except don't nag.  Just file a bug with the conclusions of your verifications and discussions.
<persia> And make sure to have tasks for any packages that need modification.
<alkisg> persia: sure, I was just kidding with that word. I don't go around nagging people... Sorry for my lack in English language.
<persia> alkisg: No worries.  Just wanted to be clear for the logs :)
<alkisg> :)
<pitti> Good morning
<joaopinto> Good morning
<jjardon> hello, any recent change in GDM code? After today upgrade, GDM doesnt start
<jjardon> (lucid here)
<pitti> jjardon: gdm didn't change, but yesterday we got a lot of new gnome libs
<jjardon> pitti, maybe that is the problem: I can see the "x" cursor, but GDM doesnt boot
<pitti> jjardon: does it work if you boot with "text", log into a VT, and "sudo start gdm"?
<ttx> cjwatson: there still is an issue with UEC installer not using the preseed file
<pitti> (that's how I have to boot my machine these days)
<ttx> cjwatson: https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/504157
<ubottu> Launchpad bug 504157 in eucalyptus "Lucid UEC installer: CC install is not preseeded when separated from CLC" [High,Confirmed]
<ttx> cjwatson: wget.gnu seems to work ok now, so it comes from something else
<jjardon> I can switch to a VT but sudo start gdm does nothing
<cjwatson> ttx: I'll need the full syslog
<ttx> ok, just a sec
<cjwatson> ttx: ideally with DEBCONF_DEBUG=developer
<seb128> pitti, I just joined but the changes from yesterday should not make a difference for login...
<ttx> hm
<ttx> cjwatson: where do I specify that ?
<jjardon> pitti, any other idea? your machine works ok?
<pitti> jjardon: yes (except for gdm starting too early)
<ttx> cjwatson: existing installer syslog attached to the bug
<ttx> cjwatson: looking into how to regenerate it with DEBCONF_DEBUG=developer
<cjwatson> ttx: on the boot command line
<ttx> cjwatson: I'm on it
<jjardon> pitti, I'm going to restart and try some things. Wish me luck!
<jjardon> weee, I'm very lucky! I've just executed locale-gen and now all works again
<jjardon> strange
<pitti> ah, yesterday's glibc broke all locales for some reason
<pitti> I did locale-gen as well
<pitti> but right after dist-upgrading
<ttx> cjwatson: syslog with DEBCONF_DEBUG=developer uploaded to bug
<davmor2> seb128: thanks for updating my rhythmbox bug.  Is there a better way of looking for bugs cause I looked it up before filing and couldn't find it :(  bug 503887 (for your info).  I'm assuming it down to the keywords you use etc
<ubottu> Launchpad bug 503887 in rhythmbox "Icon on the task bar is wrong (dup-of: 497095)" [Low,Invalid] https://launchpad.net/bugs/503887
<ubottu> Launchpad bug 497095 in rhythmbox "App indicator icon is broken" [High,Triaged] https://launchpad.net/bugs/497095
<seb128> davmor2, you're welcome, I just looked for bugs with the name "icon"
<seb128> sorting by most recent first...
<seb128> there is not too many of those
<davmor2> seb128: cool ta for the info :)
<siretart`> since yesterday's dist-upgrade, I experience segfaults in gdm/X: http://paste.ubuntu.com/352787/ - Any idea what this could come from? is there perhaps some bug on this open already?
<jmarsden> siretart`: The consensus is that the glibc update destroed all locales, and running locale-gen fixes things.  I think.
<siretart`> let's try...
 * alkisg is also having gdm problems, but locale-gen didn't solve them. startx works, though...
<cjwatson> pitti: maybe the locale definition format changed?
<siretart`> jmarsden: excellent hint, locale-gen regenerated *only* the german locales (6), the english ones where already up-to-date. thanks a bunch!
<cjwatson> in which case the installer is going to need an update ...
<jmarsden> siretart`: You're welcome.
<cjwatson> ttx: hmm. could I see the preseed file as well, which it allegedly downloaded? something isn't adding up here
<ttx> cjwatson: I can't find anything in /tmp/eucalyptus-udeb*, does it delete it after "successfully loading" it ?
<cjwatson> ttx: I mean the one at the URL you cited
<ttx> cjwatson: ah ok
<cjwatson> yes, it deletes it
<cjwatson> might be worth double-checking that this shows something sensible when run in the installer: wget.gnu -q --no-check-certificate -O - $url
<cjwatson> from the syslog, it looks rather as if it downloaded an empty file
 * alkisg has el_GR.UTF-8 as the system locale, and while locale-gen didn't solve his gdm problems, locale-gen --purge did
<ttx> cjwatson: the command gets the right contents, let me pastebin what it gets
<ttx> maybe $url is not what we think it is
<cjwatson> I'll make it syslog the URL
<ttx> preseed contents is http://people.canonical.com/~ttx/preseed.conf
<cjwatson> ok, so it definitely didn't actually load that
<ttx> cjwatson: I think I got it
<ttx> clouds="$(euca_find_component cloud)"
<ttx> cloud="${clouds#* }"
<ttx> cloud_preseed "https://$cloud:8443/preseed/preseed.conf"
<ttx> euca_find_component returns "CLC 192.168.0.151:8773"
<cjwatson> so it does
<ttx> and wget.gnu doesn't really mid trying to fetch from 192.168.0.151:8773:8443, apparently
<cjwatson> willfix
<ttx> cjwatson: assigning to you then. Some more logging could come in handy :)
<cjwatson> already added :)
<ttx> cjwatson: heh :)
<cjwatson> node->cluster preseed fetching has a similar bug
<cjwatson> actually no it doesn't
<ttx> no, it works
<cjwatson> ... yes it does. COFFEE
<cjwatson> it has it in at least some modes, I'm pretty sure. The code is cognate
<ttx> right but maybe :8773:8773 just works
<cjwatson> oh, you're right, actually the cluster code never appends a port
<ttx> the CLC+Walrus+CC+SC / NC topology works
<ttx> those bugs come from my testing of CLC+Walrus / CC+SC / NC
<ttx> Then more bugs might come from CLC / Walrus / CC / SC / NC :)
<cjwatson> ttx: fix committed, want me to upload?
<ttx> cjwatson: sure, I could use an ISO with that
<ttx> I still haven't had time to get into your netboot magic
<ttx> this week is crazy (I should get used to it)
<cjwatson> gah, eucalyptus bzr is out of sync with the archive
<ttx> beh
<ttx> which branch ?
<cjwatson> ~trout kirkland
<ttx> arh
<cjwatson> lp:~ubuntu-core-dev/eucalyptus/ubuntu
<cjwatson> kirkland: use 'bzr bind' and then you won't forget to push ...
<cjwatson> ttx: should I wait for kirkland to get back and merge whatever he has locally?
<cjwatson> bzr is missing:
<ttx> cjwatson: he uploaded to archive what he had locally, so in theory we could reapply it to branch
<cjwatson> +  * debian/control, debian/eucalyptus-nc.upstart: (LP: #446036, #452572)
<cjwatson> +    - add a versioned depends for eucalyptus-nc on a new version
<cjwatson> +      of libvirt-bin that starts using upstart
<cjwatson> +    - start eucalyptus-nc on started libvirt-bin
<cjwatson> yes, if you'd like me to do that, I can
<ttx> cjwatson: if you don't mind, I really could use those hours before he wakes up for more testing
<ogra> can some archive admin let the uboot-imx binary out of NEW (it changed the binary name to -to3 from -to2 with teh new upstream)
 * ttx tries netboot magic in the mean time
<pitti> argh
<smb> pitti, irc went mad for you, to?
<pitti> doko__: does the new glibc disable that ipv6 patch again? my internet connection sucks, and now I found out that apparently that DNS bug is back
 * pitti puts back the old workaround
<pitti> aah, sanity again
<cjwatson> it always scares me when I accidentally type 'bzr di' in (say) a git branch AND IT WORKS ANYWAY
<pitti> oh, you got bzr-git working?
<cjwatson> pitti: it worked for basic working tree stuff well before you could use it to branch
<slangasek> doko__: why has my en_US.UTF-8 locale broken on eglibc upgrade?
<doko__> pitti: it's still enabled
<doko__> slangasek: didn't see that, how is this broken?
<slangasek> doko__: bug #504198
<ubottu> Launchpad bug 504198 in eglibc "locale support broken on upgrade to latest eglibc" [Critical,New] https://launchpad.net/bugs/504198
<slangasek> caused at least one maintainer script crash on upgrade
<pitti> slangasek: in gnome-menus?
<pitti> (I fixed that this morning)
<seb128> well fixing the crash doesn't fix the fact that locales are broken
<seb128> ie everything is in english
<pitti> of course
<slangasek> pitti: yes
<pitti> at least libc6's script should call locale-gen to rebuild them
<seb128> that's not enough to fix the locale there
<slangasek> I don't think missing locales are the problem, it looks to me like glibc is getting the path lookup wrong
<slangasek> or at least, when it finds /usr/lib/locale/en_US.utf8/LC_CTYPE, it decides it's no good and keeps looking
<Laney> caused a software-center maintainer script crash for me
<seb128> pitti, I did run locale-gen and it says fr_FR.UTF-8 is still up-to-date but I get warnings on running gtk applications saying the locale is no supported by the C library...
<pitti> hm, I did that, and a reboot, and everything is working again
<seb128> not there
<pitti> oh, "up-to-date"? that's wrong
<pitti> it should regenerate it
<seb128> I think it did on the first run
<seb128> now it says that
<pitti> sudo locale-gen --purge
<seb128> no hurry it's the mini config
<seb128> I use it only for bootchart
<seb128> I will let the system in state to verify that the fix work when there will be one
<slangasek> ah; so indeed, locale-gen regenerates my non-English locales with success
<slangasek> but says the English ones are up-to-date
<doko__> slangasek: is locale-gen --purge just enough to fix the problem?
<slangasek> doko__: yes
<ior3k> hey, I'm sorry to be asking questions here, but there doesn't seem to be anyone around on #ubuntu+1
<ior3k> my keyboard stopped working with X
<ior3k> since yesterday
<ior3k> can anyone give me some pointers on how I can fix it?
<ior3k> this is lucid, btw
<siretart`> slangasek: I can confirm your observations, only my non-english locales were regenerated. - however, the effects were more grave: it made gdm and X segfault on the next reboot.
<slangasek> oh, I haven't gone so far as to reboot yet :/
<siretart`> that was fun. espc since the segfault is pretty unobviously hidden in /var/log/syslog
<ttx> pitti, cjwatson, slangasek: I could use a server CD respin to test the eucalyptus 1.6.2~bzr1120-0ubuntu5
<pitti> ttx, cjwatson, slangasek: triggering
<slangasek> ok
 * ttx needs a local archive mirror to use netboot in a satisfying way :)
<ion> It seems hal is back in the default desktop.
<ion> ubuntu-desktop recommends pitivi, pitivi recommends hal.
<highvoltage> it doesn't want to die
<tjaalton> running apt-get install --fix-policy wants to remove grub-pc and replace it with the old one..
<tjaalton> among other scary things
<slangasek> --fix-policy?
<slangasek> pitti: ^^ who can look at fixing pitivi's recommends on hal?
<pitti> slangasek: I discussed that with upstream, but it's not trivial; pitivi is in python, and there are no python gudev bindings yet (and probably won't be), and the python gobject-introspection support still needs to land
<pitti> slangasek: but I changed hal to not start on boot, but on demand (dbus activation)
<pitti> so it's not reintroduced into the boot path
<sebner> pitti: beside other breakage, is xorg broken? Seeing this in lucid: http://pastebin.com/m3cc1d9d5
<pitti> in fact I always feared that we had to do that anyway to not break brightness settings for hardware without xbacklight
<pitti> sebner: bug 504198
<ubottu> Launchpad bug 504198 in eglibc "locale support broken on upgrade to latest eglibc" [Critical,In progress] https://launchpad.net/bugs/504198
<sebner> pitti: ohhh, my hero :D
<slangasek> pitti: ok, ack
<sebner> slangasek: do I need to do a X restart after locale-gen --purge ?
<pitti> ion: there's an upstream bug for pitivi, FYI
<slangasek> sebner: shouldn't be?
<tjaalton> slangasek: to install all recommends
<pitti> ion: https://bugzilla.gnome.org/show_bug.cgi?id=605920
<ubottu> Gnome bug 605920 in general "Switch to (g)udev for device detection/support" [Normal,New]
<sebner> slangasek: I'll try xserver reboot because your "workaround" doesn't fix it for now
<tjaalton> seems to be undocumented though
<slangasek> tjaalton: hmm, indeed
<sebner> slangasek: ahh, sudo ;)
<slangasek> sebner: hem, yes... :)
<sebner> slangasek: wondering why xserver reconfig isn't working but at least the warnings are gone ^^
<sebner> slangasek: any chance you use nvidia-glx?
<tjaalton> reconfig? it's been removed
<tjaalton> there is no xorg.conf anymore (by default=
<tjaalton> )
<sebner> tjaalton: ahh, right, just need it for haXX0ring the nvidia driver evidently (which is now broken for me)
<slangasek> tjaalton: I don't see anything in lucid with wrong Recommends on grub; sounds to me like the undocumented option is broken...
<slangasek> sebner: nvidia-glx> not at all
<sebner> slangasek: kk, thx anyways
<tjaalton> slangasek: it's probably something recommending grub, and it conflicts with grub-pc
<slangasek> tjaalton: nothing in lucid recommends grub
<tjaalton> slangasek: huh, ok then :)
<slangasek> everything correctly recommends grub-pc | grub
<tjaalton> mvo: ^^
<mvo> tjaalton: hello, could you please add "-o Debug::pkgDepCache::AutoInstall=true -o Debug::pkgProblemResolver=true" and send me the output?
<mvo> tjaalton: btw, it looks like my xorg patch is in the xorg-devel moderation queue
<ttx> cjwatson: CC/SC picks up CLC preseed perfectly now, thanks !
<ion> !summon Keybuk
<cjwatson> ttx: excellent
<sebnerr> ok xserver really looks b0rken, nv segfaults X (gdm starts, black screen but mouse is visible, also loginable) and nvidia-glx wants to remove the entire X stack :(
<sebnerr> tjaalton: now I can't use vesa because I removed my xorg.conf :P
<tjaalton> sebnerr: yes, nv is broken but mvo has fixed it partially (rest is on the way) :)
<tjaalton> and tseliot has a ppa for the blob
<tjaalton> mvo: ahah, got the error.."Installing grub as Recommends of linux-image-2.6.30-5-generic" :P
<mvo> sebnerr: if you try https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/494627 that would be helpful
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress]
<tjaalton> mvo: I'll ask people to push it through the queue
<mvo> many thanks tjaalton
<tjaalton> mvo: thanks for letting me see the error :)
 * tjaalton runs the cleanup app
<tjaalton> mvo: when did you send the patch?
<tjaalton> to the list
<mvo> tjaalton: yesterday in the afternoon, I can give you the exact time, give me a sec
<mvo> tjaalton: Message-ID: <20100106135338.GL2603@tas>
<tjaalton> mvo: it's on the list
<mvo> tjaalton: Date: Wed, 6 Jan 2010 14:53:38 +0100
<mvo> tjaalton: oh, cool
<tjaalton> jcristau accepted it
<mvo> tjaalton: sorry for the noise then
<mvo> sweet
<tjaalton> no replies yet ;)
<dholbach> ion: do you have a link to your bug report or patch for mountall again?
<sebner> mvo: ohhhhhhhh, testbuilding xserver? Sure I'll try :D /me removed -nv btw to let vesa start  somehow ^^
<tjaalton> hmm computer-janitor crashes, need to clean up manually
<tjaalton> sweet, a kernel crash
<dholbach> ion: nevermind, found it - I think I'll try it out and build a package for myself locally
<dholbach> the machine just restarted itself again :/
 * dholbach summons Keybuk too
<ion> dholbach: Hereâs the merge request, https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/+merge/16868
<dholbach> thanks
<sebner> mvo: please fiXX0r your patch. you are patching xserver-xorg where apt-get source xserver-xorg which fetches xorg
<dholbach> ion: I'll let you know how it works for me
<tjaalton> sebner: hmm? the source for xserver is xorg-server
<sebner> tjaalton: me gets xorg-7.5~3ubuntu4
<ion> dholbach: Aye
<tjaalton> sebner: apt-get source xorg-server or xserver-xorg-core
<sebner> oho!
<sebner> mvo: sorry false alarm ;)
<sebner> tjaalton: thx
<slangasek> ccheney: is it possible for openoffice to be rebuilt against libicu42 in advance of alpha-2?
<slangasek> ccheney: should kick a 7MB .deb off the alternate and make me happy again :)
<doko__> ccheney: if you rebuild, please apply the visibility patch for arm
<sebner> mvo: unstable should be lucid btw
<zul> doko__: ping
<doko__> zul: just ask/write
<mvo> sebner: indeed
<zul> doko_: can you review those python-pastescript and python-pastebin MIR?
<doko__> ok
<sebner> mvo: haven't seen any blob by tseliot yet, still work in progress or anything to test already (besides installing upstream driver manually)
<tseliot> sebner: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements (still WIP)
<sebner> tseliot: uhhh, mighty tseliot :) I'll test (190 driver)
<tjaalton> could someone remove libxcb from the sync blacklist, if there is such
 * sebner fiXX0rs his xserver first
<sebner> tseliot: what do you think about mvo's xserver patch?
<tjaalton> libxcb still isn't autosynced, though lp support debsrc3.0
<tjaalton> supports
<tseliot> sebner: what patch?
<pitti> tjaalton: looking
<pitti> tjaalton: it's not blacklisted
<tjaalton> pitti: thanks
<sebner> tseliot: fiXX0r broken nv/xserver https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/494627
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress]
<slangasek> pitti: do you think the cryptsetup SRU could be published, or is there more verification you'd like to see there first?  I think the lack of screams that we broke the world is a positive sign...
<tjaalton> pitti: ok, bug 503290 then :)
<ubottu> Launchpad bug 503290 in libxcb "Sync libxcb 1.5-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/503290
<pitti> tjaalton: done
<tjaalton> pitti: great, thanks
<sebner> mvo: Is this a problem to have the "fixed" xserver + the "fixed" nv installed because in the bug report it's the best to revert your nv fix
<mvo> sebner: without the revert for the initial fix I get funny colors
<sebner> mvo: so I downgrade nv then
<mvo> sebner: do you get funny colors with the latest nv?
<sebner> mvo: didn't restart yet
<mvo> ok
<tjaalton> mvo: but the -nv change is already upstream, you mean it should be reverted?
<sebner> mvo: /me tries now
<tseliot> sebner: the patch looks good but I'm not very familiar with the nv driver
<soren> I'm having all sorts of locale related problems today. Does that sound familiar to anyone?
<tjaalton> yes, run locale-gen --purge
<mvo> tjaalton: I'm not sure, but it sounds to me like it should be, unless they are working on gamma_set anyway already
<mvo> tjaalton: for me 2.1.15+patched xserver works without a hitch since yesterday
* pitti changed the topic of #ubuntu-devel to: "Fix locale breakage in lucid with sudo locale-gen --purge | Lucid Alpha 1 released | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs fo
* pitti changed the topic of #ubuntu-devel to: Fix locale breakage in lucid with sudo locale-gen --purge | Lucid Alpha 1 released | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for
<mvo> tjaalton: but again, I do not know enough about X direction to properly judge, if the old-style colormap code gets depercated (no idea if it is nor not) then it might be the time to do the color dac programming in gamma_set
<mvo> upstream will know :)
<tjaalton> mvo: yeah
 * mvo just wanted a working X :
<mvo> :)
<tjaalton> don't we all *sigh* :)
<sebner> mvo: my screen was still blank but downgrading to the old -nv fixed the issue for me
<sebner> tseliot: I'll try nvidia blob now
<mvo> lol@tjaalton
<sebner> soren: + sudo ;)
<soren> sebner: Yeah, I guessed :)
<sebner> soren: I didn't at the first try *cough*
<tseliot> is it just me or tabs in nautilus are at the bottom in Lucid?
<sebner> hahaha
<sebner> tseliot: here too
<tseliot> :-/
<sebner> tseliot: :/ http://pastebin.com/m68641479
<seb128> tseliot, it's a design choice
<mvo> upstream?
<seb128> yes
<sebner> seb128: a really bad one tbh
<seb128> why?
<seb128> it's not to have everything at the same location
<sebner> seb128: longer way imho
<tseliot> I assume this is only in nautilus
<seb128> toolbar, pathbar, tab
<soren> sebner: I fixed that by running "apt-get dist-upgrade" again.
<soren> sebner: (the stuff you pastebin'ed)
<sebner> seb128: I (and I suppose most) didn't have a problem with it
 * sebner tries
<sebner> gnahahh
<sebner> installs b0rken nv
<sebner> :P
<seb128> there was no split view mode by then though
<tseliot> sebner: you should have updated your system with my PPA first
<sebner> seb128: is there still a discussion or will be see it in the final too
<sebner> tseliot: I guess it's because of the fiXX0red Xserver
<sebner> soren: not working :(
 * sebner runs sudo apt-get remove xserver-xorg
<sebner> xD
<kirkland> cjwatson: thanks, i didn't know about 'bzr bind'
<tseliot> sebner: I meant, apt-get dist-upgrade instead of installing nvidia directly
<kirkland> ttx: sorry about that
<soren> sebner: That driver doesn't work, or the package still doesn't install?
<sebner> tseliot: I had the old driver removed anyways
<ttx> kirkland: you owe cjwatson a beer ;)
<sebner> soren: package but I'll try something out
<kirkland> ttx: probably several, in fact ;-)
 * sebner reboots
<cjwatson> kirkland: (it's like bzr checkout but you can do it after branching without having to build the branch again from scratch)
<kirkland> cjwatson: that's really, really cool
<slangasek> didrocks: how is https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-une coming along?
<sebner> mvo: funnily I had strange colours with new nv and tseliot xserver
<pitti> slangasek: I think the only thing left is to add transitional packages to the new ubuntu-netbook{,-default-settings} packages (for the former -remix) name, and remove the old packages
<sebner> tseliot: nvidia blob installed and working but only ~1000 frames/s instead of 15000
<slangasek> pitti: ok, cool
<slangasek> pitti: just wanting to make sure that since this is for alpha-2, it lands this week, not next :)
<tseliot> sebner: my xserver contains only changes in the packaging scripts (no code change whatsoever)
<tseliot> sebner: what does "glxinfo | grep direct" say?
<pitti> slangasek: yeah, would be nice indeed; StevenK was working on that last, will ping him again (or help out)
<sebner> tseliot: direct rendering: Yes
<tseliot> sebner: really? Can I have a look at your /var/log/Xorg.0.log?
<sebner> tseliot: http://pastebin.com/m67df35b5
<sebner> tseliot: btw, I had to use nvida-xconfig else nv would start
<tseliot> sebner: glx seems to be broken. Restart your computer or it won't work
<tseliot> restarting X is not enough with the new system
<sebner> tseliot: I restarted the laptop ;)
 * sebner gives it another try anyways
<tseliot> it says that it failed to initialize the GLX module
<sebner> tseliot: same result
<StevenK> pitti: I think that's done, but I'd welcome the second set of eyes to see if I've missed anything.
<pitti> StevenK: awesome
<StevenK> pitti: Er, rather, all that remains to be done is remove u-n-r-d-s from lucid
<tseliot> sebner: let's discuss this in #ubuntu-x
<pitti> StevenK: was unr-meta superseded as well?
<pitti> ah, netbook-meta, nevermind
<pitti> StevenK: ubuntu-netbook-default-settings still needs to build a transitional ubuntu-netbook-remix-default-settings package AFAICS
<pitti> StevenK: likewise, netbook-meta (or something else) needs to build a transitional ubuntu-netbook-remix package
<pitti> and ubuntu-netbook needs to C/R/P: ubuntu-netbook-remix
<slangasek> mvo: bug #494627> hmm, when will that be uploaded?  that looks an awful lot like my periodic X-segfault-on-lid-close problem here w/ intel, I'd love to check :)
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress] https://launchpad.net/bugs/494627
<sebner> slangasek: you need a reverted -nv too though
<slangasek> no, I don't
<sebner> slangasek: creates funny colours for mvo and me
<mvo> slangasek: I was waiting for upstream on this, but tjaalton said he now merged it
<mvo> sebner: I just uploaded a reverted -nv
<sebner> mvo: \o/
<tjaalton> I need to fix my laptop first, though
<tjaalton> something is killing gdm on boot, dropping it in failsafe which doesn't work at all when kms is used
<StevenK> pitti: Notes taken, I'll upload them both (and remove u-n-r-d-s) later today
<pitti> StevenK: thanks muchly
<pitti> StevenK: unr-meta should be removed as well, right?
<StevenK> pitti: I thought it already had been, but I'll check it too and bin it too
<tseliot> ara: I think we found out what your problem with nvidia was
<ara> tseliot, nice! what was it?
<tseliot> ara: it looks like X tries to load the wrong glx binary which is in a sub-directory instead of the right one (which is a link)
<tseliot> ara: you can move /usr/lib/xorg/modules/extensions/standard/libglx.so out of the way and restart or wait for my fix
<ara> tseliot, I'll wait for the fix, so I can verify that the new PPA actually fixes it, thanks :)
<tseliot> thanks for testing :-)
<sebner> tseliot: /me waits too :)
<tseliot> good
<sbalneav> mvo: I think I cracked Bug #501559 last night.  Have a look at the second patch I attached.  forkpty isn't enabled, and it works for me in all the use cases I could test, including enabling tty_tickets in sudo.
<ubottu> Launchpad bug 501559 in libgksu "libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL" [High,Confirmed] https://launchpad.net/bugs/501559
<mvo> sbalneav: cool, I have a look
<sbalneav> I think there was a "logic error" in the way things were being attempted in the "no forkpty" case.
<mvo> sbalneav: thanks, I have a look now, may take a little bit as the #ifdef logic in the code tends to confuse me :)
<ccheney> doko__: location of patch?
<doko__> ccheney: in your inbox since October
<ccheney> doko__: ah ok
<barry> doko__: ping
<doko__> barry: pong
<barry> doko__: hi!  say, did you know that distribute (the setuptools replace) supports automatic 2to3 invocation at install time?
<tseliot> my PPA build of the xserver will start in 4 hours... :-(
<Laney> tseliot: smile sweetly for a rescore ;)
<tseliot> :-D
<tseliot> too much?
<sebner> tseliot: nvidia blob rebuild! :P
<doko__> barry: yes
<tseliot> sebner: nope just X
<sebner> tseliot: that enough?
<tseliot> yep
<sebner> tseliot: cool :D don't forget to smile bright *cough*
 * tseliot smiles sweetly to pitti
<tseliot> :-P
<sebner> tseliot: even better, I testbuild it locally! :P
<tseliot> sebner: I can but I don't have an nvidia card in my testing box and I can't unplug it from my main pc right now
<sebner> tseliot: np, I'm testbuilding it locally right now ^^
<tseliot> sebner: ah, thanks
<sebner> tseliot: Do I have to reinstall nvidia current or just setting up xserver and reboot?
<barry> doko__: i didn't know before yesterday, but that is *really* cool
<tseliot> sebner: the latter should be enough
<doko__> barry: yes, it eases packaging
<sebner> tseliot: aye, I'll tell you the result then :)
<tseliot> ok
<pitti> smb: sorry, rescore what?
<barry> doko__: so if a python package uses distribute, and is python 3 clean (i.e. works after 2to3), a packager doesn't need to do anything special to package it for both py2 and py3 on ubuntu?
<smb> pitti, Uh, did I say something here lately?
<pitti> smb: nevermind me
<pitti> tseliot: sorry, rescore what?
<barry> doko__: i'm actually trying to do this today, so i guess i'll find out :)
<tseliot> pitti: we were joking about the fact that my xserver build in my ppa will start in 4 hours
<doko__> barry: no, you still want to have two binary packages
<pitti> tseliot: if that's urgent for testing, I can bump it; URL?
<barry> doko__: that makes sense
<tseliot> pitti: the sooner we test the sooner I can start uploading things in Ubuntu: https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+packages
<tseliot> pitti: xorg-server
<pitti> tseliot: amd64 building, i386 bumped
<tseliot> pitti: thanks a lot
<kees> james_w: hi! my memory sucks, which was the oid package that you had examined and was using the less secure protocols?
<james_w> python-oauth
<james_w> oauth no oid
<kees> oauth! yes, that's why I could find it in my mail
<kees> james_w: by any chance have you looked at python-openid?
<james_w> I have
<james_w> I had more confidence in the implementation, but that may have just been because there was more code :-)
<kees> hah
<ccheney> slangasek: it looks like all i have to do to get it to use the new libicu is rebuild without changes, does that sound correct? libicu-dev seems to be for libicu42 now
<slangasek> ccheney: AFAIK, yes
<ccheney> slangasek: ok thanks :)
 * ccheney is doing a test build then will add doko's patch and get it uploaded
<sebner> tseliot: anything I need to mind after installing -21?
<tseliot> sebner: no, just make log with the nvidia-bug-report command
<sebner> tseliot: I thought it should work then ^^
<tseliot> sebner: yes, it should work but I just want to be sure that everything's ok
<sebner> sure :)
<slangasek> zul: were you taking care of seeding irqbalance and tickcount?
<zul> yes
<slangasek> ok
<zul> slangasek: problem?
<slangasek> zul: on the alpha-2 bug list, no action since before the holidays, so just checking that it's on someone's radar :)
<zul> slangasek: oh yeah its on my radar :)
<didrocks> slangasek: about UNE renamining, StevenK was the assignee. I guess it was changed to myself as I'll start next week.
<slangasek> didrocks: ah; they assigned you a spec with a deadline before your start date, not nice :)
<didrocks> slangasek: not really a pb. I think it'll be quickly done ;)
 * ccheney forgot he has to update the build system for lucid too
<didrocks> pitti: you spoke about it with StevenK yesterday I guess, do you know what's the status?
<pitti> didrocks: Steve and I went through the remaining renaming bits, he'll do them today/tomorrow
<pitti> didrocks: bonjour
<didrocks> hey pitti ;)
<pitti> didrocks: got my /query ?
<didrocks> pitti: yeah, one sec. A lot of stuff to read (back to paris) :)
<zul> slangasek: what do you think of installing irqbalance by default for everyone?
<slangasek> zul: I think that question should be put to a larger audience; my own reaction is "new daemon - ick, no"
<zul> slangasek: ok ill fire off an email to ubuntu-devel
<mathiaz> kees: hi! During the discussion about pkg demotion, you mentionned that both logcheck and logwatch should be demoted to universe. What's the rationale?
<kees> mathiaz: is that what I said?  I think I meant "one should be demoted if they do the same thing".  As it turns out, they don't do the same thing, so I'm okay with them staying in main.
<mathiaz> kees: ah ok - I thought you said that both should belong to universe
<mathiaz> kees: sorry for that
<kees> mathiaz: I don't mind less stuff in main.  :)
<mathiaz> kees: and then there is the ongoing discussion on ipsec
<mathiaz> kees: IMO we should support an IPSEC stack in main
<mathiaz> kees: as it's used in corportate environements
<mathiaz> kees: and openvpn doesn't cover all use cases
<kees> I'm on the fence.  my ubuntu-user hat says "keep ipsec", and my security hat says "I've done updates on it! out out!"  ;)
<mathiaz> kees: understood
<mathiaz> kees: the issue here is the ipsec-tools package
<mathiaz> kees: another solution is isakmpd
<ttx> kees: I know what color is your security hat, but what color is your ubuntu-user hat ? brown ?
<jdstrand> I pick logcheck as supported
<jdstrand> (I use that one ;)
<zul> jdstrand: done! boot the other out ;)
<jdstrand> :)
<mathiaz> kees: and for redhat-cluster-suite, we'll wait for the result of ivoks testing of the new cluster components (pacemaker, etc...)
 * kees nods
<tjaalton> doko__: you added a dep on xauth to xvfb, although it had been dropped right after jaunty opened
<tjaalton> doko__: and the failure log didn't have anything related to xauth
<kees> mathiaz: let's leave ipsec-tools in main for now.
<doko__> tjaalton: well, an xvfb-run true doesn't succeed for me without having xauth installed
<tjaalton> doko__: how come it took a year to find out?-)
<mvo> sbalneav: I attached a new diff (very small) could you please have a quick look/test ? it works in my tests and is whatthe original gksu in karmic did
<seb128> tjaalton, it didn't, we had this discussion before, where "we" might not be you for xorg
<seb128> tjaalton, we had to add xauth build-depends to several packages
<tjaalton> seb128: ok
<tjaalton> I won't touch it again then ;)
<seb128> well if we added the xauth build-depends that's probably because there was good reason to drop if from xvfb
<seb128> I would say doko's change should be undone and build-depends should be added to whatever he tried to build
<tjaalton> seb128: it's a Recommends anyway
<tjaalton> in debian
<mathiaz> bdmurray: hi!
<bdmurray> mathiaz: hello
<mathiaz> bdmurray: I'm going through the ubuntu-main-sponsorship queue - bug 62529 has patch attach to it
<ubottu> Launchpad bug 62529 in hundredpapercuts "Drag and drop of Bookmarks from Places menu copies entire directory instead of creating a link" [Undecided,In progress] https://launchpad.net/bugs/62529
<mathiaz> bdmurray: 1. the patch is not a proper debdiff and 2. the package is maintained in bzr
<mathiaz> bdmurray: is there a standard reply to cover that use case?
<bdmurray> mathiaz: no there isn't
<mathiaz> bdmurray: ok - I'll write something up then
<sbalneav> mvo: ok, one sec:
<genii> With upstart, is the tool to replace update-rc.d now initctl ?
<sbalneav> mvo: I'll give it a try tonight.  Unfortunately, I'm on my day job, and the lucid box is at home.
<sbalneav> mvo: I'll update the bug with my findings thisevening.  Thanks for working on this with me.  Sabayon's important for a lot of teachers, and they'll appreciate the work.
<mathiaz> bdmurray: how about that: http://paste.ubuntu.com/353029/
<bdmurray> mathiaz: The reply reads fine but that patch has been languishing for 4 months as it is...
<mathiaz> bdmurray: oh well - I can't really commant on the patch itself - I'm just trying to move things forward and get the sponsorship queue cleaned up
<mathiaz> bdmurray: as of now the patch is not in a good format - that's the best I can do in my position
<bdmurray> mathiaz: ah, okay then but isn't there somebody else on that sponsorship team who might be able to comment on the patch itself?  Removing it from the queue because it isn't perfectly formatted seems like a way to lose the patch to me.
<mathiaz> bdmurray: hm... right
<mathiaz> bdmurray: so may be I shouldn't unsubsribe the sponsor team then
<mathiaz> bdmurray: just leave a comment on how to move things forward
<bdmurray> mathiaz: that seems best to me
<kees> cjwatson: quick check, did the installer ever grow the logic to do a "service apparmor reload" in the final stages of install to generate the profile cache?
<Pici> 22
<cjwatson> kees: not AFAI
<cjwatson> K
<kees> cjwatson: ok, should I bug you or ev about that?  just needs a quick "/etc/init.d/apparmor reload; /etc/init.d/apparmor stop" near the end of the install.
<cjwatson> kees: probably ev given how my week's been ...
<kees> cjwatson: cool
<mdz> has anyone else seen this on lucid:
<mdz> [113006.639028] cron[5446]: segfault at 0 ip (null) sp 00007fffabb9dec8 error 14 in cron[400000+9000]
<mdz> [113006.639065] Process 5446(cron) has RLIMIT_CORE set to 0
<mdz> [113006.639070] Aborting core
<kees> mdz: known, in progress
<mdz> there are three of those in my dmesg today
<mdz> kees, ok, thanks
<kees> (well, not the cron crash, but the rlimit_core issue)
<kees> mdz: rlimit_core is bug 498525.  haven't seen the cron crash, though.
<ubottu> Launchpad bug 498525 in linux "[lucid] breaks apport: core dumps get aborted even if core_pattern is a pipe" [High,Fix released] https://launchpad.net/bugs/498525
<ev> kees: added to my todo list for tomorrow
<Shiran> anyone know how can i turn .po file to .qm file?
<kees> ev: ok, thanks!
<mdz> kees, thanks. I'm more concerned about the cron crash then
<kees> mdz: yeah
<mdz> kees, oddly, cron is running fine and has been for several days:
<mdz> âFine,â you say, âbut I have software to deliver, budgets to stay within, schedules to meet.â Indeed you do. But hereâs the thing â either your system is capable of delivering those results or it is not. Trying to force results beyond what your development system is capable of not going to get you where you need to be. You are not going to improve your system by stressing it to achieve aggressive targets. Systems donât work that way. You
<mdz> may get a local or temporary optimization, but you will not get a system capable of delivering high quality software reliably, repeatedly on time.
<mdz> So how do you get results? You start by making sure that work is structured so that it is a system â one that gives knowledge workers visibility into the needs and expectations of your customers. Then you focus on developing the technical capability of the system and of the people developing your products. You structure your delivery system so that workflows are steady and predictable. Finally, you develop workers who accept the challenge to continuo
<mdz> ack, sorry about the flood
 * mdz pummels inconsistent X clipboard / app shortcut semantics
<mathiaz> kees: jdstrand: what's your advise on bug 194472? Should there be visual feedback when you type your password for sudo?
<ubottu> Launchpad bug 194472 in hundredpapercuts "Entering password in Terminal gives no visual feedback" [Low,Fix committed] https://launchpad.net/bugs/194472
<mathiaz> mdeslaur: ^^?
<mdz> kees, do you know of any time when /usr/sbin/cron is started other than from the init script?
<ion> mathiaz: Rather remove the visual feedback from gksudo et al. instead. :-P
<kees> mdz: forking for running subprocesses?
<mdz> kees, hmm, yes
<jdstrand> mathiaz: imo it is not worth diverging from upstream for that. if they want to take a patch, then fine, but good luck with that ;)
<kees> mathiaz: well, there never has been for sudo.  that's a common and long-standing "feature" in *nix
<mathiaz> ion: well yes may be. First we should decide wether giving visual feedback when typing a password is recommended or not
<mdeslaur> mathiaz: how is that a papercut?
<mdz> it's happening at *:17 when cron.hourly runs
<mathiaz> jdstrand: well - upstream has an option as of 1.7.1
<mathiaz> jdstrand: so it can easily be enabed
<kees> mdz: weird, cron hasn't changed.  perhaps the new eglibc ?
<jdstrand> mathiaz: then I have no opinion, other than to say that shoulders surfers can figure out how many characters the password is
<mathiaz> jdstrand: 1.7.1: A new Defaults option "pwfeedback" will cause sudo to provide visual feedback when the user is entering a password.
<ion> mathiaz: Some visual feedback an attacker may not use to determine the length of the password would be okay.
 * jdstrand assumes that feedback is '****'
<kees> mathiaz: I would prefer the default be left to no feedback to match login, ssh, etc.
<mdz> I'm also getting locale warnings from perl, though locale-gen says my locale is up-to-date
<ion> mdz: Ditto. Forcing the regeneration of the locales is a workaround.
<mdz> kees, curiously, gdb has this to say:
<mdz> warning: .dynamic section for "/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)
<mdz> warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not at the expected address (wrong library or version mismatch?)
<mathiaz> kees: ok - would you mind adding a comment to the bug?
<mdz> ion, is there a bug open?
<jdstrand> mathiaz, kees: I already am
<mathiaz> jdstrand: great - thanks
<mathiaz> jdstrand: I'm going to unsusribe main-sponsors as long as the core issue isn't settled
<mdz> ion, ah, bug 504198
<ubottu> Launchpad bug 504198 in eglibc "locale support broken on upgrade to latest eglibc" [Critical,Fix released] https://launchpad.net/bugs/504198
<mdz> argh, gdb failure
<mdz> [New process 9748]
<mdz> [Thread debugging using libthread_db enabled]
<mdz> Cannot find new threads: generic error
<mdz> ...and restarting cron has made the problem go away :-/
<mathiaz> pitti: rickspencer3: hi - re bug 197657 - there is a merge proposal ready for review
<ubottu> Launchpad bug 197657 in hundredpapercuts "sunset in clock applet does not respect 12hr/24hr setting" [Low,In progress] https://launchpad.net/bugs/197657
<mathiaz> pitti: rickspencer3: however noone is assigned to review - is there a specific desktop team review?
<chrisccoulson> mathiaz - i was going to say that i could probably review that gnome-panel change, but it seems like i can't upload gnome-panel anyway. it might be a good idea to have vuntz review it (he hangs around in #ubuntu-desktop), but he's already got quite a lot of gnome-panel changes to review
<mathiaz> chrisccoulson: are you refering to bug 62529?
<ubottu> Launchpad bug 62529 in hundredpapercuts "Drag and drop of Bookmarks from Places menu copies entire directory instead of creating a link" [Undecided,In progress] https://launchpad.net/bugs/62529
<chrisccoulson> mathiaz - i was referring to bug 197657
<ubottu> Launchpad bug 197657 in hundredpapercuts "sunset in clock applet does not respect 12hr/24hr setting" [Low,In progress] https://launchpad.net/bugs/197657
<mathiaz> chrisccoulson: ok - thanks for the suggestion
<chrisccoulson> i have a feeling that bug 62529 is one that we're already waiting for vuntz to look at
<ubottu> Launchpad bug 62529 in hundredpapercuts "Drag and drop of Bookmarks from Places menu copies entire directory instead of creating a link" [Undecided,In progress] https://launchpad.net/bugs/62529
<chrisccoulson> i'll ask seb128 though
<chrisccoulson> pitti - do you know if there is a reason that gnome-panel is part of the "core" packageset (and not ubuntu-desktop)?
<pitti> mathiaz: it's in the sponsoring queue, so we'll get to it
<pitti> chrisccoulson: because it's also used by xubuntu and other derivatives
<mathiaz> pitti: you mean the main-sponsoring queue?
<chrisccoulson> pitti - thanks
<pitti> chrisccoulson: apt-cache rdepends libpanel-applet2-0 :)
<pitti> mathiaz: yes
<mathiaz> pitti: ok
<charlie-tca> chrisccoulson: thanks for your help on that xubuntu panel bug
<chrisccoulson> pitti - there's a lot of desktop components i still can't upload. perhaps i should consider going for core-dev one day ;)
<chrisccoulson> charlie-tca - you're welcome
<pitti> chrisccoulson: that'd be great
<tseliot> doko__, cjwatson: if I put the path to a library in a conf file in /etc/ld.so.conf.d/ this library should be used instead of the one in /usr/lib. Is this correct?
<sebner> pitti: how likely is breakage with new gdm 2.29.4? ^^
<tseliot> doko__, cjwatson: or shall I use preload?
<pitti> sebner: I don't know; but it's just a microrelease, so without knowing any details I'd say low?
<sebner> great :D
<vish> mathiaz: hi... mpt has been trying to get Bug #194472 fixed for a long time... you can note his comments in lp and upstream as well
<ubottu> Launchpad bug 194472 in hundredpapercuts "Entering password in Terminal gives no visual feedback" [Low,Fix committed] https://launchpad.net/bugs/194472
<vish> mathiaz: does the change need to be approved by anyone else?
<mathiaz> vish: well - I'm not sure whether mpt states that visual feedback should be turned on by default
<mathiaz> vish: my understanding is that he advocates for having consistency
<vish> mathiaz: comment 6 > "why not fix it, by getting sudo to show asterisks as you type your password?"
<mathiaz> vish: well - comment 8 is more precise
<mathiaz> vish: depending on the decision wether visual feedback should be enabled by default, different applications should be fixed
<vish> mathiaz: hmm... i dont think #8 is different either... in both his first mention is to show the password and only if it is not safe to change the default of others at once too...
<mathiaz> vish: well - may be. mpt is just offering his advice. The security team also commented on it.
<mathiaz> vish: to move things forward I'd suggest to send an email to ubuntu-devel to ask for feedback and may be reach a conclusion.
<vish> mathiaz: from what andrew mentions the password is shown only when the user is entering it and the feedback is removed once the user has hit enter [i havent applied the patch myself]
<vish> mathiaz: so -devel is the best approach ?
<mathiaz> vish: I guess so - the core issue to answer is whether visual feedback when entering a password should be enabled by default or not.
<unggnu> hi all
<mathiaz> vish: depending on the answer, relevant applications may require to be fixed.
<vish> mathiaz: hmm... oh boy... we'd probably end up discussing this for a long time ;)
<vish> on the ML
<unggnu> I think an option for fstab which suspends the mount a little after the boot would be great for Lucid. It could optimize the boot process for partitions which aren't needed directly on boot but should be still mounted and checked without user interaction.
<mathiaz> vish: if the ML discussion doesn't work out, the next step is to take it to the Technical Board.
<vish> mathiaz: well.. this might be a way out of my league... I'll assign the bug to mpt and request him to carry it forward :)
<chrisccoulson> i just enabled pwfeedback for sudo on my debian install
<chrisccoulson> just out of curiosity
<chrisccoulson> it clears the feedback from the terminal after you entered your password, so i don't think it's any less secure than other places that give visual feedback
<tseliot> slangasek: ping
<asac> slangasek: wrt meeting action about how to get file list that still need to rebuild: i have a script that prints out sources that are of same version in lucid and karmic. wanted to extend that by checking if thos have any binary package with Architecture != all ...
<asac> is that enough?
<asac> or do you have better ideas or scripts that are ready to use for that?
<godane> hey everyone
<pitti> apw: FYI, lp:~work-items-tracker-hackers/launchpad-work-items-tracker/2.0/ is the reorganized WI tracker
<pitti> apw: I got the DB layout, collector, and HTML reporter implemented
<pitti> apw: now I'll work on porting the burndown chart generation, and making that easier along the way, too
<pitti> apw: the wiki-status script is broken now, I'm afraid
<pitti> but hopefully it will get much simpler now, too
<pitti> apw: I created a library "report_tools.py" which now has the logic (like blueprint_completion() and assignee_completion()), and the DB has all the info about milestones, their due date, etc.
<pitti> apw: http://people.canonical.com/~pitti/tmp/lucid.db is a current lucid import (so that you don't need to generate one yourself and can just work with an existing DB)
<tweakt> what's the easiest way to get the latest available version of a package for a given release, where it may be running on a different (newer) release?
<ia> Hello. I know, probably this is not the best place for my question, but i'll try, if you let : i'm experimenting with python/gtk/(gnome)applets. Could anyone tell me, please, how to tell menu (gtk.Menu widget) making popup menu not on top of the other widget(s) (gtk.Icon/gtk.Label, for example), but near? Little illustration about my "problem" - http://yfrog.com/j9gtkmenup (so, indicator-session applet makes it right, and my testing applet - don't) ; I will
<ia>  be very appreciate for any clues.
<exosyst> Hey guys, is there any code up for https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-gdmsetup
<jcole> i have a scenario im trying to figure out... ive got packages that users install, but i want a "migration" script to run after the install (as the current mortal user logged into gnome)
<jcole> i notice for kernel updgrades and such, a "reboot is required box" pops up in the tray.. guessing dbus... can someone point me to a shell script example of how to do this?
<apw> pitti, sounds good, will look over it tommorrow and get some of my stuff working again
<ion> keybuk: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/+merge/16868
<Keybuk> ah, thanks
<ion> keybuk: There seems to be some issue remaining with initramfsless boots judging from the latest comment at <https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/503212>. Thatâll need further investigation.
<Keybuk> probably
<ubottu> Launchpad bug 503212 in mountall "mountall crashed with SIGSEGV in main() without initramfs" [High,New]
<Keybuk> but I've been battling Plymouth all day
<Keybuk> and it won
<Keybuk> isn't that the same bug?
<jcole> what the best channel to ask about ubuntu development... dont want to question spam inappropriate channels... ive also asked in #ubuntu-motu
<jcole> what's*
<ion> My branch should fix two things: a nih_assert_not_reached bug dholbach encountered and the segfault initially reported in 503212. Now that it doesnât segfault immediately, someone in 503212 seems to have found further problems with initramfsless boots.
<Keybuk> oh, cool
<Keybuk> if you can keep investigating that'd be awesome
 * Keybuk has to do plymouth as an alpha 2 deliverable
<Keybuk> and I'm on a plane to Sydney from Tuesday ;)
<ion> Yeah, iâll make a VM environment that should be able to boot without an initramfs and see what happens. (My current VM iâve been using to test mountall uses LVM root, i donât think that can be booted without an initramfs.)
<kirkland> superm1: can you point me to the dell 1220 service manual?
<freinhard> hi!
<freinhard> what's the relation between debian/foo.install and debian/foo.dir? i know .install split the files into packages defined in control, but what does the .dir file do?
<siretart> freinhard: see dh_installdirs(1)
<mathiaz> james_w: hi!
<james_w> hello mathiaz
<mathiaz> james_w: I was looking into python-boto branches and run into this error: http://paste.ubuntu.com/353148/
<mathiaz> james_w: "Revisions have no common ancestor:"
<james_w> ouch
<james_w> wth?
<james_w> something is screwed up there
<james_w> I'm not sure what off the top of my head
<mathiaz> james_w: glad to hear it's not *me* :D
<mathiaz> james_w: ok - I'll workaround it
<mathiaz> james_w: what should I do about it?
<james_w> mathiaz: file a bug against udd please
<mathiaz> james_w: ok
<mathiaz> james_w: would this be related to bug 503702?
<ubottu> Launchpad bug 503702 in udd "Collision for python-boto lucid" [Undecided,New] https://launchpad.net/bugs/503702
<james_w> it's quite possible
<mathiaz> james_w: ok - bug 504482 filed :)
<ubottu> Launchpad bug 504482 in udd "python-boto ubuntu and debian branch don't share a common ancestor" [Undecided,New] https://launchpad.net/bugs/504482
<james_w> thanks mathiaz
<mathiaz> james_w: hm - something is wrong in here: http://paste.ubuntu.com/353162/
<mathiaz> james_w: the tags are completly different between debian and ubuntu
<mathiaz> james_w: ha found the problem!
<mathiaz> james_w: I checked out the squeeze *package* instead of the python-boto package!
<james_w> mathiaz: ha!
<james_w> mathiaz: you may find python-boto is out of date anyway though
<mathiaz> james_w: bzr diff -rancestor:../lucid/ debian/ looks funny though
<mathiaz> james_w: for example debian/control is completely removed and added in the diff
<james_w> yeah, there's apparently file-id differences between the two branches
<james_w> it's a problem in the coversion
<mathiaz> james_w: however: lucid$ bzr diff -rancestor:../squeeze/
<mathiaz> james_w: looks good to me
<geser> is there a work-around for bzr failing with "Cannot have multiple roots." when doing a bzr merge-package? (the package is mutter)
<james_w> mathiaz: that is odd
<james_w> geser: I think there was some discussion on that bug today/yesterday, I think there is a proposed fix but not a workaround.
<geser> james_w: have you a bug number at hand? I've only found bug #490039 so far
<ubottu> Launchpad bug 490039 in bzr ""Cannot have multiple roots" in transform.adjust_path" [Low,Confirmed] https://launchpad.net/bugs/490039
<james_w> ah
<james_w> I was thinking of bug 494269, they might be the same
<ubottu> Launchpad bug 494269 in bzr "tree transform cannot change root id" [Medium,Confirmed] https://launchpad.net/bugs/494269
<ebroder> Is anybody else having trouble debootstrapping a squeeze chroot? I'm getting dependency resolution errors. Tried asking in #debian-devel, but didn't get any reply
<ebroder> Oh hmm...never mind. I think this might be my fault...
<freinhard> can somewone tell me why the upload went wrong? http://launchpadlibrarian.net/37597230/upload_1435073_log.txt
<crimsun> just as a sanity-check, it was a source upload, correct?
<wgrant> freinhard: That's probably a Launchpad bug.
<wgrant> freinhard: Can you link me to the build that produced that error, please?
<freinhard> https://launchpad.net/~freinhard/+archive/ppa/+build/1435073
<wgrant> freinhard: Yeah, that's a Launchpad bug that shows up sometimes. A build occasionally gets retried after it completes successfully.
<wgrant> freinhard: Ignore it for now -- all the binaries were successfully uploaded the first time.
<wgrant> So the only result of this bug will be that the build status is wrong.
<freinhard> so the .deb files are actually in the repo
<wgrant> Yes.
<geser> yes, and also published (listed in the Packages file)
<freinhard> how do i make pbuilder use my ppa to satisfy dependencies? /etc/apt.config is a symlink to /etc/apt which contains my ppa in the sources.list
<slangasek> asac: I don't have any ready-to-use scripts for that; the script you describe seems as good as anything
#ubuntu-devel 2010-01-08
<persia> kees: Didn't you have a script that discovered all the ELF objects that hadn't been compiled since your last hardening improvement?  Could we repurpose that for our ARM instruction set plans?
<slangasek> is that level of inspection needed, or is the "not rebuilt since karmic" sufficient?
<persia> Well, we don't actually care about rebuilding stuff that doesn't have ELF.
<slangasek> inspecting the ELF objects will be a lot more expensive, certainly, so is harder to iterate; and I don't think looking for karmic binaries will turn up any false-positives
<persia> For those, -marm vs. -thumb2 isn't going to make a difference.
<slangasek> true, but if you're only grabbing Architecture: any, that's nearly 1:1 with "ELF"
<persia> Fair enough.  I just thought it might be easier to use an extant script than develop a new one, even if it takes longer to run.
<asac> slangasek: ok thanks
<ccheney> doko__: i'm running into some sort of weird build error on lucid, not sure if its a toolchain issue (maybe related to java) or what, i tried 3.2 at first but can't even get 3.1.1 to build on lucid
<ccheney> getting weird errors like this: "dmake:  Error: -- `VA8CLASSFIFILES)' not found, and can't be made"
<ccheney> doko__: any ideas what could be causing that?
<ccheney> doko__: for the 3.1.1 rebuild i just added the minimum needed to get it to build on lucid the distro-config update, apply file update, and rules file update
<ccheney> doko__: it got the same type of weird class not found error as the 3.2 build i tried though
 * ccheney thinks it must be something related to java build stuff
<TheMuso> c/c
<ebroder> Hmm...so I just got an e-mail from someone I sponsored pointing out that when james-w sponsored a bzr merge, the sponsoree was still the committer, but when I follow the instructions at <https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage>, it creates a new commit with me as the committer. What is james-w doing that I'm not?
<RAOF> ebroder: They should still be the committer for the revisions that they committed; you'll have committed a new merge revision, though, right?
<ebroder> Right. But there's not much point in creating a merge revision if I'm not making any changes to their branch. Would I just `bzr branch` their branch and then `bzr push lp:ubuntu/<package>` with that, I guess?
<RAOF> If you wanted to, I guess.
<jml> hi
<jml> I've just posted about Launchpad's development roadmap to the LP blog. If I wanted to make sure that interested Ubuntu developers knew about it, where else should I post?
<persia> jml: Is your post entitled "The Road Ahead"?
<jml> persia, yes.
<persia> Then you're done :)  http://planet.ubuntu.com/
<jml> persia, ok, thanks.
<smoser> Keybuk, is there a way i can tell ureadahead to not reprofile next time?
<smoser> after its told me "ureadahead will be reprofiled on next reboot"
<dholbach> good morning
<smoser> Keybuk, ping. or anyone, i could use some upstart help. on ec2, I can reproduce regularly, the following:
<smoser> - working first boot
<smoser> - install of upstart job that has: start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)
<smoser> - install upstart job that turns on debug on 'startup'
<smoser> - reboot
<smoser> - hang
<slangasek> smoser: why are you saying 'mounted MOUNTPOINT=/'?
<smoser> per advice of Keybuk i thought.
<slangasek> hmm
<smoser> i want my job to run as early as possible such that eth0 is up
<slangasek> I don't know why you wouldn't just be doing 'start on net-device-up IFACE=eth0'
<slangasek> I'm not going to try to guess why Keybuk would have advised you to write it that way
<smoser> because i want to block other things i think.
<smoser> i want to block as much as I can on my job running
<smoser> http://paste.ubuntu.com/353326/ is the debug output
<slangasek> what, specifically, are you trying to block?  If that formulation is blocking at all, it'll block any other non-root filesystems from being mounted... which could also block the network from coming up
<smoser> well, theres only 1 "normal" filesystem
<smoser> in general, the goal is to run as early in the boot process as psossible and be able to affect as much of the boot proccess as possible.
<smoser> this actually does work for me in a kvm instance that ih ave which is really almost identical. other than timing.
<smoser> i think i know what the problem is.
<smoser> in my initramdisk, i was bringing up eth0 and not bringing it down
<smoser> that must have stopped a eth0 up event from ever firing
<slangasek> could be
<pitti> Good morning
<nixternal> pitti: come shovel my driveway, then it will be a good morning :p
<nixternal> though 01:45 and am waiting for a meeting, so even the shoveling won't make it any better :)
<pitti> nixternal: I'd get stuck in all the snow on our front door :)
<ebroder> I am so not looking forward to heading back to Boston this weekend...
<nixternal> yeah, I just looked and the snow is up on the glass...the drifting has started
<nixternal> we got another foot of snow today on top of the 2+ feet we already had...this is getting crazy
<pitti> StevenK: thanks for finishing the netbook renaming transition!
<Shiran> anyone know how can i add ASCII 0 to a string in c++?
<Flannel> Shiran: what are you trying to do with it once it's added?
<Shiran> send it  to a socket
<Shiran> i added "\0" in my string but apparently this doesn't work
<Flannel> Oh wait, we're talking about computers.  Right.
<Shiran> :P
<Flannel> Shiran: you want to append "0", not '\0'
<Flannel> No, no, I was going to mention that strings are static and you'll wind up doing a copy and stuff, but you probably don't care.
<Shiran> that doesn't matter
<Shiran> i want my string to be "blah blah blah ^@"
<ttx> pitti: good morning ! Could you trigger a Server CD respin for me ? The recent one didn't catch the lately-published eucalyptus 1.6.2~bzr1120-0ubuntu6
<persia> You want a string that contains a null byte?
<Shiran> if i write "blah blah blah 0" wouldn't it just be "blah blah blah 0" ??
<Shiran> i want it to contain ^@, i dont think thats null but im not sure
<Flannel> Shiran: That's what you asked for "ascii 0" is 0x30
<Flannel> You want it to have "^@" in it?
<Shiran> yea
<Shiran> ^@ being ASCII 0
<Shiran> right now i have   string shiran = "blah blah \0"
<persia> Shiran: You probably want to ask on a dedicated c++ channel.  That's going to be tricky.
<Shiran> what should it be?
<Shiran> presia: obvisouly i did in 2 of them
<ash211> Do you mean append ASCII 0 to the end of the string, or add to each character by the value of ASCII 0 ?
<Shiran> and i didnt get reply yet
<Shiran> ash: ASCII 0 to the end of the string
<Shiran> this is how the other socket knows i finished sending it a message
<Shiran> it should read ASCII 0
<Flannel> Shiran: what's the hex value for 'ascii 0'?
<Shiran> i dont know
<ttx> slangasek, cjwatson: if you're around, please feel free to trigger a server CD respin as well, since my usual victim (pitti) is not available :)
<ash211> well if your string is called str, why can't you just do a [[str += "0";]] ?
<Shiran> ok someone in C++ channel helped me
<Shiran> it's   mystring + '\0'
<Shiran> this works good
<ash211> oh, that's not ASCII zero, that's a null byte
<ash211> but anyway, glad you got it figured out
<Flannel> Shiran: you might also be interested in str.c_str() (where str is your string)
<Shiran> and why is that?
<Shiran> i know i'm getting char* with it
<Flannel> Shiran: Because it returns the null terminated string
<Shiran> i don't think thats good
<ttx> mvo: about bug 494499
<Shiran> because i use a certain protocol
<ubottu> Launchpad bug 494499 in update-manager "MOTD shows "run-parts: /etc/update-motd.d/91-release-upgrade exited with return code 1"" [Medium,Confirmed] https://launchpad.net/bugs/494499
<Shiran> STOMP protocol
<ttx> mvo: this bug has been targeted to alpha2
<ttx> mvo: an easy fix is to return 0 in all cases, I was wondering if it had any side-effects ?
<mvo> ttx: I'm on the phone right now, I have a look after that
<ttx> mvo: no hurry, thx
<Shiran> so my string goes like   "CONNECT\n" + "login:Shiran\n" + "passcode:passcode\n\n" + '\0'
<ebroder> Whoo! u-u-s queue is empty again :)
<Shiran> if i dont send my string exactly this way, then my server doesn't get the right command to connect me
<superm1> kirkland, no better than you can google it, sorry no special links from my end
<superm1> kirkland, probably support.dell.com and put in that model and it will be right htere
<ttx> mvo: hm, in fact it's not targeted to alpha2, just nominated for lucid
<pitti> ttx: bonjour
<ttx> pitti: hey !
<pitti> ttx: running
<ttx> pitti: thanks !
<pitti> de rien
<tseliot> doko_, cjwatson, slangasek: do you know how to make sure that a library is permanently loaded before another which lives in /usr/lib? Putting the path to the other library in /etc/ld.so.conf.d/ doesn't seem to solve the problem (see libGL.so.1): http://pastebin.ubuntu.com/353366/
<tseliot> shall I use preload and would it be acceptable if I did so?
<doko_> tseliot: LD_LIBRARY_PATH should help, I don't think that LD_PRELOAD is needed
<tseliot> doko_: but shouldn't glibc look in /usr/lib after the paths in /etc/ld.so.conf.d ?
<tseliot> doko_: is it possible that some patches that we have cause it to somehow resort the cache?
<doko_> tseliot: why? it's still one logical config file
<tsimpson> did you run ldconfig after editing the conf file(s)?
<tsimpson> that's what regenerates the cache
<tseliot> yes, of course I did
<tsimpson> as far as my knowledge of LD goes, it should be working then
<tseliot> the file that I put on pastebin ^^ is the output of ldconfig -p after doing an ldconfig
<tseliot> doko_: but I don't see why it should pick up /usr/lib/libGL.so.1 before /usr/lib/nvidia-current/libGL.so.1 if I put /usr/lib/nvidia-current/ in /etc/ld.so.conf
<superm1> what if your rename the cache before running it
<superm1> although i guess it's supposed to rebuild it anyway during the invokation
<tseliot> I can try that
<tjaalton> sounds like /usr/lib|/lib is used before anything else
<tseliot> superm1: same result
<tseliot> tjaalton: right
<doko_> tseliot: even before /usr/local/lib ?
<tjaalton> forgot /usr/local/lib :)
<tseliot> doko_: let me check
<tseliot> doko_: it's loaded after the path that I want to use
<tseliot> libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
<tseliot> libGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.1
<tseliot> libGL.so.1 (libc6) => /usr/local/lib/libGL.so.1
<tseliot> which is correct
<tseliot> since I put my path in GL.conf
<tseliot> which comes before libc.conf
<tseliot> in alphabetical order
<tsimpson> are you sure ldconfig -p prints out in the order which libraries will be loaded?
<tseliot> doko_: oh, I think I know what the problem is
<tseliot> if I copy the library from /usr/lib to /usr/local/lib the former is picked up first
<tseliot> while if I copy the one from /usr/lib/nvidia-current to /usr/local/lib the same doesn't happen
<superm1> how does that explain it?
<tseliot> this happens because these 2 libraries are considered as different libraries:
<tseliot> libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
<tseliot> libGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.1
<superm1> tsimpson has a good point though, you should double check with ldd and something that is linked to libGL.so.1 in case ldconfig -p just prints the cache in the order it likes to
<tseliot> but "ldd /usr/bin/glxinfo" confirms the fact that the wrong library is being used
<Sarvatt> open("/usr/lib/libGL.so.1", O_RDONLY)   = 3
<tseliot> Sarvatt: do you have a theory?
<superm1> tseliot, its possible that mandriva's ldconfig is behaving differently.  they probably use glibc whereas we use eglibc
<Sarvatt> nope its just definitely using /usr/bin/libGL.so.1 first like the ldconfig -p shows here with your packages
<tseliot> superm1: if it considers libGL.so.1 (libc6, OS ABI: Linux 2.4.20) and libGL.so.1 (libc6) as different libraries then there might be something wrong in what ldconfig does
<tseliot> here's what ldconfig --verbose says: http://pastebin.com/d72e5c079
<doko_> tseliot: is the library loaded at all, even if you remove the one in /usr/lib?
<tseliot> doko_: yes, it is. Currently it's the only way to get things to work
<tseliot> doko_: ldconfig still seems to be looking for /usr/bin/libGL.so.1. If I remove /usr/bin/libGL.so.1 (which is a symlink to /usr/bin/libGL.so.1.2) ldconfig recreates the symlink
<tseliot> tjaalton, doko_: I guess it depends on the flags that we use in mesa. Mandriva doesn't have (libc6, OS ABI: Linux 2.4.20) but only (libc6)
<tseliot> ldconfig sort things differently if flags or whatever are there
<tseliot> tsimpson, Sarvatt: ^^
<tjaalton> ask for the config flags of the mandriva package
<tseliot> tjaalton: they use -O2 -g -pipe -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
<tjaalton> tseliot: more than what we seem to have
 * tseliot nods
<apw> pitti, hey, looking at report_tools.py, at the names of the _completions, it seems some return tasks and others not, and there is no hint in the function name
<StevenK> pitti: You're welcome. If it all looks fine to you, I can mark the last work item as DONE?
<StevenK> pitti: Ah, you already did it, thanks!
<StevenK> seb128: You're awesome, thanks (re: gyp)
<seb128> StevenK, thanks ;-)
<asac> Keybuk: we get "Its mountall: Could not connect to Plymouth" on arm ... is that expected/known/filed?
<asac> Keybuk: unping. found that plymouth isnt seeded still
<ogra> asac, with it installed i get: init: plymouth-log main process (3094) terminated with status 111
<asac> ogra: does it break the boot?
<ogra> and still the: mountall: Could not connect to Plymouth#
<ogra> no
<ogra> just adds noise
<asac> good. just scared as it gets added next week to seed
<ogra> Keybuk, ^^^
<asac> so if it would break we would have to blacklist on armel for a2
<ogra> indeed
<sbalneav> mvo: Tested the gksu patch last night.  Works for me!  Ship it!
<mvo> sbalneav: thanks! already uploaded :)
<sbalneav> supah!
<sbalneav> mvo++
<mvo> thanks for your great help on this!
<apw> pitti, about?  i think i've got a first stab at the wiki-status for the 2.0 interface, wondering if you are generating the DB regularly yet?
<pitti> StevenK: :)
<pitti> apw: re
<pitti> apw: hm, which function is unclear? I thought I documented their return value in the docstring, but I'm happy to add improvements
<pitti> apw: db is generated hourly, at http://piware.de/workitems/lucid.db
<pitti> apw: http://piware.de/workitems/ also has all the generated reports
<apw> pitti, any chance we can get that onto chinstrap
<pitti> apw: that's indeed my hope (or, rather, rookery, so that t's publicly http-accessible); pychart isn't on rookery, but the data collection part should be
<files22> NEW TORRENT SEARCH SITE http://Torrentpirates.org
<doko_> pitti: was there some reason that we did demote autogen (besides that we hadn't a dependency on it anymore)?
<pitti> doko_: I can't remember any discussion about it; probably it just fell out of main's dependency set?
<doko_> pitti: ok, could you re-promote it? gcc-4.4 build-depends on it again. somehow I did manage to drop this b-d
<pitti> doko_: done
<doko_> thanks!
<zul> pitti: i was wondering if you had a look at the packaging for autofs5 yet?
<pitti> not yet, sorry
<kirkland> superm1: okay, thanks, i googled some, the signal-to-noise ratio was pretty low, though, thanks.
<BlackZ> hello pitti
<zul> doko: thanks for the review
<pitti> hi BlackZ
<hashimi> Hi everyone
<hashimi> I have a question regarding, how to change my bootsplash. In my special builded linux
<hashimi> i have the usplash folder, and make file. After doing make, where i must apply changes in intrd ?
<pitti> apw: http://macaroni.ubuntu.com/~pitti/workitems/ -- banzai!
<pitti> apw: unfortunately it doesn't build the .pngs yet, it complains about "Ghostscript not found." (pychart needs that apparently)
<pitti> I'll see to installing a local gs as well
<pitti> ... or not; this thing needs a million libraries
<hashimi> I have a question regarding, how to change my bootsplash. In my special builded linux
<hashimi> i have the usplash folder, and make file. After doing make, where i must apply changes in initrd ?
<apw> pitti, how often will this data be updated, at what times?  so i can sync my updates
<pitti> apw: 03 * * * *
<pitti> apw: and takes some 15 mins
<apw> so i should aim for 30
<pitti> that should be safe
<apw> cool ... i'll leave that running and see what happens
<kirkland> Keybuk: howdy
<kirkland> Keybuk: so i was up really late last night fighting something that appears broken, as best as I can tell
<kirkland> Keybuk: but i'm sure i'm just looking at it wrong :-)
<kirkland> Keybuk: start on (started foo and started bar)
<kirkland> Keybuk: let's call ^ baz
<kirkland> Keybuk: so baz has "start on (started foo and started bar)"
<kirkland> Keybuk: okay, let's say that all 3 are running (foo, bar, baz)
<kirkland> Keybuk: I now stop foo, which does in fact stop baz (as desired)
<kirkland> Keybuk: note that bar is still running, was unaffected by stopping foo and baz
<kirkland> Keybuk: now, i start "foo"
<kirkland> Keybuk: foo runs
<kirkland> Keybuk: and baz is still running
<kirkland> Keybuk: shite
<kirkland> kees: baz is *not* running
<kirkland> Keybuk: ^
<kirkland> Keybuk: baz is not running, although foo and bar are
<kirkland> Keybuk: is this the way it's supposed to work?
<apw> kirkland, isn't that the The Upstart Bug again?
<apw> that that means 'both start events occur then do this'
<kirkland> apw: oh?
 * pitti reads "baz" and remembers the old days of arch
<kirkland> apw: yup, that's what i'm hitting
<kirkland> apw: i think i've hit this before in a slightly different fashion
<apw> yeah it sounds like the one you were talking to slangasek about
<kirkland> apw: great, then i'm right back to where I started :-)
<apw> i think semantics clarification of what start on (started a and started b) means is in order
<apw> and i think we have use cases for both obvious semantics
<ion> tjaalton, keybuk: Wasnât udevadm-trigger-in-maintscript evil? xorg-server (2:1.7.3.902-1) * Run udevadm trigger on postinst, and depend on udev [linux-any].
<pitti> njpatel, StevenK: do you happen to have an idea about bug 495066?
<ubottu> Launchpad bug 495066 in netbook-launcher "Lucid netbook-launcher segfaults when started" [Critical,Confirmed] https://launchpad.net/bugs/495066
<njpatel> pitti: asac uploaded a proposed fix from me today
<pitti> njpatel: oh, sweet!
<tjaalton> ion: according to this howto it's safe https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
<pitti> njpatel: hm, not in netbook-launcher then? latest upload is from December 15th
<njpatel> pitti: clutk :)
<ion> Alright
<tjaalton> though the (driver) rules will be gone if/when we integrate the xorg.conf.d stuff
<pitti> njpatel: sweet, thanks
<asac> slangasek: you asked for ooo upload before a2?
<asac> slangasek: i am quite sure that will kill our arm images
<asac> at least there is high risk ;)
<doko_> pitti: autogen needs libopts25-dev libopts25 from universe as well :-/
<pitti> doko_: erm, it's the same source package?
<pitti> all in main now
<doko_> pitti: yes
<pitti> apw: haha! using svg instead of png avoids ghostscript and even looks much better \o/
<apw> pitti, most sneaky
<ion> Using svg for what?
<pitti> ion: burndown charts
<pitti> http://macaroni.ubuntu.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-2.html
<pitti> rickspencer3_: ^ FYI
<slangasek> asac: not having it before a2 leaves us with oversized images - why will it kill arm?
<pitti> rickspencer3_: this also uncovered some WIs we have to do for other teams
<jiboumans> piti: wtb bigger picture ;)
<rickspencer3_> pitti, nice job
<jiboumans> pitti too
<pitti> bryyce: the other day you asked for svg for the burndown charts -- there you have :)
<jiboumans> pitti++ for doing the hard work
<rickspencer3_> pitti, that's a great view
<pitti> http://macaroni.ubuntu.com/~pitti/workitems/ now has the full combinatorial explosion of all milestones and teams, all from a single DB, and super-fast to generate
<rickspencer3_> jiboumans, just zoom in, the picture is svg
<rickspencer3_> pitti, wow
<pitti> and magnitudes easier to configure
<slangasek> tseliot: peramenently loaded before another> before another library of the same name?
<jiboumans> rickspencer3_: you overestimate the cross-browser compatibility of that suggestion =/
 * pitti fixes the y labels on http://macaroni.ubuntu.com/~pitti/workitems/all.html
<slangasek> tseliot: (or did you get your answer to this overnight?)
<tseliot> slangasek: I think I've solved the problem now. The ".note.ABI-tag" in libGL from mesa makes ldconfig believe that it's not the same library as the one from nvidia as the former causes a versioned dependency.
<slangasek> heh, ok
<tseliot> slangasek: if each library lives in its own directory (as long as it's not /usr/lib) and we use ld.so.conf.d to tell ldconfig what to do, things work well
<zul> doko: can you review python-pastedeploy as well it goes hand in hand with python-pastescript
<asac> slangasek: if it fails to build on armel we cannot produce images i was told
<asac> and we probably have just one try
<asac> because of the time it takes to build it
<asac> i think it has binary all packages that would mean that its not installable (i havent checked myself, was just pointed to that problem before)
<asac> maybe we could unseed ooo ... not sure
<asac> i will see if i can get info on that
<slangasek> asac: I believe we've unseeded it before due to breakage; right now we've got two copies of libicu on the disk because OOo hasn't been rebuilt, and that's a fat library
<asac> yeah. i will try to verify that unseeding would work
<slangasek> anyway, OOo took 1d19h to build last time on armel... doesn't that give us two chances?
 * ccheney running a local OOo build with updated dmake now to see how it goes
<pitti> for a few days now, my launchpadlib scripts often get "ValueError: No JSON object could be decoded" exceptions, which seem to be transient, but numerous; did anyone else see those as well?
<jpds> pitti: I'm pretty sure james_w filed a bug about that a few days ago.
<jpds> Can't find it right now.
<pitti> ah, thanks
<geser> pitti: bug #504199
<pitti> *phew*, so I'm not going crazy
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/504199)
<geser> "Redirecting to a 200 response offline.html is a really bad idea for the API"
<pitti> geser: thanks
<smoser> Keybuk, do you happen to be around?
<ttbabie> hi room 18 female here but iam bi
<ttbabie> so whoeva wants pravite me can
<jussi01> ttbabie: not here please, this is a channel for ubuntu development.
<ccheney> slangasek: ok build worked with my updated dmake, will need to add doko's patch and then upload dmake and OOo
<jono> seb128, are you aware of any problems with python-vte?
<jono> I am trying to create a Terminal() in my app and the module says it is not there
<jono> this is on Lucid
<jono> wasn't sure if the module is broken atm
<seb128> jono, no
<seb128> $ python -c "import vte"
<seb128> $
<jono> seb128, its ok, fixe it
<jono> II had a vte.pyc lying around :)
<jono> thanks!
<seb128> cool
<mvo> jono: when python-vte break I usually get upset very quickly :)
<jono> mvo, lol :)
 * mvo uses it in various stuff like update-manager and gdebi
<jono> mvo, I have quick q you might be able to answer
<jono> I have a vte widget and need to feed it a command that it can execute, I am using feed_child to pass it the command, but how do I emulate pressing enter to run it
<jono> or is there a better way of doing this?
<jono> I just want to run a python script inside the terminal and show the output there
<pacejr> does anyone know the status on alpha 2?
<ScottK> lamont: It looks like Ross is hung somehow.  kdewebdev should have depwaited right away and even if it managed to start to build somehow, the package only takes 15 minutes (and it's been over 30).
<smoser> anyone able to offer some guidance on bug 504883
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/504883)
<ScottK> pacejr: What specificly do you want to know about?
<smoser> try again ubottu  bug 504883
<ubottu> Launchpad bug 504883 in upstart "job with "mounted MOUNTPOINT=/ and net-device-up IFACE=eth0" blocks boot" [Undecided,New] https://launchpad.net/bugs/504883
<jono> ooh I see how this works
<james_w> jono: try fork_command
<jono> its like popen
<jono> thanks james_w
<pacejr> ScottK: It was scheduled to be released yesterday, I was curious about what was holding it up and when the actual release would be.
<mvo> jono: sorry, was distracted, what james_w said
<ScottK> pacejr: No.  It's scheduled for next week.
<jono> mvo, no worries :)
<pacejr> ScottK: You're right; my eyes skipped a line. Thanks
<jono> mvo, james_w: I am using: self.terminal.fork_command("python", "/usr/share/python-snippets/pygtk/buttons.py")
<jono> but I get /: can't open file 'u': [Errno 2] No such file or directory
<jono> oh I can pass it a dir
<jono> hmm no luck
<bryyce>  pitti, beautiful svg :-)
<mvo> jono: here is a example http://paste.ubuntu.com/353583/
<mvo> jono: this is how I use it
<jono> thanks mvo
<jono> I will give that a shot
<jono> I was using: self.terminal.fork_command("python", self.current_filename, None, self.snippetsdir)
<bryyce> pitti, the chart only shows from jan 8th though ;-)
<smoser> slangasek, bug 504883 is what i was asking about earlier this AM
<ubottu> Launchpad bug 504883 in upstart "job with "mounted MOUNTPOINT=/ and net-device-up IFACE=eth0" blocks boot" [Undecided,New] https://launchpad.net/bugs/504883
<LeonBrussels> Hi! I am using Epiphany 2.28.0 on Karmic. I am experiencing https://bugzilla.gnome.org/show_bug.cgi?id=605536 in gnome-shell with epiphany. I talked to the gnome-shell guys, a fix is already in 2.28.2 of epiphany. They told me to tell you that to fix it you would have to import f0e7cc5af163c6ed16c4450115b61bfa0822b80a from upstream (or push 2.28.2, I don't know what ubuntu policy is in that regard)
<ubottu> Gnome bug 605536 in general "title in panel does not update" [Normal,Unconfirmed]
<ScottK> LeonBrussels: Did you put all that information in the bug?
<jdstrand> kees: I am trying to investigate bug #504903 and am stumped. if I build it locally in an schroot, the apparmor is included in the build, if I build it in LP, it is not. the LP buildlog is http://launchpadlibrarian.net/37456614/buildlog_ubuntu-lucid-amd64.tcpdump_4.0.0-6ubuntu1_FULLYBUILT.txt.gz
<ubottu> Launchpad bug 504903 in tcpdump "tcpdump no longer ships an AppArmor profile" [Undecided,New] https://launchpad.net/bugs/504903
<jdstrand> kees: the debhelper auto magic stuff is different between my local build and LP, even though the debhelper versions are the same
<jdstrand> kees: this is tcpdump 4.0.0-6ubuntu1 (lucid)
<jdstrand> kees: it moved over the the new 'dh $@' format with this merge, which I haven't used much before
<jdstrand> kees: is there anything obvious in debian/rules that I did wrong?
<jdstrand> kees: (I added the 'binary: install' part
<cjwatson> most dh(1) users don't have a separate install: target IME
<cjwatson> (haven't looked at the rest of it, sorry)
<jdstrand> cjwatson: this is the whole debian/rules file: http://paste.ubuntu.com/353594/
<jdstrand> there is no separate 'install', and I thought this was correct (since 'install' is done behind the scenes, aiui)
<cjwatson> no, you should just drop the install bit
<cjwatson> but that binary: doesn't look right in general
<cjwatson> what I would do is:
<cjwatson> override_dh_install:
<cjwatson>         dh_install
<cjwatson>         cp -a $(CURDIR)/debian/usr.sbin.tcpdump $(CURDIR)/debian/tcpdump/etc/apparmor.d
<cjwatson> actually, why don't you just put 'usr.sbin.tcpdump etc/apparmor.d' in debian/install instead?
<jdstrand> cjwatson: wouldn't I still need to put it in debian/tcpdump/etc... for that to work?
<jdstrand> (the 2nd suggestion)
<cjwatson> sorry, not sure what you mean?
<cjwatson> I meant 'debian/usr.sbin.tcpdump etc/apparmor.d' BTW
<jdstrand> ah, well that clarifies it
<jdstrand> let me try that
<jdstrand> I still find it curious that what I had worked in a clean schroot and not on the buildd
<kees> jdstrand: that is weird.  does using debian/install work?
<jdstrand> building now
<ccheney> doko_: is the patch you referred to the one you sent on nov 1?
<jdstrand> obviously, what I was trying to do was put the profile in place before binary was called
 * ccheney hopes it is, its the only one he could find in his inbox
<LeonBrussels> ScottK: I didn't report the bug, no. Should I post a reply to the bug in gnome-shell or file a new bug for the ubuntu package on launchpad?
<ScottK> LeonBrussels: I missed that that wasn't a launchpad bug.  I'd file an Ubuntu bug on Launchpad.
<jdstrand> cjwatson: debian/install works great. thanks!
<jdstrand> kees: ^
<slangasek> smoser: right, that's going to need Keybuk's input, because I don't see how this could ever work reliably
<LeonBrussels> ScottK: Just so I can suggest the improvement: Would the ubuntu way of doing it be to update Karmic to the new version or patch the version in Karmic or wait for Lucid altogether (not a lot of people are affected anyway, gnome-shell is devel-only anyway)?
<jdstrand> (at least locally, but I'm sure this will work on the buildd too)
<ScottK> LeonBrussels: Either fix lucid only or fix lucid and patch karmic.
<kees> jdstrand: cool
<ScottK> It depends a bit and I couldn't say for sure.
<smoser> slangasek, :-(. well, it works very reliably in my kvm guests.
<Keybuk> I don't see why it wouldn't be reliable?
<slangasek> Keybuk: smoser says this start rule was your suggestion in order to block other services until this job is done; but if that's true, isn't there a problem if bringing up eth0 depends on something else than just 'mounted MOUNTPOINT=/'?
<Keybuk> that rule is very EC2 specific
<Keybuk> after the root mount filesystem is mounted, wait for the interface to come up, download the config for that instance, and continue
<Keybuk> eth0 is never going to depend on anything complicated
<Keybuk> certainly never going to have a split filesystem
<smoser> Keybuk, well, its not working on ec2, while it does work for me in kvm
<smoser> i'm open to other more general suggestions that still allow blocking of other events and running early
<Keybuk> smoser: what doesn't work about it?
<slangasek> Keybuk: does mounted MOUNTPOINT=/ happen before or after virtual filesystems are mounted?
<Keybuk> slangasek: neither
<Keybuk> both
<slangasek> (and if it happens before, does mountall block waiting for that event to return?)
<kenvandine> cjwatson, ping
<cjwatson> kenvandine: hi
<Keybuk> mountall does not wait for virtual-filesystems, no
<Keybuk> so you can do on virtual-filesystems and mounted and ...
<smoser> Keybuk, if i add that job (see bug 504883), it blocks
<kenvandine> hey, i have 3 packages that were ~ubuntu-desktop can upload for karmic and not lucid
<kenvandine> cjwatson, mind fixing ?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/504883)
<kenvandine> indicator-applet, indicator-messages, and libdbusmenu
<kenvandine> cjwatson, ^^
<Keybuk> smoser: why does it block?
<Keybuk> what blocks?
<Keybuk> what's it blocking on?
<smoser> boot stops. i was hoping you could give more info.
<Keybuk> I don't have any more info to give you
<Keybuk> you're the one with the problem, not me ;P
<smoser> i have before and after logs there.
<smoser> with logging level to info
<Keybuk> I can take a look at the sprint for you
<smoser> well, given that it doesn't work, do you have any suggestions for me on something else to try?
<smoser> pretty please?
<Keybuk> without knowing what's broken I can't give any suggestions?
<Keybuk> you're going to need to debug it
<CodAr2D3> Ubuntu-8.10 should update with this: http://debian.cs.binghamton.edu/debian/pool/main/g/gadmin-proftpd/gadmin-proftpd_0.3.8-1_amd64.deb
<cjwatson> kenvandine: will have a look, it may not be easily fixable
<kenvandine> cjwatson, ok, thanks i do appreciate it
<CodAr2D3> Felix sit Annus Novus!!!
<cjwatson> CodAr2D3: we don't update stable releases with new upstream versions, as a rule; we backport specific targeted patches for critical bugs. see http://wiki.ubuntu.com/StableReleaseUpdates
<kenvandine> cjwatson, i have uploaded those for lucid before, dec 10
<Keybuk> smoser: I don't wish to be difficult, btw
<Keybuk> but between now and the sprint, I'm either on leave or at LCA
<CodAr2D3> cjwatson: As upstream id say itll be more fun for the users to have things that works as intended. Dont you ?
<cjwatson> kenvandine: I realise that, but since then more flavours of Ubuntu have started using it and so the software has started considering it as more core than ubuntu-desktop
<smoser> Keybuk, thats ok. thank you for your imte.
<Keybuk> and I have my own Alpha 2 deliverables which are, right now, being a complete pain and difficulty
<Keybuk> and increasingly limited time to get them done
<smoser> Keybuk, ok, the big first thing different between good and bad that i see is good has
<smoser> init: mounted-tmp main process (2127) exited normally
<kenvandine> cjwatson, sure... just in case that info helps
<Keybuk> (ie. one day)
<Keybuk> I don't have EC2
<Keybuk> I don't know anything about EC2
<smoser> and bad has 'mounted-tmp' messages
<Keybuk> I don't have KVM
<Keybuk> etc.
<cjwatson> CodAr2D3: there are multiple ways to achieve this, and I'm afraid that this policy is not normally open to negotiation, but if there's an appropriate bug we can certainly look at backporting the fixes to achieve the same result for ussers
<cjwatson> users
<Keybuk> for me to be able to get up to speed enough to even replicate your problem is more time than I have
<Keybuk> that shouldn't make a difference
<Keybuk> does your job use /tmp ?
<CodAr2D3> cjwatson: Upstreams gets hundreds of emails because Ubuntu fails to just copy in the new packages.
<cjwatson> CodAr2D3: if you make it a matter of "you have to use our new releases or your users are broken", then we may have trouble working with you; but we do successfully work with many upstream releases on the understood basis that we'll backport important patches.
<cjwatson> we do not copy in new releases because, sadly, this policy generally breaks a lot
<cjwatson> I'm an upstream myself, I know that everyone always wants people to use the newest code, but this doesn't tend to be very compatible with the notion of an integrated stable release I'm afraid, so we backport patches
<cjwatson> CodAr2D3: are there bugs filed for these problems?
<CodAr2D3> Hmm, i suddenly feel a need to escalate this issue some notches.
<cjwatson> CodAr2D3: this doesn't feel very constructive
<CodAr2D3> No, go to bed or use your head.
 * ScottK wonders who he thinks he would escalate to.
<cjwatson> charming
<smoser> Keybuk, my *real* job would use tmp, bu tthe example job just does "echo "hello world\n"'
<Keybuk> I believe that the Baby Jesus still has a place in our governance structure
<smoser> with console output
<Keybuk> smoser: your real job cannot use /tmp
<geser> ScottK: the last instance could be God (but I don't think he will intervene in this case)
<Keybuk> but I'm surprised that the echo one fails
<ScottK> One never knows for sure.
<cjwatson> I only see four bugs on gadmin-proftpd, possibly bug 242067
<ubottu> Launchpad bug 242067 in gadmin-proftpd "Gadmin-proftpd don't start testing Ubuntu intrepid 64-bit" [Undecided,New] https://launchpad.net/bugs/242067
<smoser> how would i change it such that i could use tmp? and why couldn't i use tmp at that poitn. i woudl have thought that, csince its the same filesystem, it would be usable as normal
<Keybuk> smoser: you can't
<Keybuk> if you want to block mounting, you must only use the filesystem you're blocking
<ScottK> geser: You should see the hatemail I got after wontfixing a bug that asked for gcc3.3 to be put back into the archive because there's proprietary software that needs the support libraries.
<Keybuk> since you can't guarantee that any other mountpoint is ready yet
<Keybuk> (this includes /proc, /sys, /var/run, /var/lock, etc.)
<smoser> ok, that makes sense to me for proc, sys
<smoser> but /tmp is on same filesystem as / (and so is /var.... and all things)
<Keybuk> yes
<Keybuk> and /tmp gets wiped ;)
<Keybuk> if you're really unlucky, it might get wiped while you're trying to use it
<Keybuk> mountall actually always thinks /tmp is a separate filesystem
<Keybuk> (though I think it's more likely that /tmp will be wiped before, or just after, but I wouldn't bet on that)
<smoser> ok, then to go another route, how can i say i want to run when those things are available.
<Keybuk> if you want to run when those things are available, you can't block
<Keybuk> (just reading through the code - you probably can get away with /tmp, provided you know it's never mounted as a tmpfs or similar)
<Keybuk> but none of this explains why "echo hello world" does not work
<smoser> shoot. well, possibly. let me change it. i wasn't completely truthful
<smoser> echo ========== BEGIN ${UPSTART_JOB}: $(date) ====================
<smoser> possible that sh uses a tmp file for $(date) ?
<Keybuk> shouldn't do ;)
<Keybuk> that should work
<ccheney> Keybuk: UK looks nice and cold ;-) http://news.bbc.co.uk/2/hi/in_depth/8447023.stm
<Keybuk> ccheney: I love how the cities show up in grey
<ccheney> looks like only a few areas not covered in snow/ice near scotland and north wales
<cjwatson> ScottK: this is usually the point when Mark gets a ranty e-mail, I think
<ScottK> No doubt.
<Keybuk> shouldn't Jane get those now? :p
<cjwatson> I'm not sure that people are mailing Mark as the CEO of Canonical
<Keybuk> I HATE YOUR DISTRO YOUR STAFF SUCKS PS GIVE ME MONEY AND SEND ME INTO SPACE UR SO AWESOME!!!!
<tseliot> :-D
<lamont> ScottK: no, it's not ross.  but thank you
<ScottK> lamont: OK.  I'm starting to gather it's more now.  Good luck.
<jcastro> cjwatson: next time you get someone like that please feel free to punt them towards me, I have a whole spiel on explaining that to people, etc.
 * ScottK thinks you should just explain the real solution is for them not to release buggy software in the first place.
<jcastro> yeah
<jcastro> but usually I can explain backports or PPAs to them so they at least know they're available
<cjwatson> jcastro: I think in this case he was pretty unreceptive to start with, but sure
<Keybuk> ccheney: the amusing thing about the cold weather is that some of the papers are proclaiming the end of global warming
<cjwatson> we've all released buggy software from time to time, I imagine
<Keybuk> when one of the "possible" causes for the cold weather is arguably related to global warming
<Keybuk> (if there is such a thing)
<jcastro> cjwatson: I agree, just letting you know you don't have to waste time on that. :)
<cjwatson> Keybuk: the Express being well noted for its scientific approach to life
<slangasek> cold weather is a myth
<ccheney> Keybuk: heh, well cold != warm so it must not be global warming then, see its perfect logic :)
<ccheney> its been below freezing all day here in houston area, too cold for me :)
<jcastro> as an fyi to those interested, I am working on a little cheat sheet document for upstreams so they can understand how we work: https://wiki.ubuntu.com/Upstream/Guide
<Keybuk> cjwatson: there is compelling evidence that the gulf stream has buggered off to the south
<Keybuk> (or is it to the north)
<Keybuk> might be to the north
<jcastro> Keybuk: I saw a pic of your whole island being white the other day
<cjwatson> Keybuk: yes, I saw it, scary stuff
<jcastro> ah right, the nasa one you just linked
<cjwatson> it's currently hitting Greenland IIRC
<ccheney> jcastro: yep here is one http://news.bbc.co.uk/2/hi/in_depth/8447023.stm
<Keybuk> the interesting thing will be whether that's temporary or permanent
<jdstrand> pitti: fyi, it seems that status is reversed in workitems. eg: http://piware.de/workitems/security/lucid/report.html . security-lucid-apparmor-tunables should be 2/0/5 (todo/postponed/done). Also status by assignee is wrong-- eg coffeedude.jerry should be at 100% now (same blueprint)
<jdstrand> hmm, actually, it seems out of date... that should be 3/0/5, but report.html has a timestamp of 08-Jan-2010 21:08 (I'm assuming +1)
<lamont> ScottK: yeah - build-manager was a bit snitty there for a bit.  it's flowing now
<jdstrand> pitti: ^
<smoser> Keybuk, well, i guess i need to request some of your time at the sprint to discuss this more and fins some solution.
<Keybuk> sure, time at sprint is easy :)
<smoser> if you can think of anything i can do in the meantime i'd appreciate it.
<Keybuk> debug! :)
<smoser> i'm fine to change the start on to something that gets me run early on and has access to tmp and var
<Keybuk> lots of echo and stuff
<tjaalton> Keybuk: I know there's a bug about bootlog & upstart, but is there a way to get the bootlog somehow? gdm fails to start most of the time, dropping me in failsafe. note that the logfiles are not updated, so it isn't started at all
<Keybuk> there is no boot log
<tjaalton> but how do I get to see why gdm failed?
<Keybuk> gdm's log?
<tjaalton> it's untouched
<Keybuk> that's not very helpful of it
<tjaalton> I'll try to reproduce it after the uploads.. it doesn't happen every time
<tjaalton> no it's not :)
<tjaalton> and failsafe vesa on intel kms takes the rest :)
<slangasek> tjaalton: I have failsafe X disabled here for that reason
<Keybuk> I know of a bug where gdm just flat out doesn't get started
<Keybuk> though I still can't reproduce it on demand enough to debug it
<Keybuk> it usually happens when I'm trying something else and haven't put the instrumentation in I need
 * slangasek nods :/
<slangasek> I have mountall exiting abnormally for me at the moment, hoping to debug that this afternoon
<tjaalton> slangasek: ah, so I'm not the only one. that's a relief
<slangasek> tjaalton: to which part?
<lamont> ScottK: and now it'll bitch at me the next time.
<tjaalton> slangasek: oh, hmm :) well I do remember seeing some mountall failures
<Keybuk> slangasek: ion has been doing some debugging along those lines
<slangasek> tjaalton: ok - hopefully I'll be fixing a bug for more people than myself :)
 * Keybuk sings the bugs song
<slangasek> bugs song?
<sistpoty> all your bugs belongs to Keybuk, lalalala?
<sistpoty> :P
<lamont> sistpoty: don't you mean his mom?
<sistpoty> haha
<Keybuk> too many bugs, not enough Keybuk
<lamont> what if we cut him into little itty-bitty pieces?
<Keybuk> same amount of keybuk ;)
<Keybuk> just in smaller bits
 * slangasek douses Keybuk in planarian hormones
<Keybuk> heh, if I had clones, I'd just make out with them </xkcd>
<sistpoty> Keybuk: oh, btw, do autosyncs still happen? and do they pickup -XbuildY versions as versions to sync?
<sistpoty> (looking at guvcview atm)
<Keybuk> sistpoty: autosyncs have never been auto, but entirely manual
<sistpoty> Keybuk: oh, I see... should I file a sync request then? or will it be handled manually automatically *g*?
<Keybuk> sistpoty: we're after freeze, so sync request I think
<Keybuk> slangasek is *the* guy to ask about this kind of thing, of course
<sistpoty> ah, thanks!
<slangasek> we're after which freeze?
<ScottK> lamont: Would you please rescore kde4libs on ia64.  If I can get that in ahead of gcc it should save a bunch of build failures later.https://launchpad.net/ubuntu/+source/kde4libs/4:4.3.90-0ubuntu1/+build/1436376
<slangasek> Keybuk: import freeze isn't until Feb 11
<slangasek> milestone freeze isn't until Tuesday :)
<Keybuk> oh, I thought import freeze was christmas or something
<sistpoty> <- didn't see import freeze on the wiki recently, but now it's there :)
<sebner> Keybuk: we are sycing from testing, doesn't destroy even that so so far away from release :P
<slangasek> Keybuk: it's delayed this cycle because of the testing Thing
<Keybuk> ah
<tweakt> is it possible to use the python-apt library 'apt.*' api with a custom configuration, or do I need to stick to the low level 'apt_pkg' api?
<Keybuk> maybe it's jaunty's release schedule I'm thinking of
<cjwatson> kenvandine: turns out your wish is granted after all. HAND
<kenvandine> cjwatson, excellent!
<kenvandine> cjwatson, thx!
 * jdstrand is pretty sure we are past Juanty's feature freeze
<jdstrand> err... Jaunty's
<Keybuk> exactly :D
<jdstrand> :)
<ebroder> Jaunty's DIF was Christmas day, I think
<Keybuk> yeah that's what I was thinking of
<mvo> tweakt: that should work, however apt_pkg.Configuration needs to be used, that is not exported but will be picked up by the apt.* stuff
<cjwatson> yes, I remember we had to justify it to people going "hang on, you can't schedule something for Christmas Day"
<mvo> tweakt: (if not, please let me know with a example what dosn't work)
<cjwatson> by pointing out that this was an event where you *stopped* doing work
<Keybuk> after a while, all the releases merge into one great big panic
<tweakt> mvo: so how should I access apt_pkg.Configuration ? I'm using apt_pkg.Config right now
<jdstrand> where are lucid's netboot images? (I *never* can seem to remember where they are, and I know I wrote it down somehwere...)
<elmo> jdstrand: dists/lucid/installer-$arch/
<ebroder> Hmm... cdimages.ubuntu.com/netboot/lucid doesn't exist
<elmo> jdstrand: dists/lucid/main/installer-$arch/current/images/netboot/
<elmo> specifically
<jdstrand> cool, found it
<jdstrand> elmo: thanks!
<cjwatson> ebroder: yeah, we should create that, it's all manual
<cjwatson> (prefer cdimage.u.c btw)
<jdstrand> that was where I looked first-- found the stable releases of course...
<tweakt> mvo: apt_pkg.newConfiguration() ?
<slangasek> Keybuk: does the disappearance of the Vcs-Bzr field on mountall imply the lp:ubuntu/mountall branch is now authoritative?
<slangasek> hmm, I see some 'debcommit -r' log entries, so I guess so :)
<elmo> hey, my panels no longer move when I drag them
<elmo> anyone know how to unstick them?
<slangasek> alt-drag? (WFM)
<cjwatson> ebroder: I've pushed up http://cdimage.ubuntu.com/netboot/lucid/; it should get populated shortly
<ebroder> cjwatson: Awesome, thanks
<slangasek> Keybuk: server team is keen to have bug #503212 fixed for alpha-2, which is the one ion has a merge proposal for; do you have any insights/observations on that branch that aren't expressed in the merge proposal, or if not, do you mind if I review it and upload if I think it checks out?
<ubottu> Launchpad bug 503212 in mountall "mountall crashed with SIGSEGV in main() without initramfs" [High,Confirmed] https://launchpad.net/bugs/503212
<ion> That branch fixes the initial segfault, but there are still other problems when running without an initramfs. I havenât had a chance to debug them yet, but iâm planning to.
<slangasek> ok
<slangasek> ion: do you have any more detail on what the further problems are?  I don't have a ready initramfs-less test system
<ebroder> Hmm...that's weird: "bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/bochs": bochs in ubuntu has no default branch."
<ebroder> Import bug?
<ion> slangasek: Iâd prefer Keybuk to review my first commit in that branch, he might have a different idea of how to fix new_mount()s-after-mount_policy(). The second commit should definitely be Keybuk-safe if you will. :-P
<slangasek> ion: well, I would also prefer Keybuk review it, but I'm not sure he'll be available to do so :)
<ion> slangasek: Iâve encountered an assertion failure from nih_free (i.e. a double nih_free somewhere) that still didnât kill mountall, so it seems to happen in a forked subprocess. Thatâs all i know so far, it needs actual debugging.
<slangasek> ok
<ion> slangasek: Oh, and the second commit is the only one needed to fix the #503212 segfault. The first commit fixes another bug thatâs not related.
<ebroder> Oh, do 3.0 (quilt) packages not get imported into bzr yet?
<neXyon> hello
<mothinator> I have a few questions about how merges/syncs occur: 1.) Does ubuntu sync with debian testing or unstable? 2.) When does syncing occur? Thanks.
<sebner> mothinator: normally with unstable but now for the LTS with testing. Hmm, no fixed times, every few days afaik
<neXyon> is any real ubuntu developer here? just interested
<sebner> neXyon: what do you understand under "real" ?
<neXyon> one that updates official packages
<geser> and what are "fake" developers? :)
<neXyon> ones not allowed to update official packages :D
<sebner> neXyon: "official"?
<neXyon> those in the official package repos :D
<sebner> neXyon: you are currently speaking with 2 ;)
<neXyon> okay
<neXyon> I request an update of the openal package
<sebner> neXyon: in this channel "higher" devs too though
<tweakt> Still trying to figure out how to get the high level python-apt api to use a custom configuration (so it runs as non-root, with an isolated config)
<neXyon> for ubuntu 08.04 - current
<cjwatson> neXyon: please use the bug tracking system for such things
<tweakt> any help *greatly* appreciated... tnx
<cjwatson> any update to a stable release requires a bug report anyway
<neXyon> I'm sure the bug report is there already
<crimsun> neXyon: are you referring to #503780 ?
<neXyon> my recommended solution as you don't update package versions is to change the default configuration of openal (soft) to use alsa, not pulse as the pulse backend is broken in openal soft (excluding current SVN)
<crimsun> (the default backend *is* alsa)
<crimsun> it's just being routed through the pulse pcm plugin, which is currently broken
<mothinator> sebner: There is a package in unstable that I'd like be merged in for lucid, do I just file a "please merge" bug report on launchpad?
<neXyon> then fix that one
<crimsun> both upstream alsa and pa know of it; we're quite close to a solution
<elmo> slangasek: hmm, sorry, I didn't realise/remember I needed a keyboard modifier, thanks
<sebner> mothinator: I think so, what package?
<neXyon> I then wonder why setting alsa in the openal config file helped fixing the bug in the application I'm developing
<crimsun> neXyon: I appreciate your enthusiasm, but it has never been as simple as "just fix it already?!?!?!"
<crimsun> neXyon: we can debug further whether it opens default or *hw: in a separate place
<mothinator> sebner: texlive-publishers. Revtex (installed in texlive-publishers) has updated to 4.1 in October, but the old package is still in debian testing.
<ScottK> mothinator: Why didn't the new one get in.
<sebner> hola ScottK :)
<neXyon> crimsun: well, at least, if the bug is fixed in alsa/pulse/whatever will you then update all affected versions of ubuntu?
<crimsun> neXyon: erm, I uploaded openal-soft last night to Lucid; anything further regarding other released versions of Ubuntu will need to go through the StableReleaseUpdates procedure
<Keybuk> ion: what did you need me to review?
<neXyon> crimsun: you mean openal 1.10?
<neXyon> (soft)
<crimsun> neXyon: openal-soft (1:1.10.622-1ubuntu1) lucid; urgency=low
<mothinator> ScottK: Good question. I'm just an end user that would like to see it get updated and I was curious how the process works. Is there a particular place to find out why?
<cjwatson> texlive-extra is stuck in a big dependency cycle
<ion> keybuk: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/+merge/16868 Do you agree with what i did in #254?
<cjwatson> it's trying to go into testing at the moment
<cjwatson> but it failed today, on the grounds of making a few hundred more packages uninstallable
<neXyon> crimsun: ahh yeah, have you checked out openal soft svn too? that version is really fixed, as there are still bugs with pulse in 1.10
<cjwatson> http://ftp-master.debian.org/testing/update_output.txt but it's not easy to read
<cjwatson> (I have interpreted it above for you)
<mothinator> thanks
<Keybuk> ion: #255 is "obviously right"
<crimsun> neXyon: "in 1.10" is quite ambiguous, but no, I have not done an "svn up" in the past day.
<cjwatson> see http://lists.debian.org/debian-release/2010/01/msg00005.html and thread but there isn't much more informative there
<neXyon> crimsun: which revision did you build?
<Keybuk> ion: 254 is a bit heavy
<Keybuk> ion: probably better to just have mounted() ignore TAG_UNKNOWN :p
<cjwatson> we could sync directly from unstable, but the point of syncing from testing this cycle is to insulate us from this kind of bug that tends to be very time-consuming to sort out, so it would be better to wait
<Keybuk> since the tag is largely irrelevant
<Keybuk> (mounts found from parse_mountinfo() are already mounted)
<neXyon> crimsun: because 1.10 is revision 622
<mothinator> cjwatson: so does that mean it is unlikely to make it into lucid?
<cjwatson> mothinator: it doesn't hurt to file a bug asking for it, of course, but perhaps wait until after Debian import freeze in case it gets in by itself (http://wiki.ubuntu.com/LucidReleaseSchedule)
<ion> keybuk: Ok, iâll make all cases of tag checking handle UNKNOWN properly instead of that.
<cjwatson> mothinator: you're reading more into what I said than I actually said. :)
<crimsun> neXyon: I thought my paste was pretty clear regarding which revision
<Keybuk> ion: yeah, I think I meant to do that, and just forgot
<Keybuk> "unknown" was there to literally mean "it wasn't there when we started"
<Keybuk> (otherwise I'd've just used a different default)
<crimsun> neXyon: also, I presume you meant to refer me to the git repo on repo.or.cz ?
<neXyon> crimsun: ah yeah xD my mistake; well that version is buggy as I said
<neXyon> crimsun: yeah you're right
<neXyon> man, I should go to bed :)
<crimsun> neXyon: there's considerable churn since the release 8 weeks ago
<mothinator> cjwatson: fair enough. I just need to write some papers over the next year and this update would make my life easier. Also, I am clueless about development, so thanks for your help in sorting this out.
<neXyon> crimsun: anyway, any expectation when this will be an update for the official repos so that affected users will get that fixed
<Keybuk> cjwatson: btw, since you're here, I'm sure you know already, but installs aren't working atm
<alkisg> crimsun, hi, I've heard of 3 ways to solve the SDL problem in Ubuntu and LTSP etc: 1) Put libsdl1.2debian-pulseaudio as the first dependency of libsdl1.2debian => would break [k|x]ubuntu, at least for now, 2) Put libsdl1.2debian-pulseaudio in the Ubuntu CD seeds => maybe SDL isn't needed on the CD,
<crimsun> neXyon: what do you mean by "update for the official repos"?
<alkisg> 3) Put libsdl1.2debian-all as the first dependency and either patch libsdl1.2debian to prefer pulse, if it's available, or/and set SDL_AUDIODRIVER=the preferred output method in the environment.
<alkisg> Is there any chance that any of the above methods are included to Lucid?
<sistpoty> Keybuk: I assume I can't bribe you to merge trousers for me? (my tiny change is picked up, but I have not much clue about your udev changes though)
<neXyon> crimsun: I'm not too much into ubuntu... I mean when do normal users that just do normal updates get a fixed system?
<cjwatson> Keybuk: I don't, I have been completely buried in contract work for the last week
<crimsun> alkisg: setting environment variable isn't terribly intrusive
<crimsun> neXyon: that will need to go through the StableReleaseUpdates process, as I mentioned earlier
<cjwatson> Keybuk: no rows for it on daily-installer?
<crimsun> neXyon: so no, I have no ETA
<alkisg> crimsun: I offered to test if [k|x]ubuntu work with out of the box with libsdl1.2debian-all, but the current live CDs don't work with my hardware. I'll report in LP #203158 when alpha 2 is out. Thanks! :)
<ubottu> Launchpad bug 203158 in pulseaudio "libsdl1.2debian-pulseaudio must be installed as default by libsdl1.2debian" [Undecided,Confirmed] https://launchpad.net/bugs/203158
<alkisg> (a change in the libsdl1.2debian dependencies order will be needed)
<cjwatson> neXyon: stable updates are *minimum* seven days from the time the upload enters the verification process; this is to protect users from mistakes. So certainly not before that
<Keybuk> cjwatson: no, ubiquity never finishes or runs the failure script
<Keybuk> I'll nag evan on monday
<crimsun> alkisg: changing the alternates order seems nasty; I'd prefer to export a variable conditionally
<cjwatson> Keybuk: it's probably best, this week has not been composed of short days
<alkisg> crimsun: the variable only works with -all, it won't work if -alsa is installed.
<Keybuk> cjwatson: I know the feeling
<alkisg> crimsun: So a change in the dependencies would be required for -all to be installed, when someone installs e.g. tuxpaint.  libsdl1.2debian-all is in main, so it shouldn't be much of a problem..
<neXyon> cjwatson: I am happy with 2 months :D
<crimsun> alkisg: it really makes more sense to explicitly seed the appropriate backend, then
<tseliot> cjwatson: can you accept nvidia-graphics-drivers (it's in NEW), please?
<cjwatson> tseliot: I have a rule, I don't do archive admin that requires thought when exhausted
<alkisg> crimsun: I'm fine with explicit seeding, and sdl is currently on the CD, but maybe when gimp is out people will also want sdl out of the CD?
<cjwatson> tseliot: sorry ...
<tseliot> cjwatson: it's a good rule. Thanks anyway
<tseliot> Keybuk: ^^ or maybe someone from a different time zone could help me
<Keybuk> what's a time zone?
<Keybuk> I'm going to decline as well; I need to eat and actually go do things that don't involve work :p
<tseliot> I don't know, but it sure sounds good when I say it :-P
<tseliot> fair enough
<crimsun> alkisg: I'd rather focus on fixes instead of hypothetical crackfulness
<alkisg> crimsun ++ :)
<tseliot> slangasek: ^^^
 * sebner is afraid of testing tseliots newest driver :P
<tseliot> sebner: just reboot without testing, I know you love it :-P
<sebner> hahaha
<sebner> tseliot: btw, my *new* harddrive has 1 bad sektor since that day ;)
<sebner> *sector in english
<slangasek> tseliot: hmm, let me poke first to see whether the xorg upload has fixed my crash-on-lid bug :)
<tseliot> slangasek: ok, thanks
<sebner> slangasek: you could also try the blob as I said but leave out the 40 reboots I did because tseliot was overexitced and broke stuff all the time :P
<tseliot> sebner: that's a scar of war. Treat it with respect ;)
<tseliot> soren can confirm that everything works fine now
<sebner> heh
<soren> Affirmative.
 * sebner ^5 soren 
<tseliot> but yes, we had a rather interesting session
<tseliot> testing session, that is
<sebner> heh
 * sebner hugs tseliot :)
 * tseliot hughs back sebner
<tseliot> hugs
<sebner> he
<sebner> h
 * tseliot restarts X
<slangasek> sebner: no, *I'm not running nvidia* :)
<slangasek> tseliot: great, xorg-server is fixed for me, I'll happily approve anything X-related I find in NEW now <whistles>
<tseliot> slangasek: thanks a lot :-)
<tjaalton> slangasek: would you be willing to test applying just that gamma-fix patch on top of .901 to be sure it's the one that fixed it, and not some other commit from .902?
<slangasek> tjaalton: if you insist... :)
<tjaalton> slangasek: it would probably help in getting a quick review for the patch upstream :)
<slangasek> cjwatson: do you know why lintian is broken on cocoplum suddenly? (Can't locate Digest/SHA.pm)
<cjwatson> I do not, haven't touched it, sorry
<elmo> that's most likely me
<elmo> slangasek: try now
<slangasek> elmo: better, thanks :)
<elmo> hmm, I've actually no idea why that broke
<elmo> or that package is needed
<slangasek> in karmic and above it's part of perl itself, and we're using a lintian "backport"
<slangasek> but I don't know what changed that made lintian start wanting it /since the last time I ran lintian/
<slangasek> maybe because I haven't done sourceful new in a while
<elmo> is the lintian backport locally installed?
<slangasek> tseliot: tsk, new package using debhelper 4?
<slangasek> elmo: yes, on lp_archive's path
<elmo> ah
<tseliot> slangasek: I can update that
<tseliot> it won't be a problem ;)
<tseliot> I need something working in time for alpha 2
<slangasek> tseliot: shouldn't the copyright holder be "Canonical Ltd"?
<slangasek> (in debian/rules)
<tseliot> slangasek: I work for Canonical Services Ltd
<jpds> elmo: Alt-dragging penals was a design decision in Jaunty; bug #321032.
<ubottu> Launchpad bug 321032 in gnome-panel "gnome-panel unable to drag and drop for placement" [Wishlist,Invalid] https://launchpad.net/bugs/321032
<jpds> panels*
<neXyon> cjwatson, crimsun: thx for the infos, gn8 now :)
<cjwatson> tseliot: if you've already been explicitly told otherwise, ignore this, but it's my understanding that all copyright of Canonical group companies is owned by Canonical Ltd. regardless of which particular company you work for
<cjwatson> tseliot: I wish https://wiki.canonical.com/LegalServices/Licensing were a bit more explicit - wonder if there's something ele
<cjwatson> else
<slangasek> been looking, been not finding :)
<elmo> jpds: ah, I see, thanks
#ubuntu-devel 2010-01-09
<tseliot> cjwatson: as I said in #distro, I'll fix it
 * cjwatson nods
<mathiaz> is anyone else receiving LP emails four times?
<jpds> mathiaz: Known issue.
<kirkland> slangasek: i'm trying to clean up some atrocious conffile handling in eucalyptus
<kirkland> slangasek: i need a little help
<slangasek> kirkland: nothing a judicious use of rm -rf won't fix
<kirkland> slangasek: ever the optimist!
<Claviceps> POWERAID POWERAID POWERAID
<Claviceps> POWERAID POWERAID POWERAID
<Claviceps> POWERAID POWERAID POWERAID
<Claviceps> POWERAID POWERAID POWERAID
<Claviceps> POWERAID POWERAID POWERAID
<Claviceps> POWERAID POWERAID POWERAID
<kirkland> slangasek: okay so here's the question, i'll try to state as simply as possible
<slangasek> !ops | Claviceps
<ubottu> Claviceps: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<kirkland> slangasek: /etc/eucalyptus/eucalyptus.conf is currently a conffile, though much maligned ... it most certainly should not be
<kirkland> slangasek: i have a large patch that's in the process of fixing this
<kirkland> slangasek: in the preinst, if upgrading from an older version, i want to move the contents of known conffile eucalyptus.conf to eucalyptus-local.conf
<kirkland> slangasek: then i want my package to install the new, clean, better managed conffile eucalyptus.conf into it's old location
<slangasek> so /etc/eucalyptus/eucalyptus.conf will remain a conffile, check
<kirkland> slangasek: will that work?  or will dpkg refuse to install on top of a mv'd (removed) file?
<kirkland> slangasek: check.
<kirkland> slangasek: it will look like this now: http://paste.ubuntu.com/353722/
<slangasek> kirkland: I can't say off the top of my head; it will *either* give you a conffile prompt about the diff between <null> and <new version>, or it will fail to install the new conffile at all
<kirkland> slangasek: okay
<slangasek> kirkland: test and see?
<kirkland> slangasek: i'll try it
<kirkland> slangasek: sure
<kirkland> slangasek: can i run the rest of my solution by you?
<kirkland> slangasek: to make sure that the rest is sane?
<slangasek> and if possible, restore the pristine conffile in the preinst, to avoid conffile prompts altogether
<slangasek> yes, go ahead
<kirkland> slangasek: "restore pristen conffile" means cat >/tmp/foo <<EOF .... EOF ?
<kirkland> slangasek: ie, just write it out there?
<slangasek> if you've already preserved all the local changes by moving them to -local.conf... yes
<slangasek> kirkland: sorry, I'm being evicted from here; will try to be online in ~15min
<kirkland> slangasek: coolio
<kirkland> slangasek: okay
<kirkland> slangasek: not an emergency
<slangasek> kirkland: ok back
<kirkland> slangasek: okay, so the patch i'm currently testing is http://paste.ubuntu.com/353732/
<kirkland> slangasek: i can explain what i'm doing, or you can look at that and digest it
<kirkland> slangasek: the changelog entry is pretty comprehensive, though
<slangasek> kirkland: digesting intermittently
<kirkland> slangasek: okey
<kirkland> slangasek: testing now
<kirkland> slangasek: fixing a couple of minor typos
<slangasek> kirkland: corner case: if eucalyptus was removed and then is being reinstalled, preinst will be called with a non-empty $2 but postinst will be called with an empty $2
<slangasek> (OTOH, preinst $1 won't be 'upgrade', either)
 * kirkland ruminates upon that
<kirkland> slangasek: help me out ... what are the consequences?
<slangasek> kirkland: if a user has removed-but-not-purged eucalyptus, then installed the new version, they'll get the conffile prompt for /etc/eucalyptus/eucalyptus.conf and none of their old settings will be transferred to /etc/eucalyptus/eucalyptus-local.conf
<kirkland> slangasek: ah, hmm...  okay, yeah, i've been purging in all of my testing here
<kirkland> slangasek: okay, when that happens, preinst will be caled with $1 = install, right?
<slangasek> correct
<slangasek> $1 = install && [ -n "$2" ]
<slangasek> kirkland: rest of the diff looks ok to me
<kirkland> slangasek: so, my preinst conditional should be install | upgrade
<kirkland> slangasek: /etc/eucalyptus/eucalyptus.conf
<slangasek> kirkland: yep
<kirkland> slangasek: coolio
<ccheney> the new thinkpads are on lenovo's site now :)
 * ccheney drools on the w510
<ccheney> quad core, color calibration, led backlit, 1gb nvidia graphics (ugh), etc
<ccheney> and can use two 9 cell batteries at once
<RAOF> To power that 1gb nvidia graphics chip :)
 * RAOF is very happy with his x200s.
<ccheney> i have an x200 now
<ccheney> the w510 also is 1920x1080 multitouch :)
<RAOF> I'd love a laptop as small as my x200s, but with a 1920x1080 15" screen.
<RAOF> Obviously the screen would need to fold up, or something.  But Lenovo should make it happen!
<ccheney> its not horrible but is 6lb 2.72kg
<ccheney> and only does ~ 5hr on 9cell
<ccheney> 10hr with the two 9cell setup
<RAOF> Better than my 15" asus, which did a little more than 3hr on the brand-new 9cell, but not quite the 7hrs I get from the 6cell on this lappy.
<ccheney> they haven't updated tabook for the x210 yet :-\
<ccheney> well linux seems to always do much less than windows for power mgmt so probably real world of 3-4hr
<RAOF> Boo.  I got real-world 7hrs.  I wonder what Windows would've got?
<ccheney> i think i get ~ 6hr or so on my x200 but its rated for ~ 9.5 iirc on windows
<ccheney> and it uses much more at the wall under linux than what i hear it uses under windows
<ccheney> t410 is rated at 11hr on 9 cell and 22hr with 2 9cell
<ccheney> thats pretty nice, too bad the resolution is only 1280x800 :-\
<ccheney> hmm i misread the tabook its harder to read than their website since its not consolidated
<ccheney> looks like t410 can do up to 1440x900 screen
<wgrant> Oh, they went back to nVIDIA? :(
<ccheney> wgrant: yea
<RAOF> No Intel or ATi options?
<ccheney> well i think it is switchable graphics for the dual core options, quad core can't have integrated period with new intel cpus
<ccheney> since the integrated graphics are now integrated onto the cpu and the quad cores don't have that option
<ccheney> i think the dual core models are probably switchable but i don't know for certain
<wgrant> My T400 is switchable Intel/ATI.
<wgrant> (I've worked out the ACPI magic to power the card up/down and switch the one that's connected to the LCD, but am yet to discover how to convince the card to POST)
<ccheney> oh
<ccheney> a nice feature is w510 also has 4 dimm slots so you can upgrade to 8gb cheaply
<RAOF> That is nice.
<crimsun> fta: alsa-plugins fix uploaded
<crimsun> so for those not really following along, the last of the core userspace alsa changes has been uploaded, so we have good pulse pcm routing through alsa
<crimsun> this fixes a regression since linux 2.6.27 (8.10 or whereabouts)
<fta> crimsun, lucid only?
<ccheney> coffee shop wifi finally came back up, heh
<bryyce> heya ccheney
<bryyce> ccheney, rather late at night to be at a coffee shop!
<ccheney> bryyce: coffee, alcohol, and geek meeting, heh
<ccheney> iirc they stay open until 2am
<ccheney> bryyce: when did you get an extra y?
<bryyce> ccheney, my laptop must have stole my other nick
<bryyce> or someone else stole it...  "bryce :Nickname is already in use."
<ccheney> ah
<crimsun> fta: it'll be SRUd to 9.10 at least
<tweakt> If I add packages to mini.iso (pool,dists,etc) will it then behave as a standard installer cd?
<tseliot> any archive admins around?
<sebner> tseliot: is the new Xserver (update from today) supposed to work (with nvidia blob)? ^^
<tseliot> sebner: yep
<sebner> heh great :)
<htrejh> hi
<didrocks> cjwatson: the custom.conf regression happened again with the last 15autologin change. I opened a bug explaining it and proposed a quick fix (bug #505140)
<ubottu> Launchpad bug 505140 in casper "No more autologin in live CD" [Undecided,Triaged] https://launchpad.net/bugs/505140
<freinhard> hi!
<freinhard> i just baught a tevii s660 dvb-s2 card. the manufacturer kindly ships linux drivers including GLP2 dvb-s2api stuff and tools and two firmware files without mentioning their liscense. any chance to get the drivers into the firmware package?
<persia> freinhard: Getting anything in without a license is exceedingly unlikely.
<persia> That should only happen if nobody notices.
<freinhard> isn't there any "common" liscense that everything is distributed as, if no liscense is mentioned?
<persia> *if* you have license to redistribute and have license to offer the license to redistribute to Ubuntu, you could file a bug against the firmware package and attach the firmware to be included.
<freinhard> ok, so i should ask themanufacturer about that
<persia> Yep.  Under the Berne Convention, the common license is roughly something like  "You may use this personally, but may not duplicate or distribute commercially without explicit authorisation from the copyright holder"
<persia> Please do.
<freinhard> ok, the COPYING file explecitely mentions that the firmware is not GPLv2
<persia> *Lots* of firmware isn't GPL.  Being GPL isn't a requirement for firmware in Ubuntu.
<persia> The key license requirement for firmware (as I understand it) is that Ubuntu has been granted the right to 1) redistribute and 2) permit others to redistribute
<persia> And it usually requires special arrangements if that authority is granted only to Ubuntu, rather than granted to anyone who happens to have the firmware.
<persia> (or at least anyone who received it under the license that Ubuntu has received it)
<freinhard> so there just needs to be a permission to redistribute the firmeware and it can go into linux-firmware-nonfree?
<persia> That's my understanding.
<freinhard> ok, i'll email the tevii sales about that.
<persia> And my recommendation to get it there would be to confirm and document the licensing, and file a bug for it to be included, along with the results of your research.
<persia> freinhard: Be sure when emailing them that you request not only that it be licensed for redistribution, but also that it be licensed such that the right to redistribute may be granted to those to whom it is redistributed.
<persia> Otherwise there are issues with archive mirrors, etc.
<freinhard> oh ok, i'll keep that in mind and do that once i got an answer to my first request i just sent.
<persia> Best of luck!
<freinhard> is there a dvb group for linux i can contact for packaging the GPLv2 drivers and tools?
<freinhard> s/linux/ubuntu/
<persia> I don't know much about DVB, but Google tells me http://www.linuxtv.org/ might be a reasonable place to start investigating
<persia> For Ubuntu, I don't know of a team that does that, although there are certainly some individuals who do.
<freinhard> thank you for you help, i think i'll just package it and put it in my ppy. cu!
<persia> freinhard: Well, if you've a clean package, you could also submit to REVU or Debian
<persia> Err, gone.
<persia> And this is part of why I don't like PPAs :)
<tweakt> are there build artifacts on cdimage.u.c that are the d-i bits but for a regualar installer cd, not a netboot? Hoping to use these as a base of my custom CD.
<pitti> bryyce: only jan 8> yes, as I wrote on platform I didn't bother to write a DB migration script
<tweakt> looking for an initrd.gz, etc
<pitti> jdstrand: it says 3/0/4 right now, which seems correct to me when looking at the whiteboard
<pitti> jdstrand: perhaps you just changed it recently before looking at it?
<htrejh> hi
<htrejh> i get undefined referen to's when building using debuilder, and the dev package is in the deps
<htrejh> what can be the problem?
<ScottK> pitti: Would you please rescore mesa.  It's breaking lots of other stuff as it is and it'd be nice to get it in the archive ASAP.
<tseliot> ScottK: are you an archive admin?
<ScottK> tseliot: I am.
<tseliot> ScottK: can you approve my nvidia packages, please?
<tseliot> the source was approved but the new packages were not
<ScottK> Let me look.  Becuase I don't have shell access, I'm somewhat limited
<tseliot> thanks
<tseliot> ScottK: https://edge.launchpad.net/ubuntu/lucid/+queue
<ScottK> Looking
<tseliot> nvidia-graphics-drivers, nvidia-graphics-drivers-173, nvidia-graphics-drivers-96
<ScottK> tseliot: No.  I can't.  I can't do New when I have to change the pocket and something lands in more than one.
<ScottK> Pocket/Component
<tseliot> ScottK: ah, right, the modaliases
<tseliot> ScottK: thanks anyway
<ScottK> Yes, exactly.
 * tseliot -> dinner
<cjwatson> didrocks: hmm. I *really* don't like using echo -e; it has a habit of producing weird side-effects later when things are run under a shell you didn't expect. How about this trick to ensure that the same syntax is acceptable in either case?  sed -i "\$s/\$/\n$AutologinParameters/" >> $GDMCustomFile
<cjwatson> tweakt: http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/cdrom/ (we use these for our own CD builds too ...)
<htrejh> hi
<htrejh> what is the best naming for a svn version of a program on my ppa?
<jpds> htrejh: version~svnREVISION~ppa1.
 * matti hugs jpds 
<htrejh> thanks
<Guest39900> hello can anyone hear me
<mneptok> not now
<sistpoty> hearing on irc is pretty much non-trivial ;)
<Tm_T> sistpoty: not really, just put your irc-client speak everything out loud
<sistpoty> heh
<charlie-tca> I can't get xchat to talk to me at all
<Tm_T> charlie-tca: time to file a bug then (;
<mneptok> charlie-tca: look at the app's name. you don't want it talking to you. it talks dirty.
<mneptok> "Oh yeah, baby. You know the right port. Oh yeah ...."
 * charlie-tca thinks you mneptok might be right
<r2wj> who will apply my patch? :(
<r2wj> I made a bug report and a patch
<r2wj> and now.. it just sits there
<r2wj> What happens next? Nobody will tell me
<crimsun> -ECONTEXT
<ramvi> There's a bunch of debs in this repo: http://archive.geteasypeasy.com/1.6/pool/main/ubuntu/archive.ubuntu.com/ubuntu/pool/main/a/ant/
<ramvi> They're symlinked in. They don't show up in the browser, and can't be downloaded, 403, why is that?
<sistpoty> ramvi: 403 is usually permission denied. Ask them?
<ramvi> sistpoty: Them is me. That's why I need help. Want to set up an ubuntu mirror
<sistpoty> ramvi: oh, I see... not too sure to be honest, probably eitiher a problem with your mirror script or a.u.c has on purpose disabled permissons for ant (not that I'm aware of that, but checking permissions there might give clues)
<sistpoty> ScottK: mesa: maybe-fixed. I'm ashamed, test-build never succeeded for me, but for contributors, see #ubuntu-x. I never did upload anything that didn't build for me before that though :/
<MattJ> Nafallo: Any chance of Gajim 0.13.1 in Lucid?
<sistpoty> is my mesa upload somehow stuck in a queue I'm not aware of?
<crimsun> which source version?
<sistpoty> mesa_7.6.1~rc3-1ubuntu3
<crimsun> to lucid?
<crimsun>       mesa | 7.7-0ubuntu2 | http://us.archive.ubuntu.com lucid/main Sources
<sistpoty> crimsun: thanks, that explains it all... somehow my source archive was all the time out of date
<sistpoty> probably I'm an idiot :)
#ubuntu-devel 2010-01-10
<joshua__> I've a recommendation: make a thing similar to ubuntu-minimal but for use in a chroot enviornment
<joshua__> otherwise, do-release-upgrade inside a schroot = bye bye host bootloader
<mdke> does anyone know who maintains http://patches.ubuntu.com/?
<Laney> mdke: I think it is linked with MoM, so Keybuk
<Laney> (is it out of date?)
<mdke> Laney: thanks. Not sure if it's out of date but I had a bug report about it that I want to reassign
<ScottK> mdke: MoM is currently unmaintained, so that is too.
<mdke> ScottK: I see. Well I've reassigned the bug reports anyway and I sent Keybuk an email to confirm
<ScottK> OK.  Good luck.
<mdke> :)
<tweakt> How can I use python-apt (or apt-get) to download udebs?
<tweakt> got it...  need main/debian-installer in compontents for sources.list
<dotblank> Hello can anyone help me with building PA from apt-get source
<dotblank> I need to compile a jack-module-sink module that the official debs do not have
<ScottK> dotblank: This isn't a support channel.
<dotblank> Oh ok.. sorry I was hoping some of you would have some Ideas.. Also why is there no jack module for pulse in the repos..
<cody-somerville> pitti, lp #476530 looks like it should be a backport and not an SRU.
<ubottu> Launchpad bug 476530 in bzr-builddeb "mark-uploaded fails with "Unknown target distribution: lucid"" [Undecided,Confirmed] https://launchpad.net/bugs/476530
<ScottK> dotblank: It's not in the repos because JACK isn't in Main, so pulse can't build-depend on it.
<Chipzz> mdke: MoM is unmaintained and KeyBuk doesn't care; I suggest not bringing up the subject unless you want to hear him rant about it
<Chipzz> (and that's in no way meant negatively about KeyBuk; he just has too much other work)
<ScottK> Chipzz: I don't think he doesn't care.  If he didn't care, you'd get silence, not the rant.
<Chipzz> s/doesn't care/doesn't have the time/
<Chipzz> same difference, I'ld suggest not bugging him about it
<geser> does an easy way exist to see all Ubuntu delta for a package? I used the linked patch on PTS when sponsoring syncs or merges
<dotblank> well I figured it all out but maybe there should be a pulseaudio-module-jack not in main.. Its just bothersome to this everytime I want to set up jack... oh well
<dotblank> to do this*
<ScottK> dotblank: There is some work ongoing to get JACK in Main for Lucid.  Not sure if it will pan out or not.
<mdke> Chipzz: well, I'm not too bothered - I've just reassigned bugs from the wrong project to the right one. If the right one isn't maintained, there isn't anything I can do about that
<machina> /debian Should I reassign this bug to unclutter or mark it as a wishlist? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384428
<ubottu> Debian bug 384428 in xsensors "xsensors needs "unclutter -noevents"" [Minor,Open]
<machina> Maybe I should reassign it because it's present in many GTK+ apps? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266118
<ubottu> Debian bug 266118 in unclutter "unclutter: Blinks pointer and causes 100% CPU usage" [Normal,Open]
<bsmith093> will lucid and jaunty coexist fine with grub 2
<napsy> Hello. What kernel will the upcomming ubuntu have?
<bsmith093> has anyone spoken yet bc i only see system astuatu messages
<bsmith093> nevermind
<micahg> napsy: I think 2.6.32
<napsy> hm I've read somewhere that 2.6.33 will be used?
<bsmith093> can i dual boot jaunty with lucid and grub2
<bsmith093> or will there be problems
<sebner> napsy: nah, it'll be .32
<napsy> oh ok
<kkszysiu> hello
<kkszysiu> is possible to specify id using DesktopCouch?
<kkszysiu>         r = Record(defaults, id = self.id)
<kkszysiu>         record_id = self.database.put_record(r)
<kkszysiu> not working :/
<lamont> new lucid chroots, btw
<ScottK> lamont: Is that why artigas is off the job?
<soren> geser: Are you running Lucid? Does your gnupg work for you these days
<soren> ?
<soren> geser: Er... OpenPGP card, I mean.
<lamont> ScottK: nah - that's unrelated
<ScottK> OK
<lamont> ScottK: yeah - looks like artigas fall down go boom.
<lamont> let me go stab it
<lamont> ScottK: either artigas is on the way back, or it needs more love than I care to give it on a sunday afternoon
<ScottK> Thanks
<geser> soren: I don't have yet lucid on my desktop but I could attach my smart card reader to my netbook where I have already lucid and test it.
<soren> geser: I just seem to have to kill scdaemon every once in a while, which I've never had to do before.
<cjwatson> Chipzz: capitalising it as KeyBuk indicates an unawareness of the source of the nick, so maybe it would be better to use the same capitalisation he uses. :-)
<superm1> i'm trying to join this distributed development bandwagon, but when i try to follow the last step from https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage: bzr: ERROR: Unknown target distribution: lucid
<superm1> do you have to be on lucid to be uploading to a lucid branch?
<geser> either use "debcommit -r" or the patch from bug #476530
<ubottu> Launchpad bug 476530 in bzr-builddeb "mark-uploaded fails with "Unknown target distribution: lucid"" [Undecided,Confirmed] https://launchpad.net/bugs/476530
<superm1> oh is that all that mark-uploaded does?
<superm1> will do that then, thanks
<Chipzz> cjwatson: hrrrrm, I thought that was how it was capitalized :)
<Chipzz> guess that shows you can't know it all :)
<Chipzz> cjwatson: I hope you don't mean this? http://www.earth.li/projectpurple/progs/keybuk.html
<Chipzz> :)P
<cjwatson> Chipzz: I believe it was the older DOS command rather than that particular program, but yes
#ubuntu-devel 2011-01-03
<Keybuk> cjwatson: I always find the final resolution of the "Mount time in future" bug entertaining
<Keybuk> not because of the bug itself
<Keybuk> but because after years of bitching about Ubuntu
<penguin42> which one is that?
<Keybuk> it turned out that the bug was in the ext4 code after all
<cjwatson> did you see the resolution of the dpkg-fsync-slowness bug?
<Keybuk> no?
<Keybuk> did Ted blame Bunnies?
<cjwatson> it turned out that fsync was slow after all and now dpkg uses sync_file_range and prays nothing explodes
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009#75
<Keybuk> eep
<ion> Oh? I inferred from Tedâs messages that the sync_file_range way is Correctâ¢ and Rainbows and Ponies.
<Keybuk> I enjoy how Ted thinks it's reasonable behaviour for a filesystem to require the filesystem maintainer themselves to have to investigate obscure sequences of little-used commands to get reasonable behaviour
<cjwatson> ion: after years of saying that applications should just use fsync
<ion> I mean, of course it would be good if the filesystem didnât go to Las Vegas to meet some alcohol and drink some hookers every time you do an fsync, but is what dpkg does now not secure in terms of worst-case filesystem corruption?
<cjwatson> oh, I'm sure it is  [note: this comment should not be taken to mean actual sureness]
<Keybuk> ion: the irony is that dpkg doesn't care about filesystem corruption
<Keybuk> all dpkg actually cares about is that things happen in a sensible order
<cjwatson> i.e. atomicity not durability, as several people pointed out in that bug to resounding silence
<cjwatson> "i.e." is probably wrong but that's the relevant property heree
<Keybuk> I suspect the problem is that filesystem developers don't actually understand the difference
<Keybuk> they're so (naturally) focussed on durability, they don't understand the need for atomicity
<penguin42> is it atomicity or just ordering?
<Keybuk> in dpkg's case it's just atomicity
<Keybuk> you have a "FILE" A at a "PATH" (where "FILE" is both content and meta-data, etc.)
<cjwatson> obviously ordering matters too but I think posix's guarantees are sufficient there
<Keybuk> dpkg adds a new "FILE" B
<Keybuk> all dpkg wants guaranteed is that if it places "FILE" B at "PATH", in case of any error or system crash, etc. either A or B are at "PATH"
<penguin42> ah ok
<Keybuk> the belief was that rename() was sufficient for this, because it happens to provide that atomicity for POSIX file operations
<Keybuk> but filesystem authors claim what applies to POSIX file operations doesn't apply to POSIX file systems
<Keybuk> (which is a valid, but irritating claim)
<lifeless> Keybuk: have you followed the debian-devel thread on dpkg performance?
<Keybuk> lifeless: no
<lifeless> it got v. messy ;)
<Keybuk> I can believe it
<lifeless> and now there is another thread about the general pattern being 'broken'
<lifeless> etc
<Keybuk> :-)
<lifeless> cjwatson: how feasible would it be to carry a barrier() patch set, do you think?
<cjwatson> I'm not carrying anything Ubuntu-specific here
<cjwatson> no way
<cjwatson> I didn't follow the debian-devel thread because I figured it was a cesspit; but I was of the understanding that 1.15.8.7 pretty much resolved the practical problems
<lifeless> for dpkg
<cjwatson> no idea, you'd have to ask a dpkg developer
<lifeless> I mean 'the problems for dpkg are resolved'
<lifeless> bzr has the same issue, as does git
<lifeless> gnome config files too
<cjwatson> I don't know and don't really want to know :)
<cjwatson> the whole thing depresses me and makes me want to do something more fun, like chewing nails
<lifeless> :)
<CarlFK> cjwatson: a friend wants to give up programming in favor of raising goats.  I am thinking he is onto something.
<lifeless> but are they web scale?
<CarlFK> it is much more fun than chewing nails.
<CarlFK> lifeless: what country are you in?
<lifeless> nz
<ion> Iâm already doing goats 2.0
<CarlFK> the mogo is webscale ting was done by a friend of mine
<lifeless> cool
 * lifeless waves
<lifeless> afk for a while
<CarlFK> I have a mongo db shirt wiht a blank back.  I know where the silk screen thing is to fix it :)
<psusi> blast... still no new e2fsprogs
<Keybuk> ugh, I hate just how much stuff you need to do to initialise an init daemon these days :-/
<MattJ> dbus yet? :)
<Keybuk> MattJ: how do you mean?
<MattJ> nm, upstart at least does indeed depend on dbus
<Keybuk> indeed, all IPC to/from upstart is via dbus
<Keybuk> either via the bus daemon or a private peer-to-peet socket
<didrocks> good morning
<uBUXUBu> this 10.04 is a good
<uBUXUBu> nice job
<pitti> Good morning! Happy new year!
<ebroder> happy new year, pitti
<uBUXUBu> i want to submit something, i have the initial draft done now.
<pitti> siretart: happy new year!
<pitti> siretart: can you please reupload x264 with a fixed LP: # syntax in the changelog for bug 690296? Thanks!
<ubottu> Launchpad bug 690296 in x264 (Ubuntu Maverick) "libx264 2:0.98.1653+git88b90d9-3ubuntu1 messes up bitrate when encoding (at least using mencoder)" [High,Triaged] https://launchpad.net/bugs/690296
<tkamppeter> pitti, happy new year.I got a patch to fix bug 465916 from Tim Waugh, applied and uploaded it and it has taken me most of the time between XMas and Year++ to fix several, bugs, especially segfaults in the patch. Now ity works great.
<ubottu> Launchpad bug 465916 in Avahi "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [Unknown,New] https://launchpad.net/bugs/465916
<pitti> tkamppeter: gesundes Neues!
<pitti> tkamppeter: yep, I saw; I'll upload it to sid soon, thanks for this!
<pitti> nice to have a good avahi integration in both directions now
<tkamppeter> pitti, before you could only actively create a queue pointing to a printer or a remote CUPS queue which advertized itself by DNS-SD. Now CUPS can automatically/implicitly offer a queue locally if a remote CUPS server broadcasts via DNS-SD only (usually Mac in default config). In addition, the local queues are advertized via DNS-SD and so appear on a Mac automatically.
<pitti> tkamppeter: right, the latter was missing with the old "bonjour compat" patch, right?
<tkamppeter> pitti, onot only the latter, only tyhe first one (you create actively a queue, using the discovery by the *backend*) was available. CUPS (the *daemon*) did not automatically pick up the DNS-SD broadcasts of a Mac.
<tkamppeter> pitti, Now it is the case that if you shre a printer on a Mac, you get it automatically (if you accept broadcasts). If you share a printer, the Macs in the network (which accept broadcasts) get it automatically.
<siretart> pitti: "frohes neues" to you as well! :-)
<pitti> siretart: danke :)
<siretart> pitti: reuploaded now
<siretart> pitti: do you know if kenvandine is on vacation or something? he didn't react at all to my pings regarding this bug
<pitti> siretart: he probably was until today; he should wake up in a few hours
<siretart> ah, I see
<pitti> @all heads-up: the WI tracker has kept crashing for the last few days; someone apparently changed the launchpadlib checkout on people, and didn't test it
<udevbot> Error: "all" is not a valid command.
<elmo> pitti: it's the python-launchpadlib from lucid - see the motd
<pitti> elmo: it's using /home/platform/desktop/versions/lpbinding/launchpadlib/ apparently
<elmo> pitti: ah, ok
<pitti> I'll deal with it, but lunch first
<elmo> pitti: well FWIW, the box is now on lucid - that may be the root cause
<pitti> elmo: ah, did that change recently?
<pitti> elmo: I get tons of warnings, too; lucid should be recent enough, so that we can drop the local checkout and PYTHONPATH hackery
<elmo> pitti: yeah, over the holidays
<pitti> elmo: "change recently" -> i. e. did lillypilly get a lucid upgrade recently?
<pitti> elmo: ah, thanks for the heads-up
<geser> is the DIF already in effect?
<cjwatson> geser: yes - I'll send a mail about it tomorrow
<geser> cjwatson: do you know when the last sync was done? (so I know from when I should look at debian-devel-changes for important changes)
<ScottK> barry: https://launchpad.net/ubuntu/+source/git-buildpackage/0.5.12/+build/2106718/+files/buildlog_ubuntu-natty-i386.git-buildpackage_0.5.12_FAILEDTOBUILD.txt.gz looks like it might be python2.7 related.
<BlackZ> geser: https://lists.ubuntu.com/archives/natty-changes/2011-January/004535.html - seems like this is the last one done
<Laney> BlackZ: that isn't an autosync though
<Laney> the last autosync run is what is relevant here
<geser> BlackZ: this one looks like from a sync request as we don't auto-sync from Debian experimental
<BlackZ> geser: ah, do you mean the last auto-sync? :)
<Laney> O_O
<geser> BlackZ: yes
<geser> so I can look for any security-related uploads to Debian which we should get too (if possible)
<barry> ScottK: thanks
<ScottK> barry: You're welcome.  I figure it's a new year and you're looking for stuff to do.
<barry> ScottK: i was hoping to skate along at least until next week. :)  happy new year to you
<ScottK> ;-)
<diwic> are comboboxes known to be broken in natty?
<diwic> Makes it kind'a hard to do anything :-)
<mvo> hey popey - thanks for the nice blog post about squid-deb-proxy. looks like you hit bug #666014, there is a sru for this, I will check why its not in the -updates archive yet
<ubottu> Launchpad bug 666014 in squid-deb-proxy (Ubuntu Maverick) "Avahi service for squid-deb-proxy does not start" [Medium,Fix committed] https://launchpad.net/bugs/666014
<popey> mvo: np, thanks for making it :)
<diwic> ok, it wasn't all comboboxes
<hggdh> cjwatson: good morning, can you please see bug 694772?
<ubottu> Launchpad bug 694772 in debian-installer (Ubuntu) "Sudden reboot during server ISO install" [Critical,Triaged] https://launchpad.net/bugs/694772
<cdbs> doko: ping, I have seen a few package uploads that have in changelog: Fix FTBFS due to binutils-gold. If I try to investigate the upload, I find that the package neither has binutils-gold in b-d, nor is it mentioned anywhere in the source. Infact, the package uses the standard linker (not ld.gold) and the ftbfs fix seems to be a simple fix for ld --no-add-needed. So, this means two things: 1) I am mistaken 2) The uploader falsely thinks ld.gld 
<cdbs> In other words, I mean to ask: is gold the standard linker in natty? or is the uploader in such cases getting confused?
<doko> "ld --no-add-needed" and "gold" should have the same behaviour in this regard
<doko> no, gold is not the standard
<cdbs> of course it ain't
<cdbs> doko: but doesn't gold have many more changes than that? is this an effort to ease moving to gold in the future?
<ScottK> cdbs: People are incorrectly using gold as a synonym for "ld --no-add-needed" in their changelog entries.
<cdbs> :o
<cdbs> Thanks for the confirmation ScottK
<doko> cdbs: yes, but don't make all changes at once
<cdbs> thanks doko
<ScottK> doko: Thanks for fixing up gpgme1.0.
<micahg> doko: since we're already on the topic of the toolchain, I've noticed people patching the Makefiles instead of configure for linker flags and not adding the libraries as build depends, is there a standard for this?
<doko> micahg: depends on the context which approach is the correct one. any concrete example?
<micahg> doko: http://launchpadlibrarian.net/61382381/gnome-web-photo_0.8-0ubuntu5_0.8-0ubuntu6.diff.gz
<ScottK> micahg: I would say though that if one makes a package link against another one it ought to be added to build-depends (I don't think that's context dependent).
<micahg> right, I thought that was part of the point of not violating encapsulation
<ari-tczew> IMO if package built fine without adding new Build-Depends then is OK
<micahg> ari-tczew: that defeats half the purpose of adding the libs in the first place
<doko> micahg: I think the patch does the right thing, and yes, maybe the libs shouldn't be specified directly, but some macros (X11_LIBS?) used instead. but otoh, there's already one library mentioned explicitly
<micahg> right, I was thinking that's a bad example, let me dig up another one
<ari-tczew> doko: what's the conclusion: do we have to add linked library to Build-Depends or not?
<ScottK> ari-tczew: If you don't, you're depending on the fact that some other package you build-depend on pulls it in.  You've no guarantee that won't change in the future, so not adding them is a fragile solution at best.
<doko> ari-tczew: well, it doesn't hurt, but otoh these should already be fulfilled by dependencies
<ari-tczew> ScottK: OK, got it!
<micahg> doko: here's a patch that builds fine, but I haven't sponsored since I thought it was wrong: http://launchpadlibrarian.net/61338534/firestarter_1.0.3-8ubuntu2.dsc.debdiff
<tumbleweed> I'm happy to have inferior interim solutions in Ubuntu if we can get tell upstream about the issue, and get a better fix down the line
<doko> +-FIRESTARTER_CFLAGS = @FIRESTARTER_CFLAGS@
<doko> ++FIRESTARTER_CFLAGS = @FIRESTARTER_CFLAGS@ -lX11
<doko> micahg: this is the only wrong thing which I can see
<doko> the change in .am is correct
<doko> now you could look at Makefile.in, if it has an X11_LIBS macro and use this instead
<micahg> doko: ok, so we don't have to change configure to add -lX11 to FIRESTARTER_LIBS?
<ari-tczew> tumbleweed: changes which we are adding could be included upstream? or upstream should prepare another way to fix?
<tumbleweed> ari-tczew: yeah, obviously forward your solution, and do the best you can, but upstream probably knows their build system better than you do
<doko> micahg: well, you can do this too, yes. but then, add a check for X11 too
<micahg> doko: ok, is one way any more correct?
<doko> micahg: both approaches fix the issues with --no-add-needed correctly. I assume the upstream likes fixing configure.in more
<micahg> doko: ok, thanks
<doko> adding x11 to PKG_CHECK_MODULES should be enough
<rickspencer3> doko, hello
<doko> rickspencer3: hi
<rickspencer3> doko, thanks for the work on LibreOffice, too bad about your vacation though
<rickspencer3> anyway, good news, I think the desktop team has a maintainer starting maybe this week for Libre Office
<doko> rupture of muscle fiber ...
<rickspencer3> doko, that sounds painful
<doko> rickspencer3: afaik it's Feb 01
<rickspencer3> doko, oh well, Feb will be here before we kjnow it
<rickspencer3> thanks for getting us started!
<ScottK> doko: What's the issue with KDE integration?
<doko> ScottK: see the issue list. I don't have build log anymore
<doko> ScottK: re-enable kde in debian/rules and check ...
<ScottK> doko: The natty bug doesn't have a build log.  Was the error the same as in the lucid bug?
<doko> ScottK: no, therefore the separate report
<ScottK> Sigh.
<doko> ok, starting a build ...
<mvo> popey: uploaded new version to maverick-proposed it would be nice if you could give it a go once it hits the archive so that this bug can (hopefully) be closed
<doko> ogra: shadow build failure ("first thing to fix in 2011" ;p)
<ogra> doko, yeah, yeah, i just finished my vacation, give me a day to wade through the 5000 mails that piled up
<ogra> doko, und frohes neues  :)
<doko> you too
<mvo> does anyone know why avahi-browse would return a IPv4 record that starts with fe80:: (a ipv6 address)? that does not seem to make a lot of sense
<doko> ScottK: patch attached
<ricotz> doko, thanks for the libreoffice packages!
<tseliot> cjwatson: is there a problem with installing empty files in packages in Natty? As I'm getting the following: http://launchpadlibrarian.net/61568238/buildlog_ubuntu-natty-amd64.fglrx-installer_2%3A8.801-0ubuntu1_FAILEDTOBUILD.txt.gz
<geser> tseliot: does that file exist in your debian/ directory after a fresh unpacking of the source package?
<SpamapS> so I'm working on the eglibc component of bug #672177 .. the postinst needs to not call 'telinit u' if init is upstart .. but I'm wondering about how we support an upgrade from hardy ... if upstart is installed before the new eglibc .. then 'telinit u' won't work..
<ubottu> Launchpad bug 672177 in upstart (Ubuntu) "libc6 upgrade causes umount to fail on shutdown because init cannot be restarted" [Critical,In progress] https://launchpad.net/bugs/672177
<tseliot> geser: ah, good point, let me check. BTW it works fine if I add a line that's commented out
<geser> tseliot: when looking more closely at the error I wonder about the double debian in "debian/tmp/debian/fglrx.grub-gfxpayload"
<tseliot> geser: that should be fine
<tseliot> I guess
<asac> directhex: hey ... someone claimed you managed to get banshee working?
<asac> (on arm)
<geser> tseliot: I fetched now the source package and there is no debian/fglrx.grub-gfxpayload file. My guess it that empty files don't get created by the diff.gz
<directhex> asac, i haven't observed issues with it when testing with an efikamx. just sorta works
<asac> directhex: hmm. strange. thats ubuntu or debian on it?
<asac> e.g. armv7 binaries?
<tseliot> geser: ok, good catch then. I'll add that line and fix the FTBFS
<tseliot> thanks
<directhex> asac, maverick
<directhex> my arm equipment is at home, and i'm in cambridge this week
<asac> kk
<asac> GrueMaster: ^^ ... *shrug*
<asac> ogra: ^^
<SpamapS> oohh.. init was already upstart in hardy.. so we only have to consider the dapper upgrade to lucid case..
<janimo> micahg: hi, is firefox planned to be built against the xulrunner package (I remember you said tbird does not work that way)
<ScottK> SpamapS: dapper to lucid is not a supported upgrade path.
<ScottK> SpamapS: It's have to be dapper -> hardy -> lucid.
<micahg> janimo: no, why?
<janimo> micahg: the usual, to not have to fix the same bugs twice :)
<SpamapS> ScottK: this may be an issue for dapper -> hardy .. but I think actually its ok anyway.
<janimo> in this case armel ftbfa
<micahg> janimo: ah, yeah, we're stuck with that if we want to use the firefox branding ;)
<micahg> janimo: is that all we need to fix it, that flag in the bug?
<SpamapS> ScottK: the sequence of events is .. upgrade libc and init (upstart or sysvinit), run configuration of libc6, touch /var/run/init.upgraded, then tell user to reboot, which runs 'telinit u'
<janimo> micahg: well, I set that flag and the build is happily marching on well past thte failure point
<janimo> with the proper mach arg visible on the output
<micahg> janimo: awesome, thank you, I'll upload later tonight if chrisccoulson doesn't get to it first
<SpamapS> ScottK: what may be broken is that telinit may not have the capability to restart sysvinit, which is what I'm concerned about.
<janimo> micahg: great, thanks
 * ScottK nods
<janimo> micahg: the flag is explicitly set by upstream on android builds but not for regular linux
<SpamapS> ScottK: and given that dapper is going EOL in approximately 6 months (right?) we may have a lot of people doing upgrades over the next year. ;)
<ScottK> SpamapS: Yes, but you need to solve it for Hardy, not Lucid.
<micahg> janimo: ah, idk if we can ask for that since different distros build for different ARM compatibility versions
<SpamapS> ScottK: indeed, I'm looking at that scenario right now.
<janimo> micahg: indeed, I was just mentioning it
<micahg> janimo: thank  you, it's still nice to know why stuff is the way it is even if one can't do anything about it :)
<janimo> so mozilla know about the flas, luckily we are not the first ines tetsing with armcv7+thumb2
<janimo> s/flas/flag/
 * micahg still has to get his arm box working
<doko> asac: is the banshee mir now complete?
<doko> asac: please could you have a look at the libwpd mir?
<asac> doko: yes, took the assignment
<doko> ok, promoting banshee
<ogra> bah
<ogra> all that arm ignorance
<asac> ogra: i tried hard
<ogra> yeah, just wanted to rant a bit :)
<cdbs> lool: Why did you assign bug to yourself?
<cdbs> I said I am working on it :)
<cdbs> lool: I just attached the correct debdiff, could you look at it, please?
<lool> cdbs: I didn't see you were working on it, I was working on it as well; I've actually uploaded a real fix rather than a workaround
<cdbs> lool: which is?
<cdbs> lool: Does that fix the selftest issues as well?
<lool> cdbs: Defining different readline() functions
<lool> cdbs: I didn't check whether it fixes selftest
<cdbs> lool: but still, the selftests fail, and that is a serious issue
<cdbs> lool: it causes corruption of the .bzr directories
<cdbs> it was better for bzr to be unusable than to have data corruption
<cdbs> That was the main reason I opted for a temporary workaround
<lool> cdbs: Indeed
<cdbs> lool: noooooo! That is exactly the fix which I tried earlier!
<cdbs> lool: It will build well on all archs except i386, where it will report many test failures
<cdbs> but the problems it will report are applicable for all archs
<lool> cdbs: I reverted to ubuntu1 and uploaded an ubuntu3 using python2.6 with your second debdiff
<cdbs> okay thanks lool
<cdbs> finally, we will have a good and usable bzr
<cdbs> :)
<SpamapS> looks like the package-import failed in a weird way for eglibc
<SpamapS> http://package-import.ubuntu.com/status/eglibc.html#2010-12-17 18:14:30.871947
<soren> cjwatson, persia, cody-somerville, bdrung, geser: DMB meeting in #ubuntu-meeting.
<kees> pitti: hi! around? what's the state of the karmic proposed kernel?
<bdmurray> Riddell: does bug 692636 really need a maverick task?
<ubottu> Launchpad bug 692636 in cmake (Ubuntu Maverick) "backport 2.8.3" [Undecided,New] https://launchpad.net/bugs/692636
<ari-tczew> bdmurray: it doesn't.
<bdmurray> ari-tczew: okay thanks, that is what I was thinking
<SpamapS> mmmm eglibc build
<SpamapS> Finished at 20110103-1205
<SpamapS> Build needed 01:46:26, 1871068k disc space
<SpamapS> hrm, so upgrading to natty switched me to unity, which doesn't play at all nicely with my nvidia multi monitor setup. :-(
<hallyn> SpamapS: 'ubuntu classic desktop' doesn't give you your old desktop?
<geser> SpamapS: there is still the "Ubuntu Classic Desktop".
<SpamapS> Yes I just think unity is way sexier. ;)
 * SpamapS is searching for bug reports right now before reporting
<kees> doko: does gcc-4.5 compile for you on natty? I'm seeing:
<kees> configure: error: cannot compute suffix of object files: cannot compile
<doko> kees: huh? which arch?
<hallyn> SpamapS: yeah, as soon as that settles down a bit, i'm hoping to do a tiling compiz module and have my dream wm at last :)
<kees> amd64. I suspect my chroots
<kees> doko: also, I've almost got gcc-4.6 ready with the hardening patch updates
<kees> doko: should I just email you the diff?
<doko> kees: for other archs I would suspect the binutils update, but that ftbfs on amd64
<doko> kees: or a bug report
<kees> will LP let me open a bug for a package no in the archive yet?
<doko> use gcc-snapshot
<kees> okay
<jcastro> SpamapS: the only multimonitor regression I have in Unity is the panel stretching over both panels, if you have more please report them
<SpamapS> jcastro: I'm using the nvidia proprietary drivers..
<jcastro> me too, twinview?
<SpamapS> yeah
<SpamapS> when I enable the second monitor, which has a different resolution, I get the band across the screen and the icons on the left display wrong
<SpamapS> will screenshot.. looking through a few of the other nvidia related bug reports
<jcastro> oh, does the launcher appear as if it's using the resolution of the smaller monitor to determine its size?
<SpamapS> Also for some reason even though chrome is my default browser links clicked open firefox.. but thats unrelated. :-P
<jcastro> yeah I have that one too
<tumbleweed> anyone know a bug number for that?
<tumbleweed> aah bug 670128
<ubottu> Launchpad bug 670128 in chromium-browser (Ubuntu) "gnome-open uses firefox while it's not the preferred browser" [Medium,Confirmed] https://launchpad.net/bugs/670128
<kees> doko: okay, LP: #696990 for gcc-4.6 with hardening re-enabled.
<doko> \o/
<kees> the only weird part is relro.
<doko> ?
<kees> it looks like it used to be applied on top of the gold-and-ld patch
<kees> so I tried to make it a little more agnostic (which also removes the linaro-specific bit)
<doko> yeah, I need to update that one and forward it ...
<kees> anyway, the linker spec changed so gold-and-ld doesn't apply, and since relro is right in there too, it blew up as well.
<kees> one of the testsuite patches got taken upstream completely.
<kees> so I dropped that.
<kees> a few source files got moved around, so I fixed those.
<SpamapS> ok, 15 compiz crashes later, I reported bug #696996
<ubottu> Launchpad bug 696996 in unity (Ubuntu) "Unity is offset down by difference in resolutions when Nvidia twinview is used" [Undecided,New] https://launchpad.net/bugs/696996
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: robert_ancell
* lindbohm.freenode.net changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<cjwatson> geser: I did an autosync on the morning of 30 Dec, although there are still a few bits and pieces I need to iron out (I've kept a safe copy of Sources files)
<kees> doko: uh-oh. gcc-4.6 behaves very differently than 4.5 on things...
<cjwatson> hggdh: holiday today, will look tomorrow
<cjwatson> soren: sorry - national holiday today, forgot to tell the DMB list
<doko> which things?
<kees> doko: for example, I cannot unset _FORTIFY_SOURCE any more. (see the bug report 696990) I put an example up.
<kees> COLLECT_GCC_OPTIONS='-v' '-U_FORTIFY_SOURCE' '-O2' '-o' 'test' '-mtune=generic' '-march=x86-64'
<kees> vs
<kees> COLLECT_GCC_OPTIONS='-v' '-U' '_FORTIFY_SOURCE' '-O2' '-o' 'test' '-mtune=generic' '-march=x86-64'
<doko> nice
<kees> and stack protector wasn't on... still looking for that.
<kees> doko: ah, ssp was disabled twice. an additional patch is up now on the bug.
<hggdh> cjwatson: cool, thanks
<kees> doko: so, since the spec file expects -U_FORTIFY_SOURCE, how do I change it to allow -U _FORTIFY_SOURCE ?
<doko> kees: ENOCLUE. would have to look myself. I know that option handling was revamped by jsm28
<kees> hmpf
<Laney> They should have taken the lead with the first real attempt on goal just before the half-hour mark when Troy Brown's header from Leadbitter's cross was excellently tipped over the bar by Forest keeper Lee Camp.
<Laney> Connor Wickham was a constant thorn in the side of the visitors' defence, but despite increasing pressure as the match wore on, the hosts failed to work Camp often enough.
<Laney> argh
<Laney> just in case you were interested in nottingham forest's fate... /me runs
<kees> heh
<kees> doko: ah, I think I've found a solution.
<kees> doko: I'll send and updated debdiff after I verify it.
#ubuntu-devel 2011-01-04
<pitti> Good morning
<ion> that.
<pitti> kees: in yesterday evening's SRU meeting I got the confirmation that karmic was tested, and marked it as v-done; I'll move it to -updates today
<didrocks> good morning pitti
<pitti> bonjour didrocks, ca va?
<didrocks> pitti: I'm fine thanks, just received my bed yesterday evening and glued piece together :) and you?
<JackyAlcine> Morning, guys.
<pitti> didrocks: nice! feels better than a sleeping bag :)
<pitti> didrocks: bit tired, but I'm good, thanks
<pitti> hello JackyAlcine
<StevenK> didrocks: You shouldn't need to do that in Dallas, at least  :-)
<didrocks> StevenK: hehe, right :) I'm still happy to have a real bed again and don't have to wait for Dallas to have this feeling :)
<Guest17443> where i can discuss about ubuntu amazon or UCE images - any idea - is it the right room?
<siretart> Guest17443: try #ubuntu-server
<Chipzz> mvo: ping?
 * Chipzz slaps himself for contentless ping
<Chipzz> mvo: how does apt determine, for a given deb line in sources.list, which of Packages/Packages.gz/Packages.bz2 it should try to fetch?
<Chipzz> or are all three tried (in some sort of fixed order)?
<apw> Chipzz, perhaps it uses content negociation on 'Packages'
<smb> pitti, Morning, do you know about gnome-system-tools not being installed by default. Is this intended to save cd space?
<soren> Chipzz: It says in the Releases file.
<soren> Err... "Release", I mean.
<smb> pitti, I did a Natty install of a daily image over the weekend and not having gnome-system-tools prevents you from accessing the time and date settings at least, which is kind of annoying.
<soren> Chipzz: Hm... Or maybe not.
<pitti> smb: I put it back in the seeds
<pitti> smb: it needs a -meta upload; I'll change something else today, and do that
<pitti> smb: we originally meant to replace it with a new user admin tooll, but it didn't work out yet
<G> soren: I always thought it went on most likely to least likely
<pitti> smb: so alpha-2 will have it
<soren> Chipzz, G: My bad.
<soren> Chipzz, G: Acquire::CompressionTypes::Order defines it.
<smb> pitti, Ah ok. Will have a look for it when looking at alpha-2 then
<soren> Chipzz, G: The Release file just gives the md5sums for verification purposes.
<smb> pitti, thanks
<Chipzz> soren: thx
<Chipzz> apw: I have a problem with apt-proxy giving me the following errors:
<Chipzz> W: Failed to fetch http://192.168.1.249:8080/security/dists/lenny/updates/non-free/binary-i386/Packages  404 file not found on backend
<Chipzz> which is correct given that http://security.debian.org/debian-security/dists/lenny/updates/non-free/binary-i386/ doesn't contain a Packages file
<Chipzz> if you look at the gzip file that just uncompresses to a 0 byte file
<Chipzz> so maybe the archive tools used on security.debian.org prune empty files
<Chipzz> *prunes
<mvo> Chipzz: hey, it uses acquire::compressionTypes::order
<Chipzz> now I'm not sure if apt-proxy is at fault for not supporting content negotation
<Chipzz> mvo: ^^^
<Chipzz> (actually it's apt giving me those errors, but the backend uses apt-proxy; that's more correct)
<Chipzz> mvo: what's your take on this?
<G> Chipzz: sounds like your apt-proxy is sending a 404 for all of the options of Packages
<Chipzz> or it only tries the literal file requested, not sure
<soren> mvo: apt.conf(5) says "It is not needed to add bz2 explicit to the list as it will be added automatic.". I don't see where that happens, though? getCompressionTypes seems to just return what is in the configuration.
<G> Chipzz: the client should try the next on each 404 though
<Chipzz> G: the client is apt-get
<Chipzz> so I'm wondering if apt-get is at fault, or what exactly is going wrong here
<Chipzz> most likely it's apt-proxy though
<G> Chipzz: pump up the debugging/output and see exactly whats it's requesting
<mvo> Chipzz: could you run with -o debug::acquire::http=true and see what apt-proxy returns and what it tries to fetch? might be that apt-proxy returns?
<Chipzz> mvo: will do
<Chipzz> the thing is, for some reason it has to time-out too
<Chipzz> which takes a while
<Chipzz> apt hangs at: 82% [Waiting for headers]
<Chipzz> probably apt-proxy b0rkedness
<mvo> soren: it will do a second pass in Configuration::getCompressionTypes() and append all the compression types availalbe via Acquire::CompressionTypes that are not in the override order (yes, its a bit complicated the code)
<mvo> Chipzz: what version of apt is this?
<Chipzz> mvo: debian lenny, with all updates (security/updates/volatile)
<soren> mvo: Oh.. Ok, I was looking specifically for something about bz2, but actually it adds any new compression type. Ok, that makes sense.
<mvo> Chipzz: aha, ok. that is really a bit older, the compression order does not apply here, the order is hardcoded in that version iirc
<Chipzz> mvo: 0.7.20.2+lenny2
 * mvo nods
<Chipzz> mvo: I really suspect apt-proxy to be at fault here though; it's a broken piece of software. unfortunately, the alternatives are not a lot better
<Chipzz> and I don't think I really want to run squid instead
<mvo> you know about squid-deb-proxy :) ?
<Chipzz> hrrrm no?
<ion> Iâm using apt-cacher-ng
<Chipzz> mvo: doesn't look like it's packaged for debian yet though?
<mvo> Chipzz: its a squid with a config optimized for caching debs, if you install squid-deb-proxy and squid-deb-proxy-client (the later only on the client) it will work automatically, i.e. no need to configure anything
<mvo> Chipzz: thats possible :/
<mvo> Chipzz: it uses avahi to advertise its support and is configured to server all local networks by default
<Chipzz> mvo: sounds nice, but not really something I need ;)
<Chipzz> I populate my sources.list at install time with debian-installer options
<Chipzz> mvo: is it valid for the archive tools to prune empty Packages files though?
<mvo> Chipzz: not really, a empty file is fine, it means there might be packages in the future. but no file is bad because that will result in a 404
<Chipzz> so I should poke the administrator of security.debian.org? ;P
<mvo> Chipzz: well, thats fine what security.d.o is doing because it keeps a empty Package.gz
<mvo> Chipzz: hopefully the -o debug::acquire::http=true output helps
<Chipzz> still waiting until it has timed out completely
<Chipzz> ^^
<apw> against what would i file a bug wherein dispite chromium being my default browser, opening links in xchat etc open firefox ?
<Chipzz> at least it's hanging at 89% now
<apw> mvo, actually it will only work if avahi works right?  and as thats not working in natty ...
<ion> Avahiâs not working in natty? At least host name resolution works for me, FWIW.
<apw> ion, i find it works about 1/5 boots
<apw> ion, it seems that the machine is in its own little world, thinks it is advertising its name, and indeed can resolve its own name but is not visible to other machines nor can see them
<mvo> apw: thats true, but I hope we will not realse without a broken avahi ;)
<mvo> apw: one nasty issue is that avahi-browse reports ipv6 addresses sometimes when its asked for ipv4
<Chipzz> mvo: http://chipzz.safehex.be/apt-log
<Chipzz> it seems to be doing multiple requests for the same file
<Chipzz> does 2 requests for Packages.bz2 and Packages.gz
<Chipzz> only one for the other types
<seb128> apw, the default browser thing is a known bug
<apw> mvo, so it does ... very odd indeed
<seb128> apw, gnome-control-center one
<seb128> apw, the capplet needs an update for the new default handler system
<apw> mvo, OH and if you ask for the address of 'self' a few times, that fixes the response to be ipv4, _and_ the machine is then advertised correctly remotly
<seb128> apw, you can workaround locally by editing /usr/share/applications/defaults.list
<seb128> apw, set x-scheme-handler/http to what you use
<seb128> apw, then sudo update-mime-database /usr/share/applications
<apw> seb128, perhaps i'll leave it be and use the machine as confirmation the bug fixes
<seb128> update-desktop-database rather
<seb128> apw, your call, we will test the fix for sure since it's an issue quite some users reported and obviously broken
<pitti> apw: ah, udev bug gone together with the old year?
<zyga> pitti: hi
<pitti> hey zyga, happy new year!
<apw> pitti, yep, completely bizarre, i did a dozen up/down graded to confirm it was udev only that triggered it... and decided to upgrade everything today expecting to have to downgrade udev ... and its fine.  most odd
<pitti> apw: the udevadm trigger test didn't reveal anything at the time when you still could reproduce it?
<apw> pitti, nothing no
<apw> i'll keep monitoring it, and if it comes back i'll have the box with me next week
<pitti> zyga: do you see my replies in privmsg?
<zyga> pitti: I can see you type but I cannot even see my messages
<zyga> just a second
<soren> cjwatson: No problem. We turned out to be quorate, so it was fine.  All of us except bdrung will expire in two weeks, though. I forget if we've addressed that at all?
<cjwatson> I don't know
<pitti> hey cjwatson, happy new year! had some nice holidays?
<cjwatson> pitti: yeah, they were fine thanks :)
<MacSlow> tseliot, hey there
<tseliot> hi MacSlow
<MacSlow> tseliot, happy new year btw :)
<tseliot> MacSlow: thanks and happy new year to you :)
<MacSlow> tseliot, do you know how during the login-procedure (from gdm to desktop-session) the resolution is switched on nvidia?
<MacSlow> tseliot, I mean... where is the setting for this stored and which tool triggers the switch?
<tseliot> MacSlow: it depends. Did you change it from nvidia-settings?
<MacSlow> tseliot, on the gdm-screen I still have the correct native resolution
<bdrung> cody-somerville: can you add angelabad to the motu team?
<tseliot> MacSlow: if you didn't use nvidia-settings, try to remove the ~/.monitors.xml, just in case the gnome-settings-daemon is applying the wrong resolution
<MacSlow> tseliot, well I've to change it in nvidia-settings if I want to get back to the native one.... but I rather prefer the resolution not to change at all... I mean it's ok during gdm... so no need to change it.
<seb128> MacSlow, did you check .config/monitors.xml?
<apw> seb128, ok i've switched over, and your instructions work just fine (firefox -> chromium)
<MacSlow> tseliot, seb128: no... didn't know about that file... will check now
<seb128> apw, great! ;-)
<seb128> MacSlow, that's what gnome-display-properties writes
 * tseliot nods
<MacSlow> seb128, tseliot: ~/.config/monitors.xml states the wrong resolution... so I just fix that and should be all good?!
<seb128> MacSlow, rm the file
<tseliot> MacSlow: yes, either fix that or remove it
<seb128> so it will just use the xorg config
<MacSlow> seb128, tseliot: ok... trying out the result now... brb
<MacSlow> I hope :)
<MacSlow> tseliot, seb128: ok that worked... thanks!
<tseliot> np
<seb128> MacSlow, you're welcome
<ScottK> doko: I couldn't reproduce your KDE related libreoffice build failure, but I'm not sure the chroot I used was completely clean.  Could I get the package install part of the build log so I can check what got pulled in by your build versus what I've got installed and see if there's a dependency missing as an explanation?
<doko> ScottK: I don't have the log
<pitti> tkamppeter: I just reported bug 697190, this is a prerequisite
<ubottu> Launchpad bug 697190 in system-config-printer (Ubuntu) "cupshelpers.openprinting.OpenPrinting.listDrivers() does not include fingerprints" [Undecided,New] https://launchpad.net/bugs/697190
<pitti> tkamppeter: I guess it's easy to fix, do you want me to look at it, or do you want to?
<cjwatson> lool: I'd appreciate it if you could look at bug 694772, since it's a regression caused by your recent eglibc upload
<ubottu> Launchpad bug 694772 in eglibc (Ubuntu) "Sudden reboot during server ISO install" [Critical,Triaged] https://launchpad.net/bugs/694772
<doko> ScottK: could you recheck with a PPA upload?
<ScottK> doko: I'm redoing it now locally.  I think I may have not re-enabled all the KDE bits.
<doko> ScottK: it should be just the one line in rules, then rebuilding the control file
<ScottK> There's also the one above the configure flag that I missed the first time.
<ScottK> I didn't have BUILD_KDE=y
<ScottK> So I think it didn't build the bit that fails.
<doko> ahh, ok
<tkamppeter> pitti, I will fix bug 697190.
<ubottu> Launchpad bug 697190 in system-config-printer (Ubuntu) "cupshelpers.openprinting.OpenPrinting.listDrivers() does not include fingerprints" [Undecided,Triaged] https://launchpad.net/bugs/697190
<pitti> tkamppeter: thanks; I'm currently figuring out how to do SSL cert verification in python
<pitti> tkamppeter: that are the two main building stones that I'll need :)
<elif> Preseed can use a partiotion (not try to make one, but just use one that was there already) ?
<cjwatson> unfortunately not
<ScottK> Welcome back cjwatson.  I hope you had a pleasant holiday.
<elif> cjwatson: thks.
<cjwatson> ScottK: not bad, thanks
<stefano-palazzo> building gtk fails with "Gdk-2.0.gir: error: Type reference 'GdkPixbuf' not found" - can anybody help?
<Chipzz> stefano-palazzo: this is not the place for these kind of questions; you should try on #gtk+ on irc.gnome.org instead
<stefano-palazzo> Chipzz, Oh I see, thanks anyway.
<cdbs> I can't get any python distutils-using app to build on my pbuilder, it appears that the python2.7 package isn't installed properly in it.
<cdbs> How do I fix it? I don't want to go and re build my chroot tarball
<hmca> hello, greetings and happy new year 2 all!.
<hmca> !php5
<hmca> !php
<ubottu> PHP is an HTML-embedded scripting language. A command-line only version can be installed in Ubuntu with the "php5-cli" package. See also !lamp for integrated server PHP. The Ubuntu server PHP5 guide is found at https://help.ubuntu.com/10.04/serverguide/C/php5.html
<cdbs> !msgthebot | hmca
<ubottu> hmca: Please investigate with me only with "/msg ubottu Bot" or in #ubuntu-bots.  Search for factoids with "/msg ubottu !search factoid".
<micahg> janimo_: sorry about that, this was my first time using a real mozconfig, I'll test the build tonight before uploading again
<janimo_> micahg, np at all
<janimo_> micahg, I thin just modifying mozconfig.in w/o debian rules should work
<janimo_> you can test on x86 and see wether it is affected by --enable-thumb2 - I thinknot
<janimo_> it suffices if you let the configure step run, so about 2-3 minutes
<lool> cjwatson: Hey; sorry, there was a small network outage for the machine hosting this IRC session; I think you wanted me to poke the eglibc reboot; I've attached a couple of untested debdiffs and would be happy to get your feedback while they build in my PPA
<tkamppeter> pitti, corrected s-c-p uploaded to natty.
<cjwatson> lool: thanks, followed up in the bug
<lool> cjwatson: Will test an upgrade of libc6 on my system and if that doesn't cause any error or reboot, I will upload this debdiff
<pitti> tkamppeter: cheers!
<tkamppeter> pitti, does it work for you now?
<pitti> tkamppeter: haven't tried yet, still buried in SSL stuff
<ev> I don't suppose anyone has experience automating uploading and watching for finished binaries in a PPA using launchpadlib? I'd rather not reinvent the wheel, should one exist.
<elmo> ev: lamont's done something like that - it may predate launchpadlib though, but you could ask him
<mvo> ev: something vaguely similar is lp:~mvo/%2Bjunk/lp-changelogs-crawler/
<mvo> ev: but I guess its just too different to be useful
<ev> elmo, mvo: thanks
<ogra> doko, shadow fixed and uploaded
<doko> \o/
<om26er> there are two commits to fix a bug, should i merge those commits into one patch or two seperate patches should be added for a backport?
<seb128> om26er, either way works
<om26er> seb128, alright, thank you.
<seb128> om26er, if those are different changesets better to keep them as two commits
<seb128> if the second is a fix to the first commit you can as well do a diff with both revisions
<jdstrand> pitti: hi! I'd like to get bug #690040 fixed in maverick soon. are you working on this or shall I?
<ubottu> Launchpad bug 690040 in cups (Ubuntu Maverick) "no longer confined by AppArmor" [Undecided,Triaged] https://launchpad.net/bugs/690040
<pitti> jdstrand: if you have the time, please go ahead
<jdstrand> pitti: ok. I will just update the job file like we did for other things in maverick
<wildfire> I've uploaded something to my PPA - is there a way I can check the status of the build?
<seb128> wildfire, on your ppa page
<wildfire> seb128: nothing seems to be there (uploaded about 6 hours ago), and dput says I can't upload since I already have
<wildfire> suggestions?
<seb128> wildfire, dput says that because of the .upload
<seb128> you probably have a .upload in your directory
<Laney> dput -f ...changes
<seb128> the upload probably got rejected, you should have received an email
<wildfire> seb128: yup, I did, and then I uploaded a revised version
<seb128> did you upload to the right ppa with a correct changelog target?
<wildfire> seb128: the first time, no, I set the distribution to 'unstable', the second time I think I got it right but have had no feedback
<seb128> wildfire, well rm the .upload and dput again
<wildfire> seb128: OK, will do
<seb128> wildfire, well if you used the same version the .upload probably blocked the dput saying you already uploaded
<wildfire> I updated the version and appended ~lucid to the end
<wildfire> sorry, ~lucid~0
<wildfire> seb128: the full version string is yate_3.0.0-0~ubuntu~lucid~0.dsc
<wildfire> does that look reasonable?
<seb128> wildfire, yes
<seb128> just rm the .upload and dput again
<wildfire> have done
<wildfire> hmm, noothing much appearing
<lool> SpamapS: Hey
<lool> SpamapS: upstart / libc6: IIUC, trying to properly call telinit in libc6 wouldn't do anything anyway, as it's currently broken, and I should be looking at touch /var/run/init.upgraded rather than telinit; would you like me to prepare, test, and upload such an eglibc change?
<SpamapS> lool: actually I just built a package last night that does it.. its a very tiny change...
<SpamapS> lool: let me push the branch.. and if you want to sponsor it/run with it, that would be awesome. :)
<lool> SpamapS: Given that the package importer had issues with it yesterday, I'd rather have a debdiff in the bug if that's ok with you
<lool> SpamapS: I would basically remove: telinit u 2> /dev/null || true ; sleep 1
<lool> and use touch instead
<lool> SpamapS: Debian folks told me this wouldn't work with some FS if the machine is not shutdown properly
<lool> I think they are correct, but I wonder how much this can be blamed on these filesystems
<SpamapS> lool: just pushed to lp:~clint-fewbar/ubuntu/natty/eglibc/no-telinit-u  ..
<SpamapS> lool: ahh right package import..
<Verminator> I hope this is the correct place to ask this.  I am a MS Windows C++/MFC programmer.  I want to start exploring Linux development.  Is there a good web community to get involved with or some good tutorials I can use to get up to speed?  I have already found started looking at the link given in the topic of this channel.  TIA
<SpamapS> lool: I will put a debdiff into the bug report in a bit..
<janimo> micahg, you're right, the --enable-thumb2 flag is not filtered out in mozilla build script so needs to be done as you have in debian/rules
<micahg> janimo: ok, now that my arm box is working I can actually test before I upload, so I'll add the DEB_DEFINES and see if that does it
<SEJeff> I was wondering if someone could help me track down a tricky dbus / xfce4-terminal bug
<SEJeff> xfce4-terminal hangs. I straced it and it is returning: EAGAIN (Resource temporarily unavailable) on a recvmsg call in what is a dbus call
<SEJeff> There is 1.2G of memory free
<wildfire> seb128: hmm - any other tips?
<seb128> wildfire, you didn't get any email about the upload? how did you upload?
<seb128> can you copy your .changes online somewhere?
<hallyn> grrr.  natty kernel doesn't have sysfs tagging support.
<SEJeff> hallyn, Is that a feature that lxc will use?
<hallyn> yes, it lets containers see their network interfaces in /sys/class/net
<wildfire> seb128: via dput and sure, any suggested place?
<hallyn> but actually, i dont' seem able to pass veths into a network namespace by hand in maverick at all...  hmmm
<SEJeff> Oh yuck
<sivang> hi all
<seb128> wildfire, can you give the dput line you used?
<sivang> whom do I contact to remove a paste from paste.poco.org?
<wildfire> seb128: dput yate_3.0.0-0\~ubuntu\~lucid\~0_amd64.changes
<wildfire> seb128: I'll pastebin the rest, one sec.
<SEJeff> sivang, Go to that website and click about. This isn't an ubuntu question
<wildfire> seb128: http://pastebin.com/EJ0XyynX
<micahg> sivang: poco.org?
<wildfire> seb128: AHH! I think I see the problem
<wildfire> signed with wrong key.
<sivang> micahg: indeed
<micahg> sivang: why not contact them?
 * wildfire tries a re-build and re-upload
<sivang> micahg: the post is going to cost me my job, so it'd be nice to do it assap :)
<sivang> micahg: what's the contact address?
<seb128> wildfire, ok, you have a dput config to upload to your ppa right?
<sivang> micahg: there's no where on the site where to contact them
<seb128> wildfire, because by default otherwise it will try to upload to ubuntu
<micahg> sivang: what does it have to do with Ubuntu?
<wildfire> seb128: nope, well I am trying to upload to ubuntu
<seb128> wildfire, you said to a ppa before?
<SEJeff> sivang, Go to paste.pocoo.org and click about. Just like I already said.
<wildfire> seb128: yes, an ubuntu PPA - am following: https://help.launchpad.net/Packaging/PPA/Uploading
<seb128> wildfire, you are trying to upload to the ubuntu archive there, not to a ppa
<SEJeff> It has info about the guy who runs it. Look up up and send him an email
<wildfire> which says to just use dput without doing anything
<seb128> wildfire, well you didn't use "dput your-ppa"
<seb128> wildfire, well you didn't use "dput yourppa"
<seb128> wildfire, if you don't specify a config to use it uploads to ubuntu
<sivang> SEJeff: thanks dude, sorry for the noise
<wildfire> seb128: ahh - bug #2; thanks!
<ubottu> Error: Could not parse data returned by Launchpad: 2 (https://launchpad.net/bugs/2)
 * wildfire tries once more
<ogra> does a non *_source.changes upload even work ?
<ogra> looks like you are uploading a .changes file from a binary build
<hallyn> well now... notworking in natty either
<seb128> ogra, that as well, I didn't open the pastbin before
<seb128> wildfire, ^
<seb128> wildfire, you need to do a source build to upload
<ogra> well, it might work (after all the soucre files are included) i just never tested that
<Laney> i think it rejects
<wildfire> seb128: dpkg-buildpackage -S ?
<seb128> wildfire, correct
<lool> SpamapS: I am not sure I will check the bug again tonight; this sounds urgent though; should I upload my debdiff for now?  I can definitely take another look tomorrow morning if you prefer
<SpamapS> lool: I'll add the debdiff in just a moment
<SpamapS> lool uploaded to the bug report.
<wildfire> seb128: hurrah!
<seb128> wildfire, worked?
<wildfire> seb128: well, upload accepted and building
<seb128> wildfire, great
<geser> any ubuntu-devel-announce moderator around to moderate my mails?
<cjwatson> yes
<kees> pitti: kernels> okay, thanks.
<janimo> kees, hi, do you keep a list of packages which are built without FORTIFY_SOURCE  ? If so, in case you missed it the latest pth upload does that
<jdstrand> jhunt: hi! I am looking to backport the fix in bug #689892 to maverick and lucid. is there anything in this patch: http://launchpadlibrarian.net/60617190/ifupdown_0.6.10ubuntu4.debdiff that would cause problems with upstart 0.6.5-7 or 0.6.6-3 in lucid and maverick (respectively)
<ubottu> Launchpad bug 689892 in ifupdown (Ubuntu Maverick) "[SRU] race condition bringing up interfaces with AppArmor" [Undecided,Confirmed] https://launchpad.net/bugs/689892
<jdstrand> jhunt: I'm thinking no, but thought I'd ask to be doubly sure
<kees> janimo: yeah, it's on the wiki under CompilerFlags
<janimo> kees, thanks, checking it out
<kees> doko: btw, did you see my update for the gcc-4.6 hardening patches? I solve the FORTIFY issue, I think
<doko> kees: yes, checked in. will upload a gcc-snapshot build later
<janimo> doko, I have tried an armel built of libo from ppa out of curiosity. It ERRORS with a segfault at the install step
<janimo> had to disable smoketest first
<doko> janimo: ahh, ok. same on i386
<janimo> doko, the smoketest you mean? as the package itself seemed to build on i386, unlike on arm
<janimo> it crashed on installing uno components to a 'registry' file
<doko> janimo: which package do you try to build?
<janimo> I'll check again in after the next uploads
<janimo> doko from libo ppa
<janimo> natty
<doko> janimo: hmm, is this related to the smoektest?
<doko> it's rather the same thing I see for the karmic-proposed OOo build
<janimo> doko, no, Idisabled the smoketest just as it is done for i386, so it is skipped, but it fails after that anyway
<doko> janimo: right, that is the problem =)
<janimo> ok, so nothing new
<janimo> did the arm port always have this issue?
<doko> janimo: https://launchpad.net/ubuntu/+bugs?field.tag=lo33
<doko> no, starting with lucid-proposed (not karmic), and now natty
<bdmurray> pitti: could you look at https://code.launchpad.net/~brian-murray/ubuntu/natty/apport/natty-regression-tags/
<janimo> doko, thanks, I tried searching lp for lo330 today with no results
<bdmurray> I thought it was just lo33
<doko> it is
<janimo> doko, I saw that in the LP changelog "Launchpad bug tracker for issues tagged with `lo330', "
<janimo> and did overlook the direct link in your mail to u-d
<janimo> which was correct
<doko> oops, wrong changelog
<elif> cjwatson: using kickstart support can I install a ubuntu using a partition previously made ??? (early I asked if that was possible in preseed you said it is not), I think there's no way because ks support depends on preseed, but is that possible somehow ?
<doko> janimo: now just find out *why* it segfaults ;)
<doko> welcome to one of the most ugly parts of the package
<janimo> doko, I tried a gdb backtrace this morning but it was incomplete, no symbols and corrupted frame
<janimo> but I'll keep poking at it while other stuff builds these days
<hallyn> cjwatson: did you have any comments or any plans to look further at the multipath-tools proposed package I emailed (syncing from debian)?
<hallyn> <shrug> should I simply do a merge request of https://code.launchpad.net/~serge-hallyn/ubuntu/natty/multipath-tools/debe1 into multipath-tools?
<hallyn> hm, i'll do that.
<hallyn> ivoks: cmagina: any comments you can give on my attempt to sync multipath-tools from debian (https://code.launchpad.net/~serge-hallyn/ubuntu/natty/multipath-tools/debe1/+merge/45177) greatly appreciated
<cjwatson> hallyn: well, if you wait until I'm next actually at work then I can certainly look at it.
<cjwatson> if it's a verbatim sync then a merge request is a funny way to go about it.
<cjwatson> (if it's not a verbatim sync, but a merge, please don't call it a sync :))
<ivoks> hallyn: this requires review before 11PM :)
<hallyn> it's definately not a verbatim sync
<cjwatson> ivoks: hm?
<hallyn> anyway i wanted to get on with getting the knows bugfixes into lucid+maverick but couldn't get myself to do those until i felt like i'd done the last step in getting natty fixed through upgrade...
<cjwatson> I'll look first thing tomorrow
<hallyn> ivoks: or after 9am is fine too :)
<hallyn> cjwatson: thanks!
<hallyn> ivoks: you never created a bug for the modprobe -Q right?
<ivoks> hallyn: i don't think so, no... i don't lhave much time :(
<hallyn> ivoks: thanks, just making sure - i'll create one
<hallyn> oh, there is one
<siretart> my x264 upload to maverick-proposed has been rejected. Can someone please assist me to find out whom to ask why?
<siretart> Riddell: according to the https://wiki.ubuntu.com/ArchiveAdministration, that would be you. is that correct?
<iitg-cs-grad> hi ... I am have compiled kernel 2.6.35.4
<iitg-cs-grad> and am trying to boot from it
<iitg-cs-grad>  it says device / not found or not ready after booting into it
<iitg-cs-grad> when i skip it says /tmp not found or not ready after booting into it
<iitg-cs-grad> I am using a wubi over win
<iitg-cs-grad> I saw on the forums mentioning something about giving UUID to the boot parameters
<iitg-cs-grad> I dont seem to proceed after that...
<iitg-cs-grad> ne1?
<siretart> !offtopic | iitg-cs-grad
<ubottu> iitg-cs-grad: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
<iitg-cs-grad> ty!
<lifeless> barry: hey
<barry> lifeless: hi
<lifeless> would love feedback in the concurrent package thread :)
<barry> lifeless: tbh, i've been ignoring it ;)  i got swamped during the break and just deleted the thread.  maybe i should go to gmane and read up on it?
<lifeless> barry: Well I need to know if my proposal will work
<lifeless> and then to figure out the setuptools invocation magic to make it happen
<barry> let me take a quick look
<lifeless> and finally what dh python changes to make
<lifeless> the last seems easiest to me ;)
<barry> lifeless: oops, you don't mean the futures package thread on python-dev, right?
<lifeless> barry: god no
<lifeless> barry: thats a train wreck
<lifeless> also I would have asked on #python-dev about that one :)
<barry> lifeless: hang on...
#ubuntu-devel 2011-01-05
<barry> lifeless: sorry, i got distracted by work and dinner. ;)  can you please ping me again tomorrow (i have to go out for a while now)
<lifeless> k
<SpamapS> lifeless: I've been following the thread.. and you know I'd like to help solve that issue.. have been pulled far away from that stuff though. :-P
<lifeless> SpamapS: cool
<lifeless> SpamapS: feel free to jump in :)
<SpamapS> At this point I think the "educate people" argument has proven ineffective, even if it is "the right way" .. its not helping much. :-P
<lifeless> the python community has little interest in naming modules with api versions on /every/ incompatibility
<lifeless> heck, unittest2 mentioned in that thread *isn't* an API version
<lifeless> its 'unittest backported for python 2.x'
<SpamapS> To be honest I think ruby might even do a better job of this.
<SpamapS> 192.168.122.1:/home/clint /mnt/clint nfs ro,soft 0 0
<SpamapS> what am I missing.. mountall is skipping that mount
<lifeless> SpamapS: not sure :)
<ScottK> doko: I still couldn't get libreoffice to fail with KDE enabled.  Would you please publish the source of what fails somehwere?
<kees> weird. https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/694983
<ubottu> Ubuntu bug 694983 in busybox (Ubuntu) "udhcpd crashes with 'Illegal instruction'" [Undecided,New]
<dholbach> good morning
<siretart> Riddell: unping my comment from yesterday, I've just noticed the notice in the buglog. sorry for the trouble
<pitti> Good morning
<pitti> bdmurray: will do
<evfool> #libreoffice
<pitti> mdke: here by chance?
<ara> doko, ping
<didrocks> jdstrand: hey, are you around for some apparmor questions?
<doko> ScottK: that the uploaded code, with the kde config options commented out in the natty section of the rules file
<raphink> hello
<raphink> is there someone here who knows net-snmp (and libsnmp-base in particular) well?
<raphink> I'm wondering if the wget (strong) dependency is really necessary
<raphink> it seems justified because mibfetch needs it in the README, but we don't ship mibfetch
<raphink> and on standard server installs, wget seems to be only pulled by libsnmp-base
<Chipaca> hi all. What was the process of asking for an update to a package (i.e. upstream is at a new version)? I know it starts with "write a bug", I've done it before, but can't remember more than that, and that I then had to subscribe somebody to it (who?), and ... anything else?
<cjwatson> "file a bug" seems sufficient.  anything more depends on how much you want/need to harass people about it
<raphink> Chipaca, you mean in natty?
<Chipaca> raphink: yep
<raphink> by upstream, do you mean debian or real upstream (sourceforge, LP, etc.)?
<cjwatson> FWIW, it's usually smoothest if the upstream can go via Debian
<Chipaca> real upstream :) -- checking debian
<cjwatson> means everything follows the natural grain
<raphink> Chipaca, right, like cjwatson said, it's always better to go through Debian (when possible)
<raphink> so the first step is to check if Debian has it
<raphink> if Debian has it, the package might be listed here: https://merges.ubuntu.com/
<raphink> see https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing
<raphink> ... which actually tells you to look at https://wiki.ubuntu.com/UbuntuDevelopment/Merging for the reference :-)
<Chipaca> debian has the old version
<Chipaca> I've even got the new packages working (so I can develop against the newly added api), and it was just a ... bzr merge-upstream iirc
 * Chipaca reads the wiki
<raphink> anyone has an opinion on the libsnmp-base wget dependency?
<zul> raphink: hmm? what
<raphink>  I'm wondering if the wget (strong) dependency is really necessary. It seems justified because mibfetch needs it in the README, but we don't ship mibfetch and on standard server installs, wget seems to be only pulled by libsnmp-base.
<jdstrand> didrocks: hi! fire away
<cjwatson> wget is going to be pulled in by ssh-import-id RSN anyway
<cjwatson> so may not be worth worrying about?
<cjwatson> though of course if we don't ship mibfetch we shouldn't claim its dependencies!
<didrocks> jdstrand: hey, is there any kind of debug/logs of what access have been prevented in apparmor? I can't launch unity in the guest session only if the apparmor guest profile is here
<Chipzz> cjwatson: although the same could probably be achieved by curl
<Chipzz> which makes me wonder if it wouldn't be worth writing simple wrappers for both for the simple use case "fetch a file" and depend on wget | curl
<jdstrand> didrocks: yes. they show up in dmesg/kern.log. if you have auditd installed, they show up in /var/log/audit/audit.log. use 'grep -i denied <file>'
<raphink> cjwatson, I do not see any ssh package being removed when I remove wget
<didrocks> jdstrand: ok thanks, let's have a look then. I was looking at /var/log/apparmor/ desperatly :)
<cjwatson> raphink: you haven't upgraded sufficiently recently
<cjwatson> ssh-import-id was newed today
<cjwatson> and is recommended by openssh-server now
<jdstrand> didrocks: that said, the kernel does rate limiting of apparmor when not using auditd, so if debugging and profiling you will want to do: sudo sysctl -w kernel.printk_ratelimit=0
<raphink> cjwatson, possibly, my servers are on lucid ;-)
<cjwatson> Chipzz: what would that gain?  wget is in standard; curl is not
<cjwatson> it's not as if both wget and curl are installed on default server installs
<raphink> yes indeed
<Chipzz> cjwatson: not having both installed because a depends: wget and b depends: curl
<cjwatson> Chipzz: which isn't happening on default server installs right now, which is what raphink was asking about
<raphink> (some big company where I happen to be working considers wget|curl to be harmful programs on servers)
<Chipzz> you're only thinking "main" now
<cjwatson> I'm not interested in this discussion so will withdraw
<Chipzz> ok w/e
<raphink> haha :-)
<Chipzz> raphink: the same can probably be achieved be a pretty stock perl install; or netcat
<Chipzz> so tey're misguided
<Chipzz> *they
<raphink> they certainly are
<didrocks> jdstrand: ok, seems that the issue is it's denying to open my config compiz file: http://paste.ubuntu.com/550632/
<raphink> but the company is 100k+ employees and the corporate security team has an opinion that matters much more than mine
<raphink> ;-)
<raphink> not like wget is useful for monitoring either, heh ;-)
<Chipzz> stock python can get a file too
<Chipzz> to make it impossible to download a file from a server is basically impossible
<janimo> Laney, hi, any news re ghc6 ?
<Laney> janimo: not had time yet
<Laney> if you want you can try a merge with experimental
<Laney> i'll sponsor that for you if you need it
<janimo> Laney, I have upload rights, but thanks
<Laney> ok cool
<Laney> please do that then
<janimo> Laney, problem is on my arm build even the current one succeeded
<Laney> it's what i was/am going to do when time allows
<janimo> unlike in the buildd
<Laney> yeah i don't understand it really
<janimo> Laney, ok, I'll check it out these days
<Laney> thanks
<geser> doko: do you have an idea what's the issue here: http://paste.ubuntu.com/550656/
<bcurtiswx_> anyone here successfully add a PPA to their pbuilder-dist,  I try the --othermirror option with no luck (it appears).. look at http://paste.ubuntu.com/550660/
<nigelb> bcurtiswx_: shouldn't that go into the sources.list of the pbuilder?
<bcurtiswx_> nigelb, i would normally, except pbuilder-dist overwrites the config on every load..
<nigelb> hrm, isn't there some option to stop that?
<bcurtiswx_> nigelb, maybe I missed it, but i've scoured the man pages
<tumbleweed> no, there isn't
<tumbleweed> bcurtiswx_: easy answer, use pbuilder, and point it at your pbuilder-dist root tgz
<raphink> bcurtiswx_, did you try with APTCONFDIR ?
<bcurtiswx_> raphink, APTCONFDIR="/home/ken/.pbuilder/apt.conf.d" in my .pbuilderrc where in the apt.conf.d where I have a bcurtis@wx:~/.pbuilder/apt.conf.d/apt/sources.list.d$
<bcurtiswx_> ??
<doko> geser: not at first glance. ./e-map/libemap.a as the last argument looks odd
<raphink> bcurtiswx_, that should do
<raphink> do an update --override-config
<jhunt> notify
<jhunt> oops :)
<RoAkSoAx> /win 8
<bcurtiswx_> raphink, it seems to work now.. thx.  tumbleweed you too :)
<seb128> Laney, directhex: do you have any clue about bug 596727?
<ubottu> Launchpad bug 596727 in sysinfo (Ubuntu) "sysinfo crashes when I click on "system": GConf.NoSuchKeyException: Key '/apps/sysinfo/window_width' not found in GConf" [Medium,Triaged] https://launchpad.net/bugs/596727
<seb128> the title is misleading, the crash is rather the one from comment #11
<cjwatson> Sarvatt: I'm just about ready to finally upload a console-setup with keyboard-configuration
<cjwatson> Sarvatt: how long would it take you / other X folks to prepare an upload that switches back to that, in line with Debian?
<directhex> seb128, can't look at it until the weekend. email me so i don't forget
<seb128> directhex, ok
<seb128> directhex, can I just subscribe you to the bug or do you prefer an email?
<directhex> subscribe is fine as long as something pings the bug so i end up with an email from it
<seb128> directhex, ok thanks
<Laney> the code of that Xorg() function looks a bit suspicious
<doko> kees: had to update one chunk in the default-ssp patch. now building in the ubuntu-toolchain-r ppa
<seb128> Laney, ok, I think I know what it doesn't like
<Laney> seb128: yeah I reproed it
<Laney> If you empty /var/log/Xorg.0.log then it happens
<seb128> Laney, the log lines start with [....]
<seb128> Laney, even non empty
<seb128> on ubuntu it has the stamps
<seb128> so no line matches what it wants
<Laney> ok I'm on Debian ATM, so ...
<seb128> try copying a random file over the log I guess will do the same
<Laney> where's the NRE? 320?
<seb128> nre?
<seb128> oh
<Laney> null reference exception
<seb128> System.NullReferenceException: Object reference not set to an instance of an object
<seb128>   at Sysinfo.SystemInfo.Xorg () [0x00000] in <filename unknown>:0
<Laney> yeah doesn't say which line :(
<seb128> how do you tell it to say the line?
<seb128> Laney, I guess it's the "						temp = textread.ReadLine();" when reaching the end of file without match though
<seb128> brb
<Laney> that is my thought
<Laney> so just break the loop if temp == null is easiest
<Laney> ideally that whole method would be refactored, there has to be a better way of doing that
<Laney> nm, will fix it if that is right. thanks seb128
<Laney> [edit] PowerPC
<seb128> Laney, I confirm that removing the [...] before "Build Date" fixes the crash
<Laney> seems that ReadLine() returns null if there is nothing to read
<seb128> Laney, thanks, btw do you think you could review and maybe grab the 2 small changes we have in ubuntu and get back in sync?
<Laney> yep I will take those too
<seb128> Laney, thank you, can I assign the bug to you on launchpad?
<Laney> if you want to try the patch it'll be to change the loop condition to have while (... && (temp = ... != null))
<seb128> oh you did
<seb128> Laney, I don't have the mono build-depends on that box but I will try later
<seb128> Laney, btw what you suggest will fix the crash but not make the version to be read
<Laney> yeah make it substring
<seb128> Laney, ideally it would strip the "[.*] "
<Bravewolf> latest update of lucid breaks "kde-l10n-engb" "kde-l10n-it".
<Riddell> Bravewolf: can you be more specific than "breaks"?
<Bravewolf> sure
<Riddell> pastebin the apt-get output for example
<Bravewolf> The following packages are BROKEN:
<Bravewolf>   kde-l10n-engb kde-l10n-it
<Bravewolf> 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<Bravewolf> Need to get 10,2MB of archives. After unpacking 160kB will be used.
<Bravewolf> The following packages have unmet dependencies:
<Bravewolf>   kde-l10n-it: Depends: libkdecore5 (>= 4:4.5.0) which is a virtual package.
<Bravewolf>   kde-l10n-engb: Depends: libkdecore5 (>= 4:4.5.0) which is a virtual package.
<Bravewolf> The following actions will resolve these dependencies:
<Bravewolf> Remove the following packages:
<Bravewolf> kde-l10n-it
<Bravewolf> Keep the following packages at their current version:
<Bravewolf> kde-l10n-engb [4:4.4.2-0ubuntu6 (lucid, now)]
<Bravewolf> Score is 189
<micahg> !pastebin | Bravewolf
<Bravewolf> $ apt-cache policy  libkdecore
<ubottu> Bravewolf: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Bravewolf> W: Unable to locate package libkdecore
<Bravewolf> http://paste.ubuntu.com/550710/
<Bravewolf> http://paste.ubuntu.com/550711/
<Bravewolf> Riddell: here is the output
<Bravewolf> micahg: ok
<Riddell> Bravewolf: thanks
<Riddell> Bravewolf: also pastebin  apt-cache policy kde-l10n-it
<Bravewolf> Riddell: http://paste.ubuntu.com/550712/
<psusi> ok, I have uploaded a bzr branch, requested merge, filed a bug requesting merge, linked to branch.. anything else I need to do?  like subscribe patch pilots, or tag the bug or anything?
<micahg> psusi: if there's a merge proposal, that should show up in the sponsoring queue, when there's not a merge proposal, you need to subscribe ubuntu-sponsors to the bug
<Riddell> Bravewolf: hmm, looks like you have found a significant problem
<Riddell> Bravewolf: well the good news is that you can safely remove those packages, unless you care about documentation translations, they don't contain the application translations
<Riddell> ScottK: wibble ^^
<Bravewolf> Riddell: right, I can remove them. By the way I don't know why this problem appears with the latest update. I seems that something is wrong with the dependencies and/or the new version requires some libraries not available. Who is supposed to fix to it? Should I file a bug?
<Riddell> Bravewolf: yes it's bug and we need to fix it
<Riddell> Bravewolf: please do file a bug and let me know the number
<Bravewolf> Riddell: ok
<Sarvatt> cjwatson: apologies for the delay, I'm on it now
<cjwatson> Sarvatt: great, thanks - http://paste.ubuntu.com/550726/ perhaps?  looks like the rest of that file is still useful
<Sarvatt> http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/     http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/xorg-server_1.9.0.902-1ubuntu2.debdiff
<Sarvatt> ah ok, good point
<Sarvatt> fixing
<cjwatson> Sarvatt: IMPORT{file}="/etc/default/keyboard" works fine in this VM, at least
<cjwatson> so I'm going to go ahead and upload c-s
<Bravewolf> Riddell: I was sending the bug report when I found https://bugs.launchpad.net/bugs/696675
<ubottu> Ubuntu bug 696675 in kde-l10n-engb (Ubuntu) "kde l10n packages depend on libkdecore5 which doesn't exist" [Undecided,New]
<Riddell> thanks Bravewolf
<mvo> cjwatson: I just played with the latest grub and btrfs a little bit, it complains that ""only detection is support for btrfs, you need to load the kernel first" (v1.99~0101221). is there something missing in code or am I not driving it correctly (this is from the grub shell at boot)
<Bravewolf> Riddell: thanks for your help
<cjwatson> mvo: you need 1.99~20110104-1
<cjwatson> mvo: if you're on amd64, it hasn't quite landed yet
<mvo> cjwatson: indeed, that is the problem. thanks
<cjwatson> Sarvatt: uploaded now - please go ahead and upload xorg-server when you get a chance
<Sarvatt> cjwatson: I have no upload permissions but I am attempting to find a sponsor and have fixed it up in git as well as http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/ . bryceh should be on soon, we had some other changes queued up in git that might be a bit scary to review :)
<cjwatson> Sarvatt: I suppose I could upload it, but the X team might prefer I didn't
<Sarvatt> I can't speak for the other guys but the complaints usually come from it being maintained in git and changes not pushed to pkg-xorg, already ran the nvidia/fglrx change past tseliot and bryce and RAOF is on vacation
<tseliot> Sarvatt: what's up?
<tseliot> Sarvatt: what kind of change?
<Sarvatt> tseliot: cjwatson uploaded a console-setup with keyboard-config and xorg-server needs a sponsor, fixed it up but it includes the other stuff queued up in git
<Sarvatt> tseliot: the fglrx/nvidia no xorg.conf needed change
<tseliot> Sarvatt: ok, how can I help? Aren't those changes ready?
<Sarvatt> been running it for 2 months now with no side effects, yeah just need a sponsor for http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/ if you have a bit of time
<Sarvatt> (and it's been enabled in xorg-edgers for the same amount of time)
<tseliot> sweet, there's a debdiff :)
<tseliot> Sarvatt: I'll review it and upload
<Sarvatt> tseliot: thanks a ton!
<tseliot> Sarvatt: the fix that RAOF included is something that I wanted to include myself so this basically saves me some time
<superm1> Sarvatt, with 105_* what happens if you actually still use an xorg.conf?  are you able to force it back and forth to radeonhd, ati etc ?
<Sarvatt> superm1: no difference
<superm1> i just seem to remember that there were some concerns raised with that a year back or so in #ubuntu-x
<superm1> where it broke a particular scenario
<Sarvatt> superm1: it just adds fglrx/nvidia to the autoconfig pool which isn't used when an xorg.conf is present
<tseliot> right
<tseliot> they are 2 different paths
<Sarvatt> superm1: the problem before was that it needed the DefaultDepth option to work
<superm1> oh right
<tseliot> and you really need that with fglrx and nvidia
<tseliot> ;)
<Sarvatt> only difference this will make is things will actually work if people install via a package manager and not jockey since jockey makes the xorg.conf
<tseliot> the debdiff looks good to me (I remember reviewing the same patch)
<superm1> well very cool then.  i suppose after that publishes jockey should have the functionality of making an xorg.conf disabled too
<Sarvatt> well it doesn't hurt having it in jockey, I didn't add the NoLogo option there :)
<Sarvatt> sometimes we need to add IgnoreABI to nvidia temporarily via jockey too
<tseliot> yes, we don't want the logo to show up when the session starts and we can add workarounds too, as Sarvatt says
<bdrung> doko: the press picked up your mail about libreoffice: http://www.golem.de/1101/80502.html
<tseliot> Sarvatt: maybe the change to panoramiXprocs.c should have been a patch
<tseliot> instead of a direct change
<tseliot> but I guess it's fine
<tseliot> Sarvatt: maybe the change to panoramiXprocs.c should have been a patch instead of a direct change but I guess it's fine
<tseliot> you use git to track these changes so it's definitely fine
<tseliot> Sarvatt: uploaded
<Sarvatt> tseliot: yeah i'd prefer it that way too, at least he actually cherry picked it into git this time instead of just updating the changelog :) thanks a bunch tseliot
<tseliot> np
<SpamapS> slangasek: so I think i have a handle on the statd issue. unfortunately it involves spinning waiting for statd to start the same way we had to spin and wait for portmap.
<slangasek> oh?
<SpamapS> the problem is that we *must* block mounting TYPE=nfs
<SpamapS> until statd is started
<slangasek> and why is that not happening?  isn't it just because statd forks before listen?
<SpamapS> so the timeline is.. we hit local-filesystems and started portmap ON_BOOT=y .. but then net-device-up fires at the same time, which tries to start statd, but does not block mounting .. so the mount fails
<SpamapS> basically if an event in upstart doesn't actually change the goal.. it doesn't block
<SpamapS> I think
<slangasek> oh; so the problem is statd is being triggered by an event other than 'mounting'
<SpamapS> right
<SpamapS> which it must be
<SpamapS> because of the requirement that it also be running for nfs-kernel-server in runlevel 2
<slangasek> right, certainly
<slangasek> so how do you solve this?  Not sure what you're talking about spinning waiting
<SpamapS> http://paste.ubuntu.com/550745/
<dobey> /usr/share/cdbs/1/rules/buildcore.mk:34: *** multiple target patterns.  Stop.
<dobey> anyone know why one would get that all of a sudden?
<SpamapS> slangasek: on review of statd, it should hit 'started' very quickly.
<SpamapS> slangasek: so 5 seconds is an eternity.
<cjwatson> mvo: I'm uploading grub2 1.99~20110104-2ubuntu1 now - that should build on amd64
<slangasek> SpamapS: I think you're a missing a comment in that file: "icky blech hack hack hack, remove when upstart is fixed" :)
<SpamapS> slangasek: the rant I put in the file was too long for the pastebin.. ;)
<slangasek> heh
<cjwatson> Fermat's Last Rant
<SpamapS> so yeah, there just needs to be a way to have new events attach to existing events
<dobey> is it really impossible to use substvars in package names?
<SpamapS> one thing that I'm confused on is how we can possibly run sm-notify on an NFS root system, since /var/lib/nfs would have to be unique to the machine
<kees> doko: oh? what was missed? it worked when I built it.
<ebroder> dobey: I'd expect that you'd need some major hackery that cdbs probably can't deal with
<dobey> ebroder: hrmm. not cool :-/
<ebroder> dobey: cdbs does things like calculate paths based on package names, but substvars aren't substituted until very close to the end of the build
<dobey> yeah i get that. it's still annoying :)
<doko> kees: just something not applying, maybe because of an update from the trunk. btw, it now ftbfs on amd64 with the hardening patches enabled
<ebroder> dobey: There are also all of the things like the automatically populated foo/package make targets
<kees> doko: gah. what fails?
<dobey> ebroder: yeah, which is why it should probably figure out the substitutions early, for internal use as well
<ebroder> dobey: I don't think you can do that many levels of code generation with make
<kees> doko: and you did get https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/696990/+attachment/1783015/+files/gcc-4.6_4.6-20101220-1ubuntu0.1.debdiff not the earlier one?
<ubottu> Ubuntu bug 696990 in gcc-snapshot (Ubuntu) "update for gcc-4.6 hardening patches" [High,In progress]
<slangasek> SpamapS: NFS root doesn't imply shared; indeed, /var/ *must* be unique, so anyone doing serious NFS rooting has to make provisions for this
<SpamapS> slangasek: actually I think we may be able to ditch the polling. If I do 'stop on started statd or stopped statd' then .. as evil as it sounds, we can just run 'start statd' and wait forever. *one* of those events will happen, and we'll be killed.
<slangasek> oh, that sounds less evil to me, yes :)
<dobey> ebroder: do you know if there is some other way to conditionally name packages?
<SpamapS> slangasek: any suggestions on how to wait forever? sleep 1bazillion seems a little silly
<geser> doko: re my linking problem: your hint seems to be correct: when I move the last .a more to the front the linking works
<slangasek> SpamapS: 'while sleep 3600; :; done' ? Pretty sure an hour-long nap is long enough :)
<ebroder> dobey: i think you'd need to use pure (pre-7) debhelper
<ebroder> dobey: i think i've seen something sort of like that done with the zephyr package, so you could look at that (it has provisions for building krb4 or krb5 versions of a bunch of packages, and figures out which at build-time)
<SpamapS> slangasek: one thing it does is it flags the event with an error.. so mountall bitches
<SpamapS> slangasek: but it doesn't affect any other events tied to the mounting event
<meebey> can I hint the software-center and/or app-install-data which package should be installed instead of the package it found the .desktop file in? the issue is that the package that contains the desktop file is only a portion of the software, instead a higher level metapackage should be installed
<sebner> huhu meebey :)
<meebey> sebner: hiya
<dobey> ebroder: is there any way to perhaps alter the list of packages being built in cdbs?
<cdbs> \o/
<dobey> ebroder: by mucking with a variable somehow, for example?
<cjwatson> dobey: you can generate debian/control from debian/control.in in your clean rule
<cjwatson> that's the usual way to dynamically generate binary package names
<cjwatson> you may also have to generate some other files, depending on how your packaging is laid out
<dobey> so just sed -e blah blah inside clean::?
<cjwatson> yeah
<cdbs> dobey: yup
<cjwatson> it has to be in clean because debian/control is read at the very start of the build, and the .dsc needs to match for archive consistency
<dobey> ok, i'll try that
<lifeless> barry: ping; nag.
<meebey> looks like a desktop file can be blacklisted, so I could add a symlink in the metapackage and get the other one backlisted
<doko> kees: see https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+packages (gcc-4.6 failures)
<kees> doko: you're building on maverick, not natty? I only tested natty.
<kees> ../../src/gcc/lto/lto.c:2464:1: internal compiler error: in ready_remove_first, at haifa-sched.c:1414
<kees> uuuhm, whoa
<kees> I don't think the hardening patches touch that file
<SpamapS> slangasek: this works to avoid spinning for portmap too. I think its probably the way to go for waiting for an event.
<doko> kees: same snapshot builds on unstable. will recheck next week with a new snapshot
<dobey> cjwatson: that seems to work sufficiently for what i need it for; thanks!
<kees> doko: hm, I wonder if maverick vs natty makes a difference?
<Sarvatt> cjwatson: console-setup in depwait for bdfresize thats in universe if you didn't see :(
<cjwatson> oh, bah
<barry> lifeless: hi.  thanks for the reminder.
<cjwatson> I got it MIR-approved eons ago - I'll promote it shortly
<cjwatson> Sarvatt: ^-
<Sarvatt> cjwatson: ah nice, thanks cjwatson!
<manjo> superm1, do you have any insight into  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588194 ?
<ubottu> Ubuntu bug 588194 in linux (Ubuntu) "Unexpected power-off during boot or when resuming from suspend" [Undecided,Triaged]
<zyga-efika> is the Toolchain WG call over
<zyga-efika> I'd like to see michael hope
<superm1> manjo, no sorry i can't say i've seen that before
<manjo> superm1, existed since lucid apparently
<manjo> superm1, looks like acpi related
<evfool> hi all
<evfool> trying to build unity from source, but I guess the https://wiki.ubuntu.com/Unity/InstallationGuideFromSource needs an update, cause nux can-t be built without gnome-common from svn
<cyphermox> evfool, maybe not so helpful for you, but if you're on natty, you can use the packages provided, unless you need to change them ;)
<SpamapS> slangasek: ok, pormap and nfs-utils changes are pushed up and merges proposed
<SpamapS> portmap even
<bdrung> cjwatson: you synced pwdhash 1.7-9, but it doesn't appear on https://launchpad.net/ubuntu/+source/pwdhash . what's going on?
<sebner> bdrung: cjwatson : Same with monobristol
<bdrung> same with audacious
<sebner> meh
<micahg> it's the same with everything that was sync'd today AFAICT
<sebner> breaaaaaaaaaaaaakage
<geser> syncs not flushed yet?
<kirkland> barry: howdy, around?
<barry> kirkland: hi
<hallyn> has anyone noticed that debdiff on natty always seems to add a bunch of .po files to the diff, when in fact you made no changes by hand to those files?
<ebroder> that's usually due a broken clean target
<hallyn> hm.  i've seen that with just about every package i've touched in the last two months,
<ebroder> i mean...debdiff isn't going to go making that sort of thing up
<hallyn> ebroder: right, I just don't know what to blame :)  automake?
<ebroder> hallyn: i don't really know. i haven't run into one of those sorts of packages recently, and it's never quite bugged me enough to chase after me
<hallyn> ebroder: yeah, ditto.  It might be getting close enough.  If I can close some other bugs I may have to go chase that down
<hallyn> thanks
<ebroder> err, chase after *it, as i'm sure you figured
<hallyn> heh, somehow i hadn't even noticed htat :)
<bdrung> hallyn: that (.po files to the diff) happens often if you build the binaries.
<hallyn> bdrung: I just don't remember ever seeing that with maverick, but am seeing it all the time with natty
<bdrung> hallyn: i assume this workaround should work: build only source (debuild -S) and build the binaries with pbuilder/sbuild.
<hallyn> bdrung: I *thought* I'd had this happen even with taht workflow, but can't swear by it.
<hallyn> if it happens again I'll ring :)
<bdrung> yes, and then let's find this bug that triggers the diff
<lifeless> barry: what version of python did .pth files start working in?
<cjwatson> bdrung: sorry, I just forgot to flush them.  flushing now
<bdrung> thanks
#ubuntu-devel 2011-01-06
<barry> lifeless: not sure, but at least as far back as 2.4
<lifeless> cool
<kklimonda> hmm, interesting - I have a patch in the maverick package that enables launchpad-integration
<kklimonda> it doesn't add any additional CFLAGS to the Makefile, and it worked fine during maverick development
<kklimonda> but now, that I try to make an SRU compilation fails - it can't find <launchpad-integration.h>
<kklimonda> I wonder whether I have broken my maverick pbuilder.. hmm..
<kklimonda> oh well, I'll work on that tomorrow
<TheMuso> /c/
<linuxfreaker> Is 2.6.37 Kernel expected in 11.04 Alpha2
<JackyAlcine> I doubt it, linuxfreaker.
<JackyAlcine> Maybe 2.6.36 but not 2.6.37
<micahg> 2.6.37 is already in natty
<linuxfreaker> 2.6.37-rc4 is there in natty, 2.6.37 just released yesterday
<micahg> I was commenting on the 2.6.36 vs 2.6.37 comment
<micahg> linuxfreaker: rc8 is in now
<linuxfreaker> Not rc8...GA already announced
<micahg> actually, it's 2.6.37 final https://lists.ubuntu.com/archives/natty-changes/2011-January/004719.html
<linuxfreaker> Check the kernel.org
<linuxfreaker> I compiled it yesterday..sounds better
<micahg> linuxfreaker: it's already in natty :P
<StevenK>   * rebase to v2.6.37 final
<linuxfreaker> ahh great
<linuxfreaker> So does it mean that Alpha2 will have 2.6.37 GA kernel
<StevenK> It's in about 3 weeks, but yes
<StevenK> Well, Ubuntu doesn't use kernel.org kernels, but it will be based on 2.6.37 final
<Keybuk> StevenK: well, we do use kernel.org kernels
<Keybuk> we just add things to it
<dholbach> good morning
<dholbach> bryceh, chrisccoulson: happy new year and happy patch pilot day (if you're back from holidays already :-))
<linuxfreaker> I want to raise a bug
<linuxfreaker> in Launchpad
<linuxfreaker> I created an a/c
<linuxfreaker> how can I raise a bug
<linuxfreaker> I dont see "
<linuxfreaker> Create new bug" section anywhere
<micahg> linuxfreaker: run 'ubuntu-bug PKGNAME' from the cli
<akshatj> linuxfreaker: is it a bug in a different package or launchpad itself?
<micahg> ah, that's a good question...
<pitti> Good morning
<JackyAlcine> Morning, pitti
<chrisccoulson> hi dholbach, and happy new year to you too :)
<chrisccoulson> am i patch pilot today? i'm still officially on vacation until monday ;)
<chrisccoulson> (although, i'll be hanging around for most of the day)
<dholbach> chrisccoulson, nevermind then - take it easy :)
<pitti> bryceh, Sarvatt: are you on the current xserver-xorg-core uninstallability? it depends on "keyboard-configuration" which doesn't exist
<pitti> and it's not in NEW either
<linuxfreaker> akshat: Pretty Funny
<linuxfreaker> But I am not on Ubuntu machine
<linuxfreaker> I want to file a bug through website
<linuxfreaker> launchpad.ubunut.com
<linuxfreaker> launchpad.ubuntu.com
<akshatj> linuxfreaker: its launchad.net
<akshatj> oops
<akshatj> launchpad.net
<linuxfreaker> akshatj: Cannot see File or Create a bug option
<linuxfreaker> whers that?
<didrocks> good morning
<linuxfreaker> gm
<linuxfreaker> didrocks: How r u?
<akshatj> linuxfreaker: there is 'Report a Bug' under 'Get Involved' in the right
<didrocks> linuxfreaker: I'm fine, thanks, and you?
<linuxfreaker> akshatj: I am unable to see anywhere..can yu send me the complete link
<linuxfreaker> I can browse the bugs but dont see where I can sumbit new bug
<cjwatson> pitti: that's my problem
<cjwatson> (pending MIR promotion, then keyboard-configuration will be in NEW shortly afterwards)
<akshatj> linuxfreaker: you can't see this http://imgur.com/3S2e6 ?
<cjwatson> linuxfreaker: https://help.ubuntu.com/community/ReportingBugs
<cjwatson> especially https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net
<linuxfreaker> akshatj: thanks
<apw> is there something wrong with the launchpad build farm?  i have builds which claim to have finished 9 hours ago which are still 'uploading build'
<apw> https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125799
<cjwatson> #launchpad would have better ability to check ...
<cjwatson> I hadn't heard of a general problem
<apw> cjwatson, thanks
<apw> cjwatson, am not the only one affected, so i guess a generic problem
<apw> cjwatson, seemes everything finishing since the 'deployment this morning' are stuck and not uploading
<apw> cirtainly some 8 hours or so ago at least
<Riddell> cjwatson: can we chat about kubuntu seeds today?
<Riddell> we need to work out if kubuntu mobile bits should be in an entirely separate seed
<Riddell> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<Riddell> goodness
<Riddell> bug 696675 is the issue, fix uploaded to -proposed awaiting approval
<ubottu> Launchpad bug 696675 in kde-l10n-engb (Ubuntu Lucid) "kde l10n packages depend on libkdecore5 which doesn't exist" [High,Confirmed] https://launchpad.net/bugs/696675
<pitti> hey Riddell
<pitti> Riddell: ah, will do right away
<Riddell> thanks
<pitti> uh, *all* those? ok
<bdrung> is there an problem with the archive? various builds are on "uploading build" for hours. e.g. https://launchpad.net/ubuntu/+source/pwdhash/1.7-9/+build/2126172
<dholbach> bdrung, see conversation between apw and cjwatson above
<apw> bdrung, #launchpad released something last night and its broken binary uploads by the seems of it
<mvo> cjwatson: I just booted into a btrfs boot via the new grub, pretty impressive :) it seems like grub-probe is unhappy and cant identify /boot but from the grub shell at boot its all good
<dupondje> Hi guys, can we mark bug https://bugs.launchpad.net/ubuntu/+source/php5/+bug/697181 as critical ?
<ubottu> Ubuntu bug 697181 in php5 (Ubuntu Natty) "DoS: Infinite loop processing 2.2250738585072011e-308" [Undecided,Confirmed]
<dupondje> needs some fast attention :)
<apw> bdrung, looks like things are uploading now
<linuxfreaker> I was running a NIC Hot-Add script on Ubuntu 10.10 VM and the script failed at the stage where in it checks the entries under /etc/udev/rules.d/70-persistent-net.rules  for the MAC address
<linuxfreaker> The script was checking for the Mac address entry for the newly added NIC under this file but there wasnât any entry!
<linuxfreaker> It was working in 9.10
<linuxfreaker> I tried to run the same script under Ubuntu 9.10 32bit VM, and after the NIC hot-add operation, the MAC address details were logged under the 70-persistent-net.rules file
<linuxfreaker> Pls Suggest..
<cjwatson> Riddell: is kubuntu-mobile still a universe thing?
<cjwatson> mvo_: can you get a -v log from grub-probe?
<cjwatson> mvo_: it's odd for it to work at boot but for grub-probe not to work; usually, by design, those two go together
<mvo_> cjwatson: sure, to me its inconclusive, but I'm happy to post it in a sec. it might be some oddness because this was a /boot on ext2 before that I manually converted (well, copied over)
<Riddell> cjwatson: well no, it got moved to main because keeping it in universe was too fiddly
<Riddell> cjwatson: but really it should be in universe
<mvo_> cjwatson: http://paste.ubuntu.com/551019/ (i can do one of / for comparison if that helps and/or strace it
<cjwatson> Riddell: if it's a pain to move it to a separate seed, I think I can perhaps manage to nobble component-mismatches to not consider the mobile part of the tree
<cjwatson> er, to a separate collection
<cjwatson> mvo_: what were the arguments for that?
<cjwatson> mvo_: actually, I should have asked for -vv
<cjwatson> Riddell: the component-mismatches change looks quite difficult though, and might need a Launchpad change.  How much of a pain would it be to move mobile to a separate seed collection?
<mvo_> cjwatson: http://paste.ubuntu.com/551020/ (this time with the commandline)
<cjwatson> mvo_: could you paste /proc/self/mountinfo?
 * cjwatson has a suspicion ...
<mvo_> cjwatson: sure http://paste.ubuntu.com/551022/
<sebner> Riddell: mind accepting monobristol into maverick updates? bug #688847
<ubottu> Launchpad bug 688847 in monobristol (Ubuntu) "[patch] startBristol process directly use sound device." [Medium,In progress] https://launchpad.net/bugs/688847
<Riddell> cjwatson: I think a separate seed collection would be the easiest thing to do
<Riddell> sebner: that tends to be pitti's domain
<sebner> Riddell: ah, sorry. Just saw that you are on duty today
<pitti> sebner: it needs to be fixed in natty first
<sebner> pitti: done ;)
<Riddell> sebner: I am?
<pitti> sebner: ah, so the natty task should be closed?
<sebner> Riddell: Tuesday: JonathanRiddell
<pitti> today is Thursday..
<sebner> Riddell: as long as the wiki isn't outdated
<sebner> argh
 * sebner = confused
<sebner> xD
<sebner> Riddell: I'm sorry
<sebner> pitti: done
<pitti> sebner: thanks, moving to -updates
<cjwatson> mvo_: thanks - fixed upstream, http://paste.ubuntu.com/551023/
<sebner> pitti: thank you :)
<sebner> pitti: you know, when one is student and still on holidays one tend to confuse thuesday with thursday :D
<pitti> sebner: I know the feeling; I mixed them up during my two weeks of christmas holidays, too :)
<sebner> heh =)
<mvo_> cjwatson: rock! thanks
<cjwatson> pitti: do you think you could NEW keyboard-configuration, since you asked about it earlier? :-)
<pitti> cjwatson: sure, looking
<pitti> cjwatson: is this a splitout of some kind, or does it need to go through MIR?
<cjwatson> it's binary NEW
<pitti> oh, just a new binary
<cjwatson> console-setup was split into a couple of pieces binary-wise
<pitti> cjwatson: is not having a Replaces: to go with the Conflicts: intented?
<cjwatson> hmm, I suspect there were no overlapping files upstream
<cjwatson> let me adjust that before you process it
<pitti> 'k
<pitti> cjwatson: there are a couple of bashisms in config and postinst; aside from that conflicts: it looks fine to me
<cjwatson> looks like I have to think a bit about how to handle console-setup-tty
<cjwatson> pitti: which bashisms?
<pitti> W: keyboard-configuration: possible-bashism-in-maintainer-script config:26295 'if type '
<pitti> W: keyboard-configuration: possible-bashism-in-maintainer-script config:26831 '& type '
<pitti> that's what lintian says anyway
<cjwatson> well
<pitti> not quite sure why, type exists in dash, too
<cjwatson> that's technically nonportable but all the /bin/sh implementations I know of support it
<pitti> right
<pitti> so let's ignore that one
<AnAnt> Hello, would someone comment on LP 697538 ?
<ubottu> Launchpad bug 697538 in ncurses (Ubuntu) "Sync ncurses 5.7+20101128-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/697538
<cjwatson> right, I think console-setup-tty simply belongs in console-setup, not k-c
<cjwatson> and the initramfs stuff too.  (keyboard-configuration basically exists to be a lighter dependency for X ...)
<pitti> so that you can have a downsized system with just X, and no VT font config and the like?
<cjwatson> oh, wait, they go in keyboard-configuration because they're meant to be shared with console-setup-mini (which Ubuntu doesn't really use but nevertheless if we build it we should make it work)
<cjwatson> so in fact it *is* meant to have the init stuff
<cjwatson> (sorry, this split was done upstream, I'm following alongg)
<pitti> cjwatson: I need to run out for about two hours; I'm happy to have a look afterwards unless someone else beats me to it
<cjwatson> I think I'll just add the Replaces
<pitti> cjwatson: ok; feel free to NEW it yourself then
<pitti> I can imagine how it'll look like :)
<mok0> I am puzzled that the debian policy says that the get-orig-source rule should leave the tarball in the current directory. When run from $topdir, it is then necessary to manually move the tarball one notch up
<cjwatson> pitti: http://bazaar.launchpad.net/~ubuntu-core-dev/console-setup/ubuntu/revision/165
<cjwatson> mok0: it also says "This target may be invoked in any directory", so I think the idea is that you *call* it from one level up
<tumbleweed> cjwatson: practically that invoking from any directory bit is hard to implement (if you are going to use dpkg-parsechangelog to determine the version)
<tumbleweed> I've always ignored it
<mok0> cjwatson: yes... but don't the tools always run from $topdir?
<apw> cjwatson, i assume seeds do not get turned into packages ?
<mok0> cjwatson: I can see that leaving files in $cwd is the most logical behaviour though
<cjwatson> mok0: get-orig-source is run by hand though, not via "the tools"
<mok0> cjwatson: afaik bzr-buildpackage tries to run it
<cjwatson> heh, its problem then :)
<tumbleweed> yeah, it runs it in the root of the package
<cjwatson> that seems like a bug on the face of it
<cjwatson> tumbleweed: get-orig-source doesn't need dpkg-parsechangelog information
<cjwatson> apw: some seeds do.  what do you mean?
<tumbleweed> cjwatson: how do you know which versino to download then (unless you change it on every upstream release)
<mok0> I am not sure though bzr-buildpackage might move it to its build-area
<apw> cjwatson, oh i was looking at platform.natty, to see what happened to it after it was changed
<cjwatson> tumbleweed: "the most recent version"
<apw> cjwatson, and it doesn't seem to have releases or tags, or indeed a changelog
<tumbleweed> hmm, that is a point, still that's not what one normally wants
<cjwatson> apw: phone, brb
<apw> anyone seen 'different serializers' errors when pushing a new branch to launchpad ?
<cjwatson> apw: some packages use the seeds to generate dependencies and the like, for example the ubuntu-meta source package
<cjwatson> apw: the changelog is 'bzr log'
<apw> cjwatson, so used in consumer packages, but the branch itself is just a repo
<cjwatson> correct
<apw> cjwatson, looking at platform.natty there are a lot of arm kernels listed which i don't believe exist
<apw>  * Kernel-Version: 2.6.32-410-dove 2.6.37-12-omap 2.6.35-1101-omap4 2.6.31-800-st1-5 2.6.37-11-iop32x 2.6.37-10-ixp4xx 2.6.37-11-orion5x 2.6.37-12-versatile
<apw> ixp4xx and orion5x particularly i am wondering about there
<ogra> yeah, we need to clean that up at some point
<cjwatson> it doesn't cause a problem though
<ogra> ixp is a leftover from jaunty
<cjwatson> iop32x as well
<ogra> our first arm images were for nslu2
<ogra> yep
<cjwatson> apw: BTW it's best to change those entries only in sync with a debian-installer upload
<cjwatson> I usually just use sed
<cjwatson> apw: if you want to do that in an hour's time (once the kernel's in the archive) by way of practice, I can merge/sponsor
<apw> cjwatson, yeah i've been doing the d-i changes too (https://code.launchpad.net/~apw/debian-installer/kernel-update) for the practice
<apw> cjwatson, thanks
<cjwatson> sed -i 's/2.6.37-11/2.6.37-12/g' *installer*
<cjwatson> apw: that's fine except that it's good practice to have the changelog say UNRELEASED instead of natty until it's actually uploaded
<apw> cjwatson, oh yeah i pushed it after playing with debcommit -r, ooops
<apw> cjwatson, ok those binaries are now 'in', and i've also uploaded meta (not sure that you care for this), i've pushed the d-i changes here: https://code.launchpad.net/~apw/debian-installer/kernel-update and the platform.natty changes here: https://code.launchpad.net/~apw/ubuntu-seeds/platform.natty-kernel-update
<pitti> cjwatson: re; looks fine; should I review it again?
<pitti> ah, it's in the queue, doing
<pitti> cjwatson: accepted
<cjwatson> apw: thanks, will review in a minute then
<cjwatson> pitti: great, thank you
<apw> cjwatson, whenever you have time, thanks :)
<cjwatson> it isn't necessary for linux-meta to be in place before building a new installer, but it does mean that the installer will actually install the new kernel
<benste> I'd need a review for https://code.launchpad.net/~benste/kdeedu/bugfix-lp-698056_b/+merge/45397 but kubuntu-dev list rejects my message
<pitti> Hah - "Committed revision 666."
 * pitti says "All hail to the creator of Linux" before he gets a penalty card
<shadeslayer> asac: poke ... around?
<asac> shadeslayer: whats up?
<shadeslayer> asac: hi, so i saw your post on android + Linaro
<shadeslayer> asac: and kubuntu has something called plasma-mobile running on the N900, is it possible to run that on my android device as well? ( HTC Desire )
<shadeslayer> plasma-mobile is already in the archives
<shadeslayer> the only possible way right now is to boot a lucid chroot off my phone and install the binaries
<shadeslayer> from here : http://code.google.com/p/android-cruft/wiki/LucidWithAndroid
<dholbach> debconf questions by keyboard-configuration?
<dholbach> "Method for toggling between national and Latin mode"
<dholbach> ???
<dholbach> :)
<cjwatson> shouldn't ask new questions, that's a bug.
<cjwatson> can you please STOP HERE
<cjwatson> and capture /etc/default/console-setup before it overwrites it
<cjwatson> and ideally also /var/cache/debconf/config.dat and /var/cache/debconf/templates.dat
<cjwatson> then carry on and record all the questions it asks
<dholbach> will do
<cjwatson> it's odd because it should have copied that one from console-setup/toggle, looking at the code
<cjwatson> though, hm, console-setup/toggle only used to be asked for non-Latin layouts
<cjwatson> and that still ought to be the case, so for some reason it thinks you have a non-Latin layout
<dholbach> https://bugs.launchpad.net/ubuntu/+source/keyboard-configuration does not seem to exist?
<Laney> source: console-setup
<dholbach> oops
<dholbach> sorry about that :)
<hallyn> Daviey: would you mind taking a look at https://code.launchpad.net/~serge-hallyn/ubuntu/natty/multipath-tools/backport-fixes/+merge/45410 if you get a chance?
<asac> shadeslayer: hmm ... the problem are drivers/kernels etc.
<shadeslayer> asac: well ... cyanogenmod has the kernel source code ... and it works, so can we not use that?
<dholbach> cjwatson, if there's any more information I can put into bug 698177, let me know
<ubottu> Launchpad bug 698177 in console-setup (Ubuntu) "keyboard-configuration asks debconf questions" [Undecided,New] https://launchpad.net/bugs/698177
<shadeslayer> HTC Provides the kernel source code as well
<asac> shadeslayer: the kernel might be a bit crippled, but it would be worth a try ;)
<hallyn> cjwatson: (just fyi) since the sync is gonna take me a little while for multipath-tools, I'm trying to push the fixes I've got sitting around for exsting bugs to natty separatley first, since that seems to make sru easier afterwards.
<shadeslayer> :)
<smoser> cjwatson, i now there isn't much information, but do you have thoughts on what might be causing bug 697493
<ubottu> Launchpad bug 697493 in grub2 (Ubuntu Natty) "invalid free in grub-mkrelpath" [High,Confirmed] https://launchpad.net/bugs/697493
<cjwatson> dholbach: ok, will queue it up
<cjwatson> hallyn: thanks
<dholbach> thanks a lot cjwatson
<cjwatson> smoser: can you reproduce it under valgrind?
<smoser> i haven't tried, and i figured that was what you were going to ask :)
<smoser> but i'm guessing that i can.
<smoser> i was just hoping you'd say "oh, i know what changes would have caused that"
<cjwatson> smoser: the most likely candidate is probably the btrfs patch, but I don't have a specific thing to point to there (having just read through it)
<lool> pitti: Hey there
<pitti> hey lool, bonne annee! ca va?
<lool> pitti: I'm trying to track what happened with the linux-linaro-omap dbgsyms
<lool> pitti: Ein frohes Jahr 2011 zu dir!  :-)
<lool> pitti: Going alright -- happy to see you next week :)
<pitti> \o/ likewise
<pitti> lool: so, they don't exist?
 * pitti checks
<lool> pitti: The linux-linaro-omap upload log shows the dbgsym in the .changes, but they don't appear in http://ddebs.ubuntu.com/pool/main/l/linux-linaro-omap/
<lool> and linux-linaro-omap is in main for some reason
<pitti> we currently have all kernel packages in main
<lool> 17:54 < pm215> lool: is it expected that the dbgsym package doesn't appear in  the Checksums-* sections?
<pitti> lool: ah, it's new in natty
<lool> pitti: I think similar issues occured in maverick, but I don't have specific packages to point out; yes, it's new in natty
<pitti> lool: so, sometimes the ddeb retriever hangs a long time because a buildd's apache is acting up
<pitti> in these cases I need to kill and manually restart it; also, there are other cases where the ddeb-retriever is dropping packages :-(
<pitti> i. e. it's possible that it just fell through the cracks
 * pitti really wants soyuz ddeb support *sigh*
<lool> pitti: How does one usually go with such issues?  ping you?  rt ticket?
<pitti> lool: right, so it built around christmas
<pitti> lool: ping me
<pitti> lool: the buildds keep ddebs for 7 days
<pitti> lool: so if a ddeb doesn't appear after build, I can rescue it within a week
<pitti> but then it's gone :-/
<lool> I see
<lool> pitti: Can you confirm that what happened was that the ddeb retriever was borken?
<pitti> no, I can't
<lool> pitti: Maybe we should send a weekly summary of ddeb copied to ddebs.u.c to some list of people so that we can react if it's empty?
<pitti> "nothing last as long as a makeshift"
<pitti> (which ddeb-retriever is)
<lool> eh
<pitti> wgrant: ^ OOI, is there an update for this? I thought soyuz got ddeb support ages ago, and it's 90% there?
<pitti> lool: http://ddebs.ubuntu.com/pool/main/l/linux/ does have armel ddebs, so it's not a general problem with the hack for linux (earlier releases had broken package names) or armel
<pitti> lool: so I'm afraid the only practical solution right now is to upload a rebuild, and then I watch what happens in the retriever
<pitti> lool: I guess you want to update to .37 final anyway?
<lool> pitti: Ok
<lool> pitti: We will have other uploads, I'll try to think of pinging when it happens  :-)
<pitti> lool: merci
<lool> pitti: i'll check with jcrigby to arrange that
<lool> pitti: thanks to /you/!
<pitti> lool: ah, now that macquarie is on lucid, I could even re-enable my timeout patch, to avoid the endless hangs
<pitti> hardy's python didn't support that yet
<pitti> lool: done
<lool> pitti: thanks
<pitti> lool: so, this ping was at least good to improve it in the future :)
<lool> Eh
<pitti> tkamppeter: hah! I just got Jockey to install the Epson printer driver from the op.o repository, with all the GPG fingerprint and trusted repository checking \o/
<superm1> pitti, hi. did you have thoughts about how you were planning on blocking nvidia and fglrx driver being offered in the live environment?  I was hoping there will be a way to control this.  at least for my purposes i'd like to have a way to make sure all drivers can still be offered in some fashion
<pitti> superm1: I was going to add a two-liner to both handlers to check for /rofs/, and fail if it exists
<pitti> superm1: so that you can still install wl, etc.
<pitti> I think ev heroically fixed that initramfs update problem, so that should work again
<pitti> superm1: what do you mean with "control"?
<superm1> pitti, well for my purposes i'd still like to offer them as potential targets when i run jockey during post install
<pitti> superm1: there might also be a more elegant way with putting an empty modalias override file into /usr/share/jockey/modaliases/ for fglrx and nvidia in casper
<pitti> superm1: what is "post install" in your case?
<superm1> pitti, but aren't they both now controlled by the debian package header for modaliases not the modaliases file?
<pitti> superm1: wouldn't you call that in chroot /target ?
<pitti> superm1: they are, but the modaliases/ dir is still supported
<superm1> pitti, so a blank file takes precendence?
<pitti> superm1: you'd need to add a "reset nvidia" line to it to purge the ones collected from modinfo and the package headers
<superm1> oh but you're right that I do call the backend and jockey text in the chroot, so it is likely a moot point
<superm1> there would be no /rofs in that chroot
<pitti> superm1: I don't know whether I got the ordering of those right, but I can ensure that this works
<pitti> superm1: my thought
<elif> Hi, how kickstart works ? it is translated to a preseed file ? what package source should I look for ?
<pitti> superm1: we want to disable it because there's usually too little RAM to download all the pacakges, build and install them
<superm1> pitti, right, makes sense to me.  then no worries from my side :)
<pitti> superm1: in /target/ that's not a problem of course, and it should just work
<pitti> superm1: ok, cool ;)
<sm> g'day all. When might the fix for https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/67235 become available for regular maverick users ?
<ubottu> Ubuntu bug 67235 in totem (Ubuntu) "thumbnailer crashes on unfinished avi's or .oggs" [Medium,Invalid]
<ebroder> pitti, superm1: there's no point in installing new X drivers in an actual live cd environment, since there's no persistance. but if you do a usb-creator install with persistance, then it does make sense
<ebroder> and hopefully you have enough disk space in the persistance file and RAM to support doing that
<superm1> you'd need to reboot though for that to even work most likely
<ebroder> so maybe the test should be more "if os.path.exists(/rofs") and 'persistant' not in open('
<ebroder> err... os.path.exists('/rofs') and 'persistant' not in open('/proc/cmdline').read()
<superm1> i doubt you'd be able to stop X, unload nouveau/radeon, load nvidia/fglrx safely
<ebroder> superm1: rebooting is fine. there's code to pull the new initrd out of the aufs filesystem into /cdrom, so that should all work
<barry> doko_: chinstrap:~barry/ethos*
 * sm meant https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/672352 , oops
<ubottu> Ubuntu bug 672352 in eglibc (Ubuntu Maverick) "Assertion `_rtld_global_ro._dl_pagesize != 0' failed" [Undecided,Fix released]
<cjwatson> sm: it looks as though it's available right now.       libc6 | 2.12.1-0ubuntu10 | maverick-updates | amd64, armel, i386, powerpc
<cjwatson> you do of course have to have updates enabled ...
<apw> cjwatson, has anything significant changes in grub graphics handing since 20101126 ?
<cjwatson> apw: preferred VBE resolution detection; vt.handoff=7
<cjwatson> oh, and a fix for PCI probing, I suppose that's tangentially related
<apw> cjwatson, so even when =text is deployed we would still have done more graphics fiddling
<cjwatson> yes, though it ought to have been set back to VGA text
<cjwatson> GRUB_GFXMODE=640x480 should avoid the VBE resolution detection
<apw> i think i'll punt till i can get my hands on the machine as it will be in dallas
<sm> cjwatson: thanks, good to know
<cjwatson> apw: *nod*
<sm> cjwatson: any idea why that didn't show up on the bug page like maverick-proposed and natty ?
<cjwatson> sm: not sure I understand your question
<sm> launchpad-janitor posted on the bug page when the fix arrived in those repos/pools/releases, but not when it arrived in maverick-updates
<cjwatson> actually, it posted when it arrived in -updates
<cjwatson> it's just that the changelog was written when it was uploaded to -proposed, so says "maverick-proposed"
<cjwatson> but that's misleading
<sm> it sure is. I wonder if that's why I failed to help someone install it from -proposed recently
<cjwatson> we remove things from -proposed after they reach -updates
<cjwatson> you can see where something's published in Launchpad
<cjwatson> https://launchpad.net/ubuntu/+source/eglibc in this case
<sm> I had a little extra trouble figuring things out because the source and binary packages have difference names ? eglibc/libc6 I think
<cjwatson> yes
<cjwatson> but the bug URL you posted above had the source package name in, which is what you need in this case
<cjwatson> in fact, just go to the bug page and follow the "Overview" link at the top
<cjwatson> the eglibc source package produces quite a few binary packages - libc6 is just arguably the most important one of them
<sm> I see.. clear now, and that's a useful link.. thanks!
<cjwatson> there are development packages, cross-architecture stuff, ...
<cody-somerville> cjwatson, You don't happen to know of a way off the top of your head to prevent cdrom being added to sources.list during d-i install?
<cjwatson> cody-somerville: not OTTOMH, no, which isn't to say it's not possible
<lifeless> pitti: still around per-chance?
<pitti> lifeless: yes, but on the phone
<lifeless> ok cool
<lifeless> I'll type some stuff and you can reply whenever ;)
<lifeless> I wanted to upload blobs to lp.net/+storeblob but the implementation in apport is a bit tightly coupled
<lifeless> I found http://pypi.python.org/pypi/poster/ which isn't packaged
<lifeless> *if* it gets packaged, would apport be able to switch to using that? [is there anything over and above a code-change at issue?]
<pitti> lifeless: apport/crashdb_impl/launchpad.py has a separate upload_blob() function; that doesn't work for you?
<lifeless> pitti: apport isn't widely available e.g. on windows
<pitti> lifeless: not a principal problem, just that I'd like to avoid yet another dependency
<pitti> lifeless: ideally it'd go into launchpadlib (bug 315358)
<lifeless> pitti: copying the code out seems undesirable (and the project I want it in is BSD anyhow)
<ubottu> Launchpad bug 315358 in Launchpad itself "Expose the storeblob service in API" [Low,Triaged] https://launchpad.net/bugs/315358
<lifeless> pitti: sounds like you'd be happy if launchpadlib used posted and you use launchpadlib ?
<pitti> lifeless: yes, that'd be fine
<Dawgmatix> I just cross compiled some libraries using the mingw32 toolchain for running on windows. these create files with a .dll.a and .la extensions. any ideas on how to use these with visual studio?
<directhex> yikes... i'd be amazed if you could
<Dawgmatix> i see
<wgrant> pitti: DDEB support is 90% there. But disk space is not.
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bryceh
<ebroder> hmm...does unity on natty not like monitor resolution changes?
<bryceh> ebroder, haven't tried it, but wouldn't surprise me if it's bugged
<cnd> I'm trying to use requestsync to request a sync of rinputd 1.0.4-1 which fixes ftbfs in natty for 1.0.3-6, for which the package was patched and reuploaded as 1.0.3-6ubuntu1 by someone else
<cnd> I'm stuck trying to figure out if I should use the '-e' option of requestsync
<cnd> "  -e          Use this after FeatureFreeze for non-bug fix syncs, changes
<cnd>               default subscription to the appropriate release team."
<ebroder> cnd: no, we're not past featurefreeze
<cnd> 1.0.4-1 fixes the ftbfs correctly, whereas 1.0.3-6ubuntu1 papers it over with a gcc switch
<cnd> zurgh, I thought that said import freeze
<cnd> ebroder, thanks!
<bryceh> that option seems like something that ought to be automatically detected...
<ebroder> is the release schedule actually listed in a machine parseable form anywhere? all i know of is the wiki page
<bryceh> yeah don't think so.  it ought to be though.
<bryceh> probably could be hacked into launchpad and exposed through launchpadlib in some fashion
<bryceh> (no I'm not volunteering!)
<bryceh> hmm, a really easy approach would be to just provide a JSON version of the schedule at some official-ish url, that scripts could snag.  THAT wouldn't be hard.
<cnd> parse the wiki page? :)
<bryceh> cnd, I think by 'machine parsable' he was excluding that option ;-)
<cnd> heh
<mterry> kees, you still around?
<kees> mterry: yup!
<mterry> kees, I updated the glib2.0 packaging branch to fix bug 698131, but belatedly realized that glib2.0 isn't in the ubuntu-desktop set, so I couldn't push it
<ubottu> Launchpad bug 698131 in glib2.0 (Ubuntu) "[Natty] New glib2.0_2.27.90-0ubuntu1 crashes gnome-panels" [Undecided,In progress] https://launchpad.net/bugs/698131
<mterry> kees, can I impose upon you to do a quick review and push it for me?
<kees> oh! sure thing
<mterry> kees, (asking you since you commented on the bug :))
<mterry> kees, thanks!
<kees> mterry: is the blank line 8 in debian/patches/series intentional? (not that it matters)
<mterry> kees, huh, odd.  I did an quilt import and quilt rename, didn't hand-edit it
<kees> no worries, it was there from before. quilt just appended.
<mterry> ah, that makes sense
<kees> mterry: everything looks great. I'll upload it now. thanks for finding/fixing it! :)
<mterry> kees, eh, seb128 pointed me at the patch, easy enough to download and stuff in the series.  ;)
<kees> :)
<tkamppeter> pitti, still there?
<kees> mterry: uploaded now. thanks again!
<mterry> kees, cool
<bdmurray> Amaranth: should bug 301174 really be triaged for compiz?
<ubottu> Launchpad bug 301174 in compiz (Ubuntu) "Use proper sound event instead of system beep" [Low,Triaged] https://launchpad.net/bugs/301174
<Amaranth> bdmurray: Yeah, we know of a way to work around the issue in compiz
<Amaranth> bdmurray: upstream doesn't want to do it the straightforward way though so it hasn't happened yet :)
<cjwatson> apw: version bump stuff all merged and uploaded now, belatedly
<apw> cjwatson, thanks a lot
<apw> cjwatson, just in time for the cds which will make the arm peeps happy
#ubuntu-devel 2011-01-07
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<sladen> jdstrand: are you happy with the one-word fix for bug #697181
<ubottu> Launchpad bug 697181 in php5 (Ubuntu Natty) "DoS: Infinite loop processing 2.2250738585072011e-308" [Undecided,Confirmed] https://launchpad.net/bugs/697181
<EagleScreen> is powerpc arch supported in natty?
<micahg> EagleScreen: I think it's community supported ATM
<EagleScreen> oh I thought it was going to be official in natty
<micahg> oh, maybe
<EagleScreen> but currently pbuilder doesn allow me to create a root for powerpc
<JanC> why would PPC become official again?
<TheMuso> its still community.
<JackyAlcine> Guys, I have a question regarding Boolean algerba and C++
<sladen> JackyAlcine: just ask!
<JackyAlcine> It deals with int enums.
<JackyAlcine>  Like let's say you have an enum {a = 0, b, c, d, j, k, l, m} would b & l give the same int value as a & m?
<JackyAlcine> ?
<sladen> JackyAlcine: && is logical;  & is bitwise.  Which are you after?
<JackyAlcine> I think bitwise, I'm trying to create a field to a class that uses the enum as flags, and I want the flags to incorporate a bunch of them.
<JackyAlcine> I think I should just use a vector<string>, lol.
<sladen> JackyAlcine: you might have  enum {a = 0x1, b = 0x2, c = 0x4, d=0x8, e=0x10, ...;}   and test an integater flag field with that?
<sladen> integer
<sladen> JackyAlcine: but yes, strings would stop you running out of bits and easier for a human to debug
<micahg> strings will also increase the amount of memory for each operation
<JackyAlcine> That's what I'm trying to avoid, micahg; this field's going to be accessed very often.
<kees> doko_: can you apply the patch in 691722 to the next upload of gcc-4.5 in natty?
<dholbach> good morning
<micahg> dholbach: good morning, I have a fix for gnome-python-extras coming in a few minutes, would you be able to upload it?
<dholbach> micahg, I can take a look at it but might not be the best person to judge it
<micahg> dholbach: ok, I can ask someone from the -desktop team, thanks
 * nixternal hugs dholbach 
 * dholbach hugs nixternal back :)
<tkamppeter> pitti, hi
<didrocks> good mornning
<pitti> good morning
<pitti> tkamppeter: hey
<pitti> tkamppeter: thanks for the announcement :)
<pitti> tkamppeter: btw, perhaps you can update the paragraph about trusted paths?
<pitti> tkamppeter: as distro developers now don't need to manually download and verify the key, jockey does that automatically now
<fta2> d'oh! the last kernel update doesn't like the nvidia driver. bug 698327
<ubottu> Launchpad bug 698327 in nvidia-common (Ubuntu) "[natty] /etc/kernel/postinst.d/nvidia-common: line 8: [: too many arguments" [Undecided,Confirmed] https://launchpad.net/bugs/698327
<pitti> cnd, bryceh: you both uploaded an xorg-server package to maverick-proposed; can you please upload the latest one with an appropriate -v to include the two proposed versions, or better yet, just upload a 2:1.9.0-0ubuntu7.2 which has both changes?
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: cjwatson
<pitti> cjwatson: happy piloting!
 * dholbach hugs cjwatson
<tkamppeter> pitti, great work.This completes one of the main projects of OpenPrinting, at least from the infrastructure side. I hope this motivates more manufacturers to create LSB-based printer driver packages (and then also more distros to automatically download and install them).
<cjwatson> (I have to go out in a bit under an hour, but will resume after that)
<tkamppeter> pitti, can you give me the link to the upstream home page of Jockey, so that I can reference to Jockey on the OpenPrinting page which describes the driver packaging?
<pitti> tkamppeter: https://launchpad.net/jockey
<tkamppeter> pitti, thanks.
<pitti> tkamppeter: the upstream version provides all the building blocks for GPG etc.; but the distro implementation actually needs to call them (as adding repositories and installing GPG keys is package system dependent)
<pitti> tkamppeter: i. e. the apt bits are only in the Ubuntu branch; on an RPM based distro you need to implement it differently
<pitti> tkamppeter: I'll try to fix the long hang of the progress dialog today
<tkamppeter> pitti, can you send me a text piece to add to the "Build a trusted path to distributions" section of the OpenPrinting packaging documentation to tell how it works if Jockey is used and in which cases Jockey is ready to be used and what Jockey is still missing?
<directhex> oh, what's the right way to say "there are ppds missing" to the openprinting folks these days?
<pitti> tkamppeter: something like this? http://paste.ubuntu.com/551431/
<tkamppeter> pitti, thanks. will merge it into the site.
<cjwatson> mvo: looking at bug 677516 - is it just me or is the proposed fix of making unattended-upgrades-shutdown setuid daemon extremely worrying?
<ubottu> Launchpad bug 677516 in One Hundred Paper Cuts "No sign of updates still being installed when shutting down" [Low,In progress] https://launchpad.net/bugs/677516
<cjwatson> mvo: I don't quite understand why unattended-upgrades-shutdown isn't just started with the privileges it needs to talk to plymouth
<cjwatson> mvo: seeing as it's only run from pm-utils or an init script, and both of those run as root ...
<mvo> cjwatson: that branch slipped through under my radar, we definiely do not want to make it setuid something
<cjwatson> I wonder if it's something like plymouthd running as uid daemon and explicitly refusing messages that come from root
<cjwatson> except plymouthd has code to explicitly refuse messages from non-root
<cjwatson> (look for ply_boot_connection_is_from_root)
<cjwatson> so I'm thoroughly confused about the whole thing
<cjwatson> I've posted my confusion on the merge review
<mvo> thanks cjwatson, I will poke it a bit
<mvo> cjwatson: I'm pretty sure it worked at some point when I tested it
<mvo> cjwatson: the other thing is that it keeps posting the message but the bugreport claims that it dosn't and need to do it in a loop (which it does)
<mvo> already
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<cjwatson> temporarily
 * cjwatson -> optician
<tkamppeter> pitti, documentation on OpenPrinting is updated now.
<pitti> tkamppeter: nice
<tkamppeter> pitti, in bug 465916 many users are asking for a Lucid (LTS) SRU, as the DNS-SD broadcasting in CUPS worked in 8.04, only the patch is rather big. Should we really do that?
<ubottu> Launchpad bug 465916 in Avahi "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [Unknown,New] https://launchpad.net/bugs/465916
<pitti> tkamppeter: given how many rounds it needed in natty, I'd give it some more testing in natty first
<pitti> tkamppeter: and it's very intrusive indeed, and might cause regressions
<tkamppeter> pitti, OK.
<mvo> cjwatson: I also added a comment into the bug with instructions how to trigger the screen
<janimo> is this the link to packages pending in NEW? http://people.canonical.com/~ubuntu-archive/queue/natty/
 * janimo wonders id he did something stupid again or openmpi armel debs are in NEW
<tumbleweed> janimo: https://launchpad.net/ubuntu/natty/+queue
<janimo> tumbleweed, thank you
<hrw> hi
<JackyAlcine> Hey hrw
<hrw> can someone check bugs 698230 699710 699779? they looks like duplicates
<ubottu> Launchpad bug 698230 in initramfs-tools (Ubuntu) "package keyboard-configuration 1.57ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/698230
<JackyAlcine> bug 698230
<ubottu> Launchpad bug 698230 in initramfs-tools (Ubuntu) "package keyboard-configuration 1.57ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/698230
<JackyAlcine> bug 699710
<ubottu> Launchpad bug 699710 in initramfs-tools (Ubuntu) "package keyboard-configuration 1.57ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/699710
<JackyAlcine> bug 699779
<ubottu> Launchpad bug 699779 in initramfs-tools (Ubuntu) "package linux-image-2.6.37-12-generic 2.6.37-12.26 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/699779
<doko_> wgrant: ping
<doko> wgrant: would it be possible to set up an ubuntuwire.com/ftbfs for https://launchpad.net/ubuntu/+archive/test-rebuild-20110107 ?
<wgrant> doko: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110107-natty.html
<wgrant> doko: Currently running on an old version of the script, but I'll merge the latest version tomorrow.
<doko> wgrant: cool, thanks!
<ogra> doko, could you approve bug 692613 ? asac is doing pre-sprint errands and i need u-boot-tools in main today (preferably directly with the binary NEWing)
<ubottu> Launchpad bug 692613 in u-boot (Ubuntu Natty) "[MIR] u-boot" [High,New] https://launchpad.net/bugs/692613
<doko> ok
<ogra> thanks
<ogra> jdstrand, can you let u-boot-tools and uboot-mkimage (transitional package) out of binary NEW and into main please (its a tad urgent, armel image builds depend on them)
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: cjwatson
<jdstrand> sladen: re bug #697181, possibly but I've not looked at it. sbeattie is actively working on it
<ubottu> Launchpad bug 697181 in php5 (Ubuntu Natty) "DoS: Infinite loop processing 2.2250738585072011e-308" [Undecided,Confirmed] https://launchpad.net/bugs/697181
<jdstrand> sbeattie: fyi, I went ahead and assigned you to the stable release tasks of that bug. feel free to fix natty too if someone else doesn't get to it :)
<elif> cjwatson: if I want to load a disk driver in a preseed instalation, is it possible to say to preseed.cfg ?
<jdstrand> ogra: re deNEW> sure thing
<ogra> merci ! :)
<cjwatson> elif: load it in a partman/early_command script
<elif> cjwatson: thks.
<jdstrand> ogra: did someone already do them?
<jdstrand> hmm, seems no... where are they...
<ogra> jdstrand, hmm, doko approved the main inclusion but for the former version
<ogra> not sure he also processed the queue
<doko> I did
<ogra> oh, thanks then
<ogra> jdstrand, ignore the request then ;)
<jdstrand> ok
<jdstrand> ogra: fyi, I didn't see them at https://launchpad.net/ubuntu/+source/uboot-mkimage or https://launchpad.net/ubuntu/+source/u-boot-tools though
<cjwatson> mvo: lp:~mterry/unattended-upgrades/691886 looks sensible to me - perhaps you could investigate/merge?
<mvo> cjwatson: thanks, will do
<doko> ogra: where should uboot-mkimage live?
<ogra> main
<ogra> u-boot-tools and uboot-mkimage need to be in main
<doko> and u-boot-tools too?
<ogra> the rest i dont care
<doko> ahh, the rest ...
<ogra> yeah, u-boot has bootloaders we dont use (no kernels)
<ogra> (the binary i mean)
<ogra> thats why asac requested the split
<ScottK> pitti or cjwatson: Would you please rescore kde4libs (only affects powerpc) - It'll avoid a bunch of KDE FTBFS/retries later if we can build kde4libs nowish.
<pitti> ScottK, cjwatson: sure, doing
<ScottK> pitti: Thanks.
<janimo> in what cases do only amd and i386 builds show up? ex: https://launchpad.net/ubuntu/+source/haskell-syb-with-class/0.6.1-2build1
<Laney> janimo: it's in P-a-s
<Laney> %haskell-debian: amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc      # Requires threaded Haskell runtime
<Laney> erm, %haskell-syb-with-class: amd64 i386 kfreebsd-amd64 kfreebsd-i386      # [ANAIS] needs template haskell
<janimo> P-a-s ?
<Laney> Packages-arch-specific, list of packages which should only be built on certain arches
<janimo> hmm, then build-deps on them need to be made conditional
<janimo> I got to them becsuse they lead to armel FTBFS in others
<janimo> Laney, thanks, I'll look into correcting those then
<Laney> please do it in debian
<janimo> Laney, ok
<Laney> ty
<janimo> Laney, someone retried the ghc6 build and this time it succeeded without other changes
<Laney> they should ideally just go into dep-wait if there are missing build deps
<mterry> cjwatson, hello!   I noticed glib2.0 wasn't in the desktop set.  I could see an argument for it not being (cross DE, pretty 'core'), just wanted to make sure if it was intentional
<cjwatson> mterry: I think that's intentional, yes
<Laney> so not require any changes
<janimo> Laney, yes, dep-wait indeed
<Laney> that's not a problem
<Laney> you can leave that
<mterry> cjwatson, cool, makes sense
<Laney> about ghc6/armel: good & bad I guess...
<Laney> did you check if it works?
<janimo> Laney, it builds packages in the archive, but other than that I did not check
<Laney> that's a good start because it was failing to do that before
<Laney> i will try to merge 6.12.3 from experimental at the weekend
<Laney> and then update to the latest haskell platform in Debian
<janimo> Laney, for instance some happstack packages build dep on syb-class, this makes hapstack arch specific as well I guess
<janimo> since it waits on those on armel
<Laney> yep, that's sadly expected
<Laney> it's the same for ppc too
<janimo> so happstack is not that portable?
<Laney> due to ghc6 â syb not being available, yes indeed
<hallyn> Daviey: around?
<pitti> tkamppeter: I uploaded a new jockey with much faster installation now, and a working progress bar
<micahg> hi cjwatson, are you comfortable sponsoring bug 695728?
<ubottu> Launchpad bug 695728 in gnome-python-extras (Ubuntu) "python-gtkmozembed should depend on xulrunner" [High,Confirmed] https://launchpad.net/bugs/695728
<cjwatson> looking
<cjwatson> micahg: yeah - is there a branch anywhere I should merge?
<micahg> cjwatson: no, I just added a debdiff, would you prefer a branch?
<cjwatson> (I'm checking out the vcs-bzr now)
<cjwatson> micahg: no, a patch is fine
<cjwatson> just checking for housekeeping purposes
<micahg> ah, I see the desktop team has a branch that I should've used, sorry
<cjwatson> micahg: done, thanks
<micahg> cjwatson: thanks
<pitti> cjwatson: got an ubiquity crash about "DebconfError console-setup/codeset doesn't exist"; already known, or want a bug?
<pitti> cjwatson: (OTTOYH, I'll check LP, too)
<cjwatson> pitti: bug, ideally with ubiquity -d
<pitti> ah, bug 699829
<ubottu> Bug 699829 on http://launchpad.net/bugs/699829 is private
<cjwatson> I did test ubiquity before uploading :-/
<pitti> cjwatson: I'll get you a -d output
<cjwatson> I think I see the problem
<pitti> ok, thanks
<cjwatson> I WISH Anton hadn't gone and renamed all those templates
<cjwatson> it was gratuitous
<davmor2> Hey guys,  I'm getting a kernel panic from the latest alternate and live cds.  It's on an amd 64bit system with builtin nvidia gfx.  Works flawlessly under maverick.
<tkamppeter> pitti, thanks for resolving tyhe progress bar issue in Jockey. Why is it not in upstream Jockey? Is the package installation GUI also Ubuntu-only?
<pitti> tkamppeter: no, the GUI is generic
<pitti> tkamppeter: upstream jockey uses packagekit
<pitti> tkamppeter: since all the apt specific stuff isn't appropriate for upstream
<pitti> but at least our packagekit isn't powerful enough to do stuff like "add a trusted GPG key"
<pitti> or even just adding a repo (the API exists, I think, but is unimplemented)
<pitti> I guess it's much more complete on Fedora
<pitti> so if someone is interested to do that on an RPM based distro, I'm glad to assist, but I don't feel the urge to do it myself
<pitti> especially since Fedora reinvented that wheel already anyway
<pitti> (not the printing part, though; they don't have any solution to that)
<pitti> brb
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<hallyn> cjwatson: ok, so for multipath-tools merge, like an idiot i did 'bzr merge lp:ubuntu/natty/multipath-tools' from debian/experimental, instead of the other way around.  I take it that is insufficient?  (though I'd assume both histories are inherited either way...)
<cjwatson> mm, yeah, that would be really pretty confusing, but it should be easy to revert and do it the other way
<jdstrand> Riddell: hi! does kde have an autostart directory ala ~/.config/autostart ?
 * Amaranth thought the autostart stuff came from kde
<Riddell> jdstrand: yes, ~/.config/autostart or ~/.kde/Autostart/
<jdstrand> Riddell: thanks!
<Riddell> Amaranth is right indeed
<jdstrand> *shrug*
<mvo> doko: could you please look at bug #699881 (and the attached patch). if it looks good I will upload, pycentral crash on upgrade
<ubottu> Launchpad bug 699881 in python-central (Ubuntu) "crash during natty->natty" [Undecided,New] https://launchpad.net/bugs/699881
<jdstrand> I don't know where it came from, but glad to know what it is :)
<jdstrand> s/what/where/
<hallyn> cjwatson: (ok, thanks, i suppose another merge will help make it all less magic than it was the first time :)
<doko> mvo: it surely a hack, we should at least know which package doesn't byte-compile for 2.7 ...
<cjwatson> doko: the second example under "How to Fix a Problem" in https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition looks odd.  Surely it would almost never be correct to have -l<stuff> foo.c?
<doko> cjwatson: yes. I'm not sure that I like the mixing of the error messages for the different bugs. but it's difficult for other to distinguish these
<mvo> doko: I don't mind if its fixed in a different way, but the current failure condition is that half the wold fails (becasue python-minimal can't be configured)
<jdstrand> Riddell: also, where does kmail store its mail and passwords?
<doko> mvo: do what you think works, I'm offline in a few minutes and travelling tomorrow
<Riddell> jdstrand: mail should be somewhere in  ~/.kde/share/apps/kmail
<Riddell> jdstrand: settings in .kde/share/config/kmail
<jdstrand> Riddell: great, thanks! :)
<Riddell> jdstrand: password in kwallet which should be in .kde/share/apps/kwallet/
<jdstrand> ah, perfect
<Riddell> actually settings in .kde/share/config/kmailrc
<geser> mvo: do you how I can fix this? http://paste.ubuntu.com/551527/
<mvo> geser: sure, feel free
<geser> mvo: how? (not if)
<dholbach> cjwatson, good work!
<cjwatson> ta
<mvo> geser: oh, sorry. it looks like a bug in xapian index, does it prevent synaptic from starting?
<mvo> geser: it shouldn't really
<geser> mvo: no, synaptic works but will the search with apt-xapian work reliable if the apt-xapian database doesn't get updated?
<mvo> geser: hm, I need to leave for a couple of minutes but I can have a look afterwards.
<mvo> geser: I can not reproduce it fwiw here yet
<geser> mvo: sure, no hurry; hmm, then I wonder what package I'm missing (again)
<cjwatson> mvo: there's a new grub2 in the archive now that should fix your btrfs bug
<cjwatson> it ought to cleanly upgrade and boot OOTB
<tkamppeter> Can someone look into bug 691533? It is the MIR for jbig2dec and I have now uploaded the Ghostscript package which needs it.
<ubottu> Launchpad bug 691533 in jbig2dec (Ubuntu) "[MIR] jbig2dec" [Undecided,New] https://launchpad.net/bugs/691533
<tkamppeter> It is still in "no one has seen it yet" state.
<mvo> cjwatson: yeah, installs/boots fine now, just complains that "sparse files are not allowed", but continues anyway with the boot
<cjwatson> mvo: hm, I don't think that comes from GRUB
<cjwatson> I can't find it in the kernel or btrfs-tools either ...?
<mvo> cjwatson: "error: sparse file not allowed" to be precise, its a vm so I had to type
<mvo> cjwatson: 100% reproducable for me, I'm happy to debug after dinner further
<mvo> (in this vm)
<cjwatson> ah, now I see it
<cjwatson> ./grub-core/commands/loadenv.c:234:      return grub_error (GRUB_ERR_BAD_FILE_TYPE, "sparse file not allowed");
<cjwatson> it shouldn't be sparse, so that does suggest a grub bug
<cjwatson> mvo: don't worry, we can poke at it next week
<Keybuk> FFS Thunderbird
<Keybuk> apparently if you click archive on a mail, all replies to that are archived too
<glatzor> hello mvo
<smoser> cjwatson, around ? bug 697493
<ubottu> Launchpad bug 697493 in grub2 (Ubuntu Natty) "invalid free in grub-mkrelpath" [High,Fix committed] https://launchpad.net/bugs/697493
<smoser> obviously there is a bad free somewhere, but i'm wondering if you suggest that I should have /proc mounted anyway
<smoser> (which never was needed before)
<cjwatson> smoser: I don't *think* it should be necessary if you've inserted a fake grub-probe; although I can't promise it won't be needed for update-grub in the future
<cjwatson> smoser: but as you can see, I've committed a fix
<cjwatson> or at least I think I have
<cjwatson> that's the only direct use of /proc that I can see in GRUB's C code
<smoser> cjwatson, where is the branch "butter" ?
<cjwatson> smoser: http://bzr.sv.gnu.org/r/grub/branches/butter/
<smoser> thanks.
<cjwatson> smoser: also http://bzr.debian.org/scm/loggerhead/pkg-grub/trunk/grub/revision/2279
<MattJ> Is there any work planned or in progress to integrate PulseAudio into Gnome/Ubuntu further? e.g. a shinier pavucontrol
<Quintasan> doko: ping
<Quintasan> doko: well, bug #699974, I wanted to know if we can discard delta, I have no idea about this and I was told you could help me confirming it
<ubottu> Launchpad bug 699974 in python3-defaults (Ubuntu) "Sync request for python3-defaults from Debian experimental" [Undecided,New] https://launchpad.net/bugs/699974
<ScottK> Quintasan: Needs a merge.
<Quintasan> ScottK: heh, sounds like more work, I'll look into it
<ScottK> doko: Do we want our default Python3 to be 3.1 or 3.2 now?
<ScottK> Quintasan: ^^^ If the answer is 3.2, then it can be synced.
<Quintasan> ScottK: oh, I see. Thanks for helping out. I was about to grab the source :)
<RoAkSoAx> doko: ping?
<RoAkSoAx> I have a quick question. There's a FTBFS because of the --as-needed. I'm patching the Makefile.am like http://pastebin.ubuntu.com/551595/. (Note that some for some of the *_LDADD a library is added, for a few, 3, the new lib is not added). Would it be better to add the lib to COMMONLIBS instead of adding it to each *_LDADD?
<doko> RoAkSoAx: most likely the common libs has to appear after the internal lib
<doko> RoAkSoAx: it's better to look at the Makefile.in if there are macros for the other libs and use these instead
<RoAkSoAx> doko: i was planning to patch both given that the package does not autoreconf.
<RoAkSoAx> doko: so I should add that lib to each of the binaries built, instead of adding it only to COMMONLIBS?
<doko> RoAkSoAx: it's your choice. I would only add it for the ones where it's needed
<RoAkSoAx> doko: ok yhen, thanks :)
<soreau> How is it that libwxbase2.8 installs /usr/include/wx2.8/wx/wx.h while /usr/include/wx/wx.h does not exist yet the source finds it?
<ScottK> doko: Did you see my ping about Python3 default?  Do we want 3.1 or 3.2?
<doko> ScottK: we already have 3.2
<ScottK> oK.
<ScottK> doko: actually we don't.
<ScottK> default-version = python3.1
<doko> huh? maybe I didn't upload
<ScottK> it's 3.2 in Debian experimental.
<doko> but I did announce it =)
<ScottK> doko: We can just synch from experimental.
<ScottK> Yes.  You did.
<doko> sure
<ScottK> Riddell: ^^^ We can sync python3-defaults.
<Riddell> ScottK: groovy
<doko> Riddell, ScottK: please fix the cmake b-d
 * ScottK looks at Riddell for that one.
<Riddell> doko: yes sorry I'll look into it but been too busy
<doko> soreau: I assume alternatives are used
<Quintasan> ScottK, Riddell: thanks
<Quintasan> doko: Thanks as well :)
<soreau> doko: I see it figures it out at config time
<Datz> Hi, I have a feature request, is this the place?
<bryceh> Datz, http://brainstorm.ubuntu.com
<Datz> bryceh: thanks, just submitted :)
<Datz> http://brainstorm.ubuntu.com/idea/26910/
<bryceh> Datz, totally, I'd get a lot of use out of such a feature myself
<bryceh> Datz, also it's not possible afaik to blank one screen but not the other, which would be another useful feature
<Datz> ah, yea that too :)
<ebroder> bryceh: hmm...if you added a "do nothing" option, and made it so that closing the lid automatically "disconnected" the internal display...
<ebroder> (which for all i know could happen already)
<bryceh> ebroder, yeah that'd be nice to.  It doesn't do that currently
#ubuntu-devel 2011-01-08
<JackyAlcine> TGIF!
<axp2> guys is there anyone here that can make USB private bug 699898 public so i can investigate it?
<ubottu> Bug 699898 on http://launchpad.net/bugs/699898 is private
<axp2> USB=USC
<AbsintheSyringe> is unity available as a package for 11.04 or ...? I'm thinking of making a package for Debian as well
<AbsintheSyringe> seems like it
<beachwood23> i'm having problems booting from testdriveâ¦ it will only boot from the floppy, says that the hard disk is not a bootable disk
<beachwood23> i'm having problems booting from testdriveâ¦ it will only boot from the floppy, says that the hard disk is not a bootable disk
<xdanek7> hi, I hope I am on the right channel. I stumbled upon package GLEW (extensions for OpenGL). In Ubuntu it is in version 1.5.2, in Debian Sid 1.5.4 and the current released version is 1.5.7 I tried figure out, how I can send an update to Ubuntu
<xdanek7> i downloaded branch bzr branch lp:ubuntu/glew, did some changes but I have no clue how to build the package on my computer to see if it works. Can anybody help?
<xdanek7> *to
<xdanek7> the command dpkg-deb --build . expects to find the folder DEBIAN, but in the repository the folder name is not capitalized ("debian"). And if I rename the folder to DEBIAN, it says "dpkg-deb: error while parsing  â./DEBIAN/controlâ around line 8: package name missing" . What I am doing wrong?
<geser> xdanek7: leave it as "debian" and install "bzr-builddeb" and do a "bzr bd -S" to get a new source package which you can either build with pbuilder or upload to your PPA
<xdanek7> thanks, Ill try it right now
<theclaw> hi
<theclaw> how can I report a bug on bugs.launchpad.net? when I select "Report a bug", all I get is a wiki-page where it's explained how to use a bug-reporting-tool
<theclaw> I want to report a bug without that tool
<theclaw> it's only possible with that tool?
<theclaw> I don't have a PID..
<theclaw> how annoying :-(
<bdrung> theclaw: you can report a bug against an ubuntu package without that tool
<theclaw> bdrung: how? on launchpad.net, when I click "Report a bug", only a wiki-page appears
<bdrung> theclaw: go to https://bugs.launchpad.net/ubuntu/+source/<source-package-name> and there you can file the bug
<theclaw> bdrung: okay, thanks. but I'm just curious - how should I know that?
<theclaw> bdrung: I just searched for 15 minutes how to report a bug :-(
<bdrung> theclaw: the recommended way is to use the ubuntu-bug tool. on which page did you click "Report a bug"?
<theclaw> bdrung: bugs.launchpad.net
<theclaw> err, no,
<theclaw> https://bugs.launchpad.net/ubuntu <- here
<theclaw> bdrung: ubuntu-bug might be the correct tool, but if I have already identified the bug to some extent, it's just annoying
<bdrung> theclaw: i am not redirected from this page to a wiki (maybe because i am a developer?). which wiki page is linked?
<cdbs> bdrung: bebmers of ubuntu-bugcontrol aren't redirected
<cdbs> *members
<theclaw> bdrung: when I go to "https://bugs.launchpad.net/ubuntu/+filebug", I get redirected to "https://help.ubuntu.com/community/ReportingBugs"
<bdrung> theclaw: if you have identified the bug, you can file it against a specific package.
<cdbs> bdrung: and since you're core-dev, you are already a member of ~ubuntu-bugcontrol
<cdbs> theclaw: If you want to file a package bug, then go to the url which bdrung prompted
<theclaw> bdrung: I actually tried that, but couldn't find a way to go to the launchpad-page of the package
<cdbs> theclaw: if you don't know the package, then go to https://bugs.launchpad.net/ubuntu/+filebug?no-redirect
<bdrung> theclaw: https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net
<bdrung> theclaw: i strongly recommend to file the bug against the correct package.
<theclaw> bdrung: okay, thanks - I didn't see that, sorry.
<bdrung> np
<xdanek7> A followup question. during the build process using bzr bd I get messages about failed patching. It is using tool dpkg-source -b to do the patching. The dpkg says "1 out of 3 hunks FAILED -- saving rejects to file Makefile.rej", but there is no Makefile.rej around, so I do not know what to fix. What does that all mean?
<xdanek7> sorry for bothering you, but I am really confused by the debian/patches/* files. Is there an automatic way how to update those patches when I am updating the package, or do I have to do it manually?
<BlackZ> gilir: the binary package awn-applets-python-extras (from awn-extras-applets) is missing a dependency on the python-vobject package. Without that package the calendar applet will not start
<gilir> BlackZ, awn-applets-python-extras was replaced by  binaries for each applets, awn-extras-applets will be removed
<gilir> BlackZ, see awn-extras source package
<BlackZ> gilir: ok. I just noticed you fixed the bug there :)
<JackyAlcine> :D
<AbsintheSyringe> what's Unity Team email address?
<bigon> https://launchpad.net/ubuntu/+source/mutter << is it normal that mutter have gir1.2-mutter-2.31 instead of gir1.2-mutter-2.91 in natty?
<xdanek7> hi, I was poking around the package glew (library for OpenGL) in Launchpad. I downloaded the branch and tried to update the package, but I do not understand a few things.
<xdanek7> in file http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/glew/natty/annotate/head:/debian/patches/debian-changes-1.5.2-0ubuntu1 there is section in the diff modifying the file Makefile.linux, which apparently does that it removes the section dealing with x86_64 architecture and it IMO results in placing the .a file into /usr/lib and not into /usr/lib64
<xdanek7> I want to ask, where I can learn why this is done. Thank you
<kklimonda> xdanek7: you can try reading through the debian/changelog file
<xdanek7> thanks for a hint
<kklimonda> xdanek7: in ubuntu and debian, /usr/lib64 is a symbolic link to /usr/lib - it may be a reason for this change
<xdanek7> regarding other changes in the diff, I assume they all have a good rationale to be there and have to stay there. But the source code that gets patched has changed. Is there an easy way how to do proceed with the update or do I have to manually go through all the lines in diff and decide what to do?
<geser> xdanek7: you might also want to look at the Debian Policy
<geser> Debian (and therefor Ubuntu) make the decision that native libs for the architecture should be in /usr/lib (independent if it's 32 or 64bit)
<kklimonda> xdanek7: you pretty much have to go through the whole diff and decide if changes still make sense
<xdanek7> you were right, the x68_64 thing is mentioned in the changelog, it solves a bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+419452
<xdanek7> and when I am going through the diff, do I assume I do not have to pay attention to all architectural specific things (the package comes from Debian)? There is part about configuration under i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*). So I can safely ignore that and not move it into the new version? Or something that is mentioned in the changelog as "Include patch from Aurelien Jarno to fix...
<xdanek7> ...FTBFS on GNU/kFreeBSD;"?
<xdanek7> *can
<ScottK> xdanek7: Generally we want to minimize the diff with Debian so we keep Debian specific changes unless they actively cause a problem for us.
<xdanek7> ok, I am done. What should I do now? Should I fill a bug with a path? (There is already one asking for a newer version, so I can post it there) Or should I e-mail the person that is listed as a maintainer?
<xdanek7> (the package works for me)
<xdanek7> i will probably do both. And also write about it on Twitter ;-)
<JackyAlcine> How do I cast a CURLcode to a std::basic_string, const char * or char *?
<juliank> JackyAlcine: Using curl_easy_strerror()
<JackyAlcine> That's not what I needed, but that is useful.
<JackyAlcine> I need to cast data returned from curl_easy_perform() to a std::basic_string, const char *, or char *
<juliank> JackyAlcine: It returns no data, it returns an error code
<xdanek7> "curl_easy_strerror(3) can be called to get an error string from a given CURLcode number."  Does that help?
<JackyAlcine> o.O it does! but I can std::cout << curl_easy_perform(CURL) and get the data output. what gives?
<xdanek7> oh, sorry for saying what has been already said :-(
<ebroder> JackyAlcine: uh, that's not what's printing out anything
<ebroder> JackyAlcine: a CURL handle is configured by default to print any data it gets to stdout
<ebroder> JackyAlcine: your std::cout << isn't what's printing out the data
<JackyAlcine> Hmm, thanks.
<JackyAlcine> But I want that data, lol, I need to read it.
<ebroder> JackyAlcine: look at the options in curl_easy_setopt(3)
<ebroder> in particular, CURLOPT_WRITEFUNCTION
<ebroder> "Set this option to NULL to get the internal default function. The internal default function will write the data to the FILE * given with CURLOPT_WRITEDATA.", and CURL_WRITEDATA defaults to stdout
<juliank> JackyAlcine: How about asking for help in #curl - I don't think that's really on-topic here.
<JackyAlcine> Thanks.
<kshadeslayer> http://paste.ubuntu.com/551948 << any idea why dpkg-buildpackage runs make before running cmake .. ?
<dapal> kshadeslayer: how does your debian/rules look like?
<kshadeslayer> dapal: http://paste.ubuntu.com/551950/
<dapal> kshadeslayer: can't tell, sorry :/
 * dapal doesn't know cdbs well either
<kshadeslayer> well ... lets try MOTU as well ... after that ... i sleep
<kshadeslayer> dapal: yeah ... all of us are being spoilt by dh :>
<ebroder> kshadeslayer: Does changing the order of the includes change things?
#ubuntu-devel 2011-01-09
<hrw> hi
<hrw> I dream of a day when Intel will provide really working drivers for their graphics
<micahg> I think intel graphics are pretty good overall
<ari-tczew> hrw: gma?
<hrw> ari-tczew: GM45
<ari-tczew> hrw: laptop ?
<hrw> yes
<hrw> I am in Dallas and want to watch movie on hotel's 720p TV set
<hrw> framebuffer works fine in clone mode, X11 forces both displays (LVDS1/1366x768 and HDMI1/1280x720) into 1024x768 mode and any attempt to change it ends in total crap on both displays
<hrw> 640x480 set, just part os screen visible etc
<ari-tczew> hrw: try set output only on TV
<micahg> hrw: have you tried w/xrandr from the cli?
<nico_> im trying to use arduino on ubuntu 10.10
<hrw> re
<nico_> but i have problems detecting wich usb port is connected
<nico_> how can i tell?
<nico_> is there a device manager for ubuntu ?
<penguin42> hrw: You could try putting the two displays vertically above each other; some weird stuff can happen on intel if the total widths go over 2k (or 4k on some)
<penguin42> nico_: Should probably be asking on #ubuntu, however I suggest lshw or lsusb
<nico_> penguin42, sorry
<nico_> penguin42, still , ive found out that is connected to Bus 003 Device 002 , still , all i can find on the "dev" folder is ttyUSB0, and its clearly not that one
<ebroder> cjwatson: hmm...i've had 2 different machines not pick sane defaults for my keyboard layout when i took the new keyboard-configuration stuff. not entirely sure what's going on
<penguin42> ebroder: I don't know if it's related, and I've just done updates on my 2 machines that were last uptodate last weekend, and their /etc/default/keyboard appears to be a standard version rather than specific to my config
<ebroder> when i upgraded, i didn't get debconf prompted for a keyboard or a layout, so it ended up defaulting both to what was alphabetically first (which was, like, afghanistan for the layout)
<ebroder> it only seemed to set that up as a secondary layout, thank goodness, but something a little screwy is going on
<JackyAlcine> I'll be right back.
<JackyAlcine> Hey everyone
<ari-tczew>  is it OK to add new patch system to package to use new patch? or should I patch file directly?
<AbsintheSyringe> I want to have Unity repackaged for Debian, however can anyone let me know what's Unity Team email address?
<Nafallo> AbsintheSyringe: I believe http://unity.ubuntu.com/contact-us/ is your best bet.
<AbsintheSyringe> Nafallo, tnx am on #ayatana right now trying to figure this out with rest of the guys :)
<Nafallo> kewl :-)
<penguin42> has anyone got any idea where /etc/default/keyboard comes from? dpkg -S doesn't show an owner, it looks new
<geser> could it be keyboard-configuration?
<penguin42> hmm possible - it has a /usr/share/console-setup/keyboard that looks very much like /etc/default/keyboard - they're both hopelessly wrong
<JackyAlcine> Morning, one and all :)
 * JackyAlcine Programming; working on libopenmary-c++, and tending to the Launchpad
<awesome_guest>  hi it looks like I'm missing a bunch of development libraries.. linking against -lrt and -ldl are failing.  Where would I find a directory telling me which development packages to get?
<ari-tczew> awesome_guest: could you pastebin your errors?
<ari-tczew> awesome_guest: http://wiki.debian.org/ToolChain/DSOLinking
<awesome_guest> pretty sure that I don't have the libraries in question.. I just installed fuse-dev and talloc-dev, among others
<ari-tczew> awesome_guest: did you add missing libraries to LIBS and still couldn't build?
<awesome_guest> no it's much simpler than that :) I just don't know which packages to install
<awesome_guest> is it "libLIBNAME-dev"?
<ari-tczew> awesome_guest: well, let's search following way: copy the filename of missing .so file and use command "apt-file search foo.so"
#ubuntu-devel 2012-01-02
 * solid_liq is now known as 2_tone_beat_up_old_stationwagon
<micahg> doko: infinity: fpc could use bootstrapping on armhf
<doko> micahg, no, needs a hard-float port
<micahg> doko: oh, ok, just saw it depending on itself
<micahg> doko: is it the same with gnat-4.4 and gnat-4.6?
<doko> micahg, gnat is supposed to just need a cross build, but I didn't finish it yet, lack of time
<micahg> ok
<geser> zul: is mysql-5.1 still needed? As it currently causes a "Failed Upload" on armhf. If it's still needed mysql-5.1 shouldn't build libmysqld-pic, libmysqld-dev and libmysqlclient-dev anymore (all now build from mysql-5.5).
<ajmitch> afaik the plan is to remove 5.1
<geser> do the archive admins plan to import package removals from "testing" (and "unstable") again or are removals bugs preferred?
<doko> jtaylor, ScottK: could you have a look/review at Debian #651726 and Debian #635490?
<ubottu> Debian bug 651726 in src:python-gd "python-gd: build not multiarch aware" [Important,Open] http://bugs.debian.org/651726
<ubottu> Debian bug 635490 in src:python-gd "python-gd: FTBFS Please Build-Depends on libjpeg-dev, not libjpeg62-dev" [Serious,Open] http://bugs.debian.org/635490
 * Sweetshark fought his way back from behind enemy lines.
<doko> mvo, https://launchpad.net/ubuntu/+archive/test-rebuild-20111222/+build/3031672 ftbfs using gcc-4.7/gcc-snapshot
<mvo> doko: thanks, I check it out.
<doko> and if you care about the other aptish stuff like aptitude and tagcoll2 ...
<zul> geser: ask SpamapS
<mvo> doko: I do (somewhat) so I check them out too
<mvo> doko: do you have the link at hand?
<geser> SpamapS: is mysql-5.1 still needed? As it currently causes a "Failed Upload" on armhf. If it's still needed then mysql-5.1 shouldn't build libmysqld-pic, libmysqld-dev and libmysqlclient-dev anymore (currently build from mysql-5.5).
<doko> mvo: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20111222-precise.html
<mvo> doko: ta
<doko> Sweetshark, https://launchpadlibrarian.net/88189632/buildlog_ubuntu-precise-i386.hyphenation-bn_0.6.0-4_FAILEDTOBUILD.txt.gz
<doko> https://launchpadlibrarian.net/88189677/buildlog_ubuntu-precise-i386.hyphenation-pa_0.6.0-3_FAILEDTOBUILD.txt.gz
<doko> are you able to reproduce these?
<doko> checking which Mozilla flavour to use... Libxul
<doko> checking for MOZ_NSS... yes
<doko> checking for MOZ_NSPR... yes
<doko> checking for MOZILLAXPCOM... no
<doko> configure: error: Package requirements (libxul ) were not met:
<doko> No package 'libxul' found
<doko> Sweetshark, lo ^^^
<doko> mvo: libept too
<penguin42> is https://help.ubuntu.com/community/Installation/SoftwareRAID correct? Does the mdadm.conf created get explicit /dev/sd* device names in or is it robust to different initialisation orders?
<Sweetshark> doko: I not yet at hyphenation. I just finished my catching up with my mail backlog and an rebasing 3.5b2 now.
<doko> mvo: and libwibble, and qapt (not 4.7 specific)
<tjaalton> is there a list of valid blueprint work-item status tags somewhere?
<stgraber> tjaalton: https://wiki.ubuntu.com/WorkItemsHowto maybe?
<tjaalton> stgraber: excellent, thanks
<stgraber> tjaalton: yep, seems like there's a list there: TODO, INPROGRESS, BLOCKED, DONE, POSTPONED
<tjaalton> yeah BLOCKED was what I'm after
<tjaalton> so it's there, good
<mvo> doko: libapt fixed in bzr
<kelemengabor> hi mvo, can you take a look at bug 869935 ?
<ubottu> Launchpad bug 869935 in software-center (Ubuntu Oneiric) "Software Center help translations not provided " [Medium,In progress] https://launchpad.net/bugs/869935
<mvo> kelemengabor: yes, will do! the oneiric version will have to wait until the current SRU is done, but there is no harm in me merging it and preparing it
<kelemengabor> mvo: thanks! according to the langpack export schedule, the export will start tomorrow
<maxb> mvo: Hi - re bug 869444 - 1) Do you know Abhishek, or does it look like a spurious state change to you? 2) Do you have any hints on where the problem might lie? I'd like to try to debug further, but my initial explorations didn't find anything.
<ubottu> Launchpad bug 869444 in update-manager (Ubuntu) "release-upgrader preconfigures packages 4 times!" [High,In progress] https://launchpad.net/bugs/869444
<mvo> maxb: hello - I don't know know abhishek, no
<mvo> maxb: I think its actually a bug in the fork code in python-apt, but I did not dig into it yet
<mvo> maxb: we can have a look together once I finished my current task if you want, help would be definitely welcome!
<maxb> OK, thanks for the hint, it gives me a new area to explore
<SpamapS> geser: re your mysql-5.1 question .. there are still a couple of things depending on mysql-5.1, but it should be removed soon.
<gedakc> psusi, are you there?
<Guest39404> Hello community, a friend of mine studding "economy and computer since" and nearly finished with his studies. He want to write his "Bachelor Thesis" about the work plan and the business process of Ubuntu and need an interview with a developer of the Ubuntu-Project about the detailed workflow. I would be happy to hearing from anybody who is up to help at tobias.vanark@googlemail.com.
#ubuntu-devel 2012-01-03
<pitti> Good morning, happy new year everyone!
<geser> pitti: good morning, and a happy new year too
<doko> undefined references
<doko> --------------------
<doko>  - dbus (`g_thread_init')
<doko>  - evolution-data-server (`g_module_*')
<doko>  - evolution-exchange (`g_thread_init')
<doko>  - evolution-webcal
<doko>  - geoclue
<doko>  - gnome-keyring
<doko>  - gnome-utils
<doko>  - gtk-sharp2
<doko>  - gtkhtml3
<doko>  - gtkhtml4.0
<doko>  - librest
<doko>  - likewise-open
<doko>  - yelp
<doko> pitti: found these with a rebuild test in main ... :-/
<pitti> doko: ah, thanks for the list; I'll create a tracking bug for these
<doko> pitti, build logs at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20111222-precise.html
<micahg> gtkhtml3.14 has been demoted
<pitti> doko: bug 911125
<ubottu> Launchpad bug 911125 in yelp (Ubuntu Precise) "FTBFS due to removed g_thread_init" [High,Triaged] https://launchpad.net/bugs/911125
<pitti> I fanned out some tasks and will start with a bunch
<doko> pitti, thanks, would be nice to coordinate within the desktip team
<pitti> doko: yes, of course; I'll shepherd this
<ttx> happy new year, ubuntuland :)
<pitti> hey ttx, happy new year!
<smb> Yeah, happy new year. But that's so yesterday... ;-P
<didrocks> happy new year ttx!
<doko> jamespage, is maven-ant-tasks missing a b-d on maven-parent?>
<jamespage> doko: lemme take a look
<jamespage> doko: libmaven-parent-java is missing a dependency - fixing now
<hrw> someone know what creates /run/network/ directory?
<stgraber> hrw: /etc/init/network-interface.conf or /etc/init/networking.conf whichever is executed first
<stgraber> hrw: some other scripts may be doing the same too
<hrw> cause I had to catch my dom0 admin to be able to login to my Xen instance after server reboot - all be cause 'ifup eth0' ended with '/etc/network/if-up.d/upstart: 38: cannot create /run/network/ifup.eth0: Directory nonexistent' and no network
<hrw> ubuntu oneiric on my xen
<cjwatson> That suggests to me that that script should also have a mkdir -p in it
<stgraber> yeah, if something directly calls 'ifup eth0' before either of the upstart jobs are triggered it'll indeed fail. Adding another mkdir -p to the if-up.d script sounds like a good idea
<stgraber> actually, looking at what I have on my system, the upstart script won't be the only one to fail (ifenslave's pre-up will too at least)
<stgraber> so we really should always make sure /run/network exists before calling ifupdown
<stgraber> or go through all our ifupdown scripts and make sure they all call mkdir -p
<smb> Just wondering because I rarely got into a state like that on chroots: is /run something valid? Unfortunately I wasn't really sure how I got there (and suspected upgrading during development) but it ended with /run being a link to /var/run and that being a link to /run...
<cjwatson> smb: http://wiki.debian.org/ReleaseGoals/RunDirectory
<cjwatson> that link arrangement indicates a bug somewhere though
<cjwatson> mvo: FYI it would be good if you could merge lp:~mvo/launchpad/maintenance-check-precise up to current devel and resolve conflicts; there was a bunch of general linting done on the Launchpad tree, and I just ported everything to the new python-apt API, so it conflicts six ways to Sunday
<smb> cjwatson, Right, I suspected that the goal was to move /var/run to /run in the end. And since it happened to chroots being set up during alpha and then upgraded I rather went into recreating them. Just thought hrw may try to verify this happened or really just missing the directory creation.
<hrw> stgraber: I solved it in other way. vi /etc/init/mounted-run.conf + 'mkdir -p /run/network' in it
<geser> cjwatson: Hi (and a happy new year), do you know if package removals from Debian "testing" and "unstable" are getting imported or if removal bugs are preferred/needed? Some of the "Failed to upload" errors on armhf are due to renamed source packages where the old ones aren't removed in Ubuntu yet
<cjwatson> geser: Yeah, we're behind on those.  They should get imported, but feel free to file bugs if something's particularly problematic
<jamespage> jodh: around? I have a question re setuid stanza in upstart 1.4
<mvo> cjwatson: sure, will do
<doko> cjwatson, pitti: could you accept the ac100 kernel binaries in NEW?
<cjwatson> doko: will do
<cjwatson> done
<mvo> cjwatson: lp branch should be good again
<\sh> happy new year everyone
<cjwatson> mvo: great, thanks
<cjwatson> mvo: 'rootdir="./aptroot.%s" % distro' will probably fail lint without spaces around =
<mvo> cjwatson: indeed, let me fix that too (sorry for that)
<mvo> cjwatson: fixed as well (pep8 clean now)
<sveinse> I'm trying to dist-upgrade a set of custom (non-official) packages and apt-get reports that a package has been kept back. Is there a way I can get apt-get to report why, or do I always need to traverse my packages and their dependencies to resolve the conflict?
<pitti> sveinse: try to apt-get install the held back package, this will tell you
<stgraber> TREllis: ping
<stgraber> oops :)
<cjwatson> doko: could you have a look at bug 908679, please?
<ubottu> Launchpad bug 908679 in freemind (Ubuntu) "No java runtime found" [Undecided,New] https://launchpad.net/bugs/908679
<cjwatson> I suspect java-wrappers needs to be updated for the new openjdk paths
<hrw> does bug 911188 has sense? I would like to get -dbgsym package coverage in ubuntu
<ubottu> Launchpad bug 911188 in bzip2 (Ubuntu) "Lack of *-dbgsym package" [Undecided,New] https://launchpad.net/bugs/911188
<jodh> jamespage: hi
<cjwatson> hrw: in general -dbgsym packages are provided by buildd tricks and don't require the package to generate them
<cjwatson> hrw: however it's possible that bzip2 is doing something that bypasses the buildd hooks we install; I'll check
<cjwatson> ah, yes, handwritten debian/rules
<hrw> cjwatson: dbgsym packages are generated for debhelper using packages - rest has support it by hand
<hrw> cjwatson: I plan to add each source package which lacks dbgsym to this bug
<cjwatson> hrw: no, please file a separate bug for each one
<cjwatson> otherwise anyone who fixes one gets spammed about all the rest
<hrw> ok, thanks
<hrw> cjwatson: is there a way to mass fill such bugs?
<hrw> "for package in `cat list-of-broken-packages`;do lp-reportbug $package <bug-description;done" like
<cjwatson> hrw: no doubt it's possible with the LP API
<cjwatson> (BTW: "file" not "fill")
<hrw> indeed file
<cjwatson> there's lp.bugs.createBug
<hrw> thanks, will check
<cjwatson> it is distressingly awkward to duplicate the dh_strip wrapper logic
<cjwatson> I can't help feeling there should be a better way
<cjwatson> pitti: what is the current recommended code for generating dbgsym packages in debhelper-less packages?
<hrw> cjwatson: binutils calls pkg-create-dbgsym by hand
<cjwatson> pitti: stuff like the logic for whether to add to the .changes file seems to be in dh_strip
<cjwatson> hrw: I know, but there are bugs in that
<hrw> this is the only one which I know
<cjwatson> hrw: that will fail to handle things correctly once soyuz supports ddebs
<cjwatson> I'd rather do it right
<cjwatson> I wonder if the only correct way to do this is to call dh_strip :-/
<hrw> ;d
<pitti> cjwatson: hm, I think I remember one package, there I just called pkg-create-dbgsym by hand
<pitti> cjwatson: but frankly I guess it's easier to just call dh_strip
<doko> cjwatson, hmm, works for me
<cjwatson> pitti: not in this case because its installation directory names are non-standard :-(
<cjwatson> pitti: it would be nice if the CurrentlyBuilding logic were factored out
<jamespage> jodh: hey - so I've been trying out the 1.4 upstart PPA
<jamespage> jodh: specifically the setuid stanza (wanted to see how it might work for jenkins/zookeeper)
<jamespage> I think I see that ALL scripts get run as the uid - is that correct?
<jamespage> i.e. including the pre-start one which set's up /run directories etc...
<jodh> jamespage: that's right. We might want to change that behaviour to only apply to the main script/exec section, however that could be equally confusing as the majority of stanzas apply to all sections (notable exception: 'respawn'). Could you raise a bug so this can be discussed?
<jamespage> jodh: will do; my preference would be only the main script/exec section
<jamespage> that way root can setup stuff before I drop priviledges
<jamespage> jodh: bug 911207
<ubottu> Launchpad bug 911207 in upstart (Ubuntu) "upstart 1.4: setuid/setguid apply to ALL scripts" [Undecided,New] https://launchpad.net/bugs/911207
<diwic> hi, I'm trying to install 12.04 with ubiquity and it seems to have hung, what is the suggested course of action?
<cjwatson> 'ubuntu-bug ubiquity' from a terminal and tell us everything you can about what you selected
<diwic> cjwatson, bug 911209 filed, just wondering how to resolve the immediate situation in the most graceful way.
<ubottu> Launchpad bug 911209 in ubiquity (Ubuntu) "Keyboard layout selection, right side is not updating properly" [Undecided,New] https://launchpad.net/bugs/911209
<cjwatson> diwic: you may not be able to without restarting, I'm afraid
<diwic> cjwatson, so "sudo reboot" is best here? There is no "restart" or "shut down" in the menu
<cjwatson> yes, or just hit the power button since you probably have to reinstall anyway ...
<diwic> ok, thanks
<cjwatson> sorry
<cjwatson> I'll see what I can do about that bug though my queue's a bit deep at the moment
<diwic> It's not a showstopper, I can retry, or try the alternate installer
<Sweetshark> http://it.slashdot.org/story/12/01/03/0610227/chaos-communication-congress-releases-talks <- lots of recommended talks ...
<doko> ScottK, barry: is there any reason that you didn't update boost-mpi-source1.46 to the current boost1.46 sources?
<barry> doko: probably not.  i haven't touched boost since october
<ScottK> Last time I touched it, it was updated.
<ScottK> barry: I think that's the last time it was messed with other than rebuilds and such.
<barry> ScottK: so boost-mpi needs to be updated.  i'll put that on my list
<ScottK> Great.
<ScottK> barry: Did you see the PyQt4 python3 packages got in over break?
<barry> ScottK: barely ;)  email was very spotty for me over the last week.  i'm catching up now
<ScottK> K.
<barry> ScottK: i see your message now.  that's great, thanks!
<doko> ScottK, I'll just fix the version for now, and add the gcc-4.7 patch for the next rebuild test. would be nice if you could do the final merge
<doko> what was the reason for the split? openmpi not in main?
<ScottK> doko: I really don't have time for boost stuff anymore.  Yes.  That was it.
<doko> ScottK, who did object and why?
<ScottK> For awhile we just didn't provide it, but users missed it.
<ScottK> Object to openmpi in Main?
<ScottK> or object to not providing the boost MPI stuff?
<rbasak> Is there an easy/tidy way to have dh_install install a directory but exclude a subdirectory? Or should I just call rm manually afterwards?
<doko> ScottK, object to the promotion
<ScottK> IIRC it was slangasek, but no MIR was ever written AFAIK, it was just sort of a given.
<rbasak> Actually it looks like I need to exclude specific files rather than a whole subdirectory, but I do want to get everything else rather than state everything explicitly (for easier upstream updating)
<cjwatson> rbasak: -X may help; if that has too many false positives then I'd call rm
<rbasak> cjwatson: great, thanks! Just wanted to check that I wasn't missing some other standard way :)
<doko> ScottK, fyi, I'm doing the merge
<ScottK> OK. Great.
<doko> ScottK, but didn't you volunteer to the boost1.48 transition? ;-P
<ScottK> ;-)
<ScottK> Nope.  I mentioned someone ought to consider if we should switch, but that it wasn't going to be me.
<psusi> cjwatson: say, would it be possible to rename the current parted source package, and drop the binary packges other than the lib, so that d-i can still depend on it, then upload parted3 with a new sonmae major rev?  ( 3 )?
<cjwatson> I don't want to maintain >1 version of parted, no, sorry
<psusi> damn... but theoretically, that's the right procedure for abi breakage right?
<cjwatson> and I very much doubt the security team would want there to be more than one version of it in main anyway
<cjwatson> not in general, no - it's better to have only one source version
<cjwatson> deal with the problems rather than perpetuate them
<psusi> huh?  that's kind of the point... new source version breaks abi, so now you need two different lib versions... you don't get two lib versions from one source?
<cjwatson> you need different *binary* package names, sure, but the old one should get removed pretty quick
<cjwatson> what normally happens is that we move to the new source version, the old binary hangs around in not-built-from-source state, rebuild everything against new abi, remove old binary
<psusi> sure... whenever you get around to getting d-i working with parted3 ;)
<psusi> ahhh, I see
<psusi> what do you do to get a package into the not-built-from-source state?  normally when you upload a new source and its binaries are built... ohh... since it will build a binary with a new name, it won't replace the old one so it stays?
<cjwatson> right
<cjwatson> http://people.canonical.com/~ubuntu-archive/nbs.html
<barry> doko: looks like you just did the merge for boost-mpi-source1.46.  thanks
<psusi> cjwatson: if it's only used by d-i, would it really matter for security purposes? ;)
<cjwatson> psusi: I'm not going to make that argument.
<cjwatson> the security team has a hard enough time without me coming up with weird special cases for them
<cjwatson> (anyway, there's general supportability as well as security)
<psusi> hehehe... ok...
<geser> psusi: and you would to make sure that nobody clears it from NBS by mistake
<psusi> geser: the fact that d-i still depends on it should stop that shouldn't it?
<cjwatson> yeah, that's why we have the page linked above
<soren> What's the smallest "amount" I can add to a version string? Say I want to add a custom patched package to a PPA based on a package from Ubuntu proper, but want it to be superseded by any update in Ubuntu, what should I add?
<soren> In the past, I've gone from e.g. 1.1-1ubuntu1 (as the base version) to my patched version: 1.1-1ubuntu2~ppa1.
<soren> ...but if an update turns up, it could be called either 1.1-1ubuntu2 or 1.1-1ubuntu1.1 (or something entirely different).
<geser> 1.1-1ubuntu1.0~0 I guess
<cjwatson> There's no smallest amount
<soren> My current guess is 'a~' as the suffix.
<soren> With more tildes to make it closer to "0".
<cjwatson> It's like asking what the smallest number you can add to a real number is
<cjwatson> Or maybe a rational number would be a better analogy, but either way
<Daviey> well, nobody ius going to upload something between ubuntu1 and ubuntu1a are they?
<cjwatson> However you're pretty safe with .0~0 as geser suggests
<Daviey> even a rebuild would have a "b"
<soren> cjwatson: sure, if someone, only to annoy me, deicdes to version a security update as 1.1-1ubuntu1a~~~~~~~~fuck-soren, yes, then I'm screwed.
<soren> 'a' sorts before '.' afaict.
<hallyn> slangasek: bug 802626, the proposed fix (which has an open lp merge request) has quite a few confirmations now
<ubottu> Launchpad bug 802626 in lvm2 (Ubuntu Oneiric) "vgchange may deadlock in initramfs when VG present that's not used for rootfs" [High,Triaged] https://launchpad.net/bugs/802626
<soren> dpkg's lib/dpkg/vercmp.c's order routine seems to agree that 'a' is the lowest ordered, single character suffix I can add.
<cjwatson> fair enough
<soren> If I'm reading it correctly, that is.
<Daviey> soren: Yes, 1a is less than 1.0~0
<cjwatson> so yeah, a~~ sounds pretty safe then
<barry> aufs is gone in precise, which broke my sbuild confs.  should i switch to overlayfs or unionfs?
<soren> I'm kinda confused it accepts int's.
<cjwatson> barry: overlayfs
<barry> cjwatson: thanks
<soren> Yeah, isalpha(c) makes it return c. Anything else either returns 0 (empty strings and digits), -1 (tildes) or c+256 (for anything else).
<soren> Oh, or is 'A' before 'a'?
<soren> It is, isn't it?
<Daviey> soren: Do you ever fear you put to much thought into this?
<Daviey> for a non-archive package? :)
<soren> Daviey: It's more important than you'd think :)
<geser> soren: according to dpkg 1A is less than 1a
<soren> geser: Yeah. It looks hideous, though :)
<soren> geser: I think I'll use your '.0~something'. That's looks decent.
<soren> Daviey: Use case: I have an appliance. I want to use apt to push updates to it.
<Daviey> soren: you have to give the background now!
<soren> Daviey: To maintain full control over the updates, the only repositories enabled on it are UBuntu release and a PPA.
<cjwatson> Pinning might be a better answer
<cjwatson> If you can understand it
<Daviey> soren: BTW, i use - http://pb.daviey.com/oPHE/ , i'm too lazy to remember the syntax.
<soren> Daviey: Based on the installed binaries on the appliance, I've built a list of corresponding source packages.
<Daviey> soren: for licencing?
<soren> Every half hour or so, I go through that list to check if there's a version in either -updates or -security that is newer than what I have in the PPA.
<soren> Daviey: No, just for vetting updates.
<soren> If there's an update, I get notified.
<Daviey> ah
<geser> soren: do -updates and -security update that often (less than an hour)?
<Daviey> soren: debmarshal might interst you, don't know if you have come across it.
<soren> Once I'm happy with the update, I copy the updated package to the PPA.
<soren> geser: Good point. I'll make it once an hour. This part doesn't exist yet :)
<soren> Daviey: Never heard of debmarshal, no. I'll take a look, thanks.
<soren> Anyway, they point is that if I put updated packages into this PPA, I need to be sure that an update in Ubuntu of the same package triggers a notification for me, so that I can merge that change into my package.
<soren> So I need to be rather careful with the versioning of custom packages in there.
<stgraber> geser: AFAIK cjwatson made the publisher run quickly enough now that it can run twice an hour. Not sure if that'd be a problem for soren though
<geser> soren: have you checked if it would work to trigger your check with an inotify on the Packages files instead of checking every hour?
<soren> geser: Why would that be preferable?
<soren> geser: I'm using the LP API right now, though.
<Daviey> soren: would "+sorens-goodess0" not be suitable?
<soren> geser: It runs in completely separate context.
<geser> ah
<cjwatson> Yes, the publisher is twice an hour now
<soren> cjwatson: Wow, really?
<soren> cjwatson: That's awesome!
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-December/034577.html
<hallyn> yikes, pangolin did not do well over the break.  Now mutt+imap is dying
<Daviey> hallyn: you need to switch to sorenOS for vetted updates :)
<soren> cjwatson: Awesome work!
<soren> geser: I could add apt to the process, though, but I'm not sure that'd make it any easier.
<cnd> doko, I've got a small patch to gcc 4.6's libstdc++ that fixes a bug that prevents clang from compiling anything with std::shared_ptr
<cnd> I'm going to send the patch to the gcc-patches mailing list today
<cjwatson> ta; it was about half jtv and half me, at least the recent stuff
<cnd> what should I do to ensure it gets into precise?
<geser> soren: I somehow assumed you process apt's Packages files instead of querying through LP API
<EtienneG> pitti, are we going to ship policykit 0.103 in precise?  I presume so, but checking.
<soren> geser: Oh.
<pitti> policykit-1 |    0.103-1 |       precise | source, amd64, armel, armhf, i386, powerpc
<cjwatson> EtienneG: policykit-1 |    0.103-1 |       precise | source, amd64, armel, armhf, i386, powerpc
<pitti> EtienneG: ^
<doko> cnd: if it's a regression compared to an earlier release try to get it into the 4.6 branch
 * pitti ^5s cjwatson
<cnd> doko, I will, though it's not a regression
<cnd> it's just broken
<EtienneG> pitti, cjwatson, thanks!
<cnd> doko, do you take patches in the meantime?
<cnd> or should we wait on it getting accepted upstream?
<cnd> doko, for reference, this is the patch: http://paste.ubuntu.com/791757/
<cnd> it's a fix that is required due to a late change in the c++11 spec
<doko> cnd: please could you submit it upstream first? make sure it's sent to gcc-patches & libstdc++
<cnd> ok
<doko> cnd, looks like this is already upstream?
<cnd> doko, yes, but not in 4.6
<cnd> and in 4.7 they use noexcept instead of the comment "never throws"
<cnd> I don't know if noexcept works in 4.6, so I just kept the same style as everything else
<hallyn> well this sucks now i can't check email :)
<hallyn> (bug 911305)
<ubottu> Launchpad bug 911305 in p11-kit (Ubuntu) "segfault from p11-kit when starting mutt with imap-over-ssl" [Undecided,New] https://launchpad.net/bugs/911305
<achiang> hallyn: i'll dup mine to yours. :( (i filed #911319)
<achiang> hallyn: nevermind, i don't think i will. mine has a coredump attached, which as you note, has a password in it
<achiang> hallyn: ah, i just made my problem go away with an apt-get dist-upgrade
<hallyn> achiang: i did see there was a new update in the source pakcage, but haven't updated again yet.
<hallyn> yay!  fixed :)
<doko> jml, can't reproduce bug 908679, is this seen on more than one machine?
<ubottu> Launchpad bug 908679 in java-wrappers (Ubuntu) "No java runtime found" [Undecided,Incomplete] https://launchpad.net/bugs/908679
<jono> seb128, quick q: I am seeing some gnome-settings-daemon crashes, and around the time it crashes my mouse stops working - do you think the two issues are connected?
<seb128> jono, it's likely that you hit bug #868400
<ubottu> Launchpad bug 868400 in lightdm (Ubuntu Precise) "Synaptics touchpad stops working - two syndaemon instances running" [High,Triaged] https://launchpad.net/bugs/868400
<seb128> jono, g-s-d gets respawned and start a second syncdaemon
<seb128> didrocks, skaet: ^
<jono> seb128, gotcha
<jono> thanks seb128
<seb128> yw
<seb128> didrocks, skaet: just mentioning it because g-s-d in precise is having some stability issues due to ubuntuone bugs so that might explain the increase in those reports
<barry> jdstrand: ping
<didrocks> seb128: ah, good to know, thanks :)
<jdstrand> barry: hi, happy new year :)
<barry> jdstrand: thanks, and to you too!
<barry> jdstrand: doko mentioned that you classify this python bug as a security problem: http://bugs.python.org/issue13156
<barry> jdstrand: python 2.6 is in security-only mode, so i would need some justification in the python tracker to apply and eventually release a fix for 2.6
<barry> jdstrand: so i'm wondering if you could comment on the above, if that's the case
<skaet> seb128, didrocks - workaround from bug 868400 sorts the recent increase in this behavior - will mark the one I opened yesterday as a duplicate.
<ubottu> Launchpad bug 868400 in lightdm (Ubuntu Precise) "Synaptics touchpad stops working - two syndaemon instances running" [High,Triaged] https://launchpad.net/bugs/868400
<jdstrand> mmm, no-- I saw a bug float by last week but it wasn't that one
<barry> jdstrand: ah. okay.  if you can dig it up (in lp even) let me know
<jdstrand> barry: it was this bug we were talking about: http://bugs.python.org/issue11662
<doko> oops, did paste the wrong one
<barry> doko: no worries.  jdstrand that's in 2.6, and it was one of the few security fixes in 2.6.7, so we should be good
<jdstrand> barry: well, it needs to be backported to earlier releases, but yes, I see there are patches
<barry> jdstrand: it looks like it was applied to 2.5, 2.6, 2.7, 3.1, 3.2, and default (3.3).  it was released in 2.6.7 and 2.7.2
 * jdstrand nods
<jdstrand> barry: I will be preparing updates for it
<barry> jdstrand: and 3.2.1.... cool, thanks
<jdstrand> barry: fyi, I fixed python3 before the holidays
<jdstrand> barry: (for the stable releases that were affected)
<barry> jdstrand: awesome, thanks
<barry> jdstrand: i'm still not caught up on my holiday email ;)  i was off-line quite a bit
<jdstrand> yes, me too :)
<barry> i hope it was a nice for you :)
<barry> er, "as nice"
<jdstrand> it was. restful and pleasant :)
<barry> :)
<jtaylor> lamont: hi, can you maybe help with bug 910757?
<ubottu> Launchpad bug 910757 in pyzmq (Ubuntu) "pyzmq ftbfs on amd64 and i386 (test failures)" [High,Confirmed] https://launchpad.net/bugs/910757
<jtaylor> see comment 1
<dr3mro> hello , I am ubuntu user and wondering how to prevent network manager from locking the usb modem /dev/ttyUSB0 so i can access it to check sms while i am connected to internet
<mwhudson> dr3mro: #ubuntu or ask.ubuntu.com would be better places to ask that question
<mwhudson> http://askubuntu.com/ rather
<lamont> jtaylor: nothing springs to mind
<jtaylor> lamont: hm so what to do now? I'm pretty sure its a builder issue
<lamont> https://code.launchpad.net/~lamont/launchpad-buildd/chroot-scripts <-- jtaylor: then ./make-chroot.sh --lp -d precise (as root)
<lamont> then mount things inside the chroot and pretend to be launchpad
<jtaylor> lamont: works fine with such a chroot
<ScottK> jtaylor: At least the powerpc build that succeeded was built with a different libc version than the i386 one that failed.
<ScottK> Different gcc too
<jtaylor> thats probably because I retried it a week ago
<jtaylor> the first failure was ages ago and most likely with similar versions
<ScottK> OK.
<seb128> slangasek, there?
<slangasek> seb128: heya
<seb128> slangasek, hey ;-) happy new year:!
<slangasek> seb128: you too :)
<seb128> slangasek, I'm looking at bug #908801
<ubottu> Launchpad bug 908801 in gtk+3.0 (Ubuntu Precise) "libgtk-3-0:<arch>.postinst erase IM cache file, that breaks GTK-3 apps IM environment." [High,Triaged] https://launchpad.net/bugs/908801
<slangasek> hmm!
<seb128> slangasek, the gtk postinst all "<update_command> newdir olddir" which "fails" when olddir is empty
<seb128> do you see any issue dropping the "olddir" in precise?
<seb128> the other way would be to fix the command to computer the list of files correctly so the call doesn't fail when the second argument has no items
<slangasek> seb128: well, it would impact partial upgrades at least
<seb128> computer->compute
<seb128> slangasek, well, couldn't that lead to load .so from the wrong arch?
<slangasek> no, it would never lead to it being loaded from the wrong arch
<seb128> like amd64 install could try to load i386 .so in the old dir
<slangasek> dlopen() will fail
<seb128> ok
<seb128> so my shell skills suck, do you know what is wrong in the command that makes it bail out rather than just ignore the non existant files? ;-)
<slangasek> trivial fix: /usr/lib/x86_64-linux-gnu/libgtk-3-0/gtk-query-immodules-3.0 $(ls /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/*.so /usr/lib/gtk-3.0/3.0.0/immodules/*.so 2>/dev/null)
<slangasek> the ls 2>/dev/null eats the missing files before passing the list to the command
<seb128> ok
<seb128> I'm still not convinced that we should keep the compat dir rather than check that everything is ported and use a Breaks ;-)
<slangasek> that's probably ok too, especially for gtk3
<seb128> that seems "cleanr" than keeping stuff not ported to multiarch and let dlpoen fail
<seb128> slangasek, ok, I will try to go forward for gtk
<seb128> slangasek, ok, I will try to go forward for gtk3 since it was not in the previous lts
<seb128> we can use the ls and compat for gtk2
<slangasek> yep, sounds fair
<seb128> thanks
<slangasek> n/p
<slangasek> SpamapS: <ping flavor="myodbc"/>
<slangasek> pitti: hmm, has something regressed with apport handling of root-only crash files?
<slangasek> pitti: it seems apport consistently fails to dispatch to firefox when the crash file is owned by root, but works ok for ones owned by my user
<seb128> stop the gnome-keyring spam people! ;-)
<lamont> jtaylor: interesting.  it doesn't maybe try to actually connect to something off-machine does it?
<lamont> because that'll fail
<jtaylor> only localhost
<jtaylor> lamont:
<slangasek> pitti: btw, the apport retracing service seems to set the importance of all retraced bugs to 'medium', even if someone has already set it to 'high'...
<SpamapS> slangasek: <blink>PONG</blink>
<slangasek> SpamapS: hi; seen mail?
<SpamapS> slangasek: just returned from lunch.. so not for 90 min or so.. but I did respond (I think) to your earlier mail
<SpamapS> slangasek: ah ok
<SpamapS> slangasek: right, I think the one in the svn repo restores it
<SpamapS> libmysqlclient-dev.files:usr/lib/*/libmysqlclient_r.a
<SpamapS> libmysqlclient-dev.files:usr/lib/*/libmysqlclient_r.so
<slangasek> SpamapS: ok - is that an upload you'd like me to sponsor?
<rbasak> tyhicks: thanks for the review! I'll go through it tomorrow.
<tyhicks> rbasak: np - pretty simple stuff
<tyhicks> rbasak: BTW, don't worry about the changelog formatting changes unless the upgrade path needs fixed
<rbasak> tyhicks: what do you suppose I should do about the upgrade path? Unilaterally override existing permissions on that file, or only if it was 644, or only if upgrading, or some combination?
<tyhicks> rbasak: Good question. It isn't something that I have a lot of experience with. Let's get another opinion.
<tyhicks> sbeattie: Have a sec?
<rbasak> tyhicks: OK. Also for the changelog formatting, apart from the path error, in what way does it not match the examples? Or at least, I tried to follow the examples and looking at it now I'm not sure what you mean.
<rbasak> sbeattie: it's bug 858878 - thanks
<ubottu> Launchpad bug 858878 in cobbler (Ubuntu Oneiric) "lack of csrf protection in cobbler-web" [High,Incomplete] https://launchpad.net/bugs/858878
<tyhicks> sbeattie: A file containing password hashes has previously be incorrectly installed as world-readable. How do we typically handle that in a security update? (see rbasak's suggested options above)
<tyhicks> rbasak: I was suggesting s/(taken from upstream)/Based on upstream patch./
<tyhicks> rbasak: Like I said, very minor, but we try to make all of our updates have the same style.
<SpamapS> slangasek: I've been holding off to fix the static linking problem
<slangasek> SpamapS: hmm, which problem is that?
<rbasak> tyhicks: ah I see, np
<sbeattie> tyhicks | rbasak: I don't have a lot of experience here, either, but generally I think we've fixed things like permissions on configs on upgrade with a version check.
<rbasak> sbeattie, tyhicks: ok, thanks. I'll base it on a version check on upgrade then.
<tyhicks> thanks, sbeattie
<SpamapS> slangasek: mysql client is statically linked, and there's no obvious way to have it dynamically link
<slangasek> heh
<slangasek> SpamapS: ok; well, if you want me to sponsor something I can, and in the meantime I have a myodbc 5.1.9 branch that works for the unstable version of libmysqlclient and is as-yet-untested for experimental :)
<SpamapS> slangasek: will have something by EOD tomorrow
<slangasek> SpamapS: okie
<cjwatson> slangasek: I tracked down bug 900526; I'm not sure I'm reassured
<ubottu> Launchpad bug 900526 in debian-installer-utils (Ubuntu Precise) "d-i fails to divert initctl when upgrading packages during install" [High,Triaged] https://launchpad.net/bugs/900526
<cjwatson> (sentence starting "Alarmingly", always good for a laugh)
 * cjwatson targets to everything
<infinity> slangasek: ls for shell globbing, really?
<cjwatson> echo would do
<cjwatson> oh, no, it wouldn't, not without nullglob
<cjwatson> there's $(wildcard ...)
<broder> wildcard is a make-ism, isn't it?
<broder> (or did i miss context and this is in make-land?)
<cjwatson> I thought the context was make but ICBW
<infinity> cjwatson: shell.
<cjwatson> ah
<infinity> 14:15 < slangasek> trivial fix: /usr/lib/x86_64-linux-gnu/libgtk-3-0/gtk-query-immodules-3.0 $(ls  /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/*.so  /usr/lib/gtk-3.0/3.0.0/immodules/*.so 2>/dev/null)
<cjwatson> then ls isn't a bad way to filter out the way that the shell leaves unmatched globs unexpanded, unless you want to require bash for nullglob
<infinity> Which made me flinch.  I shouldn't read backscroll some days.
<infinity> Well, or you can glob and test.
<cjwatson> Yeah.  ls is a lot shorter though ...
<infinity> I just hate relying on the output of ls to be expected.
<infinity> Unless dpkg violently cleanses the environment.  I suppose it must anyway.
<slangasek> cjwatson: yowch
<slangasek> infinity: I didn't say pretty, I said trivial ;)
#ubuntu-devel 2012-01-04
<lifeless> ScottK: is https://bugs.launchpad.net/launchpad/+bug/566339 fixed ?
<ubottu> Ubuntu bug 566339 in Launchpad itself "Cannot accept package which would notify private email addresses" [High,Triaged]
<pitti> Good morning
<pitti> slangasek: apport root files> nothing known to me, and the code didn't change in ages, but perhaps that's another one of the sudo vs. admin regressions
<pitti> slangasek: fixed the bug importance setting, thanks
<didrocks> good morning
<pitti> slangasek: I get a window "firefox is already running, but is not responding" -- is that what you get?
<doko> pitti, I get spammed with "cannot open pixbuf loader files" on upgrades ... any gtk change?
<slangasek> pitti: thanks for the bug importance fix - and yes, "already running, but not responding" is what I see here
<iceroot> https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/911622
<ubottu> Ubuntu bug 911622 in gdk-pixbuf (Ubuntu) "[12.04] GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': Datei oder Verzeichnis nicht gefunden (file not found)" [Undecided,New]
<ScottK> lifeless: I've no way to know if it is or not.
<lifeless> ScottK: ah
<pitti> doko: I'll ask seb128 once he's online; looks like a multiarch bug in gdk-pixbuf, thanks for pointing out
<doko> cnd, did you update the pr5050 patch?
<micahg> pitti: could you please have a look at bug 906110, there are 2 dep waits on this package in universe
<ubottu> Launchpad bug 906110 in python-cogent (Ubuntu) "Please move python-cogent to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/906110
<pitti> micahg: done
<micahg> thanks :)
<pitti> jibel: happy new year!
<pitti> jibel: nice to hear that bug 903475 is fixed, thanks for confirming
<ubottu> Launchpad bug 903475 in openoffice.org (Ubuntu Precise) "Failed to upgrade from Oneiric to Precise: E:Could not perform immediate configuration on 'openoffice.org-writer'" [High,Fix released] https://launchpad.net/bugs/903475
<jibel> good morning pitti and happy new year!
<jibel> pitti, there's a new bug for lts upgrades bug 911659, I assigned it to foundations but it's more a kubuntu thing.
<ubottu> Launchpad bug 911659 in update-manager (Ubuntu Precise) "lucid -> precise upgrade failed: Could not perform immediate configuration on 'phonon-backend-gstreamer'" [High,New] https://launchpad.net/bugs/911659
<doko> cjwatson, slangasek: is it possible to depend on a multiarch package which is not the default architecture?
<doko> unlike for the ix86 multilibs, where libc6-i386 (amd64) and libc6 (i386) install into a different location, armel and armhf install into the same (multiarch) location
<doko> so gcc-4.6-multilib should depend on libc6-dev (<non-default-arch>) | libc6-dev-<non-default-arch> (<default-arch>)
<cjwatson> I don't believe so
<doko> the alternative is to change libc's symbols file for arm like:
<doko> libc.so.6 libc6 #MINVER# | libc6-armhf #MINVER#
<doko> and do that for libc, and the other biarch/multilib gcc runtime libraries
 * micahg wonders if arch specific multilib packages could depend on the package from the other arch marked as foreign
<micahg> i.e. gcc-4.6-multilib (armhf) depend on libc6-dev-armel which is only built on armel
<hrw> Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/lib/perl/5.14/File/Glob.pm line 3.
<doko> right, but then you do need to manually edit e.g. the substvars for libhfstdc++6
<hrw> did someone saw that during upgrade in precise?
<hrw> ok, manual reinstalation of perl-base helped
<hrw> guys: any new information about moving arm(el,hf) from ports.ubuntu.com to normal repo? I am a bit tired of having to disable/enable i386/armel on my amd64 when using multistrap like tools
<rbasak> hrw: that sounds like bug 862129
<ubottu> Launchpad bug 862129 in update-manager (Ubuntu Oneiric) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<rbasak> hrw: (the perl-base problem)
<hrw> rbasak: maybe, got it solved anyway
<doko> apw, about bug 903695, who is supposed to work on the verification-testing?
<ubottu> Launchpad bug 903695 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.0.0-1206.14 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/903695
<herton> doko, I usually do it, it is done, but as oneiric master had a regression and was redone, a new linux-ti-omap4 was rebased, and a new update is in progress (bug 911102)
<ubottu> Launchpad bug 911102 in linux-ti-omap4 (Ubuntu) "linux-ti-omap4: 3.0.0-1206.15 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/911102
<herton> which supersedes 3.0.0-1206.14
<herton> already closed 903695 as duplicate
<doko> herton, thanks
<mdeslaur> cyphermox: have you seen bug 911592? ssl certs don't work in evo in precise...
<ubottu> Launchpad bug 911592 in nss (Ubuntu Precise) "[precise] Too few certificate authorities listed after upgrade to 12.04" [High,Confirmed] https://launchpad.net/bugs/911592
<mdeslaur> (just fyi, not sure if it's nss or evo yet...)
<cyphermox> mdeslaur: ok, I'll take a look too
<mdeslaur> cyphermox: thanks
<seb128> doko, hey, could you send your patch from https://launchpad.net/ubuntu/+source/dia/0.97.1-10ubuntu1 to the bts or open a bug? it's the only diff we have on dia, so we could sync it...
<pitti> doko: natty linux-ti-omap4 and lucid linux-fsl-imx51 moved to -updates/-security FYI
<cyphermox> mdeslaur: afaict evolution would be trying to import certs from nss; all I can see is that it uses nssckbi to do this and appears to look for it in nss's libdir, which seems correct
<cyphermox> mdeslaur: but I can't seem to call certutil right to see what certificates NSS has, any idea how this works?
<cyphermox> mdeslaur: certutil -L -d something, but the something I can't quite get right yet
<mdeslaur> cyphermox: yeah, I tried to play with certutil earlier also, and apparently got stuck at the same place you're at
<cyphermox> invalid database?
<mdeslaur> yep
<cyphermox> bleh
<mdeslaur> I was busy with other stuff, and didn't have time to look at it further
<cyphermox> ok
<seb128> do we sync new sources from debian unstable this cycle? or from testing like normal syncs?
<pitti> usually from testing
<seb128> ok, thanks, I will sync manually the ones I need then
<pitti> we can manually sync from anything of course, that's just for the (semi-)autosyncs
<pitti> seb128: libgda5? :-)
<seb128> yeah
<seb128> and gtkspell3
<seb128> they added a new source rather than dual building gtkspell
<seb128> pitti, thanks
<cjwatson> new from testing by default, yes
<seb128> thanks
<cyphermox> mdeslaur: found something, I think it might be evo's fault, will try a patch
<mdeslaur> cyphermox: cool!
<cyphermox> could someone please sponsor https://code.launchpad.net/~mathieu-tl/ubuntu/precise/check/merge-0.9.8-1.1/+merge/87420 ; I need this to be able to update bluez, check is a new build-depends and now bluez ftbfs because it's not compiled with PIC
<mdeslaur> cyphermox: sure, one sec
<doko> seb128, bug #654611:
<ubottu> Launchpad bug 654611 in KARL3 "Former Staff users appear in people directory reports." [Medium,Fix released] https://launchpad.net/bugs/654611
<seb128> doko, danke!
<mdeslaur> cyphermox: uploaded
<cyphermox> thanks
<rbasak> tyhicks, following on for yesterday, would http://paste.ubuntu.com/792803/ in a new cobbler.preinst be a sensible approach to fix the upgrade path? I need to get this into Precise first I presume, then update my patch for oneiric-security with the version number for comparison adjusted?
<doko> slangasek, why did you object to openmpi in main?
<slangasek> doko: deep dep chain with horrible build systems
<cnd> doko, he applied the patch with some changes: http://gcc.gnu.org/viewcvs/branches/gcc-4_6-branch/libstdc%2B%2B-v3/include/bits/shared_ptr.h?view=log
<doko> cnd, ahh, thanks. I thought he did see some testsuite regressions?
<cnd> no real regressions
<cnd> just errors and warnings emitted with different line numbers than before
<cnd> I'm new to gcc development, so I didn't know what was expected of a submission
<doko> ok, I'll prepare updates
<cnd> doko, note that the revision touches both shared_ptr.h and shared_ptr_base.h
<cnd> I don't know how to make viewsvn spit out a patch for a revision across files
<doko> apw, ogasawara: ^^^ will update gcc-4.6 this week. any kernel uploads pending?
<cnd> doko, thanks for pointing me in the right direction :)
<ogasawara> doko: not at the moment
<apw> ogasawara, i would expect we will get a 3.2 final any time now, like today
<doko> apw, ogasawara: sorry, reboot. any answers?
<ogasawara> doko:  we don't have anything pending currently but do expect 3.2 final to drop relatively soon, in which case we would want to upload.
<doko> ogasawara, so uploading today would work for you, and then using this build?
<ogasawara> doko: sure
<doko> afaics, nothing extraordinary again, just ice fixes
<doko> slangasek, cjwatson: ohh, I had some other business. boost1.48 ...
<cjwatson> the last I saw on debian-devel about that it still looked kind of marginal, but I don't know if you've worked out the amount of work required in main (say)
<cjwatson> reminds me, I need to work on gnutls28, seeing as I synced that in
<doko> there are about 28 build failures, a handful in main
<slangasek> doko: and is Debian making a push to get it sorted out?
<slangasek> cjwatson: I know openldap is on the gnutls broken list; I'm poking at the new upstream version, will see if this fixes it
<cjwatson> just added a transition tracker for it now
<slangasek> I'm not clear why it's called libgnutls28-dev instead of libgnutls-dev
<doko> slangasek, I won't upload it now, just when it starts in unstable. yes, there was an analysis of the build failures
<slangasek> doko: the analysis I saw looked kinda hand-wavy, suggesting that maintainers "just" needed to pull new upstream versions or change their build-dependencies to deal with it :)
<infinity> doko: Err, what's the point of your eglibc upload, exactly?
<infinity> doko: You're adding provides that aren't needed in any way.
<doko> they are, to install gcc-multilib without the biarch packages, but with the multiarch packages
<infinity> doko: Those same provides don't exist for any other bi-arch setup.
<infinity> doko: So, why just for ARM?
<doko> read the backlog
<infinity> doko: Hrm.  So, is the plan to make other biarch setups eventually behave the same way?
<infinity> doko: (Until then, I don't really see why ARM should be special here, even if the provides are technically true)
<infinity> doko: Mostly cause it's just confusing. ;)
<infinity> doko: Surely, just updating the Conflicts lines to match what they do for all the other biarch builds would have made things a bit less weird.
<doko> no, in other biarch setups you can install both the biarch and the foreign lib, not with arm*
<infinity> True.
<infinity> Well, true once someone fixes the ld.so overwrite mess.
 * infinity glances at slangasek.
<infinity> doko: I suspect it's still missing some conflicts there, then.
<doko> likely
<infinity> Ugh.  Why did quilt grow a recommends on m-t-a?
<jtaylor> reverted in git already
<infinity> Mmkay.
<iceroot> infinity: https://bugs.launchpad.net/quilt/+bug/911631
<ubottu> Ubuntu bug 911631 in quilt (Ubuntu Precise) "quilt is pulling citadel" [Medium,Triaged]
<infinity> iceroot: Yeah.  I'm inclined to cherry-pick the fix from git, because it annoyed me enough to waste a few minutes of my morning.
<iceroot> there are much bigger problems
<infinity> There always are.
<iceroot> https://bugs.launchpad.net/ubuntu/+source/citadel/+bug/911732
<ubottu> Ubuntu bug 911732 in citadel (Ubuntu) "[12.04] citadel-server is producing errors every second in syslog (DB: not a restored transaction DB: PANIC: Invalid argument citadel: bdb(): PANIC: Invalid argument citadel: bdb(): txn_commit: DB_RUNRECOVERY: Fatal error, run database recover) " [Undecided,New]
<iceroot> just because of quilt
<infinity> iceroot: I'll note that you deleted all of citadel's conffiles...
<infinity> iceroot: Or many of them, anyway.
<infinity> iceroot: That could, perhaps, relate to it freaking out?
<iceroot> infinity: i have deleted nothing
<iceroot> infinity: just "dist-upgrade" and quilt was pulling citadel
<iceroot> never touched a conffile by hand
<infinity> modified.conffile..etc.citadel.messages.aideopt: [deleted]
<infinity> modified.conffile..etc.citadel.messages.changepw: [deleted]
<infinity> [etc ...]
<iceroot> yes i know but it was not me
<iceroot> infinity: but i guess you dont have that ptoblems so it should be related to my system and the bug is invalid
<infinity> iceroot: Yeah, I just tried to reproduce it here, and the conffiles get installed correctly, and the daemon runs.
<infinity> iceroot: I can't guarantee that it's doing useful things, but it's not spinning out of control and throwing errors either.
<iceroot> infinity: strange but ok, thank you for the info then i will update the bug later
<iceroot> done
<jdstrand> seb128: hi (and happy new year :)
<seb128> jdstrand, hey, happy new year!
<jdstrand> seb128: I noticed that eog is now the image previewer in precise instead of evince. is this expected to change?
<seb128> jdstrand, hum?
<seb128> jdstrand, evince is a pdf,ps viewer, it never did image previews
<jdstrand> seb128: it did at one point actually. I have a qrt script that tests the thumbnailer and previewer
<seb128> jdstrand, well it does preview pdf and ps files
<seb128> jdstrand, but I doubt it ever previewed images
<chrisccoulson> jdstrand's machine is magic ;)
<jdstrand> I'd need to check. I know it supported it in the past. but the real question is-- we expect eog to be the image previewer? is it what also is doing the thumbnailing?
<seb128> yes
<jdstrand> ok, thanks
<seb128> jdstrand, https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/715874
<ubottu> Ubuntu bug 715874 in totem (Ubuntu) "gnome thumbnailers should have an apparmor profile" [Wishlist,In progress]
<seb128> you can probably add eog there
<seb128> jdstrand, in fact wait
<seb128> jdstrand, that's not right
<jdstrand> I might have done the schema files before and misremembered that bug
<seb128> evince is the pdf viewer
<seb128> eog is the image viewer
<jdstrand> yes
<seb128> thumbnailers for nautilus are: evince (pdf,ps,dvi), totem (videos)
<jdstrand> evince used to support images too. now it flakes out
<seb128> nautilus should be doing the images thumbnails by itself
<seb128> I don't think eog has any "thumbnailer"
<jdstrand> right, via gdkpixbuf
<jdstrand> but that is actually not super great. but this isn't so much about that bug
<jdstrand> ok, so no thumbnailer for eog
<jdstrand> I have be set straight
<seb128> jdstrand, ok, let me know if I didn't reply to your question, I'm not sure what issue you try to solve there ;-) evince was maybe support images thumbnails via gdkpixbuf but it was never meant to do anything with images by default, nautilus does the preview for those for ever and eog is the viewer for ever
<jdstrand> seb128: ok, that answers my question. thanks
<seb128> yw
<sbeattie> rbasak: yes, http://paste.ubuntu.com/792803/ looks good to me (tyhicks is on holiday)
<rbasak> thanks sbeattie. I fixed the bugs in that and have proposed it for precise. For oneiric-security I've changed just the version number to compare against, and will test that
<slangasek> cjwatson: openldap 2.4.28 still doesn't build with gnutls28
<cjwatson> grumble
<slangasek> (same issue as reported on list, undefined reference to `gnutls_certificate_get_x509_cas')
<sbeattie> rbasak: where's the current proposed version?
<rbasak> sbeattie: for precise? https://code.launchpad.net/~racb/ubuntu/precise/cobbler/858860/+merge/87508
<slangasek> hmm, why did I get a prompt from dictionaries-common on upgrade?
<slangasek> (debconf prompt)
<micahg> slangasek: krb5 back in sync
<hallyn> jdstrand: for bug 901272 does http://people.canonical.com/~serge/debdiff look ok?
<ubottu> Launchpad bug 901272 in libvirt (Ubuntu) "Missing entries in libvirt-qemu AppArmor profile" [Undecided,Triaged] https://launchpad.net/bugs/901272
<hallyn> (in later comments you both left out the directory/ r parts, but i assume those are still needed)
<jdstrand> hallyn: looks fine to me
<jdstrand> hallyn: thanks!
<hallyn> great, thanks
<slangasek> micahg: woohoo :)
 * cjwatson sighs at SourcePackageRelease.dsc_binaries being nadgered for significant numbers of packages in production
<Daviey> How are your eyses anyway?
<cjwatson> eyses?
<Daviey> hmm, wrong window, sorry.
<tormod> anyone who would like to take care of bug 588935? Otherwise I will ask again next year also.
<ubottu> Launchpad bug 588935 in linux-wlan-ng (Ubuntu) "please drop linux-wlan-ng from ship-live seed" [Undecided,New] https://launchpad.net/bugs/588935
<micahg> tormod: I could make the change, but I'd like an ACK from cyphermox or someone on the desktop team that this is really not needed in Ubuntu
<cyphermox> what does linux-wlan-ng do? :)
<slangasek> it makes your wlan go "nnng"
<slangasek> it's a support package for some very old drivers
<tormod> slangasek, most people installing it think exactly that :)
<stgraber> wow, prism2, I'm pretty sure I have a pcmcia card that uses that (very old 802.11b card) but I don't have any machine that still has pcmcia nor any access point that still allows 802.11b clients :)
<cyphermox> I'm not against dropping it, but I also don't have that hardware ;)
<slangasek> tormod: why are people installing it, and what do you recommend as an alternative for users of these cards?
<tormod> slangasek, they want "new generation" to fix all their wlan issues :)
<tormod> see my explanation in the bug report
<tormod> it is just useless on a live CD without network
<micahg> tormod: that's not a reason to remove it
<tormod> from the CD?
<slangasek> micahg: it's a reason not to have it taking up space on the CD
<slangasek> if it can't be used to actually enable someone's network device unless they already have network access
<micahg> ah, right :)
<micahg> what I think is more interesting is that the description says it's been included in kernels since 2.6.31 anyways
<tormod> micahg, there are different binary packages
<micahg> so, I guess that's some consensus to remove it?
<slangasek> yep - removed
<tormod> slangasek, thanks!
<slangasek> tormod: fwiw, bugs like this will probably get attention more quickly if filed against the ubuntu-meta package instead; I assume no one was actually watching bugs on linux-wlan-ng
<tormod> slangasek, thanks I had no idea where to hand it to. not first time I ask about it here though.
<slangasek> apparently you caught us at a bad time the last time you asked :)
<tormod> slangasek, is it fixed in ubuntu-meta with a LP: closer?
<cjwatson> it won't actually need an ubuntu-meta upload, but ubuntu-meta is the package we use as a sort of pseudopackage for seed changes
<slangasek> ship-live doesn't pull from the package, but from the bzr repo... ubuntu-meta is just the closest that we have for - drat, cjwatson is faster again
<cjwatson> since *some* seed changes go into ubuntu-meta
<tormod> cjwatson, thanks, I'll close the bug then.
<cjwatson> I suppose we could use the ubuntu-seeds project, but at the moment we don't
<micahg> slangasek: it's in 2 other seeds also (ship and usb-ship-live), should it be removed from either of those?
<slangasek> hohum
<slangasek> yes, it should :)
<slangasek> done
<micahg> slangasek: the only question left is whether or not it should stay in main, now that it's not seeded, it'll show up on components-mismatch
<slangasek> micahg: I don't think that's really a question :)
<slangasek> i.e., it's obvious to me that it should be demoted
<ScottK> stgraber: Thanks for the networking blog post.
<stgraber> ScottK: np. Glad you liked it.
<ScottK> slangasek: Would there by any chance you could don your archive admin hat and process pending backports.  There's only a few, but some of them have been sitting there a long time
<slangasek> ScottK: looking
<ScottK> slangasek: Thanks.
 * micahg goes to mark a backport as accepted quickly
<micahg> done
<slangasek> ScottK: the tools are failing to backport clamav; I'm guessing this is not the outcome you were looking for ;)
<ScottK> Heh.  No.
<ScottK> Sigh.
<micahg> slangasek: I assume you used the backporthelper script?  I just want to know who to complain to about being credited for a backport I didn't request
<slangasek> micahg: ah, my understanding is that the convention is that the backport team is always credited
<slangasek> so yes, I used the backporthelper script, but I think this is wontfix :)
<micahg> slangasek: oh really?
 * slangasek nods
<micahg> ScottK: is this the way it's supposed to be?
<broder> micahg: cjwatson made me change it to do that
<ScottK> credit/blame, but yes.
<micahg> oh, fun :)
<ScottK> Most backports requests are made by people not invovled in development, so you need a dev to point a finger at.
<micahg> ScottK: yes, I was more concerned about the latter ;)
<ScottK> So tag.  You're it.
<ScottK> broder: can you figure out why the clamav backports wouldn't work?
<broder> slangasek: how did it fali?
<broder> oh wait...i bet i know how it fails
<slangasek> I: Extracting clamav_0.97.3%2Bdfsg-1ubuntu0.11.04.1.dsc ...
<slangasek> that doesn't parse right
<slangasek> rather, it can't match it to a file name
<broder> i have suspected for a while that backporthelper doesn't correctly handle backports that aren't from the release pocket, but have never actually had an opportunity to investigate it thoroughly
<broder> but i have to run at the moment
<slangasek> this looks like a simple filename encoding issue
<ScottK> slangasek: You wouldn't have happened to have kept a list of what packages got hit when we multi-arched Qt would you?  fabo is about to do it in Debian and it'd be nice to give him a list.
<slangasek> hrm, I don't think so
<tormod> any patch pilot volunteer for bug 908711 ?
<ubottu> Launchpad bug 908711 in s3switch (Ubuntu) "Please sync s3switch 0.1-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/908711
<slangasek> anything I produced a patch for *should* have been sent to the Debian BTS
<ScottK> OK.  Thanks.
<cyphermox> hallyn: hey
<cyphermox> hallyn: I noticed you uploaded libvirt earlier; would you please be able to review https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/908581 as well, it would remove libvirt from the NBS list for libnl3?
<ubottu> Ubuntu bug 908581 in libvirt (Ubuntu) "FTBFS with libnl3 >3.2" [High,New]
<slangasek> ScottK: mass-sync fixxored; apparently this is the first time in a while anyone's needed to backport a package that had a + in the version number :)
<ScottK> Interesting.
<ScottK> Thanks.
<hallyn> cyphermox: taking a look
<cyphermox> hallyn: thanks. sorry to bug you with this
<hallyn> d'oh
<hallyn> np at all - thanks for pointing it out
<hallyn> ok lemme do a few test builds and i'll upload
<hallyn> so libnl-3-dev replacing libnl3-dev is the way to go, for sure?
<hallyn> (waiting for the pkgs to d/l)
<hallyn> heh, i see, guess so
<hallyn> cyphermox: something doesn't seem right with the (change to the) libnl3.patch - Makefile.am adds LIBVIRT_LIBS, but Makefile.in adds LIBNL_LIBS (which is already there)?
<hallyn> so i think the first hunk of the src/Makefile.in patch is suppsoed to add LIBVIRT_LIBS?
<hallyn> except that seems wrong (doesn't exist)
<hallyn> i'll ask in the bug
<hallyn> oh no, maybe quilt is playing games with me
<hallyn> nope that's not it
<cyphermox> hallyn: I need to run, but I can take another look later... though it's not my patch :)
<hallyn> cyphermox: no worries, i'm just pulling that out, and if it builds i'll push it with that bit pulled out;  otherwise i'll wait for a response from the bug submitter.
<hallyn> thanks
<cyphermox> ah
<hallyn> cyphermox: seems to work fine like that, i'll upload and hope i did the right thing :)  thanks again for pointing it out, it wasn't on my radar
<cyphermox> np, thanks to you
<cyphermox> if it builds, it's most likely right
<cyphermox> if anything was wrong with that patch the build would just fail to compile or link
<cyphermox> bbl
<slangasek> bdmurray: is bug #912017 a known package manager bug?  (Could not install the new version of "/sbin/unix_chkpwd": No such file or directory)
<ubottu> Launchpad bug 912017 in pam (Ubuntu) "package libpam-modules 1.1.1-2ubuntu5.4 failed to install/upgrade: impossibile installare la nuova versione di "/sbin/unix_chkpwd": Nessun file o directory" [Undecided,New] https://launchpad.net/bugs/912017
<bdmurray> slangasek: I'd not heard of it and don't see that message in any other DpkgTerminalLog files
<slangasek> ok
<bdmurray> slangasek: did you look at dmesg?
<slangasek> bdmurray: I hadn't, but I'm not surprised to see that it's a low-level filesystem problem
#ubuntu-devel 2012-01-05
<lifeless> bryceh_: hey, https://bugs.launchpad.net/launchpad/+bug/617695 seems either stalled or done, I can't tell.
<ubottu> Ubuntu bug 617695 in Launchpad itself "Extend bug tracker config pages to allow manually linking products/components to source packages" [High,Triaged]
<tilgovi> anyone have experience with git-dpm?
<twb> What provides /etc/mailcap ?  It's mentioning vim instead of vi, which is wrong for the vim-tiny that ubuntu-minimal pulls in.
<geofft> twb: looks like mime-support
 * twb digs
<twb> Ah, "update-mime"; I was looking for "update-mailcap"
<geofft> you may or may not be able to do something with update-mime? yeah
<twb> OK, problem solved
<twb> Broken file is /usr/lib/mime/packages/vim-common
<twb> http://bugs.debian.org/654674 FYI
<ubottu> Debian bug 654674 in vim-common "vim-tiny incompatible with vim-common's mailcap" [Minor,Open]
<micahg> doko: all the gcc builds except for i386 look hung
<doko> no, yellow usually takes 12h
<micahg> ah, ok
<doko> but we maybe can kill the snapshot build on powerpc, it will fail anyway
<pitti> Good morning
<bryceh_> lifeless, the code is finished and landed, but got feature flagged off so is unusable :-(
<lifeless> bryceh_: why did that happen?
<bryceh_> lifeless, I think curtis wanted to review the UI in more detail, but I think he's been tied up on other stuff
<lifeless> nab him next week
<StevenK> Even if the flag is only turned for a small team
<bryceh_> lifeless, I had a follow on branch (https://code.launchpad.net/~bryce/launchpad/component-in-bug-filing-links) but it's kinda hard to test without having the config branch available so having it disabled stalled that work.
<lifeless> I would say just turn it on, its new stuff not changes to existing UI, so might be horrible but unlikely to regress anything
<lifeless> but, if sinzui wanted it off, I don't want to second guess him
<bryceh_> lifeless, my hope was to get the bugtracker forwarding feature escalated on the stakeholder roadmap so I could get more active help at getting this done, but of course that hope's been dashed ;-)
<bryceh_> lifeless, right, it's new UI in an out of the way corner I think few users go to, but for certain bugtrackers with lots of packages (e.g. gnome) it makes for a rather long list of links and buttons.  I'm sure curtis could think of a more attractive way to show it.
<lifeless> perfect enemy good etc
<lifeless> anyhow, nab him, and I'm sure he'll unblock it somewhat
<bryceh_> lifeless, certainly.  In any case thanks for looking into it.
<bryceh_> lifeless, I notice you've marked it down to low priority?
<lifeless> bryceh_: I have to downgrade 900 bugs
<lifeless> bryceh_: this reflects accurately the project opinion of the bug I think; you can of course hack on it yourself; and if you escalate it, its importance will increase (a lot :P)
<bryceh_> lifeless, ...
<lifeless> bryceh_: ?
<bryceh_> lifeless, I've got my own separate tools for doing bug upstreaming for X.  Reason I've been working on this was because I understood it was functionality folks wanted to see integrated in launchpad itself.
<lifeless> bryceh_: we do
<lifeless> bryceh_: LP is *big*; fpr the 'high' category of bugs we want ~ 6 months work; with the changes happening thats about 1/4 what it was before
<lifeless> bryceh_: if you think this thing is worth bumping a different one from, from the perspective of canonical sponsored work on LP, thats fine - just put it back to high, explain why, and I'll try to find something else to bump
<lifeless> bryceh_: e.g. for remote bug tracker stuff, we have the following defects - offhand -
<lifeless>  - archived debugs don't work
<lifeless>  - savannah.nongnu.org doesn't work
<lifeless>  - other instances od debugs don't work
<lifeless>  - mantis doesn't work
<lifeless>  - sourceforge doesn't work
<bryceh_> lifeless, wow
<lifeless>  - comment push cannot be disabled without disabling watches
<lifeless> bryceh_: so I'm looking at a lot of bugs and making the best assessment I can; I will get it wrong - like I say above, if this is one of those cases, say so (in the bug please) and I will correct
<bryceh_> lifeless, okay. Well this goes along with the bug forwarding feature, which has already been escalated.  I think there's little harm in  this bug waiting until that feature work bubbles back up in priorities.
<lifeless> bryceh_: I think you should get the stuff done so far fully live, having inventory on the shelf sucks
<bryceh_> lifeless, yes, I totally 100% agree
<bryceh_> lifeless, I guess basically I've been stuck not knowing *how* to get it fully live.
<bryceh_> lifeless, also btw since I'm merely a community guy now I don't have powers for setting launchpad bug priorities or anything fancy like that anymore
<lifeless> bryceh_: so, getting it live - put a request on launchpadproductionstatus to turn the flag on
<lifeless> bryceh_: unless sinzui asked you not to or whatever
<lifeless> bryceh_: Would you like to be in ~canonical-launchpad-emeritus ?
<bryceh_> lifeless, maybe?  I don't know what that is
<lifeless> a group for ex-lp engineers that are still at cnaonical
<lifeless> grants bugsupervisor
<lifeless> will grant review etc when I figure out how not to spam the team
<bryceh_> ok, sounds useful
<lifeless> the presumption is you are still tacking the broad project so that this is useful :)
<lifeless> right, you should have bugsupervisor now
<bryceh_> lifeless, thanks
<bryceh_> lifeless, ok past EOD for me, hopefully I can catch curtis next week.  I think it's going to be a busy week for me.
<lifeless> likewise :)
<micahg> jamespage: hi, I've got a build failure with a new java package that I'm not sure how to fix, I tried adding the build dependency it seems to want, but I get the same failure, the build works fine with network access (it must be downloading something) https://launchpad.net/~micahg/+archive/ftbfs-test/+build/3064946, this is needed for an FTBFS depwait in precise
<jamespage> micahg: lemme take a look
<jamespage> micahg: see http://paste.ubuntu.com/793582/
<jamespage> basically it can't generate the javadoc because it can't find the artifacts it just built
<micahg> ah, so I was still missing stuff
<jamespage> micahg: well its a fault in the packaging really - it should use 'install' rather than 'package' to ensure that the jars are deployed into the local maven repository during the build process
<micahg> jamespage: oh, is that it?
<jamespage> micahg: setting DEB_MAVEN_BUILD_TARGET := install in debian rules should resolve the issue
<micahg> jamespage: thanks!, will try that
<jamespage> BTW I got that error message by building offline locally and then looking at the txt file that the error message refers to.
<micahg> jamespage: BTW, is there a guide anywhere to fix Java FTBFS?
<jamespage> micahg: nope
<micahg> jamespage: do I still need the javadoc-plugin build dependency?
<jamespage> micahg: I already see libmaven-javadoc-plugin-java as a build-dep in Debian? not sure why you had to add that...
<micahg> jamespage: ah, indeed it is, I guess I couldn't see it when trying to fix this the first time at 3AM :)
<frafu> Hi,
<frafu> As you probably know, Onboard is the onscreen keyboard shipping by default with Ubuntu. We are considering porting it to python 3. Could anybody please tell me whether python 3 will be available on the Ubuntu 12.04 LiveCD? Could anybody please tell me whether there is any reason concerning Ubuntu to not port Onboard to python 3? Thanks in advance.
<brendand> frafu - it will be there
<brendand> as for reasons not to port it. ? maybe someone else has something to say
<brendand> frafu - you can always check http://cdimage.ubuntu.com/daily-live/current/precise-desktop-i386.manifest for a package list
<brendand> frafu - i guess you could find some required modules aren't yet ported to python3 i guess
<frafu> brendand: Thanks for the reply and the link to the list with the packages of the current LiveCD. It will be useful to check whether the required dependencies are also available. If anybody sees a reason to not port it (assuming all dependencies are available on the LiveCD), please let me know.
<iceroot> the contact for universe-packages is ubuntu-sponsors? or is that handled on a different way?
<pitti> ubuntu-sponsors sponsors all components
<iceroot> all? so i guess "main" is not called a component? or am i wrong?
<geser> iceroot: "main" is a component but ubuntu-sponsors isn't limited on any specific component
<pitti> iceroot: IOW, ubuntu-sponsors is fine for universe
<iceroot> hm maybe not the right channel for that but i have sometimes the problem about putting the responsable team on cc on LP, so in universe i always choose sponsors, for the rest i am doing a depper search (like ubuntu-kernel-team, lubuntu-desktop)
<Laney> You can use ubuntu-sponsors if you have something to be sponsored for any package, except security updates for which you should use ubuntu-security sponsors. That makes it appear on http://reports.qa.ubuntu.com/reports/sponsoring/.
<iceroot> Laney: thank you for the info
<TLE> pitti: hallo, since there are no language packs in the build queue: https://launchpad.net/ubuntu/oneiric/+builds?build_text=&build_state=pending&arch_tag=all I guess we are good to go for oneiric lang pack testing?
<pitti> TLE: yes, since yesterday already
<TLE> pitti: great thanks
<pitti> TLE: will do the natty -updates copying now
<TLE> pitti: great
<pitti> cjwatson: our current i386 alternate now has both the pae and the regular kernel, which is why it exploded so much; seed error, or on purpose?
<cjwatson> error
<cjwatson> I think
<cjwatson> I'll check and sort it out, thanks for the heads-up
<pitti> thanks
<Laney> how often does the sponsorship queue run?
<Laney> (and when)
<pitti> feels like every 20 minutes or so
<Laney> k
<pitti> seb128, cjwatson: FYI, http://people.canonical.com/~pitti/tmp/oneiric-precise2012-01-05-cdsize.txt is a cleaned up output of oneiric vs. today's precise amd64 CD size analysis
<seb128> pitti, thanks
<pitti> so 9.1 MB delta from package growth, 10 MB net delta from removed/added packages
<pitti> adding python 3.2 is +5.9 MB, that's known
<pitti> I'll check fonts-nanum, it was supposed to replace the old unfonts, but I don't see that on the removal list
<seb128> pitti, I will look at the gtk2 one, I wonder if that's the "don't bzip the changelogs, news, etc" to workaround that gzip md5sum between archs bug
<pitti> seb128: hm, hardly -- we don't even install most of those
<seb128> but that seems a bit much to be that
<pitti> seb128: but anyway, thanks
<pitti> geoip-database (Î 0.2 MB - 20110709-1: 3.3 MB   20111220-1: 3.5 MB)
<pitti> that's an interesting growth
<cjwatson> Is it?  Probably just more data?
<pitti> I'll take the evince growth, too
<pitti> cjwatson: haven't looked at it yet; but 200 kB -> 3.3 MB seems quite radical
<pitti> could be that our previous package didn't actually ship any data or so :)
<cjwatson> Uh, that output says 3.3 MB -> 3.5 MB.
<pitti> argh, *headdesk*, of course
<pitti> *blush*
<pitti> I just phear the moment when Sweetshark uploads the new LibO :)
<seb128> cjwatson, do you know if there is any chance gparted would go to gtk3 this cycle btw? it's keeping the gtk2 bindings on the CD, dropping those would win some space as well
<pitti> seb128: the two libjavascriptcoregtk versions are probably a splitout from webkit? all the more reason to drop the gtk2 webkit
<cjwatson> seb128: sorry, I don't know
<seb128> cjwatson, no worry, I was just checking in case
<cjwatson> I did file an upstream bug and upstream followed up a bit
<cjwatson> I don't remember the current status though, you can probably check bugzilla as well as I can :)
<seb128> cjwatson, yeah, I checked bugzilla, it's not very encouraging ;-)
<cjwatson> (sorry, have so far done one out of five things planned for today ...)
<seb128> cjwatson, I asked in case you had extra infos compared to what is in bugzilla
<seb128> no worry
<cjwatson> I don't, no
<seb128> ok
<seb128> pitti, no clue about libjavascriptcoregtk
<pitti> seb128: rdepends of libwebkitgtk-1.0-0
<pitti> cjwatson: I did a test install on my mini 10, and bcmwl fails; turns out that we only install l-headers-3.2.0-7-generic, not -pae; want me to fix the seeds, or do you want to?
<cjwatson> pitti: I just did, independently :)
<pitti> cjwatson: thanks
<psusi> cjwatson: how's the workload?  just wandering if you'll have time to review my parted merge soonish ;)
<cjwatson> psusi: Probably not this week I'm afraid
<cjwatson> Remind me next week?
<cjwatson> pitti: Oh god, -generic being on i386 images is a germinate bug
<cjwatson> (Not the headers, but image and installer bits)
<cjwatson> Kernel-Version isn't scoped properly
 * cjwatson edits the warty seeds, as the only seeds relying on this germinate bug :-)
<psusi> cjwatson: sure
<pitti> cjwatson: ... in case we want to release 4.10.1 :)
<pitti> "The Vintage Edition Release"
<cjwatson> call it OCD ...
<cjwatson> this bug goes back to germinate r25!
<cjwatson> (currently at r470)
<pitti> cjwatson: it affects package names where one is a prefix of another one?
<pitti> probably not a very common case indeed
<cjwatson> No
<cjwatson>  * Kernel-Version: foo-generic
<cjwatson>  * /^.*-modules-.*-di/ [amd64]
<cjwatson>  * Kernel-Version: foo-generic-pae
<cjwatson>  * /^.*-modules-.*-di/ [i386]
<cjwatson> The Kernel-Version in force for the last line is in fact "foo-generic foo-generic-pae"
<cjwatson> This is bogus
<cjwatson> ... and this is truly painful to fix because germinate only keeps a record of that per-seed right now and indeed processes it long after it's forgotten exactly where in the seed it is
<cjwatson> I may be able to bodge it
<apw> cjwatson, am seeing a 'grep: input file '/boot/grub/grub.cfg.new' is also the output' for each grub menu update on P, known ?
<cjwatson> apw: I did notice that but I haven't investigated it yet
<apw> cjwatson, is there a bug, or shall i do the honours
<cjwatson> I'm not up to date on grub2 bugs
<cjwatson> feel free to file one, worst case I dup it
<cjwatson> even better, fix it :)
<apw> cjwatson, no worries, i'll do that
<jibel> apw, bug 911225
<ubottu> Launchpad bug 911225 in grub2 (Ubuntu) "grub-update: bad 'grep' and 'lvs' invocations" [Undecided,New] https://launchpad.net/bugs/911225
<apw> UpgradeStatus: Upgraded to precise on 2009-02-07 (1060 days ago)
<apw> time traveling machine it seems
<seb128> zul, slangasek: could you look at bug #911888 and make sure it doesn't get ignored? it seems a new issue with samba, we got 3 bugs about it this week
<ubottu> Launchpad bug 911888 in samba (Ubuntu) "gvfsd-smb-browse crashed with SIGSEGV in debug_lookup_classname_int()" [High,Confirmed] https://launchpad.net/bugs/911888
<hallyn> jdstrand: on bug 912007, should I just add '/dev/dm* r' to /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper ?
<ubottu> Launchpad bug 912007 in libvirt (Ubuntu) "Apparmor profile denies access to /dev/dm-* for guests using LVM partitions storage" [Low,Triaged] https://launchpad.net/bugs/912007
<zyga> has anyone seen james hunt recently?
<jdstrand> hallyn: I have been thinking about that. I think it would be better to add deny rules like we do for /dev/mapper/ and /dev/sd*
<jdstrand> hallyn: that will silence the non-fatal denial without giving away more access
<stgraber> zyga: sure, though maybe you didn't notice he changed his nick for jodh
<hallyn> grr, compiz keeps crashing
<zyga> jodh, oh
<zyga> stgraber, many thanks :)
<zyga> stgraber, nice article about network interfaces btw :)
<zyga> jodh, hi, do you have a minute?
<hallyn> jdstrand: so adding the deny rule will stop the log msg?
<stgraber> zyga: thanks!
<jodh> zyga: hi
<hallyn> i see - i missed the /dev/sd entry when i looked before.  makes sense.  thanks.
<zyga> jodh, I'd like to get some advice from you on what a good "daemon/service" looks like upstart wise
<jdstrand> hallyn: yes. apparmor is deny by default with logging. an explicit deny rule will deny without logging. 'audit deny' will deny and log again
<zyga> I'm making some changes to celery (distributed queue for django and friends) and I'll be making sure celery plays nice with upstart
<jodh> zyga: does this cover it? http://upstart.ubuntu.com/cookbook/#daemon-behaviour
<zyga> is there anything I need to especially do to be "good" as a service from upstart's point of view?
<zyga> let me check and get back to you
<hallyn> jdstrand: now if only we had a working udd tree this is the kind of thing i'd queue up for the next upload.  but i'm afraid if i don't push this now i'll forget about it
<hallyn> guess i need to just keep a list.
<zyga> jodh, unrelated question, is 1.3 going to be backported to oneiric or is it just for precise+
<hallyn> jdstrand: anyway i'll add that, thanks
<jodh> zyga: we're on 1.4 now :)
<jdstrand> hallyn: thanks!
<zyga> I meant 1.4
<zyga> especially the new features for process containment
<jodh> zyga: I'm not aware of any current plan to do this.
<zyga> ok, thanks
<zyga> jodh, quickly looking at the link you provided I don't see any references to current working directory and logging
<jodh> zyga: daemons are free to handle those particular attributes as they wish. Upstart provides the chdir+chroot stanzas. conventionally, daemons use syslog but if they want to speak to stdout/stderr they can as of Upstart 1.4.
<slangasek> seb128: I defer to zul; I don't believe that samba 3.6.1 is releasable in general
<seb128> slangasek, ok thanks
<zyga> jodh, is it your recommendation that services daemonize themselves?
<cjwatson> pitti,apw: linux-image-generic is ending up in there because linux Depends: linux-image Depends: linux-image-generic
<cjwatson> pitti,apw: I think that linux-image should Depends: linux-image-generic-pae on i386 now; do you agree?
<apw> cjwatson, does linux-image really still have a place, i had thought it was really a transitional package
<apw> perhaps it is time for it to just go away
<cjwatson> apw: It's definitely not a transitional package.  It was always a dependency-only package
<cjwatson> Transitional packages are those which used to have real contents and are now dependency-only
<cjwatson> I think we ought to change it anyway to help the upgrade path
<apw> cjwatson, ahh i mean transition in the sense we used to use linux-image, then we got flavours so we added linux-image-<flavour> and those do the mappings
<cjwatson> In fact it's probably the simplest way to get the upgrade path right
<cjwatson> No, that isn't the cas
<cjwatson> e
<apw> if its meant to be the default flavour then it should point to -pae
<cjwatson> We never had linux-image depending on a contentful kernel image package directly
<cjwatson> The original semantics were that it was a per-architecture sensible choice of default if such a choice existed
<apw> ok, then yes under that definition it should point to the recommended kernel
<apw> cjwatson, shall i make that change happen?
<cjwatson> yes please :)
<apw> cjwatson, ack
<cjwatson> pitti: http://bazaar.launchpad.net/~cjwatson/germinate/trunk/revision/471 *sweat*
<apw> cjwatson, is there any tracking bugs for the generic generic-pae default change?
<cjwatson> apw: bug
<cjwatson> ere
<cjwatson> apw: bug 897786
<ubottu> Launchpad bug 897786 in linux (Ubuntu Q-series) "Kernel is dropping non-PAE flavour" [Undecided,In progress] https://launchpad.net/bugs/897786
<cjwatson> erk, cdimage is still using germinate 1.11
 * cjwatson upgrades that and crosses his fingers
<SpamapS> hmm.. is there something like apt-cacher-ng already in main?
<SpamapS> juju makes use of it, but I don't want to Recommend: apt-cacher-ng if we can drop something else in.
<apw> cjwatson, ok meta fixes are committed
<RoAkSoAx> adam_g: yeah still failing
<chrisccoulson> lamont, if i kill a PPA build, will it save the log for me? https://launchpad.net/~chrisccoulson/+archive/mozilla-test/+build/3070682 has progressed past the part of the build that i'm interested in, and don't really want to wait for the whole thing to finish
<chrisccoulson> (but i do want to see the log)
<RoAkSoAx> cjwatson: howdy... was just wondering if you've seen a grub-installer failure (for now in amd64) with error "main-menu[494]: (process:27699): Wrong number of args: mapdevfs <path>"
<RoAkSoAx> cjwatson: full syslog: http://paste.ubuntu.com/794026/
<slangasek> mvo: ping
<cjwatson> RoAkSoAx: No, that's new to me.  I'll need a syslog of an installation run with DEBCONF_DEBUG=developer on the kernel command line.  (Make sure not to use a valuable password.)
<mvo> slangasek: pong
<RoAkSoAx> cjwatson: adam_g just filled Bug #912431
<ubottu> Launchpad bug 912431 in grub-installer (Ubuntu) "Preseeded 12.04 grub-install failed: Wrong number of args: mapdevfs <path>" [High,Confirmed] https://launchpad.net/bugs/912431
<jtaylor> TheMuso: hi, have you spoken with the debian espeak maintainer about multiarching?
<jtaylor> if we could get it multiarched there too we don't have to maintain a diff for espeakup
<jtaylor> nevermind, we need a diff for the new pulse dep anyway
<RoAkSoAx> cjwatson: ok, just posted the syslog with debcof debug output in lp bug #912431
<ubottu> Launchpad bug 912431 in grub-installer (Ubuntu) "Preseeded 12.04 grub-install failed: Wrong number of args: mapdevfs <path>" [High,Confirmed] https://launchpad.net/bugs/912431
<apw> cjwatson, ok found the grub issue (the grep error I was seeing) and pushed up a branch for it, the other thing i've not looked at yet
<lamont> chrisccoulson: let me go stab that build in a way that will give you a log
<chrisccoulson> lamont, it's ok. it's finished now :)
<lamont> chrisccoulson: actually, I see that it finished
 * lamont was lunching with his daughter
<TheMuso> jtaylor: I have access to the Debian git repo for espeak, and I put my work into the git repo for Debian.
<TheMuso> jtaylor: Espeak is maintained by pkg-a11y, and I am on that team, so have access to their git repos on alioth.
<jtaylor> TheMuso: so the same update planned to be done in debian soon too?
<TheMuso> jtaylor: I can poke a member of the pkg-a11y team who is a DD to upload it if its urgent, otherwise it will be uploaded when one of them gets around to it.
<TheMuso> I generally just do work on both our packaging and Debian's, and they haven't complained yet, so this seems to work well for us.
<TheMuso> jtaylor: Oh for espeakup as well, I could get that into the git repo for you if you'd like.
<jtaylor> I have no real connection with the package, I just fixed the last ftbs
<jtaylor> and the new espeak upload breaks it again
<TheMuso> Ah ok.
<jtaylor> I'll just wait a bit for the update in debian
<TheMuso> Do you have your work for espeak somewhere, i.e the changes needed to make it build again? If not, enver mind, I'll take a look myself.
<jtaylor> one issue is the espeakup udeb, as espeak now needs pulse the udeb pulls in a nono-udeb
<jtaylor> I'll upload a branch that fixes it in a moment
<TheMuso> Ok.
<semiosis> hi all, i've got a solution for an ubuntu-specific bug in a package we get from debian.  how can I go about contributing the fix to the ubuntu packaging?  it's really simple, just replacing an initscript with an upstart job.
<semiosis> https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/876648
<ubottu> Ubuntu bug 876648 in glusterfs (Ubuntu) "Unable to mount local glusterfs volume at boot" [Undecided,New]
<jtaylor> TheMuso: lp:~jtaylor/ubuntu/precise/espeakup/sync-and-fix-ftbs
<jtaylor> TheMuso: and here the diff against debian: http://paste.ubuntu.com/794209/
<arges> is there a wiki on how to create a backport of a package for testing? i have pbuilder-dist set up on my machine, but not sure if that's the right tool.
<smoser> cjwatson, around ?
<smoser> or anyone who would know what debug info i should collect for bug 912492
<ubottu> Launchpad bug 912492 in debian-installer (Ubuntu) "install fails during grub installation" [Undecided,New] https://launchpad.net/bugs/912492
<TheMuso> jtaylor: Thanks, will get that uploaded and into Debian for you today.
<jtaylor> its not needed as long espeak is not update
<jtaylor> also the pulse udeb issue should be checked
<TheMuso> Ok.
<broder> arges: you should check out backportpackage in ubuntu-dev-tools
<TheMuso> jtaylor: Actually, I think there are grounds for not linking libespeak.a against pulse at all, since libespeak.a is statically linked against espeakup.
<TheMuso> jtaylor: So I'll fix the espeak packaging so that pulse is only used in the shared lib.
<TheMuso> And then adjust your espeakup diff accordingly and upload both.
<arges> broder, awesome. i'll check that out
<semiosis> can anyone point me in the right direction to contribute an ubuntu specific change to a package we import from debian?
<micahg> semiosis: if you likes VCSs: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<semiosis> micahg: thank you! sure I like VCSs
<semiosis> i'm basically already at "request merge" i just have no idea how to go about doing that.
<micahg> ah, ok
<semiosis> i have already contributed the fix to the upstream project, now its just a matter of updating the ubuntu packaging to use it (an ubuntu upstart job instead of the debian initscript)
<semiosis> i even have a ppa with the fix already included :)
<semiosis> after much testing, i think its ready for primetime
<micahg> ah, so you just need the info at the bottom of that page then
<semiosis> micahg: thanks so much I think i can have this done today :D
<micahg> great!
<chrisccoulson> hi cnd, you around?
<cnd> chrisccoulson, yep
<chrisccoulson> cnd - i've just restart my precise box after doing the first upgrade in a while, and noticed that edge scrolling no longer works on my touchpad
<chrisccoulson> cnd - i have "2 finger scrolling" enabled in control center, which i think is the default. but, isn't it meant to fall back to edge scrolling when 2 finger isn't suported?
<cnd> chrisccoulson, unfortunately, that's not the case
<chrisccoulson> it doesn't seem to be doing that now (i have to actually select edge-scrolling in control-center to make it work)
<chrisccoulson> oh?
<cnd> IIRC, you can do both at the same time, if you twiddle with options in xinput
<cnd> but the GTK configuration dialog doesn't allow that flexibility
<cnd> it does exactly what it says
<cnd> if you select two touch scrolling, it won't do edge scrolling
<chrisccoulson> cnd - wasn't 2 finger scrolling enabled by default before though?
<cnd> chrisccoulson, we looked into it
<cnd> but the GTK configuration dialog was one reason we couldn't enable it by default out of the box
<cnd> so it was put on the back burner
<chrisccoulson> hmmm, i wonder what's changed then? i've had to manually enable edge scrolling now :/
<chrisccoulson> maybe this is seb128's fault ;)
<seb128> chrisccoulson, !!!
<chrisccoulson> seb128, is it fixed yet???
<seb128> lol
<seb128> chrisccoulson, wait, you will see ;-)
<chrisccoulson> heh
<arges> broder, ok i'm getting the same result previously when just using pbuilder-dist and the .dsc.  It says it needs newer versions of  cdbs and debhelper.  Do I need to backport those packages first and use those? or is there a repo i can add?
<broder> arges: usually the best thing to do in that case is figure out why the required versions of cdbs/debhelper are so high, modify the packaging so it doesn't need features from those versions, and then drop the build-dependency to whatever is in the release you're backporting to
<broder> that's not something that can be automated
<arges> broder, ok gotcha
<cnd> chrisccoulson, I thought edge scrolling was the default, maybe upstream gtk changed it?
<chrisccoulson> cnd, hmm, i'm confused now. it doesn't look like the default has changed
<Daviey> Anyone else noticed mountall/upstart core dump on boot?
<TheMuso> Daviey: Is this after the most recent mountall update? If so, not yet, as I haven't updated yet.
<bryce> Daviey, nope, I just updated this morning.  I got several crash notices but not upstart or mountall
<Daviey> there is NOW a pending mountall update which wasn't on my local mirror when i last updated :)
 * Daviey tries it
<slangasek> Daviey: ehm, that sounds rather serious - which process is the one doing the dumping?
<smoser> has anyone seen bug 912492 ?
<ubottu> Launchpad bug 912492 in debian-installer (Ubuntu) "install fails during grub installation" [Undecided,New] https://launchpad.net/bugs/912492
<smoser> it does not seem system specific for me
<hallyn> smoser: yeah adam_g reported the same bug
<hallyn> smoser: bug 912431
<ubottu> Launchpad bug 912431 in grub-installer (Ubuntu) "Preseeded 12.04 grub-install failed: Wrong number of args: mapdevfs <path>" [High,Confirmed] https://launchpad.net/bugs/912431
<Daviey> slangasek: I'm not exactly sure...
<slangasek> Daviey: are you able to boot in spite of the crash?
<Daviey> slangasek: i'm not exactly getting much data out.
<smoser> i'd say thats critical as critical can get
<Daviey> slangasek: only to rescue mode.
<Daviey> slangasek: http://bootie.daviey.com/~dave/erk/
<Daviey> i'm not /certain/ it's mountall, but did happen at the same time.
<slangasek> Daviey: please try booting with --no-log added to the kernel commandline
<Daviey> slangasek: to single user mode, or normal boot?\
<slangasek> normal
<Daviey> ok
<slangasek> and after testing that way, you might want to delete /etc/udev/rules.d/86-hpmud-hp_laserjet_professional_p1566.rules...
<slangasek> Daviey: so, that should've done the job; did it?
<Daviey> slangasek: sorry for the slow RTT, yes - it got me to a functioning desktop
<slangasek> ok
<slangasek> please file a critical bug against upstart
<Daviey> wilco
<Daviey> slangasek: bug 912558
<ubottu> Launchpad bug 912558 in upstart (Ubuntu) "log.c Assert failed - err=>number == EIO" [Critical,New] https://launchpad.net/bugs/912558
<slangasek> pitti: has bug #901038 been reproduced by anyone else?
<ubottu> Launchpad bug 901038 in upstart (Ubuntu) "packages fail to install: Failed to connect to socket /com/ubuntu/upstart: Connection refused" [Undecided,Confirmed] https://launchpad.net/bugs/901038
<slangasek> pitti: the symptom is quite suspect; one doesn't get "upstart not running" on a 12.04 system...
<slangasek> Daviey: thanks
#ubuntu-devel 2012-01-06
<smoser> where does 'apt-install' in the server installer (debian-installer) come from?
<smoser> i'm just wondering what changed that caused bug 912431
<ubottu> Launchpad bug 912431 in grub-installer (Ubuntu) "Preseeded 12.04 grub-install failed: Wrong number of args: mapdevfs <path>" [High,Confirmed] https://launchpad.net/bugs/912431
<smoser> slangasek, cjwatson ? i'm sure one of you know.
<smoser> we're hoping to do work on juju doing installs via cobbler during the rally, and this is currently broken
<broder> smoser: i think it's in debian-installer-utils
<broder> (source package0
<broder> )
<smoser> broder, you are correct of course. thank you.
<pitti> slangasek: no, I haven't seen it myself either
<pitti> Good morning
<cjwatson> smoser: I will deal with your bug today
<cjwatson> smoser: oh, you've already submitted an MP, cool
<Laney> Riddell: Can you fix ~kubuntu-dev to have ~developer-membership-board as owner or admin please?
<micahg> pitti: can you please copy firefox,mozvoikko,ubufox from {natty,oneiric}-proposed (bug 906389) to {natty-oneiric}-security
<ubottu> Launchpad bug 906389 in ubufox (Ubuntu Oneiric) "Tracking bug for Firefox 9 (9.0.1) transition in Natty/Oneiric" [High,Fix committed] https://launchpad.net/bugs/906389
<pitti> micahg: sure, copying to -updates as well
<micahg> pitti: yep, that's fine :)
<pitti> micahg: all done
<micahg> pitti: thanks
<chrisccoulson> yay \o/
<chrisccoulson> now we're only 3.5 weeks until the firefox 10 release ;)
<micahg> chrisccoulson: we're still ahead of Mozilla pushing out to everyone :)
<chrisccoulson> heh
<chrisccoulson> and, 3.5 weeks to fix this KDE patch!
<chrisccoulson> g'ah
<chrisccoulson> it's way too late in the beta cycle to be making significant code changes
<micahg> I'm hoping we'll have an upstream powerpc FTBFS fix by then
<chrisccoulson> if we care about it, then we should just fix it rather than waiting for somebody else to do it ;)
<micahg> glandium was working on it, I'll check in with him next week (he had a partial fix, but something was wrong), I filed a tracking bug for it
<sveinse> I'm here because I don't know where else to ask. I hope it not OT:
<sveinse> I'm trying to apt-get into a staging directory (on a Ubuntu system). I've used the apt config option RootDir to prefix into the staging dir. Then I run apt-get update. It downloads the indexes to the staging dir, however it fails at the end as it tries to access /var/lib/dpkg/lock without the staging dir prefix. Bug?
<sveinse> On a Natty system, sorry
<seb128> cjwatson, hey, is the .maintscript use documented somewhere?
<seb128> i.e the format of the files, the version of dpkg needed, the pre-depends stuff etc?
<seb128> somewhere like in a manpage or a wiki, I keep looking for examples on my disk every time I set one, I didn't find a reference documentation
<cjwatson> seb128: Pre-Depends documented in dpkg-maintscript-helper(1), file format documented in dh_installdeb(1)
<sveinse> When strace-ing the apt-get, I see that it uses the proper stage dir prefix as setup in the config, except at the end where it tries to access the host's dpkg lock file.
<cjwatson> and in fact the latter documents the substvar needed so that you don't need to know the precise pre-depends version
<seb128> cjwatson, ok thanks
<pitti> jibel: is bug 911813 covered by the daily auto-upgrade tests?
<ubottu> Launchpad bug 911813 in gdm (Ubuntu Precise) "Lucid to Precise: debconf prompt about which DM to use during upgrade" [Medium,In progress] https://launchpad.net/bugs/911813
<pitti> jibel: I think I know what's wrong, but as it takes ages to reproduce, could we just wait for the next auto-run to verify?
<pitti> The fix I'm doing is necessary anyway, I'm just only 90% sufe it's sufficient
<pitti> "sure"
<pitti> jibel: ah, and it's a race condition, too; if gdm gets configured before lightm, it happens, otherwise not
<jibel> pitti, no, the test didn't discovered it. It's on my todo to find why.
<pitti> jibel: might just have been lucky, it's a race condition
<jibel> pitti, very lucky then because I reproduced it more than once.
<mdeslaur> cyphermox: happy new year: 912758
<krinetic> just filed bug#912818
<smoser> bug 912818
<ubottu> Launchpad bug 912818 in Ubuntu "Mute/unmute keyboard button does not work properly" [Undecided,New] https://launchpad.net/bugs/912818
<krinetic> changed it to affect gnome-settings-daemon
<bdmurray> pitti: might bug 911834 be related to bug 905602?
<ubottu> Error: Launchpad bug 911834 could not be found
<ubottu> Launchpad bug 905602 in pygobject (Ubuntu Precise) "software-properties-gtk crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Fix released] https://launchpad.net/bugs/905602
<pitti> bdmurray: at first sight it's a different problem; maybe over three corners
<pitti> bdmurray: I'll follow up with a question
<bdmurray> pitti: are there likely to be lots of dupes of 905602 though?
<pitti> bdmurray: asked and sub'ed
<pitti> bdmurray: I did a bug search for _decode_value, not that many actually
<pitti> most of them duped themselves through apport
<bdmurray> pitti: ah, great.
<pitti> good night everyone, see you in Budapest!
<SpamapS> you know what is *blatantly* missing from https://wiki.ubuntu.com/UbuntuMainInclusionRequirements  ? *documentation*
<psusi> cjwatson: say, at what point do you think Ubuntu should drop grub-legacy?
<cjwatson> psusi: I'm in no rush
<psusi> why not?  grub2 has been in since hardy... ;)
<cjwatson> there are still enough corner cases of one kind or another; I don't see a need to deliberately break them
<ogra_> we should drop it as soon as we drop lilo ;)
<psusi> hrm... is there a list of them so that grub2 can be fixed to handle them?
<psusi> well, lilo still has upstream support doesn't it?  so that's just a matter of preference
<cjwatson> not coherently.  xen support is a big one, which I know is in the works
<cjwatson> but there are probably various odd bugs
<psusi> xen support?  what's wrong there?  I thought we recently got a xen package that you just install and it sets up grub2 to load the xen hypervisor as the kernel and the kernel and initrd as modules and off it goes?
<cjwatson> grub2 doesn't have any xen support
<cjwatson> as in guest
<cjwatson> I'm not talking about the hypervisor
<psusi> I thought the guest didn't use grub... that the xen tools just loaded the kernel and initrd directly
<cjwatson> pvgrub
<psusi> ohh... hrm... interesting...
<cjwatson> hence e.g. grub-legacy-ec2
<cjwatson> anyway, I don't see any reason to rush.  It takes negligible amounts of my time to maintain and it's no longer the default so it shouldn't get in people's way particularly
<cjwatson> "maintain" i.e. leave alone and occasionally fix build bugs or whatever
 * psusi wants to whack the bug list ;)
<cjwatson> they aren't hurting anyone
<psusi> cjwatson: which partman package deals with copying partitions?
<cjwatson> partman-partitioning has the UI for it; the actual copy is done by a COPY_PARTITION command to parted_server (in partman-base) which is mostly implemented in libparted
<cjwatson> (whether that works in libparted 3 I don't know)
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<infinity> I knew I forgot something today.
<slangasek> jodh: bug #912558> maybe it's noteworthy that in his screenshot before the crash, he's getting a lot of spam from udev due to a broken rule in /etc/udev/rules.d?
<ubottu> Launchpad bug 912558 in upstart (Ubuntu Precise) "log.c Assert failed - err=>number == EIO" [High,Confirmed] https://launchpad.net/bugs/912558
<jodh> slangasek: can you point me at the screenshot you're looking at as the one on that bug doesn't mention udev (?)
<jodh> slangasek: the good news is that daviey and I have -- we believe -- just identified the problem causing the assert failure :)
<slangasek> jodh: ah, what's the problem?
<slangasek> jodh: the one showing udev is this: http://bootie.daviey.com/~dave/erk/precise-init-crash.jpg
<slangasek> apparently Daviey trimmed the context when posting to the bug!  Bad bug submitter! :)
<jodh> slangasek: that seriously hurts my eyes :)
<jodh> slangasek: if upstart attempts to run a single-line *non-existent* command with no shell meta-characters in it, the assertion fires.
 * slangasek blinks
<slangasek> how specific!
<slangasek> so he has some non-standard job on his system that's triggering it?
<jodh> slangasek: yeah!
<slangasek> oh, because that's tied in with getting a different return value from exec(), right
<jodh> slangasek: I have a fix for it but it'll need atleast 1 new build test and 1 new runtime test (so prolly tomorrow).
<slangasek> ok
<jodh> slangasek: yes, so the child process fails in that specific instance and the io watch therefore has an invalid fd to watch, hence the follow-on "bad file descriptor" error.
 * slangasek nods
<jodh> slangasek: so, you hit this bug if you've removed a package but the .conf files persist, as they refer to non-existent binaries.
<jodh> slangasek: I'll update the bug with this and a script folks can run to convince me I've fully understood the problem.
<SpamapS> jodh: nice work finding it (and hiding from your arch-nemesis, jhunt ;)
<jodh> SpamapS: thanks. Yeah, he shadows me everywhere. Keep catching glimpses of him in the mirror... He *so* needs a haircut.
<dupondje> Its still planned to removed vinage & rdesktop and switch to remmina & freerdp ?
<SpamapS> does anyone else get a nice warm fuzzy when they turn on the test suite for a package build? Like.. you have suddenly done the security team and the users a nice big favor that you didn't have to? ;-)
<kees> +1
<SpamapS> now if only java test suites didn't take *days* to run. :-P
<chrisccoulson> it's ok until the tests start hanging your builds ;)
<SpamapS> yeah I think ZK's test suite may literally take days to run on arm. :-P
<lifeless> SpamapS: you need a beowulf cluster of armhf then, obviously
<SpamapS> lifeless: btw, we still can't triage bugs in the server team. :(
<lifeless> SpamapS: the bug is still open and escalated, yes ?
<SpamapS> lifeless: yes
<lifeless> good good
<SpamapS> I know there's nothing more we can do.. but.. SQL fail is so painful to see. :-P
<jdstrand> SpamapS: every time :)
<SpamapS> 60% of the time, it fails, every time
<jdstrand> I was responding to the good feeling
<jdstrand> :)
<SpamapS> ah good
<SpamapS>     [junit] Running org.apache.zookeeper.test.QuorumTest
<SpamapS>     [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 185.082 sec
<SpamapS> paging performance? performance? no, sit down java
#ubuntu-devel 2012-01-07
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<lifeless> bryce: oh, and freedesktop.org watches are borked too ><
<Sarvatt> lifeless: fdo bugzilla has been up and down all night if its recent, they're moving servers
<lifeless> Sarvatt: not recent
<lifeless> Sarvatt: another gem hidden in the lp bugtracker
<raju> hello i have a samsung mobile , am i able to install Ubuntu in that ?
<stgraber> pitti: just saw you uploaded a new calibre, cool! Now with the new wxwidgets2.8 I just uploaded, I should be able to install calibre and still be pycentral free ;)
<ogra_> isnt calibre a Qt app ?
<ogra_> at least it used to be
<stgraber> ogra_: oh, indeed, so that was another Edubuntu package that was depending on wxwidgets2.8. Calibre was bringing pysupport or pycentral in Edubuntu because of python-cherrypy3 which I converted a few days ago
<ogra_> ah
<Eren> debian maintainer's guide states that the package is installed temporarily under "debian/package" directory
<Eren> is it different in ubuntu?
<Eren> I've looked at the source of gtk+ package, and accordingly to *.install files, it's stated as "debian/install/shared/usr/share/... usr/share"
<tumbleweed> Eren: not different on ubuntu
<Eren> tumbleweed: is it specific to gtk+ then?
<tumbleweed> Eren: I don't know the gtk+ package, but I'm assuming it's using debian/install as a staging area, where most packages use debian/tmp as the staging area
<tumbleweed> when you build multiple binaries from one source package, you usually build into debian/tmp, and then use dh_install to move them into the binary package directories
<Eren> tumbleweed: thanks. When building packages, how is ubuntu different than ubuntu? I'm currently learning how to package *.deb and I would like to know how ubuntu is differentiated from debian in terms of package management
<Eren> ops, how is debian different than ubuntu* :)
<tumbleweed> Eren: there aren't any differences you need to worry about, yet
<Eren> tumbleweed: when should I worry?
<tumbleweed> when you run into them. But you almost certainly won't
<Eren> okie, thanks. I'll keeping debian maintainer's guide, and debian policy as main documents then
<tumbleweed> the biggest difference you are likely to run into is that ubuntu won't include the upstream changelog in the deb
<tumbleweed> (and only part of the debian/ubuntu changelog)
<Eren> tumbleweed: so, debian includes upstream chanlog in /usr/share/doc/<package>
<tumbleweed> yes
<jtaylor> doko: something is weird with python2.7
<jtaylor> python2.7-dev is now 10 times larger than before
<tumbleweed> looks like the 3 static libraries balooned
<jtaylor> can't tell I'm still downloading ._.
 * tumbleweed was just looking at the build log
<jtaylor> a forgot debc output is in there
<doko> that's the lto sections
<jtaylor> so its going to stay like this?
<jtaylor> omg python3 is now 18.7mb
<jtaylor> doko: is that static library /usr/lib/libpython3.2mu.a intentionally in python3 and not python3-dev?
<jtaylor> 3.2
<doko> jtaylor, no, will fix
<jtaylor> thx, my poor internet connection thanks you :)
<trism> Is it intentional that the debug version of dbus-daemon is being installed instead of the production version in both the dbus packages in oneiric and precise? (you can see the binary be installed once from build/bus then overwritten by build-debug/bus in the logs).
<trism> Moving --exec-prefix=/ from the common_configure_flags to the non-debug build flags in override_dh_auto_configure in debian/rules seems to fix it if it is a bug. Only noticed it because it was causing weird aborts in make check for the dbus-python code. (at a part that shouldn't be enabled in the production build)
<wyuka_> hi
<wyuka_> is there a page explaining how live installation actually works?
<wyuka_> in detail?
<infinity> wyuka_: What level of detail are you looking for?
<infinity> wyuka_: "Copy the read-only FS from the livecd to the target filesystem; run d-i components in target to configure it" is the short answer.
<infinity> wyuka_: Significantly more detail than that means documenting everything each d-i component can/does do, which I'm not sure is worth the effort.
<infinity> wyuka_: There's also the "remove some packages we don't want" phase, and optionally "install more packages than the livecd had installed".
#ubuntu-devel 2012-01-08
<l3on> whois mako
<l3on> mmm... doko is around ? :)
#ubuntu-devel 2012-12-31
<psusi> smoser, hey, remember the auto root fs resize on boot without an initramfs issue we discussed at uds last year?  the patches have finally made it into the kernel and back down into raring, and the partx patches have been merged into upstream util-linux
<psusi> jesus, I can't believe it's been a year...
 * infinity puzzles over why his laptop suddenly has decided to stop suspending.
<melodie> hello
<melodie> I have been looking at a bug report about lightdm not providing an automatic login in Live and after install, if I have got it well: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/797669 and all taken in charge by cjwatson - I thought I would come ask for some hints here, because now trying to customize an Ubuntu version, I meet with an issue which looks alike a lot
<ubottu> Ubuntu bug 797669 in user-setup (Ubuntu Oneiric) "No autologin on live session with lightdm" [High,Fix released]
<melodie> I try to create a version with some specific setups in an Openbox almost only desktop. I used the best I know to make a first test version, then a second one and I am looking for a fix for this issue I meet with
<melodie> the ubuntu bug 797669 refers to a former version of ubiquity, and I am working on a projet using Precise
<ubottu> Ubuntu bug 797669 in user-setup (Ubuntu Oneiric) "No autologin on live session with lightdm" [High,Fix released] https://launchpad.net/bugs/797669
<melodie> hi again
<melodie> good night
#ubuntu-devel 2013-01-01
<melodie> hello
<Bluefoxicy> echo "always" | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
<Bluefoxicy> ^^^ anyone experimented with this?
<Bluefoxicy> also transparent_hugepage=always on the kernel command line does the same thing
<penguin42> I've read of it but not tried - what are your experiences - I'm guessing somethings work well and some things go nuts?
<Bluefoxicy> it's called 'transparent' for a reason.
<Bluefoxicy> Redhat says their worst-case benchmark is 2.5% faster with THP enabled
<Bluefoxicy> http://www.linux-kvm.org/wiki/images/9/9e/2010-forum-thp.pdf
<Bluefoxicy> penguin42: this is from 2.6.28 btw
<Bluefoxicy> it's had time to mature.  :)  There were bugs in 2.6.28-rc1 that needed ironing out before release
<Bluefoxicy> haha what
<Bluefoxicy> THP makes KVM 2.6x faster
<Bluefoxicy> oh no, 20% faster ... it's 25% slower without THP in guest or host, but with EPT on (which is a different thing entirely) ... typical of RH, these graphs are deceptive and they are benching unrelated things.  (Embedded pagetables are AMD-V and VT-x)
<blami> which package contains keyboard layout indicator?
<melodie> blami, several packages do contain it : http://packages.ubuntu.com/search?keywords=keyboard+layout+indicator&searchon=all&suite=all&section=all
<melodie> choose your's ? :)
<melodie> how can I get zram to be loaded and zram-config started in a customized live cd ?
<penguin42> Bluefoxicy: Well I guess to some level they are attacking a similar problem; I think EPT makes pagetable wrangling cheaper/free, and THP just ends up using less of them
<melodie> knowing that /etc/init.d/zram-config is a symlink to /lib/init/upstart-job ?
<melodie> but that it is not managed in the jobs-admin program, nor is is taken in account with a "systemctl start zram-config" launched in the chroot ?
<Bluefoxicy> penguin42: i may be confusing NPT with EPT
<Bluefoxicy> melodie:  i'm still confused as to why zram isn't the swap device on ubuntu
<Bluefoxicy> melodie: https://github.com/bluefoxicy/zram-init
<Bluefoxicy> I don't have/didn't know about zram-config D:
<melodie> Bluefoxicy, I thank you I look
<Bluefoxicy> where did you get zram-config?
<melodie> in Synaptic
<melodie> I have a few questions : would your's replace zram-config ?
<melodie> would it be possible here: https://github.com/bluefoxicy/zram-init/blob/master/debian/etc/default/zswap to have 1/4 instead of 1/2 of the ram available for the block device ?
<melodie> this is the value I used to have, and which is better
<Bluefoxicy> yeah
<Bluefoxicy> https://github.com/bluefoxicy/zram-init/blob/master/debian/etc/init.d/zswap
<Bluefoxicy> i have good luck with fairly large values
<Bluefoxicy> KiB Mem:  15747100 total, 15238172 used,   508928 free,   155688 buffers
<Bluefoxicy> KiB Swap:  7873520 total,   122220 used,  7751300 free,  7294676 cached
<Bluefoxicy> granted i wrote this when I had 4096MB real RAM
<melodie> then in Archlinux which I also use, the script provided by the distro creates more than one block device when there are more than on cpu : I think it is a good idea, what do you think ?
<Bluefoxicy> that one multithrads
<Bluefoxicy> see line 99-116
<Bluefoxicy> linux will spread swapouts across devices; zram takes 1 thread per device, so you get parallel compression
<Bluefoxicy> where did you get zram-config, what package?
<Bluefoxicy> It's probably upstart-capable (mine isn't) and a better basis to start from for Ubuntu, adding any features it doesn't have (like cpu multi-thread awareness)
<melodie> zram-config is from Universe
<melodie> it is version 0.1
<Bluefoxicy> ah ok
<Bluefoxicy> that was simple
<melodie> what I don't understand yet is how come I can't have it working in the live : for it to work in live, when booting to live I first need to load the zram module (modprobe) then I need to start zram-config : either with service start or with initctl start zram-config
<Bluefoxicy> melodie: do you have zswap running right now?
<melodie> however I had changed the two scripts which I found and contained indications about it (I did a large grep to find out that) : the files are :
<Bluefoxicy> https://github.com/bluefoxicy/zram-init/blob/master/tools/zram_stat.sh this will show you how big compressed RAM is versus original size
<melodie> wait a sec, I explain at once
<Bluefoxicy> except it's buggy somehow
<melodie> I think in the installed version it is ok, just I can't get it to work in the live
<Bluefoxicy> still.  Seems to get down to about 25%-30% of original size on average (I've seen as high as 40%)
<melodie> the files I modified are this ones:
<Bluefoxicy> which is why I use a swap value of half as default
<melodie> http://meets.free.fr/debian/configurations/OBUbuntu-Zram-live.tar.xz
<Bluefoxicy> 2G takes up like 500-800MB of RAM tops, so you wind up with a 4G system that has 5.5G available
<melodie> I think zram being created for low resource machines and embedded systems, low should be better, in order perhaps not to take too much on the cpu for compressing and uncompressing. then it is possible to create up to 4 block devices according to the case : and a good idea would be to have a zram.conf file in /etc, where the people can adapt the size for the block device and number block devices
<Bluefoxicy> it only takes CPU for what's being compressed
<melodie> I wonder if there is not one working like that in a debian spin...
<Bluefoxicy> i.e. you can't really make the situation worse :P
<melodie> Bluefoxicy, I said perhaps, I was not sure
<Bluefoxicy> like high-resource systems benefit a lot more from zswap than low-resource systems
<melodie> according to the experience I have had with it, both is equally true
<melodie> in the paste times I had created a spin with openbox and a few light programs of another distro, with less programms in it, just minimal, and one guy decided to try install it on a machine with 128 MB ram:
<melodie> next thing, when we added zram, he was able to install it to the low ram machine without creating a swap file prior (the installer is a gui) whereas before he couldn't go without creating a swap file
<Bluefoxicy> yeah
<Bluefoxicy> I've been arguing this should be a default configuration for a decade
<melodie> I do agree
<melodie> I have sent a mail to nitin gupta once, on his mailing list and one was why is it still in the staging directory of the kernel tree, when it has been used for many years now and didn't find any trouble with it ? he said that it was mainly due to... his lazyness and lack of time !
<melodie> he also said something about a fellow module related to memory which was going to be replaced by another one on which zram would rely, but after looking for it in the new kernel versions, I never found this new version of the memory cache module
<melodie> Bluefoxicy, the problem I met with the zram-config from the repos might well be that it is an upstart job
<melodie> in antix I had used a classic init script, this one:
<melodie> http://pastebin.com/FALaHEXU
<melodie> presented and tested formerly here : http://antix.freeforums.org/post25708.html#p25708
<melodie> and that one was ok in the Live Antix when booted.
<melodie> I am interested to know what you think about it ?
<Bluefoxicy> on ubuntu, upstart jobs are superior
<Bluefoxicy> fedora/rhel7 systemd, debian undecided but currently seems to use a dependency-based sysvinit?
<Bluefoxicy> gentoo is still ahead of its time even over a decade later, with named runlevels and dependency-based init.
<melodie> debian I am not sure, I think it might depend on which debian version and latest antix use Debian testing as repos but their own made core with added scripts in /usr/local/bin
<melodie> gentoo leaves it's users free to use either or systemd or sysvinit
<melodie> and Ubuntu precise still has both if I understand things : I can see in the /etc/init.d some scripts, and also some symlinks to upstart-jobs
<Bluefoxicy> systemd is honestly a fantastic piece of software, but Canonical is the second coming of Redhat and will never get over their NIH
<melodie> what is NIH ?
<melodie> my mother tongue is not English. :)
<Bluefoxicy> (granted, bzr is fantastic and the whole world rushed to git because the first iteration of bzr was crap and the impression stuck)
<Bluefoxicy> Not Invented Here
<melodie> oh, ok
<Bluefoxicy> it's when a person or team makes their own stuff despite all alternatives and regardless of any merit or demand patterns.
<melodie> well whatever method, as long as we can get things going the way we would like them to...
<melodie> it seems to me that Upstart was implemented before systemd came out ? or did I miss something ?
<Bluefoxicy> the most blatant example is Redhat, especially in the case of Ulrich Drepper and the PT_GNU_HASH feature of gcc and glibc
<melodie> ?
<Bluefoxicy> in which case, unable to actually come up with something better or just-as-good, after a discussion on a public mailing list Drepper re-posted Michael Meeks' patch with a few bits moved around, and claimed he wrote it from scratch, and that there was some discussion with Meeks but nothing came of that
<Bluefoxicy> (Meeks posted a completely working patch with benchmarks and test examples; the whole thing was his idea and he wrote all the gcc and glibc code)
<melodie> so he robbed the guy idea, but that is a "person" problem, ego and such ?
<Bluefoxicy> Yeah I don't like redhat or their developers.
<penguin42> well, eglibc/glibc has merged and I assume solved that problem
<penguin42> Bluefoxicy: Most of them are OK
<melodie> Bluefoxicy, I think in all communities some people are better than others, I would not blame a community in particular
<melodie> better techs as well as better persons as human beings caring for others
<Bluefoxicy> penguin42: http://sourceware.org/ml/libc-alpha/2006-06/msg00095.html this is 'that problem'
<ubottu> sourceware.org bug 2006 in kprobes "Incorrect nmissed count for multiprobes" [Normal,Resolved: fixed]
<Bluefoxicy> lol
<Bluefoxicy> anyway
<melodie> Bluefoxicy, about zram-config, I am still interested to find how to start it in live. have u had the time to look at the  files I pointed to a bit earlier ?
<Bluefoxicy> nah I've never built a live cd
<melodie> and who would have knowledge about the way Casper works, and could help me ?
<melodie> hi gilir
<melodie> I am struggling with a few things in the project...
<gilir> hi melodie
<melodie> :)
<melodie> are you very busy now ?
<melodie> Bluefoxicy, ?
<melodie> I just found out what caused zram not to be started in the Live in spite of the configurations I had done : do you want to know ? :)
<Bluefoxicy> sure
<melodie> a file in the initramfs-tools : initrd/scripts/init-top/compcache
<melodie> it contains an instruction TO NOT load zram in Live CD's if the machine has 512 MB and above
<Bluefoxicy> well that's silly.
<melodie> the comment says:
<Bluefoxicy> zram doesn't do anything until something's swapped onto it.  It's a no-op until performance would start lagging out.
<melodie> yes, it's strange... the maintainer of this package is the Ubuntu Kernel Team
<melodie> while original maintainer used to be Debian kernel team
<melodie> Bluefoxicy, I agree with you.
<melodie> I think I will comment this part out for the next test version I will do. by any hazard, is it likely that you might be interested in a spin easy to use with Openbox as main "desktop" ?
<Bluefoxicy> gnome-shell
<melodie> ok
<Bluefoxicy> don't need a new livecd here.  The only thing interesting to me in practice is automated install and slipstreaming updates.
<melodie> what is slipstreaming ?
<Bluefoxicy> building a release with all the updates run
<Bluefoxicy> so it's up to date on install
<Bluefoxicy> the install-then-patch cycle is silly
<melodie> are you saying that you would update versions and republish updated versions ? Or do you mean something else ?
<Bluefoxicy> rather have a script that regenerates the current ubuntu-desktop release CD with all packages from updates
<Bluefoxicy> that way I can just pop out a CD ISO at will all up-to-date
<Bluefoxicy> (honestly, I'd rather just have *the* build system the developers use to produce the release CDs, complete with example release file that produces the original release CD, with a configuration that can be modified to change packages and install them from other repos--particularly updates for up-to-date install media.  Also, preseed)
<Bluefoxicy> which is probably in the repo somewhere
<Bluefoxicy> i just haven't found it yet.
<melodie> Bluefoxicy, if it is just to have an up to date version, a build script fit to customize an iso should be enough ?
<micahg> is python-config --includes an upstreamable way of fixing the various python can't find headers issues or is there a better way?
#ubuntu-devel 2013-01-02
<tjaalton> infinity: lo and behold, I got the gpu hung on my t420s after using it for an hour :)
<RAOF> VT-d claims another victim?
<tjaalton> not sure
<tjaalton> also, xorg resumed after a while, so it wasn't a fatal hang
<tjaalton> i mean, not sure if I have vt-d on or not
<tjaalton> so, apport doesn't open the lp bug submission page anymore?
<tjaalton> no wonder we only have a handful of xorg bugs on raring :)
<sil2100> Hello!
<sil2100> Is there anyone here who could sponsor a precise unity-2d release for me?
<sil2100> It's a re-release of a rejected one, with the offending commit removed
<sil2100> Since this version of unity-2d is already waiting for release over 5 months
<xnox> sil2100: I don't see unity-2d in http://reqorts.qa.ubuntu.com/reports/sponsoring/ . Where is the source package? =)
<sil2100> xnox: in lp:unity-2d ;)
<xnox> ah =)
<sil2100> xnox: ah, sponsoring bug!
<sil2100> There was one for the rejected version, maybe I could re-use that one ;p
<sil2100> https://bugs.launchpad.net/unity-2d/+bug/1060262 <- you think I could simply change it back to 'Fix Committed' in Precise?
<ubottu> Ubuntu bug 1060262 in unity-2d "Unity-2D SRU-1 needs releasing" [Medium,Fix committed]
<zykes-> what's the stuff in Contents-<arch>.gz made of ?
<cjwatson> it's apt-ftparchive's own format
<zykes-> is it required for repositories?
<cjwatson> zykes-: no
<zykes-> cjwatson: is there a thing that can generate it besides apt-ftparchive ?
<zykes-> like python-debian?
<cjwatson> Not AFAIK
<cjwatson> There are a few parsers around but I don't think any of them are in library form: I can think of apt-file, auto-apt, and http://anonscm.debian.org/gitweb/?p=webwml/packages.git
<zykes-> cjwatson: i'm creating a integration for .deb for Pulp, how does one generate the content stuff ?
<cjwatson> apt-ftparchive contents
<zykes-> :q
<cjwatson> Or it's not that complex, if you have some different needs just do it by hand
<menace> reprepro or dpkg-scanpackages perhaps? :)
<zykes-> but what info does it use ?
<zykes-> reprepo doesn't do it menace ..
<cjwatson> dpkg -c
<cjwatson> basically.  Please read the source :)
<cjwatson> apt/ftparchive/contents.cc
<cjwatson> I think it was originally intended just for human consumption / casual grepping and only later retconned into something tools might want to parse properly
<cjwatson> so it's not the tidiest of formats
<zykes-> darn :O
<tjaalton> someone rejected my sssd upload to precise-proposed last friday, without leaving any note on the bugs it was supposed to fix
<geser> does somebody know if the "python-config" script is official? can it be used to detect Python configure flags in upstream configure scripts?
<jtaylor> why would you need those?
<geser> fixing the vim FTBFS in raring
<xnox> geser: yes.
<geser> vim does some own detection of the Python config dir, include directories and fails now that libpython-dev is multi-arched
<jtaylor> that can be done without python-config
<jtaylor> get_python_inc(plat_specific=True)
<jtaylor> sys.
<jtaylor> which is definetely official since 2.4
<xnox> python-config, pkg-config, or query plat_specific=True are the 3 ways to get include paths you want.
<doko> geser: it's upstream, except for the --configdir option in 2.7
<cody-somerville> vanhoof: Happy Birthday! :)
<rickspencer3> infinity, do you have a link to the archive probs page for raring?
<geser> SpamapS: if you want to review/sponsor bug #1095320 it will fix the vim FTBFS from your last upload
<ubottu> bug 1095320 in vim (Ubuntu) "FTBFS with multi-arched Python" [Undecided,New] https://launchpad.net/bugs/1095320
<cjwatson> rickspencer3: http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html - that one?
<rickspencer3> hey cjwatson that's the one!
<rickspencer3> thanks
<rickspencer3> and always nice to see beer there :)
<rickspencer3> cjwatson, I kind of pair that page with this one:
<rickspencer3> http://reports.qa.ubuntu.com/smoke/raring/
<rickspencer3> to get a sense of how daily quality is going
<rickspencer3> (fwiw)
 * cjwatson nods
<SpamapS> geser: ACK, looking now
<doko> http://wiki.debian.org/Python/MultiArch
<micahg> thanks, that's what I was looking for
<micahg> doko: are there usertags associated with python multiarch bugs?
<doko> micahg, no, not yet. but I would use debian-python@ and multiarch
<doko> I think we used that for 3.3
<micahg> ok, thanks
<hallyn> SpamapS: infinity: could someone pls accept the precise-proposed unapproved upload of qemu-kvm 1.0+noroms-0ubuntu14.6 ?  (sorry to bug you, but im not sure now who it is appropriate to ping)
<infinity> hallyn: Looking.
<hallyn> (back in awhile)
<infinity> hallyn: Accepted (and built).
<hallyn> infinity: thanks!  now to finally verify that beast
<infinity> geser: Thanks for the vim/python fixes.  Did you forward those to Debian as well?
<geser> infinity: I mailed my patch for review to vim's DD
<infinity> geser: Yay, thanks.
<gotwig> Can I distribute my scope and lenses that I've develop for Ubuntu, for Ubuntu for phones?
<RzR> hi
<RzR> is there a hidden #ubuntu-mobile place somewhere ?
<Pici> If you're looking for somewhere to talk about the announcement, #ubuntu-discuss is the place.
<RzR> Pici, thx let's head over there
<RzR> btw i already run ubuntu on my phone :)
<adam_g> if a package is accepted into, say, quantal-proposed and no branch exists at lp:ubuntu/quantal-proposed/$pkg, how does one get created?
<dobey> adam_g: the branch importer magic scripts do it
<adam_g> dobey: any common reasons why that would not happen? still waiting on a couple of branches to show up for stuff that was accepted last week
<cjwatson> the branch import scripts can be a bit wobbly - TBH I find it best to ignore them for SRUs as the workflow doesn't work all that well there
<dobey> cjwatson: seems to work fine for me; at least for raring it will be easier to deal with since everything already has a -proposed
<cjwatson> dobey: as a sponsor it's much more of a pain than for dev
<dobey> cjwatson: more of a pain if people propose branches, rather than uploading with dput?
<sivang> hi all
<cjwatson> are they actually working properly for raring?  I'd seen some rumours of brokenness but haven't really looked
<cjwatson> dobey: rather than attaching patches
<sivang> is ubntu superphone open source and accepting contributors just like other ubuntu projects?
<cjwatson> because then I don't have to faff around with faking the branch status as merged
<sivang> I have some deb packaging experience from ancient times..;)
<dobey> oh, the middleman case. i suppose that's frustrating no matter what though :)
 * sivang hi's some familiar faces, g'evning cjwatson :)
<jhansonxi> Does apt assume that mirror:// is http?  Is it possible for mirror:// to be a local file (not require a web server)?
<sarnold> jhansonxi: there's some kind of funky cd-rom-based apt lines, those may be more amenable to local file storage (this is a wild guess)
<jhansonxi> sarnold: I'm specifically referring to automatic mirror fail-over: http://mvogt.wordpress.com/2011/03/21/the-apt-mirror-method/
<jhansonxi> I'm trying to come up with a way to deal with potential connectivity problems with the server the mirror list is located on.
<jhansonxi> Also for repos that don't have a mirror list (like getdeb.net which has been down for a month).
<sarnold> jhansonxi: oh, that's more clever than I expected. :)
<hallyn> slangasek: adam_g is running into bug 1092715.  i'm tempted to submit an emergency revert for q and r to go back to manually fixing up the /dev/kvm perms
<ubottu> bug 1092715 in udev (Ubuntu) "udevadm trigger --action=change not working since quantal?" [Undecided,New] https://launchpad.net/bugs/1092715
<hallyn> marked it confirmed based on adam_g's sighting
<slangasek> hallyn: why does it need an emergency revert?  I thought the previous version of the package didn't work either?
<slangasek> (particularly the quantal one)
<hallyn> the original version didn't.  the previous version did (which manually did setfacl)
<slangasek> I don't believe there was a previous SRUed version
<hallyn> previous version pushed to -proposed (which you rejected) that is :0
<hallyn> right
<slangasek> right, so there's no need for an "emergency revert" AFAICS
<hallyn> cool :)
<slangasek> however, if you want to submit a (calm, non-emergency :) SRU that does the fix-up by hand like you originally proposed, I think that's acceptable here while we figure out what's wrong with udevadm.
<hallyn> adam_g: ^ is that needed for you?  SRu's are slow enough I'd just as soon spend my time looking into the udevamd bug...
<adam_g> hallyn: yea. i'm trying to get verification done for some other SRUs that are consumers of qemu. i can work around it in the meantime, assuming thats kosher wrt verification process.
<slangasek> adam_g: will those consumers break at install time without the qemu fix, or will they just have the same problem that qemu itself does (have to reboot or manually apply acl to use it)?
<adam_g> slangasek: the latter
<slangasek> adam_g: in that case I think it's fine to apply whatever workaround is needed during the verification
#ubuntu-devel 2013-01-03
<caligari> good night people
<caligari> I dont know if this is the right channel: I can't download packages from http://ppa.launchpad.net/ui-toolkit
<caligari> There is some kind of problem with server (QML toolkit): 404 not found
<TheLordOfTime> the 404 suggests there's not packages
<TheLordOfTime> forgive me for asking, caligari, but which ubuntu are you on?
<TheLordOfTime> (which release)
<TheLordOfTime> (or are you on dev :P)
<caligari> precise
<TheLordOfTime> caligari, the PPA you mention, is it this one?  https://launchpad.net/~ui-toolkit/+archive/ppa
<caligari> it is the qml toolkit preview: http://developer.ubuntu.com/get-started/gomobile/
<caligari> sudo add-apt-repository ppa:ui-toolkit/ppa
<TheLordOfTime> ppa:ui-toolkit/ppa  -> translates to the PPA I linked.
<TheLordOfTime> caligari, that PPA only publishes for Quantal
<caligari> OMG! :(
<TheLordOfTime> https://launchpad.net/~ui-toolkit/+archive/ppa/+packages  <-- you'll see only Quantal stuff on that list
<TheLordOfTime> it may be a good idea to make a note of that on the site, devs ;)
<caligari> thank you for assist me :)
 * TheLordOfTime returns to bug triaging
<caligari> yes it is a good idea ;)
<ryao> Is the source code for Ubuntu for phones available?
<nrosvall> I know this might not be the right channel to ask this, but as I asked on another channel: [10:51] <nrosvall> I'm a long time Windows developer and I'm just about to start developing an application for Ubuntu. Now with this new Ubuntu Phone and coming Ubuntu sdk. Is it still recommened to use gtk and python as mentioned in developer.ubuntu.com? Or should I go for c++ and qt? Or is it just
<nrosvall> too early to think about the phone?
<andyrock> nrosvall, i'd go with c++/qt/qml
<andyrock> ;)
<nrosvall> I think I will yes
<Tm_T> nrosvall: go with c++/qt/qml and you do cross-platform (:
<nrosvall> mm true
<tjaalton> so, how do I figure out who to discuss with the rejection of an upload to -proposed?
<xnox> tjaalton: which upload? and usually they all hang out on #-release
<tjaalton> xnox: sssd to precise-proposed
<tjaalton> got rejected last friday
<tjaalton> joined -release, we can disuss it there
<xnox> tjaalton: the only nit-picking i can spot, is absence of matching quantal SRU for  the two bugs affecting it.
<tjaalton> xnox: ok, I guess it got rejected due to the new upstream version, bugfix or not
<xnox> tjaalton: well, are all changes present documented in the bugs? you can open an extra bug "remaining changes in this micropoint release"
<tjaalton> xnox: that's bug 1086304
<ubottu> bug 1086304 in sssd (Ubuntu Precise) "new upstream bugfix release from the LTM branch" [High,In progress] https://launchpad.net/bugs/1086304
<tjaalton> which should explain the rest of the diff
<xnox> awesome.
<xnox> infinity: based on my logs, was it you who rejected sssd on 28th of December? ^
<tjaalton> I'll prepare the update to quantal
<tjaalton> xnox: now I noticed that the changelog didn't mention the meta-bug.. my bad
<hrw> hi
<sourav> hi all, any idea when it will be available
<cjwatson> "it" is a bit vague but I suspect you want #ubuntu-phone
<sourav> thanks
<hrw> doko: I took a look at 'cameleon' ftfbs. With rebuild of 'lablgtk-extras' and installing resulting packages it started building
<hrw> doko: but as I have no idea on ocalm stuff I prefer to not do upload to force such rebuild
<sonne> greetings! is this the right place to ask about packaging for ppas?
<geser> #ubuntu-packaging would be better
<hrw> doko:  dpkg-source --after-build cameleon-1.9.21
<hrw> doko: so it built.
<sonne> geser, cheers :)
<xnox> hrw: sounds correct: http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html
<micahg> jdstrand: mind if I upload the newer version of icedtea-web (you're TIL)
<jdstrand> micahg: hey, I don't really have any context (also, what is TIL? :)
<micahg> jdstrand: Touched It Last
<jdstrand> ah
<jdstrand> micahg: in raring? feel free :)
<micahg> yeah :)
<jdstrand> micahg: and thank you :)
<micahg> jdstrand: sure
<micahg> doko: for icedtea-web, is there a reason why default-jdk isn't used instead of openjdk-6-jdk?  in raring, the current packaging produces a JRE headless 7 with JDK 6, switching to default-jdk gives version 7 of both
<apw> doko, fyi the linux build on armhf in your rebuild archive blew an internal compiler error
<ara> Hello!
<zyga> http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-amd64.manifest
<ara> daily images for 12.04.2 contain the 3.5 kernel in the amd64, but 3.2 kernel in the i386 one
<zyga> http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-i386.manifest
<zyga> :-)
<cjwatson> please wait, dealing with something else
<hrw> btw - would be nice to give linux-image-virtual update for linux-lts-quantal so it will switch to -generic
<hrw> Bug #1095710
<ubottu> bug 1095710 in linux-lts-quantal (Ubuntu) "update-grub-legacy-ec2 does not consider 3.5.0-generic as valid for Xen" [Undecided,New] https://launchpad.net/bugs/1095710
<bdmurray> barry: at one point in time you were looking at bug 915626 - there is now some additional information which has helped in recreating the issue.
<ubottu> bug 915626 in usb-creator (Ubuntu Quantal) "usb-creator-gtk crashed with SIGSEGV" [High,Triaged] https://launchpad.net/bugs/915626
<bdmurray> cyphermox: there are some comments in bug 780602 regarding 12.10 users being affected.
<ubottu> bug 780602 in OEM Priority Project precise "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602
<cyphermox> aye
<hallyn> mahmoh: are you around?
<hallyn> mahmoh: well, i'm hoping you can pursuade infinity that if he accepts https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=seabios  into lucid-proposed you can verify bug 589063 right quick
<ubottu> bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Triaged] https://launchpad.net/bugs/589063
<darkxst> Sarvatt, are you able to have a look at my merge request for ppa-purge?
#ubuntu-devel 2013-01-04
<mandrig> If I were looking for resources on beginning to develop for Ubuntu, where should I look? Thanks!
<mspencer_> Hi, I was working on a bug fix (LP #657275) a while ago but haven't had time to test it until now.  Apport has been updated since then so now my fix is in an older version. What do I need to do to get it into the current version of Apport?
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
<sarnold> mandrig: I'd start skimming here: http://developer.ubuntu.com/packaging/html/
<mandrig> sarnold: thank you
<sarnold> mspencer_: at the least, try it on a new version of apport :)
<mspencer_> sarnold: By copying all the changes into the new version of the code?
<sarnold> mspencer_: yes, making sure to adjust them if necessary
<mspencer_> sarnold: Okay, thanks.
<mandrig> Is there a known delay for Launchpad to be able to verify PGP keys? I'm trying to attach my key to my Launchpad account, and LP keeps telling me there's an issue with my key.
<TheLordOfTime> mandrig, about 15 - 30 minutes i think.
<TheLordOfTime> before LP will recognize it on the PGP keyservers
<mandrig> Thank you TheLordOfTime, I figured there was a propogation delay or something :)
<TheLordOfTime> yeah, its not usually long though, i've seen it work in 5 minutes before, but i'd give it up to 30 just in case things're being slowish
<pitti_> Good morning
<Mirv> there looks to be a big spike at errors.ubuntu.com for gnome-control-center & update-manager that wasn't there yesterday
<Mirv> for precise, and precise at least just had some gcc update?
<infinity> xnox: How do you feel about addressing jdstrand's compiler warning concernes in bug #1077484 so we can finish up the MIR mess for shadow?
<ubottu> bug 1077484 in cunit (Ubuntu) "[MIR] libsemanage (shadow's rdep to continue SELinux support in shadow)" [Undecided,In progress] https://launchpad.net/bugs/1077484
<infinity> xnox: Comment number 8.
<doko> tjaalton, please consider to use llvm-3.2 instead of 3.1 for mesa
<tjaalton> doko: in raring? sure
<doko> tjaalton, yes, thanks
<tjaalton> does debian-experimental have it too?
<tjaalton> sid does
<tjaalton> that's enough
<xnox> tjaalton: for bug 1068404, you invalidated the bug in comment #62. There are a few patches proposed to be merged, but i am not convinced it is or isn't cherrypicks from upstream.
<ubottu> bug 1068404 in xserver-xorg-video-intel (openSUSE) "Low graphics mode in Hybrid ATI/Intel GPU systems after fglrx upgrade" [Critical,In progress] https://launchpad.net/bugs/1068404
 * xnox ponders if 12.04.2 with quantal stack will have the same problem or not.
<tjaalton> xnox: I'll check it again. maybe we should revert the change after all
<xnox> tjaalton: ack. It's best if you look at what upstream actually did, as comments #102 & #105 indicate that xorg-edgers ppa may or may not be fixed already.
<tjaalton> xnox: upstream just commented that it's safe to revert for now, but in future more will get removed. hope fglrx is fixed by then
<tjaalton> xnox: assigned the bug to myself, you can remove sponsors from the subscribers
<tjaalton> and the review team
<tjaalton> heh, 42 proposed members on the review team
<xnox> unsubscribed sponsors, i am not in the review team, and we need TB member to set merge proposal for quantal as "work-in-progress"
<tjaalton> I'm not going to merge from bzr anyway ;)
<xnox> fair enough =)
<tjaalton> hum, can't join the sponsors team
<tjaalton> doko: unfortunately one of the mesa drivers doesn't build with 3.2 yet. there are patches for llvm & mesa to fix it though
<doko> tjaalton, do you have a pointer to the llvm patches?
<tjaalton> doko: searching..
<tjaalton> doko: http://cgit.freedesktop.org/~tstellar/llvm/ looks like it's a ton of changes..
<doko> tjaalton, could you file a debian bug? Sylvestre prefers it having there
<tjaalton> doko: sure
<doko> yeah for llvm not having release branches ...
<tjaalton> what's the bug topic?-)
<tjaalton> adding support for r600/si?
<doko> fix mesa ftbfs with llvm-3.2
<doko> ?
<tjaalton> ahh, right
<tjaalton> it doesn't even go past configure phase
<tjaalton> but anyway
<pitti> apw, ev: what's the status of https://code.launchpad.net/~ev/apport/kernel-oops-crash-signature/+merge/129440 ?
<ev> oh, andy was mentioning that he's not seeing them show up in production. Adding to my todo list
<ev> oh
<ev> it seems I lost track of this :)
<ev> apw: ^ would you mind providing some review on that
<apw> ev, looks good to me
<ev> cool, thanks
<apw> ev, there are bound to be problems with it, but till we get it sucking on some input we'll never notice, so i say apply it
<mitya57> happy new year everybody (once again)
<mitya57> is it possible to include new translations in SRUs?
<geser> pitti: Hi, do you have an idea why the installation of postgresql-common in pbuilder or PPA fails? "/usr/share/postgresql-common/supported-versions: 46: /usr/share/postgresql-common/supported-versions: DISTRO: parameter not set" (https://launchpadlibrarian.net/127277379/buildlog_ubuntu-raring-i386.postgresql-filedump_9.1.0-1_FAILEDTOBUILD.txt.gz)
<pitti> geser: yes I have
<pitti> geser: I fixed it in bzr yesterday; missing lsb-release dependency
<geser> ah
<pitti> geser: (I fixed it without the need for that dependency)
<pitti> but if you install that somehow (it's just a recommends), it'll work
<geser> I stumbled upon it while reviewing the archive test rebuild results
<Laney> Can someone tell why this source package build is failing with a failed patch application? http://paste.ubuntu.com/1495288
<Laney> You can see the patch in question applying correctly at the start, but then for some reason dpkg-source tries to apply it again and only one file in it fails ?!?!?!
<diwic> Laney, your skills are bigger than mine, but "*** No rule to make target `distclean'." might be a hint?
<diwic> Laney, a distclean should have unapplied the patches?
<ogra_> dh_clean should, no ?
<Laney> don't think so
<diwic> hmm, I'm trying here
<Laney> why does it pick that one in the middle of the series?
<Laney> which happens to be the one I just added
<diwic> just apt-get source
<diwic> Laney, which one did you add?
<Laney> add-pkgconfig-file
<diwic> could there be stray .pc directories?
<Laney> still happens if I quilt pop -a; rm -r .pc; debuild -S
<diwic> maybe it's some kind of bug related to .pc files in the actual patch too?
<diwic> or maybe I'm just shooting in the dark
<ogra_> i wonder what dh_autoreconf_clean does to Makefile.am ...
<cjwatson> I don't think it's picking one in the middle of the series - I think it suppresses output from applications that succeed
<geser> patch "import-camerabin" touches Makefile.am too
<cjwatson> I would tend to agree with ogra_ that some kind of interaction with dh_autoreconf_clean is likely to be at fault
<cjwatson> Make sure you quilt refreshed in a clean state (after dh_autoreconf_clean)
<Laney> dh_autoreconf hasn't been run in this tree
<cjwatson> Well, although thinking about it dh-autoreconf really shouldn't be touching Makefile.*am*
<Laney> so I doubt _clean is doing anything
<cjwatson> Only Makefile.in
<Laney> there's no fuzz with this patch
<cjwatson> So I don't know and need to run :)
<Laney> running the erroring command (after changing paths) works
 * Laney wibbles
<Laney> let me tar up the directory :-)
<Laney> oh, ffs
<Laney> so the answer was that I had accidently edited Makefile.am outside of the patch and inserted some whitespace
<diwic> ok :-)
<Laney> which quilt was happy patching as it was consistent within the directory
<Laney> but when applied on top of the orig.tar.xz it obviously fails
<ogra_> heh
<Laney> diffing with an unpacked copy of the archive's source package revealed that
<Laney> a "welcome back to work after a long holiday" problem
<tkamppeter> pitti, all works and I have also updated the GIT of CUPS.
<pitti> tkamppeter: nice!
<tkamppeter> pitti, can you upload the cups-filters to Debian, thanks.
<pitti> tkamppeter: yup, doing
<OdyX> ^ woot
<OdyX> tkamppeter: can you make your changelog entries less verbose ? Specifying all affected files for a split makes it unnecessarily verbose.
<tkamppeter> pitti, OdyX, the test failure in the Debian package of CUPS seems to be small, it one error message in error_log too much.
<OdyX> tkamppeter: ah nice.
<OdyX> tkamppeter: does it clean its print queues now ?
<pitti> tkamppeter: do we really need a new binary package for a 23 kB binary?
<pitti> tkamppeter: the three libavahi-common* depends are ~ 100 kB in total
<pitti> (i. e. the extra depends)
<pitti> tkamppeter: or is that for more easily uninstalling this feature? (but I thought ordinarily you would configure it off, not uninstall)
<OdyX> tkamppeter: also, you forgot to move the manpages
<melodie> hello, would someone know what Casper/Ubiquity uses to define the ubiquity-frontend-gtk background please ?
<xnox> melodie: the paths to backgrounds are hard-coded in ubiquity-dm, and a custom wallpaper binary is used to "paint" them in ubiquity mode. (The wallpaper picture in the background of ubiquity)
<xnox> in live-session mode - is done the same way as in final install.
<melodie> xnox, humm... how could I add a custom wallpaper binary in a customized version I am working on ?
<melodie> because for now it's plain black and somehow difficult to read. :D
<xnox> melodie: raring? wallpaper is broken in raring dailies.
<xnox> to replace background drop it here and it will be used: /usr/share/backgrounds/warty-final-ubuntu.png
<melodie> no it's Precise
<melodie> oh !
<xnox> or in ubiquity-dm look for backgrounds paths and you can modify it =)
<melodie> I'll have to look what the files installed by ubiquity-dm then : maybe I'll use the easy solution
<xnox> (yes default background is always called "warty", meh )
<melodie> let met see what this /usr/share/backgrounds/ png file looks like
<melodie> I don't mind the name, thanks
<tkamppeter> pitti, the separation of the CUPS daemon allows having the CUPS damon for only driverless printing, for example printing to remote CUPS queues. This is a scenario for mobile, like Ubuntu for Android.
<tkamppeter> OdyX.
<melodie> xnox, that's exiting !
<tkamppeter> OdyX. ^^
<melodie> xnox, thank you very much !
<xnox> np. =)
<melodie> here is a pic of what I am doing : http://meets.free.fr/debian/images/BoxBuntu.png
<pitti> tkamppeter: ah, so it's to avoid the cups-filters dependency, not the other way around
<tkamppeter> pitti, OdyX, one gets a 1MB (cups-damon + libcups2 + cups-browsed) printing stack. I have intendedly left all docs in the "cups" package to save space. The cupsd is started automatically anyway.
<pitti> tkamppeter: uploaded; will take a bit though as this has to get through Debian's NWE
<pitti> NEW
<tkamppeter> pitti, and to leave out CUPS' own heavy stuff like filters, backends, the web interface, documentation, ...
<tkamppeter> Odyx ^^
<melodie> xnox, I don't find a file under /usr/share/backgrounds for now
<melodie> neither in my box nor in a lubunti
<melodie> lubuntu
<OdyX> pitti: did you upload to Debian ?
<melodie> what size is that image supposed to be ?
<pitti> OdyX: cups-filters, not cups
<OdyX> pitti: ah okay.
<OdyX> pitti: I'm currently merging master-wheezy
<xnox> melodie: it can be one of these four names: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L383
<tkamppeter> OdyX, about the test failure, all error messages in error_log of the test are here: http://pastebin.ubuntu.com/1495462/
<tkamppeter> pitti ^^
<OdyX> tkamppeter: the one too much is "Filter "urftopdf" not found.
<tkamppeter> OdyX, pitti, there is one error message more than expected, but I do not know which one.
<OdyX> tkamppeter: â¦ I guess
<melodie> xnox, thanks, I look. I am also looking into the python script ubiquity-dm now and I might be interested in the lubuntu-openbox method, because the box I build is with openbox (no dm)
<tkamppeter> OdyX, urftopdf was added to cups-filters very recently.
<pitti> tkamppeter: right, that's the most plausible one
<melodie> xnox, I'll have to pick one that exists, to get the right size of image, to do one specifically for this openbox remix
<melodie> I might have a xubuntu iso, I'll try to extract it from there
<tkamppeter> pitti, OdyX: /usr/lib/cups/filter/urftopdf exists on the system where I did the build.
<ogra_> xnox, heh, funny that only edubuntu has a generic name for it
<xnox> ogra_: tbh, we should be querying xfce-config / gsettings what now & use that. Otherwise one has to change default flavour settings & ubiquity to change wallpaper name.
<ogra_> well, thats what we did in the past i think
<ogra_> yeah, i agree
<pitti> tkamppeter: yes, but not in the temp install for the test suite
<pitti> tkamppeter: it's using the local files, not the system installed ones
<tkamppeter> pitti, and it is using the mime files from the system? Or why does it search for urftopdf?
<pitti> tkamppeter: that was my next question -- the corresponding mime file should be installed by cups-filters, not cups
<pitti> and I don't see any match for "urftopdf" in cups indeed
<tkamppeter> pitti, is it linking in the system's filters (from cups-filters) by a series of hard-coded "ln -s ..." commands, needing to be manually updated whenever cups-filters adds a filter?
<pitti> tkamppeter: could be; I don't know enough about how that stuff works to know off the top of my head
<tkamppeter> pitti, CUPS does not know about urftopdf, cups-filters delivers urftopdf and the appropriate mime entries, so everything what the CUPS package needs to use it.
<tkamppeter> pitti, so this is a bug in CUPS-upstream's test suite? Do I have to register every new filter in cups-filters at CUPS upstream that they hard-code its linking into their test-suite?
<OdyX> tkamppeter: ah, you need to check debian/patches/tests-use-cupsfilters.patch
<OdyX> tkamppeter: yes. It's patched by us to have it work.
<OdyX> so just add a line there
<pitti> ooh, and then tests will work again, and we can finally upload to Debian experimental?
<pitti> I think I saw several requests from Debian to get 1.6
<bdrung> do we have some rules for posting to ubuntu-devel (e.g. re. top posting, plain text)?
<xnox> bdrung: we have code of conduct + your mail will be moderated if you are not a developer.
<xnox> ubuntu-devel-discuss is an open ml
<Laney> he means style guidelines
<bdrung> exactly
<ogra_> the general ML guidelines apply i think
<bdrung> where are these guidelines documented?
<melodie> xnox, thanks to you I'll be able to go a little further
<mahmoh> infinity: I need to persuade you to accept https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=seabios into lucid-proposed I can verify bug 589063 quickly, otherwise hallyn will have my head :) - please?
<ubottu> bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Triaged] https://launchpad.net/bugs/589063
<xnox> bdrung: they are unspoken rules, but there are a few guides on google.
<melodie> I'll have one more question in case someone has an idea : for unknown reason I am unable to get an automatic login in the live cd, and at the end of install when I configure a user, with automatic login as well, I don't get the automatic login in the installed version either. My tests are run in virtualbox and I don't use a desktop manager. Only lightdm as session manager. any idea ?
<ogra_> bdrung, http://www.ubuntu.com/support/community/mailing-lists
<ogra_> "Write your email underneath the email which you are replying to."
<xnox> wow =)
<Laney> Evolution (Ubuntu's default email client)
<ogra_> haha
<ogra_> time for an update it seems
<Laney> hur hur
<bdrung> ogra_: thanks. that page sums all up.
<tkamppeter> pitti, OdyX, I have fixed CUPS on the GIT now, it passes the test suite, but needs cups-filters 1.0.25 or newer to build.
<pitti> tkamppeter: awesome! can you please bump the build dep accordingly?
<tkamppeter> pitti, I did so already.
<OdyX> tkamppeter: you don't need the -3~ for cups-filters (it will fail)
<OdyX> tkamppeter: it was needed because I added bc in .24-3 but .25 doesn't have a -3 yet
<tkamppeter> OdyX, sorry, I forgot it in one of the two lines. It built for me locally and so I dd not see it.
<OdyX> tkamppeter: and did you re-enable the pstops patch ?
<tkamppeter> OdyX, no, I did not see that there was a disabled patch.
<tkamppeter> OdyX, I have fixed the -3~ now.
<OdyX> tkamppeter: good, thanks.
<OdyX> tkamppeter: the merge is a headache to manage, but I'll get there eventually by sub-merging the releases one by one
<pitti> OMG 226 line changelog
<pitti> (in cups debian git trunk)
<pitti> override_dh_auto_test:
<pitti>         make check
<pitti> tkamppeter: ^ do we still need that then?
<tkamppeter> pitti, I did not add this. Is "make check" not the defauult call for the self test of an upstream source package?
<pitti> that's what I thought
<pitti> tkamppeter: presumably it's a leftover from previously disabling the tests with "make check || true"?
<tkamppeter> OdyX, pitti, re-activating the pstops patch makes the ipp-2.1.test fail. It should not, if we want to test IPP stuff it should not depend on filter chain priorities.
<OdyX> pitti: might be.
<OdyX> pitti: yeah, I'd like to have more descriptive changelog entries (and less lists of files thereâ¦)
<pitti> OdyX, tkamppeter: package builds fine ATM and all tests succeed; nice! (there is a missing symbol in debian/libcupsppdc1.symbols, but we don't build with -c4)
<OdyX> pitti: wait, I'll break it by merging the stuff targetted at Wheezy
<OdyX> :)
<melodie> bye
<highvoltage> bdrung: is this perhaps what you looked for? http://www.ubuntu.com/support/community/mailing-lists
 * ogra_ hands highvoltage some *strong* coffee
<bdrung> highvoltage: yes and i recommend you to take ogra_'s *strong* coffee ;)
<ogra_> hehe
 * xnox is out of coffee *snif*
<highvoltage> thanks ogra_, I just got up and need it :)
 * bdrung comes out as non coffee drinker
<xnox> bdrung: do you drink red bull then?
 * xnox is acting all naive =)
<bdrung> xnox: rarely
<bdrung> i drink coke rarely, too
<bdrung> so most times i am tired :)
<tkamppeter> pitti, as cups passes the tests now, will youy upload it to Debian? Or needs the pstops issue to be fixed at first?
<pitti> tkamppeter: I don't know about the pstops issue; but I understand that OdyX is still working on cups?
<tkamppeter> pitti, if OdyX is still working on CUPS, let him complete.
<OdyX> tkamppeter, pitti : I'm just merging the job done for Wheezy into experimental
<doko> jodh, online?
<infinity> mahmoh: Promise?
<mahmoh> infinity: which?
<infinity> mahmoh: That you'll verify this seabios this time. :P
<ogra_> beer ?
<mahmoh> infinity: yes, I'm properly notified now, 100% or a case of beer for all!
<mahmoh> (one case for all to share that is :) )
<infinity> xnox: Any progress on tidying up cunit?  The archive's in a mildly inconsistent state until we get this sorted. :/
<infinity> xnox: (Since I trusted Jamie's review and promoted everything before noticing the extra dep...)
<OdyX> tkamppeter: I'm not convinced that the split is worth the effort, but ohwell.
<xnox> infinity: yeap. I am about finished with partmal-lvm-auto & clashing vg names. And then I'll do cunit. Should be today. I'll ping you about cunit promotion.
<infinity> xnox: Thanks in advance, then. :)
<OdyX> tkamppeter: damn. The test suite still fails to purge the control files when built in sbuild.
<OdyX> tkamppeter: ah no, even outside of an sbuild now.
<OdyX> hrm
<OdyX> tkamppeter: might it be a crash/timeout of imageto* in cups-filters ?
<OdyX> tkamppeter: all the remaining control files here are when it tries to print testfile.jpf
<OdyX> jpg
<OdyX> tkamppeter: ah, indeed: "/usr/lib/cups/filter/imagetops 1 user 'title' '' '' testfile.jpg > /tmp/test.ps" fails
<melodie_> hi
<melodie_> xnox, are you still here ? I have done an iso with a new png image added into /usr/share/backgrounds and I was expecting the background for ubiquity gui installer to change color but it didn't, it still stayd black. Would you have another idea ?
<melodie_> I paid attention that the name for the png be the same, and the size in pixels as well
<melodie_> warty-final-ubuntu.png
<melodie_> and also the rights and permissions
<OdyX> tkamppeter: would it be possible that cups-filters needs a 1.6 cups to work correctly ? In that case, it would need a bootstrapping in Debian, no ?
<OdyX> tkamppeter, pitti : pushed my merge to master, the build fails here because of the control files purge. It get "better" if I install the packages I just built before re-building, so I stand to my "bootstrap" suspicion, but I can't fix that for now. If you have an idea...
<OdyX> tkamppeter, pitti : also, I don't get how /etc/default/cups gets installed in libcups2, that's very probably wrong (or needs a Breaks)
<infinity> Laney: Did you mean s/good/base/ in your cheese upload?
<infinity> Laney: Oh, I see, it's waiting on a split from NEW.
<infinity> hallyn: I thought the whole point of this qemu merge was to get us in sync with Debian?  Why the Ubuntu upload?  Are we still stuck with a delta for some reason?
<hallyn> infinity: we have a ubuntu delta because:
<hallyn> 1. we have some arm and gridcentric patches which are not yet upstream
<hallyn> 2. we need some changes to deal with our old package layouts (to obsolete them)
<hallyn> 3. there are some things we can't have in main
<hallyn> infinity: the debdiff from debian is actually pretty small though
<hallyn> infinity: http://paste.ubuntu.com/1496902/  the debdiff from debian to ubuntu
<infinity> hallyn: I'd push for some of these to just be in the Debian package to make merging easier (like the Breaks/Replaces on qemu-common, doesn't hurt to have it in Debian)
<infinity> hallyn: Same with the breaks/replaces on qemu-kvm.  (and we could keep theirs as well)
<infinity> hallyn: The transitional packages, perhaps they don't want, but even that wouldn't hurt, and lets people more easily test and sidegrade.  But that's not even remotely a supported thing to do, so meh.
<hallyn> i can ping Michael Tokarev to see if he's amenable
<infinity> hallyn: The bits where we differ in /etc might be nice to try to converge on as well at some point.
<hallyn> infinity: yes - i'm not sure whether they actually use what they ahve or not
<infinity> hallyn: (other than /etc and debian/control bits, the rest seems sane to have as a delta for now, I concede the point... At least we're getting closer)
<hallyn> infinity: i'll start by trying to break the debdiff into meaningful chunks (the bottom bits of which would be pushed to debian) at github.com/hallyn/qemu
<hallyn> infinity: esp since this also (almost) gets rid of qemu-linaro
<jbicha> hallyn: "things we can't have in main" = spice ? are there reasons for that posted somewhere?
<hallyn> jbicha: it's also vde2
<hallyn> there is a spice MIR bug which should have the rationale for the nack for main
<hallyn> mainly it depends on libs which are duplicates of what is already in main, and not particularly trusted
<jbicha> hallyn: I've tried searching but I can't find a spice mir
<jbicha> I also am wondering why spice-protocol is in main
<melodie_> xnox, if you are still around, this is what I get : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
<hallyn> jbicha: the libraries in question were cegui-mk2 xerces-c2 ois devil allegro4.2 dialog svgalib freeimage
<jbicha> oh, nm I guess xserver-xorg-video-qxl pulls it in
<melodie_> the blue image around is what I have put into the wallapers directory, but how can I get the ubiquity windows itself to have the right colors ? at least something clear and readable ?
<jbicha> hallyn: is that still the case? I'm having trouble finding those libraries in the spice source
<hallyn> jbicha: then it might be worth revisiting
<jbicha> part of why I'm asking is because a friend has to workaround bug 975165
<ubottu> bug 962376 in qemu-kvm-spice (Ubuntu) "duplicate for #975165 spicevmc not supported in QEMU binary" [Undecided,Confirmed] https://launchpad.net/bugs/962376
<hallyn> jbicha: i'd be very happy to just have spice in main.  do you want to open a new MIR for it?
<jbicha> hallyn: sure I can start the paperwork :)
<hallyn> jbicha: awesome, thanks!
<melodie_> which version of Ubuntu does this one ubiquity-dm belong to ?
<melodie_> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L564
<melodie_> the one for Precise seems not to be the same ? http://pastebin.com/z4JiC5NK
<melodie_> I am trying to find out how to get a background with a decent color in the window of the ubiquity gtk frontend, and can only have a black background (a remix I'm trying to do) here is a pic : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
<melodie_> any idea how I could fix it ?
<melodie_> good night
<vadi2> How would I go about asking for a package that was updated in Debian to be updated in Ubuntu+1?
<xnox> vadi2: which package?
<vadi2> https://launchpad.net/ubuntu/quantal/+source/mudlet
<xnox> vadi2: it's fully up to date, https://launchpad.net/ubuntu/+source/mudlet
<xnox> in raring.
<xnox> if you want a backport to previous releases, !backports
<xnox> !backports
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<vadi2> Ah. Thank you.
#ubuntu-devel 2013-01-05
<MrWGW-> hey there
<MrWGW-> I find it highly annoying that /bin/sh is symlinked to dash by default, because dash is not fully compatible with the Bourne Shell, let alone bash
<MrWGW-> what would the chances be of that being changed to a symlink to /bin/bash?
<MrWGW-> just symlinking it to bash would reduce the size of /bin slightly and improve compatibility with other distros and UNIX like OSes
<MrWGW-> if that's a bridge too far, perhaps ash could be used; ash implements most of bash and is also properly backwards compatible with Bourne
<infinity> MrWGW-: sudo dpkg-reconfigure dash
<xnox> MrWGW-: see past discusions and reasons why we switched to dash. It's faster and significantly decreases boot speed. Bashism is not compiant. Debian also uses dash. If you depend on bash the you should specify #!/bin/bash
<infinity> MrWGW-: dash is POSIX-compliant, which is all that one requires from /bin/sh so, no, we won't switch back.
<infinity> MrWGW-: The above dpkg-reconfigure will let you change it on your own systems, if you prefer.
<infinity> MrWGW-: But yes, as xnox states, if your scripts use bashisms, they're not /bin/sh scripts, and should specify #!/bin/bash
<infinity> MrWGW-: (As for your statements about ash, ash in Debian is just a package that ships a symlink to dash...)
<infinity> MrWGW-: dash was derived from ash.
<MrWGW-> infinity: in ash, echo -e and functions work properly
<MrWGW-> I have some Buffalo Linkstation NASes that use ash, and I have scripts that run correctly on that ash version, but not on your dash
<infinity> MrWGW-: I suspect you're wrong, and what you really mean is "in my version of ash, echo isn't a builtin".
<MrWGW-> I would propose that what you guys should have done, that would have been a better design: use dash during booting, but refer to it explicitly with the path /bin/dash in your scripts, but meh
<infinity> MrWGW-: If you rely on non-POSIX extension to echo, use /bin/echo
<infinity> MrWGW-: If you rely on non-POSIX shell functions, use the shell you want to use explicitly.
<MrWGW-> my script uses a POSIX compliant function declaration which is breaking on dash
<infinity> Really?
<infinity> MrWGW-: If you're using the keyword "function", that's not POSIX.
<infinity> MrWGW-: You want "funcname() { code; code; }" not "function funcname() { code; code; }".  The latter is a bashism.
<MrWGW-> I'm using funcname()
<infinity> Then what's breaking?
<MrWGW-> when executing the script I'm getting an /usr/bin/nssync: 5: Syntax error: "(" unexpected
<infinity> We have shell functions all over the place.
<infinity> That's exactly what you'd see if you prefaced the line with "function".
<MrWGW-> its not prefaced
<MrWGW-> maybe the dash executable file is corrupt
<MrWGW-> brb while I check this
<infinity> Could you show us the script?
<MrWGW-> btw one thing that I do appreciate, this dash business aside, is that you continue to ship upstart vs. systemd
<geofft> Can you write a small example that demonstrates the problem?
<geofft> foo() { echo hi; } appears to work for me, in dash.
<MrWGW-> yes, once I verify its not a problem on my machine
<MrWGW-> hmmm this is strange, the dash image file on this freshly provisioned 12.10 instance on Azure has a different md5 checksum than the same file on an ubuntu 12.10 system I have in the lab
<MrWGW-> I'm going to provision another 12.10 instance and see if the problem persists, and if not, we can chalk it up to Microsoft stupidity
<infinity> Both the same architecture?
<MrWGW-> yes, x86_64
<MrWGW-> do you guys have access for development purposes to a Windows Azure cloud account?   Its remotely possible there's an oddity with their image, but I've started the provisioning of another instance
<infinity> The error you pasted doesn't sound like something that would come from a corrupt dash, just a broken script.
<MrWGW-> its also remotely possible that someone somehow pwnt my 12.10 instance in between the time of its initial provisioning and my attempting to install this script on it
<infinity> -rwxr-xr-x 1 root root 105712 Aug 15 04:41 /bin/dash
<infinity> b0c9cf166a0a3051e1f1c359f3e50d17  /bin/dash
<MrWGW-> the line of code in the script is conf_transfer()
<infinity> ^-- This is what Q's dash should look like, though.
<MrWGW-> that matches the md5 checksum on my lab box but not on the azure one
<infinity> MrWGW-: Immediately followed by a {, I assume?
<geofft> Is there a bashism on the previous line of code?
<MrWGW-> infinity: yes
<infinity> Oh, it's quite possible you have a rootkit and that's not dash at all, yes.
<MrWGW-> that's my thought
<MrWGW-> especially since the other instance just came up and the md5 checksum is what it should be on that
<MrWGW-> weird though that it got pwnt in that manner, given that it only had ssh key based authentication
<MrWGW-> strange
<MrWGW-> fortunately it wasn't in production yet
<infinity> Yeah.  We build the Azure images, I'd like to think I'd know if they were broken.
<MrWGW-> I'm going to blow that instance away
<MrWGW-> I use azure as a backup for my colo servers because I get it with my bizspark subscription
<infinity> Makes a valid argument for doing security updates within seconds of initial install.  But still, ew.
<MrWGW-> on another matter, are there any semi-official or official derivatives planned featuring Mate?
<MrWGW-> I'd really like to see a Kubuntu or Lubuntu style derivative with Mate, designed to fit on a single CD ROM disc
<infinity> Nothing planned that I know about, but I certainly won't stand in the way of someone willing to do the work.
<MrWGW-> do you think if such a derivative were produced it could get recognized to the same extent as Kubuntu, Lubuntu, Xubuntu et al?
<MrWGW-> assuming it was of sufficient quality and so on
<infinity> Googling for Mubuntu (the obvious choice of name?) got me to http://sourceforge.net/projects/mubuntuproject/
<infinity> No idea how active that is, and it's not in the Ubuntu archive.
<MrWGW-> I myself miss the convenience of the single-CD live CD, as CD-Rs are a heck of a lot cheaper than DVD-Rs, the Mate vs Unity thing is less a big deal for me becauseI mainly use Ubuntu server-side, but a lot of the older guys at the LUGs I go to have been up and arms over Ubuntu, and are either not updating their systems or they're increasingly installing Mint or some other third-tier distro
<infinity> Certainly, if someone was willing to do the work as an Ubuntu developer in the archive, we've not stop them.
<MrWGW-> another good name for what I just proposed would be Ubuntu Classic Edition
<infinity> MrWGW-: I gave up on spinny media long ago, and just install from USB sticks.
<MrWGW-> infinity: USB sticks are good, but I own a vast collection of computers some of which lack boot from CD support
<MrWGW-> also I prefer to use my USB sticks for other things
<MrWGW-> so having a large array of disposable blank CD ROMs is useful as they're just dirt cheap
<MrWGW-> even the drives are dirt cheap
<MrWGW-> at fry's they're selling LG OEM blu ray disks for $10
<MrWGW-> BD-ROM units
<MrWGW-> so when my desktop systems have an optical drive failure, which is a fairly routine occurence, replacement is no big deal
<infinity> MrWGW-: MATE also appears to have a repository of packages built for Ubuntu, so one can do a minimal install, then slap MATE on.
<MrWGW-> its more of a headache on laptops and servers that use weird proprietary disk drives
<infinity> (I'd still definitely prefer to see this happen in the Ubuntu archive, but whatever)
<MrWGW-> infinity: well I'd love to roll a MATE variant which would feature MATE already on the syste, be sized to fit a single CD ROM, or smaller, and feature the Ubuntu font and desktop background
<MrWGW-> providing a polished experience similiar to that of Ubuntu 10.10 (which I personally consider to be the zenith of Ubuntu desktop releases thus far)
<infinity> 12.04 is pretty shiny.
<MrWGW-> and my enthusiasm for this is driven by the fact that your distro is sticking to upstart, which is a really nice init system IMO
<MrWGW-> I really like the GNOME 2.x interface that 10.10 featured, it was very nice, it also had the prettiest wallpaper IMO
<infinity> Heh.
<MrWGW-> I am looking forward to seeing some Ubuntu TVs and phones hit the market though
<infinity> Well, wallpaper can always be rescued.
<MrWGW-> I suspect we'll really start to see Unity shine on those systems
<MrWGW-> infinity: I use The Dawn of Ubuntu wallpaper on one of my systems, from 6.10
<infinity> I know I also had problems with the GNOME2->Unity transition, so much so that I used to run XFCE tailored to look just like old skool Ubuntu.  But, I eventually conformed.
<MrWGW-> Edgy Eft
<infinity> I now run a stock Unity setup on raring.
<MrWGW-> as far as I'm concerned systems like Unity are optimized for tablets and should be used on them, but for workstation use something else is needed
<MrWGW-> MS is making an even bigger mistake with the Metro UI
<infinity> http://lucifer.0c3.net/~adconrad/xubuntu.png <-- My old XFCE desktop, before I switched to Unity.
<MrWGW-> which is completely inappropriate for desktop or workstation use
<MrWGW-> now if you don't care about workstation use then this is a moot point, but for a technical power user like myself, a different style of interaction is required
<MrWGW-> at that, a lot of workstation guys like to use an even more minimal X system running blackbox or something of that nature
<MrWGW-> but that's just a bit too spartan for me
<infinity> I've become even more keyboard-driven since forcing myself to switch to Unity.  This isn't a bad thing.
<MrWGW-> I do like having a nice pretty background and transparent menu bars
<MrWGW-> I use ThinkPads and on my desktop, Thinkpad style USB keyboards, which feature trackpoint mice
<infinity> Ditto.
<MrWGW-> these reduce the overhead of moues usage
<MrWGW-> I'm right hnaded, but I can maneuver the trackpoint with my left index finger
<MrWGW-> (I also use Sun Type 7 UNIX layout keyboards on some of my workstations, and I have a few other keyboard varieties of a more conventional nature
<MrWGW-> a Unicomp M series clone, a pair of keytronics keyboards, and so on
<MrWGW-> I am a keyboard afficianado
<MrWGW-> there's a really pretty $75 gaming keyboard at fry's that I want
<MrWGW-> so I'm going to in the next few weeks look into the possiblity of doing the MATE variant we just discussed
<MrWGW-> and if conditions permit, I'll start working on it
<MrWGW-> I have a relative in the hospital now
<MrWGW-> so that's the only real variable
<MrWGW-> but if it can be done, it would be pretty cool, and it would also have the effect of silencing some of the anti-Ubuntu people who are whining about Unity or the other changes you've made
<MrWGW-> changes which I should add are superficial and irrelevant
<MrWGW-> the important thing is that you guys have avoided making unpleasant changes to the underlying system, i.e. systemd
<MrWGW-> and I hope you keep it that way
<infinity> We'll never silence all the detractors.  They could easily run Xubuntu, Lubuntu, or Kubuntu, but they choose to focus on what the "official Ubuntu CD" has on it.
<MrWGW-> I have historically been a heavy CentOS/Scientific Linux user, but the new changes in the most recent Fedora builds that will be going into RHEL 7 are...unpleasant
<infinity> And if it's not exactly what they want, complaints.  Such it life.
<MrWGW-> infinity: having a Mubuntu or Ubuntu classic edition would silence the more legitimate detractors
<MrWGW-> or rather
<MrWGW-> it would keep them happy and in the fold
<MrWGW-> and take marketshare away from Linux Mint
<MrWGW-> you have a bunch of customers who use your product and like it, but odn't like some, but not all, of the new changes, so it makes sense to allow for a community-developed variant to meet their needs
<infinity> I have no interest in sticking it to Mint.  But I also don't mind if MATE ends up in Ubuntu's archive.  So, whatever happens.
<MrWGW-> that way they can be happy, you can be happy and so on
<MrWGW-> the only Linux distro I really want to stick it to right now is Fedoera heh
<MrWGW-> the arrogance of their engineering steering committee is astonishing
<infinity> I thought there was an effort to get MATE into Debian.  If that's still ongoing, that would be the obvious first place to contribute.
<infinity> Cause if it's in Debian, Ubuntu gets it (nearly) for free.
<MrWGW-> the changes they've made have the effect of breaking compatibility with other distro, with other Unices, with sysv, with POSIX
<MrWGW-> and brekaing everyone's management scripts and software
<infinity> And building images based on that wouldn't be rocket surgery.
<MrWGW-> I believe MATE is already in Debian
<MrWGW-> but I'll check on that
<mbiebl> MrWGW-: it isn't
<infinity> But there's a lively debate in the ITP bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783
<ubottu> Debian bug 658783 in wnpp "ITP: mate-common -- common scripts and macros to develop with MATE" [Wishlist,Open]
<MrWGW-> I'll take a look
<infinity> Seems like the general concensus is "not while MATE still ships a bunch of duplicate old skool code".
<infinity> But they're working hard on moving from gconf to gsettings, dropping old libs, moving to GNOME3 libs on the backend, etc.
<infinity> So, may be more favourable soon.
<MrWGW-> gah if the Debian developers block MATE I'm going to hate that project even more than I do already
<infinity> I don't see any blocking going on.
<infinity> There's a freeze in Debian right now anyway.
<infinity> And pre-1.6 MATE was a no-go for a variety of good reasons.
<infinity> Things may be shaping up now.
<mbiebl> infinity: forking gconf was pointless in the first place
<mbiebl> gconf is still maintained upstream
<mbiebl> if they switch to gsettings fully, then hopefully this won't matter
<Bluefoxicy> ughhhhh
<Bluefoxicy> Find the person that decided it was a good idea to un-highlight when highlighting in the Rhythmbox search box or Playlist name (when editing the playlist name) and hang him.
<Bluefoxicy> I can't believe somebody exerted positive energy to add this behavior.
<Bluefoxicy> Omissions of stuff that really needs to be done yes.  Why would you take a perfectly round wheel and plaster corners onto it?
<infinity> MrWGW-: I just commented on the Ubuntu bug, BTW: https://bugs.launchpad.net/ubuntu/+bug/876675
<ubottu> Ubuntu bug 876675 in Ubuntu "[needs-packaging] MATE" [Wishlist,Confirmed]
 * Bluefoxicy complain.  Should file bugs.  Should git blame and file bugs.
<MrWGW-> infinity: by the way
<MrWGW-> you might just port over the Linux Mint repo
<MrWGW-> since they're binary compatible with Ubuntu anyway
<MrWGW-> at least in theory
<infinity> MrWGW-: That's not going to happen. :P
<MrWGW-> why not just fork their repo?
<MrWGW-> if it works
<MrWGW-> and would save time...
<infinity> The "if it works" part is the important bit there.  And my experience with Mint's packaging quality hasn't been stellar.
<MrWGW-> I'll take a look
<infinity> Either way, I have no interest in packaging MATE.  It will need an active maintainer in Debian and/or Ubuntu, or it's really not going to happen.
<MrWGW-> hmm and you know I tihn ktheir standard Mate is slightly modified
<MrWGW-> they use a SUSE style taskbar with a start menu if I recall
<MrWGW-> so yeah
<MrWGW-> so suppose, if my relative is OK and I can commit the time, I become the maintainer of Mate and the shipper of the Mate variant we've discussed
<MrWGW-> would that be alright with you?
<MrWGW-> Mate would I presume live in the "universe" repo right?
<infinity> Are you an Ubuntu developer?
<MrWGW-> not at present
<MrWGW-> i am a sysadmin who runs about 200 Ubuntu server systems though
<infinity> Well, that's something you might want to work on if you want to seriously commit to maintaining an etire DE.
<Bluefoxicy> that's different than maintaining a package
<infinity> But you're not signing up for a simple/minimal task there, either.
<Bluefoxicy> maintaining a package involves having a clue about what's going on around you, which is really the hard part since nobody e-mails you when a new version of your stuff is out.
<infinity> Desktop environments take a ton of work.
<Bluefoxicy> figuring out the packaging stuff is a one-off thing.
<Bluefoxicy> when I tried to maintain the pax-utils package, every 6 or 7 versions the lead developer would poke me and ask why I didn't update the package in ubuntu
<MrWGW-> I do understand the time commitment; that's why I have to wait to see how my relative is doing before I can commit
<infinity> (Not trying to discourage, just warn... DE maintainers are grumpy people... Except for Riddell, nothing seems to get him down)
<MrWGW-> I do get that
<MrWGW-> and given the surge in popularity MATE is experienceing its also possible someone better qualified will rise to the occasion and do this
<MrWGW-> but within the next few weeks I'll decide
<MrWGW-> the other question I would have is if Ubuntu plans on introducing systemd in the next three years
<MrWGW-> because what I'm really seeking for myself is to maintain a system that preserves the classic sysV init compatible upstart system, fits on a single CD, supports a wide range of Linux filesystmes for the root and boot partition, and has MATEand right now Ubuntu fits the bill
<infinity> It's not in our current plans, no.  It would likely only happen if it ended up forced on us by outside influences.
<MrWGW-> what about the fact that udevd and systemd are now developed from the same codebase?
<infinity> Like, if all Linux systems become dependent on systemd and we have no choice.  But I don't see that happening, as much as the systemd guys want it to.
<MrWGW-> could that force your hand to any extent?
<infinity> Nah.
<infinity> It can still be built independently.
<MrWGW-> if that happened I'd just say screw it and switch all my stuff to OpenBSD and freeBSD
<MrWGW-> I already use those OSes on half of my server systems
<MrWGW-> all of my filers are FreeNAS systems and OpenBSD runs on all of my firewalls and network managemnet devices
<MrWGW-> but as you of course know
<MrWGW-> there are some things that are still more ocmfortable and pleasant to do on a Linux system
<MrWGW-> Im of the opinion that Linux first took off in the 1990s because it was generally compatible with other UNIX systems, it of course had the GPL license, and it was also the leanest, most bloat-free UNIX system available in that timeframe
<MrWGW-> even now some aspects like the Linux kernel's use of a generic task structure to represent both threads and processes set it apart from other more complicated systems
<MrWGW-> so  Ithink the trick for Linux to remain relevant is to stick to these values on which its success was built
<MrWGW-> as opposed to following in the footsteps of AIX and Solaris and OS X to unlimited bloat and ugliness and proprietary, incompatible extensions
<bdrung> Sweetshark: when will libreoffice 3.5.7-0ubuntu2 be available in precise-proposed? i am hit by bug #585910
<ubottu> bug 585910 in libreoffice (Ubuntu Quantal) "[Upstream] Impress Font fuzzy in presentation mode when Use hardware acceleration enabled" [Undecided,Triaged] https://launchpad.net/bugs/585910
<bdrung> Sweetshark: it would be nice to have at least libreoffice 3.6.4 in raring
<bdrung> Sweetshark: can we sync 3.6.4-1 from debian experimental?
<ricotz> bdrung, if you want you can use the quantal version in the libreoffice ppa with raring
<bdrung> ricotz: i don't want i fix for myself. i want a fix in the archive.
<ricotz> bdrung, raring will get 4.0 and he don't want to spent time on 3.6.x then
<ricotz> bdrung, syncing is not possible due the missing ubuntu specific patches
<mitya57> I don't think we can sync 3.6.4-1 because of unitymenus patch
<bdrung> okay, i will look into merging 3.6.4-1 when i have time instead of waiting for 4.0 to arrive
<ricotz> bdrung, i would recommend to forward port https://launchpad.net/~libreoffice/+archive/ppa/+sourcepub/2835951/+listing-archive-extra
<ricotz> didnt have time for it, but the obvious problem was the recognizing python in raring
<melodie> hello
<melodie> does someone know what must be done to get a normal color background in Ubiquity frontend gtk please ? not around the window but inside ? Here is what I get (a remix project I try to put up) : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
<melodie> is xnox here ? :)
<streulma> hello, is the Evolution-calendar bug already fixed in 12.10?
<melodie> streulma, what is this bug ?
<streulma> melodie: many of the people I know have the calendar bug in Ubuntu 12.10
<streulma> Evolution is not used
<melodie> streulma, and what does this bug do ?
<streulma> melodie: see here: https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1064136
<ubottu> Ubuntu bug 1062068 in evolution-data-server (Ubuntu Quantal) "duplicate for #1064136 evolution-calendar-factory crashed with SIGFPE in g_hash_table_lookup_node()" [High,Confirmed]
<Aeyoun>  Hi. I have a problem with deb packaging. Every file in debian/* is copied over to the build-area *except* for the upstart file so it fails to be detected by dh_installinit and is not included in the package.
<Aeyoun> I have studied other deb packages and cannot see that any of them are doing anything different from what I am doing.
<Aeyoun> Have verified that the upstart file is not copied over by monitoring the file system. Have also placed debug code in dh_lib and made sure it would have worked if the file was copied into the build-area correctly.
<Aeyoun> What process is responsible for copying over files from src/debian/* to build-area/package-name/debian/?
<infinity> Is it named <package>.upstart?
<Aeyoun> infinity, I have tried with upstart and <package.upstart>
<Aeyoun> and <package>.foo.upstart
<infinity> It would be dh_installinit that's meant to install it.  Which should Just Work, if you're using dh(1), but if you're using old skool debhelper (by calling each one manually), you may be missing _installinit.
<Aeyoun> The verbose output says shows that dh_installinit runs but it does not output anything. Debugging it shows that it does not find the file and this is skipped.
<infinity> From here, I'd probably need to see the source package in question.
<Aeyoun> The Ubuntu packaging guide learned me to package using `bzr builddeb -- -us -uc`
<Aeyoun> infinity, I would be grateful if you could assist me. :-) I'll upload the source.tar and my debian/ now.
<infinity> Oh, wait.  You mean bzr bd isn't exporting it?
<infinity> That could be as simple as you needing to bzr add the file.
<Aeyoun> if by "not exporting" you mean does not copy it from source/debian/ to ../build-area/packagename/debian, than yes.
<infinity> (I assumed you meant it was in debian/ in the source package, but not getting installed into the binary package)
<infinity> But if you mean it's in your source REPO, but not making it into the source PACKAGE, that sounds like maybe it's just not actually in the repo. :P
<infinity> (ie: needs a bzr add, or a commit)
<Aeyoun> Oh. I did not know that. o.O
<Aeyoun> (Sorry for pasting directly)
<Aeyoun> bzr status
<Aeyoun> modified:
<Aeyoun>   debian/control
<Aeyoun>   debian/rules
<Aeyoun> unknown:
<Aeyoun>   debian/upstart
<Aeyoun>   debian/watch
<Aeyoun>   debian/source/format
<infinity> The first step in bzr bd is to export the repo, so you have a clean source package.  Export (in any VCS) won't export files that aren't tracked.
<infinity> So, "bzr add debian/upstart debian/watch debian/source/format" and try again.
<Aeyoun> The Ubuntu Packaging guide should probably have mentioned that I needed to do that.
<infinity> This is a mistake I make about 5 times a week when exporting from Debian glibc SVN to my source package and wondering where my new patches went. :P
<Aeyoun> infinity, please kiss yourself and dance happily around on the floor with yourself from me! :-D You solved my eight day mystery problem!! :-D
<Chipzz> make sure you also commit debian/control and debian/rules, because the package you build may not have these changes
<infinity> Chipzz: Committing isn't necessary for test-building with bzr bd.
<infinity> Chipzz: Export will catch modified files, just not untracked ones (to avoid cruft)
<Chipzz> infinity: ah k. not used to bzr, slightly more familiar with git
<Chipzz> different mindset :P
<infinity> Well, git would behave the same if you did a git add, then export.  That's just not most people's git workflow (most people do "git commit -a" and just add the world, if random tutorials are to be believed)
<Aeyoun> I am also more familiar with git. Never used bazar for anything.
<Chipzz> I tend to stage/commit my changes with vim and gitv/fugitive ;)
<Aeyoun> I assumed it would use my working directory and not the repo.
<infinity> Aeyoun: It does use your working copy, but new files aren't actually part of your working copy without adding them, that's all.
<infinity> Fairly classic behaviour inherited from CVS and SVN, among others.
<Aeyoun> I really wish it would give me a warning. "These files are untracked or have uncommitted changes: $list"
<Aeyoun> or some other indication that would have made the last few days more productive. :-P
<infinity> You could file a wishlist bug on bzr-builddeb to warn about untracked changes on invocation.  Might be handy.
<infinity> (Personally, I don't use any of the foo-builddeb packages, so I have a pretty low care-factor)
<Aeyoun> https://bugs.launchpad.net/bzr-builddeb/+bug/1096433
<ubottu> Ubuntu bug 1096433 in bzr-builddeb "warn about untracked changes" [Undecided,New]
<infinity> Aeyoun: Danke.  Added a distro task to the bug as well.
<Aeyoun> Another question, am I supposed to use the 0ubuntu1 tag to packages I upload to ppas? or is that just for "official" packages?
<infinity> You can version PPA packages however you want.  BUT.  If you plan to upload to the archive later, and want smooth upgrade paths, I'd recommend something like:
<infinity> Debian: 1.2.3-1
<infinity> Ubuntu: 1.2.3-1ubuntu1 (or 1.2.3-0ubuntu1, if ours is a newer upstream)
<infinity> PPA: 1.2.3-1ubuntu1~ppa (or 1.2.3-0ubuntu1~ppa, see above)
<infinity> The "~ppa" on the end will make sure that version sorts just before the "real" -0ubuntu1, which would be what you'd want to upload to the archive.
<infinity> And you can rev those (~ppa1, ~ppa2, ~ppa3, etc) ad nauseum, and still be able to use the proper version number for the archive later, with a sane upgrade path.
<Aeyoun> thanks again, that makes sense.
<infinity> (The string there doesn't matter, it's the ~ that's the magic "just before the previous bit" sorting, so you could use 1.2.3-0ubuntu1~aeyoun1, if you want them more personalised and easier to track when people whine about a specific version)
<maxb> You might also see things like 1.2.3-0ppa1 or 1.2.3-0ubuntu0ppa1 which are accomplishing more or less the same thing - the important thing is how the version comparisons turn out compared to versions in Debian and Ubuntu official archives.
<maxb> -0ppa1 is taking gratuitous advantage of the fact that 'p' comes before 'u'
<infinity> maxb: Yeah, lots of schemes work.  I like the realversion~ppaversion thing because it denotes "I plan for this to eventually be released as 'realversion' some day".
<infinity> But to each their own.
<infinity> It doesn't even matter if PPAs sort lower than the archive (or clash, even) except, as I mentioned, giving users sane upgrade paths.
<infinity> Which is always a nice thing to do.
<maxb> I like the realversion~ppaversion thing too, when that is actually what is being denoted :-)
<WONDERFULWONDER> #join
<Deborah_Meltrozo> Hello
<WONDERFULWONDER> hi
<Deborah_Meltrozo> Can anyone recommend me a tool, framework, etc for Unit Testing, if its GUI-based is better
<Deborah_Meltrozo> on Python
<WONDERFULWONDER> quit
<WONDERFULWONDER> #quit
<WONDERFULWONDER> try download quickly but it is not downloading pls help
<dkessel> WONDERFULWONDER, how do you try to download, and what is the error you get?
<melodie> could someone help me with the ubiquity theme setup for a remix ?
 * melodie annoyed after several days seeking the web docs and wikis
<Aeyoun> Hi again. I ran into another problem. This time with pbuilder-dist quantal mypackage.dsc. "amd64" has snuck in at the end of the CFLAGS. Resulting in ""cc: error: amd64: No such file or directory" error.
<infinity> Aeyoun: Can you point me at the sources?
<infinity> (Also, I can't believe we still recommend pbuilder... Should really talk to someone about fixing that)
<Aeyoun> the upstream makefile has $(ARCH) after $(CFLAGS). This is not a problem when running  `make build` nor `bzr builddeb`. pbuilder, however, sets this variable.
<infinity> That seems like a goofy thing for the upstream Makefile to do unless it's meant to be setting it to something.
<Aeyoun> it is set on OS X but no other platform. :-)
<infinity> Set to what, though?
<Aeyoun> fatbinary.
<infinity> Anyhow, you could just explicitly unset it.
<Aeyoun> 32+64 bit
<infinity> "unexport ARCH" in your debian/rules might tidy that up.
<infinity> A more correct fix to forward to upstream would be for them to explicitly set it to an empty string on all platforms, then twiddle it on OSX to whatever weird thing they want.
#ubuntu-devel 2013-01-06
<Aeyoun> This is really not encouraging. http://developer.ubuntu.com/packaging/singlehtml/index.html#submitting-for-inclusion "You've done lots of work following this wiki, and now you need to learn a bunch of new stuff and do things slightly differently over at this other place."
<micahg> doko__: nevermind about icedtea-web, I see it's dependent on which release you generate the control file on, not which one it's targeted too (which is a bit fragile, but I worked around it)
<mitya57> Logan_: can you please mark lp:~logan/ubuntu/raring/ocfs2-tools/debian-merge as merged (so that it doesn't show in the sponsoring queue)?
<Logan_> mitya57: Hmm, but it's not merged, though.
<Logan_> I'll set it as Work in progress.
<mitya57> Logan_: there was upload authored by you: https://launchpad.net/ubuntu/raring/+source/ocfs2-tools/1.6.4-2ubuntu1
<Logan_> Well fancy that.
<Logan_> Okay, marked as Merged. :P
<mitya57> thanks!
 * mitya57 wishes Logan_ becomes Ubuntu developer soon :)
<Logan_> Haha, same here. I'm actually planning on applying for MOTU, which would gain me Ubuntu membership in the process.
<nrosvall_> hi is there plans to disable menu icons from Qt apps?
<nrosvall_> as now gtk apps do not show menu icons by default in unity, but Qt apps do
<nrosvall_> I guess that needs some qt dconf integration?
<nigelb> 6/
<nigelb> /3333oi52
<nigelb> err, sorry!
<Bluefoxicy> âIn terms of software, Ubuntu is like the iPhone" <-- too much proprietary, in-house software and an extreme habit of not playing well with others while telling everyone you play well with everyone?
<Bluefoxicy> http://www.ubuntu.com/ubuntu/why-use-ubuntu
<Bluefoxicy> (A Nexus phone is probably a more favorable comparison, though with Unity and Upstart people will argue about whether or not it's a more accurate comparison)
<maxb>  That is a rather a bizarre quote
<maxb> I'd dismiss it a just being something said by a newspaper, but having it requoted on ubuntu.com makes it more prominent
<maxb> Thdn again, more people who use a nexus phone can probably figure out if they'd like to use ubuntu all by themselves, so maybe its a deliberate attempt to seed curiosity in a particular market segment
<penguin42> debian security seems to be busy today
#ubuntu-devel 2013-12-30
<alkisg> Hi, upgrading Trusty on i386, I got: installing libtxc-dxtn-s2tc0:i386 (0~git20131104-1) ...
<alkisg> update-alternatives: error: alternative path /usr/lib/x86_64-linux-gnu/libtxc_dxtn_s2tc.so.0 doesn't exist
<alkisg> I worked around it by symlinking the dir it's searching for, but it's probably wrong and needs to be changed...
<alkisg> root@server:/usr/lib# ln -s i386-linux-gnu/ x86_64-linux-gnu
<zyga> hi, what is the delay between a new package hitting Debian unstable and it showing up in Ubuntu?
<zyga> I have a package that is in Debian now, I can find it in the ubuntu package pool but I cannot see it in any of the apt indices
<zyga> the package in question is plainbox
<pjotr> Hello, I'd like to file a bug but I don't know against which package.
<pjotr> The bug is this: power management for the wireless chipset often causes slow, laggy or unresponsive wireless internet. So I always turn it off like this: https://sites.google.com/site/easylinuxtipsproject/internet#TOC-Disable-power-management-for-the-wireless-card (item 2.1, right column)
<pjotr> But I think it would be better if power management for the wireless chipset, would be off by default. Against which package can I file this bug?
<pjotr> cjwatson: maybe you know against which package I can file this bug?
<cjwatson> zyga: plainbox is in Ubuntu now, it just had to go through NEW.  You're better off checking Launchpad than apt, as a rule.  The delay is typically no more than twelve hours or so
<zyga> cjwatson: so ubuntu has NEW just like debian? I didn't know that
<zyga> cjwatson: where can I find this on launchpad?
<cjwatson> zyga: of course
<geser> zyga: https://launchpad.net/ubuntu/saucy/+queue
<cjwatson> zyga: https://launchpad.net/ubuntu/+source/<source package name>
<zyga> aahhh
<cjwatson> (in this case it was binary NEW so it will show up under the source)
<zyga> one learns something new every day :)
<cjwatson> (As well)
<zyga> thanks :)
<cjwatson> NEW for syncs gets waved through fairly rapidly as a rule, others may wait longer
<cjwatson> geser: wrong series, too
 * zyga feels that launchpad has lots of hidden, magic URLs
<geser> cjwatson: thanks for reminding me to update my bookmark :)
<cjwatson> zyga: https://launchpad.net/ubuntu/+source/<source package name> should be in every Ubuntu developer's browser configuration via a smart bookmark or whatever you prefer, IMO
<zyga> woot, my first package in Ubuntu through Debian :)
<zyga> cjwatson: I think that the proliferation of PPAs lessens the incentive to get into the core distribution so many people don't know about things like that
<zyga> cjwatson: what made plainbox go to main instead of to universe?
<zyga> ah, I take it back
<cjwatson> zyga: it didn't
<zyga> why is component main in one of the fields
<zyga> ?
<cjwatson> zyga: that's just quoting the Debian component
<zyga> ah, ok
<cjwatson> "these are just the package defaults" as the small print explains
<zyga> cjwatson: since that packge has autopkg tests, will it automatically get tested in ci.ubuntu.com?
<cjwatson> I assume so
<cjwatson> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-plainbox/
 * zyga needs to file main inclusion request
<zyga> oho
<zyga> I see a small failure in adt scripts!
<zyga> nice
 * zyga goes to correct that
<zyga> cjwatson: do you know if Debian has adt support?
<cjwatson> zyga: people have been working on it but I don't *think* jobs are being automatically run as yet.  They'll probably end up on http://jenkins.debian.net/ if they are
<xnox> zyga: i use http://pad.lv/u/<source package name>, more shortcuts at http://pad.lv/ it's not an official service run by launchpad, but it is quite handy.
<arun__> guys, which kernel is the best?
<xnox> NT
<dobey> arun__: the one that works
<nemo> so. the worrying error on installing blcr-dkms on a VM post-13.10 - is that a serious issue or not?
<nemo> or just some random .deb prob that I can ignore?
<arun__> dobey: which would be the best for a distro?
<zyga> xnox: thanks for the tip, is there a list of shortcuts that it provides?
<xnox> zyga: yeah, on the top page http://pad.lv
 * zyga looks
#ubuntu-devel 2013-12-31
<Guest89396> Hi everyone
<Noskcaj> hey Guest89396
<Guest89396> I'm a Computer Science student, interested in contributing to Ubuntu, currently reading this https://wiki.ubuntu.com/ContributeToUbuntu Haven't used IRC before so was just checking it works
<Guest89396> which is does, thanks @Noskcaj
<Noskcaj> no problem. It's great to have another new contributor. Try and have irc online as much as possible, since it makes it easier to contact you, and more people will recognize you.
<hyperair> something's odd with upstart.
<hyperair> it's taking up 200MB of memory on my machine. how odd.
<hyperair> at least, the init --user process
<Whoopsie> Can someone help me fix this error http://askubuntu.com/questions/397724/quickly-error-cant-create-or-update-ubuntu-package
<mitya57> cjwatson: What was wrong with Debian version of python-qt4? I saw you changed something, but then wgrant_ reverted that.
<xnox> mitya57: i think this is all influx trying to support multiple python 3 versions at the same time. As at the moment work is underway to enable 3.4 and 3.3 both as supported versions. 3.3 still the default at hte moment.
<xnox> mitya57: some of the things are fixed by latest python3.4 upload https://launchpad.net/ubuntu/+source/python3.4/3.4~b1-4ubuntu5 which still needs python3-defaults rebuild.
<mitya57> xnox: the Debian version of pyqt4 should build fine for multiple python3 versions (that worked in 3.2/3.3 times), but it looks like cjwatson didn't like something
<xnox> mitya57: nobody denies that it builds =) it didn't provide correct pyqtconfig, and thus pykde4 was FTBFS with not able to find/import pyqtconfig. That's as much as I know. Let me look up FTBFS build logs, if not cobbled over.
<mitya57> That's a bit more helpful, then why was it reverted?
<xnox> mitya57: i think buildlogs got overriden, but there is another upload of pykde4 to fix 3.3&3.4 compat.
<xnox> http://launchpadlibrarian.net/161093392/pykde4_4%3A4.12.0-0ubuntu1_4%3A4.12.0-0ubuntu2.diff.gz
<xnox> not sure why wgrant_ is removing ABITAG renaming =/
<xnox> ... unless that is done elsewhere / later.
<xnox> nah, looks like everything is properly abitagged in the debs.
<cjwatson> mitya57: wgrant didn't revert it, he fixed it harder
<mitya57> My main question is whether I should include cjwatson's changes in Debian or not
<mitya57> cjwatson: no, it is a revert
<mitya57> The current d/rules in Ubuntu and Debian are equivalent
<cjwatson> mitya57: I beg to differ, I've read the change and it isn't
<cjwatson> https://launchpadlibrarian.net/161093392/pykde4_4%3A4.12.0-0ubuntu1_4%3A4.12.0-0ubuntu2.diff.gz is not a revert of anything I did
<cjwatson> er whoops that's pykde4, let me recheck
<cjwatson> huh, so it is.  perhaps I made a mistake then, sorry
<cjwatson> I initially tried to get it to build with the new python-defaults and it failed, but I no longer have the log
<cjwatson> mitya57: So I guess pretend that never happened and we can sync over it next time
<cjwatson> sorry for the confusion
<mitya57> cjwatson: ok, thanks
<cjwatson> I probably got confused at some point in the six-hour build time on my laptop :-/
<xnox> cjwatson: mitya57: i think it's relevant that python-defaults & python3.4 had fixes in the mean time. E.g. it used to be correct to patch the way cjwatson did, until python-defaults/python3.4 got re-fixed.
<mitya57> You mean python3-defaults
<mitya57> Thanks for investigation!
<cjwatson> xnox: ah, could be
#ubuntu-devel 2014-01-01
<Noskcaj> Can someone review/upload https://code.launchpad.net/~noskcaj/+junk/geoclue-2.0 please? Ubuntu needs to change the source package name due to the number of packages we have that need the old API
<xnox> Noskcaj: has that been done in debian already?
<xnox> Noskcaj: geoclue 2.0 is in experimental, why do we need it in ubuntu?
<xnox> Noskcaj: it would be easier to review, if your branch was based on top of lp:debian/experimental/geoclue
<Noskcaj> xnox, I didn't know about the experimental lp branch. darkxst requested that we change source package due to API breaks
<Noskcaj> Should i change it?
<Logan_> Halp. Why isn't dh-autoreconf working to fix the ppc64el FTBFS on this library? https://launchpadlibrarian.net/161336888/buildlog_ubuntu-trusty-ppc64el.libapache-mod-encoding_0.0.20021209-10ubuntu1_FAILEDTOBUILD.txt.gz
<Logan_> https://launchpadlibrarian.net/161336929/buildlog_ubuntu-trusty-arm64.libapache-mod-encoding_0.0.20021209-10ubuntu1_FAILEDTOBUILD.txt.gz <-- And it also didn't update config.{sub,guess} for arm64?
<infinity> Logan_: Looks like it's not relibtoolising.  Perhaps the aclocal include is hand-crafted.
<Logan_> Hmm.
<infinity> Logan_: And autoreconf won't update config.{sub.guess} on projects that don't use automake.
<Logan_> It uses automake.
<infinity> Oh, it does.  Curious.
<infinity> Anyhow, I'd just back out the autoreconf change there, stick to autotools-dev, and hand-patch occurences of the libtool elf64ppc bits.
<infinity> Logan_: See, eg: http://launchpadlibrarian.net/161285599/rhythmbox_3.0.1-1ubuntu7_3.0.1-1ubuntu8.diff.gz
<Logan_> Did autoreconf not work on rhythm box?
<Logan_> *rhythmbox
<Logan_> Because I think that's a more futureproof solution than hand-patching the libtool stuff.
<darkxst> xnox, geoclue2 is needed by a number of 3.10 apps such as gnome-maps (which currently broken in archive), gnome-clocks, gnome-settings-daemon/g-c-c
<infinity> Logan_: autoreconf is definitely the more future-proof solution, and if you want to fix the upstream package to autoreconf correctly, please do.  I'm just being time/effort pragmatic here in some cases.
<Logan_> infinity: I don't mind losing the TIL on libapache-mod-encoding... wanna fix it? ;P
<Logan_> Lemme look into autoreconf for rhythm box.
<infinity> I wouldn't bother, if I were you.  A new upstream will (at some point) pick up the new libtool, and the delta can go away.
<infinity> The Debian maintainers once tried to autoreconf and ended up backing it out too. :P
<Logan_> Which package are you referring to?
<infinity> rhythmbox
<Logan_> Oh, okay.
<Logan_> My request still stands, in that case. :P
<infinity> Yeah, I'll fix up mod-encoding.
<Logan_> Many thanks!
<Logan_> I was going to say, libapache-mod-encoding isn't being updated upstream any time soon. The last release was in 2002. :P
<infinity> Logan_: Also, you forgot to run update-maintainer(1) on this upload.  Probably true for some others too.
<Logan_> Wait, I always run that...
<infinity> Oh, wait.  No.  That was me starting from the Debian base.  Nevermind.
 * Logan_ wipes the sweat off his forehead.
<Noskcaj> infinity, Logan_ Is there anything i can do to help with arm64/ppc64el ?
<Logan_> Fix FTBFSes! http://qa.ubuntuwire.org/ftbfs/ppc64el.html long lists yay
<Logan_> and http://qa.ubuntuwire.org/ftbfs/arm64.html
<Logan_> Hmm, libass. Sounds like my kind of library.
<Noskcaj> ok, and convince corsac and/or xfce upstream to update their autotools stuff
<Noskcaj> lol
<Noskcaj> i think there's a merge for it too
<Logan_> Noskcaj: I'd recommend looking at my uploads to see how I fix stuff.
<Noskcaj> will do
<Logan_> (If you want to help out.)
<Noskcaj> yeah, i've got nothing else to do
<Logan_> Go outside!
<Logan_> Don't be a loser like me.
<Logan_> Better yet, go outside AND fix ppc64el failures.
<Logan_> With a Nexus 7 running Ubuntu Touch or something.
<Noskcaj> I already have my pajamas on, so outside doesn't really work, and my brother won't let me put ubuntu on his nexus
<Logan_> Hmm, that does pose a conundrum.
<Noskcaj> :)
<Noskcaj> How would i fix https://launchpadlibrarian.net/154958763/buildlog_ubuntu-trusty-arm64.xfce4-battery-plugin_1.0.5-2ubuntu1_FAILEDTOBUILD.txt.gz ?
<Noskcaj> It doesn't look like the standard autotools fix
<infinity> It's not.
<Logan_> Hmm.
<infinity> Logan_: mod-encoding happy.
<Logan_> From a quick Google, it looks like you might need #include <unistd.h>.
<Logan_> infinity: Yayness.
<Noskcaj> ok
<Logan_> Which is there, but inside an #ifdef HAVE_SYSCTL conditional block.
<Logan_> Hmmmm.
<Logan_> ...and checking for sysctl... no
<Logan_> I feel like Sherlock.
<Logan_> Let's see how it's checking for sysctl, as arm64 should presumably have that.
<Logan_> AC_CHECK_FUNCS([sysctl]) ... well that's not helpful.
<Logan_> infinity: Any insight? :P
<infinity> Dunno.  Retrying it with glibc 2.18 before I dig.
<infinity> Nope, still fails.  Curious.
<Logan_> I think it has something to do with the sysctl check.
<infinity> Well, yes.  But curious that it fails.
<Noskcaj> Just wondering, would https://launchpadlibrarian.net/160701912/buildlog_ubuntu-trusty-ppc64el.lxsession_0.4.9.2-0ubuntu6_FAILEDTOBUILD.txt.gz just need a rebuild, since it has autoreconf already?
 * Logan_ looks.
<infinity> Noskcaj: No.
<Logan_> No. The autoreconf failed. I can fix it.
<Logan_> We'll either want to specify subdir-objects as an option or remove -Werror.
<Logan_> That's thanks to a new automake, not the ppc64el architecture.
<infinity> I'd remove Werror, that's actively hostile to the point of dh_autoreconf.
<infinity> You want errors to halt the build, but not every new warning.
<Logan_> I always have trouble deciding which to do.
<infinity> Logan_: A good rule of thumb for Werror (for both C code and autotools) is that upstream should develop with it on, but distributions should ship with it off.
<Logan_> Gotcha. I'll keep that in mind for the future.
<infinity> Logan_: Upstreams should try to release code as clean as they can, but making me stop and fix every warning on every rebuild with a slightly different toolchain is insanity.
<infinity> Logan_: That said, when an upstream is very fastidious about the cleanliness of their code *and* is very open to patch submissions (the latter being a big deal), I don't mind fixing and pushing the patch.
<infinity> But it's a huge time sync to do it for every project every few months.
<infinity> sink*
<Logan_> Noskcaj: Uploaded a new lxsession with a fix.
<Noskcaj> Logan_, thanks
<infinity> Oh, hrm, midnight happened here and I didn't even notice.
<infinity> Happy 2014.
<Logan_> So unfestive.
<Noskcaj> happy 2014 infinity
<Logan_> It's been 2014 here for two hours, 15 minutes and counting. :P
<Noskcaj> 18 hours, 16 min here
<infinity> I had been planning to celebrate on the east coast.  So, yeah, I noticed when you ticked over, not when I did. :P
<Logan_> yay east coast
<Noskcaj> what is the normal error for just needing autoreconf?
<Logan_> also CDBS needs to die a long and miserable death
<Logan_> Noskcaj: for ppc64el? missing *.so
<infinity> Noskcaj: For ppc64el, it's generally that autoconf complains that the linker doesn't support shared libraries.
<Logan_> during dh_install
<Logan_> or that
<Logan_> mostly the one I mentioned
<Noskcaj> ok, thanks
<infinity> Noskcaj: Which can fail early, or can make it all the way to dh_install before noticing there's no .so
<Logan_> it often doesn't fail early, unfortunately
<Logan_> I'd say 90% of the packages I've fixed so far fail at dh_install
<infinity> (But in either case, you'll see the autoconf message in configure saying "checking if ld supports shared libraries... no"
<Logan_> Noskcaj: you can throw a debrief at me if you want to see if you're doing things right, since you can't test locally
<Logan_> friggin autocorrect
<Logan_> debdiff*
<Noskcaj> Logan_, For anything complex, will do
<JackYu> happy new year, every one!
<xnox> darkxst: right, there are 10 packages using geoclue at the moment, it would be nice to test-rebuild all ten of them against geoclue 2.0 and get them ported if porting is needed & simply sync over geoclue.
<xnox> darkxst: and please email ubuntu-devel about it, instead of doing it on irc.
<xnox> (one might be a duplicate) so 9 in total only.
<xnox> darkxst: http://paste.ubuntu.com/6672991/
<xnox> darkxst: oh, since it's DBus there might be much more users....
<xnox> Laney: is the code search active to do a geoclue search?
<xnox> darkxst: is it just me, or geoclue 2.0 API offers a lot less than 0.x did ?
<Laney> xnox: http://162.213.35.4/
<xnox> darkxst: yeah there are a few more.
<xnox> darkxst: it's best to not diverge from debian here, and request for geoclue 2.x to be packaged in-parallel to 0.x series there as well and have matching source package names.
<xnox> Laney: http://ubuntu-codesearch.surgut.co.uk/ =)
<Laney> neat
<alkisg> Happy new year to all
<alkisg> stgraber: can we sync LTSP 5.5 from unstable so that we have more time in testing/fixing things? Or do we have to wait until it migrates to testing?
<labsin> Hi all, I'm trying to cross-compile my ubuntu touch app.
<labsin> I've found the mailinglist post [Cross-compile with CMake from SDK Apps to Unity8/Mir]https://lists.launchpad.net/ubuntu-phone/msg05556.html
<labsin> but I can't seem to get it right...
<darklight_> Is someone working on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/775434 ? Having the meta+"numbers" shortcut hardcoded is making unity a living hell for me
<ubottu> Ubuntu bug 775434 in unity (Ubuntu) "Keyboard shortcut - Make Unity keyboard shortcuts configurable" [High,Triaged]
<Noskcaj> Does arm64 have to use gles2 like armhf does?
<infinity> Noskcaj: Not currently, though we may have to make that switch in the future.
<Noskcaj> ok, then i trust my evas merge slightly more.
<darkxst> xnox, geoclue 2 is a completely new API that is not at all compatible with the old version
<darkxst> and there will be rdepends that use features not in geoclue-2
<xnox> darkxst: ok. then it really should be introduced as a new src package in both debian and ubuntu. Can you ask for it to be a new src package in Debian?
<xnox> darkxst: since it's already packaged as same src in experimental....
<darkxst> I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733901
<ubottu> Debian bug 733901 in geoclue "geoclue: package geoclue-2.0 in parallel to geoclue 0.12.99" [Normal,Open]
<Noskcaj> What do i have to do to fix http://paste.ubuntu.com/6675509/ ? It only occurs with autoreconf turned on
<xnox> Noskcaj: that doesn't look like a complete log. look truncated on the top.
<Noskcaj> xnox, Does it need to have the stuff above?
<xnox> Noskcaj: yeah.... the error is on the top, and then debhelper cat config.log to standard output which is a big pile of poo =)
<Noskcaj> http://paste.ubuntu.com/6675520/ is the entire build
<xnox> Noskcaj: line 129/130
<Noskcaj> ok. Now i will do a lot of googleing to find what is wrong.
<xnox> Noskcaj: IT_PROG_INTLTOOL macro was unknown at the time you did autoreconf, so probably simply a built-dependency is missing of a package which provides that autoconf macro....
<Noskcaj> so intltool?
#ubuntu-devel 2014-01-02
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<YokoZar> slangasek: pitti: kees: infinity: stgraber: mdeslaur: congrats
<YokoZar> lool: bdrung_: SpamapS: mterry: sorry :)
<YokoZar> ^^^ Tech board election results
<mdeslaur> YokoZar: thanks!
<darkxst> xnox, could you take a look at gsettings-desktop-schemas and gnome-themes-standard during your shift?
<xnox> darkxst: i don't usually do any DE/gnome/desktop things, unless i really know that it doesn't have negative effects across all flavours. Somebody more clued on those components would be better to review/merge those. E.g. Laney / seb128
<xnox> darkxst: althought gsettings-desktop-schemas looks reasonable.
<darkxst> xnox, gnome-themes-standard just has a handful of minor gtk fixes in the highcontrast theme (which all the other flavors use)
<darkxst> and it fixes alot of theming issues in Adwaita
<darkxst> but anyway will check with Laney or seb128
<xnox> darkxst: looking into gnome-themes-standard, i wonder what the lock screen changes are. (background keys?!)
<darkxst> xnox, not sure what changes you mean, however the lock screen is gnome-shell only
<xnox> darkxst: right. will test the package more and then upload.
<darkxst> thanks
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xnox> @pilot out
<Apteryx> Hi there. Could someone tell me what is the general user case of the bluetooth applet operation?
<Apteryx> If I turn bluetooth off from the applet, the icon disappears and the interface goes down. Good. "service bluetooth status" reports that it is still running.
<Apteryx> Now what I am suppose to do to bring it back ON?
<Apteryx> I guess the designed way is to go to "Settings -> Bluetooth" and there turn the swith ON.
<Apteryx> The switch turns ON, but the interface stays down in my case, as reported by hciconfig.
<Apteryx> Is this hardware specific? My bluetooth interface is provided by the Atheros AR3011 chip.
<SpamapS> YokoZar: hah, thanks for the consolation. Though I'm not on the TB, I think the results came out _wonderfully_. :)
<SpamapS> Truth be told I'm a bit relieved. It is a big responsibility.
<YokoZar> SpamapS: If you want to stage a coup, let me know.
<slangasek> YokoZar: thanks!  is there any more official announcement of this? :)
<YokoZar> slangasek: Usually pleia2 puts out something on the Fridge and such, I imagine she'll do that tomorrow after the CC meeting
<slangasek> ok
<stgraber> YokoZar: thanks!
<darkxst> Logan_, was there some reason why you disabled JS support in mediatomb?
<caribou> xnox: you have marked the merge of backuppc as "please take"
<caribou> xnox: I'd like to get some more merge experience, could it be a good idea for me to work on this one ,
<caribou> ?
<xnox> caribou: sure, although Logan_ was the last one to merge it "properly". I'll certainly can review your work for correctness.
<caribou> xnox: I'll check with Logan_ first, in case he's started to work on it
<caribou> xnox: how about the php5 one ?
<caribou> xnox: looking at it, mostly done
<xnox> caribou: it's non-trivial. I giving up some of the merges, because i don't feel comfortable merging them.
<caribou> xnox: ah, ok I see
<xnox> caribou: if you are looking into something to do really good things (and easy) to fix are http://qa.ubuntuwire.com/ftbfs/ppc64el.html and http://qa.ubuntuwire.com/ftbfs/arm64.html
<xnox> caribou: typically it needs enabling dh-autoreconf (and sometimes dh-autotools-dev), such that config.guess/.sub and libtoolize are updated during builds.
<caribou> xnox: ok, I'll look at it
<caribou> xnox: is there an "easy" way to test those builds locally (i.e. w/o having some ARM H/W) ? Can sbuild do that ?
<rbasak> caribou: https://www.stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/ might work for you
<caribou> rbasak: thanks, will try that
<rbasak> I've never tried it with sbuild though :)
<rbasak> However, for sbuild, it might be possible to just use qemu-user-static actually.
<xnox> caribou: well, those fixes are needed on arm64/ppc64el for which emulators might not be stable (or exist) or be slow.
<rbasak> I imagine you can set up a chroot with qemu-user-static installed, and then everything should just work. But I'm not sure if mk-sbuild can do that for youj.
<xnox> caribou: in practice, it trains trianging the type of build failure and fixing it. E.g. if configure says that it can't determine system machine time, then config.guess/.sub need updating (preffered with dh-autoreconf, dh-autootools-dev if doesn't work)
<rbasak> Not sure of qemu status with ppc64el. AFAIK qemu-user-static for powerpc is pretty broken.
<xnox> caribou: and check locally that during build, config.guess timestamps are updated =) and all of them.
<xnox> caribou: and e.g. grep for the arm64/ppc64el gnu triplets in the update config.guess/.sub.
<xnox> caribou: for ppc64el, one often needs dh-autoreconf to update libtool, as otherwise the build log will have "libtool supports shared libraries... no" or some such and weird build error at the end with "dh_install can't find *.so" or static linking of some binaries fails.... because well it wasn't detected correctly that shared linking is available and is the only one support.
<caribou> xnox: still, as for ftbs on amd64/i386 I need to be able to test the build locally
<caribou> xnox: I've done a few of those already, but never on arch other than amd64/i386
<xnox> caribou: sure, but the links i gave you, most of the packages do build correctly on i386/amd64/armh/powerpc. It's just the new ports that need enablement.
<xnox> caribou: and it's better to have a FTBFS with a real arch-specific bug, instead of the "config.guess is out of date, abort"
<caribou> xnox: true, but I still need to be able to test the build to find out, isn't it ?
<caribou> xnox: at least test the fix
<xnox> caribou: well sure, you need to make sure that the package still builds after autoreconf is enabled, and verify that config.guess/sub is updated, and libtoolize is executed (if applicable)
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<shadeslayer> is there any news on a bluez5 migration?
<infinity> shadeslayer: Which news were you hoping for?
<shadeslayer> Any blueprints or any ongoing work to package Bluez5?
<infinity> It's been packaged in Debian experimental, though no activity there since May.
<infinity> No idea if anyone's dicussed and/or committed to doing the work in Ubuntu.
<shadeslayer> well, on the KDE side, the powerdevil 1.x series will be EOL soon
<shadeslayer> and only the 2.x series will be supported
<shadeslayer> which in turn depends on Bluez5
<infinity> Sure.  I suspect some effort needs to be put in to testing (and possibly porting) all the rdeps.
<mitya57> doko: What should be done in qtchooser re bug 1209239?
<ubottu> bug 1209239 in qtchooser (Ubuntu) "MultiArch support for QT5 is insufficient for cross building" [Undecided,Confirmed] https://launchpad.net/bugs/1209239
<shadeslayer> infinity: only 46 reverse deps ... right :D
<caribou> following my previous discussion with xnox, does someone have a suggestion on how to setup an environment to test builds on arm64/ppc64el ?
<infinity> caribou: For arm64, you could try https://wiki.debian.org/Arm64Qemu
<infinity> caribou: But most of the bugs people need to fix (config.{sub,guess} updates and libtool macro updates) can be easily tested for correctness on any arch.
<xnox> mitya57: that's rather for me, rather than doko. qtchooser demands & searching for native arch qt installation, instead of guessing / using native tools without a full native qt installation.
<infinity> caribou: Sure, the build *might* fail later for other unrelated reasons, but history has shown that's only likely in about 1/100 such uploads.
<xnox> mitya57: e.g. the dreaded "can't find qt installation" should be resolved, such that it always finds native qt-tools, even though native qtbase-dev is not installed.
<caribou> infinity: ok, thanks I'll look at that
<caribou> infinity: I already found apw's blog post on using ARM64 Foundation mode
<infinity> caribou: The Foundation Model is certainly going to give you the most correct results.  But it's sloooooow.
<caribou> infinity: yeah, I noticed that already
<infinity> caribou: But, honestly, for most of these uploads, you shouldn't need to build on the tagret hardware to know that what you're fixing is correct.
<infinity> caribou: If you do need to build on target hardware to see the fix in action, there's a fair chance you don't understand the fix.
<caribou> infinity: that could happen as well ;-)
<infinity> (Again, discounting the 1% of the time when things need actual porting)
<caribou> infinity: but then, if the FTBS is not arch specific, it should fail on the other arm builds as well
<rbasak> I've never felt confident uploading without doing at least a build test to check a fix. It's a way of checking my own work.
<infinity> rbasak: I always build-test on *some* arch. :)
<mitya57> xnox: Right, thanks. I think opening a bug upstream makes sense.
<rbasak> If it's an arch-specific issue, I check two arches.
<infinity> But for autotools type updates, I'm happy to build-test on x86, and spot-check that the update machinery did what I wanted.
<mitya57> (does qtchooser have a bugtracker???)
<rbasak> I guess I'm not confident enough with autotools for that.
<infinity> rbasak: Well, that goes back to "understanding the fix". :)
<rbasak> I think there's a difference between thinking I understand the fix, and knowing that I understand the fix.
<infinity> rbasak: If you're not confident with the autogenerated code, I'm not sure how "it accidentally worked on two arches" is any better than "it accidentally worked on one".
<caribou> infinity: rbasak: which goes back to my assertion that if it's not arch specific, it should ftbs on more than one arch build
<xnox> mitya57: yeah, i was going to get to that soon. But am busy with touch-emulator work at the moment.
<infinity> caribou: Sure, but you're trying to fix arch-specific issues here.
<caribou> infinity: simply because xnox pointed be to a bunch of ftbs on amd64 qa page
<caribou> s/be/me
<xnox> caribou: well i pointed to both ppc64el, arm64. And I has _explicit_ that you do _not_ need to test build on arm64/ppc64el.
<infinity> Not for autotools mangling, anyway.
<infinity> Not if, like I said, you understand the fix and how to spot-check that it's correct.
<caribou> xnox: yeah, I got that as well, but then when I looked at some failures, they did not relate to what you described
<caribou> xnox: so I got further in the arm64 specific builds
<xnox> caribou: note, that a test build on amd64 is sufficient as long as you verify that: you are fixing config.guess/libtool issues, and that package does update config.guess/libtoolize correctly during any build (e.g. amd64 is sufficent)
<xnox> caribou: step one was to find those that are that issue =) most of them are in the universe section ;-)
<infinity> caribou: There are, of course, a hundred or so failures on x86 too, you could look at those. :P
<xnox> caribou: main is mostly fixed now.
<caribou> infinity: that's what I did last week :)
<xnox> caribou: and there is more chance on the ppc64el page ;-)
<caribou> xnox: infinity: bottom line is : many of those are good ground for me to learn tons of things
<rbasak> xnox, mdeslaur: FYI, I'm planning on merging apache2 and php5 this week.
<rbasak> Any objections?
<xnox> rbasak: yes please. =) you know how to test all of that stuff properly.
<rbasak> xnox: indeed. I run the dep8 tests I wrote :-P
<rbasak> I think there are a bunch of bugs that can be trivially fixed with a merge, too, which I'll sort out at the same time.
<mdeslaur> rbasak: no objections from me!
<mdeslaur> :)
<xnox> rbasak: omg, you have Technical Board member blessing for that work. You are totally invincible now ;-)
<mitya57> Can anybody please upload a python-apt rebuild (for python3.4)?
<mitya57> (Builds fine in a PPA)
<Laney> tkamppeter: your poppler uploads broke ABI
<Laney> xpdf is busted now
<Laney> & evince
<tkamppeter> Laney, in which point did they break ABI, perhaps I can get fixed patches.
<Laney> ubuntu5 it seems
<Laney> PSOutputDev::PSOutputDev(char const*, PDFDoc*, char*, int, int, PSOutMode, int, int, bool, bool, int, int, int, int, bool, bool, GooString* (*)(PSOutputDev*, PSOutCustomCodeLocation, int, void*), void*)
<infinity> Quite, yes.
<infinity> tkamppeter: As a general rule, a patch that changes a function prototype is going to break ABI...
<infinity> Were these backports from a new upstream version?
<infinity> Perhaps we just want the new upstream and an SOVER/ABI transition.
<tkamppeter> Laney, I will ask upstream whether one can do it without breaking ABI. The patches are from upstream. It is https://bugs.freedesktop.org/show_bug.cgi?id=72312.
<ubottu> Freedesktop bug 72312 in utils "[patch] pdftops: Fixes/improvements for -origpagesizes" [Normal,New]
<infinity> Note that if you back out the ABI breakage, you'll also have to rebuild anything that build agaist the library post-breakage.
<infinity> If we don't plan to take a new poppler soon, you should really just back out those patches *now* before the ABI break leaks any further.
<infinity> And then sort out how to fix it differently.
<infinity> tkamppeter: ^
<Laney> The changes aren't even committed upstream yet
<Laney> AFAICS
<infinity> Yeah, then definitely please back them out.
<infinity> And then hunt for rdeps that were built against the new ABI, so we can rebuild them.
<tkamppeter> Laney, infinity, I have informed upstream now asking them to find a solution without ABI change. I will step back to the state before these upstream changes.
<infinity> tkamppeter: For upstream, an ABI break is fine.  They break ABI in poppler constantly.
<infinity> tkamppeter: But we *can't* backport that to our current package, that's all.
<infinity> Oh crap.
<infinity> Everything that depends on poppler in ppc64el is probably broken.
<infinity> Oh, I guess it's not that many things anyway.
<infinity> But yeah, we might have to rebuild all of poppler's rdeps after you fix it, just to be on the safe side.
<infinity> I'll look at that more closely when I get back from lunch.
<mitya57> We may want poppler 0.24.5 or 0.25 (both have different abis from 0.24.4)
<mitya57> There is a bug somewhere with my debdiff for 0.24.4->0.24.5 attached
<Laney> you mean .3 -> .4 I guess
<mitya57> Err, yes, of course
 * mitya57 puts the time machine back
<mitya57> And, actually, the tkamppeter's change and .3->.4 changes are unrelated :(
<Laney> yeah, that's what we observed just now
<Laney> Maybe they could be cherry-picked to the 0.24 series once committed to 0.25 for .5 which we could take, or something.
 * mitya57 needs some sleep, will be able to help with poppler tomorrow
<mitya57> (I am also in process of forwarding our changes to Debian)
<tkamppeter> infinity, Laney, I have now uploaded poppler -0ubuntu12, reverting to my patches which I have created to fix the bugs and proposed upstream. They do not have any ABI changes.
<infinity> doko: Bah, syncing Debian's differently multi-arched tk/tcl broke upgrades.
<doko> infinity, in which way?
<infinity> doko: 8.6 needs the same fix you applied to 8.5
<doko> ahh, you mean the replaces for tcl-lib?
<infinity> doko: I'll do it right now, unless you want to be TIL on tcl/tk
<infinity> doko: Yeah.
<doko> no, please go ahead
<doko> looking at the ruby2.0 ftbfs now ...
<doko> https://launchpadlibrarian.net/161446482/buildlog_ubuntu-trusty-amd64.ruby2.0_2.0.0.353-1build1_FAILEDTOBUILD.txt.gz
<doko> infinity, ^^^ tries to link -lieee twice, and then complaining about a duplicate symbol from the same library?
<infinity> doko: Works on ARM and PPC, time to ditch x86 from the archive.
<doko> infinity, fails on armhf too, looks like glibc complains
<doko> ahh, no, it's the test_gc testcase
<infinity> doko: Why is it linking that statically at all?
<infinity> doko: The previous build seems to be linking -ltk8.5
<infinity> doko: Did the library shuffling lose the .so -dev symlink for tcl/tk?
<doko> infinity, enoclue yet, it has -DSTATIC_BUILD on the command line
 * infinity looks closer.
<infinity> lrwxrwxrwx 1 root root      11 Jan  1 23:28 /usr/lib/x86_64-linux-gnu/libtk.so -> libtk8.6.so
<infinity> -rw-r--r-- 1 root root 1392528 Jan  1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so
<infinity> lrwxrwxrwx 1 root root      11 Jan  1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so.0 -> libtk8.6.so
<infinity> Well, that's backwards... But should still work.
<doko> still has the /usr/lib/x86_64-linux-gnu/libtcl.so symlink
<doko> and it build ok locally
<doko> but doesn't link with -lieee locally
<infinity> It builds fine locally?
<infinity> With current tk-dev?
<doko> yes. rechecking on osageorange
<infinity> So, -lieee is from tkConfig.sh *but*, it was there in 8.5 too.
<infinity> And I suspect only shows up on static builds.
<infinity> So, my guess is that your local build didn't do the static thing, for whatever reason.
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> doko: Fails locally here.  I wonder what you've done to make your computer like it.
#ubuntu-devel 2014-01-03
<infinity>   %w[8.5 8.4] # At present, Tcl/Tk8.6 is not supported.
<infinity> doko: ^-- That's the problem.
<infinity> doko: Okay, so maybe that's *a* problem, but not *the* problem.
<infinity> doko: Though, even ruby trunk claims to not support anything >> 8.5, so I think this is a lost cause, and it should just build-dep on 8.5
<infinity> doko: Was there a reason other than "new shiny" to bump the tcltk-defaults ahead of Debian?
<doko> infinity, well, I was trying to get the interpreter languages up to date ... things like ocaml did block, didn't expect that many issues with tcl/tk
<doko> ruby is the only failing one for now in main
<xnox> infinity: doko_ : i distinctly remember multiarched-tktcl patches required to build ruby2.0 against multiarched tcltk... have those been applied? /me looks
 * xnox did ask ruby maintainer to do so at debconf....
<xnox> right those did get merged.
<xnox> horum.
<xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733372
<ubottu> Debian bug 733372 in src:ruby2.0 "ruby2.0: FTBFS: ossl_ssl.c:2179:65: error: 'SSL_OP_MSIE_SSLV2_RSA_PADDING' undeclared (first use in this function)" [Serious,Open]
<xnox> upstream does claim 8.6 is not supported... http://bugs.ruby-lang.org/issues/8000
<xnox> bdmurray: i've uploaded a fix to apport (ubiquity hook) and adt test has failed, with loads of errors of: FileNotFoundError: [Errono 2] No such file or directory: for apport-upack, apport-valgrind, crash-digger. I'm not sure if that's something I have caused, or how to resolve / fix the adt test.
<xnox> bdmurray: any ideas?
<xnox> pitti is not online.
<zyga> any X person here might know why I still need to edit xorg.conf in 2014? Is this something that we can convert to a better (but sensible) default? https://plus.google.com/116315264177593873442/posts/WhF9anC2mow
<xnox> zyga: weird, i didn't have to do anything like that with my dual or tripple head setups with all my laptops/desktops. Granted all of them are intel.
<xnox> zyga: on the latest laptop I did have to set xorg settings to get the brightness working.
<rbasak> zyga: I had to do that for dual-head support on an ancient laptop. How old is your hardware?
<xnox> (keys that is)
<zyga> xnox: this is A8 apu, current gen, with fglrx as open source drivers resulted in heavy corrpution all the time
<zyga> rbasak: brand new
<zyga> rbasak: this A8 richland APU
<zyga> rbasak: with two screens
<zyga> rbasak: one is 2048 another 1024 in width
<zyga> rbasak: apparently the default is 2048 max horizontal resolution
<zyga> rbasak: I tried with two smaller screens and it worked out of the box
<zyga> rbasak: using DVI and VGA outputs, nothing fancy
<rbasak> zyga: sounds like a bug to me. Though I'm not familiar with things that happened in X since the days of XFree86 :-/
<zyga> (this is a desktop, not a laptop)
<zyga> I recall reading that some GPUs have a limit on the max texture size, so large screens would not work with something like unity
<zyga> but this was last on i915 or something like that
<zyga> asac: hey, any chance for plainbox MIR review? :-)
<apw> cjwatson, am i right in thinking that grub2 no longer has 'trigger' support ?
<cjwatson> apw: AFAIK it never did
<apw> cjwatson, no longer compared to grub1 ... would it be something we would like if i can be bothered ?
<infinity> apw: How would triggers be any better than /etc/kernel/postinst.d/zz-update-grub ?
<apw> infinity, when you install or remove 3 kernles at once you would only run it once
<infinity> apw: Oh, sure, one could turn zz-update-grub into a trigger wrapper like ldconfig, or do something more clever entirely.
<infinity> Not that update-grub takes long to run.
<apw> it does take quite a while if you have more than a few kernels installed, and right now twice per kernel
<infinity> Is it uncouth to eat a wheel of brie on its own because it's the only food you have?
<cjwatson> apw: maybe, yeah
<cjwatson> though the postinst is pretty complicated as it is
<cjwatson> but it would be nice to speed all that up a bit, I agree
<infinity> apw: Anyhow, using something like /sbin/ldconfig as a cheat, you could just add a few guards to zz-update-grub, register the trigger, and call it done.
<infinity> Not that I'd recommend that as the best way forward, it was just the easiest way to do ldconfig without forcing all its users to adapt.
<cjwatson> The GRUB Legacy trigger work never went into Debian, apparently.  This would need to (I don't want to have an Ubuntu delta for grub2 again).
<cjwatson> I don't think it was very complete either - it didn't auto-trigger on things running update-grub, it just supplied an explicit trigger, which isn't as good an approach
<cjwatson> infinity: Probably not necessary here.  Adjusting zz-update-grub would do most of the work.
<apw> cjwatson, no indeed, they said they wanted the equivalent of our grub1 work in grub2, but ... its not there indeed
<cjwatson> It was in the Ubuntu package but was never merged back
<infinity> cjwatson: Well, you could guard zz-update-grub or update-grub itself, depending on the desired outcome.
<cjwatson> As far as it went, anyway
<infinity> Guarding update-grub and registering an update-grub interest would probably do the trick without having to touch any callers.
<cjwatson> infinity: Sure, either would work
<cjwatson> Indeed, update-grub is already a wrapper script
<cjwatson> So it would probably be logical to put it there
<apw> yeah
<apw> so if i do somethign comprehensive in that manner, it should be mergable back to debian pretty well i assume
<infinity> Something like guarding update-grub and an interest trigger would be very mergable back because, like I said, no need to update callers.
<infinity> And /sbin/ldconfig /var/lib/dpkg/info/libc-bin.triggers probably have the three lines of hints required to make that work.
<apw> infinity, ok cool i'll likely poke at it and get with you on the details
<infinity> Probably don't need the NOTRIGGER hack, since grub triggering itself isn't nearly as vile as libc6 triggering ldconfig.
<apw> i am mostly interested in fixing the update initramfs mess -extras have made
<infinity> update-initramfs is a whole different story...
<apw> infinity, but i see ... we still have your 'hacked merge' in here
<infinity> Yeah, I'm fixing that this week. :)
 * apw will wait till you fix that then
<wachin> Good day to all Ubuntu Developers
<wachin> On my operating system UbuntuSTudio 13.10 is installed Nautilus 3.8.2 and the search feature is not helping me. I ask you to please leave it as it was before in Nautilus 3.4.
<wachin> Consider that only for this reason many people will go to Linux Mint, it is not convenient
<rbasak> We're supposed to keep all quilt patches refreshed on an upload right? So if I see offsets in an Ubuntu-delta patch while merging, I should refresh it?
<xnox> rbasak: not necessory, the only dpkg requirement is to have no "fuzz", but offsets are ok.
<rbasak> xnox: good to know, thanks. What's best practice? Leave it alone?
<xnox> rbasak: plus if one uses options different from debian maintainer, one can easily generate very large diff because like timestamps are removed or "a/:b/" are renamed to "foo/:foo.old/" etc....
<xnox> rbasak: i tend to go for minimal diff possible, and thus i don't refresh patches unless i have to (e.g. to get rid of fuzz)
<wachin> and I read several posts, many people complaining for this reason.
<wachin> And I read in a post that is people who complain, developers will do nothing
<rbasak> wachin: have you checked to see if these changes are coming from upstream, or from Ubuntu developers?
<wachin> I have tried to put myself in your place, to understand why this happened, I understand that you can use it to 3.8 or 3.6 nautilus efficient way for their activities. But for the normal user that is not a help. Nautilus 3.4 are best
<wachin> No I'm not know how to that
<rbasak> It sounds to me that upstream are making changes that you don't like, and Ubuntu developers are stuck in the middle.
<wachin> I am a Spanish parlant. In the #Ubuntu chanel guide to here
<xnox> wachin: this is not an appropriate forum to raise those concerns. #ubuntu-devel is for ubuntu core platform development. And e.g. nautilus is a single packaged shared by Ubuntu, Ubuntu Gnome, Ubuntu Studio etc. There are many file managers available, and you are free to install any you like.
<xnox> wachin: if you want to change the defaults in any of the distos, please talk to developers/leads of those distros, e.g. ubuntu-studio.
<xnox> wachin: or email ubuntu-devel-discuss mailing to reach all interested parties.
<wachin> Ok
<xnox> wachin: such things are never revert based on "demands" or "cries out" on irc. that is not productive technical discussions.
<wachin> Ok xnox, I understand
<wachin> Do you know how to I  can write to the team that set nautilus 3.6 -3.8 on Ubuntu
<rbasak> wachin: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
<xnox> wachin: ubuntu-devel-discuss mailing list.
<wachin> Thanks rbasak
<zyga> mterry: hey, what did you mean by "Package needs a team bug subscriber", I cannot see any bug controls on the source package page and the upstream project already has a team subscribed
<xnox> zyga: which package?
<xnox> zyga: typically same team should be subscribed to distro bug mail as well.
<zyga> xnox: plainbox MIR request: https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1265754
<ubottu> Ubuntu bug 1265754 in plainbox (Ubuntu) "[MIR] plainbox" [Undecided,Incomplete]
<zyga> xnox: see mterry's comment on that bug
<xnox> zyga: on https://launchpad.net/ubuntu/+source/plainbox there should be "+ Sbuscribe to bug mail" on the right.
<xnox> zyga: and you should subscribe, e.g. plainbox-team to it.
<zyga> ah
<zyga> ok, I get it now
<zyga> thanks!
<mterry> zyga, yup
<mterry> xnox, thanks
<mterry> zyga, that's just so that when bugs get filed in Ubuntu, they don't go into the void
<zyga> mterry: that's a very good point, I just didn't understand how that works
<zyga> mterry: I'm filing a bug on the autopkg test issue you found and I'll get it fixed in Debian
<zyga> mterry: do you think we should wait for -3 to hit Ubuntu before that MIR can be reconsidered?
<mterry> zyga, if you're trying to promote right now, I can approve the MIR as long as the test fix is in the works
<zyga> mterry: I'll show you commited -3 in debian SVN and then we can decide, ok?
<mitya57> mterry, barry: while we are speaking about the teams: do you think we can subscribe ~ubuntu-pythonistas to jquery* bugs? Or do you know any better team?
<mterry> mitya57, is that a real team?
 * mitya57 notices that jquery itself has ~ubuntu-foundations-bugs subscribed
<mitya57> bdmurray: can we please have ~ubuntu-foundations-bugs subscribed to 4 packages mentioned in bug 1261149?
<ubottu> bug 1261149 in libjs-jquery-isonscreen (Ubuntu) "[MIR] jquery-goodies, libjs-jquery-{hotkeys,isonscreen}" [Undecided,Incomplete] https://launchpad.net/bugs/1261149
<zyga> mterry: http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=26981
<mterry> zyga, approved, thanks!
<zyga> mterry: awesome, thanks
<bdmurray> mitya57: okay
<rbasak> bdmurray: could you take a look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1178245 please? danwest just experienced it. The last comment looks like a good explanation to me; on the surface, anyway.
<ubottu> Ubuntu bug 1178245 in ubuntu-release-upgrader (Ubuntu) "missed python-apt dependency" [Undecided,Confirmed]
<mitya57> mterry: there are three members ;)
<bdmurray> rbasak: ah, okay.  do you know what kind of install (for testing) the upgade was being attempted from?
<mitya57> mterry: note that I am subscribed to those packages anyway
<rbasak> bdmurray: no, but I'll ask danwest to join this channel.
<mterry> mitya57, yeah and that is useful.  But teams provide some long-term security in case you get hit by a bus  :)
<danwest> bdmurray: testing upgrade from raring to saucy (armv71)
<bdmurray> danwest: what kind of install was the raring system?
<danwest> bdmurray: kind? server - is that what you were looking for?
<bdmurray> danwest: yes
<danwest> k
<bdmurray> danwest: so it was a server install?
<danwest> bdmurray: yes, I believe so - let me verify
<danwest> bdmurray: this was the image -> https://rcn-ee.net/deb/rootfs/raring/ubuntu-13.04-console-armhf-2013-12-17.tar.xz
<bdmurray> danwest: okay, thanks
<infinity> danwest: Really, a third party image? :P
<infinity> (I guess this was on something we don't support, like a BBB?)
<danwest> infinity: yup beagle bone black
<danwest> nice little MAAS server I hope
<mitya57> bdmurray: thanks
<mitya57> mterry: better now?
<infinity> bdmurray: Seems fairly obviously just a fundamental issue with the py2->py3 transition, where do-release-upgrade and the release-upgrader tarball are of different vintages.
<mitya57> doko_: Can you please test if the aarch64 atomics patch can be dropped from qtbase?
<mitya57> <hrw> mitya57: you do not need qatomics stuff for 5.2
<mitya57> <hrw> mitya57: in other words: 5.2.0 qtbase builds out of box for aarch64
<mitya57> Mirv: ^ also FYI
<mterry> mitya57, approved, thanks!
<mitya57> mterry: thanks!
<chiluk> what are the conditions that prevent me from changing a bug to won't fix?
<jtaylor> has python3.4 changed something in their shared library extensions again?
<xnox> jtaylor: compile flags.
<xnox> jtaylor: but i don't know if that was fixed / reversed or not.
<jtaylor> you mean the -Wdeclaration-without-statement thing?
<jtaylor> I mean file extensions of c libraries
<jtaylor> I get a test failure in the source tree but not on install tree (after dh_python3 ran and possibly reverted it?)
<jtaylor> 3.4 only
<mitya57> Mirv: by the way, any news on Qt transition?
<bdmurray> chiluk: probably not being an uploader of the package or not in ubuntu-bugcontrol
<chiluk> bdmurray I'll apply now.
<xnox> jtaylor: i had some 3.4 failures, where some of my deps were missing 3.4 modules.
<xnox> jtaylor: do you have build-log?
<jtaylor> no I'm just running the build again thistime with shell hook to look into it
<jtaylor> just asking if someone knows something
<jtaylor> great it really changed again
<jtaylor> ffs
<jtaylor> and the interface it provides gives wrong results
<jtaylor> might be an ubuntu change
<jtaylor> doko_: is the multiarch SOABI accessible somehow?
<jtaylor> python3.4 only
<mitya57> So... When built against a mix of Qt versions, python3-pyqt5.qt{serialport,sensors} .so files are empty
<mitya57> I.e. ldd says they are not linked dynamically to anything
<doko_> mitya57, should be SOABI-$(DEB_HOST_MULTIARCH)
<mitya57> doko: ENOPARSE, where is the issue?
<mitya57> s/doko/doko_/
<cjwatson> I think doko_ maybe intended to address that to jtaylor
<jtaylor> doko_: from within python
<jtaylor> use the _multiarch?
<jtaylor> also special case it for 3.4 and not 3.3?
<doko_> and it's 3.3 and 3.4
<jtaylor> 3.3 works fine
<jtaylor> shouldn't python itself be fixed instead of the modules?
<jtaylor> by having SOABI not be wrong for what it is used outside of ubuntu
<jtaylor> ok 3.3 has the same problem but only after running dh_python3
<doko_> jtaylor, well, we still want this as the default for people building extensions not only for the distribution
<doko_> the renaming is distro specific. I know, it will break for a handful of packages
<doko_> mitya57, ahh, qtbase, yes will start a build
<mitya57> Danke!
<jtaylor> so what should upstream do if they want the abi tag?
<jtaylor> check if running on ubuntu?
<tedg> It seems that "ubuntu-bug" doesn't work to file a bug on a package.  What has that changed to?
<doko_> jtaylor, get the EXT_SUFFIX, that's the suffix you use without --install-layout=deb
<tedg> Seems apport-cli -f -p works
<jtaylor> doko_: that doesn't have the multiarch parts
<jtaylor> also unreliable, but thats a different story
<doko_> jtaylor, yes, that' what I said
<jtaylor> what if I want to find packaged modules?
<doko_> somewhere there is a list of extensions the interpreter understands
<doko_> ?
<doko_> anyway, later, have to run
<jtaylor> I guess this should work until python3.5 http://paste.ubuntu.com/6686728/
<tarpman> hi! while working on bug 937200 I found an odd behaviour wrt fontconfig, ubuntu font, and unfonts: https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/937200/comments/62 Can anyone help me figure out whether that fc-match behaviour is buggy, and if so which package is responsible?
<ubottu> Ubuntu bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Confirmed]
<sbeattie> doko_: do the regular buildds install recommends? I had a daily ppa build just fail on trusty because the split out libtool-bin package didn't get installed from the build dependency on libtool.
<stgraber> (trusty-amd64-sbuild)ubuntu@lxc-testing01:/$ grep -ri recommend /etc/apt/
<stgraber> /etc/apt/apt.conf.d/99buildd:APT::Install-Recommends "0";
<stgraber> sbeattie: ^
<sbeattie> stgraber: okay, so are we expected to add an explicit build dependency on libtool-bin?
<stgraber> unless libtool can't function without libtool-bin which would then make the Recommends a bug and should have it promoted to a Depends
<nemo> heh. you know, I don't know if you guys know this, but, Wine, a thing that is pretty important for noobs trying to transition, breaks pretty badly when installing from ubuntu software centre
<nemo> my approximate guess as to what happens, is it is the ms core fonts license dialog
<nemo> somehow it is prompty forever for that, just burning CPU, at about the halfway point
<nemo> you kill it, and it then requires a dpkg --configure -a to repair, which luckily synaptic informed me of
<nemo> installing in synaptic ofc worked perfectly, since it isn't trying to be quite as friendly
<nemo> I ran into this on a test VM image of 13.10 where I was going through the effort of setting things up using unity and software centre like my noob friend would
<OdyX> tkamppeter: I have just uploaded cups 1.7.0-1 to Debian unstable, which should included all your changes, some of which I implemented differently, plus some Fedora patches that make the package globally better; I trust. Feel free to compare+sync it!
#ubuntu-devel 2014-01-04
<Logan_> hey infinity, are you around to fix a couple more ppc64el packages manually? :P
<Logan_> specifically, https://launchpad.net/ubuntu/+source/gst-plugins-ugly0.10/0.10.19-2ubuntu1 and https://launchpad.net/ubuntu/+source/gst-plugins-ugly1.0/1.2.2-1ubuntu1 are both failing, even with an autoreconf
<xnox> Logan_: well, despite running dh_autoreconf it didn't run libtoolize.
<Logan_> and why
<xnox> Logan_: (no lines with libtoolize: jibberish)
<xnox> Logan_: and checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
<Logan_> but why didn't it run libtoolize?
<xnox> Logan_: because autoreconf decided not to run libtool, as it doesn't blindly do it, but rather tries to detect if a particular tool is used and only then updates stuff....
<xnox> Logan_: i wish I knew why autoreconf is so careful =)
<Logan_> is there any way to force a libtoolize using dh_autoreconf without using a script?
<xnox> Logan_: first of all the ltmain.sh patch should be dropped, and instead --as-needed autoreconf option should be used... lets see what else.
<xnox> Logan_: test-building a fix here.
<Logan_> great, thanks!
<Logan_> feel free to upload if you find a fix
<xnox> Logan_: something like that - http://paste.ubuntu.com/6688530/
<xnox> Logan_: uploaded that. let's see if it builds.
<xnox> Logan_: that worked.
<cjwatson> sbeattie: It's almost certainly a bug if a package tries to use /usr/bin/libtool (libtool-bin's only useful content) at build time.  Only a handful of packages with broken build systems do that.  You're meant to have your configure script generate a libtool script in your build tree at build time.
<cjwatson> sbeattie: cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682045
<ubottu> Debian bug 682045 in libtool "libtool: please mark libtool multi-arch: foreign (as in Ubuntu)" [Important,Open]
<cjwatson> (we seem to have a different solution than advocated at the end there, but it still has the basic rationale for why no build ought to need /usr/bin/libtool)
<Logan_> xnox: beautiful, thank you
<sbeattie> cjwatson: yeah, I realized that. It's a bug in an ancient copy-n-wasted script. I'm fixing it upstream.
<vrga> 'lo folks, i'm using a ubuntu core 13.10 rootfs for fiddling with my arm tablet.
<vrga> due to some obvious issues, i need to install some packages from a chroot before i can run the thing natively.
<vrga> i got the chroot to run through qemu-user and stuff, but apparently it has no network connectivity to the outside world.
<vrga> or at least, thats what running apt-get update indicates.
<vrga> so, erm, i'm kinda stuck for the moment.
<Fudge> hi, cpufreqd bug #11621q60 has a simple work around but wondering if it can be fixed in the package for trusty before a freeze takes place? the same version from raring is in trusty 2.4.2-2
<ubottu> bug 11621 in gtkmm2.0 (Ubuntu) "gtkmm2.0: FTBFS: Fails making tutorial." [High,Fix released] https://launchpad.net/bugs/11621
<vrga> kill me. just needed resolv.conf
<Fudge> #1162160 should I say
<maxiaojun> Fudge: an 'outsider' here, I guess you should try contacting the debian maintainer as cpufreqd is a universe package?
<maxiaojun> http://packages.qa.debian.org/c/cpufreqd.html
<Fudge> oh right, thanks maxiaojun  had not considered that :D
<infinity> Fudge: Also, the "workaround" is silly, when there's an actual upstream patch to fix the real bug.
<Fudge> still in git ?
<infinity> Fudge: Yeah, I'll just pull the git patch and test it now.
<Fudge> :)
<maxiaojun> where is the upstream git?
<infinity> Looks to be mirrored a few places, but I yanked the patch from http://git.taihen.jp/cgi-bin/gitweb.cgi?p=cpufreqd.git;a=patch;h=b5b23525edcc09898288360c48e92b4a6c9cb0ee
<infinity> Anyhow, building now, will test the binary and upload in a second.
<Fudge> you can find stuff faster than me :D
<tkamppeter> OdyX, thank you very much, I will look into this soon.
<infinity> Fudge: It was referenced in the bug report. :P
<Fudge> thats what I thought, but my FF is being a bit strange at the moment, only just switched to Trusty and its a bit flakey with Orca for some reason
<infinity> Uploaded to trusty.
<Fudge> nice
<infinity> Fudge: And forwarded to Debian for completeness (since it's probably irresponsible to fix a buffer overflow locally without pushing it to them).
<Fudge> infinity:  thanks so much for jumping on that so fast mate
<infinity> NP.
<Fudge> now how can I get my 4 workspaces to go loL
<maxiaojun> Fudge: you mean the workspace icon in launcher?
<Fudge> maxiaojun:  it is not there
<maxiaojun> you want it to be there?
<Fudge> maxiaojun:  I read that in system preferences, appearance, behaviour you can set the 2x2 grid for workspaces which is what I want, I use keyboard shortcuts to move around workspaces. but the behaviour screen is not completely intuative to me with Orca. I see some settings have been changed by an external program, hit the button and have something saying left, top left, etc and a slider with 0.2 through to 8.0. But do not understand 
<maxiaojun> ok, i do not know a bit about Orca :(
<Fudge> it is just some of the information on the screen that is not being read, is that where the collum/rows are configured?
<infinity> Fudge: In unity, a 2x2 grid would be the default anyway.
<Fudge> mm, maybe the shortcut is not set then, let me look there instead
<tkamppeter> OdyX, I have synced CUPS now.
<infinity> Fudge: The slider orca's reading to you is a slider for launcher reveal sensitivity.  There's nothing to select grid size (it defaults to 2x2, and can only be changed by deeper settings abuse, like ccsm)
<infinity> Fudge: In that system settings panel you're on, there's a tickbox for "Enable workspaces".  If that's off, you'd be gridless.
<OdyX> tkamppeter: cool.
<Fudge> infinity:  thank yo uso much, that is a very clear explanation, I'll see if those items can present themselves a bit better maybe with TheMuso
<infinity> Fudge: Also, if Orca's failing to read the label on that "Reveal sensitivity" thing, please file a bug against Unity for labelling it in a non-friendly manner. :/
<infinity> (Or bug TheMuso, sure) :)
 * infinity misses the days of text-only UNIX and braille terminals, it was so much harder to fuck that up.
<Fudge> :D I hear ya bud, I use console a lot, speech is so fast and responsive for me
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1164252
<ubottu> Ubuntu bug 1164252 in ubuntu-meta (Ubuntu) "Improve default selection of IBus related packages" [Undecided,New]
<maxiaojun> filed just before 13.04 release, forgot during 13.10 cycle, hope that i won't forget it again
<Fudge> oops
<Fudge> strange, totems desktop file has name Videos, I just changed  mine back to Movie Player how I like it.
<tester56> is it possible with ubuntuone to sync only changes of a truecrypt container, so that the container does not have to be uploaded every time?
<maxiaojun> Fudge: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1108977
<ubottu> Ubuntu bug 1108977 in One Hundred Papercuts ""Videos" is a very confusing name for a video player" [Medium,Triaged]
<sladen> tester56: u1sync would need to understand the internal structure first
<sladen> tester56: file a feature request
<maxiaojun> Fudge: https://git.gnome.org/browse/totem/commit/data/totem.desktop.in.in.in?id=9dc401b1213aa9fec2f5274d0e6cb8dcefba486f
<tester56> sladen: that measn: currently not supported?
<sladen> tester56: correct (to the best of my knowledge), but I would suggest Googling
<sladen> tester56: to see whether there are any other similiar requests/work being done
<tester56> sladen: googling does not lead to any valueable information in this case (at least I was not able to get valueable information, that is actual)
<sladen> tester56: make sure that the request regarding truecrypt container is recorded in Launchpad somewhere
<sladen> tester56: and then the next person will hopefully find it, and dicussion can be focused in one place
<tester56> sladen: done: https://bugs.launchpad.net/ubuntuone-filesync/+bug/1266021
<ubottu> Ubuntu bug 1266021 in Ubuntu One Filesync "Ubuntu One should support syncing file changes, instead of re-uploading the whole changed file (example use case: syncing Truecrypt container)" [Undecided,New]
<mitya57> doko: I think jtaylor was looking at nee numpy, maybe he was looking at scipy as well
<mitya57> doko__: having a scipy built for 3.4 will indeed fix some other packages
<mitya57> My pandas upload anyway FTBFS on powerpc because statsmodels didn't build there, I've pinged yoh about that
<jtaylor> I'm almost done with numpy
<jtaylor> then scipy can be synced
<mitya57> Great!
<mitya57> ... The pandas can be put in sync as well
<jtaylor> pandas will get a new update soon
<jtaylor> required for new scipy
<mitya57> I thought pandas depends on scipy, not vice versa
<jtaylor> yes but scipy breaks it
<jtaylor> 0.13
<infinity> jtaylor: Hrm?  What needed doing with numpy?  Didn't I already upload that for 3.4 support?
<jtaylor> new upstream
<infinity> Ahh, fair enough.
<OdyX> tkamppeter: Any opposition to switch cups to openssl (instead of GnuTLS) ? (See #714492)
<OdyX> tkamppeter: also; has the colord-per-queue patch been submitted to cups.org ?
<sladen> tester56: excellent!
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1164252
<ubottu> Ubuntu bug 1164252 in ubuntu-meta (Ubuntu) "Improve default selection of IBus related packages" [Undecided,New]
<maxiaojun> anyone?
<OdyX> tkamppeter: uploaded 1.7.0-2 fwiw
<tkamppeter> OdyX, have you seen that the bug tracker on cups.org is back? So you can report all bug fixes which are now domne by distro patches upstream.
<OdyX> tkamppeter: yeah, saw it; I begun to report some.
<OdyX> tkamppeter: but each one his owns; the colord is more yours than mine: :-)
<jtaylor> hm the python3.4-dbg debug symbols do not match the source
<jtaylor> how can that be?
<doko> ?
<jtaylor> the line numbers are off
<doko> strange
<TJ-> which package contains the UEFI "/EFI/BOOT/BOOTx64.EFI" firmware image installed to the ISOs, or generates it?
<doko> jtaylor, were you working on a new cffi upload?
<jtaylor> no zmq
<stgraber> TJ-: on current (secureboot enabled) images, that'd be shim-signed
<TJ-> stgraber: So, is "BOOTx64.EFI" a generate or renamed file from the shim* packages? I'm having 'issues' and trying to figure out where the files originate
<TJ-> I've looked for mentions of "bootx64" in live-build, livecd-rootfs, shim and shim-signed so far. There's one mention in shim/shim.c where it tries to get the image from the UEFI itself. Not clear yet how it gets onto the liveCD image though
<stgraber> TJ-: it's a copy of the signed shim.efi
<TJ-> stgraber: OK, so some script is renaming it to that expect by the EFI simple file-system protocol?
<TJ-> s/expect/expected/
<xnox> TJ-: correct, the path for removable devices UEFI firmware.
<xnox> <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI
<TJ-> xnox: Yeah, I've been working with the OVMF and qemu to test out ways of recovering a physical system that has become confused
<xnox> TJ-: well there is a packaged version of OVMF and extensive guides on working with it https://wiki.ubuntu.com/SecurityTeam/SecureBoot
<xnox> TJ-: i found that OVMF can be easily confused and it doesn't have persistent storage beyond the lifecycle of the VM.
<xnox> (e.g. for secureboot keys, etc)
<TJ-> xnox: OVMF is fine, I'm using it to work out a way to fix a physical install
<TJ-> xnox: Was trying to get my head around how the UEFI works differently with removable media (simple file system) as opposed to fixed media which require entries in the UEFI nvram's boot list
<Logan_> What is the easiest way to submit the entire Ubuntu delta to Debian? submittodebian just seems to do the latest Ubuntu revision based on the revision before it, even if that was also an Ubuntu revision.
<jtaylor> just run debdiff and email it is not very hard
<PublicStaticVoid> SO may I ask politely.. Why was the decision made to go for Mir and not Wayland?
<PublicStaticVoid> When all future WM's and DE's are going to be depending on Wayland..
<PublicStaticVoid> 95% of Distros are moving to Wayland..
<PublicStaticVoid> k..
<Logan_> jtaylor: But submittodebian makes it so easy. :P Alright.
<Fudge> hey infinity, the workspace switcher check box is unavailable and gets not tab focus with orca. GF could not click it.
<Fudge> infinity:  thank you for fixing cpufreqd
#ubuntu-devel 2014-01-05
<xnox> Logan_: i find submittodebian to be broken.
<Logan_> xnox: it's fine for ubuntu1
<xnox> Logan_: if i wish to cherrypick, take lp:debian/package and cherry-pick/merge what you want to submit and then just do a bzr diff to generate patch.
<Logan_> but once you pass that, it gets wonky
<Logan_> oh, that would work
<xnox> Logan_: or reverse, might be easier, take lp:ubuntu/package uncommit to last debian revision and do $ bzr shelve -i, to remove not-needed chunks (e.g. ubuntu changelog, reverse maintainership field, etc...)
<jtaylor> mitya57: numpy merge https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream/+merge/200473
<doko> jtaylor, well, then you should prepare scipy too
<jtaylor> scipy is a simple sync
<jtaylor> I just would like numpy first to see test results
<doko> well, if you already *know* that cython will fail ...
<jtaylor> I know
<jtaylor> I'm planning to look into it
<doko> thanks
<jtaylor> most likely its just an overly explicit tet
<jtaylor> but if someone else wants to have a look, be my guest :)
<infinity> Logan_: submittodebian for the whole delta is easy, just edit the changelog to collapse ubuntu* to one changelog entry, then run it.
<Logan_> Now that's clever. I'll try that.
<infinity> (Yes, it should probably have a version range argument to do that for you)
<Logan_> I would prefer that. I might file a bug.
<Logan_> Although ubuntu-dev-tools development seems kinda dead right now.
<xnox> Laney: huh, ubuntu-dev-tools has constantly new commits and frequent uploads, they are done direct to debian and synced to ubuntu however.
<xnox> unping, Logan_ ^
<xnox> Logan_: and patches are welcome.
<Logan_> okay
<xnox> Logan_: infinity: did "submittodebian" started to reverse X-Original-Maintainer thing? that was bugging me the most I think.
<Logan_> yeah, that's still a bug
<Logan_> infinity: https://launchpad.net/ubuntu/+source/mpclib/+publishinghistory Any reason why you deleted mpclib from proposed? (It's still in release, and it's also still in unstable in Debian.)
<xnox> Logan_: deletions have comments - Superseded by mpclib3
<xnox> Logan_: i guess transition to mpclib3 should happen, and then mpclib also removed from -release.
<xnox> Logan_: see text under arrow.
<Logan_> well yes
<xnox> Logan_: do you want updates in the mean time, or we need to keep both into trusty?
<Logan_> I just don't see the point of removing it from proposed right now
<xnox> Logan_: -proposed is an overlay, and the less things are in -proposed the better. My guess is that it was not migrating to -release and generating britney spew.
<infinity> Logan_: It was failed-to-upload in -proposed because it shipped older versions of libmpc-dev
<xnox> Logan_: and possibly was not co-installable with mpclib3.
<xnox> Logan_: oh, that =) ^
<infinity> Logan_: Hence the superseded comment.
<Logan_> okay
<mitya57> jtaylor: thank you!
<Noskcaj> A trusty-proposed branch for jsxgraph has not been made, and fixing the ftbfs should just need a b-dep on uglifyjs
<Fudge> oh the error for gstreamer package http://paste.ubuntu.com/6695846/
<jtaylor> doko_: a cython fix for numpy is available, so nothing in main would be broken
<jtaylor> (just a test issue, so cython does not need fixing before the upload)
<labsin> xnox, ping?
<xnox> pong
<labsin> xnox, I'm trying to cross-compile my app (with cmake) and I have a lot of issues
<labsin> using click chroot
<xnox> can you pastebin full build-log or better email ubuntu-phone with it attached?
<xnox> together with pointers to source-code and your cmake files?
<labsin> xnox, ok
<xnox> it's not something i can look into over irc, just right now.
<labsin> I'll post it on the already running topic
<Logan_> xnox: ...halp
<Logan_> should we back out the changes for both gstreamer packages?
<Logan_> but I want them to work on ppc64el :(
<Fudge> infinity:  I hope I filed this correctly as you suggested the other day, bug #1266219
<ubottu> bug 1266219 in LaTeXDraw "Mirrors do not work" [Critical,Triaged] https://launchpad.net/bugs/1266219
<Fudge> oops that is the wrong bug
<Fudge> bug #1266291
<ubottu> bug 1266291 in unity (Ubuntu) "Workspace switcher toggle in Appearance Behaviour tab not available to Orca" [Undecided,New] https://launchpad.net/bugs/1266291
<xnox> Logan_: i think, previously it didn't run gettext/autopoint, yet my patch probably made it run.
<jtaylor> grr whats the deal with the skimage autopkgtest, its unreprodicable in a chroot and local kvm adt suite
<xnox> Logan_: a short term fix is to compare .debs (e.g. amd64) before the changes & after and purge any "extra" conflicting files.
<jtaylor> is it running in some kind of qemu emulation without proper floating point support?
<xnox> Logan_: ".mo" for sure, but possibly more.
<Logan_> xnox: okay - I have to go shower and head to dinner, but I'll take a look later
<xnox> Logan_: i'm off to bed now, but can look into it tomorrow morning.
<Logan_> heh
<xnox> Logan_: it's not the end of the world... =)
<Logan_> you never know. the apocalypse is nigh!
#ubuntu-devel 2014-12-29
<al_exquemelin> what's the versioning rule for PPA packages that are brand new? (I mean, not present in Ubuntu's nor in Debian's repositories)
<al_exquemelin> should some -XubuntuY suffix be added to the version number?
<al_exquemelin> I guess it should be -0ubuntu1, as it is the first release for Ubuntu, right?
<teward> al_exquemelin: i don't think there's PPA-specific packaging schemes, but that would work, appending ~ubuntu14.04 or similar based on the security team's versioning scheme
<teward> I use a slightly different one on my ppas, except when they're build tests of Ubuntu-destined packages...
<al_exquemelin> teward: I've got Ubuntu 14.10, and without the -XubuntuY part, bzr builddeb gives an error stating inconsistency between source format and version
<al_exquemelin> so I think -0ubuntu1 should work
<teward> al_exquemelin: well, you'll need -* so either -0 or -0ubuntu1
<al_exquemelin> teward: ok, I'll stick with -0ubuntu1, thanks
<al_exquemelin> and yet another question. when entering the build directory, bzr builddeb tries to clean it, as far as I can see
<al_exquemelin> but there are no object files in it yet, so dh_auto_clean exits with an error
<al_exquemelin> what should I do to proceed with building?
<al_exquemelin> for now I changed rm *.o in my Makefile to -rm *.o, this should force the error to be ignored
<xnox> Noskcaj: tah.
 * xnox is not sure why i'm not getting notifications about highlights in this hexchat =(
<xnox> Logan_: let me see.
<Logan_> I have no idea what you're replying to :P
<xnox> Logan_: ari appears to have merged it already
<Logan_> what package?
<xnox> Logan_> xnox: can you please sync or merge guayadeque? you're the TIL, and it's blocking a transition ;)
<Logan_> ah
<Logan_> I prefer notifying the TIL before taking a merge ;)
<xnox> Logan_: it is still stuck in -proposed, not sure if it needs another rebuild or not.
<Logan_> looks like codelite would break if wxsqlite3 migrates
<Logan_> but that doesn't make sense
<Logan_> oh, it's because it loses ppc64el
<Logan_> (I think)
 * Logan_ retries that build
<Logan_> xnox: hmm, looks like codelite needs liblldb-3.5-dev on ppc64el
<Logan_> is there any progress on that? I see you were involved in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756380
<ubottu> Debian bug 756380 in llvm-toolchain-3.5 "llvm-toolchain-3.5: Add support for ppc64el" [Normal,Fixed]
<Logan_> although the title is misleading, as it just "supports" it by disabling lldb support
<xnox> Logan_: hm?! we have llvm-3.5+ on ppc64el everywhere....
<xnox> what's the problem?
<Logan_> liblldb-3.5-dev isn't built on ppc64el
<Logan_> it's not in the architecture list
<xnox> Logan_: it appears that codelite might be able to build without lldb component.
<Logan_> I was just about to test the same thing :)
<Logan_> you built it locally without that build dep? and it was successful?
<Logan_> yeesh, it takes 20 min on the buildds
<Logan_> xnox: I'm going to sleep now, but feel free to upload another codelite with [!arm64 !ppc64el] for lldb if you find that it's fine locally
<Logan_> I wonder what features would be lost
 * Logan_ shrugs
<Logan_> ah, it looks like it's just a plugin
<Logan_> we should be fine :)
<Logan_> g'night
<xnox> Logan_: night.
<xnox> doko: are you going to do an archive rebuild with gcc-5 this cycle?
 * xnox is excited about -std=gnu11 by default
<mitya57> What happened to Launchpad? It says it can't resolve two of pyqt5 build-dependencies, but they are clearly present (libenginio1-dev and libqt5websockets5-dev).
<mitya57> Oh I see, someone demoted them to universe.
<mitya57> Hmm, they were always in universe, but the previous version of pyqt5 was synced from a landing PPA where all builds are against universe... :-/
<mitya57> ScottK: do you think we should MIR qtwebsockets/qtenginio or disable that for Ubuntu?
<teward> question: where do i upload to for the ubuntu repositories now that I have approved upload access for the nginx package?  There's a merge in the sponsorship queue, but since I have upload rights I can upload it myself, I just need a little bit of information to do so
<xnox> teward: $ dput *_source.changes
<Laney> https://wiki.ubuntu.com/MOTU/New
<xnox> Laney: oh, nice one =)
<xnox> Laney: next time i'm asking "how to upload a package into ubuntu" on the dmb meeting.
<teward> ahh, okay, so it's just dput.  nice.
<Laney> good page
<Laney> xnox: "What is xnox's favourite drink?"
<teward> xnox: alternatively: put it on the FAQ list for what new uploaders frequently ask questions on :)
<teward> Laney: yes, that one is important.  :)
<xnox> Laney: .... and if one responds beer they get declined to apply for another 12 months.
<Laney> a lovely pint of guinness
<xnox> Laney: i have never tried guinness =) i'm saving that for dublin.
<bekks> Write down your name and your address onto some note, before entiering the pub :D
<xnox> bekks: that's one reason why i have bussiness cards with me, when i'm going out.
<bekks> xnox: Well, it's kinda hard for the barkeeper to get you on a plane/train/bus to your home/business address ;)
<bekks> But I guess you got the point ;)
<teward> is it atypical for web server binaries to FTBFS on powerpc, and do I need to panic with this failing to parse ddeb data?
<nxvl> hi, i'm having a pretty weird issue with a package, when i try to build a package it's FTBFS with "undefined reference to" a function, but when i compile using make and the exact same compiler flags it works fine
<nxvl> any pointers on what could sbuild be adding that i'm missing?
<nxvl> http://paste.ubuntu.com/9642820/
<mdeslaur_> nxvl: you probably need libimobiledevice-dev as a build-depends
<mdeslaur_> just guessing
<mdeslaur_> nxvl: also, go buy an android :)
<mdeslaur_> nxvl: is libimobiledevice what you're actually trying to build?
<nxvl> mdeslaur_: i'm building libimobiledevice
<nxvl> mdeslaur_: what i've found is that on plain make configure status i get "dependency style of gcc... gcc3" and on sbuild i get "dependency style of gcc... none"
<nxvl> which seems to be the one bit producing the issue
<mdeslaur_> are you rebuilding the package from the archive? what release? what version of package?
<nxvl> mdeslaur_: new upstream version, on trusty
<mdeslaur_> and you used the trusty package as a base, or the utopic/vivid package?
<nxvl> vivid
<nxvl> but that one builds just fine
<nxvl> so, i first updated to 1.1.7+git20140505.1be575f8
<nxvl> that worked fine
<nxvl> now that i'm updating to the final 1.1.7, i'm having the issue
<mdeslaur_> hrm
<nxvl> what i don't understand is why on sbuild the gcc dep method is none
<nxvl> and not gcc3 too
<mdeslaur_> where did you get 1.1.7+git20140505? is that your own tarball?
<nxvl> yup
<nxvl> git pull and re-tarball
<mdeslaur_> hrm...would have to diff the two tarballs to see what changed
<mdeslaur_> my guess would be it's because of this: http://cgit.sukimashita.com/libimobiledevice.git/commit/?id=4c4bbd31f52845de70f5b828121eeea62f8b4514
<mdeslaur_> but I don't know what the fix would be, and have to go
<nxvl> mdeslaur_: thanks!
<mdeslaur_> it's just a quick hunch, but may point you in the right direction
 * mdeslaur_ goes away
<mdeslaur_> perhaps disable Use-symbol-script-to-exclude-private-symbols.patch
<mdeslaur_> (wild guess)
 * mdeslaur_ goes away for real
<nxvl> mdeslaur_: yes, that did the trick, now you can go in piece!
<nxvl> peace*
<sladen> libimobiledevice ... that's a familiar name
#ubuntu-devel 2014-12-30
<Noskcaj> How long till http://qa.ubuntuwire.com/bugs/rcbugs supports vivid?
<Noskcaj> wgrant, ^
<wgrant> ajmitch: ^^
<Noskcaj> Is there a vcs where i can try and make a patch?
<teward> i'm only getting an ftbfs on a powerpc build of nginx, 1.6.2-5ubuntu1 seems otherwise to be working - do I need to panic about the powerpc build failing, or no?  https://launchpadlibrarian.net/193675980/buildlog_ubuntu-vivid-powerpc.nginx_1.6.2-5ubuntu1_FAILEDTOBUILD.txt.gz is the build log, looks like it doesn't relate to a code ftbfs issue, maybe
<teward> s/a powerpc build/the powerpc build/
<cjwatson> teward: I wouldn't counsel "panic", but somebody needs to figure it out as this package has previously built on powerpc so the new version isn't going to reach vivid until this is fixed.
<Peace-> guys .... http://wstaw.org/m/2014/12/30/plasma-desktopyq1947.png
<teward> cjwatson: the question then becomes, why are the ddebs unable to be parsed
<cjwatson> teward: Don't know, you'll have to investigate that ...
<cjwatson> That usually means that some of the .debs that you might expect to be generated actually weren't generated
<cjwatson> IIRC
<teward> hmm
<cjwatson> You may well be able to work some of this out by reading pkg-create-dbgsym code and matching it up against the error output
<teward> cjwatson: out of pure curiosity - are the repository builders for powerpc virtualized?
<cjwatson> No
<cjwatson> (Not yet, anyway)
 * teward grumbles.
<cjwatson> None of the builders used for Ubuntu itself are currently virtualised
<cjwatson> But also, powerpc is not yet available in PPAs, which I suspect is your actual question
<teward> makes it difficult to run build tests here if there's no reliable way to replicate the environment... but whatever, guess i'll start digging, on top of work adding 5 days of work into 2 days work
<cjwatson> We'll hopefully improve the virtualisation situation next year
<teward> cjwatson: is there any way to replicate a powerpc environment locally?  Because I can find no sane reason for the package to not build - the binary hasn't actually changed and apparently the exact same one builds fine upstream, so it's either in our Ubuntu delta... or something else
<teward> (upstream in Debian)
<teward> if the changes break because of the delta, then why didn't they break -4ubuntu1... hence my confusion
<teward> and my seeking of a way to replicate the build environment local
<cjwatson> teward: you can try with qemu-system-ppc, though it probably won't be quick
<cjwatson> you can also retry the build to see if it's a non-deterministic failure, I suppose
<teward> cjwatson: i'm thinking it might be a temporary derp, if it ftbfs again then maybe i'll dig into it, but it makes no logical sense that the changes incorporated in the merge would break the automated debug symbols process
<teward> especially when the actual delta hasn't changed and doesn't affect the light packaging
<teward> and there didn't appear to be any actual build failures either...
<cjwatson> did you check for failures earlier in the build that might not have stopped the build?
<teward> o...kay this is interesting
<teward> https://launchpad.net/ubuntu/+source/nginx/1.6.2-5ubuntu1/+build/6678397
<teward> looks like it reran its own build?
<teward> either that or someone poked it - looks like it built the second time round o.o
<cjwatson> oh yeah, I did a mass retry of all failures (unrelatedly)
<cjwatson> so there, you can stop agonising about it ;)
<teward> heheh
<teward> cjwatson: possible non-deterministic temporary failure perhaps?
<teward> (thanks for that btw)
<cjwatson> *shrug* dunno
<teward> cjwatson: i think i saw other powerpc failures upstream once before but a rerun fixed it there *shrugs*
<teward> i'd have to sift throug hmy debian notices
<cjwatson> maybe it was on a different builder, I didn't check
<cjwatson> yeah, denneed02 vs. sagari, suppose the different host might make a difference, but not hugely motivated to dig into it
<LocutusOfBorg1> hi ubuntu developers!
<LocutusOfBorg1> have a nice new year!
<sladen> LocutusOfBorg1: I think you might be a day or two early :)
<LocutusOfBorg1> sladen, maybe ;) but I won't be there tomorrow :D
<LocutusOfBorg1> maybe somewhere it is already tomorrow ;)
<mark06> hi all, what's the position of ubuntu regarding packages that link to other packages that were built with openssl?
<mark06> for example if cyrus sasl has been built with openssl support, that means a given gpl package cannot link against cyrus sasl, or what?
#ubuntu-devel 2014-12-31
<soreau> Hi, I'm wanting to install a python package manually and want to pass --install-layout=deb but only if on ubuntu/deb based distro
<soreau> what's the 'easiest' build system check to see if you're on deb based system so the modules get installed to the correct location or what's a better way of doing this?
<mark06> maybe something around the lines of https://github.com/renatosilva/pidgin/blob/master/build/ububuild.sh#L21
<teward> cjwatson: no reason to dig into it unless others report a broken build on the same host.  until then, thank you for the unrelated retry of build failures, which happened to build the powerpc package without issue.  :)
<teward> (sorry, late ping, been a bit busyish since this morning)
<ScottK> mitya57: I'd rather not cripple pyqt5.
<mitya57> ScottK, ok, will file a MIR
<weasel_popper> so, this is just pointless nagging as it's something that impossible to fix without breaking everything, but implicit globbing is a terrible design flaw in linux
<weasel_popper> it would be better imo if it were explicit. like  'glob rm *.txt | bash -s', where 'glob' would print the globbed arguments to stdout
<weasel_popper> then you could write programs that do things like 'calc 2*3+1', or properly use forwardslash in path names
<bekks> echo "2+3*4"|bc
<weasel_popper> that was just an example. yet another one is multiple file renaming. eg. you can't do 'mv * *.txt'
<bekks> Use rename instead of mv.
<weasel_popper> that doesn't solve the problem, it just works around the one case
<bekks> Well, you can disable globbing in bash.
<weasel_popper> True. The problem is that there even being implicit globbing period is largely what makes Linux incompatible with Windows from a file system point of view.
<cjwatson> It isn't a property of Linux.  It's a property of the shell.
<cjwatson> In particular it's not a property of the file system.
<cjwatson> The shell is a replaceable component.
<weasel_popper> @cjwatson, it's a property of the bash shell, which is the standard shell for all unixes.
<udevbot> Error: "cjwatson," is not a valid command.
<bekks> bash is NOT the standard shell for ALL unixes. In fact, most Unices dont even have bash installed.
<cjwatson> I'm aware that the POSIX shell (not bash) is standard.  It's still replaceable.  Understanding what layers things happen at is important.
<cjwatson> (rather, *a* POSIX shell)
<weasel_popper> well, more correctly, the 'bourne' shell is the standard shell. bash is an extension of that
<bekks> weasel_popper: And the bourne shell is not the standard shell on most unices, too.
<weasel_popper> next you're going to tell me that 'ed' isn't the standard editor
<cjwatson> bash is an extended reimplementation based on the Korn shell, which in turn was based on the Bourne shell
<bekks> HPUX uses ksh, AIX uses ksh, Solaris 10 uses ksh - and they all dont even have bash or the bourne shell installed, by default.
<cjwatson> Most Unix systems have at least Korn-style shells nowadays.
<cjwatson> Anyway, they all have globbing, so this is a moot point.  And this is a totally pointless debate here. :-)
<cjwatson> I'd just like you to acknowledge the difference between "Linux" and individual shells more clearly.
<weasel_popper> I was just rambling anyway. Was studying shell design for OS dev and noticed there was literally no criticism whatsoever of implicit globbing to be found on the net
<cjwatson> This seems unlikely
<cjwatson> Anyway, there are obvious trade-offs either way
<weasel_popper> Another thing I find to be a design flaw is the use of a root directory. It essentially offers you a million ways to shoot yourself in foot in exchange for typing 2-4 more characters like c:/ or hd0:/
<cjwatson> OK, please stop this.
<cjwatson> This isn't going to result in concrete actionable changes to Ubuntu.
<cjwatson> There must be forums elsewhere for general chat about OS design ideas?
<weasel_popper> I'm sure there are, but I don't wanna die :(
<achiang> how does one force apt-get source to download source from an unauthenticated repo?
<achiang> note that this is different from attempting to apt-get install from the repo
<achiang> on trusty, apt-get source just bombs out with an error
<darkxst> achiang, there is an allow-unauthenticated option
#ubuntu-devel 2015-01-01
<orbisvicis> its been a while, but I can just drop patches in debian/patches and pdebuild will incorporate them?
<orbisvicis> or not..
<orbisvicis> oh right, add to series
<Noskcaj> mitya57, Can we sync notification-daemon from exp?
#ubuntu-devel 2015-01-02
<mitya57> Noskcaj, not yet, it breaks LXDE if I recall correctly
<ubunted> Installing ubuntu-14.04.1-desktop-amd64 fails with "'grub-install /dev/sda' failed" , no specific error given
<ubunted> Installing ubuntu-14.04.1-desktop-amd64 fails with "'grub-install /dev/sda' failed" , no specific error given
<xperia> hi all. i am having problems with compileing tkgate from sources. when i do this here => sudo apt-get build-dep tkgate & apt-get source tkgate & cd tkgate-2.0~b10 & ./configure & make i get build error messages like "block.c:1103:20: error: âTcl_Interpâ has no member named âresultâ"
#ubuntu-devel 2015-01-03
<cjwatson> xperia: http://www.tcl.tk/cgi-bin/tct/tip/330.html - see for example http://anonscm.debian.org/cgit/users/cjwatson/vigor.git/tree/debian/patches/tcl-interp-result.patch for how to fix this
<xperia> cjwatson: thanks for the tip. will look into it.
#ubuntu-devel 2015-01-04
<Unit193> Did a test sync of cairo, seems to fix the segfault that I keep on hitting.  In Ubuntu it's stuck on an old git snapshot.
<Unit193> !info libcairo2 vivid
<Unit193> !info libcairo2 unstable
<ubottu> libcairo2 (source: cairo): The Cairo 2D vector graphics library. In component main, is optional. Version 1.13.0~20140204-0ubuntu1 (vivid), package size 537 kB, installed size 1467 kB
<ubottu> libcairo2 (source: cairo): Cairo 2D vector graphics library. In component main, is optional. Version 1.14.0-2.1 (unstable), package size 780 kB, installed size 1630 kB
<ari-tczew> Unit193: I think it should be processed by seb128.
<Logan_> Unit193: note the changes from the last merge: https://launchpad.net/ubuntu/+source/cairo/1.12.10-1ubuntu1
<Logan_> but yeah, definitely talk to seb128
<Unit193> Logan_: Right, one is a git commit and another is an additional dep that's been added since.
<Noskcaj> Logan_, Is --parallel enough of a reason to not sync latexila?
<Logan_> what about the recommends/suggests?
<Noskcaj> I didn't see a need for them, but i think i should contact matttbe before syncing
<Logan_> good call :)
<dupondje> xnox: are you planning to merge/sync cryptsetup soon?
<dupondje> seems like you included alot of ubuntu changes into debian yet :)
<shadeslayer_> hi there, when running autopkgtests, do you reckon it would make sense to export some standard variables like HOME, XDG_* , etc so that tests that write files to those locations can proceed without issues? In a whole bunch of KF5 and Plasma 5 tests, I've had to manually export dirs in each of the tests which is super annoying ...
<Bluefoxicy> is it appropriate to suggest a prerelease package for Inkscape for Vivid?
<Bluefoxicy> the current version is 0.48, and there is a 0.91pre3 pre-release which is 3 years newer.
<Bluefoxicy> It would be nice to have inkscape and inkscape0.91 (the same as there used to be multiple wine packages), but this may be out of taste for ubuntu
<Bluefoxicy> there's a ppa that includes nightly builds, but that is ... well, nightly builds are different than having a development build.
<Unit193> Experimental has 0.91.
<Bluefoxicy> (similarly, why the hell does 14.10 have Wine 1.7?  1.7 is a development branch, and there is no wine 1.6 available))
<Bluefoxicy> Unit193: there's an Experimental repo?
<Unit193> Debian, upstream.
<Bluefoxicy> ah
<Noskcaj> Is there a way i can find out why UDD branches aren't in sync with the current version?
<cjwatson> http://package-import.ubuntu.com/status/
<Noskcaj> bzrlib.plugins.builddeb.upstream.pristinetar.PristineTarError fails a number of xubuntu's packages, is there something xfce/bluesabre could do to help avoid that?
<cjwatson> Give up on UDD? ;-)
<teward> heh
<cjwatson> Though in that case it's possible that an updated pristine-tar backport might help.  Not currently sure what the UDD host is running.
<Noskcaj> cjwatson, Until i get some upload rights, UDD is by far the best way to package i've found. If you could backport pristine-tar, that would be great
<cjwatson> UDD is all but unmaintained, I'm afraid, so major problems are unlikely to be fixed.
<Noskcaj> cjwatson, I don't know much about coding, but is there anything i can do to help with it?
<cjwatson> Looks like package-import == jubany is running precise, so that would be pristine-tar 1.20ubuntu1.
<Noskcaj> How much would be fixed by updating the host to more current packages?
<cjwatson> pristine-tar might be improved, but I doubt much else would change
<cjwatson> Might be worth trying to isolate the particular pristine-tar failures in packages you care about (they may be isolatable by grabbing the bzr branch and trying to use pristine-tar directly) and working out whether they correspond to fixes that have been made since 1.20 that could be SRUed to precise
<Noskcaj> ok
<Noskcaj> How should i run pristine-tar? i've not used it before
<Noskcaj> cjwatson, package-import can't just be upgraded to 14.04?
<ari-tczew> Noskcaj: why don't you just upload debdiff instead creating enormous bazaar branches?
<Noskcaj> ari-tczew, because it's easier to work with the vcs
<ari-tczew> Noskcaj: IIRC you have internet connection, so I think it's easier to upload small debdiff debian -> ubuntu than gigantic branch
<ari-tczew> (if example is merge from Debian)
<Noskcaj> yeah, but with smaller sized packages (less than 10mb branch) it is IMO a beter workflow to use the bzr
<ari-tczew> Noskcaj: ok, you say something about vcs. do you mean gnome packages, or every package?
<Noskcaj> i was meaning the bzr vcs
<Noskcaj> gnome stuff is often desktop team vcs, which is a bit different
<Noskcaj> and ubuntu-gnome is going to be using git by the end of the cycle
<cjwatson> Noskcaj: I expect the problem would be QAing it; I don't think it has a staging site
<cjwatson> (but I know relatively little about it)
<ari-tczew> Noskcaj: I don't know what would be easier to use bzr, at least on sponsoring site, but it's only IMHO.
<ari-tczew> Noskcaj: what about your MOTU? is the discussion still going on mails?
#ubuntu-devel 2016-01-04
<sunweaver> MATE 1.12 will soon arrive in Ubuntu 16.04... http://sunweavers.net/blog/node/30
<pitti> Good morning, and happy new year!
<pitti> cjwatson, Laney: I had http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl be a "valid candidate" several times over the holidays, but update_output.txt was full of alleged uninstallability; I tried in a -proposed chroot and it all worked
<pitti> cjwatson, Laney: may it be that britney objects to the removal of perl-modules (replaced by perl-modules-5.22), and this needs hinting?
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, mterry
<xnox> doko, happy new year! The boost1.54 trusty, arm64 build log has this in it:
<xnox> virtual memory exhausted: Cannot allocate memory
<xnox> in a few targets. maybe we should disable parallel build on arm64 for it?
<xnox> Logan, i was off until 2016, hence the _2016 nick ;-)
<xnox> spinxsearch delta could be moved to debian now, now that it is maintained no? plus something rather uses sphinxsearch. possibly like the location auto-identification webapp. might need to be tested.
<didrocks> cjwatson: hey! happy new year. Once you have time to have a look: http://paste.ubuntu.com/14398330/ (this is why grub isn't themed anymore in xenial). Tell me if you prefer a formal bug report
<jamespage> cjwatson, hey - ok if I pickup your libqb merge? just having a run through HA related bits for 16.04
<LocutusOfBorg1> hi folks!
<LocutusOfBorg1> can anybody please retry this build? https://launchpad.net/ubuntu/+source/dspdfviewer/1.14-1/+build/8407197
<LocutusOfBorg1> I presume it was failing due to some toolchain problem
<LocutusOfBorg1> pitti, welcome back! to be nitpicking, you sponsored more than 12 packages to me :) Just you didn't look to this link I guess https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsoree=LocutusOfBorg&sponsoree_search=name
<LocutusOfBorg1> but who cares :)
<LocutusOfBorg1> welcome back
<pitti> LocutusOfBorg1: ah indeed, so I was missing https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=LocutusOfBorg&sponsoree_search=name
<pitti> LocutusOfBorg1: happy new year too!
<pitti> LocutusOfBorg1: build retried
<LocutusOfBorg1> thanks! and thanks dholbach for the sync :)
<LocutusOfBorg1> it is nice to have you all back
<rbasak> doko: are you back today? About bug 1527865. Disabling LLDB entirely for i386 seems better to me than total FTBFS - at least an incremental improvement. And it's reported fixed on 3.8 so shouldn't have any ongoing maintenance burden. So are you happy for me to sponsor LocutusOfBorg1's comment 7 debdiff?
<ubottu> bug 1527865 in llvm-toolchain-3.7 (Ubuntu) "FTBFS on i386" [High,Triaged] https://launchpad.net/bugs/1527865
<rbasak> LocutusOfBorg1: have you build tested that in a PPA, please?
<jtaylor> will 16.04 still get glibc 2.22?
<jtaylor> I'd love to have libmvec available in the LTS
<LocutusOfBorg1> rbasak, I had, but I deleted due to space issues
<LocutusOfBorg1> well, testing something disabled is difficult
<LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/8743215
<rbasak> OK. As long as it builds (and doesn't regress builds on other archs), I'm happy with that debdiff.
<rbasak> I trust that your debdiff shouldn't regress any other archs in any way, except for latent bugs which for a development release I think is OK to risk on balance.
<LocutusOfBorg1> it  should affect only i386, if this is what you care
<rbasak> right.
<LocutusOfBorg1> BTW if 3.8 will be the default fox xenial, we can also don't care too much
<rbasak> LocutusOfBorg1: maybe ask for more PPA space BTW? I don't know what Launchpad's policies are on this, but as you are helping fix LLVM I think that would be a fair request.
<rbasak> don't care too much> this also paves the way for an SRU to 15.10 to do the same thing, if you're interested in driving that?
<LocutusOfBorg1> rbasak, the problem has been that I uploaded 6 llvm in a row, not sure how long the space of the previous one is freeded because of superceeded sources
<LocutusOfBorg1> sure rbasak why not
<rbasak> 6 llvm in a row> perfectly reasonable if you're working on fixing llvm :)
<LocutusOfBorg1> rbasak, yes, but I guess the resources aren't freeded as soon as a new one is uploaded, so you need 4 times the space
<rbasak> LocutusOfBorg1: I'm suggesting that you ask for 4 times the space :)
<rbasak> LocutusOfBorg1: I appreciate you helping with this, and I don't want to see you inconvenienced.
<LocutusOfBorg1> rbasak, actually I did the other builds on another ppa with more space https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+builds?build_state=built
<LocutusOfBorg1> :)
<LocutusOfBorg1> but I'm asking some more space
<cjwatson> pitti: No, that's just a binary package.  More likely the autohint is missing some subset of the sources required for the transition ...
<cjwatson> didrocks: thanks, will apply that or something similar once I get my feet under me :)
<cjwatson> jamespage: libqb> no problem
<jamespage> cjwatson, ta
<pitti> cjwatson: ah, can that be added manually somehow?
<pitti> cjwatson: we have an alpha-1 blocker ATM anyway, but that should be gone by tomorrow, and then I guess we should finish this
<cjwatson> didrocks: shouldn't we try both paths for the sake of partial upgrades?
<cjwatson> pitti: well, it relies on working out where the problem is first ;-)
<jamespage> doko, xnox: good morning - how do we feel about pdf doc generation in Ubuntu main using fop? its currently broken (impacting on the s390 port for xmlstarlet which is blocking ceph migration) due to mismatching xmlgraphics - I've looked at merging fop 2.0 from debian, but it has a un-avoidable dependency onto something that's going to try to pull maven into main
<jamespage> there are a handful of packages in main that use fop for pdf generation
<xnox> aaaaaah =) jamespage, happy new year to you too! =)
<jamespage> xnox, happy new year!
<Odd_Bloke> xnox: PDF generation?  I'm having flashbacks... :p
<jamespage> erlang, x11proto-core and xorg-docs BD on fop for this purpose
<jamespage> and we have two reverse-recommends that could be dropped to suggests
<jamespage> xmlto and libbatik-java
<jamespage> vs ~160 package MIR for maven...
<jamespage> I'm not sure why I've not just done this already...
<xnox> jamespage, i'm a bit slow. what are you proposing? demoting fop to universe?
<xnox> + sync new fop?
<jamespage> xnox, yeah
<jamespage> and a small delta on 5 packages to support that
<xnox> jamespage, and then what? xmlto, erlang, xorg end up without docs?
<jamespage> xnox, they end up without PDF docs - they still get htmls ones...
<doko> jamespage, is fop the only thing pulling maven?
<jamespage> doko, there are a few other deltas across main packages to avoid that right now
<xnox> it seems to me that over the years, all that jamespage does is constantly avoid maven. when will the day come that we will not be able to avoid maven?
<xnox> and has the delta of keeping maven away, is really worth maintaining?
 * xnox is sure MIR team will love 160+ packages to review =)
<rbasak> slangasek: mariadb-10.0 FTBFS on s390x (only). It's in universe and looked after in Ubuntu by the Debian maintainer, in sync with Debian and doesn't FTBFS on Debian buildds.
<rbasak> slangasek: can you suggest how he should approach fixing this, please?
<rbasak> I wonder if it's an environment issue.
<rbasak> I see things like "InnoDB: Error: pthread_create returned 11" in some of the test failures.
<xnox> rbasak, i can look into that. we have toolchain differences from debian on s390x, fyi
<rbasak> xnox: I'd appreciate that, thanks. You can find otto in #debian-mysql on OFTC if you need him.
<xnox> rbasak, but, mariadb-10.0 is ftbfs in xenial-release too on s390x, thus why would it matter? is it blocking something from being installable?
<jamespage> xnox, doko: I'm not sure we have the resources to deal with the MIR and subsequent support overheads
 * jamespage certainly spends alot less time of java bits these days...
<rbasak> xnox: apparently it once succeeded, so the failure blocks proposed-migration: https://launchpad.net/ubuntu/+source/mariadb-10.0/10.0.22-4/+build/8448317
<tumbleweed> do we document anything about our s390x port anywhere? I don't ever recall it even being announced
<xnox> rbasak, it means there is NBS in proposed, and one should ask release team, to decruft mariadb-10.0 on s390x, in proposed =)
<didrocks> cjwatson: yeah, it can be changed to do dual path detection, that makes sense, I wasn't in favor of adding a Breaks: against plymouth << path_change_version, but dual path sounds good. Want me to do it?
<rbasak> xnox: I'd be fine with that, too, if that's acceptable.
<xnox> rbasak, however, other things may have ended up building against it already. let me check.
<cjwatson> didrocks: yeah, if you have time, please
<didrocks> cjwatson: sure (will finish some other tasks first and will do)
<rbasak> xnox: thank you for the help. Is it OK to point otto directly to you if in future he needs any more assistance with s390x for mariadb-10.0 in Ubuntu?
<xnox> rbasak, yes.
<xnox> rbasak, all things s390x i should be able to help with.
<doko> jamespage, xnox: basically agrred, but if we come to a point where it makes more effort to keep things out of main ... we have to keep the component mismatches clear, and this one is unresolved now for more than two months ...
<jamespage> doko, huh - the one blocking component mismatches is not the one I'm talking about either...
<doko> jamespage, rbasak: ok, and who is supposed to fix this one?
<didrocks> cjwatson: I just went for the easy solution (no need to use a for loop or anything else, rather added a deprecation note): http://paste.ubuntu.com/14399150/
<cjwatson> didrocks: pushed to git, thanks
<didrocks> thanks :)
<cjwatson> doko: some of this should simplify once libbusiness-isbn-perl manages to be promoted
<cjwatson> er, moved to release, that is
<rbasak> doko: which one? jamespage's question or my question?
<xnox> yeah, i made two uploads. let's see if they will build =)
 * xnox goes to grab more coffee
<doko> dholbach, please upload the boost1.58 mpi source package too when uploading boost1.58
<dholbach> LocutusOfBorg1: ^ do you know about this?
<Odd_Bloke> doko: hallyn: One of our partners is asking us about qemu 2.5. I notice that it has landed in stretch and sid; do you have any plans to get it merged for xenial?
<LocutusOfBorg1> dholbach, what exactly?
<dholbach> LocutusOfBorg1: what doko said
<dholbach> LocutusOfBorg1: I uploaded your boost1.58 merge
<LocutusOfBorg1> oh I see
<LocutusOfBorg1> so next time just a plain sync?
<LocutusOfBorg1> do you want an ubuntu2 with the patch reverted? so we enable it right now?
<dholbach> doko: ^ can you maybe explain?
<LocutusOfBorg1> now the merge is done, so sync is not possible anymore
<doko> dholbach, a sync would end up in dep-wait. the mpi boost has to have the very same version number
<dholbach> LocutusOfBorg1: ^
<doko> Odd_Bloke, I'm not a qemu stakeholder, better ask hallyn about it
<Odd_Bloke> doko: Ack; just saw your name on the last merge so thought I'd check in with you. :)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<xnox> doko, are there ftbfs results somewhere I can start looking at?
<doko> xnox, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151218.1-xenial-baseline-xenial.html (yes, need to announce that)
<xnox> doko, tah.
<mitya57> doko, there are some failures without logs, ie https://launchpad.net/ubuntu/+archive/test-rebuild-20151218.1-xenial-baseline/+build/8562576
<LocutusOfBorg1> doko, mpi-defaults is the same as debian I see
<LocutusOfBorg1> so dholbach can sync the package then?
<doko> LocutusOfBorg1, no, you don't understand
<doko> https://launchpad.net/ubuntu/+source/boost-mpi-source1.58 needs an update
<doko> mitya57, given back. I surely can give back these one more time, but then you don't have *any* build logs
<dasjoe> cjwatson: I couldn't find any info about whether it's acceptable to send "git request-pull" formatted mails to Debian's bugtracker, so I hope the mail is useful to you
<mterry> slangasek, do you mind subscribing foundations to libtest-mockmodule-perl bugs (for MIR bug 1529744).  Happy 2016, btw :)
<ubottu> bug 1529744 in libtest-mockmodule-perl (Ubuntu) "[MIR] libtest-mockmodule-perl" [Undecided,New] https://launchpad.net/bugs/1529744
<cjwatson> dasjoe: it's not particularly helpful, but I can always ignore it ...
<dasjoe> cjwatson: hah, okay
<cjwatson> dasjoe: (I'm going to have to apply things in a different way than you're trying to do)
<dasjoe> cjwatson: right, sorry for the noise, then :)
<bobbyz> Hi guys.  Does anyone know how the debian-cd_info.tar.gz file is built (e.g. http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/cdrom/)?  The contents of that file are extracted and used to generate the boot files for the ubuntu live CD as part of the tools/boot/*/boot-* scripts in the lp:~ubuntu-cdimage/debian-cd/ubuntu project.  However, I can't find the build scripts that put together this
<bobbyz>  debian-cd_info.tar.gz  file
<cjwatson> they're in the debian-installer source package
<bobbyz> cjwatson thanks!  I'll take a look there
<smoser> infinity, is there anything i can do to help move hwe-w installer kernels into -updates ?
<smoser> bug 1511497 . I can test and post results of a amd64 install if you'd like on that bug or anywhere else.
<ubottu> bug 1511497 in maas-images "No hwe-w kernel for 14.04" [Medium,Confirmed] https://launchpad.net/bugs/1511497
<flexiondotorg> xnox, I've just seen your commit in the Ubuntu MATE seeds - Drop NBS gnome-control-center-shared-data.
<flexiondotorg> What does NBS mean? And is there something replace gnome-control-center-shared-data?
<LocutusOfBorg1> doko, I admit I'm lost, so drop the boost-mpi-source1.58 and sync boost-1.58 is fine? why did you split it?
<didrocks> flexiondotorg: https://wiki.ubuntu.com/UbuntuDevelopment/NBS
<pitti> LocutusOfBorg1: probably to keep mpi in universe, as boost itself is in main?
<flexiondotorg> didrocks, xnox It would seem I just need unity-control-center-faces now :-)
<xnox> LocutusOfBorg1, no no no no.
<flexiondotorg> didrocks, Thanks for the learning :-)
<xnox> LocutusOfBorg1, mpi is in universe.
<xnox> LocutusOfBorg1, that's why we have each boost split into two source packages - one to build most of boost, in main. and another one in universe to build mpi portions.
<xnox> LocutusOfBorg1, and there is loads of logic in debian/rules to update -mpi split package.
<xnox> LocutusOfBorg1, if you sync boost, it will never build.
<xnox> flexiondotorg, oh, really.
<xnox> flexiondotorg, =) well, please fix that up. sorry about it, I didn't really get what the #Faces comment meant =)))))
<flexiondotorg> xnox, Yeah, I just had gnome-control-center-shared-data in UBuntu MATE for faces.
<flexiondotorg> Already push updated seeds for Ubuntu MATE :-)
<dholbach> LocutusOfBorg1: I think both source packages need to be updated and have the same versions and everything (we have it because of the main/universe split)
<xnox> dholbach, correct =)
<TJ-> Anyone available to consider this improvement to cryptsetup/initramfs-tools key-file integration? bug 1494851
<ubottu> bug 1494851 in cryptsetup (Ubuntu) "initramfs cryptroot hook script doesn't install cryptsetup if keyfile but no keyscript" [High,Triaged] https://launchpad.net/bugs/1494851
<infinity> smoser: Some verification on LP: #1524366 would be helpful.  I was going to run some test installs today on a couple of arches, but if you want to do x86 for me while I do PPC, that would be lovely.
<ubottu> Launchpad bug 1524366 in livecd-rootfs (Ubuntu Trusty) "Add support for lts-wily kernel flavours in trusty" [Medium,Fix committed] https://launchpad.net/bugs/1524366
<smoser> infinity, sweet. i was hoping you'd point me at your bug
<smoser> thanks. i'm' in process of doingv amd64 and will do i386 for fun
<infinity> smoser: Ta.
<LocutusOfBorg1> ack xnox :) thanks a lot!
<LocutusOfBorg1> wilco
<LocutusOfBorg1> seems so easy then, sorry I didn't see the target mismatch
<slangasek> mterry: done
<mterry> slangasek, cheers!
<slangasek> hallyn: did you still have questions about pam-auth-update?
<hallyn> slangasek: nope, thx
<mapreri> now, why can't I change lp #1306960 (in pencil2d) back to in progress...
<ubottu> Launchpad bug 1306960 in pencil (Ubuntu) "update to pencil2D" [Undecided,In progress] https://launchpad.net/bugs/1306960
<mapreri> does it need ~ubuntu-bugcontrol superpowers that too?
<mitya57> mapreri, I've just done it
<mapreri> mitya57: thanks.
<mitya57> I think only bugcontrol can reopen bugs, yes
<mapreri> I should probably stop wasting everybody's time and get my motu hat too, umpf
<mitya57> ++!
<LocutusOfBorg1> cjwatson, stupid feature request (stupid to say, not to implement, sorry for that)
<LocutusOfBorg1> e.g.
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1530949
<ubottu> Launchpad bug 1530949 in gambas3 (Ubuntu) "please merge gambas3 from debian" [Undecided,New]
<LocutusOfBorg1> build uploading on ppa:costamagnagianfranco/locutusofborg-ppa
<LocutusOfBorg1> I would really appreciate (maybe my sponsors too) something that converts ppa:blah/blah2
<LocutusOfBorg1> into https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/
<LocutusOfBorg1> or something similar :)
<LocutusOfBorg1> an a href would be awesome
<lamont> what did I just change by freshening xenial, that alt-a is now getting eaten by something instead of passed through to gnome-term and therefore irssi
<lamont> ah, nm
<tarpman> LocutusOfBorg1: maybe not exactly what you want, but there's http://pad.lv/ppa/costamagnagianfranco/locutusofborg-ppa
<LocutusOfBorg1> tarpman, sure, it is already really nnice
<LocutusOfBorg1> maybe the regex is easy to implemtn
<sarnold> tarpman: oh, nice, that ought to be amenable to a firefox search thingy..
 * tarpman <3 pad.lv
<stgraber> infinity: dmb meeting now in #ubuntu-meeting
<doko> why are the linux autopkg tests still marked as fail?
<doko> pitti, ^^^
<elbrus> pitti: just thought to let you know: I will look into the autopkgtest failure of dbconfig-common myself, but it will take a few days because I first want to straighten out a CVE issue in one of my packages.
<sarnold> LocutusOfBorg1: congratulations :)
<LocutusOfBorg1> thanks!
<LocutusOfBorg1> :)
<ESphynx> hey guys, is there a way to request a rebuild on a ubuntu package that failed on a particular architecture?
<ginggs> ESphynx: which package?
<ESphynx> ginggs: https://launchpad.net/ubuntu/+source/ecere-sdk -- the amd64 build failed, strangely
<ginggs> ESphynx: retrying... please check whether it fails the same way and file a bug if it does
<ESphynx> ginggs: I am both upstream and maintainer
<ESphynx> will certainly keep an eye on it :) Thank you.
<ESphynx> (I strongly doubt it will)
<ginggs> ESphynx: you are welcome
<ESphynx> ginggs: it failed again :S
<ESphynx> cat: ./usr/share/ecere/samples/3D/terrainCameraDemo/res/aircraft/06: No such file or directory -- This seems to be the problem
<ESphynx> There's a PNG file named '06 17 09.png' (with spaces)
<ESphynx> this funky PNG optimization stuff seems new?
<ESphynx> pkgstripfiles: PNG optimization -- There seems to be a failure to handle those spaces
<ginggs> PNG optimization has been around for a couple of releases now
<ESphynx> But why would it only affect amd64?
<ginggs> only amd64 because that's where the arch:all packages are built as well
<ESphynx> ah. that explains
<ESphynx> those resources are not new from the last version that built though
<ginggs> notice that the arch:all and arch:amd64 packages were not built on the debian buildds https://buildd.debian.org/status/package.php?p=ecere-sdk&suite=unstable
<ESphynx> Changing the actual content of PNG files does seem way over-reaching to me (as an upstream)
<mhall119> slangasek: ping
<ginggs> they were built by the uploader - sometimes this causes problems e.g. buildds have no network access, missing build-depends
<ESphynx> ginggs: But I was referring to this previous version that built https://launchpadlibrarian.net/222298118/buildlog_ubuntu-xenial-amd64.ecere-sdk_0.44.11-0ubuntu2_BUILDING.txt.gz
<mhall119> slangasek: a couple of things: (1) I sent emails to the TB and DMB lists from the CC about this cycle's regular catchup meeting, but they're waiting for moderation, can you let them through?
<dobey> it didn't have a png file with spaces in its name?
<ESphynx> dobey: it did have that same exact file
<ESphynx> 06 17 09.png
<mhall119> slangasek: (2) The Xubuntu developers said there is some outstanding issue with their xubuntu-core packages, that there might have been some concern about the name which was preventing it from getting into the archives, do you know anything about that?
<ESphynx> could those 'cat' be new things that were recently added?
<dobey> looks like maybe how png optimization is run was changed
<ESphynx> dobey: seems like it's failing to treat spaces safely :P
<dobey> ESphynx: i suspedt trying to build the same source on sid might have the same issue?
<doko> ESphynx, dobey: yes, I changed that last month to run in parallel. There might be a bug then ... the source is in pkgbinarymangler
<ESphynx> dobey: possible... I confess my pbuilder failed to upgrade
<doko> dobey, pkgbinarymangler is Ubuntu only
<dobey> ESphynx: ^^ ah, seems like you should file a bug against pkgbinarymangler then, per doko's comment
<dobey> doko: ok, wasn't sure if it was something ubuntu specific, or a change in the build tools in debian too.
<doko> dobey, ESphynx: I'm afk now. see the optimize_pngs function in pkgstripfiles
<ESphynx> dobey: so it is ubuntu specific?
<ESphynx> could you guys please file the bug?
<ESphynx> you might be more familiar with those deiban/ubuntu tools :)
<ESphynx> https://bugs.launchpad.net/ubuntu/+source/pkgbinarymangler -- Would this be the place?
<ESphynx> Is it this line?  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkgbinarymangler/wily/view/head:/pkgstripfiles#L103
<dobey> that package is the place, yes
<dobey> well, no, that's the code in wily
<dobey> https://code.launchpad.net/~ubuntu-core-dev/pkgbinarymangler/ubuntu is the upstream trunk code
<dobey> lol, or not
<ESphynx> http://bazaar.launchpad.net/~ubuntu-core-dev/pkgbinarymangler/ubuntu/files -- all gone? lol
<dobey> ok, you probably need to pull-lp-source pkgbinarymangler then
<dobey> because there is no lp:ubuntu/pkgbinarymangler branch
<ESphynx> I'm sure other packages would suffer from this :P
<dobey> at least, no bzr branch
<dobey> anyway, file the bug
<dobey> and include the few lines from the build log, showing the error
<ESphynx> I can do that much
<doko> dobey, ESphynx: uploaded a fix, please retry once it's published
<ESphynx> doko: thank you. should I still file a bug? lol
<ESphynx> I don't have permissions to retry the build
<dobey> i guess not
<ESphynx> but I keep an eye on it
<ESphynx> thanks guys for the prompt support.
<dobey> just ask for another rebuild then
<ESphynx> ginggs, dobey could you please request another rebuild once pkgbinarymangler is published?
<dobey> i have to go
<dobey> so no :)
<ESphynx> cheers dobey
#ubuntu-devel 2016-01-05
<ESphynx> doko: I imagine this is now published? https://launchpad.net/ubuntu/+source/pkgbinarymangler/127/+build/8801747
<ESphynx> oh it's you doko :)
<ESphynx> Could someone please retry the AMD64 build of ecere-sdk on Xenial now? https://launchpad.net/ubuntu/xenial/+source/ecere-sdk
<slangasek> mhall119: hi, so the xubuntu thing hadn't been a concern about package names, but rather image names.  I'm pretty sure we talked through that and reached a resolution, and now there's just the matter of getting their livecd-rootfs changes reviewed and merged
<slangasek> mhall119: "Subject:  Best Windows Replacement Deals of the Year- Available Now.=" -- that your mail to the TB? ;)
<slangasek> mhall119: (messages approved)
<ESphynx> This annoying Unity Alt-F (for my app) bug popping up the Unity dash board that I had reported and was supposed to be fixed is apparently still there in 15.04
<darkxst> ESphynx, 15.04 will be end-of-life in a few weeks, you should upgrade!
<infinity> tjaalton: Ping, re: lts-w X stack.  Time's running out.
<ESphynx> darkxst: 15.10 I mean, sorry
<ESphynx> darkxst: also, seriously annoyed that upgrades put back Unity as my default WM
<darkxst> ESphynx, how did you set your default WM?
<ESphynx> or maybe it didn't
<ESphynx> I have a drop down and normally do GNOME Classic, I think 'Ubuntu (Default)' got selected by default (i.e. just entering password at login screen)
<darkxst> that should not be reset on upgrades
<ESphynx> 2 other major issues I have with Ubuntu is A) always puts my backlit keyboard on bootup, and can't even turn it down before login (and every login turns it back on) and B) Does not remember my choice of deactivating the Touch Pad when a mouse is plugged in
<darkxst> ESphynx, file bugs, not whine on IRC!
<darkxst> a. might be a kernel issue
<ESphynx> darkxst: bugs take considerable time to file and it just depresses me when they get ignored for years :P
<ESphynx> re: a), not that I can use the keyboard keys to turn it 'off' once logged in
<ESphynx> note*
<darkxst> ESphynx, use `ubuntu-bug <package>` should only take a couple of minutes
<darkxst> if they are ignored after a while send an email to relevant email list linking to your bugs
<ESphynx> darkxst: finding what package is responsible in those cases would take me a while :)
<darkxst> a.) likely kernel b.) possible gnome-settings-daemon
<ESphynx> thanks. will take note and may end up filing bugs :P
<ESphynx> you don't happen to have rights to re-schedule a failed build, do you? ;)
<darkxst> probably not unless its part of ubuntu GNOME or -desktop packagesets
<ESphynx> ah, no it's not, but thanks!
<TheMuso> ESphynx: I can retry a failed build for you, as long as you are sure it will succeed. What package?
<ESphynx> TheMuso: https://launchpad.net/ubuntu/xenial/+source/ecere-sdk
<ESphynx> TheMuso: doko published a fix earlier for pkgbinarymangler which should theoretically fix the failed build
<TheMuso> ESphynx: Which version?
<ESphynx> TheMuso: this amd64 build  https://launchpad.net/ubuntu/+source/ecere-sdk/0.44.13-1/+build/8791598
<ESphynx> the 'all' architecture is actually what was failing due to the PNG optimization code
<TheMuso> ESphynx: Ok, retried.
<ESphynx> thank you!
<TheMuso> You're welcome.
<ESphynx> doko, TheMuso: it failed again... :( It does seem to be using pkgbinarymangler 127 which was supposed to fix this ( https://launchpadlibrarian.net/232975999/buildlog_ubuntu-xenial-amd64.ecere-sdk_0.44.13-1_BUILDING.txt.gz )
<TheMuso> ESphynx: Ah that sucks. I'm not familiar with that package, so don't feel I can be any further help sorry.
<ESphynx> TheMuso: thanks, will ping doko again tomorrow :)
<tjaalton> infinity: bug 1519753 is there for libdrm which needs to go in first
<ubottu> bug 1519753 in libdrm (Ubuntu Trusty) "Please backport libdrm for 14.04.4" [High,In progress] https://launchpad.net/bugs/1519753
<pitti> Good morning
<pitti> doko: for gcc-5? well, because they do fail..
<pitti> doko: but the rebuild test succeeds, so good enough for gcc, I'll hint it
<pitti> cjwatson: I just saw commit 803 in hints-ubuntu -- i. e. we actually do need a manual hint for perl transitions?
<cjwatson> pitti: no, if it was "unblock" there must have been a freeze in progress at the time or something
<pitti> cjwatson: yes, it was "unblock"
<pitti> cjwatson: ah, so these are not manual hints, just counter freeze hints; check
 * pitti wonders how he can convince britney to let systemd and ifupdown in -- they have a mutual Breaks:, but otherwise work fine
<pitti> I tested a dist-upgrade from wily to xenial-proposed
<cjwatson> pitti: probably "easy systemd/blah ifupdown/blah" then
<pitti> cjwatson: ah, thanks; this type of hint is/was new to me
<cjwatson> pitti: The current autohint seems to be getting there, but still 129 extra uninstallables.  I'll poke at it some more after breakfast.
<cjwatson> pitti: I've poked it along a reasonable amount.  One problem is that the new uwsgi needs new php5, which is blocked on various autopkgtest failures; any chance you could have a look at those?
<cjwatson> pitti: (also it needs insighttoolkit4 to build on amd64, an unfortunate casualty of Swift problems during the break, which I've retried but usually takes something like 18 hours)
<pitti> cjwatson: I did over the holidays; we could decide to ignore all those, but it seems the new php actually does break a whole lot of stuff :(
 * pitti retries those without apt pinning, maybe a few of them will work
<cjwatson> Deliberate language changes, or bugs?
<pitti> "Missing PHP extension "http" or wrong version!" might be due to apt pinning
<pitti> but I didn't see a pattern there, they fail due to dozens of different causes
<cjwatson> maybe worth punting to mdeslaur as the person who merged php5
<cjwatson> can also temporarily remove uwsgi from the release pocket to disentangle these, but let's see
<pitti> uwsgi has reverse dependencies, though
<pitti> I remember that this was one of the remaining hard ones on http://people.canonical.com/~ubuntu-archive/transitions/html/html/perl5.22.html
<cjwatson> a few, yes
<pitti> retried the php tests (without pinning), but queues are also Qt-DoSed, will take a bit
<cjwatson> it was previously hard on the transition tracker because it depended on libcoro-perl, but the sync from unstable disentangled those
<pitti> in the meantime I'll run them against release and see which ones are actual regressions
<pitti> cjwatson: right; I tried to remove libcoro from it (as discussed in the Debian bug), but gave up after an hour or so; fortunately the Debian maintainer did it the next day :)
<cjwatson> so I think the only remaining issues are geneweb (tangled with ocaml issues on s390x, but I might just remove the geneweb/s390x binary), waiting for all the pending builds, and uwsgi/php5
<pitti> geneweb has no reverse deps, so that sounds fine
<cjwatson> I want to see if it can be fixed properly before doing that though
<pitti> cjwatson: oh, arm64 distro builds are now on bos, with more capacity -- nice!
<cjwatson> pitti: it's a hideous hack (we're treating virtualised builders as nonvirt, because that way we don't run into all the reset bugs), but does the job for now
<pitti> I can reproduce the php5 regressions locally; e. g. "adt-run php-doctrine-bundle" succeeds, "adt-run --apt-pocket=proposed=src:php5 -U php-doctrine-bundle" failsl
<pitti> interestingly it succeeds in Debian
<pitti> cjwatson: oh, there are a couple of php module FTBFS, I'll look at those; they explain at least part of the regressions
<Saviq> pitti, can you please restart qtmir with qtmir-gles trigger http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/i386/
<Saviq> /we need to look into that test, starts looking unstable
<pitti> Saviq: queued
<Saviq> thanks
<pitti> Saviq: but it will take a while, cf. the rather large queue on http://autopkgtest.ubuntu.com/running.shtml
<Saviq> ack
<pitti> . o O { can we just test everything on s390x? :-)
<pitti> cjwatson: I'm creating a nice long list of php module related FTBFS/depwaits, now in a nice phpunit-mock-object <-> phpunit circular build dep; I'll see to untangle this
<pitti> dear debian, please stop allowing arch:all uploads, kthxbye
<cjwatson> pitti: I wanted to bootstrap that ages ago, but I've been blocked on infinity adding the usual bootstrap archive back to the xenial amd64 chroot
<cjwatson> pitti: you probably *could* disentangle those manually, but it sucks to have to
<cjwatson> i.e. via uploads
<cjwatson> leaves garbage in the archive
<pitti> I'm trying to build phpunit with the older phpunit-mock-object, if that fails I'll just temporarily disable its tests, let both build, and re-enable them
<pitti> ATM it fails for an entirely different reason, meh
<Odd_Bloke> xnox: Did you see gaughen's email asking if you're ready for s390x cloud images to be built?
<pitti> Odd_Bloke: speaking of which, what's the word on xenial cloud images (for other arches)?
<pitti> Odd_Bloke: and happy new year!
<Odd_Bloke> pitti: Happy New Year!
<Odd_Bloke> pitti: So we are building xenial cloud images using the old system at the moment, which should work as you expect.
<pitti> Odd_Bloke: I mean http://cloud-images.ubuntu.com/xenial/ has Dec 18 as latest image
<Odd_Bloke> pitti: Oh, hm.
<Odd_Bloke> pitti: It looks like we've been publishing that image to clouds since December 18th; let me work out what's going on.
<Odd_Bloke> pitti: OK, that's unwedged now.
<pitti> Odd_Bloke: nice, thanks!
<Odd_Bloke> pitti: So I'll let this next build go through, then I'll be plumbing the new system in (which will probably break everything for a few days :p).
<xnox> Odd_Bloke, hm... yes =) i just have.
<xnox> Odd_Bloke, yo, send a reply. Yes, we can start building series of bytes that resemble a cloud image =)
<xnox> Odd_Bloke, do you have ability to add hooks and things in the initramfs?
<Odd_Bloke> xnox: I haven't done it myself, but I assume that dropping stuff in /etc/initramfs-tools/... and then running something in a chroot would do the trick?
<xnox> Odd_Bloke, ok. I'll think about it. I think we will need s390-cloud-init or some such package (or changes to sysconfig-hardware) which will activate first NIC and first DASD drive (for example) on first boot, and remember that persistently, when no other NICs/Drives are configured.
<xnox> Odd_Bloke, or e.g. change sysconfig-hardware to take hints from kernel cmdline or some such.
<xnox> Odd_Bloke, anyway, does my email sound clear at all? to e.g. produce "a series of bytes that look like a cloud-image" ? =)
<Odd_Bloke> xnox: Yep, it does (to me at least :p).
<doko> xnox, are you looking at the cython ftbfs issue?
<xnox> doko, yes, i believe it's a bug with asyncio module and regression in python.
<xnox> doko, as it used to build with earlier 3.4 python.
<xnox> but i didn't bisect it yet, to hand over to you / upstream.
<doko> earlier 3.4 or 3.5?
<tumbleweed> cython uses asyncio?
<doko> at least some test case
<jtaylor> cython implements asyncio, also in python3.4
<tumbleweed> neat
<jtaylor> so you should be able to use await et. al. probably also in python2
<jtaylor> (never tested it though)
<cjwatson> pitti: Can you work out what's up with http://autopkgtest.ubuntu.com/packages/d/debci/xenial/s390x/ ?
<cjwatson> (blocking librabbitmq -> kamailio -> perl)
<pitti> cjwatson: will do
<cjwatson> thanks
<pitti> ok, it seems I finally untangled phpunit, mass-retrying the failed php builds
<cjwatson> nice
<cjwatson> I fixed findlib on s390x, so a bunch of retries going through for that too
<pitti> cjwatson: btw, are your lcy builders still busted? (most of them are "cleaning")
<pitti> cjwatson: my lcy instances are sometimes brittle, but they by and large survived over the holidays (I was quite surprised)
<cjwatson> pitti: looks like it, our clouds are in various pieces
<pitti> lgw seems to be back (was broken yesterday)
<mdeslaur> pitti: infinity promised to fix the phpunit-mock-object <-> phpunit circular build depends before the holidays...
<mdeslaur> pitti: I was waiting on that to see how many php5 stuff would then pass
<pitti> mdeslaur: good morning, happy new year!
<pitti> mdeslaur: indeed, it was phpunit-mock-objejct, phpunit, and php-codecoverage circularly depending
<pitti> mdeslaur: but it seems they work now; I'll revert the changes once britney settles down (I have the uploads locally prepared)
<mdeslaur> pitti: happy new year to you too! :)
<mdeslaur> pitti: awesome, thanks for fixing that!
<dgadomski> hey pitti, I guess noone reported any problems with fix for bug 1337873 on xenial, do you think we're good to proceed with earlier releases?
<ubottu> bug 1337873 in ifupdown (Ubuntu Vivid) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Medium,Confirmed] https://launchpad.net/bugs/1337873
<mhall119> thanks slangasek
<doko> dholbach, LocutusOfBorg1: any update on the boost1.58-mpisource package?
<dholbach> doko: I thought LocutusOfBorg1 would look into it
<dholbach> LocutusOfBorg1: AFAICT the boost1.58-mpi source package needs to be updated to have the same contents and version number as boost1.58
<pitti> dgadomski: yes, I think so
<dgadomski> pitti: cool, could you please sponsor it?
<pitti> dgadomski: yes, can do; I'll skip vivid though, that's going to be EOL in two or three weeks
<dgadomski> pitti: sounds good, thank you
<pitti> dgadomski: why is https://launchpadlibrarian.net/221884579/trusty_ifenslave_2.4ubuntu1.2.debdiff necessary for trusty, but not for precise or wily?
<dgadomski> pitti: the fix is only for 14.04+ and wily's ifenslave already has the necessary change
<pitti> dgadomski: ah, and there is no precise patch yet, I see
<dgadomski> pitti: that's right, there are so many differences in implementation that I was not able to backport it without backporting half of trusty ifupdown
<pitti> dgadomski: so I guess we just don't care for precise; after all, it has lived for so long without this that it hardly matters
<pitti> dgadomski: sponsored and bug updated
<dgadomski> pitti: thanks!
<LocutusOfBorg1> doko, I'm doing some other work, I''ll look at it soon (TM)
<pitti> cjwatson: FYI, that's debian bug 809265, race condition in the test
<ubottu> Debian bug 809265 in src:debci "debci: FTBFS: ./test_blame.sh failed at least one test (test_passing_the_test_resets_the_blame?)" [Serious,Open] http://bugs.debian.org/809265
<pitti> cjwatson: so if this unblocks stuff, I'm happy to ignore it for now
<pitti> cjwatson: (but looking at it right now anyway)
<cjwatson> pitti: Yeah, it will unblock stuff.  Thanks
<cjwatson> geneweb/s390x is fixed now, though p-m hasn't caught up yet
<pitti> cjwatson: hinted
<cjwatson> thanks
<doko> LocutusOfBorg1, just be aware that everything b-d on boost-mpi ftbfs currently
<pitti> cjwatson: debci fix committed to Debian git, FTR
<pitti> Laney, apw: blimey! I just got my autopkgtest quota bumped, 40 new instances!!!11!
<pitti> they zipped through the remaining queue in no time
<cjwatson> pitti: oh cool, thanks
<pitti> now armhf looks really bad :)
<apw> pitti, awsome, thats more like it
<Laney> pitti: nice! some new capacity arrived then?
<pitti> Laney: I don't think so, I just got my quota bumped
<pitti> Laney: apparently lcy and lgw already have enough capacity
<pitti> Laney: that's for x86 -- ppc64el still only has 15 parallel instances
<Laney> oh, well, good news either way
<LocutusOfBorg1> doko, I wasn't
<cjwatson> pitti: your debci hint version should be 1.0.1ubuntu1, not 1.0.1
<pitti> cjwatson: argh, sorry; fixed
<pitti> cjwatson: btw, I pushed your test fix upstream, thanks for that
<pitti> so we can sync 1.0.2 and it should be good
<cjwatson> pitti: ah, thanks, I evidently forgot about that
<cjwatson> pitti: does http://autopkgtest.ubuntu.com/packages/c/composer/xenial/amd64/ need to be retried without pinning?
<pitti> cjwatson: done so 10 mins ago, they are running
<pitti> (wholesale)
<cjwatson> pitti: or maybe that'll get sorted out when composer's armhf tests finish anyway ...
<cjwatson> pitti: thanks
<pitti> this becomes unnerving; /me bumps bug 1517426 and works on that RSN
<ubottu> bug 1517426 in Auto Package Testing "apt-get source the pinned versions, not the latest available ones" [High,In progress] https://launchpad.net/bugs/1517426
<pitti> cjwatson: ok, news on http://autopkgtest.ubuntu.com/ look much more promising now :)
<cjwatson> pitti: ah, indeed!
<cjwatson> down to 41 extra uninstallables for perl now
<cjwatson> 18 of those will be fixed by php5 autopkgtests being sorted out, the rest (plus at least 6 progressions) will be from insighttoolkit4/amd64 finishing building plus maybe a couple of rebuilds against that
<xnox> cjwatson, hm, but i thought insighttoolkit4 will fail the test-suite on amd64 and will ftbfs, no?
<xnox> oh i386 succeeded =) i guess you did things to it.
<pitti> cjwatson: great; on my side, armhf is swamped, but the queue contains the necessary retries, so at this point I think we should continue to look at this tomorrow morning
<xnox> cjwatson, it will take 3 days to build... it's non-parallel amd64 build.
<xnox> e.g. https://launchpad.net/ubuntu/+source/insighttoolkit4/4.8.1-1ubuntu3/+build/8174103
<smoser> infinity, i went ahead and tested ppc64el for https://bugs.launchpad.net/ubuntu-cdimage/+bug/1524366 also.
<ubottu> Launchpad bug 1524366 in livecd-rootfs (Ubuntu Trusty) "Add support for lts-wily kernel flavours in trusty" [Medium,Fix committed]
<pitti> cjwatson: err, except that I'm on a national holiday tomorrow  :) (but I'll have a look in the morning all the same)
<pitti> mdeslaur, cjwatson: FYI, I hinted the tests which are still failing everywhere (and for a long time) on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5
<pitti> so as soon as armhf catches up, it should hopefully become valid
 * pitti is almost tempted to let it in now
<mdeslaur> great!
<Odd_Bloke> cjwatson: I'm seeing "mount: /build/binary/boot/filesystem.ext4: failed to setup loop device: No such device or address" in  https://launchpadlibrarian.net/233040357/buildlog_ubuntu_xenial_s390x_cpc_BUILDING.txt.gz, which I haven't seen before; any ideas as to what that might be, before I start digging in to live{-build,cd-rootfs} code to try to debug it?
<pitti> slangasek, mdeslaur, infinity, stgraber, kees: reminder, TB meeting in 15 mins
<mdeslaur> pitti: ack
<Odd_Bloke> xnox: ^^^ is on s390x, so you might also have run in to something like it...
<xnox> Odd_Bloke, cjwatson: old kernel image, without loop.ko module, which is in -extra package in old kernel builds.
<xnox> Odd_Bloke, cjwatson: new kernels have it as built in.
 * xnox checks kernel version numbers.
<xnox> infinity, wgrant, cjwatson - either extra package should be installed, and loop modprobed. Or upgrade to 4.3.0-5.16 kernels throughout.
<xnox> Odd_Bloke, is that a good enough answer for you =)
<infinity> xnox: I'll upgrade all the buildds today.
<xnox> infinity, thanks \o/ =)
<Odd_Bloke> \o/
<cjwatson> xnox: 3> oh well
<Laney> pitti: what TB? :)
<pitti> Laney: tech board
<Laney> this one? https://launchpad.net/~techboard/+members
 * Laney is gently trolling, sorry
<pitti> Laney: ah right :)
<tseliot> pitti: hey, how is it that udevadm info reports properties of a pci device after this is added but I don't get all the said properties to match when using a udev rule?
<pitti> tseliot: without knowing the details, maybe your udev rule runs earlier than the one that adds these properties?
<tseliot> pitti: entirely possible. Maybe 71-seat-rules or 80-drivers then? http://pastebin.ubuntu.com/14412167/ (trying to get PCI_ID)
<pitti> tseliot: you could equivalently use the "vendor" and "device" attributes which don't depend on any extra probing
<tseliot> pitti: I'm doing RUN+="/bin/touch /run/u-d-c-nvidia-%k-%s{device}" and, while %k works, %s{device} doesn't
<pitti> tseliot: oh, I haven't seen that one, just $attr{device}
<tseliot> pitti: yes, no change though
<xnox> doko, barry - there is asyncio regression in 3.5.1 wrt 3.5.0. The regression is spotted by cython test-suite, it fails when using generators. Reverting asyncio module changes between .0 and .1 makes it pass again. Details are at Bug #1526613
<ubottu> bug 1526613 in python3.5 (Ubuntu) "ftbfs asyncio test failure with 3.5.1-2, used to pass with 3.5.0-2" [Undecided,New] https://launchpad.net/bugs/1526613
<xnox> i'm not sure how to bisect the changes further, given that asyncio module is imported into stdlib...
<dannf> cjwatson, doko, cyphermox : have you looked into the grub2 FTBFS? fwiw, i've determined it is due enabling linaro in gcc-5, but wasn't able to identify the specific change
<dannf> the chip errata workarounds seemed like a logical explanation, but disabling those in the CFLAGS didn't help
<cjwatson> dannf: I reported it on grub-devel@, and Leif was looking into adding the necessary relocation support
<dannf> oh, cool
<cjwatson> dannf: if you do happen to figure out compiler flags that disable the use of the relocations, that would be nice in the meantime, but it may not be possible
<LocutusOfBorg1> doko,
<LocutusOfBorg1> dput ubuntu boost-mpi-source1.58_1.58.0+dfsg-4.1ubuntu1_source.changes
<LocutusOfBorg1> please double check as soon as the upload is finished
<LocutusOfBorg1> :)
<LocutusOfBorg1> thanks
<cjwatson> pitti,Mirv: ubuntu-system-settings-online-accounts autopkgtests may need some attention; I can't quite see what's going on there.  http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/xenial/amd64/
<cjwatson> related to latest Qt?
<cjwatson> hm, maybe due to the libqt5gui5->libqt5xcbqpa5 depends->recommends change in qtbase-opensource-src 5.5.1+dfsg-10
<cjwatson> Mirv: what should gain a dependency on libqt5xcbqpa5 to keep autopkgtests working if not libqt5gui5?
<infinity> A reasonable change if it's a plugin, but yeah, rdeps need tending to, then, to see if they load it.
<cjwatson> Maybe autopilot-desktop would be a good package to gain a dependency on libqt5xcbqpa5?
<ESphynx> doko: thanks, it built this time with 128 :)
<Mirv> cjwatson: probably autopilot-desktop yes, although it's an option to deviate from Debian too there and they are also still juggling them.
 * Mirv AFK though now
<Mirv> cjwatson: they're thinking of putting the plugins back to libqt5gui5 after all so while waiting for it (they're doing it for 5.6) we could also change back the Recommens to Dependency
<Mirv> feel free to upload any solution(s) you want, I'm away tomorrow
<jdstrand_> pitti: hi! looking at the apparmor regressions on excuses, the lxc ones are all due to "There is no download available for release=xenial, stream=daily, arch=<arch>"
<jdstrand_> pitti: the ubuntu-system-settings-online-accounts failures for amd64 and i386 are "18:02:02.016 WARNING testcase:547 - Failed to create Touch device for bug lp:1297595 workaround: Unable to instantiate any backends"
<jdstrand_> pitti: "UInput: UInputError('"/dev/uinput" cannot be opened for writing',)"
<jdstrand> pitti: this upload involved no code changes (only changed the nameservice abstraction)
<Mirv> right, some circular dependency thing coming with 5.6 if I understood correctly and they'll merge libqt5xcb5 back to libqt5gui5 so it'd be ok to change Recommends -> Depends for us for the time being. mitya57 can confirm if he's around, I can't check the details right now
<mterry> coreycb, re: bug 1526927 -- good that the python-keystoneauth1 build-depend got fixed in debian.  But why was it building without it?  is the dep not actually needed for the tests or do the py3 tests not fail the build when the dep is missing?
<ubottu> bug 1526927 in python-openstacksdk (Ubuntu) "[MIR] python-senlinclient, python-openstacksdk, python-keystoneauth1" [Undecided,New] https://launchpad.net/bugs/1526927
<coreycb> mterry, it's not a test requirement so I'd have to guess we were getting lucky building without it
<coreycb> mterry, it's a run-time requirement
<mterry> coreycb, our only delta with debian (added in 0.7.1-1ubuntu1) is to add a build-dep on the py2 version to fix tests
<mterry> coreycb, so it presumably is at least partly a build-time requirement?
<coreycb> mterry, you're right, it's used in some tests too.  I was just going off of it being in requirements.txt only.
<mterry> coreycb, but then I'm wondering why we didn't need the py3 versoin?
<coreycb> mterry, that's a great question.  let me give it a run and make sure tests are actually running.
<coreycb> py3 tests.
<mterry> cool thanks
<coreycb> mterry, ok, so the current version in xenial doesn't run py3 tests
<mterry> huh?  I thought I saw it doing that, must have missed that
<coreycb> mterry, however the next version, that needs to get uploaded, does
<mterry> coreycb, yup I see that now
<coreycb> mterry, I need to poke some folks to get that uploaded
<mterry> coreycb, ok with that caveat, I'll approve
<coreycb> mterry, great, thanks
<barry> xnox: hey.  interesting.  did you end up reporting it upstream?
<infinity> Odd_Bloke: s390x buildds should have loopy kernels now.
<barry> robru: i merged and uploaded the new pylint, but it will wait until astroid un-depwaits and builds.  i believe cyphermox is assigned the mir for lazy-object-property, so if/when that's approved the queue should ungunk itself
<robru> barry: oh cyphermox is off this week. can anybody else pick that up/
<smoser> any one want to hazard to guess what would cause newaliases to fail
<smoser> in a qemu-static chroot
<smoser> https://bugs.launchpad.net/debian/+source/postfix/+bug/1531299
<ubottu> Launchpad bug 1531299 in postfix (Ubuntu) "postfix upgrade can fail due to "newaliases: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol"" [Medium,Confirmed]
<barry> robru: anyone else on the mir team: https://launchpad.net/~ubuntu-mir/+members#active
<smoser> utlemming, ^ that is our maas image arm64 build failure cause
<robru> barry: but will somebody grab it or do I have to hassle people?
<barry> robru: since the issue is currently assigned to cyphermox you probably have to hassle people
<robru> barry: oh mterry did the assignment. *shakes fist*
<mterry> robru, what I do?
<robru> mterry: you assigned https://bugs.launchpad.net/ubuntu/+source/lazy-object-proxy/+bug/1531033 to cyphermox but he's off this week
<ubottu> Launchpad bug 1531033 in lazy-object-proxy (Ubuntu) "[MIR] lazy-object-property is new dep for main package pylint" [Undecided,Confirmed]
<mterry> robru, ah didn't know
<mterry> robru, this is urgent?  I can look
<robru> mterry: well, not super urgent. it fixes pylint, which is important before release, but it's not like the world is burning or anything.
<mterry> robru, sure.  But no reason to wait a week
<mterry> robru, I bet it's small, I can probably bang it out now
<robru> mterry: I don't know what your workload is like ;-)
<robru> mterry: thanks!
<cjwatson> smoser: why are you doing image builds inside qemu-static?
<utlemming> cjwatson: that is the evilness we are trying to get away from
<infinity> utlemming: So, let's get away from it? :)
<infinity> utlemming: What's still blocking that?
<cjwatson> ah, right, this is not something you're seeing in LP then?
<utlemming> cjwatson: no, that is the KVM builders for the cloud images
<utlemming> infinity: working on it :)
<infinity> smoser: As for that specific error, it looks more like a misconfigured chroot in general rather than a qemu-related problem but replacing that hack seems more important than fixing it.
<cjwatson> Mirv: OK, moving Recommends back to Depends for the moment, then.
<cjwatson> Mirv: (but feel free to revert if you have a better solution, this is just to unblock stuff)
<lpotter> Saviq: any way to get qmake to work with sbuild on arm?
<Saviq> lpotter, hey, not unless you're willing to hack around debian/rules
<Saviq> lpotter, I assume you mean to cross-build for arm, not "just" qmake on arm?
<lpotter> yes cross
<Saviq> lpotter, so yeah, we have qt5-qmake-arm-linux-gnueabihf
<Saviq> which is a qmake binary built so it's prepared for cross-building (library paths and such, which are unfortunately baked into qmake build-time)
<Saviq> lpotter, but I don't think there's any package that does the magic in their debian/ yet
<lpotter> ever tried using qtchooser?
<Saviq> lpotter, you'd need to add it to Build-Depends for [i386, amd64] unconditionally, or generate debian/control in debian/rules clean after querying dpkg-architecture, and do the same for dh_override_auto_configure
<Saviq> lpotter, qtchooser doesn't really help much here, since we only have qmake prepped for cross, not the whole thing
<Saviq> lpotter, it is an unfortunate design decision of qmake that it compiles the paths in build-time
<Saviq> lpotter, qtchooser only lets you configure a single PATH for all qtchooser-managed binaries, not per-binary (afaict)
<Saviq> [...] unfortunate in the sense it's not compatible with debian/ubuntu's approach to multiarch
<Saviq> other build systems have different profiles that you can choose from runtime
<lpotter> ya qtopia had to do some real funky stuff with qmake, coming up with qtopiamake.
<Saviq> lpotter, at least it's doable now (if inconvenient...), but it's really just a case of someone doing it for the first time and others will be able to copypasta ;)
<Saviq> lpotter, FYI, if you want to try, I did see an issue with PKG_CONFIG_PATH not being set right, had to point it at the armhf path
<Saviq> but it worked after all
#ubuntu-devel 2016-01-06
<lpotter> ok, I might some day
<Saviq> slangasek, infinity, you're the only ones ~active at this hour with "access to snakefruit", if you're around, could I please ask for a re-run of the regression here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8 (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests)
<slangasek> Saviq: looking
<Saviq> thanks
<slangasek> Saviq: ok, running: http://autopkgtest.ubuntu.com/running.shtml
<pitti> jdstrand: I hinted apparmor
<dholbach> good morning
<pitti> jdstrand: apparmor is still trapped by perl, but I hope we get that in RSN
<pitti> cjwatson: php5 landed, uwsgi is a valid candidate
<asac> looking for a package/software-compoennt that uses kbuild that isnt kernel, uboot, busybox... anyone knows?
<asac> oh vbox
<asac> seems the only one using the kbuild package from archive in build-depends
<asac> of course doesnt mean that others have their kbuild inline
<asac> anyonw knows any smallish piece of soft let me know!
<asac> thanks
<Laney> cjwatson: ok to steal your sbuild merge?
<Odd_Bloke> xnox: So what's the grub situation with s390x?  Do we need it at all?
<xnox> Odd_Bloke, this is not the bootloader you are looking for =) there is no grub on s390x as far as I can see =)
<xnox> Odd_Bloke, there is /etc/zipl.conf and well zipl.
<Odd_Bloke> xnox: OK, cool; that's what I figured. :)
<xnox> Odd_Bloke, there is this magic bootmap file.
<xnox> Odd_Bloke, http://paste.ubuntu.com/14418965/
<xnox> so given the config file, zipl generates bootmap file, which can include the kernel+initrd+parameters inside it, or reference them on disk... magically.
<xnox> and somehow this bootmap file is found by z/VM OS on disk and manages to be "executed" as the intial programme, by the inital programme loader.... aka "boot".
<Odd_Bloke> xnox: Would that zipl.conf work generally (it looks like it to me)?  If not, do we have a good way of generating them?
<xnox> Odd_Bloke, we don't currently have a good way to generate them (e.g. for cloud images / non-standard things)
<xnox> Odd_Bloke, the d-i installer writes out a slightly longer version.... https://sources.debian.net/src/zipl-installer/0.0.28/debian/zipl-installer.postinst/
<xnox> which has default, timeout and both /boot/vmlinuz and /boot/vmlinuz.old "boot menu options"
<Odd_Bloke> OK.
<xnox> Odd_Bloke, i wanted to write something like update-zipl, that would do something similar to our update-grub, and eg. detect all kernels and generate "Ubuntu", "Ubuntu recovery", and then all available kernels [normal|recovery] boot options.
<xnox> Odd_Bloke, but i have not done something like that yet.
<Odd_Bloke> But once we find the right configuration, it doesn't need to have values plugged in for each different image build, which is good. :)
<xnox> to me, that would be handy, and like useful / ubuntu-like. On the other hand average s390x user, is capable of modifying zipl.conf and booting a different kernel =)
<Odd_Bloke> xnox: Yeah, that would be handy.
<LocutusOfBorg1> good morning
<xnox> or like figure out "this is unconfigured cloud-image, maybe i should add "cloud-init-first-boot-ever" param to the kernel cmdline..."
<Odd_Bloke> xnox: What would that be needed for?
<xnox> Odd_Bloke, on first initramfs boot, determine available NIC and DASD drive and activate that, and store the results of such activation on disk.
<xnox> Odd_Bloke, at the moment, instead of like activating all the things that are discovered... we do nothing, or like activate only the nic's / drives that users chose to configure at install time, or later by tweaking sysconfig-hardware.
<Odd_Bloke> Oh, OK; the "cloud-init" bit threw me off. ;)
<xnox> "something-not-installed-with-d-i-but-debootstrapped-like-thing"
<LocutusOfBorg1> xnox, what does it happen if I run a syncpackage boost-defaults?
<xnox> LocutusOfBorg1, permission denied =) cause it's in main ;-)
<LocutusOfBorg1> xnox, ok, the question actually is: can it be syncable?
<LocutusOfBorg1> I did a debdiff, but I'm confused
<xnox> LocutusOfBorg1, do you understand the split between main and universe, and what are the requirements for main?
<xnox> (usually boost-defaults are updated in ubuntu slightly ahead of debian)
<LocutusOfBorg1> xnox, sorry, not a native speaker :)
<LocutusOfBorg1> yes, I understand that I can't sync it, because of main, and not universe
<xnox> not that.
<LocutusOfBorg1> and I also understand that boost transitioned before in ubuntu rather than in debian
<xnox> LocutusOfBorg1, in general, in ubuntu, why do we have main/restricted/universe/multiverse and what are the differences between them?
<cjwatson> Laney: sure, go ahead, thanks
<LocutusOfBorg1> yes, I know the differences, and I also know I can only touch universe :)
<xnox> LocutusOfBorg1, looking at it, i think boost-defaults can in fact be synced, let me double check things.
<Laney> cjwatson: ta
<Laney> and hooray for working --arch
<xnox> LocutusOfBorg1, yeah, it could be synced.
<LocutusOfBorg1> xnox, the question is more "general", I'm looking to possible things to sync, and I want to be sure that just a little debdiff and looking at changes is the correct thing to check
<LocutusOfBorg1> lets discard the "main" thing please :)
<xnox> right.
<LocutusOfBorg1> I'll learn to check that as soon as I get many permission denied :)
<xnox> LocutusOfBorg1, yes boost-defaults is syncable at the moment. And instead of syncpackage, you can do e.g. requestsync =)
<LocutusOfBorg1> xnox, I use requestsync since a lot of time actually :)
<xnox> LocutusOfBorg1, and then somebody (a core-dev) can sponsor that for you.
<LocutusOfBorg1> BTW the question is also: https://packages.qa.debian.org/b/boost-defaults.html
<LocutusOfBorg1> I did a debdiff between unstable and xenial
<LocutusOfBorg1> and then I looked at the patch on BTS (right corner, at the bottom)
<LocutusOfBorg1> they look different
<xnox> yes....
<LocutusOfBorg1> oh the script didn't run after the last debian upload
<xnox> the one online looks out of date.
<LocutusOfBorg1> fine then
<LocutusOfBorg1> yes, indeed
<LocutusOfBorg1> there is the last debian entry missing
<xnox> maybe that should be reported somewhere....
<xnox> cjwatson, is patches.ubuntu.com healthy at the moment? or does it only generate a patch once, and that's it?
<LocutusOfBorg1> so the lesson learned today is: do not look at patches.ubuntu.com, but do the job yourself :)
<LocutusOfBorg1> thanks a lot
<xnox> LocutusOfBorg1, i think the patch might be odd, because ubuntu boost-defaults is a "fork" rather than on top of a debian revision.
<xnox> because we did a 0ubuntu1, before ...1 version was available in debian.
<LocutusOfBorg1> yes, probably mergechangelogs doesn't work with that
<cjwatson> xnox: it's failing - I'll fix it up this morning
<cjwatson> xnox: (I knew about it already by mail notification but haven't had a chance to poke it yet)
<LocutusOfBorg1> BTW boost in ubuntu should be finally fixed <-- doko
<LocutusOfBorg1> it migrated
<doko> ta
<LocutusOfBorg1> doko, will you retry the build failed because of boost?
<doko> LocutusOfBorg1, done for the one I know of
<LocutusOfBorg1> thaks
<LocutusOfBorg1> thanks
<cjwatson> xnox: patches.u.c should sort itself out in a bit
<xnox> thanks a lot =)
<LocutusOfBorg1> oh well, I can act as sponsor, but I can't unsubscribe sponsors-team from the bug reports :)
<Laney> you could join the team if you ask an admin
<LocutusOfBorg1> lets do little steps :)
<LocutusOfBorg1> but I will eventually
<cjwatson> xnox: any objection to me demoting insighttoolkit4 and its three revdeps (elastix, itksnap, plastimatch) to -proposed temporarily to detach them from the perl transition?
<cjwatson> I'm pretty bored of waiting
<LocutusOfBorg1> cjwatson, I have no objection in *removing* them :)
<LocutusOfBorg1> that transition is sooooo bad
 * LocutusOfBorg1 speaking on the debian side
<cjwatson> well, that's a different argument :)
 * LocutusOfBorg1 was just jocking
<mdeslaur> xnox: I'm stealing your ldb merge
<mdeslaur> seb128: I'm stealing your samba merge
<Laney> you feef
<mdeslaur> heh
<LocutusOfBorg1> stealing work is always nice :)
<mdeslaur> funny how people never steal my work :P
<cjwatson> pitti: I meant to ask you about what's going on with e.g. http://autopkgtest.ubuntu.com/packages/o/openafs/xenial/s390x/ - there are a couple of packages that fail like that, and it's notable that they work fine when the trigger is linux-meta.  no kernel in the autopkgtest chroot maybe?
<Odd_Bloke> xnox: https://launchpad.net/~daniel-thewatkins/+livefs/ubuntu/xenial/cpc/+build/48062 \o/
<Odd_Bloke> xnox: So those don't contain any zipl stuff etc.; they're effectively just what we produce for the other arches.
<xnox> Odd_Bloke, excellent.
<xnox> Odd_Bloke, i guess i could grab disk1 and mangle it, until it becomes bootable?
<xnox> Odd_Bloke, and then report back to you? =)
<Odd_Bloke> xnox: Yeah, having a clear set of changes to make would be good.
<Odd_Bloke> xnox: Because the build process is 'upload to PPA, build, wait for publish, kick off livefs build, wait', which isn't the most nimble way to iterate. :p
<cjwatson> xnox: did you see my insighttoolkit4 question above?
<Odd_Bloke> xnox: So am I OK to leave the cloud images until I hear back from you?
<xnox> cjwatson, i have not.
<cjwatson> 12:03 <cjwatson> xnox: any objection to me demoting insighttoolkit4 and its three revdeps (elastix, itksnap, plastimatch) to -proposed temporarily to detach them from the perl transition?
<cjwatson> 12:04 <cjwatson> I'm pretty bored of waiting
<xnox> cjwatson, i want to demote insighttoolkit4 with fire =)
<cjwatson> xnox: right :-)  I'll take care of that then, thanks
<xnox> it pretty much made mono transition non-trivial 2 month affair, instead of it being trivial.
<cjwatson> xnox: (I'll wait until this afternoon though - I'm going out in an hour or so, and if there's a decent chance that perl will land I want to be around to disable the publisher to make sure that it all lands in one go)
<cjwatson> mind you, at this rate autopkgtests will take an hour or two to catch up anyway.  sod it
<cjwatson> done
<pitti> cjwatson: right -- linux-meta* triggers actually do install that kernel, so that dkms modules have something to build against; but the default lxc containers don't have a kernel
<pitti> cjwatson: I think the fix for that would either be to install the default kernel headers (but this would still fail if dkms modules don't work against that, which does happen), or perhaps better, ignore linux-meta* triggers when determining "ever passed"
<pitti> cjwatson: I filed that as bug 1531488
<ubottu> bug 1531488 in Auto Package Testing "ignore linux-meta triggers for "ever passed"" [Medium,In progress] https://launchpad.net/bugs/1531488
<cjwatson> thanks
<pitti> cjwatson: we are still waiting on insighttoolkit, I presume?
<pitti> oh my, https://launchpad.net/ubuntu/+source/insighttoolkit4/4.8.1-1ubuntu4/+build/8449963 only started an hour ago
<pitti> ah, nevermind, saw backscroll above
<cjwatson> pitti: yep, hopefully once the current autopkgtest backlog clears a bit we should be good
<cjwatson> (need libmath-bezier-perl/armhf)
<mitya57> cjwatson, your upload looks correct, thanks
<mitya57> (cc Mirv)
<mitya57> (though it's unrelated to Qt 5.6, the circular dependency coming in Qt 5.6 is unrelated thing)
<mitya57> s/unrelated thing/a different thing/ to not repeat myself :)
<smoser> cjwatson, infinity the maas image build process makes a few changes to a cloud image build. that all is hoped to be moved to buildd and thus running native at some point.  wrt "misconfigured chroot", i'm not sure what you mean.   the chroot has functional networking (apt-get update works), and also in that particular one, sys and proc and even dev are mounted. additionally, the same set of things work happily doing native chroot (i
<smoser> e amd64 -> amd64) without qemu-static.  so yes, i think its qemu-static related, and i was confused by that also as it does not seem likely.
<mapreri> so, a package taking over the only binary of another package just reached the release pocket.  do you confirm me that old source is going to disappear automagically from xenial? (and what about the open bugs against it?)
<mapreri> or is there a cruft report, similar to what debian has, and a human process it every so often?
<LocutusOfBorg1> python-udiskie, pencil ^^^
<LocutusOfBorg1> e.g. with udiskie in -release I think https://launchpad.net/ubuntu/+source/python-udiskie should disappear
<rbasak> mapreri: it isn't automatic, but isn't a problem and will be dealt with by an archive admin before release usually. It should appear in this report: http://people.canonical.com/~ubuntu-archive/nbs.html
<rbasak> mapreri: the bugs will need to be handled separately. Please close or reassign with a suitable comment as appropriate.
<LocutusOfBorg1> mmm rbasak I don't see udiskie here
<jdstrand> pitti: hi!, re apparmor> thanks!
<Odd_Bloke> infinity: Before the holidays you were going to see if the latest powerpc image I had produced was bootable.  I don't know if you got anywhere with that then, but there's one for you to test here, if you have the time: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/48068
<Girish> Hi! Are Ubuntu bugs in launchpad marked as per their difficulty? I'm new to Ubuntu. Where can I find some easy bugs to squish?
<dobey> no, difficulty to fix things is subjective.
<dobey> but there are some trivial low hanging fruit type bugs that are tagged in a certain way, iirc
<roadmr> Girish: some projects (not all) add a "bite-size" or similar tag to small, easy bugs
<sladen> Girish: is there perhaps something like a spelling mistake you've noticed in your day-to-day use of Ubuntu?
<dobey> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<dobey> though some of those are obviously not "bite sized"
<dobey> there's also the "verification-needed" tag, which is on things that have a proposed fix in the proposed pocket, and they need testing and verification that the fix is good or not
<Girish> Cool. Thanks will check them out.
<cjwatson> rbasak,mapreri: NBS only covers binaries, not obsolete sources, for which there is unfortunately no cruft report.  Otherwise you're correct.
<cjwatson> mapreri: That said, for packages that were removed from Debian and are unmodified in Ubuntu, we'll generally pick up the removal as a result of following along with removals from Debian unstable.
<mapreri> cjwatson: pencil was never in debian
<mapreri> cjwatson: and I just added a delta to pencil2d to build a transitional package and take it over (pencil2d being pencil's maintained fork)
<cjwatson> right, file a bug and subscribe ubuntu-archive for the removal, then
<mapreri> cjwatson: cool, thanks
<cjwatson> pitti: autopkgtest sad?  http://autopkgtest.ubuntu.com/running.shtml says "[an error occurred while processing this directive]
<cjwatson> "
<pitti> cjwatson: currently at it
<pitti> cjwatson: the page had some leftovers, I had to restart the collector; it will start showing stuff once the first request comes in again (queues are empty ATM)
<pitti> I'll also re-run the tmpfails etc.
<pitti> at least armhf has finally caught up \o/
<pitti> hmm, "no route to host", cloud troubles again?
<cjwatson> pitti: ah good, thanks.  check #is-outage, there've been various PS4.5 outages
<pitti> it seems to work again right now, let's see for how long
<cjwatson> pitti: excuses seems a little confused about the state of libmath-bezier-perl triggered from perl
<cjwatson> test in progress, but it's not on running.shtml and http://autopkgtest.ubuntu.com/packages/libm/libmath-bezier-perl/xenial/armhf/ has a most recent run >four hours ago
<pitti> running.shtml is back (with retrying regresisons with apt pinning)
<pitti> cjwatson: yep, next britney run will re-trigger them
<pitti> they fell victim to repeated tmpfails and giving up
<cjwatson> ah :-/
<pitti> all workers repeatedly failed due to "no route to host" (amqp server), and some noise
<pitti> cjwatson: FYI, in those cases I wait until britney is not running (or running --print-uninst), and remove proposed-migration/data/xenial-proposed/autopkgtest/pending.json (britney's cache which tests it already triggered in previous runs)
<pitti> this re-requests all "in progress"
<cjwatson> ok, I'd been steering clear of doing that since there's an admonition in the wiki page not to do that in general :)
<pitti> ugly, and I'm slowly detecting them better, but there are still cases which we don't reliably detect as "tmpfail"
<cjwatson> pitti: would it maybe make sense to just force-badtest libmath-bezier-perl/0.01-2 ?  the most recent armhf test in fact also ran against perl 5.22, and it's going to take aaaages to get round to it
<cjwatson> pitti: could you please also bump the version of your sbuild hint to 0.67.0-2ubuntu1 ?
<lfaraone> I'm trying to figure out the right way to fix bug 798414 â namely, if you have a separate /boot partition and just do automatic updates, you'll eventually fill up /boot and have to resolve it manually.
<ubottu> bug 798414 in initramfs-tools (Ubuntu) "update-initramfs should produce a more helpful error when there isn't enough free space" [Medium,Triaged] https://launchpad.net/bugs/798414
<pitti> cjwatson: done
<lfaraone> The cleanest solutions involve some more logic outside of dpkg that manages your kernel packages, ensuring that you have, idk, latest, current-running, and a few previous.
<lfaraone> but I don't know if we do that anywhere else in the project, and there is very possibly a solution I'm just not thinking of.
<cjwatson> pitti: the sbuild part?  thanks
<lfaraone> cccccceefhjhcgefnfufdjeuvjjbuvkkbdtuvllcufej
<cjwatson> lfaraone: things are hooked up nowadays so that that's how apt-get autoremove will behave
<cjwatson> lfaraone: although some people report that not working, I think possibly because they've used "partial upgrade" in u-m
<lfaraone> cjwatson: hm. would it be safe to run autoremove automatically?
<cjwatson> difficult
<lfaraone> this e.g. caused tech support questions from my mother. :P
<cjwatson> maybe it would be possible to write a python-apt program that did the kernel parts automatically?
<pitti> cjwatson: done> yes, bumping the sbuild hint
<arges> cking: is bug 1527460 fixed in xenial?
<ubottu> bug 1527460 in fwts (Ubuntu) "fwts PCIe ASPM tests are throwing Segmentation fault" [High,In progress] https://launchpad.net/bugs/1527460
<lfaraone> cjwatson: sure. i'd be interested in working on thatâ¦ would that be something that would run as a separate cron, or is there an existing project I should integrate it with?
<pitti> cjwatson: ah, overlooked the libmath-bezier-perl/0.01-2 thing, sorry; added the hint
<cjwatson> pitti: cool cool, thanks
<cjwatson> lfaraone: I don't know, I'm afraid
<cjwatson> there are some apt cron jobs, perhaps there
<cking> arges, it will be on the fwts 16.01.00 release
<tkamppeter> Hi, I have a question about Upstart .override files. I /etc/init/cups.conf "respawn" is set and I want to de-activate respawning in the /etc/init/cups.override file, for on-demand use of CUPS. How do I proceed?
<pitti> cjwatson: darn, we actually need both sbuild hints
<pitti> cjwatson: but at this point it might actually be easier to force-skiptest perl?
<pitti> as this is quite a whack-a-mole game
<cjwatson> pitti: sbuild/armhf is running at the moment, which should make that not a problem
<pitti> cjwatson: added the skiptest
<pitti> bbl
<cjwatson> pitti: though I was considering suggesting the same thing, so yeah
<cjwatson> pitti,infinity,slangasek: please could you "force-skiptest libfilesys-df-perl/0.92-5build2" and "force-skiptest exim4/4.86-7ubuntu2" - same reason as perl, it's because the force-badtested sbuild failure is for an older version on armhf and we can't have both versions
<cjwatson> sbuild/armhf has restarted several times, so I'm not hopeful of it working
<infinity> cjwatson: I can give it a jab.
<cjwatson> thanks
<pitti> infinity: you are adding the hints? ok
<infinity> Done.
<cjwatson> great
<infinity> Odd_Bloke: What am I trying to boot?  disk1.img?
<Odd_Bloke> infinity: Yep, think so.
<Odd_Bloke> infinity: (I mean, you tell me :p)
<pitti> cjwatson: sbuild/armhf repeatedly causes the container to fail rebooting, that's also what makes the workers so slow
<pitti> will look at that tomorrow
<cjwatson>  orig: 307+0: a-66:a-34:a-33:i-33:p-36:p-34:s-71
<cjwatson>   end: 300+0: a-65:a-34:a-33:i-33:p-36:p-34:s-65
<cjwatson> disabling publisher so that that will all land in one chunk
<infinity> Odd_Bloke: I assume it'll fail to boot completely due to cloud-init weirdness or something, but we're just looking to see if bootloader->kernel->init work?
 * infinity is downloading.
<infinity> Odd_Bloke: And nope.  Dumps me to a grub shell.
<Odd_Bloke> infinity: Hmph; could you pastebin the command you're running so I can test future iterations myself?
<infinity> Odd_Bloke: http://paste.ubuntu.com/14422052/
<infinity> Odd_Bloke: Adjust cores and memory to taste and not overload whatever host you're using. :P
<mhall119> slangasek: so the Xubuntu devs tell me they're still waiting to hear back from you on https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
<hallyn> in qemu, the init scripts were moved at version 1:2.3+dfsg-4ubuntu1 from qemu-system-x86 to qemu-system-common.  The defaults file was accidentally not moved, so it simply didn't exist between 1:2.3+dfsg-4ubuntu1 and now.
<hallyn> at 1:2.3+dfsg-4ubuntu1, qemu-system-common B/R qemu-system-x86
<hallyn> so now if i put the defaults file into qemu-system-common, do i need to again B/R qemu-system-x86?
<hallyn> i.e. if someone has preexisting defaults file and upgrades, is the default file rightnow just orphaned, or is it seenas belonging to qemu-system-x86 in the latest version?
<hallyn> dpkg -S says it belongs to qemu-system-x86, so i guess that's my answer
<xnox> mhall119, slangasek: the requested changes have not been made still. https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167/comments/714269 commented to remind about that, and explain in more details.
<xnox> infinity, >_< 30 GB of RAM =) fun.
<hallyn> though a test run with handbuild pkg suggests it's fine
<Unit193> xnox: Uh, that's not really what we're aiming for here, though.  It's not really a "normal desktop" and "Super featurefull desktop" which is what you're/that's implying, it's "Normal desktop" and "OK lets strip everything out except the DE itself", which then implies the user actually knows how to add whatever backends he needs.
<xnox> Unit193, ...... this is exactly what desktop vs dvd used to be =)
<infinity> No it's not.
<Unit193> So, 'desktop' was actually missing a load of stuff?
<xnox> Unit193, one bigger than the other. adding a new product, is extra un-necessory complexity, when dvd/desktop already exist.
<infinity> desktop was always a complete desktop, dvd just had "more stuff".
<Unit193> No browser, office suite, some gvfs backends missing, etc?
<hallyn> stgraber: ^ do yo uknow offhand? mainly i can't figure why dpkg -S is telling me the file still belongs to qemu-system-x86
<hallyn> (with my tst pkgs that didn't happen)
<infinity> hallyn: Regarding your upgrade question, keep in mind that we support upgrades from trusty. :P
<hallyn> infinity: right but -common already B/R a recent versin of -x86, though that is handled
<xnox> infinity, Unit193: i agree with slangasek on the merge proposal: mv desktop dvd; touch desktop. Rather than create a "core" variant for _everything_ =)
<infinity> hallyn: And orphaned conffiles will still belong to the package that orphaned them unless you use rm_conffile.
<hallyn> s/though/so/
 * xnox hates core, it's overloaded term by now three times over
<infinity> hallyn: Or if their Replaced by shipping it in another package.
<hallyn> ok, so when they're replaced by shipping in another package dpkg won't complain?
<infinity> s/their/they're/ ... Wow, thanks internet.
<Unit193> xnox: Can't we rename dvd to core then? :P  And, at least we did this right before trusty hit, and based it off of something even older than that so it's not just following the trend! :P
<stgraber> hallyn: sounds like the orphaned without rm_conffile case
<infinity> hallyn: It will complain if there are changes to the file.
<hallyn> so better to update the B/R version numbers?
<xnox> Unit193, there is core already in other parts of the things, that means a tarball without a kernel. i'm not sure which parts of things build it though.
<infinity> hallyn: Updating B/R versions is correct in your current context.
<hallyn> ok thx
<infinity> hallyn: There's a lot more pain involved in "properly" moving conffiles between packages, but that depends on level of carefactor and odds that people have edited it.
<hallyn> (odd that my hand-built test packages behaved differently, but i probably just messed them up)
<xnox> Unit193, you really do not want a tarball without a kernel =) which at one point was based of lubuntu on armhf or some such.
<Unit193> xnox: Hah, not really.  But dvd/desktop is certainly not what we're aiming for either, it's the opposite.
<xnox> Unit193, image if current xubuntu download button on your website from xenial on points to -dvd-.iso. That's the new "Xubuntu"
<infinity> xnox: core was never lubuntu.
<xnox> Unit193, image that minimal xubuntu, with just de and not much else (aka code name core) is the download called -desktop-.iso. (aka desktop-only)
<Unit193> !info lubuntu-core
<ubottu> lubuntu-core (source: lubuntu-meta): Lubuntu Desktop environment - minimal installation. In component universe, is optional. Version 0.62 (wily), package size 3 kB, installed size 14 kB (Only available for i386; amd64; powerpc; armhf)
<xnox> Unit193, do you under stand what i'm trying to do?
<Unit193> xnox: I understand, I don't like.
<xnox> Unit193, for both *buntu-minimal would have been a better name....
<Unit193> xnox: I don't exactly disagree, but at least that hit before all the Ubuntu Core stuff hit the fan so it's not trying to use the advertisement.
<infinity> I still like xubuntu-lite, if you're bikeshedding names, but really, it's a whole lot of who cares.
<infinity> We've been around and around with this for months.
<infinity> xnox: The problem with the desktop/dvd proposal is that it implies that Xubuntu-desktop is actually a full desktop.  At least, if you're being consistent with Ubuntu history.  It doesn't fix confusion, just shifts it.
<infinity> xnox: ubuntu-desktop versus dvd was never about one being minimal/crippled and one being complete, it was about one fitting on a CD and one having extra stuff.
<xnox> Unit193, btw do you really want to images?
<xnox> as far as I remember e.g. edubuntu has a ubiquity plugin and offers a choice of DE's.
<Unit193> infinity: Or xubuntu-bare. :D  Oh the implications!
 * Unit193 ducks.
<dobey> all i want is ðº
<xnox> wouldn't you want a single xubuntu-desktop.iso and a page/tick-box "install just minimal DE bare lite core fizz buzz"
<xnox> dobey, .... AND A LOLLIPOP!
<dobey> xnox: i guess those two things don't go well together. that's why they come in separate packages
<Unit193> xnox: Actually, Ubuntu Studio has been working on that.  But no, not as far as I've ever heard.
<Unit193> infinity: Thanks very much, btw!
<barry> xnox: did you ever report LP: #1526613 upstream to cpython or cython?
<ubottu> Launchpad bug 1526613 in python3.5 (Ubuntu) "ftbfs asyncio test failure with 3.5.1-2, used to pass with 3.5.0-2" [Undecided,New] https://launchpad.net/bugs/1526613
<pitti> cjwatson: wheeee! ^5s
 * Laney got email about some ancient uploads migrating :)
<pitti> excuses is still big, but nowhere near as bad as it was at the beginning of the week
<pitti> perl and php were a good chunk of it
<pitti> task for tomorrow: go-faster stripes for armhf
<Bluefoxicy> why does software center use a light green text on a white background anyway?
#ubuntu-devel 2016-01-07
<teward> did the perl 5.22 transition finish already?
<Unit193> teward: https://launchpad.net/ubuntu/+source/perl
<Bluefoxicy> Transition to what?  An expanded list providing duplicate keys in a hash?
<teward> that answers the question xD
<teward> Unit193: thanks  (the transition tracker shows one thing still failing, hence the question)
<Bluefoxicy> no docker 1.9 in next LTS?
<Bluefoxicy> the new docker-compose allows setting ulimits in the compose file, which is a pretty major feature
<Unit193> Just means I can do my perl5.22 rebuilds now too.
<cjwatson> teward: the tracker is only a guide, and in this case that's only failing because I hadn't yet done NBS removals following the transition (doing now)
<teward> cjwatson: ah, OK, i should've known when nginx 1.9.6-2ubuntu2 landed that the perl migration finished :P
<teward> thanks though
<Bluefoxicy> nginx 1.9!
<Bluefoxicy> Ubuntu 16.04 LTS will have http2 capability
<teward> um
<teward> maybe at some point
<teward> but not right now
<Bluefoxicy> ... as if that matters.  Running nginx out of a docker container is easy.
<teward> (talk to the Security Team)
<cjwatson> ECHAN?
<Bluefoxicy> teward:  http2 is part of nginx 1.9
<teward> Bluefoxicy: optional module, has to explicitly be enabled
<Bluefoxicy> ah
<teward> you may be interested to read the merge bug
<cjwatson> oh right
<Bluefoxicy> so it's in the docker container for official, but not enabled in nginx on Ubuntu ok
<teward> https://launchpad.net/bugs/1510096
<ubottu> Launchpad bug 1510096 in nginx (Ubuntu) "Please merge 1.9.6-2 (main) from Debian Unstable (main)" [Wishlist,Fix released]
<teward> Bluefoxicy: the PPA has it though
<teward> also managed by yours truly :)
<teward> cjwatson: ?
<Bluefoxicy> that's ... odd.
<Bluefoxicy> does http2 add anything to the execution path if you don't explicitly set listen ssl http2?
<teward> Bluefoxicy: as I said, talk to the sec team
<jrwren> "security team"
<teward> ^ they overrule things :P
<Bluefoxicy> I mean I understand the point; I'm just curious if the code is even executed (thus, capable of bringing security problems) if the user doesn't use it explicitly
 * teward shrugs
<teward> whether I believe it's stable or not, not my call
<Bluefoxicy> (I'm also annoyed nginx doesn't package modules as DSO, but that's a long-standing conversation between nginx developers and entire world)
<teward> Bluefoxicy: for those of us on the tail end of a long day beating an ancient Dovecot into submission to migrate it to a newer dovecot, mind expanding DSO to full words?
<teward> please :)
<Bluefoxicy> teward:  Dynamic Shared Object
<teward> Bluefoxicy: i think they just want the HTTP/2 protocol to have more exposure in the real world :)
<teward> ahhh, yeah, i think dynamic modules are planned
<teward> where'd I see that email...
 * teward digs up the message from rbasak he saw recently...
<Bluefoxicy> there was experimental dynamic loading support 10 years ago :P
<teward> https://lists.ubuntu.com/archives/ubuntu-release/2016-January/003499.html is relevant
<teward> (for the HTTP2 in Xenial thing)
<Bluefoxicy> ah
<cjwatson> teward: never mind
<teward> cjwatson: ok :)
<teward> wheee, ftbfs in sbuild schroots >.>
 * psusi remembers when dynamic loading was the fancy new thing both to the kernel and user space... circa 1997 or so...
<psusi> had a lot of fun playing with the new shared objects and dynamically loading them in eggdrop 1.3.x irc bot
<psusi> can't believe it's 2016 already
<teward> psusi: heheh
<sarnold> pitti: could you please give some feedback on 1503762? It feels to me like Felipe's suggestion for an apparmor systemd service file is just about right but it'd be nice to have your opinion before we get too far ahead of ourselves :) thanks
<Mirv> is it known Ubuntu Installer e-mail notes lag by up to a month? every now and then I still keep getting notices from my December's Qt landing. yesterday I got a notice for this https://launchpad.net/ubuntu/+source/gammaray/2.3.0-3build1 that landed to release pocket 2015-12-10
<Mirv> and I had e-mail about this https://launchpad.net/ubuntu/+source/gcin/2.8.4+dfsg1-1ubuntu1 on 2015-12-28..
<infinity> Mirv: Sounds more like a mail server hitching up somewhere.
<infinity> Mirv: LP just spits the mail out to an MTA managed by IS, after that it's a blackhole to us.
<infinity> Mirv: Oh.  Or no.
<infinity> Mirv: It's s390x catching up, probably.
<infinity> https://launchpad.net/ubuntu/+source/gammaray/2.3.0-3build1/+build/8387977
<infinity> https://launchpad.net/ubuntu/+source/gcin/2.8.4+dfsg1-1ubuntu1/+build/8387979
<infinity> Note those builds happened fairly recently.
<infinity> And when proposed-migration decides they're good to copy, it recopies the source+binaries, since that's easier than figuring out how to just copy a binary. :P
<infinity> That should probably happen silently for those cases, but it doesn't currently.
<infinity> cjwatson: In the step where britney generates the list of archive actions required, does it know at that point (I imagine it does) if a copy is binary-only?
<infinity> cjwatson: If so, it might be nice to flag those as silent, so people don't get a confusing second mail when an arch is catching up.
<infinity> cjwatson: Though, a bit late now that s390x is mostly done. :P
<Mirv> infinity: ah, a logical explanation! thanks!
<pitti> Good morning
<dholbach> good morning
<sladen> Morgen
<Odd_Bloke> I'm seeing a "The following packages have unmet dependencies:\n perl-base : Breaks: perl-modules (< 5.22.1~)\n perl-modules-5.22 : Breaks: perl-modules" error when trying to build a xenial livefs; I saw some discussion yesterday about a Perl migration, but don't know how to work out when I can expect my builds to return to a working state.
<pitti> Odd_Bloke: it actually should work, the perl transition is complete
<Odd_Bloke> Ah, OK.
<Odd_Bloke> Well, it isn't: https://launchpadlibrarian.net/233282042/buildlog_ubuntu_xenial_amd64_cpc_BUILDING.txt.gz ^_^
<pitti> Odd_Bloke: so of course you need the current perl-base with the current perl-modules
<pitti> hm, I built containers this morning
<Odd_Bloke> The "Get"s are perl-modules-5.22 all 5.22.1-3, perl amd64 5.22.1-3, and perl-base amd64 5.22.1-3.
<pitti> the gets look alright to me
<pitti> just not sure why dist-upgrade croaks about the breaks:
<Odd_Bloke> "dpkg: perl-modules: dependency problems, but removing anyway as you requested: perl depends on perl-modules (>= 5.20.2-6)."
<Odd_Bloke> Wait, maybe that's in the host rather than the chroot.
<pitti> perl-modules should be removed, that's right (replaced by p-m-5.22)
<infinity> Odd_Bloke: Fixing.
<Odd_Bloke> infinity: <3
<infinity> pitti: It's because perl-modules is NBS and still present in seeds as a result of still being in the archive, so his attempt to install a task that includes it will explode.
 * infinity removes it.
<pitti> infinity: why on earth do we seed perl-modules?
<infinity> pitti: We don't, but things depend on it.
<infinity> pitti: Which lands it in tasks.
<pitti> ah
<infinity> Oh.  And also explicitly seeded in samba-server.
<infinity> Which is obsolete not.
<infinity> s/not/now/
<infinity> There, fixed even harder.
<infinity> Odd_Bloke: Should be slightly less sad in an hour or so.
<Odd_Bloke> infinity: Great, thanks!  Will I be able to tell that it's good once perl-modules disappears from http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/cloud-image?
<infinity> Odd_Bloke: That would be a reasonable indicator, yeah.
<LocutusOfBorg1> hi folks, stupid question: what does "unapproved" means? (wrt queue)
<LocutusOfBorg1> I'm a recent MOTU, I uploaded an SRU for wily, and a backport for precise,trusty,utopic, wily and all of them ended in unapproved queue
<pitti> LocutusOfBorg1: that's the queue for pockets that require archive admins or the release team to review and approve uploads
<LocutusOfBorg1> oh I found it
<LocutusOfBorg1> https://wiki.ubuntu.com/ArchiveAdministration#Diffs_for_unapproved_uploads
<pitti> LocutusOfBorg1: i. e. all stable releases, and the devel series when it's "frozen"
<LocutusOfBorg1> google was pointing to the queues not to the means
<LocutusOfBorg1> yes sure, thanks
<LocutusOfBorg1> for debian backports needs approval the first time (because they are new), not anymore after that I think
<LocutusOfBorg1> so even after the first backport there is still need to go in the queue, fine :)
<LocutusOfBorg1> thanks
<LocutusOfBorg1> "virtual memory exhausted: Cannot allocate memory"
<LocutusOfBorg1> this happens on arm64, how can I fix it?
<LocutusOfBorg1> maybe I can upload and force -j1
<infinity> LocutusOfBorg1: Which build?
<LocutusOfBorg1> arrayfire/arm64
<LocutusOfBorg1> I tried to give it back twice
<LocutusOfBorg1> no help
<LocutusOfBorg1> I'm going to upload an ubuntu1 without --parallel build
<infinity> LocutusOfBorg1: Sec.
<infinity> LocutusOfBorg1: Please don't.
<LocutusOfBorg1> ack
<LocutusOfBorg1> no problem
<infinity> LocutusOfBorg1: I'm going to retry it on a machine that (probably) sucks less.
<LocutusOfBorg1> thanks :)
<seb128> there seems to be a blueman/bluez issue on xenial, looking at e.u.c ... Noskcaj_ could you check if that's due to your blueman update?
<infinity> LocutusOfBorg1: Okay, if the current build on auburn fails in the same way, feel free to experiment.
<infinity> LocutusOfBorg1: If it doesn't, it probably just means we need to fix our VM configs a bit for the bos* nodes.
<LocutusOfBorg1> infinity, BTW assuming it will build there, it won't migrate because of missing powerpc build, I asked to remove it on Debian, should I file a bug in Ubuntu too?
<LocutusOfBorg1> infinity, I have no problems in disabling parallel builds in Debian, maybe -j4 is too much for arm64?
<LocutusOfBorg1> I don't want to have the same issues on the next debian upload, even if now it is fixed :)
<infinity> LocutusOfBorg1: We select the -j, not you. :P
<infinity> LocutusOfBorg1: And if we're selecting too high, we need to fix our setup.
<LocutusOfBorg1> infinity, exactly I know, but I can disable it at all, or even force it :)
<infinity> (or, rather, if we're memory starving ourselves)
<infinity> LocutusOfBorg1: We'll see how it goes first.
<LocutusOfBorg1> debian defaults arm64 with -j8, right?
<infinity> LocutusOfBorg1: Well, it's -j8 on the builder I just put you on too.
<infinity> LocutusOfBorg1: Generally, people do -j$(nproc)
<infinity> And nproc on a Mustang is 8.
<infinity> One our VMs, it's 4.
<LocutusOfBorg1> ok so it wasn't a real hw
<infinity> LocutusOfBorg1: Also, uhm, please don't remove on an arch for one failing test.  Fix the bug instead?
<infinity> LocutusOfBorg1: It's obviously an endian bug.  Same failure on all big-endian arches.
<seb128> pitti, did you see https://errors.ubuntu.com/problem/03377c894de2d08604cdabf066893d99c348d84f ?
<seb128> "udev.prerm called with unknown argument 'deconfigure' dpkg ( error processing archive /var/cache/apt/archives/ifupdown_0.8.5ubuntu1_amd64.deb (--unpack))"
<pitti> seb128: actually I did, it's debian bug 809744 and debian bug 809743
<ubottu> Debian bug 809744 in udev "/var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'" [Serious,Fixed] http://bugs.debian.org/809744
<ubottu> Debian bug 809743 in ifupdown "/var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'" [Normal,Fixed] http://bugs.debian.org/809743
<seb128> pitti, danke
<seb128> pitti, I'm just looking at the e.u.c xenial top reports and it's in it
<seb128> good to see it's handled
<pitti> seb128: unfortunately a broken prerm can't be retroactively fixed, so we'll work around it in ifupdown
 * seb128 clicks bug opening and add the debian watch
<LocutusOfBorg1> infinity, I agree, but the package is rather complicate, my endianness knowledge is stuck in the "headache" step, it isn't a package I personally maintain / care about
<pitti> I can't reproduce it in my dist-upgrades though, but apparently some people do
<seb128> hum
<seb128> e.u.c "create" fails
<LocutusOfBorg1> but maybe knowing it is a big-little endian issue will make me try to patch
<infinity> LocutusOfBorg1: Given all the BE arches failing on buildd.debian.org, it's pretty clearly that.
<LocutusOfBorg1> infinity, I'm not too much a porter guy to remember just by looking at architectures list which are big and which are little :) sorry
<infinity> LocutusOfBorg1: Anyhow, it's also a leaf package, so I won't whine too hard about removing the PPC binaries.  Tomorrow, after we've figured our arm64.
<infinity> LocutusOfBorg1: Bug fixing the endian bug would be lovely too. :P
<LocutusOfBorg1> I'm already trying that :)
<LocutusOfBorg1> you gave me the best hint I could get
<LocutusOfBorg1> unfortunately upstream doesn't care too much about the porting, so maintaining the code aligned for other archs might be difficult for the Debian Maintainer
<LocutusOfBorg1> and I don't think science packages are used too much on arm* or powerpc
<pitti> seb128: I'll merge it ASAP
<seb128> pitti, danke
<pitti> seb128: it's bug 1531685
<ubottu> bug 1531685 in ifupdown (Ubuntu) "package ifupdown 0.8.5ubuntu1 failed to install/upgrade: Unterprozess installiertes pre-removal-Skript gab den Fehlerwert 1 zurÃ¼ck" [Undecided,New] https://launchpad.net/bugs/1531685
<seb128> k
<infinity> LocutusOfBorg1: I suppose that depends on how sciency they are.
<infinity> LocutusOfBorg1: Some very large machines run ppc64 and sparc64 and then, well, there's s390x.
<LocutusOfBorg1> infinity, the build seems to have passed the problematic build step
<infinity> LocutusOfBorg1: Yeahp, when it completes successfully, I'll remove the powerpc binaries for you.
<infinity> LocutusOfBorg1: And if someone wants to fix the BE bug later, yay.
<LocutusOfBorg1> infinity, upstream fixed i386 in this upload, so I'm going to point them to the "BE issue" thanks
<Odd_Bloke> infinity: No sign of an update to the germinate output yet (I was even a good boy and waited 90 minutes to nag you ^_^).
<infinity> Odd_Bloke: Give the build a whirl anyway, that germinate output on people isn't updated often.
<Odd_Bloke> Whirling now.
<infinity> LocutusOfBorg1: Okay, arm64 uploading, PPC binaries scheduled for deletion.
<Odd_Bloke> infinity: Aha, the new builds look like they're succeeding; thanks!
<infinity> Odd_Bloke: You might want to diff manifests between yesterday and today to make sure the seed/perl changes didn't do something nasty, but it should be fine.
<LocutusOfBorg1> infinity, upstream is now aware of the BE issue :)
<LocutusOfBorg1> BTW I don't think it will migrate because of an armhf regression
<LocutusOfBorg1> but I'll see
<infinity> LocutusOfBorg1: Given the stellar history on http://autopkgtest.ubuntu.com/packages/a/arrayfire/xenial/armhf/ it seems like a fluke that it ever passed.
<infinity> LocutusOfBorg1: But I'll retry it.
<rbasak> mvo_: around? do you know if there is any way I can get apt to keep around the file after a Hash Sum mismatch? Got some odd behaviour behind a (mandatory) proxy with a mismatch on some debs. Which, AFAICT, are being served accurately and match the Packages file, so I need to dig deeper somehow.
<rbasak> Confusingly my failure happens reproducibly with sbuild (a handful of mismatches on debs, but not all) but then if I don't purge the session then I can install using apt-get manually without a problem.
<rbasak> Whatever sbuild does to invoke apt doesn't seem to end up in /var/log/apt/history.log :-/
<cjwatson> infinity: I think it possibly could, but it doesn't pass it through at the moment, and it's a bit buried :-/
<cjwatson> infinity: (arch-specific copies)
<doko> apw, please could you have a look at merging schroot?
<infinity> Odd_Bloke: Bootloader->kernel bits work on the latest powerpc test image.
<infinity> Someother bits seem broken, but progress. :)
<sil2100> Hey! Does anyone know if there are plans of merging the new ppp from Debian to Ubuntu? If yes, is there anyone working on that?
<LocutusOfBorg1> the last uploader was ScottK ^^^
 * ScottK is not.
<LocutusOfBorg1> I'm working on it
<sil2100> LocutusOfBorg1: on ppp?
<sil2100> LocutusOfBorg1: I'm working on some network-manager merges right now and I can only merge the new -pptp if we merge ppp, which is a bit of a bigger story
<LocutusOfBorg1> yes, http://paste.ubuntu.com/14429758/
<LocutusOfBorg1> feel free to test and upload
<LocutusOfBorg1> I can't :)
<sil2100> LocutusOfBorg1: ok, will check, I'm actually building a quick test build of a ppp merge already, but you probably put more attention when prepping this than I did ;)
<sil2100> (since I just did minimal changes)
<sil2100> LocutusOfBorg1: thanks!
<LocutusOfBorg1> yw!
<Odd_Bloke> infinity: http://paste.ubuntu.com/14429904/ is the package diff between pre- and post-seed change; that looks like a lot of removed Perl packages to me, but I don't know if that's what is expected.
<Odd_Bloke> (For all I know, the whole point of the migration was to not pull in all of these unnecessary packages :p)
<cjwatson> That's a familiar-looking set of removals.
<cjwatson> I haven't tracked down why, but wouldn't get too sad about it.
<cjwatson> Might be things moving into core or something.
<Odd_Bloke> OK, cool.
<pitti> sarnold: I replied to the bug, and subscribed (so I'll see responses timely)
<seb128> pitti, did you see that the ifupdown update hit a regression on i386 autopkg
<pitti> seb128: ah, upstart's tests have been flaky for a while; I'll retry, and ignore it if it keeps  failing
<seb128> k
<mvo_> rbasak: sorry for the delay, the files should be in /var/cache/apt/archives/partial, if you have more info please let me know I can also try to reproduce. this sounds worth digging into
<rbasak> xnox: I'm working with kickinz1 on a freeipmi merge. We're looking at 1.1.5-3ubuntu3 that you uploaded with "Fix dso linking on the convenience library." Your patch was http://paste.ubuntu.com/14430242/
<rbasak> xnox: was this for an --as-needed type thing or some other FTBFS or something else?
<rbasak> xnox: we're not sure if this is still needed. It doesn't appear needed, but I don't understand why you needed it.
<Odd_Bloke> infinity: cjwatson: I'm seeing a lot of "Unknown symbol mcount (err 0)" in the powerpc boot log, which looks like it's always the last message for a module (where ppc64el has many more for each module/driver, and actually boots).  Any ideas?
<Odd_Bloke> http://paste.ubuntu.com/14430284/ is the full log.
<Odd_Bloke> Googling around, this normally shows up when a DKMS module hasn't been compiled against the current kernel.
<Odd_Bloke> But that seems... unlikely.
<rbasak> mvo_: hmm. They're all truncated at exactly 2986 bytes.
<rbasak> 2896 bytes sorry.
<xnox> rbasak, it's been more than two years for that one... i have no idea =) if not needed, and it builds everywhere drop it, i guess...
<cjwatson> Odd_Bloke: no idea, sorry!
<arges> pitti: for bug 1531768, are you running arm64 instances on top of amd64? (emulated)
<ubottu> bug 1531768 in linux (Ubuntu) "arm64 kernel and multiple CPUs is unusably slow" [Undecided,Confirmed] https://launchpad.net/bugs/1531768
<pitti> arges: no, the host should be proper arm64
<pitti> arges: the bug report isn't that useful yet, it's mostly for collecting data
<arges> pitti: ok, and in a single CPU variation you don't experience all the stalls?
<pitti> arges: so it seems the more CPUs the instance gets, the faster it falls into that trap (whatever it is)
<pitti> arges: I can't even boot an 8-CPU machine half of the time, and with 4 it at least survives a bbit
<arges> pitti: which hardware is it exactly?
<pitti> arges: I haven't tested single-CPU yet (it would be completely useless to me, but it'd be interesting for this bug report indeed) -- still on my list
<pitti> arges: good question, whatever we have in Scalingstack; but I don't know about the hosts there
<arges> ok
<arges> pitti: i'll put the questions in the bug.
<apw> doko, schroot ack, will put it on the list
<rbasak> xnox: OK, thanks. I think it was needed to fix an FTBFS, and we seem to build OK without it now, so we'll drop the patch. For next time, could you try to document the reason for an upload in the changelog, please?
<gpiccoli> nacc: ping
<nacc> gpiccoli: pong
<gpiccoli> Hello nacc, how are you doing?
<gpiccoli> Sorry to bother you, can I pm?
<nacc> gpiccoli: doing well, thanks! and yes, sure
<gpiccoli> nice, ty
<juliank> APT will soon start depending on liblz4, that needs to be promoted from universe to main (mvo_ et al)
<juliank> Unless it is already
<juliank> No it is not
<juliank> I'll do an MIR now
<juliank> Filed as bug #1531923
<ubottu> bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] https://launchpad.net/bugs/1531923
<juliank> Someone needs to figure out who's going to be responsible for it.
<juliank> Feel free to update the bug accordingly
<juliank> The package is tiny though, and has always been synced.
<bdmurray> xnox: How would you expect an updated app-install-data-partner package to change software-center? I don't see anything when I filter by "Canonical Partners".
<xnox> bdmurray, horum.
<hallyn> xnox: hey, you still have some upstart insight, right?
<hallyn> <grin>
<xnox> hallyn, i guess so...
<hallyn> we have this really really weird bug going on involving upstart killing tasks in a container when uevents happen
<hallyn> (i thought it was a fuse related bug, sforshee made the connection to uevents)
<hallyn> (trying to find the bug#, one sec)
<hallyn> bug 1530617
<ubottu> bug 1530617 in lxc (Ubuntu) "FUSE in wily image with upstart installed causes chaos" [High,Confirmed] https://launchpad.net/bugs/1530617
<hallyn> it's quite fascinating
<xnox> bdmurray, well, i guess we simply need to rebuild the package. And if i remember correctly, iff one has partner enabled, and the app-install-data-partner is up to date, and one doesn't have e.g. skype installed, the icon and channel discription should still be visible in the software centre and/or some such.
<xnox> hallyn, i don't think we actually support upstart in 15.10... do we?
<xnox> hallyn, this is crazy =)
<hallyn> wait, we don't?
<xnox> hallyn, not without systemd as pid 1 removed....
<hallyn> it's not the default but i thought we supported it at least though 16.04
<hallyn> ^ without systemd as pid 1 removed - not quite parsing,
<xnox> hallyn, we support it as running as part of the upgrade.
<xnox> not as anything else.
<xnox> hallyn, e.g. if one is running 14.04, one can upgrade to 16.04 and still be running upstart until reboot.
<hallyn> i thought bc of phone users that wasn't an option
<xnox> hallyn, but e.g. 15.10 cannot be doing that.... as the only upgrade path to 15.10 is from 15.04 which is running systemd by default.
<xnox> none the less. container should not be able to see udev events. and there shouldn't be udev running in the container.
<xnox> if that is the case, it's a resource leak no? and e.g. container can affect the host....
<hallyn> that's a huge discussion upstream, and no right now uevents cannot be filtered to not go to containres
<hallyn> it's wise not to run udev in container, but the solution is just to prevent udev in container from writing to sys
<hallyn> mind you containers used to not run udev, not quite sur when that changed.
<hallyn> (for upstart)
<hallyn> still curious what is sending SIGKILL though.
<bdmurray> mvo_: I've updated the app-install-data-partner info for xenial but still don't see anything in software-center. Any ideas?
<mvo_> bdmurray: hm, you updated and installed it and nothing is in there. nothing at all? or nothing from the new set?
<mterry> Laney, hey...  so I'm reminded of some patches I put into accountsservice to enable libpam-pin years ago.  At the time, I thought we might use them for Touch, but we went a different way.  The upstream bug hasn't seen any movement, so they don't seem likely to be integrated upstream.  No one seems to use the module.  It might be good to drop the patch now, before 16.04?
<mterry> Just checking on thoughts / confirmation no one uses it before dropping it
<barry> mterry: LP: #1531033 is fix committed, but it's still in universe and we're depwaiting on it.  do i need to do something to actually get the package in main?
<ubottu> Launchpad bug 1531033 in lazy-object-proxy (Ubuntu) "[MIR] lazy-object-proxy is new dep for main package pylint" [Undecided,Fix committed] https://launchpad.net/bugs/1531033
<mterry> barry, not typically, but you can poke an archive admin to speed things up
<barry> mterry: ack, thx
<TJ-> bdmurray_: re app-install-data-partner - I have no idea what its supposed to point to - I only found it in a roundabout way due to reading the man-page of apturl and investigating the repo path examples it gives
<bdmurray_> TJ-: alright
<sarnold> pitti: thanks so much for your feedback on 1503762! :)
<Laney> mterry: No objections from me, feel free to upload it and make it be removed on upgrade
<mterry> Laney, cool
<hallyn> xnox: hm, so if we're going to say upstart is not supported, should it be dropped from main?  (I'm looking for some authorotative statement about it not being supported;  that woudl qualify)
<rbasak> hallyn: AIUI, upstart is still supported when used for user sessions on the phone, so it must remain in main.
#ubuntu-devel 2016-01-08
<hallyn> rbasak: have you seen jodh around lately? :)
<rbasak> I didn't think we ever "supported" upstart as system init since the switch to systemd, whatever that even means. "Supported" is such a weasel word. It can mean anything.
<rbasak> hallyn: :)
<hallyn> i bet he'd be interested
<hallyn> cause it's a fascintaing bug
<rbasak> In fact upstart is still used for user sessions on the desktop too, isn't it? And the system init on the phone too.
<lamont> how is it that "drop database foo; create database foo;" on current xenial results in a complete restore of the database?
<stgraber> I don't know the answer to that question either way, but you may want to mention what DB you're using :)
<lamont> stgraber: heh.. yeah.  postgresql 9.4
<lamont> renaming the db before droping it doesn't help either
<lamont> stgraber: sadly, I'm just trying to make a fresh start, and postgrs is being overly helpful, apparently
<pitti> Good morning
<sarnold> morning pitti :)
<pitti> hey sarnold, how are you?
<sarnold> pitti: not bad, getting over a cold, a little slower than I'd like, but otherwise alright :) how are you?
<pitti> sarnold: oh, get well soon then! you seem to be in good company :/
<pitti> sarnold: I'm quite fine, fortunately I managed to evade the flu all winter so far :)
<sarnold> pitti: too true, half my family got the cold ..
<sarnold> pitti: nice nice :)
<pitti> didrocks: I just followed up to bug 1524480; the Breaks:/Replaces of plymouth-theme-lubuntu-logo to plymouth is just for moving files, I suppose?
<ubottu> bug 1524480 in lubuntu-artwork (Ubuntu) "package plymouth 0.9.2-3ubuntu2 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/1524480
<pitti> didrocks: do you know, does that only affect lubuntu-logo for some reason, or a gazillion other themes too? I. e. the mutual Breaks:
<pitti> mutual Breaks: forces "deconfigure", i. e. I wonder if we can avoid that somehow
<didrocks> hey pitti! I'm afraid that's pretty much global, indeed
<didrocks> pitti: as most of the themes seems to be copy and paste and they copied a wrong prerm
<didrocks> yeah, the Breaks/Replaces is just about the moving files, to ensure we don't end up for partial upgrade with an non working theme
<pitti> didrocks: oh, so that's not just plymouth's prerm, but *all* prerms of logo packages?
<didrocks> pitti: yeah, plymouth prerm is fine (let me confirm in a minute), it's the ones in the logo packages for sure at least
<didrocks> and most of them are copy/paste :/
<pitti> didrocks: so instead of SRUing all logo packages and plymouth itseslf, it seems easier to me to just drop the Breaks: of the logo packages in xenial?
<didrocks> yeah, that would be slightely incorrect, but there is nothing else anyway that should call deconfigure on those packages
<pitti> didrocks: oh, ok, I misinterpreted the log, it's indeed not plymouth itself
<pitti> didrocks: right, which is how it got unnoticed for so long
<didrocks> we should still fix them in xenial though, so that this doesn't happen in the future
<didrocks> well, years :p
<didrocks> some packages were untouched since 2010/2011â¦
<pitti> didrocks: curiously I had exactly the same case for ifupdown and udev two days ago (mutual Breaks:, missing deconfigure in udev.prerm)
<pitti> didrocks: yes; so my proposal is to fix all the logo packages in xenial with (1) teaching prerm about deconfigure, and (2) dropping the Breaks: to fix upgrades
<didrocks> I don't know why people are doing this *) echo "Call with unknown parameter; exit 1
<pitti> didrocks: I had that too; I think that was in some standard templates
<pitti> but that's a bit overzealous indeed
<didrocks> pitti: as most cases are empty anyway, I would suggest we drop that
<didrocks> yeah
<didrocks> so yeah, we can workaround and avoid the SRU by removing the Breaks
<didrocks> (in plymouth)
<pitti> didrocks: oh, in plymouth, not in the logo packages?
<didrocks> the Breaks in plymouth against logo packages
<pitti> didrocks: you should drop it on the side which has the  Replaces:, not the other one
<didrocks> there is no Replaces
<didrocks> just Breaks
<didrocks> basically, new plymouth needs themes in /usr/share instead of /lib
<pitti> Replaces: lubuntu-plymouth-theme, plymouth (<< 0.8.1-1~)
<pitti> oh, I see, that's much older, not from this transition
<didrocks> yeah
<didrocks> the breaks is just to ensure we don't install new logo without new plymouth
<didrocks> and vice-versa
<pitti> didrocks: that could also become a versioned depends: on the logo (which is simpler)
<pitti> i. e. Depends: plymouth + Breaks: plymouth (<< 0.9.2-3ubuntu1~) == Depends: plymouth (>= 0.9.2-3ubuntu1~)
<pitti> (was looking at plymouth-theme-lubuntu-logo)
<didrocks> but if you upgrade plymouth alone
<didrocks> you are in a "broken" situation
<didrocks> (for some definition of broken, for sure ;))
<pitti> didrocks: yes, that's why I think we should keep the Breaks: on plymouht and drop it from the themes
<didrocks> the breaks in plymouth won't force deconfigure in -logo?
<pitti> didrocks: only a mutual Breaks: forces that
<pitti> didrocks: if it's one-sided, the broken package gets upgraded first
<didrocks> oh didn't know that, was thinking one way was enough if plymouth was going to get configured first
<didrocks> ok
<didrocks> so apt reorders
<didrocks> making sense
<pitti> didrocks: but if both packages break each other, there is no order which would always be consistant, so apt randomly picks one package, deconfigures that, and upgrades both
<didrocks> I can handle it then
<didrocks> indeed
<didrocks> we should maybe at some point scan the archive to see if this broken template is used elsewhere
<pitti> didrocks: I *think*, plymouth breaks: theme (<< version) and theme Depends: plymouth (>= version) should work
<didrocks> yeah, worth a try anyway :)
<didrocks> pitti: ok, I'll prepare this and upload this early next week (don't want to try without doing an upgrade try)
<didrocks> well, first, let me check how many themes are concerned
<pitti> didrocks: right, it should happen 50% of the time on upgrades depending on the order that apt picks
<pitti> didrocks: I put the IRC conversation into the bug for reference
<didrocks> thanks!
<pitti> didrocks: thanks to you!
<didrocks> thanks for looking and finding a way not breaking partial upgrades :)
<didrocks> pitti: I keep the mutual breaks in the ones that are not impacted, anything against it?
<pitti> didrocks: technically not, but aesthetically a versioned depends: is clearer
<pitti> didrocks: but no need to upload just for that, just if you have to touch a package anyway
<didrocks> yeah, some will need to replace harcoded 15.10 to 16.04 anyway
<pitti> didrocks: ah, so not all themes are affected?
<didrocks> no, there is basically 2 templates that were used
<pitti> didrocks: e. g. plymouth-theme-ubuntu-{logo,text}.prerm seem fine
<didrocks> pitti: yeah, the one based on the xubuntu theme are the ones to blame
<didrocks> they all contains something like http://paste.ubuntu.com/14436235/
<pitti> didrocks: ok, so can you handle that? you probably still have the most context in your head
<pitti> didrocks: yeah, let's just drop that completely
<didrocks> pitti: yeah, and I have the list! So, preparing, doing an ugprade testing, and uploading :-)
<didrocks> +1
<pitti> didrocks: merci beaucoup !
<didrocks> pitti: mais de rien :-)
<pitti> didrocks: so, I hope that Breaks: and versioned Depends: don't force deconfigure; if it does, then indeed we can only just drop the Breaks: on one side :/
<pitti> (I'd still drop it on the themes side, though)
<didrocks> yeah, let's see if I can reproduce a wrong order in some vm with that fix (but that's why I only want to upload it on Monday)
<pitti> (schroot should suffice)
<didrocks> yeah, but easier to use a snapshot for multiple runs
<didrocks> (I'm not on btrfs here :p)
<didrocks> well, should mount my schroot on tmpfs, yeah
<didrocks> (had to revert that recently as not enough RAM)
<pitti> didrocks: so, I started a wily schroot, and this reproduces it:
<pitti> apt install plymouth-theme-lubuntu-logo
<pitti> <change sources.list>
<pitti> apt update
<pitti> apt install plymouth-theme-lubuntu-logo
<didrocks> ah, quite easy indeed!
<didrocks> thanks for looking
 * pitti puts that into the bug
<pitti> didrocks: yeah, and takes a second only
<sladen> Morgen!
<dholbach> good morning
 * sladen beat the script!
<dholbach> what? no script :)
<didrocks> pitti: so works, and the good news is that the other themes aren't impacted (no prerm), only the other maintainer scripts have the parameters restrictions
<didrocks> pitti: uploading now :)
<pitti> didrocks: \o/ merci!
<doko> pitti, why does ruby2.3 trigger any autopkg tests at all? it's not yet supported ...
<pitti> doko: well, britney doesn't know what we consider "supported"
<pitti> we can override it if we don't care, but seeing what breaks against it is interesting nevertheless, no?
<doko> well, if somebody addresses these
<seb128> hum
<seb128> since before holidays consoles are in qwerty layout on my xenial
<seb128> unsure when it started but it was not like that in wily or earlier in the cycle
<seb128> didrocks, ^ did you notice that as well?
<seb128> pitti, is that a systemd thing?
<seb128> /etc/default/keyboard is pc105/fr/oss
<seb128> that used to work
<pitti> console-setup presumably?
<seb128> that didn't change since wily
<didrocks> seb128: it's still azerty here
<seb128> :-(
<didrocks> (I didn't update since yesterday morning)
<seb128> I had the issue before holidays
<seb128> so it's not a today update one
<seb128> thanks for testing!
<pitti> seb128: did "systemctl status console-setup.service" run? if you run it manually, does it fix the layout?
<pitti> seb128: I think that's what sets the layout (it calls loadkeys)
<seb128>    Active: inactive (dead)
<pitti> oh: sudo journalctl -u console-setup
<seb128> yes, that fixes it
<pitti> it does run for me
<seb128> dÃ©c. 11 08:43:11 seb-e6410 loadkeys[311]: Chargement de /etc/console-setup/cache
<seb128> -- Reboot --
<seb128> janv. 08 10:29:02 seb-e6410 systemd[1]: Starting Set console keymap...
<pitti> seb128: ah, that's just from right now
<seb128> so no mention between decembre when the issue started and my manual start
<pitti> oh, hang on
<pitti> Dez 09 08:26:53 donald systemd[1]: Started Set console keymap.
<pitti> that's my last entry
<pitti> so indeed it doesn't get run any more
<seb128> want a bug report? against what component?
<pitti> hmm, 228-1ubuntu2 landed on Nov 23 (too early), -2ubuntu1 o Dec 12 (too late)
<pitti> seb128: it's shipped by keyboard-configuration, so against that, but please assign to me
<pitti> I'll find out what's supposed to start it
<seb128> pitti, danke
<seb128> pitti, in fact bug #1531442 seems to be about that issue
<ubottu> bug 1531442 in keyboard-configuration (Ubuntu) "reboot switches to us keyboard layout on console" [Undecided,New] https://launchpad.net/bugs/1531442
<seb128> assigned it to you
<pitti> thanks
<seb128> pitti, "-2ubuntu1 o Dec 12 (too late)"
<seb128> pitti, are you sure?
<seb128> my last valid run is from dec 11
<seb128> so that would pretty much match
<seb128> yours is 09 and you maybe didn't reboot or installed the new systemd before upload to test it?
<pitti> hm, not sure why it wouldn't have started for me on Dec 10  or Dec 11, but maybe I had a pre-upload version installed
<pitti> seb128: I do reboot every day, but local dpkg -i sounds plausible
<pitti> seb128: so indeed that one is the most probable culprit indeed
<seb128> http://launchpadlibrarian.net/227354002/systemd_228-1ubuntu2_228-2ubuntu1.diff.gz doesn't have much though :-/
<pitti> *nod*
<pitti> seb128: anyway, I'll check on wily what's supposed to depend on console-setup.service, apparently that's now missing
<seb128> danke
<pitti> it's a static service (no [Install] section), so it doesn't run by itself
<seb128> I've a feeling it's plymoyth
<seb128> plymouth
<seb128> diiiiddrrooock
<seb128> or not :p
<seb128> +Description: Remove systemd-vconsole-setup.service as it's not shipped in Debian
<seb128> but that's different
<pitti> Requires=console-setup.service
<pitti> it's not
<pitti> seb128: so that's what started it
<pitti> seb128: i. e. systemd-vconsole-setup.service got previously started, which pulled in console-setup
<seb128> http://launchpadlibrarian.net/229422903/plymouth_0.9.0-0ubuntu9_0.9.2-3ubuntu1.diff.gz
<seb128> the diff has
<seb128> ++After=systemd-udev-trigger.service systemd-udevd.service keyboard-setup.service
<pitti> seb128: but still, this sounds like an accident
<seb128> that's to plymouth-start.service
<pitti> IMHO keyboard-configuration should just make sure to run console-setup by itself
<pitti> not to rely on plymouth to do it
<seb128> yeah
<pitti> so, let's just add that enablement symlink to keyboard-configuration
<pitti> seb128: thanks for the research
<seb128> yw!
<xnox> hallyn, we cannot drop it from main... (a) we need it in main for 14.04->16.04 upgrades (b) desktop user session uses upstart, and nobody ported that to systemd yet (c) phone uses upstart, both as pid 1 and in the user session, and nobody has ported that to systemd yet
<Odd_Bloke> infinity: Any ideas about the "Unknown symbol mcount (err 0)" in the powerpc boot log (http://paste.ubuntu.com/14430284/)?
<doko> pitti, ruby2.3 ... it doesn't even test with ruby2.3, it's all run with 2.2 ...
<doko> so, wasting resources
<xnox> rbasak, do we ship cloud-archive on the server iso?
<LocutusOfBorg1> infinity, hi, upstream seems to be working on endianess thanks to you https://github.com/arrayfire/arrayfire/issues/1055
<LocutusOfBorg1> if you could force it to release I'll be so happy
<pitti> doko: ah, because of ruby-defaults
<pitti> doko: ack, I'll force-skiptest ist
<pitti> doko: they haven't started running on armhf yet, so I'll drop them from the queue (and the other arches are already done)
<pitti> smoser: would you be able to merge open-iscsi? I know very little about it, I wouldn't know how to sensibly test it
<rbasak> xnox: AFAIK, no. Stuff on the server iso is seeded entirely separately, although there is overlap of course.
<rbasak> Actually the cloud-archive has nothing to do with seeds either I think.
<rbasak> It's completely independant and online only unless I'm mistaken.
<LocutusOfBorg1> yofel, seems that kdepimlibs is preventing boost-defaults from migrating
<yofel> LocutusOfBorg1: sorry, I won't get to looking into the test failures before tomorow
<yofel> you'll have to temporarily override it if you need boost to migrate
<pitti> yofel, LocutusOfBorg1: you mean kdepimlibs?
<yofel> yes
<pitti> done
<yofel> thanks
<LocutusOfBorg1> thanks
<doko> cjwatson, could you have a look at a proposed merge? http://paste.ubuntu.com/14437303/  I left three FIXME's in the changelog
<pitti> doko: "Install a suspend.d symlink to also call the pm-utils hook on" -> that doesn't actually exist in the debian/rules delta any more, and it's also obsolete
<pitti> so the changelog entry can be dropped
<doko> ta
<pitti> --noscripts --onlyscripts? that sounds contradictory
<doko> yes, that's a change I found there ...
<pitti> doko: hm, does the .deb actually ship an init.d script? current version doesn't
<cjwatson> dunno about the exact details but the original motivation was that udev would run hdparm anyway so the init script wasn't needed
<pitti> so it would be a complete no-op
<cjwatson> see changelog for 6.3-3ubuntu1
<doko> so dropping these too
<cjwatson> just compare file lists and maintscripts before and after, I guess
<pitti> doko: so as long as the .deb doesn't actually ship an init.d script, the whole debian/rules delta can be dropped
<doko> tdaitx, https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1527685 needs some feedback
<ubottu> Launchpad bug 1527685 in freeipmi (Ubuntu) "Please merge freeipmi 1.4.11-1 (main) from Debian unstable (main)" [Wishlist,Incomplete]
<tdaitx> doko, yes, I am working on that one =)
<doko> just looking at ooold merges
<doko> ogra_, ping
<xnox> cjwatson, doko - so briefly packagekit 0.9.5 existed in wily-proposed which made packagekit-qt to build _and_ migrate (cause it has only alternative depends on the new packagekit...) which makes it now impossible to build. I guess obviously we should move to packagekit 1.0.11, but before that becomes a viable option, what should I do?
<xnox> surely packagekit-qt should be downgraded too, no?
<kickinz1> tdaitx, o/
<cjwatson> er, I don't know, sorry.  perhaps.
<tdaitx> kickinz1, o/
<kickinz1> tdaitx, I'm finalizing the merge of freeipmi right now.
<doko> xnox, ask seb128 or the desktop cabal ... something isn't yet updated for the new packagekit ...
<xnox> i mean i could build packagekit 0.9.x in a ppa, build packagekit-qt there for s390x, and copy the lot over to the archive.... to replay how it was built before...
<kickinz1> tdaitx, did we miunderstood the other day?
<cjwatson> doko: click
<kickinz1> tdaitx, (did I misunderstand)
<tdaitx> kickinz1, oh, it seems we did
<doko> cjwatson, only that? but then, this is actively developed. this is more than a year now ...
<xnox> really britney should not migrate things, which have unsatisfiable build-depends...
<cjwatson> doko: you say actively developed
<xnox> it should be part of the excuses, no?
<xnox> doko, snap is active...
<doko> ahh, ok
<cjwatson> doko: but I don't have hardware to test the native-dbus change, and mvo hasn't had time to push it forward; I'd heard that somebody (was it alecu?) was going to pick it up
<doko> xnox, ahh, and apt-daemon
<rbasak> tdaitx, kickinz1: between you both, who is working on the freeipmi merge? Have you decided?
<cjwatson> ah yes, http://irclogs.ubuntu.com/2015/12/09/%23ubuntu-devel.html#t17:52
 * xnox files bug #1532197
<ubottu> bug 1532197 in packagekit-qt (Ubuntu) "unbuildable packagekit-qt" [High,Triaged] https://launchpad.net/bugs/1532197
<doko> rbasak, the good news is: there are more merges left ;-P
<rbasak> doko: yes, and so I'd like to know what I'm reviewing so I don't waste my time! :)
<doko> rbasak, well, I just saw 1527685 ...
<xnox> rbasak, thanks for your answer w.r.t. cloud-archive.
<rbasak> kickinz1, tdaitx, slangasek: can we resolve this exclusively on this channel please, so there's no confusion?
<rbasak> I don't mind who does the merge or who sponsors it.
<rbasak> As long as it gets done.
<rbasak> I just want to know if I'm sponsoring something, and if so exactly what I'm reviewing.
<rbasak> I also don't want to duplicate review/sponsoring effort with slangasek, since that's a waste of effort and confusing, since different reviewers will always have slight differences in what they want.
<kickinz1> Ok, so I think that with tdaitx, we finally agreed that I  will finsh working on this with rbasak for sonsoring this merge.
<doko> rbasak, according to the bug report, the merge is just needing feedback/review
<rbasak> doko: do you mean Steve's debdiff?
<rbasak> I'm not clear on what slangasek wanted to happen after posting that, since presumably he didn't upload it himself for a reason.
<doko> rbasak, yes, that one
<kickinz1> tdaitx, can you confirm?
<tdaitx> rbasak, doko: he probably wanted me to check that and provide an update, I just copied and pasted the feedback message and was working on it, but I failed to see the attachment and was doing the changes myself
<rbasak> OK, I don't mind what happened. It's all clearly just a misunderstanding. Just decide between you who is submitting what and who is sponsoring, and let us all know.
<rbasak> As long as you both say that you agree to do the same thing, that's fine. Just please tell us what that is.
<tdaitx> rbasak, doko: the changes in the proposed debdiff are just fine
<smoser> pitti, i really want to merge that too.
<smoser> (open-iscsi that is).
<doko> tdaitx, well, then subscribe -sponsors, or slangasek can upload himself =)
<pitti> smoser: I looked at the merge, it doesn't seem particularly complicated; but it's a new upstream version, so some actual testing would be good
<rbasak> doko, tdaitx: OK, I'm just going to "sponsor" slangasek's merge without review. Given that he's an uploader and he says it's good, it's good.
<rbasak> And then we'll be done with it.
<tdaitx> rbasak, doko: agreed, go ahead, I will talk to slangasek later on
<rbasak> ack
<rbasak> kickinz1, tdaitx: I need to lose power for a while. I will upload when I'm back online.
<ogra_> doko, kindof pong (i'm on vacation)
<dobey> hmm
<dobey> where is ocamlopt on ppc64el?
<dobey> seems it's not part of ocaml-nox there?
<cjwatson> I think that's something that requires explicit compiler support as opposed to bytecode-type stuff
<cjwatson> So it only exists on some arches
<cjwatson> maybe?
<cjwatson> Package: ocaml-native-compilers
<cjwatson> Architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc sparc
<cjwatson> Yeah, that's it
<cjwatson> It might actually be a packaging bug - I see some ppc64 support in there, so might be worth looking at whether it can be extended if you fancy a weekend project ;-)
<juliank> If someone from the MIR team has time, #1531923 is needed for squashfs-tools 4.3 which is in depwait for who knows how long and the upcoming APT 1.2
<juliank> bug #1531923
<ubottu> bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] https://launchpad.net/bugs/1531923
<doko> juliank, mvo: missing bug subscriber
<juliank> doko: mvo: I'd propose to have that handled by the foundations team, but that's not my choice. (but it's subscribed to both apt and squashfs-tools)
<juliank> Who decides if foundations could take on lz4 bug subscription? slangasek?
<juliank> It's used by two reverse deps (squashfs-tools and soon apt) that are both foundations material
<juliank> bdmurray: ^
<bdmurray> juliank: seems fine to me, I'll subscribe the team
<juliank> bdmurray: thanks
<juliank> doko: ^
<pitti> smoser: o-iscsi> is that something which you'll actually have time for in the next days, or should we perhaps share the load, and you test my merge in a PPA ?
<smoser> pitti, i'd be very happy to have you do the merge ;)
<smoser> have you looked at rbasak's "ubuntu logical delta" theory  ? https://github.com/basak/ubuntu-git-tools
<smoser> i'd love to have a set of logical delta changes that we can look at individually.
<LocutusOfBorg> Laney, I did something wrt lp: #1424769
<ubottu> Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [High,Triaged] https://launchpad.net/bugs/1424769
<LocutusOfBorg> what do you think about?
<LocutusOfBorg> I'm setting up a virtualbox trusty VM to test it right now
<hallyn> jodh: hey!
<hallyn> jodh: i know you've moved on, but i think you'll find this very intersting: bug 1530617
<ubottu> bug 1530617 in lxc (Ubuntu) "FUSE in wily image with upstart installed causes chaos" [High,Confirmed] https://launchpad.net/bugs/1530617
<xnox> jodh, any advise would be appreciated. it seems like udev, inside the container is causing havoc =)
<dobey> cjwatson: ah, hmm.
<Laney> LocutusOfBorg: nice, will look soon, thanks!
<doko> slangasek, mind, if I have a look at the shadow merge?
<slangasek> doko: be my guest
<doko> barry, fyi https://launchpad.net/ubuntu/+source/python-pysam/0.8.4+ds-1  looks like the same thing
<nemo> So... like an idiot, I decided to try vmware-view-client:i386 instead of vmware-view-open-client (x64) and right away ran into the fact that pkcs11 support appeared to be non-existent.  So I tried to go back, and, oh look, vmware-view-open-client had been pulled from trusty sometime between when I installed it and now...
<nemo> Is there any secret repository where I can get this back? â¹
<nemo> 'cause I think I just broke my entire work setup
<cjwatson> you can dig it out from https://launchpad.net/ubuntu/trusty/amd64/vmware-view-open-client
<nemo> oh sweet. thanks
 * nemo backs that up
<nemo> wooooot.  reinstall the .deb from your link, reapply the fixes from https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770  and vmware view works again! â¥
<ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed]
 * nemo documents this process internally
<nemo> cjwatson: thanks. you're awesome
<nemo> well. apart from the fact it appears to be you who removed it ð
<cjwatson> nemo: it was Debian who removed it, I was just robotically following :)
<nemo> I have a feeling the "official" client would work if I was willing to remove all amd64 from all our ubuntu systems and just install i386
<nemo> (and applied the fixes)
<nemo> (or package an opensc:i386)
<tgm4883> Would this be a good place to ask about packaging conf files for mysql-server?
<tgm4883> Previously we've packaged a file that changes the bind-address, but I don't believe that is going to work anymore
<tgm4883> or rather, what would be the proper way for another application to change the bind-address of mysql-server
<sarnold> tgm4883: would debconf(7) help you any?
<tgm4883> sarnold: I don't think so. It's not that I can't make it work. It's that mucking around with other people conf files seems bad
<tgm4883> sarnold: so I'm not sure what the right(tm) way should be
<sarnold> tgm4883: indeed, that is a bit rough, unless of course that's why they want it :)
<sarnold> tgm4883: in which case something like ansible or puppet or chef or whatnot might be a decent way to centralize all those sorts of changes..
<tgm4883> sarnold: if that's the case, that sucks. It defaults to bind-address=127.0.0.1 which makes building anything that depends on mysql-server not really work
<sarnold> tgm4883: but if it's just one config setting, maybe a dpkg-precofigure command to run first might be tolerable
<tgm4883> sarnold: it's a single configuration change. The issue arrises from there being a new conf directory in mysql-server for cnf files
<tgm4883> sometime between 14.10 and and now
<tgm4883> what we used to do is drop a file in /etc/mysql/conf.d/ and as long as it was read last it works fine. However now there is an additional /etc/mysql/mysql.conf.d/ that gets read after our file
<tgm4883> and there is a mysqld.cnf file in there that sets bind-address to localhost
<tgm4883> Now I could easily drop a file in that directory that gets read after the other file and sets bind-address accordingly
<tgm4883> we currently have a debconf question that asks about that for the old directory
<tgm4883> But my question is, what is the blessed way to do this?
<tgm4883> I suppose at this point, it's less of a technical issue and more of a political one
<nacc> I guess it depends in my mind on what you mean by blessed
<nacc> it seems odd to me to repackage anything just for a config file change
<nacc> you should use a configuration management tool, I'd think
<nacc> tgm4883: --^
<nacc> that way, when/if upstream (ubuntu in this case, I suppose) puts out a new version of mysql, you don't need to build your package again; you can just update like normal and the configuration manager handles it
<tgm4883> nacc: wait, you want me to package a configuration management tool to change a setting?
<nacc> tgm4883: no, use a configuration management tool to manage your configuration :)
<nacc> sarnold mentioned several, ansible, puppet, chef
<tgm4883> nacc: I don't need to manage my configuration, I need a way to manage the configuration of users that install this package
<tgm4883> my configuration already works :)
<nacc> tgm4883: so (I assume) you have several systems you have to manage (physical or VM)
<nacc> you want to ensure the mysql installation on those systems follow some standard set of rules?
<tgm4883> nacc: let me back up a step and see if this makes more sense.
<nacc> tgm4883: sure
<tgm4883> I (Mythbuntu) need to package MythTV  (which includes both mythtv-frontend and mythtv-backend packages) for 16.04. These packages can be installed on the same box, or in a distributed setup, but the mythtv-frontend package needs to be able to connect to the mysql-server (mythtv-backend pulls in mysql-server). So if you are in a distributed setup, you need
<tgm4883> mysql to listen on on the private IP address rather than localhost. Previously we've had a debconf question that asks if you are doing a distributed setup and then places a cnf file in /etc/mysql/conf.d/ with the bind-address set to "bind-address=::". However in 16.04 (and probably some other versions after 14.04) there is a second conf directory for cnf
<tgm4883> files at /etc/mysql/mysql.conf.d/ and in this directory exists a file that sets bind-address to "bind-address=127.0.0.1". Since this gets read after the other directory, our setting gets overridden. Now I could easily just drop the file in /etc/mysql/conf.d/ and have it get read after the other file (it seems to be done alphabetically), but I'm not sure if
<tgm4883> this is the "correct" way to do this, and I'd rather not just do it and have the archive admins complain when I push the package to the official repos
<tgm4883> also, I've been shuffled from #ubuntu-server to #ubuntu-app-devel to here
<tgm4883> nacc: sarnold however, yes. If I was just talking about my own network, or my network at work. I would use Puppet (as I do in those cases)
<sarnold> tgm4883: I wonder if the /etc/mysql/mysql.conf.d/ vs /etc/mysql/conf.d/ represents upstream finally adapting something that debian was doing themselves for ages... that's happened with other .d/ directories. If that's the case then probably moving the file you're setting to the new location is the correct answer
<tgm4883> sarnold: is there anything that explains what that directory is? I know there's hier for the top level directories, but this one's probably owned by mysql
<tgm4883> sarnold: it's odd, as there are cnf files in both directories
<sarnold> tgm4883: the changelog entries here give me the impression that it's a deliberate change https://launchpad.net/ubuntu/+source/mysql-5.6/5.6.23-0ubuntu1
<tgm4883> sarnold: so then just moving to that other directory should be fine?
<sarnold> tgm4883: probably :)
<tgm4883> sarnold: hmm, ok. That fixes one problem and introduces another. We can install it to that other directory, but can I do a .install that is release specific (eg. mythtv-database.install.xenial) ?
<tgm4883> is anything like that doable
<sarnold> tgm4883: hmm, I think I'd probably approach it with different source packages for different releases, but there may be better ways
<tgm4883> why though, that seems like extra work for little gain
<sarnold> normally you'd lreesae them every six months or so? :)
<tgm4883> sarnold: we have daily builds that is built from the same packaging
<tgm4883> for supported releases
<sarnold> ahhh
<tgm4883> they push to out PPA, but it uses the same packaging that we use in the repos
<tgm4883> that makes testing a bit easier
<nacc> tgm4883: sorry, didn't realize you were referring to mythbuntu's packaging ... makes more sense now
<tgm4883> nacc: no worries, I didn't want to hit anyone with that wall of text that didn't ask for it ;)
<nacc> so yeah, you'd need to put the config file in the right place depending on the release, then?
<tgm4883> yea that's the new problem :)
 * nacc naively assumes mysql itself knows where config files should live  ... is there some sort of hook you can call that says your package needs mysql to be reconfigured?
<tgm4883> Looking at https://github.com/dannf/mysql-5.6/commit/61e2b53ddede9a951f9910a027e68edd2a74903a
<tgm4883> maybe I can just call update-alternatives and pass it some parameters
<tgm4883> I wonder if there is a $MYSQL_CONF_DIR or similiar
<tgm4883> I don't see one
<tgm4883> and nothing in debconf either
 * tgm4883 blames Daviey
<Daviey> tgm4883: entirely my fault.
<tgm4883> Daviey: glad you are taking the blame. I'm assigning this bug to you
<Daviey> tgm4883: which bug?
<tgm4883> Daviey: the one I'm about to file for getting mythbackend working in 16.04
<tgm4883> We've got it worked out to a packaging issue that we need to figure out how to fix now
<tgm4883> Daviey: basically, we need to change where mythtv.cfg gets installed. But then how do we do that for 16.04 and yet have a different location for 14.04
<tgm4883> I thought we could do something like mythtv-database.install.xenial but I can't find any documentation on that
<Daviey> tgm4883: Hmm..
<Daviey> Why not install it to the same place and add a compatibility symlink?
<tgm4883> so install it in the old location and if the new location exists symlink it there?
<tgm4883> Daviey: That might work. on 16.04 it would be getting read twice, as mysql looks in both directories. As long as the mythtv.cnf file gets read last it should work
<skoe_> Hi, I want to debug an alsa issue (for the first time) on Xenial Xerus. https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS seems to be the wrong way - at least I don't see a DKMS package there. Can somebody give me a pointer?
<dobey> skoe_: i guess #ubuntu-kernel might be a better place to ask
<tsimonq2> dobey: 0.0 that exists? woah thanks :D
<dobey> of course
<skoe_> dobey, thanks, I missed that one
<Saviq> slangasek, 'tis me again... can I ask for a restart of the failed run http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/armhf/, and /me files bug for flaky test
<slangasek> Saviq: looking
<slangasek> Saviq: that's with unity8 as the trigger?
<slangasek> Saviq: (triggered)
<Saviq> slangasek, yes, thank you
#ubuntu-devel 2016-01-09
<barry> doko: ack, thanks.  the evidence mounts against the python change
<ScottK> barry: how's it looking for a quick resolution upstream?
<barry> ScottK: fairly good i think.  i'll do a few more tests locally but unless serhiy objects, i'm just going to back out that change for 3.5.2 then prep a patch for doko
<barry> probably monday
<ScottK> Cool.
<doko> still need something for #809079, but I'm lost how to reproduce this
<ScottK> barry: I think the same thing was committed for 3.4 and 2.7 too (just not released yet).  Those'll need fixing too.
<doko> we don't care about 3.4 anymore
<ScottK> Upstream does.
<barry> ScottK: right.  and i want to back it out of the 3.6 branch too
<psusi> is the sponsor queue really behind?  bug #1250109 has been waiting for a sponsor to apply the patch for a month now
<ubottu> bug 1250109 in linux (Ubuntu) "Please use dpkg-triggers" [Wishlist,Triaged] https://launchpad.net/bugs/1250109
<psusi> I wonder if it is because it is marked as assigned to apw?
<sarnold> heh just the other day I waited through a few of those update-grubs and wondered how this fix was going :)
<psusi> been waiting for either a sponsor to upload, or me to finally get upgraded to core-devel ;)
<sarnold> hehehe
<psusi> missed the meeting due to new baby and no sponsors yet, so if you care to sponsor: https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
<psusi> ;)
<sarnold> psusi: I suspect whoever would patch-pilot this would want to know better what kinds of testing you've done with it --
<sarnold> congrats :)
<psusi> thanks
<sarnold> psusi: -- so if you could add to it which kinds of dist-upgrades, apt-get purges, dpkg --purge, mixed purge and install, etc. you've done with it, that'd probably ehlp grow confidence in the patch
<psusi> it was a fairly straight forward stealing of the code from update-initramfs, and I tested it by removing a few older kernels and seeing that it only did an update once... then installing one new kernel and seeing that it also runs one update
<doko> xnox, changed maintainer address: https://packages.qa.debian.org/libo/libopenobex.html
<mapreri> can somebody try another run of pbuilder's autopkgtest on s390x ?
<jamespage> doko, hey - just so I don't forget next week - I think I've done all the right bits to get fop demoted to universe, however its not showing up on the component mismatches report
<jamespage> I can't find it in a seed - the only thing still showing is an alternative Recommends on xmlto - would that cause that?
<cjwatson> mapreri: done
<cjwatson> jamespage: no, it wouldn't; the reason it's not showing is that xmlstarlet is scheduled for promotion to main and build-depends on fop
<cjwatson> mapreri: (in theory.  doesn't seem to have done anything - maybe ask again when pitti's around if it doesn't happen eventually)
<mapreri> cjwatson: ok, i'll poke pitti.  "unfortunately" pbuilder has very few deps, so it's not triggered that often...
<dobey> pitti: hey, if you happen to see this anytime, can you please re-run the amd64 autopkgtest for unity-scope-click? thanks.
#ubuntu-devel 2016-01-10
<cjwatson> mapreri: Oh, it did work after all.  http://autopkgtest.ubuntu.com/packages/p/pbuilder/xenial/s390x/
<cjwatson> dobey: done
<mapreri> cjwatson: oh, thank you.  and nice to see it actually passes the test ;)
<LocutusOfBorg> infinity, ping about arrayfire build on arm64 real hw :)
<LocutusOfBorg> as you can see now it builds everywhere thanks to you
<r0x> Do you ever heard about bulk file compilation?
<LocutusOfBorg> hi, somebody please retry arrayfire/arm64 on some real hardware. it is always failing on emulated stac
<LocutusOfBorg> stack
<jamespage> cjwatson, hmm - ok - I see that's tied up in the ivy/maven explosion...
<robert_ancell> popey, do you review click apps?
<popey> robert_ancell, i do
<popey> got one in the queue?
<robert_ancell> popey, I've got the last update of mines marked for manual review. I think it's due to the warning "Could not find compiled binaries for architecture 'multi' lint_architecture_specified_needed"
<popey> yeah, the .mo files?
<popey> there is a workaround
<robert_ancell> popey, yeah, is this a known problem?
<popey> yes, there's a bug for it, dholbach filed
<robert_ancell> I was hoping you'd know :)
<popey> the workaround is set arch to be armhf, i386, amd64 in the manifest
<popey> rather than "all"
<robert_ancell> popey, I have that
<popey> oh
<robert_ancell> It worked for the last few uploads, but not this last one
<robert_ancell> Wondering if the checker changed
<popey> https://bugs.launchpad.net/click-reviewers-tools/+bug/1530894
<ubottu> Launchpad bug 1530894 in Canonical Click Reviewers tools ".mo files don't seem to be allowed in packages of arch 'all'" [Undecided,Fix committed]
<robert_ancell> popey, ta
<robert_ancell> ok, I'll try and re-upload without the arch hack.
<popey> i just get a warning
<popey> when i review the one in the store
<popey> so happy to approve it
<popey> you have arch 'multi'
<popey> not explicitly listing the arches
<robert_ancell> popey, they are listed in the manifest, the resultant click is marked "multi"
<popey> odd
 * popey approves anyway
<popey> done
<robert_ancell> popey, ta
<momken> Hello
<momken> whenever I try to build a deb package from source package I get an error
<momken> e.g. I ran "pbuilder-dist trusty build ../gnome-calculator_3.10.2-0ubuntu2.dsc". The dsc file is build by myself after changing source a little for test purposes
<momken> but it gets this error in downloading some packages:
<dobey> 3.10.3 is already in trusty updates
<momken> Err http://archive.ubuntu.com/ubuntu/ trusty-updates/main libgnutls26 amd64 2.12.23-12ubuntu2.3
<momken>   404  Not Found [IP: 91.189.92.201 80]
<momken> Fetched 6370 kB in 7min 10s (14.8 kB/s)
<momken> E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/g/gnutls26/libgnutls26_2.12.23-12ubuntu2.3_amd64.deb: 404  Not Found [IP: 91.189.92.201 80]
<momken> E: Unable to correct for unavailable packages
<dobey> pbuilder-dist trusty update
<momken> dobey, I know, I am just testing the build process to learn how to build a package
<dobey> your apt cache is outdated in the pbuilder chroot. you need to run the update
<momken> dobey: Oh, interesting. I couldn't guess that myself. Thank you very much
<momken> dobey, Just a question: Are the apt-cache files of my pbuilder located in ~/pbuilder/aptcache/ubuntu/ ?
<dobey> no
#ubuntu-devel 2017-01-02
<tzero> what's the difference between debian/source/include-binaries and debian/source/*.install ?
<tzero> specifically, I get "dpkg-source: error: unwanted binary file: debian/projectname/usr/share/..." about a file included in one of my debian/source/*.install files
<sil2100> fossfreedom: hey! Did you manage to take a look at the build failures from ubuntu-budgie?
<sil2100> I saw the daily builds auto-failing for the whole holiday period
<fossfreedom> sil2100: yeah. scratched my head on this.  Talking to Jeremy Bicha we were speculating that a tasksel had not been created "ubuntu-budgie-live" - so we have added the ubuntu-budgie specifics to the tasksel project.  This got sync'd with main.  Unfortunately this didn't fix the issue :(
<fossfreedom> I couldn't find anyone else though on this channel to help ... deathly quiet ... everyone having a much deserved break!
<cjwatson> tzero: debian/source/*.install isn't a thing.  Perhaps you mean debian/*.install?  debian/source/include-binaries is described in dpkg-source(1), while debian/*.install is described in dh_install(1)
<sil2100> fossfreedom: I can try diving into that tomorrow if no one pops up to look at it before that
<fossfreedom> sil2100: much appreciated.  Cheers
<karstensrage> this seems ridiculous that i have to do this, but to get ubuntu to boot with my custom NSS library, this is what i have to do : http://pastebin.com/HYsJ72rB
#ubuntu-devel 2017-01-03
<tzero> http://askubuntu.com/questions/3446/how-to-create-and-administer-multi-architecture-ppas <- is this still relevant for releasing a PPA package with multiple distribution support?
<cpaelzer> good morning
<rbasak> o/
<rbasak> Happy New Year!
<Unit193> Happy new ears, rbasak!
<rbasak> Unit193: sorry, can you speak up? :-)
<cpaelzer> happy eraly bird year rbasak
<pitti> Good morning, and happy new year!
<cpaelzer> hi pitti, a happy new year to you as well
<pitti> hey cpaelzer, wie gehts? gut reingerutscht?
<cpaelzer> pitti: jepp, alles im Lot - heute is mail/bug prozesstag um zu erfassen was Ã¼berhaupt los ist
<pitti> amen :)
<rbasak> cpaelzer: somehow I managed to catch up already! I guess it's different from vacation at any other time because everyone else was off as well.
<rbasak> squid3 merge next I think. But sleep first.
<Mirv> doko: could bug #1653529 (armhf only, multiple definition of `__bss_start' etc on linking) be a gcc problem? no such problem on Debian on same package when it compiled two weeks ago.
<ubottu> bug 1653529 in qtwebkit-opensource-src (Ubuntu) "qtwebkit 5.7.1 fails to build on armhf" [Undecided,New] https://launchpad.net/bugs/1653529
<Mirv> I see gcc-6 6.3.0 as a recent upload so that leads me to thinking that
<caribou> Is there a rationale behind allowing both Full disk encryption together with /home + swap encryption at the same time ?
<caribou> I mean, shoudn't /home + swap encryption be disabled if full disk encryption was previously selected during installation ?
<rbasak> I don't know of any rationale (before my time), but there are some functional differences. With FDE with ecryptfs, your home directory is locked when you're not logged in, for example.
<rbasak> You'd lose that with FDE only.
<caribou> rbasak: well, LP: #1307003 kinda outline one reason : multiple users on one FDE
<ubottu> Launchpad bug 1307003 in ubiquity (Ubuntu) "Ubiquity installer allows encrypting home folder even if /home is already on an LUKS-encrypted partition" [Undecided,Confirmed] https://launchpad.net/bugs/1307003
<xnox> finished reading bug mail. #2017goals
<Odd_Bloke> * xnox is done for the year.
 * Laney had a suspiciously low amount of bug mail over the hols
<xnox> all my evenings for the rest of the week will be busy with adult lego from ikea, 2 wardrobes.
<ahasenack> hi guys, question. A discarded -proposed upload (i.e., it failed verification), should the new upload be based on it, or is the discarded one really discarded?
<ahasenack> i ask because I made a new upload, ignoring the failed -proposed package, but launchpad is showing me a diff between the discarded failed proposed package and my upload, instead of a diff between what's in -updates and my upload
<xnox> ahasenack, usually one should superseed and use -vLAST_UPDATES_OR_RELEASE_VERSION to include the full changelog, including failed attempts.
<xnox> that's what i do.
<ahasenack> xnox: what's that -v option? Who gets it?
<ahasenack> xnox: also, in the general case, how would I know there was a failed -proposed package? I usually just go to packages.ubuntu.com, check what's in <distro>-updates and base on that. Or use pull-lp-sources
<xnox> debuild -S -sa -v1.0-1
<xnox> when building 1.0-1ubuntu0.2 (a fix up for the failed 1.0-1ubuntu0.1 sru)
<xnox> such that all changelog entries are included in the .changes file /since/ 1.0-1 (last good one/shipped)
<cpaelzer> has anybody a hint what on this proposed migration is still blocking https://launchpad.net/ubuntu/+source/dpdk/16.07.2-0ubuntu0.16.10.1 (belongs to bug 1647945)
<ubottu> bug 1647945 in dpdk (Ubuntu Yakkety) "[SRU] microrelease exception for src:dpdk (16.07.2)" [High,Fix committed] https://launchpad.net/bugs/1647945
<seb128> cpaelzer, best to check with the SRU team but it's likely that it's just that the SRU team has been in holidays and not copying updates, should be back to business this week
<cpaelzer> seb128: people in holidays is the best case that could happen for the package and the people - thanks
<seb128> cpaelzer, yw!
<seb128> cpaelzer, though http://people.canonical.com/~ubuntu-archive/pending-sru.html has an autopkg regression for openvswitch listed so that might turn out to be an issue once people are back...
<cpaelzer> seb128: thanks for pointing that out - that very likely is a transient issue not related as the dpdk test succeeds
<seb128> right
<cpaelzer> seb128: but it is good to be aware
<cpaelzer> jamespage: please let me know if you think that is somethinh on the dpdk end of things^^
<FourDollars> How to see the debug messages of indicator-power?
<seb128> FourDollars, what version of Ubuntu?
<FourDollars> seb128: Ubuntu 16.04
<seb128> FourDollars, the log should be in the upstart job log, in .cache/upstart/indicator-power.log
<seb128> FourDollars, you can also stop the service using "stop indicator-power" and start it by hand
<FourDollars> seb128: I saw it. Thx a lot. :D
<seb128> FourDollars, yw!
<kirkland> caribou: I use ecryptfs on top of full encrypted luks/dmcrypt root disk
<kirkland> caribou: rbasak: the difference is that there is one system wide passphrase/key for the full disk encryption, where as ecryptfs has per-user passphrases/keys
<caribou> kirkland: yeah, I do that too; I was just curious as why both encrypted HOME as we set it up & full disk encryption could be used
<caribou> kirkland: the per-user situation is what I was after
<kirkland> caribou: yeah, that's roughly it;  provides a little bit of separation between alice and bob and carol on the same system
<caribou> kirkland: but there is a bug in Trusty which, if you use both, will wipe out the /dev/mapper/cryptswap1
<kirkland> caribou: oh, interesting, that should be fixed, then
<caribou> kirkland: no LP yet but I'm on it
<kirkland> caribou: conflicting management of swap?
<caribou> kirkland: think so
<caribou> kirkland: problem in trusty looks like LP: #953875 that never got completed fixed for Trusty
<ubottu> Launchpad bug 953875 in ubiquity (Ubuntu Trusty) "Encrypted swap no longer mounted at bootup" [High,Triaged] https://launchpad.net/bugs/953875
<caribou> kirkland: even with encrypted $HOME only
<caribou> kirkland: from what I remember from before xmas, it's the offset= handling in /etc/crypttab that is still missing
<jamespage> cjwatson, hello - is there a way to switch to source of a git repo import on launchpad?
<jamespage> I can find it in the UI
<cjwatson> jamespage: I don't quite understand the question.  Can you rephrase?
<henrix> barry: i'm seeing all trusty linux ADT tests failing for armhf.  any idea if there's anything going on?
<jamespage> cjwatson, ok best illustrated with an example
<jamespage> https://code.launchpad.net/~openstack-snappers/snap-glance/+git/snap-glance
<jamespage> import from github.com/openstack-snaps/snap-glance
<henrix> barry: i'm looking here: http://people.canonical.com/~kernel/status/adt-matrix/trusty-linux-meta.html
<jamespage> I want to switch that to github.com/openstack/snap-glance
<jamespage> as the repo has now moved to a new org
<dobey> jamespage: you don't see "(+) Edit import source or review import" on that page under the list of successful imports?
<cjwatson> jamespage: ah, it's probably restricted to ~vcs-imports.  I can change it for you
<cjwatson> jamespage: Is it the same repository, just moved?
<dobey> oh
<jamespage> cjwatson, yup - I have a few others to switch as well - are you ok todo those as well (only about 6 total)
<barry> henrix: i don't know, but looking at the bbswitch log, it seems like it might be a dependency issue?
<cjwatson> jamespage: done that one, and sure, just give me a list
<jamespage> cjwatson, ack
<jamespage> https://code.launchpad.net/~openstack-snappers/snap-keystone/+git/snap-keystone
<jamespage> https://code.launchpad.net/~openstack-snappers/snap-neutron/+git/snap-neutron
<jamespage> https://code.launchpad.net/~openstack-snappers/snap-nova/+git/snap-nova
<jamespage> https://code.launchpad.net/~openstack-snappers/snap-hypervisor/+git/snap-nova-hypervisor
<barry> henrix: but it's not all armhf though, right?
<henrix> barry: iirc, a MISS means the test didn't get executed at all so there shouldn't exist any logs.
<jamespage> cjwatson, ^^ thats all of them
<jamespage> thankyou
<cjwatson> jamespage: all done, though s/snap-hypervisor/snap-nova-hypervisor/ in that last URL
<jamespage> ah yes - my bad
<jamespage> cjwatson, ta
<cjwatson> np
<henrix> barry: i've tried a 'retry' but i still don't see them being run
<barry> henrix: off-hand i'm not sure what's going on.  my stack is a bit deep with post-vaca catch up, but i'll see if i can investigate further in a bit with my meager pitti-fu ;)
<henrix> barry: oh, you were looking at the ppc64el FAIL.  yeah, that's ok and it has always failed.  i was looking at all the MISS for armhf
<henrix> barry: ack, thanks!
<infinity> henrix: "miss" usually doesn't mean the test never ran, it means the versions don't match what Andy's expecting.
<infinity> henrix: So, if adt triggers kernel_1 against dkms_1, and then dkms_2 is uploaded, Andy's matrix demands that kernel_1 be tested against dkms_2 to be considered good, and logs it as a "miss".
<infinity> henrix: Smacking the retry is all that's needed, but beware queue depths, etc.  You're not going to see instant results.
<infinity> barry: ^
<infinity> barry: The kernel team's matrix is another level of "whee" on top of the britney stuff.
<infinity> henrix: Although, for stable uploads, there shouldn't generally be that many misses, so it's possible either a queue is super long, or got flushed.
<infinity> henrix: Oh, and now I've caught up to reality (and your complaint) that it's only armhf.  Yeah, looks like a queue exploded somewhere.  Hrm.
<henrix> infinity: ah!  thanks for clarifying.  i've retried a few, but none of the trusty armhf seem to have changed anything.  i'll keep an eye on it and see if there are changes.  it's odd that _all_ armhf are MISS
<infinity> henrix: Indeed, armhf might just be buggered right now.  That'll need a deeper dive.
<henrix> infinity: ok, it is possible that this has happen already in the last cycle and i just failed to notice :-/
<infinity> Heh.
<henrix> (last cycle was... well.. hmm.. that)
<infinity> Indeed, looking at the matrix, it doesn't seem to be an uncommon situation of late.
<infinity> Not an ideal one either, but...
<henrix> infinity: there's only the lxc ones that are new, but they are MISS in all archs
<henrix> infinity: note that lts-x has the same issue (i.e. armhf MISS)
<infinity> henrix: Yeah.  Something's definitely goofy.
<infinity> henrix: On the other hand, these aren't useful runtime tests (armhf runs in containers on aarch64 hosts), so the only tests that would be interesting are the dkms compile tests.
<infinity> henrix: Which seem unlikely to break on armhf and no other arch.
<infinity> henrix: So, from the POV of "our testing sucks anyway", you're likely safe to ignore this for this cycle.  We should look into WTF, though.
<infinity> (We should also sort out how to make the armhf tests actually boot armhf VMs...)
<henrix> infinity: agreed.  who shall i keep bothering regarding this?
<infinity> henrix: In theory, barry, me, Laney (and, when he's back, Andy), in practice, we have some catch up to do to be adequate pitti replacements.
<stgraber> infinity, kees, mdeslaur, slangasek: TB meeting in 7
<mdeslaur> ack
<infinity> stgraber: Can't make me.
 * infinity refuses to start 2017.
 * slangasek nods
<Laney> Mmm.
<slangasek> infinity: enjoy your prolonged 2016
<infinity> slangasek: Is that not what 2017 promises to be anyway? :/
<infinity> Well, actually, it promises to be worse.
<ogra_> more artists dieing ?
<dobey> time is an illusion anyway
<dobey> lunch time doubly so
<Laney> infinity: henrix: I rm-ed pending.json for trusty - should cause the 'in progress' requests to be requeued
<Laney> There were some similar lost requests for zesty/armhf too, which I did the same for this morning
<Laney> No guarantee they'll work, but at least they should get queued and run
<henrix> Laney: cool, thanks!  i'll keep an eye and see what happens
<infinity> Laney: Do you have plans to continue development on the autopkgtest infra, or is in maintenance mode for now?
<infinity> Though, I guess my armhf-on-VMs thing will really come down to teaching scalingstack how to do that, not really an autopkgtest thing.
<Laney> infinity: I want to find time to work on it
<infinity> Laney: I want to find a lot of extra time too.  I also know how well that doesn't usually work. :)
<Laney> infinity: I'll do me best
<Laney> Still trying to puzzle out how all of it hangs together too
<Laney> I've got basically NFC about the kernel bit
<infinity> Laney: The kernel bit is a disgusting hack directly in britney.
<infinity> Laney: One that should be removed Very Soon.  I'll have a chat with Andy about it when he gets back.
<Laney> I'm sort of aware how they get queued
<Laney> but not of any big picture there
<infinity> Laney: It should become largely unnecessary with the new Testsuite-Triggers stuff.  Maybe.  If we do it right.
<infinity> Laney: Well, how they get queued it the only picture that matters to you.  The rest is handled outside our infra, by the kernel team.
<infinity> s/it the/is the/
<infinity> But the disgusting hack we use to queue it all should be replaced.
<Laney> I'd quite like to understand the usecase
<Laney> But not urgent
<infinity> I'm pretty intimately familiar with how things happen on the britney side (and the kernel team's stuff too), it's everything on the other side of the MQ that's a black box to me.
<infinity> And I feel like it shouldn't be.
<infinity> Request goes in, [stuff!], results!
<Laney> Cool - add us together and we make 50% of a pi_tti :P
<slangasek> ... and I'll form the head?
<cjwatson> develicons!  pi_tti in disguise!
<pitti> Laney, infinity: kernel> that was a result of looong discussions with apw.. basically, we want to trigger everything off linux-meta so that apt pinning DTRT, and introduce a fake linux â linux-meta dep so that linux doesn't propagate before linux-meta
<pitti> that's basically it
<pitti> plus some extra synthethic deps to trigger things like lxc for new kernels, which should be replaced with Testsuite-Triggers:
<pdeee> rbasak, do you think you'll have time to review RAOF's Certbot SRU packages
<pdeee> ?
<rbasak> pdeee: I will, but please give me a week at least - it was my first day back from vacation today.
<pdeee> rbasak, of course. Happy 2017!
<barry> infinity, Laney we should huddle some time re: autopkgtest infra moving forward.  i am powering up my clone army for this
<tsimonq2> pitti: BTW while you're here, good luck going forward :)
#ubuntu-devel 2017-01-04
<pitti> tsimonq2: thanks!
<pitti> Good morning
<doko> Mirv: can you reproduce this in Debian too? I would however suspect a binutils change ...
<fossfreedom_> sil2100: hi! did you find anytime yesterday to look at the ubuntu budgie LP build issue?  TIA
<sil2100> fossfreedom_: hey! Sadly I got swarmed with post-holiday stuff yesterday, but I'm looking into this nowish
<fossfreedom_> sil2100: no worries - same here.  cheers.
<sil2100> Mirv: hey! Do you know the autopkgtest infra enough to maybe somehow kick the libnih armhf test from http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#dbus ? Since it seems to be 'Test in progress' but not on any queue
<pitti> $ retry-autopkgtest-regressions -s xenial --state RUNNING
<pitti> and see "retry-autopkgtest-regressions --help" how to actually send them
<pitti> sil2100: ^
<Laney> armhf is having a sad time as well
<Laney> I'm trying to sort it out but slow going
<pitti> in lp:ubuntu-archive-tools; this is also on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
<Laney> might or might not just be trusty
<sil2100> pitti: thanks \o/
 * sil2100 bookmarks the wobpage
<pitti> sil2100: but please ask Laney to check the logs first why the requests disappeared; that's not really expected
<Laney> pitti: sil2100: Can't find it immediately, busy trying to understand this "container not running" thing, sorry
<doko> ginggs: fyi, freemat ftbfs with LLVM 3.9 (debian-science)
<ginggs> doko: thanks, will take a look. i checked julia yesterday and it also fails. are you planning to remove 3.8 for zesty? or are you only changing the default to 3.9?
<doko> ginggs: I only wanted it demoted, which is done now
<ginggs> doko: sorry what demoted? i do not understand
<doko> ginggs: llvm-3.8 demoted (main -> universe)
<ginggs> doko: ah, got it now
<Mirv> sil2100: hi
<Mirv> sil2100: yeah but it seems you got answers already :)
<Mirv> sil2100: sorry for the delay, right when you pinged me I started driving my car to yearly service
<Mirv> feels like: -24'C, nice weather
<Mirv> doko: I've been experimenting a bit, and now I got the same problem with forced binutils 20161212: https://launchpadlibrarian.net/301180375/buildlog_ubuntu-zesty-armhf.qtwebkit-opensource-src_5.7.1+dfsg-1build1~1_BUILDING.txt.gz (fake bumped version number). I don't have Debian armhf available for testing. I'm still building a similarly older gcc-6 to test next.
<doko> rbasak: https://bugs.launchpad.net/ubuntu/+source/parallax/+bug/1653959
<ubottu> Launchpad bug 1653959 in parallax (Ubuntu) "[MIR] parallax, dependency of crmsh" [Undecided,Incomplete]
<Mirv> that should be roughly the same binutils that was in use when Debian's package was built (https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-src&arch=armhf&ver=5.7.1%2Bdfsg-1&stamp=1481858819)
<doko> Mirv: thanks for checking
<rbasak> doko: noted, thanks.
<sruli> i want to run a script each time apt finishes installing updates, i tried apt post success hooks but its not working, dpkg post success runs the script after each package is installed and i dont want that, i only want it to run when all is finished, how can i go about this?
<doko> main is now down to one llvm version ... instead of three
<dobey> sruli: alias apt-upgrade="apt upgrade && foo" ?
<sruli> dobey: thanks, didnt think of that, but i need it to work from gui update-manager
<dobey> why? what are you trying to accomplish exactly?
<cjwatson> what exactly did you try for apt post success hooks?  those sound like the right tool for the job
<cjwatson> perhaps you just got the syntax slightly wrong or something; it would help to know a little more than "it's not working"
<sruli> dobey: i am holding back kernel updates for a few weeks after release, wrote a bash script to check date of kernel and install if > x days, i want it to run at the same time of regular updates
<cjwatson> ah, you probably can't do that in an apt hook, I bet it's not re-entrant in the right way
<dobey> after apt already succeeded in installing the updates, seems like way too late to do that
<dobey> seems like you'd want to check that *before* the download/install started
<cjwatson> turn the problem on its head: use APT::Update::Post-Invoke-Success to put all kernel packages on hold except for those that it's acceptable to install
<cjwatson> that will run immediately after 'apt update', thus generally before download/install
<sruli> i am calling an external script, what difference does it make it apt finished installing the updates? my lines in "60aptupdate" APT::Update::Post-Invoke-Success {"path/to/script";}; and APT-get::Update::Post-Invoke-Success {"path/to/script";};
<cjwatson> if you put the ones you don't want to install on hold, then all the rest should happen naturally
<cjwatson> also, APT-get::Update::Post-Invoke-Success isn't a thing
<sruli> i can get by the issue of when it calles it by telling the script to call another one and second one will wait for /va/lib/dpkg/lock to free up.. point is the apt hook is not called when using the gui
<sruli> cjwatson: ther are some other scripts i also need to run after install, question is why is the hook not called when running gui update-manager
<sruli> actually its also not called when running from command line, i just noticed the hook made no difference, i made a wrapper before for apt-get and have a copy of it in /usr/local/bin, when that file is there then apt update from command line triggers it, however the hooks in /etc/apt/apt.conf.d/ are not being triggered
<cjwatson> APT::Update::Post-Invoke-Success definitely should be
<cjwatson> and it is here
<cjwatson> for example if you have update-notifier-common installed, then you should notice that the timestamp of /var/lib/apt/periodic/update-success-stamp is updated every time you do an apt update; that's handled by /etc/apt/apt.conf.d/15update-stamp
<cjwatson> I'd suggest starting by seeing whether that happens from update-manager as well
<cjwatson> if so, then that means it must be a problem with your hook rather than with the hook system in general
<cjwatson> it's been a while, but I *think* that update-manager possibly doesn't generally do an apt update itself, but just relies on the apt cron jobs to do that
<sruli> time stamp does work,
<cjwatson> as far as I know the only way to install a hook that runs after install is to use DPkg::Post-Invoke - that's not "after each package is installed", but rather after each dpkg invocation (which may operate on several packages at once)
<sruli> i tested the dpkg post invoke it ran after every package, will try again, post-invoke-success or just post-invoke?
<cjwatson> APT::Update::Post-Invoke-Success -> after apt update, DPkg::Post-Invoke -> after every dpkg invocation
<cjwatson> you will definitely not be able to use apt-get install from DPkg::Post-Invoke, so don't bother trying things like that
<sruli> i am not trying to call that directly from post invoke, i am trying to call an external script
<cjwatson> sure, just a warning
<cjwatson> in general you just need to write things in a way that will cope with being called multiple times from a single apt upgrade run, though
<cjwatson> which is usually not difficult, just requires a little thought
<sruli> something is wrong with hooks, in 15update-stamp i copied the line to touch another file, it doesnt touch that file
<cjwatson> if this were on my system this would be where I'd break out strace
<sruli> i dont know how to use that.. try adding to your 15update-timestamp "APT::Update::Post-Invoke-Success {"touch /var/lib/apt/periodic/1234 2>/dev/null || true";};
<sruli> its exactly same line but touches different file
<cjwatson> works fine for me
<cjwatson> $ sudo apt update
<cjwatson> $ ls -l /var/lib/apt/periodic/ | head
<cjwatson> total 0
<cjwatson> -rw-r--r-- 1 root root 0 Jan  4 15:26 1234
<sruli> update-manager gui is what i am testing
<cjwatson> like I say I don't think it does an apt update
<cjwatson> but rather relies on apt's cron jobs to do that from time to time
<sruli> but it does update the timestamp on /var/lib/apt/periodic/update-success-time
<cjwatson> ok, I tried update-manager and it apparently did kick off an update, and /var/lib/apt/periodic/1234 was touched
<cjwatson> I've helped you all I can, need to go and do some other things now, sorry
<sruli> how do i do an strace?
<cjwatson> best read its documentation
<sruli> willdo, thanks for your help
<cjwatson> (it will produce a lot of output - you'll want to arrange for that to go to a file, and then you can search for interesting things in that file)
<sruli> cjwatson: didnt run a strace but rebooted and tried again, it did kick it of, i checked with ps before reboot and update-manager was not running! how do i apply changes to apt conf files without reboot?
<cjwatson> you don't need to reboot to apply changes to apt configuration files
<cjwatson> perhaps you didn't check for other apt-related processes in ps
<sruli> well i just tried a million different configs, nothing kicked of the post invoke until a made a reboot!
<sruli> ok, glad that i got that working,
<cjwatson> apt reads its configuration every time it starts.  the only way a reboot could possibly be relevant is if there was some apt-related process running that you missed.
<sruli> possibly
<cjwatson> (and by apt, I mean anything that uses the apt libraries)
<sruli> question is now if there is a way to do a post-invoke for upgrade? else i will need to call a "script &" that script will need to wait for the lock on /var/lib/dpkg/lock to be freed
<cjwatson> there isn't a way to do a post-invoke for upgrade, no
<sruli> also apt update from command line executes the script once, from gui it calls it 3 times, so will have to touch a tmp file when called and first thing in script is if tmp file exists = exit 0
<cjwatson> I'd probably use a cron job or systemd service or similar rather than putting a script in the background, though
<cjwatson> and I'm still confused about why you'd need to call apt from a hypothetical post-upgrade hook; that sounds like a symptom of bad design
<cjwatson> I gave a design for your kernel use case earlier that wouldn't require that
<cjwatson> (and if apt (or dpkg) isn't involved then /var/lib/dpkg/lock shouldn't matter)
<sruli> well few reasons, 1. usually after a month the kernel is no longer in cache so cant install it, (my script downloads kernel as soon as its released but keeps in in different dir) 2. i run some other scripts to change m/c/a times on /boot files, (dont want anyone to be able to see when was last time i booted the machine) i need this script to run every time a update changes a file in /boot
<cjwatson> if I were you I would have your script maintain a local apt repository
<cjwatson> that way it'll still be available in the apt cache and you can use the simpler hold-all-kernels-except-if-approved design above
<cjwatson> and 2. doesn't require /var/lib/dpkg/lock to be released, so you can do that stuff any time
<sruli> 1. i looke dhard and could not find a way to tell apt/dpkg to install a package based on mtime, and i tried but was not successfull in holding a specific kerne, had to put "linux-image-generic" on hold "linux-image-4.4.0-48-generic" did not hold
<sruli> 2. but i need it to change the mtimes after dpkg finishes, if it runs before then dpkg might update some files in boot after...
<cjwatson> 1. like I say, maintain a local apt repository, put everything on hold from APT::Update::Post-Invoke-Success except the ones that you determine are old enough
<cjwatson> 2. DPkg::Post-Invoke should be sufficient for that - apt holds the lock basically to avoid confusion, but DPkg::Post-Invoke itself is reliably run after dpkg finishes
<sruli> how do i determine if its old enough without downloading the file to check the mtime, if i already need to download it, why keep a local repo of many GB's
<sruli> also what is the gain of your way? my script downloads, keeps a dir full of them, if it determines mtime is ripe, it moves it to /var/cache/apt/archives and executes "apt install linux-image-x.x.x-x-generic" so it goes through the normal apt install proccess
<cjwatson> you can either keep a little database of package names/versions to mtimes, or do an HTTP HEAD request to get the mtime; and a local repository doesn't *necessarily* require actually having all the files locally, you could have just the index information locally and do the download when your APT::Update::Post-Invoke-Success hook decides to unhold a kernel package (for example; there are other ...
<cjwatson> ... possible strategies)
<cjwatson> the gain of this is that it's more reliable with respect to apt locking etc.
<cjwatson> you wouldn't have to mess about with trying to work out when apt isn't running, potentially colliding with other things; and it would mean the package would be straightforwardly visible in update-manager, and be applied as part of the normal upgrade run
<cjwatson> anyway you obviously don't have to take my advice, but you asked, so ...
<cjwatson> also if your script is already keeping a directory full of them then I don't see why running a bit of extra code to turn that directory into an apt repository is a problem
<cjwatson> it might actually end up being less code
<cjwatson> (since apt would deal with acquiring stuff straight from that directory)
<sruli> i did not find a way to check mtime with http header, also if i remove the hold like you suggest it will install the lastest kernel, unless i misunderstood part of your instruction
<sruli> regarding taking your advice.. sure i want and thanks for your time, i want to do things the best way possible... but i have to understand properly.. and it has to achive my goal
<cjwatson> the mtime is in the Last-Modified header in an HTTP HEAD request, although if you already have the files locally then using that is certainly easier
<cjwatson> I don't understand why it would install the latest kernel
<sruli> if there is no hold on it and its doing a update it will install latest
<cjwatson> if you have a local apt repository then you'd pin that repository to be preferred over versions in the archive
<cjwatson> that's one good reason to have a local repository, in fact; if properly configured then it makes it harder to commit accidents if using apt by hand
<cjwatson> hm, might be slightly fiddly with multiple versions though
<cjwatson> really out of time to think about this
<cjwatson> might be necessary to maintain the repository out of band with a cron job, so it would basically only "publish" the packages that are old enough in its Packages index file
<sruli> there are multiple other problems, i will need to download it to the repo to check the date, if its in the repo, it will get installed.. for the moment i will have to go with what i have and at a later stage think of resoing it
<sruli> many thanks for your time and advice
<cjwatson> then you don't need anything in APT::Update::Post-Invoke-Success, you'd just have a preferences file that causes all kernel packages from the primary archive to be ignored
<JanC> sruli: why do you want to postpone important security updates?
<sil2100> fossfreedom: I think I see what's wrong, I think I reviewed your livecd-rootfs branch too broadly and we miss some changes there - let me add what's needed and try re-running (once it migrates)
<cjwatson> anyway in general the way I would recommend thinking about this kind of thing is that you're basically trying to maintain a curated channel for updates, and the best way to do that is generally to try to make things look as much like the existing channels (e.g. xenial-updates) as possible
<sruli> JanC: i do not want anyone to be able to see from my /boot partition when i last booted it so have to postpone kernel few weeks, if you know how i can encrypt boot and at sametime have hidden grub with regular boot going straight to windows you will be my hero
<sil2100> fossfreedom: or better said, too narrowly I guess ;)
<cjwatson> sruli: what do you do about /proc/uptime?
<JanC> I'm not sure what booting has to do with installed kernels
<JanC> boot time, I mean
<sruli> cjwatson: you cant get that from boot partition, can you? rest of system is luks, i am not worried about when i am using it, i dont want colleagues to try to check when i am not around
<cjwatson> ok, but you're not likely to make your system more secure by holding back upgrades just so that it's hard for people to tell how recent it is
<sruli> JanC: if a kernel is realeased 2 days ago and its in my boot partition, u know i must have used it in the last 2 days, i want it to be a month since i last used it
<cjwatson> sounds like you want two grub installations, one chaining to the other
<sruli> cjwatson: correct, actually impossible to tell, without the luks key they can play all they want in boot
<cjwatson> (you could also just encrypt /boot if you don't mind having to type in your LUKS passphrase at every boot)
<JanC> that's what I was thinking too...
<sruli> cjwatson: problem with that is i need windows to be able to boot without pass, my work even demands that it always boots striaght into windows so had to hide the grub menu
<sruli> cjwatson: chaningin 2 grubs is one of the ideas that came up on #ubuntu , had a few ideas on how to have encrypted boot with default booting straight into windows, couldnt find any guides.. i guess i will need a week to fugire it out and test it properly.. its on my list
<JanC> basically you want your first stage grub (or other bootloader) to be on something else than /boot
<sruli> with regards to grub password, i was thinking to use keyfile on usb stick, it usb is connected it shows grub and unlocks else boot windows
<sruli> theat the way to go i guess... need some time to figure it out.. unless you can point me to a guide
<cjwatson> don't have a guide, but I'd probably do something based on grub-mkstandalone (or maybe grub-mkrescue)
<sruli> and i will be able to hide the grub menu and default boot windows?
<cjwatson> certainly possible, a matter of crafting an appropriate grub.cfg
<sruli> thanks, will be back when i am ready to try it.. really appreciate the help
<sil2100> fossfreedom: ...actually scratch that, the error seems to be somewhere else, I continue looking
<Mirv> doko: still a problem with forced gcc 6.2.1-5ubuntu1, so maybe it's something Ubuntu specific. https://launchpadlibrarian.net/301204319/buildlog_ubuntu-zesty-armhf.qtwebkit-opensource-src_5.7.1+dfsg-1build1~1_BUILDING.txt.gz
<fossfreedom_> sil2100: this really is a roller-coaster!  cheers for the feedback.
<Mirv> updated bug #1653529 with how the testing was done and a link to Debian log of the same source that succeeded on Dec 16th
<ubottu> bug 1653529 in qtwebkit-opensource-src (Ubuntu) "qtwebkit 5.7.1 fails to build on armhf" [Undecided,Confirmed] https://launchpad.net/bugs/1653529
<sil2100> fossfreedom_: I'm wondering if the problem might be that your budgie seeds are missing the -live metapackage, e.g. ubuntu-budgie-live
<mitya57> Can some SRU team member please look at owncloud-client in Yakkety queue? It's and important fix and waits since 2016-12-19â¦
<sil2100> fossfreedom_: I mean, the seeds do have live configured, but the ubuntu-budgie-meta package doesn't define it (and doesn't link to it in the metapackage-map)
<sil2100> fossfreedom_: sadly live-build is very vague in giving any clues on failures quite frequently, but that would be my first guess here
<fossfreedom_> sil2100: oh! I'm looking here but not sure what needs updating - http://bazaar.launchpad.net/~ubuntubudgie-dev/ubuntu-seeds/ubuntu-budgie.zesty/files
<fossfreedom_> wait - you mean the debian package itself that you run the ./update on to regenerate it?
<mitya57> Does anybody know why is the sponsorship tracker "Last updated at: Wed, 21 Dec 2016 16:40:29 -0000"?
<rbasak> That sounds familiar. IIRC, the pending-sru report was stuck at a similar time.
<rbasak> If it has the same root cause, someone with access to snakefruit can kill things/clear locks.
<rbasak> (assuming the sponsorship tracker updates from snakefruit)
<cjwatson> the sponsorship tracker isn't on snakefruit is it?
<cjwatson> what's the URL?
<Laney> It's on a different host
<rbasak> Oh
<mitya57> The URL is http://reqorts.qa.ubuntu.com/reports/sponsoring/
<cjwatson> yeah, that's cranberry
<cjwatson> bdmurray: ^-
<cjwatson> (IIRC)
<mitya57> It's cranberry, yes.
<Laney> The files are owned by dholbach... hope it wasn't run out of his crontab or anything like that :)
<rbasak> That's be ironic :)
<rbasak> THat'd
<bdmurray> I'll have a look
<bdmurray> mitya57, cjwatson, rbasak, Laney: it looks like it was run by him, I'll move it over to ubuntureports this week.
<mitya57> Thanks!
<Laney> Ta
<fossfreedom> sil2100: hi - I've looked at ubuntu-meta and ubuntu-gnome-meta and they don't have a "live" mapping.
<fossfreedom> I'm a little confused - I can't see other community flavours with a "live" name metapackage
<sruli> cjwatson: you around? i got my script working fine, but change the hook to dpkg it now only works with post-invoke, not with post-invoke-success, what can that be?
<cjwatson> sruli: Because you can't make up configuration key names and expect them to work - you have to use the specific ones that apt cares about.  And, for whatever reason, the key names it has defined in this area happen to be spelled "APT::Update::Post-Invoke-Success" and "DPkg::Post-Invoke".
<cjwatson> (though "APT::Update::Post-Invoke" also exists)
<cjwatson> apt-pkg/deb/dpkgpm.cc:   if (RunScripts("DPkg::Post-Invoke") == false)
<cjwatson> apt-pkg/update.cc:       RunScripts("APT::Update::Post-Invoke-Success");
<cjwatson> apt-pkg/update.cc:      RunScripts("APT::Update::Post-Invoke");
<sruli> i see so there is no post-invoke-success for dpkg, interesting, google is full it..
<cjwatson> The first hit I find for (quoted) "Dpkg::Post-Invoke-Success" is a stackexchange post explaining that it doesn't exist.
<cjwatson> As far as I can tell somebody made it up or typoed it in some other stackexchange post and didn't check whether it really existed.
<cjwatson> I get three hits total for it before Google starts omitting "very similar" results, and all three hits are basically copies of the same post.
<sruli> ok, i see now that stackexchange post, will have to use post-invoke,
<cjwatson> I mean, maybe it would be useful if it did exist, but you'd have to file a bug report against apt asking for it.
<sruli> thanks
<sil2100> fossfreedom: might be unrelated, but I guess I might be onto something - need to poke someone, will continue digging tomorrow
<fossfreedom> sil2100: ok - cheers for all your time today.  much appreciated.
<bdmurray> mitya57: The sponsors page has been updated and cronned
<mitya57> bdmurray, thanks a lot!
<mitya57> bdmurray, maybe you can help me one more time today? I need someone to look at owncloud-client in Yakkety SRU queueâ¦
<bdmurray> mitya57: Can you properly reference the Launchpad bug in the changelog.  Otherwise the pending SRU report won't show an LP bug and the verification process won't go so well.
<mitya57> bdmurray, the previous upload (2.2.2+dfsg-1ubuntu0.1), already in proposed, references that bug properly.
<mitya57> But if you want me to put the proper reference to this upload too, please reject it and I'll reupload.
<bdmurray> mitya57: please do reference the bug again, I've rejected the existing upload
<mitya57> bdmurray, re-uploaded
<mitya57> bdmurray, thanks a lot!
#ubuntu-devel 2017-01-05
<tzero> is there a suggested way to confine the "buildroot" of the package to a subdirectory under debian/ ? Up until now, an `rsync --delete debian/` from the host OS to a ubuntu VM to avoid subsequent `dpkg-buildpackage` runs from complaining about the extraneous files under debian/ from the prior build
<cpaelzer> good morning
<FourDollars> How to stop/start indicator-power in zesty like `stop indicator-power` in xenial?
<pitti> FourDollars: systemctl --user stop indicator-power
<FourDollars> pitti: thx
<cjwatson> tzero: It depends on the upstream build system that's involved, but you should probably look into the "BUILD SYSTEM OPTIONS" section of debhelper(7) for building blocks you can use.  And of course you should make sure that your clean target cleans up after the build, rather than relying on rsync --delete.
<tvoss> xnox: hey there :)
<sil2100> Hey! Does anyone know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-keyboard is blocked in proposed? It the ubuntu-keyboard package the depends are unsatisfiable is provided by the source itself
<Laney> sil2100: component-mismatch
<sil2100> Ah!
<sil2100> Indeed, the ubuntu-keyboard-esperanto is a new binary package from the source
<Laney> Does it want to be in universe?
<sil2100> I think it needs to be in main as all the other ubuntu-keyboard binaries
<doko> barry: who should be the bug subscriber for python-webencodings?
<barry> doko: i'm happy to be that
<barry> doko, mterry i'll look into the tests comment
<doko> barry: but I'm not ;p that has to be a team ...
<barry> doko: well then, foundations of course!
<mterry> barry should be easy
<doko> ok
<bluefoxxxx> sanity check:  I can't find any reference to a bug about Grub giving the error:
<bluefoxxxx> grub-install: error: cannot open `/boot/grub/x86_64-efi/gcry_twofish.mod': No space left on device.
<rbasak> slangasek: squid3> thank you for your reply.
<bluefoxxxx> I've done a lot of googling and can't locate this issue.  This happens in post-install for shim-signed
<bluefoxxxx> the way I work around it is to copy the files manually to the destination, because the device is in no way out of space
<rbasak> slangasek: so if the update-rc.d line moved from squid3.postinst, I think it was a no-op before because it is defined not to work if /etc/init.d/squid3 exists, and that's exactly what squid3.postinst tested for first.
<rbasak> And it's run in set -e, so I'm surprised the postinst didn't fail.
<rbasak> Anyway, I'll sort it out. Thank you for your help :)
<bluefoxxxx> grub-install just thinks it is.
<bluefoxxxx> and ffs launchpad
<bluefoxxxx> okay, you know what?
<bluefoxxxx> I'm just pasting the output here instead of filing a bug in launchpad because whoever designed the "file a bug" ui in launchpad obviously didn't want people going to launchpad to file bugs!
<bluefoxxxx> go to lauchpad.net
<bluefoxxxx> click ubuntu
<bluefoxxxx> click "Report a bug"
<bluefoxxxx> https://help.ubuntu.com/community/ReportingBugs
<bluefoxxxx> i.e. "Fuck off, we don't want you reporting bugs, so we'll give you this wall of text with no obvious way to get into the bug tracker and enter bug details!"
<bluefoxxxx> oh, there it is
<bluefoxxxx> the one-hundredth link somewhere down 2/3 of the way into the page
<bluefoxxxx> after re-reading that page several times over about a dozen visits spanned across months, I found the link that takes me to the ACTUAL BUG REPORTING FORM
<bluefoxxxx> hooray
<bluefoxxxx> now let's see if I can remember what I wanted to file a bug about
<doko> Laney: please could you override the libreoffice autopkg test for python3.5? the junit-subsequentcheck failure seems to be unrelated
<Laney> doko: ok, would appreciate it if you could ping SweetShark / file a bug & assign it though
<doko> Laney: he's not here, and I'm tired chasing people on various channels every time ...
<Laney> I'm tired of skipping tests every time too
<seb128> doko, report a bug on launchpad instead of chasing people then
<sil2100> Can anyone please promote the binary package ubuntu-keyboard-esperanto to main?
<sil2100> Since all the other binaries from ubuntu-keyboard are in main already
<Laney> sil2100: That's backwards
<sil2100> Oh, it is, but why
<sil2100> The ubuntu-keyboard source is in main
<sil2100> Is there any reason why ubuntu-keyboard binaries are still in universe I wonder?
<sruli> i want to install kernel manually, is there a particular order i must install it? i have headers-, image-, image-exra, & signed-image
<sil2100> mterry: hey! I'm wondering if you remember by any chance why ubuntu-keyboard source is in main and the binaries are still in universe
<seb128> sil2100, binaries get only promoted if something in main depends on those
<seb128> otherwise we keep them in universe
<seb128> no point maintaining something in main if we don't need to
<mterry> sil2100: yeah what seb128 said, but I don't remember why nothing depends on its binaries anymore...
<sil2100> mterry, seb128: ok, so I would like to request someone to either promote ubuntu-keyboard binaries to main or downgrade the new ubuntu-keyboard-esperanto binary to universe - whichever is more conveninent :)
<sil2100> Since the new binary is in main but causes a component mismatch as it depends on the ubuntu-keyboard binary which is still in universe
<sil2100> And thanks for the explanation!
<seb128> unsure who NEWed the new binary and why they put it in main
<seb128> check with doko maybe?
<sil2100> Isn't it automatic for new binaries for a main source package to also go to main, or something?
<doko> yes, it is
<sil2100> Anyway, I'm fine with any solution just to get this package migrating
<gpiccoli> Hi, sorry to annoy. Anyone knows what means the message:
<gpiccoli> WARNING **: Configuring 'bootstrap-base' failed
<gpiccoli> on syslog during installation? Where can I get more information on why it failed?
<gpiccoli> Seems to me it might be a failure on grub installation
<Saviq> Laney, after a fresh boot, dbus.log just has http://pastebin.ubuntu.com/23746715/
<Saviq> I suppose it's a chicken-egg issue?
<Laney> Try reverting the upstart job
<sil2100> fossfreedom_: hah! The budgie build seems to have moved forward finally!
<sil2100> fossfreedom_: I see it's still in the middle of building but the livefs builds succeeded \o/
<sil2100> fossfreedom_: so far so good thanks to cjwatson!
<fossfreedom_> sil2100: brilliant news!!  1000 thank-you's to you and cjwatson
<sil2100> For future's sake I'll document it somewhere on our wiki
<slangasek> rbasak: that wasn't a cross-file move, AFAIR?
<Saviq> Laney, confirmed, reverting the job makes it start, what I'm seeing happen is that DBUS_SESSION_BUS_ADDRESS is already set, but it's not running, it's likely some intricacy of how the touch session is set up
<Saviq> maybe the pre-start job should check for validity of the var...
<tzero> thanks cjwatson, I'll check it out
<Laney> Saviq: Wouldn't it be better to stop setting it to a bogus value?
<Laney> I guess this only worked before because the job just clobbered it
<Saviq> Laney, sure, that, too
<Laney> Wonder what's doing that
<fossfreedom_> sil2100: I see the ISO :)  downloaded.  First image here http://imgur.com/Kq545ci
<sil2100> \o/
<barry> mterry: thanks!
<mterry> :)
<doko> seb128, Laney: filed https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1654320
<ubottu> Launchpad bug 1654320 in libreoffice (Ubuntu) "libreoffice junit-subsequentcheck autopkg test failure" [High,New]
<seb128> doko, thanks
<seb128> doko, you might want to indicate in what Ubuntu serie and maybe a log url
<Saviq> well, kindof, commenting that line out didn't really help
<ogra_> Saviq, theer used to be an /etc/profile.d snippet that sets it
<ogra_> (not sure that still exists)
<rbasak> slangasek: it seems like it was to me. I'll reply to the thread.
<Saviq> ogra_, well, yeah, that's what I commented out, wondering now where the value comes from
<ogra_> ah
<ogra_> there also used to be an Xsession.d script ... neither sure if that still exists
<ogra_> (or if that would be even processed in your case)
<rbasak> slangasek: I'm sorry, my mistake. It was all in squid3.postinst.
<rbasak> (I won't email the thread then)
<slangasek> ok :)
<rbasak> slangasek: I think my statement that it couldn't have worked before still applies, but I can raise that with Debian separately. Either way I agree we can drop it now.
<fossfreedom_> open question to anyone - during an ISO build - is there a way to blacklist (i.e. not install) a package that is normally installed because it is a recommended package of another package?
<jbicha> bdmurray: could you help iio-sensor-proxy through phased-updates? the error isn't new, but I guess the error signature changed and I think yakkety's release version didn't work at all, bug 1644246 & bug 1637864
<ubottu> bug 1644246 in iio-sensor-proxy (Ubuntu) "/usr/sbin/iio-sensor-proxy:ERROR:iio-sensor-proxy.c:186:send_dbus_event: assertion failed: (data->connection)" [High,New] https://launchpad.net/bugs/1644246
<ubottu> bug 1637864 in iio-sensor-proxy (Ubuntu Yakkety) "80-iio-sensor-proxy.rules in wrong location" [High,Fix released] https://launchpad.net/bugs/1637864
<nacc> jbicha: weird, i use iio-sensor-proxy on yakkety and rotation works fine
<jbicha> nacc: which version?
<nacc> jbicha: oh nm, i see, i'm running the 'fixed' version. Although i thought it has worked since i upgraded to y.
<jbicha> I like the idea of phased-updates but for things that get stuck, it splits the userbase between those who use only update-manager to install updates and those who don't
<slangasek> barry: NB the revert has to happen in network-manager, not in systemd
<pitti> slangasek, barry: see https://lists.ubuntu.com/archives/ubuntu-devel/2016-December/039564.html
<ogra_> cjwatson, hmm, did sshd startup behaviour change with the switch to systemd ? i remember in the past the sysv/upstart scripts created a host cert if there wasnt one by default on first start of a new image ... bug 1650677 looks like that isnt the case anymore
<ubottu> bug 1650677 in Canonical System Image "Xenial image for frieza does not have SSH configured correctly" [Undecided,New] https://launchpad.net/bugs/1650677
<bdmurray> jbicha: I've restarted the phasing of iio-sensor-proxy
<Saviq> Laney, *something* is writing to $XDG_RUNTIME_DIR/dbus-session, but dbus-daemon is never launched with that socket... (I've hacked the dbus-daemon binary to log into /tmp) http://pastebin.ubuntu.com/23747444/
<Saviq> will now grep through / to try and find what else might be writing to dbus-session...
<Saviq> unless you have an idea?
<Laney> Saviq: I sort of remember ogra_ doing something to save the DBUS_SESSION_BUS_ADDRESS
<Laney> maybe it's that?
<ogra_> Laney, thats the one in /run ... and Saviq said he disabled the profile.d snippet that does this
<Saviq> ogra_, one that *saves* it? no, that I didn't find, I only saw Laney, well, I think
<Laney> oh right
<Saviq> http://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/view/head:/etc/profile.d/dbus-source.sh
<Saviq> which *reads* it, doesn't save?
<ogra_> oh, right ...
<Laney> There was a thing to save it
<ogra_> yeah, one sec
<Saviq> and that's the only mention in /etc/
<ogra_> that used to be in the ubuntu-touch-session script itself, but it is gone
<Saviq> ogra_, dbus.conf, but..
<Saviq> that's what's *not* writing it... and anyway the format would be different
<Saviq> because the upstart job does it with mktemp /tmp/dbus.XXXX...
<Saviq> something's adding the guid= there
<Saviq> http://pastebin.ubuntu.com/23747444/
<Saviq> everything else in /usr only seems to read it, nothing writes it AFAICT
<ogra_> lifghtdm ?
<Saviq> doesn't look like it, nothing related in grepping the code
<ogra_> and you are sure /etc/X11/Xsession.d/75dbus_dbus-launch is not executed ?
<Saviq> dbus-launch? but wouldn't that call dbus-daemon anyway?
<ogra_> (as i mentioned before)
<Saviq> systemd --user??
<Saviq> again, grep not helpful
<Laney> It's written by the upstart job of dbus
<Laney> But that should be the same one it launches dbus with
<Saviq> Laney, well, it's *not* written in this case, since it's prepopulated and the job does "sleep infinity" in that case, so post-start never runs?
<Laney> Oh?
 * Saviq checks again
<Saviq> or maybe it does, because you do exec
<Saviq> so it then does post-start
<Saviq> ok so dbus-session is a red herring
<Saviq> we need to find who's setting the env
<Saviq> correct
<Saviq> Laney, yes it is the upstart job that's writing it
 * Saviq was chasing the wrong thread
<Laney> Saviq: The problem is that it's already set in the environment earlier on, right?
<Saviq> yes
<Laney> so the new job thinks it doesn't need to launch one
<Saviq> got it
<Saviq> it's systemd
<Saviq> it even has a FIXME there...
<Saviq> grr where do I find the code repo for the package :/
<Laney> for systemd?
<Saviq> Laney, ogra_ https://github.com/systemd/systemd/blob/master/src/login/pam_systemd.c#L177
<ogra_> hah
<Laney> that sets it to $XDG_RUNTIME_DIR/bus no?
<Saviq> indeed
<Saviq> lightdm's setting it, but only to a value that's already there...
<Saviq> http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/src/seat.c#L878
<Saviq> ok it's dbus-server's value
<Saviq> https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-server.c#n70
<Saviq> question is now who's setting the env with it
<Laney> look at upstart's /proc/pid/environ to see if it came earlier than upstart, maybe
<Laney> got to run, might be back later
<Saviq> yeah it did
<Saviq> ok it is systemd
<barry> pitti, slangasek yep
<cjwatson> ogra_: none of my sysv/upstart jobs ever created host keys at boot time; I have specifically nacked that multiple times because the time you exactly shouldn't generate host keys is at boot when the system is low on entropy (there is academic research about how that particular idea leads to weak keys in the wild)
<cjwatson> ogra_: anything which you observed doing that in the past was outside of the openssh package, and either without my knowledge or over my objections
<cjwatson> ogra_: it should be done at imaging time or similar instead
 * cjwatson feeds that into the bug
<cjwatson> (https://factorable.net/weakkeys12.conference.pdf)
<ogra_> cjwatson, oh, ok ... yeah, then it was at imaging time or so
<ogra_> cjwatson, thanks for taking the time :)
<cjwatson> always happy to play whack-a-mole with dangerous plans ;-)
<Saviq> Laney, ogra_, ok found the real problem: http://pastebin.ubuntu.com/23747890/
<Saviq> this spawns dbus with --exit-with-session, which in the case of a unity8-touch-session seems to happen right after, so DBUS_SESSION_BUS_ADDRESS is left in the environment, but the dbus it launched dies
<Saviq> commenting out #use-session-dbus in /etc/X11/Xsession.options makes everything work again, but I'm not sure that's what we actually want
<Saviq> jibel, sil2100Â â
 * Saviq filing a bug
<Saviq> Laney, in any case, I think there's a bug in your dbus.conf - if you stop/start it, it won't launch it even if it was the one that launched it in the first place
<Saviq> Laney, ogra_, bug #1654365
<ubottu> bug 1654365 in ubuntu-touch-session (Ubuntu) "Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately" [Undecided,New] https://launchpad.net/bugs/1654365
<Saviq> mterry, do you have enough lightdm/ubuntu-touch-session knowledge to shed more light â?
<Saviq> or do we need Robert?
 * mterry reads
<mterry> Saviq: no I don't know off hand why dbus is dying so quickly
<mterry> I do suspect that the Xsession.d files are deprecatable
<mterry> Upstart or systemd should be triggers for dbus these days I'd think
<Saviq> mterry, sure, we can actually make that happen by just disabling the dbus thing in Xsessions, but that means the rest of those scripts don't get the full env (not sure if it matters much, but still)
<Saviq> just added note of this workaround
<fossfreedom> Please can someone add Ubuntu Budgie to the ISO tracker? TIA http://iso.qa.ubuntu.com/qatracker
#ubuntu-devel 2017-01-06
<nacc> doko: is it possible that glibc update in z-p (which is also a locales update) would lead to the build regression in phpmyadmin? if I build the same phpmyadmin (4.6.5.2-1) against z-release, it passes all the tests.
<nacc> rbasak: if you are around in the morning, would appreciate a chance to sync up on the importer
<rbasak> nacc: sure. You mean your morning, or mine? Yours, I presume?
<nacc> rbasak: i assumed you'd be asleep right now, so yeah, mine :)
<Saviq> jibel, bug #1654365 for the dbus issue
<ubottu> bug 1654365 in ubuntu-touch-session (Ubuntu) "Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately" [Undecided,New] https://launchpad.net/bugs/1654365
<jibel> Saviq, thanks. Although I'm wondering why we're building touch images with proposed enabled
<Saviq> jibel, right, that's another issue - but we'd have hit that regardless when this migrated
<jibel> absolutely
<Saviq> jibel, do you know anything about the orientation sensor? my frieza is stuck in portrait after the dbus fix
<Saviq> unity8 doesn't get any orientation updates
<jibel> Saviq, I know nothing about this sensor. Someone in yc's team maybe
<Saviq> I rather meant "about issues with it" :)
<Saviq> as in, was it broken before, or, like everything else, broke over EOY
<jibel> Saviq, it worked IIRC. I'll reflash an old image to confirm
<jibel> Saviq, rotation works on 102, this bug is another christmas gift
<Saviq> yay
<Saviq> jibel, another issue seems to be that pulseaudio never starts
<Saviq> or at least takes a *long* time to start
<rbasak> doko: could you take a look again at bug 1609043 please? The most recent comment suggests a wider problem than just MySQL.
<ubottu> bug 1609043 in mysql-5.7 (Ubuntu) "mysqld: relocation error: mysqld: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference" [High,Confirmed] https://launchpad.net/bugs/1609043
<rbasak> He's saying there's an ABI break between libstdc++.so.6.0.21 and libstdc++.so.6.0.22
<rbasak> Also http://askubuntu.com/questions/777803/apt-relocation-error-version-glibcxx-3-4-21-not-defined-in-file-libstdc-so-6
<rbasak> It would be that users have that PPA installed though
<fossfreedom_> xnox: since I haven't seen something similar for zesty - any immediate thoughts on this one?  Are we missing a systemd package or something similar to make ubiquity run without root permissions?  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1654368
<ubottu> Launchpad bug 1654368 in ubiquity (Ubuntu) "Ubuntu Budgie - zesty Ubiquity crash when installing locales (daily 05Jan)" [Undecided,Confirmed]
<xnox> fossfreedom_, not too sure. best place to have this discussion on #ubuntu-installer (there is more experteese there)
<fossfreedom_> xnox: cheers!
<ricotz> hello, are there known "sed 4.3-1" related build-failures? maybe related to "sed: character class syntax is [[:space:]], not [:space:]"
<ricotz> chrisccoulson, hi, did you ran into issues with mozilla'4 buildsys and sed 4.3 yet?
<chrisccoulson> ricotz, I haven't, but I'm not running zesty
<ricotz> chrisccoulson, you see the firefox beta builds on zesty failed
<ricotz> and it looks related to the recent sed update yesterday
<chrisccoulson> ricotz, it seems like the build system needs to be updated to use the correct character class syntax. Is there a bug report upstream?
<chrisccoulson> The old sed allowed it, the new one seems to not allow it
<ricotz> chrisccoulson, the syntax of the call in question looks right
<chrisccoulson> ricotz, which call is it?
<ricotz> version=`sed -n 's/^[[:space:]]*#[[:space:]]*define[[:space:]][[:space:]]*U_ICU_VERSION_MAJOR_NUM[[:space:]][[:space:]]*\([0-9][0-9]*\)[[:space:]]*$/\1/p' "$icudir/common/unicode/uvernum.h"`
<ricotz> in build/autoconf/icu.m4
<ricotz> the call works locally standalone, so it might get mangled by autotools/m4
<chrisccoulson> ricotz, it does get mangled. The actual call in ./old-configure is:
<chrisccoulson> version=`sed -n 's/^[:space:]*#[[:space:]]*define[[:space:]][[:space:]]*U_ICU_VERSION_MAJOR_NUM[[:space:]][[:space:]]*\([0-9][0-9]*\)[[:space:]]*$/\1/p' "$icudir/common/unicode/uvernum.h"`
<chrisccoulson> (from my m-c checkout)
<chrisccoulson> ricotz, I'm not sure how much help I can be here. Perhaps there's someone else in the channel who knows more about m4 and autoconf and might be able to help
<ricotz> chrisccoulson, I see, the sed warning/error is not new though
<ricotz> the maybe debian carried some convenience patch
<ricotz> chrisccoulson, I simply pushed this hack now https://paste.debian.net/plain/907006
<xnox> barry, over at #ubuntu-ci-eng people are asking questions about autopkgtest infra performance.
<xnox> and wheather or not some tests are "hung up" e.g. linux taking 7h. is linux tests that long?
<rbasak> doko: I moved bug 1609043 to src:gcc-6.
<ubottu> bug 1609043 in gcc-6 (Ubuntu) "mysqld: relocation error: mysqld: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference" [High,Confirmed] https://launchpad.net/bugs/1609043
<nacc> rbasak: just making some coffee now, still free to chat in a bit?
<rbasak> nacc: sure. How about 1615 UTC?
<rbasak> UTC is easy because I'm in UTC currently. That's 7 minutes from now :-)
<nacc> rbasak: ack
<acheronuk> Mirv: did you try building the QtWebEngine now in debian experimental?
<acheronuk> http://metadata.ftp-master.debian.org/changelogs/main/q/qtwebengine-opensource-src/experimental_changelog
<jbicha> acheronuk: it's in zesty-proposed depwait too
<acheronuk> jbicha: yes, the dfsg-1 is
<acheronuk> jbicha: Mirv tried test building that, and it failed on the issues the version I linked to is supposed to fix
<jbicha> ok, I'll sync that one for you too then
<acheronuk> jbicha: if you don't mind, that would be great
<acheronuk> :)
<fossfreedom> jbicha: are you around?
<jbicha> yes
<fossfreedom> hi - quick question - did you or someone on the ubuntu gnome team have to make changes to ubiquity in the early days to get stuff to work?
<jbicha> we've made chagnes for better integration and occasionally there has been things broken for Ubuntu GNOME too that needed fixed
<jbicha> are you just asking about bug 1579454 ?
<ubottu> bug 1579454 in ubiquity (Ubuntu) "Ubuntu GNOME 16.04 runs ubiquity without root so it fails" [Critical,Triaged] https://launchpad.net/bugs/1579454
<fossfreedom> similar one.  We seem to have to run ubiquity in the live-session with sudo to make it to work.  I've just noticed - if I install "gnome-shell" in the live session then the installer works without needing sudo.  Trying to figure out why.
<fossfreedom> BTW Ubuntu GNOME daily also fails with the direct install like Ubuntu Budgie - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1654630
<ubottu> Launchpad bug 1654630 in ubiquity (Ubuntu) "Ubuntu Budgie and ubuntu GNOME zesty crash when choosing Install" [Undecided,New]
<cjwatson> bin/ubiquity-dm is the main bit that's tended to require highly-desktop-specific hacking
<cjwatson> bin/ubiquity-wrapper to a lesser extent, and it calls pkexec
<cjwatson> note though that ubiquity.desktop already uses sudo
<fossfreedom> hmm - not really understanding all the intricacies on ubiquity-dm but doesnt "seem" to deal with permissions.
<pedahzur> I can't find a way to open a new bug here: https://bugs.launchpad.net/~ubuntu-virt so am reporting here.  Please feel free to refer me to a better forum.  I added the PPA to my 16.04 system per the instructions on the PPA page.  When I run apt-get update, I get this at the end: https://gist.github.com/jkugler/2e11770c28c6b7a6715e8bf4a82bde15  Apparently there is a file missing in the repo.
<cjwatson> that PPA doesn't support anything newer than quantal according to https://launchpad.net/~ubuntu-virt/+archive/ubuntu/ppa/+packages
<cjwatson> oh, no, there's one package for yakkety
<cjwatson> but still, it's not really a bug if PPAs don't support all series
<cjwatson> I think I'd interpret that as "this PPA is mostly stagnant and there's no point trying to use it for anything recent"
<cjwatson> the instructions on the PPA page are mostly generic autogenerated ones, though note that the drop-down on https://launchpad.net/~ubuntu-virt/+archive/ubuntu/ppa (under "Technical details ...") doesn't list xenial
<cjwatson> the virtualisation stuff in the primary Ubuntu archive for xenial should be adequate for most purposes unless you're doing something pretty specialised ...
<nacc> pedahzur: --^ :)
<pedahzur> cjwatson: OK, thank you. In the past, it has had updated packages that fixed bugs, so that's why I added it.  Appreciate the feedback.
<fossfreedom> cjwatson: thanks for your help on the ubiquity issue.  I've managed to tweak ubiquity-dm and this seems to fix the installer for the live session
#ubuntu-devel 2017-01-07
<cjwatson> fossfreedom: approved - let me know when you've done those minor tweaks and I can merge it for you
<nacc> rbasak: dumb q, re: qemu failing to import orig, do you have git-buildpackage installed in that env?
<Mirv> acheronuk: no, and actually there is not much point since it is not needed to land Qt 5.7.1 anyway - once Qt lands, it would automatically get built once dependencies are satisfied
<Mirv> meanwhile, nothing seemingly happened in autopkgtest x86 queues overnight, so it's not really Qt dossing the infra, more like those linux uploads I guess :)
<rbasak> nacc: good question, but yes it is. 0.7.2, on Xenial.
<rbasak> juliank: so I just hit some variation of bug 1522675. But I can reproduce with "apt-get --reinstall flashplugin-installer" and that results in:
<ubottu> bug 1522675 in apt (Ubuntu) "Needless scary warning: Download is performed unsandboxed as root: _apt user not allowed" [Medium,New] https://launchpad.net/bugs/1522675
<rbasak> flashplugin-installer: processing...
<rbasak> flashplugin-installer: downloading http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20161213.1.orig.tar.gz
<rbasak> Err:1 http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20161213.1.orig.tar.gz
<rbasak>   404  Not Found
<rbasak> W: Can't drop privileges for downloading as file '/var/lib/update-notifier/package-data-downloads/partial/adobe-flashplugin_20161213.1.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
<rbasak> E: Failed to fetch http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20161213.1.orig.tar.gz  404  Not Found
<rbasak> E: Download Failed
<rbasak> juliank: AFAICT, that's a real failure, rather than a spurious error, no?
<rbasak> Sorry, I should've pastebinned that. Longer than I thought.
<fossfreedom> cjwatson: much appreciated.  Have revised and tested the ubiquity amendments - https://code.launchpad.net/~fossfreedom/ubiquity/fix_add_ubuntu_budgie_support
<cjwatson> fossfreedom: thanks, uploaded
<tomreyn> hey pitti. a couple months ago, we talked about the need for a utility which is able to precisely state which of your installed packages are supported / unsupported, or which support policy applies to them (if it can be determined) on > 12.04 LTS (since on 12.04 there is a legacy mechanism present for this purpose). back then, i think you said it was high (or not low) on your to do list (if everyday work allowed for it). i'm wondering
<tomreyn> whether you had a chance to work on it since?
<tomreyn> uuh sorry, i think i mixed you up with mdeslaur there
<tomreyn> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670
<ubottu> Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [Undecided,Confirmed]
<tomreyn> since it's marked 'fixed' in yakkety, where "the Supported field [..] is correct", should we expect that 18.04 will again be able to use the 'Ãubuntu-support-status' utility, so that there will again be a way to realiably tell whether your system has only supported packages installed ( which IMHO isn't the case for the current LTS release)?
<mdeslaur> tomreyn: assuming nothing breaks again before 18.04 comes out, yes
<mdeslaur> tomreyn: actually, I believe it's the lts support field logic that is broken, so it needs to get fixed before 18.04 comes out
<mdeslaur> tomreyn: I haven't had time to look into that yet, but will do soon
<tomreyn> thanks, including for responding during the weekend. ;)
<Bluefoxicy> https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1654777 this is intended for Ubuntu+1 so
<ubottu> Launchpad bug 1654777 in zram-config (Ubuntu) "zram-config control by maximum amount of RAM usage" [Undecided,New]
<valbr> is there someone here working for Canonical?
<fossfreedom> quick question all - our seeds for our meta package contains a blacklist file - despite blacklisting a package it still appears to be installed on our ISO.  Its not a dependency - just a recommendation.  Is the blacklist file in seeds ignored?
#ubuntu-devel 2017-01-08
<Bluefoxicy> ok, it looks like xrdp doesn't build x11rdp in the current package.
<Bluefoxicy> There.  I've suggested just getting wayland-rdp built and using that instead of x11rdp.  That should work.
<cjwatson> fossfreedom: blacklist> sort of; it's at least very much less useful than people assume it is
<cjwatson> fossfreedom: you have to think about this in terms of what apt will do, really
<cjwatson> fossfreedom: for purposes of putting images together, germinate ends up basically having to predict the behaviour of apt, and apt is definitely not going to have the slightest idea about seed blacklist files
<cjwatson> fossfreedom: the best that a blacklist can ever do is remove things roughly on the level of directly-seeded entries, not dependencies
<cjwatson> valbr: you'd need to be a lot more specific - there are plenty of Canonical employees here, but that doesn't mean that any engineer is going to be able to be a spokesperson for the company on any given issue ...
<valbr> cjwatson: I understand, I was looking for an internship, but as I understand correctly this is not possible by Canonical. which is sad in my opinion
<valbr> therefore I was looking for an employee to get a better picture of what is possible and what not
<valbr> as the site itself did not give much information about this topic
<cjwatson> OK, I doubt I can help with that; anything I think I know would probably be outdated/wrong and I don't want to mislead you
<cjwatson> isn't there an email contact on the website somewhere?
<cjwatson> (since this is the sort of thing HR would be best-placed to answer, but they don't tend to hang out on #ubuntu* IRC)
<fossfreedom> cjwatson: thanks for the info re the blacklist file. Is there another hook somewhere where we can post install of the meta package remove packages.  The reason for the question - there is a lot of dross in the ISO which we could remove to slim the ISO down
<cjwatson> fossfreedom: you're going to have to refactor this some
<cjwatson> fossfreedom: for example you could turn off recommends for certain seeds (which would need a paired change in livecd-rootfs) and only list the recommends you need
<fossfreedom> cjwatson: interesting.  Are you aware if Ubuntu itself or another community flavour have done this themselves? - probably wiser to reuse where we can.
<valbr> cjwatson: I sended them an email, so I will wait, but I am not sure if it will end up with the right person or not
<valbr> I sended to the PR email and the customer service department we will see
<cjwatson> fossfreedom: It's the sort of thing Lubuntu has done IIRC
<cjwatson> valbr: They can hopefully at least pass it on to somebody appropriate
<Bluefoxicy> good crap I forgot how much of a pain this is.
 * Bluefoxicy alters the weston-1.9.0 package to build a weston-rdp-compositor package, touches up the changelog, and makes a diff.
<Bluefoxicy> >_< and it fails to build!
<Bluefoxicy> omg.  freerdp in debian sid is from like 2014.  Okay.
<Bluefoxicy> ok, need to request a pull of freerdp2 from Debian I think?
<Bluefoxicy> nope, it's already in zesty.  Just need to modify the zesty package and submit a patch
<Bluefoxicy> Does anyone know how I can bring up a greeter in an Xsession and log in as a regular user?
<Bluefoxicy> I have no clue what I'm doing, so I have a patch on top of whatever `apt-get source` produces that `dpkg-buildpackage -b` spits out correct binaries
<Bluefoxicy> okay, I've produced the patch as a debdiff now.  It's smaller for no reason I can ascertain.
#ubuntu-devel 2018-01-01
<elbrus> jbicha: right. And upstream is probably willing to carry it as well.
<elbrus> it should have been upsteamed long ago
<JackFrost> LocutusOfBorg: Hrm, what was the reason to switch remmina away from ayatana indicators?
<ginggs> flexiondotorg: Happy new year! do you think you could add Conflicts: telegram-desktop to your telegram PPA packages please?  It would prevent future bugs like LP: #1740708
<ubottu> Launchpad bug 1740708 in telegram-desktop (Ubuntu) "package telegram-desktop 1.1.23-1 failed to install/upgrade: trying to overwrite '/usr/share/applications/telegramdesktop.desktop', which is also in package telegram 1.1.23-1~artful1.0" [Undecided,Invalid] https://launchpad.net/bugs/1740708
<Bh_> Hi, which kernel version does Ubuntu 18.04 nightly got? does it fix the issue which made 17.10 download link removed from ubuntu.com site?
<acheronuk> Bh_: 4.13.0-17, which according to the bug report was never affected
<Bh_> acheronuk: kewl, I think on installing it instead of 16.04 on my laptop, how stable is it?
<acheronuk> Bh_: no idea. I run Kubuntu. That is is stable, which is all I can comment on
<Bh_> acheronuk: Kubuntu nightly?
<Bh_> or 17.10?
<acheronuk> Both
<Bh_> ok, kewl and thx :)
<acheronuk> Bh_: development version is meant to be reasonable stable nowadays, but I would still only suggest running it if you have some significant experience running (and occasionally fixing) pre-release stuff
<Bh_> acheronuk: I had 16.04 already and I wasn't able to make my second monitor (which is connected with HDMI to the laptop) to work no matter what I did (spent few good hours on it), if I remember correctly it was cause 16.04 didn't really knew how to work with laptops which got a gpu and a video card and it was said that it was fixed later on
<Bh_> so I'm kinda stuck now
<acheronuk> Bh_: fair enough. I'm just doing the mandatory (beware the -dev version may kill your kittens, type) warning ;)
<acheronuk> albeit that most people developing it also run it with good stability.....
<Bh_> acheronuk: hehehe thanks, I'll keep considering it
<Bh_> It's those trailing dots which terrify me..... ;)
<Bh_> acheronuk: btw, doesn't Ubuntu 16.04 will do an update to the buggy kernel? (guess not.... but just to be sure :))
<Bh_> I'm more from the Internet server side systems development side of life :)
<Bh_> minus the server itself though...
<Bh_> acheronuk: btw I rechecked and its said at the bug report "Fix: The issue was fixed in Kernel Version 4.13.0-21. But previous affected machines still suffered from a broken BIOS." so the nightly is stll bugged
<acheronuk> Bh_: no, it's not. as the Bionic -release version never had the buggy driver enabled
<acheronuk> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
<ubottu> Launchpad bug 1734147 in linux (Ubuntu) "Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models" [Critical,Confirmed]
<acheronuk> Bionic is not an affected series
<Bh_> acheronuk: ok so now I'm confused... its not only connected to the kernel version but also to something else?
<Bh_> ahhhh artful & xenial are the series?  (did I mention that this is not my field? :))
<acheronuk> Bh_: correct. I'm not usre if the buggy version was ever uploaded to bionic, but it certainly did not get to the -release pocket and hence the iso's from the info in that bug
<Bh_> acheronuk: honestly I don't totally follow u.... :)
<Bh_> how can u be sure about that?
<dobey> are you on a lenovo laptop?
<Bh_> dobey: HP
<dobey> HP 14-r012la
<dobey> that one?
<Bh_> Nope, but I don't want to be the one will report my model ;)
<Bh_> I got an Insyde BIOS for once...
<acheronuk> Bh_: because the current kernel in bionic is the same as the artful one from before the bug was introduced
<Bh_> also tried to upgrade 16.04 to 17.10 about a month ago, entire installation just crushed and Ubuntu never responded anymore no matter what I did, I got a new HD now and considering what to do
<Bh_> acheronuk: according to https://bugzilla.kernel.org/show_bug.cgi?id=195951 the bug exist from at least kernel 4.11.2
<ubottu> bugzilla.kernel.org bug 195951 in Other "Booting kernel 4.11 triggers a reset of UEFI firmware settings on the next boot" [Normal,New]
<dobey> assuming it's a kernel bug
<Bh_> dobey: thats the bug ticket which is mentioned at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147 . honestly I think I'll just be safe and go for 16.04 for the time being, that's supposed to be a safe option for the time being, right? (the kernel wont get updated to the buggy version and such...)
<ubottu> Launchpad bug 1734147 in linux (Ubuntu) "Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models" [Critical,Confirmed]
<dobey> well, the hwe stack is supposed to get upgraded to the 17.10 kernel in the next few weeks
<dobey> but i don't know how this issue will affect that schedule
<dobey> #ubuntu-kernel is probably a better place to ask about kernel specific issues
<Bh_> dobey: kewl thanks :)
<Bh_> acheronuk: thanks again :)
<Bh_> cheers!
<acheronuk> I *think* the affected kernel only went into the hwe-edge channel so far on 16.04. at least, that was the channel the 16.04 fix was pushed to
<acheronuk> and looks like the bionic kernel in -release is actually affected. concerning
#ubuntu-devel 2018-01-02
<ahasenack> hello
<ahasenack> with whom can I speak about dep8/excuses/autopkgtest test bed setup?
<ahasenack> I have a failure in armhf that, according to my research, only started happening when the test bed moved from lxc to lxd
<ahasenack> the other architectures are not using lxd and are using vms, where the error doesn't happen
<ahasenack> http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#iproute2 armhf "regression"
<ahasenack> in autopkgtest (first line with a red)
<didrocks> ahasenack: hey! this is basically a question for L_aney but he's on holidays until next week AFAIK
<didrocks> IIRC, the wiki only mentions vms (to test on armhf), so can't really help you there
<ahasenack> didrocks: which wiki? Maybe I can get more information there
<didrocks> ahasenack: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure
<ahasenack> didrocks: thanks
<didrocks> yw!
<didrocks> ahasenack: and http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<didrocks> that was the one I was looking for (but using VMs)
<ahasenack> http://autopkgtest.ubuntu.com/packages/autopkgtest/trusty/armhf
<ahasenack> all fails since the switch to lxd
<ahasenack> last green was with lxc
<didrocks> ahasenack: maybe you can try as well with s_tgraber (unsure when he's back)
<rbasak> In their absence, I wonder if it would be acceptable to force-badtest tests that ahasenack locally confirms pass in lxc.
<ahasenack> rbasak: I was just about to ask you to import autopkgtest into git :)
<rbasak> Perhaps a little difficult with armhf though
<ahasenack> mh, yeah, I don't have my arm board here
<didrocks> maybe try the above setup in a qemu vm? ^
<rbasak> ahasenack: OK importing
<ahasenack> I tried arm in qemu once, wasn't sucessful at all
<ahasenack> successful
<didrocks> been a long time I hopefully didn't need to do that as well ;)
<ahasenack> had to work around some things in autopkgtest, but in the end it wouldn't boot
<ahasenack> rbasak: did you pay attention to the authentication request from lplib this time? :)
<ahasenack> (wrt importing autopkgtest)
<rbasak> ahasenack: haven't had one yet. It may still happen at the end!
<ahasenack> it's waiting for then you are not looking
<ahasenack> s/then/when/
<ahasenack> man
 * ahasenack -> snack
<jbicha> doko: would you be interested in doing some python GNOME2 removals like LP: #1739800 and LP: #1731725 ?
<ubottu> Launchpad bug 1739800 in x-tile (Ubuntu) "Please remove gnome-python from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1739800
<ubottu> Launchpad bug 1731725 in pygtksourceview (Ubuntu) "Remove pytgtksourceview from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1731725
<ahasenack> rbasak: how's the autopkgtest import going?
<rbasak> ahasenack: it was stuck on the LP auth :-)
<rbasak> ahasenack: it's now (apparently) pushing.
<ahasenack> hah
<ahasenack> thanks
<rbasak> ahasenack: it was the zombie hang bug. Something should be pushed now, at least.
<ahasenack> rbasak: confirmed, I was able to clone it
<xnox> doko, apw - could you please help me to understand what is the current next step for https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1521174 ? it's an old bug, which got recently resurrected, and it seems like it is being ignored.
<ubottu> Launchpad bug 1521174 in amd64-microcode (Ubuntu) "[MIR] amd64-microcode (multiverse -> restricted)" [High,Triaged]
<xnox> what's next todo for it?
<slangasek> infinity, kees: do we have a TB chair today?
<kees> slangasek: oop! I can, one sec
<NewGnuGuy> What is the process for moving a package from multiverse into universe if it is fully freely licensed? I'm asking specifically about the package redeclipse.
<rbasak> NewGnuGuy: ask an archive admin. I think. If you can't find one here, you can file a bug and subscribe ~ubuntu-archive to it.
<NewGnuGuy> The upstream Debian package is in Debian main which should in and of itself qualify the package for the universe repository.
<cjwatson> It's just that it was in Debian contrib when it was first introduced, which automatically shunted it into multiverse.  As rbasak says, file a bug and subscribe ~ubuntu-archive, should be easy.
<NewGnuGuy> How do I file a bug and what do you mean by "subscribe ~ubuntu-archive"? I've never done this before
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/redeclipse/+filebug?no-redirect
<cjwatson> (you'll need a Launchpad account, if you don't already have one)
<cjwatson> then after you've filed it, you'll see "subscribe someone else" at the right-hand side; click that and enter "ubuntu-archive"
 * rbasak wonders what ?no-redirect does
<dax> stops it from redirecting to the "how to use apport" wikipage, iirc
<rbasak> Hmm. I've never seen that behaviour. Or is that because I'm special somehow?
<wgrant> rbasak: ~ubuntu-bugcontrol is exempt from the redirect.
<rbasak> I see. Thanks.
#ubuntu-devel 2018-01-03
<Laney> cking: hey, happy new year - here's a present for you: can you look into the autopkgtests of stress-ng please? tlb-shootdown is somehow murdering the test runner
<Laney> I think it's killing the parent or something
<Laney> reproduces in the qemu runner fwiw
<cking> Laney, how urgent is it?
<Laney> I can blacklist for now
<Laney> so depends if you want results
<cking> blacklist it for now, I'll look at it sometime next week, thanks for the heads-up on this, it is a torture test that probably is too hard on the test runner for sure
<Laney> I run that stressor over SSH and it kills my SSH connection :-)
<cking> oops, that's a bit harsh of it
<cking> Laney,  OK, I'll add some oom'ing magic to that one to make sure it gets oom'd before anything else. I think that's the issue
<Laney> cking: I don't see any OOM stuff in dmesg from these runs
<Laney> anyway, should reproduce for you I'd imagine
<cking> Laney, how many CPUs and how much memory on the box?
<cking> and which kernel?
<Laney> 1 / 1024 / 4.13.0-17
 * Laney did this: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<cking> ok, that's a good starting point, I'll try and get around to that next week
<Laney> righto
<juliank> apt's happy eyeballs in progress for security.ubuntu.com: https://paste.ubuntu.com/26312732/ - I artificially lowered the connection attempt delay to like 10 seconds to get quite a few attempts
<juliank> It's a host that prefers IPv4, but you also note that the second v4 attempt completed before the first, so that one is picked.
<juliank> This also means that if one of the addresses fails, APT now falls back to another within that delay (250 ms by default), rather than waiting for 2 minutes
<juliank> I'm considering adding a linear back off factor, but currently it's a constant as the RFC specifies for stupid clients
<juliank> It seems a natural back off the RFC 8305 does not specify would be to just always wait clamp(250 ms, time we spent so far, 2000 ms). Opinions welcome :D
<wxl> ypwong: saw the recent changes to The Bugâ¢. does this signal that we'll be respinning and releasing 17.10 again?
<juliank> Huh. I just heard that loading rtsx_pci enables support for 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)
<juliank> how odd
<juliank> -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1741084
<ubottu> Launchpad bug 1741084 in linux (Ubuntu) "rtsx_pci needs to be manually loaded for Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader [10ec:5229]" [Undecided,New]
<letterman> does the default install pam log user passwd history
<nacc> letterman: you're in the wrong channel.
<wxl> oh ho! interesting fact: 4.15rc6 is being suggested to fix broken BIOS due to Intel SPI on bug 1734147 .... and that theoretically includes all of the x86 page table isolation patches https://lwn.net/Articles/742449/
<ubottu> bug 1734147 in linux (Ubuntu) "Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models" [Critical,Confirmed] https://launchpad.net/bugs/1734147
<wxl> so maybe we could kill two bugs with one stone? :)
<dannf> slangasek: looks like some fixes i had queued for d-i/bionic got dropped from the repo before the last upload - was there a problem with those?
<dannf> or maybe i failed to push them...
<slangasek> dannf: sorry, I didn't knowingly drop anything
<dannf> slangasek: ok - probably my fault then :)
<JackFrost> Laney: https://sigma.unit193.net/source/debhelper_11ubuntu0.1~ubuntu16.04.dsc - https://sigma.unit193.net/source/debhelper_11ubuntu0.1~ubuntu17.10.dsc btw.
<JackFrost> Xenial needs dh-autoreconf too, but that's super easy.
<tsimonq2> It seems that all Launchpad builders are currently disabled. See the topic in #launchpad for more details.
* cjwatson changed the topic of #ubuntu-devel to: LP build farm disabled for maintenance; no ETA yet | Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<JackFrost> My bad, dh-autoreconf already *has* a backport.  Not very recent, but should do the trick.
<juliank> Yes, 12 is the minimum for debhelper
<tsimonq2> juliank: We're on to debhelper 12 already? O_O
<JackFrost> I'm aware, I didn't see xenial had it.
<juliank> The other ones are mostly speed ups :D
<juliank> tsimonq2: dh-autoreconf 12
<juliank> :D
<tsimonq2> juliank: hehehehe I was gonna say... :D
<juliank> but debhelper 12 compat level exists in development :D
<JackFrost> juliank: There was a discussion in #debian-derivatives, I may have accidentally volunteered to help backport debhelper.
<juliank> I'm obviously highlighted by dh-autoreconf and happy to do any backports of that :D
<juliank> but none needed so
<JackFrost> I'd say "sorry for the ping", but your fault putting that on highlight. ;)
<juliank> Re backports: I still gotta build an apt snap
<JackFrost> ...Unless you want me to poke you again about xdt-autorun. :>
<juliank> Latest apt everywhere :D
<JackFrost> I'm presuming https://anonscm.debian.org/git/apt/apt.git/commit/?id=8d23827be3043daf7fed1b86da1d41578889eaeb won't get backported?
<juliank> JackFrost: Oh, that should be backported to 1.4.y and 1.2y.
<JackFrost> Ooh nice, won't have to wait for Bionic then.
<juliank> I gotta cleanup 1.5.2 and release that
<juliank> and then I can add that to the 1.4.y and 1.2.y queues
<JackFrost> I still have to wait for Bionic for the new apt-file though, of course.
#ubuntu-devel 2018-01-04
<juliank> Tomorrow we'll see apt 1.6~alpha6 with a new mirror method and very fast ipv6->ipv4 fallback
 * juliank is already running it as 1.6~alpha5ubuntu1 - a weird anomaly :D
<juliank> The new mirror method is amazing
<juliank> it actually works
<juliank> the previous one is broken for unknown reasons
<juliank> at least in bionic
<JackFrost> Hmm?
 * juliank has not checked artful or older
<juliank> It just hangs
<juliank> in my bionic system
<juliank> I think it worked fine in my sid
<JackFrost> Using mirror://?  People actually use them? :3
<juliank> I don't know, but we have a new method for it
<juliank> :D
<juliank> There's also mirror+https now
<juliank> which you probably should be using
<juliank> though, I don't know.
<juliank> All I can say is that it works fine now
<JackFrost> sources.list normally doesn't contain https :3
<juliank> Well the thing with the mirror stuff is that it contains a completely untrusted mirror list
<juliank> Using https gives you some security for that
<juliank> sure, it would be nicer if the mirror list were signed
<juliank> OK, we also do not only fall back fast from IPv6 to IPv4, we fall back fast on any connection problem.
<juliank> :D
<juliank> So we just do multiple attempts concurrently and pick the first winner
<juliank> alternating between the v6 and v4 (or whatever preference your system has), and with 250 ms delay between attempts
<JackFrost> Hrm, I need to figure out how to use .sources properly.
<juliank> I think we also enabled retries by default
<juliank> If something fails to fetch, APT now retries automatically
<juliank> Or no, it might be off by default
<juliank> But that's really useful with some CDNs......
<juliank> JackFrost: Regarding https in sources.list - my debian system is mostly https
<juliank> but then I rewrote the https stuff so I had to use it
<juliank> https just adds modest levels of confidentiality
<juliank> at the risk of having to run all that TLS code
<JackFrost> http://paste.openstack.org/show/637558/ I had to hope that would work, but alas. :P
<juliank> JackFrost: So, you gotta place that as a .sources file in .sources.list.d, it can't be a .list
<JackFrost> I'm aware, and no the format is each URI in a separate block.
<juliank> So you can only have one uri in the uris field?
<juliank> or?
<JackFrost> You don't know? :3  But yes, that's what it seems to be saying in the 'As an example, the sources for your distribution..' section of the manpage, which means 'URIs' is very misleading.
<JackFrost> I'd be fine if it picked one so you could but a group of fallover ones there, but with that sources file apt just hangs.
<mwhudson> can someone mark ubuntu-image/1.3+18.04ubuntu1 as a badtest?
<mwhudson> it's failing because a new flake8 breaks the qa autopkgtest
<JackFrost> LocutusOfBorg: Did you see my question the other day?
<LocutusOfBorg> JackFrost, no
<JackFrost> OK.  I wondered why you dropped remmina back to indicators from using ayatana indicators?
<LocutusOfBorg> because it is not in main
<LocutusOfBorg> feel free to request a MIR
<cpaelzer> Is today some unusual business or shortage on builders?
<cpaelzer> my ppa gets predicted times of 4-6 hours to start builds
<cpaelzer> just wondering if I need to look for mistakes on my end or if it is just a hickup on the builders themselve
<LocutusOfBorg> cpaelzer, I guess the kernel intel foo bug
<cpaelzer> oh is today the patchday
<cpaelzer> yeah things might recycle then
<cpaelzer> but I wondered as all arches stall me
<cpaelzer> but if there are core components recycled that could be possible
<Laney> all builders are off, see the topic in here
<cpaelzer> thanks Laney
 * cpaelzer wonders if he every read a topic unless people ask him to do so :-)
<LocutusOfBorg> I actually tried to read the topic, but hexchat when topic is long, shows just the end, not the begin :/
<Laney> can't type /topic or something?
<LocutusOfBorg> yep, but it didn't come in my mind that it could have been written at the begin, it was a brain bug :)
<JackFrost> LocutusOfBorg: Aha, wondered if that was it.
<JackFrost> Laney: I versioned it the way I did so that it'd satisify (>= 11) depends, though technically isn't the most accurate version.
<JackFrost> LocutusOfBorg: I specifically wondered as I'm waiting to see what happens before I take action on xfce4-indicator-plugin.
<Laney> JackFrost: thanks, can you post on the bug please so that I don't forget and others know?
<JackFrost> Sure, I'm not attached to the version string though.
<Laney> I guess someone can help review / consider it
<LocutusOfBorg> JackFrost, the desiderata should be to move everything in main to the new dependency
<LocutusOfBorg> jbicha, is it possible to switch network-manager-applet to aytana-appindicator?
<JackFrost> Debian #880169.
<ubottu> Debian bug 880169 in src:network-manager-applet "Please enable Indicator support and build against Ayatana Indicators" [Wishlist,Open] http://bugs.debian.org/880169
<LocutusOfBorg> nice
<LocutusOfBorg> transmission can probaably loose support
<JackFrost> https://wiki.debian.org/Ayatana/IndicatorsTransition
<LocutusOfBorg> and update-notifier is left
<LocutusOfBorg> why update-notifier is not in that list?
<JackFrost> Because that's not a package.
<JackFrost> !info update-notifier unstable
<ubottu> Package update-notifier does not exist in unstable
<cking> Laney, FYI, I fixed that issue with stress-ng very late last night, so it should be fine now
<cking> http://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=25292428d235e2e96a3590ba7a48ef823ef0226a
<Laney> cking: great, thanks!
<Laney> if you ping me just before you upload it next time I can revert the blacklist
<Laney> ha
<Laney> nice fix
<cking> stupid bug more like ;-)
<Laney> try THIS for stress *pow pow pow*
<cking> it's very good at stopping everything :-)
<LocutusOfBorg> JackFrost, I'm talking about ubuntu
<LocutusOfBorg> !info update-notifier bionic
<ubottu> update-notifier (source: update-notifier): Daemon which notifies about package updates. In component main, is optional. Version 3.188 (bionic), package size 50 kB, installed size 238 kB
<cpaelzer> hmm - is is a common issue that dbgsym of old releases are not copied forward
<cpaelzer> libopts25 was last uploaded in zesty
<cpaelzer> and I can't find its -dbgsym in bionic
<cpaelzer> I can however
<cpaelzer> use https://launchpad.net/ubuntu/bionic/amd64/libopts25-dbgsym/1:5.18.12-3
<cpaelzer> and things work
<cpaelzer> just wondering if I stumble or found an actual issue
<cpaelzer> rbasak: ahasenack: I'd appreciate if you could take a look at the dbgsym question I had above ^^ - just to be sure it is no real thing
<ahasenack> cpaelzer: sorry, I don't see the question in my history, my irc proxy must have been down
<rbasak> They end up on ddebs I think?
<rbasak> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
<rbasak> libopts25-dbgsym isn't published in Zesty either.
<rbasak> You have to add the ddebs repo to get it
<ahasenack> rbasak: do you know if I have perms to use bileto now? I would like to run the ocfs2-tools dep8 tests there. I can upload that particular package to the archive, if that matters
<cjwatson> bileto ain't going to get very far for a while (see topic)
<ahasenack> I see
<ahasenack> does that include ppas?
<cjwatson> yes
<ahasenack> ok
<cpaelzer> rbasak: I have the repo in bionic
<cpaelzer> rbasak: and I get other bionic ddebs just fine
<rbasak> cpaelzer: ah, so it's a missing ddeb?
<rbasak> ISTR some kind of publication problem for ddebs a while back.
<rbasak> Where some ddebs were lost or something.
<rbasak> I wonder if it's that.
<cpaelzer> they are still avail on the LP link I had above
<cpaelzer> let me check if it would have worked in zesty itself
<cpaelzer> yep working just fine in zesty
<cpaelzer> I'll sping up a few contianers and make an overview a) to be sure and b) to outline the issue better
<cpaelzer> rbasak: ok - it works now on all releases I tested not only zesty
<cpaelzer> checking the sys I originally had the issue now ...
<doko> apw, xnox: about 1521174, who should be the bug subscriber?
<xnox> doko, updates will be published in the upstream linux-firmware repository from now on. Not sure if it makes sense to have this package stand-alone or be folded into linux-firmware
<xnox> doko, foundations or kernel.
<xnox> either or both will do
<xnox> subscribed foundations bugs
<jbicha> LocutusOfBorg: I don't know anything about the current status of the ayatana stuff in Ubuntu, ask sunweaver or flexiondotorg
<apw> bug #1521174
<ubottu> bug 1521174 in amd "[MIR] amd64-microcode (multiverse -> main)" [Undecided,Confirmed] https://launchpad.net/bugs/1521174
<pavlix> pitti: HI!
<pitti> hey pavlix, how are you? :-)
<pavlix> pitti: I quit Red Hat at the end of April and went freelance. I moved back to Prague in August. And I started a short term contract on network configuration in September. What do you think? :)
<pitti> pavlix: sounds great, good luck with it! certainly a lot more effort to look for customers yourself, but also exciting :)
<pavlix> pitti: I actually had to postpone the search for customers as I was already in contact with more than I can handle simultneously.
<pavlix> pitti: Sounds like this wans't a bad time to get back to the market after five years.
<pavlix> pitti: Anyway, I heard Ubuntu has some news regarding network management.
<pitti> pavlix: right, it's using netplan by default now, to replace ifupdown with networkd
<pitti> and allow a more common config between that and NM from cloud configs, etc.
<pavlix> pitti: When we're at it, unification and progress is exactly the area I'm attacking now.
<pavlix> pitti: Debian is keeping ifupdown forever?
<pitti> pavlix: not sure, but it's certainly not pushing strongly away from it
<pavlix> pitti: What is the main motivation for networkd?
<pitti> it had been unmaintained for a while, but now Guus took it over and he is pretty active
<pavlix> pitti: As networkd is a half-baked and hacky solution.
<pitti> pavlix: it's a lot simpler and more robust than ifupdown, supports real hotplugging, more types of virtual devices OOTB
<pitti> well, ifupdown is doubly (or more) that :)
<pavlix> pitti: I used ifupdown for ages and used all the scripting features there. I'm afraid networkd has close to no scripting features now.
<pitti> https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml links to the full specification and use case analysis, but it's Canonical-internal (so I can't access it either any more)
<pitti> pavlix: well, it's not going away, just not used by default any more
<pitti> also, these scripting facilities got abused a lot and were the source of many bugs and race conditions
<pavlix> pitti: Everything can be abused. That's not the best reason to avoid it.
<pitti> but a good reason to replace it with something more robust that avoids the races :)
<pitti> as said, this is fine for the vast majority of use cases, like pretty much every cloud/virtual image; desktops use NM; and for the remaining 1% of use cases you can pick whatever tool you need
<pitti> it's an opinionated default, nothing more
<pavlix> pitti: Sure.
<pavlix> pitti: Anyway I have a plan to automate testing a bit with kernel namespaces and test the network services that way.
<xnox> pavlix, do checkout networking-test.py in systemd tree; and the intergration test-suite in netplan.
<xnox> pavlix, the netplan integration tests a lot of networkd and network-manager.... which does uncover how unreliable network-manager is =/
<xnox> pavlix, more networking setups and more networking tests is always needed, because it's really under-tested.
<bdmurray> jbicha: So I should reject both evolution and e-d-s since there will be a new version shortly?
<jbicha> bdmurray: that sounds good
<bdmurray> mvo, ogra_: Could somebody respond to my comment on bug 1623125?
<ubottu> bug 1623125 in initramfs-tools (Ubuntu Xenial) "fixrtc script does not catch "Last mount time: n/a" string" [Undecided,New] https://launchpad.net/bugs/1623125
<rbasak> smoser: what if we said that from Bionic onwards, cloud-init will default to manage_etc_hosts: localhost. What would that break?
<rbasak> In addition, we declare that on Ubuntu, the responsibility to do the right thing lies with either the installer (for non-cloud), or cloud-init (for cloud).
<rbasak> That would leave lxd the responsibility only when using a stgraber image, I think.
<stgraber> rbasak: images:ubuntu/series/arch already templates /etc/hosts (and I do that for all distros we build images for)
<stgraber> it's just with the images that use cloud-init that we don't mess with any of those files :)
<rbasak> stgraber: oh? How does lxd know to apply templates?
<rbasak> Is there metadata in the image or something?
<stgraber> oh, except we do /etc/hostname even in the cloud-init ones these days due to the dhclient race IIRC
<stgraber> rbasak: the metadata tarball contains a yaml doc that lists all the templates to run and when to run them
<rbasak> I see. Nice!
<rbasak> smoser: so my proposed solution works universally then I think?
<rbasak> Treat lxd as an "installer" when using non-cloud.
<smoser> rbasak: it would break the case where something expects hostname --fqdn to do something meaningful
<smoser> which is a flawed expectation to be sure
<rbasak> smoser: doesn't manage_etc_hosts: localhost *fix* "hostname -f" to return the specified FQDN?
<rbasak> Unless the name supplied to cloud-init is bad, that is, but DNS had it right.
<rbasak> In which case, isn't that a horribly broken cloud?
<smoser> sorry, i think i mispoke. i think
<smoser> its more
<smoser>  $ hostname --ip-address
<smoser> 127.0.1.1
<smoser> some programs (i can't find the reference, but in my head it tends to be java/tomcat, but probably other things)
<smoser> try to figure out "how can someone communicate with me"
<smoser> and do so by looking up their hostname in dns
<smoser> and then publishing that.
<smoser> and when there is 127. address in /etc/hosts, that clearly is busted.
<smoser> that is also very clearly broken assumptions and simplistic view of the world
<smoser> i think i'm ok to do that though.
<rbasak> I see
<rbasak> I agree that it seems an appropriate thing to break in order to fix the general problem.
<rbasak> (only in a new release of course)
<pavlix> xnox: I know pretty well about reliability of NetworkManager and did quite some work to improve it but was unfortunately not able to continue.
<pavlix> xnox: My special interest is in specialized tests...
<pavlix> xnox: Nice to meet you, by the way.
<mitya57> I get 500 internal server error when trying to retry autopkgtests, is that a known issue?
<mitya57> URL is http://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=s390x&package=python-ruffus&trigger=mathjax/2.7.2%2Bdfsg-1&trigger=sphinx/1.6.5-4
<pavlix> Son_Goku: You're everywhere. :)
<pavlix> Son_Goku: I came here to visit pitti.
<nacc> mitya57: i'm just guessing it might be due to /topic
<Son_Goku> heh
<Son_Goku> you know he's also in #cockpit
<mitya57> nacc: not sure if autopkgtests are related to the buildd farm anyhow, but will try later, thanks
<pavlix> Son_Goku: Yep, I do, he answered my e-mail.
<dexterfoo> I found a bug in the apparmor profile of the inspircd package written by lamont jones. It doesn't allow connecting to(opening) any sqlite database files. This makes the included inspircd "m_sqlite3.so" module broken and useless
<nacc> !bug | dexterfoo
<ubottu> dexterfoo: 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.
<sarnold> dexterfoo: woot
<sarnold> dexterfoo: where's the profile for that live? in the package or somewhere else?
<dexterfoo> sarnold: in the package
<dexterfoo> https://packages.ubuntu.com/artful/amd64/inspircd/filelist
<sarnold> dexterfoo: sweet, as nacc points out, a bug report might be best, https://bugs.launchpad.net/ubuntu/+source/inspircd/+filebug
<dexterfoo> ok thanks
<lamont> dexterfoo: I think I missed a lot of things when I wrote that apparmor profile, tbf.  bugs welcome
<dexterfoo> lamont: cool. i'm not sure what the proper fix is to allow access to arbitrary sqlite files. but maybe just allow access to sqlite files in the /etc/inspircd/ directory. (The profile already allows reading all files in that directory, but for sqlite to work, it needs "k" permission in addition to "r" permission)
<xnox> pavlix, hehehe well in that case you are all set i guess!
<xnox> pavlix, i'm just a minion.
#ubuntu-devel 2018-01-05
<pavlix> xnox: So what are your main interests?
<xnox> pavlix, volleyball and skiing =)
 * xnox giggles
<xnox> pavlix, been around since about 2012. DD, Ubuntu Core Developer, ex SPI director. Mostly code in C and Python. Did a bit of upstart, a bit of systemd, currently doing a bit of s390x.
<pavlix> xnox: That sounds nice. I joined Red Hat in May 2012 as a core NetworkManager developer at that time but later worked with the packagers of various network services and recently left to go back freelance.
<xnox> pavlix, fun!
<sunweaver> LocutusOfBorg: what do you need to know about Ayatana Indicators?
<JackFrost> sunweaver: Problem for remmina was that remmina is in main and ayatana indicators aren't.
<sunweaver> ouch.
<sunweaver> why is remmina main?
<sunweaver> it would require a ubuntu series file then I guess that reverts the upstream patch in remmina.
<ginggs> flexiondotorg: would you add Conflicts: telegram-desktop to your telegram PPA packages please?  It would prevent future bugs like LP: #1740708
<ubottu> Launchpad bug 1740708 in telegram-desktop (Ubuntu) "package telegram-desktop 1.1.23-1 failed to install/upgrade: trying to overwrite '/usr/share/applications/telegramdesktop.desktop', which is also in package telegram 1.1.23-1~artful1.0" [Undecided,Invalid] https://launchpad.net/bugs/1740708
<JackFrost> sunweaver: https://ubuntudiff.debian.net/q/package/remmina just have to flip deps really.
<sunweaver> we could do a libappindicator3-dev (>= <ubuntu-version) | libayatana-appindicator3-dev in the Debian package, so that patch would be unnecessary.
<sunweaver> I am in touch with remmina upstream, so I could ask to get the translations.patch upstreamed, too.
<sunweaver> JackFrost: I just pinged mfv from Debian on this who maintains remmina in Debian and lives "next door" to upstream of remmina.
<JackFrost> Ooooh, fancy.
<JackFrost> Thanks, sunweaver.
<sunweaver> we hang out on #debian-remote (OFTC)
 * sunweaver loves shrinking the ubuntudiff website...
<JackFrost> sunweaver: Indeed, though in the past I didn't want to push any indicator stuff on to Debian.
<sunweaver> that's why I started a fork....
<sunweaver> because Inidicators from Launchpad do not work on non-Ubuntu systems.
<JackFrost> sunweaver: I'm Unit193, btw..
<sunweaver> this man(?) is confusing me...
<bdrung_work> mvo, hi. can you merge initramfs-tools from Debian unstable to bionic (you are the last uploader) or should i do it?
<bdrung_work> apw, ^
<mvo> bdrung_work: you are welcome to merge it, my contribution was mostly a drive-by fix
 * apw is happy for anyone to merge it indeed
<rbasak> slangasek: ahasenack pointed out to me that the Breaks in Xenial seems to be holding back distro-info-data. I had noticed that but ignored it previously.
<rbasak> slangasek: I think it's because the Breaks in distro-info-data for Xenial is wrong.
<rbasak> Because on Xenial, juju-core is a 1.x series transitional package.
<rbasak> So those of us who upgraded into Xenial with juju 1.x previously installed have a blocked distro-info-data package.
<ahasenack> https://pastebin.ubuntu.com/26325364/ ^
<bdrung_work> apw, done
<bdrung_work> ubuntu carries a huge amount of change. many of them should be upstreamed.
<apw> bdrung_work, yes, yes it should
<slangasek> rbasak: it certainly appears that distro-info-data's Breaks don't have a version of juju-core in xenial that satisfies them, so something needs fixed...
<slangasek> rbasak: so distro-info-data probably needs to Breaks: juju-2.0 (<< 2.2.6) instead?
<rbasak> slangasek: that sounds about right. But only in Xenial.
<rbasak> Unless future series have the same arrangement in Juju?
<rbasak> Otherwise that'll be painful for future distro-info-data imports :-(
<slangasek> rbasak: it only matters for xenial
<slangasek> rbasak: well, it mattered also for zesty, but EOL
<rbasak> slangasek: OK. I'm not really familiar with the details. Just passing on the report :)
<slangasek> rbasak: distro-info-data reuploaded, if you want to review
<rbasak> slangasek: diff looks empty apart from changelog?
<slangasek> rbasak: but is it a good changelog? ;)
<slangasek> looking
<slangasek> rbasak: rejected/reuploaded, thanks
<rbasak> slangasek: looks good, but do you know any reason for distro-info-data 0.28ubuntu0.3 to be in the security pocket?
<slangasek> rbasak: not offhand
<rbasak> Seems like some distro-info-data updates were deliberately being put in there.
<rbasak> So now I don't know whether it's correct for this fix to go in there, or all fixes to distro-info-data should go into the security pocket :-(
<mdeslaur> rbasak: if you're sruing it, just get someone to pocket-copy it to -security after
<rbasak> mdeslaur: ah, OK. I was under the impression that a pocket copy in that direction wasn't always safe.
<rbasak> (though seems unlikely to be an issue for distro-info-data)
<mdeslaur> it isn't, but this package only has data in it
<rbasak> I'm happy with your ack then. Thanks :)
<mdeslaur> rbasak: oh, was that a regression only in post 0.3?
<mdeslaur> sorry, I lack a bit of context
<rbasak> I'll need to check the versions.
<mdeslaur> you need to make sure you don't break juju-core users that don't have -updates enabled
<rbasak> A distro-info-data update caused a regression in Juju which was parsing the data wrong.
<rbasak> We have a Breaks: for it now.
<mdeslaur> is the breaks on a version that is in -security?
<rbasak> And juju is fixed now.
<rbasak> Looking
<rbasak> The version of distro-info-data in xenial-security won't break any version of Juju.
<mdeslaur> right, so if you push the new distro-info-data to -security, environments that have -updates disabled will break, no?
<mdeslaur> because the new juju won't be available
<rbasak> But if we did pocket copy the version of distro-info-data I just accepted into xenial-proposed to xenial-security, then the version of src:juju-core in xenial-security won't work with it.
<rbasak> Right
<rbasak> So better not do that.
<mdeslaur> right
<tsimonq2> doko: Looking at GCC 8 failures, fixing Debian bug 885128 should fix a few failing Qt packages, and qtlocation is interesting because it could (not sure) be a GCC segfault. Otherwise the rest of the Qt failures should be fixed upstream...
<ubottu> Debian bug 885128 in g++-8 "g++-8: Missing file: avx512bitalgintrin" [Important,Open] http://bugs.debian.org/885128
<tsimonq2> All I have for now :)
#ubuntu-devel 2018-01-07
<blowme847> ââââââââââââââââ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 vciwegrt: alexbligh1 caribou karstensrage ââââââââââââââââ
<blowme847> âââââââââââââ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 ygqvvx: jtaylor dasjoe kees âââââââââââââââ
<blowme847> ââââââââââââââ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 asyprsrx: austin987 leosilva rharper âââââââââââââ
<tsimonq2> ugh really?
<tjaalton> what's the problem with ppa builders? I've uploaded a package days ago and it still says "start in 1 hour"
<wxl> tjaalton: /topic #lanchpad
<wxl> ugh you get the idea
<tjaalton> aha
<tjaalton> nice
<wxl> yeah..
<dax> the /topic for here says the same thing, fwiw
<dax> my guess based on nothing whatsoever would be meltdown/spectre
<wxl> i think that's a safe guess
<wxl> kernels coming soon
<wgrant> Indeed, Spectre is the problem.
#ubuntu-devel 2019-01-02
<LocutusOfBorg> cyphermox, I uploaded most of dkms ubuntu changelog to debian
<LocutusOfBorg> https://salsa.debian.org/debian/dkms
<LocutusOfBorg> can you please tell me if I have to upload this remaining delta too? https://paste.ubuntu.com/p/jBF8gndVYY/
<LocutusOfBorg> this is the last bit
<teward> can an SRU team member review gparted in Bionic's proposed queue for https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1779292 please?  It should already be pending in unapproved thanks to jbicha sponsoring the upload.
<ubottu> Launchpad bug 1779292 in gparted (Ubuntu Bionic) "GParted fails to shrink an LVM PV with lvm2 >= 2.02.171" [High,In progress]
<teward> oops wrong channel :|
<teward> i'll wait before reposting to -release
<teward>  #ubuntu-release*
<teward> god I can't type today
<jbicha> teward: it's already in the queue and the SRU team will review it when they get back from holidays
<jbicha> https://launchpad.net/ubuntu/bionic/+queue?queue_state=1
<teward> jbicha: ack.
<teward> odd it doesn't show up in the pending SRUs list, but that's probably because it's sitting in unapproved?
<jbicha> it's part of "Upload queue status at a glance"
<teward> ah.
<teward> see I keep forgetting that exists >.>
<jbicha> hmm
#ubuntu-devel 2019-01-03
<tjaalton> jbicha: please coordinate mesa uploads with me
<jbicha> tjaalton: ok, it was blocking building any mesa rdepends because of the awkward lm-sensors transition
<tjaalton> I know, and uploaded -1u2 which was identical to your u3
<tjaalton> not knowing 1u2 had already happened
<tjaalton> was first trying to build/upload a new point-release
<jbicha> I think we can re-enable the sensors dependency now but I didn't test build it
<tjaalton> I'll do that with the point-release tomorrow
<tjaalton> just needs an upload
<jbicha> sorry for the inconvenience. I stumbled across lm-sensors because sane-backends wouldn't build until net-snmp was rebuilt first
<tjaalton> ok
<tjaalton> anyway, bedtime for me..
<jbicha> lm-sensors was hanging out in -proposed for 2 weeks waiting to trap someone!
<resnik2> guys, I'm hitting a bug/feature in grub and I'm not sure whether there's anyone knowlegeable enough to tackle it. Are grub bugs just forwarded upstream?
<teward> depends on the bug probably
<resnik2> getting "alloc magic is broken at xx: 0" while trying to boot an unsigned efi bin while secure boot is enabled.
<resnik2> It, at least, should've outputted "wouldn't load untrusted bin" or alike, but not crash outright
#ubuntu-devel 2019-01-06
<volty> Hi, guys. Last night I installed kubuntu-18.04, and today I woke up with a dead computer. Was going to throw it and buy a new one.
<volty> Switch on and no video signal, no other signs of life except the fan.
<volty> After hours of trying, I came with the idea of googling for ubuntu bios corrupt after installation, and found that it happens with some computers since version 17.
<volty> Anybody alive here?
<krytarik> volty: #ubuntu is the support channel.
<volty> I'm not taking about support!!!
<volty> I already solved my problem. And by case. Was going to throw my pc. Read what I write before answering generic ...
<volty> I am asking you, devels, to take note and broadcast. The installation process should warn the user that his bios is going to be touched. The quarrel about who's responsible (producer of mb and/or bios, or ubunt) has no sense
#ubuntu-devel 2019-12-30
<xnox> hallyn:  all architectures are self-service these days.
#ubuntu-devel 2020-01-01
<sdhd-sascha> hey, if so, then - happy new year :-)
#ubuntu-devel 2020-01-03
<JackFrost> For private files in public bugs, does Canonical have some form of private tracker to keep things historical internally?
<sladen> JackFrost: if there are necessarily private files; make a private bug report.  But it will get less eye-balls.  Instead try to avoid the private file; eg. by refining/reducing the use-case
<JackFrost> sladen: Actually that's not what I'm getting at, the bug was most certainly not private, but the testcase was.  It was about a SRU that hit an issue (which amusingly didn't happen in the development series), and I'm hoping that a new release that's about to start filtering in will have that regression again.
<chiluk> Where's the latest documentation for +1 maintenance.  I thought I did a proper +1 upload for vagrant + focal, but it seems to have gone into a black hole....
#ubuntu-devel 2020-01-04
<HayashiEsme> Anyone in?
<HayashiEsme> Out of curiosity, have there been any Ubuntu Open/Developer Weeks in recent times?
<sladen> hello HayashiEsme
<The_LoudSpeaker> Did anyone report a touchpad issue after recent updates on ubuntu bionic (18.04) ? Two of my friends who have ubuntu 18.04 reported touchpad not working after recent updates.
<The_LoudSpeaker> Reported as in, told me via a message.
<HayashiEsme> Hiya:)
<cjwatson> JackFrost: Attachments to bugs always have exactly the same privacy settings as the bug they're attached to, so I'm not sure how private files in public bugs could have existed in the first place, unless they were in a separate bug somewhere
<cjwatson> chiluk: Launchpad sent you a rejection message first time round because you didn't build the upload with -sa so the .orig.tar.xz was missing, but I see you seem to have figured it out
<The_LoudSpeaker> Re: touchpad issue. https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1858219 this is exactly what my friend is facing. I will ask him to create an account on launchpad and tick as affected.
<ubottu> Launchpad bug 1858219 in ubuntu-release-upgrader (Ubuntu) "dell vostro 15 3568 touchpad not wrking after regular update, external mouse is working fine." [Undecided,New]
<HayashiEsme> Hey there, I'm interested in contributing to Ubuntu. I've been going through the contributing wiki, only to've realized that the docs I've been following from here seem to be somewhat outdated. (https://wiki.ubuntu.com/ContributeToUbuntu#Contributing_to_the_Universe_Repository_.28MOTU.29) Is there a link to anything new or can someone point me into
<HayashiEsme> the right direction? :3
<HayashiEsme> (Also, is #ubuntu-motu a IRC channel people use much? I've said hi a few times but I've not seen any activity there)
<JackFrost> cjwatson: It was passed to the Canonical person looking into it for triage, then on to the one that fixed the issue.
#ubuntu-devel 2020-01-05
<HayashiEsme> https://wiki.ubuntu.com/SponsorshipProcess
<HayashiEsme> whoops sorry!
<HayashiEsme> mean to say: Hey there, I'm interested in joining MOTU, is this wiki page still accurate for how to seek sponsorship? https://wiki.ubuntu.com/SponsorshipProcess
<cjwatson> JackFrost: If it was just passed around under the table then I'm not aware of any private tracker
<JackFrost> cjwatson: OK, thank you very much.
<brlin> Hello, I would like to ask why does the /lib/x86_64-linux-gnu/libpthread-2.27.so file has executable permission(x)?
